Ubuntu Wiki

Launchpad Translations import queue management

Import queues

• Hardy

• Intrepid

• Jaunty

• Karmic

The auto-approver script

• Runs every ten minutes if it finishes in less than that, but with a long queue it may take up to an hour (or even two) for it to complete.

General rules when doing approvals

• We only approve .pot templates, not .po files. An exception to this rule is when a .po file has been uploaded manually. But normally, approving the template will pull in all .po files associated with it.

• We don't approve help files, man pages, test cases and other package-specific documentation. Those items should set to "blocked".

• "blocked" means the template won't show up again, "deleted" means the current entry is removed from the list. If there is a new upload of the same template, it will show up again. This is useful if there are two entries of the same template, dating from different package versions. In this case we would delete the old one and approve the new one.

• When approving, we need to click onto the "Edit" button on the right hand side and fill in the template name and the translation domain. Usually the translation domain is the same name as the .pot file, just without ".pot". The template name is usually also the same, with two exceptions:

  1. Underscores need to be replaced with hyphens ("_" -> "-"),

  2. Usually the templates don't carry a package version number, while the translation domain and the .pot file do. This is actually a bug in the package and should be reported as such. .pot and .mo files should not contain version numbers. If you are not sure of the template name, click on the package name in the import queue to find out which templates exist already.

• Sometimes it's necessary to dig in the source code of a package and build it locally to find out what to do with the templates.
• If the .po files will not be compiled into .mo files during build time of the package, then we don't want those templates in our language-packs (and usually also not in Rosetta). Ubuntu-docs and debian-installer are accepted into Rosetta but will not be exported into language-packs for obvious reasons. For those templates the checkbox in the approval screen needs to be unchecked.

Checking package compatibility with language packs

There is nothing magic about language packs. In order to use the translations from langauge packs a package should read the .MO files from a predefined location specified at build time (/usr/share/locale-langpack/).

To check this functionalty you will need to build the binary package:

$ apt-get source PACKAGE_NAME
$ find . -name "*.pot"
$ dpkg-source -x PACKAGE_NAME.dsc
$ cd PACKAGE_NAME
$ debuild -us -uc
$ find ./debian/PACKAGE_NAME -name "*.mo"

If debuild will complain about unmet build dependencies, please install them.

Now we have the following case:

No POT file

If the first "find" command will not reveal any POT file, this means there are no strings available for translations and there is no way you can use Launchpad Translation for translating this package.

If the source package is using a different format for handling the translation, please contact the package maintainer and see if the package can be converted to use gettext standards.

The only exceptions are firefox and openoffice, but we will exclude them, as they require special/extra care.

No MO file

If the second "find" will not show any "MO" files, again the package can not be used with language packs".

If the source package contains "POT" files, but the binary will not produce any "MO" files, this means that the translations are only used during the build phase, and not at runtime.

For now on, you can block the specific "POT" files in the import queue, and inform the package maintainer that those translations can only be translated upstream. Also the package maintainer must take care not to include specific Ubuntu string in those "POT" files, of if he need to, then ask him to requiest help/guidance from UTCs.

MO file in /usr/share/locale

If the binary package contains "MO" files in /usr/share/locale, then evertying is OK and the "POT" template can be approved.

MO file in an arbitrary location

If the binary package contains "MO" files in arbitrary location and not at the "LOCALE" variable specified during build time, the package will not use the langauge packs.

Please contact the package maintainer and see if you can modify to source package to use the standard LOCALE location.

Operations

The next sections provide step-by-step guides on how to perform some common operations when acting on the imports queue entries.

Disabling templates

1. Uncheck the "Accept translations" checkbox
2. Uncheck the "Include translations for this template in language packs?" checkbox
3. Save changes

Renaming templates

1. Locate the old template
2. Go to the old template and open the "Administrate" page
3. Rename the old template name and translation domain to the new one. If necessary, change the source package entry to the new package (if the template has been moved).
   • TODO, check: possibly renaming the template is enough, as the translation domain will be extracted from the approved new "Needs review" entry in the import queue.
4. Save the changes
5. In the import queue approve the new template with the same template name and translation domain like the one you have just modified
6. At this point the the new template and translations should be in the right place.

Notes:

• Template names are internal to Launchpad and case-sensitive. We stick to using lower case names for convention.
• Domain names should use the case format the application is using.
• In case the new template has already been approved, we'll have a conflics and some manual work will be required (downloading translations and uploading them back again). That's the reason we follow the above procedure: updating the old template first to avoid such conflicts.

To do items

Items the UTC team needs to take action on:

Unknown translation domains

When generating language-packs, occasionally errors show up in the log. One of those errors is called "unknown translation domain", which indicates that a given translation domain is either not used by any package in 'main', or that the translation domain name is buggy (i.e. has been renamed or contains errors, like upper/lower case letters, etc.).

For Karmic, the following translations domains have errors. We need to investigate how to resolve those errors.

Unknown languages

The following languages don't have language-packs, because they don't have locale codes yet. The UTC team needs to get in touch with those who care about those languages ask them to create a locale and to submit it to upstream glibc. Also, if they need help, we should assist them with doing so.

Other useful information

• Language pack generation schedule

CategoryTranslations