Ecommerce localization for product catalogs

A storefront can stay in place while the product records behind it serve every market in the right language, units, currency, and offer state. The difficult work is keeping those records consistent across feeds, marketplaces, and AI shopping surfaces as products change.

We treat ecommerce localization as a product-data problem first. This guide shows how to separate canonical facts from market overrides, map each output to its channel contract, and validate the result before it syncs.

Ecommerce localization has two layers#

Ecommerce localization is the adaptation of an online offer to a specific market. That can include the whole shopping experience. For product-data teams, the useful unit is narrower: a localized product record is a structured representation of one product or variant for a market, locale, and channel.

That distinction keeps a market launch from becoming a storefront rebuild. Your existing site can own navigation, checkout, account pages, and legal content. A product-data layer can publish the same sellable item with the right title, description, attributes, units, price, availability, link, and eligibility for each destination.

At Catalog, we keep those records machine-readable and synchronized while the storefront and source systems retain their roles. The goal is a reliable parallel product surface for channels that need typed, current product data.

What product-record localization includes#

• Locale content: titles, descriptions, bullets, attribute labels, and search terms written for the buyer's language and market vocabulary.
• Market presentation: local units, size systems, number formats, currency, approved price, sale window, and market-specific product links.
• Commercial state: availability and inventory at the sellable variant and market level.
• Eligibility: whether a product may be sold or shown in a country, channel, campaign, or fulfillment region.
• Channel output: a payload shaped for Google Merchant Center, a marketplace, a product feed, an API, or an AI shopping surface.

What it does not replace#

Translation supplies language. Localization also selects, converts, formats, and validates structured values. Pricing strategy sets the approved market price. Localization carries that price with the right currency and market context.

Keep one canonical record, then add market context#

Start with one stable product and variant model. Add locale and market overrides without copying the entire record into a new source of truth.

Use explicit keys such as variant_id + market + locale + channel. A locale is a language and regional convention. A market determines where an offer can be sold. A channel determines which fields and formats are accepted. Treating all three as one language column hides the decisions that make a record publishable.

Keep stable identifiers stable. Google's product specification says to use the same ID for the same product across countries or languages, while titles, descriptions, attributes, and offers carry the context that changes. That lets a destination match updates to the right item instead of creating a second product.

Localize the fields that change meaning#

For every field, decide whether the workflow should keep, translate, convert, calculate, or select the value. Record that decision in the data model. Do not leave it to whichever export happens to run next.

Titles and descriptions#

Translate titles and descriptions with a market glossary, then adapt the wording to how buyers search and compare products locally. Keep brand names, model numbers, regulated claims, and identifiers tied to approved source values. Put variant differentiators such as color or size in the title when a channel requires them.

Store the localized copy as fields, not as a replacement for the canonical product facts. A reviewer should be able to see the source text, locale, glossary version, reviewer, and approval state. For a channel such as Google Merchant Center, keep the title and description in the data-source language, follow its length and editorial rules, and remove promotional copy from fields intended to describe the product. Google's product data specification documents those destination rules.

Attributes and taxonomy#

Normalize attributes before translating their display values. The canonical value might be color: navy, while the German display value is Marineblau. Both should point to the same controlled concept so filters, comparison, and analytics continue to work.

Map taxonomy in two steps:

1. Map the product to your internal category and approved attribute set.
2. Map that controlled category to each channel's taxonomy and locale labels.

Do not infer a category from a translated title. Keep the mapping versioned so a channel taxonomy change does not rewrite the product's identity.

Units and sizes#

Store numeric facts with a unit in the canonical record. Convert them for display or a channel only when the market requires it. Keep the unrounded value and the conversion rule so a reviewer can reproduce the output.

For example, a jacket length of 65 cm can display as 25.6 in in the United States. A weight of 1.2 kg can display as 2.65 lb. Round only at the presentation boundary. Keep compliance, safety, and technical source values in their required units.

Use locale-aware number and unit formatting rather than string replacement. Unicode's CLDR currency patterns documents how decimal separators, grouping, currency symbols, and spacing vary by locale. Size conversions deserve their own approved table because apparel sizing is a fit convention, not a universal arithmetic conversion.

Prices and currency#

A localized price needs at least four values: amount, ISO 4217 currency code, market, and effective time. Keep them separate from a formatted display string.

amount: 139.00
currency: EUR
market: DE
effective_from: 2026-10-01T00:00:00Z
price_type: consumer

A currency symbol alone is ambiguous. Store 139.00 EUR, then format it for the locale as 139,00 € when that is the approved display convention. A converted estimate can help a shopper understand a base price, yet a channel feed should receive the approved price and currency for its target market. Pricing strategy decides the amount; localization applies the amount accurately.

Google's feed specification uses a numeric price and an ISO 4217 code, and requires price and currency to match the landing page and checkout context. Its landing-page requirements also tie the product-data language and currency to what shoppers see when they arrive.

Availability and market eligibility#

Availability is an offer state for a variant in a market. It is not a translated product attribute. Use controlled values such as in_stock, out_of_stock, preorder, or backorder, then attach the source timestamp and inventory rule.

Keep eligibility separate from availability:

market: DE
eligible: true
eligibility_reason: ships_to_market
availability: in_stock
inventory_source: warehouse-eu

A product can be eligible for Germany and out of stock there. It can be in stock in the United States and ineligible in Germany. A missing market rule should fail closed for publishing. Do not use an English fallback to make an unavailable offer look complete.

Make fallbacks explicit#

A fallback prevents a blank field from becoming an accidental data decision. Define it field by field and store which fallback was used.

A practical chain for an approved localized description might be:

1. exact market and locale, such as DE + de-DE;
2. language-only record, such as de;
3. a market-approved regional default, if the channel accepts it;
4. hold the record for review when no safe value exists.

Use a different policy for each field class:

• Identity and universal facts: fall back to the canonical value when the field is language-neutral.
• Customer-facing copy: fall back only through an approved language policy. For a channel that requires one feed language, a missing translation should hold or exclude the item rather than publish the wrong language.
• Price, currency, availability, and eligibility: require a market-specific value. Never fall back from Germany to the United States for an offer.
• Channel fields: require a destination mapping and a valid enum. A generic source field is not a valid channel payload by itself.

Record fallback_used, fallback_source, and review_state. This gives operations a way to find incomplete localization without inspecting every export manually.

Map each market record to each channel#

Channel mapping is the boundary between a normalized product model and a destination contract. Build one mapping per channel and keep locale, market, and variant context in the input.

A Google Merchant Center output, a marketplace listing, and an AI shopping object may all describe the same jacket while requiring different field names, length limits, enums, and acceptance checks. Keep those transformations at the edge. Do not fork the canonical record for every channel.

Google's data-source guidance separates primary sources, target countries, language, and supplemental regional data. That model is a useful reminder to carry country and language as explicit publishing context, even when your stack uses different names.

Validate before you sync#

Localization is complete when the right record is accepted downstream, not when a translation job reports success. Run validation at four boundaries:

1. Canonical record: required IDs, variant joins, source facts, provenance, and approved claims.
2. Localized overlay: locale tags, glossary or reviewer state, translated fields, converted units, market price, and eligibility.
3. Channel payload: required fields, allowed values, length limits, encoding, URLs, image references, and destination schema.
4. Destination state: fetch or API response, processing result, rejection reasons, freshness, and read-back parity with the market page.

Keep source and destination timestamps. A file that was generated is not necessarily fetched. A feed that was fetched is not necessarily accepted. A successful API request is not proof that the destination serves the updated item.

For price and availability, compare the same variant across the localized output, product page, structured data, and checkout. For language, check that the title, description, variant labels, and page content use the intended locale. For units and currency, validate both the typed values and the formatted display.

Our product data quality guide covers completeness, validity, consistency, and freshness checks. Our product feed management guide covers the channel lifecycle. Localization adds the market and locale dimensions that those checks must carry.

Worked example: localize a jacket for Germany#

Suppose the canonical record contains one sellable variant:

variant_id: NL-JKT-NVY-M
item_group_id: NL-JKT
brand: Northline
product_type: waterproof commuter jacket
color: navy
size: M
length: 65 cm
weight: 1.2 kg

The US output may use English copy, inches and pounds, and a USD offer. The German output keeps the identity and technical facts, then applies a German locale, a Germany-specific offer, and a German product link.

The channel export then maps these values into its own fields. If the German description is missing approval, hold the German row and keep the canonical record available for other markets. If Germany is out of stock, publish out_of_stock or exclude the offer according to the destination contract. Do not quietly send the US price, English copy, or US inventory as a substitute.

QA checklist for every market launch#

Use this checklist before enabling a new market or channel:

• Identity: IDs are stable, unique, and joined to the correct parent and variant.
• Facts: Technical values, ingredients, claims, images, and compatibility data match the approved source.
• Language: Titles, descriptions, attributes, and variant labels use the intended locale and approved glossary.
• Fallbacks: Every fallback is allowed for that field, recorded, and visible in review; missing required copy blocks publication.
• Taxonomy: Internal categories and controlled attributes map to accepted destination values.
• Units: Numeric values retain their source unit, conversions use a documented rule, and rounding happens only at output.
• Currency: Amount, ISO 4217 code, market, effective time, and display format agree.
• Offer state: Availability and inventory refer to the same variant and market as the price.
• Eligibility: Country, channel, campaign, fulfillment, and restriction rules filter the output correctly.
• Links and media: Localized URLs resolve to the same product and variant; image URLs are reachable and relevant.
• Channel contract: Required fields, enums, character limits, encoding, and schema validation pass for the destination.
• Sync: Source, publish, fetch, process, and read-back timestamps are recorded; rejected or stale rows have an owner and replay path.

Frequently asked questions#

Can I localize product data without rebuilding my storefront?#

Yes. Keep the storefront as the owner of the shopping experience and add a product-data layer that creates market and channel outputs from the same canonical records. The storefront still needs the right language, price, and availability when a shopper opens the link, yet the catalog work does not require duplicating the entire site.

Is ecommerce localization the same as translation?#

No. Translation changes language. Ecommerce localization also handles units, currency, taxonomy, market eligibility, availability, links, channel schemas, and validation. A translated description cannot correct an incorrect market price or an unavailable variant.

What should happen when a localized field is missing?#

Apply the field's explicit fallback policy. Use canonical values for language-neutral facts, approved language fallbacks for copy, and no cross-market fallback for price, availability, or eligibility. Hold the output when the destination would receive a misleading or invalid record.

Catalog helps brands keep these decisions in one product-data layer, then publish live, normalized product data to the channels and AI shopping surfaces that need it. See how Catalog can fit beside your storefront and source systems.