We shouldn't hardcode the list of available locales in settings/index.html. This list could be: - built dynamically on runtime, - filtered dynamically on runtime, - built on build time via some Makefile/mozharness magic.

Kaze, any thoughts on this? I'd like to start the discussion about localized builds with releng and I feel that this is blocking us slightly.

We'll need this to properly build localized B2G, both for testing and production. Requesting blocking-basecamp. We want to be able to configure which locales are enabled in any given build (single- or multilocale) on the releng side via an all-locales file and buildbot configs. This ensures scalability for v1 and later and will allow us to build localized testing builds.

We can manage this with hardcoding for V1

Now that bug 805781 changed the location of languages.json to shared/resource, it would be great to use it to dynamically construct the list of available locales from it. It will make it significantly easier to do multilocale repacks. See bug 766962 and its dependencies.

I agree with Staś, it’s a trivial fix and it would be much easier to handle the localization.

(In reply to dscravaglieri from comment #3) > We can manage this with hardcoding for V1 I don't agree with this statement. I believe that we should abstract our build system from the code. Having a single central location to configure available locales is the way to go. It will allow us to meet future requirements for shipped locales with no effort on the infrastructure side. Re-nominating.

(In reply to Staś Małolepszy :stas from comment #6) > (In reply to dscravaglieri from comment #3) > > We can manage this with hardcoding for V1 > > I don't agree with this statement. I believe that we should abstract our > build system from the code. Having a single central location to configure > available locales is the way to go. It will allow us to meet future > requirements for shipped locales with no effort on the infrastructure side. > Re-nominating. 100% agree. We require at least two different l10n builds (dev ones, with 6 or so languages and localizer ones with 50+) so this isn't even a theoretical need.

Comment on attachment 684523 [details] patch proposal r=me, thanks!