I have a bilingual site in English and Japanese. English is default langauge. I am having a problem that, after I create a piece of content and its translation, I go to menus to check the relationships between the two translations and it says it doesn't exist. Taking you through my workflow may be a bit easier to explain. Also there is a screen shot attached:

1) Create english content, select english as language, click 'provide a menu link,' save.
2) click translate, choose Japanese (add translation), japanese language is selected and greyed out, translate everything (title, etc), click 'provide menu link,' save.

My menus work correctly - english shows up on english pages, japanese shows up on japanese. However, when I 3) click on 'menus' to review that these two items are related to each other as translated menu items, the relationship is not there. It says English, but 'add translation, n/a (title)' for Japanese. Now, what is interesting is this - when I look at this same page / menu item while in the Japanese mode it says Japanese is filled out correctly and 'add translation, n/a' for English. You can see also that for each, it says that each one is the source, which isn't the case - English is the source

My point is, shouldn't following my above workflow automatically create translation sets of each other? Do I need to go in and manually do this?

CommentFileSizeAuthor
Screen Shot 2011-11-25 at 3.05.06 PM.png157.29 KBGastonia

Comments

jose reyero’s picture

jose reyero commented
Category: bug » feature
Status: Active » Postponed (maintainer needs more info)

> shouldn't following my above workflow automatically create translation sets of each other?

Maybe, I don't know. How would that help your sites besides seeing the menu translation sets?

jose reyero’s picture

jose reyero commented
Status: Postponed (maintainer needs more info) » Closed (cannot reproduce)
iNade’s picture

iNade commented
Version: 7.x-1.1 » 7.x-1.4

I have the exact same problem : creating translation of node do not translate menu item.

1/ Create a node "MY NODE" in language A; set menu item for this node.
2/ Create a translation of "MY NODE" in language B; set menu item for this node too.

Expected behavior :
-> Two menu items related to each other.

Actual behavior :
-> Two differents menu items. No link between them.

iNade’s picture

iNade commented
Status: Closed (cannot reproduce) » Active
jose reyero’s picture

jose reyero commented
Status: Active » Postponed (maintainer needs more info)

Yes, I know but please answer question in #1

Gastonia’s picture

Gastonia commented

My concern was about the database and overall performance. Does this not add complexity and duplicate entry to the database? It's the same relationship, but it seems it has to be stored twice somewhere. I have not checked the database schema to verify that assumption.

For me it was very confusing. In fact, that's why I thought it was a bug. It seems that it would be best for both user experience and performance if the relationships that exist between nodes and menus that can be created automatically should be created automatically to avoid confusion as well as duplicate entry in the database, if that is the case as well, for better performance of the module.

drzraf’s picture

drzraf commented
Version: 7.x-1.4 » 7.x-1.x-dev
Status: Postponed (maintainer needs more info) » Active

The answer to #1 : why menu items association has been introduced in D7 if its of no use.
Actually I can't myself answer this.

But I can easily find a suggestion: menus having translatable menu items are a mess to manage.
The whole list output every possible menu item without any chance to filter by language.
Let's say 4 languages and 10 items, your listing is already 40 items long.
There's no <table> to help in sorting that that out while it has been done for translatable taxonomy terms.
Strangely I can't find a feature-request about this though every site having a couple of language should have encountered this issue.

AFAICT, the same problem for blocks needs a backport (#1790096: Add 'language type' option for block visibility. (Backport block language visibilty from D8)).
[ edit: I'm wrong on this, it's about public block visibility, no about about block visibility to ease blocks management in the admin UI ]

ahtoge’s picture

ahtoge commented
Version: 7.x-1.x-dev » 7.x-1.8
Priority: Normal » Major

I agree completely with Gastonia.

My site has 3 languages, and even though the relationships between the node, its translations and the menu items for each translation is obvious; my users have to go through a unneccesary complicated process to build the translation set.

jose reyero’s picture

jose reyero commented
Priority: Major » Normal

Ok, fair enough, it sounds like we could add this for some kind of consistency (and ok, maybe for admin UX too). And also due to popular demand, see #1933848: Menu translation problem when created by nodes

Just to clarify:
- Translations of menu items are useful for paths that are cannot be translated otherwise, say you want to translate two menu items for panels or views, or translate a node menu item for a taxonomy term one (mixed objects in translation).
- For objects that are related some other way, say nodes that are in a translation set, or taxonomy terms that are translations of each other you don't really need the 'menu translation sets'.

Now if anyone wants to work on a patch for this you are welcome. Just some tips:
- There are nodes, and taxonomy terms too for this case.
- Consistency goes both ways, so if you update the menu item translations when updating the node translation set, updating the menu translations should (possibly) update the node translation set too...(?)