launchpad-users team mailing list archive
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
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
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
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
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
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
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
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
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
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.
Of course. Just click "Change details" from the project's main page,
and uncheck the "Translations for this project are done in Launchpad" box.
Is there a way we could explicitly mark our project as _not_ using
launchpad for translations any more (if we wanted to)?
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!