+++ This bug was initially created as a clone of Bug #1431260 +++ Currently, we use Chrome Registry's `global` locale package to identify available locales . As we move away from Chrome Registry we also want to move away from using it as a reference location for available locales data. The new source of truth is L10nRegistry and its data is a combination of multilocale.json registered locales (package) and language packs. One of the benefits of this move is that we can vastly reduce the number of language negotiation states we go through during the bootstrap. At the moment we hit at least 5: 1) no locales available, defaultLocale requested 2) PreferencesService reads default prefs.js, new requested locales 3) ChromeRegistry registers packages, new available locales 4) prefs.js reads user's profile prefs.js, new requested locales 5) Extensions are registered, new available locales But in reality the number of states is much higher, since *each* time we read a new locale, ChromeRegistry registers it, triggers `available-locales-changed` and language negotiation. I'd like to vastly simplify it. The PreferencesService rewrite should handle the (2)+(4) state, and I believe that multilocale.json can handle the (1)+(3) state, leaving us with: 1) LocaleService reads multilocale.json - available locales ready 2) PreferencesService reads default prefs.js, requested locales ready 3) Extensions are registered, new available locales  https://searchfox.org/mozilla-central/rev/1f9b4f0f0653b129b4db1b9fc5e9068054afaac0/intl/locale/LocaleService.cpp#119  https://searchfox.org/mozilla-central/rev/1f9b4f0f0653b129b4db1b9fc5e9068054afaac0/browser/components/nsBrowserGlue.js#675  https://searchfox.org/mozilla-central/source/toolkit/components/extensions/Extension.jsm#1834
See Bug 1440235
You need to log in before you can comment on or make changes to this bug.