Problem/Motivation

Say you have a field on both the article and basic page bundles but only the article bundle is translatable. Calling isTranslatable() on the field config for the basic page bundle will return true. This is the problem. If the basic page bundle becomes translatable (but not the field itself), isTranslatable() correctly returns false. So basically, as @plach said, the translatability is inherited from the field storage if they are not configured in the UI.

Proposed resolution

I believe it doesn't make sense for a field config to call itself translatable if it is in fact not. But I also probably am missing a lot of context info as to why this is. So it's very much open to discussion.

Remaining tasks

Discuss this issue and come to an agreement on the matter.

User interface changes

None.

API changes

Unclear.

Original report by @Upchuk

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

plach’s picture

Component: language system » field system
Issue tags: +D8MI, +language-content

A possible solution to this issue would certainly be taking also bundle translatability into account: if a field definition is attached to a bundle and the bundle is not translatable then we would return FALSE. OTOH FieldDefinitionInterface::isTranslatable() is called a lot on multilingual sites (see ContentEntityBase::getTranslatedField()), so we should probably figure out in which cases this issue can cause serious problems, before trying to change the current status.

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.

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.

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

Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)

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

Drupal 8.5.6 was released on August 1, 2018 and is the final bugfix release for the Drupal 8.5.x series. Drupal 8.5.x will not receive any further development aside from security fixes. Sites should prepare to update to 8.6.0 on September 5, 2018. (Drupal 8.6.0-rc1 is available for testing.)

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

DamienMcKenna’s picture

DamienMcKenna’s picture

I'm specifically running into this in Entity Reference Revisions (entity_reference_revisions) where EntityReferenceRevisionsItem::preSave() checks the field's definition via getFieldDefinition(), checks isTranslatable() and will return either TRUE or FALSE.

DamienMcKenna’s picture

I wonder if part of the problem is that FieldStorageConfig::isTranslatable() only checks $this->translatable rather than following similar logic to ConfigEntityBase::isTranslatable():

    // Check the bundle is translatable, the entity has a language defined, and
    // the site has more than one language.
    $bundles = $this->entityManager()->getBundleInfo($this->entityTypeId);
    return !empty($bundles[$this->bundle()]['translatable']) && !$this->getUntranslated()->language()->isLocked() && $this->languageManager()->isMultilingual();
DamienMcKenna’s picture

Version: 8.6.x-dev » 8.7.x-dev
Status: Active » Needs review
FileSize
919 bytes

Would this be acceptable? It replicates the code from ContentEntityBase::isTranslatable() and adds on an extra && $this->translatable in case the config was set to be translated.

DamienMcKenna’s picture

The code in #11 could / should probably be improved upon.. but it at least checks the system translations.

Status: Needs review » Needs work

The last submitted patch, 11: drupal-n2457787-11.patch, failed testing. View results

DamienMcKenna’s picture

I guess not ;-)

DamienMcKenna’s picture

Status: Needs work » Needs review
FileSize
652 bytes
1.02 KB

Trimmed down patch so now it just checks $this->languageManager()->isMultilingual() and $this->translatable.

Status: Needs review » Needs work

The last submitted patch, 15: drupal-n2457787-15.patch, failed testing. View results

plach’s picture

Didn't look at the patches closely yet, but I think it's useful to point out that the field storage definition's translatable property is meant to tell whether the field storage supports translation. The actual field runtime configuration should not affect this as we don't change the field storage depending on that.

OTOH it makes sense to tie field translatability to bundle translatability when dealing with field definitions as this is a per-bundle setting. I'm only afraid of possible BC issues.

DamienMcKenna’s picture

A minor adjustment to the test, this confirms that the field is not translatable before the additional languages are added.

The last submitted patch, 18: drupal-n2457787-18.test-only.patch, failed testing. View results

Status: Needs review » Needs work

The last submitted patch, 18: drupal-n2457787-18.patch, failed testing. View results

DamienMcKenna’s picture

@plach: That's a good point. I suppose it could also be handled in Entity Reference Revisions, so maybe instead of $this->getFieldDefinition()->isTranslatable() it should be checking the instance?

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.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.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

larowlan’s picture

Is this still an issue @DamienMcKenna?

yogeshmpawar’s picture

Status: Needs work » Needs review
Issue tags: -Needs reroll
FileSize
1.93 KB
2.28 KB

Updated patch with reroll diff added.

Status: Needs review » Needs work

The last submitted patch, 29: 2457787-29.patch, failed testing. View results

larowlan’s picture

Status: Needs work » Postponed (maintainer needs more info)

For #28

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

DamienMcKenna’s picture

I no longer have access to the site this problem first showed up for me, and I haven't ran into the problem on any other site since; that said, every site I work on either has zero translation or one extra language with translation enabled on all content types, I still think the original bug is a valid scenario.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.