en-GB / en-US / en-AU (etc.) as selectable language variants, consistent with how Chinese regional variants are already supported, so merchants can manage regionally-adapted English content the same way they manage other localized languages.
You are right that you cannot add a second English. Shopify allows one core English locale and the admin will not let you create another one alongside it.
The adaptation part already exists though, just not as a separate language. In Translate & Adapt you pick a market and edit the English content for that market specifically. Shopify’s own example is a US market showing Sweaters and a UK market showing Jumpers off the same base entry. So regionally adapted English is doable today, it is just keyed on the market rather than on a locale code.
Doing that entry by entry is miserable at any real catalogue size. The bulk path is Settings then Languages then Export. The CSV that comes out has a Locale column and a Market column. Keep Locale as en, put the market name in the Market column, run find and replace on the spellings, then import it back. If you would rather script it, the Translation API takes the same locale plus market pair.
What I think is genuinely missing, and worth narrowing your request down to, is the shopper facing side. Because both markets are still en, the language selector only ever shows one English, so someone who lands in the wrong market cannot switch copy the way they can flip between zh-CN and zh-TW. I have not checked what hreflang Shopify emits when two markets share en, which is worth confirming before you file it, since that is the part that would actually justify a separate locale code.
Hey @Ozkan_Kaya, regionally-adapted English already works today through market-level content adaptation. You add English once as the language, then each market carries its own wording on top of the same locale, so your UK market can say Jumpers where the US one says Sweaters. In Translate & Adapt, open the content you want to change, hit More actions > Localize, pick the market and enter the market-specific text. The catch that trips most people up is that you can only customise content in languages already added to that market, so attach English to the UK market first, then reload Localize and check the UK option actually shows up.
Appreciate the detailed breakdown, and you were right to have me check hreflang first, that part is actually clean, en points to .com and en-GB points to .co.uk correctly. The real issue I’m running into is narrower than hreflang: market-level Localize overrides content on top of the same en locale, but it doesn’t touch locale-derived fields like URL slugs. When I add German as an actual language, slugs regenerate for that locale automatically. With two markets sharing en, the slugs stay identical across .com and .co.uk no matter what I override in Localize, only the visible copy changes. That’s the part that still points to needing en-GB as its own locale rather than a market override, since it’s the underlying URL structure that reads as duplicate to Google, not just the on-page text.