Milo Commerce: IETF or geo?

[3ch023]

The topic of commerce concerns everyone so I open a discussion here.

Context

Milo Commerce (merch) needs to know the country and language of the page to fetch and render a price.
Currently, commerce is using the 'ietf' property of locales object, and splits the value by '-' into language and country.

Commerce Mapping ( geo <-> locale)

Some geo's are very specific, e.g. umbrella regions - sea,africa,cis. For them we can't use 'ietf' language tag, so Commerce has its own mapping.

const GeoMap = {
    africa: 'en-ZA',
    mena_en: 'en-DZ',
    il_he: 'iw-IL',
    mena_ar: 'ar-DZ',
    id_id: 'in-ID',
    no: 'nb-NO',
    cis_en: 'en-AZ',
    cis_ru: 'ru-AZ',
    sea: 'en-SG',
    la: 'es-DO',
};

Problem

All projects (milo,bacom,cc,dc,hompage) have locales, where 'ietf' contains only language, e.g. 'en'. In this case, Commerce is fetching a wrong price, because it will default to US country. For example, on bacom, in Egypt currently the wrong price will be shown.

Solution 1 - fix ietf

All projects fix their 'ietf' values to be suitable for Commerce.
cons: risky change, since many other features depends on 'ietf' values
pros: no mapping duplication

Solution 2 - extend Commerce Mapping

Stop depending on 'ietf' language tag to define a country for commerce.
Instead, we extend Commerce Mapping to include all geo's.

const GeoMap = {
    africa: 'en-ZA',
    ... all geos
};

Solution 3 - combination of 'ietf' + geo

Try to split 'ietf' first, if there is no country - split 'geo' prefix. I believe some team is using this approach but it won't work for us, because many projects have 'en_GB' as their 'ietf' for some countries, e.g. Milo

Solution x - please suggest

P.S. I prefer 2nd option but need input from others to make a final call.

[narcis-radu]

If there are multiple projects which need explicit language / country values, then it would make sense to add the properties in Milo and consuming projects. This way, the information would be available to all everyone, even if it would require multiple changes in every Milo and consuming project.
However, I think these properties are only required for Commerce (and maybe the Jarvis / Universal Navigation integration). It would make sense for Commerce to keep such a mapping, but this can also prove to be sensitive when we need to add support for new locales: engineers would need to make changes in Milo, consuming projects and Commerce. Since Commerce has an existing mapping, I think it makes sense to extend it and cover all possible values (option 2).
An additional argument in favour of having a mapping in Commerce instead of Milo is that certain umbrella regions are used with an invalid code. Milo uses these codes to populate the lang attribute, which would become invalid. If the mapping is in Commerce, the lang attribute would not be populated with invalid values.

[3ch023]

If there are multiple projects which need explicit language / country values, then it would make sense to add the properties in Milo and consuming projects. This way, the information would be available to all everyone, even if it would require multiple changes in every Milo and consuming project.

agree, this is why I reach out, to see who else (if anyone) needs the country to be present in the 'ietf'.

It would make sense for Commerce to keep such a mapping, but this can also prove to be sensitive when we need to add support for new locales: engineers would need to make changes in Milo, consuming projects, and Commerce.

yes, it would add 1 additional PR for commerce repo. But from commerce team standpoint it's not so bad, we will do this 1 PR and be sure that all 5 consumers have it working. With ietf we would need to reach out to each team separately to make sure they set a proper ietf, that will suit commerce. And if business will want ietf that will not suit commerce, we would still need a PR for commerce. So IMHO not that much overhead, its still simpler, to have mapping in 1 place than 5. And in our full control.

[overmyheadandbody]

I think IETF are quite difficult to standardise, each platform has a slightly different version of regions and locales and these might reflect in the URL as well. It's why most projects set up their own regions and why we can't have a universal region modal. I think solution #2 is the most straightforward with the least overhead.

[npeltier]

right, there are all those "dimensions" to take in consideration for one given page:

• which language to pick for a given geo/locale: often the later just show countries and "default" language is set by GeoMap, i think this is the same across all sites. This works as well for regions (umbrellas).
• which language code to pick for a given language, which as stated by Rares can differs depending on the platform. this i have the feeling we should try to fix in long term for sake of consistency, but we do need temporary solution as this will not happen quickly,
• which country (and language) code we use to send to our commerce systems, which is obviously needed when country is not one (umbrella region), and less obviously when language code we use does not correspond to country and language codes used by commerce. Same here, would be great to get consistency, but this will probably not happen quickly so we should need something

i guess i would be for solution x :p extending solution 2: if no entry set for one given geo in commerce map, pick country language code from geo, otherwise, take commerce entry. This way we can save a few bytes :)

[hparra]

@3ch023 My suggestion is any solution that avoids locales.

I did extensive work on this in Summer 2023. My attempts at solution 1 were blocked. I created a solution similar to 3 but reverted it when I solved my team's use-case in a very different way -- I still had to decouple gnav and caas from the value we needed.

Product leadership is now aware of this latest attempt to fix locales and I have been looped in again. I am preparing an overview doc that is still WIP but whose discovery process is about 70% complete: https://wiki.corp.adobe.com/display/seoteam/Milo+IETF+Technical+Debt. ETA is EOD 1/12.

This file is still a problem and will still be a problem for caas, commerce, gnav, and any other feature that depends on these values. My team and I do not have any vested interest in this file anymore, but I'm routinely pinged when an SDE wants to make a major change to it. My hope is that this document will be a final knowledge transfer of all the problems associated with locales and the challenges to fixing them.

[3ch023]

I am going to implement solution 2 for commerce.
With a small adaptation as suggested by @npeltier.
Commerce will have it's own mapping. This mapping will not include geos that consist of 'country_language' (e.g. 'gr_en'), since those are explicit and do not need a mapping.

To get country and language commerce will:

1. Take geo (locale.prefix)
2. Check if GeoMap, if it contains a mapping - use it
3. If no mapping in GeoMap - try splitting country and language for this geo ('gr_en') by '_'
4. if not successful - default as always to US