Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Did this on a clean D7 installation:
Activated block translation, menu translation and Internationalization.
Created a new menu and set translation mode to translate and localize.
added one link to the menu with no translation or language.
In the translate interface I translated the menu item title to the desired language.
For detection and selection I activated the Browser option.
If menu is set as source for main links or secondary links the translation works fine.
if used as a block instead and added to a region the translation do not work.
I know other people who have encountered the same problem and I'll try to see if I can find why this is happening, but for now i've not found it.
/Peter
| Comment | File | Size | Author |
|---|---|---|---|
| #12 | menu_item_in_block-1152680-12.patch | 761 bytes | idflood |
| #11 | menu_in_block.patch | 806 bytes | jose reyero |
| #9 | 1155066_menu_in_block.patch | 806 bytes | jose reyero |
| #6 | menu_item_translated-1152680-6.patch | 727 bytes | idflood |
Comments
Comment #1
Jean Gionet commentedI'm getting the same thing, however I did nothing this message under /admin/config/regional/i18n/select
Any fixes for this? or idea when it'll implemented?
Comment #2
jose reyero commentedThat's not related to 'select options', but to i18n_menu_block_view_alter(), this is where the issue should be.
Comment #3
Jean Gionet commentedI seem to have my issue confused with this issue.
Mine is I created a custom menu, set it to be translated, added translation sets for my items and yet when I load the menu I get both languages displayed at once.
Comment #4
filijonka commentedIn the mentioned function begins with an if and it checks !empty($block->i18n_mode). The value of i18n_mode should be 5 I think and thereby returning true.
In the testing I've done it returns false due to that the $block->i18n_mode has the value 0 and therfor returning false.
Comment #5
idflood commented#1154128: Custom Menu with custom items are not filtered seems to have the exact same problematic line of code as this issue. Maybe a duplicate.
The question is, why is this !empty block check there? Should we simply check the menu i18n settings instead of the block one?
( moving this to 7.x-1.x-dev since bugs are fixed in dev version if I'm right )
Comment #6
idflood commentedHere is a first patch. I changed the if() to verify the block->i18n_mode OR menu->i18n_mode. Hopefully this should do the trick.
Comment #7
idflood commentedComment #8
zentasapprentice commentedAwesome. Patch works for me on custom menus.
I don't know if this is related or separate, or a total noob mistake, but links in the "main menu" do not localize like they do in custom blocks. Not sure why, all the settings are the same.
Anyway, I'm just getting rid of the "Main Menu".
Comment #9
jose reyero commentedYes, the problem is we are using here the 'block (title) translation options, which we shouldn't as menus have their own translatable (i18n_mode) state.
This is a patch besed on #6 (which works) just simplifying the logic a bit and using i18n_block_mode() which is the one intended for this case.
If you could give it a try and let me know whether it fixes all the issues....
(Also wondering whether we should test this too before doing other menu replacements on the module...)
Comment #10
Jean Gionet commentedpatch #6 worked like a charm!! thxs
Patch #9 gave me an error. I'm assuming I simply have to update to the latest dev release?
Comment #11
jose reyero commentedUpdated patch
Comment #12
idflood commentedPatch in #11 looks good and works as expected on my test setup. I've just rerolled it as it added a trailing space.
Comment #13
jose reyero commentedThen committed, thanks.
Comment #14
filijonka commentedthanks for the good work
Comment #15
jose reyero commentedKeeping our list clean.