Ecommerce localization is adapting an online store and its product catalog to a specific market, so a shopper there sees the language, units, sizes, currency, payment options, legal text, images and search terms they expect. Translation is one part of it. A Dutch kettle listing translated into flawless English still fails in the UK if the photo shows a plug that does not fit British sockets and the price is in euros.
The short answer for most stores: localize in two layers. Website localization covers the storefront, checkout, emails and legal pages, and you do it once per market. Catalog localization covers every product record: titles and descriptions in local search terms, converted units and sizes, market-specific variants, prices with local endings, and compliance text in the local language. The catalog is where most of the work and most of the mistakes sit, so this guide spends most of its time there, with a worked example of one product localized for four markets.
Translation, internationalization and localization are three different jobs
The terms get mixed up in project plans, which is how budgets end up covering only the first one.
- Internationalization (i18n): building the store so it can support more than one locale at all. Separate fields per language, prices per currency, units stored as structured values, templates that do not break when German words run much longer.
- Translation: turning text from one language into another. It is necessary and it is the easiest part to buy.
- Localization (l10n): deciding what the shopper in one market should see and adapting everything to it, including things that are not text at all, such as which variants you offer, which plug a kettle ships with and how a price ends.
A store can be fully translated and barely localized. The reverse also happens: a UK and an Irish store share a language but still need different currencies, VAT handling and delivery promises. For the bigger picture of entering a new country, from choosing markets to VAT and shipping, see our international ecommerce guide. This post covers the localization work itself.
Website localization: the storefront layer you set up once per market
Website localization is the part most guides describe. It is finite: once a market is set up, it changes rarely. The items to cover:
- Navigation, templates and microcopy: menu labels, filter names, buttons, error messages and empty states. Untranslated system strings such as "Add to cart" on an otherwise German page are the most visible sign of a half-done job.
- Number and date formats: 1,299.00 in the US is 1.299,00 in Germany and the Netherlands. 03/04 is March 4 for an American and 3 April for most Europeans, as the W3C internationalization guidance points out. Delivery dates and best-before dates must follow the local format or spell out the month.
- Currency display: symbol position and spacing differ (€ 24,95 in Dutch, 24,95 € in German and French). Your platform usually handles this per locale, but check custom templates and feeds.
- Checkout, emails and invoices: order confirmations, shipping notifications and return labels in the local language, with local address formats and phone prefixes.
- Legal pages: terms, privacy, returns and imprint pages adapted to local law, not just translated.
- Customer service: at least the contact page and FAQ in the local language, plus honest information about which languages support can answer in.
URL structure and hreflang also belong to this layer. They are covered step by step in our multilingual SEO playbook, and the hreflang generator writes the tags for you.
Catalog localization: where a store's real localization work sits
The storefront has a few hundred strings. The catalog has a few thousand products, each with 20 to 60 fields, many of which change per market and not only per language. That is why the product record, not the theme, decides how long a market launch takes and how many returns it causes.
The sections below cover the catalog fields that need more than translation: units, sizes, variants, prices, legal text, images, tone and search terms. Each one has a structured fix that works across thousands of products, because doing it by hand in description text does not scale and cannot be checked.
Units and measurements: convert the value, not just the label
A product that is "30 cm" in the Dutch store is "11.8 in" in the US store, and a 750 ml bottle is 25.4 fl oz. Two problems show up in almost every catalog that grew without a plan:
- Units hidden in text. "Ø 28cm pan, 2,4L" in the title is fine for one market and wrong for the next. Store diameter and capacity as separate numeric attributes with a unit, then build titles and spec tables from them per market.
- Labels changed, values not. A bulk edit that relabels "kg" as "lb" without multiplying by 2.2046 produces products that are suddenly less than half their real weight. Convert the number and round it to a sensible precision for the target unit.
Unit prices are the other half. In the EU, EFTA countries, the UK, Australia and New Zealand, Google Merchant Center requires the `unit_pricing_measure` attribute for products sold by weight, volume, length or area, because local rules require shoppers to see a price per unit. A 250 g bag of coffee beans at €8.95 is shown as €35.80 per kg. That only works when net quantity is a clean field (250, g) instead of a phrase inside the title.
Sizes, plugs and variants that change per market
Some localization changes the product itself, not its description. These are the cases that cause returns rather than just lost clicks:
- Clothing and shoe sizes: EU, UK and US shoe sizes use different scales, and brand conversion charts disagree with each other. Store the size system as part of the value (EU 42, UK 8) and publish a size chart per market.
- Bedding and furniture dimensions: a Dutch duvet cover of 140 x 200 cm has no exact US equivalent, and US shoppers search by twin, full, queen and king. Map your dimensions to the local size names instead of translating the centimeters.
- Electrical products: plug shapes and mains voltage differ between countries, and the IEC counts more than a dozen plug types in use worldwide. A kettle for the UK or US market is often a different SKU with a different plug or a different build, not a translated listing. Your catalog needs a market or region attribute on the variant so the UK store never shows the EU plug version.
- Variant availability: colors, pack sizes and bundles that sell in one market may not exist in another. Assortment per market is a localization decision, and the product feed must reflect it.
Currency, VAT display and price endings per market
Converting a price is arithmetic. Localizing it is a pricing decision. Platforms can convert automatically: Shopify multiplies the price by the exchange rate, adds its conversion fee and then applies rounding for the currency, so $10.00 can become €8.85. That keeps prices in sync with exchange rates, but it also means prices move when rates move.
Many stores set fixed prices per market instead, for three reasons:
- Price endings: €24.95, £22 and $27.99 each look normal in their own market. A converted €21.37 looks like a mistake.
- Tax display: consumer prices in the EU and UK include VAT; US prices are shown before sales tax. The same product needs a different displayed price logic, not just a different number.
- Margins per channel: a marketplace fee or higher shipping cost in one country should change the price there without touching the base price in your catalog.
Whatever you choose, store prices per market or derive them with explicit rules, and never type a currency into a description. "Only €19,95!" in a translated description is a common leftover that contradicts the real price on the page.
Legal, returns and warranty text in the local language
Legal text is where a word-for-word translation of your home market is most likely to be wrong. Some examples for EU stores:
- Right of withdrawal: EU consumers can cancel an online purchase within 14 days without giving a reason, counted from delivery for goods. If your US store offers 30 days, do not translate that promise into the EU pages, and do not translate a shorter home-market policy into a market where it is unlawful.
- Legal guarantee: EU consumers have a minimum 2-year legal guarantee, and some countries go further. A product page that says "1 year warranty" needs to make clear it is a commercial warranty on top of the legal guarantee, not instead of it.
- Safety warnings, ingredients and care instructions: these often must appear in the official language of the country where the product is sold. Keep them as separate structured fields so they can be checked per language, rather than as a paragraph at the end of the description that a translator might shorten.
Treat legal text as reference content owned by one person, translated once and reviewed by someone who knows the local rules, then reused across products. Do not regenerate it per product.
Images, tone of voice and cultural fit
Shoppers look at images before they read, so an image that belongs to the wrong market undoes good copy.
- Text baked into images: infographics with Dutch callouts, "NIEUW" badges and size labels in centimeters need a version per language, or better, no text in the image at all.
- What the photo shows: the plug on the kettle, the keyboard layout on a laptop (QWERTY, AZERTY in Belgium and France, QWERTZ in Germany), the steering side of a toy car. Shoppers notice.
- Seasons and context: a summer campaign image in Australia runs in December. Lifestyle shots that fit one culture can feel off in another.
- Form of address: German product copy often uses the formal Sie, while Dutch ecommerce copy almost always uses the informal je. Pick one per market, write it into your style guide and apply it to every field, including microcopy and emails.
- Humor and wordplay: puns rarely survive translation. Write the selling point plainly in the source language and let each market rephrase it.
Local search terms: the same language can use different words
A translation can be correct and still use a word nobody searches for. Shoppers buy in the words they type, and CSA Research found 76% of consumers prefer to buy products with information in their own language and 40% never buy from websites in other languages. Their own language includes their regional vocabulary:
- US and UK English: sneakers and trainers, pants and trousers, sweater and jumper, flashlight and torch, stroller and pushchair.
- Dutch in the Netherlands and Flanders: koelkast and frigo, mobiele telefoon and gsm, stofzuiger in both but different brand and product naming habits in each.
- German in Germany, Austria and Switzerland: spelling (Switzerland does not use ß) and some product words differ, so a German-only catalog works but rarely ranks as well in Switzerland or Austria as locally checked copy.
The fix is a terminology list per market: the source term, the preferred local term and terms to avoid, applied to titles, attribute values and filters. Keyword research per language, not per translation, is explained in the multilingual SEO playbook. How well a machine translation engine follows such a glossary, and whether it can switch between formal and informal address, differs per engine; we compared them in DeepL vs Google Translate for product catalogs.
Worked example: listing a Dutch 1.7 liter kettle in Germany, Belgium, the UK and the US
A Dutch kitchenware store sells a stainless steel electric kettle and wants to list it in Germany, Belgium, the UK and the US. Here is the same product as four records.
One 1.7 liter kettle as five market records
| Netherlands (source) | Waterkoker RVS 1,7 liter, 2200 W | Source SKU, plug type C/F; capacity stored as 1.7 with unit l, power as 2200 W | €39.95 including 21% VAT | Je-form copy; 2-year legal guarantee mentioned in the returns block |
|---|---|---|---|---|
| Germany | Wasserkocher Edelstahl 1,7 l, 2200 W | Same SKU and plug; decimal comma kept | €39.95 including German VAT, so the margin differs from the Dutch price | Sie-form copy; safety instructions in German as a separate field |
| Belgium | A Dutch record checked for Flemish usage, plus a French record: Bouilloire électrique inox 1,7 l | Same SKU and plug | Photos must not show Dutch-only text, because French-speaking shoppers see them too | |
| United Kingdom | Stainless Steel Electric Kettle, 1.7 Litre, 2200W | Different SKU with a UK plug | £34.99 including VAT | British spelling; photos showing the UK plug |
| United States | Stainless Steel Electric Kettle, 1.8 Quart (1.7 l is about 1.8 US quarts) | Different SKU, built for US mains voltage, with its own wattage on the spec sheet | In dollars, before sales tax | US-specific warranty text |
Two takeaways from this one product. First, three of the five records are different SKUs, so localization starts in the product model, not in the translation queue. Second, almost every difference is a field (capacity, unit, plug, voltage, price, guarantee text), which means it can be generated, converted and checked in bulk once the data is structured.
Per-market localization checklist for a catalog launch
Run this list for every new market before the first product goes live:
Catalog localization checklist per market
Localizing thousands of SKUs without a spreadsheet per country
Localization at catalog scale only works when each product lives in one record with fields per language and per market, instead of a separate spreadsheet per country. WISEPIM is built around that record. Its AI translation, which is 95%+ accurate, works per field and follows the terms in your translation dictionary; bulk edits convert units across thousands of products; and pricing rules adjust export prices per channel without touching the base price. Tackerplein used it to get German translations live in 6 weeks instead of the 4 to 6 months an agency quoted, and saved EUR 45,000 (read the case). See how translating products with AI works, or how WISEPIM supports multilingual ecommerce.
