Recipe for a good translation team

A while back I was asked by a member of a Ubuntu translation team (who shall remain anonymous) about how the Brazilian team’s workflow worked and how we managed to maintain our position among the top translated teams in Rosetta. What follows was my reply to this person. I hope it will prove to be useful to any other team out there who may be struggling with the same issues. I’m also interested to learn how other teams managed to keep their members involved and/or how others can benefit from their experience.

|> Now, the LOCALE translators have some organisation problems and some |> problems to find good guys for translating ubuntu. When I saw, how |> complete is the brasilian translation i get an idea. Maybe you or some |> of the other translators may help us.

Hi there Anonymous! The translation process of free software has been the reason why I joined the masses of the free software world. It is a very rewarding experience when you see people being able to take advantage of open source software in their native tongue.

The Brazilian team has proved to be an interesting experience for me. I was the second person to take on the lidership of the team, and I’d like to offer your my opinion and insight as for why we have managed to grow and maintain a pretty decent track of quantity and quality.

I think that anyone who participates in open source communities likes to have a sense of direction and ownership. By that I mean that people like to know what is going on, what they can do (but not in generic terms; they need specifics) and what the roadmap is. When people see an organized team and specific goals set out, it makes them want to participate too.

How can you do this? Simple. Start simple… Schedule IRC meetings on a regular basis so people can “update” their status as well as discuss priorities and give feedback on what is working and what is not.  Speaking of priority, create a list with the software packages the translators should focus on during the period (a weekly sprint?  monthly?) so that once you reach that mark people will have a feeling of accomplishment! They will like that feeling, I can guarantee you… and they’ll comeback for more!

Also, set up a wiki where people can put their names next to the packages they’re currently working on, so that new collaboratores don’t work on the same packages as other people. Set up a program where current team members would have to “adopt” a new translator and show him/her how everything works, as well as be responsible for reviewing and providing feedback. The current member will feel that he he/she has ownership of the process and team as a whole, and that is very rewarding. The new translator will have a feeling of direction… and that is very rewarding as well! It is a very good cycle that can strengthen the entire team, no matter if they’re “veterans” or “newbies”.

Lastly, let everyone know that their word counts! Assign a current member as your right hand and share the responsibility of the administration of the team (ownership, remember?) It is the job of the administrator to make decisions on behalf of the team, but it is just as important to heed to the team’s members interests and ideas. Having someone who you trust to bounce off ideas is a sure way to make sure you stay on track as well.

As far as how we keep the quality of our translations? Many of our members, myself included, work with the upstream teams for GNOME, KDE, XFCE, etc and try to stick to their translation standards. I suggest you take a look at the following web site: www.open-tran.eu. It is a great service that allows you to see what terms the upstream teams are using in their translations and allows you to also follow the same pattern.

Well, these were the things I did back when I was the leader for the team. I’m sure the other guys will be able to provide you with some more tips.

Tags
comments powered by Disqus