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.

A few days ago, a simple idea came to me, to export all the Drupal interface texts as one big text file and get people spell check and correct things in it, in the hopes that we can turn the fixes into patches. While there are tools for spell-checking Gettext files (the format we use for translations), admittedly, spell checking a simple text file can be easily done in most office suites, simple command line programs, and the fixes are easy to integrate into Drupal. Thankfully a few guys jumped on the idea, and the first batch of trivial typo fixes are now in Drupal 6, leaving space for debates on spelling and wording of some remaining parts.

The logical next step is to improve the wording of Drupal interface elements. Sometimes a shorter explanation would do better, because it would actually be more welcoming for readers, and at the same time in some places, the existing explanations leave some to be desired. We can much more easily spot these problem areas, when browsing around, so if we would have a tool to "touch up" interface text while browsing around, it would help our work. It turns out that what helps people localize sites, is also a time saver here. See how Localization client is useful for improving the English interface itself:

Now for every user with proper permission (including user 1), a tool will appear on the bottom of the page. This allows you to modify any text displayed on the page, effectively fixing the interface for yourself.

Of course the fun does not stop in making all these yourself. To save you time and effort when you update your site later and some string might get modified to serve users better, it is best to share results with the community. You can easily export "My English" on the Locale module export page: Administer - Site building - Translate interface - Export. From here, you get a Gettext PO file with all empty translations and the touch up you provided.

Now everything is left before submitting this in the Drupal issue queue, is to focus this file on the actual fixes. Using the command line msgattrib helper enables you to do just that: msgattrib "en-my.po" --translated > "Drupal-fixes.po". Unfortunately this part is not as easy as clicking around (for people without gettext tools on their machines), but let me ensure you if this is the only part stopping you from submitting considerable fixes for Drupal 6, let me know and I'll help you out or get someone to help you.

Of course because all the above is pretty much automatable and could even live on a central server, an enterprising folk could easily go and set up a temporary site for interface touch-up collaboration. At the end, the result of the group effort can be submitted. Although these suggestions will be made into patches at some point, this is again a good way to help out without knowing anything about writing Drupal patches.

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.

Hit Edit on the item in the result list if found.

A form with all languages are displayed, fill in the translations you want to provide.

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.