Untranslated Firefox in the Maverick and Lucid language pack PPAs
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| langpack-o-matic |
Fix Released
|
Undecided
|
Unassigned | ||
Bug Description
It seems that the change in langpack-o-matic to copy the xpi files is causing an issue in the language pack PPAs containing FF3.6 translations (maverick+lucid), as it seems that translations have moved from the -base to the delta package and don't work there.
This was discussed on the translators list recently https:/
By the way, another related question: it seems that the translation domain as set in Launchpad is used as the name of the folder in which the xpi translations are stored in the full export translations tarball.
As I understand it, we'll have to support the two XPI layout formats (.jar archive in the xpi file vs. unpacked files -no .jar- in the FF4 xpi file) while we've got both FF 3.x and FF 4.x in the Ubuntu archive.
Right now the domain is 'firefox' for all versions. Would it help if I named the domain as 'firefox-3.6' (or 'firefox-3.x' or whatever) for Lucid and Maverick and name it 'firefox-4.0' (or 'firefox-4.x', 'firefox', etc.)?
This way langpack-o-matic or po2xpi could detect which xpi format to process and (in dev mode) to create.
Related branches
| Martin Pitt (pitti) wrote | #1 |
| Changed in langpack-o-matic: | |
| status: | New → Fix Released |
| Martin Pitt (pitti) wrote | #2 |
| Redmar (redmar) wrote | #3 |
Fixed in langpack-o-matic and rolled out. The next build of language packs will have this fixed. Note that I can't automatically fix packages for people who already upgraded to the broken PPA version; they will need to purge the packages (-base as well) and reinstall them.
As for the domain name, right now I'm actually making the distinction based on the Ubuntu release, not the firefox release. But I wouldn't actually look at the domain name, but at the supported version in the install.rdf; so po2xpi could create unpacked (4.0) vs. jar'ed (3.6) XPIs based on the version in install.rdf, not based on the domain name. I think that's a more robust approach, so from that POV we don't need to change the domain names.