Gecko Locale Selection remodel completed (repost from dev.platform)

Zbigniew Braniecki (Gandalf) zbraniecki at mozilla.com
Tue Mar 28 15:58:57 UTC 2017


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/firefox-dev/attachments/20170328/f699190f/attachment.html>


More information about the firefox-dev mailing list