Three days ago on the 27th of August, Drupal.org's localization service, localize.drupal.org held its one year anniversary. It is worth a look back and a look forward to understand how far we came and what kind of tasks are ahead of us still.

The new web based user interface for Drupal localization came to unseat the usual tools used to translate Drupal itself, and its modules and themes. Over 30 teams joined the first two months, and most others followed later. The site now hosts over 70 language teams and numerous are in the queue discussing best ways they can leverage our toolset.

If you look through http://localize.drupal.org/news, we kept improving our performance, make our user interfaces simpler, give team maintainers more control over their teams, etc. We flip-flopped from backend and bugfix updates to user interface improvements and new features. We were the second site on drupal.org to deploy the new redesigned theme and therefore serve as a good test case for how it works.

With almost 1800 contributors and over 14000 project releases to translate, it is not surprising that we have a staggering 220000 size database of strings to translate. Attracting new contributors is a must in many teams (if you look at the front page highlighting Drupal core translation status, many teams are really far off from even completing a core translation). But a bigger issue might be quality control, and keeping up with the suggestions coming in. Looking at the list of languages, it is not uncommon for teams to have thousands of suggestions sitting waiting for approval. We have done three key changes in the previous couple months to improve on this: the rethought user interface rolled out earlier this year as well as string deeplinking and suggestion exports all attempt to provide different solutions for the issue, giving suggestions more spotlight. Activity streams/feeds for translation teams are also in the works, so moderators can be notified of new input on a real time basis.

Given localize.drupal.org's success to unseat CVS as the de-facto storage for translations, the git migration plans do away with handling .po files in version control altogether. (At least as far as human managed version control goes). We need a unified place to go for translations, and scattered, duplicated efforts don't do our translators and users favors.

That said, localize.drupal.org still needs some infrastructure improvements to be even easier to use for the average Drupal site builder. We did not make as much progress with the Localized Drupal install profile as we wanted, but it is still on our plan as the tool to drive people into localized installations right away when they start to set up Drupal. The Localization update module already works as a client to all the localize.drupal.org downloads, so you don't need to manually hunt down all the translation files for your modules. More testing there is appreciated.

Looking back on this past year, we accomplished a lot. What we have ahead still looks like a mountain to conquer. Let's do it together!