Problem/Motivation

The most recent stable release of Entity Translation uses a different i18n_mode value for translated taxonomy terms. See https://git.drupalcode.org/project/entity_translation/-/blob/7.x-1.1/ent...

This means that any user trying to migrate from an up-to-date Drupal 7 instance will lose translation data.

Steps to reproduce

  1. With the most recent Drupal 7 release + Entity Translation, create a vocabulary which allows its terms to be translated by entity translation.
  2. Try to migrate the source Drupal 7 instance (e.g. with Migrate Drupal UI)
  3. You'll see a logged migrate exception message thrown from the migration plugin in the IT: "No static mapping found for ''32768'' and no default value provided for destination 'language_alterable'."
  4. You'll see that none of the term translations are migrated (d7_taxonomy_term_translation migrate map table contains skipped rows only)."

Proposed resolution

Update mappings to deal with the most recent i18n_mode.

Remaining tasks

  1. Patch
  2. Test

User interface changes

Nothing

API changes

?

Data model changes

?

Release notes snippet

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

huzooka created an issue. See original summary.

huzooka’s picture

Assigned: Unassigned » huzooka
huzooka’s picture

Assigned: huzooka » Unassigned
Status: Active » Needs review
FileSize
792 bytes
quietone’s picture

Issue tags: +Needs tests

Another good discovery. Thanks.

Can the title just be 'Add support for i18n_mode 32768 in d7_language_content_taxonomy_vocabulary_settings migration.' I am not sure that it is a regression if this mode was never handled before. Or am I missing something?

huzooka’s picture

You cannot migrate term translation translated with Entity Translation for a year and a half – while language.migrate_drupal.yml, config_translation.migrate_drupal.yml and content_translation.migrate_drupal.yml tells you that you can. I strongly believe this worked in the past, but now it doesn't. That's why I evaluate this as a regression.

Unfortunately, it seems that changes made in #3022137: Update migrate fixtures for remaining active issues were (at least partially) manual edits, and the database fixture is corrupted in regards of the data structure of Entity Translation settings. Or the Entity Translation update hook is wrong?

I don't think this can be fixed manually.

I added a change to \Drupal\Tests\language\Kernel\Migrate\d7\MigrateLanguageContentTaxonomyVocabularySettingsTest which does the same thing what the Entity Translation 7009 update hook does, so the fixed test should pass (but it fails because of the above).

Anyway, the source database should be fixed. We have a test, so removing the needs test tag – it only reveals the issues of the database fixture.

Status: Needs review » Needs work
huzooka’s picture

d7_taxonomy_term_translation also should map this 32768 to translatable.

huzooka’s picture

Assigned: Unassigned » huzooka
huzooka’s picture

Addressing #7, without test.

huzooka’s picture

Title: Regression: d7_language_content_taxonomy_vocabulary_settings migration fails if user tries to migrate translated terms from a multilingual Drupal 7.80 + Entity Translation 1.1 » Regression: multilingual taxonomy term migrations are failing if user tries to migrate from Drupal 7.81+ and Entity Translation 7.x-1.1
Issue summary: View changes
Wim Leers’s picture

🤯 Epic archeological work here!

Wim Leers’s picture

Wim Leers’s picture

+++ b/core/modules/content_translation/migrations/d7_taxonomy_term_translation.yml
@@ -17,6 +17,7 @@ process:
+        32768: true

This code no longer exists since #3187616: Fix TermTranslation query and add missing source plugin test got committed!

🤔

So … is this safe to delete?

huzooka’s picture

Based on this, yes, absolutely: https://git.drupalcode.org/project/drupal/-/commit/4bc7dbb#07405c4197980...

There is a new condition which excludes source items where the i18n_mode is not 0 or 1. That will obviously include 32768 values!

Wim Leers’s picture

Yay, thanks!

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.