One or two weeks ago, the Dutch team of OpenTranslators – which I’m proud to coordinate – passed a “big” milestone, when the 100Th translator was approved.
That’s one hundred people, translating extensions into Dutch. The results speak for themselves: the Dutch team is the most productive OpenTranslators team – outperforming some bigger teams like the Spanish (Sorry, Luis). Seeing how those volunteers work hard to translate extensions, is a humbling experience.
Of course, with the headline I picked you’re expecting tips on how I made it happen. And I will gladly deliver – although the recipe for success is surprisingly simple.
The recipe for success.
I’d consider the following three points to be cornerstones of success of the Dutch (and other) teams.
- A Strong Vision
- Freedom for Translators
- Quality Control by Peers
But before I start explaining things, you should know how OpenTranslators works. OpenTranslators is an unofficial organization, that plays “man in the middle” between translators and Joomla Extension Developers. Using Transifex we allow people to translate extensions of developers, that choose to use our teams. The key component is that OpenTranslators opens up the translation process, and makes it easy to participate
As a Team Coordinator, I’m assigned to “lead” the Dutch team. I get to approve translators, appoint reviewers and so on. But I don’t see (or use) it as a position of power; I see it more as an administrative role. Now, let’s take a look at the principles I followed.
A strong vision
This is actually the easy part, since OpenTranslators has set out his goals. Our vision is to make translating extensions easy; and I’m there to facilitate that. I do what I can to promote “Open” translations. I strongly believe that our ways of doing things is one of the best ways to facilitate translations in an Open Source community, and act upon that.
Freedom for Volunteers
When managing a team, there are many approaches you can follow. Personally I’ve chosen to let volunteers be completely free in their doings. It is one hundred percent up to them to choose what they translate, and when and how they do it.
From the get-go I was convinced that, to Open Source translations, trying to control translators isn’t the right thing – if it’s even possible. If that means people only want to translate one specific extension, I’m fine with that – OT served his purpose as a middle-man between that specific developer and translator.
When approving translators, I try to keep an open mind. You should know that I do a short background check of every translator before I approve him or her. Nothing fancy – I try to figure out who he or she is and what his relationship with Joomla is. What I don’t do, is “interview” people. I don’t know If they’re experienced translators, or people with a passion for one specific extension. Of course I’d love to lead a team of translation rock starts, but I’ve seen college marching bands do some pretty awesome things as well, without rock stars on board.
Another part of the “Freedom” policy is that volunteers are free to work on what they want. And they can work how they want, too. They could use the online editor, or upload translations. They can finish incomplete translations (my favourite) or power through entire extensions in days. That’s up to them. I just stand aside, and nod in approval.
Quality Control by Peers
I’m just going to drop a bomb here: I don’t believe in rigorous “Quality Control” for translations. I think it gets in the way of “Getting things done”. In my opinion, it’s better to have a mediocre translation than none. Mediocre can easily be improved on. That’s a bit harder for “non-existant.”
That doesn’t mean that Quality isn’t important. I believe that the path to quality translations is “Quality control by peers.” By creating a “good” translation, and making it available, you can outsource “quality control” to the end-users; who will be seeing your work in a real-world environment. Those end-users include the translators themselves.
Once your translation is exposed to the outside world, people can then criticize it, point out errors and make suggestions – which is valuable feedback you wouldn’t get when you “holding back” on releasing. People will find errors. Things might not be perfect. But they are now enabled to make suggestions – maybe do some translating on their own. For me, that’s a valid form of “Quality Control.”
Conclusion
As much as I’d like to claim that these rules are a guarantee to success if you adapt them for your project (whatever it might be), you won’t see me do that. All I can do is look at the result – a productive Dutch OpenTranslators team – and reflect on the “strategies” I’ve tried to apply. You won’t see me sell books on how to manage Open Source communities any time soon.