Migrate content_translation_source when migrating node translations

This will probably need an extra join against the node table, to find the source translation for each translation.

This needs #2225775: Migrate Drupal 6 core node translation to Drupal 8 to go in first, right?

Yay, that went in now :)

@penyaskito: In the issue summary you say:

In #2225775: Migrate Drupal 6 core node translation to Drupal 8 we migrated node translations, which doesn't rely on content_translation being enabled.

I tried migrating D6 translated nodes without enabling content_translation in D8, and only the nodes in the source language got migrated. Also, in the tests included in #2225775: Migrate Drupal 6 core node translation to Drupal 8, content_translation is always enabled, which seems to point to the fact that it is in fact relying on it. Am I missing something here?

Oh, and there's also this comment in D6NodeDeriver:

Translations don't make sense unless we have content_translation.

And this one in MigrateNodeDeriverTest:

Without content_translation, there should be no translation migrations.

So I'm a bit confused by the issue summary.

Here's a first try at it.

@maxocub: I think you made the translation migration now depend on content_translation in D8, so that is a recent change :) This issue predates that change.

@Gábor Hojtsy: What we did in #2809115: When migrating a multilingual D6 site, the overview page says that the translation upgrade path is missing did not made the translation migration depend on content_translation. That array is only use to construct the upgrade form and to show what paths are available/missing. There's no dependencies enforcement there. The translation migration worked well before that change (provided we enable content_translation).

No, that did not change. But since the creation of the content translations in Drupal 6 needed the core translation module (alternate implementations were possible but did not emerge at all), it makes sense to tie the migration to the content translation module in Drupal 8 also, otherwise you have no way to manage that data(?) Also what does that mean for this issue, can we translate that to actionable steps? :)

What's the next actionable step here?

Thanks.

1. +++ b/core/modules/node/migration_templates/d6_node_translation.yml
   @@ -29,6 +29,7 @@ process:
      revision_timestamp: timestamp
   +  content_translation_source: source_langcode
   

   This right in the D6 translation migration does not satisfy the summary that this should be dependent on content_translation module. Otherwise this base field is not there.

2. +++ b/core/modules/node/tests/src/Kernel/Migrate/d6/MigrateNodeTest.php
   @@ -96,6 +101,10 @@ public function testNode() {
   +    // Test that content_translation_source is set.
   +    $manager = $this->container->get('content_translation.manager');
   +    $this->assertIdentical('en', $manager->getTranslationMetadata($node->getTranslation('fr'))->getSource());
   

   It would be nice to test with yet another node that has another source langcode? Do we have that in the dump?

@Gábor Hojtsy: Thanks for the review, I'll make those changes.

Re: #15:

1. I added a check to see if content_translation is enabled.
2. I added a translated node in the dump to test with a source other than English.

Hmm, I just saw that moduleExists() is available in DrupalSqlBase, so I removed all the useless things to get access to the module handler.

I should have read the doc, moduleExists() on DrupalSqlBase is for the source installation.
So this is the same patch form #19.

Looks all good to me :)

Committed/pushed to 8.3.x and cherry-picked to 8.2.x. Thanks!

Superb, thanks!