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
Comment #1
Gábor HojtsyCurrently postponed on #1498674: Refactor node properties to multilingual.
Comment #2
Gábor HojtsyComment #3
Gábor HojtsyAlso added #1952062: Remove legacy translation module in favor of content translation postponed on this.
Comment #4
BerdirIs this still postponed?
Comment #5
vijaycs85making it active as dependencies are done and dusted.
Comment #6
Gábor HojtsyI don't think dependencies are done. You still cannot reproduce this module with the current API/UI. Among other things: #2019055: Switch from field-level language fallback to entity-level language fallback, #2004626: Make non-configurable field translation settings available in the content language settings (to some degree #1810370: Entity Translation API improvements), and #1939994: Complete conversion of nodes to the new Entity Field API. See https://drupal.org/node/2004626#comment-7540143
Comment #7
Gábor HojtsyComment #8
catchWhat's actually blocking the upgrade path of the data? (As opposed to missing features once the data is upgraded).
Comment #9
plachQuoting from #1952062-10: Remove legacy translation module in favor of content translation:
Comment #10
catchYes that might be a more reasonable approach (as would using migrate to merge nodes) rather than trying to just run the upgrade automatically.
Comment #11
catchAssigning to Dries for some feedback.
Comment #12
plachTotally.
Can we mark this won't fix?Comment #13
plachComment #14
Dries CreditAttribution: Dries commentedMarking this "won't fix" based on the discussion in #1952062-14: Remove legacy translation module in favor of content translation.
Comment #15
plachRelated issue: #2073467: Migrate Drupal 7 Entity Translation settings to Drupal 8.
Comment #16
Gábor HojtsyReopening based on recent migration related discussions. Sounds like this may need to be in core after all but not with update functions.
Comment #17
plachThe 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.
Comment #18
Gábor HojtsyRight, 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 :)
Comment #18.0
Gábor Hojtsyexplaining no upgrade path
Comment #19
plachComment #20
Gábor HojtsyPigned @penyaskito and @pcambra to see if this is already resolved in migrate or if they have duplicate issues for this. I believe they do.
Comment #21
pcambraWe do have related stuff in there, but no progress lately: #2225775: Migrate Drupal 6 core node translation to Drupal 8 & #2225271: Migrate content type language settings from Drupal 6 & 7
Check https://www.drupal.org/project/issues/search?issue_tags=i18n-migrate for the complete list
Comment #22
Gábor HojtsyOk. I've heard at several places that the Drupal 6 migration is in place, that does not include some core features looks like then....
Comment #23
catchI'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.
Comment #24
catchComment #25
catchComment #27
xjmDiscussed with @weal, @mikeryan, @benjifisher, and @alexpott. This issue is mostly a duplicate of various children of #2208401: [META] Remaining multilingual migration paths (see https://www.drupal.org/project/issues/search?issue_tags=i18n-migrate) particularly those in #21.