Language variants don't work in Firefox because the language codes are separated with an underscore rather than a hyphen in chrome.manifest

Bug #632760 reported by André Gondim on 2010-09-07
80
This bug affects 16 people
Affects Status Importance Assigned to Milestone
Ubuntu Translations
High
Unassigned
language-pack-bn (Ubuntu)
High
Unassigned
language-pack-en (Ubuntu)
High
Unassigned
language-pack-es (Ubuntu)
High
Unassigned
language-pack-pt (Ubuntu)
High
Unassigned
language-pack-ta (Ubuntu)
High
Unassigned
language-pack-zh (Ubuntu)
High
Unassigned

Bug Description

Binary package hint: firefox

We have pt_BR pack to Firefox, but in Ubuntu 10.10 Maverick is using pt istead of pt_BR.

description: updated
André Gondim (andregondim) wrote :

I made a fresh Ubuntu 10.10 Maverick Meerkat Beta instalations. But in Firefox I have a pt translations istead of pt_BR. My locale can see below:

$ locale
LANG=pt_BR.utf8
LANGUAGE=pt_BR:pt:en
LC_CTYPE="pt_BR.utf8"
LC_NUMERIC="pt_BR.utf8"
LC_TIME="pt_BR.utf8"
LC_COLLATE="pt_BR.utf8"
LC_MONETARY="pt_BR.utf8"
LC_MESSAGES="pt_BR.utf8"
LC_PAPER="pt_BR.utf8"
LC_NAME="pt_BR.utf8"
LC_ADDRESS="pt_BR.utf8"
LC_TELEPHONE="pt_BR.utf8"
LC_MEASUREMENT="pt_BR.utf8"
LC_IDENTIFICATION="pt_BR.utf8"
LC_ALL=

David Planella (dpm) on 2010-09-08
Changed in ubuntu-translations:
status: New → Triaged
importance: Undecided → High
Chris Coulson (chrisccoulson) wrote :

I suspect that the issue is that the language code in the chrome.manifest for the language pack is incorrect (if it is pt_BR, then it needs to be pt-BR). The same issue also affects all of the english language pack variants too.

affects: firefox (Ubuntu) → language-pack-pt (Ubuntu)
Changed in language-pack-en (Ubuntu):
importance: Undecided → High
Changed in language-pack-pt (Ubuntu):
importance: Undecided → High
Changed in language-pack-en (Ubuntu):
status: New → Triaged
Changed in language-pack-pt (Ubuntu):
status: New → Triaged
Chris Coulson (chrisccoulson) wrote :

The upstream xpi's use a hyphen to separate the variants, so something in Launchpad mangles them

summary: - Wrong pack lang in pt_BR installation for Firefox
+ Language variants don't work because the language codes are separated
+ with an underscore rather than a hyphen in chrome.manifest
summary: - Language variants don't work because the language codes are separated
- with an underscore rather than a hyphen in chrome.manifest
+ Language variants don't work in Firefox because the language codes are
+ separated with an underscore rather than a hyphen in chrome.manifest
Chris Coulson (chrisccoulson) wrote :

I think we just need to do something like the attached patch in po2xpi. I wonder whether this has ever worked for these languages though?

Chris Coulson (chrisccoulson) wrote :

This is also what is breaking the localization of Google search results for en-GB users :)

tags: added: patch
Changed in language-pack-zh (Ubuntu):
importance: Undecided → High
status: New → Triaged
YunQiang Su (wzssyqa) wrote :

why it happens in every ubuntu release, and can be fixed at last time before release?

At least, it happened in karmic and lucid.

Ricardo Pérez López (ricardo) wrote :

I think the problem is present in es_ES, too. Using Firefox, when I type "www.google.com", it remains using ".com" domain. However, when using Google Chrome, when I type "www.google.com" it automatically changes to "www.google.es", which is the right way.

$ locale
LANG=es_ES.utf8
LC_CTYPE="es_ES.utf8"
LC_NUMERIC="es_ES.utf8"
LC_TIME="es_ES.utf8"
LC_COLLATE="es_ES.utf8"
LC_MONETARY="es_ES.utf8"
LC_MESSAGES="es_ES.utf8"
LC_PAPER="es_ES.utf8"
LC_NAME="es_ES.utf8"
LC_ADDRESS="es_ES.utf8"
LC_TELEPHONE="es_ES.utf8"
LC_MEASUREMENT="es_ES.utf8"
LC_IDENTIFICATION="es_ES.utf8"
LC_ALL=

Ricardo Pérez López (ricardo) wrote :

This is what I get when I type "www.google.com" in my Spanish-localized Firefox.

Ricardo Pérez López (ricardo) wrote :

Also, the "about:home" page shows in English instead of Spanish.

If I put "Español/España [es-es]" in Edit->Preferences->Content->Language, then all works OK as expected.

BTW, I can confirm the problem on both Lucid and Maverick.

Weird... Now I have 4 languages defined: es-es, es, en-us, en. They suddenly appeared replacing the previous "[chrome://global/locale/intl.properties]" value, and now all works OK. The only thing I did was to add "es-es" language by hand and then moved it below the "[chrome://...]" value. I can't see what happened.

André Gondim (andregondim) wrote :

Ricardo, your workaround doesn't works for pt-br.

cheers. ;)

Arne Goetje (arnegoetje) on 2010-10-02
Changed in language-pack-es (Ubuntu):
status: New → Triaged
importance: Undecided → High
Arne Goetje (arnegoetje) on 2010-10-02
Changed in language-pack-bn (Ubuntu):
status: New → Triaged
importance: Undecided → High
Changed in language-pack-ta (Ubuntu):
status: New → Triaged
importance: Undecided → High
Arne Goetje (arnegoetje) wrote :

I have uploaded a fix to lp:~arnegoetje/rosetta/po2xpi-arne which attempts to fix this. The following are the instructions to that person who is handling the language-packs now:

On the server where the language-packs are generated, the following needs to be done:
 * in langpack-o-matic is a subdirectory po2xpi, which should point to po2xpi-arne. in This subdirectory, please use bzr pull lp:~arnegoetje/rosetta/po2xpi-arne
 * to fix this bug in the current packages, do the following:
  1. in maverick/sources-base/language-pack-{bn|en|es|pt|ta|zh}-base/data/ is a mozilla.tar.gz . Untar it in a temporary directory.
  2. it will untar several subdirectories, one per language. In each subdirectory is a chrome.manifest and a firefox-3.6-$LANGCODE.jar file.
  3. in each chrome.manifest replace only the first ll_CC with ll-CC
  4. tar everything up again and replace the mozilla.tar.gz in the language-pack with the new one.
  5. cd ~/langpack-o-matic; for l in bn en es pt ta zh; do cd ../maverick/sources-base/language-pack-${l}-base; dch -v 1:10.10+20100930.1 -D maverick "Fix firefox translations (LP: #632760)"; cd ../; for p in gnome kde; do cd language-pack-${p}-base; dch -v 1:10.10+20100930.1 -D maverick "Version bump, no changes."; cd ../; done; cd ../sources-update/; for p in language-pack-${l} language-pack-gnome-${l} language-pack-kde-${l}; do cd ${p}; dch -v 1:10.10+20100930.1 -D maverick "Version bump, no changes."; cd ../; done; cd ~/langpack-o-matic; echo "../maverick/sources-base/language-pack-${l}-base\n../maverick/sources-base/language-pack-gnome-${l}-base\n../maverick/sources-base/language-pack-kde-${l}-base\n../maverick/sources-updates/language-pack-${l}\n../maverick/sources-updates/language-pack-gnome-${l}\n../maverick/sources-updates/language-pack-kde-${l}" >> updated-packages; done
 6. upload the packages like normal.

@dpm:
This bug seems only to happen when po2xpi runs in devmode, i.e. all exported .po files will be used and not just the officially published .xpi files. If you don't want this, edit the 'import' file in the langpack-o-matic source code and replace line 281 with the next higher ubuntu release number. Or, if you want to use 'devmode' for all releases in future, replace the code with something more appropriate. We ususally change the code in our local branch checkouts of langpack-o-matic, commit the changes and then pull the changes on the server, where we generate the langpacks.
You would need to re-run langpack-o-matic then and bump up the version in the launchpad translation tarball.
If you need my help, contact me on Skype.

Changed in ubuntu-translations:
status: Triaged → Fix Committed

Interestingly, my chrome.manifest files seems to be already right, i.e. they contains "es-ES" and not "es_ES":

$ cat /<email address hidden>/chrome.manifest
locale global-region es-ES jar:chrome/es-ES.jar!/locale/es-ES/global-region/
locale global-platform es-ES jar:chrome/es-ES.jar!/locale/es-ES/global-platform/
locale pippki es-ES jar:chrome/es-ES.jar!/locale/es-ES/pippki/
locale pipnss es-ES jar:chrome/es-ES.jar!/locale/es-ES/pipnss/
locale alerts es-ES jar:chrome/es-ES.jar!/locale/es-ES/alerts/
locale autoconfig es-ES jar:chrome/es-ES.jar!/locale/es-ES/autoconfig/
locale cookie es-ES jar:chrome/es-ES.jar!/locale/es-ES/cookie/
locale passwordmgr es-ES jar:chrome/es-ES.jar!/locale/es-ES/passwordmgr/
locale places es-ES jar:chrome/es-ES.jar!/locale/es-ES/places/
locale global-region es-ES jar:chrome/es-ES.jar!/locale/es-ES/global-region/
locale global es-ES jar:chrome/es-ES.jar!/locale/es-ES/global/
locale global-platform es-ES jar:chrome/es-ES.jar!/locale/es-ES/global-platform/
locale browser-region es-ES jar:chrome/es-ES.jar!/locale/browser-region/
locale browser es-ES jar:chrome/es-ES.jar!/locale/browser/
locale browser-region es-ES jar:chrome/es-ES.jar!/locale/browser-region/
locale mozapps es-ES jar:chrome/es-ES.jar!/locale/es-ES/mozapps/
locale necko es-ES jar:chrome/es-ES.jar!/locale/es-ES/necko/
locale global-region es jar:chrome/es-ES.jar!/locale/es-ES/global-region/
locale global-platform es jar:chrome/es-ES.jar!/locale/es-ES/global-platform/
locale pippki es jar:chrome/es-ES.jar!/locale/es-ES/pippki/
locale pipnss es jar:chrome/es-ES.jar!/locale/es-ES/pipnss/
locale alerts es jar:chrome/es-ES.jar!/locale/es-ES/alerts/
locale autoconfig es jar:chrome/es-ES.jar!/locale/es-ES/autoconfig/
locale cookie es jar:chrome/es-ES.jar!/locale/es-ES/cookie/
locale passwordmgr es jar:chrome/es-ES.jar!/locale/es-ES/passwordmgr/
locale places es jar:chrome/es-ES.jar!/locale/es-ES/places/
locale global-region es jar:chrome/es-ES.jar!/locale/es-ES/global-region/
locale global es jar:chrome/es-ES.jar!/locale/es-ES/global/
locale global-platform es jar:chrome/es-ES.jar!/locale/es-ES/global-platform/
locale browser-region es jar:chrome/es-ES.jar!/locale/browser-region/
locale browser es jar:chrome/es-ES.jar!/locale/browser/
locale browser-region es jar:chrome/es-ES.jar!/locale/browser-region/
locale mozapps es jar:chrome/es-ES.jar!/locale/es-ES/mozapps/
locale necko es jar:chrome/es-ES.jar!/locale/es-ES/necko/

So maybe my issue is not the same as yours and language-pack-es is not affected by this bug. Actually, my issue is about having "[chrome://global/locale/intl.properties]" instead of right language names "es-es", "es", "en-us", "en". Arne, what do you think?

On 10/02/2010 04:36 PM, Ricardo Pérez López wrote:
> Interestingly, my chrome.manifest files seems to be already right, i.e.
> they contains "es-ES" and not "es_ES":

[...]

> So maybe my issue is not the same as yours and language-pack-es is not
> affected by this bug. Actually, my issue is about having
> "[chrome://global/locale/intl.properties]" instead of right language
> names "es-es", "es", "en-us", "en". Arne, what do you think?
>

That is, because es-ES is one of those locales, where Launchpad stores
it as 'es' without country code. Those get matched to es-ES correctly,
because those mappings are hardcoded in the po2xpi script. Any other
es_* locale will be affected, i.e. any locale, where Launchpad stores it
as ll_CC and not just ll.

About your chrome settings, I don't know, because we don't set them in
the language packs. That setting must come from somewhere else.

What I'm wondering though is: this bug has been in po2xpi forever! How
come no one reported it earlier?

--
Arne Götje (高盛華) <email address hidden>
PGP/GnuPG key: 1024D/685D1E8C
Fingerprint: 2056 F6B7 DEA8 B478 311F 1C34 6E9F D06E 685D 1E8C
Key available at wwwkeys.pgp.net. Encrypted e-mail preferred.

André Gondim (andregondim) wrote :

Since last update this problem was solved in pt-br.

Cheers.

YunQiang Su (wzssyqa) wrote :

Now, is there a locale that still has this bug?

Changed in language-pack-zh (Ubuntu):
status: Triaged → Fix Released
Changed in language-pack-pt (Ubuntu):
status: Triaged → Fix Released
David Planella (dpm) wrote :

André Gondim just told me that the bug was fixed in the final Brazilian language packs for maverick. Chris Coulson also tells me that it was fixed for en-GB

According to Chris:

<chrisccoulson> i supplied a patch to po2xpi, which pitti applied (with a small correction), which fixed what i thought the problem was

@ Ricardo: was that fix in Spanish?

Subscribing the other potentially affected language teams. If you could tell us if the bug is solved for your language, that'd be great.

Thanks!

Changed in language-pack-en (Ubuntu):
status: Triaged → Fix Released
David Planella (dpm) on 2011-10-19
Changed in ubuntu-translations:
status: Fix Committed → Fix Released
Adolfo Jayme (fitojb) wrote :

This bug is no longer relevant because we're not using po2xpi anymore

Changed in language-pack-bn (Ubuntu):
status: Triaged → Invalid
Changed in language-pack-es (Ubuntu):
status: Triaged → Invalid
Changed in language-pack-ta (Ubuntu):
status: Triaged → Invalid
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers