I can confirm this bug with the nightly of 5/29. The language will stay at en-US, no matter what is set as the preferred language. As a german is set this to de-de, de, en-us, en.
Same here - Firefox 1.0.3 on Mac OS X sends en-US regardless of its language settings or the system language. See also: bug 299522 (navigator.language property form doesn't follow the documentation)
Same here on 2.0b1. When Firefox talks to a real webserver, it correctly send the language as this header, making it work correctly on these situations: Accept-Language: pt-br,en-us;q=0.5 Note that "pt-br" is my default primary language. But if a page accesses navigator.language I only get "en" or "en-us". Without this, its impossible to make client-side JS/Ajax page internationalization. On IE, navigator.language or navigator.userLanguage return the language that was set in the browser configurations. More people are reporting the same problem here: http://www.codingforums.com/archive/index.php?t-45565.html In my opinion, this a blocking-firefox2 bug. Hope it will be corrected before 2.0 final release.
This works for me using Firefox 188.8.131.52 on Mac OS X 10.4.9 (Intel). Note that you have to set general.useragent.locale for it to work. That's what navigator.language is calling. If there's something I'm missing here, please reopen this bug.
firefox should use the value from the currently used locale. We verified that it only works with pre-localized builds, but using locale .xpi package it neither works when passing -UILocale/-contentLocale nor when using the matchOS preference (which should detect locale from system settings). Tweaking the general.useragent.locale setting is not feasible and most likely not the intended behaviour. Reopening.
confirming bug on linux using official builds.
changing firefox-l10n.js to pref("general.useragent.locale", "chrome://global/locale/intl.properties"); solved this issue for me. globle/intl.properties in each language jar file contains right value for general.useragent.locale. Is it the right solution?
Created attachment 314847 [details] [diff] [review] Patch for browser/locales/Makefile.in, browser/locales/en-US/firefox-l10n.js, config/config.mk The attachment is an idea. # make DEF_LOCALE=chrome://global/locale/intl.properties
Comment on attachment 314847 [details] [diff] [review] Patch for browser/locales/Makefile.in, browser/locales/en-US/firefox-l10n.js, config/config.mk Axel, could you please check the patch?
Comment on attachment 314847 [details] [diff] [review] Patch for browser/locales/Makefile.in, browser/locales/en-US/firefox-l10n.js, config/config.mk r-, I don't see anything that this patch does. This should likely go into app startup or network. The DOM gets the locale from the http protocol handler. I'm not sure why that wouldn't return the right value at least in the langpack case, though. I'd like to get that confirmed. I'm not sure if there's anything good to do in the matchOS case, other than to actually "fix" that code. No idea what it'd take to do so.
Created attachment 329808 [details] [diff] [review] patch This is the right patch we used in OpenSolaris. chrome://global/locale/intl.properties is in every langpack. The document of "navigator.language" defined as "Returns a string representing the language version of the browser." So I think it's the right thing to do. Also, it is already widely used in our source. http://lxr.mozilla.org/seamonkey/search?string=intl.properties
Comment on attachment 329808 [details] [diff] [review] patch no, this is not the right fix. Now you're in a closed loop, the pref sets the locale, but tries to get it from a localized file.
(In reply to comment #12) > (From update of attachment 329808 [details] [diff] [review]) > no, this is not the right fix. > > Now you're in a closed loop, the pref sets the locale, but tries to get it from > a localized file. Cool! I've just wanted to attach this patch :)
(In reply to comment #12) > (From update of attachment 329808 [details] [diff] [review]) > no, this is not the right fix. > > Now you're in a closed loop, the pref sets the locale, but tries to get it from > a localized file. > chrome://global/locale/intl.properties is from something like toolkit/locales/en-US/chrome/global/intl.properties so it's not a closed loop.
Comment on attachment 329808 [details] [diff] [review] patch You apparently haven't bothered to try this on a localized build as shipped by Mozilla. Breaking our builds is not an option.
1) This bug doesn't exist in Mozilla localized build, since the value of "general.useragent.locale"" is hardcoded in these files, http://lxr.mozilla.org/l10n/find?string=firefox-l10n.js 2) In my patch, I only changed for en-US, actually this patch should be applied to every language. Or this line should be changed to a better place. 3) You apparently haven't bothered to try my patch at all.
And yes, I didn't test the patch at all, because I *know* that it won't work. It probably does the right thing for en-US, as that's the locale the chrome registry falls back to when the pref ain't set, but all other locales will just break. As the line you're wripping apart is the one and only line in the whole product that actually tells the chrome registry to use something other than en-US-
You can check these files http://lxr.mozilla.org/l10n/find?string=intl.properties to see which language misses a line like general.useragent.locale=fr The patch works for en-US, and other locales. It's not a fallback. I tested with Mozilla localized build on MacOS X. That's why I *know* it works.
Now I understand why you think it won't work. general.useragent.locale is used to decide which langpack to be used if you don't have intl.locale.matchOS = true or specified UILocale. This design is not supposed to work with multiple langpack.
This seems like an old bug, is there a resolution or work-around? How do we make Firefox report something other than en-US for the default build of Firefox?
(In reply to comment #21) > This seems like an old bug, is there a resolution or work-around? How do we > make Firefox report something other than en-US for the default build of > Firefox? The default build of Firefox only has en-US locale UI, what do you expect it return other than en-US?
It's not the definition of navigator.language. Maybe the discussion here is useful to you. http://groups.google.com/group/mozilla-labs-jetpack/browse_thread/thread/8459ccb6a7246656/df01c3b4e32850cb?#df01c3b4e32850cb
(In reply to comment #24) > It's not the definition of navigator.language. > > Maybe the discussion here is useful to you. > http://groups.google.com/group/mozilla-labs-jetpack/browse_thread/thread/ > 8459ccb6a7246656/df01c3b4e32850cb?#df01c3b4e32850cb Despite these concerns, it appears that that exact change landed in bug 55366 (Firefox 5). navigator.language is now set to the first language in Accept-Header.
(In reply to comment #25) > navigator.language is now set to the first language in Accept-Header. Let me try that again: navigator.language is now set to the first language in the Accept-Language header.
ok, so this bug should be closed, either won't fix or dupe of Bug 55366.