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

Categories

(Core :: Internationalization, defect)

x86
Linux
defect
Not set
normal

Tracking

()

RESOLVED INVALID

People

(Reporter: jshin1987, Assigned: smontagu)

Details

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/navigator.properties' instead
of the actual value stored in navigator.properties
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/navigator.properties'
instead of 'en-US, en' stored in navigator.properties 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". (http://plaza25.mbn.or.jp/~snip/)
(3) Change Language/Content Pack.
(4) Access to <http://www.google.com/> via <http://web-sniffer.net/>.

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

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

Build: 1.5final/Linux
Status: UNCONFIRMED → NEW
Ever confirmed: true
Mass reassign of my non-Firefox bugs to ben_seamonkey@hotmail.com
Assignee: bugs → ben_seamonkey
Product: Browser → Seamonkey
I'm able to verify exactly this bug with Firefox 1.5.0.1 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:

alert(navigator.preference("intl.accept_language"));

then I'll get a message "chrome://global/locale/intl.properties" 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.

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