In Drupal 8.5, changes were made that allow creating pending/draft revisions of multiple translations in parallel. To avoid conflicts, that requires to hide non-translatable fields when editing translations.
This conflicts with complex use cases like Paragraphs on untranslatable fields, which expects to be shown on translations as well and then allows to edit the referenced translations.
Several backwards compatible additions were introduced that allow such fields/widgets to work with pending revision translations.
Support for setting #multilingual in a widget
The Content translation module now respects an already set #multilingual key, which allows widgets to enforce that they are visible when creating translations even if their field is set to untranslatable. A widget can override the form method like this:
/**
* {@inheritdoc}
*/
public function form(FieldItemListInterface $items, array &$form, FormStateInterface $form_state, $get_delta = NULL) {
$elements = parent::form($items, $form, $form_state, $get_delta);
$elements['#multilingual'] = TRUE;
return $elements;
}
A new hasAffectingChanges method on FieldItemListInterface
Until now, \Drupal\Core\Entity\ContentEntityBase::hasTranslationChanges() and \Drupal\Core\Entity\Plugin\Validation\Constraint\EntityUntranslatableFieldsConstraintValidator::hasUntranslatableFieldsChanges() assumes that a field has affecting changes if the values are not equal, with a special case for ChangedItem.
This change introduces a new method that allows each field type to override that logic and for example ignore certain properties that might not be relevant for a given translation.
public function hasAffectingChanges(FieldItemListInterface $original_items, $langcode) {
// When saving entities in the user interface, the changed timestamp is
// automatically incremented by ContentEntityForm::submitForm() even if
// nothing was actually changed. Thus, the changed time needs to be
// ignored when determining whether there are any actual changes in the
// entity.
return FALSE;
}
Note that this only relevant for translation affected flags and validation. Those values (on untranslatable fields) will then be ignored and overwritten when creating a new revision from a draft and if necessary, the new hook_entity_revision_create() hook must be implemented to process the values further.
New hook_entity_revision_create() and hook_ENTITY_TYPE_revision_create() hooks
See the changes in Entity Reference Revisions for a more complex implementation of the hasAffectingChanges() method and the new hook.
