Region Nav for a Language Based Site (Express)

[vhargrave]

Hi all,

Recently Express went with milo for India (adobe.com/in/express/), and we're having some issues with the way the region-nav treats our primarily language-based site.
I want to describe the issues, and how I'm proposing that we solve these problems, but am creating a community post for transparency and in case I'm missing something.
Tagging @salonijain3 @aishwaryamathuria @bandana147 from the Tattva team
Furthermore I think this discussion will be of interest to @sukamat @narcis-radu, since it has to do with language based sites.
cc: @JingleH @fullcolorcoder @mokimo @overmyheadandbody & @robert-bogos too.

Issue Number 1:
We have about 20 locales currently in Express, and most of them are for different language versions of the site.
Pre-migration, when opening up the region-nav, we converted links for locales that didn't exist, but that we had a language of, to an equivalent language variant.
For example, the link to the Argentinian website adobe.com/ar/express/ would get converted to adobe.com/es/express/ in the region-nav, since we have a Spanish experience.
What we would also do though, is still set the international cookie to ar on a user click, so that prices for example would get appropriately displayed for Argentina.
This conversion doesn't happen with the milo implementation of the region-nav and it means that links to adobe.com/ar/express/ now stay as is, but when a user hovers over the link, milo checks if the adobe.com/ar/express/ page exists, and since it clearly doesn't , milo rewrites the link to take the user to the homepage. This is not the experience that we want.

Solution Number 1.:
I think the best approach that we can take is to create a type of language map. I have an example PR [here]. (https://github.com/adobecom/milo/compare/vhargrave/language-based-region-nav?expand=1#) of how that would look (only the changes in the region-nav.js file after line 138. The rest of the code is temporary to test this feature) . Sites as consumers would pass their languageMap as part of the config, and if they pass one then the region nav would map /ar/ to /es/. I personally like the simplicity of this approach and think would scale well to other use cases, such as us adapting the georouting for language based sites.
It also makes this feature opt in, giving peace of mind that things are not breaking for other consumers, and it leaves us flexilbity for how sites want their URLs to be mapped.

Issue Number 2
We are also using the federated global footer, and would like to keep using it if possible. One of the silliest issues though that we're having is that links such as adobe.com/ar/ in the federated region-nav are getting turned into relative links, because we do not have ar as one of our locales.
This means that all the urls with prefixes, that are not in our locale list, get turned into adobe.com/in on our migrated indian homepage.

Solution Number 2
Add #_dnt to every single link in the federated region nav. It doesn't hurt to have and means these links will not get localized.