Language specific term(i18n_taxonomy) should not rely on entity translation in d7 taxonomy term migration

@bappa.sarkar thanks for the patch.

+++ b/core/modules/taxonomy/src/Plugin/migrate/source/d7/Term.php
@@ -66,9 +66,12 @@ public function prepareRow(Row $row) {
+    if (!$row->hasSourceProperty('language') || $row->getSourceProperty('language') === 'und') {

Is this extra check needed? The $source_language will be FALSE if entity_translation is not in use and the default language set in the source db will be used.

Moving to migration system.

Good find! This would need test coverage.

I believe this has been fixed in 8.9.x and 9.0.x by #3073050: Migrate D7 i18n taxonomy term field translations which now has a check to determine if entity translation is in use before using the source_language variable. So, this is probably outdated now.

    $translatable_vocabularies = array_keys(array_filter($this->variableGet('entity_translation_taxonomy', [])));
    $entity_translatable = $this->isEntityTranslatable('taxonomy_term') && in_array($vocabulary, $translatable_vocabularies, TRUE);

    if ($entity_translatable) {
      $source_language = $this->getEntityTranslationSourceLanguage('taxonomy_term', $tid);
      $language = $entity_translatable && $source_language ? $source_language : $default_language['language'];
    }

@bappa.sarkar, Do you still get this problem with 8.9.x?

@quietone I am getting this problem in 8.9.x as well:

You can see the issue in \Drupal\taxonomy\Plugin\migrate\source\d7\Term::prepareRow here (comments removed for readability):

$default_language = (array) $this->variableGet('language_default', ['language' => 'en']);

$translatable_vocabularies = array_keys(array_filter($this->variableGet('entity_translation_taxonomy', [])));
$entity_translatable = $this->isEntityTranslatable('taxonomy_term') && in_array($vocabulary, $translatable_vocabularies, TRUE);

if ($entity_translatable) {
  $source_language = $this->getEntityTranslationSourceLanguage('taxonomy_term', $tid);
  $language = $entity_translatable && $source_language ? $source_language : $default_language['language'];
}
if ($row->get('i18n_mode')) {
  $language = ($row->get('i18n_mode') === '1') ? $default_language['language'] : $row->get('language');
 }

Our migrated term translations are i18n_mode = 1, which uses the default language when entity_translation isn't present. However, this should be using the ltlanguage value from d7_term_localized_translation, which I believe this issue is trying to solve.

To elaborate further, we migrated the term translations, but in the mapping only the "zh" mappings were present since all the sourceid2 values were "en" and "zh" destid2 was overwriting the other languages. Carrying over the correct source language resolved this for us.

Patch for 8.9.x attached.

Not sure if quietone is right on this being fixed or not, but we need a failing test to prove we have a bug and a fix.

I have tried again and I am still not able to reproduce. I am testing with the source test fixture, it has content for every i18n mode available for taxonomy and there are migration tests that cover all the cases, at least as far as I can tell.

The IS states

Please note: This is not related to translation of a taxonomy term. This is related to term that is added for a specific language in a multi language site.

And along with the steps to reproduce this would be an i18n mode of 4. That corresponds to the vocabulary, vocabtranslate in the source fixture. That vocab has three terms, one in each language (en, fr, and is). Those terms are migrated correctly, the language matches the language on the source. I checked the row as well, and the language is correct.

Furthermore, the fix for this, patch #6, has logic is in an if block, !$row->hasSourceProperty('language'), that will never be executed for the D7 source fixture because the Term table has a language column. So, what if the source doesn't have a language column? In that case the logic is, if entity translation use that language, if localized then use that language, else use the source site default language or 'en' if not set.

Then in comment #15

Our migrated term translations are i18n_mode = 1, which uses the default language when entity_translation isn't present. However, this should be using the ltlanguage value from d7_term_localized_translation, which I believe this issue is trying to solve.

This changes the problem to a type of translation, using the Localized translation. Currently there are two localized vocabularies is the source fixture, each with a term that is translated. The migration of the translated values is tested. The comment states the the migration should be using the ltlanguage. The migration for localized terms does use ltlangugae. The language property is changed in the prepareRow of \Drupal\taxonomy\Plugin\migrate\source\d7\TermLocalizedTranslation which is executed after parent::prepareRow($row) so the process will have the correct language.

Now, looking at git blame for parent::prepareRow($row) I see that the line setting the language was added in #3143676: Missing condition in d7_term_localized_translation source plugin causing invalid migration committed on Date: Thu Oct 8 16:26:15 2020, which is two months after #15. The relevant change is here, the setting of $language.

     $language = $row->getSourceProperty('ltlanguage');
-    $tid = $row->getSourceProperty('tid');
+    $row->setSourceProperty('language', $language);

So, the change is in but not in Term it is in TermLocalizedTranslation source plugin.

Based on the above it looks like there is nothing to do here. The problem is the IS is not reproducible and the second problem has been fixed. I am closing this a can't reproduce based on the IS. If you are experiencing this problem just set the status to 'Active' and provide steps to reproduce.