Allow Experience Builder fields to support Asymmetric and Symmetric translations

All passing

Created follow-up for 🐛 If Experience Builder field is not translatable the dynamic source properties do not use the translated entity field value Active

I figure out the problem with viewing entity as a translation and having the XB field being untranslated and showing the title of the default translation.

I figured out why this happens.

1. \Drupal\Core\Entity\ContentEntityBase::get() calls \Drupal\Core\Entity\ContentEntityBase::getTranslatedField
2. getTranslatedField has

   if (!$default && !$definition->isTranslatable()) {
           if (!isset($this->fields[$name][LanguageInterface::LANGCODE_DEFAULT])) {
             $this->fields[$name][LanguageInterface::LANGCODE_DEFAULT] = $this->getTranslatedField($name, LanguageInterface::LANGCODE_DEFAULT);
           }
           $this->fields[$name][$langcode] = &$this->fields[$name][LanguageInterface::LANGCODE_DEFAULT];
         }
         else {
   

   So in the case the XB field is not translated it do a recursive call to getTranslatedField() but his time using LanguageInterface::LANGCODE_DEFAULT

3. In the recursive call to getTranslatedField() then this is called
   

   $field = \Drupal::service('plugin.manager.field.field_type')->createFieldItemList($this->getTranslation($langcode), $name, $value);
   

   So $this->getTranslation($langcode) means the field item list will be created with the default, LanguageInterface::LANGCODE_DEFAULT translation, even though the entity that had the original call to \Drupal\Core\Entity\ContentEntityBase::get() in step above could have been the translation of another language.

The change was made in #2513094: ContentEntityBase::getTranslatedField and ContentEntityBase::__clone break field reference to parent entity →

$field = \Drupal::service('plugin.manager.field.field_type')->createFieldItemList($this, $name, $value);

was changed to

$field = \Drupal::service('plugin.manager.field.field_type')->createFieldItemList($this->getTranslation($langcode), $name, $value);

I will read up that issue. But presumably there was a good reason to need the translation instead of the original entity object.

I was able to use hook_entity_prepare_view to set the fields entity parent to the correct translation

I think maybe we can close #2513094: ContentEntityBase::getTranslatedField and ContentEntityBase::__clone break field reference to parent entity → as I think the use of hook_entity_prepare_view is an okay solution here. But I will research #2513094: ContentEntityBase::getTranslatedField and ContentEntityBase::__clone break field reference to parent entity → a little more to be sure.

but I think hook_entity_prepare_view is a least a good solution for now and we could leave #2513094: ContentEntityBase::getTranslatedField and ContentEntityBase::__clone break field reference to parent entity → open if we want to ask for some core change

@larowlan could we merge this and open a follow-up for the feedback? @tedbow is currently on PTO and it would be great to merge this if we think it's close enough 😇

Will take a look early next week @lauriii

Back from vacation. I reviewed all other issues that you worked on, @tedbow, because they seemed to be where your current attention is at.

Will review on Monday, unless @larowlan beats me to it.

Didn't get to it last week, but @tedbow was already working on the more urgent 📌 FieldType: Support storing component *trees* instead of *lists* Fixed , which is now in 👍

Updated the MR to pass on the latest 0.x.

Questions on the MR.

fixing phpcs

Fixed the phpcs problem expect for 1 in themes/engines/semi_coupled/semi_coupled.engine which was not changed. I guess there is new rule in core?
Anyways I could fix this other file too if we want to get green

fixed the other file, can revert if needed

📌 Lift most logic out of ComponentTreeItem::preSave() and into a new validation constraint Needs work landed and conflicted, merged in upstream + resolved conflicts.

Almost there: https://git.drupalcode.org/project/experience_builder/-/merge_requests/5...

See MR comment

That MR comment is great — thank you! Pushed a commit that captures it for future readers.

As I was making a final pass, I realized that this MR is not actually using/updating the translation: symmetric|asymmetric setting yet 😅 See https://git.drupalcode.org/project/experience_builder/-/merge_requests/5....

Let me know if you agree with this and I can implement it https://git.drupalcode.org/project/experience_builder/-/merge_requests/5...

Wim Leers → credited effulgentsia → .

Discussed with @tedbow and @effulgentsia — we agreed that a setting might offer nicer UX, but that's for some very distant day in the future, that is nowhere near urgent. It doesn't even merit a follow-up issue. Because the current UX for configuring this also might be sufficient 👍

1. Re #22 removed the setting
2. Merged in 0.x and fixed tests(just merged in 2 more commits, think tests will pass🤞🏻)
3. Assigning to @Wim Leers for review. Wim in the Gitlab CI I see
   

   The change requests must be completed or resolved.

   I made the changes I think you asked for and resolved the threads. Not sure where in the UI to mark this as resolved

Tantalizingly close — there's one thing I don't understand 😭

Not caught up on the whole discussion or experience builder storagae in general. I do want to add that the real complexity around translations starts to show when you add pending revisions, aka content_moderation/workflows to the mix. Because that's when you need to start to merge revision data on a per-field or even field-property (in case of ERR/paragraphs, in this case on whatever partial thingies you store/define here).

See also https://berdir.github.io/entities-explained/#/7/4 and slides before and after that.

Mostly an issue for symmetric translations. As an example, assume you have a thing that has a translatable text field, a partially translated image field (file id is synced, alt/title is per-translation) and an untranslatable list/reference field. You might create 3 draft translations in parallel for different languages and at the same time also change the untranslatable list field in the default translation. Then you publish all those in order and the resulting revision should then contain all translations and the untranslatable value from the default translations.

You don't need to and very likely don't want to support that complexity in this initial issue, but it needs to be on the radar, because this is is how content on multilingual sites works (you need to prepare changes on multiple languages and publish them all basically together). Paragraphs/ERR supports this fairly well, getting as far as we are was a large amount of work but people are still struggling with a number of scenarios (for example ✨ Draft translations should be based on the latest revision of the source language, not the published version Needs work and there are several open issues in ERR that I'm struggling to understand).

Thank you so much for that, @Berdir!

This issue represents a big step forward, but I acknowledge it does not guarantee that everything works.

So:

1. merging this MR
2. extracted #26 into a new critical issue: 📌 Test (a)symmetric XB field translations with revisions, pending revisions and content_moderation/workflows Active

Automatically closed - issue fixed for 2 weeks with no activity.