We have just spent several hours debugging the most obscure front page / menu item problem imaginable... under very specific circumstances, some menu links on the front page of an internationalised site weren't appearing, which we traced to the fact that the items' access flags were set to false because Drupal incorrectly worked out that their language didn't match the current page's language.

We have a site which had no i18n early on, and had a default site frontpage set (thus a variable called site_frontpage in the variable table). We now have the frontpage as an internationalised variable, so the site db also has site_frontpage's set in the i18n_variable table.

The old default frontpage was english, the page with the error was Indian (site.com/in). The default English front page works fine, but the frontpage at /in was missing menu items.

Here's what we found:

Menu.inc's menu_tree_check_access() contains:

    $result = db_query(db_rewrite_sql("SELECT n.nid FROM {node} n WHERE n.status = 1 AND n.nid IN (". $placeholders .")"), $nids);

which triggers db_rewrite_sql, which ends up calling i18n_selection_mode().

i18n_selection_mode(), among other things, can be used to return the language, set at $current_value, and in our case was returning the wrong language (EN rather than IN). We discovered that it was related to the value of 'q' (as in $_GET['q']) which contained the value of the default site frontpage (the English one) not the translated site_frontpage (the Indian one).

Now, i18n_init() exists to internationalize the 'q' variable when loading the front page. It works quite nicely. But as it turns out, it isn't run soon enough.

i18n_selection_mode() calls menu_get_object('node'), which calls menu_get_object(), which calls menu_get_item() which looks at 'q' with a _GET['q'].

Unfortunately, in our tests i18n_selection_mode() runs several times before i18n_init() and thus the value of 'q' is not yet internationalized. The problem is made worse by the fact that i18n_selection_mode() uses static caching to do its stuff only once.

In other words, in the case of a site frontpage where that site had a site_frontpage set BEFORE i18n was turned on, because i18n_selection_mode() runs before i18n_init(), it statically caches the language of the original site frontpage, not the translated site frontpage, as it would do if it ran AFTER i18n_init().

We fixed this by calling i18n_init() from inside i18n_selection_mode(), which certainly works, but is perhaps not the ideal solution because it means that i18n_init() is called more than once.

        if (($node = menu_get_object('node')) && $node->language) {


        if (($node = menu_get_object('node')) && $node->language) {

Alternatively, deleting the site_frontpage row from the variable table will do the trick as well, but it's really just avoiding the fundamental flaw that i18n_init() is doing something that needs to happen before i18n_selection_mode() ever runs.


jeff h’s picture

Also, I forgot to mention, there's a probable relationship with the issue at http://drupal.org/node/513600

GiorgosK’s picture

Title:i18n_init() not run early enough» i18n_init() not run early enough - frontpage primary menus in wrong language or dissapearing
Status:Active» Needs review
new601 bytes

I have the same exact problem - wrong primary menus on frontpage
created a patch which avoids running i18n_init all the time

if($current_value=='') i18n_init();

run it from your root drupal installation with i18n 1.2 installed

making the title more descriptive possibly for others to find

GiorgosK’s picture

Version:6.x-1.1» 6.x-1.2

forgot version change
if patch does not work with dev version please reply and I can provide

Bilmar’s picture


GiorgosK’s picture

it would help a lot to explain under what circumstances you get this error and if this patch works for you (without any side effects)

marcushenningsen’s picture

Priority:Normal» Critical

Wow, thanks a bunch for this patch. I was going crazy because menus were acting weird. This actually also solved a problem with the right menu items showing up in the right language.

This seems critical (changing status). We probably need more reviewing. I've have no idea if the creates negative side effects.


ebeyrent’s picture

We attempted to use this patch today, but saw no difference in behavior - our menus are still disappearing.

apophis.ch’s picture

Status:Needs review» Needs work

Same here, the patch doesn't help.


Same Menu:

It seems like i18n is not compatible with the newest drupal version. Its very hard to see where this issue comes from. It not only affects menu, also block translation does not work, either it disappears completely or is in the wrong language.

GiorgosK’s picture

Status:Needs work» Postponed (maintainer needs more info)

For all I know the patch still works on all the sites I have tried it even with newest version of drupal on it
and the solution was given by the original user which means it was working for him as well

please give more details as to your setup and modules used
please use garland theme for testing (as it might be an issue with your theme)

also try using the following i18n_variables in your settings.php

$conf['i18n_variables'] = array(
apophis.ch’s picture

We partly solved it, we cannot link with a french title to a german node. If we do, the menu entrie disappears. A VERY strange behaviour? can anybody tell me what the reason is for that?

weseze’s picture

Had the same problem with a clean install of Drupal 6.16 with i18n 1.3. Patch in #2 fixed the problem.

closed_account’s picture

Status:Active» Postponed (maintainer needs more info)
GiorgosK’s picture

@Dominic Mayers
just for reference where is this code that you changed ? what file ?

closed_account’s picture

closed_account’s picture

new556 bytes
closed_account’s picture

Status:Active» Postponed (maintainer needs more info)
new555 bytes
closed_account’s picture

Guty’s picture

#16 works for me. i18n 6.x-1.3
Symptoms before the patch:
Primary and secondary menu from the theme (Acquia Marina) just seen in default language. When I switched to a translation (click on the logo) the menu items have been gone.
Later on I changed the menu items from default language (English) to language neutral. So I've been able to see these menu items in 'language neutral' when I switched to a translation.
All this happened after the update from Drupal 6.15 to 6.16. At the same time I updated i18n form 6.x-1.2 to 6.x-1.3.
Then I faced this bug and also http://drupal.org/node/595160
As already stated 'inline': I use path prefix with language fallback.

Hope this helps.
Thanx for the fix.

GiorgosK’s picture

Status:Postponed (maintainer needs more info)» Reviewed & tested by the community

why was this set to postponed ?
there is two solutions and we need maintainer to take a look at them

marcushenningsen’s picture

I believe you changed the status yourself in #9

JGO’s picture

Sorry, #16 is really not working here!!
It only works when commenting out both lines. Why are those lines there? It works with everyone when they are commented out.
I have the news module.

Setting language to dutch, I see:
Latest news (--> block title, latest 1.4 version has a nice bug _again_ which makes this is not translated anymore lol)
Nieuwe website

When commenting out those 2 lines I see what mixed language should see:

Latest news (--> block title, latest 1.4 version has a nice bug _again_ which makes this is not translated anymore lol)
Websense Unveils TRITON
Entrust Advances Methods for Secure Third-Party Communication
Nieuwe website

So those 2 topics are untranslated, so I need the english links.
When using the patch in #16 I don't see the 2 english only links

Maybe it fixes something else, but it's certainly not fixing the related #583836: Bug with node language != interface language too

closed_account’s picture

Status:Postponed (maintainer needs more info)» Reviewed & tested by the community
closed_account’s picture

Status:Reviewed & tested by the community» Active
closed_account’s picture

Status:Reviewed & tested by the community» Active
marcushenningsen’s picture

Status:Postponed (maintainer needs more info)» Needs review

I just tested the patch in #16 again, in for me it works. I know I should try to reproduce it with a fresh install, but I don't have the time right now.

If you don't mind I'm changing status again, since what we need is exactly this, reviews in order to be able to reproduce the error.


JGO’s picture

the guy with the closed account also verified the problem
Please try these steps to easily reproduce it:

1) Install EN, FR , NL
2) Set content negotiation to mixed
3) Install the "usernews" module
4) Post 3 EN usernews topics
5) Translate one of the 3 to NL and FR
6) Add the latest news default block
7) It will not show the EN only nodes when switched to NL or FR

Bartezz’s picture

Status:Needs review» Reviewed & tested by the community

The patch at #16 works like a charm for me...

- Have EN as default and NL and FR as supplement languages
- Current language and language neutral.
- i18n menu module enabled

Before this patch when I switched to FR from an EN node for example I would not see the FR menu when I was trying to switch to an untranslated node.
Reason being that the system would show the default language node (EN) and was determing language based on the untranslated node $current_value = $node->language and not based on the path $current_value = i18n_get_lang();

Hope this gets committed soon!


Guty’s picture

I just want to mention that #16 works for me with version 6.x-1.4 of this module. :-)
On the other hand this means that this issue is still not fixed in 6.x-1.4. :-/

JGO’s picture

Why is it not fixing for me then? See post #26 and verify if it fixes anything. You can't make up a solution without knowing the exact cause. This would more be a workaround than solution, just as commenting out those lines is. (Because that works too!! in my case and yours too probably!)

Guty’s picture

Have you ever tried without usernews module?
I run 3 languages just like you. Default language is 'en'. I also use i18n's 'path prefix with language fallback'. Do you use that too?
Don't know if I find time to try the patch on a fresh install.

JGO’s picture

yeah it did not only happen with the usernews module, but also with other stuff.
But the usernews module is the easiest example. IIRC it also happened with the stats block.

Bartezz’s picture

Indeed.... that's why I changed the status from needs review » reviewed & tested by the community

Jose is a busy man, I will contact him and see what's up!


Jose Reyero’s picture

Status:Reviewed & tested by the community» Needs work

While I see the patch in #16 makes some sense, I think there's something wrong with it that may cause other issues.

As i18n_selection_mode() is suppossed to cache the mode ('node') and the language (node language) , for this case the wrong language may get cached.

So we should either run i18n_init() before, adding some static for it not to run twice or do the same with i18n_selection_mode() so if it is run before i18n_init() it doesn't cache the mode nor the language (which could also translate in having 'i18n_init' re-setting 'selection mode'.... (we can use global variables instead of static)

Does this make sense?

Jose Reyero’s picture

new3.61 KB

Please give a try to this patch. This should fix some of these issues, not sure if all of them. But it also should fix some others, like displaying the right menu items when having different content / language interface.

Though maybe it's bigger than needed for this single issue, it moves everything to its place and provides a reusable _i18n_init() for the future.

What it does:
- Use the default selection mode for queries run before module_init(), not sure where it applies though it should be 'safer'
- Does all variable and path initialization before setting the 'selection mode' for the rest of the page

JGO’s picture

Hi Jose,

To be sure: can this fix be applied to 6.x-1.2 ?

cbovard’s picture


Jose Reyero’s picture


patches are for -dev version, though I guess this will apply cleanly for latest stable versions too.

Jose Reyero’s picture

Status:Needs work» Fixed

Ok, let's speed up the testing. I want to put out a new release ASAP,

The patch is now applied on -dev. Please try and let me now.

wils.solutions’s picture

Hello there,

I am facing the following problem:

- My app uses English and French version.
- Switching the language isn't working, I am getting always the English labels instead of French ones.

Will this path fix this problem?

Thank you

Bartezz’s picture

Give it a go and find out :) If it doesn't just roll back! And always test on a non-production server!


GiorgosK’s picture

as per #38 fix is in the DEV version
try it and report what you find
if it does not work go back to the previous stable version

Jose Reyero’s picture

Done one more 'init' rework to fix this new (Drupal 6.17) one, #817164: static-cached variable for drupal_is_front_page() conflict with 'site-frontpage' multilinigal variable?

Testing and feedback welcomed. We want to put out a new release ASAP

JGO’s picture

I can confirm it's fixed with the latest maintenance release. Although I'm still suffering from an old old bug: #634144: i18n views content negotiation + Mixed current language

Status:Fixed» Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

Bartezz’s picture

new647 bytes

I think I still have this issue with 6.x-1.7 (2010-Sep-10) which I just installed.


- two languages, English as default
- create a node in English, lets say en/node/1
- view en/node/1
- switch to Dutch with language switcher -> nl/node/1
- primary menu shows no Dutch links and none of the English links except the link to nl/node/1 (although it should be en/node/1)

Looking at the patch in #16 I created this patch against 6.x-1.7 to have i18n_selection_mode based on the active language instead of the node's language.

This has solved my problem and everything else seems to be working fine.

@Jose: can you live with this patch or is it to rigurous? I could make it a setting to use i18n_selection_mode('node', $node->language); by default and to use i18n_selection_mode('node', i18n_get_lang()); by option?


Bartezz’s picture

new648 bytes

Hmm, somehow my patch was created against 6.x-1.5, something really screwed up with my version manager.
Anyway here's the patch against 6.x-1.7 (2010-Sep-10).


JGO’s picture

Status:Closed (fixed)» Active


Issues came back in 1.7 !!! what a mess is this!
And the fix from bartezz does not fix everything for me :( :(

EDIT: Sorry in my case it's the views handler. So I cannot comment on bartezz fix. For me that one makes no difference.

About the views issue: It says: Broken/missing handler
What do I need to make my view work again ?

JGO’s picture

Ok, for views it's split up now apparently: http://drupal.org/project/i18nviews
I did not notice before, but I did not delete the i18nviews dir inside the i18n project. Because of that I did not notice it earlier.

cedricmc’s picture

Hi there,

after hours of wondering what I did wrong, I've just realized that it is a bug. I detail which is my particular case, if that may help you.

- My site may be found at http://www.icmat.es (when it is switched on).
- Multilingual (English, Spanish), being English the default language.
- Language negotiation is set to "Path prefix with language fallback".
- Content selection mode is set to "Current language and language neutral".
- All the nodes are translated.
- All the menu items are set to "All languages".
- All the menu names but one are translated by "admin/build/translate".

What does happen:
- When the prefix is "en" (for English), the (primary) menu appears properly (in English), independently of the language content of the node.
- When the prefix is "es" (for Español), the (primary) menu does not appear (not even in English), independently of the language content of the node.

- node/1 has English content.
-- http://cryss.imaff.csic.es/en/node/1 (primary) menu in English.
-- http://cryss.imaff.csic.es/es/node/1 has not (primary) menu (nor English, nor Spanish).
- node/2 has Spanish content (translated from node/1).
-- http://cryss.imaff.csic.es/en/node/2 (primary) menu in English.
-- http://cryss.imaff.csic.es/es/node/2 has not (primary) menu (nor English, nor Spanish).

Comment http://drupal.org/node/614548#comment-3453896 did not solve the problem.

plach’s picture

Version:6.x-1.2» 6.x-1.7
Component:Code» Menus

I've fixed the language selection problems in http://drupal.org/project/i18nmenu_node#language-selection. We might want to move that approach from i18nmenu_node to i18nmenu.

Edit: related issue #782018: Child Items not showing in String Search.

Bartezz’s picture

No news on this? Looks like my patch still does the job for me...
Haven't encountered any other problems?


jhedstrom’s picture

I'm running into an issue similar to that detaile in #49. Oddly, if I comment out these lines:

// Node language when loading specific nodes or creating translations.
if (arg(0) == 'node' ) {
      if ((
$node = menu_get_object('node')) && $node->language) {
i18n_selection_mode('node', i18n_get_lang());
      elseif (
arg(1) == 'add' && !empty($_GET['translation']) && !empty($_GET['language'])) {
i18n_selection_mode('translation', db_escape_string($_GET['language']));

the menu items work as expected for an i18n selection mode of 'mixed'. Looking at the documentation for the i18n_selection_mode function, I don't see 'node' as one of the available arguments, so I wonder if this is a mistake introduced in the patch from #34?

JGO’s picture


Please see all my comments, all the time I've seen fixes which never completely worked.
Only thing that worked 100% properly was commenting out that line. Although I must say something was improved, because weirdly enough I don't see the problem all the time anymore.

Bartezz’s picture

In stead of your comments you might want to report better what exactly does work with what settings, what patch and which modules installed. Besides that you might want investigate yourself by disabling modules, changing settings to see if this changes things and possibly provide a patch.

I've described my issues clearly and provided a patch to solve these issues. This patch might not solve other problems. Problems I don't have so I can't investigate. This is open source, part of the reason for it being open source is that users can provide code and functional improvements and bug fixes. Please don't hesitate to get on board and provide your own patches.


JGO’s picture

I put tons of time into finding the problem. You can see my post #26 and a lot of others.

Look to this link to see it happening, the EN items should be displayed as well. It works on other pages, but not on this page for example. Of course you have block caching which hides the problem when you first go to a page where it works and then come to here or vice versa.

Only thing I know is that when I comment out the line, all works perfectly everywhere all the time.
Nobody reported problems when the line was commented out either as far as I know. It would be great if somebody explained what the use of that line is?

Bartezz’s picture

What EN items should be displayed as well?

professorbikeybike’s picture

I ended up fixing this by adding an implementation of hook_init to a custom module weighted more heavily than i18n. Within that function, I simply reset the selection mode:

function custom_init() {

without this, what was happening was that the lines introduced in patch #34 set the selection mode to 'node', which didn't play well with the query alters that populate the menu properly.

ctsimps’s picture


am relatively new to drupal and have made a multi-language site and all is well except on the homepage when I switch from default (en) to traditional chinese (zh-hant) most of my menu items disappear. this doesnt happen when i switch language on any other page.

I think that it is to do with the fact when I switch it isnt going to example.com/zh-hant/node/2 as it is supposed to. it is going to example.com/zh-hant.

is this the same problem as you are having or something different?

Bartezz’s picture

Have you set frontpages for each language under /admin/settings/site-information?
You should declare this a multilingual var in your settings.php if you haven't and then set it for each language.

# settings.php example
$conf['i18n_variables'] = array(

If you have done this and still have problems with disappearing menu items try http://drupal.org/node/614548#comment-3453896


ctsimps’s picture

works perfectly now.

many thanks bartezz

Bartezz’s picture

What was it that helped fixing it? The patch? Always important to post back this kind of information.


jlbretton’s picture

Hi all,
Here also a menu story.
I have to languages running well together except when saving a comment in a the secondary language.
If a user make a comment on the secondary language, it looses the entire main menu after having saved the comment, falling back to the default language without the menu and path aliases.

Applying patch #46 helps but not enough. It brings back the menu, but the wrong one, the default language. The path alias is also still missing.

Note: The content I'm talking about is not on the front page

Language Settings:
- Language negotiation: Path prefix only.
- Content selection mode: Current language and language neutral.
- Default language: fr
- For French : Path prefix: (emply)
- For English: Path prefix: en
- For both languages weight: 0

Menu Configuration:
- No primary neither secondary, but one menu block with all the languages, each entry having one language define.

Any idea how to solve that?

Bartezz’s picture

Could you check what it says inside the action attribute of the comment form in question?


jlbretton’s picture

Hi Bartezz,
This is what I have:

*** *** ***
FRENCH start page (default languge)
Page-node-179 with correct menu and alias

<form action="/comment/reply/179"  accept-charset="UTF-8" method="post" id="comment-form">
<input type="submit" name="op" id="edit-submit" value="publier mon commentaire"  class="form-submit">

Form french and page french with correct menu and alias
<form action="/comment/reply/179"  accept-charset="UTF-8" method="post" id="comment-form">
*** *** ***

*** *** ***
ENGLSIH start page (non default language)
Page-node-180 = Form english and page english with correct menu and alias

<form action="/en/comment/reply/180"  accept-charset="UTF-8" method="post" id="comment-form">
<input type="submit" name="op" id="edit-submit" value="save"  class="form-submit">

Page english without alias
Form english = node 180 but text content of the from in french and wrong menu
<form action="/comment/reply/180"  accept-charset="UTF-8" method="post" id="comment-form">
*** *** ***

Bartezz’s picture

So that's not the cause. Probably the menu block is causing this. Did you create this via menu_block module? Can't really help you as there are so many modules influencing menus and so many different set ups... What I did to come up with the patch in #46 is to drupal_set_message(print_r($variablename, true)) a lot if lines within the i18n module before the if then statements to see what values it uses to define waht or what not to show.... prepare for some rigorous debugging!!

Cheers n good luck!

jlbretton’s picture

Thanks for your quick input.
Actually I'm not using any fancy module for menu creation. Standart menu block only. But what might have some impact:

All standart menu, except the summury page of all the language specific articles page (an article = content where you're allowed to write comments).
The base menu of Articles, is a multilingual Views page, so menu level 1 coming from there. (--> Name of menu ARTICLES --> In english and in frensh same name --> ARTICLES menu = multilingual ). I sort the language specific pages result in Views but with a multilingual Menu --> ARTICLES
1. Page with all summury articles --> coming from VIews. The menu level one coming from here.
2. Click on an article summury --> brings to full page of the article (= not a view)
3. Commenting on the current article trigger the problem explained before.

ctsimps’s picture

sorry for delayed reply...the patch was what fixed it. cheers

Bartezz’s picture

ctsimps, please be more detailed in your comments! There are 68 comments in the isue queue, people have to read all issues to find out that you are probably talking about this patch; http://drupal.org/node/614548#comment-3453896

Is that correct?


Jose Reyero’s picture

new1.12 KB

Please give a try to this patch and let me know whether it works.

plach’s picture

Status:Active» Needs review
jcassano’s picture

I recognize this is a very long issue thread, but I think my issue falls under this as well, though it's slightly different than the other variances I've seen listed above. Right now I'm having a very peculiar response with internationalizing menus. I have created one menu, translated all the menu items, and everything is fine. But for some reason, on another menu it seems like it only displays menu items if the content was originally created in the currently selected language.

For example:
-Two languages, English and Turkish
-Path prefix with language fallback (no prefix for English, tr for Turkish)
-node/1, node/2, node/3 are all translated as node/4, node/5, node/6 respectively.
-when viewing node/1, node/2, and node/3, I only see links to node/1 in the menu.
-when viewing node/4, node/5, or node/6, I only see links to node/5 and node/6 in the menu.
-the menu items are all translated in the translate interface section.

The important thing to note here is that node/1 was originally created in English while node/5 and node/6 were originally created in Turkish. This corresponds to which menu items show up in which language, which leads me to believe this is a bug.

This might be something obvious I've overlooked, but it seems to be like I've done everything the exact same way for both menus, so I'm posting here instead of as a support request. I'm happy to repost this as a support request though if that's where it belongs.

ColinMctavish’s picture

nothing is working for me and this is whats stopping me from launching my site..

squinternata’s picture

I think i have the same problem,
-Two languages, English and french
-Path prefix only
-node/1 translated in all languages
i have a menu block setted to all languages with item(all languages) linked to the node/1
i see the menu only when i m in english interface as soon as i switched in french the menu disappear.
is it possible to have only one menu item linked to the node and visible in all languages?
or i have to create a menu for every language?

ColinMctavish’s picture

I have it set up for both languages and it still disappears.

ColinMctavish’s picture

Version:6.x-1.7» 6.x-1.9

I really need this to be fixed. I am willing to pay someone. Please get in touch with me if you can help. I appreciate it immensely.

GiorgosK’s picture

#70 still applies cleanly with 1.9 version
and solves problem of primary menu in wrong language

@ColinMctavish please apply and review patch and report back in order to help this issue to get resolved

if patch gets reviewed by a few more people, than it will probably get included in the next version of i18n and will all have one headache less

Andrew Schulman’s picture

Hallelujah, #70 solved the problem for me. (My problem description is the same as in the original post.)

Andrew Schulman’s picture

Clarification: When I view pages, the problem is solved. The primary links are the same on all pages, including the front.

But when I edit pages, the primary links are wrong again: only links to pages in the same language as the page I'm editing are shown.

* Default language is English (http://www.tealtoes.org), and we have some translated pages in Vietnamese (http://www.tealtoes.org/vi).
* Language negotiation is Path prefix with language fallback.
* Content selection mode is mixed/default/neutral.
* From http://www.tealtoes.org/vi, when I go to any page and click on Edit:
* If the page is in English, while I'm editing, the primary links only show links to pages in English or Language neutral.
* If the page is in Vietnamese, the primary links only show links to pages in Vietnamese or Language neutral.

My i18n is 6.x-1.9, with #70 applied.

Should I open a separate issue for this?

Thanks for all of your work on i18n, and this problem in particular.

steinmb’s picture

Status:Needs review» Needs work

Tested the patch in #70, default language != en

1. It fixed that the gone main/secondary-menu on , great work!
2. It does not load the translated front page when your switch language, is this a separate issue?

Best regards

steinmb’s picture

Status:Needs work» Reviewed & tested by the community

Ooobs, disregard #80 (2). The front page multi-language tricks found at http://drupal-translation.com/content/setting-front-page-language takes care of that. Marking this as RTBC, let's get this old issue rolling.

Jose Reyero’s picture

Status:Reviewed & tested by the community» Fixed

Committed the patch in #70

Status:Fixed» Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

organicwire’s picture

Version:6.x-1.9» 6.x-1.10
Status:Closed (fixed)» Needs work

Sorry for re-opening. The fix introduced a new bug for me. See #8470645-7