Contents7
A translation memory is the database in which each translated sentence of a site is stored alongside its translation, language by language. For a company that publishes in several languages, it decides two things: what each update costs, and who keeps the work already paid for. This article looks at it from the company’s side, not the translator’s; it complements our articles on website translation and opening new markets.
What is a translation memory?
The memory splits the text into segments: a sentence, a heading, the label of a button. Each segment is stored with its translation in each language.
What the memory does on the next pass
- Splitting
The text is split into segments again.
- Lookup
Each segment is looked up in the memory.
- Reuse
The segments found reuse their translation as it stands.
- Translation
The missing segments are translated, then join the memory.
That leaves deciding what “already translated” means. Two settings coexist:
- Exact matching. Each segment receives a fingerprint computed from its text. One extra comma changes the fingerprint, and the segment is sent for translation again. That is the principle of our own pipeline: only new or modified segments are sent for translation.
- Fuzzy matching. A segment is reused if it is similar enough to a known segment. According to DeepL’s documentation on its translation memories, a stored segment applies by default as soon as it matches at least 75% of the source text, which catches typos and small variants. The threshold goes down to 50; at 100, only exact matches count.
On a website, prefer exact matching, or a threshold close to 100. A sentence that changes by only a number or a negation looks very much like the old one: with a low threshold, it risks receiving the old translation, when the changed word is precisely what matters.
What does a company gain with each update?
A site is alive: a page is added, a price changes. The memory changes what each of these actions costs, in three ways.
It only charges for what has changed. Without a memory, an update retranslates the whole page, or asks someone to spot by hand what has moved. With it, only new or modified segments are sent again.
From the field
On Palmora Property, a real estate listings site that we operate, served in six languages, the translation pipeline stores each segment under its fingerprint: 95% of segments come out of the cache after the first pass, without calling the AI again. That figure holds for that site: the share reused depends on what changes from one update to the next.
It keeps the same words everywhere. Without a memory, nothing guarantees that the same sentence receives the same translation on two pages, or from one pass to the next. With it, a “Request a quote” button is worded the same way across the whole site, and the reader does not wonder whether they are two different things.
It keeps the corrections. When a person corrects a translation, the correction must go into the memory, marked as reviewed. Corrected only in the published page, it risks being overwritten on the next pass, if the page is rebuilt from the memory. Corrected in the memory, it applies to every page that uses the sentence.
Translation memory or glossary: what is the difference?
The memory keeps sentences; the glossary fixes words. In its documentation on Cloud Translation glossaries, Google defines it as “a custom dictionary the Cloud Translation API uses to consistently translate the customer’s domain-specific terminology”. Two of its examples show the use: a product name that is not translated (Google Home stays Google Home), and an ambiguous word that you tie to your field (the English word “bat” can mean a piece of sports equipment or an animal).
The glossary is written before the first pass: brand names, trade terms, tones to avoid. The order matters, because the memory faithfully records what it is given. Without a glossary, a term translated three different ways on the first pass is kept in three ways, then served again like that at every update.
Where does the memory live, and who owns it?
A translation memory necessarily lives somewhere: in the translator’s or agency’s software, in the account you open with a machine translation service, or in your own system. At DeepL, for example, memories are stored in your account, where they are uploaded from its interface or through its API, and each translation request can designate one.
It is first a matter of contract. If the memory stays with the provider, changing provider means paying again for sentences already translated and losing the reviewed corrections. So write into the contract that it is delivered to you, along with the glossary.
The exchange format is called TMX. Google describes it as “a standard XML format for providing source and target translations”, and its API accepts it, in version 1.4, to load a glossary. DeepL exports its translation memories as TMX, the only export format offered in October 2026, and according to its documentation imports no other. For the glossary, keep the source file, a simple table: Google specifies that its service does not version glossaries, and that rolling back requires the original file.
Key takeaway
Four questions to ask before handing over your translations
- Delivery: are the memory and the glossary delivered to me, and how often?
- Format: TMX for the memory, a table for the glossary?
- Review: are the segments reviewed by a person distinguished from those translated by the machine?
- Invoicing: is a sentence that has already been translated invoiced again when it comes back on another page?
What a translation memory does not do
It does not check that every language has all its pages. That is the job of the parity check: every content key exists in every language, and no page announces a missing version. Palmora Property’s pipeline keeps this strict parity of keys across languages; what happens when a language is missing somewhere is described in the hreflang mistakes we have run into on a six-language site.
Watch out
A memory does not correct a bad translation: it repeats it
A stored mistake comes back on every pass, on every page where the sentence appears. Hence the order: review, then store.
Which pages to have reviewed, and when, is the subject of our method for translating a site with AI.
Where to start
Start from what you already have. If a translator or an agency has translated your site, ask them for the memory’s TMX export and the glossary. If there is neither, first write the glossary of the terms that are not up for discussion, then decide where the memory will live before the next update.
To set up a translation memory that stays with you, tell us about your languages and how often you update: we start from what you have already translated.
Frequently asked questions
Is a translation memory still useful with machine translation?
Yes. A machine translation engine, or an AI model, translates quickly, but nothing guarantees that it renders the same sentence the same way from one pass to the next. The memory fixes the version that was kept and reviewed, and avoids calling the engine again for what has not changed. Some services build it in: when a segment matches, DeepL reuses the stored translation instead of producing a new one.
Do you have to retranslate everything when you change translation tool?
No, if the memory belongs to you and can be exported. The segments already translated and reviewed remain valid: only the new ones are sent to the new tool, and the glossary keeps the terms aligned between the old and the new. Even so, compare the two tools on a sample of your own texts, language by language, before switching. If the memory stays with the former provider, everything is sent for translation again.
Can you build a translation memory from a site that is already translated?
Yes. The pages already translated are split into segments, which are paired language by language: the French sentence with its English version, the heading with its heading. These pairs are reviewed before they enter the memory, because an old translation may contain mistakes you do not want to serve again. After that, each update starts from this base instead of retranslating the whole site.
Is a translation memory worth it for a small site?
Yes, as soon as it is updated. A site translated once and never modified does not need one. But every correction and every new page raises the same question: do you retranslate everything, or only what has changed? The memory answers by itself, and it prepares the day you change translator or tool.
Sources
- DeepL’s documentation on its translation memories (new tab)developers.deepl.com
- Its documentation on Cloud Translation glossaries (new tab)docs.cloud.google.com
- DeepL exports its translation memories as TMX (new tab)developers.deepl.com
Jim · founder of Brain Plus AI
Also in translation and new markets
Choose and price7 min
Translating your website with AI: automatic or reviewed?
Having everything reviewed is expensive, and reviewing nothing lets errors through in languages that nobody at your company reads. The split is decided page by page, depending on what each page commits you to.
Practical guide6 min
Hreflang and multilingual SEO: the costly mistakes
Hreflang pointing to pages that do not exist, a poorly chosen x-default, 404s in the wrong language, untranslated titles, a language routed but forgotten elsewhere: the mistakes we found on multilingual sites we operate, and how to avoid them.