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?

Jamie Winchester and Róbert Hrutka formed their band six years ago, but they become well known in Hungary (as far as I know) after one of their songs was used in a local mobile carrier's commercial. Although that was quite some time ago, they release thrilling songs ever since, and the quality of their work is constantly amazing for my ears. Here is one one of their fine songs, titled "Take me home".

We organized Drupal Conference Hungary 2007 for this past weekend. After last fall's first local conference, this was our second big event in Hungary. The conference had more then 150 registrants, so we needed to close the registration in advance to let people have seats in the session room. Unfortunately this year we were not so close to the 90% show up percentage we had last year, so the room was not fully packed. However, this was the only negative point I was able to spot.

Whenever you spot an untranslated string on your Drupal site, you need to:

1. Remember the string or at least some unique identifier from the text.
2. In Drupal 6 go to Administration - Site building - Translate interface - Search tab; in Drupal 5 go to Administration - Site configuration - Localization - Manage strings tab.
3. Enter what you remembered in step 1 and hit submit.
4. Identify the string in the result list or if it is not found, go back to step 1 and find an actually unique part of the string to search for.
5. Hit Edit on the item in the result list if found.
6. A form with all languages are displayed, fill in the translations you want to provide.
7. Go back and check whether the translation was used properly.

This is quite time consuming and error prone. Of course a lot of people suggested that we should have a solution which gets closer to the user, but it was not implemented before. So here I am to tell you that there is a solution for you which just works and eliminates nearly all of the steps above.

Three months ago, I posted a request for people to take over some of my modules, so I can concentrate on supporting the set I am actively developing and using better, and the other modules get proper maintenance going forward from other fine folks in the community. Nearly all of the modules found their maintainers, but I am still searching for a new maintainer for filebrowser module.

This module provides an FTP-like file browsing interface. I developed this for drupal.hu, where we used to have a custom Subversion backed Drupal interface translation repository, this module providing the file browsing interface on top of it. It has highly customizable output already, but has issues which would push it farther away from being an FTP-like browser, and more like a media asset browser.

Let me know, if you are interested. I'd rather orphan the module in a month if nobody is interested in keeping it up. I don't like "pretending" to be a maintainer, when I am not doing actual maintenance on the module.

At DrupalCon Barcelona, I decided to volunteer to fix the "event organization and promotion problem" around Drupal. We had a great "next DrupalCon" BoF where we discussed a lot of bigger and smaller details, and it was decided that we should retain this knowledge. Robert Garrigos announced the BoF initially to hand over the knowledge they learned while organizing the event, so we needed to find a permanent place to write up these notes.

This was also a good opportunity for me to step a bit ahead from the "internationalization and localization guy" stereotype. Now that we are growing the Drupal system to support local and international communities of all sorts, we should improve our infrastructure to help our own communities grow and promote themselfs. That is the next step for world domination, I thought.

I am back home again from DrupalCon Barcelona 2007. I must say that it was a very exciting event. It was fantastic to meet people with whom I last met in person in 2005 in Antwerp (on the first famous meet-in-person developer meeting which was in a hotel basement). The Drupal community grew a lot since then. Dries mentions that last years Brussels conference had 150 people while this years Barcelona event had 450, which means the conference is three times bigger.

FrOSCon was a great conference. Lots of interesting people, lots of new information shared and discussions participated in. Although I did not have time to process and upload the photos yet, I found Bonn, Cologne and Sankt Augustin to be perfect places to stay in.

One of the best things about the conference was that all our sessions were recorded, so you can not only download my slides, you can also see me having my first mistakes with presenting on a Mac. After all, I am a recent convert, and I still use the Mac and my Ubuntu side by side. Pushing aside the issues caused by the first time I presented with a Mac, I think I did a fairly good job of giving an overview of all the hard work of people who contributed a huge amount of their work to make Drupal 6 work better in different languages.

With the support of the Drupal Association, I traveled to Bonn this Thursday and played the tourist around the city that day. I have been to Cologne yesterday (have seen fantastic sights in both cities), and we ended the day with a nice dinner with people here for the conference and guys from the local user group. See some of Morten's pictures which are already up.

We also ended up at our hotel for some night drinks, and I actually met with some of the nice people I know well from the PHP community (from my previous deeper involvement with the PHP project). It turned out that I switched from the Drupal guys table to the eZ Publish table (lots of people staying in the same hotel). All-in all everybody is very nice, we mixed up quite well.

The conference is also going well, although there are lots of German talks, which some of us can't understand unfortunately. But this means we are progressing with core patches in the meantime, so if you have some pet issues, be sure to continue work on them.

Again, thanks for the Drupal Association for sponsoring the event, I would not be able to make it without their support! And special thanks to Robert Douglass, who had a very good sense of flawlessly organizing the Drupal presence so far.

To cater to the needs of multilanguage websites, Drupal and other content management systems should take into account the different uses of these sites and the unique content and interfaces they provide. For example, a search site where content will not be translated might need different languages in its interface, while a personal blog where posts are entered in different languages might need many different features.