When menu links are set up with i18n to only be displayed for a certain language, sometimes they are still displayed even when you're not viewing the page in the right language. One such occasion is when you edit and then save a content type. I've come up with a solution for this that seems to work:

In theme_superfish_build, after this line:

foreach ($menu as $menu_item) {

and before this line:

if (!isset($menu_item['link']['hidden']) || $menu_item['link']['hidden'] == 0) {

paste this code:

$itemlang = $menu_item['link']['localized_options']['langcode'];
if($itemlang) { 
   global $language;
   if($language->language!=$itemlang) continue;
}
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

ulsc’s picture

Priority: Normal » Critical
Status: Active » Needs review
$lang = $menu_item['link']['language'];
if($lang) {
  global $language;
  if(($language->language!=$lang) && ($lang!='und')) continue;
}

solves also the taxonomy menu problem. If you have multilingual taxonomies in which the items should be translated seperately, the code above works fine.

ulsc’s picture

Version: 6.x-1.8 » 7.x-1.x-dev
Status: Needs review » Patch (to be ported)
FileSize
3.93 KB

Here's the patch to test and commit. But it's for 7.x

C. Lee’s picture

Applied the patch (#2) and it looks working fine.

Anonymous’s picture

Patch from #2 fails on 1.9-beta4 (2011-Nov-24) but works on 7.x-dev (2011-Mar-28).

Thanks!

Anonymous’s picture

About the patch from #2: My understanding is, that the patch removes menu items *after* the unstructured lists and list elements have been created (using the theme(); function?). Therefore, if one of the items that is being removed happens to be the first or the last one, the li-element with class="first" or class="last" is gone from the list, possibly causing display errors if those classes are being used to style the menu.

I don't know exactly how, but I suggest it would be better to get rid of the "wrong" menu items *before* the HTML list is being generated. Is this possible?

I temporarily fixed this by using :last-child/:first-child selectors in my CSS, but I'd prefer to go with the provided .first/.last classes.

Anonymous’s picture

Status: Patch (to be ported) » Needs work

I tested the patch on

a) sites with multiple language items and
b) on pages with only 1 default language (other than english), meaning the menu items are mostly language neutral.

I receive the following Notice on all sites like b):

Notice: Undefined index: language in theme_superfish_build() (line 876 of /home/mediagen/lib/drupal/d7contrib/superfish/superfish.module).

I think it has to do with this piece of code here:

+  	$lang = $menu_item['link']['language'];
+	if($lang) {
+	   global $language;
+	   if(($language->language!=$lang) && ($lang!='und')) continue;
+	}

The menu-item array apparently does not contain a language index if the item is language neutral - as in i18n_menu is disabled.

This here works:

if(module_exists('i18n_menu')) {
  $lang = $menu_item['link']['language'];
  
        if($lang) {
           global $language;
           if(($language->language!=$lang) && ($lang!='und')) continue;
        }
}
ulsc’s picture

Here's the new patch. Thank you genox!

mehrpadin’s picture

Hey everybody,

Thanks a lot, I've added this issue to my to-do list, but can someone please confirm that the problem does exist with the v1.9-beta4 too?

Anonymous’s picture

Hmm this is awkward. I just installed 1.9-beta4 and it seems that everything just works like it should. When switching languages, items switch too and no duplicated items in multiple languages. I was using the dev release all along, with bugs that have been fixed already. Great.. :-)

I'm using drush to install and manage modules and the current dev you get via drush/git is the outdated one. I'm so used to using dev releases that I must have chosen the dev release automatically without comparing the dates properly. :P

@ulsc, can you confirm that too?

ulsc’s picture

@genox sure! :)

luigithekid’s picture

Was having this issue with 7.x-1.8. Got 7.x-1.9-beta4 and at least

a) sites with multiple language items

works fine

drupalerocant’s picture

Hello!
Superfish (7.x-1.9-beta4) multilanguage menu (with i18n 7.x-1.4 on Drupal 7.12) working fine except for home page.
I have three languages on my site and superfish works fine except for home page where it shows the three menu links (for the three languages) and the three points to the same page depending the language you are.
This means, it shows the three home menu itemsand if you are in english, the three menu links points to the english frontpage and if you are in spainsh the three menu links points to the spanish frontpage.
I set frontpage according to http://drupal.org/node/1216132

Any ideas?

IdanC’s picture

tried patch #7 on version 7.x-1.8, worked like a charm! thanks!

Nuno Ricardo Da Silva’s picture

Hi all,
I have a similar problem. I have a website in Two languages. And when i put a parent menu item with no link (#) or node/a-child, this menu works as i want, when i click on parent, i go to child node. But when i do that, Drupal automatically add this menu in the Portuguese other language menu.
Anyone as a solution for that?
Thanks in advance.

eloivaque’s picture

tried patch #7 on version 7.x-1.8, worked! thanks!

Vacilando’s picture

There's a solution in #1112928: i18n translation.

Enno’s picture

Superfish (7.x-1.9-beta4) multilanguage menu (with i18n 7.x-1.4 on Drupal 7.12) working fine except for home page.
I have three languages on my site and superfish works fine except for home page where it shows the three menu links (for the three languages) and the three points to the same page depending the language you are.

I cannot verify this. For me the update from 1.8 to 1.9-beta4 fixed the multilanguage menu issues in the Superfish block including the frontpage.
Menu point for front page is set up with path <front> without a specified language and in a localized menu. So, it only shows up once in the menu itself, but has multiple translations via i18n.

anttro’s picture

Priority: Critical » Major
FileSize
218 bytes

Having similar issue with Drupal 7, Superfish 7.x-1.8 and Internationalization 7.x-1.7

I'm using two languages in a single bilingual main menu, and some level 1 items have two translations.
Superfish displays each translation as a separate item, no matter which language is selected, i.e. all bilingual items are duplicated and displayed in two languages in the same menu.

Issue is only reproducible with Superfish, while core Menu and Nice Menus work as expected.
I fixed it for Superfish by adding this code to theme_superfish_tree function (borrowed from nice_menus):

  // Allow i18n module to translate strings where available.
  if (module_exists('i18n_menu')) {
    $menu = i18n_menu_localize_tree($menu);
  }

Works just fine now.
Patch file is attached

mehrpadin’s picture

Anton,

Just upgrade to v1.9-beta4 :)

anttro’s picture

Hmm, just tried v1.9-beta4, same issue with duplicated items (each translation turned into menu item) as in v1.8.

According to this, i18n_menu_localize_tree must be used to prepare the i18n menu.
http://drupal.org/node/1114010

migue_’s picture

Thank you!!
It works for me!!

jherencia’s picture

Status: Needs work » Needs review
mjgmaas’s picture

I used the patch from Anttro in #18 and it works fine for me. Thanks!

mehrpadin’s picture

Should I label this as fixed? can some of you confirm it's fine in 1.9?

mehrpadin’s picture

Issue summary: View changes
Status: Needs review » Closed (fixed)

Feel free to reopen, if necessary.

Skrln’s picture

I'm still experiencing this issue on Drupal 7, Superfish 1.9

In standard language: correct menu items are displayed, in other languages both standard menu items and translated menu items are displayed simultaneously.