285267 - navigator.language js property doesn't reflect browser default language

Status: RESOLVED WONTFIX

(Firefox :: General, defect)

Description

[Simone Chiaretta]

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]

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]

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]

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)]

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]

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]

confirming bug on linux using official builds.

Comment 7

[Ginn Chen]

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]

Attachment: 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ý [:stransky] (ni? me)]

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]]

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]

Attachment: 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]]

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ý [:stransky] (ni? me)]

(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]

(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]]

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]

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]]

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]

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]

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 21

[Mark Richards]

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]

(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]

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]

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]]

(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]]

(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]

ok, so this bug should be closed, either won't fix or dupe of Bug 55366.