Milo Commerce - Commerce Locale

[3ch023]

This discussion is to decide how we generate 'wcsLocale' value.

Details

'wcsLocale' is a required value to resolve a price or checkout link. Format: 'lang_COUNTRY', e.g. 'zh-hant_HK'.
'wcsLocale' is used:

• to provide 'language', 'country', and 'locale' properties when sending a request to Commerce API.
• to create an OSI (POST request to AOS), to search for an OSI (GET request to AOS)

In Dexter, 'commerce locale' is set as a separate property on the language node. An alternative solution was to reuse the 'lang' property. However, in Dexter 'lang' attribute could be modified by Content Authors and thus it was unstable and inconsistent to use for commerce.

In Milo, we want to reevaluate if the 'lang' attribute can be used to generate 'commerce locale'. 'lang' attribute in Milo is controlled by developers and can't be changed by Content Author, so we can be sure it is a unified stable value. We still will need a mapping though, see special cases below.

Special cases

• umbrella region mappings (For 'mena', 'en' should turn into 'en_ZA')
• country mappings (For Puerto Rico country should be 'US')
• language mappings ('zh-HK' -> 'zh-hant_HK')
• missing country (en -> 'en_SA')
• wrong country ('en-GB' -> 'en_IN')

Milo list of href locales

If we want to re-use 'lang' value, we need to make sure the country is always included. Additionally, we might need to define 2 mappings, one for the country and another for the language.

Alternatively, we could define a separate list of locales, but for commerce usage only.

[honstar]

In an ideal world, it'd be great if we could have a single list of locales where commerce would handle those special cases that you listed.

So +1 for re-using the existing list of locales in milo for commerce.

[auniverseaway]

FWIW, you don't necessarily have to use the lang attribute...

const { locale } = getConfig();

Will give you all locale information for a page.

[3ch023]

Cool, if no objections, we go with the option of reusing the locales.