On Fri, Jun 25, 2004 at 11:04:36PM +1000, Bernd Groh wrote:
DISCLAIMER: This does not represent the views of Arabeyes and are only
my personal views.
> Wow! I am completely and utterly confused now. For the record, the main
> change that has been undertaken is the [Take], [Release] mechanism, that
> is to prevent two translators from comitting at the same time. Can
It also prevents a team to exert control over their language's translation.
> anyone tell me what exactly happened here? *confused* We did not
What happened here is that I have been watching Youcef get ridiculed and
treated as if he is the sole translator of Fedora, and as if he wants
total control of the translation for himself. For your information, Dr.
Groh, this is not the case. There is a large team that stands behind
Youcef. If there are a couple members (some of which are redhat
employees) who feel that Arabeyes is not worthy of translating Fedora,
then so be it. I would personally propose to Arabeyes to drop its
efforts with Fedora and let the chaos ensue.
> introduce any new policy, we merely, as said, implemented a mechanism to
> prevent two translators from comitting at the same time. And one thing I
Read above -- it does more than just prevent two translators from
committing at the same time.
> should mention, since I am not clear whether it is clear or not, though
> it should be, what I am saying here on list is *not* Fedora policy, it
> is *my* opinion. I believe in my opinion and in my right to state it,
> that I've implemented this new system for the Fedora project has
> absolutely nothing to do with it.
And I am telling you that this system is a bad system. You should
consider looking at how other projects have successfully been doing
| Mohammed Elzubeir | Visit us at: |
| | http://www.arabeyes.org/ |
| Arabeyes Project | Homepage: |
| Unix the 'right' way | http://elzubeir.fakkir.net/ |
I saw some posts mention the GNOME Translation Project (GTP) model as a
reference. Some of them seemed entirely correct, some of them while
partly correct also seemed based on slight misunderstandings. I'd like
to take this oppurtunity to clear these things up. If nothing else, this
could perhaps get some insight in how another community translation
There are some more or less defined goals with the model that the GTP
* We want to encourage translators to work together (we call these
groupings "teams"), since this usually means more consistent terminology
and better QA for the translations.
* We recognize that sometimes bad and confusing translations can be
worse than no translation at all, so we want to encourage QA and
contributors working together in teams, which in itself encourages some
level of basic QA.
* We want to encourage new translators to get in contact with their team
right from the start, since the team can help them get started, with
instructions and help in their own language. Also, the teams usually
know what terminology can be used, and the team also usually has some
experience in translating and can help in any question, regarding from
language difficulties to technical issues such as PO syntax etc.
* We want to give the teams some freedom to decide how they want to
organize their own work, since we recognize that no mandated policy fits
every team. Some teams are small, some really big, and some prefer an
open policy, while others a more strict one.
* We want to make sure that no, or very few, conflicts arise, and that
if they arise, they are resolved before the affected translations that
may be results of this are being committed. There's often not many
things that are as counterproductive as conflicts, be they accidental or
intentional. To avoid accidental conflicts, we want the translators to
form teams, one for each language.
* We want to make sure that the ones deciding on the translations are as
much as possible the ones with knowledge in the affected language, and
not other people, such as software maintainers or GTP maintainers. It's
close to impossible for someone not fluent in a language to
differentiate a "good" translation from a "bad" one, so the teams are
the ones to decide, since they have the knowledge of the language.
* At the same time, we still want to make the entry level barrier for
contribution as low as possible.
The GNOME Translation Project (GTP) is divided into language teams. A
"team" can be everything from a single person working for himself, to
many dozens of translators working together. But there can only be one
team for each language at any given time.
Each team should have a coordinator. This is basically in practice just
a title that gets listed together with the team entry on the GTP web
pages. The coordinator for the most part just has to act as a contact
person, so that people from the GNOME side of things has a person they
can contact in case there's a general problem with those translations,
but also so that new volunteers have someone to contact in case they
want to get started translating into that language.
Starting to translate a new language
In the GTP, anyone is welcome to start translating a new language. All
it basically takes is for someone to write to the project mailing list
and say "I want to translate into the X language". Then we'll list a new
X language team on the GTP web pages, with this person as the
coordinator for that new team, and help this person get started.
Starting to translate an existing language
On the GTP web pages, new volunteers are strongly encouraged to get in
contact with their language team and its coordinator in case there
already is a team. If they report that they haven't tried, we urge them
to do so before continuing. The team can then help the volunteer to get
started, and they also know if someone is already working on a
particular translations, things to watch out for, etc.
We also encourage software maintainers to do the same thing, i.e. point
interested translation volunteers to the GTP and their language team¹.
If someone reports that they have failed in getting in contact with the
current team coordinator, either because the mail bounced, or because
the current coordinator didn't respond, we formally give the current
coordinator one week to respond and explain. If he or she hasn't
responded in a week, we appoint someone else that has volunteered for
this position as coordinator for that team.
The coordinator's role
The primary goal for a language team coordinator is to act as a contact
person. However, with the position also comes some level of final say
over the GNOME translations for this language, or other aspects covering
the language team. This is rarely ever needed though, but it helps
avoiding confusion should such situations occur. It's somewhat like the
situation of being the maintainer for a piece of software.
We don't want to allow coordinators to become "dictators" though. If
someone reports that their coordinator is acting in such a way, we urge
the coordinator to explain himself. Should the issues be for real we can
opt to replace the coordinator, but fortunately that rarely happens.
Almost all such cases seem to be based on misunderstandings, and are
solved amicabilly for all parts.
In GNOME, CVS accounts aren't restricted, not even translator ones. This
has both benefits and drawbacks, but one effect is that we are somewhat
more restrictive with giving out CVS accounts. A translator has to
produce some translations before he or she can apply for and have a CVS
account. This usually amounts to a handful of translations or something
like that. We just want to make sure that the person's request is
somewhat serious, and the best way to get a hint on that appears to be
on whether there are already existing contributions.
Also, the team coordinator must approve of the CVS account request for
any member of his team. This is just to ensure that the team knows who
will be committing translations for their language, and help avoid
conflict situations later. We don't want to have potential conflicts
occur in CVS, but rather have them resolved before that point. Also, in
many cases we catch those situations where someone wanted to translate
into a language but completely missed the fact that there is a team that
does this and that he or she could join. Most people appear to be
thankful for getting to know this.
Once the person has a CVS account, it's personal and he or she can use
it for both committing own translations and other people's translations,
usually from the same team. Usually, at least one person in a team has a
CVS account, and with big, productive teams there can be many in the
same team that have access, and so the team as a whole can also help
committing the translations of new members.
Obviously, no system or model is perfect. One area that we have
recognized is that there is a possibility for a coordinator to abuse his
or her situation. Fortunately, this rarely occurs, since most
translators appear to be sensible people. And when it happens, we
usually get to hear complaints about it, and can have an open discussion
on how to solve it. Often the teams solve any such issues themselves.
There are some drawbacks I see with this model myself. First of all, the
barrier of entry is not as low as it could be. It takes some mailing to
get started: Subscribing to lists and getting contact with the
potentially already existing team. Even worse when a coordinator or
other people in the team should happen to not be reachable anymore; then
the new volunteer must also report that before the situation can be
However, most translators seem to agree that the benefits outweigh the
drawbacks. The benefits is the strong team community and team
cooperation, and the encouragement for QA and terminology consistency
built into the system.
Also, since the teams usually gather experience with time, there is also
a mentorship aspect, as older team members can help novice translators
get started and also help later on, and this with instructions in their
own language, a help which can be quite valuable. Usually all of this
adds together, so that the whole translation becomes becomes like an
ecosystem of its own, with the contributors in the seperate language
teams getting more experienced, helping new ones get started, and then
the new ones grow "old" one day and can help new ones, and so on, so
this ensures a continuity effect that is most interesting and I believe
also very beneficial to the project.
So this is one model for organizing translators, and I believe that it
is close to identical with the translation projects of many other big
projects, such as KDE, Mozilla, OpenOffice.org or the Translation
Do I consider this model perfect? Obviously not. It has its drawbacks.
But I don't think ignoring or downplaying the issues a model like this
tries to solve is a good thing to do when organizing a new translation
project. Also, I think the issues should be taken into careful
consideration when designing a fundamentally different approach, since
there is a substantial danger of just reexperiencing all the problems
others has had before before they learned from it.
¹ I have even written a template that many GNOME software maintainers
can opt to use to point new translation volunteers in the right
This is intended to all translators involved in Fedora, whether they are
involved for Arabic or any other language. It is also intended for the
people who shape the policies and tools used by and for the translators.
To all Arabeyes members who are involved in translations, I would
strongly advise you to join the fedora translation list  to voice
your opinions, in order to allow the Fedora maintainers to better
understand our requirements.
Fedora recently announced  a new system which nullifies pre-existing
language translation teams. This is not to say that they had such an explicit
policy, in the past but they are now saying that it is definitely not the
policy. What do they want to do then? They want to have translator per module.
What does this mean? Simple. There is module A that translator X can take,
translate, release. Translator Y comes along, takes A, translates, releases.
The same goes for modules B, C, etc.
Sounds good, eh? More people can easily contribute. What this will result in
is complete and utter chaos. Allow me to elaborate.
The Loss of Consistency
There will be absolutely no conherence among translations. Each translator,
depending on their language skills will have their own interpretation of
strings. They will also have their own vocabulary that will most certainly
conflict with someone else's in the overall translation.
The Loss of Quality Control
Since there is no group overseeing the quality of the translation, there are
no assurances that the quality of translation is up to any standard. So who
says what is standard? In the case of Arabic, the Arabeyes Project  has
set up a committee (Quality Assurance Comittee ) that is specifically
tasked with overseeing such standardizations across all translation projects.
This is something that other projects can learn from. However, with such a
scheme standards published by the QAC have no means of being implemented.
The Loss of Communication
Since there is no group, each individual translator is on their own island
with their own ideas of how things should be done. This does not affect
Fedora alone. This affects how Arabic is translated across a variety of
localized applications and libraries.
This additionally creates a very serious problem for a large project, like
Arabeyes. For example, in order to perform CVS sync's, the maintainer now
has to manually see what module he still has control over and what
modules he does not. In other words, a 5 minutes job will now take 50
The Loss of a Community
This scheme completely obliterates the sense and spirit of a community.
In the case of Arabic, this took very hard long years to build and foster.
With such a scheme, this community no longer needs to exist and is simply
put back to an individual doing a couple strings and going home forgetting
about the work he/she has modified.
The Loss of Credit
Arabeyes has taken great pains to ensuring that credit is given to each
and every individual who has contributed in any way, shape or form. With
the current scheme, this is no longer guaranteed.
Past experiences from projects such as KDE, GNOME, Mandrake, etc. should be a
good reference point to anyone outlining a localization policy for a project
of the size of Fedora. Fedora's point of view is, if a team maintainer
is needed, we can do that, as long as no one objects. However, it is not
clear as to what would be done if someone objects for no reason. I can simply
sit there on the list and object to every maintainer who comes up, just
in spite of the project. Would that be taken seriously? What if I have a
personal agenda against an individual? Would that suffice? What if, what if?
These questions do not have answers yet.
It is our hope that this policy would be reviewed and discussed with the
community of the many language teams and individual translators, before it
is being made as policy. We also hope that this would result in a more
reasonable policy that accounts to the fact that some languages already indeed
have a large set of translators and contributors who are organized and
structured. It is also our hope that other language teams of translators would
join us in our plea to Fedora to re-consider this policy.
| Mohammed Elzubeir | Visit us at: |
| | http://www.arabeyes.org/ |
| Arabeyes Project | Homepage: |
| Unix the 'right' way | http://elzubeir.fakkir.net/ |
Doc mailing list
Our LUG has recently started translating the fedora packages to
Macedonian. We're about to finish the translations, but cannot update
the CVS as there are no previous mk.po files to update. Add/commit
return "no permission errors".
Please take the neccessary steps to help us synchronize the CVS with
macedonian translation files.
Thank you on behalf of our LUG.
-----BEGIN PGP SIGNED MESSAGE-----
Some commit errors:
**** Access allowed: rahal is in ACL for rhn-applet.
[specspo/dist/ar.po] is not assigned to you.
**** Access allowed: rahal is in ACL for specspo/dist.
cvs server: Pre-commit check failed
cvs [server aborted]: correct above errors first!
Even though I have this file assigned to me.
Youcef R. Rahal
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
-----END PGP SIGNATURE-----
There seem to be some problems with my cvs account. Although I am
able to authenticate into the new system that's been set up, when I do so I
get a message saying "Unknown translator: dannutz". I have previously
deleted and then re-created my account, and I didn't receive the
confirmation message which leads me to believe that my account might be in
a strange inactive state. Can anyone help?
PS: the account name is "dannutz"
I have to say that the past two or three days is the most exciting
period of this mailing list since Fedora Translation Project started :)
It's great to have so many people join the discussion and give their
opinions from different perspectives.
I'd like to explain a few things raised among the discussions.
1. About CVS access.
Someone mentioned that it was too easy to get a CVS account. True.
Currently anyone who has a valid email address can be granted CVS access
to the commit locale of his/her choice. It was because in the early
phase of the project we'd like to encourage people to participate and to
start forming teams. There is no way to know or qualify people - on what
basis should we give someone access to cvs while denying others? If the
person is a GNOME or KDE coordinator then he/she should be the default
coordinator for Fedora? There is no convincing formula. I believe by
adopting an open policy then close the loopholes and fixing problems as
they arise will maximise the community participation. (BTW, your cvs
account has very limited rights, so don't even think of misuse it ;) ).
It is easier to add features and put limitations on accounts than to
remove features/restrictions. In the future process development, we may
be able to have different level of cvs accounts. For example, a
proofreader's account may have more rights than a new translator's
2. Coordinator's role
I believe a coordinator's role is not *to control* how things should be
but to stay *in control* of how things are. People participate one
project naturally form groups. Some are small - relatively easy to
coordinate and come to a resolution. Some groups are quite large with
hundreds of members - it's quite a task to keep things organised and
come to a consensus on discussions. For any languages that don't have a
separate mailing list yet, I'd like to see the translators of the same
language discover each other and form a group. If there are five or more
people in the group, just elect your own coordinator and send me an
email to request a separate mailing list.
3. Tools vs. Teamwork
Tools will never eliminate the need of teamwork. The new status page is
designed to ease the work involved in coordination. For smaller groups,
it may be very effective to notify through mailing list about the work
he/she is undertaking, but for groups with hundreds of members it's hard
to track who is doing what through mailing list notification. It may
seem cumbersome to have to go through take/release when you know you are
the only translator out there :) but it may not be the case tomorrow,
someone else may signed up to be a translator and want to help out.
There are lots of things tools cannot replace teamwork, such as quality
control, vocabulary consistency etc, but tools (or we hope to
develop/modify tools) could help with those activities. The status page
or any future enhancement is by no means a replacement for teamwork.
4. Red Hat people
Fedora project is Red Hat sponsored open source project, naturally you
will see plenty of people with "redhat.com" email address. That doesn't
mean anything said by anyone(a)redhat.com is official. Like everyone here,
he/she is also a participant/contributor. Fedora is a community project
and anyone participate the project should respect the community, Red Hat
people is no exception.
Last but not the least, I know it's pretty hard to stay cool in a heated
discussion but please keep in mind when you post to this mailing list
that everyone is entitled to his/her opinion and we may have different
approaches but we all have the same goal. All constructive suggestions,
debates, and criticisms are welcome in this list.
It would be better if the system can release the module automatically
after the taken module's translator check in the updated module. :D
======= 2004-06-22 17:38:32 Quote from your mail =======
>If you have only 2 translators, then it may not be a problem, it gets
>more difficult with 10. And if you have 20+ translators to a language,
>peer-to-peer communication has proven not to be ideal. In this way,
>everyone is informed of who is doing what. You only have to [Take] a
>module once, and then it belongs to you until the translation is
>finished, or you [Release] it. We believed this mechanism to be
>Sharuzzaman Ahmat Raslan schrieb:
>> Sulyok Peti wrote:
>>> My opinion is that conflicts should be resolved according to the docs of
>>> CVS. By using this take-over tech. teamwork has to be done outside CVS,
>>> or by using another CVS repository. This might be painful for teams
>>> working on the large PO files like dist and anaconda.
>> Agreed. Previously, I and another Malay translator working together
>> with anaconda totally using CVS. No issue about take over. Both
>> updates their own tree and resolve any conflict prior to committing
>> new translation. It works well and we manage to complete it before FC2
>> I don't see the benefit of the take over mechanism here. Can anybody
>> Sharuzzaman Ahmat Raslan
>> Fedora-trans-list mailing list
>Dr. Bernd R. Groh Phone : +61 7 3514 8114
>Software Engineer (Localization) Fax : +61 7 3514 8199
>Red Hat Asia-Pacific Mobile: +61 403 851 269
>Fedora-trans-list mailing list
Sharuzzaman Ahmat Raslan,
Set a expire time first, for example 3 hours, if the translator can't
check in the updated module in 3 hours, then the [Take] status will be released?
======= 2004-06-22 17:55:55 Quote from your mail =======
>Bernd Groh wrote:
>> If you have only 2 translators, then it may not be a problem, it gets
>> more difficult with 10. And if you have 20+ translators to a language,
>> peer-to-peer communication has proven not to be ideal. In this way,
>> everyone is informed of who is doing what. You only have to [Take] a
>> module once, and then it belongs to you until the translation is
>> finished, or you [Release] it. We believed this mechanism to be
>> extremely helpful.
>Okay, but what if one of the translator [Take] the module, but left it
>there untranslated? Can other [Release] the module or it just locked there?
>If it locked there, can other translator [Kill] the translator, and
>[Rob] the module?
>Sharuzzaman Ahmat Raslan
>Fedora-trans-list mailing list