All insights

Localising an e-commerce store for Europe: language, currency and delivery

Translating the interface is the easy quarter of the work. The rest is pricing, delivery thresholds, address formats, tax and the URL structure you will be stuck with.

Integrations8 min read

Vowly Store ships across Europe and sells in English, French and German, with free EU shipping over €59 and country-specific rates below it. Paperly serves the German market with a €4.95 domestic rate. Those two sentences contain most of the categories of work that cross-border commerce actually involves.

Translation is the visible quarter

Interface strings are the part everyone plans for, and they are genuinely the smallest part. The work that gets underestimated is everything with a number or a name in it.

  • Dates, which are read differently in different markets and must never be ambiguous on an order confirmation.
  • Decimal separators — a price rendered as 14.95 to a German customer is wrong, even though it is legible.
  • Address forms, where field order, postcode format and whether a state exists all vary by country.
  • Name handling, where assumptions about character sets and about first-name-then-surname ordering both break.

Thresholds are business logic, not configuration

A free-shipping threshold looks like a setting. It is not; it is a rule with several genuinely ambiguous edges. Does the €59 apply before or after a discount code? Before or after tax? Does it count gift wrapping? What happens when a customer removes an item and drops below it — and does the interface tell them clearly enough that they will add something back?

The way to keep this sane is to implement the rule once, as a pure function from cart to shipping outcome, and to test it against a table of cases including every awkward one. Scattering it across a theme, a shipping app and a checkout customisation guarantees that the three will disagree eventually, and the disagreement will surface as a customer complaint rather than an error log.

Get the URL structure right the first time

Language and market URLs are close to irreversible. Changing them later means redirects, lost rankings and a long tail of stale links, so this is a decision worth spending a day on rather than an hour.

The pattern that causes the least trouble is a path prefix per language, one canonical URL per page per language, and a complete set of hreflang annotations that includes a self-reference and an x-default. The most common mistake we are called in to fix is a site where every localised page declares the homepage as its canonical — which tells search engines that the entire catalogue is a duplicate of the front page.

Currency and tax follow the customer, not the store

Displaying prices in the customer's currency raises the question of rounding. A price converted at the day's rate produces figures like €14.83, which look accidental. Most stores are better served by market-specific price points that are set deliberately and change rarely.

VAT rates vary by country and, for some goods, by category within a country. This is the area where using an established commerce platform earns its fee most clearly — the rules change, and keeping up with them is not a good use of a product team's time.

Support has to be localised too

A store that sells in three languages and answers support in one will feel broken to two thirds of its customers at exactly the moment they are most anxious — after they have paid. Localised order confirmations, shipping notifications and returns instructions matter more than a translated marketing page, because they arrive when something has gone wrong.

Related reading

Working on something like this?

We build and run the systems described here. Tell us what you are planning and we will give you an honest technical assessment.