ubuntu-translations-coordinators team mailing list archive

[Arne Goetje <arne@xxxxxxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi fellow UTCs,

We've been working on the imports queue during the Platform sprint this
week, and altough we've managed to bring the list of POT templates
needing review to 0, we've also noticed that there is a large number
(ca. 9000) of PO files still stuck in the Needs Review queue. I've been
investigating some of those cases and I discovered that there are
different causes involved. At this point, I'd like to ask you for your
help in fixing them.

Here is a general advisory on how to investigate the problems:

1. I have a script in
https://code.launchpad.net/~arnegoetje/+junk/translation-tarballs
(thanks to Martin Pitt), which gives you the download location of the
.translation.tar.gz tarballs which are fed to Rosetta on import, so that
you don't need to rebuild the source packages locally. :)
Download this script, you will need it. ;)

  bzr branch lp:~arnegoetje/+junk/translation-tarballs

The .translation.tar.gz tarballs get created on build time when
pkgbinarymangler is installed. These tarballs are fed to Rosetta and
include all the templates and .po files for a given source package. In
order to find out packaging bugs, we need to investigate these tarballs.

Change the date in line 34 to include the latest import date of the
package you are looking for. The script will output all imports since
that date. So, you may need to filter the output. :)

2. In the import queue, filter the list for .po files and 'Needs Review'
3. click on the link to the source package of an entry and see the
import queue for that source package (might be best if you do it in a
new tab).
4. Filter the list for 'Needs Review'. You may see files from multiple
uploads, check the date.
5. Figure out what the problem is. Here are a few hints and solutions:

 * if the path of the .po files in the list suggests that we don't want
them in Rosetta anyways, set them to be 'Blocked'. This is the case for
help/, doc/, test/ and similar files which don't seem to belong to the
main template. The corresponding template might have been blocked
already, but the .po files have not been moved into blocked state for
some reason. Hint, use the translation-tarball script mentioned above to
grab the tarball of the latest build and see the structure of that
tarball. If those .po files belong to test cases in the package, please
file a bug against the package and ask the package maintainer to remove
those .po files. (Example bug:
https://bugs.edge.launchpad.net/ubuntu-translations/+bug/409773 ).

 * if you find that all is left in the queue are some .po files with
encoding information in the filename (e.g. zh_CN.cp936.po, ja.sjis.po,
...), please delete those and file a bug (e.g.
https://bugs.edge.launchpad.net/ubuntu-translations/+bug/409765 ). Those
files are completely useless.

 * if you find no.po files, please file a bug (e.g.
https://bugs.edge.launchpad.net/ubuntu-translations/+bug/409765 ). 'no'
is obsolete and has been split into 'nb' and 'nn'. Mostly, 'no'
translations are in fact 'nb'. It should be mentioned in the header of
the .po file. Check if it really is Bokmål and if there is already
another nb.po file in the tarball. If there is already another nb.po
file in the tarball, the no.po file might just be obsolete. Check in
Rosetta when the 'Norwegian Bokmal' translations were updated the last
time. If you decide we still need to import the no.po file, approve it
with the language code for 'Norwegian Bokmal (nb)'.

 * if you find 'bn_IN.po' files left behind, check when 'Bengali' was
last updated for that package in Rosetta. If there is already a newer
version in Rosetta, just delete the .po file in the queue. If not,
approve it as 'Bengali', _not_ 'Bengali (India)'. This was actually a
bug in Launchpad, which has been fixed recently. Future imports of bn_IN
should go through automatically.

 * if you find that many languages have not been imported for the same
template, check in the Administrate screen of the template, if the
'Source path' is the same as the .po files in the queue. For example: if
the .po files have a path of src/po/de.po, but the template has a source
path of 'foo-2.3.1/src/po/foo.pot', import won't work. The path in the
template needs to be corrected to match the .po files. Change it to
'src/po/foo.pot'. After this change, the remaining .po files will be
picked up and imported automatically. No need to approve them manually.

 * if you find .po files without a template (check the tarball!), please
file a bug against the package. E.g.
https://bugs.edge.launchpad.net/ubuntu-translations/+bug/409770

I have put some generic guidelines for package maintainers on the wiki (
https://wiki.ubuntu.com/UbuntuDevelopment/Internationalisation#Verifying%20translation%20uploads
).
If you find anything in the tarballs which gravely violates these
guidelines, please consider filing a bug against the package.
Example bug reports:
 * https://bugs.edge.launchpad.net/ubuntu-translations/+bug/409765
 * https://bugs.edge.launchpad.net/ubuntu-translations/+bug/409770
 * https://bugs.edge.launchpad.net/ubuntu-translations/+bug/409773

Please let me know if you've got any questions.

Cheers and Thanks
Arne
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkp6+AwACgkQbp/QbmhdHozTPwCdH5rru59LyUu27jJ05W67UVZv
g58AniQ9WiyS6a9xcN8TPCE+TRXaZ9rU
=TiKD
-----END PGP SIGNATURE-----