MWPW-200345 [Lingo] Split Adobe Home redirect into acomLocale + acomCountry

[vhargrave]

Follow-up to MWPW-194172 (#6100). Makes the post-sign-in Adobe Home redirect emit the Akamai/CCH param shape on Lingo pages, and drops the international cookie from sign-in region resolution.

Resolves: MWPW-200345

What changes

On Lingo pages the redirect is now …/home?acomLocale=<language>&acomCountry=<geoCountry>:

• acomLocale = the locale's ietf language (e.g. de-CH→de, fr-FR→fr, en-US→en). This correctly handles regional Lingo prefixes (/ch_de→de) and the international base site (/→en), which a path-prefix approach could not. Split tolerates the underscore ietf form (fr_FR→fr) that getLanguage synthesizes for language-first config rows.
• acomCountry = the user's geo country (uppercased/ISO-normalised via getCountry(), so uk→gb) — but only when that geo country maps to a valid region of the current page's base.

The base-region gate (the important part). A base locale like /fr only has a fixed set of regional variants — ca_fr, ch_fr, be_fr, lu_fr → countries ca, ch, be, lu. We only pass acomCountry when the user's geo is one of those:

• User on /fr in Switzerland → acomLocale=fr&acomCountry=CH (fr-CH exists).
• User on /fr in Germany → acomLocale=fr only (no fr-DE variant).
• User on /fr in France → acomLocale=fr only (France is the base, not a variant).

The gate is resolved the same way getLingoRegion resolves a region — including:

• Regional-variant pages (/ch_de): resolved against the variant's base (de, whose regions are at/ch/lu). Swiss user on /ch_de → acomCountry=CH; Canadian on /ch_de → acomLocale=de only.
• Aggregate regions via mepLingoCountryToRegion (africa, la, mena_en): a Kenyan on the root maps to the africa region → acomLocale=en&acomCountry=KE.

This matches the Akamai redirect shape (?acomLocale=…&acomCountry=…) so Adobe Home / CCH receives one consistent contract regardless of which path (sign-in vs. Akamai) produced the redirect.

Pre-Lingo pages are intentionally unchanged (lower risk): acomLocale stays the path prefix (the combined value we've always passed, e.g. lu_de) and no acomCountry is sent.

The international cookie is no longer consulted for sign-in region resolution — under Lingo it holds only the language (not a region), so region/country comes from the user's physical location (geo) only.

cn/sea still redirect to their locale homepage rather than /home (unchanged).

Code Changes (libs/utils/utils.js)

• getLingoRegion({ useGeoLocation }) — removed the international sessionStorage/cookie lookup from the geo path; with useGeoLocation: true the region resolves purely from geo. The region-matching logic (direct key + mepLingoCountryToRegion) is extracted into a shared helper resolveLingoRegionKey; behavior for existing callers is unchanged. The default (no-arg) path — used by getGeoLocalePrefix/MEP/content — is unchanged (still the selected-market country cookie).
• getBaseRegions / resolveAcomCountry (new, internal) — resolve the valid region set for the current page's base (a base locale uses its hydrated regions; a regional variant reconstructs its base's siblings) and return the geo country only if it fits that set.
• loadIms redirect_uri — acomLocale = isLingo ? locale.ietf-language : locale.prefix; acomCountry = resolveAcomCountry(...) (geo, gated on base fit). The SUSI widget display locale is still region-aware (lingoRegion.ietf) — only the redirect params changed. acomCountry reads geo from sessionStorage.akamai (already set by loadArea→setCountry; getAkamaiCode dedupes+caches), so there is no duplicate geo fetch, and it's only computed on adobe-home-redirect pages.

Behavior matrix

Page	Lingo?	Geo	Fits base?	redirect_uri
/fr	yes	CH	✅ ch_fr	/home?acomLocale=fr&acomCountry=CH
/fr	yes	CA	✅ ca_fr	/home?acomLocale=fr&acomCountry=CA
/fr	yes	DE	❌ no fr-DE	/home?acomLocale=fr
/fr	yes	FR	❌ base country	/home?acomLocale=fr
/ch_de (regional)	yes	CH	✅ base=de	/home?acomLocale=de&acomCountry=CH
/ch_de (regional)	yes	CA	❌ base=de	/home?acomLocale=de
/ (international)	yes	US	❌ base country	/home?acomLocale=en
/ (international)	yes	KE	✅ africa (mep)	/home?acomLocale=en&acomCountry=KE
/fr	yes	(no geo)	—	/home?acomLocale=fr
/lu_de	no (pre-Lingo)	—	—	/home?acomLocale=lu_de (unchanged)
/cn, /sea	any	—	—	/cn, /sea (unchanged)

Pairs with

• Akamai/CCH: acomCountry is consumed on the Adobe Home side (CCH — CCH-37414). Until CCH maps acomCountry to a display language, the visible CCH language may not change yet, but the redirect URL params are verifiable in the address bar.

Test URLs

Branch libs override: ?milolibs=vhargrave-lingo-acom-country--milo--adobecom

Test 1 — Canadian on /fr → acomLocale=fr&acomCountry=CA

• Before (stage): https://www.stage.adobe.com/fr/products/photoshop.html?akamaiLocale=ca
• After (branch): https://www.stage.adobe.com/fr/products/photoshop.html?akamaiLocale=ca&milolibs=vhargrave-lingo-acom-country--milo--adobecom

1. Sign in → land on …/home?acomLocale=fr&acomCountry=CA (CA fits the /fr base — ca_fr exists)

Test 2 — Swiss on /fr → acomLocale=fr&acomCountry=CH

• After (branch): https://www.stage.adobe.com/fr/products/photoshop-lightroom.html?milolibs=vhargrave-lingo-acom-country--milo--adobecom

1. Join Swiss/Basel VPN → Sign in → …/home?acomLocale=fr&acomCountry=CH

Test 3 — Geo that does NOT fit the base → language only

• After (branch): https://www.stage.adobe.com/fr/acrobat.html?milolibs=vhargrave-lingo-acom-country--milo--adobecom

1. Join a Germany VPN (or any country with no fr-XX variant)
2. Sign in → …/home?acomLocale=fr — no acomCountry, because Germany is not a region of the /fr base.

Test 4 — international cookie is IGNORED (geo wins)

• After (branch): https://www.stage.adobe.com/fr/acrobat.html?milolibs=vhargrave-lingo-acom-country--milo--adobecom

1. Join Swiss/Basel VPN
2. Open …/fr/acrobat.html#langnav, set region to Luxembourg – Français (writes international=lu_fr)
3. Sign in → …/home?acomLocale=fr&acomCountry=CH — the international pick is not honored; geo (CH) wins.

Test 5 — Pre-Lingo locale unchanged (no acomCountry)

• After (branch): https://www.stage.adobe.com/lu_de/acrobat.html?milolibs=vhargrave-lingo-acom-country--milo--adobecom

1. Sign in → …/home?acomLocale=lu_de (combined prefix, no acomCountry) — /lu_de isn't on Lingo, so behavior is unchanged.

Tests

• test/utils/utils.test.js — getLingoRegion (geo-only, international ignored) + loadIms redirect: ietf language on Lingo pages (incl. underscore-ietf split), regional prefix (ch_de→de), international base (/→en), and the base-fit gate: geo that fits (ca/ch on /fr, at/ch on /ch_de, ke→africa via mep) sends acomCountry; geo that does not fit (de/fr on /fr, ca on /ch_de, us on root) sends language only; plus no-geo and pre-Lingo unchanged (fr, lu_de, bare root).
• test/blocks/susi-light-login/susi-light-login.test.js — sign-in widget locale follows geo, ignoring the market and international cookies.
• Full npm test: green (the only failure is a pre-existing language-selector timing flake, verified to fail ~2/3 runs on clean stage).

[aem-code-sync]

Hello, I'm the AEM Code Sync Bot and I will run some actions to deploy your branch.
In case there are problems, just click the checkbox below to rerun the respective action.

• Re-sync branch

Commits

• fb36b3a ✅ (latest)
• dfe4370 ✅
• 8f49a3e ✅
• ba1eab5 ✅
• c25118c ✅
• 9fd25da ✅
• cd5e35d ✅

[vhargrave]

Shelving this for now: per Shane Do, acomCountry isn't a CCHome requirement yet (Akamai-only shipped today), so we're holding the acomLocale/acomCountry split. The low-risk half — dropping the international cookie — continues in #6298 (MWPW-200785). This PR is complete and linked on MWPW-200345; easy to reopen once CCH is ready to consume acomCountry.