Ecommerce Internationalization: How to Prepare Your Store for Global Markets
Ecommerce internationalization explained: locale and market models, currencies, formats, languages, routing, content, APIs, data and storefront architecture.
Quick answer
Ecommerce internationalization means building the store so adding a market is configuration, not code. Separate market (currency, prices, availability, tax, delivery) from language, define locales with fallbacks and user override, store money as minor units with ISO currency codes, format numbers, dates and currencies with standard locale data, keep translatable content in structured fields, give each language or market version its own URL with hreflang, pass locale and market explicitly through APIs, and use Unicode everywhere. Then localization teams can adapt each market without engineering work.
Internationalization vs Localization
Internationalization (often abbreviated i18n) is an engineering concern: can the system represent many languages, currencies and formats? Localization (l10n) is a market concern: what should this market see? A store built without internationalization makes every new market expensive, because strings are hard-coded, prices assume one currency and URLs can't represent languages. The diagram above shows the four layers to get right. For the market-facing work, see ecommerce localization.
The Locale and Market Model
Most ecommerce stores need two related concepts. A locale defines language and formatting (en-GB, fr-CA). A market defines commercial rules: which countries it covers, currency, price list or catalog, tax and duty settings, shipping and payment methods. A market can have several languages; a language can serve several markets. Shopify Markets, for example, uses markets with conditions (countries and regions) and customizations such as currency, catalogs, domains and languages (Shopify Help Center).
| Concept | Determines | Example |
|---|---|---|
| Locale | Language, formats, text direction | fr-CA |
| Market | Currency, prices, availability, tax, delivery, payments | Canada |
| Fallback chain | What shows when a translation is missing | fr-CA → fr → en |
| Default locale | What shows without a signal | Store's primary language |
| User override | Visitor's explicit choice | Stored preference |
Formatting: Use Standard Locale Data
Number, date, currency and plural formatting rules are complex and vary widely. Use locale-aware libraries or built-in APIs (such as JavaScript's Intl APIs, which draw on standard locale data) rather than hand-written formatting. Store raw values and format at display time.
const price = new Intl.NumberFormat("de-DE", { style: "currency", currency: "EUR" })
.format(1234.5); // "1.234,50 €"
const date = new Intl.DateTimeFormat("en-US", { dateStyle: "medium" })
.format(new Date()); // US-style medium date, month name first
const items = new Intl.PluralRules("pl-PL").select(5); // "many"Money: Store Amounts Safely
Represent money as integers in minor units (cents, pence) together with an ISO 4217 currency code, never as floats or formatted strings. Keep prices per market or per price list, and record the currency, exchange rate (if converted) and rounding rule on every order. Refunds must use the original currency. See multi-currency ecommerce.
Routing and URLs
Give each indexable language or market version its own URL, using subdirectories, subdomains or country domains, and connect versions with hreflang. Google recommends different URLs for each language version rather than cookies or browser settings, and advises against automatically redirecting users between language versions (Google Search Central). Provide a visible market and language switcher, remember the visitor's choice, and suggest (rather than force) a version based on location. See international ecommerce SEO.
Rebuilding a store that was never designed for other markets?
ZSpace architects internationalized storefronts so each new market is configuration rather than a project.
Content and Data Model
Every customer-facing string should be translatable: UI text from message catalogs, product and content fields from the CMS or platform with per-language values. Structured product data (sizes with systems, dimensions with units, materials as controlled values) localizes better than free text. Decide which fields vary by market rather than language (legal text, promotions, availability).
| Data | Varies by |
|---|---|
| UI labels and messages | Language |
| Product title, description | Language |
| Price, currency | Market |
| Availability | Market |
| Legal and policy pages | Market (and language) |
| Size display | Market or language, from structured data |
APIs and Services
Pass locale and market explicitly on every request that returns content or prices, and include them in cache keys. Avoid services that infer locale from server settings. In headless Shopify builds, for example, the Storefront API accepts country and language context so responses return localized content and prices for that market. Webhooks and back-office integrations should carry market and currency on orders. See headless ecommerce architecture.
Text, Layout and Input
Use UTF-8 end to end. Design layouts that tolerate longer text (translations can be significantly longer than English), support right-to-left languages if you plan to serve them, and accept international names, addresses and phone numbers without over-strict validation. Search must handle each language's tokenization and synonyms.
- UTF-8 in database, APIs, emails and exports
- Flexible layouts for longer strings
- Right-to-left support if needed
- Name and address fields that accept international formats
- Search analyzers per language
Testing Internationalization
- Pseudo-localization to find hard-coded strings and layout breaks
- Formatting checks for numbers, dates and currency per locale
- Checkout with international addresses and phone numbers
- Hreflang and canonical tags per version
- Cache variation by market and language
- Orders, emails and refunds in the correct currency and language
Worked Example: Adding a Second Language and Market
An illustrative scenario: a store built for one market hard-codes English strings in templates, stores prices as decimals and assumes one tax rule. Before adding Germany, the team moves strings to message catalogs, converts prices to minor units with currency codes and per-market price lists, introduces a market model (UK and EU) separate from language (English and German), adds /de/ URLs with hreflang, passes market and language through APIs and caches, and switches formatting to Intl. The German launch then becomes mostly translation and configuration, and later markets reuse the same foundation.
Unicode and Text Handling
Use UTF-8 everywhere: databases, APIs, files, emails and search indexes. Test with accented characters, non-Latin scripts and right-to-left text. Check that search, sorting and filtering handle them correctly, that names and addresses aren't truncated, and that fonts include the needed characters.
- UTF-8 end to end
- Search and sorting tested with non-Latin scripts
- Right-to-left layouts supported where needed
- Field lengths allow longer names and addresses
- Fonts cover required character sets
Dates, Times and Time Zones
Store timestamps in UTC and convert for display in the customer's or market's time zone. Format dates by locale. Be careful with cut-off times, sale start and end times and delivery estimates across time zones, and with daylight-saving transitions. See localization for the adaptation that sits on top of these foundations, and translation vs localization.
Common Mistakes
- Hard-coded strings in templates and emails
- Money stored as floats or formatted text
- Language and market treated as the same thing
- Locale inferred silently from IP with no override
- Caches that ignore market and language
- Validation that rejects international names and addresses
Ready to internationalize your commerce stack?
Talk to ZSpace about internationalized storefronts and APIs and Shopify Markets and headless localization.
Conclusion
Internationalization is the groundwork that makes every market cheaper to add: a clear locale and market model, safe money handling, standard formatting, per-version URLs, structured content and locale-aware APIs. For how markets are configured on Shopify, see Shopify Markets.
Common questions
Designing and building a store's software so it can support multiple languages, regions, currencies and formats without code changes for each new market. It's the technical foundation that makes localization possible.