desktop-* (KDE4) and some other PO files not imported at all

[Kenneth Nielsen]

2008/10/22 Jeroen Vermeulen <jtv at canonical.com>:
> Kenneth Nielsen wrote:
>
>> Isn't manually uploading to compensate for lack of automatic
>> integration of upstream translations, a bit like peeing in your pants
>> to stay warm? As far as I know, as soon as you upload manually it
>> counts as a LP translation, which means that all the usual fun and
>> horror with override priorities start kecking in. Personally I would
>> leave it, the only effect the users will see are bad translation for
>> the first month or so, but I really don't think it is worth
>> introducing permanent work for us to fix that.
>
> I can't say I've tried that method of staying warm, but manual uploads can
> make sense: the Ubuntu package builds pump hundreds of thousands of files
> into the translations import queue, and some proportion of them will fail.
>  And it's not usually clear who should be notified about those failures.

Ahh, but that is something that could perhaps be alleviated. I don't
know if this is already implemented, but at least I haven't found it.
I think it would be a good idea to create a "tag" for the components
in LP. This value of this tag would include information about where
the component is from, upstream. So the values could be like
"gnome-svn", "kde-svn", "source-forge" or "none" in the case the code
is hosted on Launchpad. This tag could be used for several things. It
would make it easier to email the correct persons about the failed
import, you could subscribe specific persons or e-mail lists to
generally failed kde imports or language teams or specific persons
within these if say a Danish GNOME import fail. The other thing these
tags could be used for, which is off course my main interest, is that
it makes it significantly easier to show people directly in LP where
they should go upstream to translate a package. So if people click to
start translating a particular package, like say banshee, then this
"hosting" information could be visible right there to help guide them.
Hell you could even make specific translations lists based on them, so
if someone wants to work only in LP, you could show them the list of
translations that are being hosted directly in LP.

Regards Kenneth Nielsen

PS: I know that the place the code is being hosted is not always the
same as the place the translations are being hosted, but as a start
just basing the tag on where the code is being hosted is a fair
approximation.

>  If
> somebody then steps up and re-uploads the files that failed to import, the
> system will notify them of any errors and they can be handled on a
> case-by-case basis.
>
> For instance, we just discovered that a bunch of KDE files used a bit of
> syntax that our parser couldn't handle: "#~|" to mark old msgids of messages
> that are both fuzzy and obsolete.  So we stripped out the offending lines
> and re-uploaded just the affected files.  There were only about 1400 of
> these, so the automated "blind" upload took care of most of the work and
> made it possible to do something about the missing ones.
>
> Something else I'd like to do about this (when there is time! :-/ ) is to
> make the failure messages accessible from the import queue UI.  See the
> blueprint here:
>
> https://blueprints.launchpad.net/rosetta/+spec/import-queue-failed-error-display
>
>
> Jeroen
>