Ensuring Quality in Ubuntu Translations

[Matthew East]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

* Carlos Perelló Marín:
> 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...

No worries!

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

{snip}

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

I'm going to disagree with this concept. I think that right now,
building all Ubuntu teams around a QA concept is not going to work, for
the simple reason that people do not have time to do all the QA for a
whole team - we're all volunteers and it's not going to work to expect
1-5 people to consider and approve all translations for a particular
language, while other members of the team contribute suggestions.

I think that the system where there is a whole translation team, the
members of which are all able to commit translations to Ubuntu *can*
work. The QA needs to be done BEFOREHAND - the message behind my
original email in this thread was that teams need to establish good QA
practises for who can become a member of the team, and Rosetta needs to
help provide the tools to enable that to happen.

For example, I'm confident that the system the Italian team has worked
out provides good quality translations, because there is careful QA of
the new members, and good communication between the existing ones. This
will improve even further when Rosetta provides better tools to do that
QA, which is generally done by the team administrators.

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

Yes, I think that is a very good idea.

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

I bet it's really rare that an upstream string needs to be altered. The
upstream strings that are currently altered are probably mainly due to
the fact that there was no upstream translation imported at the time the
Ubuntu translator did their change. I see no problem with a system where
 upstream strings take precedence, or alternatively require significant
intervention to alter.

Matt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFUEtGtSaF0w5rBv8RAj0zAJ949ieAHyYz3Ea0tWzxlpVOs7uaWgCeIEpM
o1AEwLQGOFKKH+F9cmszcDo=
=1GeP
-----END PGP SIGNATURE-----