Filtering for strings with suggestions is broken.
When filtering for "Translated" and "Has suggestion" untranslated strings show up. Example
When filtering for "Untranslated" and "Has suggestion" no strings show up at all. Example

These results cannot be correct, no matter how I interpret the filter settings (I assume they are ANDed, not ORed).

CommentFileSizeAuthor
#2 drop-before.patch1.61 KBgábor hojtsy

Comments

gábor hojtsy’s picture

Hm, agreed, looks buggy. I'll need to grab a copy of the DB and experiment with this locally.

gábor hojtsy’s picture

Component: User interface » Database
Status: Active » Fixed
StatusFileSize
new1.61 KB

Actually, I looked at the live DB to diagnose this quicker. Compared the suggestion and translation flags. Thankfully, all this data is just caching of values from the translation table, so if its broken, we can regenerate.

mysql> select count(distinct(sid)) from l10n_community_status_flag where has_suggestion = 1;
+----------------------+
| count(distinct(sid)) |
+----------------------+
|                39651 | 
+----------------------+
1 row in set (0.14 sec)

mysql> select count(distinct(sid)) from l10n_community_translation where is_suggestion = 1 and is_active = 1;
+----------------------+
| count(distinct(sid)) |
+----------------------+
|                39651 | 
+----------------------+
1 row in set (0.19 sec)

mysql> select count(distinct(sid)) from l10n_community_translation where is_suggestion = 0 and is_active = 1;
+----------------------+
| count(distinct(sid)) |
+----------------------+
|                66595 | 
+----------------------+
1 row in set (0.48 sec)

mysql> select count(distinct(sid)) from l10n_community_status_flag where has_translation = 1;
+----------------------+
| count(distinct(sid)) |
+----------------------+
|                76522 | 
+----------------------+
1 row in set (0.27 sec)

So looks like flags were ok for suggestions (at least looking at the numbers) but not at all ok for translations (look there is a 10000 gap there). This got me thinking that the flag initialization code was at fault (this is too big of a difference to appear in one day).

So looked at the update code, and indeed, it is dropping the empty translation placeholders used previously, before calculating which strings had translations. So where empty placeholders existed before, it thought those have translations. To fix this quickly on the live DB, I sent the site to maintenance, dropped the flags and recreated them with the same code used in the update function.

mysql> delete from l10n_community_status_flag;
Query OK, 454804 rows affected (3.11 sec)

mysql> REPLACE INTO l10n_community_status_flag SELECT sid, language, MAX(has_suggestion) AS has_suggestion, MAX(has_translation) AS has_translation FROM (SELECT sid, language, (is_suggestion = 1 and is_active = 1) as has_suggestion, (is_suggestion = 0 and is_active = 1) as has_translation FROM l10n_community_translation HAVING has_translation = 1 or has_suggestion = 1) t GROUP BY sid, language;
Query OK, 443881 rows affected (4.05 sec)
Records: 443881  Duplicates: 0  Warnings: 0

Then checked your links, and they seemed to work fine, so brought the site back into operation.

Finally, for others updating the module, I've reordered the code so they'll have good data at the start. Committing this to the l10n_server module.

So all-in-all the live server should run on fine data, and the updates should get an older server to the right state. Thanks for the report.

linulo’s picture

I used the LocServ extensively and did not encounter any problems regarding this issue anymore.
Thank you very much for the quick action.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.