Problem/Motivation

In #2431329: Make (content) translation language available as a field definition we introduced a translated default_langcode field, but we prevented it from being altered as it should be considered read-only. We did not use a standard method to implement this as read-only constraints were not working at the time. Moreover until #2137801: Refactor entity storage to load field values before instantiating entity objects is fixed, the field is actually populated so it cannot be read-only. However we should switch to a standard method as soon as possible.

Proposed resolution

TBD

Remaining tasks

  • Figure out a solution
  • Write a patch
  • Review it

User interface changes

None

API changes

None

Comments

plach’s picture

Issue summary: View changes
hchonov’s picture

Why is the default_langcode considered as read-only?
Consider the following use case:

  1. Create an entity with default language german.
  2. Add an english translation.
  3. At some point decide that the german translation is not needed anymore.
  4. Switch the default language to english and remove the german translation, so that it is not carried through all the further revisions of the entity as it is not needed and it will stay there only as a garbage.

At the moment we are not able to do this.

mkalkbrenner’s picture

I second hchonov's use-case described in #2. He demonstrated it to me by simply removing the Exception that is thrown when you modify the default language field.
I'm now of the opinion that it should be allowed to modify the default language. But additionally we need constraints that ensure that there is always a valid default language.

plach’s picture

Status: Postponed » Active

This is an interesting point and may help with solving #2485499: Allow source translations to be removed. However, I think we still need to ensure that only one single translation is marked as default and, if we change it, the previous default is marked as non-default.

Anyway, I'm pretty sure just changing the default_langcode field value is not enough, unless the entity is reloaded, because the internal data structures need to be adjusted to take the new default langcode into account.

plach’s picture

Title: Use constraints to ensure default_langcode has always a valid value » Allow default_langcode field value to be changed
plach’s picture

Priority: Normal » Major
Issue tags: +Entity Field API
Berdir’s picture

This might also resolve bugs in the serializer when you have multiple translations, because it currently explodes on the default_langcode field, as it tries to explicitly set the value to 0/1 for different translations.

mkalkbrenner’s picture

Anyway, I'm pretty sure just changing the default_langcode field value is not enough, unless the entity is reloaded, because the internal data structures need to be adjusted to take the new default langcode into account.

@plach: Could you explain, why a change of this field has to be handled differently from a change of any other field?

plach’s picture

Because many internal data structures of a content entity are keyed by language, so if we change the default language we must adjust them. For instance the field values of the default translation are keyed by LanguageInterface::LANGCODE_DEFAULT to make it easy to change the entity's default language from the UI (usually keeping its values untouched). If instead we switch the default language, we need to adjust that.

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.

mikeryan’s picture

Last comment here was one year ago today - time for a bump!

Migration needs this - we can't guarantee the default language node (the one referenced by tnid in the legacy installation) will be the first one migrated, so want to be able to change it when that node is migrated in.

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.

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

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should 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.