Quantcast
Channel: Issues for Drupal core
Viewing all articles
Browse latest Browse all 295283

Migrate D6 and D7 node revision translations to D8

$
0
0

Postponed on #2975509: Migrate D6 vocabulary language settings and #2886609: Migrate translations for D6 i18n taxonomy 'localized' terms

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.

Proposed resolution

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.

  • For each D6 and D7 revision, the migration source should yield every translation that we think goes along with it. This means multiple rows per revision, which is slightly confusing. But it will provide a mostly-sane revision history.
  • Make sure to pull in the correct fields for each such revision-translation row. The row's vid-for-matching-revisions-together may not necessarily be the same as its vid-for-finding-field-values.
  • Make sure the current revision of each node has the correct data in it. This must be true even if the current revision is not the highest one (ie: revision was reverted).
  • Make the code to accomplish this comprehensible. Previous attempts had complex subquery-joins, which need at least more explanation. Maybe there's a better solution without weird joins?

Viewing all articles
Browse latest Browse all 295283

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>