Your product catalog is the backbone of your online store, but the moment it crosses a border, it fractures. Sizes don't match, units confuse buyers, search returns irrelevant results, and reviews sit untranslated, each gap silently eroding conversion. According to CSA Research, the vast majority of online consumers prefer to buy in their native language, and a significant share will not purchase at all from English-only pages. The challenge isn't just translation; it's building a localization system that spans catalog attributes, on-site search, user-generated content, marketplace feeds, checkout flows, and legal compliance, all without ballooning costs or fragmenting brand voice. This guide walks through every layer of that system, from product data modeling to measuring conversion lift, so you can design a catalog-to-checkout localization pipeline that actually scales.
If you're already wrestling with multi-market catalog complexity, schedule a walkthrough with Ollang's localization team to see how an AI execution layer handles these workflows end to end.
Catalog and Attribute Data Models
Structuring Multilingual Product Attributes
A well-localized catalog starts with the data model. Every product attribute, title, description, material composition, color name, feature bullets, needs to exist as a locale-aware field, not a single string that gets overwritten. The cleanest approach is a base-locale-plus-override architecture: you author in a source language, then maintain per-locale overrides that inherit from the base when no translation exists.
Key structural decisions include:
- Attribute typing: Distinguish between translatable text fields (descriptions, marketing copy) and non-translatable fields (SKU, GTIN, weight in grams). Mixing these wastes translation budget and introduces errors.
- Enumerated values: Colors, materials, and categories should use controlled vocabularies mapped to locale-specific display names. "Navy" in your taxonomy renders as "Bleu marine" in fr-FR and "Marineblau" in de-DE, but the underlying value stays constant.
- Rich content blocks: If your PDPs include embedded HTML, markdown, or JSON-based content modules, your localization pipeline must parse and translate the text nodes without breaking the structure.
Product Information Management (PIM) systems like Akeneo or Salsify support locale dimensions natively, but the real challenge is keeping translations synchronized when source content changes. A robust system flags stale translations automatically and routes only deltas for re-translation.
Size, Fit, and Unit Conversions
Size and unit mismatches are among the highest-friction points in cross-border e-commerce. A US men's shoe size 10 is a UK 9.5, an EU 44, and a JP 28, and getting this wrong drives returns.
Effective localization requires:
- Locale-specific size charts that map your internal sizing system to the local standard, displayed dynamically based on the shopper's detected or selected locale.
- Unit conversion for dimensions and weight: Display centimeters and kilograms in metric markets, inches and pounds in the US. This applies to product specs, shipping estimates, and packaging dimensions.
- Fit guidance localization: Phrases like "runs small" or "true to size" carry nuance. These need human-quality translation, not just word-for-word conversion, because fit language directly influences purchase confidence.
Store the canonical measurement in a single unit system (metric is standard) and convert at the presentation layer. Never store converted values as source data, rounding errors compound.
Compliance Labels and Regulatory Content
Every market imposes its own labeling requirements. The EU requires CE marking, REACH compliance disclosures, and energy labels. California demands Prop 65 warnings. Japan mandates specific textile care labeling under JIS standards. These aren't optional marketing copy, they're legal obligations.
Your catalog model should include:
| Content Type | Examples | Localization Requirement |
|---|---|---|
| Safety warnings | Prop 65, CE, UKCA | Market-specific text, legally reviewed |
| Care instructions | Wash symbols, textile composition | Translated per local regulation |
| Ingredient/material lists | Cosmetics (INCI), food allergens | Locale-mandated format and language |
| Energy/efficiency labels | EU Energy Label, FTC EnergyGuide | Locale-specific visual + text |
| Age/usage restrictions | Toy safety, electronics | Translated warnings, sometimes icon changes |
Compliance content should be managed in a separate translation memory with legal review gates. Machine translation alone is insufficient here, regulatory text requires domain-expert validation.
Image Text Overlays and Alt Text
Product images often contain embedded text: size callouts, feature annotations, promotional badges ("Best Seller," "New Arrival"), and instructional overlays. Each of these needs localization, which means either:
- Maintaining layered source files (PSD, Figma) with text on separate layers that can be swapped per locale, or
- Using dynamic image rendering services that overlay translated text at serve time.
The second approach scales far better. Services like Cloudinary or custom CDN pipelines can composite locale-specific text onto base images without manual design work per market.
Alt text is equally critical. It serves both accessibility requirements (WCAG compliance) and image SEO. Alt text should be translated with the same care as product titles, it's indexed by search engines and read aloud by screen readers. Generic alt text like "product image" wastes a ranking opportunity in every locale.
SEO Architecture for Localized Storefronts
Hreflang Implementation and Common Pitfalls
The hreflang attribute tells search engines which language and regional version of a page to serve to which audience. Getting it wrong means your German page competes with your Austrian page, or Google ignores your locale pages entirely.
Core rules:
- Every page must include hreflang annotations pointing to all its locale variants, including itself.
- Use the x-default value to specify the fallback page for users whose locale isn't explicitly covered.
- Hreflang values must match the page's actual content language. Serving hreflang="de-AT" on a page written in English is a violation that search engines will eventually penalize or ignore.
- Implement via HTTP headers, HTML <link> tags, or XML sitemaps, but be consistent. Mixing methods across pages introduces conflicts.
Common pitfalls include orphaned annotations (page A points to page B, but B doesn't point back), currency-only variants without language differences (these don't warrant separate hreflang), and failing to update hreflang when new locales launch.
Schema.org Markup for Local Commerce
Structured data amplifies your visibility in search results. For localized e-commerce, the most impactful schema types are:
- Product: Include name, description, offers (with priceCurrency and availability), and sku. Each locale page should carry its own Product markup with locale-appropriate values.
- AggregateRating and Review: Surface star ratings and review counts in SERPs. If you translate reviews, the schema should reflect the translated content.
- BreadcrumbList: Helps search engines understand your site hierarchy per locale.
- FAQPage: Localized FAQ schema can win rich results in local SERPs.
All schema text fields must match the visible page content in the same language. Serving English schema on a Japanese page violates Google's structured data guidelines and risks a manual action.
Localized Site Search
Multilingual Embeddings and Synonym Management
On-site search is where localization most visibly fails, or succeeds. A shopper in France searching for "pantalon" needs to find the same products as a US shopper searching for "pants." This requires more than translated index fields.
Modern approaches use multilingual vector embeddings (models like multilingual E5 or Cohere's multilingual embed) to map queries and product data into a shared semantic space. This means a search for "zapatillas deportivas" can match products indexed as "running shoes" without explicit keyword mapping.
However, embeddings alone don't handle everything. You still need:
- Locale-specific synonym lists: "Jumper" (UK) = "Sweater" (US). "Handy" (DE) = "Mobile phone." These must be curated per market.
- Stop word and tokenization rules: CJK languages require different tokenizers than Latin-script languages. Arabic needs right-to-left aware indexing.
- Spelling normalization: Handle "colour" vs. "color," "grey" vs. "gray," and locale-specific transliterations.
Search relevance tuning is an ongoing process. Monitor zero-result queries per locale and feed them back into synonym lists and embedding fine-tuning.
If your search platform lacks locale scoping or rule-based merchandising, let Ollang review your search relevance and merchandising setup.
Merchandising Rules per Locale
Search results aren't just about relevance, they're about revenue. Merchandising rules (boost, bury, pin, redirect) need locale-level configuration.
Examples of locale-specific merchandising logic:
- Boost winter coats in the Southern Hemisphere during June-August while boosting swimwear in the Northern Hemisphere.
- Pin locally popular brands to the top of category pages in specific markets.
- Redirect searches for region-specific terms (e.g., "thongs" in Australia should route to footwear, not lingerie).
- Suppress products that can't ship to a given locale or that lack regulatory approval there.
Your search platform (Algolia, Elasticsearch, Bloomreach, etc.) should support rule scoping by locale index or locale parameter. If it doesn't, you'll end up maintaining entirely separate search instances, which multiplies operational cost.
