Bug 445304

This is a regression relative to 5.0 at least.

adding mhideo and jfearn to this bug, as i am not sure how
to address this (packaging issue?)

This is also a regression against 5.1.

Jeff and I looked at this with firebug and window.navigator.language
returns "en-US" always, it seems?

I meant to add:

So has the handling of window.navigator.language
in Firefox 3 changed or moved to another javascript variable?

window.navigator.language is derived from user agent string and this string is
set during build. The proper variable is "intl.accept_languages" (it's a list of
preferred languages, the first one should be the current locale)

Thanks, moving back to redhat-release-notes then.

(In reply to comment #5)
> window.navigator.language is derived from user agent string and this string is
> set during build.

Nevertheless this is a change of behaviour from Firefox 1.5 and 2.0.

Anyway going by comment 5, I guess something like:

 var lang = intl.accept_languages.split(',')[0];

should do the right thing.

(In reply to comment #5)
> window.navigator.language is derived from user agent string and this string is
> set during build.

There is an upstream bug open for this: since we only ship one firefox build for
all langs this seems unacceptable, and it used to be different for firefox2.

> The proper variable is "intl.accept_languages" (it's a list of
> preferred languages, the first one should be the current locale)

I don't know how to access that from client side javascript.

Changing the behavior of window.navigator.language is going to break every
existing locale checking script in use today; they all use
window.navigator.language to determine the current language.

This will make Firefox work differently than Konqueror and thus require browser
checking logic to be added. The latest Konqueror works as expected.

I have found no way to access intl.* variables from within client side javascript.

This bugzilla has Keywords: Regression.  

Since no regressions are allowed between releases, 
it is also being proposed as a blocker for this release.  

Please resolve ASAP.

Created attachment 311775 [details]
proposed patch

This patch to firefox-redhat-default-prefs.js seems to fix the problem (based
on https://bugzilla.mozilla.org/show_bug.cgi?id=285267#c7)

Actually we used to manage it by this code for 1.5. But it has been removed
during rebase to 3.0.

%{__cat} > $RPM_BUILD_ROOT/%{mozappdir}/defaults/preferences/firefox-l10n.js << EOF
pref("general.useragent.locale", "chrome://global/locale/intl.properties");
EOF
%{__chmod} 644 $RPM_BUILD_ROOT/%{mozappdir}/defaults/preferences/firefox-l10n.js

*** Bug 456815 has been marked as a duplicate of this bug. ***

ON rhel5.3 20090106.0
can reproduce this problem under following locales :as_IN,bn_IN,kn_IN,ml_IN,mr_IN,or_IN,ta_IN,te_IN.
(window.navigator.language=en-US)

under other locales :pt_BR,de_DE,es_ES,fr_FR,ru_RU,ko_KR,
ja_JP,zh_CN,zh_TW,gu_IN,hi_IN,pa_IN,si_LK
HTML/index.html redirect to the right index page

Moving to ASSIGNED based on Comment #19.

This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.

(In reply to comment #19)
> ON rhel5.3 20090106.0
> can reproduce this problem under following locales
> :as_IN,bn_IN,kn_IN,ml_IN,mr_IN,or_IN,ta_IN,te_IN.
> (window.navigator.language=en-US)
> 
> under other locales :pt_BR,de_DE,es_ES,fr_FR,ru_RU,ko_KR,
> ja_JP,zh_CN,zh_TW,gu_IN,hi_IN,pa_IN,si_LK
> HTML/index.html redirect to the right index page

Please open a new bug report about missing start page translations. This one is about broken firefox (which is fixed already) but you need to report missing HTML pages from redhat-release-notes package.