September 3rd, 2009

Pimpin' Transifex

I've said it before and I'll probably say it again....  I think Transifex's way of layering a translation community over the top of the development community is the right way to go in building a vibrant and sustainable interface between those communities without pidgeonholing either developers or translators into making tool choices uncessarily.  It's just the right amount of centralization to facilitate project translation without being overly inflexible to other factors which influence overall project development workflow. 

Regardless of whether your project development is using git or mercurial or bzr  or even tarballs... Transifex provides a translation workflow that hides those choices from the translation community because those tool choices are largely immaterial to the work that translators need to do.   But at the same time Transifex is designed so that the translation community are working with upstream developers and commiting changes to upstream codebase. There's no hoarding of translations in downstream builds of your project that have to be merged back in later the translation changes go directly to your project...when someone remembers to fire off the merge.  No... the Transifex translation community is working shoulder to shoulder with upstream developers in the upstream that all users benefit as part of the upstream development process regardless of where they get their binary builds from.

If you want to help out open source software projects as a translator for your native language.. you should look at registering with Transifex,net and becoming part of the translation community there. 

If you are a project developer and want your project to have wider language coverage as part of upstream releases.. you should take a real close look at registering your project with