Localizing language based site links on adobe.com

[Ruchika4]

We have a request in CC to localize creativecloud.adobe.com links authored on CC Milo pages in adobe.com
creativecloud.adobe.com is a language based site. However our current link localization localizes the link by appending locale.prefix which is geo based.
So for example when localizing https://creativecloud.adobe.com/discover to Japanese it converts it to https://creativecloud.adobe.com/jp/discover instead of correct url https://creativecloud.adobe.com/ja/discover

Discussed this with @auniverseaway and he had following suggestions/considerations

After Milo's loadArea, scan page for specific domains (blog, creativecloud, etc.) that are language-based.
If there are any links that match, load the localeToLang map for the domain.
Some other thoughts / considerations:
You'll want to build this in a way that is fragment friendly, which means possibly putting it in [here](https://github.com/adobecom/milo-college/blob/main/scripts/utils.js#L40-L58).
Making this fragment friendly in the above would mean it fires before LCP which is not ideal. You don't really want a link that likely won't be clicked to be prioritized before the LCP.
You could ask Milo Core for an event that could fire... Something like after section load... then you don't impact LCP, but it runs right after. This also means you are not cluttering up your decorate function.
I would probably try keep this out of core milo aside from the event. My take is that Milo should mostly be unaware of nitty gritty domain details (think locales, typekits, etc.) the creative cloud mapping is a CC problem, not an everyone problem (for now).

I also tried below approach:

1. Add lang parameter in locale something like below

2. Add another parameter in config to define sites that are language based in consuming site script.js

3. Then in localizeLink function in milo utils.js put a check to see if link is in langDomains then append locale.lang instead of locale.prefix

Challenge with above approach is that not all language based sites are not following same language code format. For example blog.adobe.com has APAC (English), US (Englis), UK (English). However creativecloud.adobe.com only has English.

So I feel we'll need to do locale and language mapping for each domain.
I'll appreciate community input also to finalize the approach and best place to create the mapping file to pass in config.

Looking forward for feedback. Thanks in advance.

cc @dstrong23 @overmyheadandbody @narcis-radu @mokimo @rgclayton @chrischrischris

[overmyheadandbody]

I 100% agree that Milo itself shouldn't have opinionated consumer logic. We had the same approach when defining the prod to stage link transformation, we chose to make Milo itself oblivious to such details and instead ask consumers to provide a map.

From what you're describing, it sounds like different domains have different mappings, right? So your suggested approach would be domain-specific, although locales are site-specific, which is a no-go. Otherwise you could have inferred the language directly from the ietf code, without needing an additional property. So having a domain-specific map sounds like the lesser evil long-term. I'd likely avoid defining these maps in Sharepoint, since it would probably come with a performance cost and the language data is usually immutable enough to not justify having authors maintain it; it could've acted as a source of truth for all consumers (if defined under the federal Sharepoint), but until we get more such requests, I'd leave the idea aside.

So you'd likely have to define this map on the consumer side, either in your scripts or as a completely different module. You should check the effect on the bloated scripts file for pages that don't need this map vs importing a new module for pages that do.

I'm not sure an event approach would work OOTB; the flow I'd think occurs is: section starts being decorated, including link localization, so /discover becomes /jp/discover, then we'd fire an event and we'd need to replace the /jp with a /ja. So one idea could be to prevent these links from being localized to begin with, a sort of #_dnt behavior if the domain has different rules. This would need a Milo contribution to skip localization for certain domains provided by the consumer through a new config property to be passed. A generic event could be dispatched after a section loads and you could then call localizeLink for links that match your pattern.