Product content localization
Product content localization is the work of adapting product data for a specific market. It converts units of measure, swaps compliance and certification attributes, remaps taxonomy and classification codes, and uses the terms local buyers search. A UL 486A listing means little to a buyer looking for a VDE mark. Translation changes the words; localization changes the record.
Localization is not translation
Translation takes a string in one language and produces a string in another. Localization takes a product record that works in one market and produces a record that is correct, compliant, and findable in another.
The gap shows up fast in B2B. A German electrician looking for a wire connector does not type "wire nut." They type "Verbindungsklemme," and they filter on a VDE mark, not a UL listing. A flawless translation of your UL 486A copy is still the wrong record.
| Dimension | Translation | Localization |
|---|---|---|
| Scope | Free text: titles, descriptions, marketing copy | The whole record: attributes, units, codes, assets, search terms |
| Units | Passes "3/8 in" through unchanged | Converts to 9.525 mm, or substitutes the nearest metric part |
| Compliance | Renders "UL listed" in another language | Replaces with the mark that market recognizes, or flags the SKU as not sellable there |
| Taxonomy | Untouched | Remaps to the local scheme: ETIM, eCl@ss, national HS extension |
| Assets | Untouched | Swaps plug-type images, local spec sheets, region-legal labeling |
| Failure mode | Reads slightly off | Product is unfindable, non-compliant, or returned |
What actually changes when a SKU crosses a border
Take one fastener line item and put the US and German records side by side. Same job on the jobsite, two very different rows.
| Field | US (en-US) | Germany (de-DE) |
|---|---|---|
| Title | 3/8-16 x 2" Grade 8 Hex Cap Screw, Zinc | Sechskantschraube M10 x 50, Festigkeitsklasse 10.9, verzinkt |
| Thread | 3/8-16 UNC | M10 x 1.5 |
| Length | 2 in (50.8 mm) | 50 mm |
| Strength | SAE J429 Grade 8 | ISO 898-1 property class 10.9 |
| Dimensional standard | ASME B18.2.1 | DIN 931 / ISO 4014 |
| Classification | UNSPSC code | ETIM class + eCl@ss code |
| Selling UOM | Each, box of 100 | Stück, VPE 100 |
| Tariff | 7318.15 root, extended by US HTSUS digits | 7318.15 root, extended by EU TARIC digits |
Three things in that table are traps:
- The length row is a substitution, not a conversion. 2 in is 50.8 mm. The German row is a different part that happens to do the same job, and the record has to say so.
- Grade 8 and class 10.9 are close, not identical. A localized record that silently equates them creates returns. Sometimes localization ends in a cross-reference and a substitution note.
- The imperial part may not exist in that market at all. The honest output is "no equivalent, do not list," and a catalog that can't express that will list it anyway.
Taxonomy, units, and compliance are locale-specific
Every market files products its own way, and a SKU usually carries several classifications at once — one for the wholesaler, one for the buyer's ERP, one for the shopping feed. Localization means keeping all of them true simultaneously, per locale.
What has to be handled as locale-specific data rather than translated text:
- Classification codes. ETIM for electrical and HVAC in Europe, eCl@ss for German manufacturing and procurement, UNSPSC for global purchasing, GPC for GDSN, Google Product Category for feeds. Each is a separate scheme with its own structure.
- Certification marks. UL and CSA in North America, CE, VDE, and UKCA in Europe, PSE in Japan. Never map one onto another as a synonym.
- Regulatory attributes. REACH SVHC declarations, RoHS, WEEE, California Prop 65. If a locale requires an attribute you don't hold, you have a fill-rate gap, and someone has to go source the value.
- Electrical ratings. 120V/60Hz versus 230V/50Hz usually means a different part number.
- Units and packaging. Value and unit belong in separate fields. "2 in" stored as a string cannot be converted by anything.
Where localization breaks in practice
The failures repeat across catalogs:
- Machine translation pointed at attribute values. "Stainless steel" comes back as five different free-text strings and faceted search splits into five values that never merge. Attribute values belong in a controlled vocabulary, translated once at the vocabulary level, then reused.
- One taxonomy forced on every market, usually the home-market one, because remapping the whole catalog to ETIM looked expensive.
- No fallback rule. When de-DE has no value, does the PDP show en-US, or show nothing? Pick one deliberately and write the rule down.
- Fill rate measured across the catalog instead of per locale. A catalog that is near-complete in en-US and half-empty in de-DE is a half-empty catalog in Germany.
- Review by someone who doesn't speak the language. A native reviewer catches a wrong category in seconds.
How to run it alongside your PIM
Most PIMs model locales and locale-scoped attribute values. The schema is rarely the problem; the empty fields are.
Someone still has to find the DIN equivalent for the ASME standard, confirm the certificate covers the part, pick the right ETIM class, convert the ratings, and write a title using the words German buyers type. That is research work, done SKU by SKU, and it lands in scopes your PIM already defines.
The PIM stores your product data; Anglera does the work of completing it, locale by locale.
Frequently asked questions
What is the difference between internationalization (i18n) and localization (l10n)?
Internationalization is the engineering work that makes a market possible: locale-scoped attribute values, value and unit kept in separate fields, a taxonomy layer that can hold more than one scheme at a time. Localization is filling that structure for a given market — the German title, the ETIM class, the VDE certificate. i18n happens once in your data model. l10n happens for every SKU, in every locale you sell into.
Can machine translation handle product attributes?
Sort the fields by what a wrong answer costs. Marketing copy tolerates a machine draft with a native reviewer behind it. Attribute values need a controlled vocabulary translated once and reused, so faceted search doesn't fracture into near-duplicate facets. Standards, certification marks, and classification codes carry legal and returns exposure, so those come from a source of truth with a human signing off.
Do I need separate SKUs for each market?
Often, yes. A 120V/60Hz device and its 230V/50Hz counterpart are different parts with different certifications. A 3/8-16 imperial fastener and its M10 counterpart are near equivalents. Where the physical product is identical, one SKU with locale-scoped attribute values is correct. Where ratings, threads, or certifications differ, force a separate SKU and a documented cross-reference between them.
How does localization affect classification codes and HS codes?
Classification schemes are market-specific. European electrical wholesalers expect ETIM; German procurement often expects eCl@ss; global purchasing systems use UNSPSC; shopping feeds need Google Product Category. HS codes share a six-digit international root but each country extends it — the US via HTSUS, the EU via TARIC. One SKU normally carries several of these at once, all of which must stay accurate.
Doesn't my PIM already handle localization?
Most PIMs model locales and locale-scoped attribute values, so the structure is usually there. The open question is occupancy: run attribute fill rate per locale rather than across the whole catalog and the answer shows up fast. If de-DE holds a title, a price, and little else, the PIM is doing its job — storing what it was given. Completing those values is a separate job.