launchpad-users team mailing list archive

[Jeroen Vermeulen <jtv@xxxxxxxxxxxxx>]

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

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

  https://launchpad.net/lp-translations-tools


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


Jeroen