vanishing menu entries (rewriting menu_tree_check_access sql)
| Project: | Active Translation |
| Version: | 6.x-1.1 |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs review |
Jump to:
Active translation should not rewrite queries from menu_tree_check_access. This can lead to vanishing menu entries.
To reproduce at least two languages need to be active (Example EN, DE)
1.) Create a node (page or book) in EN and translate it to DE.
2.) Create a menu entry for the original EN node
Now switch the language -> The menu entry will disappear in the german menu (happens for all menu entries which directly point to a specific node).
The attached patch prevents that menu_tree_check_access queries are rewritten. Patch definitly needs review.
Still can be improved as the menu entry (when switched to DE) will point to the EN node which will be loaded. At least (if configured) the "Translation note: A German translation of this content is available here" shows up although it would be nicer if the correct node would be loaded directly.
| Attachment | Size |
|---|---|
| menubug.patch | 851 bytes |
#1
i was able to verify the behavior you described but i'm not sure that it's really a bug... since the user created menu items aren't translated and are per language, you'd need to add in separate menu items for each language to have the link translated right?
i guess i need to disable active translation and compare that behavior.
#2
Can't try it out at the moment but afair you don't need to make a second link (unless you use active translation without the hack-patch above). Any menu title goes through t() automatically from the menu system (still needs confirmation). So the link title is translated as long as appropriate string translation is available. The problem with this translation is that the link itself still points to the original version of the page.
And now it becomes worse: Afair (I tried the following out once): active translation will not load the translated node as it does not rewrite the queries in this case of node loading.
So it should not be a problem that the menu entry is translated but still the "wrong" node would be loaded (but active translation inserts the message that the content is available in the selected language too). Making a second link to circumvent this behavior is not intuitive and impractical (and just not possible to explain to my users)
#3
you're right, i'm thinking of the D5 behavior where only core menu items were translated.
my hesitation with the current patch is that it's matching on very little and seems like it'd open up a whole different class of bugs. i wish it had more identifiers to match against.
so should we be altering menu items pointing at node/* to point to their translation?
#4
I'm not convinced this is a bug. More a feature request, because just as i18n module itself:-
From http://drupal.org/node/313302
The feature request would be another module, or extension to this, that hooked into the menu system, used the active_translation lookup table and replaced the item iff there was a translation in the user language. I'm not sure if this is possible by the way.