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]));
| Comment | File | Size | Author |
|---|---|---|---|
| #7 | i18n_menu-migrate-menu-link.patch | 1.7 KB | mrfelton |
Comments
Comment #1
mikeryanThe matching code should take language into account.
Comment #2
mikeryanActually, 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.
Comment #3
mikeryanSay, Taxonomy Manager?
Comment #4
rv0 commentedIndeed, not provided by core. Didn't realize it is provided by Internationalization ( http://drupal.org/project/i18n )
Changing status and assigning to migrate_extras project
Also changing title.
Thanks for the quick follow up.
Comment #5
mikeryanUpdated the chart on the project page to include this request.
Thanks.
Comment #6
mikeryanMigration support for a contrib module should be implemented in that module.
See also #1784792: Support for Menu Translation (i18n).
Comment #7
mrfelton commentedHere is a basic migrate destination class for i18n_menu to handle menu links.
Comment #8
jose reyero commentedSo.. does this work?
(Wondering how migrate module finds that class...)
Comment #9
mikeryanhook_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 .migrate.inc file - no migration code at all in .module.
Comment #10
luke_nuke commentedI 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 :) .
Comment #11
jose reyero commentedHey, 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?
Comment #12
luke_nuke commentedI have nothing against it :) .