launchpad-users team mailing list archive

[Peter Clifton <pcjc2@xxxxxxxxx>]

On Mon, 2009-01-26 at 20:13 +0700, Jeroen Vermeulen wrote:
> 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.

Turns out they had been filtered into the folder where I get all Ubuntu
email. I'm a member of the Ubuntu-X swat team, so that folder tends to
get overrun with bug reports.

The error cited was that there wasn't a timestamp:

"
We were unable to import your translations because you did not update
the time stamp in its header to state when you added your translations.

To fix this problem, please upload the file again, but with the 'PO-
Revision-Date' field updated.
"

I'm just importing exactly the .po files we have upstream. I guess I can
look through the git commit logs, find when they were last modified and
add a header.

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

Unfortunately not, but at least having found the emails, I can see why
it is failing.

> > 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.

We aren't forking the code-base, we _are_ dealing with multiple
translation sources (I think). Our old translators have been making
updates in GIT, so it is important for us to re-upload the upstream
translations.

> 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.

That is exactly my position. I'm trying to manage translations for the
gEDA project, not upload my 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.

Indeed - although Launchpad now seems to think almost all our
translations were modified in Launchpad, and doesn't list them as being
the same as upstream.

> 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!

Sorry I was a bit negative about it. If we can get this to work, I know
it will encourage translators who wouldn't otherwise intact with our
project to help translate it.

As a gEDA project admin, I feel like there ought to be extra knobs to
allow me to help myself through any problems with the import. I hate the
fact that I have to rely on bugging people at canonical to fix mistakes
at the first round level.

It would seem that there are a lot of periodic admin tasks (like dealing
with the template name change) which I just can't do for myself.


> > 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.

It was in the tarball, in a "libgeda" directory - same as in the
original upload of translations. It wasn't the only part of the upload
which was mis-classified as gattrib.

> 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).

We're not intending to update translations for the stable release
series, as hopefully we'll be releasing another stable release in a few
months.

I honestly don't know what the best thing to do with libgeda32/35 is. A
lot of the strings will be the same, so yes.. we'd not want to loose
translations from the libgeda32 template when migrating to libgeda35.

The SOMAJOR suffix is only there because Debian like to co-install
different library versions, and this allows us to provide co-installed
translations for them. We _could_ drop the number, but I'd guess it is
also important that translations on Launchpad / upstream match?

> 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.

That's one possible way, and presumably when we export translations for
shipping upstream, we can rename the .po files.

> 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.

I didn't see anything.. the old gattrib messages in the web interface
remained, no new ones appeared. I think I might have even tried
exporting them to look.

> > 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.

Thanks - I didn't find it when I looked. I won't push it just yet, as
hopefully we can get this resolved.

Thank you for your kind assistance,


Best wishes,

-- 
Peter Clifton

Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9, JJ Thomson Avenue,
Cambridge
CB3 0FA

Tel: +44 (0)7729 980173 - (No signal in the lab!)