- Issue created by @wim leers
- 🇺🇸United States effulgentsia
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)
I might be naive, but I don't think that XB will run into the same problems here that ERR/Paragraphs has because XB (SDC) component instances aren't their own entities. So we don't need to support the concept of some static prop values being translatable and others not, like Paragraphs needs to do. For XB component instance prop values that are sourced from the host entity's fields, those host entity fields can be translatable or not, but that's all managed by the host entity without XB introducing anything new as far as that goes.
However, once 🌱 [META] Support component types other than SDC Needs work adds support for XB to host Paragraph entities as components, then we'll need to figure out how to do that in a way that matches Paragraphs module's behaviors with respect to translations. I'm hoping we can do that by delegating all of those complexities to the ERR and Paragraphs modules rather than XB introducing anything unique with respect to how the Paragraph entities/revisions/translations get managed.
Meanwhile, yeah, it still makes sense for this issue to add test coverage for pending revision translations of the XB field as a whole.
