Multilingual eCommerce on a Marketplace: Translations, Search, and Missing Locales

Multilingual eCommerce on a marketplace is the schema decision about whether one product carries a value per language or exists once per market, and everything else about translation follows from it.

A second language looks like a line in the budget and a conversation with a translation agency. It is a change to your data schema, made once and usually without realizing it, while you design the product page.

Reversing it a year later is a migration of the whole catalog.

This article breaks down:

• How many times does one product exist in a multilingual catalog?
• Which 3 layers does translating a catalog split into?
• What should you show when a translation is missing?
• Why does the invoice arrive in the wrong language?

Key insights

• A second language is a schema decision, made once while you design the product page, and reversing it a year later is a migration of the whole catalog.
• Hand-translating 60,000 new descriptions a year takes almost seven people for one language. That number is enough to stop anyone promising a board a hand-translated catalog.
• A missing translation is the normal state. Keep structure and attributes in the buyer's language, show untranslated prose in the source language with a label, and hide only what you answer for.
• Record the buyer's language on the order the moment it is created. If the storefront drops it, the site is translated, and the confirmation and invoice are not, and six months later you cannot recover which language they read.

How many times does one product exist in a multilingual catalog?

The board asks, "How do we translate the descriptions?" You are answering a different question: does the same product exist once in your system, or as many times as you have languages? There are three answers, and they differ in what happens the day you add a sixth language.

1. One product, language as a dimension of the value

There is one "description" field, and it holds a separate value per language. Adding a language is configuration: the structure does not change, and the import file gets one column.

2. One product, a separate field per language

Instead of a dimension, you have description_pl, description_de, description_es. These are ordinary text attributes that somebody gave a language meaning.

In the implementations, we know it is the most common variant because it demands nothing from the platform. The price: adding a language becomes a change to the taxonomy.

New attributes, wiring them into every category, new import and validation templates, and the seller gets columns they do not understand. The fallback order stops being a policy and becomes a side effect of configuration: in some solutions, which language shows when the right one is missing follows from the order of fields in the panel.

3. One catalog per market

A separate installation per country. It is sometimes imposed, because some solutions assume one country and one base currency per installation.

You do not then have a catalog in five languages. You have five catalogs: five truths about the same product, the same debt five times over, and no way to compare markets without gluing the data together outside the platform.

Everything else, translation quality included, follows from that choice. That is why the question belongs at the gate before the build, next to the catalog model and the matching key from "Product Catalog Management on a Marketplace: One Shared Page or Seller Listings?" and "Product Matching on a Marketplace: GTIN, EAN, and Where Identifiers Stop".

Which 3 layers does translating a catalog split into?

"Translating the catalog" glues together three layers with a different owner, size, and rate of change. Take a hypothetical catalog: 300,000 products, 1,200 categories, 800 attributes, five languages (the source and four translations).

A value from a list travels through the system as a code: the product stores NAVY, and the buyer sees "granatowy" or "navy blue" depending on who is looking. Then you translate the list once.

A value in a text field gives you none of that. "granatowy," "ciemnoniebieski," "navy," and "grantowy" are four strings you cannot count up front.

The point sits in the spread between the second row and the fourth. You close the first two layers by design, for 32,000 translations: one order.

The fourth is a process without an end. And the third decides which group it lands in.

Every attribute moved from a text field into a list moves its translation from an infinite set to a finite one. In a single-language marketplace, a list buys filters and order.

In a multilingual one, it also buys the translation for free. That argument is usually missing from the taxonomy conversation in the category tree.

Hence one sentence for the integration specification: the files you exchange with a seller operate on codes. A file built on labels is a file in one language.

Who translates a marketplace catalog and what does it cost?

The seller. Quality is random, and most will not do it at all.

Practitioners from large implementations say it plainly. Letting a seller into the next country meant they had to supply the title and description in that language themselves, and for some sellers that was reason enough not to enter the market.

A translation requirement is an entry gate. The extreme version: when the seller's language differs from the platform's, the offer description, the store description, and the return policy have to be written in the platform's language.

It is cheap, and it works. It also settles who can sell on your platform.

You. The cost grows linearly with the catalog and does not stop.

At 60,000 new descriptions a year and 40 descriptions per person-day, that is 1,500 person-days, which over 220 working days is almost seven full-time people for one language. That number is enough to stop you from promising the board a hand-translated catalog.

The machine. For structure names and lists, it is cheap and good enough: short, repeatable phrases in a finite set, reviewed by a human once.

For free content it is risky, because quality depends on the language pair and the category. Independent evaluations of machine translation with professional raters show the problem is not solved in the era of large language models either.

Then there are the fields whose content you are answerable for: warnings, safety information, compliance data. There, the machine is out of the question, because liability sits with whoever published the text.

Two mechanisms are worth writing into the requirements. First: machine translation enters as a source with a priority.

It fills empty fields and loses to a better source. Otherwise, it quietly swaps a good manufacturer description for a mediocre translation.

Second: billing by the word is a policy in practice. Translation layers are sometimes billed against a word limit, and once you pass it, new content stays in the source language.

If you do not settle what happens to an offer with no translation, the invoice will settle it.

What should a marketplace show when a translation is missing?

A missing translation is not an exception. It is the normal state.

You have three ways out.

You show the text in the source language. The buyer lands on a page they do not understand and loses trust in the whole site.

You hide the offer. The catalog stays consistent, but you lose assortment and a seller who does not understand why they are not selling.

It is an operating cost: 40,000 offers with no translation from 200 sellers is two hundred conversations.

The third way, practical and rarely named: you split the page by layers. Structure, attributes, and values from a list are always in the buyer's language, because they are yours and finite.

Free content with no translation shows in the source language with a visible label saying this part has not been translated. The buyer knows what they are reading and can choose on the attributes.

The recommendation: the third way as the default, hiding only for the fields whose content you are responsible for. A missing translation of marketing copy is an inconvenience.

A missing translation of a warning is a risk. The fallback has to work per layer.

Otherwise, the page jumps between languages and looks broken.

Why does a translated catalog still send a foreign-language invoice?

This is the most important warning in the article: it surfaces after launch and catches teams that did the catalog perfectly.

The class of problem. In some solutions, the system content is a table of keys and values with one value per key: you can change the wording of a message, but not hold two versions at once.

Transactional emails, invoices, and PDF documents then stay in one language even though the site is translated. Tools that translate the browser layer do not save you, because they translate the page as it is displayed, and an email and an invoice are not a page.

The buyer gets a store in their own language and an order confirmation in a foreign one.

The mechanism that sorts this out: the language of a document is not a property of the document. It is a property of its recipient.

One order produces three documents with three addressees. The buyer's invoice goes out in the buyer's language.

The commission invoice and internal documents go out in the language of your team. The statement for the seller goes out in the language from their settings.

With a €1,000 cart and a 12% commission, the seller gets €880, whatever language they sold in, but the document for that €880 has to come out in a language they understand, and the invoice for the buyer in another.

Hence a requirement before the build: the buyer's language has to be recorded on the order the moment it is created. If the storefront does not pass that along, everything goes out in the default language.

You will not fix it afterward, because six months later you do not know which language the buyer read the page in. This class of failure is treacherous, because it looks like it works.

The data layer returns translations correctly; the middle layer drops the language of the request, so everything comes out in the default, and nobody sees an error.

And a multiplier nobody warns you about: templates are edited separately in each language, and a change does not propagate. Forty email templates in five languages are two hundred versions.

Fixing one sentence in the footer is five edits and five chances to drift apart.

What does multilingual search need beyond a translation?

A translated description does not make the product findable. The index has to know which language the text is in, so it can reduce words to their base form.

Without that, "pralki" will not find "pralka." In search engines, this is a separate component per language, ready for a few dozen, and for some, Polish among them, it takes an added plugin. Synonyms cannot be translated, because they belong to the language.

Six hundred pairs in the Polish set do not become a translation when the fifth language arrives. They become a fifth set of six hundred pairs to invent and maintain.

Language settings also cover alphabetical order, plural forms, and number formats. Sorting gives a different result in each language, and that is how it should be.

One apparently minor thing is worth asking: is adding a language to the index a switch on your side, or an order placed with the vendor? In some solutions, rebuilding the index needs the platform maker's team to step in, which turns "we are adding German" into a line item with a date you do not control.

What does a second language change about the rest of your build?

1. Expansion stops being a marketing decision

"We are entering the Czech market in the third quarter" is a question about the data schema and belongs to the conversation about organization and launch.

2. Lists gain value and text fields lose it

That shifts priorities in the taxonomy and in what you will realistically enforce on a seller.

3. Field ownership becomes a language question

Who is allowed to overwrite a translation: the seller, your team, the machine?

4. Catalog debt multiplies by languages

A product that is incomplete in one language is incomplete in one market, so a debt report with no breakdown by language tells you nothing. The method is in catalog debt.

5. Where the neighbouring topics live

Three neighbouring decisions have chapters of their own: commercial terms per country and the country sections of your terms, tax, and imports and customs. Prices per market are the chapter on pricing, and the language switch belongs to the chapter on the storefront.

In which order do you add a language to a marketplace?

1. Settle the schema before the first seller arrives. Language as a dimension of the value or language as separate fields: the only decision on this list you cannot change cheaply later.
2. Translate the structure and the lists. Finite, yours, one order. Only then anything else.
3. Record the source language per field. Without it, you do not know which text is the original and which is a translation. A machine that translates a translation produces a third text, drifting further from the truth with every pass. When you do not know the language, record it explicitly as undetermined. The standards for marking language have a separate value for that, and it is more honest than entering the platform's language.
4. Record the recipient's language on the order and check that it reaches the documents as well as the site.
5. Write the missing-translation policy into the seller terms, so hiding an offer is not a surprise.
6. Translate free content last, and in order of turnover rather than alphabet. By hand the pages that sell, by machine the tail, never the fields that carry liability.

One question at a demo that settles more than a whole feature matrix: show us the same product in two languages, and then the order confirmation and the invoice in the second one. If you hear that the documents "are configurable," ask for two versions at once.

Which mistakes do operators make about multilingual catalogs?

1. Multilingual bolted on as separate fields. It works for the second language and comes back to bite you on the third: every next one is a change to category templates, import files, and validation.
2. Translating free content before the lists. You spend the budget on millions of rows to skip a few thousand labels. The filters the buyer chooses stay in a foreign language.
3. No policy for missing translations. The system's default behavior settles it, or the word limit in a contract does. You find out from a complaint, or from a report where half the assortment has disappeared.
4. The machine let in as an overwrite. The translation replaces a better manufacturer description, and a year later you do not know which field is the original.
5. The buyer's language is not recorded on the order. A store in Polish, a confirmation, and an invoice in the default language. What you did not record, you cannot reconstruct.

What do you still have to settle about your own languages?

This is a map of design decisions. It is neither legal advice nor a recommendation of a translation vendor.

Three things we leave explicitly open.

The quality of a particular machine translation on your catalog. It depends on the language pair and the category, so the only honest answer is to measure it on a sample of your own descriptions before you sign for the whole catalog.

We give neither a rate per word nor a quality threshold.

How many languages you need. That is a decision about markets, and it comes before everything written here.

Requirements about the language of the information given to the buyer, warnings, and responsible-entity data in particular. The family of regulations to take to a lawyer: general product safety rules and the sector rules for your categories.

Our thesis is narrower and independent of those answers: every set of requirements will ask for the value of a specific field, in a specific language, for a specific recipient. A catalog that cannot point to that value is not ready for all the variants at once.

Summary: What does a second language really change?

The shape of your data, and then everything downstream of it. Language as a dimension of a value makes a new market a configuration change; a separate field per language makes it a taxonomy change every time.

After that, the work splits by layer: structure and lists are finite and yours, so they get translated first and once, while free prose is endless and goes last, by turnover. And the part that catches teams who did the catalog perfectly sits outside the catalog, in the emails, invoices, and statements, where the language belongs to the recipient rather than to the document.

Ask to see the same product in two languages, then the order confirmation and invoice in the second. Building a marketplace where the buyer's language lands on the order and travels to every document?

Talk to us about the build.

Frequently asked questions on a multilingual marketplace catalog

How should a marketplace store product data in several languages?

As one product where language is a dimension of the value, so adding a market is configuration rather than a schema change. A separate field per language works until the third language, then every new one means new attributes, new category templates, and new import and validation files.

A separate installation per market gives you several catalogs instead of one.

What should a marketplace do when a product translation is missing?

Split the page by layer. Structure, attributes, and list values always appear in the buyer's language because they are finite and yours.

Untranslated prose shows in the source language with a visible label. Hide only the fields whose content you answer for, such as warnings and safety information.

Why do order confirmations arrive in the wrong language?

Because the buyer's language was never recorded on the order. Some systems also hold one value per message key, so emails and invoices stay in one language however well the storefront is translated.

Browser translation tools do not help because an email is not a page.