INTERNATIONAL · MARKETS · SEO · 29 JULY 2025 · 8 MIN READ

Translation and localisation beyond currency

Switching the currency is the first ten per cent. The rest is menus, metafields, notification emails, size guides and the tags your filters are built on.

Localise in layers, and do the layers in the order a customer meets them. Currency and duties come first because they decide whether someone buys at all. Then the storefront language, on its own URL — Shopify serves published languages from subfolders such as example.com/de or subdomains such as de.example.com and adds the hreflang tags itself. Then the content your theme pulls from metafields and metaobjects, which is invisible to a translation pass that only covers products. Then the notification emails and SMS, which is where most stores quietly send German customers an English dispatch email for two years. And then the things translation cannot fix: size systems, address formats, imagery with English baked into it, and product tags, which Shopify’s documentation says cannot be translated at all.

IN SHORT

Shopify publishes each language on its own URL — a subfolder or a subdomain — and adds hreflang tags to language-specific URLs automatically, so hand-rolled hreflang is usually a source of bugs rather than a requirement.
All published languages are included in the store’s sitemaps, which is how the alternate versions get discovered.
A resource’s `tags` field cannot be translated. If your storefront filters are built on tags, they stay in your primary language whatever else you translate.
Metafields can be translated only if they are publicly accessible — which matters enormously if your page content lives in metafields and metaobjects.
Translations registered through the Admin API need the `translatableContentDigest` returned by the `translatableResources` query, so translations are tied to the exact source content they were made from.
Untranslated content falls back to the primary language, so a partial translation ships as a bilingual page rather than a broken one — which is useful, and also why nobody notices the gaps.
Human-translate the twenty pages that carry your traffic and machine-translate the long tail. Paying for a full human translation of four thousand product descriptions is the most common way to spend a localisation budget badly.

Language is not a market, and conflating them is the root of most of the mess

Two independent dimensions. A market is where you sell — the country or region that decides pricing, currency, duties, available payment methods and shipping. A language is what the store reads in. Switzerland is one market with three plausible languages; Spanish serves a dozen markets at different prices. Build a plan that assumes one language per country and the first exception rewrites it.

The useful consequence is that the two decisions can be sequenced separately. Opening a market is a commercial decision with a clear test — can we ship there profitably, can they pay in a way they trust, do they know what the total cost is at checkout. Adding a language is a content decision with an ongoing cost, because every page you publish from then on exists in one more version. Plenty of stores should open a market before they add a language, and English-language checkout in the Netherlands is a far smaller problem than a surprise customs invoice.

So the first question is not "which languages" but "which of these two things is actually blocking sales here". If the answer is the money, translation can wait a quarter.

The four layers, in the order a customer meets them

A localisation project that goes in this order tends to show a return at each step. One that starts with product descriptions tends to stall after the largest bill.

Money. Currency, local rounding, local payment methods, and the total cost at checkout including duties. This is the layer that changes conversion most and translation least.
The storefront. The language of the pages, on its own indexable URL, including navigation menu links — which are a separately translatable resource and are frequently missed because the theme keeps rendering the English ones without complaint.
The content your theme composes. Metafields and metaobjects, which on a well-built store hold most of the words on the page. A translation pass that covers products and pages and stops there will leave every block a merchandiser built in the primary language.
Everything after the order. Notification emails and SMS templates, order status, returns instructions, and support. This layer is invisible in every review and QA pass, because those all happen before anyone places an order.

What Shopify does for you, and what it explicitly will not

The platform handles more of this than most teams expect, which makes the exceptions worth knowing precisely.

URLs and hreflang. Published languages are served from language-specific URLs — the documentation gives subfolders such as example.com/de and subdomains such as de.example.com — and hreflang tags are added to those URLs automatically. All published languages appear in the sitemaps. This is the part people most often break by installing something that generates its own hreflang on top of Shopify’s.

Checkout and notifications. Checkout is translated by the platform for published languages, which is a large amount of copy you do not own. Notification templates, by contrast, are a translatable resource you do have to fill in.

Fallback. Untranslated content displays in the primary language. Nothing 404s and nothing renders empty, which is why an incomplete translation can sit in production for a year: it looks finished to anyone who does not read the second language.

Tags cannot be translated. The Admin API documentation is explicit that a resource’s tags field cannot be translated. This is the single most consequential limit in the list, because tags are what a lot of stores build their storefront filters and automated collections from. Translate everything else and your German customers still filter by waterproof and mens. If a filterable attribute needs to appear in a second language, it needs to be a product option or a metafield, not a tag — the same conclusion we reach for other reasons when [sorting out faceted navigation](/blog/faceted-navigation-without-wrecking-your-crawl-budget).

Metafields must be publicly accessible to be translated. Documented, and a genuine trap for a store whose section content lives in private app-owned metafields. Check this before commissioning translation of content you may not be able to install.

The primary locale cannot be changed through the API, and there is a documented ceiling on how many locales a store can enable and publish — 20 in the translation API reference, with the merchant-facing limit depending on your plan. Read the current figure before planning a thirty-language rollout.

How the translations get in, and why the digest matters

Three routes: Shopify’s Translate & Adapt app, CSV import and export, or a third-party app. All three write to the same place, so the choice is about workflow rather than capability.

The mechanism underneath is worth understanding even if you never touch it, because it explains a behaviour that confuses content teams. Translations are registered against a resource with a translatableContentDigest — a unique digest returned by the translatableResources query, representing the source content as it was when the translation was made. Change the English, and the digest no longer matches; the translation is now flagged as outdated rather than silently serving a translation of text that no longer exists.

That is the right behaviour and it has a process implication: every edit to primary-language copy creates translation work. A store that rewrites its product descriptions quarterly in English and translates into six languages has just created six times the work it thinks it has. This is the real argument for translating fewer pages properly rather than everything cheaply — the ongoing maintenance, not the initial quote.

One pattern to refuse outright: apps that translate the page in the browser by swapping text after load. It puts the translated content outside the HTML a crawler reads, gives every localised page the same URL as the original, and adds a render-blocking dependency to every page view. Translation has to be server-rendered at a distinct URL or it is decoration.

The parts translation does not touch

Assume the words are all correct. A significant list remains, and this is the part that separates localisation from translation.

Size systems. UK 10 is not EU 38 is not US 6, and a converted size chart is not the same as a chart drawn in the local system. This is a returns-rate problem, which means it is a margin problem.
Address and phone formats, and the order of the fields. Checkout handles this; your custom account pages and any address form you built may not.
Imagery with text in it. Every hero, badge and promotional tile with English baked into the pixels is untranslatable by definition. Plan artwork so the text is a layer of the page, not a layer of the image — and translate your alt text while you are there.
Units and formats. Dates, decimal separators, metric and imperial, paper and clothing sizes, and the week starting on a different day in a date picker.
Regional English. An adaptation, not a translation: colour and color, trousers and pants, VAT and sales tax. Shopify’s Translate & Adapt exists partly for this, and it is the cheapest localisation there is.
Delivery expectation and returns. "Next-day delivery" is a claim about a specific country. So is the returns address, and shipping a return across a border is a different proposition from posting one domestically.
Support. A translated storefront that answers enquiries in English sets an expectation it then breaks, which is worse than an honest English storefront.

Selectors, redirects and the one thing not to do

Give people a visible way to switch and never decide for them silently.

The localization object gives a theme everything a selector needs — available_countries, available_languages, and the currently selected country, language and market. Render it as a real form so the choice is a request the server answers, and put it somewhere findable: header on desktop, footer is acceptable, hidden behind a flag icon is not.

What not to do is hard-redirect a visitor to a localised URL based on their IP address. It breaks the link a customer was sent, it makes support impossible — nobody can look at the same page as the person they are helping — and it interferes with how alternate versions are discovered. A recommendation banner that says "Shopping from Germany? Visit our German store" with a dismissible option does the same job and keeps the URL the person clicked.

The subtler version of the same mistake is a language selector that throws away context, dropping a visitor onto the translated homepage from a product page. If the current page exists in the target language, the selector should go there.

What we would actually spend the money on

For a first proper rollout, in order, and deliberately less than most proposals.

Fix the money layer first — currency, local payment methods, duties at checkout. Measure it. This often removes the urgency from everything below.
Publish one language, not four. Pick the market with real demand and learn the maintenance cost on one before multiplying it.
Human-translate the twenty pages that carry your traffic — homepage, top collections, the policies, the bestsellers — and machine-translate the long tail with a plan to review what earns traffic.
Translate the navigation menus, the notification emails and the SMS templates. Place a test order in the second language and read every message it generates.
Audit what your filters are built on. If they are tags, decide now whether they move to metafields or options, because retro-fitting that later means rebuilding collections.
Leave hreflang alone. Shopify emits it; verify it in the rendered source and do not install anything that generates a second set.

Questions this raises

How do you localise a Shopify store properly?

In layers. Get currency, local payment methods and duties right first, because those decide whether people buy. Then publish the language on its own URL, translating navigation menus as well as products and pages. Then translate the metafields and metaobjects your theme renders content from. Then the notification emails and SMS. Finally handle what translation cannot: size systems, address formats, imagery with embedded text, units, and the tags your filters are built on.

Does Shopify add hreflang tags automatically?

Yes. Shopify serves published languages on language-specific URLs — subfolders such as `example.com/de` or subdomains such as `de.example.com` — adds hreflang tags to them, and includes all published languages in the store’s sitemaps. Verify it in the rendered source, and avoid apps that generate their own hreflang on top, because two competing sets is worse than none.

Can you translate product tags in Shopify?

No. The Admin API documentation states that a resource’s `tags` field cannot be translated. That matters because storefront filters and automated collections are often built on tags, so those filter labels stay in your primary language. If a filterable attribute must be localised, model it as a product option or a metafield instead.

Can metafields be translated?

Only if they are publicly accessible, per Shopify’s documentation. This is a real constraint on stores whose page content lives in metafields and metaobjects, because an app-owned private metafield holding a paragraph of copy cannot be translated. Check the access setting before commissioning translation of that content.

Is machine translation good enough for an ecommerce store?

For the long tail, usually yes, and paying to human-translate four thousand product descriptions is the most common way to waste a localisation budget. For the pages that carry your traffic and your policies, no — those need a human, because that is where a mistranslation costs a sale or creates a legal problem. Split the catalogue accordingly and review what starts earning traffic.

Should you redirect visitors to a localised store by IP address?

No. A hard redirect breaks shared links, makes support impossible because nobody can see the same page, and interferes with how search engines discover the alternate versions. Show a dismissible recommendation banner and let the visitor choose, and build the selector so it keeps them on the equivalent page rather than dumping them on a translated homepage.

How many languages can a Shopify store publish?

There is a documented ceiling and it depends on your plan — the translation API reference puts the limit at 20 enabled and 20 published locales. Check the current figure before planning, but the practical limit arrives earlier: every language multiplies the maintenance cost of every future content change, which is why one language done properly beats four left half-finished.

Free store audit

A senior Shopify engineer reviews your storefront, theme performance and checkout, then sends a prioritised list of fixes.

GET THE AUDIT