As promised in my previous post, I’d like to do a better job at delivering status updates on Internationalization and Localization technologies at Gecko at shorter intervals than once per year.
In the previous post we covered recent history up to Firefox 58 which got released in January 2018. Since then we finished and shipped Firefox 59 and also finished all major work on Firefox 60, so this post will cover the two.
Firefox 59 (March)
Firefox 58 shipped with a single string localized using Fluent. In 59 we made the next step and migrated 5 strings from an old localization system to use Fluent. This allowed us to test all of our migration code to ensure that as we port Firefox to the new API we preserve all the hard work of hundreds of localizers.
In 59 we also made several improvements to performance of how Fluent operates, all of that while waiting for the stylo-chrome to land in Firefox 60.
In LocaleService, we made another important switch. We replaced old general.useragent.locale
and intl.locale.matchOS
prefs with a single new pref intl.locale.requested
.
This change accomplished several goals:
- The name represents the function better. Previously it was pretty confusing for people as to why Gecko doesn’t react immediately when they set the pref. Now it is more clear that this is just a requested locale, and there’s some language negotiation that, depending on available locales, will switch to it or not.
- The new pref is optional. Since by default it matches the
defaultLocale
, we can now skip it and just treat its non-presence as the default mode in which we follow the default locale. That allowed us to remove some code. - The new pref allows us to store locale lists. The new pref is meant to store a comma separated list of requested locales like
"fr-CA, fr-FR, en-US"
, in line with our model of handling locale lists, rather than single locales. - If the pref is defined and the value is empty, we’ll look into OS for the locale to use, making it a replacement for the matchOS pref.
This is important particularly because it took us very long time to unify all uses of the pref, remove it from all around the code and finally be able to switch to the new one which should serve us much better.
Next come a usual set of updates, including update to ICU 60 by Andre, and cleanups by Makoto Kato – we’re riding the wave of removing old APIs and unifying code around ICU and encoding_rs.
Lastly, as we start looking more at aligning our language resources with CLDR, Francesco started sorting out our plural rules differences and language and region names. This is the first step on the path to upstream our work to CLDR and reuse it in place of our custom data.
Notable changes [my work] [intl]:
- Bug 1411012 – Experimentally migrate a small chunk of .properties/.DTD to Fluent
- Bug 1414390 – Introduce a pref to store BCP47 locale list
- Bug 1405993 – Update our in-tree ICU to 60
- Bug 943272 – Get rid of nsIPlatformCharset
Firefox 60 (May)
Although Firefox 60 has not yet been released as of today, the major work cycle on it has finished, and it is currently in the beta channel for stabilization.
In it, we’ve completed another milestone for Fluent migrating not just a couple, but over 100 strings in Firefox Preferences from the old API. This marks the first release where Fluent is actually used to localize a visible portion of Firefox UI!
As part of that work, we pushed our first significant update of Fluent in Gecko, and landed a special chrome-only API to get Fluent’s performance on par with the old system.
With an increase in the use of Fluent, we also covered it with Mozilla eslint rules, improved missing strings reporting, and wrote an Introduction to Fluent for Firefox Developers.
On the Locale Management side, we separated out mozilla::intl::Locale
class and further aligned it with BCP47.
But the big change here is the switch of the source of available locales from the old ChromeRegistry to L10nRegistry.
This is the last symbolic hand-over from the old model to the new, meaning that from that moment the locales registered in L10nRegistry will be used to negotiate language selection for Firefox, and ChromeRegistry becomes a regular customer rather than a provider of the language selection.
We’re very close to finalize the LocaleService model after over a year of refactoring Gecko!
Regular healthy number of cleanups happened as well. Henri switched more code to use encoding_rs, and updated encoding_rs to 0.7.2, Jeff Walden performed a major cleanup of our SpiderMonkey Intl source code, Andre added caches for many Intl APIs to speed them up and Axel updated compare-locales to 2.7,
We also encountered two interesting bugs – Andre dove deep into ICU to fix `Intl.NumberFormat` breaking on roundings in Persian, and I had to disable some of our bidirectionality features in Fluent due to a bug in Windows API.
Notable changes [my work] [intl]:
- Bug 1424682 – Migrate the chrome of Preferences to the new Localization API
- Bug 1435912 – Migrate Preferences::General XUL to .ftl
- Bug 1426054 – Update Fluent in Gecko to 0.6
- Bug 1363862 – Add a chrome-only DOM API for localization
- Bug 1431260 – Migrate LocaleService::AvailableLocales from ChromeRegistry to multilocale.json
- Bug 1431356 – Update encoding_rs to 0.7.2
- Bug 1431957 – Split up Intl bits across multiple files into a builtin/intl subdirectory
- Bug 1432229 – Land compare-locales 2.7 in mozilla-central
Summary
With all that work in, we’re slowly settling down the new APIs and finalizing the cleanups and the bulk of work now is going directly into switching away from DTD and .properties to Fluent.
As Firefox 60 is getting ready for its stable release, we’re accelerating the migration of Preferences to Fluent hoping to accomplish it in 61 or 62 release. Once that is completed, we’ll evaluate the experience and make recommendations for the rest of Firefox.
Stay tuned!