Problem/Motivation

I had a partly-multilingual d6 site. Today I attempted to migrate it into D8 using Migrate UI.

I ran into an interesting problem. Some of the content in the d6 site was not translated, and these nodes had an empty language field. They were migrated into the d8 site with language UND.

The problem is that some of the core views, such as taxonomy pages and the default front page, filter to the current page language. This language is never UND, so for instance if you go to the taxonomy page for a term that is on one of these UND language nodes, that node doesn't show up on the page because it's not an EN language node. On the d6 site the node does show up on the taxonomy page, and on the d8 site the same node doesn't. It took me a bit of debugging to figure out, because the Migrate UI didn't warn me about this after the migration.

It isn't extremely hard to fix -- you can edit the view and change the filtering. In principle you could also change the node language after migration, but I'm not sure how to do this without a database query.

Proposed resolution

Probably one of the following:

a) Decide this isn't a bug at all and close with Works As Designed. [pretend it isn't a problem]

b) Warn the user if content is migrated in with empty language, that it was migrated into UND, and they might need to change the filters on some of the system-provided views, such as taxonomy pages, or they might need to update the node language. In this case, it would be helpful if there was a tool provided somewhere in Core that would make it easy to change the node language (such as a views bulk operation -- there doesn't seem to be one now to change node language). [make it the user's problem, with a warning so they're aware]

c) Import the content with the site-default language, warning the user that this has been done. [automatic fix, with warning so they're aware]

d) Have a setting in Migrate UI to determine what to do with content that has an empty language field. Choices could be: migrate as site-default language, migrate as some particular language, migrate as UND. [user-defined fix up front]

Remaining tasks

User interface changes

API changes

Data model changes

Comments

jhodgdon created an issue. See original summary.

gábor hojtsy’s picture

How did your nodes end up as und in Drupal 6? By default Drupal 6 creates nodes with empty langcode as far as I see in http://cgit.drupalcode.org/drupal/tree/modules/node/node.pages.inc?h=6.x... although it was a long time I looked so it may be changed somewhere, but that is the node module default. If that is what the migration maps to und to fix an invalid language code, maybe it can map to the site default language also given that an empty language indicates that you never picked an explicit und, so we can make other assumptions if we want IMHO.

jhodgdon’s picture

Title: Migrating content with UND language is problematic » Migrating content with missing language is problematic
Issue summary: View changes

My mistake. The d6 database has an empty langcode field for those nodes. Correcting issue summary. Sorry about that!

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

geerlingguy’s picture

I ran into this issue, though it might be somewhat different in that I've never had a multilingual site, just started with Drupal 6 then upgraded to Drupal 7 with one language, English.

Details are here: Fix old comments that have gone missing.

I have to manually set all the comments' langcode in comment_field_data to und, and also have to set the comment__comment_body langcode value to und. Only after doing that, and clearing all caches, do my comments appear.

I'll probably do something in the migration to just always default to und, but this tripped me up a while in my own migration.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

geerlingguy’s picture

My fix, for now, was to force the und langcode on all content in my comment migration:

/**
 * Implements hook_migrate_prepare_row().
 */
function custom_migrate_prepare_row(Row $row, MigrateSourceInterface $source, MigrationInterface $migration) {
  $migration_id = $migration->id();

  // Force 'und' language for comments.
  if ($migration_id == 'upgrade_d7_comment') {
    $row->setSourceProperty('language', 'und');
  }
}
quietone’s picture

The core d6_taxonomy_term migration does not have a langcode destination property but the d7 ones does, although it does not have a default value; The d6_comment migration and the d7_comment migration have a langcode property but only the d7 one uses the default_value plugin.

I wonder if all the entity migrations need to be examined so that the langcode property is always this:

  langcode:
    plugin: default_value
    source: language
    default_value: und

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

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

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.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.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.

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.