Localization Server status update

Several people asked me to post about the status of the localization server, so here it goes. This project was started originally by Bruno Massa, then picked up by me as part of Google Summer of Code 2007 aiming to replace the Gettext and CVS based workflow for translators, providing a fully web based translation interface. One of the cool things of working full time on Drupal at Acquia is that I have capacity for spare time developments like this one. That's great.

The ultimate goal of the localization server is to have a central translation server running on Drupal.org which knows about relevant releases of all drupal.org projects, can share translations between projects and provide a collaboration interface for translators. This server should generate tarballs of translations for download and make information available on drupal.org project pages about translation status (among several smaller integration goals).

At it's current state, several translation teams alpha-test it on their own and they bear with the bigger updates which bring corrected behavior and new functionality from time to time. There are several things missing to call it "ready to be deployed on drupal.org":

• Drupal.org integration is still being worked on. This tool needs a list of drupal.org projects to mirror when deployed on drupal.org, so a list of projects in XML form is required: http://drupal.org/node/157514 But there is also an integration requirement in the other direction, which is not even started yet. Although translation tarballs are nicely generated, their data should all be funneled back to project module for use.
• There are performance issues. The database model of the server is according to the school book (ie. normal forms, not much data repetition); or in other words, we need to join at least 4 tables to get translations for a specific release of a project (even if we skip the project table altogether and just start from the releases). Indexes might not be right, and we should come up with more performant tricky ways of storing and accessing the data. This is still to be investigated more. Clearly, a server which should be able to host translations for multiple releases of 2000+ projects and 40+ languages is performance intensive. There are some optimizations in place already for easier lookups, but this is short from being ready.
• The translation interface is still being refined. There are good ideas flowing around, some in the issue queue, coming into even better forms in some mockups, so the translation experience is getting even more user friendly. Clearly, getting rid of CVS and Gettext formats for translators is just the beginning.

These are the three major areas, where work is being planned and done. The alpha-testing of some translation teams helps (literally) filling up the issue queue, so the interface is getting better and bugs are fixed. The project is quite usable already for smaller tasks like translating a few hundred modules to one language, but it is not ready for prime-time on drupal.org yet unfortunately. Help is welcome, especially in the first two areas, while the directions are close to being implemented in the third point.