← Back to team overview

launchpad-users team mailing list archive

Re: Lost in translations


Peter Clifton wrote:

Hi Peter,

I made a tarball and uploaded as usual, but some uploads have failed
(with no quoted reason), and I'm not sure the updates which claimed to
have been approved have even been merged.

You should at least have gotten an email with the error. Some of the failed files had clear errors in them that msgfmt detected, but others did not. For the ones that look alright, I've asked the system to try again. I've also re-imported the files in the queue to what appear to be their correct templates. The only errors I saw this time around were one deadlock, which is rare but becoming less so with scale (we have an idea for fixing this), and an error about a header that should be in your inbox now if it was about one of your files.

The extra imports will have produced some duplicated email for you, but I hope it fixes the problem.

If I'm working with an individual language, I can upload a .po file and
mark it as being "identical" to upstream. Why isn't there a similar
option for uploading the whole .tar.gz of .pot and .po files?

For pot files, the system has no concept of such differences: the distinction between published and user ("Launchpad-specific") translations is there to cope with multiple translation sources, not for forking of the actual codebase. For forking within a project we have release series.

When it comes to the tarball uploads, the workflow was designed with Ubuntu in mind. The assumption is that a translator is not going to upload a tarball of Launchpad-specific translations, but the people who manage a project may periodically upload a tarball of fresh templates and upstream translations. So the tarball uploads happen at the series, package, or possibly template level and contain published translations whereas translators may upload individual PO files that could be their own offline work or ones they got from some other source at their own initiative.

We've long been too conservative to mess with this. One reason is that it's very important for us to avoid adding knobs and levers where at all possible, or throwing too much text at the user. We've been discussing what we can do to improve this area of the UI recently. Your frank criticism is a good stimulant for us to do so!

Our library, libgeda has had a major SO_VERSION bump, so the translation
template is now called libgeda35 (not libgeda32). Something appears to
be severly broken in the import, as it is quoting:

libgeda/libgeda35.pot in gEDA Series: trunk

Uploaded by Peter Clifton on 2009-01-25 00:49:33 GMT Will be imported
into Template "geda-gattrib" in gEDA trun

The most likely explanation is that this file was uploaded specifically from the UI pages for geda-attrib, instead of from the "trunk" page. In that case, the system does not try to figure out for itself which template the file belongs to and trusts the context in which it was uploaded instead.

About the libgeda32 vs. libgeda35 situation: do you want those to exist side by side? Or are you saying it should be renamed? We can do either. I jumped the gun a bit by creating a new libgeda35 template. If you just wanted me to rename the old libgeda32, please say so and I can give you a single libgeda template again, with the existing translations. (I'd leave the filename out of the template, so the file-to-template matching logic is never thrown off by a name change).

If you do want the two side by side, I'd suggest having a single libgeda template but in separate release series. You can kick-start the translations for a new series by importing the translations of the previous series (or trunk) there, and from there on diverging as the texts change.

By the way, this is probably also why the imported translations weren't appearing. If libgeda35.pot was imported in place of geda-gattrib, then for all the system knows, that is the latest version of geda-gattrib. And that means that the existing geda-gattrib translations will appear as obsolete. The situation is easy to spot when you download a translation: if (almost) all the translations appear as obsolete messages, i.e. commented out with "#~", then the problem is most likely that an import went to the wrong place. I hope the kick I just administered to the import queue fixes the situation for you though.

The automated translation approval process seems to be broken,
un-necessarily slow, and very frustrating with its lack of feedback, and
sensible project admin interface.

Is there a way we could explicitly mark our project as _not_ using
launchpad for translations any more (if we wanted to)?

Of course. Just click "Change details" from the project's main page, and uncheck the "Translations for this project are done in Launchpad" box.


Follow ups