Follow-up to #2225775: Migrate Drupal 6 core node translation to Drupal 8
Problem/Motivation
In D8, a node revision has data for all languages. In D6 and D7, each node revision has data for just one language. This means currently D6 -> D8 and D7 -> D8 migrations yield a revision history where each node revision has only one language present, even if previous revisions had translations. This is strange and likely to confuse users.
Priority is given to the D7 migration because the D6 one might be effected by the term node migrations.
This is for migrating core translation revisions, migrating revisions for entity translation is now being done in #3076447: Migrate D7 entity translation revision translations to D8. It is intended that this issue is completed first and then the approach used here is also used for entity translations.
Things to consider, taken from notes of meeting with alexpott, Gábor Hojtsy, heddn, mikelutz and quiteone
- Migration dependencies
- Possible: easy to do
- BC concerns: none
- BC what about contrib? Commerce / metatag
- Possible incompatible
- How do we figure out you need the new complex master migration?
- Possible: moderate to do
- BC concerns: none
- Don’t effect expose new d*_node_master unless explicitly enabled to existing sites
- This handles incremental, no UI option available to enable
- For new installs, give an option to upgraders to enable disable the new d*_node_master migration and use the old method.
- What about migration lookups on dn_node etc.
- Possible: easy to do
- BC concerns: none
- What about incremental migrations that have already begun
- Not allowed. You can only use the new approach on a site that has not run migrations. So we need some of flag where existing installs use the old migrations.
- Contrib/Custom
- Does it make sense to use d*_node_master instead of d*_node migrations?
Proposed resolution
The current focus is to get the D7 version working and then move those changes to D6.
Using the existing method where the final revision is migrated first doesn't work instead the revisions need to be migrated in order. The first proof of concept patch to show this is in #121, thanks to mikelutz. The current working name of the migration is dN_node_master.
However, this new approach doesn't integrate with the current migrations, that is the one either runs the existing node migrations or the new master one, not both. This will also be a problem for the drush migrate-upgrade --all command which runs all migrations. Also, we need to make sure that non-translatable and non-revisionable nodes are migrated correctly.
From the original IS
D6 and D7 node revisions do not directly indicate which other translated node revisions they are associated with. But we can attempt to guess this, based on the order of revisions.
Remaining tasks
From #55
- Make this work with a multilingual source and a non multilingual source
- Discuss and document implications for drush, especially
drush migrate-upgrade --all - Make sure the d6 and d7 tests includes testing a fields on each revision
- Handle the case where the vid of the first revision is higher the vid of a later revision. This is true for both d6 and d7.
- Make sure that the use of migration_tag 'translation' is documented. It is used in
- d6_node_translation.yml
- d7_node_entity_translation.yml
- d7_node_translation.yml
- d7_node_revision_translation.yml
- d7_user_entity_translation.yml
- d7_taxonomy_term_entity_translation.yml/li>
- d7_comment_entity_translation.yml
- d6_node_revision_translation.yml
- Make sure that the source plugin 'translation' property is documented
- Make sure that the destination plugin 'translations' property is documented
