Blog

Translation Management is making its first steps. The new handbook gives a preview of the main features and how the module will work.

The idea behind the module is to implement much of our translation process in a Drupal module, so that everyone who needs to run complex multilingual sites can use.

Unified Translation Editor

The heart of the module is the unified translation editing screen. Translators will use this single screen to translate anything.

Be it nodes, CCK, blocks or even interface strings. The translators don't need to know where to translate these in the Drupal admin. The module will collect everything that requires translation and will display in the same translation editor.

The translation editor will adapt according to what's being translated. For each job, it will include the right fields. Each field shows the original text and the translation.

It also shows which fields are new or modified, so that translators don't need to guess or look for changes.

When they complete translation in the translation editor, the module will send everything to its right place in Drupal.

Managing Translations

Content managers will be able to create new Translator users. Then, they use the Translation Dashboard to send jobs.

The translation dashboard gives a full picture of everything that needs translation. From that screen you can see contents that needs translation, what's being translated right now and what's already completed.

Translation Queue

When content managers send jobs for translation, the module notifies the translators.

Then, each translator has a queue of pending jobs. The translator clicks on each job to start translating.

Want to Get Involved?

Our plan is to have a first working version in about 6 weeks.

We're also going to do a session about it in DrupalCon Copenhagen in August. The session is called Translation Management for the Enterprise.

We're looking for early adopters who want to take the module for a spin. Contact us if that interests you.

First, there were websites (well, there were a few things before...).

Then, came content management systems.

Then, they became multilingual.

And then, problems started - how do we manage all these translations?

Working with Translators

Enterprise clients need a systematic process for managing translations. This process begins with original-language content and ends with completed translations.

In the middle, there's an entire process which includes notifying translators, translation review, quality assurance, building the translated contents in the CMS, maintaining a glossary and lots of other activities.

Translators Don't Speak Druplish

The best translators out there spend all their time translating. They're busy folks (and well paid as well). The last thing they need is to learn about the fascinating aspects of Drupal multilingual administration.

And so was born the title - translations manager / coordinator / administrator. The translation manager goes through the Drupal contents, finds what needs translation, sends it to the translators, gets it back and puts it in Drupal. A full time job if you're running even a medium sized Drupal site.

Enterprise Translation Management

Multilingual websites that have dozens of new articles a day cannot rely on a manual translation management process. They need a systematic solution, where the entire translation process is handled automatically.

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

The idea is to allow enterprise users to run multilingual Drupal sites without reinventing the wheel every time.

The "bread and butter" of translation management (features for this module):

• Tracking of what's translated and what needs translation
• A translator role
• Jobs queue, per translator
• Notification to translators about new contents they need to translate
• Unified translation interface (I'll explain about this in a minute)
• Automatic link adjustment

Unified Translation

When translators translate your contents, they need to translate node title, body, taxonomy, blocks, CCK, interface strings and everything else your site uses. These are a lot of different things, each going to a different place in Drupal.

We don't want to teach translators where to go for everything and which tab to click on.

Instead, we'll have just one translation page. That page will let the translator edit everything. When translators edit, the module will automatically take those translations and put them in the right place. This way, multilingual content management happens automatically.

Sounds Confusing?

It's not a trivial subject. Companies build million dollar systems around translation management. We'll write more and explain each of these features in details.

The good news are, it's more difficult to explain than to use :-)

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.