Reposting from http://acquia.com/blog/drupalorg-steps-helping-localized-drupal-installs...

I just came back from Drupalcon Paris this week. It was an action packed conference with lots discussed and many things done to further Drupal's reach. In my case, I've submitted sessions to teach people to write modules the right way, theme Drupal in minutes and translate Drupal interfaces to multiple languages. Thankfully only this last submission was accepted, but that was about a new service on drupal.org which first needed to launch. Way to get people to advance services on Drupal.org!

My talk titled "Here comes localize.drupal.org" started off with a history of interface localization in Drupal. I've joined the core team when it was still SQL ALTER TABLE commands to add a language to your Drupal install and translations were shared with carefully crafted database dumps. We've gone a long way since then, because we have projects, CVS and issue queues to manage all that and we use the de-facto standard .po format to share translations. However, managing CVS branches and releases, merging translations and getting same string translations to various modules is not much easier then SQL dumps after all. So I've started work in 2007 sponsored by Google Summer of Code to have a web based translation user interface to submit and manage translations in a community-integrated fashion. The result of that was the localization server and localization client modules.

Over the past two years, these modules grown up enough so that it was time to deploy the server on our live infrastructure and get translation teams use it to work collaboratively. The new tools replace CVS, releases, branches, direct .po file editing and do not require module or theme maintainers to actually review translation files or generate templates manually. We can automate all of these. What's even better is that when connected with the localization client, people can enter an API key on their own Drupal site and submit translations directly to the community from the comfort of their own browser/website. This lowers the barrier in an amazing scale, since people only need to enter text in a textarea to contribute to community translations. Imagine what this can do to Drupal's reach!

Localize.drupal.org already has the latest releases of all modules parsed from all their branches, which means over 5600 releases. This translates to around 150000 unique translatable strings, with common text like "Home" and "Operations" shared among modules. While this sounds like a lot, it is "only" like translating Drupal itself 43 times. Most contributed modules are not as big as Drupal core. When added up, these strings are about 8 million characters, so even with small type, a full print of them would be 16km (about 10 miles) long. However, translated all these, a team would cover all of Drupal modules, themes and install profiles hosted on Drupal.org.

My slides

Check out my slides from the session for details of the tools being used and how you can set one server up yourself if you do in-house module or theme development and need to localize the code to clients.

While we have a central translation server improving by the day, some questions are still open. We are dedicated to remove translations from CVS, but we still need the packaging/export infrastructure and client software on a Drupal site to grab those translations and import when needed. Part of the pain with Drupal translations is to download the right files, unzip them at the right place and then still not being able to update translations easily. So we are working on Drupal core improvements and server side tools to get all these fantastic translations from localize.drupal.org to actual Drupal sites as part of an interactive Drupal install or update automatically. Think plugin manager coverage for translations!

I'm hopeful that with these tools in place, we get a huge boost in translation coverage for Drupal as well as actual translated websites installed. Interested? Looking forward to your contributions in translation teams, the queue related to our suggested code and server changes and the localization server and client issue queues to help tie these tools even better for an even smoother integrated experience.

Comments