Follow-up to #2476563: Entity operations links tied to original entity language, ignore everything else

Problem/Motivation

Currently, deleting a source translation means everything disappears, and we behave differently in the UI depending on whether we are dealing with a source translation or not. This means we have to do workarounds such as changing deletion links for an entity if we're dealing with a source translation, which ideally we wouldn't have to do.

Quoting from @Gabor in #2476563: Entity operations links tied to original entity language, ignore everything else

When you delete the original translation of an entity, the entity API should have provisions already to pick another original language for that entity I believe.

Apparently these provisions do not exist yet.

@plach

In this case ideally we should remove only the original translation and designate a new default entity language, but this may not be trivial to achieve

Proposed resolution

Allow for the original language to be reassigned in the entity API

Remaining tasks

  • Figure out what we will do whenever a user removes a source translation
  • Validate the proposed solution
  • Write a patch
  • Reviews

User interface changes

TBD

API changes

TBD

Comments

stefan.r’s picture

The UI implications of this are probably out of scope for this issue, but at least thinking of what we're going to do on the UI level may help us think of a proper solution for this. I had discussed this earlier with some people and some of the solutions mentioned for how to deal with a source translation deletion were:

If the node only has 2 languages:
- just assign the other language.

If the node has 3 or more languages:
- ask the user in a confirmation screen what the new original language for every entity will be.
- or: have a ready made weighted list of default languages, where we just go to the next in line.

Or maybe we could just say none of the translations is a source translation anymore? And I say that not knowing why we need one of the translations to be marked as a source translation in the first place and how much logic depends on this... On an intuitive level it makes sense though, if we delete a piece of content that's the source of all other translations and we ask the entity which of the existing pieces of content is the source, the answer is actually "none of them".

stefan.r’s picture

Issue summary: View changes
plach’s picture

Title: Source translations cannot be removed » Allow source translations to be removed
Category: Bug report » Task
Status: Active » Postponed
Related issues: +#2443991: Allow default_langcode field value to be changed

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.