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

Status: RESOLVED INVALID

(Core :: Internationalization, defect)

Description

[Jungshik Shin]

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.

Comment 1

[Alexander Opitz]

Reporter can you reproduce this bug with a newer build (1.4 final)?
If not, then please close this bug as worksforme. Thanks.

Comment 2

[Koike Kazuhiko]

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

Comment 3

[Ben Goodger (use ben at mozilla dot org for email)]

Mass reassign of my non-Firefox bugs to [e-mail]

Comment 4

[Manuel Reimer]

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"?

Comment 5

[Christian :Biesinger (don't email me, ping me on IRC)]

-> core/intl, but that GetCharPref doesn't treat prefs as localized prefs doesn't sound like a bug to me.

Comment 6

[Manuel Reimer]

But I think a fix in any form is needed to have an easy way to "just read the preference".

Comment 7

[Zibi Braniecki [:zbraniecki][:gandalf]]

This is fixed by now. Reopen if needed.