Problem

  1. Create a menu with items set to 'All Languages'
  2. Use the interface translation to translate these menu items
  3. Switch to the langauge you translated into. The translations don't appear.

Analysis

The i18nblocks module uses theme('blocks') to translate the menu item. It does this by overriding the system's default themer, in i18nblocks_theme.
However, by default i18nblocks has the same weight as the system module - this means that system_theme is called after i18nblocks_theme (as it's done by weight, then alphabetically), and therefore the override does not work.

Solution

At the very least, the weight of the i18nblocks module should be set in the .install file. Ideally, there should be an i18nblocks admin page that warns you when the weight of 18nblocks is lower or equal to that of the system blocks ; and that lets you change that weight. Both patches are provided below.

Patch

First, a patch to the .install file :

Index: modules/i18n/i18nblocks/i18nblocks.install
===================================================================
--- modules/i18n/i18nblocks/i18nblocks.install  (revision 1293)
+++ modules/i18n/i18nblocks/i18nblocks.install  (working copy)
@@ -8,8 +8,8 @@
 function i18nblocks_install() {
   // Create database tables
   drupal_install_schema('i18nblocks');
-  // We dont need to change module weight
-  //db_query("UPDATE {system} SET weight = 20 WHERE name = 'i18nblocks' AND type = 'module'");
+  // We do need to change module weight
+  db_query("UPDATE {system} SET weight = 20 WHERE name = 'i18nblocks' AND type = 'module'");
 }

 /**

Next, a patch to create an admin page and set the weight :

Index: modules/i18n/i18n.admin.inc
===================================================================
--- modules/i18n/i18n.admin.inc (revision 1293)
+++ modules/i18n/i18n.admin.inc (working copy)
@@ -29,9 +29,59 @@
     '#options' => _i18n_selection_mode(),
     '#description' => t('Determines which content to show depending on the current page language and the default language of the site.'),
   );
-  return system_settings_form($form);
+  if (module_exists('i18nblocks')) {
+    $blocks_weight = db_result(db_query("SELECT weight FROM {system} WHERE name = 'i18nblocks' AND type='module'"));
+    $system_weight = db_result(db_query("SELECT max(weight) FROM {system} WHERE name = 'system' AND type='module'"));
+
+    $form['i18nblocks'] = array(
+      '#type' => 'fieldset',
+      '#title' => t('i18nblocks module configuration'),
+    );
+    $form['i18nblocks']['weight'] = array(
+      '#type' => 'textfield',
+      '#title' => t('Module weight'),
+      '#description' => t(
+        'In order to function properly, the i18nblocks module must be heavier than the system module. The system module currently weights %weight',
+        array('%weight' => $system_weight)
+       ),
+      '#default_value' => $blocks_weight,
+    );
+  }
+
+  // We don't use the default system form settings, as we want to update the weight of the module
+  // straight away.
+  $form['buttons']['submit'] = array('#type' => 'submit', '#value' => t('Save configuration') );
+  $form['buttons']['reset'] = array('#type' => 'submit', '#value' => t('Reset to defaults') );
+
+  if (!empty($_POST) && form_get_errors()) {
+    drupal_set_message(t('The settings have not been saved because of the errors.'), 'error');
+  }
+  $form['#submit'][] = 'i18n_admin_settings_callback';
+  $form['#theme'] = 'system_settings_form';
+  return $form;
 }

+/**
+ * Save the admin page settings form
+ */
+function i18n_admin_settings_callback($form, &$form_state) {
+  if (isset($form_state['values']['op']) &&
+      $form_state['values']['op'] == t('Reset to defaults')) {
+    variable_del('i18n_selection_mode');
+    drupal_set_message(t('The configuration options have been reset to their default values.'));
+  } else {
+    variable_set('i18n_selection_mode', $form_state['values']['i18n_selection_mode']);
+    if (module_exists('i18nblocks')) {
+      db_query("UPDATE {system} SET weight='".intval($form_state['values']['weight'])."' "
+               ." WHERE type='module' AND name='i18nblocks'");
+    }
+    drupal_set_message(t('The configuration options have been saved.'));
+  }
+
+  cache_clear_all();
+  drupal_rebuild_theme_registry();
+}
+
 // List of selection modes
 function _i18n_selection_mode(){
   return array(

Comments

Alice Heaton’s picture

Forgot to say, this issue has already been mentioned : http://drupal.org/node/230868#comment-895966 and http://drupal.org/node/263717 though I think it's the first time it's reported as an issue in it's own right.

madrock9’s picture

Hi, it does not appear to work if the menu is created with taxonomy [i.e. create the vocabulary, add terms in language A, translate them in language B; on both languages the menu is shown with all links is both languages] ... Thanks, corina

Alice Heaton’s picture

Hi madrock9 :) The issue I report here has nothing to do with how the menu is created. Your issue is a different problem, and as such I suggest you open a new bug report for your specific issue - you can do so on this page : http://drupal.org/node/add/project_issue/i18n/bug . Bug reports should be as specific as possible ; otherwise it's very hard for the developers to understand what the problem is.

jose reyero’s picture

Status: Needs review » Fixed

Fixed some other way, so we don't have to mess with module's weight. Thanks though

Frank Steiner’s picture

Status: Fixed » Active

Hi,

it works for menu items created in the menu build page. But if I create a lang-neutral page with a menu entry via the node edit form, $link['customized'] is not set and so the menu entry is not localized.

We talked about this in http://drupal.org/node/263124 in you said:

> About the second part, menu items for nodes (is it what we are talking about?)
> don't need to go through menu translation as the menu system will just show
> the menu items for the nodes in the current language.

This is true for pages with a language. But for language neutral pages, those can be shown for all languages (when using e.g. 'Current language and no language'), and then their menu items should be translated if a translated menu string exists.

Especially when using the language sections module. We use this and thus have only language neutral pages containing both, the german and the english text in the same node. Depending on the the current language, just the german or english parts are shown. So when we change the language, the content translates, but the menu item does not.

Btw, if you create the menu item with the menu build page and let it point to a language neutral page, then it will be translated, although it's a menu item for a node. So translation doesn't depend on what the menu item is used for, but how it is created.

Can't we just remove the test about the customized item? Or why do we need it?

cu,
Frank

jose reyero’s picture

Status: Active » Fixed

@Frank

You're right but you're talking about a different issue, the one on this thread is fixed.

But we cannot remove the 'customized' test, there are many strings that are not supossed to go through localization, nor i18n's string translation. And not node titles certainly.

So provided your node is not really 'language neutral', maybe you should consider creating translations for it. Please open a different thread if you want to follow on that (suggested: feature request)

Anonymous’s picture

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.