For Drupal 7, see the Variable Translation module documentation.

Some text and settings are stored in Drupal as variables, and some site-wide ones like 'site name' and 'site slogan,' along with module-specific ones, can be edited through the administration pages. The Internationalization package makes it so these variables can be translatable.

To enable these variables to be translatable we need to identify the low-level names Drupal uses for them. This can be done looking at the 'variable' table in the database or searching through the code. However, we'll show you how to translate the more common settings below.

Once you have identified the variables you want to be translated, they need to be added in the settings.php file for the site as follows:

/**
 * Multilingual settings
 *
 * This is a collection of variables that can be set up for each language when
 * internationalization (i18n) is enabled. These are the basic ones for Drupal
 * core, but you can add your own here.
 */
$conf['i18n_variables'] = array(
  // Site name, slogan, mission, etc..
  'site_name',
  'site_slogan',
  'site_mission',
  'site_footer',
  'anonymous',
  // Different front page for each language
  'site_frontpage',
  // Primary and secondary links
  'menu_primary_links_source',
  'menu_secondary_links_source',
  // Contact form information
  'contact_form_information',
  // For theme variables, read more below
  'theme_settings',
  'theme_garland_settings',
);

About theme related settings, they're stored in a different variable for each theme, which is usually 'theme_THEMENAME_settings' and these are merged with the default theme settings in 'theme_settings'. Some themes may have other specific variables so you may need to take a look at the 'variable' table (or use devel module) to see how they're stored.

The configuration file is usually under /sites/default/settings.php or another subfolder under sites. Also, there may be more than one if you are using a multisite setup.

Once you have the correct settings added to your configuration file, they'll be marked as 'multilingual variable' when you go to the corresponding administration pages. You must switch the site language while in the administration pages to set the value for each language.

The values of the multilingual variables will be saved in the i18n_variable table.

Find the settings file in the attachment.

AttachmentSize
446371032_5066593810.jpg23.19 KB

Comments

Pepe Roni’s picture

You must switch the site language while in the administration pages to set the value for each language.

And you must also switch the presentation language to match the site language. If not, it will mess up.

And, don't forget to change the site and presentation language each time you maintain the site information, otherwise you will mess up your site information strings.

Nice feature, and so user-friendly :(


..........
Wilfried
Drupal: a CMS without typo in its name
FiNeX’s picture

Not all variable works. Look at http://drupal.org/node/482800 .

tomsm’s picture

When an administrator adds a user, his presentation language must be the same as the user's language in order to send a welcome e-mail in the correct language.

I have done this test: I added all user configuration variables to settings.php.
Then I translated the "user_mail_register_admin_created_subject" and body field. I translated the English text to French.
When I add a user using English as presentation language, select French as the user's preferred language, the received welcome e-mail is in English.
When I do the same using French as presentation language, the e-mail is in French.

I think that the language used by an administrator shouldn't determine the language of a welcome e-mail sent to a user. This language must match the preferred language set for that user by the administrator.

Is there a solution for this problem?

dddave’s picture

bsimon’s picture

Like a lot of the i18n features, this can be hard to understand the first time, so here's a more detailed explanation of some steps.

To keep things simple to begin with, just change one feature, the default front page for each language. This is a good place to start because the default front page seems to be the most obvious feature that simply will not work properly on a multilingual site (unless you follow the instructions on this page or figure out some other hack/workaround).

1. As explained above, add some code to the end of settings.php. If uncertain, make a backup of settings.php first. You probably need to temporarily change the permissions for settings.php to 644 to edit it. Change back to 444 after you save it.

The difference between this code and the code above is just that the '//' at the beginning of most lines makes those lines into comments so they have no effect. Remove '//' later when you're ready to implement each feature. It's easier to understand what's going on if you just change one thing at a time.

/**
 * Multilingual settings
 * 
 * This is a collection of variables that can be set up for each language when i18n is enabled.
 * These are the basic ones for Drupal core, but you can add your own here.
 */
$conf['i18n_variables'] = array(
  // Site name, slogan, mission, etc..
//  'site_name',
//  'site_slogan',
//  'site_mission',
//  'site_footer',
//  'anonymous',
  // Different front page for each language
  'site_frontpage',
  // Primary and secondary links
//  'menu_primary_links_source',
//  'menu_secondary_links_source',
  // Contact form information
//  'contact_form_information',
);

So we only actually added 'site_frontpage' at the moment. Every other variable is behind a '//' and has no effect.

2. To test this new i18n variable, it's best to have the standard language switcher block enabled on every page. If you can't see it, enable it at Administer › Site building › Blocks

3. Now go to the admin page Administer › Site configuration › Site information

And... because of the new variable, 'site_frontpage', that you just added to settings.php, 'This is a multilingual variable' should have appeared after 'Default front page' . If not, it probably means your change to settings.php was not effective for some reason.

4. Next, click on the switcher block to change to one of the other languages you are using

Obviously, this should change the language for the whole page - that's normal, but you should also see that the language prefix in the path after 'Default front page' has changed. (the prefix is the two letter language code such as /en/, /fr/, /de/, /es/, /fr/, /zh/, etc)

5. Now, after 'Default front page', type the location of the other language's front page.

6. If you stay on the Site Information page and switch languages on the switcher block, you can immediately see the Default front page path change to match it.

7. Repeat from step 4. for all the languages you're using.

janbolat’s picture

I couldn't understand what is 'Default front page' on step 5?
could you please show these things on picture...
I have 'This is a multilingual variable' text near those strings...
But I can;t change them for each language

bsimon’s picture

The default front page setting in step 5 is on your Drupal site administration page: example.com/admin/settings/site-information

If the multilingual variables are working OK, it should look like this.

http://img296.imageshack.us/my.php?image=drupali18nsettings2uc1.gif

But I think it's possible to see the 'This is a multilingual variable' text sometimes even when it's not working properly.

ping3608’s picture

Disable module(Internationalization tests)

ShutterFreak’s picture

If you also want to be able to set the default menu for nodes, then make sure you also add 'menu_default_node_menu' to the list of localizable variables in settings.php.

Mehrdad201’s picture

I have done this modification in settings.php

but only site name and default page have become multi language

the other variables such as slogan or mission are still no change

Please help me

what is my mistake?

menros’s picture

Thanks for this helpful guide.
I've followed it - and it works great.

I would like to go further and make my site more 'multilingual', i.e the new user registration help message, the e-mail that notifies a new user that the account is waiting approval, the wellcoming e-mail message with the account details, and more...

where can i find the name of these variables, so i can add them as more lines in the list at the end of settings.php?

many thanks

bsimon’s picture

You can often find the variable names just by looking at the source (in Firefox, select the relevant section, right click, choose 'view selection source' and look for a field like name="some-variable")

But for some types of variables (for example theme variables), this method will only appear to work. You get the 'This is a multilingual variable' message, but actually it doesn't have any effect.

In that case, you can also find the variable names in the database, as briefly described here: http://drupal.org/node/333796
Just using this method on its own will not display 'This is a multilingual variable', even when it's working.

I've got this working with a few variables that I needed to make multilingual (such as posting date formats and the logo path), but I don't know if these two methods will work in every case.

Also, for some of the things you want to do, it's possible the 'Translate interface' option in Admin might be the way to go.

pjunker’s picture

The Solution doesn't work for me. I added the multilingual variable to the settings.php and a frontpage link for my second Language in Administer->Site Configuration. The Switching of the Frontpage to my second Language works but the switchback to the default language not.

link of the default language: mysite.com/node/3
link of the second language: mysite.com/en/node/4

If i want to switchback drupal takes the link: mysite.com/node4 and not mysite.com/node/3

Where is my fault? or is it a bug? Can somebody help me?

fp’s picture

I ran into a similar issue and here's the little magic (it really is!) I have done to get it to work:

* If I read you correctly you have set the Language negotiation to path prefix
* If so, you need to set a prefix for your default language (and remove it right after if you want): go to admin/settings/language/edit/{default_lang} and set the path prefix to something meaningful then save. Then, if you want, remove the path prefix entirely and save.

Then you should be good to play with language specific variables.

dddave’s picture

It is vital to run Cron after making something a variable.

After that you can make your changes per language.

iva2k’s picture

One thing is not clear - how one adds variables found in a contributed module? For example, I want to provide multilingual settings in the iTweak Login module. I want to execute this code:

  $conf['i18n_variables'] += array(
    'itweak_login_register_button',
    'itweak_login_register_button_name',
    'itweak_login_register_name',
    'itweak_login_recover_name',
    'itweak_login_recover_url',
    'itweak_login_login_button_name',
  );

Questions:

1). Where is the correct place - some hook or toplevel of .module file? Can anyone shed some light on that?

2). I searched for 'i18n_variables' (grep) in whole drupal-6.12 directory - zero results. Is there a specific contrib module that needs to be installed?

--
iva2k

FiNeX’s picture

I've the same question... how to add a multilingual variable to a module?

FreddieK’s picture

Anyone's found a solution?

a6hiji7’s picture

Your code is perfectly correct except that there is no need of that +. You can add any variable to the array of i18n_variables and they will become multilingual. Just go to the module's settings page (or wherever the variables are saved) and you will see the text "This is a multilingual variable" added to the description of the field. Then switch languages to add the different values.

strellman’s picture

After you set a variable as multilingual be sure to save the default version first before translating it or you will lose your default.

Here is what we use at the bottom of settings.php:

/**
* Multilingual settings
*
* This is a collection of variables that can be set up for each language when i18n enabled.
* These are the basic ones for Drupal core, but you can add your own here.
* Find them by looking through source of page for name=
*/
$conf['i18n_variables'] = array(
'theme_default',
'file_directory_path',
'menu_primary_links_source',
'menu_default_node_menu',
'nice_menus_custom_css',
'site_mail',
'site_name',
'site_slogan',
'site_mission',
'site_footer',
'anonymous',
'site_frontpage',

/* User configuration */
'user_registration_help',
'user_mail_register_admin_created_subject',
'user_mail_register_admin_created_body',
'user_mail_register_no_approval_required_subject',
'user_mail_register_no_approval_required_body',
'user_mail_register_pending_approval_subject',
'user_mail_register_pending_approval_body',
'user_mail_password_reset_subject',
'user_mail_password_reset_body',
'user_mail_status_activated_subject',
'user_mail_status_activated_body',
'user_mail_status_blocked_subject',
'user_mail_status_blocked_body',
'user_mail_status_deleted_subject',
'user_mail_status_deleted_body',

/* Node help */
'blog_help',
'story_help',
'contact_form_information',

/* Location */
'location_default_country',
'location_settings_user',

/* Invite */
'invite_subject',
'invite_default_mail_template',

/* User_relationships */
'user_relationship_mailer_request_subject',
'user_relationship_mailer_request_message',
'user_relationship_mailer_cancel_subject',
'user_relationship_mailer_cancel_message',
'user_relationship_mailer_approve_subject',
'user_relationship_mailer_approve_message',
'user_relationship_mailer_disapprove_subject',
'user_relationship_mailer_disapprove_message',
'user_relationship_mailer_remove_subject',
'user_relationship_mailer_remove_message',
'user_relationship_mailer_pre_approved_subject',
'user_relationship_mailer_pre_approved_message',
'user_relationships_ui_msg_submitted',
'user_relationships_ui_msg_accepted',
'user_relationships_ui_msg_disapproved',
'user_relationships_ui_msg_cancel',
'user_relationships_ui_msg_default',
'user_relationships_ui_msg_removed',
'user_relationships_ui_msg_pending',
'user_relationships_ui_msg_pre_approved',
'user_relationships_ui_msg_too_many_relationships',
'user_relationships_ui_msg_existing_request',
'user_relationships_ui_msg_existing_relationship',
'user_relationships_ui_msg_not_accepting_requests',
'user_relationships_ui_msg_self_request',
'user_relationships_ui_msg_non_existant_user',
'user_relationships_ui_msg_non_existant_type',
'user_relationships_ui_msg_unknown_error',
'user_relationships_ui_msg_relationship_type_not_set',
'user_relationships_ui_msg_relationship_type_not_allowed',
);

joch’s picture

Add to above list

.. $conf['i18n_variables'] = array(
'theme_default', ...

/* the next line make a theme vars Multilingual */
'theme_xxtheme_settings', /* xxtheme = name part of file in theme, xxtheme.info */

'logo_path',
);

kasiawaka’s picture

I read a lot of documentation and error reports and I could not setup the multilingual logo as described, by using logo_path and the theme settings variables.

I did some investigations and here is the solution that works for me:

1. In settings.php file, add to the $conf['i18n_variables'] array the value for your theme, for example:

$conf['i18n_variables'] = array(
       ...
	'theme_XXX_settings',	
);

where XXX is your theme name.

There is no need to add "theme_settings" or "logo_path" variables. In fact, adding "logo_path" variable caused the logo to not display properly.

Then, visit the theme settings page (admin/build/themes/settings/XXX) and change the theme logo path. The field will not display information that this is a multilingual variable but in fact, it is, because if you save different logo for EN and for other language, it will preserve the value.

A note on the background:
The table "variable" holds values for all Drupal variables. Adding any variable name in the settings.php in array $conf['i18n_variables'] will cause the system to look for the values for this array not in the "variable" table but in the "i18n_variable" table. Thus if experiencing any problems, please check the i18n_variable table to make sure it has values for all your languages for your theme and that it doesn't have logo_path values.

Kasia

Kasia W

ngstigator’s picture

thanks! ran into this on a recent upgrade and removing 'logo_path' fixed the problem for me.

chris

rvallejo’s picture

While dates (months, day of week, etc) should automatically be translated, I got localized/multilingual date formats to work the same as described above. I found this to be helpful, for example, when displaying dates as "April 1, 2010" when viewing the site in English, and "1 de Abril 2010" in Spanish. Under Multilingual Settings in the settings.php file, add the variables below, run cron and select/save the formatting option for each language:

'date_format_short',
'date_format_medium',
'date_format_long',

jessicakoh’s picture

For those who's not getting it, take another look at Germinal's final comment. It helped too.

ttp://drupal.org/node/313272#comment-1207713

aschiwi’s picture

For those people this isn't working for: Check your settings.php - if you have uncommented the existing $conf = array( (for example to change the default maintenance theme). This might work if you're not seeing the "This is a multilingual variable".

funana’s picture

Install the "tcontact" Module: http://drupal.org/project/tcontact to translate the contact form and the auto-replies. You need to define at least one contact category per language to do this.

adrianmak’s picture

How about different front page layout of a multi-lingual site ?
Drupal provided a custom template page-front.tpl.php to customize front page.
Say,
Engish is a 2-3-2 column front-page
Spanish is a 1-6 column front-page
French is a 2-5 column front page

dddave’s picture

I think this could be easily done with panels.

adrianmak’s picture

I need only different layout on front-page as per language. That's all.
Therefore panels is too much for my case.

iva2k’s picture

Asking users to edit settings.php for each multilingual module they install is just not right. It brushes against modular nature of Drupal. I believe developers should have some means to mark variables in their module as multilingual.

I used the following code:

/**
 * Implementation of hook_init().
 */
function MYMODULE_init() {
  $variables = array(
    'MYMODULE_variable1',
    'MYMODULE_variable2',
  );
  $i18n_variables = variable_get('i18n_variables', array());
  $i18n_variables = array_merge($i18n_variables, $variables);
  variable_set('i18n_variables', $i18n_variables);
}

I should note that it is not very wise solution from performance perspective. It does not use global variables cache, and it is executed regardless of the i18n module use on a particular website.

Looking for a good implementation I tried the same code in hook_install() where it would run only once. But I discovered that it won't work. Core function variable_init() will use a value which is set in settings.php over any value saved to the database. And it is the current way for 'i18_variables' to be set in settings.php if you want to have any of the core variables translated. So hook_init() looks to be the only working place for contrib modules.

--
iva2k

droshani’s picture

I do not get any statement "This is a multilingual variable" for Slogan.

These are my setting in setting file

/**
* Multilingual settings
*
* This is a collection of variables that can be set up for each language when i18n enabled.
* These are the basic ones for Drupal core, but you can add your own here.
*/
$conf['i18n_variables'] = array(
'theme_default', (adding this did not make any difference)
'site_name',
'site_slogan',
'site_mission',
'site_footer',
'anonymous',
// Different front page for each language
'site_frontpage',
'menu_primary_menu',
'menu_secondary_menu',
'contact_form_information',
// Primary and secondary links
'menu_primary_links_source',
'menu_secondary_links_source',
// FAQ variables
'faq_title',
'faq_description',
'faq_question_label',
'faq_answer_label',
'faq_back_to_top',
);

fmjrey’s picture

I was trying to make some variables become i18n in simplenews module. I did not want users to have to modify settings.php and preferred a coded solution. So I considered what was suggested in iva2k's comment and clandmeter's reply, which is to use the hook init:
http://drupal.org/node/313272#comment-2786004

However this was not enough, variables were tagged as "This is a multilingual variable" but no translation was possible. After a few trial and debugging sessions I realized i18n variables were in fact initialized only once in the hook boot of the i18n module, that is, before the init hook had a chance to declare the i18n variables.
So in the end I had to implement the boot hook like this:

function simplenews_boot() {
  global $conf;
  $conf['i18n_variables'][] = 'simplenews_confirm_subscribe_unsubscribed';
  $conf['i18n_variables'][] = 'simplenews_confirm_subscribe_subscribed';
  $conf['i18n_variables'][] = 'simplenews_confirm_unsubscribe_subscribed';
  $conf['i18n_variables'][] = 'simplenews_confirm_unsubscribe_unsubscribed';
  $conf['i18n_variables'][] = 'simplenews_confirm_subscribe_subject';
  $conf['i18n_variables'][] = 'simplenews_confirm_subscribe_page';
  $conf['i18n_variables'][] = 'simplenews_confirm_unsubscribe_page';
}

From then on translations were retrieved by the variable_get function.
But in case you want to apply this solution in your module, make sure it's weight and name make its hooks called before the i18n module.
In my case the simplenews module is not weighted (weight=0 in system table) whereas the i18n module has a weight of 10, so that means the simplenews boot function was called before i18n boot function, allowing the former to declare it's i18n variable before the latter can modify the values of i18n variables according to the page language.
For more info see http://drupal.org/node/54902#comment-104509

Anonymous’s picture

Had this same issue - with the weight setting, but also:

My form field names were not using the same name as the variables I was using with variable_set() and variable_get().

If the form field name is not the same multilingual variables cannot be tamed.

lpalgarvio’s picture

i would suggest a new way of writing i18n variables in settings.php: make use of multiple code blocks, through array_push

the original i18n block, with a minor change

/**
* Multilingual settings
*
* This is a collection of variables that can be set up for each language when i18n is enabled.
* These are the basic ones for Drupal core, but you can add your own here.
*/
//$conf['i18n_variables'] = array(
if (!is_array($conf['i18n_variables'])) $conf['i18n_variables'] = array(
  // Site name, slogan, mission, etc..
  'site_name',
  'site_slogan',
  'site_mission',
  'site_footer',
  'anonymous',
  // Different front page for each language
  'site_frontpage',
  // Primary and secondary links
  'menu_primary_links_source',
  'menu_secondary_links_source',
  // Contact form information
  'contact_form_information',
  // For theme variables, read more below
  'theme_settings',
  'theme_garland_settings'
);

any new blocks we may add

/**
* Multilingual settings - Pathauto
*
* Variables for Pathauto usage.
*/
if (is_array($conf['i18n_variables'])) array_push($conf['i18n_variables'],
  // pathauto
  'pathauto_node_pattern', // General pattern for nodes
  'pathauto_node_blog_pattern', // Pattern for blog nodes
  'pathauto_node_forum_pattern', // Pattern for forum nodes
  'pathauto_node_poll_pattern', // Pattern for poll nodes
  'pathauto_node_story_pattern', // Pattern for story nodes
  'pathauto_node_page_pattern', // Pattern for page nodes
  'pathauto_node_book_pattern' // Pattern for book nodes
);

it's more modular this way, easier to edit and add. less prone to errors. less prone to make users create support requests.

the issue about this is here:
http://drupal.org/node/945660

Luís Pedro Algarvio
Site Reliability / DevOps Engineer.
Free and Open Source Software advocate.
Passionate about life and work.
lp.algarvio.org

lpalgarvio’s picture

user mail:

/* User configuration */
if (is_array($conf['i18n_variables'])) array_push($conf['i18n_variables'],
'user_registration_help',
'user_mail_register_admin_created_subject',
'user_mail_register_admin_created_body',
'user_mail_register_no_approval_required_subject',
'user_mail_register_no_approval_required_body',
'user_mail_register_pending_approval_subject',
'user_mail_register_pending_approval_body',
'user_mail_password_reset_subject',
'user_mail_password_reset_body',
'user_mail_status_activated_subject',
'user_mail_status_activated_body',
'user_mail_status_blocked_subject',
'user_mail_status_blocked_body',
'user_mail_status_deleted_subject',
'user_mail_status_deleted_body'
);

Luís Pedro Algarvio
Site Reliability / DevOps Engineer.
Free and Open Source Software advocate.
Passionate about life and work.
lp.algarvio.org

lpalgarvio’s picture

note: Dave Reid, a co-maintainer of Pathauto, has just stated that these variables do not apply to pathauto:

Posted by Dave Reid on October 20, 2010 at 10:03pm

That documentation is completely wrong and does not actually work properly with Pathauto. There are *already* per-language variables defined by pathauto.

http://drupal.org/node/945662#comment-3601712

the method is still valid for other variables though

Luís Pedro Algarvio
Site Reliability / DevOps Engineer.
Free and Open Source Software advocate.
Passionate about life and work.
lp.algarvio.org

Andy Inman’s picture

You can generally find the required variable name by looking at the HTML source for the relevant configuration page, or using Firebug to examine the configuration form.

Example: at admin/settings/site-information look at the entry field for Email address you will see something like:

<input type="text" class="form-text required" value="support@example.com" size="60" id="edit-site-mail" name="site_mail" maxlength="128">

... this tells us that the variable name is site_mail. So, add the following to your settings.php:

$conf['i18n_variables'] = array(
  'site_mail',
  ...

... and you will be able to set a different contact email address per language.

In general this method of finding the variable name will work for Drupal core and modules which use Drupal's system_settings_form method of providing a configuration page.

emarchak’s picture

Works perfectly! Thanks so much.

Dret’s picture

I'm lookink for a variable to handle correctly translations for 404 and 403 pages.

Some ideas?

FiNeX’s picture

Hi, you could try this: http://drupal.org/project/translation404
Or create a 403/404 page with the translations and configure the variable with the 403/404 settings as multilingual

Andy Inman’s picture

Yet another way is to use a single page (node) with Language Sections to provide language-dependent content for that page.

Dret’s picture


configure the variable with the 403/404 settings as multilingual

Can you make me an example about it?

What's the syntax to add this variable in setting.php file?

Thanks!

NB I know Translation404 module but is not my target!

FiNeX’s picture

Hi. You can set multilingual variables defining an array like this:

$conf['i18n_variables'] = array(
  // Site name, slogan, mission, etc..
  'site_name',
  'site_slogan',
);

You can find a more detailed description on this page: http://drupal.org/node/313272

P.S: it doesn't work with all Drupal variables, so give it a try :-)

adrianmak’s picture

the i18n 'site_frontpage' variable has a little bit problem.
My site has two languages, English and Japanese.

node/1 is front page content of English and node/2 is front page content of japanese.

I configured node/1 for English frontpage under site information and node/2 for the Japanese front page.

However when I published content (language netural) and promoted to front page, the content won't show up on frontpage on neither languages.

aschiwi’s picture

The promoted to front page checkbox publishes your content to "/node", not whatever else you set as your front pages, unless you make a view for your front pages that shows nodes that are filtered by promoted to front page.