A supplier switched a coffee table from solid oak to an oak veneer, and the buyer updated the product. The English description went from Solid oak, 120cm to Oak veneer, 140cm the same afternoon. Six weeks later a customer in Munich returned one, because the German storefront still read Massiv Eiche, 120cm and the table that turned up was neither solid nor that size. The French page said the same. Nobody had edited the German or the French to make them wrong. They were right the day they were written, and the product moved on without them.
Multilingual master data is the domain people think they have solved because they can store a description in five languages. Storing them is the easy half. The hard half is keeping the five in sync with the one thing they all describe, and that is the half almost nobody builds, because on a good day it is invisible. Every language renders, every storefront loads, and the drift only surfaces when a translation ends up describing a product that has quietly changed underneath it.
Not every field is the same field in another language
The first mistake is treating multilingual as a single problem. It is three, and they need opposite treatment. Sort every attribute into one of these before you model anything, because getting an attribute into the wrong bucket is what causes most of the damage further down.
Pure translations are one value wearing different languages: the product name, the description, the marketing copy. There is a single source of truth, usually the language the product was authored in, and every other language is a rendering of it. These must track the source. If the source changes and a translation does not, the translation is now wrong, whatever it says.
Locale-specific values are legitimately different per region and are not translations of each other at all. The legal entity name in Germany, the compliance text a market requires, the list price, the address format. Nobody translates a French price into German; there is a different price. Model these as independent per-locale values, and never wire them to a source, because they have none.
Language-neutral values must never vary by locale under any circumstances: the GTIN, the net weight in kilograms, the part number, the physical dimensions. A barcode is a barcode in every market. The moment a locale can hold its own copy of one of these, you have handed someone a way to make the German weight disagree with the English weight for the same box, and nothing about the interface will stop them. Keep these single-valued, and format them per locale only at display time, so 15 kg and 15,0 kg are the same governed number shown two ways.
Where the languages drift
None of these throw an error. Each language renders fine on its own storefront. The failure only exists when you compare a translation to the thing it was supposed to describe, which is the one comparison most systems never make.
The translation that outlived the source
The English description is edited from solid oak to veneer after a supplier change. Nothing links the German and French copies back to it, so they are never flagged. Both storefronts keep selling the old spec, looking perfectly correct, until a customer receives a veneer table they ordered as solid wood and sends it back.
The free-text field nobody linked
A translated attribute is stored as plain text with no reference to the value it translates or the version it was made from. There is no way to ask which translations are current, because the system was never told what current means. Every language is an island, and drift is invisible by construction.
The machine translation nobody read
To fill a gap fast, a locale is auto-translated and published without review. A category called "Springs" (the metal coils) comes back as the season. It renders on the storefront, it is grammatically fine, and it is selling garden furniture under a heading about the weather until someone in that market complains.
The silent fallback to nothing
A new product launches with English and German filled in but Italian missing. Instead of falling back to the source language, the storefront renders the empty field, so the Italian page ships a product with a blank name. A defined fallback would have shown the English. The absence of one shows a hole.
The unit baked into the string
A description reads "Weighs 15 kg" and gets translated as free text into a market that expects pounds. The number is now trapped inside a sentence in five languages, so correcting the weight means editing five strings instead of one governed value. The unit should have lived in its own language-neutral field, formatted per locale at display time.
The first one is the worst, because at the record level nothing is broken. Three valid descriptions, three valid storefronts, three valid orders. The error lives only in the relationship between the source and its translations, and that relationship is exactly what a free-text field throws away. It is the same shape as a slowly changing dimension problem: a value has a history, other values point at a moment in that history, and the two have to stay consistent or the whole thing quietly lies.
Make the translation know what it translated
The fix is to stop storing translations as loose text and start storing them as what they are: dependents of a source value. A translatable attribute has one source language and a set of translations, and every translation carries a stamp of the source version it was made from. That single stamp is the whole game. It turns which translations are stale from a question nobody can answer into a query the system runs for free.
When the English description moves to v3, every translation still stamped v1 is out of date by definition. The system flags them, routes them to whoever owns that locale, and holds them in a re-translate queue instead of leaving them live and wrong. The German copy does not have to be edited to be caught. It has to fall behind, and falling behind is now something the data can see.
Two more rules carry most of the rest. Define an explicit fallback, so a missing translation renders the source language rather than a blank; a customer who sees an English name on an Italian page knows the page is incomplete, but a customer who sees nothing thinks the product is broken. And gate each locale behind an approval step, so a fast machine translation is a draft a native reviewer signs off, not a string that reaches a storefront the moment it is generated. Machine translation is a good first pass. It is a bad last word.
This is a PIM job the MDM has to set up
Multilingual data lives where product data is richest, so it is easy to file it under PIM and stop there. The trouble is that the syndication a PIM does well only works if the record underneath is governed: one source language declared, the translatable and language-neutral attributes separated, an owner per locale, a rule that says a translation cannot go live stale. That governance is master data work. The PIM pushes the languages out to the channels. The MDM decides what a correct set of languages even is.
It also has to sit next to the rest of the product record. The unit of measure that keeps a weight out of the description string, the reference data that supplies the locale codes themselves, the identity work that stops the same product existing three times before you have even worried about its translations. Multilingual is a layer on top of a governed record. Bolt it onto an ungoverned one and you are just producing the same duplicates and the same drift, now in five languages instead of one.
If you are coming off MDS
MDS had no concept of a locale. Teams that needed multilingual product data built it by hand, and there were only two ways to do it, both bad. One was a column per language: NameEN, NameDE, NameFR, widening the entity every time a market was added and giving no way to tell which columns had fallen behind. The other was a separate entity per language, joined back to the product, which turned every read into a join and every governance rule into something you enforced by convention because the model could not.
Neither carried a source version, so neither could tell a current translation from a stale one. That check lived in a spreadsheet a steward maintained by hand, if it lived anywhere. Migrating off MDS is the moment to stop treating multilingual as extra columns and model it as what it is: a source value, its translations, and the version stamp that keeps them honest. Carry the column-per-language mess into the next system and you have migrated the drift along with the data.
Common questions
What is multilingual master data?
A master record whose descriptive attributes exist in more than one language, because the same product or category is shown in different locales. The hard part is not storing the languages. It is keeping each translation tracking its source value, so that when the source changes the translations are flagged as out of date instead of silently describing a product that no longer exists.
Which attributes should be translated and which should not?
Three kinds behave differently. Pure translations (name, description) are one value in many languages and must track a single source. Locale-specific values (legal name, compliance text, price) are legitimately different per region, not translations. Language-neutral values (GTIN, weight, part number) must never vary by locale. Most trouble comes from confusing the three.
Why do translated descriptions drift out of sync?
Because most systems store the translation as an independent free-text field with no link back to the source or its version. When the source is edited, nothing marks the translations stale. They keep rendering, correct-looking and wrong, until someone notices the local page describes a different product than the one that ships.
How should multilingual master data be governed?
Model each translatable attribute as a value with a source language and dependent translations, each stamped with the source version it came from. When the source changes, mismatched translations are flagged stale and routed to the locale owner. Define an explicit fallback so a missing translation shows the source, not a blank. Keep language-neutral fields single-valued, and approve per locale so a machine translation cannot ship unreviewed.
Keep every language tracking the same product
Primentra governs the record your translations hang on: translatable and language-neutral attributes kept separate, an owner and an approval step per locale, and a full audit trail so you can see when a source value moved and which languages have not caught up. It runs on your own SQL Server, deploys in a day, and costs €7,500 per year flat. The 60-day trial runs against your real catalog, which is long enough to find the translations that stopped tracking the product a year ago.