Most storefront teams working on AI visibility have focused on one half of the problem: making conte…
Localisation vs. Translation: 14 Layers Storefronts Need
According to Shopify Plus' Global Ecommerce Playbook (2020), up to 75% of shoppers won't consider buying from a site that isn't in their language. 59% rarely or never buy from English-only sites. 67% prefer navigation and content in their own language.
The typical response from most e-commerce teams when they see these numbers: "Then we'll translate."
That's correct. And it's nowhere near sufficient.
The Playbook describes 14 layers that genuine localisation involves, translation is layer one. The remaining 13 layers are where internationalisation projects in mid-market companies typically fall apart: not from a lack of translation budget, but from a lack of architecture.
The 14 Localisation Layers, and Where Monoliths Break
The Playbook doesn't present them as a numbered list, but they emerge clearly from the use cases described throughout. Here they are, ordered by technical complexity:
Layers 1-4: Language and Text
- Translation of all content (product copy, metadata, confirmation emails, packing slips, invoices)
- Search misspellings: Australian shoppers on a US English site search for "colour" and find nothing. Your search function needs to know local spelling variants
- RTL layout support for Arabic-language markets, design decisions need to account for this upfront
- Checkout field labels: in Brazil, customers must enter their CPF tax number. In some countries the convention is "family name" rather than "last name"
Layers 5-8: Formats and Standards
- Address format per country: in Italy and Mexico, the house number comes after the street name. In Japan, most streets don't have names, the address system uses block numbers
- Shoe sizes and measurements: UK size 8 is EU 42, US 10, Japan 26.5. If you sell footwear and don't adapt this, you lose sales
- Date format, time zone, number format
- Form field length: international addresses are longer than domestic US addresses. "Field too short to fit the address" was one of the most common checkout errors according to Statista data referenced in the Playbook
Layers 9-12: Visual and Cultural
- Climate-appropriate hero imagery: a winter jacket model in snow makes no sense on an Australian site in December, it's summer there
- Cultural norms in imagery: which body postures are acceptable? Which colour codes carry cultural meaning?
- Reading pattern: the F-pattern scan is universal, but Arabic shoppers read right to left, a mirrored F-pattern. This affects where you place navigation, CTAs, and key information
- Local faces vs. Western models
Layers 13-14: Commerce Logic
- Currency and tax display: 92% cart abandonment without local currency (Shopify Plus Global Ecommerce Playbook, 2020). 16% cart abandonment without preferred payment method
- DDP vs. DDU at checkout, are you showing the landed cost including all duties and taxes, or does the customer receive a bill at the door?
The Monolith Problem: Every Layer Becomes a Manual Hardcode
In a monolithic commerce setup, each of these layers gets patched into the system individually. A template edit here, a conditional render there, a hardcoded currency rule in backend logic. This works for market one. For market two, it means: new template, new conditional, new backend change. For market three: the same steps again, plus regression tests because the changes may interact.
The Playbook describes the real consequence path: companies that expand internationally without building their storefront for localisation start a technical debt project. Instead of launching quickly into new markets, they get stuck in an endless loop of template patches, broken form fields, and manual currency rounding rules.
That doesn't scale. It doesn't produce a consistent brand experience per market. And it makes every additional market expansion more expensive than the previous one.
The Composable Pattern: Declarative Locale Configuration
A composable storefront with a properly built frontend management platform layer solves this structurally. Locale configuration is declarative: for each market, there's a configuration that describes which language, which currency format, which tax display, which payment method prioritisation, which address format applies. The frontend layer consumes this configuration, it renders it, it doesn't code it.
In practice, this means:
- A German brand expanding to Italy and Spain doesn't need to build two new frontend deployments. It configures two new locales
- Form fields adapt per locale: Italy gets the house-number-after-street-name format, Spain gets the correct postcode logic
- RTL layout for an Arabic market is a configuration option, not a layout rebuild
With Laioutr's Multi-Brand Multi-Market setup, this configuration logic is the core of the product. You see in the Studio how a locale switch affects the layout, checkout fields, and tax display, live, without deployment.
Practical Example: A German Brand Expanding to Italy and Spain
Consider a German D2C brand selling outdoor clothing. Home market: Germany. Next markets: Italy and Spain.
What needs to change?
Italy:
- Address format: Via Roma 15 instead of Römerstraße 15, house number after street name
- Tax display: 22% IVA must be visible at checkout
- Payment method: Bonifico bancario (bank transfer) is more relevant in Italy than in Germany
- Search variants: Italian shoppers search in Italian terms, not German or English translations
- Hero imagery: Mediterranean climate context, not alpine winter
Spain:
- Different postcode system
- 21% IVA
- Bizum as a local payment option is relevant
- Different holiday planning (Sant Jordi Festival in April rather than Valentine's Day)
In a monolith: 12-14 separate changes per market, spread across frontend templates, backend tax logic, payment gateway configuration, and CMS.
In a composable setup with FMP: two new locale configurations. The rendering logic reads them.
What This Means for Your Development Team
The time-to-market difference is not marginal. A typical monolith localisation project for a new market takes 6-12 weeks, requirements gathering, template work, QA, staging, release. An FMP-based locale setup takes days to weeks, depending on content translation and payment gateway integration.
The Playbook emphasises that the first market test should validate whether your brand resonates with international consumers. That requires the test to be fast and low-cost. If every new market means a three-month project, you're not testing, you're committing. That's a fundamentally different risk profile.
Checklist: Is Your Storefront Localisation-Ready?
Check these six points. If any of them is "no", you have a monolith problem:
- Can your checkout form dynamically restructure address fields per country, without a code change?
- Can your frontend switch to RTL layout per locale as a configuration?
- Are shoe sizes and measurement charts configurable per country, not hardcoded?
- Can your search system recognise locale-specific spelling variants?
- Are currency, tax display, and payment method prioritisation read from a configuration per locale?
- Can your marketing team swap hero images per market without dev involvement?
Six out of six "yes": your storefront is localisation-ready. If not: the gaps show you where your next technology project needs to go.
Further in This Series
The next post goes deeper into the commerce layer: multi-currency and multi-payment in the DACH context, why 92% of international shoppers abandon without local currency, and how a composable setup handles this without your team re-integrating every new payment method.
If you want to see what a live locale switch looks like in the Studio, with address format rendering, tax display, and payment prioritisation in real time, book a demo with the Laioutr team.
Source: Shopify Plus (2020). The Global Ecommerce Playbook: Map, launch, and scale internationally.
Related Insights
Related resources: Composable Digital Experience Platform and laioutr.com.