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 –
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.
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.
- Bug 1518252 – Block layout on Fluent
- Bug 1509609 – Provide a sync version of generateBundles for L10nregistry
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.
Firefox 68 (July 2019)
This release may feel slightly busier than average.
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!
- Bug 1503657 – Implement Fluent DOMOverlays in C++
- Bug 1533481 – Update our in-tree ICU to 64 and update to Unicode 12
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
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.
- Bug 1558602 – Add an option to localize document synchronously
- Bug 1546432 – Migrate Fluent’s MutationObserver to C++
- Bug 1552714 – Extract DOMLocalization out of DocumentL10n, expose it via WebIDL and replace DOMLocalization.jsm with it.
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.DateTimeFormat, cleaned up SpiderMonkey Intl build system, unified our language tag parsing around Unicode Locale Identifier spec, and fixed several smaller bugs.
- Bug 1517880 – Implement fluent mini-cache
- Bug 1433303 – Implement Intl.Locale
- Bug 1566410 – Implement Intl.NumberFormat Unified API proposal
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.
- Bug 1433306 – Implement Intl.ListFormat
- Bug 1570370 – Move language tag parsing and Intl.Locale to C++
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.
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.
- Bug 1487212 – Can we share hyphenation data across processes?
- Bug 1571915 – Switch to `unic-langid` to back MozLocale
- Bug 1581960 – Use fluent-locale-rs for LocaleService::NegotiateLanguages
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.