Posted by fletchgqc on January 26, 2009 at 2:31pm
| Project: | Internationalization |
| Version: | 6.x-1.0 |
| Component: | Code |
| Category: | bug report |
| Priority: | critical |
| Assigned: | brucepearson |
| Status: | closed (fixed) |
Issue Summary
The first time I edit a translated node, its menu settings are partially replaced with those from the source node. After being fixed and saved once, the behaviour returns to normal. To reproduce:
- Create a node in Spanish (default language), put it in the primary links menu with a Spanish parent item
- Translate the node to English, put the translation into the primary links menu with an English parent item, save translation.
- The English node appears in the menu as expected - everything fine!
- Click "edit" on the English node. The edit page comes up but the node has lost its menu settings. On the edit form the Menu link title is set to the Menu link title of the Spanish node, and Parent item is Navigation.
- Change the menu settings to the correct English settings again and save.
- Click "edit" - the menu settings now appear correctly
Additional information: This bug does not occur on another of my sites which is fairly similar except that it is running i18n-6.x-beta3 and it has English as the default language. Also, I am using Primary links as the source of Secondary links in case that's relevant.
Comments
#1
Sorry one thing was wrongly reported above - the problem does not go away. I seem to recall that previously the behaviour was as reported above, but now using version 1.0 I have the experience that every time I edit a non-default-language node, it loses its menu settings.
Isn't anyone else experiencing that?
#2
I experience exacly the same - and yes, every time I edit the translated notes. Only difference is my default language is danish and second language is english. So, the english nodes loose their menu settings.
#3
Same problem. I realised no matter which was the source(first) node's language - the default or the additional - in both case the translated node's Menu link title was overwritten by the source node's Menu link title, when clicked the translated node's Edit button.
#4
Same problem. Had to revert back to beta6 in order to get it all working again. Would be very grateful If anyone finds a solution and posts it here.
#5
Don't know if it means anything, but I had this very same problem and I noticed that it goes away if you disable the "Menu translation" module. FWIW.
#6
I just tried to revert to beta6 as well. Yes, beta6 works here as well.
Also I can confirm that disabling "menu translation" (as jorgemare suggests) on 1.x-dev works as well.
#7
It resets to primary links here
#8
This is the same issue
http://drupal.org/node/367248
#9
Hi jvieille,
The correct thing to do before lodging an issue is to search the issue queue to see if someone has already reported it. In this case for example I did "advanced search" and put "menu" as the search string to see what anyone else had reported recently about the menu, before I lodged my issue, to avoid duplication.
If you discover that you have lodged a duplicate issue, you should mark your issue as status "duplicate" and enter the link to the original issue in the comment box. Please can you do this for the issue which you have mentioned above.
#10
Well, nobody cares about this issue?
That prevents any translation to be processed by a non-Drupal-Guru-Admin
I changed to critical
#11
I updated the module yesterday and I have the same problem with translated content. Disabling the "menu translation" made the problem go away... Since the site I´m working on is still not online I can live with the menu translation turned off. Let´s hope this little problem´s gonna get fixed with the next release...
Ohh, almost forgot, I use the 6.x-1.0 version
#12
Same problem... menu is broken!
I completely removed the internationalization module and made a "second" site for the second language...
#13
I've attached a patch to fix this problem. It wasn't properly detecting that the node already had a menu and was creating a copy of the original menu in the translated content.
#14
#15
works good for me
#16
#17
Works for me too
#18
It solved a big issue
Thanks
#19
Work fine for me.
Thank you very much Bruce (new site with 6 languages... arab, chinese and japanese included: a nightmare before this patch)!
Ciao
#20
Works fine, here, too...
#21
@brucepearson Thanks for this fix.
Averted a minor disaster for me ;)
#22
Works for me too.
#23
Thank you so much for this fix, works well. Can we get this committed?
#24
Works for me too
#25
Thanks, that fixed it for me too.
#26
Many thanks!! Fixed for me.
#27
Thanks, committed a bit changed (empty)
#28
I'm sorry for dumb question :-)
How to apply this patch?
#29
See: http://drupal.org/patch/apply :-)
#30
have already found it.
thanks a lot!
#31
I made the change by hand - much more simple than patching for me :)
When can we expect a release - at least a dev?
#32
Thank you, the patch works perfectly!
#33
We applied the patch from the file attached at comment #13 and it works like a charm! Who said number 13 brings bad luck? :P
#34
I love this patch, it seems to work for me, thanks a lot!
I hope it will be fixed in next release (dev or stable)
#35
@brucepearson : Thanks for the patch!
#36
works for me to, thanks.
#37
Again, when will it be committed, at least as a dev?
1,5 months is largely enough to validate the (perfect) fiX.
This is a critical bug, we cannot rely on patching for so long.
Thanks
#38
How do you know it's not committed? According to Jose's comment #27 it was committed and so it should be in dev.
If you are having this problem in dev, then comment and re-open the issue (set status to active).
#39
The current 6x-1.0 is date Jan 25
The dev version is dated Jan 26
The discussion started on January 26, based on these versions buggy behaviour .
The José posted #27 on Feb 18 (same year...). I modified my version manually at this date.
Times always goes forward in our World: some chances that loading the latest version would destroy my fix.
#40
the patch in this issue has not commited yet. the dev version and 1.0 version are exactly the same, exept in i18nviews module.
another thing is this patch solve the stated problem but it causes another problem, when you create a translation and asign it a menu item (from within create content form), the menu item behaves wrongly.
#41
In what was does the menu item behave wrongly?
#42
It is precisely what the patch was addressing.
Everyone reported satisfaction with the patch to date.
Or is this another issue?
#43
Patch works great, thanks!
#44
Patch works fine for me also, thanks
#45
fixed the issue for me. thanks :)
#46
Please, committ in dev!
Thanks
#47
Yeah, please solve this severe problem. TIA!
#48
A great patch, thanks a lot.
#49
Is there any reason not to committ?
(apart the acceptable "too busy maintainer" excuse)
#50
This has been committed:
http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/i18n/i18nme...
The 6.x-1.x-dev doesn't seem to be updated though (which is a separate issue).
#51
subscribe... Glad to know it has been committed.. waiting for a release..
#52
I thought i was crazy..
its a bug after all.
Can anyone post here when a release is done?
#53
Thank you for that patch, keep up the good work! ;)
#54
Could please, please, please a release be done? This bug is considered critical and solved for a long while now.
#55
Subscribing to keep track of this issue.
#56
I need this patch included in an official release. (i.e. 6.x-1.1)
I see the patch in comment #13, but the directions referred to in comment #29 say that you should not patch a live site.
This is a critical bug! None of our users can update translated nodes without "Administer Menu" privileges.
#57
Thank you! Work nice for me too.
#58
Is the maintainer still alive?
#59
Automatically closed -- issue fixed for 2 weeks with no activity.
#60
No reason to close this......
#61
The issue has long been fixed, so it should be closed. Please only set it back to active if the original bug resurfaces.
#62
yeah, lets forget it and enjoy all the happy people here.
Before I get bashed: I know the difference between active and fixed. Accidently made it active when "we are begging" would have been better.
#63
Not solved yet.
The latest dev version is of the 25th jan, no new release since the issue was raised on 26th jan.
The issue cannot be considered closed as long as the module does not work without patch
#64
The patch has been committed, the issue itself is thus fixed. The latest dev version is from April 28 and contains the fix. If you want a new release, consider testing this development version and posting an issue requesting such a release.
#65
Sorry, my mistake. The dev version is actually OK.
What is the difference between closed and fixed?
#66
See here
#67
Just ran across the SAME issue with the current supported release (6.x-1.0)
The comment fixed the problem for me in the easiest manner.
This was to simply turn off the menu translation module.
#68
Why the patch hasn't been backported to the current stable release?
So many people have said that the patch works, why we need to wait for a future release to fix a functionality bug?
I am not lazy to apply a patch, but many other people will came here to claim this bug that have been fixed months ago.
PLEASE add the patch to the current stable release.
Thanks.
#69
The bug has been fixed in CVS and the current development release. A new 1.1 release should contain this patch. As said above, if you want such a release, please test the current dev and post your review in a separate issue requesting a 1.1 release.
Thanks.
#70
#472090: Please roll 6x-1.1 out
#71
The patch also worked here.
Please release as soon as possible a fixed release or make a comment on the project site.
I changed the status to 'revieved & tested by ...'. Otherwiese this bug doesn't appear when using the link 'View pending patches' and one might think a fix is already released or isn't yet submitted.
#72
As repeated above, over and over, the bug has been fixed--the fix is included in the latest dev release.
#73
Is too complicated to understand that normal people use the stable version, not the -dev one?
Using -dev can fix my bug and introduce 3 new.
#74
Please stop moaning; These people are working hard to make our lives easier.
#75
Or moan here: #472090: Please roll 6x-1.1 out
#76
There is a "Please" at least. ;)
#77
@Scorp I understand your frustration, but since the fix for this bug is really simple—only one line of code needs to be changed (see patch)—you can simply apply the patch to the latest stable version if you have concerns about using the dev version. And since the patch has already been committed, it will be included in the next stable version—you won't lose the change when you later upgrade to the next stable version.
#78
@dboulet Yeah, isn't a problem for a developer to apply a patch, but keep in mind that not all people that use Drupal are developers, most of them probably doesn't know what the hell is CVS or a bug tracker.
You don't ever know how many people encountered this problem (a one-line fix, as you said,) and get lost with Drupal, for months.
I am cutting here with replies to this issue, but I hope someone will catch my words.
Keep up the good work.
#79
Automatically closed -- issue fixed for 2 weeks with no activity.