A translation memory accumulates on its own as translation happens, but staying current is a separate matter altogether. In manual localization programs where each new model derives from the last, the TM is where the next document starts, so any change that reached the published file without passing back through the TM will resurface. Leave that work undone and leverage erodes while sentences you already corrected reappear in the next manual.
A TM builds itself
A translation memory stores every translated sentence as a pair, source and target. Work in Trados, memoQ, or any other standard platform and those pairs are written segment by segment as you go. The next time the same or a similar source sentence appears, the tool retrieves what you stored. How closely the two correspond is expressed as a match rate, and identical source text produces a 100% match.
Nobody has to build this. It is a byproduct of the work and it grows every time you translate, which is why “you need to manage your TM” tends to land strangely with people who know the process well. If the thing fills up by itself, what exactly is left to manage?
That question is what this article is about, specifically for manual localization work where similar documents go out in many languages, year after year.
Which programs this applies to
Not every translation project needs a managed TM. Contracts, marketing copy, website content, and video subtitles are commissioned once, delivered once, and closed out. The TM generated along the way goes to the client with the files and gets stored in case something similar comes up later. No one manages it, and no one needs to. A TM becomes an asset, and starts to require management, under conditions like these:
- Successive models in the same product family keep producing new manuals
- One source document goes out in many languages at the same time
- Documents stay alive after publication and continue through revisions
- Regulated or safety-related wording has to appear identically every time
- In-country reviewers are attached to each language
Two or three of these and the TM belongs under management. Manual localization programs and multilingual user guide production for hardware manufacturers usually meet all five.
From record to reference
On a one-off job the TM is a record. It documents what was translated and how, and it rarely gets opened again.
In a derivative program the role changes. The next model manual derives from the previous one, and the TM is where that derivation begins. Whatever sits in the TM lands in the next document. At that point the TM stops being a record and becomes a reference.
A wrong record is a wrong note in a file. A wrong reference produces a wrong deliverable, and the higher the match rate, the more quietly and widely it spreads. Reviewers do not reread 100% matches.
So in a derivative environment the point of TM management is that everything already stored is still correct today, which has very little to do with how much of it there is.
Four places where the TM drifts from the published file
Automatic capture alone does not keep a TM current. Real manual translation and localization workflows have gaps that nothing writes back into. Four of them account for most of the damage.
1. Changes made just before release
In the final stretch, single sentences keep changing. A specification gets corrected, a phrase gets swapped. Nobody runs the whole file back through the translation process for that. There is no time for it and no reason to do it, so the sentence gets handled on its own and dropped into the deliverable.
The change reaches the deliverable and stops there. The published file carries the change while the TM behind the full file still holds the old wording. On the next derivative that position comes back as the old sentence at 100% match, and because it is a 100% match, nobody reads it.
2. Content that never went through translation
A regional sales company or distributor sends wording written for its own market. Regulators specify mandated text that comes down as-is. These sentences have no source and target pair behind them, because all that ever existed was the finished wording.
If the wording will keep applying, it has to live in the TM. Otherwise the next derivative either drops it or retranslates it into something different. When that happens, someone constructs the source side and registers the pair by hand.
3. Edits returned by in-country reviewers
This is the largest category by volume. Where item 2 covers approved text that arrives without translation, this one covers a finished, translated document coming back with corrections marked on it. Regional sales offices or the client review team go through the files shortly before release. With a reviewer per language, you receive as many rounds of feedback as you have languages.
Those edits reach the deliverable, and they have to reach the TM as well. Skip that and the TM now holds something other than what was actually published.
4. Superseded versions left in place
Several translations of the same source coexist in the TM. Specifications changed and the phrasing moved with them, or terminology policy was revised. With no status marking which one is current, the tool offers one of them and the translator assumes the offered version is the latest. Each entry needs a status, and superseded entries need to stay out of search results.
How the update actually gets done
Once the need is recognized, every translation company and every manufacturer’s documentation team can build a procedure that fits its own process. Hansem Global arrived at the following through more than two decades of repeat manual localization for global manufacturers. This section and the two that follow describe how Hansem Global does it. Treat it as reference and adjust for your own workflow.
Assume regional distributors have marked up PDFs in their own languages and sent them back.
First, locate the segment
The edits sit on the translated file while TM search runs on source text, so without the source sentence in hand there is no way to find the entry.
So you take the marked position in the translated PDF and find the corresponding passage in the source PDF. First obstacle: the page numbers do not line up. Text expands and contracts by language, and pages shift.
With the source sentence in hand you search the TM. Second obstacle: if the sentence contains UI strings or non-breaking markup, it will not match as typed. You separate the tagged portion from the rest and search on the remainder.
When several candidates come back, you stack conditions. Filter on a distinctive string, then add a length condition if the list is still long, and keep going until you are down to a single entry.
Then you repeat the whole sequence for the next comment. Twenty languages means twenty sets of feedback, each handled the same way.
Do not edit on sight
Having located the entry, you still do not change it yet. First compare the translation stored in the TM against the translation printed in the PDF.
If the two differ, that is itself a finding. The TM and the deliverable separated at some point, and until you know where, the edit cannot go in. Apply it anyway and you are stacking a new error on top of an existing mismatch.
Not every edit goes in as received
It is tempting to treat a client edit as final. Some of them call for a stop and a check first, and which ones should be written down rather than left to whoever happens to be handling the file.
| Stop and confirm when | Why |
|---|---|
| The edit changes safety wording or a locked segment | The text was fixed through regulatory and safety review. That is not a call an individual reviewer makes. |
| The edit changes an approved term | Change it in one document and consistency breaks across every product that uses the term. |
| The edit contradicts the language style guide | Personal preference is running against an established standard. |
| The edit changes meaning or adds content that was not there | This falls outside translation. The source itself may need to change. |
| The TM translation and the PDF translation differ | The situation described in the previous section. Find the cause first. |
| The same sentence was edited differently in different places | Applying both puts a contradiction into the TM. |
When an item falls into this table, confirm before proceeding. Who signs off differs from one company to the next, so take it to whoever owns publication of that document.
What these cases have in common
None of them stops at the document in front of you. A TM flows onward into the next product and into the other language versions. One line applied today shows up in dozens of documents next year. An edit that is right for a single document can be the wrong edit for the asset.
TM management needs a system
What remains is when the update happens and who does it. Three approaches are common, and in Hansem Global’s experience none of them holds up.
| Approach | What goes wrong |
|---|---|
| Update immediately on every change | Work gets interrupted, and content that has not cleared review can land in the TM. |
| Leave it to whoever is handling the file | The stop-and-confirm cases get judged differently by different people. Nobody knows what went in and what was held. |
| Do not update at all | The most common choice, because nothing happens right away. Match rates drift downward and the drop cannot be traced. |
Four things to put in place:
- A numbered step in the process. TM update cannot be the thing that happens after the project closes if anyone has time. Give it a number in the process so that completion is verifiable and projects stop closing with it outstanding.
- Registration rules. What gets registered, what gets held, and how superseded entries are handled, including the confirmation cases listed in the table above.
- A named owner. One person carries this rather than each translator individually. That person verifies what was applied and keeps the rules current for everyone working on the files.
- A history. Which project, which language, who applied it and when, along with segment counts and elapsed time. Without that record, omissions stay invisible.
Registration is a procedure too
Even adding new translations is more than pushing the whole file in. You isolate the segments translated in this round, flag their status, and import only that status into the master TM. On import you decide whether existing entries get overwritten, and you record in a field who approved the content.
Why record the origin. When a sentence comes under suspicion later, you need to know which route it came in by. Without that, the only option left is to distrust the entire TM.
Who owns the TM
Vendors often hold the TM, which is reasonable since that is where the work happens. That arrangement says nothing about who owns the asset. If you change vendors and cannot take the accumulated TM with you, the compounding you built stops and resets at that moment.
Check whether your contract carries an extraction clause, and confirm that the copies you receive on a regular schedule actually open.
This part does not automate
In multilingual technical documentation, much of TM management stays manual, and current AI does not take it over.
| Handled automatically | Requires human judgment |
|---|---|
| Duplicate detection | Whether an edit falls into the stop-and-confirm list |
| Tag and formatting errors | Whether a change applies going forward or only this once |
| Glossary violations | Whether to construct a source side for an unpaired sentence |
| Match rate statistics | Why the TM and the deliverable diverged |
| Format inconsistencies | Whether an edit corrects an error or reflects local preference |
The right column cannot be settled by looking at the sentence. You need the history of that product, and you need to know how the same sentence was handled in the other language versions. That information lives in the project record rather than in the text.
What changes when the TM is managed
- Leverage goes up. When current sentences are properly registered, more of the next derivative gets caught by the TM. Less new translation volume means lower cost for multilingual technical documentation.
- Accuracy goes up. This matters more than leverage. Once matched sentences can be trusted, review scope can narrow. When they cannot be trusted, a high match rate still means rereading everything, and the TM has stopped earning its keep.
- Consistency holds. With the confirmation step working, individual reviewer preference stops moving the standard for an entire product family.
- Fewer omissions. Regulated sentences that have to appear are less likely to fall out of the next document.