Degree of trust and quality for Ubuntu Localization Teams

[Khaled Hosny]

On Wed, Jul 08, 2009 at 12:24:31AM +0300, Adi Roiban wrote:
> Hi,
> 
> During the last UDS we have talked about various reasons why people
> blame Ubuntu translations.
> 
> This is a long email, but I think that the raised issue is very
> important and it is fundamental for the way in which Ubuntu translations
> are perceived by users, developers and other/upstream translators.
> 
> One of the cause is the due to the fact that for some languages everyone
> (whether he/she knows or not the language) can submit a translation and
> that translation will land directly in Ubuntu. They can also
> delete/modify translations coming from upstream projects.
> 
> This can happen for Ubuntu Localization teams that use an open policy
> for membership, or for teams that does not check whether or not the new
> members are able to assure the translations quality.
> 
> I would like to note that the main goal of Ubuntu Localization Teams is
> to assure that quality of translations. Everyone is free to suggest
> translations and suggesting translations for Ubuntu is not limited to
> member of those teams.
> 
> This email was triggered by an incident occurred in the Ubuntu Slovenian
> Team where one of the team members was submitting approved translations
> for Slovenian but they were in fact Russian translations (using latin
> alphabet).
> 
> >From my point of view membership of Ubuntu localization teams should be
> moderated and before approve a new member, the team coordinators will
> have to take the requires measurement to make sure that person is aware
> of hes/her role in the team and the team's commitment to quality.
> 
> We can also go further and follow the model used for LoCo teams and have
> approved and unapproved localization teams. And approves teams would be
> the one able to assure a minimal degree of quality.
> 
> I know there are pros and cons for opening or moderating a team, but I
> think that all Ubuntu Localization teams should be moderated and have at
> least one active member willing to moderate new members, assure the
> translations quality, and be the spoke person for that language inside
> the Ubuntu community.
> 
> Below is a list of team with open membership policy. 
> I am aware that all translations are base on voluntary work and everyone
> is helping as best as he/she can.
> My intention is not to blame a person or a team, but I think that we
> should try not to ruin the work of other people.
> A bad translation could fail an application from starting, or it can
> confuse the user or lead to erroneous actions. 
> 
> The main questions: 
> 1. What do you think?
> 2. Should we moderate membership for localization teams and implement
> some minimal quality checks or we should have open team without any
> quality assurance measures?

I totally agree with this, we had this before in Arabic (the team was
open) and we ended up with the worst Gnome translation, despite all
incremental improvements upstream.
We ended up (after passing team ownership to new one) with a moderated
team, with only few members, and who is welling to contribute do so by
suggesting translations and another team member will review and accept
it.

I'm all with having moderated teams by default, it doesn't make any
sense to have open teams at all. From my experience, translation isn't
an easy task, and well-intended but ill-informed volunteers usually get
it all the way wrong, ranging from linguistic to technical mistakes. And
some team owners don't even care about this, since, unlike many upstream
teams, whoever applies for a team first get it without any attempt
qualify him (compare with Gnome for example).


Regards,
 Khaled


-- 
 Khaled Hosny
 Arabic localiser and member of Arabeyes.org team
 Free font developer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <https://lists.ubuntu.com/archives/ubuntu-translators/attachments/20090708/9f0fa79c/attachment.sig>