Re: Fedora and Translation Teams

[Christian Rose <menthos at menthos dot com>]

fre 2004-06-25 klockan 19.18 skrev Sherif Abdelgwad:
> First, I am just a stating *my own* openion here and it is 
> not *fedora* openion or redhat.

Certainly. I believe everyone here is aware that people are usually
speaking for themselves, without any particular hat on, unless otherwise
stated.


> I am getting confused and lost in the long emails. Can Mohamed or
> Youcef please explain in short email, in points : what are the
> problems as I failed to follow all long emails here. I do not
> see any changes in the policys, the only thing happened was
> to prevent multiple translators committing changes at same time.

I think reading the long detailed mails is a good thing; they explain
quite a lot of background, which the heated flamage mails don't.

Anyway, I think everyone agrees that avoiding translation conflicts is a
good thing. It's not really that which is causing the debate. The point
is in *which way* this is achieved. Traditionally, translation projects
are communities where volunteers join seperate language teams to produce
translations, and in this work the teams naturally also arrange these
issues for themselves and arrange who works on what and so on.

In Fedora, language teams are right now bypassed completely by the
organization, so that each contributor by default just works for himself
or herself, thus eliminating all benefits of teams. Teams are not
mandated nor encouraged by the process, which many experienced
translators seem to believe is a serious mistake.


> I went through Mohamed email and I am not sure where all these
> issues came from? 
> 
> I belive that by people establish teams here, things will be
> start to shape and take better form. Let me ask first, 
> when Arabeyes started translation, did they have full list
> of things how it should be? Things are still being built and
> taking final shape. I belive in the freedom of allowing 
> people to contribute. 

Certainly, so do we all. The key issue here is: when would the teams
take shape, and what would those teams look like? With the new Fedora
translation status pages, where anyone can contribute without ever
discussing anything with anyone else, the concept of teams aren't
mandated nor even encouraged.

Allowing anyone to contribute right away without discussing with anyone
may sound like a nice idea in theory, but it is usually in practice
totally orthogonal to the idea of producing coherent, good quality
translations. To have that, one must first cooperate. There's no magic
way around that. And to get that, you must first mandate or at least
encourage volunteering translators to join teams.

Also, there's no way for someone else not fluent in the language to
decide whether particular translations are good or bad. Thus, you
usually have to ask the translators for that language as a group to have
that question answered. That means teams. So no matter how you design
your translation organization, you usually can't get around the concept
of teams, at least not if you care squat about quality assurance.


Thus the heated debate: The concept of community translations of Red Hat
Linux or Fedora Core is not new, so there are long-time contributors
that have already formed successful language translation teams for many
years, producing 100% complete translations for [insert divinity] knows
how many releases. Some of those teams are large, some teams are
smaller, but they are usually all quite experienced.
Enter today where these existing teams are suddenly completely nullified
by the Fedora translation status pages, which ignore them completely.
Then perhaps you can understand why people are annoyed, when they have
the successful teams they've built up and contributed with in the past
now being completely ignored.

Granted, these existing Red Hat/Fedora community language translation
teams weren't really tracked before. They weren't really official; Red
Hat just tracked individual contributors and hoped that these should
organize themselves some way. Which is also what happened. Unofficial
language teams were formed out of registered community translators, and
were successful in producing Red Hat translations and later Fedora
translations.
So, would we be again at that point in time at the birth of the project,
I would agree with you that we would just need to wait and see
translation teams form.

But we aren't. For many languages, there is already organized and
successful teams that have already been dealing with this for many
years. Bypassing and ignoring the existance of them, be it accidentally
or intentionally, is like throwing the baby out with the bathwater.


> The main goal I see here is to provide traslation. Is the 
> translation provided by certain people will be final and
> for good? I doubt! To establish a translation first is the
> first step. I belive yet to come a lot of tuning and enhancement.

Certainly. It's just that to have help and feedback from other
translators they must know about your work and be able to review it,
preferrably in good time. With the current system, some random person
could commit a babelfish-quality translation without other translators
fluent in the language (the "team") knowing about it or catching it in
time.


> I am not aginst keeping things the same across all modules, 
> and similar to other translations. For sure will be great
> to have team like Arabeyes team to contribute. Yet, why
> assuming anyone else who would like to contribute would
> cause a mess because s/he decided not to be part of Arabeyes. 

I can't speak for Arabeyes, but there's nothing magic about most teams.
They're not a secret, closed band of elitist people. Usually they're
quite informal. All it takes to become a "member" of a language team is
often a discussion like this on a language team mailing list:

        A: Hi, I want to translate the X module into LL!
        B: Sure, go ahead. We will note in this LL team that you're
        doing the X translation. Please ask if you have any questions
        and also consider subscribing to our mailing list if you haven't
        already. Also, once you're finished, please send your
        translation to the mailing list so others can try to review it
        and give helpful comments.
        A: Gee, thanks, will do.

If the situation was that all teams were closed gangs of self-selected
arrogant people that perhaps rejected new volunteers or demanded them to
work on stuff they didn't like to, then I would understand your point
that there should perhaps be a way for volunteers to decide not to be
part of a team to participate.

This almost always isn't the situation though. The teams are usually as
informal as could possibly be. They're there so that volunteer
translators for that language know each other and who's working on what
in the project, and can help eachother and review each other's work, and
as a consequence in the end as a team produce coherent translations for
that language.

Thus, I don't understand at all what the benefit would be of deciding
not to join a team, or why the system should encourage that or even have
that as an option. If there's a particular team that isn't as open or
helpful as could be to new volunteers, then it's a problem with that
particular language team, not the concept of language teams per se.


> So, to keep this discussion constructive, can we discuss
> here what are the requirment or the right way someone think
> the system should be ? I had hard time to get clear requirment
> or request. I only found hey this policy is no good, why
> this should be this way. It would be better to be hey
> why do not we have things this way. 

If you ask for my opinion, something like the model used in almost all
other translation projects is the way to go. See my "The GNOME model"
mail which explains how such translation projects often work.

Perhaps not every little detail should be copied, since even those
systems have their problems in details, but an organization
fundamentally built on teams is a must, and also that the system
encourages or mandates that volunteers join the teams first before
committing translations. If you don't have that, you scrap all the
benefits of having the teams in the first place.

Also, each team having a coordinator is often a must. Perhaps you can
live without a team coordinator if the team is only two people, but if
the teams grow larger you often need it. Then you can have someone that
has the final say, should there be an issue in the team where there
needs to be someone that has the final say.
Usually this is not the case, but should there be such a situation the
team will often be able to resolve the issues themselves if there has
been a coordinator assigned in the team. Otherwise the translation
project maintainer may need to step in and decide on an issue he or she
couldn't possibly make a qualified decision on, because it involves
knowledge of the particular language.
And if the team is unhappy with the team coordinator, the coordinator
can always be replaced.
Also, occasionally you will want to get in contact with a team, and if
you have assigned a coordinator, you have an excellent contact person
aswell.


I hope this mail was helpful, even if it was long. Translation itself
isn't rocket science, but it often scales into a very large project with
many volunteers quite rapidly. And dealing with how to best organize
those large amounts of volunteers so that they can cooperate in the best
way possible and produce coherent translations is a nontrivial task,
from which lessons have been learned in the past in other free software
translation projects. We should learn from those lessons.


Christian