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

Gábor Hojtsy’s picture

Gábor Hojtsy’s picture

Title:Consider upgrade path for legacy content translation module data» Upgrade path for legacy content translation module data
Gábor Hojtsy’s picture

Berdir’s picture

Is this still postponed?

vijaycs85’s picture

Status:Postponed» Active

making it active as dependencies are done and dusted.

Gábor Hojtsy’s picture

Component:translation_entity.module» content_translation.module
catch’s picture

Status:Postponed» Active

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

plach’s picture

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.

catch’s picture

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

catch’s picture

Assigned:Unassigned» Dries

Assigning to Dries for some feedback.

plach’s picture

Assigned:Dries» Unassigned

as would using migrate to merge nodes

Totally. Can we mark this won't fix?

plach’s picture

Assigned:Unassigned» Dries
Dries’s picture

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.

plach’s picture

Gábor Hojtsy’s picture

Title:Upgrade path for legacy content translation module data» Migration 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.

plach’s picture

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.

Gábor Hojtsy’s picture

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 :)

Gábor Hojtsy’s picture

Issue summary:View changes

explaining no upgrade path

plach’s picture

Gábor Hojtsy’s picture

Pigned @penyaskito and @pcambra to see if this is already resolved in migrate or if they have duplicate issues for this. I believe they do.

pcambra’s picture

Gábor Hojtsy’s picture

Ok. I've heard at several places that the Drupal 6 migration is in place, that does not include some core features looks like then....

catch’s picture

I've also seen this, and I don't think anyone should be making claims like that anywhere. It's OK to say an 'alpha' of the D6 migration is in place.