Blog: Internationalization

Drill Down Faceted Searches Based on Language

Sometimes it's easy to forget that less than half the web is in English. However, when managing large sites in multiple languages, it's good to be constantly aware of what language you're working with. That's why we wrote internationalization support for the ApacheSolr search module.

You can see how it works in this screencast.

With the new patches and a slight change to the search index schema, ApacheSolr will store the languages you choose with the i18n module. Then you can enable the Language Filter block to perform faceted searches based on language - to drill down to those that you speak or read.

Adding this and other extensions to ApacheSolr is possible because Solr itself uses a flexible schema to store document data. Adding an indexed language field was as simple as appending

   <field name="language" type="string" indexed="true" stored="true"/>

to the site's schema.xml file. This flexibility also allowed for a few other tweaks to the search engine, so stay tuned.

You can download the new patches and be sure to make the change specified to your schema.xml file.

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

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.