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

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=

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.

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

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?

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

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

At least, it happened in karmic and lucid.

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=

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

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.

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

cheers. ;)

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.

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.

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

Cheers.

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

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!

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