Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
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;
}
Comment | File | Size | Author |
---|---|---|---|
#18 | superfish.module.patch | 218 bytes | anttro |
#7 | multilang-improvement-1410078-5574708.patch | 4 KB | ulsc |
#2 | multilang-improvement-1410078-5507862.patch | 3.93 KB | ulsc |
Comments
Comment #1
ulsc CreditAttribution: ulsc commentedsolves also the taxonomy menu problem. If you have multilingual taxonomies in which the items should be translated seperately, the code above works fine.
Comment #2
ulsc CreditAttribution: ulsc commentedHere's the patch to test and commit. But it's for 7.x
Comment #3
C. Lee CreditAttribution: C. Lee commentedApplied the patch (#2) and it looks working fine.
Comment #4
Anonymous (not verified) CreditAttribution: Anonymous commentedPatch from #2 fails on 1.9-beta4 (2011-Nov-24) but works on 7.x-dev (2011-Mar-28).
Thanks!
Comment #5
Anonymous (not verified) CreditAttribution: Anonymous commentedAbout 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.
Comment #6
Anonymous (not verified) CreditAttribution: Anonymous commentedI 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):
I think it has to do with this piece of code here:
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:
Comment #7
ulsc CreditAttribution: ulsc commentedHere's the new patch. Thank you genox!
Comment #8
mehrpadin CreditAttribution: mehrpadin commentedHey 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?
Comment #9
Anonymous (not verified) CreditAttribution: Anonymous commentedHmm 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?
Comment #10
ulsc CreditAttribution: ulsc commented@genox sure! :)
Comment #11
luigithekid CreditAttribution: luigithekid commentedWas having this issue with 7.x-1.8. Got 7.x-1.9-beta4 and at least
works fine
Comment #12
drupalerocant CreditAttribution: drupalerocant commentedHello!
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?
Comment #13
IdanC CreditAttribution: IdanC commentedtried patch #7 on version 7.x-1.8, worked like a charm! thanks!
Comment #14
Nuno Ricardo Da Silva CreditAttribution: Nuno Ricardo Da Silva commentedHi 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.
Comment #15
eloivaquetried patch #7 on version 7.x-1.8, worked! thanks!
Comment #16
Vacilando CreditAttribution: Vacilando commentedThere's a solution in #1112928: i18n translation.
Comment #17
Enno CreditAttribution: Enno commentedI 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.Comment #18
anttro CreditAttribution: anttro commentedHaving 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):
Works just fine now.
Patch file is attached
Comment #19
mehrpadin CreditAttribution: mehrpadin commentedAnton,
Just upgrade to v1.9-beta4 :)
Comment #20
anttro CreditAttribution: anttro commentedHmm, 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
Comment #21
migue_ CreditAttribution: migue_ commentedThank you!!
It works for me!!
Comment #22
jherencia CreditAttribution: jherencia commentedComment #23
mjgmaas CreditAttribution: mjgmaas commentedI used the patch from Anttro in #18 and it works fine for me. Thanks!
Comment #24
mehrpadin CreditAttribution: mehrpadin commentedShould I label this as fixed? can some of you confirm it's fine in 1.9?
Comment #25
mehrpadin CreditAttribution: mehrpadin commentedFeel free to reopen, if necessary.
Comment #26
Skrln CreditAttribution: Skrln as a volunteer commentedI'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.