Lock GNOME upstream translations

[Johannes Schmid]

In the discussion on gnome-i18n-list (http://mail.gnome.org/archives/gnome-i18n/2008-January/msg00227.html) most translators would prefer if their upstream translations would be locked in Launchpad so that it is impossible to change them. Of course people should still be able to extend existing translations by translating new strings (though we would prefer if they did it upstream) but should not be able to touch any translation that has been checked-in upstream.

The reasons:
- Downstream translators often don't know about policies of the upstream language teams and many teams have a very strict review system
- Upstream teams get bug reports about strings that are correct upstream but have been changed in launchpad
- Duplicate work for translators
- Importing stuff from launchpad (which is not easy anyway) becomes even more difficult when strings have to be merged.

[Daniel Nylander (yeager)]

+1

[Arangel Angov (arangel)]

This has been a big problem for Macedonian also. Even some of the stuff that were corrected back in GNOME 2.14 (Upstream) are still wrong in Launchpad. The translation teams are not going to be very efficent when they have to go and fix stuff in two places, instead of only in Upstream.

[Jorge González (jorge-gonzalez-gonzalez)]

+1 from Spanish GNOME translation team.

[Jonathan Ernst (jonathan.ernst)]

The French GNOME translation team has the same problem.

Luckily the leader of the Ubuntu French translations put in place some rules (available on their wiki) telling Ubuntu translators to not touch GNOME, KDE, etc. translations and to concentrate their efforts on Ubunut specific packages.

However we still have from time to time to manually revert changes made by people who didn't read these rules ; this is really annoying, makes us loose time and sometimes give a bad impression to Ubuntu users when translations have been borked.

[wouter bolsterlee (wbolster)]

The upstream Gnome-NL (Dutch) team supports this proposal as well.

[Gil Forcada (gilforcada-deactivatedaccount)]

+100

[Jonh Wendell (wendell)]

+1 from Brazilian Portuguese GNOME translation team!

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

Hi Johannes, Daniel, Арангел. We are aware of the position of upstream teams (not surprisinly, since I am involved in "one" myself :), but there are many problems which are technicaly not trivial.

Let me go through Johannes' points.

- Downstream translators often don't know about policies of the upstream language teams and many teams have a very strict review system

This one is true, but not really a problem of Launchpad as a tool. It's a communication problem: translations in Launchpad are sometimes too easy, and potential translators and team coordinators don't bother with actually establishing policies. Until Launchpad gets AI, it's just a PO editing tool like any other. We've got privilege system in place, but problems arise if people misuse it (as they have done numerous times, allowing everybody into translation teams).

Also, there's another reason. Many different localisation projects for the same language have differing terminology. For example, I know Serbian GNOME and KDE translation teams have different terminology. I see no reason for Ubuntu Serbian l10n team not to unify these translations and make them consistent accross Ubuntu. Yeah, I'd prefer it if they've used GNOME translations because that's where I am coming from, but I'd still prefer consistency over insisting on the "Serbian GNOME terminology". So, one important point here is that this is not a translation of GNOME, it is a translation of GNOME in Ubuntu, which is not exactly the same piece of software (only slightly changed, compared to relative size of GNOME, but changed nevertheless).

Now, I understand that in practice we've more often than not came into a situation where this technical ability has allowed translations of subpar quality to enter Launchpad and Ubuntu. That has happened a lot in the past because of the communication issues, but should happen less nowadays.

So, we're confronted with two options: consider upstream translation teams the only trustworthy source of translations (basically disallowing the option of doing any creative translation work in Launchpad, across entire sphere of Ubuntu software), or improve the trustworthiness of current Launchpad translators. We have so far decided to work on enabling better translator education in Launchpad through review and changed-in-LP workflows. However, Launchpad itself still doesn't provide enough means of communications between translators, and there's nothing that can replace communication. Launchpad is still a tool, and as such, it can't replace the communication needed between people. As a proof of that, I can point you at teams which are handling this process fairly well.

In practice, I am completely aware that you are right: majority of downstream translators are unaware of the policies upstream teams have, nor do they have their own policies. That's why we are considering different options for solving this, and that's why we've added the changed-in-LP filter and easy reversion process (and are looking into implementing reversion of entire PO file at once: https://blueprints.edge.launchpad.net/rosetta/+spec/revert-translation-to-packaged).

Another option we are considering is locking a certain...

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

Also, we are hoping to improve communication on Ubuntu side of things. That will involve establishing an Ubuntu translation coordinator position, who'll be in charge of setting up teams and teaching team leaders how they should run their teams. If any of you are at the same time active Ubuntu users and want to help Ubuntu with that (and I know most of you personally, and have full trust in you), we'd be more than happy to consider you for the position. :)

[Ignacio Casal Quinteiro (nacho-resa)]

+1 from Galician Gnome team.

[Djihed (djihed)]

+1 from the Arabic team.

Danilo, it seems to me that, in part, you are trying to solve a technical problem via a social solution.

For some of us with stretched resources, there is simply too much overhead to try and coordinate with so many distributions, ubuntu being only just one. I don't like the idea of pushing some work (be it even communication) over upstream coordinators.

You're referring to many ways of partial solutions to some of the points addressed in the report. Most of which involve us fiddling with Rosetta/Launchpad. I do understand the need for Canonical to push LP and tools forward, but it shouldn't be at the expense of the coordinators time.

While the "communication" route can be a temporary solution (in the same sense as a hack in code), finer control over locking translations should be the way to go. E.g . Ubuntu wants some strings to be "creatively translated" ? fine, mark those for translations, but lock the rest and let me forget it about it.

I'm glad I see some (albeit unclear) intention in having that, but I'm not quite sure.

[Djihed (djihed)]

I will also respond in particular to this:

"Since we can't accept the simple solution of disallowing Ubuntu translations through Launchpad (which is basically what you are suggesting), we are looking at other options of improving experience for both Launchpad and upstream translators."

Why you want to mark already translated strings coming from upstream for translation again in Ubuntu, I will never understand.

I think you seriously need to re-evaluate whether this is really important for Rosetta, and whether it is worth the headache for us upstream translators.

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

Djihed, please look through my comment. Fine-grained locking over the messages is technically very hard at the moment. We're slowly going there, but it's impossible to do so many major changes to the system in a short period of time.

We also don't want to force communication on upstreams, but rather on Launchpad translators who are currently not doing enough of it. If they communicated with you, we'd all have much better translations, and we'd be a very happy bunch.

[Johannes Schmid (jhs.schmid)]

Hi Daniel!

First, I never intended to say that you would want to harm any project/translation by purpose. But as you can see from the reply of 9 translation teams, this is a real practical problem. And Ubuntu is the only of various distributions that causes such problems though it's of course also the most widespread one.

In detail:

- This one is true, but not really a problem of Launchpad as a tool. It's a communication problem: translations in Launchpad are sometimes too easy, and potential translators and team coordinators don't bother with actually establishing policies. Until Launchpad gets AI, it's just a PO editing tool like any other. We've got privilege system in place, but problems arise if people misuse it (as they have done numerous times, allowing everybody into translation teams).

Please fix this ASAP (and the hard way as we dicussed yesterday on IRC). And it would also be nice to point people to the upstream teams because otherwise they will never know about their existance. It's usually better to help upstream in case you don't do Ubuntu-specific work. People SHOULD know that.

- Also, there's another reason. Many different localisation projects for the same language have differing terminology. For example, I know Serbian GNOME and KDE translation teams have different terminology. I see no reason for Ubuntu Serbian l10n team not to unify these translations and make them consistent accross Ubuntu. Yeah, I'd prefer it if they've used GNOME translations because that's where I am coming from, but I'd still prefer consistency over insisting on the "Serbian GNOME terminology". So, one important point here is that this is not a translation of GNOME, it is a translation of GNOME in Ubuntu, which is not exactly the same piece of software (only slightly changed, compared to relative size of GNOME, but changed nevertheless).

This is something the different translation teams should take care of. Anyway, I don't like that Ubuntu makes it's own policies here. Upstream project have usually though very long about certain terms and if there is a difference between the KDE and the GNOME policy it should be resolved between those and not in Ubuntu.

- So, we're confronted with two options: consider upstream translation teams the only trustworthy source of translations (basically disallowing the option of doing any creative translation work in Launchpad, across entire sphere of Ubuntu software), or improve the trustworthiness of current Launchpad translators. We have so far decided to work on enabling better translator education in Launchpad through review and changed-in-LP workflows. However, Launchpad itself still doesn't provide enough means of communications between translators, and there's nothing that can replace communication. Launchpad is still a tool, and as such, it can't replace the communication needed between people. As a proof of that, I can point you at teams which are handling this process fairly well.

I know that there are teams where this works well (hardly heard of problems in gnome-de for example). Anyway, no to trust upstream translations is very unfair. I doubt that there are many places where the upstream translation ...

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

Hi Johannes,

Today at 13:12, Johannes Schmid wrote:

> First, I never intended to say that you would want to harm any
> project/translation by purpose. But as you can see from the reply of 9
> translation teams, this is a real practical problem. And Ubuntu is the
> only of various distributions that causes such problems though it's of
> course also the most widespread one.

Unfortunately, it's not the only one. I've heard similar complaints
about at least SuSE.

> Please fix this ASAP (and the hard way as we dicussed yesterday on IRC).
> And it would also be nice to point people to the upstream teams because
> otherwise they will never know about their existance. It's usually
> better to help upstream in case you don't do Ubuntu-specific work.
> People SHOULD know that.

Searching for 'translating ubuntu' leads me to the following page:

  https://wiki.ubuntu.com/TranslatingUbuntu#head-237425e48b4c2f6a6a7ef45204ac72183858ea2c

What is said there is

  "Join the team you are interested in, but take care that it's more
  QA team than just a translation team. You don't need to join a team
  to translate Ubuntu, only to improve already existing translations."

This might not be clear enough, so we will work on improving this
further. However, I am pretty sure most people won't even hit this
page, so I don't know what's the best solution to educate people.

> This is something the different translation teams should take care of.
> Anyway, I don't like that Ubuntu makes it's own policies here. Upstream
> project have usually though very long about certain terms and if there
> is a difference between the KDE and the GNOME policy it should be
> resolved between those and not in Ubuntu.

Agreed to an extent. However, we are not going to design something
which stops people from being creative and patching entire set of
translations. If they want technical aid to stop them from doing that
by mistake (which is what's happening now most of the time), we'll
provide that.

> I know that there are teams where this works well (hardly heard of
> problems in gnome-de for example). Anyway, no to trust upstream
> translations is very unfair.

Please re-read what I've said. I said 'consider upstream teams the
only trustworthy source'. I wasn't at any time debating whether one
should trust upstream teams, because that's considered a given. I was
debating whether they are the only one (and I think they are not).

> I doubt that there are many places where
> the upstream translation of a string is significantly worse than the
> launchpad one. So, I still do not understand why you would need any
> "creative translation work". It's good to extend exisiting translations
> but no use to change them other than in an Ubuntu-specific way.

I am not saying we need them. I just don't see a reason to design a
tool to disallow it.

> - Also, I am pretty confident that an easy fix for many translation
> teams would be a simple option: make packaged translations automatically
> override LP-provided translations. However, that might also remove bug
> fixes, so it's hard to enable across entire Launchpad right now. I know
> you want bug fixes to happen upstream first, but ...

[Arangel Angov (arangel)]

"Solving that problem will take a while, and as soon we are able to do that, I am sure we'd be happy to add "lock to Ubuntu-provided messages only"."

Данило,

This would be a perfect solution (at least for my language) because the same two and only people that are working on the GNOME translations are also working on Ubuntu. In this case The GNOME translation team = The Ubuntu translation team. We'd love to see this implemented as it's pretty frustrating now, having to go and fix or import translations that are already fixed and ready in upstream.

As a long term solution, it would be great to see Canonical act on some of the concerns that the GNOME translation teams have at the moment.

Btw, is there a bug report about the particular feature mentioned above?

Thanks.

[Johannes Schmid (jhs.schmid)]

Hi Danilo!

(I try to answer by mail as I guess Launchpad might support this...)

Am Dienstag, den 05.02.2008, 14:40 +0000 schrieb Данило Шеган:
> What is said there is
>
> "Join the team you are interested in, but take care that it's more
> QA team than just a translation team. You don't need to join a team
> to translate Ubuntu, only to improve already existing translations."
>
> This might not be clear enough, so we will work on improving this
> further. However, I am pretty sure most people won't even hit this
> page, so I don't know what's the best solution to educate people.

I think it's not very clear apart that only few people will be reading
it anyway. Sorry, but I can't say where a good place to add this info is
as I never used launchpad for translations.

> Agreed to an extent. However, we are not going to design something
> which stops people from being creative and patching entire set of
> translations. If they want technical aid to stop them from doing that
> by mistake (which is what's happening now most of the time), we'll
> provide that.

IMHO, people should do their creative work upstream or at least push it
upstream. Though I don't like the work "creative" in this context, as
there are only good or bad translations.

> I am not saying we need them. I just don't see a reason to design a
> tool to disallow it.

Why allow something where there is no need?

> Afaik, Ubuntu is not that slow at all. The problem is that we give
> priority to corrections done in Launchpad, and we can easily
> reconsider this.

I don't know how the Ubuntu system works but it still ships anjuta 2.2.0
while the upstream version is 2.2.3. But this is going to be off-topic.
(But see recent posts on planet.gnome.org)

> That would mean that any new package uploads in Ubuntu would refresh
> current translations with upstream provided ones, if a translation
> team chooses to use that option. However, that can happen next month
> at the earliest (and I am not making any commitment yet, this has to
> be discussed within the team), because, even if a simple change, it
> will involve changes to the core piece of our code, thus needing a lot
> of testing.

Would this be language-wide or could you implement this based on package
sets? Because I guess no language will be willing to check this as a
global option but rather for good-maintained package-sets
(GNOME/KDE/freedesktop).

> Doing this will, of course, limit our time on other interesting things
> we can work on, but I am sure GNOME as an upstream doesn't really care
> about that.

I think you are wrong here as most people really take care on the
end-user. I cannot speak for GNOME (not even for gnome-18n, you are the
spokesman ;-) but there are lots of interesting things I would like to
see in Ubuntu/launchpad.
Anyway, lets consider this won't be in place for hardy (= GNOME 2.22).
That's no problem as most of the big problems could be solved by
team-reorganizations. But would it be possible to to implement the
"overwrite" policy (instead of a "lock" policy) for Hardy + 1 (= GNOME
2.24)? Personally I think that would be a reasonable time-frame for
testing, getting feedback, discussing on GUADE...

[Jan Claeys (janc)]

The Ubuntu-NL (Dutch) translation team supports this proposal as well (and we and other Ubuntu translators have asked for this several times in the past).

Why don't you trust the Ubuntu translation team administrators to decide which translations to use/prefer for their language? Most local teams do have contact with upstream translators, and will be happy to work together with them (at least, I want to), but currently it's not possible due to Launchpad having only a very limited access control (every translation team member can edit every single translatable string, everybody else can't translate anything). So we have two choices: problems/accidents with upstream translations will keep happening, or no translations will happen at all, even for Ubuntu-specific translations (which makes Launchpad's translation interface obsolete).

BTW:
> We've got privilege system in place, but problems arise if people misuse it
> (as they have done numerous times, allowing everybody into translation teams).

You forget to tell that allowing everybody in was the default for a very long time (years!), so don't blame the translation teams for that, they often didn't even formally exist before taking over such an open "team" and locking it...

[TLE (k-nielsen81)]

>> That would mean that any new package uploads in Ubuntu would refresh
>> current translations with upstream provided ones, if a translation
>> team chooses to use that option. However, that can happen next month
>> at the earliest (and I am not making any commitment yet, this has to
>> be discussed within the team), because, even if a simple change, it
>> will involve changes to the core piece of our code, thus needing a lot
>> of testing.
>
>Would this be language-wide or could you implement this based on package
>sets? Because I guess no language will be willing to check this as a
>global option but rather for good-maintained package-sets
>(GNOME/KDE/freedesktop).

I think this is a really good solution. I agree with Johannes that it would be a good idea to enable this feature based on some package-sets, essentially they should probably be based on upstream source i.e. one for GNOME upstream and so on, but that's all details which can be worked out later.

>> Doing this will, of course, limit our time on other interesting things
>> we can work on, but I am sure GNOME as an upstream doesn't really care
>> about that.
>
>I think you are wrong here as most people really take care on the
>end-user. I cannot speak for GNOME (not even for gnome-18n, you are the
>spokesman ;-) but there are lots of interesting things I would like to
>see in Ubuntu/launchpad.
>Anyway, lets consider this won't be in place for hardy (= GNOME 2.22).
>That's no problem as most of the big problems could be solved by
>team-reorganizations. But would it be possible to to implement the
>"overwrite" policy (instead of a "lock" policy) for Hardy + 1 (= GNOME
>2.24)? Personally I think that would be a reasonable time-frame for
>testing, getting feedback, discussing on GUADEC, etc.

I agree with Johannes on both points.

On another note. You guys were talking earlier about how to get information out to the masses. May I suggest that this feature is made in such a way, that when a user enters the translation page for a package, which is one of those that have strings that will be overwritten, then the first thing that he sees is a big red flashing warning-light. This warning should explain that if he wants to contribute to this package, he should first translate any remaining strings upstream after coordinating with the upstream team (contact information and so on should be given) and then after the complete upstream translation has made it into LP then he can translate any remaining strings added by Ubuntu specific patches in LP, if such strings exist.

This would not only help to better explain the "best" way to contribute but would also make sure that any volunteers that come in from the Ubuntu community is properly greeted and not left not knowing how to proceed if they want to contribute.

Regards Kenneth Nielsen

[Andre Klapper (a9016009)]

[i want to CC myself without adding a comment. obviously this is not possible. great. sorry for the noise.]

[Matthew Paul Thomas (mpt)]

[Andre, CCing yourself is indeed possible without adding a comment. If you can remember what led you to think it wasn't possible, please report that as a UI bug. <https://bugs.launchpad.net/malone>]

Adding language-and-software-specific translation guidelines is bug 3, and defaulting to showing untranslated strings rather than all strings (which would be better than asking translators to switch to that view themselves) is bug 177919.

[Johannes Schmid (jhs.schmid)]

Hey, why is this invalid? Parts are duplicated of bug 3 and bug 177919 but that's not all!

[wouter bolsterlee (wbolster)]

Indeed, this is not solved at all.

[wouter bolsterlee (wbolster)]

Oops, seems it was only marked "invalid" for Launchpad itself. It remains an issue for "Launchpad Translations". Reverting my previous revert ;)

[Jan Claeys (janc)]

Defaulting to showing untranslated strings won't help much, as many translations in launchpad are outdated compared to upstream, and there is no decent procedure for translation teams to update or diff them.

Why can developers decide when & how to sync or upload new versions, while translators or translation teams aren't?

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

Marking as a "duplicate" because I've figured out a way to do this properly for a majority of use cases and described it in a more concrete bug: see bug #255665 (marked as High priority so we get to it RSN). Basically, I believe net effect will be exactly what you want: translations from packages (~upstream) will have precedence over ones in Launchpad when there was no previous translation from a package. Only intentional changes by Ubuntu translators will remain, but that's what's actually desired.

The two other missing components are going back to a suitable state (i.e. reverting all unneeded changes), and solving the Ubuntu translators organization. Ubuntu side of things is on-going already, Arne Goetje is in charge of Ubuntu Translation Group, and should be helping organize everything so teams start having reasonable policies.

As for reverting translations changed in LP, we've got a separate task for that: https://blueprints.edge.launchpad.net/rosetta/+spec/revert-translation-to-packaged (also High priority). This will allow easy reversion of an entire PO file, and after the two LP tasks are done, you should not expect any more problems with changed translations in LP. You might want to subscribe to that spec as well to fully track the progress of solving the problem described in this book^Wbug report. (You should automatically be subscribed to the other bug, which is why I am marking this a duplicate; if that's a problem, I apologize)