Using migrate to import nodes with term references.

The problem is that terms have languages, but sometimes there's no difference between the termname in several languages.. What happens is that migrate seems to match the term reference in a similar way of taxonomy_get_term_by_name, ignoring language and taking the first match, and thus making wrong references to other languages.
In my case my Dutch en French nodes are ending up with German terms attached, which leads to several problems in the site.

Any way to prevent this? I am already specifying the language in field_mapping.

    $this->addFieldMapping('field_soort', 'soortdesc')
        ->arguments(array('language' => $this->language[1]));
#7 i18n_menu-migrate-menu-link.patch1.7 KBmrfelton
Test request sent.
[ View ]


mikeryan’s picture

Title:Identical termnames, different term language. How to map correctly in term reference fields?» Term matching does not respect language
Component:Miscellaneous» Code
Category:support» bug

The matching code should take language into account.

mikeryan’s picture

Status:Active» Postponed (maintainer needs more info)

Actually, hold on a second - core Drupal 7 doesn't appear to support languages on terms (particular term reference field values can be marked with a specific language, but not the terms themselves in taxonomy_term_data). Are you using a contributed module to enable multi-lingual terms? If so, support for that would go in the migrate_extras module.

mikeryan’s picture

rv0’s picture

Title:Term matching does not respect language» Support for Taxonomy Translation (i18n)
Project:Migrate» Migrate Extras
Component:Code» Migrate Extras Features
Status:Postponed (maintainer needs more info)» Active

Indeed, not provided by core. Didn't realize it is provided by Internationalization ( )

Taxonomy translation (both, per language terms and translatable terms)

Changing status and assigning to migrate_extras project
Also changing title.

Thanks for the quick follow up.

mikeryan’s picture

Category:bug» feature

Updated the chart on the project page to include this request.


mikeryan’s picture

Title:Support for Taxonomy Translation (i18n)» Support for migration
Project:Migrate Extras» Internationalization
Version:7.x-2.4-beta1» 7.x-1.x-dev
Component:Migrate Extras Features» Compatibility

Migration support for a contrib module should be implemented in that module.

See also #1784792: Support for Menu Translation (i18n).

mrfelton’s picture

Status:Active» Needs review
new1.7 KB
Test request sent.
[ View ]

Here is a basic migrate destination class for i18n_menu to handle menu links.

Jose Reyero’s picture

Status:Needs review» Postponed (maintainer needs more info)

So.. does this work?
(Wondering how migrate module finds that class...)

mikeryan’s picture

Status:Postponed (maintainer needs more info)» Needs work

hook_migrate_api() is defined, so it should be fine (note that destination classes don't need to be registered - were you thinking of handler classes, which need to be listed in the return from hook_migrate_api())?

I will say that I consider best practice to be putting hook_migrate_api() in the file - no migration code at all in .module.

Luke_Nuke’s picture

Issue summary:View changes

I started work on set of modules for handling migration of internationalized core content. migrate_extras is not developed further so they are grouped in the new module i18n_migrate . For now it allows migration of translation sets and internationalized taxonomy (in "translated" mode), so it already should be useful for some people. I invite anyone interested in improving this further to my issue queue, any help with testing/patches are welcome :) .

Jose Reyero’s picture

Hey, thanks, having a migrate module looks like a much better solution to me.

Should we close this issue and link that i18n_migrate from the i18n project page?

Luke_Nuke’s picture

I have nothing against it :) .