One of the 2010 objectives is community localization:

http://wiki.maemo.org/Objective:Community_localization

The goal is to allow the organization of translators in language teams in order to produce community supported languages for Maemo. This would include the official releases and the tool could be open to community/third party applications as well.

After some research and thoughts, I think we could have a look to http://transifex.org/ an open source tool created precisely for this kind of purpose. It is being used by the Fedora project: http://translate.fedoraproject.org/

A strong candidate would be also https://translations.launchpad.net/ - planned to be open source later this year. A drawback seems to be (please correct me if I'm wrong) that Rosetta is part of the whole Launchpad infrastructure and it's not easy to detach.

Sitenote: While making it easy for translators to contribute is the most important thing (in GNOME's "Damned Lies" tool you still have to commit to SVN/git manually as it's not integrated into the platform, but planned as far as I know) I wonder if any of these platforms also create&update (on-the-fly) automatically a glossary for each language and pre-fill in proposals for translators (maybe even based on language glossaries already existing for GNOME, KDE, Mozilla and Microsoft), because lack of consistency is one of the biggest issues I've seen in GNOME's translations in the last years. I think Launchpad did this partially, but it's been a while that I've taken a look at it (and I haven't worked with Transifex yet).

Will this only be for providing support for unofficial languages, or can improvements be offered for official localizations? Nokia's English strings are usually a bit . . . weak (and occasionally offensive—see the "You loose!" debacle). It'd be nice if we could get ahold of the strings early enough before a release to help improve them (since poor strings tend to say a lot about a platform).

I agree with these kind of tools! And I'm available for translation into Italian language.

I guess such tool should be used to file bugs / enhancement requests about the official languages, yes. How early the strings can be made available would depend on factors such as open/closed apps and product launch vs sales start. Good to raise the suggestion now. I will ask.

I tried Transifex for a bit - just summarizing my immediate experiences with it:

* Easy to set up, had it up and running within 15 minutes
* No online .po editor - it requires a translator to download a .po editing tool, which causes the workflow to be download, modify, upload
* Close integration with SVN/CVS/BZR, but failed to get it to actually commit to a repository - when you upload a translation you commit to the repository.
* OpenID support, which is nice.

It is a bit like a fancy interface to a source code repository, which shows the statistics of how many strings are translated, but doesn't seem to support any collaboration features beyond locking a translation and uploading/downloading translation files. It does not even tell you what strings are represented in one but not the other.

My showstopper problems with it:
* A translator shouldn't be required to download tools to help out - it limits the amount of people we can crowd source from
* It doesn't offer any kind of connection between the translations / .po files, even if there's a lot of things that could be done to make translation an easier experience.
* It would be better to offer an administrative "merge translation" capability, than the current "upload straight to repository" method.

I've put up a test instance of Transifex up on http://trac.tspre.org:8088/ - use login guest, password guest, - it is based on the Mer project, so there's pre-existing Hildon etc strings loaded into it.

Yeah, I don't see this working (it certainly hasn't worked so far). Nokia tends to take at least a year to actually take useful action on things filed in the bug tracker (or three, or never. . . .), and by that time the strings are often obsolete anyway, and a whole new set of (broken, poorly written) strings have been shipped.

No, if there's any chance of the community managing to help fix these, we need to be able to get in there before every thing's set in stone.

Possible alternative:

http://pootle.locamotion.org/

Seems straightforward to start translating for a user - register, activate, log in, and translate - easy to find where there are lacking strings. All through a web page.

Having used all of the options already mentioned here for the translation of several different open source projects, I have to say that Transifex is in my opinion at the very top of my list. From the perspective of the administrator who is setting up a project for localization for the first time, the fact that you do not have to create several accounts for the given versioning control system is a major plus, specially for larger projects with many different teams and collaborators. Most projects will create these accounts/credentials on a as needed basis and try to keep them to a minimum. During "peak" season, usually right before a release, having only one (or a couple) person with credentials to make the commits could lead to a bottle neck if this person is not available for whatever reason. Transifex allows for the creation of a list of "trusted" collaborators who have direct access to the commit process without the need of a corresponding account in the version control system.

About your first point, I actually think that the fact that you only need a text editor, regardless of what operating system you're using is a major plus. No tools to download but the po file itself. I wasn't sure about your second point, but about the third, you could use roles to control the workflow, so that people can upload their work and then be reviewed by someone.

I don't remember right off the top of my head if Tx provides a diff of the uploaded file compared to the original one, but the Tx guys are very quick at turning feature requests into functional code.

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