Hmm - your problem seems to be familiar ;-)


I have been facilitating/leading the largely volunteer based l10n/i18n efforts at One Laptop Per Child for the past year and a half, and we have been really happy with Pootle.



Some of the reasons we chose it (at that point) were:

Low Barrier to Entry: We wanted to lower the barrier to entry for potential translators as much possible (especially since we were targeting languages/locales like Dari, Aymara, Pashto, where technical computer knowledge could be minimal). If you have a internet connection, translation using Pootle is extremely easy. We had a primer which covered most of the process: http://dev.laptop.org/~sayamindu/pootleforxo2.pdf We managed to go from around 2 supported language (>80% translation) to 19 supported in less than a year. Of course, this was largely due to super awesome translation community that helped us, but I think the relatively lower barrier to entry helped us as well (someone with an internet connection could just register on the site, and start contributing). Even if someone cannot translate directly due to ACLs set by a language team coordinator/lead, one can always submit suggestions which can be reviewed and accepted later by other members in the team.

Flexibility/Choice: Pootle gave the option of download and subsequent upload of PO files (like you would do in Tx), as well that of online editing of PO files using simple web based UI. We were dealing with potential regions with very little connectivity, and wanted to be as flexible as possible. This turned out to be a life saver during a Aymara translation sprint in Bolivia, where someone volunteered to collect all the translated PO files, drive to the nearest place with an internet connection, and upload them.

Support for Different Formats: Support for different formats was yet another major issue for us. Eg, for some deployments we sent out PO files converted into CSV files, which were edited using Spreadsheet software, and were finally subsequently converted back into PO files with the tools which come with Pootle's backend - the Translate toolkit (the process required a bit of manual tweaking though, but it proved to be a life saver at times).

Built in tests: Pootle has some nice built in tests which an administrator can use to ensure quality. These check for some common mistakes which are done during UI translations. A description of the various tests is at http://wiki.laptop.org/go/Localizati..._within_Pootle

Assigning tasks, etc: Pootle has some nice tools for the coordinator of a translation project. One can assign tasks, etc using the web based interface. The OpenOffice.org folks (who use Pootle, btw) have put up a nice guide on these features: http://wiki.services.openoffice.org/...nslation_Leads

Support for multiple VCS-es/repos: Pootle supports all the major version control systems, and we wanted to make sure that if someone did not use Git (OLPC's preferred VCS), we could still accomodate them.

Support for alternative languages: This was a bit of special requirement for us. Our Aymara translators wanted to see the source strings in Spanish, as they knew little English. So with a little bit of effort we managed to add this feature to Pootle where you could choose an extra language, and while translating using the web interface, you would see the translations for that particular language as well (if they already existed in Pootle - which was not a problem in our case since we had nearly 100% coverage with Spanish). I believe this feature exists in Rosetta as well. Subsequently this feature was polished a pushed upstream (with a set of other features as well) by a GSOC student.

Grouping of files: We could group PO files by category, which helped us to prioritize translations. The core UI and libs could be translated first, and then the Activities.

Adoption by other leading FOSS projects: OpenOffice.org was already using it, and at that point there were talks about Mozilla folks adopting it as well. The OpenOffice.org people are still using it, and the Mozilla people have been also contributing to the code base significantly (they have proposed some radical UI changes). I believe the plan is still on for the Mozilla folks to adopt Pootle as the base of their l10n infrastructure, though the schedule seems to have slipped somewhat (https://wiki.mozilla.org/Verbatim)

Glossary/Terminology Support This is extremely important if you want to ensure consistent translations (eg: you should try to ensure that Open is translated as Foo everywhere, and not as Foo at one place and Bar at another). Pootle supports glossary, and here's how to use them: http://wiki.services.openoffice.org/...Glossary_Guide and http://translate.sourceforge.net/wik...ology_matching There are tools (which are parts of the Translate toolkit) which lets you generate a glossary for your language from existing translations as well. The tool to do this is poterminology, which is documented at http://translate.sourceforge.net/wik.../poterminology

Access control: The language team lead can set default permissions, as well as individual permissions for team members. The permissions range from ability to submit suggestions to reviewing them and actually translating terms, to committing files and assigning work.




Of course, not everything was not perfect, so here's a list of Pootle disadvantages that we found out/faced:

Slow and resource hungry: With large files (eg: we had individual files with almost 4500 strings), Pootle can be excruciatingly slow, especially if you are trying to merge something or upload something. This process would take up significant CPU, as well as memory. However, with newer version, this has been dealt with partially (better caching of PO file statistics, indexing using Lucene/Xapian, etc). Currently we are evaluating moving Pootle to a newer hosting facility at SugarLabs, and I'm pretty happy with the new version's performance.

Poor intra-team communication: A language team lead had no way of communicating with the members of the language team via Pootle, and this is true for the reverse as well. However, I think this feature can be easily added with some amount of effort. I have often manually helped language leads by providing them with a list of all the people who have signed up in Pootle, and chosen the relevant language from their settings panel.

Requires reminder for committing: Sometimes language team leads forget to commit the files, assuming that just translating the files would be enough. It has been suggested that some kind of visual cue (marking a file as uncommitted) on the web interface can be helpful, but we have not successfully implemented this feature yet (mostly due to lack of time).

Complicated "backend": We have a significant number of files in OLPC's Pootle installation. This needs to be managed, and I have had to create a set of scripts and cron jobs to ensure that things stay in order. I'm not sure what your plans are, but Pootle does require some amount of manual attention, love and care, which might necessitate a l10n infrastructure team (I don't mean a large team - at OLPC, upto this point, it has been a one person team.. which was me (apologies for the shameless plug :-) But now, as we are scaling upwards with Sugarlabs, we have started to build a l10n infra team, for adding redundancy and reducing the bus factor, if not anything else)




Hope that helps in your evaluation. I do not have particularly anything against Tx or Rosetta, and feel that they are incredible tools. I just wanted to share our experiences about what looks similar to what you are trying to achieve.
I'm terribly bad at documenting the things I do, but I had created a small description of the workflow that we use: http://wiki.laptop.org/go/Localization/Workflow
A list of the important Pootle features is at http://translate.sourceforge.net/wiki/pootle/features