launchpad-users team mailing list archive

[Jeroen Vermeulen <jtv@xxxxxxxxxxxxx>]

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.

Jeroen