Un Sito Web in Dozzine di Lingue: i18n Pratica per l'E-Commerce

Internationalizing an e-commerce site beyond a handful of languages exposes every assumption embedded in a codebase that was built for one locale. The hardening work — the string extraction, the locale-aware formatting, the RTL layout adjustments — is well-understood in principle and deeply tedious in practice. What is less well-understood is the sequence of decisions that determine whether the result is a genuinely localized experience or an obviously machine-translated facade that happens to render in the correct script.

After working through this process for sites targeting dozens of locales, the most salient finding is that the technical implementation is the smaller part of the problem. The translation pipeline, the URL architecture, and the hreflang configuration are solvable engineering problems. The cultural adaptation work — understanding what makes a product page credible in Japan versus Germany versus Brazil — is where most localization projects fall short, because it cannot be automated and requires knowledge that is expensive to acquire.

URL Structure: The Decision That Cannot Be Changed Later

The URL structure for a multilingual site is the first decision and the hardest to reverse. Three approaches see meaningful use: separate domains per locale (example.de, example.fr), subdomain-per-locale (de.example.com, fr.example.com), and subdirectory-per-locale (example.com/de/, example.com/fr/). Each has consequences for SEO authority, deployment complexity, and operational overhead that are not equivalent.

Separate domains have the cleanest user experience and allow fully independent hosting per market, but they fragment domain authority: years of backlinks to example.com provide no benefit to example.de. For sites with established organic traffic, this is a significant cost. For new sites targeting markets where local TLDs carry trust signals, the calculation is different.

Subdirectory-per-locale is the approach most commonly recommended for sites consolidating SEO authority, and it is generally the right choice for e-commerce sites without a compelling reason to separate markets at the domain level. The tradeoff is that all locales share infrastructure, which means a deployment affecting one locale can affect all of them. For most teams this is an acceptable operational constraint.

The decision that matters most is making it consciously, early, and with full awareness of the SEO and operational implications — because the cost of changing URL structure after a site has accumulated inbound links and search indexing is high enough that the original choice tends to persist long after its weaknesses become apparent.

The Translation Pipeline

A translation pipeline for dozens of languages involves three distinct activities that are often conflated: initial machine translation to establish a baseline, human review to correct errors and adapt tone, and ongoing maintenance as the source content changes. Each has a different cost structure and a different quality ceiling.

Machine translation has improved to the point where it is a credible starting point for most Western European languages and a usable but more limited starting point for Japanese, Chinese, and languages with complex honorific systems. The output requires review regardless of quality — not because machine translation is systematically wrong, but because it consistently produces text that is technically correct and tonally wrong. Legal copy translated by a machine sounds like legal copy translated by a machine, which undermines the credibility that localized content is supposed to establish.

Maintaining translations across content updates is the operational challenge that expansion plans routinely underestimate. Updating the source content in one language triggers a translation debt for every other locale. Without explicit tracking of which translations are current, stale content accumulates invisibly — until a user in a non-English market encounters a product page with last year's pricing or a discontinued feature described as available.

The tooling choice — whether to use a translation management system, a flat-file approach, or a database-backed content management layer — should be driven by this maintenance workflow rather than by the initial translation volume. A flat-file approach that is fast to bootstrap becomes a liability at scale if it lacks the tooling to identify and prioritize translation debt.

hreflang: Implementation and the Common Failures

hreflang tags tell search engines which language and regional version of a page to serve to which users. The implementation looks straightforward in documentation: add a set of <link rel="alternate"> tags to each page, one per locale, with the correct BCP 47 language codes. In pratica, there are enough failure modes to make incorrect hreflang implementation the norm rather than the exception.

The most common error is incomplete hreflang sets. Every locale must reference every other locale — including itself — in its hreflang tags. A page that lists seven out of eight locales in its hreflang set will cause search engines to discount the entire set as malformed. Generating these tags programmatically from a single list of supported locales prevents this, but only if the list is maintained accurately as locales are added or removed.

The second common error is mismatched hreflang values: the tag on the English page points to /de/product-name but the German page's canonical URL is actually /de/produktname. This happens when slugs are translated (as they should be for SEO in markets where local-language keywords matter) without updating the hreflang references accordingly. Automated auditing — crawling the site and verifying that every hreflang tag resolves to a real, canonical URL — is the only reliable way to catch these discrepancies at scale.

The x-default hreflang value is frequently misunderstood. It does not mean "default language" — it means "for users who do not match any of the specific locale tags." For most sites this should point to the primary-language version, but for sites with locale selection pages or geolocation-based redirects, it may correctly point elsewhere.

RTL: More Than Flipping the Layout

Right-to-left language support — primarily for Arabic and Hebrew, and to a lesser extent Farsi and Urdu — is treated in most projects as a CSS problem: add dir="rtl" to the root element, flip flex directions, mirror padding and margin values, and call it done. In realtà, RTL support surfaces layout assumptions that are invisible until the layout direction changes.

Icon directionality is the most common oversight. Navigation arrows, progress indicators, and directional icons that point left or right have semantic meaning that should be mirrored in RTL contexts — a "back" arrow that points left in LTR should point right in RTL. The CSS transform: scaleX(-1) approach handles this mechanically, but requires auditing every directional icon in the UI to ensure it is mirrored only where appropriate.

Numeric formatting, phone numbers, and postal codes remain LTR even within RTL text — they are neutral-direction content that should not be flipped. Mixing LTR and RTL content within a single text block (a product description that includes a model number, for example) requires explicit Unicode bidirectional control or careful use of HTML dir attributes to prevent the browser's bidirectional algorithm from producing garbled output.

Cultural Adaptation Beyond Translation

Localization and translation are not the same activity. Translation converts words. Localization converts meaning — which requires understanding the cultural context that determines what a given message means to a specific audience.

The most commercially significant differences are in trust signals. What makes a product page credible varies substantially by market: German customers place weight on certification marks and technical specifications; Japanese customers on brand reputation and packaging quality; American customers on social proof and return policy visibility. A product page that converts well in one market may convert poorly in another despite identical translation quality, because the layout and emphasis optimize for the wrong trust signals.

Payment methods are another cultural dimension that is often handled as a technical integration rather than a localization concern. In Germany, bank transfer (Überweisung) and SEPA direct debit remain important purchase paths. In Japan, convenience store payment retains significant usage. Offering only credit cards and PayPal in these markets is not a localization failure in the translation sense — it is a localization failure in the practical sense of not meeting customers where they are.

The honest assessment is that most multilingual e-commerce sites are translated rather than localized. The text is in the right language; the experience has not been adapted to the market. For companies competing against native-market players, the gap between translation and localization is where organic conversion rate differences originate.

Approfondimenti Correlati

SEO Fixes That Actually Move the Needle: Canonicals, Sitemaps, and Trailing Slashes — the specific technical SEO changes that correlate with improved indexing and ranking for multilingual sites.
Astro i18n: Building a Nine-Language Static Site Without a CMS — the implementation details behind the i18n routing and translation system used on this site.
Our Shopify Exit Strategy: Evaluating Headless E-Commerce Alternatives — how i18n requirements influenced the decision to evaluate headless platforms as Shopify alternatives.