How to translate Menu items?

there is a separate sub-module to translate menus....but I can't figure out how to work it either

I just seen that this is a v6 support request. There is still the i18n module (outside of core) to help with this.

Install i18n, enable i18nmenu
Create your menus (Multilingual Menu)
and go to Administer > Site building > Translate interface
(If the menus have been created previously, try the Refresh tab so the show up in the strings to translate)

tried what you recommended. does not seem to work. tried the refresh tab but the string does not show up. I am using the april 2 development version. i remember that it use to work on the older version. could you please check why is this so.

i have also tried to move the menu around to Navigation or secondary links. it still does not show up in the translate interface.

i have tried both creating the menu item before enabling the i18n menu & also after. i think its broken.

Same issue:
Created a primary link (choose all language) which appeared after the refresh, so I could translate it, but had no affect on the page, so remained untranslated...

Created also a primary link where I tried to choose a language, but in this case it is not appearing in the translation... (refresh does not help)

Tried to add this to the settings.php, but as it seams the table i18n_variable is still empty...
$conf['i18n_variables'] = array(
// Site configuration
'site_name',
'site_slogan',
'site_mission',
'site_footer',
'anonymous',
// Node help
'blog_help',
'story_help',
// User configuration
'user_registration_help',
'user_mail_welcome_subject',
'user_mail_welcome_body',
'user_mail_approval_subject',
'user_mail_approval_body',
'user_mail_pass_subject',
'user_mail_pass_body',
// Primary and secondary links
'menu_primary_menu',
'menu_secondary_menu',
'primary_links',
// Theme settings. This is an 'all or nothing' for each theme
// This is for 'garland' theme, for other theme it would be 'theme_[themename]_settings'
'theme_garland_settings',

);

So can we say that the menu module of i18n is not working or I am doing something wrong?

Hi,

just tried the same and here's how far I got: I had created a german page with a menu entry, but couldn't find it at the "Translate interface" menu (btw, I don't have any "refresh" button or sth. Just Overview/Search/Import/Export and non of them provides a refresh possibility. Where is it supposed to be? This is with drupal 6.2)

But after disabling and then re-enabling the "Multilingual Menu" module, it said

Configuration changes saved
Created string item:168:title for text group menu: Startseite

Now I could find the entry "Startseite" in Translate interface/Search and add an english translation "Main page". But now what? The help for i18menu says
- Use the localization system to translate menu item strings
- Instead of the old menus use the new blocks provided by the module. These will be localized.

So how is that translated menu entry supposed to work after all? How do I use these "new blocks"?
When I just switch the language, the "Startseite" menu just disappears. Of course I can still translate the german page that has the "Startseite" menu entry and enter a english menu entry for the translated page. But then I didn't have to translate that menu entry in the "Translate interface" menu before...

I expected that I wouldn't have to chose a menu entry for the translated page anymore, but that would be done automatically. Is that how it should work?

Hmm, with the new release from April 17th, I can't find any menu titles of new menus I created anymore when searching for them on the "translate interface" page...

Frank,

I'm using the April 17th release as well and also having problems translating the primary links.

I had to disable and re-enable multilingual menu for my link to register, so thanks for posted that tip. I was then able to then translate the link using the translation interface. I tried extracting the .po file and then also searching the menu string. Both methods seemed to work however the actual link does not display the translation.

I've tried selecting all languages as the link option as well as the individual language but neither method shows the link in translation. The default language link continues to show in both cases -- it does not disappear. And if I click on the link it goes to the node I want. This really baffling since the string shows a translation.

Hmm, this is strange. I can again find my new strings by dis- and enabling the menu. And indeed I have one menu entry that behaves as you describe: it has a translation, but when switching the language, I always see the german menu title "Mein Menue". BUT this menu title brings me to the german or the english translation, depending on the language I've chosen with the language switcher block.
In the menu settings for the translated page, there is no menu link title selected. But in the list I can see the german menu title "Mein Menue" in the parent selection, but not its translation.

However, I tried to reproduce it and failed. I created a page with german language and a menu entry. Then I translated the menu entry in translate interface. Then I created a translation of the german page and didn't chose any menu title (note that in the parent selection I cannot see the german nor the english title of the menu, but I can see the german title "Mein Menue").
But then the translated, english page doesn't have any menu entry at all, not even the german one. I guess it should automatically get the english title without me entering anything in the title field, shouldn't it?

I don't remember what I did with this one page that shows the german menu "Mein Menue" for the german and the english body. And why this menu entry shows up in the menu-selection list for translated pages, while the other menu title, which I localized also, does not.

I hope someone will look into this soon, because currently it is not really possible to have a multi-language site with 6.x :-(

Exact same problem here

Breakthough!

I deleted the primary link entry in the menu panel. Then I went to the node and added a menu link title there. I did the same for the translated versions. I refreshed the menu strings in the translation interface and viola, when I click English, I only see English, French shows the French link...And all the menu links go the appropriate node.

I have no idea why the system isn't localizing for me. Everything looks as if it is localizing but then the changes do not show. I had the same problem with my taxonomy strings, so I just switched to language specific terms. I guess whatever works but I wish I understood how the localization is supposed to function!

But I think this isn't a localized menu. If you enter a menu link title for the original language, and enter another menu link title for the translated version, you end up with two different menues. Drawbacks are that e.g. the ordering of those two menues might not be the same. When I did what you did, the menu link title of the translated page was at a quite different position and I had to reorder it.

When you localize a menu entry, I think that it will be only one menu entry with two languages (or more) "attached" to it instead of two different menues with one language each.

I was trying to figure out the difference (apart from that ordering thing) and I would expect the following to happen (don't know if that's really true):
Guess you have a menu with submenues, i.e.
A
|- B
|- C

All pages language neutral initially. Now when chose a language for A and then translate it to the second language and give the translation a new menu link title "A-trans", then B and C will disapear, too, when you change the language, even if the pages are language neutral. Just because A disappears because A has only one language attached, it will also hide its submenues.

However, if you localize A, I would expect (don't know if it will really works like that) that A just changes to A-trans while B and C stay. That would be a fine concept for having content where only some pages are bi-langual so far, i.e. it would be better to always show all language-neutral pages indepentend from the language.

I feel that's how it should work...

I am seeing the same problem here. Navigation menu gets correctly translated, but primary links remains unchanged, Although if I enable Primary Links to display in a block, there is no problem. It is only the themes Primary Links menu have a problem with.

I have the same problem, the normal menu works great - the primary items are translated but if i push the lang switcher the primary items doenst change. All other items switch to the correct lang.

For me it doesn't work in the Navigation menue, but I've moved all usual links from the Navigation menu to some other menu and just put my own menu items in the Navigation menue. And none of my *own* menu strings in the Navigation menu translates...

I found a workaround, actually an ugly hack.

In menu.inc, in the menu_navigation_links function, add the line

i18nmenu_localize_tree($tree);

before the foreach statement.

marked #253724: MENU items doesnt seem to get translated? as a duplicate.

miopa, doesn't seem to work for me... is that the only thing you changed?

Not working for me...There must be something else to modify.

I have just double-checked, that was all. Drupal 6.2, and i18n 6.x-1.0-beta1 from 2008-Apr-23.
Multilingual Menu, Mutilingual Blocks, Strings and Translation Synchronization modules enabled.

I print the menus like this (in page.tpl.php):
print theme('links', $primary_links, array('class' => 'links'))

Anyway, here are the functions in whole

In menu.inc

function menu_navigation_links($menu_name, $level = 0) {
  // Don't even bother querying the menu table if no menu is specified.
  if (empty($menu_name)) {
    return array();
  }

  // Get the menu hierarchy for the current page.
  $tree = menu_tree_page_data($menu_name);

  // Go down the active trail until the right level is reached.
  while ($level-- > 0 && $tree) {
    // Loop through the current level's items until we find one that is in trail.
    while ($item = array_shift($tree)) {
      if ($item['link']['in_active_trail']) {
        // If the item is in the active trail, we continue in the subtree.
        $tree = empty($item['below']) ? array() : $item['below'];
        break;
      }
    }
  }

  // Create a single level of links.
  $links = array();
  i18nmenu_localize_tree($tree); // miopa hack
  foreach ($tree as $item) {
    if (!$item['link']['hidden']) {
      $l = $item['link']['localized_options'];
      $l['href'] = $item['link']['href'];
      $l['title'] = $item['link']['title'];
      // Keyed with unique menu id to generate classes from theme_links().
      $links['menu-'. $item['link']['mlid']] = $l;
    }
  }
  return $links;
}

and in i18nmenu.module

function i18nmenu_localize_tree(&$tree) {
  global $language;
  foreach($tree as $index => $item) {
    $link = $item['link'];
    if ($link['customized']) {
      // Remove links for other languages than current
      // Links with language wont be localized
      if (!empty($link['options']['langcode'])) {
        if($link['options']['langcode'] != $language->language) {
          unset($tree[$index]);
          //dsm("Removed because language:".$link['title'].' language='.$link['options']['langcode']);
        }
      } else {
        $router = i18nmenu_get_router($link['router_path']);
        // If the title is the same it will be localized by the menu system
        if ($link['link_title'] != $router['title']){
          //$tree[$index]['link']['title'] = 'Translated';
          $tree[$index]['link']['title'] = tt('menu:item:'.$link['mlid'].':title', $link['link_title'], NULL, TRUE);
        }
      }
    }
  }
}

@miopa:

What is it exactly, you get working with this hack?

I have the same system: Drupal 6.2, i18n (and a ton of other modules). I use a modified 4 Seasons theme, where I have removed Primary and Secondary links. They took too much space in my header ...

I only navigate with my Navigation menu. I do get it to work as far as menu items - both system and custom, gets translated with the Localizer in Translate Interface.
But I am have quite some trouble getting the various menu items pointing to the right nodes (to say it mildly...)

I succeeded in applying your hack in menu.inc. As far as the i18nmenu.module goes, I don't see any difference in the code, you pasted here, and the original. What did you change?

Has someone any luck with the i18n module? Would really like to know :-)

- Christian

Hacking menu.inc is not a real solution to this problem. It looks like hooks of the i18nmenu.module aren't fully hooking into the drupal system. I wonder why this problem has been so totally ignored by the maintainers for 6 weeks now :-( It's really a major bug that makes the i18n menu system unusable.
A little "yes, we realized the problem and will be working on it soon" would help already :-)

@drunkensailor

Before the hack, primary and secondary links (and i guess navigation) were displaying all the menu items, regardless of the active languange and language setting of the menu item. I never had problems with pointing to the right nodes.

No change in i18nmenus, was included just for reference.

miopa, I added your small hack. seems to make the fix for me. However, if I add an item to the primary menu that is a node, it doesn't show up. Example: node/2 shows up in English, but not in my Japanese menu no matter how I set it. All other items work, < front >, absolute url's, and even blog show up in both English and Japanese, but not node/x. node/x will only show in the default site language's menu. odd huh. something must still need fixing.

Thanks for posting your workaround. I do hope a developer can make a more permanent fix, no hacking needed.

I was able to create a little work around by creating two menu items for the node. Each one directing to the appropriate node and selecting the corresponding language when creating them. The one for the second language had to be created using the absolute url in order to work, and the one for the primary language was created as node/x.

The "work around" is exactly what you can do in drupal without the i18n module. But the problem that you work around is exactly the core problem, i.e., menu entries are not localizing... See comment #13.

I found a workaround, actually an ugly hack.

In menu.inc, in the menu_navigation_links function, add the line

i18nmenu_localize_tree($tree);

before the foreach statement.

Thank you very much!
It works now!

Argh. I'm having exactly the same problem. heland's patch does seem to help, but I spent well over an hour figuring out that this module was broken and then scrubbing drupal.org to find this patch. Any hope of getting this fixed anytime soonish?

Doesn't look like, at least none of the developers has commented on this for two months :-( The patch doesn't solve all problems, e.g. I still have problems finding the translated strings in the localize menu, so there must be some more things wrong that just the missing for translating the menu :-(

Regarding the problem that newly created menu strings are not found on the "Translate interface" page but only after dis- and re-enabling the i18nmenu module, you can find the patch here: http://drupal.org/node/263124
Now all new menu strings are found when selecting "Menu" and clicking "Refresh strings".

subscribing

subscribing

subscribing

It took a while but worked for me

drupal 6.2 i18n 6.x-1.0-beta1
with i18menu enabled

English Page
"PageNameEN"
menu "PageNameEN"
URL path "en/pagename" (very important it seems)
actual path becomes "en/pagename"

Create translation
Greek Page (EL)
"PageNameEL"
menu title: "PageNameEL"
URL path: "pagename" (very important it seems)
actual path becomes "el/pagename"

For me the trouble comes when I want to refer to the same page
with different menu Title for each language

English Menu
menu title: "News"
URL path: "news"

Greek Menu
menu title: "Νέα"
URL path: "news"

Both menus show up Both for English AND Greek page viewing

Anyone can report the same ?

Γεια,

It doesnt work yet, that is the menu.

I also have duplicate menus
news -> news
ニュース -> news

Confirmed, we have same problem with menus in admin appearing for all languages.

I have no problems with changing the language of a menu link when editing the node through content management. What is confusing the heck out of me is that it seems to add the english teaser into the editor when I open it to edit.

I will raise this as a separate issue.

Subscribing.

Also, as Frank points out in #13, translating a node and adding another (translated) menu title there, would not get me a localized menu. However, until there is a real fix for this issue, I would like to go this way. BUT: would I be able to later specify which menu entry is a translation of another? Or would I never get a truly localized menu if I choose to start this way. Thanks for sharing your thoughts.

I think you will never get localized menu entries then, because as far as I understand it, localized menues are not made up of two menu items that are translations of each other (as it is with pages), but it is just one menu entry who's title translates when switching languages.
However, I'm not sure if such a localized menu will ever be able to show to two different pages. From my tries to get it working (see http://drupal.org/node/263717) I cannot imagine how a localized menu entry could point to one node in one language, and then point to the node's translation when switching language.
This might only be possible with fixed or builtin pathes, like en/search and de/search.
But for user-created menu entries like "en/mysearch" and "de/meinesuche" this might never work, at least I cannot see how the current drupal core code would allow for this, as I pointed out in the post linked above.

ArjanLikesDrupal, I'm now pretty sure that localized menus cannot work the way I expected it. You cannot have two nodes (an original page and its translated version) bound to the same (localized) menu entry.

Please read http://drupal.org/node/263717 to understand why. I just revisited the code and I'm sure that there is no way making it work.

Although I could make the localized menu entry show to either the original or the translated version when switching the language, I could achieve this only by changing the href when showing the menu entry.

But to make it really work, one would have to change the menu object stored in the database every time the language is switched. Because otherwise the menu object in the database will always point to the original node. And then things start to go wrong when drupal construct the menu tree. In short:
When you view the translated page, I achieved that the menu entry for this page also pointed to the page, so that you could click on the menu again and still come to the translated page.

But if that menu entry has children, it should unfold when you view the page. But drupal thinks that the translated page,. the one you just visit, doesn't have a menu entry, because it doesn't find one in the database (where the menu entry still shows to the original page, not the translated one).
Therefore it will not unfold the tree while viewing the translated page, only when viewing the original page. And this doesn't make any sense.

I could hack this by rewriting the database, but then you have a problem when two people view the page and its translated version at the same time.

Conclusion: I don't know what localized menues are for and how they should work. And I guess only Jose can explain it. At the moment I think that localized menue items can only point to a language neutral page, i.e., they always show the same page, no matter what language you select. But the menu title can change.

Consider e.g. the "Search" entry from drupal. With my settings, the path is "/search/" or "en/search", but the page is always the same. But when the string "Search" is localized, the menu entry for the search page is either "Suche" or "Search".

The content of the search page can of course be localized, too, if all strings shown there are handled with the t() function.

But what you and me want to do, i.e., create a page and one or more translated versions for this page, will not work with localized menus. For this, you will have to create two different menu items. And the drawback is that all children will have to be recreated, too. My idea of a translated page with a menu entry and menu children which are language neutral, cannot work. Thus, when you translate a page and the menu item of this page has menu children, you must translated all of those children, too, or they will not be shown when you visit the translated page.

I had already taken your word for it :) and created a menu for each language. I suppose it all comes down to Drupal's way of handling multilingual content, not as one item with different language versions of it, but as separate items that are related. In my case the static pages that need to be available in different languages in the menu are limited and not extended that regularly, most content will be news appearing with Views so I won't have to be adding menu entries all the time ;)
Related, though a different topic, is multilingual taxonomy. You can have a fully 'localized' taxonomy but it involves translating strings and when I tried I didn't find those; I chose to go with translated taxonomy terms. That handles taxonomy the same way as nodes and it works, just a little more user input. It can all be a little confusing ;)

W.r.t. miopas hack in post #17:

For the non-ugly way ;-) you must increase the module weight of at least i18nblock, possibly others, too, which were loaded after i18nblock so far. I explained in http://drupal.org/node/263717 that i18nblocks_theme is responsible for calling i18nmenu_translated_tree for every block which finally translates menus. But the system module is loaded after i18nblocks and does return array_merge(drupal_common_theme(), array(..., thus rewriting the blocks theme from i18blocks with the defaults from drupal_common_theme.

So, login to your mysql database, start with USE name_of_your_drupal_database;
and then enter

      UPDATE system SET weight = 1 where name = 'i18nblocks';
      UPDATE system SET weight = 1 where name = 'i18nmenu';
      UPDATE system SET weight = 1 where name = 'languageicons';
      UPDATE system SET weight = 1 where name = 'i18ncontent';

Then you will find "translated" version of every menu in the block configuration page at admin/build/block/, e.g. Primary links[translated]
Menu strings that have been translated should localize in these menu blocks. For an easy test you should be able to create a language neutral page with a menu entry, then translate the entry (make sure you find it, see http://drupal.org/node/263124). Then the menu entry should switch to the translated version when you switch the language.

Please try that and let me know if it has the same effect as miopas hack. If it works, I will make it a patch for i18n.install.

Btw. you can check the module weights by

SELECT name,weight FROM system WHERE type = 'module' AND status = 1  ORDER BY weight ;

Now that I am really filling my site with content, I notice feel like SOMETHING really should be done about the multilingual menus, although to me it doesn't really matter which way. It is clear that a fully localized menu, if you happen to get that done somehow, cannot point to different nodes (in the proper language).

Both multilingual node-types and multilingual taxonomies go a different route than localized menus: separate nodes or terms are created, their languages defined, and then their relationship as translation is defined. With nodes this is done using 'translate' button, with taxonomy you first create your terms in different languages and then assign translation relationships. If this is how Drupal works with multilingual content, would it not make sense to put up a feature request that menu items can have translation relationships assigned, exactly like taxonomy terms?

It seems to me that the current problems with menus are a legacy of treating the Navigation menus in the same way as User-created menus, i.e. the Primary and Secondary Links. I think it makes more sense to treat them like nodes and terms (except for Navigation menus).

One practical problem this would solve is the following case: I define a menu item 'News' with the path /news for my English menu, and a menu item 'Noticias' with path /noticias for my Spanish menu. Now when I am at the News section and I switch language, it still takes /news as the path instead of /noticias. Translated nodes do not have this problem when switching language.

Since we are all dealing with the same problems I would like to hear your thoughts on this.

Fully agreed. I think we should have one menu item object that can store a list of node paths. When creating a translation you should have a checkbox close to field where you can define the menu item, sth. like "Reuse menu for translated node". If this was checked, an element ('en' => node/xxx) would be added, so a menu item could store an array like ('en' => node/xxx, 'fr' => node/yyy) and so on.

When you switch a language, the menu item would stay if there is an element with the matching language in its node list and change its href to this node. If the menu string has a translation, it would change at this moment, too.

Since the menu item would stay the same object when changing languages, it could also keep its children.

I'm not sure how this would interact with defining a languagefor menu items which you can also do in the administration section for menus. I don't even know where this makes sense.

I'm not totally familiar with how i18n works, but have you considered altering each menu link on output to add the language code as a prefix to the path? if, for example, es/node/1 gives you the translation of node/1 this might work.

That's what I did (but in a extender way to handle URL aliases) but you can read in #41 why this is not enough. Translations cannot be bound to the localized menu entries.

@Frank - if you know the parent node, is there an i18n function to return the translation for the active language? If so, than this should not be hard. You _alter the link to point to the translation before the link is rendered.

This is what I did! But that is not the problem! The problem is that the drupal menu system starts with the node it currently shows and searches for the menu item that points to this node. For a translation of the node there is no such menu item. That's not a problem for the menu item itself, because I changed the href before it was rendered so that the menu item indeed points to the translation.
BUT: since the menu system doesn't find any menu entry in the database (and that search is done before rendering and my altering happens), drupal does not unfold the menu entry. Thus, if the menu entry has children, they are unfolded and shown when looking at the original node. But when changing language (and menu link) to show the translated node, the menu entry does not unfold and the children are not shown (and they should if they are all language neutral or have a translation). And that's because drupal cannot figure out that this menu entry and the translated node are connected.
You need to extend a few lines in menu.inc to get that working. I might try it some time...

@Frank - it still sounds to me like something is wrong with your approach - can you point me to the code?

Let's start with the assumption that you can do this all via the core code - for example, look at the approaches I used in admin_menu module

No, I've not made a public patch for my code. I might do it, but you won't reach anything. Just look into menu.inc at the function menu_tree_page_data. You will find that this function searches for the menu entry of the node that is just shown. If it doesn't find one, it doesn't unfold any menu items to show its children (unless a menu item is always unfolded).

A menu entry can just point to one node. Thus, having the same menu item for a node and its translation is just not possible. Therefore, menu_tree_page_data will never find a menu entry for a translation of a node (unless you give the translation it's own item, of course, but then you don't share subtrees either).

Of course you can get around this by writing your own function that is exactly like menu_tree_page_data except that it also checks if there is a menu item that shows to the original version of a translated node. And if so, handle it as if it was indeed showing to the translated node that we just see in the browser. Use a theme function (just like i18n) to get that function applied to every block.
That would work, yes, but copying a function with 100 lines of code and changing just two lines is anything but an elegant solution. The right approach is to change the menu item object so that it can store references to a node and all of its translations. I proposed that on the developer list, but no one seems to be interested in that topic. From my point of view, it is just a quite bad design to have translations of node that are connected to each other, while translations of menus that can be connected, too, don't exist.

So, yes, you can do it. But I refuse to replicate such a big amount of core code to get it done...

@Frank - you misunderstand me entirely. Here's what I suggest:

1. Make you menu links using the parent (untranslated) nodes.
2. For each node that has a translation, set the corresponding links to be altered on output using hook_menu_link_alter (or alternately, just set all node links to be altered)
3. The menu tree is built based on the untranslated nodes (small hitch here - the ordering will go by the untranslated title - but you can avoid this problem by setting the weights)
4. Before the menu tree is rendered, each node link gets passed to hook_translated_menu_link_later (because you set it to be altered in menu_link_alter).
5. each such node link passed to the _alter hook, you look up any existing translation in the current language
6. If a translation node is found, you alter the link path & title accordingly.

Perhaps I'm misunderstanding what you want to do, but I think this will work. I vaguely suggested this to Jose at one point, but not in such detail.

No, I understand what you propose and this is more or less what I did. But that is not the problem! You are just talking about altering menu titles and links of menu items that we find in the menu tree. I did this already. I did alter the link path and the title.

But the problem is a different one. When showing a translated node, then some items are missing in the menu tree that we get from menu_tree_page_data! And when they are missing we cannot do anything with them.

If I do show a translated node, then I alter the link path and the title of the according menu item. But in the database, this menu item still links to the original node, not the translated node.
And therefore the menu tree is built without the subtree of this menu item (if there is one). Because the whole menu tree is built in menu_tree_page_data *before* I can do anything about rendering.

Assume that we have an original node in english with menu entry A and child A1:

A ---> links to node "English"
|-- A1 -> links to language neutral page

I localize the title "A" to "B" and translate node "English" node to "German" node. Now I can easily alter the menu item to reach:

B ---> links to node "German"

BUT: When showing node "English" menu_tree_page_data will return a tree
A
|-- A1

When showing node "German", menu_tree_page_data will return a tree
A

The children of A are missing because menu_tree_page_data checks in the database that there is no menu item linking to node "German". And this is correct, because the link altering is done after menu_tree_page_data hs built the menu tree. So whatever I do with rendering, hooking etc., I work on two different trees: when showing the translated node I get a tree without the children of menu item A.

Even worse: if A1 points to a node "English" and we translated that to "German" and localize "A1" to "B1", then "A1" will not be in the menu tree if we show node "German". So when we view "English" we have the menu item "A1" on the left. When we switch the language, we see node "German" but the menu entry "A1" disappears completely. That's the fault of menu_tree_page_data and no hook function can change this.

A solution to this that I'm thinking about currently could be: when altering the menu item (localizing, link altering) I could check if this menu item points to the translated node that we currently show. For this menu item, I could fetch the menu children from the database and add those to the tree that link to languageu neutral pages, to pages in the current languages or to some node that has a translation in the current language.

This way I don't have to replicate the whole menu_tree_page_data but just part of it. I will consider this.

ah, ok - now I understand.

If you can forgo the use of expanded links, you could use menu_tree_all_data to generate an alternate menu (as book module does). Otherwise, I suggest you look at the code from that function and reproduce it with the addition of the check for expanded links.

Thanks for the hint with the book module. I will look at this, maybe it helps!

I'm pretty sure that I can come up with what I want. I just wonder if anyone else needs this. From a design point, it looks straightforward to me that a menu object should be able to store links to all translations of a node, too. But not many people seem to share that view ;-)

@Frank - menu links don't really know what sort of page they link to - though there is already some special-case handling of node view permissions to reduce memory consumption.

Since there are proposals in D7 to use this same code for taxonomy term hierarchies, etc, I'm not sure how uch traction this will get.

As an alternative (and this would solve your problem a different way) could i18n replace the node content based on the current language? E.g. if my language is set to 'es' and I look at node/2, what's displayed is the 'es' translation, rather than the original content. You could accomplish this by altering the designated load functions for node/% and node/%/view using hook_menu_alter.

e.g., something like:

/**
 * Implementation of hook_menu_alter().
 */
function i18n_menu_alter(&$menu) {
  $menu['node/%node_i18n'] = $menu['node/%node'];
  $menu['node/%node_i18n/view'] = $menu['node/%node/view'];
  unset($menu['node/%node'], $menu['node/%node/view']);
}

/**
 * A function in i18n.module to load the relevant translation of a node
 * based on the current language.
 */
function node_i18n_load($nid) {

  // find the translation if it exists based on $nid and the current language
   ...

  return node_load($tnid);
}

Reading through all of this. I am just asking, did anybody get the Primary Links translated and showing up when changing languages?

For the primary links the hack from #17 (i18nmenu_localize_tree($tree);) work for me. My other normal block menu doesnt work :(

I try a lot of hours all the tricks here, but nothing works for my block menu.

But i find another problem: If i go in my Translation Interface i see double entries with the same item:xxx:title. i check this in my db, one of this is translated, the other isnt it. If i translated the last entry and delete the first one, the translation works at my primary links. I dont know why there are double enties.

So i really really hope, that anybody can fix this whole problem. im sitting since a few weeks here with my site adn cant lauch it, because this language problem. I totally agree Frank, this problem isnt good for the whole drupal project.

jdc

hello

i can create content pages with the node editor that are linked to the "primary links menu".
im translating this same node with the node editor, and give another name to the menu link.
im using the garland's theme default primarylink menu on top right.
im using the language switcher block.
everything is fine.
my menu links appear and dissapear depending on the language.

the problem i have is when im creating a custom menu link using admin/build/menu-customize/primary-links
the links im creating appear all the time for any language.

i have this problem using the garland's top menu but i dont have this problem using the block "primary links"

subscribing

For primary/secondary links, the menu won't get translated when handled by the theme. But it will when displaying it using a block.

I'd recommend this approach for primary/secondary link translations:

http://drupal.org/node/70194

@#43

Frank, I've tried updating the weights and removing the i18nmenu_localize_tree($tree) hack, it didn't work in my setup. Primary links were displayed regardless of language, and no [translated] appeared in the block configuration page. You have probably changed something else too, or have different settings.

I'm currently using i18nmenu only for translating menu titles of language neutral pages in my own menu, so it is very likely that just increasing the module weight works for me but misses many other cases :-(

subscribing

I like the proposed solution in #56. The way I see it, the idea is "locking" users into their language, so that my Italian users will only see their Italian translated pages, even if they go to an English node.

This solution has a logical problem: What do you do if you have a menu tree pointing to nodes in english, and aht the very bottom you have one node that has an english and a italian translation. If you look at the italian translation, the whole menu tree above should not be shown since all those items point to english-only nodes. If you show the menu items, it's not clear what should happen if you click on one of them while your selected language is italian. But they must be shown if a child of this menu tree is the active page and if it is in italian.

This concept only works fine if every node is either language neutral or has translations for all active languages, otherwise you can never find a logically clean way for showing or hiding menu items.

My solution was to use language neutral pages only, let i18nmenu localize the menu item titles and use the language sections module to put all languages content into the same page. This way, the menu items are always shown, they translate when I switch language, and users can see whatever I define in the language sections (stuff for each language, or stuff shown for all languages etc.). Makes it easy to e.g. share a table with linked files for all languages while just translation the table title etc.

I have D6.3 running, i18n-6.x-1.0-beta3 installed and Multilingual Menu active.

Somewhere high up in this treat it is stated "Create your menus (Multilingual Menu)".
But, how do I do this?
If I go to Administer==> Site Building ==> Menus, I do not see anything language specific, i.e. I can create new menus etc, but there is nothing about languages on these screens.

Do I look in the wrong place?

I link menu items to taxonimy terms... so the menu item doesn't link to a node in a specific language. The taxonomy terms are localized with the i18n-taxonomy module. So being able able to tranlate menu titles at admin/build/translate/search would be ideal.

But I can't find the strings. Updating and refreshing doens't help. Disabeling and enableing the Multilingual Menu module also doesn't solve this. I'm using drupal 6.3 and Internationalization 6.x-1.0-beta3

After browsing to the module code I've solved my problem!!

The below function is used to localize the node titels AND refresh the translate strings. The thing is that you're menu items MUST have the 'all languages' setting for language otherwise all localization is skiped. So now my menu items are in Dutch (my default language) with setting 'all languages'. And then the titles are localized through the admin/build/translate/search screen to english. It works perfectly.

/**
 * Localize menu tree
 */
function i18nmenu_localize_tree(&$tree) {
  global $language;
  foreach($tree as $index => $item) {
    $link = $item['link'];
    if ($link['customized']) {	
      // Remove links for other languages than current
      // Links with language wont be localized 
      if (!empty($link['options']['langcode'])) {
        if($link['options']['langcode'] != $language->language) {
          unset($tree[$index]);
          //dsm("Removed because language:".$link['title'].' language='.$link['options']['langcode']);
        }
      } else {
        $router = i18nmenu_get_router($link['router_path']);
        // If the title is the same it will be localized by the menu system
        if ($link['link_title'] != $router['title']){
          //$tree[$index]['link']['title'] = 'Translated';
          $tree[$index]['link']['title'] = tt('menu:item:'.$link['mlid'].':title', $link['link_title'], NULL, TRUE);
        }
      }
    }
  }
}

Right, and this makes sense. A menu item that is bound to a specific language, shouldn't localize to other languages because it shouldn't be visible in this other language.

The main problem with i18nmenu is just that it lacks some documentation and people don't know what to expect from it and how to use it.

I think 1. is not correct. Even if a menu entry points to a node with a language, it will localize when you have "All content. No language conditions" activated in the multilingual settings, but the href (path it points too) will be invalid if you use e.g. language prefixes in URLs.

One addition: i18nmenu localizes user defined menu titles only. The core menu system localizes menu items defined in hook_menu.

@ #71

The localization of MENU ITEM titels does work in on the theme default position

@ #70: Yes it made sense to my to when I found out.... but i whent through discussions and comment on the site for hours before that. For a new user this is very counter intuitive because translation of nodes works differently. With a node one marks the language the node is written and and then translates. With menu items one MUST give the menu item a titel in the default language and select 'all languages' and then translate... very confusing..... but logical when one understands the system

Well... a have to take back my previous post. MenuItem title localisation in the default thema menu area is kinda working for me. Its very weird. With only one menu item it doen't localize. When I add a second the first localizes but the second menu item doesn't. When I add a third. The first two localize but the third doesn't !
All menu items set to all languages and all localized through the tranlaste search page. But always the last created doens't show the translated string.

If I then delete the third item the second one doens't localize anymore. Allway one menu item not working!
I'm getting pretty frustrated now.

subscribing

Submit that as patch!

Hey,

I've had a specific problem relating to translating menu item titles, in that sub-menu item titles are not available for translation. I didn't see anything about that in this thread (but might have missed it!) and thought that as it was very specific, it was better to have it as it's own bug report - but still worth mentioning here.

It's here http://drupal.org/node/298612 and includes a patch (to the infamous i18nmenu_localize_tree function :) )

Thanks :)
Anselm

I've raised a new issue specifically about the problem highlighted in #43 ; I guess it has more change of being looked into if it's on its own as a very specific issue ! I also provide a patch to the install file ; and an admin page to set the module's weight.

http://drupal.org/node/299642

hi. . . i see this issue is closed.do we have a working example-howto or a code-patch?thanx

http://drupal.org/node/514108