Catalog Localization at a European Home Goods Retailer
An example project: a home goods retailer translates its whole 200,000-product catalog and 25,000 weekly changes into five languages with an open model on one dedicated GPU, with its glossary checked in code and native speakers reviewing a sample, for about a seventh of what partial human translation costs today.
This is an example project, not a customer story. The company is made up, and every number on this page is an assumption stated so you can replace it with your own.
The whole catalog is translated for about $3.6 million a year less than part of it costs today
Build cost assumes engineers at $180,000 a year fully loaded. Time from other staff, such as reviewers labeling examples, is not counted. Payback is counted from go-live. See the arithmetic.
Most of the catalog is only sold in one country
An online retailer sells furniture, textiles, lighting and kitchenware in six European countries: the UK, Germany, France, the Netherlands, Spain and Italy. Its catalog has about 200,000 products, written in English in its product information system. Each product has a title, five bullet points and a description, about 160 words in all. Every week about 2,500 products are added and about 22,500 are changed, usually a bullet point or a line of the description.
Translation into German, French, Dutch, Spanish and Italian goes to an agency at a blended $0.09 per word, after its translation-memory discounts. The budget covers about 180,000 English words a week, so the agency only gets new products in the core ranges and changes to products that were already translated. Turnaround is eight to ten business days. About 130,000 products have never been translated, and are sold only in the UK store.
The brand also has rules the agency gets wrong often enough to cause rework: product line names such as Fjord or Linen Loft are never translated, materials and care terms must use the same wording as the size and care guides, and titles have length limits in the store.
The goal is to sell the whole catalog in all six countries, with each week’s changes live in every language within two days, and to spend less than today.
A batch job with the model in one step
The model translates. Selecting what changed, enforcing the glossary and publishing are the retailer’s own code, and the reviewers work in the translation tool they already use.
Find what changed
retailer's codeA weekly export from the product information system lists new and changed text, split into segments (title, each bullet, each sentence of the description). Segments that match the translation memory exactly reuse the existing translation and are not sent to the model.
Build the request
retailer's codeFor each product and language, code looks up the glossary entries that appear in the English text and puts them in the prompt with the required translation, along with the language’s style rules and the title length limit. The instructions are the same for every request in a language, so they are cached.
Translate
modelThe model returns the translated segments in the same structure it received. The endpoint is set to favor throughput, since nobody is waiting on a single request.
Check in code
retailer's codeChecks the model cannot be trusted to do: every glossary term has its required translation, product line names are unchanged, numbers and units match the source, markup is intact, and titles fit the length limit. A segment that fails is sent once more with the failure stated, then goes to a reviewer.
Review a sample
native-speaker reviewersReviewers check a sample of each language in the agency’s translation tool and correct errors. Corrections go into the translation memory, and repeated errors become glossary entries or prompt rules.
Publish
retailer's codeApproved text goes back into the product information system and out to each country’s store. Products that were only sold in the UK go live in the other five stores as their text is published.
The weekly run takes about two hours on one GPU
The arithmetic we would start from. Profiling on real traffic replaces these estimates before anything goes into a contract.
| English words a week (2,500 new products at 160 words, 22,500 changed at 16 words) | 760,000 |
|---|---|
| Translated words a week, into five languages | 3.8M |
| Requests a week (one per product per language) | 125,000 |
| Input tokens a week (about 800 of instructions and glossary per request, plus the English text at about 1.3 tokens a word) | about 105M, most of it cached instructions |
| Output tokens a week, at about 2 tokens per translated word | 7.6M |
| Starting configuration to profile | gemma-3-27b-it on one RTX PRO 6000 (96 GB) |
| If one GPU sustains 1,000 output tokens a second across the batch | about 2.1 GPU-hours a week |
| Backfill: 130,000 products, 104M translated words, 208M output tokens | about 58 GPU-hours, about 14.4 hours on 4 GPUs |
Translation writes about as much as it reads, so output throughput sets the GPU time. German, French, Dutch, Spanish and Italian often take more tokens per word than English, and the figure of 2 output tokens per translated word is an assumption to measure on real text in each language before anything else.
The 27B model’s weights are about 55 GB in 16-bit precision, which leaves about 40 GB of a 96 GB GPU for the cache. That is enough to process many products at once, which is what a batch job needs.
The rate of 1,000 output tokens a second per GPU is the assumption to check first during profiling. At half that rate the weekly run takes about four hours, which still fits the two-day target easily. The backfill is a one-off batch. The endpoint’s maximum workers can be raised for a day and lowered again afterwards.
How the numbers add up
| Agency translation today: 180,000 English words a week into five languages at $0.09 a word | $4,212,000 a year |
|---|---|
| The same agency for every weekly change (760,000 words into five languages) | $17,784,000 a year |
| Native-speaker review of a 10% sample of 3.8M words a week, at $0.03 a word (a reviewer at about $36 an hour checking 1,200 words an hour) | $592,800 a year |
| One RTX PRO 6000 kept all year, at our reference price of $1.25 per GPU-hour | $10,950 a year |
| Ongoing cost with the model, covering every weekly change | about $604,000 a year |
| Backfill of 130,000 products: agency rate, against GPUs plus a 10% review sample | $9,360,000, against about $312,000 |
| Saving a year | about $3.6 million |
| One-time cost: one engineer for three months ($45,000) plus the backfill review ($312,000) | about $357,000 |
| Payback on the one-time cost, from go-live | about 5 weeks |
At these assumptions the yearly cost falls from about $4.2 million, for partial coverage, to about $0.6 million for the whole weekly flow. The first year also carries about $357,000 of one-time cost: $45,000 for the build and $312,000 for the backfill review. The saving covers it in about five weeks.
The review rate decides the cost, and the GPU barely does. At a 30% sample, review costs about $1.78 million a year, still well under today. Reviewing every word costs about $5.93 million a year, more than today’s spend but with the whole catalog covered. The real risk is a language where review finds so many errors that reviewers have to rewrite instead of check. At that point the work is post-editing, which costs more per word than review, and full coverage stops being cheaper. The pilot shows which case each language is in.
A sensible plan is to review every word of a language for its first weeks, then drop to 10% once errors per 1,000 words stay under the bar the localization lead sets. Titles of best-selling products can stay at full review, since they also appear in search ads.
The benefit that does not show in the table is the assortment. About 130,000 products that are sold only in the UK today go on sale in five more countries.
How the project would run
Build the evaluation set
weeks 1 to 2The retailer already has agency translations for about 70,000 products. Pull 1,500 across categories with all five languages, plus the glossary, and hold back 300 that no prompt or fine-tune ever sees.
Compare models on the held-out set
weeks 3 to 5Run three or four candidate models on a trial endpoint. Native-speaker reviewers score each output blind, against the agency translation, using an error typology the localization lead agrees, and the code checks report glossary failures. Pick the smallest model that meets the bar in every language, not on average.
Pilot on untranslated products
weeks 6 to 9Translate 5,000 products that are not sold outside the UK yet, into all five languages, with every word reviewed. Nothing already on sale changes, so mistakes cost little. This gives the real error rate per language and the real tokens per word.
Weekly run, one language at a time
week 10 onwardMove the weekly run to the model for the language that scored best, with full review at first, then add the others. Lower each language’s review rate to 10% once its error rate holds for three weeks. The agency moves from translating to reviewing.
Backfill
after the weekly run is stableTranslate the 130,000 untranslated products in batches by category, with the endpoint scaled out for a day per batch. Review the first batch of each category at a higher rate, since new categories bring new vocabulary.
What to measure
Errors per 1,000 reviewed words, by language
Using the agreed error typology, with major and minor errors counted separately. One average across languages hides the weak one.
Code check failures
The share of segments that fail the glossary, number or length checks on the first attempt. If it rises, look at the glossary and the prompt before the model.
Time from change to published
From the weekly export to live in all five stores. The target is two days; the agency takes eight to ten.
Sales of newly translated products
Orders and returns, per country, for products that were UK-only before the backfill. Returns that cite a wrong description point to translation errors the sample missed.
Models to test first
Candidates from our catalog, not a ranking. The project picks one by testing them on its own labeled examples.
gemma-3-27b-it
The starting choice. Google reports out-of-the-box support for over 35 languages and pretrained support for over 140. Its 16-bit weights fit on one 96 GB GPU with room for the cache. Check the Gemma license terms for your use.
Mistral-Small-24B-Instruct-2501
Mistral names English, French, German, Spanish, Italian and Dutch among the languages it supports, which covers all five targets. A dense 24B model of similar size, with a 32K-token context and an Apache 2.0 license.
Qwen3-30B-A3B-Instruct-2507
Alibaba reports that the Qwen3 family supports 119 languages and dialects. About 3B of its 30B parameters are active per token, so it may finish the weekly run and the backfill in less GPU time. Test whether its error rate holds in every language.
Qwen3-235B-A22B-Instruct-2507
A much larger model to test against the others. Its 16-bit weights are about 470 GB, so it needs tensor parallel across four H200 GPUs on one node. The weekly run is short enough that this costs little. It is only worth it if it lowers the review error rate enough to cut the sample.
Sizes are total parameters as listed in our catalog. Mixture-of-experts models use only part of them for each token. Check each model's license for your use. Several, such as the Llama and Gemma licenses, carry their own terms.
When fine-tuning helps
Translation suits fine-tuning here because the training data already exists: about 70,000 products with agency translations in five languages, and from the pilot onward every reviewer correction. Fine-tuning helps with house style and recurring home goods vocabulary, such as fabric names and furniture parts, that a general model translates inconsistently.
Fine-tune after the pilot, once the review logs show which errors repeat. A separate adapter per language can run on one endpoint. Keep the code checks in place either way, since the glossary changes faster than any model is retrained.
When the data has to stay put
Product text is not sensitive once published, but unreleased products and next season’s ranges are, and a retailer may not want them processed outside its own environment before launch. The endpoint can run in the retailer’s own environment or in a specific region, such as inside the EU.
Tell us about your project
Bring us your volumes and a sample of your data. We will tell you which models to test, what the endpoint would need, and what a performance commitment would cover. Self-service accounts can create inference endpoints to try the platform, but not on our top-tier GPU capacity.