Description of problem:
while run firefox in localized desktop, then following locales have en_US content, while translation is
en_US Page for Following langauges:
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. login to respective language
2. run firefox
3. check default index.html page
default page: /usr/share/doc/HTML/en-US/index.html
it is should be respective localized page (/usr/share/doc/HTML/<LANG>/index.html
Detailed Test Run: https://tcms.engineering.redhat.com/runs/?a=search&search=Firefox%20index.html
(In reply to comment #0)
> Description of problem:
> while run firefox in localized desktop, then following locales have en_US
> content, while translation is
> en_US Page for Following langauges:
> as_IN (/usr/share/doc/HTML/as-IN/index.html)
> bn_IN (/usr/share/doc/HTML/bn-IN/index.html)
> hi_IN (/usr/share/doc/HTML/hi-IN/index.html)
> kn_IN (/usr/share/doc/HTML/kn-IN/index.html)
> mr_IN (/usr/share/doc/HTML/mr-IN/index.html)
> te_IN (/usr/share/doc/HTML/te-IN/index.html)
> ta_IN (/usr/share/doc/HTML/ta-IN/index.html)
For these languages, they have set general.useragent.locale=en-US in their translations for file toolkit/chrome/global/intl.properties because of which the script (basically "var lang = window.navigator.language") from index.html is always getting en-US.
To me I think, this problem could be fixed two ways.
1. Either grab the language from the LANG variable (if possible)
2. Get all these languages' localization fixed upstream and then downstream.
I guess this level of research would be helpful to move this bug forward.
Hindi for reference: http://hg.mozilla.org/releases/l10n-mozilla-1.9.2/hi-IN/file/fb95f601904e/toolkit/chrome/global/intl.properties#l8
Just for the sake of avoiding this issue for thunderbird, translators also would want to fix general.useragent.locale=en-US in mail/chrome/navigator/navigator.properties file.
general.useragent.locale, IIRC, is set from the environment unless the chrome hardcodes it. So this would be fixed in FF/xulrunner.
What about the entries for the following:
Do these need appropriate entries for Indic languages?
(In reply to comment #6)
> What about the entries for the following:
> Do these need appropriate entries for Indic languages?
Yes, please correct them as well. however, not all of them affect this bug.
Btw, from the logs of mozilla l10n hg repository, following languages are going to be fixed in the next minor release of Firefox:
1. Marathi (mr) : http://hg.mozilla.org/releases/l10n-mozilla-1.9.2/mr/
(ffxbld - Added tag FIREFOX_3_6_9_RELEASE for changeset 59d40d917016. CLOSED TREE)
2. Telugu (te) : http://hg.mozilla.org/releases/l10n-mozilla-1.9.2/te/
(ffxbld - Added tag FIREFOX_3_6_9_RELEASE for changeset 6c7447a0dd09. CLOSED TREE)
3. Kannada (kn) : http://hg.mozilla.org/releases/l10n-mozilla-1.9.2/kn/
(ffxbld - Added tag FIREFOX_3_6_9_RELEASE for changeset 91fd21203bef. CLOSED TREE)
The languages that are corrected and submitted but will not be available in the next release of Firefox (3.6.9) are hi-IN, bn-IN and ta due to miss in the 'sing-off' part. as-IN will not be fixed as well, because of no resource.
Thanks for that update, Ankit
So hi-IN, bn-IN might land in 3.6.10? :)
(In reply to comment #9)
> Thanks for that update, Ankit
> So hi-IN, bn-IN might land in 3.6.10? :)
Yes, there is some account activation issue for hi-IN, bn-IN and ta with upstream, as soon as it's fixed the upstream fix will land. hopefully by 3.6.10.
Okay, I can see hi-IN, bn-IN and ta also signed-off and approved for 3.6.10, so they will land in 3.6.10.
Assamese (as) will still remain, as we don't have in-house resource who can fix the issue upstream.
Reassigning bug back to the Firefox Package Maintainers, requesting them to included Firefox 3.6.10 from upstream to RHEL6 downstream to get this issue fixed.
status with build: firefox-3.6.11-1.el6.x86_64
as_IN - Not working
bn_IN - Not working
te_IN - Not Working
hi_IN - FIXED
kn_IN - FIXED
mr_IN - FIXED
ta_IN - FIXED
(In reply to comment #13)
> status with build: firefox-3.6.11-1.el6.x86_64
> Not FIXED:
> as_IN - Not working
> bn_IN - Not working
> te_IN - Not Working
> hi_IN - FIXED
> kn_IN - FIXED
> mr_IN - FIXED
> ta_IN - FIXED
as-IN : is not fixed in upstream as well because of no resource.
bn-IN and te-IN : is fixed (so redirection is happening correctly according to the language, but the translations of redhat-indexhtml itself is not completed on time, due to resources were on vacation during that task).
So, I would like to request you to file new bug for updating translations of redhat-indexhtml for bn-IN and te-IN.
as-IN, we are yet to hire a new resource, so it will be unresolved at this stage.
*** Bug 644251 has been marked as a duplicate of this bug. ***