Updating translations for Drupal 6

Drupal 6 comes with quite a few language improvements, some of which directly affect translators.

Changes in Drupal 6

The most important changes for translators are:

• In Drupal 5, each language had one .po file for download and import for runtime translations and one installer.po file for installer translation. With Drupal 6, the translation packages themselves will have multiple smaller .po files, organized by modules and themes. This is good, because the end users see the same files the translators work with (until we migrate to a web based translation service, see later), so they can contribute back editing those files. But what's better is that only the .po files for modules and themes users actually install are used by Drupal.
• Drupal 6 supports installer translation (just as Drupal 5 did), but it does inform the users on the first screen (instead of silently hiding this feature) so users will be well aware that the translation experience can be translated. This happens based on the installer.pot file from the translation templates. Because the database is not available at the start of the installer, translations of this file are read from the file system.
• Drupal 6 comes with a new feature that automatically imports translations. If you use a localized installer (a Drupal core installer with .po files placed into proper directories), .po files for all modules and themes installed by the installer will have their translations imported for the language the install process was done with. This means that a localized install experience continues right away with a localized Drupal experience. Nothing else is required for this other than the placement of .po files into proper directories.
• Whenever a new language is added via the interface, a new module is installed, or a new theme is enabled, translations will be imported automatically. When adding languages, all translations for currently enabled modules and themes will be automatically imported. With modules and themes, the translations for all enabled languages will be imported.
• String translation is now possible in JavaScript code as well! This means strings wrapped in Drupal.t() and Drupal.formatPlural() will appear in .po files. These strings are translated with pre-generated .js files in each Drupal instance for best performance. You can work with these strings just like any other translatable string in PHP, the syntax used is the same.

Note that we introduced an interesting solution to prevent short and long month names from possibly colliding. We have a '!long-month-name' marker for long month names so that translations for May (long version) and May (short version) will not collide. You will also notice that we did a lot of spell checking and put a lot more thought into help texts. This makes your older translations not as reusable, but makes Drupal a much better system, so everybody will hopefully be happy about it.

File naming

This version comes with a good bit of automation, which requires proper file placement. Let's see what kind of files Drupal 6 recognize: language code.po files and some prefix.language code.po files. Core translation templates have file names referring to the location where they come from: modules-system.pot signifies that the template was generated based on files in modules/system/*. The same rule can be applied to misc.pot, includes.pot and so on. Two file names are special: root.pot, which was generated based on files in the Drupal root directory, and installer.pot. which has the same role as in Drupal 5.

File placement

So where do these files go, when translated? Drupal 6 finds translations for install profiles, modules and themes under their translation subdirectories. For example, translations of the help module are placed in modules/help/translations/. Because of the above mentioned file naming, although translators can work with files in the same single directory to ease their work, the file names as modules-help.it.po (using the example of Italian) can be moved to modules/help/translations/modules-help.it.po when the download package is generated. The Drupal 6 version of the Hungarian translation includes a build.php file which helps you do this automatically for testing purposes if you are on a Unix based system (Linux or Apple Macintosh).

Common files like misc.it.po, includes.it.po, etc. will also be moved to the system module's translation folder. As translations for these strings are always required, they should be imported when Drupal is installed.

The installer.it.po file serves as translation for the Drupal installer, and is placed in profiles/default/translations/. If this file is found, Drupal will offer installation in Italian, based on recognition of the 'it' language code in the file name.

So how to update my Drupal 5 translations?

The easiest way is to start with merged Drupal 5 translations (eg. an it.po file in case of Italian) and then merge this with all of the .pot files provided for Drupal 6. This ensures that all Drupal 5 translations usable in Drupal 6 are carried over. The manual has instructions on merging small po files to one big po file (if you have more updates to your translations in CVS and do not wish to use the merged file provided by drupal.org in the package). There is also a page on recycling old translations, which is exactly applicable here. Feel free to post suggestions on these manual pages where appropriate, or ask questions on the translations mailing list or the translations forum.

Merging file by file is not practical as the file names have changed and the location of common strings have moved, making general.pot less of a huge aggregate of all things appearing multiple times. Now, if a string appears multiple times but only in files of the same module, the string is kept in the file for that module (which makes your translation work more concentrated).

There was some talk about easier to use translation tools, not?

Indeed. There is an amazing Localization client module, which helps you translate Drupal as you go along. This may or may not be a good tool for core translations, because you can only translate what you see (and it might be more difficult to apply the same wording to similar parts of the text as you go along). The Localization client module provides a nice user interface for translating most text, however, and allows you to export your translations and merge as discussed on the recycling old translations page.

Work is still underway to develop the Localization community server. While we hoped that it would be ready by this time (so that we could provide you a nice clean web interface), it is not ready yet. This tool will allow translation teams to collaborate on core and contributed project translations, sharing their work, so they can skip redoing translations of the same text for contributed modules. It will also be integrated with the drupal.org project infrastructure, and will replace the CVS based workflow with a nice web-based one. It still suffers from performance problems and needs lots of user interface tweaks and additional key features before it can go live. The Localization community server is expected to be hosted centrally on drupal.org, so no translation team will need to set it up for themselves. Currently, several translation teams are alpha-testing the project and providing feedback and bug reports. If you are interested in the Localization community server, you are welcome in the project's issue queue.