Blog: Internationalization

Getting Webforms Into Arabic and Other Right-to-Left Languages

Ever think about trying out Drupal's right-to-left (RTL) language support for languages like Arabic or Hebrew? We got to test it out for a project we're working on with the SEEP Network, a support system for microfinance and microenterprise communities around the world. Currently they're working to build the capacity and improve the services and performance of organizations within national and regional-level networks of microfinance institutions. To get feedback on their efforts and track changes that occur, they needed a tool that would allow members of these networks to give them feedback directly. And since these members speak many different languages - including RTL languages like Arabic - we got to try out Drupal's support for this while building their survey tool.

The key to RTL language support in Drupal 5 is the internationalization module (i18n), and Jose reminded me that there's a great documentation page on using RTL languages on Drupal sites here. 

In a nutshell, the i18n module allows you to define a language as being a right-to-left language. Then when the site is being viewed in that RTL language, you can make your theme aware of this fact and have it call different or additional CSS stylesheets in order to theme according to the direction of the language. In the case of this webform, we were simply able to call an additional stylesheet after all the other stylesheets were called, which adjusted all the text from left-to-right to right-to-left.

How the Internationalization Package Will Help with Translations

There have been some big advances made in multilanguage support in the latest release of Drupal. As you may have seen, Drupal 6 is multilingual, and it really does a nice job of handling languages and content translations. However, it does still need some help to be able to translate everything.

This is where the Internationalization package comes in, but it won't be the same package you remember. The Internationalization package has come a long way from it's beginnings in Drupal 4.4. After many Drupal core upgrades and the continuous addition of new features, it became the huge collection of modules and tools you saw in Drupal 5. Now that we can rely on Drupal 6 core for the low level stuff and multilingual content, we can finally start simplifying it and trimming down those big chunks of code. We can now focus much more on making it easier to set up, more simple overall, and better integrated. To make sure this happens, we've set some guidelines. 

New Drupal 6 Guidelines for i18n:

• Seamless integration with Drupal core or "Don't try to do better that what Drupal core already does"
• Administrator friendliness or "end this modules and options mess"
• No core patches, just install and play
• Independent modules when possible - you can use the Language Icons module without the rest of the package to add some color to your website

And now for what you've been waiting for.

These Features are in the i18n Module for Drupal 6:

Improving UI Translations Means Greater Usability

Lately we’ve been spending a lot of time on improving the usability of our tools by designing more straightforward user interfaces, building more intuitive workflows, and making sure we’re displaying all the right messages in the right places. But this only gets you so far. When a tool is in a language the user doesn’t speak, all of these usability improvements won’t make up for this barrier. But with recent user interface translation improvements for Drupal, we can improve usability for thousands of websites.

We are well on the way of having these translation problems fixed for Drupal, thanks largely to our great localization guru Gábor Hojtsy who recently released two impressive Drupal modules -  the Localization Client, which provides on-page localization editing, and the Localization Server, which provides a community localization editor.

Here's a look at one of the new tools - the Localization Server:

I’ve spent some good time this month working with them both and wanted to share with you why they are so exciting. But first, let me explain the problem in a little more detail. To have a truly usable interface in different language, you need a high quality translation. And to get that, you need to provide translators with the right tools and an easy to follow workflow so they can get the translations right and be fired up to do the translations in the first place. That’s especially important in the open source software world where we have thousands of translators willing to help but no way for them to easily do so. In Drupal, to translate text in the user interface you have to 1) edit string, 2) export po file, 3) post to the issue tracker, 4) follow up, and 5) have someone else to check and commit it. This inhibits the quantity and quality of the translations in Drupal.  

The two new modules will go a long way towards fixing this problem. 

Localization Client

Gabor's work on translating strings in the right context has produced the LocalizationClient, which allows for “just in time” translation in the same page that the text will appear. Young did some great UI improvements on this while working closely with Gabor and now Drupal sites have this awesome tool. We posted a screencast in the fall if you want to see how the tool works.

On a site-by-site basis, this is a huge improvement. But what if we had better and full translation packages to start with so you almost never had to translate anything? If we can crowd source the translation process and provide the people, even those with no technical knowledge, with an easy way to contribute translations, then we’ll all start off with a bigger translated base of text. The Localization Server helps make this possible. 

Localization Server

Out of the need to streamline the old translation workflow explained above came Localization Server. This module makes it really easy to translate texts and get their contributions into the deliverable language files. This is a great tool for doing community translations and handling different projects and releases.

The goal for this tool is for it to become the future translation interface on drupal.org and integrate with project releases and organic groups, and hopefully that will mean that we'll have a central translation system for every language soon.

Note: Only the l10n server is intended to be used in drupal.org.

Streamlining the Translation Process for Multilingual Websites

Recently we built a multilingual website for the International Council on Archives. Training their staff on how to use the website drove home - again - just how bulky it was to translate text in multilingual Drupal websites. So last week I worked on an update on the l10n_client to streamline the translating process and simply make translating content easier.

Here's a screencast that shows how you can now translate text with the update:

The l10n_client update includes several bugfixes/optimizations as well as some cool new features:

Bugfixes

• The string list now displays translated strings in the target rather than source language.
• Strings are now stored in a hidden DOM tree rather than a javascript array. The array was causing browser slowdowns on some pages with lots of strings.
• Several other small fixes and optimizations.

New Features

• String list "live search"
• Simple keybindings: F1 toggles the l10n_client panel, ESC clears a live search
• Selected-text quicksearch: Hilight a string to be translated and hit F1 to automatically find it in the string list

Many thanks to Gabor Hojtsy, lead Drupal 6 developer and maintainer of the l10n_client module. Also, a big thanks to Jose Reyero who backported l10n_client to Drupal 5. We're now using l10n_client on several multilingual Drupal 5 sites and have gotten very useful feedback from our users. These improvements should find their way back to the Drupal CVS version of l10n_client sometime next week. You can also find Jose's Drupal 5 backport of l10n_client in our repository here:

http://svn3.cvsdude.com/vvc/devseed/sandbox/l10n_client_backport/(Note: requires a patch to the locale module)

Technical Note

• If you're wondering why the search is case sensitive, it is because l10n_client makes use of the JQuery selector :contains. This is an incredibly powerful and fast selector - it more than doubled the speed of l10n_client's search (which was previously case-insensitive but much more costly).