Categories: L10n Reports

Firefox L10n Report – Aurora 50

Here’s an outline of what is currently in Aurora this cycle for Firefox 50 and some information on the accomplishments of the l10n Community during the previous cycle.

Current Aurora Cycle – Firefox 50

Key dates for this cycle:

  • Beta (49): localization updates for already shipping locales must be completed before 31 Aug. For reference, the date is roughly 2 weeks before the next release date, and it’s the last good day to include your updates into a Beta build.
  • Aurora (50): localization updates must be completed before 12 September. That’s the Monday, also known as merge day, before the next release of Firefox.

String breakdown:

  • Firefox Aurora desktop has 155 added strings (125 obsolete). About 43% of the new strings are for Developer Tools.
  • Fennec Aurora has 88 new strings (61 obsolete). 11 new strings are Fennec-only (in /mobile).

There are currently no pending requests to uplift patches with strings to Aurora.

For further details on the new features you can check the release notes (they’re usually published a few days after release):

Current Release Cycle (Firefox 48)

Noteworthy events for Firefox 48 (release date 3 Aug):

  • 52 locales, corresponding to 63% of our shipping locales, signed off updates for Firefox 48 on desktop.
  • 48 locales, corresponding to 72% of our shipping locales, signed off updates for Fennec 48 on Android.

As recently announced, localizers are not going to request sign-offs anymore for Firefox and Fennec, l10n-drivers will sign-off and review any update landing in the repository, for both Aurora and Beta.

For this reason we’re probably not going to include this section in the next cycle reports, while we determine more meaningful metrics to track localization activity.

Noteworthy Changes Available in Aurora

These are some of the interesting changes introduced in the last cycle.


The new Containers feature is not enabled outside of Nightly (it might be included in a future Test Pilot experiment). If you want to test it, you need to manually switch the preference privacy.userContext.enabled to True.

More details about this feature are available in this blog post.


As explained in the previous report, team is starting to use a new way to define keyboard shortcuts (not accesskeys), adopting a syntax similar to Electron.

You should not translate fragments like “CmdOrCtrl”, “CmdOrCtrl+Plus” (Plus indicates the ‘+’ key), “CmdOrCtrl+Shift+D”. Also a reminder that you should not be changing shortcuts in general, unlike accesskeys, unless the default keyboard layout for your locale doesn’t include that specific key, or combination of keys. Translating these keys will result in the tools being broken.

Several developer tools are also moving strings from .DTD to .properties, it should be expected to have a perfect match in TM tools like Pontoon & Pootle between old and new strings. For example:


The string with ID or was changed from Oriya to Odia to reflect a change in the language name. This kind of changes can’t introduce a different ID, since the locale code remains the same.

Common Issues

Translated reference entities and untranslated labels

In .DTD files, a string can contain a reference to another entity in the form of &another_entity_name; (note the ampersand at the beginning and the semicolon at the end). These are references to other string IDs and should not be translated.

Example from Fennec:

You can always turn this off in &settings; under &pref_category_general;.

A few locales translated the first &settings;, generating an error. It’s also good to remember that these errors break the multi-locale Android build for all locales, en-US included, and that’s why you will see someone from l10n-drivers committing a fix directly in tools (Pontoon, Pootle) or Mercurial. Please remember to keep an eye on the dashboard page for your locale and verify errors and warnings.

On the other hand, Pootle displays a string with an accesskey as &Show: the label is “Show”, the accesskey is “S” (the character after the ampersand). Note that there’s no semicolon at the end. This has to be translated, and dropping the ampersand will make the accesskey fallback to English. Never add the accesskey to your label, e.g. “Show (S)”. For further details about accesskeys, see this discussion on dev-l10n.

Thanks to everyone for your dedication and hard work this last cycle. If you note anything missing in these reports, or would like to see other information included, please let me know.

No comments yet

Post a comment

Leave a Reply

Your email address will not be published. Required fields are marked *