Language pack translations export needs to add universe packages to domain map
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
| Launchpad itself |
Low
|
Unassigned | ||
| Ubuntu Translations |
High
|
Unassigned |
Bug Description
As a follow-up to bug 788685, translations from selected universe packages can be now imported to Launchpad and exported to language packs.
However, they are not added to the domain map file (mapping.txt), which maps translation domains to source packages. As such, they are ignored by langpack-o-matic (the tool that processes that file and creates the language packs on the distro side), translations are not included in language packs, and the affected applications are left untranslated.
This bug is simply about adding the universe package entries to the domain map.
Martin Pitt (pitti) wrote : | #1 |
Changed in launchpad: | |
status: | New → Triaged |
importance: | Undecided → Low |
tags: | added: langpack lp-translations |
David Planella (dpm) wrote : | #2 |
I've noticed that there is a 'component' parameter in the code [1] to specify from where (e.g. main, universe, etc.) translations are exported. I'm not sure how the language pack exporter script is called in the cron job, but I could imagine that the component is not passed.
So my hope is that it is a small job and just a matter of passing main and universe as components in the cron job to enable listing the universe PO files in mapping.txt.
Could someone more familiar with the LP code perhaps confirm?
Thanks.
Curtis Hovey (sinzui) wrote : | #3 |
Hi David.
I looked at the script and the model code. The script uses the components argument to filter non-matching components. You don't want to do that. Our 3 cronscripts for language-
If a component were passed to the script, the tarball in the librarian would include it in the name. eg. ubuntu-
Maybe this issue is just about how we generate mapping.txt. I see it is created from a simple helper function iter_sourcepack
I looked at bug bug 788685 and I think I see an incomplete fix. I see that we can use universal packages in recent series, but lp.soyuz.
Changed in ubuntu-translations: | |
status: | New → Triaged |
importance: | Undecided → High |
William Grant (wgrant) wrote : | #4 |
AFAICS this works fine. banshee appears in the mapping file of the full quantal export from October, and there's no raring export yet to suggest that it's broken.
Changed in launchpad: | |
status: | Triaged → Incomplete |
Martin Pitt (pitti) wrote : | #5 |
The recent full precise export on https:/
Gabor Kelemen (kelemeng) wrote : | #6 |
Hi Martin
As far as I see, the X-Ubuntu-
I think it is enough to automatically add the necessary entries for Raring, so that Raring can see a wider use of this feature (finally).
Martin Pitt (pitti) wrote : | #7 |
This is still live. Examples of missing domains: kubuntu-
Changed in launchpad: | |
status: | Incomplete → Confirmed |
William Grant (wgrant) wrote : | #8 |
From mapping.txt in the raring 2013-04-16 langpack tarball:
kubuntu-
kubuntu-
kubuntu-
Changed in launchpad: | |
status: | Confirmed → Invalid |
Martin Pitt (pitti) wrote : | #9 |
Closing this old bug. I just re-confirmed that the trusty exports are fine, they have everything in mapping.txt
Changed in ubuntu-translations: | |
status: | Triaged → Fix Released |
> This bug is simply about adding the universe package entries to the domain map.
More specifically, only those packages which are marked for using langpacks. It doesn't hurt to include _all_ universe packages, but it's not necessary if it helps to save DB query time, etc.