Ensuring Quality in Ubuntu Translations

Carlos Perelló Marín carlos.perello at canonical.com
Tue Oct 31 20:06:19 GMT 2006


El lun, 10-04-2006 a las 19:14 +0100, Matthew East escribió: 
> Sorry for the length of this email, I kinda wrote it as a blog post so
> it's a bit more wordy that I'd like.

Hi,

I know this thread started a while ago... but my pending mail from
rosetta-users mailing list is a bit... out of control...

First of all, thanks for this email.

> 
> An interesting discussion on the #launchpad irc channel yesterday has
> been making me think about the question of quality assurance for Ubuntu
> translation teams. To put the question into context, this is how the
> discussion arose:
> 
> An upstream GNOME translator for the Dutch language mentioned that often
> there are complaints on their mailing list about the quality of
> translations of the GNOME desktop environment for Ubuntu. He says that
> these flame wars are particularly irritating given that the translations
> complained of are not made by GNOME translators at all, but are
> introduced by the Ubuntu translation team, overwriting the upstream
> translations. One of the Ubuntu translation team joined the
> conversation, and it became clear that there was very little QA going on
> to ensure that the members of the Dutch team are (a) good translators,
> and (b) familiar with the GNOME and other upstream translation
> guidelines.

Agreed, we need to do something to improve this situation.

> 
> Thanks to the two Dutch guys who made a lot of good points, some of
> which I've stolen in this post.
> 
> This is a topic which has particularly interested me recently because
> the Italian translation group has been debating this question over the
> last few months, and has evolved a quality assurance technique to try
> and prevent this problem from happening. Also, I think this problem is
> not just with the Dutch team, but is likely to be common. I'd be
> interested to hear whether anyone else has experienced problems like
> this.

Spanish team has exactly the same problem.

> 
> Basically, my view is that the blame for this problem lies partly with
> Rosetta, and partly with the translation teams themselves. In reverse
> order:

Well, initially, Rosetta was designed to use teams in a really different
way we are using them atm. The concept of an Ubuntu translation team as
we have atm is just a QA team. That means that, only the members of that
team would be able to change translations for Ubuntu and any other
member would add suggestions but they wouldn't change anything.

The problems I think that produced current situation are:

- Our reviewing tools are reduced or unimplemented.
- Our UI is not stating anytime that those teams are supposed to be QA
teams.
- Our documentation is not saying anything about the QA concept either.


I want to improve this situation and, with our current usage of Rosetta,
I know that people needs the concept of 'team' to know the list of
persons that are translated for a given distribution/project/product and
language.

There are several solutions in my mind:

- Create two teams, ubuntu-l10n-XX (current ones) and ubuntu-l10n-XX-QA
and give control over Ubuntu translations to the QA teams and thus, all
members of current teams will lose their rights to modify translations
directly, they will add suggestions as any other non member would be
able to do.
- Create two teams too, but modify our permission system so we only
accept suggestions from current ubuntu-l10n-XX teams so you need to join
that team to be able to add suggestions. The QA teams are the only ones
that will be able to change translations.

Also, Ubuntu is handling the creation of an Ubuntu Translation
Coordinator to help all teams and apply some common policies to all
Ubuntu translation teams so we can share solutions for QA problems and
have a contact for upstream to solve any future conflicts.

> 
> = Translation Teams =
> 
> The basic starting point is that a central part of the Ubuntu
> philosophy[1] is that software should be available to all in their local
> language.
> 
> [1] http://www.ubuntu.com/ubuntu/philosophy
> 
> In order to achieve this, Ubuntu has given a lot of authority (and
> responsibility) to the various translation teams that exist in
> Launchpad[2]: these teams are responsible for what the operating system
> looks like, because the translations which they enter in Rosetta will
> eventually go into the operating system.
> 
> [2] https://launchpad.net/people/?name=ubuntu-l10n&searchfor=teamsonly
> 
> This is a lot of responsibility for the translation teams. It is clear
> that randomly accepting any new member to a team can result in bad
> translations. It seems that in the case of the Dutch team it has had
> really bad consequences. I refuse to believe that this problem doesn't
> exist elsewhere. For example, the Ubuntu French translation team has 250
> members (and 1 administrator to approve/disprove new candidates!!), the
> German team 86, the Brazilian team 78, etc. It's difficult to imagine
> that these members have all been through some kind of quality assurance.

Agreed.

> 
> Upstream translators on the other hand _do_ go through rigorous quality
> assurance. Translations are uploaded to (e.g. GNOME) CVS if the
> translator is already well known for good quality translation, or
> alternatively if the individual translation is checked first.
> 
> So how can Ubuntu translation teams do similar quality assurance? This
> is where teams should share their experiences, in my view. So here is
> what the Italian team does:
>  * When a new member applies to join, he's asked to join the mailing
> list and write a mail of presentation
>  * In order to be admitted to the group, the member goes through the
> following (relatively informal) process: 1. sign the code of conduct, 2.
> create a wiki page on the italian wiki with contact details, 3. read the
> upstream translation project guidelines, and the GNOME translation
> guidelines, 4. begin translating in rosetta by submitting "suggestions".
>  * When the proposed member has done #3 above, an existing member of the
> group checks the suggestions the proposed member has submitted. If they
> are ok, the proposed member becomes a real member.


That's a nice procedure, I think others should follow it too. Also, with
the new UI interface we are developing for translate, the review process
should be quite fast now (it's being reviewed right now, it should land
quite soon).

> 
> Now, this process may not work for every team. Some teams have lots of
> people, others not so many. Equally, this process is by no means perfect
> (I'd be very interested to hear what other teams do). It's up to each
> team to figure out what quality assurance system works for them.
> However, a quality assurance system IS necessary, if the problems like
> those experienced in the Dutch team are to be avoided.
> 
> What concrete proposals could assist here? I'd suggest that some common
> "translator group guidelines" would do some good. But it's a very big
> job to "reform" existing groups, both in terms of the amount of work,
> and the delicacy of the social problems (it's important to get the
> balance right between encouraging inclusive participation, and quality
> assurance). However, if groups set up well thought out mechanisms for
> quality assurance, I feel convinced that it is a job which can be
> successfully carried out.
> 
> = Rosetta =
> 
> There are lots of ways in which Rosetta can and should help this QA
> process, in my opinion. They are all fairly well known bugs, I think.
> But they are important ones.
> 
> The first is technical. It is not nearly as easy to check a proposed
> member's translations as it should be. This is a oft-cited bug in
> Rosetta. It should be possible to go to a person's profile, and view
> each suggestion that person has made for a translation. At the moment,
> it is only possible to view which template the person has contributed
> to, and then you have to go through all the untranslated strings for
> that template, and look for the person's name. Not very convenient.

Hmm, We are preparing that page to link with pofiles instead of just
potemplates but I guess we could prepare something like what you
describe.

Filed as https://launchpad.net/products/rosetta/+bug/69563

> 
> The second is technical too. You can't search a package for a particular
> string, which means that if you see a bad translation, it's harder to
> fix. Worse than that, once a translation is committed, there is no
> obvious way of seeing who committed the translation, so people who are
> not following guidelines cannot be approached to discuss the problem.
> 

The search feature is already in danilo's queue and will be started once
he finish native OO.org support.


About the info about who committed a translation is now visible.

> 
> The third is technical and social. It would be a bad thing to make
> upstream translations take precedence over Ubuntu translations (because
> then it would be impossible to correct mistakes upstream, or alter a
> translation where the context is slightly different in Ubuntu), but most
> of the problems are caused by the fact that upstream translations are
> not currently imported quickly enough into Rosetta. This results in
> Ubuntu translators translating strings which they otherwise would not
> touch, if the upstream translations were already there. Earlier
> importing of upstream translations would save much of the pain that
> Dutch Ubuntu users have experienced, I'll guess. (The social aspect of
> this is that Ubuntu translation teams should AVOID translating until
> they know that all upstream translations have been imported).

Well, this one is hard to 'fix' in a perfect way. As a workaround, we
are going to add tools to allow easy reverting of translations to
whatever upstream has or a way to filter messages to see just the ones
that are different from the ones in upstream.

https://launchpad.net/products/rosetta/+bug/60029


> 
> 
> The fourth is purely social. The main reason that translation groups
> don't do QA is that they are not aware of this need. Given that Ubuntu
> has given the translator groups this immense responsibility, it is their
> duty (and by implication, that of Rosetta/Launchpad) to make them aware
> of it. New teams and team owners/administrators should be made aware of
> the importance of assuring quality translations in the distribution. The
> other reason that Rosetta needs to take on this social task is that
> Rosetta really does make translation very very easy indeed, which rocks.
> However, it's vital to ensure that "easy" doesn't equate to "sloppy".

I think this part would be solved by the Ubuntu Translation Coordinator
position in Ubuntu. Once the designated person starts handling those
tasks we would see what could we do in Rosetta to make his/her live
easier.

> 
> = Conclusion =
> 
> My conclusion is that Rosetta helps to go half way towards fulfilling
> the promise in Ubuntu's philosophy of making the operating system
> available to users in their local language. However, now for the hard
> bit: making the operating system available to users in their local
> language and _professional_ at the same time. In order to do this,
> translation teams need to put quality assurance in place and Rosetta
> needs to help them to do this.

Agreed. We, Rosetta team, is trying to reach that point, it takes a lot
of time to implement everything needed, but I think we are every day in
a better position to reach that goal.

Thanks for your input.

Cheers.
> 
> Matt
> -- 
> rosetta-users mailing list
> rosetta-users at lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/rosetta-users
> Learn more about Rosetta: https://wiki.ubuntu.com/Rosetta
-- 
Carlos Perelló Marín
Ubuntu => http://www.ubuntu.com
mailto:carlos.perello at canonical.com
http://carlos.pemas.net
Alicante - Spain
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada
	digitalmente
Url : https://lists.ubuntu.com/archives/loco-contacts/attachments/20061031/11ca9831/attachment-0001.pgp 


More information about the loco-contacts mailing list