Blog: I18n

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:

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

Making It Possible To Collect User Information in Five Languages

The United Nations Millennium Campaign gathered millions of people around the world this week to stand up against poverty and in support of the UN’s Millennium Development Goals. We were heavily involved in developing the Stand Up Speak Out campaign's Drupal website,  StandAgainstPoverty.org, and had a great time adding some interesting and important features to the site.

A very important part of that development work revolved around the need to make the site viewable in five languages (English, French, Portuguese, Spanish and German, for those keeping score). The real trick was that the campaign wanted to collect information from the people visiting their website using their CRM system - Democracy In Action's (DiA) Salsa toolset - but the toolset only handled information in English. I'll explain in this blog post how we used Drupal to get DiA's CRM to also handle information in the site's other four languages.

We used a number of i18n-related modules to make translation easy and integrated several forms created using DiA in a way that made the forms i18n-friendly for fast translation. The approach described below is not ideal, but it was executable in the short timeframe in which we were operating. Ideally, we'd make better use of DiA's API so that form-creation is accomplished in DiA's Salsa interface, and Drupal could query the details of the various form pages and build Drupal forms on the fly with that data.

Given our time constraints, we built the forms manually. For anyone who needs to quickly build forms in Drupal, I can't recommend the Forms API Quickstart Guide on Drupal.org highly enough - it helped shake out the cobwebs.

Building the two forms was straightforward enough. I began by adding a menu callback to my module, then added the page building function, and then built my form out.

// Menu callback
	$items[] = array(
		'path' => 'path/to/my/form',
		'title' => 'DiA Signup Form',
		'callback' => 'dia_signup_page',
		'access' => TRUE,
	);

[...]

// Page building function
function dia_signup_page() {
	return drupal_get_form('dia_form');
}

There are several things to keep in mind here. First, in order to make these forms available to the l10n_client for easy translation, you will need to wrap your field titles in Drupal's t() function.

// Sample form field
  $form['dia']['First_Name'] = array(
    '#type' => 'textfield',

		// Make translation easy--always use the t() function!
    '#title' => t('First Name'),
    '#size' => 30,
    '#maxlength' => 64,
  );

In Drupal, you can save your hidden form fields and add them in your form submission function, thereby eliminating another place where unexpected client input may cause headaches (or worse). DiA forms make heavy use of hidden fields when custom data is collected or when user submitted records are added to DIA groups.