← Back to team overview

launchpad-users team mailing list archive

Re: Lost in translations


Peter Clifton wrote:

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.

I know how you feel. It may be worthwhile to do some extra filtering for this.

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.

Just be sure not to do it if the files haven't been modified, so you don't end up replacing new translations with old ones. (This is why we give the error: we can't tell whether someone just forgot to update the timestamp or we're really looking at an outdated version of the file).

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.

Did it fix the problem of all those files being imported to the wrong template though?

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

You can use the Launchpad Translations tools to automate periodic uploads, if you want:


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.

Ah, then the system will see them as coming from an external source ("published elsewhere").

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.

It's a bit of a hassle, but if you want to change that, here's what you can do: export your current translations as a single tarball. Where the "in-Launchpad" translations differ from the "upstream" ones, that will give you the in-Launchpad ones. Then you re-import this tarball, and the effect Launchpad sees is that upstream synchronized with its translations.

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.

I meant it: sometimes it's good to be shaken up a bit.  :)

By the way, if you're interested in organizing the translations more tightly, e.g. because you have some languages that you can afford a real quality-control process for, consider using a translation group. We can set one up for you (just file a question in the Answers app for the rosetta project) or you may want to use the Launchpad translation group. With a translation group assigned, you get to choose access models that give you more control.

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.

There are definitely things we want to do in that direction. Ironically the limiting factor is engineering time.

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.

Right, there was a whole bunch of files that went wrong. For some of the imports that failed you may need to be explicit about what template they should go into the next time you upload.

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.

Naturally. So for that, I'd definitely consider release series. That lets you leave one template alone while you move ahead with the other.

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're going to import upstream files, then Launchpad will follow the naming scheme used upstream. It's not particularly important for Launchpad whether you keep the number in there, so long as it's consistent (avoiding the need for manual approval when a file name changes). So if you had a "35" release series with a libgeda35.pot, and a "32" release series with libgeda32.pot, then you could upload libgeda32.pot files to the one and libgeda35.pot to the other. You can do that now, in a single series, but we don't deal terribly well with multiple templates in the same directory and it really confuses the auto-approval process.

For example if we need to review a PO upload, it'd have to be clear which template it was for, so that'd have to be in the path or filename somewhere.

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.

Yes, you can. In fact you'll probably want to do some of that: when people translate to a new language, Launchpad transparently creates a POFile on the fly. At that point it picks a filename for it, but that may not be the name you would have used.

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.

Thanks for your confidence.  Definitely want to keep you on board if we can!