i18nmenu doesn't work with module-defined menu items.

Apparently the menu system can save extra information. In i18nmenu_menu_link_alter() the extra information is set:

$item['options']['langcode'] = $item['language'];

I can then see this information in the menu_links table. But it gets ignored. The only reason that I can think of is that there is already a 'contact' entry in the table without language and that it picks that one when verifying the language.

I'm going crazy. This:

  unset($tree[$index]);

Removes the links in the Navigation block. I just cannot find where the primarly-links are filtered..... frustrating!!!

A summary of what I've found out. (This way I can continue where I left of.)

1. menu_tree_page_data() loads all the menu items with that big query and puts it in $data['tree'].
   After the query all the menu items in all the languages are available.
2. menu_tree_check_access() removes the menu items that should not be seen by the user.
   1. In menu_tree_check_access() after the db_query(db_rewrite_sql()) all the links to nodes in the correct language have their access set to TRUE.
   2. Then there is _menu_tree_check_access > _menu_link_translate > that loads the extra options and finally _menu_check_access is going to set access to TRUE for the contact forms since it does the access callback.

This means that:

1. i18nmenu is completely useless for the moment since even if you don't set languages on the menu items it will work just the same because if the links are shown or not is decided by the language the link points to. The language you set for the menu item is completely ignored.
2. I'm wondering if it will even be possible to hide the link to the contact page in other languages.

This is one possible approach. For the menu items where a language is set we indicate that they're "special" by setting "alter". For these "special" items drupal_alter('translated_menu_link', $item, $map); is called. In that hook we set the access to FALSE for the items we don't want to see.

It's the only solution I can come up with for the moment so feedback is appreciated.

After you install the patch you should EDIT and SAVE all your menu items one by one with a language set so that the $item['options']['alter'] = TRUE; gets set.

Did you do that?

Well, this behaviour comes from the D5 version of the module so I'm not completely sure if this is the best way to proceed in D6. One reason I can think of is that some pages have no language, like the "contact" page. So in the case of the contact page, if I have a 3-language site I'll have the menu entries

• nl/contact "Contacteer ons"
• fr/contact "Contactez-nous"
• en/contact "Contact us"

With each entry having the correct language and it should only be shown when the user has chosen that language. With menu items having languages you have the most flexibility. When you set the language negotiation to "anything" you can have menu's with anything it you want. The thing is that the menu should filter on the language of menu items AND what the language negotiation is set to. Now the former wasn't happening at all.

Indeed, CURRENTLY i18nmenu leaves menu items with languages alone. It seems that the only work on it is done to support the i18nblocks module. My patch is the first attempt to make the i18nmenu module function for more use cases.

If you want an English menu with items that point to French pages, why not? The only thing is that the module should warn when you have menu items that are incompatible with your current language negotiation settings. And I'm starting to wonder why the language isn't applied to menu's rather than menu items.

The current state of affairs is that i18n worked way better for D5 than D6. Developmentseed also promised an upgrade path from D5 i18n to D6 i18n but it seems they're not coming through and honestly, IMO, it was a crazy promise to make.

I think that this is an example where the new i18n features that have been imported into core come into conflict with the things that existed. I hope to have time one of the coming weeks to look at this further. The patch works for my current use case but is not ideal for bigger sites and it doesn't feel right.

Thus we need to work out how we would like menus to work. I need to look at the "language negotiation" thing some more because I thought that it means "show nodes of this language by default" but apparently it blocks access to the other languages as well. The two options I can think of are:

1. Show all menu items with the current language in the menu.
2. Show menu items to nodes to a valid language. "Valid" is determined by the language negotiation. (= current situation without a working i18nmodule).
3. (2) + only menu items that have the current language

In D5 it worked as (1) and is the way I would want to have it work in D6 as well. So I'll try to cook up a patch but it will be hard since the menu item visibility is done in core and I'm not sure if you can intervene in that process through a module.

A combination of (1) and (2) it is. If no language is set on the menu item only show it if it points to a node that is visible under the current language negotiation settings. If a language is set on the item show it if the interface is in that language. I'll try to give this a go.

Well the patch above does exactly that and still works with the first beta of i18n module. So this is still ready for review.

The above is incorrect. Links that have a language but point to a node that has another language will still not be shown. That's the interesting part to investigate since the menu system uses #access to hide them.

@19:

I've tried the 'Language dependent variables' approach but it doesn't seem to work. The links in different language to the contact page keep appearing in all the menus. I've only enabled the Internationalization module for this, the is no language dependent module as far as I can see.

How can I verify that I'm using separate primary menus for each language? I'm also using D6 so the explanation at http://drupal.org/node/70194 isn't totally correct anymore.

UPDATE: It works as advertised (It was menu_primary_links_source in stead of menu_primary_menu). Thanks Jose!

For me this ticket can be closed since it's possible to do what I wanted to do with the language dependent variables. I'm am wondering what the i18nmenu module is good for then.