Problem/motivation

Drupal 8 does not intend to support two parallel content translation systems. The legacy node translation module stores nodes as separate entities when translated. The new content translation module stores translations all in the same node. Consider adding an upgrade path to migrate this data to the new system.

Beware: other related data such menu items, taxonomy term relations, node access rules, path aliases, visitor stats, etc. will be affected, and would need to be taken care of. This is likely what makes the task *huge*!

Proposal

Bring the existing migration code up to date from http://drupal.org/project/entity_translation and make it work in Drupal 8. See if we can tackle the related data in core and provide contrib with ways to cope with the extent of the change.

Nope. Won't fix by @Dries. #1952062-14: Remove legacy translation module in favor of content translation

I'd be ok with fixing the upgrade path [of content translation] in contrib.

BUT, also at Prague it was suggested to not have upgrade path in 8.0 .. in general, not just for this old content translation. (Need a post, discussion or issue to link to that explains that plan.)

Dependencies

#1498674: Refactor node properties to multilingual (hard dependency)
#1658846: Add language support to node access grants and records (optional, will need to migrate node access data as well accordingly)

Comments

Title:Consider upgrade path for legacy content translation module dataUpgrade path for legacy content translation module data

Is this still postponed?

Status:Postponed» Active

making it active as dependencies are done and dusted.

Component:translation_entity.module» content_translation.module

Status:Postponed» Active

What's actually blocking the upgrade path of the data? (As opposed to missing features once the data is upgraded).

Quoting from #1952062-10: Remove legacy translation module in favor of content translation:

The main critical issue with the upgrade path is that we will be merging nodes, which sounds like a lot of potential pain. In contrib D7 the upgrade path is a standalone module that provides a UI, hooks, and a functionality to redirect from the old urls to the new ones:

it/node/1
en/node/2  -- redirect --> en/node/1

I am not sure whether it makes sense to have such code in core. It sounds much more like a D7 CCK thing, even if we don't provide a UI for it.

Yes that might be a more reasonable approach (as would using migrate to merge nodes) rather than trying to just run the upgrade automatically.

Assigned:Unassigned» Dries

Assigning to Dries for some feedback.

Assigned:Dries» Unassigned

as would using migrate to merge nodes

Totally. Can we mark this won't fix?

Assigned:Unassigned» Dries

Assigned:Dries» Unassigned
Status:Active» Closed (won't fix)

Marking this "won't fix" based on the discussion in #1952062-14: Remove legacy translation module in favor of content translation.

Title:Upgrade path for legacy content translation module dataMigration path for legacy content translation module data
Status:Closed (won't fix)» Active

Reopening based on recent migration related discussions. Sounds like this may need to be in core after all but not with update functions.

The problem here is we won't need only a migration path (see #9). Moreover Jose is planning to revive the node-copy approach in https://drupal.org/project/translation, hence punting the upgrade migration to contrib will give people a choice.

Right, Drupal 8 does not plan to have update function based upgrade path anymore. We plan to have migrate module style upgrade path now :) The question is whether there is a point in doing that for this functionality in core. We'll need to have it somewhere built because it is about migration from one older core way of doing things to a new core way.

I think a somewhat confusing way would be to save compound nodes in the migration and create path aliases with the old node Ids (if old node aliases are not available). Eg. alias 'node/2' to 'node/1' for 'fr' if the French node used to be node/2 :) That sounds a bit confusing, but it would keep old paths working and render in the proper language of the node still :)

Issue summary:View changes

explaining no upgrade path