l10n

In 2003 I selected Drupal to replace an aging PostNuke system on a Hungarian web developer community site (weblabor.hu) that I helped ignite a few years before. Of course I needed it fully translated to Hungarian. If you were using Drupal back then, you may remember that adding a new language to your site meant running ALTER TABLE queries on your locale tables to add new columns, editing your settings file and handling database dumps of your translations (which was the only way to share them too).

Drupal has come a long way since then.

I just got back from Drupalcamp Stockholm 2011, which was an action-packed two days for me to say the least. Due to a busy schedule, I was only able to arrive last minute the night before and leave just right after my sessions on the second day. Once again I decided to do a multilingual session all over again starting from the drawing board. There are lots of new things happening plus I think I'm developing better models to explain the components involved, so I think it was a good idea to build a new presentation. I've also presented on Drupal Security on behalf of the security team, which I hope turned out to be a very informative introduction to some of the most important things to look for when securing sites.

Dear Drupal interface translators!

Your valuable work helps Drupal to actual world domination, so we try to support you all ways possible to be able to more efficiently organize your time to translate Drupal projects (the Drupal core system itself, as well as contributed modules, themes and install profiles). Currently your work involves lots of manual steps and several "esoteric" tools.

Bryan Ruby points out that many open source content management systems are started to think about multilanguage support as a core building block recently. Drupal 6 is one of these systems, and although it does not come with complete internationalization and translation features, it goes a long way compared to Drupal 5. Jose A. Reyero pulled together a nice comparision table of the Drupal 5 and 6 core multilanguage features. As his table shows, right to left (RTL, eg. Arabic, Hebrew) language support is improved considerably. Now we know about each post being written in an RTL language or not, and we know whether the language used to present the page is RTL. All is left is complete theme coverage, so themes can be RTL-aware. Drupal 6 comes with automatic discovery of RTL CSS files, so a theme can easily support RTL styles.

I have been to REMIX 07 today, which was basically a rehash of some of the Microsoft MIX conference topics and presentations for a road show stop in Budapest, Hungary. Although I use much less Microsoft technology then I actually go to the conferences, I mostly enjoy going because it inspires me. I see cool new stuff which of course escalates into cool new stuff I would like to implement with my tool set.

One of the simple ideas that occurred to me today was about in-place interface translation editing. It is so common a request to ask for in-place editing tools for translations in Drupal. Just recently, Boris Mann posted a pointer to SLS, which aims to be a more generic solution for the problem (although I commented there why I don't think it fits Drupal well). Unfortunately we only know in t() that we are working with a localized string, so we could print a span or div with metadata to allow some jQuery to tap in and allow translation editing. Unfortunately in t(), we don't know whether we deal with output for email, SMS, watchdog logs and so on, where the extra div or span would look very unprofessional (in a text medium!). So that rules out the PHP way we could add an in-place translation widget (forget about introducing another wrapper, t() is wrapped deep enough).

On the heels of my recent announcement that thanks to Raimund Bauer stepping in, the translation template extractor is now a separate project, I decided to look into where does this change need to get propagated into the Drupal Handbooks. To be honest, I have not really been around in this part of the handbooks before (although I am a lead member of the Drupal Hungarian translation project), and what I found was not actually pleasing. The Translator's guide seemed to be intimidating for newcomers, basic questions are sprinkled all around the guide's pages. The start page was in the first paragraph talking about what is *not* documented there, instead of trying to help people grasp how things work here.

The Hungarian Drupal interface translation team used to use a private Subversion repository to store translations. Our reason for that was that we initially had many people contributing, and it seemed to be difficult to apply for CVS accounts for each of them. It also happened that we had some of our own tools developed and used. Now there is not that many contributors and many of our tools are already migrated to Drupal.org (and the others can be migrated too), so we are moving to Drupal.org. This will most importantly be better for our users, so they can find Hungarian translations in the tarballs downloaded from Drupal.org, without browsing through our own translation repository.

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.

Image

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!