Translate interface filter showing no results with "Search in only untranslated strings" selected

This belongs to the locale queue. Translation module concerns content translation.

Did you visit the pages that print the strings you wish to translate?

I confirm the bug. There is no results for untranslated strings for other language but English (provided by Drupal). I have checked Russian. Possibly there is some logic behind that?

The problem is in _locale_translate_seek() function.

We need to apply language condition during join and not separately below. See attached patch.

Also I corrected Language or Languages title in header of table. If there is only one additional language added, when we use "All languages" in filter we will get plural Languages (but still we have only one added language).

#6: locale-untranslated.patch queued for re-testing.

Subscribe, I've noticed empty results when searching for strings, too.

Seems the latest patch partly fixes the issue.

Before:
http://skitch.com/yoroy/dsjqj/translate-interface-before

After:
http://skitch.com/yoroy/dsjqw/translate-interface-after

But searching for 'Read more', as used in teasers on the front page still doesn't return results.
This was the case where I hit on this issue: it's one of the few user-facing strings, I wanted to translate it to dutch.

@yoroy Can you see 'Read more' string when you just list all words without filters? I am not sure if this problem is related to this issue.

I get a total of 19 results when doing a blank search on all languages, translated or untranslated, all text groups.

@yoroy but can you see 'Read more' in the list of 19 results? If not then you will not find it with filters applied and this is not related to this issue. Possibly it is some other bug or not.

No it's not in there. Sorry for distracting from the issue.

I hope this issue is RTBC. Please review it.

+++ includes/locale.inc	10 Sep 2010 16:36:14 -0000
@@ -1510,7 +1510,15 @@ function _locale_translate_seek() {
-  $sql_query->leftJoin('locales_target', 't', 't.lid = s.lid');
...
+    $sql_query->leftJoin('locales_target', 't', 't.lid = s.lid AND t.language = :language', array(':language' => $query['language']));

@@ -1539,12 +1547,6 @@ function _locale_translate_seek() {
-    $sql_query->condition('language', $query['language']);

There's no real difference in the performed query here, since the query performs a left join.

+++ includes/locale.inc	10 Sep 2010 16:36:14 -0000
@@ -1554,7 +1556,8 @@ function _locale_translate_seek() {
+  $header = array(t('Text group'), t('String'), t('Context'), ($limit_language || count($languages) < 3) ? t('Language') : t('Languages'), array('data' => t('Operations'), 'colspan' => '2'));

Should use format_plural().

Powered by Dreditor.

Regarding the query there is big difference between two queries (the query is to select all source strings that do not have translations). Before patch the query was like following:

SELECT * FROM locales_source s 
LEFT OUTER JOIN locales_target t ON t.lid = s.lid 
WHERE (s.source LIKE '%') AND (t.translation IS NULL) AND (t.language = 'ru') 
ORDER BY s.source ASC

This means to join tables and then select all records with Russian language. This query does not make sense as if t.translation IS NULL that record should not exist in locales_target table but in other hand t.language = 'ru' means that record exists and language key is 'ru'.

After patch the query is similar to

SELECT * FROM locales_source s 
LEFT OUTER JOIN locales_target t ON (t.lid = s.lid) AND (t.language = 'ru')
WHERE (s.source LIKE '%') AND (t.translation IS NULL ) 
ORDER BY s.source ASC

That means to select all records from both tables where t.language = 'ru'. So if there is no ru translation in locales_target table the join will be with empty record so all values will be NULL. And that what we really need as after the join we select only records where translation IS NULL (that means that we haven't found any record in locales_target table).

In other cases I believe the queries are equal.

Regarding second point about format_plural() I have changed the patch.

This seems to be a quite major bug which hopefully still can make it into D7?

So the Drupal 7 release party in Gothenburg, Sweden will update, test and review this patch so we hopefully can make some progress on it.

I'm by no way stealing the issue by assigning it to me, just stating that I will coordinate some work on this later today.

I can confirm this bug. The patch in #17 fixes the problem as expected. But the patch only applied with offsets. So here is a re-roll of the patch in #17.

Do we need a test for this one?

Hi!
The patch above works like a charm! We also need a test to check that this actually works. the attached patch provides a test for this.

ouch!

The last patch was full of coding standards errors. Here is a better one.

Alright, it's not my day today =)

Here is a patch that actually does what it is supposed to do.

Patch applied, problem solved. Great work, dixon_ and fabsor :)

(This patch was made possible by Gothenburg Drupal 7 Release Party.)

Patch still works and applies without offset.

Steps to reproduce the problem:

1. Install fresh site
2. Install the Locale module
3. Go to admin/config/regional/language and add another language without importing any strings (everything will be untranslated in that language then)
4. Go to admin/config/regional/translate/translate and search for an existing string under your new language. Use the "Only untranslated strings".
5. See how an empty search result appears. Obviously we should have search hits here, because our newly added language doesn't contain any strings.

Next:

1. Apply patch
2. See how you get search hits and now can translate your strings
3. Go celebrate :)

The only problem I have is this code comment:

+++ includes/locale.inc	7 Jan 2011 20:36:43 -0000
@@ -1668,7 +1670,11 @@ function _locale_translate_seek() {
+  // Use singular Language if query is limited by language
+  // or there are less than 3 languages.

It doesn't flow in my mouth that good. And initial capital letter in Language confuses me. Attached is a patch that instead says this:

// Format the string according to number of languages used in the query.

Powered by Dreditor.

+++ modules/locale/locale.test	27 Jan 2011 08:56:05 -0000
@@ -502,6 +502,17 @@ class LocaleTranslationFunctionalTest ex
+    $this->assertNoText(t('No strings available when searching using another language than english.'), t('Search found the string.'));

1) "English" should be uppercase, no?

2) assertNoText() is an insufficient assertion when you actually expect something particular to be there. assertNoText() will pass even if it is horribly broken.

Lastly, this bug sounds a bit annoying/confusing for the end-user, but it's not major.

Powered by Dreditor.

This appears fixed in 8.x. I could not reproduce with the steps outlined in #24.