Is there an upgrade path planed or will users stand in the rain / stuck like in some past i18n upgrades? I'd like to know if there will be an automatic process or if everyone need to develop upgrades on his own.

Comments

plach’s picture

Yes, the plan is to provide an upgrade path to D8, which will likely be the only functionality implemented in the 8.x-2.x branch. Both translation models will be supported.

plach’s picture

Priority: Normal » Critical
Status: Active » Postponed

This won't happen until we are done with the D8 entity storage at least.

klonos’s picture

Title: Upgrade path to D8? » Entity Translation: Upgrade path to D8?

...better title for our dashboards ;)

plach’s picture

plach’s picture

matsbla’s picture

One question: In entity translation D7 I think all languages are saved in every revision, while in D8 "we write to the storage only field values that actually changed": #2562759-2: Nodes revision cannot be saved per translation.
So will the upgrade path be able to pull out the relevant changed translation for each revision in D7 or will just all revisions for all languages be imported into D8?

plach’s picture

That means that only changed values are re-written, but they are always stored at least once per revision.

meanderix’s picture

Has there been any progress on this issue? Is there going to be an upgrade path in the 8.x-2.x branch?

I'm using entity translation with field translation, i.e. language_content_type_{type} == 4.

#2225271: Migrate content type language settings from Drupal 6 & 7 seems to add support only for the legacy translation settings and not for Entity Translation with "field translation".
#2669964: Migrate Drupal 7 core node translations to Drupal 8 also seems to deal only with the legacy translation.

Any pointers as how to approach this in a new migration project?

masipila’s picture

Should this issue be moved to the Drupal core queue? I think that many migrations where d7 contrib functionality has been moved to d8 core are now handled in the core issue queue.

Cheers,
Markus

Gábor Hojtsy’s picture

Title: Entity Translation: Upgrade path to D8? » Migrate Drupal 7 entity translation data to Drupal 8
Project: Entity Translation » Drupal core
Version: 7.x-1.x-dev » 8.4.x-dev
Component: Base system » migration system
Priority: Critical » Major
Status: Postponed » Active
Issue tags: +i18n-migrate, +D8MI, +migrate-d7-d8

Unpostponing and moving to the core queue. I think There is nothing stopping this from happening other than people working on it :)

mikeryan’s picture

vasi’s picture

My colleague Jigar wrote some example i18n migrations, including one for D7 entity translation. The particularly interesting part is the custom source he used.

It's not quite a general solution—it's only for nodes. However, it definitely shows the major pieces:

  1. We need a way to determine whether a D7 bundle is entity-translated. This method works for nodes only, there's no general method for this—other migration sources will need different methods.
  2. As with other translatable sources, we need an extra ID field in getIds(), for language.
  3. We need to modify the query so it joins against the entity_translation table, and overrides some fields. Ideally this would go in a base class and/or trait for D7 migration sources, so they all could use it.
  4. We need to modify getFieldValues() so it supports a $language parameter, and then have prepareRow() use that.
Gábor Hojtsy’s picture

Jigar also blogged about it now at https://evolvingweb.ca/blog/migrating-content-translated-entity-translat... -- can we turn that somehow into a more general solution in this issue? That would be great :)

jigarius’s picture

I wanted to experiment a bit, so I thought I'd spend some time to create a solution. I didn't know how to start the "right way", so I created a repo on https://github.com/jigarius/drupal/tree/dev-2073467 and did the following:

  1. Added support for a $language parameter in the d7\FieldableEntity class.
  2. Added a new method d7\FieldableEntity::loadFieldValues(Row $row, $entity_type). This will allow source plugins to load field data with a single method call with quite a simple set of arguments, instead of having to call the getFields() method and then iterating over every field, etc.
  3. Added a D7EntityTranslationTrait in the migrate_drupal module.

Here's what a source plugin needs to do to implement entity translation support:

  1. Source plugin uses the D7EntityTranslationTrait. The plugin will need to implement the d7\FieldableEntity interface and override the query() method to call D7EntityTranslationTrait::handleEntityTranslations() (which currently has some basic arguments I could think of).
  2. The source plugin implements a getEntityKeyInfo() to provide entity key data.
  3. The source plugin overrides the prepareRow() method to call the loadFieldValues() method to attach field values in the language concerned ($language parameter must be specified as and when applicable to get the field values in the correct language).
  4. The migration definition (YML) sets the source parameter translation_method: entity_translation. The translations: true parameter should work as expected to get things working.

Comments and suggestions are welcome. Oh! And this is the first time I'm working on Drupal core, so if I do something which is not "standard procedure", please let me know.

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.