Currently, our installer has to be built into a single language for its UI and it downloads a single corresponding version of Firefox locale. We recently (bug 1358824) made progress in enabling ourselves to build Firefox with multiple languages packaged into it. We now also have an improved langpack ecosystem which gets us closer to being able to reliably install a new language into already installed Firefox. The next step is to enable our installer to be built with multiple languages. That means that we would separate a list of locales the installer is packaged with, from the list of locales Firefox is packaged with. At runtime, such an installer would look through the packaged locale resources and match the best one based on the operating system UI locale. Eventually, we may be able to make the installer download a matching Firefox locale to the OS locale.

Keep in mind here that we have two different things called "installers", a full installer and a stub installer, and we can treat them differently if it helps us to do so. The full installer packages a specific build of Firefox, so ideally it should include whatever set of locales is available in that build; anything else would seem confusing and off-putting to a user. The stub installer is pretty separate from any Firefox build though, so it could contain a different, larger or smaller set of locales. We already take advantage of this property with architecture; we have separate full installers for 32-bit and 64-bit builds because the build itself can only be one or the other, but the stub can install either one and it automatically selects which one is appropriate.

I should note, that whatever solution is picked should have releng input as to implementation and timing. Firefox/Devedition Desktop is built on release trees on every checkin, and l10n for those happens only after Release management sends a "go", and it greatly reduces our end to end times for these desktop platforms. Android however, for multi-locale does its build as a completely separate build ontop of CI. So we'll want releng involved in the planning to help identify if there are, or what, blocked on release automation.