Display Builder override saves to wrong language on multilingual sites

Thanks a lot ZiQiang for the ticket and the proposal 🙏

Overview

So, if my understanding is right, the issue is about EntityViewOverride buildable only, so the main work is in display_builder_entity_view:

• ✅ EntityViewOverridesController::title() update to print language
• ⚠️ Update of entity_delete hook and a new entity_translation_delete hook: the logic seems a bit complex, so I am not sure I understand well, but I guess it is to delete all overrides of a specific language when the display config of the same language is deleted? Am I right? That's all or something else happens here?
• ⚠️ A few updated methods in EntityViewOverride buildable plugin. Let's check once the Instance entity ID change is clear.
• ⚠️ A little change in InstanceEntityViewDisplayOverrideAccessControlTest::testInstanceEntityViewDisplayAccess(), only about the Instance entity ID change

Outside display_builder_entity_view:

• ✅ a little check in src/Controller/IntegrationControllerBase.php: may not be directly related to the change, but it is a nice precaution
• ✅ src/DisplayBuildablePluginBase.php: feeding the existing langcode field when creating an instance was missing
• ⚠️ Instance::label(): related to the Instance entity ID change
• ⚠️I don''t understand why are we also modifying src/HtmxEvents.php
• ⚠️ display_builder_update_11105: why not a display_builder_update_11105 display_builder_entity_view_update_11101? And this instance ID change again.

Instance entity ID change

The display_builder_instance entity ID for entity_view_override overrides follows this format:
entity_override__{entity_type}__{entity_id}__{field_name}
This ID contains no language information, so all translations of the same entity share a single Instance entity as their working copy.

Instance entity is translatable using the standard content translation API of Drupal. So I don't understand why we need to put the language code in the entity ID.

Let's take a 1 unique node with 2 translations (node:54:en and node:54:zh and the overrides stored in field_teaser. It will generate a single instance entity with 2 translations:

• display_builder_instance:entity_override__node__54__field_teaser:en
• display_builder_instance:entity_override__node__54__field_teaser:fr

Do we really for 2 different instance entities, one for each language ?

Because of the upcoming #3555110: Symmetric translation, it would be nice if Christian do the final review of this ticket.

That's surprising as our instance entity is translatable. I do not think there is a huge rewrite, more that we need to plug to existing translation mechanism.

Translation in Drupal is not perfect, and there is work in progress in core to make it better, there is helpers like language_audit. So I guess we need to POC around a bit more and see what's the best and avoid any 'custom' system around translation.

Using translation to solve this problem would require a complete overhaul of the current history handling mechanism, as the history mechanism based on revision and default vision, as well as the undo and redo mechanisms, would need to be completely rewritten.

If we must reorganize InstanceStorage::redo(), ::undo(), ::getPast() and ::getFuture() to make them aware of translations, let's propose a change there.

I have the feeling it is better than tweaking the Instance ID.

For your information, we did a little mistake during the early days of the development: instead of considering Instance entity ID as an opaque string, we have put meaning into it, and we rely on this meaning in DisplayBuildableInterface::checkInstanceId(), ::getDisplayUrlFromInstanceId(), ::getUrlFromInstanceId().

It is not necessary anymore since the introduction of this field in Instance entity:

    $fields['buildable'] = BaseFieldDefinition::create('plugin')
      ->setSetting('plugin_manager_id', 'plugin.manager.display_buildable')
      ->setRequired(TRUE)
      ->setReadOnly(TRUE);

And we may be happen to remove the legacy methods some day: #3573905: Simplify DisplayBuildableInterface.

So, let's not add more meaning in Instance entity ID strings.

I don''t understand why are we also modifying src/HtmxEvents.php

Because some language codes contain hyphens(zh-hans), adding language codes to the ID causes JavaScript to fail to parse the ID correctly, resulting in a page error. Therefore, this was modified.

That's interesting, thanks for the explanation, but let's hope the new direction will prevent us to send this info to Javascript.