7

In a custom module I define several configuration variables by implementing the Variable module's API. The module is part of a multilingual site project, so some of these variables should be translatable.

In my hook_variable_info() implementation, these variables are defined as with 'localize' => TRUE so they are available in the Multilingual settings > Variables interface provided by the Variable translation module (part of Internationalization). But their default state is not to be translated. So, in order to have the variable translated, the site administrator needs to visit the page and select my module's variables.

I need my custom variables to be automatically translated when the module is installed.

The module already uses Features to export other configuration, so a solution based on Features would be nice. But it can be purely code based.

  • +1 For interesting question. I did not even know about that module before! It's new in D7. – amateur barista Feb 2 '12 at 16:31
4

Update: With recent version of the Variable translation module (ie. 7.x-1.7), the list of translated variables is stored by the language variable realm controller in its list variable. The following code demonstrate how to use the realm controller to set translated variables from a module hook_enable() implementation.

function MODULE_enable() {
  // Get the language variable controller.
  $controller = variable_realm_controller('language');
  // The list of translatable variables.
  $translatable_variables = $controller->getEnabledVariables();
  // The list of variables that could be translated.
  $available_variables = $controller->getAvailableVariables();
  // Add our variables to $translatable_variables.
  foreach ($available_variables as $name) {
    // Translate user mail messages.
    if (preg_match('/^user_mail_[a-zA-Z_\[\]]*\[mail_part\]$/', $name)) {
      $translatable_variables[] = $name;
    }
  }
  $translatable_variables = array_merge($translatable_variables, array(
    'user_registration_help',
    'user_picture_guidelines',
    'maintenance_mode_message',
    'menu_main_links_source',
    'menu_secondary_links_source',
  ));
  // Save the updated list of translatable variables.
  $controller->setRealmVariable('list', array_unique($translatable_variables));
}

Update: This is not the way to do it, unless you are using an old version of Variable translation module (< 7.x-1.7)

The names of the translated variables are stored in the i18n_variable_conf variable. This variable itself cannot be exported using Strongarm (or similar solution). I ended using an old trick: checking the variable in a hook_init implementation and setting it if needed. The array in the foreach controller contains the names of the variables to be translated.

/**
 * Implements hook_init();
 */
function MODULE_init() {
  $i18n_variable_conf = variable_get('i18n_variable_conf', array());
  $i18n_variable_conf_updated = FALSE;
  foreach(array(...) as $name) {
    if (!in_array($name, $i18n_variable_conf)) {
      $i18n_variable_conf[] = $name;
      $i18n_variable_conf_updated = TRUE;
    }
  }
  if ($i18n_variable_conf_updated) {
    variable_set('i18n_variable_conf', $i18n_variable_conf);
    variable_set('i18n_variable_list', variable_children($i18n_variable_conf));
    cache_clear_all('*', I18N_VARIABLE_CACHE, TRUE);
  }
}

Compared to a feature based solution, this enforce the settings for the configured variables and will cancel any manual edit. This may wanted or not wanted. In my case it was.

My only issue with this solution, is that it had some overhead to each request.

1

A solution based on Features should be strongarm. However, that feature does not exist (yet) http://drupal.org/node/1086986

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.