Hi Firefox devs! We just landed the final change that culminates the 3 month long major refactor of how Gecko handles language selection [0] (pending autoland->central).
We now have a single new API - mozilla::intl::LocaleService [1] (and mozILocaleService [2]) - which centralizes all operations related to things like asking for languages that the user requested, which language resources are available and which languages have been negotiated for the app to use. Also, all events related to those operations are now distributed from the new API. On top of that, we gained an additional helper API for retrieving Internationalization-related infromation from the operating system - mozilla::intl::OSPreferences [3] (and mozIOSPreferences [4]). Changes ======= We migrated all the code in mozilla-central to use the new code [5] for you, but if your work uses those areas, please make sure to take a look at those APIs and start using them in your code. In particular, please use `LocaleService::getAppLocalesAs(BCP47|LangTags)` for all code that wants to follow the current UI language, and use LocaleService's `getRequestedLocales` and `setRequestedLocales` instead of manipulating `general.useragent.locale` pref directly [6]. JS Context and mozIntl APIs now use the current browser UI language selection instead of OS locales. That change also marks the beginning of deprecation of the nsILocaleService, nsLocaleSerivice, nsLocale and related APIs [7]. Lastly, we've moved away from ChromeRegistry as the central place for negotiating language selection for the product (LocaleService takes over that role), which means that in almost all cases you should consult LocaleService, not ChromeRegistry. What's Next =========== This last step opens up the ability for us to introduce a new localization resources registry [8] which will slowly take over that role from ChromeRegistry. There are still a couple minor features we'll be adding to LocaleService over the next month [9], but generally, the API is complete and ready to handle centralized language management in Gecko. Beyond cleaning up 20+ year old code, unifying the behavior and enabling the new registry, those changes put us on a path to more flexible multi-lingual behavior aligned with the modern Web. >From here, we plan to make Gecko be able to: - decouple release of the product from the releases of language resources - handle localization of HTML/WebComponents/WebExtensions/XUL/XBL/JS using a single localization API - better align between language resources and Intl APIs (date/number formatting etc.) - deliver language resource updates on the fly - gain control over at what point in the UI loading we inject strings - change languages on fly - first step on the path to the end of .DTD and .properties - handle error scenarios better (death to the Yellow Screen of Death!) Team responsible for the refactor: :gandalf, :jfkthame, :pike, and :stas. Greetings, zb. [0] https://bugzilla.mozilla.org/show_bug.cgi?id=1347306 [1] http://searchfox.org/mozilla-central/source/intl/locale/LocaleService.h [2] http://searchfox.org/mozilla-central/source/intl/locale/mozILocaleService.idl [3] http://searchfox.org/mozilla-central/source/intl/locale/OSPreferences.h [4] http://searchfox.org/mozilla-central/source/intl/locale/mozIOSPreferences.idl [5] https://bugzilla.mozilla.org/show_bug.cgi?id=1334772 [6] https://bugzilla.mozilla.org/show_bug.cgi?id=1334772 [7] https://bugzilla.mozilla.org/show_bug.cgi?id=1350102 [8] https://bugzilla.mozilla.org/show_bug.cgi?id=1333980 [9] https://bugzilla.mozilla.org/show_bug.cgi?id=1346877 _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
