Migrate sets revision_translation_affected incorrectly when different languages co-exist for 8.x un-translatable fields

Created on 9 March 2020, over 4 years ago
Updated 4 April 2023, about 1 year ago

Problem/Motivation

See #2746541-400: Migrate D6 and D7 node revision translations to D8
#2746541-403: Migrate D6 and D7 node revision translations to D8
#2746541-405: Migrate D6 and D7 node revision translations to D8

This happened with a content type is using entity translation. The field types are simple text fields. In our system there are fields that were translatable in D7 and are no longer translatable in D8. See #6

See #6

Proposed resolution

Remaining tasks

Needs steps to reproduce

User interface changes

API changes

Data model changes

Release notes snippet

🐛 Bug report
Status

Closed: outdated

Version

9.5

Component
Migration 

Last updated 1 minute ago

Created by

🇬🇧United Kingdom catch

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • 🇳🇿New Zealand quietone New Zealand

    First, I should point out that migration does not alter revision_translation_affected.

    I am removing the workbench moderation tag based on #6

    The issue is actually related to how D7 to D8 node translation revisions are handled when a D7 translation node (i.e. "de") has a different field value from their source translation node (i.e. "en") in fields that are now considered "untranslatable" in D8. When this is the case during migration, \Drupal\Core\Entity.

    As I understand this the source is using entity translation with a field. That field has value A in the source language node and value B in the translated node. And when that is migrated the field in no longer translatable.

    I tested that with a clean standard install of Drupal 7 and added Italian as the second language. I then added a content type that uses entity translation with a translatable text field. I created two node, one with English as the source language and the other with Italian as the source language and added data in the text field. I translated each node and changed the data in the text field for the translation.

    I then migrated that to a Drupal 10.1.x site using the UI. After the migration the two nodes and the translates were present, the text fields were translatable and the data was correct. Revision_translation_affected was set to 1. I then tested with the classic migrations using drush and again everything migrated as expected.

    Unless I am missing something, I can't reproduce the problem.

    More details were asked for 2 years and no extra information has been provided. There have been no further reports of this problem. Based on that and my own testing I am closing this as cannot reproduce. Reopen and leave a comment if I am mistaken.

  • 🇮🇳India kunalkursija Mumbai

    I faced this today for doing paragraph_items to block_content migration, From Drupal 7 to Drupal 9. In my case, The block_content(of XYZ type) in D9 is translatable and paragraph_items in D7 were not translatable, But the nodes to which they are attached are translatable in D7.

    I had to migrate all the revisions of the paragraphs[Not going into the details of work around paragraph's item-id/revision-id and node's nid/tnid to create revisions/translations of block_content].

    When I ran the migration I faced a problem where the 'revisions' tab of the source translation showed more revisions than the actual count.

    After looking into the tables, I sensed something was wrong with the 'revision_translation_affected' flag in tha DB table block_content_field_revision. And, Then I came across this issue and #6 by @firewaller. I used that solution by overriding the block_content entity's storage handler and it solved the problem and revisions tab started showing correct data.

Production build 0.69.0 2024