Closed Bug 163271 Opened 20 years ago Closed 11 months ago

intl.accept_language is set to a strange value when it's absent in prefs.js


(Core :: Internationalization, defect)

Not set





(Reporter: jshin1987, Assigned: smontagu)


When intl.accept_language is not present in prefs.js
in $HOME/mozilla/$profile/....../prefs.js,
nsPref:GetCharPref() (or nsPrefBranch:GetCharPref() ) returns
'chrome://navigator/locale/' instead
of the actual value stored in
which is 'en-US,en'. 

I found this trying to debug mozilla for bug 122779.
In nsDocument.cpp:StartDocumentLoad(), GetCharPref()
is called to get the value of 'intl.accept_languages'
and it returns with 'chrmoe://navigator/locale/'
instead of 'en-US, en' stored in file. 

However, preference - navigator - languages shows 'en-US, en' correctly.
Reporter can you reproduce this bug with a newer build (1.4 final)?
If not, then please close this bug as worksforme. Thanks.
It seems the default value of "intl.accept_languages" overwritten
by language pack is ignored.

(1) Create a new profile.
(2) Install Japanese Language Pack, which overwrites "intl.accept_languages"
 to "ja, en-us, en". (
(3) Change Language/Content Pack.
(4) Access to <> via <>.

Actual result: "Accept-Language: en-us,en"

Expected result: "Accept-Language: ja,en-us,en"

Build: 1.5final/Linux
Ever confirmed: true
Mass reassign of my non-Firefox bugs to
Assignee: bugs → ben_seamonkey
Product: Browser → Seamonkey
I'm able to verify exactly this bug with Firefox and with SeaMonkey 1.0 on Linux and on Windows.

If I try to fetch the value of intl.accept_language using something like this:


then I'll get a message "chrome://global/locale/" and not "en-us, en" as expected.

If you ask me then the whole concept of localized preferences is bad. It's just abuse of a string preference.

If you really want localized properties that way, then please update navigator.preference and prefBranch.getCharPref, too to avoid hacks when using the preferences system...

BTW: May someone please change "Product" to "Core"?
-> core/intl, but that GetCharPref doesn't treat prefs as localized prefs doesn't sound like a bug to me.
Assignee: ben_seamonkey → smontagu
Component: Preferences → Internationalization
Product: Mozilla Application Suite → Core
QA Contact: bugzilla → amyy
But I think a fix in any form is needed to have an easy way to "just read the preference".
QA Contact: amyy → i18n

This is fixed by now. Reopen if needed.

Closed: 11 months ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.