I have a multilingual site with the content selection mode set to 'Current language and language neutral', I use the primary-links menu for all menu items. This means that if a page has x number of translations, it must appear in the menu x number of times - once for each translation.

The following should highlight my problem:

- Item 1 (no language)
    - item 2.1 (irish)
        - item 3 (no language)
    - item 2.2 (uk)
        - item 3 (no language)

So. Item 2 is specific to each version of the site, whist one of its children (Item 3) is not. In this case, item 3 must appear in the menu twice - both times pointing to the same node (I may be wrong here, but I can't see any other way to get Item 3 into the menu hierarchy). Now, visiting Node 3 on each version of the site produces an incomplete breadcrumb of:

Home > Item 1

but it should be:

Home > Item 1 > Item 2(.1 or .2 depending on the current site version)

Comments

I'm having the same problem: http://drupal.org/node/618700#comment-2531350
And a similar problem is present with menu_blocks...

could the root of the problem be something on the menu module or in the i18n one?

Please correct me if I'm wrong (this is oldish knowledge), but I don't think Drupal has ever cleanly handled the situation of having more than one menu link pointing to a given page. You can do it, and each menu link will function in so far as you will end up on the correct page, HOWEVER once you are on that page Drupal has no way of knowing which of those multiple menu links you took to get there, and consequently has no way of showing you the appropriate active trail.

hook_menu_breadcrumb_menu_list was an attempt to mitigate this kind of thing (for breadcrumbs only) if different languages used separate named menus, but it won't do anything for the situation you've described, where all the links are in the same menu.

If you do in fact get a sensible language-specific menu for each language, could you let us know which module handles that? (locale?) It might well be possible to build some matching support into menu_breadcrumb.

I've tried to configure two primary menus and a i18n variable to set for each language the specific primary menu. I've created two menu_blocks, one for each menu and now the problem has been solved in the menu_block. The breadcrumb menu still doesn't understand the right path.

But maybe I've found an interesting clue: on the menu_breadcrumb settings, we can enable/disable the menu and select the order of the menus.

If the english menu is before the italian one, the english breadcrumb will be correct, if the italian menu is before the english one, the italian breadcrumb will be correct. This makes me think that the menu_breadcrumb looks for the current path following the menu order.

Would be possible to have a i18n variable in order to have multiple menu_breadcrumb settings? One for each language? It could easily solve this problem :-)

Currently I've set:

$conf['i18n_variables'] = array(
'menu_primary_links_source',
);

in the settings.php.

What do you think about?

You're onto it :)

Some kind of clean integration with the standard multi-lingual modules would probably be a great addition to menu_breadcrumb, but FWIW the aforementioned hook_menu_breadcrumb_menu_list will facilitate exactly this (just without the nice interface).

That hook allows you to modify the configured menu order in code, before the breadcrumbs are generated. So an implementation could check the current user's language, and rearrange the array so that the menu for that language had precedence.

If you're happy to give that a shot, please post the resulting code here for others to see. Otherwise I guess you'll have to wait until someone has time to look into it...

In the meanhile I've tried to set "menu_breadcrumb_menus" in the settings.php as an i18n_variable: the settings are stored, but the module doesn't use it: the variable used from menu_breadcrumb is the last saved (even if th the i18n_table there are two records, one for each language with the correct settings).

I think it could be easier that the module will use the settings which already exists in the database. Unfortunatly there isn't documentation about this... or at least I'm not able to find it :-)

Tomorrow I'll try to look the hook_menu_breadcrumb_menu_list. I don't know what I could do... but I've to try: this is a very important issue I've to solve even if I'm not enough skilled :-(

I'll accept every suggestion.

Many thanks :-) :-)

About the problem I've pointed in #5 (the multilingual variable is not considered for the menu order setting), I've found a possible related bug: http://drupal.org/node/482800.
There is a patch, but the patch doesn't work :-(

This is just a brain dump/copy+paste from following your links, as I'm completely unfamiliar with this stuff.

The internationalization (i18n) module has a Multilingual Variables feature whereby you should be able to define language-specific values for persistent variables, such that variable_get('foo') might return different values depending upon the current user's language.

This is configured by adding the name of the variable as an element of the $conf['i18n_variables'] array in settings.php.
(e.g.: This is how FiNeX has enabled language-specific primary links in #3 above.)

Once this has been done, the variable will be marked as 'multilingual variable' on the relevant administration page. You must switch the site language while in the administration pages to set the value for each language. You must also switch the presentation language to match the site language.

The values of the multilingual variables will be saved in the i18n_variable table.

dddave claims that you should run cron after adding a new variable name to the i18n_variables array and before editing values (at least, that was my interpretation), but does not explain why.

And finally, the reason this mechanism is not working for menu_breadcrumb's weighted menu list (as investigated by FiNeX in comments #5 and #6) is that there is a bug concerning persistent variables which are set from nested form elements (#482800: 'This is a multilingual variable.' doesn't show up in nested form elements.), and our settings form element is $form['include_exclude']['menu_breadcrumb_menus']. That issue was marked as a duplicate of another issue which was marked as fixed, but the issue still exists.

@jweowu: all correct. You've wrote a great summary :-)

I've reopened the i18n bug hoping for some help on that side. I think we could close this after the i18n bug will be really fixed.

When the internationalization bug will be fixed, we should add how to configure menu breadcrub in a multilingual site in the documentation.

Do you agree?

+1 for more documentation on this subject

Any progress on this?

@fuse, I'm not familiar with multilingual vars myself, but it looks from the comments above like we need i18n to handle #482800: 'This is a multilingual variable.' doesn't show up in nested form elements. / #451120: Multilingual variables: Some fields are inaccessible due to logic problem before we can take this further.

The best way you can help this be resolved is probably by testing, contributing code towards, or even just raising awareness of those issues.

Here is an workaround:

- first issue is that the i18n module doesn't see the menu_breadcrumb_menus item as a multilingual variable, so it will not bind the menu breadcrumb configuration form to its submit function. You can add a dummy variable as multilingual variable, that is present in menu breadcrumb configuration form (eg: menu_breadcrumb_determine_menu) so i18n can attach to this form. Your settings.php may look something like:

$conf['i18n_variables'] = array(
'menu_breadcrumb_menus',
'menu_breadcrumb_determine_menu'
);

When the form is saved, the menu_breadcrumb_menus variable will be treated as multilingual variable though.

- second issue is that i18n module has a higher weight than menu_breadcrumb (and so it should be) but both modules uses the hook_init. Thus menu_breadcrumb calls the variable_get function before i18n can set up all the specific variables according to current language setting.

This can be fixed by creating a custom module that should have a lower weight than menu_breadcrumb module with the following content:

function custom_i18n() {
i18n_variable_init();
}

this will initialize system variables to language specific before menu_breadcrumb uses it.

Hope this helps!

I'd like to see these three Menu Breadcrumb issues fixed in the next release.

* #400748: Incorrect breadcrumb when multilingual node appears in menu more than once
* #717100: Problem with multilingual site and multiple menu's with same links
* #1054202: Hide the breadcrumb if the breadcrumb only contains the link to the front page not working with i18n menu.

In order to do that I'd like to get fixes tested and reviewed for all of them.

The release co-ordination issue is #1827248: Release co-ordination for Menu Breadcrumb 6.x-1.4 and 7.x-1.4. Aiming to release in a month from today. If you're interested in getting these fixes in, now is the time to patch or review these issues.

@petrica.martinescu - I'm not intimately familiar with i18n module. You suggest that i18n module should be run later than menu_breadcrumb. Why is that?

I'd prefer to use module weights unless there's a reason we can't; if that's not an option then we can look at checking for i18n module in hook_init().