Adding a multi-language field to the backend takes an afternoon. The part that takes months sits in …
Internationalization in E-Commerce: The 9 Frontend Gaps No Backend Fixes For You
Adding a multi-language field to the backend takes an afternoon. The part that takes months sits in the frontend. Locale routing, hreflang, number formats, RTL layouts, payment methods, delivery promises and legal copy cannot be solved with a database flag, they are rendering decisions, layout decisions and content-modeling decisions made directly in the storefront. Teams that plan internationalization as a pure translation project run into a list of gaps nobody wrote down, usually right around the second market. This post is that list: nine concrete frontend gaps that recur at every market launch, with a frontend-level fix for each. Translation tooling and the choice between machine and human translation get only a brief mention here, we cover both in depth in dedicated posts linked below. Each of these gaps is solvable on its own, the trouble usually starts when teams tackle them in parallel without a shared schema decision, one team owns translation, another owns payments, a third owns legal copy, and nobody ends up owning the point where locale and content actually meet.
1. Locale routing and URL structure
The problem starts before any content renders: does a market live under a subdirectory, a subdomain, or its own ccTLD, and does the frontend resolve that structure consistently without duplicating the entire page tree per market? In practice, duplication grows exactly where routing and content locale stop referencing the same record, and every new landing page then has to be rebuilt by hand in every market version. The workable approach is a single component tree whose locale variant is resolved from the same content source at render time, not a forked set of templates per country. That is the practical reason to treat Multi-Brand and Multi-Market as a platform property rather than a per-country project build. For the locale tag itself, IETF BCP 47 already defines the format, tags like `de-DE` or `en-GB`, rather than inventing a custom shorthand that collides the moment a fourth market ships.
2. hreflang and canonical tags
According to Google's own documentation, hreflang only works as a reciprocal, self-referencing set: every language version must point to every other version, including itself, or Google may ignore the annotation partly or entirely. That is nearly impossible to maintain by hand once a fourth or fifth locale joins. If locale routing and content locale point at the same node, as described in gap one, the frontend can generate that reciprocal set automatically from a single source instead of running a separately maintained mapping table that goes stale the moment a new market ships. That set also needs an `x-default` entry for visitors whose language matches none of the shipped locales, otherwise which market version Google shows as a fallback is left to chance.
3. Content and copy translation in the frontend
Translation itself is one of the nine gaps, but it is rarely the one that stalls a project once schema and ownership are clear from the start. How TMS, PIM and component schema fit together is covered in depth in our post on the translation workflow between TMS, PIM and component schema. Whether a given content type tolerates machine translation or needs a human review step is a separate, per-field decision, which we walk through in the framework for machine versus human translation. For this list, the short version is enough: without a translatable flag per field and a stable reference key, each of the following six gaps gets harder to solve, because content and layout end up blocking each other.
4. Text expansion and layout stability
German and Finnish strings routinely run noticeably longer than their English source, and a component only ever tested against English word counts breaks reliably the moment the first long translation arrives. The fix is not a translation problem, it is a component-review step: every prop that accepts translated text gets a character budget and a defined wrap or truncation behavior, tested against a worst-case placeholder before any real translation exists. Fixed heights on buttons and labels are a bet an international storefront loses the moment a market with long compound words shows up. A German word like „Versandkostenfrei" is three shorter words in English, and a label container built only for „Free" has to either wrap or shrink its type, not truncate the text.
5. RTL languages and bidi rendering
Arabic or Hebrew are not simply right-aligned text, they flip the entire reading direction of the page: navigation, cart icon, form fields, slider arrows all mirror. The foundation for that is the Unicode Bidirectional Algorithm, which defines how mixed left-to-right and right-to-left text resolves within the same paragraph. A frontend that defines spacing and alignment with `margin-left` instead of logical CSS properties like `margin-inline-start` has to maintain a separate style branch for every RTL locale. Teams that build on logical properties and the `dir` attribute at the component level from the start effectively get RTL for free the moment the first Arabic or Hebrew locale goes live. A simple test: open the storefront once with `dir="rtl"` set on the root element and see which icons and spacing stubbornly stay left instead of mirroring.
6. Currency, number and date formats
A price, a date and a phone number look different in every market, decimal separators, thousands separators, date order and currency position all vary independently of the language itself. The Unicode CLDR standard collects exactly these locale-specific formatting rules, and standard APIs like `Intl` build directly on top of it. The problem starts the moment formats get hardcoded into a template or delivered from the backend as a finished string, instead of being computed at the component boundary from a raw value plus a locale. The moment a new market joins, every affected component then needs its own patch instead of the locale resolution simply carrying through. A price shown as "€1,234.56" in one market and "1.234,56 €" in another is not an edge case, it is the default the moment decimal and thousands separators swap roles, and that is exactly what CLDR exists for, not a homegrown formatting function per team.
7. Market-specific payment methods at checkout
iDEAL is the default in the Netherlands, Klarna dominates parts of Scandinavia, Bancontact matters in Belgium, and in other markets none of those options are relevant at all. A checkout frontend that hardcodes its payment method list instead of loading it as configuration per market turns every new payment method into its own deploy. The more resilient approach is a checkout component that pulls payment methods as market-level configuration from the Growth Kit for Checkout rather than anchoring them in component code, so a new provider becomes a configuration entry instead of a release. This is not just about which payment icons show up either, it also covers which provider is preselected as the default, since that ordering by itself moves conversion per market.
8. Delivery promises and shipping logic per market
A delivery promise that is accurate in the home market shifts in the next one because of customs, VAT thresholds, or simply different carrier lead times. If the shipping line in the frontend lives as static template text instead of a data-driven block tied to shipping zone and warehouse, every new market gets an incorrect promise on the product page until someone corrects it by hand. This belongs in the same category as price and payment method: a frontend component that resolves locale and shipping zone together instead of maintaining them separately. For commerce teams orchestrating exactly that across multiple markets, it is the core case among our e-commerce solutions. Customs rules and threshold values also change regularly per market, which is why the shipping line deserves a content field with an editorial process behind it, not a constant baked into the source code.
9. Legal copy per market
Imprint, terms and withdrawal-rights language differ between Germany, Austria, Switzerland and France in wording and sometimes in substance, and a single globally rolled-out legal template is very likely wrong in at least one market. That is not purely a frontend problem, but the frontend decides whether legal copy is treated as versioned, market-specific content objects or as a hardcoded page nobody updates again once the launch is done. Legal copy belongs in a content management structure with clear market assignment and version history. Note that this is a statement about content architecture, not legal advice, the actual requirements per market are a question for your legal counsel.
Where this fits into the frontend
None of these nine gaps gets solved by a single tool, they are all expressions of the same underlying question: where does the decision live about what differs per market, and where does the decision live about what stays the same everywhere? Under our Composable Headless Frontend architecture, routing, formatting, payment configuration and legal content run through the same component layer instead of nine separate per-market workarounds. How much local trust actually moves revenue in international storefronts is a separate question we cover in the post on local trust in international storefronts.
Frequently asked questions
Do we need to solve all nine gaps before launching a new market? No. Locale routing, hreflang and the translatable flags in the schema are the foundation the other six gaps build on. Payment methods and shipping logic can often be added market by market once that schema decision is solid.
Is RTL only relevant if we are actively expanding into RTL markets? For most teams, not in the short term. But using logical CSS properties instead of physical ones costs nothing extra up front, while retrofitting them later becomes its own refactoring project.
Does this post replace a legal review of our market-specific copy? No. Gap nine describes how legal copy should be organized in the frontend as a content structure, not which wording is legally correct in a given market. That stays your legal team's call.
Next steps
If you are building out a second or third market and noticing that locale decisions are scattered across your frontend, book a 30-minute demo. We will look at your current locale structure and show which of these nine gaps is most urgent for you.
More from the Laioutr platform
About the author: Marcel Thiesies is Co-Founder of Laioutr and works on how internationalization actually scales in the frontend, beyond the single translation ticket.