Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Problem/Motivation
Version 7.x-1.14 seems to have broken menu translation, and it is still broken in 7.x-1.15 and in the current dev branch.
Steps to reproduce error:
- Fresh install of Drupal 7.53.
- Enable module Entity Translation Menu and all required dependencies
- At admin/config/regional/language/configure, enable URL languge detection method for both user interface and content. Save.
- At admin/structure/menu/manage/main-menu/edit select Translation mode: Translate and Localize. Save.
- Enable two additional languages, e.g. Italian and Portuguese
- In Structure > Content Types > Basic page: edit > Publishing options, select Multilingual support: Enabled, with field translation, and save.
- In Structure > Content Types > Basic page: manage fields > Body: edit, click Enable translation, and save.
- Content > Add content > Basic Page
- Set language to English, type in a title "TITLE (all)", check 'Provide a menu link' and type in Menu link title "MENU LINK EN". Save.
- In Translate tab, click link to add first translation, e.g. Italian
- Change the Menu link title to "MENU LINK IT" and save.
- Observe that page is displayed in Italian (URL is /it/node/1) and the menu link "MENU LINK IT" is visible.
- In Translate tab, click link to add second translation, e.g. Portuguese
- Change the Menu link title to "MENU LINK PT" and save.
- with i18n version 7.x-1.13: Observe that page is displayed in Portuguese (URL is /pt-pt/node/1) and the menu link "MENU LINK PT" is visible.
- with i18n version 7.x-1.14 and 7.x-1.15: Observe that page is displayed in Portuguese (URL is /pt-pt/node/1) but the menu link "MENU LINK EN" is visible. Further, edit the Portuguese translation and observe that the menu link value is filled in as "MENU LINK EN". And at /admin/config/regional/translate/translate set Limit search to: Menu and Filter to see that the String "MENU LINK EN" does not have a Portuguese translation. (If one is supplied by manually translating the string here, then Drupal does use it when displaying Portuguese content.)
Sorry I haven't been able to find out why this has happened.
Proposed resolution
Remaining tasks
- Identify cause of problem
- Fix code and submit patch
- Expand tests to cover this situation
User interface changes
API changes
Data model changes
Original report by [username]
| Comment | File | Size | Author |
|---|---|---|---|
| #9 | revert_307b54dcdb_oct22_2016_issueNumber2338735-2848806-9.patch | 414 bytes | joseph.olstad |
Comments
Comment #2
joseph.olstadThere's over 49500 installations of 7.x-1.14 which was released last year in October 2016 and you're the first one to report this issue.
For this reason, I'm quite sure this isn't a bug so I'm reclassifying it as a support request.
Please consult the documentation
You can also consult the readme.txt file for i18n_menu .
Comment #3
joseph.olstadComment #4
martin_qAdded missing step to reproduce problem.
Comment #5
martin_qLike you, I am surprised that I am the first person reporting this, so I have re-read the documentation and the readme as you suggested. I also just walked through the above described steps again (during which I found I'd forgotten to note an essential step without which you can't actually translate a node), first using D7.54 freshly downloaded plus i18n 7.x-1.13 and using Drush to retrieve 7.x-1.0-beta5 of entity_translation. The menu item for the third language of the node is correctly translated. Then I replaced i18n 7.x-1.13 with 7.x-1.14 and repeated steps 8-14, and the menu item for the third language of this second node is not correctly translated.
This is true regardless of whether I use entity_translation_i18n_menu version 7.x-1.0-beta5 or the current 7.x-1.x-dev.
So I guess I do, as you suggest, need support to move on from here, because if
(a) previously demonstrably working behaviour is now demonstrably broken following an i18n version change, and
(b) if there's no way it can be the fault of i18n...
then
- either my workflow is wrong (the brief comment about having to have translated content first, under "Troubleshooting" in the readme, is vague on this point),
- or I'm depending on unintended and therefore unsupported behaviour of either i18n_menu or entity_translation_i18n_menu
In case it is either of the above possibilities, having re-reviewed the documentation and readme files, I am stumped as to what I am doing wrong. As the steps I took are documented above, if someone can review them and point out my mistake I'd be truly grateful.
(By the way, I note that some tests for entity_translation_i18_menu, previously working on i18n 7.x-1.13, now fail on 7.x-1.14 - #2836238: Entity Translation Menu (entity_translation_i18n_menu) compatibility check against the i18n_menu (7.x-1.x-1.14) - though this is a slightly different situation (they only have English and Spanish in their tests, and I'm reporting something that happens with a third language), and it is still an active issue. But it demonstrates that 7.x-1.14 has led to at least one other thing breaking... :) )
Comment #6
joseph.olstadThanks for your detailed analysis. Should be easy to fix.
Easiest way to debug, clone the i18n repo, replace yours with it.
You already know that the issue is in between 1.13 and 1.14 because it regressed in 1.14
Use git to locate changes to i18n_menu between 2015 1.13 release and 1.14. To find the culprit;
This will give you all changes to i18n_menu starting with the latest descending order. Zero in on the changes before November 2016 and 2015
I will have a look myself and see.
If you are good with git you can git checkout before and after suspected regression and pinpoint the exact commit and date, with that we can create a new patch or revert the regressed code change depending on what it is.
I know we did do one change to i18n_menu that gave us a huge performance improvement, it is possible that this also created a problem for trilingual or quadrilingual menu link translations. Keep in mind there's several different ways to use i18n_menu for translation of menu links. There may also be a workaround for this use case but let's start by locating the suspect commit.
Comment #7
joseph.olstadhttp://cgit.drupalcode.org/i18n/log/i18n_menu?qt=grep&q=
There were three commits to i18n_menu October 22, 2016
Have a look at those three.
Comment #8
joseph.olstadComment #9
joseph.olstadHi @martin_q,
I've created two different patches. I'm fairly confident that at least one of them will work for you. Please tell me which one of these works.
These two patches will revert respectively the two changes made to i18n_menu between 7.x-1.13 release and 7.x-1.14 release
Instructions : restore version 7.x-1.15, then apply one of the patches, repeat your test.
it should work, if it doesn't then apply the second patch. and tell me if that works, at this point I'm 99% sure that it'll work.
If you can tell me which one of these two patches works for you (patch against 7.x-1.15)
then I (or we) can investigate and find the best possible solution moving forward.
Comment #10
joseph.olstadtrigger the testbot
Comment #11
joseph.olstadtry this patch (against 7.x-1.15) first:
https://www.drupal.org/files/issues/revert_c5ed2b268c7_nov13_2015_issueN...
I hope its this one
but if not, then apply the other one (again against 7.x-1.15).
https://www.drupal.org/files/issues/revert_307b54dcdb_oct22_2016_issueNu...
Comment #12
joseph.olstadbump up the priority, please provide feedback asap.
Comment #13
martin_qThanks for the tips and the patches. Will be trying them in the next couple of hours and will let you know as soon as I have a result.
Comment #14
martin_qSorry for the delay. Thanks for providing the patches.
I can report:
revert_c5ed2b268c7_nov13_2015_issueNumber2614700-2848806-9.patch - did NOT fix this issue
revert_307b54dcdb_oct22_2016_issueNumber2338735-2848806-9.patch - DID fix this issue
Comment #15
joseph.olstadHi @martin_q , thanks for the feedback,
followup work in
#2338735: hook_menu_link_alter() should set $item['i18n_tsid']
Comment #16
joseph.olstadComment #17
joseph.olstadComment #18
joseph.olstad@martin_q , what version of php are you using when you observed this issue ?
If you can provide this information it will help me better pinpoint a solution.
Comment #19
joseph.olstadAlternatively, this might be a more desirable solution that will work best for everyone.
TODO: could probably static cache the count variable, increase performance, as that list languages call will get called too many times unnecessarily otherwise. Potentially improve performance of this.
Comment #21
joseph.olstadre-queueing again, looks like a testbot hiccup unrelated to patch
Comment #22
joseph.olstadLatest patch needs review
Comment #23
joseph.olstadI'm sure there is a better solution, feel free to post one
Comment #24
martin_qI observed the problem on my machine, running PHP 5.5.32.
My colleagues and our testbot also observed the problem with PHP 5.6.30 and 7.0.13, respectively.
The most recent patch looks like it would fix the problem reliably, but is perhaps slightly overcompensating. It's not the *presence* of three or more languages on a site that causes the problem, but the fact that one is saving a translation in a third language. That said, I'm not sure how easy it is to find out the latter... I'm sorry I'm not able, at the moment, to contribute more time to helping investigate/fix this.
Comment #25
joseph.olstadpatch 18 has not been tested.
patch 9 could use more testing and analysis.
Comment #26
Stevel CreditAttribution: Stevel commentedThe patch in #19 does not solve the issues for entity translation. revert_307b54dcdb_oct22_2016_issueNumber2338735-2848806-9.patch from #9 does seem to work.
Comment #27
joseph.olstadok, so we should revert this then.
Comment #29
joseph.olstadfixed