Migrating to Transifex

Published
2010-04-28 18:19
Written by
As you have already read in the previous blog posts, one of the outcomes of the translation sprint is the fact that we’re switching our translation server to a new tool, Transifex. We decided to go with Transifex for various reasons:
  • Transifex allows teams of people to collaborate on translations – this is not an issue when you have a single person working on a translation, but as soon as you have two or more contributors working remotely, it’s crucial to use a tool that streamlines the process and allows for easy and centralised communication,
  • the user hierarchy is simple, clean and seems to be efficient: project maintainers accept language maintainers who, in turn, accept language team members and coordinate given language’s development,
  • project maintainers can announce localisation-oriented things on the project’s page,
  • teams can have discussions on the per-language discussion boards,
  • the user interface for translations is better and easier to work with, and has the (dubious for some languages, but useful for others) ability to fetch Google Translate suggestions on-the-fly,
  • PO files can be locked for work in offline tools (like Poedit, Virtaal or others) and the locking is visible to other contributors.
Another set of reasons for choosing Transifex was more technical, but – especially in my opinion ;) – the reasons are no less valid:
  • it’s an open source solution with a hosted version available, so one one hand we don’t have to host it ourselves, but on the other we can move it to our server any time if needed,
  • it’s based on PO files, which means we were able to migrate in two days’ time, and we don’t have to switch many things on our back-end to accommodate the transition,
  • we were able to connect Transifex to our new localisation repository at GitHub, and the translations are committed there automatically,
  • the translation commits have the relevant translator in the ‘author’ field, so every single strings translation will now be properly attributed,
  • Transifex seems to be developed in a quick pace and my general (if subjective) feeling is that they bring in the right features quickly and are very open to collaboration (our request for recognising Canadian French as a proper language was answered instantly),
  • again, it might be a subjective opinion, but a lot of design decisions (like choosing Django) and small, nice features (Gravatar user icons, proper Git commit authorship) assure me that the Transifex team is doing a great (and smart!) work, and their blog is worth reading and keeping track of.
The current state of the migration is that both our previous translation system and our new Transifex home are operational, and this will be the case for the next couple of days (to let people working in the old system finish whatever they might be working on); our policy is to not have a single translated string left behind, so we’ll make sure all the contributions end up in the new install as well. The CiviCRM project on Transifex has currently two Transifex components, ‘CiviCRM 3.1’ for the current stable version and ‘CiviCRM 3.2’ for the upcoming version that’s currently in alpha. As you can see after checking them out, we’re experimenting with a new approach to PO files: instead of having -core, -modules and -helpfiles split (which we’ll keep for CiviCRM 3.1), the new idea is to have a per-CiviComponent split (with separate files for CiviEvent, CiviMail, etc.); the ‘core’ CiviCRM strings will be now in civicrm-base.po files, while strings common to more-than-one CiviComponent will be in civicrm-components.po file. Note: we’re open to adjusting the split of CiviCRM 3.2 POT/PO files in any way you deem sensible (and we’ll make sure any moved strings are kept translated). Also note that the CiviCRM 3.2 strings are not frozen yet, so do expect quite a few changes (but do also report any strings that should be fixed!). Last (but definitely not least): please do read a recent Transifex blog post on their project development and do let them know about any features that would make CiviCRM translators’ lifes better. :)