Markets & localization

The country/language switchers are <change-country> and <change-language> - pickers that consume storeContext, so each needs a <storesynk-store> ancestor (SSK-101). They have two author-detected modes (like change-option): select (default - an adopted/auto-created native <select>) and template/pill (a first-child <locale-value> cloned into a keyboard radiogroup). They dispatch sf:country-change / sf:language-change up to <storesynk-store>, which owns the switch (re-prices the cart’s buyer identity, rebuilds the money formatter, re-provides context, and emits sf:locale-change).

My pill/flag locale picker renders nothing (but a <select> version works)

Pill mode is opt-in via a template child: the picker only builds a pill radiogroup when its first child is a <locale-value>. With no <select> and no <locale-value>, the picker falls back to auto-creating a <select> - so a pill design that’s missing (or misspelled) its <locale-value> template silently becomes an empty select instead of your pills. Confirm the <locale-value> is a direct first child of the picker (its parent element becomes the pill list), with <show-locale-name> (and, country-only, <show-locale-currency>) leaves inside it - a leaf outside any picker trips SSK-108. (Detection order: a <select> beats a <locale-value> beats auto-create, so don’t put both in the same picker.)

My <change-country> / <change-language> renders nothing

Two by-design cases before you suspect a bug. First - most common - it’s a single-market shop: with ≤1 country (or ≤1 language for the active country) the picker sets [hidden] + [ss-empty] and shows nothing, because there’s nothing to pick. That’s expected; the pickers are safe to leave in a store that only later becomes multi-market. Second, the localization query loads lazily on mount and is memoized - if it failed (a network error), the picker stays empty and a retry happens on the next mount; confirm the store booted with valid credentials. If neither applies, check the pickers actually sit inside <storesynk-store> (SSK-101) - outside it there’s no store context and they render nothing, silently.

The country picker shows options but no currency

<change-country> only appends the currency (e.g. “Germany (EUR €)”) when you add the show-currency boolean attribute. Without it the option text is just the country name. (show-currency is country-only - there is no such attribute on <change-language>; authoring it there trips SSK-201.)

Prices don’t switch currency after the buyer changes country

The built-in money displayers (show-price, show-cart-total, show-line-price, …) route through the store’s context-aware formatMoney, which the store rebuilds on every locale switch (shop-currency amounts keep the merchant moneyFormat; a foreign presentment currency is formatted via Intl). So if a price won’t switch, it’s almost always a hand-rolled price that reads the raw amount itself instead of using a show-* displayer - replace it with the displayer so it re-renders on sf:locale-change. (A custom <show-data money> also formats through the same context.)

The cart still shows the old currency after a country switch

On a country change the store calls the cart’s updateBuyerCountry, which re-prices the existing cart via a buyer-identity update and re-syncs it through the standard shopify:cart:lines-update event. A cart that stays in the old currency was usually created before the buyer-identity feature existed (a stale _storesynk-cart-id in localStorage) - clear that key (or the cart) so the next add creates a fresh, correctly-contextualized cart. This is Shopify-side cart state, not a markup problem the validator can see.

My locale choice isn’t remembered between visits

<storesynk-store persist-locale="…"> controls this: localStorage (the default, key _storesynk-locale), cookie (storesynk_locale=<COUNTRY>/<LANGUAGE>, readable by an SSR server), or none (don’t persist). If a choice never sticks, you likely set persist-locale="none"; if you need the server to read it (for SSR market pricing), use cookie. A persisted choice overrides the country/language attributes at boot - so if the picker opens on a different market than the tag’s country, a remembered choice is winning (by design).

---

Imported from the Storesynk skill v0.1.0 (references/known-issues.md). To change this page, change it there.