All posts
Ray Iyer
Ray Iyer
Co-founder & CEO, Anglera

Localization is not translation: taking a catalog into new markets

Localizing a catalog means new units, standards, taxonomy nodes, and search vocabulary — not translated strings. Here's how to do it without losing rankings.

Localization is not translation: taking a catalog into new markets

A team expands into a new country, runs the catalog through a translation vendor, and ships it. Three months later, conversion is flat, the wrong products are ranking, and the local team is filing tickets about "wrong" specs that were never actually wrong — they were just never adapted. Translation changed the language. Nothing else moved. That gap is where market expansion quietly fails.

Translation is one line item in a much bigger job

Swapping words is real work, but it is the shallowest layer of taking a catalog into a new market. Underneath the copy sit four things that actually determine whether a listing sells, ranks, or even displays correctly:

  • Units and measurements. Voltage, plug type, torque, weight, and dimensions don't translate — they convert, and the conversion has to be correct at the attribute level, not just in a paragraph of prose.
  • Regulatory and quality standards. A product certified under one region's standard often needs a different mark, disclosure, or test standard to be legally listed in another (UL versus CE/UKCA is the classic case in electrical and tools).
  • Taxonomy. Global classification systems like GS1's Global Product Classification exist precisely because category structures diverge by retailer and region — a brick code stays constant, but the category path a shopper browses does not.
  • Search vocabulary. The word that ranks in one market often isn't the word used in another, even when the language is nominally the same.

Each of these is a data problem, not a copywriting problem. Translating the description while leaving these four untouched produces a listing that reads fluently and still fails the market it's supposed to serve.

Same language, different search terms

The most underestimated piece is search vocabulary. Multiple SEO practitioners point to the same UK/US pattern: "trainers" in the UK is "sneakers" in the US, and "jumper" is "sweater" — same product, same language family, different query. That pattern repeats across categories and dialects far beyond fashion, and it also holds inside a single language across countries: Spanish search behavior in Spain and Mexico reflects distinct terminology, seasonal patterns, and product preferences even though the language tag is identical. A translated title captures none of this — it captures grammar, not demand.

Ask an answer engine "what's a good cordless impact driver for UK tradesmen" and "best impact driver for a contractor" in the US, and you'll surface different competing products, different attribute expectations (Nm versus in-lbs torque, BS versus NEMA plug), and different phrasing entirely. If your catalog only carries US-market vocabulary and units, it's invisible to the first query no matter how well the description was translated.

A before/after, not a before/after-in-words

Here's what a translation-only pass produces versus what an enriched, market-adapted record looks like for the same SKU sold in two markets.

Raw feed description (translated only): "18V cordless impact driver. Compact, lightweight design ideal for tradesmen. Includes battery and charger."

Enriched, market-specific attributes:

AttributeUS listingUK listing
Charger input / plug120V, NEMA 1-15230V, BS 1363
Torque unitin-lbsNm
Battery certificationUL 2054UKCA / CE
Category pathTools & Home Improvement > Power Tools > Drills & DriversDIY & Tools > Power Tools > Drills & Drivers
Search term coverage"impact driver," "impact driver kit""impact driver," "combi driver"

Same product. Same brick-level classification underneath. Two structurally different, market-correct listings — because the attributes carry the market difference, not a translated adjective.

Why this is also where rankings get lost

Localizing badly doesn't just cost conversion — it costs visibility, and the failure mode is almost always structural rather than linguistic. Google's own guidance on multi-regional and multilingual sites is explicit: use distinct URLs per market rather than cookies or geo-redirects, make the local language visible in the actual page content rather than relying on markup, and use hreflang so each regional version points to the correct sibling — every page self-referencing, every annotation bidirectional. Get the reciprocity wrong (a common failure when localization is bolted onto an existing catalog late) and search engines can end up ignoring the entire cluster of regional pages, collapsing your carefully localized catalog back into duplicate-content noise.

The pages can be technically flawless and still rank for the wrong things if the underlying product data — units, standard, category, term — was never adapted. Technical SEO gets you crawled and indexed correctly. Attribute-level localization gets you matched to the right query once you're there.

Localize the record, not the listing

The pattern that scales is to treat market variants as structured fields on the product record — market-specific unit, standard, category mapping, and term set — rather than a separate marketing pass per country. Do it as a translation project and every new market means re-touching every SKU by hand, forever, with no consistent source of truth to audit against.

This is the same discipline Anglera applies to any catalog: pulling from your PIM or a flat file, enriching each SKU with the units, standards, category paths, and search terms a given market actually needs, and writing structured, source-grounded values back to your existing system — no rip-and-replace, no re-platforming. A catalog that's ready for a new market isn't one that's been translated. It's one whose data was built to be read correctly wherever it lands.

Ray Iyer

About the author

Ray IyerCo-founder & CEO, Anglera

Ray is the co-founder and CEO of Anglera, building the product-data infrastructure for agentic commerce — turning messy catalogs into structured, AI-readable data that buyers and answer engines can find. Previously product at Uber; Stanford CS.

See it on your own SKUs.

A 30-minute walkthrough on your categories and your supplier data.

Book a demo