Old upstream strings locked by "changed in launchpad"

[Jannick Kuhr]

The upstream maintainer of the german Kaffein translation has contacted our team due to the following problem:

A lot of strings in Kaffeine are different from the current german upstream version. I tried to fix this by importing a new po file manually marked as upstream translation, but nothing changed. My first idea was that these strings may have been translated in Rosetta in the days of the Dapper release, when many upstream translations were missing from Rosetta. But the translator of many (all?) of these strings is the old upstream translator, who never was member of the Ubuntu translation teams. I think the mayority of these strings has been imported into Rosetta for Hoary or breezy:

[Jürgen Kofler does not use Launchpad. This page was created on 2005-08-23 when importing the German (de) translation of kaffeine in Ubuntu Breezy package "kaffeine".]
https://launchpad.net/~kaffeine-gmx

For example the followings strings are affected:

Message 508:
    'Can't init xine Engine!'
Old (Rosetta):Modified Message:
    'Kann xine-Engine nicht initialisieren!'
New (upstream):
    'xine kann nicht eingerichtet werden!'

Message 382:
    'Effect &Plugins...'
Old:
    'Effekt-&Plugins...'
New:
    'Effekt&module ...'

Message 572:
    'New Item'
Old:
    'Neuer Eintrag'
New:
    'Neues Element'

Message 333:
    '&Player Engine'
Old:
    '&Spieler-Engine'
New:
    'Abs&pielgerät'

Message 302:
    'Set video driver'
Old:
    'Video-Treiber'
New:
    'Videotreiber einstellen'

Message 28:
    'This name is not unique.'
Old:
    'Diese Bezeichnung ist nicht einmalig.'
New:
    'Diese Bezeichnung ist nicht eindeutig.'

Message 341:
    'Enter a URL:'
Old:
    'Geben sie eine URL ein:'
New:
    'Bitte Adresse eingeben:'

I attached the output of Sebastian Heinleins tool podiff. It contains an endless list of also affected strings.

[Jannick Kuhr (jakuhr-deactivatedaccount)]

Carlos, do you have news regarding this issue?

[Carlos Perelló Marín (carlos)]

It would be that someone selected/changed those translations. Until recently, we didn't track the 'reviewer' so there is no way to know for sure whether it was done due to a bug or someone doing bad reviewer work.

To complete your 'fix' you need now to do the same upload you did as published as user upload. That will set all metadata matching upstream and Ubuntu versions so next upstream update will update translations in Ubuntu automatically again. That's the workaround we have right now until we add a way in our UI to revert translation changes.

Another option is that you file a ticket on answers.launchpad.net/rosetta requesting that we revert everything to whatever we have noted as coming from upstream, but this one is slower as it needs some DBA action.

[Jannick Kuhr (jakuhr-deactivatedaccount)]

Ok, I uploaded a 'fix' (user upload) right now. Thank you :)

[Jannick Kuhr (jakuhr-deactivatedaccount)]

The new filter "Changed in Launchpad" shows, that a lot of other KDE apps are affected too. For example in kicker 4 strings [1] are locked by the "changed in Launchpad" flag. All of this have been imported to launchpad by the initial import of KDE apps (probably for dapper) and were the official upstream translation at this point. I am quite sure that noone ever touched these strings in Launchpad, but they are "locked". In kdelibs I found about 50 strings like this, but already fixed them.

[1] https://launchpad.net/ubuntu/gutsy/+source/kdebase/+pots/kicker/de/+translate?batch=10&show=changed_in_launchpad

[Timo Jyrinki (timo-jyrinki)]

This should be fixed now in the way that you can select a "Packaged" string for each of the results from the Changed in Launchpad filter. After that, those strings should receive also future updates from upstream, and are not anymore shown in the Changed in Launchpad searches. Correct me if I'm wrong, I'm no Launchpad developer. Marking as Fix Released.

[Jannick Kuhr (jakuhr-deactivatedaccount)]

Sorry, but this bug is not fixed in any way. The new feature just makes it possible to locate such strings and fix each of them manually. At least I don't want to click me through about 1500 templates and fix each of these strings (somtimes up to 100 and more...).

Don't misunderstand me, the new feature is very nice and makes it possible to handle minor differences between upstream and launchpad very well, but it doesn't really help to solve the horror that happened last year.

The only possibility to fix these issues seems to be a complete reset off all translations. At least the german team is thinking about taking this step, although it would result in the loss of almost all strings translated by our translators in lauchpad. But atm we have to confess that the Ubuntu/Kubutnu/Xubuntu translation has the worst quality of all distributions.

Perhaps you woul like to mark this bug as "Won't fix"?

Kind regards,

Jannick

[Matthew Paul Thomas (mpt)]

Jannick, so you want something more than reverting individual translations, but less than reverting all translations. Can you be more precise?

[Jannick Kuhr (jakuhr-deactivatedaccount)]

I thought it would be also in your interest to figure out what happened last year and caused this problem of Rosetta, not just to fix the results. And I still hope that we could ensure that this issue is already fixed and won't happen again. Perhaps it would be also possible to detect affected strings and only reset this ones?

If you told us that you know what happened, the bug is already fixed and you don't see any other possibility than resetting the whole translation, you could close this bug.

I hope you understood my point.

Kind regards, Jannick

[Данило Шеган (danilo)]

Jannick, we've got a new reversion process (per PO file) already planned: https://blueprints.launchpad.net/rosetta/+spec/revert-translation-to-packaged

For solving the crap we've had in the DB more than a year ago will require more investigation, and we'd need a lot more help from you (you made a good start here). I'd suggest you file a separate bug about it.

But, do you really feel that the "old upstream strings locked by 'changed in launchpad'" bug is not fixed? I know you may not like the solution, but are the strings still locked?

If you agree that the problem is solved, please close the bug (bug is not a discussion forum, imho). If you don't agree, can you explain what is it that is not solved here?

Thanks.

[Jan Claeys (janc)]

It seems like “last year's bug” is not solved and still exists...
https://bugs.launchpad.net/ubuntu/+source/libqalculate/+bug/72226/comments/6

[Данило Шеган (danilo)]

I just looked at Tino's comment and Dutch coreutils translation, and the uploaded PO file is identical to what we get when we export the file from Launchpad, except for one string which seems to be the victim of our whitespace handling:

@@ -2655,7 +2667,7 @@
 # (tino)
 #: src/df.c:152
 msgid "Filesystem "
-msgstr "Bestandssysteem "
+msgstr "Bestandssysteem "

Anyway, this seems to be totally unrelated to this problem.

[Данило Шеган (danilo)]

FYI, whitespace handling bug is bug #30358.

[Tino Meinen (a-t-meinen)]

Danilo, thank you for your comments.
I assumed that my translations were lost, exactly because of the one string you mentioned. It's the one that's most visible to me, and the one that prompted me to look into the coreutils package.
So: seeing that string reverted back to its faulty translation, I wrongly assumed all my translations were lost..

the faulty translation of
#: src/df.c:152
msgid "Filesystem "
msgstr "Bestandssysteem "

causes the output of " df -h " to be badly misaligned.

I'll add myself to the whitespace-bug you mentioned to track the status of it.
As soon as it's fixed, I'll update my coreutils package.

Thanks again for clearing things up.

[Tino Meinen (a-t-meinen)]

Hmm, the makeup of the command gets lost in the bug so to clarify I replaced the spaces with '+'characters to make things clearer here.
#: src/df.c:152
msgid "Filesystem++++++++"
msgstr "Bestandssysteem++++++++"

[Andrej Znidarsic (andrejznidarsic)]

The error is still there. I have noticed it for slovenian translation, as some upstream packages are dated 2007 and even 2006 !!

This extremely lowers the quality of ubuntu translations.

Can't be something done about this ?

[Данило Шеган (danilo)]

Andrej, can you please point us at the exact messages where you see the problem. Thanks!

[Andrej Znidarsic (andrejznidarsic)]

Sure.
One example is f-spot, which has been updated on 2008-07-07, although there have been newer upstream translations. If you look at it here - https://translations.launchpad.net/ubuntu/karmic/+source/f-spot/+pots/f-spot you will notice there are 0 strings, which were translated from upstream. All of the translated strings have been translated in launchpad. If you look at it at gnome localization page ( i do gnome translations, so that's what i know), you will notice it has been recently completed to 100 % (before it was partially completed) and wasn't imported on 2009-09-23 as were some other packages, which were uplaoded at gnome translation freeze. (one example which was updated on 2009-09-23 is gnome-settings-deamon, because it hasn't been updated in launchpad)
Further point to confirm that is that f-spot.po in launchpad has 873 strings, while at l10n.gnome.org it has 866 strings.

On link here you can see it hasn't been attempted to be imported (disregard my manual upload from today) for karmic (or jaunty or intrepid) at all. https://translations.launchpad.net/ubuntu/karmic/+source/f-spot/+imports

Another example, this time core gnome package named brasero, which has the right amount of strings, but still 125 untrasnlated,
https://translations.launchpad.net/ubuntu/karmic/+source/brasero/+pots/brasero/sl/+translate
even though it has been tarnslated 100 % in gnome upstream at both gnome 2.28 and gnome 2.26
http://l10n.gnome.org/languages/sl/gnome-2-26/ui/
(therefore it should have been fully translated in jaunty as well, but it wasn't).

There are numerous other examples where the package has been partially translated in GNOME, missing translations were added in launchpad and the .po files were not updated anymore.This is bad beacause some strings have been changed in the upstread as
we correct mistakes and unify translations with other projects.
In the last two days i have changed all the strings (which were changed but not translated in launchpad) from such projects to packaged versions in hope they will get updated from upstream for karmic.

It is really annyoing some bugs keep on appearing over and over again so i would be VERY pleased if this would be fixed.

[Данило Шеган (danilo)]

What Andrej describes are separate problems, and I don't see them anymore. Please file these as separate bugs as soon as you notice them next time, so we can investigate. Also note that the way upstream translations get into Launchpad's Ubuntu part is through Ubuntu packages, so there always is some delay between them being available upstream and in Ubuntu. Also, this depends entirely on Ubuntu packagers (for now).

We are working on syncing directly from upstream.