How a product catalogue sends new descriptions to translation without an exported file

When a product catalogue refreshes every cycle, exporting files for translation becomes the slowest and least reliable part of the process. This article shows how one catalogue sends new descriptions straight from its source system to translation, with terminology checked before a single word is translated.

Consider a specialist e-commerce catalogue that translates a few million words a year and refreshes its catalogue every cycle. New products arrive, existing descriptions change, and every market needs the update at the same time.

For a team like this, the real cost of translation is not the price per word. It is what happens on the live product page when the same thing is called by different names.

One material, three correct names

A typical starting point is a single material. In German it has three correct names: Kunstleder, Lederimitat and veganes Leder. None of them is a translation error. Each one is a word a German shopper would use.

Imagine 500 products made from this material. Over several cycles, 180 are described as Kunstleder, 240 as Lederimitat and the rest as veganes Leder.

Now look at it from the shopper's side:

• A shopper who ticks the Kunstleder filter sees 180 products, not 500.
• A shopper who searches for Lederimitat finds 240 and misses the rest.
• The products are in stock, correctly priced and well described. They are just invisible to anyone who used a different word.

No single translator did anything wrong. Each batch was translated correctly on its own. The problem only shows up across batches, which is exactly where a file-based workflow cannot see.

Step 1: The source system sends content through the API

Nobody exports a file. The system that already holds the product content sends it to translation directly. That can be a PIM, a product feed or an automation tool. For implementation detail, see How to use TextUnited API .

Each item travels with the source system's own identifiers, such as the product ID, field name and category. When the translation comes back, it lands in the right product and the right field. There is no spreadsheet to match up and no copy and paste.

This also means translation starts when the content is ready, not when someone has time to prepare a file.

Step 2: Terminology is checked before translation

Before any translation starts, the terms in each batch are pulled out. New product names, materials, features and category words are listed for review.

A person then approves them. Only approved terms go into the terminology repository. In our example, this is the moment someone decides that the catalogue uses one name for the material in every German description.

This order matters. Fixing a term after translation means finding and correcting every product that used the wrong one. Deciding it before translation means it is right the first time, in every product of the batch.

Step 3: Translation follows the approved terms

Translation then works with three things in place:

• Terminology: approved terms are enforced, not just suggested.
• Style guide: tone, formatting and market rules are applied, such as how to write sizes or address the shopper.
• Translation memory: sentences translated in earlier cycles are reused, so unchanged text stays the same and costs less.

TextUnited connects these governed resources to the workflow. Read more about translation memory and terminology and how this scenario remains illustrative rather than a named client case study.

Step 4: Every segment gets a score

Each translated segment receives a quality score. The score decides what happens next: publish, or send to a person for review. This is the same distinction explained in LQA versus human review .

The threshold is not one number for everything. It is set per market, product category and content type. The team decides where the bar sits, based on what an error would cost.

This puts review effort where the risk is, instead of spreading it evenly across millions of words.

Step 5: A proofreader samples the output, whatever it scored

Scores are useful, but they are not the final word. A proofreader also reviews a sample of the output, including segments that passed their threshold.

This is how the team finds what a score cannot see. A sentence can be fluent and still use a word your shoppers do not search for. Sampling high-scoring content keeps the scoring honest and shows whether thresholds are set in the right place.

Step 6: Each batch improves the next one

Nothing learned in one cycle is lost. Approved terms stay in the repository. Sampling findings feed back into terminology, the style guide and the thresholds.

The next batch starts from a better place than the last one. Over time, fewer terms need approval, fewer segments need review, and the catalogue stays consistent as it grows. See how this works in TextUnited’s workflow integration case studies.

How this differs from a file-based workflow

In a file-based workflow, someone exports the new descriptions, sends the file, waits, and imports the result. Each file is handled on its own. For a related look at this manual-work problem, see the copy-paste tax in translation .

For the owner of product content, the intended benefit is visible on the live site: filters can return the full range, search can find matching products, and each refresh is designed to require less manual work than the one before.

Start with one product page

You do not need to rebuild your workflow to find out whether this problem affects your catalogue. One published product page is enough to start.

Send us the link to a product page in one of your markets. We will check how its key terms are used across your catalogue in that language, and show you where filters and search could be missing products.

*Note: The figures in this article (500 products, 180 described as Kunstleder and 240 as Lederimitat) are illustrative. They show how inconsistent terminology affects filters and search, and do not describe a specific client's catalogue.