Drupal 5 comes out with a nifty new feature (among a lot of others): it only creates database tables and imports CSS files for modules turned on. It is a logical step to do the same with interface translation files. The practice up to Drupal 4.7 was to generate smaller translation template files for translators, so they can better work with strings and collaborate with version tracking tools. These smaller files were merged into one big translation file, which was given to end users to import if they needed the Drupal package work in their language. What should be the new model, and how do we support it? Do I have a working (starter) solution? Yes. Read on!
Maybe we are in time to change the previous practice for the first Drupal 5 interface translation packages, but even if this is not going to happen, the format will surely get changed soon anyway. We need to support importing of translations for only the enabled functionality (themes, modules). For this to work, we need to hand over the smaller translation files to end users, and provide some automatism to import them when needed.
Drupal 5 supports installer translation out of the box. So if you have a languagename.po file in the install profile folder (eg. profiles/default/de.po for a German translation) the installer offers this language, and you can install Drupal on a German interface. But Drupal is still English when you open it up. We need a custom install profile which turns on the automatic translation import functionality for the Drupal interface. This profile is now called autolocale, and can be found as a simple file in the autolocale module folder. This profile turns on the autolocale module, so that it can look at the modules turned on in the install process and import their corresponding small translation files. For this to work, the translation files need to be in some standard place to get found.
This already works almost perfectly (there are some small interesting side effects to work out). The next step would be to support automatic import of translation files for modules turned on at a working (live) site. Maybe also support removing of translations for modules turned off (although there is no metainformation in the database now to support such a feature).
I have the Hungarian community alpha test the new package format and the install profile. I did code some ugly looking shell and PHP scripts to generate this package format, but it works nicely. I fully intend to share the package generation code, especially for drupal.org to refine and use for next generation interface translation packaging.
You can try or look at the Hungarian package if you wish, since it is publicly downloadable from: http://drupal.hu/forditas/forditasdrupalhu/forditas/hu-5.0.tar.gz The screenshot presented above shows me registered and greeted with a Hungarian first user information screen. This was impossible to get before due to the workflow of enabling locale module and importing translations later.
The package structure (files in package) to make the process work is as follows:
// Module PO files
// Include PO files and general PO
// Translation for default profile and localized profile
// Module to handle the import at install time
The best thing again is that Drupal does not need to be modified in any way. The installer interface translation is supported out of the box in Drupal 5 and the other features are possible to implement by hooking into Drupal when needed.