Open Atrium: Solving the Translation Puzzle


4 min read

We launched “”: earlier this week to support translating “Open Atrium”: into more than a dozen languages. It currently ships out of the box in English, Spanish, and Arabic, but we want to grow this. To do this we built a localization server that provides “downloadable, up-to-date translations”: that are automatically repackaged every few hours and that allows people to post their own translations and fixes to the server while they’re doing them on their own sites.


The “tools that make this possible have been in the works for some time now”: The “localization client”: allows for on page translations of UI strings, and the “localization server”: lets you keep a centralized translations repository for all modules, versions, and languages. We’ve had the tools for awhile, however, in order to realize just how hard it is to actually do and maintain translations in Drupal, you need to try it.

In the case of Open Atrium, we’re not talking about a Drupal module or a single site. Open Atrium is a full featured Drupal intranet distribution that uses Drupal core, some contributed modules, and some custom specific ones, and all of this this is deployed to many sites. This is one of those times when it feels like you have all the pieces to do what you want to do, but it’s still hard to figure out how to make everything work together in a human friendly way to get the job done.

So for Open Atrium, we want to:

  • Provide a downloadable package for a simple installation in any of the supported languages.
  • Set up some channel to allow people to easily contribute and improve translations.
  • Keep everything up-to-date with our release schedule and the quickly moving codebase.
  • Allow Open Atrium users to easily keep their translations up to date with the latest version.

Nope, it’s just not that easy.

With a contributor-based translation system like this, the code updates come before the translations. So we first release the modules, then wait for the translations to come in, and finally release the translations. There’s no way we can deliver updated translations with each release unless we have a full team dedicated to translate pre-release versions.

There are about 50 modules in Open Atrium besides Drupal core, and that makes updating single module translations unworkable. To get around this issue, we came up with a meta-package idea — to bundle the code into different packages that are imported by the extractor, creating some fictitious projects (and versions) that can be either translated, handled, or released separately. This gave us an atriumfeatures package, an atriumthemes, an atrium_custom, and a big atrium package that includes all the others.


Now for how to keep the translations up-to-date. There is a very little known feature built into the localization client and server that allows a client to automatically post translations over xml-rpc, using some shared key system that provides client authentication to the server. This is important.

While the localization server allows for the downloading of translations, they’re repackaged every time and therefore not really suitable for public downloads (especially if you expect a lot of them). To get around this we’ve built “another custom module”: that automatically repackages all translations periodically and makes them available for downloading.


We’re excited to test this out and keep working on it, as some kind of “l10n server will likely be in the future of Drupal”: to handle core and module translations. Hopefully, some of the work we’re doing can be later reused for that.

Coming next — automatically updating your site’s translations (which is why we really needed the packaging module).

And for fun, here’s a peak at the full design for created by Saman that I just love.


What we're doing.