Summary: Gecko's localization framework has not really changed much in the last 20 years and is based on two data formats - DTD and .properties - neither have been designed for localization purposes. Our internationalization status is a combination of DIY helper functions, ICU based APIs and ancient code written for Netscape. The current situation results in high maintenance burden, lower translation quality and keeps us locked out from the ability to develop new localization related features.
Over last three years we created a modern localization and internationalization infrastructure that we deployed for Firefox OS and put on ECMA standardization path. Now we intent to integrate it into Gecko, and migrate Firefox to it. We're going to host a session about this project in London, on Friday at 13:15 - https://mozillalondonallhands2016.sched.org/event/79As/the-future-of-l10ni18n-in-firefox-and-gecko The two pillars are: 1) Localization For l10n we intend to base our API on L20n API designed by Axel Hecht, Stas Malolepszy and me and use the newly designed L20n syntax, which is based on ICU's Message Format. A single localization format will lower the technical burden and lower the complexity of our ecosystem. A new API will also result in cleaner and easier to maintain code base improving quality and security of our products. The new API will provide a resilient runtime fallback, loosening the ties between code and localizations. That will empower more experiments on shipping code and shipping localizations. 2) Internationalization For i18n we intend to leverage our current design plan for ECMA 402 (JS I18n spec) and deploy the spec proposals that originally came from FxOS requirements. This will allow us to unify our I18n architecture, reduce code redundancy and end up with Gecko's I18n being the same as JS I18n. The new infrastructure has been designed to work together - L20n ties perfectly into I18n formatters, while parts of L20n API and syntax may end up becoming Web Localization standards proposal. Our goals are to significantly improve our ability to create high quality multilingual user interfaces, simplify the l10n API for developers, improve error recovery and enable us to innovate. The first area of innovation that we're planning to build on top of the new infrastructure are "Live Updates" - a technology that will allow us to pull localization resources independently from code base updates enabling scenarios like partial translation releases where the localization is added within a couple days after the product is available. Bug: Meta bug is https://bugzilla.mozilla.org/show_bug.cgi?id=1279002 Current POC: https://github.com/zbraniecki/gecko-dev/tree/l20n Link to standards: Intl: *) https://tc39.github.io/ecma402/ *) https://github.com/tc39/ecma402#current-proposals - Intl.RelativeTimeFormat ( https://github.com/zbraniecki/intl-relative-time-spec ) - Intl.PluralRules ( https://github.com/tc39/proposal-intl-plural-rules ) - Intl.UnitFormat ( https://github.com/zbraniecki/proposal-intl-unit-format ) - Intl.ListFormat ( https://github.com/zbraniecki/proposal-intl-list-format ) L10n: *) http://l20n.org/ *) https://github.com/l20n/l20n.js *) (icu-design proposal) https://sourceforge.net/p/icu/mailman/message/35027629/ Platform coverage: Our initial plan is to migrate Firefox to the new architecture. In the future we'll look into enabling it for Web Extensions and other platform targets. As we progress with standardization of the I18n and L10n APIs through ECMA 402 we will expose those APIs to the public. Estimated or target release: At this point we do not have a clear visibility into which release we will target. We plan to enable the APIs gradually, starting with L20n JSM module and HTML/XUL bindings. We would like to start landing the first batch of patches over the next month. Do other browser engines implement this? Other vendors are working with us to standardize I18n APIs through TC39 working group. We plan to standardize most of the new formatters in 4th edition of ECMA 402 and we expect other vendors to implement it then. L10n API is less mature and we expect to work with ICU, W3C and TC39 to come up with pieces of API that we will be able to push for standardization. Please, share any feedback and come to our session in London! zb. _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
