The Variable translation module, part of the Internationalization (i18n) package, allows you to translate text and settings that are stored in Drupal as variables. These variables include text such as 'site name' and 'site slogan', as well as settings like 'Default front page' and 'Default 404 page'.

Dependency

The Variable translation module has a dependency on the Variable module.

Support for Contributed Modules

Variables provided by contributed modules can also be translated by the Variable translation module if they implement hook_variable_info(). For documentation, see the Variable module project page.

Usage

To enable multilingual variables (Figure 1):

1. Enable the Variable translation module included with the Internationalization package
2. Go to Administration > Configuration > Regional and language > Multilingual settings
3. Click on the Variables tab
4. Select the variables that will be multilingual
5. Click Save configuration button

Figure 1

Though for most of the content it will just work, be ready for some missing (multilingual) data and manual reconfiguration.

The module has been fully reworked (again) to keep up with new Drupal core features. There are new modules and features. Many settings have been changed. So please, read all this page before doing anything.

Some old (multilingual) variable values may be lost as for some cases they have been converted to blocks by Drupal core: Site mission, Site footer. Write down the old values for each language so you can use them later.

Multilingual sites are complex enough and each site is a whole different story. Try the upgrade before with a clone of your production site.

Drupal 7 upgrade notes

• You may lose some string and variable translations in the process so you better get a dump of i18n_variable and export your locale translations for textgroups different than default.
• To upgrade from 6.x, first upgrade to the latest 6.x stable release. To upgrade from 5.x, first upgrade to 6.x, then to 7.x
• Other parts like the multilingual block system have been completely reworked and will need manual reconfiguration. Existing normal blocks won't be lost but the language settings will need manual reconfiguration.

The Translation Dashboard gives a full picture of translation status for the entire site.

It shows:

• Nodes
• CCK
• Blocks
• Contact forms
• Interface strings

Here is how it looks like:

The screen includes a display filter, list of contents and translation controls.

For example, you can display all English documents, that require translation. Or, you can view all documents written in English and translated to French and see their translation status.

The documents list shows the translation status per target language. These are the possible status values:

• Translation complete - means that translation is up-to-date and doesn't require any work.
• Not translated - there is no translation at all.
• Translation needs update - the original has changed since it was last translated.
• Translation in progress - the document was sent for translation and translation did not yet complete.

The Translation Management module creates a systematic process for multilingual content management.

It creates a new Translator role. Each translator has a queue of jobs to complete. Translators do all their editing using a unified translation screen. There, they can translate anything, without having to know Drupal's multilingual system.

Content managers have a single Translation Dashboard. From that screen, they can view all documents that require translation and send to the translators.

Both translators and content managers can view the queue of pending translation jobs. They see the amount of pending work and completed work per translator or language pair.

Translators

First, you need to add translators. A translator would be a Drupal user with a special role, created by the module.

A translator role allows:

• Getting notifications about new jobs
• Access to the job queue (each translator has a separate queue)
• Translating using the unified translation screen
• Reviewing completed translations in the public pages

Old functions tt() and ts() have been deprecated. Use i18nstrings() and i18nstrings_update() instead.

The Internationalization module provides translation services for user-defined strings. It also tracks source strings and keeps them up-to-date using a 'string key' that is a string with these elements "textgroup:object_type:object_key:property_name".

Some examples of these 'string keys' are:

taxonomy:term:12:name
nodetype:type:story:name

For translating these strings, the module must call this function before displaying them:

/**
 * Translate or update user defined string.
 * 
 * @param $name
 *   Textgroup and location glued with ':'.
 * @param $string
 *   String in default language. Default language may or may not be English.
 * @param $langcode
 *   Optional language code if different from current request language.
 * 
 * @return $string
 *   Translated string, $string if not found
 */
function i18nstrings($name, $string, $langcode = NULL) {
   .....
}

For strings that have an input format, you must use the function i18nstrings_text() that takes care of applying the correct filters if there is a translation.

/**
* Get filtered translation
*

This is the approach I have followed, there might be others :

This works with 2 languages and the principle is the same with more languages. The idea is to create one new block per language and to invoke some php code to insert the user login block content.