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]
Comments
Comment #2
gábor hojtsyHow 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.
Comment #3
jhodgdonMy mistake. The d6 database has an empty langcode field for those nodes. Correcting issue summary. Sorry about that!
Comment #9
geerlingguy commentedI 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'
langcodeincomment_field_datatound, and also have to set thecomment__comment_bodylangcodevalue tound. 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.Comment #11
geerlingguy commentedMy fix, for now, was to force the
undlangcode on all content in my comment migration:Comment #12
quietone commentedThe 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: