Translated node forgets its menu settings

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.

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.

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.

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.

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.

It resets to primary links here

This is the same issue
http://drupal.org/node/367248

Well, nobody cares about this issue?
That prevents any translation to be processed by a non-Drupal-Guru-Admin
I changed to critical

Same problem... menu is broken!
I completely removed the internationalization module and made a "second" site for the second language...

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.

works good for me

It solved a big issue
Thanks

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

Works fine, here, too...

@brucepearson Thanks for this fix.

Averted a minor disaster for me ;)

Thank you so much for this fix, works well. Can we get this committed?

Works for me too

Thanks, that fixed it for me too.

Thanks, committed a bit changed (empty)

I'm sorry for dumb question :-)
How to apply this patch?

have already found it.
thanks a lot!

I made the change by hand - much more simple than patching for me :)

When can we expect a release - at least a dev?

Thank you, the patch works perfectly!

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

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)

@brucepearson : Thanks for the patch!

works for me to, thanks.

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

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.

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.

In what was does the menu item behave wrongly?

It is precisely what the patch was addressing.
Everyone reported satisfaction with the patch to date.

Or is this another issue?

Patch works great, thanks!

Patch works fine for me also, thanks

fixed the issue for me. thanks :)

Please, committ in dev!
Thanks

Yeah, please solve this severe problem. TIA!

A great patch, thanks a lot.

Is there any reason not to committ?
(apart the acceptable "too busy maintainer" excuse)

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).

subscribe... Glad to know it has been committed.. waiting for a release..

I thought i was crazy..

its a bug after all.

Can anyone post here when a release is done?

Thank you for that patch, keep up the good work! ;)

Could please, please, please a release be done? This bug is considered critical and solved for a long while now.

Subscribing to keep track of this issue.

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.

Thank you! Work nice for me too.

Is the maintainer still alive?

No reason to close this......

The issue has long been fixed, so it should be closed. Please only set it back to active if the original bug resurfaces.

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.

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

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.

Sorry, my mistake. The dev version is actually OK.
What is the difference between closed and fixed?

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.

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.

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.

#472090: Please roll 6x-1.1 out

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.

As repeated above, over and over, the bug has been fixed--the fix is included in the latest dev release.

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.

Please stop moaning; These people are working hard to make our lives easier.

Or moan here: #472090: Please roll 6x-1.1 out

There is a "Please" at least. ;)

@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.

@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.