My scenario is that there is a Test environment, and Production environment.

If a node has been translated in the Test environment, and then is imported into the Production environment, it retains the tnid property of the node from the Test, but gets a new nid. This results in a corrupted node, as this is an impossible scenario according to the way Drupal core handles translations. The desired behavior is that if the node is new in the Production environment, and gets a new nid, the tnid would be reset to 0, since the new node does not have any translations in the Production environment.

CommentFileSizeAuthor
#1 corrupt_tnid--1852210--1.patch706 bytesjessehs
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

jessehs’s picture

Status: Needs work » Needs review
FileSize
706 bytes

Here's a patch I've tested with the 6.x-2.x release that resets tnid during node cloning during import. I have not tested it against the 6.x-3.x branch.

brettbirschbach’s picture

Note that I have a patch for the drupal 7 version of this bug in http://drupal.org/node/1896904. The patch I have written preserves tnid, updating it to match the new nid so that the nodes can retain their translation relationship.

danielb’s picture

Issue summary: View changes
Status: Needs review » Closed (outdated)