apt templates handling in Ubuntu

I think if apt-all is not used in Ubuntu, we should disable it and just expose the translatable templates the application is using.

The reason I'm suggesting this is because I think if we keep it there it will just be one more manual step we'll have to care about, which tend to be forgotten. I'd rather have an up-to-date list of templates in Launchpad than obsolete ones.

I think that if the templates are handled differently in Debian, we could add a note to the 3 current templates in LP, or alternatively, explain the differences at https://wiki.ubuntu.com/Translations/KnowledgeBase#Special%20translations and link to the document in the template descriptions.

Michael, are the templates (domains) Adi was mentioning the current ones? Should we expose these? :

apt.pot (apt)
libapt-pkg4.8.pot (libapt-inst1.1)
libapt-inst1.1.pot (libapt-pkg4.8)

At the moment in Lucid it looks like this: https://translations.launchpad.net/ubuntu/lucid/+source/apt

(note that the versions have been removed from the template names for display purposes in Launchpad, as there is only one translatable version)

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

Todo #1 done: bug #855085 filed.

Todo #2 done.