MSM content structure for XF to support several language variations

[koha26]

Hi, community,

On your project (AEM Release 2023.9.13665.20230927T063259Z), we follow a well-known content structure to manage pages and XFs.

Content:
/content/site/language-masters
             |
             |__de
             |__en - language copy of /content/site/language-masters/de
             |__fr - language copy of /content/site/language-masters/de

/content/site/de/de - live-copy of /content/site/language-masters/de
/content/site/gb/en - live-copy of /content/site/language-masters/en
/content/site/fr/fr - live-copy of /content/site/language-masters/fr
/content/site/ch/fr - live-copy of /content/site/language-masters/fr

XF:
/content/experience-fragments/site/language-masters
        |
        |__de
        |__en - language copy of /content/experience-fragments/site/language-masters/de
        |__fr - language copy of /content/experience-fragments/site/language-masters/de

/content/experience-fragments/site/de/de - live-copy of /content/experience-fragments/site/language-masters/de
/content/experience-fragments/site/gb/en - live-copy of /content/experience-fragments/site/language-masters/en
/content/experience-fragments/site/fr/fr - live-copy of /content/experience-fragments/site/language-masters/fr
/content/experience-fragments/site/ch/fr - live-copy of /content/experience-fragments/site/language-masters/fr

However, we found out that languages like nl_be, zh_cn are not correctly handled during the rollout process of XFs. There is an action referencesUpdateXF that rewrites references in the XF during the rollout process. Based on the code of this action, it expects to have language code (not locale) in the XF source path and link to be rewritten. For example:

We have /content/experience-fragments/site/language-masters/zh_de/teaser/teaser that has a button with a link to /content/site/language-masters/zh_de/some-page. We want to roll out XF to /content/experience-fragments/site/cn/zh/teaser/teaser. 

Actual result:

The link is not rewritten. 

Expected result:

The button link leads to /content/site/cn/zh/some-page.

During the rollout actions expects that the source XF path looks like /content/experience-fragments/site/language-masters/zh/teaser/teaser and link /content/site/language-masters/zh/some-page. However, it doesn't fix requirements, because the zh language is another variation and is used for another country. 

Has anyone encountered the same problem and how did you solve it?

[kautuk_sahni]

@aanchal-sikka @A_H_M_Imrul , Can you please review this Question and share your thoughts? 

[Shashi_Mulugu]

@koha26 how had you created live copy folders in Experience fragments?

[koha26]

Let me describe our content management flow. 

We have a 3rd-party translation provider. It's responsible for creating language copies.

If we want to introduce new language (to create a language copy), we will add /content/site/language-masters/de as content source, and all XF source paths (e.g. /content/experience-fragments/site/language-masters/<new_lang>/site/header) to the translation project. As a result of the translation, we will have a language copy for content and XFs.

Having content, XFs under the language masters we are able to create live-copies. To do that, we have a custom workflow that helps to create XF live copies from the language masters.

Under the hood, we programmatically create XF live-copy using POST /bin/wcmcommand with "createLiveCopy" command.

As a payload we take a live copy path in the content, find relevant source XF language master path, and target XF path. For example: 
Content: /content/site/ch/de
Source XF language master: /content/experience-fragments/site/language-masters/de

Target XF: /content/experience-fragments/site/ch/de

[Shashi_Mulugu]

Understood @koha26 still not optimal way for handling msm in exp fragments, you should be able to manage with lang masters version itself in sites pages and ootb exp fragment core component has capability to pickup localized exp fragment.

But to your question , use custom link rewriter with custom sling pipeline option which acts at html rendering level than at each rollout action.. so technically at jcrcontent it will be based on source but while we hit .html url, it will change.

[koha26]

Thank you for your answer. I understood your idea.

You described how XF is localized in the template. The XF Sling model has conditions for localizing the XF link.

This makes the XF MSM concept unusable for XF, which is not in the template. For example, we have an XF teaser that can be reused across different pages. Usually there is a link in such a teaser. So we need to somehow rewrite the xf variant reference on rollout (this doesn't currently happen with the "referencesUpdate" action), and we need to have translated content with the correct XF references.

I realized that this could be easily fixed with an HTML rewriter, but it would be like fixing the consequences. I'd like to implement the obvious solution. Additionally, there is a "referencesUpdateXF" action that rewrites references in XF content, but does not handle nl_be, zh_cn languages in paths.

So I want to either extend it or create my own deploy action to handle such languages. I realized that there is currently no optimal way to handle MSM for XF versus pages.

Additionally, I would like to transform the fragmentVariationPath when the page is rolled out, rather than when it is rendered. It's content and link, so I think it needs to be transformed. Link translation is the responsibility of the rollout process, not the page rendering.

[Harwinder-singh · Accepted solution]

@koha26 You will need a custom rollout config to achieve this. something similar to this one - https://bimmisoi.blogspot.com/2021/07/update-link-reference-inside-experience.html

[kautuk_sahni]

@koha26 Did you find the suggestions from users helpful? Please let us know if more information is required. Otherwise, please mark the answer as correct for posterity. If you have found out solution yourself, please share it with the community.

[koha26]

Thanks to @Harwinder-singh, we will implement a custom rollout config to handle nl_be, and zh_cn links rewriting. 

Regarding second issue that I mentioned above (rewriting fragmentVariationPath), I found that Adobe released a fix in Release 13665 (2023.09):

• SITES-14773: Experience Fragments: Link Reference does not get updated inside experience fragment.