10:57 a.m.
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
project works.
There are some more or less defined goals with the model that the GTP
uses:
* 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 teams
---------
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.
CVS access
----------
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.
Abuse
-----
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.
Drawbacks
---------
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
fixed.
Benefits
--------
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
Project.
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.
Cheers,
Christian
¹ I have even written a template that many GNOME software maintainers
can opt to use to point new translation volunteers in the right
direction:
http://www.gnome.org/~menthos/package-translation-guide-template.html