locale

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.

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.

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.

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).