When setting an Experience Fragment in a blueprint, live copies will not automatically pick the correct corresponding language version of the Experience Fragment. This makes our author's output slower on Experience Fragments. And it increases the risk of human error/inconsistency significantly.
Use-case:
A multilingual setup making use of Experience Fragments. Each Experience Fragment has a Blueprint (en) and a language copy. And in Sites, a Blueprint (en) and live copies in the same languages.
Current/Experienced Behavior:
When an author creates or updates pages in Sites blueprint, and we synchronize those changes into the live copies, the Experience Fragments in those pages have to be adapted manually to the correct laguage. This means authors cannot manage Experience Fragments from the Blueprint in a multilingual setup. It means an Author is forced to go an manually pick the correct Experience Fragment in each language, whereas it as simple as chaning the language part from the pointer to the correct language, e.g
Experience-fragments/en/test/master
->
Experience-fragments/nl/test/master
In our multilingual setup: this step is repeated for all the languages, because we use a language copy structure inside Experience Fragments, the action is very simple, but repetitive and error-prone.
Authors need to repeat the same change in the Blueprint and each Live Copy individually, which results in loss of time on repetitve tasks and the introduction of possible errors.
Improved/Expected Behavior:
Pointers to Experience fragments are automatically translated in "Sites" when sites and Experience fragments both use the same language structure.
Environment Details (AEM version/service pack, any other specifics if applicable):
Thanks for suggesting the idea. Can you share few screenshots or a quick screen cast to understand the use case clearly and the same could be discussed with the product team accordingly.