In order to complete the fallbacking scheme, we should de-hardcode en-US as the defaultLocale, and make sure that the default locale is one of the available locales. So, when a user builds Firefox with "de", "de" should be the default locale, which also serves as "last resort" locale. When user builds Firefox (Android) with multiple locales, we should probably ask for a default locale explicitly as a build command. Once we have it, we will use it for language negotiation to get the appLocales.

I think the defaultLocale should be the locale in which the program was originally written, assuming that it worked at least in that locale. In our code base, that's en-US, so I don't think we should change that.

After talking with Axel, we agreed to make it a static attribute for now. It'll help me as I clean up through the ChromeRegistry and nsILocaleService callers to migrate them away from manually typing things like: try { locale = getLocale(); } catch (e) { locale = "en-US"; }

(In reply to Axel Hecht [:Pike] from comment #1) > I think the defaultLocale should be the locale in which the program was > originally written, assuming that it worked at least in that locale. > > In our code base, that's en-US, so I don't think we should change that. I wonder about this. If we ship a single-locale "de-DE" build, for example, does it really make sense for it to report en-US as default locale?

> I wonder about this. If we ship a single-locale "de-DE" build, for example, does it really make sense for it to report en-US as default locale? Yeah, that was my assumption as well. Axel said that the build system should not allow to build Firefox without en-US. I can imagine that in the future we could have something like: ``` ./mach build --locales de,fr,it --default-locale=de ``` and if you did: ``` ./mach build --locales de,fr,it --default-locale=ar ``` that would be a build time error (and then runtime, once we fix bug 1345957 and language negotiation will refuse to negotiate if default is not in available). For now, I'd just like to collect the references so that we can have a choice like that later on.

(In reply to Zibi Braniecki [:gandalf][:zibi] from comment #8) > > I wonder about this. If we ship a single-locale "de-DE" build, for example, does it really make sense for it to report en-US as default locale? > > Yeah, that was my assumption as well. Axel said that the build system should > not allow to build Firefox without en-US. That's not the case at present, though (is it?) If I download the German version of Firefox from https://www.mozilla.org/en-US/firefox/all/, it looks like the only locale present is "de". So ISTM that for now, the correct thing for defaultLocale to return in such a build is "de". Maybe we're going to change that, and have en-US always available, but until we do, it seems wrong to return it here. > and if you did: > ``` > ./mach build --locales de,fr,it --default-locale=ar > ``` Or the default-locale would automatically be included in the locales, even if not explicitly mentioned there.

Also, I wonder about the terminology here; I'm finding it quite misleading. Should we be calling this "fallbackLocale" or something, rather than "defaultLocale"? The natural interpretation of "defaultLocale", ISTM, is that it'd be the locale that code should use by default (unless explicitly told otherwise) -- which should mean the user's preferred locale, determined from their accept-languages or their chosen browser localization or their OS locale setting or whatever, but a hard-coded "en-US" can't possibly be the right answer to this. It's plausible that we may want en-US to be a universal last-resort fallback, but it's not the universal default.

> That's not the case at present, though (is it?) If I download the German version of Firefox from https://www.mozilla.org/en-US/firefox/all/, it looks like the only locale present is "de". Hmm, I thought that when we build "de" Firefox we bundle "de" and "en-US" locales. Do you know how can I retrieve this bit? It seems like at least ChromeRegistry doesn't know what locale was the "default" - it just registers packages. > So ISTM that for now, the correct thing for defaultLocale to return in such a build is "de". I'm wondering how it works then when so much code just fall back on "en-US"... > Maybe we're going to change that, and have en-US always available, but until we do, it seems wrong to return it here. I'm happy to return whatever is the "last resort" locale, and according to what you're saying we should be the locale Firefox was built with. :Pike, are you ok with that? :jfkthame - can you help me find a place where I can retrieve the bit to put it in LocaleService?

> Also, I wonder about the terminology here; I'm finding it quite misleading. Should we be calling this "fallbackLocale" or something, rather than "defaultLocale"? I just followed https://tools.ietf.org/html/bcp47#section-3.4.1 > It's plausible that we may want en-US to be a universal last-resort fallback, but it's not the universal default. Not sure what's the difference in your opinion. My idea behind this is that this is the locale we want to fallback on when nothing matches. That should be the locale that is bundled into Firefox package. So when user asks for one set of locales, and none of them is available, or some other error happens with langpacks, the last language in the supported locales chain is this. The reason why I think 'default' works here is that it is the locale we'll use if user won't specify any other and it is the locale that we ship with the product. It also happens to be "last fallback" so I can see how it may be alternative name for it - my reason is just to stick to BCP47.

Default locale is also used in the same way in LDML - http://unicode.org/reports/tr35/tr35.html#LanguageMatching

The status quo is that we bundle requested locale and default locale into a single bundle. The intent of this patch queue is to break this up for all things but the chrome registry, and then slowly get away from the status quo. The nomenclature is weird, but I agree that we should call our last-resort "defaultLocale". And within all things gecko, that's 'en-US'.

Comment on attachment 8847249 [details] Bug 1346611 - Introduce LocaleService::GetDefaultLocale. https://reviewboard.mozilla.org/r/120262/#review123380

Pushed by zbraniecki@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/b583679fedc4 Introduce LocaleService::GetDefaultLocale. r=jfkthame