Last Comment Bug 285267 - navigator.language js property doesn't reflect browser default language
: navigator.language js property doesn't reflect browser default language
Status: RESOLVED WONTFIX
:
Product: Firefox
Classification: Client Software
Component: General (show other bugs)
: unspecified
: All All
: -- normal with 3 votes (vote)
: ---
Assigned To: Ginn Chen
:
Mentors:
: 574759 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-03-08 04:54 PST by Simone Chiaretta
Modified: 2011-07-13 04:26 PDT (History)
13 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Patch for browser/locales/Makefile.in, browser/locales/en-US/firefox-l10n.js, config/config.mk (1.85 KB, patch)
2008-04-10 07:17 PDT, Takao Fujiwara
l10n: review-
Details | Diff | Splinter Review
patch (594 bytes, patch)
2008-07-16 04:00 PDT, Ginn Chen
l10n: review-
Details | Diff | Splinter Review

Description Simone Chiaretta 2005-03-08 04:54:45 PST
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050223 Firefox/1.0.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050223 Firefox/1.0.1

I've set Italian as default language, but when I try to read the default
language using javascript (navigator.language) I still get en-US which is the
locale of the browser.
It used to work before FF 1.0

Reproducible: Always

Steps to Reproduce:
1.Set your default language to something different than the locale
2a. access navigator.language javascript property
2b. or access http://gemal.dk/browserspy/language.html

Actual Results:  
you get your locale

Expected Results:  
you should get the default language
Comment 1 Mugros 2005-05-31 09:42:48 PDT
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.
Comment 2 Alexey Proskuryakov 2005-07-03 02:49:36 PDT
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)
Comment 3 Avi Alkalay 2006-08-15 06:14:22 PDT
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.
Comment 4 Samuel Sidler (old account; do not CC) 2007-04-08 13:11:29 PDT
This works for me using Firefox 2.0.0.3 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.
Comment 5 Alexander Sack 2007-06-13 04:17:25 PDT
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.
Comment 6 Alexander Sack 2007-06-13 04:18:20 PDT
confirming bug on linux using official builds.
Comment 7 Ginn Chen 2008-04-10 04:20:32 PDT
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?
Comment 8 Takao Fujiwara 2008-04-10 07:17:50 PDT
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 9 Martin Stránský 2008-07-14 14:00:51 PDT
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 10 Axel Hecht [:Pike] 2008-07-14 14:33:42 PDT
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.
Comment 11 Ginn Chen 2008-07-16 04:00:22 PDT
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 12 Axel Hecht [:Pike] 2008-07-16 04:08:02 PDT
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.
Comment 13 Martin Stránský 2008-07-16 04:14:17 PDT
(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 :)

Comment 14 Ginn Chen 2008-07-16 04:24:42 PDT
(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 15 Axel Hecht [:Pike] 2008-07-16 04:31:17 PDT
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.
Comment 16 Ginn Chen 2008-07-16 04:53:59 PDT
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.
Comment 17 Axel Hecht [:Pike] 2008-07-16 04:56:43 PDT
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-
Comment 18 Ginn Chen 2008-07-16 05:14:18 PDT
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.
Comment 19 Ginn Chen 2008-07-16 23:48:12 PDT
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.
Comment 20 Jo Hermans 2010-06-25 13:10:51 PDT
*** Bug 574759 has been marked as a duplicate of this bug. ***
Comment 21 Mark Richards 2010-07-16 08:32:41 PDT
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?
Comment 22 Ginn Chen 2010-07-16 21:08:39 PDT
(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?
Comment 23 Mark Richards 2010-07-19 04:59:03 PDT
I would like it to return the same value as the first language in the Accept-Language header.  This way it's possible to do client-side language detection in Javascript.  Is this completely off-base? Is there a better solution that doesn't rely on the server?
Comment 24 Ginn Chen 2010-07-19 11:30:07 PDT
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
Comment 25 Gordon P. Hemsley [:GPHemsley] 2011-07-12 10:59:29 PDT
(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.
Comment 26 Gordon P. Hemsley [:GPHemsley] 2011-07-12 11:00:16 PDT
(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.
Comment 27 Ginn Chen 2011-07-13 04:26:33 PDT
ok, so this bug should be closed, either won't fix or dupe of Bug 55366.

Note You need to log in before you can comment on or make changes to this bug.