The default bug view has changed. See this FAQ.

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

RESOLVED WONTFIX

Status

()

Firefox
General
RESOLVED WONTFIX
12 years ago
6 years ago

People

(Reporter: Simone Chiaretta, Assigned: Ginn Chen)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

12 years ago
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
(Reporter)

Updated

12 years ago
Summary: doesn't reflect the default language → navigator.language js property doesn't reflect browser default language
(Reporter)

Updated

12 years ago
Severity: normal → major
(Reporter)

Updated

12 years ago
OS: Windows XP → All
Hardware: PC → All

Comment 1

12 years ago
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

12 years ago
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

11 years ago
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.
Assignee: bross2 → nobody
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.
Severity: major → normal
Status: UNCONFIRMED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → WORKSFORME

Comment 5

10 years ago
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.
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---

Comment 6

10 years ago
confirming bug on linux using official builds.
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Assignee)

Comment 7

9 years ago
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

9 years ago
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

9 years ago
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?
Attachment #314847 - Flags: review?(axel)

Comment 10

9 years ago
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.
Attachment #314847 - Flags: review?(axel) → review-
(Assignee)

Comment 11

9 years ago
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
Assignee: nobody → ginn.chen
Attachment #314847 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #329808 - Flags: review?(axel)

Comment 12

9 years ago
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.
Attachment #329808 - Flags: review?(axel) → review-

Comment 13

9 years ago
(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 :)

(Assignee)

Comment 14

9 years ago
(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.

(Assignee)

Updated

9 years ago
Attachment #329808 - Flags: review- → review?(l10n)

Comment 15

9 years ago
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.
Attachment #329808 - Flags: review?(l10n) → review-
(Assignee)

Comment 16

9 years ago
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

9 years ago
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-
(Assignee)

Comment 18

9 years ago
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.
(Assignee)

Comment 19

9 years ago
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.

Updated

7 years ago
Duplicate of this bug: 574759

Comment 21

7 years ago
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?
(Assignee)

Comment 22

7 years ago
(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

7 years ago
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?
(Assignee)

Comment 24

7 years ago
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.
(Assignee)

Comment 27

6 years ago
ok, so this bug should be closed, either won't fix or dupe of Bug 55366.
Status: ASSIGNED → RESOLVED
Last Resolved: 10 years ago6 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.