Understand translation and classification

How catalog translation works

Localizable attributes, fallback, workflow, and what to translate first.

Translating a catalog is not translating a website. A website has fifty pages. A catalog has 40,000 products with eight text fields each, half of which change every quarter. The difference is not size — it is that catalog translation never ends, so it has to be a process rather than a project.

The scenario

Your Austrian subsidiary sells to a Polish buyer. The buyer opens your shop, switches to Polish, and sees: a Polish navigation, Polish category names, German product names, and an English description that was machine-translated eighteen months ago from a German source that has since been rewritten.

Every one of those four states is a separate mechanism, and this article is about all four.

What is localizable and what is not

An attribute marked localizable holds one value per language. One that is not holds a single value used everywhere. The distinction is set on the attribute in the catalog, and it is the decision the whole translation workload rests on.

LocalizableNot localizable
name, short_description, descriptionsku, ean, manufacturer_part_number
application_notes, marketing_claimweight, length, pressure_rating
Option labelsStainless steel V4AOption codesv4a
Category and family labelsCategory and family codes
Asset titles and alt textThe asset file itself

The test: would a translator change this value? If yes, localizable. If it is a number, a code, an SKU or a date — not.

Two consequences people miss:

  • Option labels are where most of the value is. A select attribute with twelve options translated once serves every product that uses it. Translating material and surface_finish labels costs an hour and localises the facet panel of the entire catalog.
  • Measurements do not need translating; they need converting. 10 bar is 10 bar in every language. A market that uses psi needs a unit conversion, which is a measurement family question, not a translation one.
Marking too much as localizable is the expensive mistake. Every localizable attribute multiplied by every language multiplied by every product is a cell somebody has to fill or explicitly leave empty. A catalog with fourteen localizable attributes, 40,000 products and three languages has 1.7 million cells. Changing an attribute from localizable to not — or the reverse — after data exists is a migration, not a toggle.

Fallback chains

No catalog is ever fully translated. The question is what a buyer sees when a value is missing, and the answer is a fallback chain: an ordered list of languages to try.

de-AT  →  de-DE  →  de  →  (empty)
fr-CH  →  fr-FR  →  en  →  (empty)

Regional variants fall back to their base language first — an Austrian buyer should see the German text, not the English one. Languages with no relation fall back to whichever language your organisation treats as the source, usually German or English.

Where the chain ends is a policy decision with two honest options:

End of chainEffectRight when
Source languageThe buyer sees German text on a French pageTechnical catalogs; a German name is more use than a blank
EmptyThe field is absent; completeness marks the product incompleteMarketing-led catalogs, or where mixed language damages the brand

Most B2B catalogs choose the source language for name and empty for description. A German product name in a French listing is recognisable. Three paragraphs of German marketing prose in a French product page is not.

Fallback is display, not translation. A field showing its fallback value is still untranslated, and must still appear in the translation queue. A fallback that silently counts as "done" is how a catalog stays 40% German for two years while every report says it is complete.

What to translate first

The order is not obvious and it decides how quickly a new market becomes usable.

  1. Category and family labels. A few hundred strings. Without them the navigation is in the wrong language and the shop looks untranslated regardless of what else you do.
  2. Option labels. Also a few hundred, and they localise the entire facet panel — see Facets and filters. Highest value per string in the whole catalog.
  3. Product names. Thousands, but short. Names are what buyers scan in a result list and what search matches against. A market with translated names and untranslated descriptions works. The reverse does not.
  4. Short descriptions. The listing-page line.
  5. Long descriptions. Last, and only for the products that justify it.
  6. Application notes, marketing text. Only for your top articles.

The rule underneath: translate what is short, structured and reused before you translate what is long, unique and rarely read. Nobody reads paragraph three of a description for a hexagon screw in any language.

Cut the scope further by product, not just by field. Your top 500 articles by revenue usually cover most orders. Translate those fully; translate the tail's names and option labels only.

Machine draft, human review

Machine translation is good enough to be the first draft of a catalog and not good enough to be the last. It gets prose right and technical vocabulary wrong, in exactly the places where being wrong is expensive: it will translate a norm designation, invent a material name, and cheerfully convert a thread size.

The workflow that works:

source value changed
        ↓
machine draft generated      → state: machine
        ↓
reviewer edits or approves   → state: reviewed
        ↓
source changes again         → state: needs review

Three states, and every value in every language is in exactly one of them — plus untranslated for the ones nothing has touched. That state is what makes the work visible and assignable; see Translation quality.

Never publish machine-only text for the fields buyers make decisions on. Names, safety notes, and anything with a norm or a dimension in it get human eyes. Long descriptions on tail articles can ship as machine drafts, clearly tracked, and be reviewed when someone has time — but that is a decision you take deliberately, not one you discover later.

Give the machine a glossary before it starts: your product names, brand names, norm designations and material codes, marked as do-not-translate or with a fixed target term. Without it, V4A becomes something different in every paragraph. With it, machine drafts need a fraction of the correction.

How this works in the Revenue Cloud

  • Languages belong to markets. A market carries its locales, currencies and tax classes; a locale is a language and a country — de-AT, fr-CH. Set up in Configuration › Markets. See Add a language.
  • Localizable is an attribute flag, set in PIM › Data model › Attributes.
  • Completeness is calculated per locale, so "how ready is the French catalog" is a question you can actually answer — see Channels, locales and completeness.
  • Search is per locale. Each language has its own index and its own synonyms, which is why an untranslated catalog shows up first as a terrible zero-result rate in that market.

Next