Last updated 12 October 2012.

The interface translation of Drupal and contributed modules/themes is a separate process from the development of these projects themselves, and it is also separate from translating content that is entered into Drupal (such as nodes, blocks, taxonomy terms, etc.). This page describes the process of interface translation.

What is available for translation?

Developers of Drupal itself as well as its modules and themes use the Localization APIs in the source code, applicable for their respective Drupal version compatibility. These APIs allow Drupal core to translate text when it is displayed to the user.

Drupal core has a built in mechanism to maintain this text and the translations in the database used by the website. As Drupal runs and finds source strings, it stores text in the database so administrators can translate them. This means you can translate Drupal and its add-ons without any further tool. However, many people have done so before, and sharing the translations is of high interest to the community.

Therefore we set up a central repository of translations at to help with these efforts. maintains a list of all projects from and makes their releases available for translation. Each release that is published on is made available for translation in a short time (about 30-60 minutes) automatically. uses translation template extractor to find text used with the above mentioned Localization APIs, and makes those available for community translation (versus the Drupal core built in local method, which is limited to your site only).

Translation organization organizes language translations into groups, each having their respective leads. It is common for these groups to accept new members automatically, and promote active members to be leaders/moderators of the group.

The main functionality of is the web translation interface. Contributors can work with various filters to focus their work on just specific modules or even specific versions of specific modules. By default, translators add suggestions which are then vetted and approved or declined by moderators. Strings can have multiple suggestions at a time, and even translated strings can receive further suggestions to help fine-tune translations. Therefore the lifecycle of translations is generally from suggestion to approved translation. Moderators can submit approved translations right away.

It is also possible to work offline. You can export a set of strings for translation in the GNU Gettext .po format, and once done with them, you can import the .po file back in. This allows you to use desktop software or work on translations while without internet connection. Group membership is required for certain actions.

Finally, it is also possible to participate in translations remotely. The localization client module which comes with the Localized Drupal install profile can be easily set up to share your translations with the community. The client is a great tool for touching up on community provided translations, and you can be part of the community by submitting your fixes at the same time, without special effort to look up the strings on

Most important of all, there is no Git account required or special permissions needed to contribute to this work.

Getting translations to users also runs a regular build process which generates exported versions of the quality assured translations. The files are available from just like all other project downloads, but are simply in the Gettext .po format for ease of download and import.

You can use the web interface on to get these downloads, but on a website running tens of modules and maybe even multiple languages, downloading these many files can be tedious. Therefore it is suggested that you use the localization update module to automate downloading and keeping your translations up to date. This module is also included with the Localized Drupal install profile.

Read more