Just to recap, the basic workflow is the following in the upstream apt:
- translators translate po/apt-all.pot
- the build system splits the translations into three smaller templates: apt, libapt-pkg4.11, libapt-inst1.3. The apt binaries use these, and apt-all is not used after this build time step at all.
At this point, enters Ubuntu packaging. Formerly, all three templates went into the apt package, recently this changed, and they go into the apt, libapt-pkg4.11 and libapt-inst1.3 packages.
pkgbinarymangler does not know about this yet, so it strips away translations from the latter two packages: http://bazaar.launchpad.net/~ubuntu-core-dev/pkgbinarymangler/ubuntu/view/head:/striptranslations.blacklist
*Todo: file a bug about this (I volunteer :)).
In Launchpad Translations, we have currently all four templates enabled to import and translate, but only apt-all is set to export into langpacks, which is exactly the inverse of what should be done, if we want to provide updates in the langpacks: https://translations.launchpad.net/ubuntu/oneiric/+source/apt/+translations
* Todo: unset exporting apt-all, set exporting the derived templates. The versioned translation domains have to be updated too.
I think this is what we should do:
- encourage translators to translate apt-all.pot, then make sure it gets exported at non-langpack freeze time, and the apt package is rebuild with it, so folks can see its strings translated at install time too. I don't think that exporting the three derived templates to be used at build time would especially please the package maintainers, but I can be wrong :).
We can also encourage syncing this with upstream.
- ask translators to fill in only new translations into the three derived templates. Because .mo files in /usr/share/locale take precedence over those in /usr/share/locale-langpack (and rightly so), only newly translated strings will be visible via langpack updates, corrections of existing strings will have to wait until next export&rebuild.
Status update, as of Oneiric.
Just to recap, the basic workflow is the following in the upstream apt:
- translators translate po/apt-all.pot
- the build system splits the translations into three smaller templates: apt, libapt-pkg4.11, libapt-inst1.3. The apt binaries use these, and apt-all is not used after this build time step at all.
At this point, enters Ubuntu packaging. Formerly, all three templates went into the apt package, recently this changed, and they go into the apt, libapt-pkg4.11 and libapt-inst1.3 packages. bazaar. launchpad. net/~ubuntu- core-dev/ pkgbinarymangle r/ubuntu/ view/head: /striptranslati ons.blacklist
pkgbinarymangler does not know about this yet, so it strips away translations from the latter two packages: http://
*Todo: file a bug about this (I volunteer :)).
In Launchpad Translations, we have currently all four templates enabled to import and translate, but only apt-all is set to export into langpacks, which is exactly the inverse of what should be done, if we want to provide updates in the langpacks: https:/ /translations. launchpad. net/ubuntu/ oneiric/ +source/ apt/+translatio ns
* Todo: unset exporting apt-all, set exporting the derived templates. The versioned translation domains have to be updated too.
I think this is what we should do: locale- langpack (and rightly so), only newly translated strings will be visible via langpack updates, corrections of existing strings will have to wait until next export&rebuild.
- encourage translators to translate apt-all.pot, then make sure it gets exported at non-langpack freeze time, and the apt package is rebuild with it, so folks can see its strings translated at install time too. I don't think that exporting the three derived templates to be used at build time would especially please the package maintainers, but I can be wrong :).
We can also encourage syncing this with upstream.
- ask translators to fill in only new translations into the three derived templates. Because .mo files in /usr/share/locale take precedence over those in /usr/share/