What is Translation Memory and how does it work?

Translation memory ™ is a database of segments you have already translated, paired with their source text. When new text comes in that matches something in the database, the stored translation is offered for reuse.

That is the whole idea. Its value is not cleverness — it is that software copy is far more repetitive than it feels while writing it, and a mature product accumulates a memory that answers a large share of new work for free.

How it works#

Three steps, repeated forever.

1. Store. Every time a translation is approved, the pair is written to the database:

source: "Your changes have been saved"
target: "Vos modifications ont été enregistrées"
locale: fr

2. Look up. When a translator opens a segment, the system searches the memory for source text resembling the new source text and ranks the results by similarity.

3. Offer. Matches appear alongside the segment, best first. The translator accepts one, edits one, or ignores them.

There is nothing to configure and nothing to maintain. The memory fills up as a side effect of translating, and it gets better the more you use it.

Match quality#

Matches are scored as a percentage, and the vocabulary is worth knowing precisely because pricing and workflow decisions get built on it.

The threshold is adjustable, and the trade-off is real: a low threshold surfaces more suggestions including weak ones, a high threshold surfaces only strong matches and hides useful near-misses. Translators tend to settle somewhere around 75% once they have a feel for a particular project’s memory.

A 100% match is not automatically correct. The classic counterexample is a single word: Open as a button label and Open as a ticket status are the same source string and different translations in most languages. This is why context matters, and why an in-context match — identical source and identical neighbours — is treated as a stronger signal than a bare exact match.

Project memory and global memory#

Most systems separate memory by scope, and the distinction matters more than it first appears.

Project memory learns from your own translations. It carries your product’s voice, your terminology and your decisions. It is small at first and becomes the more valuable of the two over time.

Global or shared memory aggregates translations across many projects — in WebTranslateIt’s case, more than 24 million translations contributed by projects that opt in. It is enormously useful on day one, when your own memory is empty, and for the generic strings every application contains: Cancel, Settings, Password must be at least 8 characters.

The sensible configuration is both, with project memory ranked first. Your own approved translation of a string should always outrank a stranger’s, however good theirs is.

WebTranslateIt also lets you point a project at another project’s memory, which is the mechanism for sharing a memory across a product family — a web app, a mobile app and a marketing site that should all use the same words.

The thing that quietly destroys match rates#

Here is a failure that is invisible until someone measures it. These three strings are the same sentence:

Android   I have %1$s dogs
iOS       I have %@ dogs
Rails     I have %{count} dogs

To a memory doing exact string comparison, they are three unrelated entries. Translate the Android string into Japanese and the iOS string still shows no match. A cross-platform product can be translating the same sentences three times over and see nothing wrong in any report.

The fix is normalization: strip placeholders and decode HTML entities before comparing, so all three reduce to I have dogs and match each other. When a match is reused, the placeholders are adapted into the syntax the destination project uses, so a Rails %{count} comes back out as an iOS %@.

WebTranslateIt does this automatically. Normalized matches are labelled as such and rank below exact matches, so an exact hit always wins; existing memory was backfilled into the index, so it applies retroactively rather than only to new translations.

If you are evaluating platforms and your product spans more than one, ask specifically how the memory handles placeholder variance. It is the difference between a memory that works across your stack and one that works within each silo. The placeholder formats cheat sheet covers the syntaxes involved.

Where the value actually comes from#

Three places, roughly in order of size:

Iteration. Software copy is revised constantly. Changing “Your changes have been saved” to “Your changes were saved” is a high fuzzy match, not a new translation. Products that ship weekly get most of their value here.

Repetition across surfaces. The same message appears in the web app, the mobile app, the API error response and the notification email. Translate once.

Consistency. Underrated. A memory means the same source sentence gets the same translation every time, without anyone having to remember what was decided last quarter. That consistency is what makes an interface feel coherent in a language you cannot read.

Limits#

It does not understand anything. It matches text. A high match with a subtly different meaning is genuinely dangerous, because it looks safe — which is why fuzzy matches should be edited rather than accepted wholesale.

It inherits your mistakes. A bad translation approved once will be offered forever. Memories need occasional cleaning, especially after a terminology change.

It is worth nothing on day one for your own content, which is exactly why a shared global memory is valuable at the start and less so later.

It does not replace a term base. Memory works at the segment level; a term base works at the word level and enforces consistency for terms that appear inside otherwise-unrelated sentences. They solve adjacent problems and you want both.

Keeping it healthy#

A memory is a database that only ever grows, and untended databases rot. Three habits are enough:

Clean after a terminology change. Renaming a feature invalidates every stored segment mentioning it. Those segments will keep being offered as high-confidence matches carrying the old name.

Do not let unreviewed machine output in. If raw MT is written to the memory it comes back later indistinguishable from a human translation somebody approved. Keep the two separable.

Prune duplicates and near-duplicates periodically. Several stored variants of the same source text mean the translator is choosing between your own past decisions, which is exactly the inconsistency the memory was supposed to prevent.

Getting an existing memory in#

If you have translation history in another system, export it as TMX and import it. In WebTranslateIt that means creating a project, setting up the language pairs, uploading the TMX, and then pointing your working project’s translation resources at it.

Do this before starting a new project rather than after. A memory imported six months in has missed the six months of work it would have accelerated.

And check the export path on any platform you adopt. Your translation memory is an asset you paid to build, and it should be portable on the way out as well as the way in.