Language pack translations export needs to add universe packages to domain map

> 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.

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.

[1] http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/view/head:/lib/lp/translations/scripts/language_pack.py#L203

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-pack-exporter.py do not pass components because they want everything.
If a component were passed to the script, the tarball in the librarian would include it in the name. eg. ubuntu-quantal-main-translations.tar.gz

Maybe this issue is just about how we generate mapping.txt. I see it is created from a simple helper function iter_sourcepackage_translationdomain_mapping. If it misses the universal packages, then the mapping will be incomplete, though the actual tarball will contain them.

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.model.queue.PackageUploadCustom.publishRosettaTranslations only accepts main and restricted. I think we want to update it to accept universe too. The method is responsible for attaching the translation files in the librarian to the release.

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.

The recent full precise export on https://translations.launchpad.net/ubuntu/precise/+language-packs has neither banshee nor gnome-panel-3.0 in its mappings.txt. Is that something which only works for quantal onwards and we need the workaround for precise still? Or is that independent from the release?

Hi Martin

As far as I see, the X-Ubuntu-Use-Langpack: was dropped from both gnome-panel (since quantal, see http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/quantal/gnome-panel/quantal/revision/230 ) and from banshee (since precise, see bug 1022943), so there is no need to add these in those release. The packages now contain the translations, so I think their current situation can be considered "not broken".

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).

This is still live. Examples of missing domains: kubuntu-patched-l10n desktop_kubuntu-firefox-installer desktop_kubuntu-notification-helper

From mapping.txt in the raring 2013-04-16 langpack tarball:

kubuntu-firefox-installer desktop_kubuntu-firefox-installer
kubuntu-notification-helper desktop_kubuntu-notification-helper
kubuntu-patched-l10n kubuntu-patched-l10n

Closing this old bug. I just re-confirmed that the trusty exports are fine, they have everything in mapping.txt