Ubuntu translations import queue management in Launchpad
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:
Underscores need to be replaced with hyphens ("_" -> "-"),
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. Exception to this rule: packages where multiple versions can be installed in parallel, e.g. postgresql, firefox, xulrunner. Those templates need to have version numbers.
- 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 language packs a package should read the .MO files from a predefined location specified at build time (/usr/share/locale-langpack/).
To check this functionality 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 request help/guidance from UTCs.
MO file in /usr/share/locale
If the binary package contains "MO" files in /usr/share/locale, then everything 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 language packs.
Please contact the package maintainer and see if you can modify to source package to use the standard LOCALE location.
The next sections provide step-by-step guides on how to perform some common operations when acting on the imports queue entries.
- Uncheck the "Accept translations" checkbox
- Uncheck the "Include translations for this template in language packs?" checkbox
- Save changes
- Locate the old template
- Go to the old template and open the "Administrate" page
- 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.
- Save the changes
- In the import queue approve the new template with the same template name and translation domain like the one you have just modified
- At this point the the new template and translations should be in the right place.
- 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 conflicts 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.
Tips and tricks
When exporting translations from Launchpad, they are not named ll.po, but rather template-ll.po (TODO: point to bug). To mass-rename translations, mmv can be quite useful. Here's an example of renaming all PO files from the about-kubuntu template:
mmv "about-kubuntu-*.po" "#1.po"