Add empty FTL files to l10n repos to avoid falling back to English
Categories
(Mozilla Localizations :: Other, task)
Tracking
(Not tracked)
People
(Reporter: flod, Assigned: flod)
References
Details
Attachments
(2 files)
In the past 24h I received multiple reports of menus showing up in English (tab context, findbar). Turns out we added a new file, sync.ftl
, which is loaded lazily.
MozXULElement.insertFTLIfNeeded("browser/tabContextMenu.ftl");
That's the same context used by other UI files, and explains why we fall back to English. That's an incredibly poor experience for users, especially in a world where we commit to ship any updates, not just complete localizations.
One solution would be to create empty FTL files to avoid the fallback. It's a poor solution, but it's better than the status quo (the proper solution would be bug 1464156).
I have two open questions:
- Do we add all FTL files, or just the ones loaded lazily?
- Do we update all locales? I was thinking of using Pontoon's API, get the locales above a certain threshold, and only add files for those. If a locale is below 60%, for example, it hardly makes sense to add those files.
Comment 1•5 years ago
|
||
This is the list of files missing in localizations that get added if needed. Just to have something to think about for starters.
Comment 2•5 years ago
|
||
Assignee | ||
Comment 3•5 years ago
•
|
||
I built a script this morning that looks at all missing FTL files, and ignores locales that are not in Pontoon and below a threshold.
Locales not available in Pontoon (23):
ak, bn-BD, bn-IN, csb, en-ZA, hto, kok, ku, mn, nr, nso, pbb, rw, sah, sat, ss, st, ta-LK, tn, ts, ve, zu
Threshold 70%
Total files to add: 470
Locales below 70% (38):
ace, af, arn, as, bo, brx, cv, frp, fur, gv, ilo, ixl, jiv, ks, lb, lg, lo, lus, mai, meh, mix, mk, my, ny, or, pai, quy, qvi, sc, scn, si, son, sw, tsz, uz, wo, xh, zam
Threshold 80%
Total files to add: 295
Locales below 80% (50):
ace, ach, af, arn, as, ast, bo, brx, bs, cv, frp, fur, ga-IE, gv, hy-AM, ilo, ixl, jiv, km, kn, ks, lb, lg, lo, lus, mai, meh, mix, mk, ml, my, ne-NP, ny, or, pa-IN, pai, quy, qvi, sc, scn, si, son, sw, ta, trs, tsz, uz, wo, xh, zam
Maybe 70% is a good compromise.
Assignee | ||
Comment 4•5 years ago
|
||
Slightly adapted plan: add FTL files to locales with more than 70% translated in Pontoon, but ignore files that are clearly stand-alone (i.e. used in a single context, like about:policies or about:support).
The script is running, and I will likely run it again in the future, until we solve the root problem.
I'm also adding a file with the license header, not just an empty file, e.g.
https://hg.mozilla.org/l10n-central/cs/rev/e6ab1b367c1649cc3a019a63e34d856db17b0b9a
Comment 5•2 years ago
|
||
I've modified the Taskcluster L10n repackage jobs for Thunderbird in bug 1779330 to create missing .ftl files automatically. . The code is based on https://github.com/flodolo/fluent-migrations/blob/master/scripts/add_missing_ftl_thunderbird.py; i left out the pieces that query Pontoon for completion status.
The idea is to remove the need to update the l10n-central repositories since you're a finite resource. It should port to mozilla-central easily enough if you think it would be useful.
Assignee | ||
Comment 6•10 months ago
|
||
This problem has been impacting us a lot more, since the update to l10n-changesets.json was moved to autoland (bug 1752111).
Before, it was possible for me to run migrations in the morning, and have the next build correctly localized. Now, we have at least one build in English (happened today), but we had cases where the timing was unfortunate, and we ended up with no translations over a long weekend for Nightly users.
Description
•