Comment 13 for bug 1637801

The correct approach is to have gettext look into the langpack translations first, and then fall back to the package's translations. That's also the way it was explained to work: Packages ship initial translations for bootstrapping purposes, and those can be updated via language packs.

I have no intention to ship translations from Launchpad in apt. That would mean diverging from the upstream packaging, which I have no intention to, I'm happy we got that working without a diff now. If people want to help with the translations apt ships, they can do that _upstream_ (talk to the previous translators, and take over if they don't respond).

That said, even if I wanted to, merging the translations from launchpad would be a pain in the ass:

First of all, the translation templates are not remotely up-to-date (only since 1.3 there's a chance for Launchpad to import them, previous versions only had templates without any of the headers). Thus, Xenial does not have templates suitable for the apt version it ships with, but rather for 1.0something or similar.

Secondly, the translation templates in launchpad are the split ones - APT's build system requires a merged translation file of all domains.

What we can do, if neccessary, is fix translations in the stable branches for strings not in master. But that really needs review by the appropriate channels upstream as well. And especially for 17.04 and 17.10 - those will get the same release series as the next Debian stable release. For Ubuntu-only branches, we can probably relax the translation-ML-must-review requirement, but it seems a bit rude.