ICanLocalize is migrating its proprietary closed translation management system into an open-source Drupal translation management module.

We are aiming at having an initial beta release of the module towards the end of next week if all goes to plan.

What's done:

• Add/Edit Translators - specifying which uses can be translators and what languages they can translate from and to.

Drupal's t() function allows translating texts from one language to others. In order to work right, you must create texts that translate well. We’ll show you frequent mistakes and how to correct them.

Localization 101

Once you've created a site, using the t() function, Drupal will scan the texts and send them to translation. The String translation mechanism allow replacing the texts in the original language with texts in other languages.

Translators cannot change anything else in the site or in the HTML. They only translate the texts that you give them.

Some of the things that translators cannot do:

• Change the order in which texts appear
• Merge or split texts
• Translate texts that are not inside the t() function

Give your translators complete sentences

When translators get single words to translate, it's practically impossible to translate them correctly. They need to see full sentences in order to translate with meaning.

A common case is the login message:

You must be logged in to post a comment.

Too often, folks create this message using this code:

<?php print t('You must be') ?> <a href="<?php print url('user/login') ?>">
<?php print t('logged in ') ?></a> <?php print t('to post a comment.') ?>

This means that the translator now sees three strings to translate:

You must be
logged in
to post a comment.

Each of these strings makes little sense.

Did you know that the English word "be" has several meanings in Spanish?

Be can mean what you are (ser) or where you are (estar). Translators cannot tell which one you mean when they just see "you must be".

To fix this and create a sentence that translates well, we'll merge all these strings into a single sentence, as it's supposed to be in the first place.

We'll use placeholders to insert values from other functions into the sentence.

<?php print t('You must be <a !link>logged in</a> to post a comment' ),
 array('!link' => 'href="' . url('user/login') . '"') ) ?>

Now, it's crystal clear. The translator sees one sentence, from start to finish. If needed, the translator can swap between parts of the sentence and write it correctly in any language.

Beyond complete sentences

When we create multilingual sites, we need to remember that translation is not everything. Localization means adapting the site to a different language, country and conventions.

We need to create interface strings that allow adjusting things like:

• Number formats
• Date formats
• Units
• Phone numbers (adding country codes)
• Addresses (adding the country)
• and many others...

The first and most important step is understanding. Once we understand that localization only begins with adding t() functions, we'll create much better websites that read natural in any language.

Gábor Hojtsy and Robert Douglass will be talking about internationalization and localization at DrupalCon SF. Parlez vous Internet? Ignore the rest of the world at your own risk.

If you are going to the conference I hope you can make it. It should be very interesting.

<self-promotion>

A common question we get asked at ICanLocalize is:

What's the best way of translating our Drupal site with minimum downtime and minimum disruption to our existing users.

I guess there are a number of answers, this is one method.

Create a test (Quality Assurance) server

Here I'll show you how to set up a test site that's a copy of your original site so that you can then use this to setup a multilingual site. You will then be able to use this test site to add the required multilingual modules, enable your languages and translate your content.

cp -Rpv /home/bruce/drupal-6.15 /home/bruce/drupal-6.15-QA

$db_url = 'mysqli://username:password@localhost/drupal_db_QA';

$base_url = 'http://localhost/drupal-QA';

<VirtualHost *:80>
  DocumentRoot /home/bruce/drupal-6.15-QA
  ServerName localhost
 
  <Directory /home/bruce/drupal-6.15-QA>
    AllowOverride All
  </Directory>
</VirtualHost>

apache2ctl restart

Now you should have a complete duplicate of your site running at:
http://localhost/drupal-QA

You can now go ahead and setup your translated site.

• Add languages
• Add modules, i18n, ICanLocalize, etc
• Enable language switch block
• Translate the content
• etc

See our how-to guide for further info: Setup for a multilingual site

Once you have finished setting up your multilingual site all you need to do now is follow some of the above steps to copy your translated site back to your production site.

Note for ICanLocalize users: When moving the ICanLocalize settings to the production server you will need to ask the ICanLocalize team to change the settings on the ICanLocalize server so further translations are sent back to the correct server.

A client recently had a problem where content that was sent for translation wasn't translated fully. The returned translation was only half done and appeared to be truncated. After a quick investigation I discovered there was an error in the HTML for a node.

Instead of:

<a href='...'>link text</a>

they had:

<ahref='...'>link text</a>

(a space was missing between 'a' and 'href')

Many times, browsers manage to display pages with broken HTML, so it's difficult to notice there's a problem. In this case the link is missing but the text is all there.

Broken HTML leads to problems

This is what ICanLocalize does when you send content for translation:

1. The node title and body text are sent to the ICanLocalize server
2. The ICanLocalize server parses the HTML
3. The HTML parser extracts the text for translation

The HTML parser extracts the text in such a way that translators only have to edit text and not HTML tags. While translators are editing, a preview panel shows them how the translated document would appear.

Our parser is fairly robust but obviously in this situation it failed.

Remember that the ICanLocalize server is not the only computer to process your pages. Search engines (a.k.a Googlebot) read your pages and try to make sense of them. When they encounter broken HTML, they get confused. Parts of the page, or even entire pages can be lost if search engines cannot process them and cannot follow links.

Make sure your HTML is valid

Before sending content for translation it's always a good idea make sure the HTML in your nodes are valid. I've done a quick search for drupal markup validation modules and this one looks useful: http://drupal.org/project/w3c_validator

You can use the validator directly: http://validator.w3.org/

My personal favorite is the Firefox HTML validator. It's pretty simple. Green means GO, red means no-go and yellow means check. You get instant validation for entire pages as soon as you save the first draft.