Translation memory definition

To reuse translations across similar content, store every approved translation as a source and target pair in a translation memory, then match new text against it so only unmatched segments go to a translator. The smaller the unit you translate, the more matches you get. Sanity stores content as typed fields rather than finished pages, so translation connectors and AI workflows work on individual fields, which is what lets a memory match at field level, with a person reviewing before publish.

How does translation memory work?

Translation memory works by splitting source text into segments, typically sentences, and storing each one alongside its approved translation. When new content arrives, the translation tool compares each new segment with stored segments before anyone starts translating.

A segment that matches a stored one word for word is an exact match, and the saved translation is reused as is. A segment that is close but not identical, such as a sentence with one product name swapped, is a fuzzy match. The tool shows the earlier translation and a similarity score, expressed as a percentage, and the translator edits it instead of starting from nothing. Segments with no useful match are translated fresh, and once approved they are added to the translation memory so the next project can reuse them.

Over time, a translation memory becomes a record of how an organization says things in each language. That record drives two benefits: consistent wording across documents, and less new text that has to be paid for.

How do I reuse translations across similar content to reduce costs?

You reuse translations across similar content by ensuring every approved translation lands in a translation memory and every new piece of content is checked against it before it goes out for translation. A practical sequence has five steps.

First, break content into small, stable units, such as individual fields or sentences, not whole pages. Second, run new or changed content against the translation memory and separate exact matches, fuzzy matches, and new segments. Third, reuse exact matches directly, with a quick check that they still fit their context. Fourth, send fuzzy matches and new segments to a translator or a machine translation step, followed by human review. Fifth, write every approved result back to the translation memory so it is available for the next round.

The savings come from the second and third steps. When a vendor prices matched segments below new words, every match is cheaper work, and content that only changed slightly costs a fraction of a full retranslation. Keeping wording consistent in the source language also helps, because two sentences that say the same thing in slightly different ways will not produce an exact match.

How is translation memory different from machine translation, termbases, and LLM translation?

Translation memory reuses translations that people have already approved, while the other tools generate new translations or constrain them. They solve different problems and work best together.

Machine translation produces a new translation automatically from statistical or neural models. It is fast, but it does not know how your organization translated a sentence last month. A termbase, also called a glossary, is a list of approved terms and their translations, such as product names and regulated phrases. It governs individual words, while a translation memory governs whole segments. AI translation with large language models (LLMs) generates translations that can follow instructions about tone, audience, and context, but its output can vary from run to run.

In a combined workflow, the translation memory supplies exact and fuzzy matches first, the termbase keeps key terms correct, and machine translation or an LLM drafts only the segments that have no match. A human reviewer then approves the result, and the approved text feeds back into the translation memory.

Why does structured content make translation memory more effective?

Structured content makes translation memory more effective because it supports translation at the field level, not the page level. Structured content means a page is stored as separate, labeled fields, such as a title, a summary, a price note, and body text, rather than as one block of formatted text.

When each field is translated as its own unit, the same product description or legal notice reused on many pages produces the same segment every time, so the translation memory recognizes it and reuses the translation. Page-level translation tends to bundle layout, navigation, and one-off copy together, which gives the memory messier segments to match against.

Structured content also makes changes visible. If an editor updates one field, the system can identify which field changed and send only that field for translation, while every untouched field keeps its existing translation. Retranslating a whole page because one sentence changed is the most expensive way to localize, and field-level change tracking avoids it.

Where does Sanity fit in a translation memory workflow?

Sanity fits in a translation memory workflow as the place where structured content is modeled, localized field by field, and sent to translation. Sanity is the AI Content Operating System, and its content model stores each piece of content as typed fields, so localization can be defined per field rather than per page.

Because content is already split into fields, translation connectors can pass individual fields to translation services, where translation memory and termbases are applied, and return the translated fields to the right place. AI content workflows can draft translations for fields with no memory match, following instructions about tone and terminology.

Human review stays in the loop throughout. Translators and editors check and approve translated fields before they publish, and approved translations are the ones worth keeping in a translation memory. The result is that teams spend translation budget on new and changed text, not on content that has already been translated.

Last updated: October 29, 2026