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

This issue is misdiagnosed as being related to Workbench Moderation since it was an unknown factor when I commented in the related issue above.

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\ContentEntityBase::hasTranslationChanges will set "revision_translation_affected" to "1" for "en" incorrectly when it should only assign it for "de". Conversely also during migration, it will sometime skip setting "revision_translation_affected" to "1" for "de" (and all other languages).

So the solution was extending Drupal\node\NodeStorage::populateAffectedRevisionTranslations during migrations to enforce the "revision_translation_affected" value:

// Double-check to prevent migrated source from getting mis-assigned.
if ($new_affected && $langcode != $entity->get('langcode')->value) {
  $new_affected = NULL;
}
elseif (!$new_affected && $langcode == $entity->get('langcode')->value) {
  $new_affected = TRUE;
}

@firewaller, thanks for the update. Can you provide some detail about the source site so I can replicate that for testing? In this case, replicate means updating the source db fixture. Is the content type using entity translation? What is the field type and any relevant settings?

I am intrigued by "in fields that are now considered "untranslatable" in D8." Are you saying that the fields were translatable on D7 and were changed during migration? Or something else?

Thx

I'm not sure why this is Critical, there is no data loss, there is no indication that the site is not usable and there is workaround. Changing to major. I'm sure someone will correct that if I am wrong.

Also, changing to migration_system because that is what is reviewed at migrate meetings.

I came across this issue when investigating something similar happening with Scheduler. It helped a lot to identify the problem pointed out in #6 so I am sharing this issue #3080979-19: Schedule does not work for forward pending revisions after published as it could shed some light here.

@quietone sorry for the late response, but thank you for looking into this and relabeling it.

Yes, the content type is using entity translation. The field types are simple text fields.

Yes, in our system there are fields that were translatable in D7 and are no longer translatable in D8.

I am happy to provide further context if necessary.

@firewaller, thank you. It would help to know more about the fields that 'were translatable in D7 and are no longer translatable in D8'. Is there any difference between the fields that were translatable on D7 and are still translatable on D8 versus those that are no longer translatable on d8? Oh, when responding to issues marked Postponed (maintainer needs more info) please change the issue status. Thanks.

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.

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.