gettext

Moshe Weitzman recently started the D7CX movement to rally people to get Drupal 7 contributed modules upgraded and released on time for the Drupal 7 release. This would be a great boon to the Drupal 7 release, which shapes up to be a huge improvement over Drupal 6 already. He also suggests a contributed module release manager who can help with (among other things) ensuring that tools are available to help people upgrade.

Me being the guy, who maintains modules important for the translation of Drupal interfaces, such as l10n_client, potx and l10n_server, I looked at this movement from my angle. While my modules are not among the highly popular top 40 modules Moshe highlights, these tools are used to translate them and reach many parts of the globe. So in part on Acquia sponsored time and my free time, I went ahead and ported both the Localization client and Translation template extractor to Drupal 7. Both had their own challenges. The client port is just a direct functionality port, so does not include real string context support yet (a feature new to Drupal 7). The template extractor however got full context support to match what Drupal 7 supports currently. It also got its coder_review integration updated. Both modules now have their 7.x-1.x development snapshots downloadable.

Thanks to these updates, I hope people working on the D7CX movement will not be in the dark about localization API changes and usage limitations of the new API. You can run the template extractor on your code or run the code review from Coder review to get error reports when the localization API was not properly used. While Coder review includes some rules on its own to test for some common errors, only using the actual tool translators use can tell you all the errors you can make while writing your code.

Future plans include backporting the Drupal 7 parsing support from the template extractor to Drupal 6 (which would be easy except a little API change required), so when integrated with the localization server, contexts would be properly stored. Which would require an update to the localization server too. The goal is to have a Localization server system which can be used to translate Drupal 7 core and modules, so translators can work on their part before the release too. Also, the localization client would pass on the context information too to the server, so people can keep using that to translate and share their work right away.

People keen on magic names can just refer to this effort as D7TX, the translator experience ;) Have fun using these tools, and as always report bugs and provide patches please!

In a recent blog entry titled The future of Drupal interface localization lies in install profiles I showed you a proof-of-concept way for a new Drupal interface translation packaging format. As the Drupal 5 release is closing on us, and we were able to fix quite a few small glitches around interface translation related problems, I decided to clean up the packaging scripts and release them to the public, so other translation groups can try this distribution format and we might eventually get this up at drupal.org as the default.

I have uploaded the packager shell and PHP scripts to the tricks contributions area. I hope I have provided adequate comments in there to let you know what directory structure is expected by the script to work right. If everything is done fine, it should generate packages like our hu-5.0.tar.gz which is our downloadable for Hungarians interested in more advanced interface localization. We don't even have the previously used package format for download anymore.