Non Regional Domains

ie: support.disney.com/en-us - where language codes are mapping to regions instead (see apple.com)

Pros:

Fewer Domain Names / Certs
Zendesk OOB browser location will relocate users to correct domain
Easier for tech writers to manage localizations **
- Because English version will be available at all times, they can just select from dropdown to edit while in their current domain, vs having to change to a different domain to edit the other languages version.
Local Dev File structure will be cleaner ( less folders )
Less complicated gulp task
Less 404 / Redirect Issues on launch ** ( external partners linking to us, won't have to adjust current links, although they may still 404, it'll be on the correct domain ie: help.disney.com so they can navigate from there )
More complex hot fixes and smoke tests

Cons:

OOB Dashboards can't report on per language
Missing some "English" options, ie: EN-ME
Having to build a custom Language selector
Having to build a custom Region selector
Chance to max out on settings when a product is in many languages ** ( ie: 25 languages, with more than 4 settings each ) - we don't know if we will run into this, but calling it out for visibility
We would still require external JSON files to handle external links
Contact channels are shared between regions ( you cannot have them available for France, but not Germany ) **

Regional Domains

ie: support.disney.xx - where xx is the region code (see amazon.com)

Pros:

Not required to build custom language selector
Aligns with Disney.com
Can use OOB dashboards for site metrics
More settings per region (100 vs 4) **
No external JSON files required
More flexibility with "English" options, ie: EN-ME
Contact channels are not shared between regions ( you can have them available for France, but not Germany ) **

Cons:

** Important Items