Closed Bug 1586984 Opened 5 years ago Closed 5 years ago

Add empty FTL files to l10n repos to avoid falling back to English

Categories

(Mozilla Localizations :: Other, task)

task
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

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.
Assignee: nobody → francesco.lodolo
See Also: → 1464156

This is the list of files missing in localizations that get added if needed. Just to have something to think about for starters.

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.

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

Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
See Also: → 1779330

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.

Blocks: 574986
No longer blocks: 574986

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.

You need to log in before you can comment on or make changes to this bug.