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