localization

Just over a week ago, I've been in New Orleans to talk about multilingual Drupal website building at the Do It With Drupal event organized by Lullabot. I've been happy to join fellow Acquians for a short time at the office and then at the Do It With Drupal seminar to represent the company. It was a fun experience to hook up with so many other people looking into using Drupal for the first time or even selling Drupal services already. It was a good mix, and was a very different target audience compared to Drupalcons. This event was more focused on the path seekers and the beginners with high detail and cross-discipline talks over four days. I've enjoyed several sessions, including Robert's session on Solr.

Unfortunately (for my enjoyment of the conference), my session was at one of the last slots, but it had a good turnout nonetheless. I've been prepared well in advance with a completely rethought line of thought (compared to previous, more developer focused events), and a slideshow done from the ground up. So despite talking about this topic before elsewhere, I needed to have a totally fresh look at the topic and present all the latest developments to date.

Since I do not have the permissions to upload my session to the website of the event, and the slides I sent in by email were not uploaded yet, I figured I'd better share them here with those eager to look into them soon. Happy holiday's reading if you are about to take time to learn more about multilingual Drupal solutions!

This story started almost a year ago, when I published my cheat sheet for the Drupal 6 localization API. Although Drupal 6 was not ready at that time, the localization API was as stable that the cheat sheet is useful without modification even today.

My intention with the cheat sheet was to start a localization API guide on Drupal.org and get the intricate details of this API documented for the general good. Over the past few weeks, i've managed to have time to actually sit down and document best practices and tips for these functions, and published the Localization API guide as part of the Drupal.org developer handbook (it is worth to check out the printer friendly version for a quick glance). While some parts of the guide are still under discussion and finalization (and I still plan two pages: one on emails and the other one on pointers for people looking to translate user provided data), the guide is pretty much complete as far as localizing the interface goes.

Another side of that old blog post of mine was new Translation template extractor support for the coder module. Well, that was basically tapping the existing errors into coder and make you figure out the rest. The existing error messages in extractor were however quite cryptic, like Invalid marker: t($joe). This is not really helpful in finding out what is the issue at hand, when you are not familiar with the finer details. This was unhelpful for both module authors and code reviewers, who were eager to fix these problems. I got several support requests in the extractor issue queue to clarify guidelines. So updating the error messages was clearly in order.

The result of these two efforts is that the latest development version of the extractor on the 6.x-2.x branch (update from CVS or wait for today's tarball to materialize) now supports nicely understandable error messages for coder module (and way better error messages for its standalone mode just as well) with links to the actual documentation explaining the underlying causes and details. This will hopefully end up in a new release very soon.

So do you have any excuses left to not write nicely translatable Drupal module interfaces?

I am way behind in blogging about DrupalCon Boston 2008, which was truly a blast. It was the biggest and best organized Drupal conference so far, and was put together in record time. I was happy to come early to Boston and stay a bit more with people who had their flights cancelled, and others who simply live in Boston to tourist around the city as well.

The conference provided lots of opportunities to be productive on-site in the BoFs and on the code sprint which followed the conference. Honestly, I intended to work on some of my core modifications for filters which (unfortunately) are still not in patch form, but without network connection for a considerable time, I needed to look into what I have on my computer, and figured I should work on the top priority contrib issue in my projects, as identified at the BoFs. Read on to find out more.

It looks like the list of sessions for DrupalCon Boston is finalized, so I am happy to announce, that we are going to have a Multilanguage Drupal: a status report and a discussion session, which is going to cover the current state of Drupal 6 and a short overview of contributed modules, and should end up in a vibrant discussion on where Drupal 7 is headed as far as language support goes. There is a huge interest in multilingual support with around 20 modules hosted on drupal.org already. Come and discuss where Drupal is heading, Drupal 7 is in need of hands to advance in this area.

While most of what Drupal core lacks is user entered content translation and localization, and the above session will focus on this, I also added a BoF suggestion which deals with (built-in) interface localization exclusively. Localization tools for Drupal teams and users is expected to focus on tools like l10n_client and l10n_server and related technologies.

In my working hours, I am busy with better support for WYSIWYG editors in Drupal 7 these days, so I am co-hosting a working group BoF with Doug Green titled WYSIWYG Working Group for 7.x core which should be a discussion of proposals on fixing current WYSIWYG integration problems and weaknesses.

At last but not least, Kristof Van Tomme is proposing Szeged, Hungary for DrupalCon Europe 2008, and he intends to hold a discussion BoF on this. The Drupal Association also intends to have a discussion meeting (not open for the public) on the next DrupalCon, so whether this BoF happens is still to be seen. In any case, I am one of the firm supporters of a DrupalCon in Szeged, and I am confident Kristof would be able to lead effectively to get it done in good quality. The easily digestable version of the proposal is up at Proposing Szeged, Hungary for Drupalcon Europe 2008 (look for the attached PDF).

And, well, honestly this is all just peanuts to what all DrupalCon Boston has to offer. So if you are still wondering, whether to go or not to go, make sure you reserve your place! It's a must.

Several people asked me to post about the status of the localization server, so here it goes. This project was started originally by Bruno Massa, then picked up by me as part of Google Summer of Code 2007 aiming to replace the Gettext and CVS based workflow for translators, providing a fully web based translation interface. One of the cool things of working full time on Drupal at Acquia is that I have capacity for spare time developments like this one. That's great.

Through the development of the Localization Server project, I decided that it is important that we use icons instead of boring text links especially that we need to communicate lots of different things and provide action buttons for multiple options in a small space.

We do not (yet?) have a graphics artist to help out here, so it turned out that whatever icon set we choose, there will be some problem with the icons size, the exact set of icons available, their color, and so on. So it occured to me that we have a huge set of symbols already in the Unicode character set which Drupal is using, so why not use those as icons?

GMail's labels, Mint's Peppermill site and others already use a trick to wrap a few tags with specific margins to get a rounded cornered button feel, and putting a Unicode symbol in as text makes for a useful button. It is definitely not as perfect as specially tailored icons, but it allows for a few neat things. Let's see...

The current Drupal process of translating with Gettext PO files, trying to get them into CVS before a release file is generated and then going over hops to update it properly is far from ideal. There are lots of drawbacks, and I started working on a web interface this summer, sponsored by the Google Summer of Code program to improve this situation. Unfortunately the server is not yet ready for prime time (on drupal.org), but there are a number of beta testing servers where some translation teams already try to leverage the cool things this tool offers, so I have lots of feedback on the issue queue.

In the last two weeks, I spent a sizable amount of my free time on improving the navigation user interface, and adding team features to the localization server, which resulted in a huge changeset, and consequently an 5.x-1.0-alpha2 release of the module, which is now available for download.

I put in a lot of thought into designing an interface which is both easier on the newcomers and on the experienced translators, but honestly I focused more on the experienced translators with as easy access to their work as possible, implementing "quick jump forms", direct linking possibility to the translation filter pages, and so on. Note that I am not a professional interface designer, I make plans up as I go along, based on user feedback and my own focus areas.

While there is still lot of room for improvement, I believe this user interface update makes using the application easier. I tried to concentrate on emphasizing the application aspects, but honestly this is not easy when you don't have control over the theme your application is displayed with. I played with adding a web application theme into the mix and requiring that for Localization Server onwards, but then decided that this can be done later if desired. For now the navigation changes can live well with any theme not exactly focused on web applications, but web sites. I see however that in the not so distant future, I might need to tie the interface to a theme, because that allows proper focus on a usable application interface.

Check out some screenshots of how the current interface looks on my Flickr account. Next up is fixing some remaining bugs, as well as new bugs introduced with this navigation interface update and finally improving on the translation interface itself.

In my short free hours the last few days, I was brainstorming on new features for the translation template extractor (this little module which extracts translatable strings from Drupal modules) to make both the translators and Drupal coders life easier. Today I am proud to announce, that I released the old stable code as Potx-5.x-1.0 and Potx-6.x-1.0 (which signifies that the development code was quite stable for some time now) and wandered to implement new features for the 2.0 versions of the modules.

Our localization tools and approach help us a lot in making the Drupal interface better, but we did not make use of these great features so far. I hope to involve you in making Drupal 6 even better with two simple ideas, which only require very simple tools, so anyone can contribute.

As a maintainer of Drupal's locale module I try to find creative ways to help people localize their sites. Our focus in Drupal 6 was on more features for content translation and interface translation imports, while the built-in locale interface was nearly untouched. We even complicated it a bit with the textgroups feature which might or might not get used by contributed modules at the end. 

In a previous post, I announced the new localization client module which strives to solve some of the problems with the built-in locale module translation interface by bringing an AJAX powered widget close to the site translator. While this module is a very good looking way to solve the translation problem, it has two weaknesses:

• You can only translate what you see on the site pages you browse by. Some text is only shown in emergency, when form values are not filled properly, when some backend data is not accessible, etc. Some text is even restricted to different user groups. So you can only translate the most visible parts of your site.
• Closely connected, but slightly different issue is that you cannot translate strings with plural versions at once. If your page shows 3 years ago, you can translate @count years ago but not 1 year ago (the singular form) or @count[2] years ago and friends, which are used when the language in use has more then two plural forms. The Drupal database gives no clue in relating these for translation, so we cannot help users intending to translate all these at once.

Although locale module provides a more complete solution, allowing you to have a translation percentage overview as well as filter untranslated strings and work on them, you are still restricted to the same old, hard to use interface. If you'd like to improve on the interface issue, you can switch to use potx module to extract Gettext translation templates from your modules, then use some desktop Gettext editor which suits your taste and then import the translation back to your site. For most people though, the "favorite Gettext PO editor" question is like asking about the best time to go to the dentist. If we can do better, then why not?