Multilingual Gecko Status Update 2019

Welcome to the fourth edition of Multilingual Gecko Status Update!

In the previous update we covered the work which landed in Firefox 61-64.

At the time, we were landing Fluent DOM Localization APIs, still adding mozIntl features, and we had close to 800 strings migrated to Fluent.

I indicated that 2019 should be quieter, and in result I reduced the update frequency to just one this year.

Let’s dive into what happened:

Firefox 65 (January 2019)

We left off at Firefox 64 introducing document.l10n API which became the core way to handle localization of Firefox UI.

In Firefox 65, we extended that to handle non-system-principal documents which means documents that don’t have special privileges – about:neterror etc.

There were a number of smaller changes, but the only other one that stands out is the landing of Intl.RelativeTimeFormat by André Bargull, and a period update to ICU 63 by him.

Notable changes [my work] [intl module]:

Firefox 66 (March 2019)

In Firefox 66 we deepened the relationship between Fluent and DOM making our layout block on initial translation.

It’s been a major milestone and I spent a lot of time testing for any potential regressions that may come out of placing Fluent on the blocking path, but fortunately we avoided any regressions and were able to get much closer to Fluent performing well on the startup path.

The only other noticeable change was the introduction of a sync path for Fluent in Gecko.

Since the very beginning we received request from the principal engineers to design Fluent as asynchronous, and that’s how we landed it in Gecko and implemented so far.

But startup path is one place where the risk of blocking UI on resource loading is not realistic, while getting the resources needed to paint the first UI is all that matters.

For that reason Boris Zbarsky asked me to make the main UI initial localization synchronous, and in Firefox 66 I landed a synchronous version of L10nRegistry API to enable that.

Notable changes [my work] [intl module]:

Firefox 67 (May 2019)

Firefox 67 was very quiet. My main focus was the C++ DOM bindings for Fluent, but only one change landed in this cycle.

Notable changes [my work] [intl module]:

Firefox 68 (July 2019)

This release may feel slightly busier than average.

I’ve continued integrating Fluent into DOM rewriting portions of the code to C++, most notably DOM Overlays API, but several other engineers were able to join and help me with that effort.

Mike Conley integrated intl.uidirection flag into DOMLocalization, Staś Małolepszy updated Fluent in Gecko to 0.12, while Gijs Kruitbosch tracked down a weird interaction between localization links and history state and fixed it!

Notable changes [my work] [intl module]:

Firefox 69 (September 2019)

In 69 the major focus was getting Fluent on the startup path, and for that to happen we needed to move many of the JS bits to C++.

I was able to migrate L10nMutationObserver and DOMLocalization to C++ and remove the JS counterparts completely.

On top of the work from Firefox 66, I added a data-l10n-sync flag that can be set on any document to make its initial translation synchronous.

Notable changes [my work] [intl module]:

Firefox 70 (October 2019)

An exciting release for intl!

On the Fluent side we were able to integrate Fluent into Gecko’s XUL cache system which put us finally on par with DTD and enabled the migration of the startup path to Fluent!

On the Intl API side, Andre and Jeff Walden landed a lot of updates to our system! The unified revision of Intl.NumberFormat which enables units has landed. Intl.Locale has landed, Andre also reduced the size of our ICU bundle, implemented Intl.RelativeTimeFormat.formatToParts, added fractionalSecondDigits to Intl.DateTimeFormat, cleaned up SpiderMonkey Intl build system, unified our language tag parsing around Unicode Locale Identifier spec, and fixed several smaller bugs.

Notable changes [my work] [intl module]:

Firefox 71 (December 2019)

After busy Firefox 70 cycle, 71 is much quieter.

Since we enabled Fluent on startup path, the whole cycle has been spent migrating strings to it, while in SpiderMonkey, the only notable changes were the implementation of Intl.ListFormat and the move of Intl.Locale parsing from JS to C++ for performance reasons.

Notable changes [my work] [intl module]:

Firefox 72 (January 2020)

With all new Intl APIs implemented (behind the flag), and the integration of Fluent into Firefox mainly completed, this cycle saw a new direction – Rust.

First, Jonathan Kew wrote a Rust hyphenation library mapped_hyph and replaced C library libhyphen used in Gecko with it.

Then I was able to replace our MozLocale API with unic-langid Rust crate backed one, and our LocaleService::NegotiateLanguages with fluent-langneg Rust crate.

That marks the starting point for what I expect to be a slow and steady migration of our Intl stack to Rust. My current task is to migrate Fluent API to Rust, which I hope to achieve in 73 or 74 cycle.

Notable changes [my work] [intl module]:


2019 was a great year for our Intl stack! JS Intl module was extended to cover new APIs, Fluent is available in the whole Firefox, we bumped from ~800 strings in Fluent to close to 4000, we were able to deprecate DTD as a localization format, and begin introducing Rust into Intl stack.

In 2020 we hope to complete the migration of Firefox to Fluent, make Firefox easier to use in multilingual environments, move more of our module to Rust and enable new JS Intl features as their standardization process comes to conclusion.

Let’s go!

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.