apt templates handling in Ubuntu

Reported by Adi Roiban on 2009-10-08
30
This bug affects 8 people
Affects Status Importance Assigned to Milestone
Ubuntu Translations
Medium
Unassigned

Bug Description

The apt source package only contains the apt-all.po files and no apt-all.POT.

It look like durring the build time from apt-all, the build script creates 3 new templates:
apt.pot
libapt-pkg4.8.pot
libapt-inst1.1.pot

In Launchpad translations I have approved all 3 templates:
https://translations.edge.launchpad.net/ubuntu/karmic/+source/apt

I also did the transition from libapt-pkg4.7.pot (used in previous Ubuntu release) to libapt-pkg4.8.pot.

Since the new source package does not contains any apt-all.pot file, the current apt-all template from Rosetta is not updated. Should we disable it ?

If we disable it, will be hard for Ubuntu translators to send translations upstream.
But since there are no new apt-all template update, the current apt-all template from Rosetta is outdated.

To avoid duplicate work and keep things in sync with upstream translation, Ubuntu translators shoul only translate the apt-all.po files and the manualy approve the required suggestions in the other 3 templates.

I think we should inform Ubuntu translators about this procedure and also modify the templates description.

Michael Vogt, do you have any advice how we should best handle the apt translations in Ubuntu to make it easy for both Ubuntu translators but also for sending transltations upstream.

Adi Roiban (adiroiban) on 2009-10-08
Changed in ubuntu-translations:
status: New → In Progress
assignee: nobody → Adi Roiban (adiroiban)
Adi Roiban (adiroiban) on 2009-10-08
description: updated
Adi Roiban (adiroiban) on 2009-10-14
Changed in ubuntu-translations:
importance: Undecided → High
Adi Roiban (adiroiban) on 2009-10-14
Changed in ubuntu-translations:
importance: High → Critical
Adi Roiban (adiroiban) on 2009-11-08
Changed in ubuntu-translations:
importance: Critical → Medium
David Planella (dpm) wrote :

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)

Gabor Kelemen (kelemeng) wrote :

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.

Gabor Kelemen (kelemeng) wrote :

Todo #1 done: bug #855085 filed.

Gabor Kelemen (kelemeng) wrote :

Todo #2 done.

David Planella (dpm) on 2012-03-23
Changed in ubuntu-translations:
status: In Progress → Triaged
assignee: Adi Roiban (adiroiban) → nobody
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers