Who owns your translation memory? Avoiding quiet vendor lock-in

Most teams find out how this works at the worst possible moment. They decide to change translation suppliers, send a friendly message asking for a copy of their translation memory, and discover that what they assumed was a file handover is actually a negotiation.

The confusion is understandable, because a translation memory does not look like an asset. It is not a build, it is not a design document, and nobody on the team ever opens it. But it is the accumulated record of every wording decision you have paid for across every update — and once you have several years of a live game in it, it is worth more than any single delivery you have ever accepted.

This article is about that asset as a procurement problem: what you are actually asking for, how lock-in forms without anyone intending it, what to request and in what format, and how to move to a new supplier without paying to translate the same lines twice.

What you are actually asking for

Asking for the translation memory is a request for less than most people imagine. The memory is the sentence pairs, and it is only one part of what the work produced. A complete picture is four things:

• The translation memory — every confirmed source-and-target segment pair, per language pair
• Terminology — the glossary or termbase of terms with an agreed rendering, including the ones that must never be translated
• The style guide — tone, formality level, how to address the player, formatting conventions, per language
• The query log — the questions translators asked and the answers your team gave

The query log is the underrated one. It holds the reasoning behind every non-obvious choice: why a character uses that speech pattern, why a piece of terminology deviates from the obvious rendering, what an ambiguous source line actually meant. Without it, a new supplier re-asks questions your team already answered years ago, and — because the people who answered them may have left — sometimes gets a different answer, which then shows up as an inconsistency in the shipped game.

The style guide has a similar property. A memory tells the next translator what was written; a style guide tells them why it was written that way, which is what they need in order to extend it consistently instead of merely matching it.

Ownership, possession, and the gap between them

Three separate questions hide behind who owns the translation memory, and confusing them is what causes the surprise.

The first is ownership: what the contract says about who holds rights in these assets. The second is possession: who physically has a current copy. The third is usability: whether the copy you receive can actually be loaded into another tool by another supplier. All three have to be yes for the asset to be yours in any practical sense.

The common failure is a contract that clearly assigns all deliverables to the studio, a memory that lives entirely inside the supplier's tooling, and an export that nobody has ever requested. On paper the studio owns it. In practice, at the moment of a switch, the studio is asking a party it is leaving to perform a favor with no deadline attached — and even a cooperative supplier is not going to prioritize it during someone else's crunch.

One more wrinkle is worth knowing about before you ask. If a supplier has merged memories across clients, or built a general games memory that your project contributed to, they cannot hand you the whole thing, because it contains other clients' content. That is a legitimate reason for a limited answer, and it is also why segregation of your project's memory is worth agreeing on at the start rather than discovering at the end.

How lock-in actually forms

Nobody sets out to lock you in. It forms out of defaults, and the mechanism is pricing rather than possession.

A supplier who holds your memory can quote new work against it: repeated and near-repeated content is faster for them, so their quote reflects that. A challenger without the memory quotes the same batch as new translation, because for them it is. The incumbent therefore looks cheaper on every comparison, not because they are better or even because their underlying rate is lower, but because they are the only party allowed to reuse work you already bought.

The other half of the cost is not on any invoice. Re-translating existing content produces new wordings for lines already in players' hands, so a supplier change becomes visible in the game as terminology drift — a skill, an item, or a character's manner of speaking that quietly changes between one patch and the next. In a series or a long-running live game, that drift accumulates across titles.

None of this is dramatic, which is exactly why it persists. There is rarely a moment where someone decides to accept lock-in; there is only a series of quotes where staying looks like the sensible choice.

What to ask for, in what format, and how often

Format matters less than most discussions suggest, as long as it is portable. Translation memory has a standard interchange format, terminology has one too, and a clearly specified spreadsheet is an acceptable substitute for terminology if both sides agree on the columns. What is not acceptable is a proprietary export that only reopens in the tool it came from.

Cadence matters more than format. A memory delivered at every milestone, or at minimum every quarter, means the copy you hold is never far behind reality, and the handover is a routine file transfer rather than an event. Scope matters too: all language pairs, including the ones where the project stalled or the language was later dropped, because those are exactly the ones you will want if you revive that language.

A useful way to specify it is to describe the package rather than the clause. Something like this is unambiguous enough that both sides know whether it was delivered:

handover-2026-08/
  tm/
    en-ja.tmx          all confirmed segments, all builds to date
    en-de.tmx
    en-zh-Hans.tmx
  terminology/
    glossary.tbx       or glossary.csv with the agreed columns
  guides/
    style-guide-ja.pdf
    style-guide-de.pdf
  decisions/
    query-log.csv      question, answer, date, who decided

Checking that what you received is usable

A file arriving is not the same as an asset transferring. Verify on receipt, while the relationship is still live and questions still get answered — not two years later when you finally need it.

• Segment counts are in the range you expect for the volume you have paid for, per language pair
• Language codes are correct and consistent, including the region-specific ones like the two written forms of Chinese or Latin American versus European Spanish
• The file opens without mojibake and non-Latin scripts display correctly
• Placeholders, variables, and markup survived the export instead of being stripped or escaped into something else
• Metadata is present — creation dates and origin — since a memory with no provenance is much harder to trust selectively
• A spot check of ten lines you know were difficult actually appear, with the agreed wording
• The file imports successfully into a second, different tool

The last item is the one that decides the others. A memory that only opens in the supplier's own tool has not achieved portability, whatever the file extension says. Doing this import test once, early in the relationship, converts an assumption into a fact at a point where it is still cheap to fix.

Switching without re-translating everything

With the assets in hand, a supplier change becomes a supply change rather than a restart. The sequence that works is roughly this: export and verify, hand the memory and glossary to the new supplier as part of the brief, and then reconcile the memory against the text that is actually shipping. That last step matters because the build is the truth, not the memory — years of hotfixes and in-engine edits mean the two have drifted, and the new supplier should be matching what players see.

Then run a small paid pilot before the first real batch: a few hundred segments that exercise your typical content, translated with the memory available. You are checking whether the new supplier will honour the existing voice and terminology or quietly improve it, and how they handle near-matches from the memory — accepting them, flagging them, or rewriting them.

That pilot forces a decision worth making explicitly. A new supplier will disagree with some past choices, and some of those disagreements will be correct. You can prioritize consistency with the text players already have, or you can take the opportunity to fix long-standing terminology, but doing both silently produces the worst outcome: half the game in the old wording and half in the new, with no record of which is intended.

The durable version of all this is simply to hold the assets from the start. A studio that receives its memory, glossary, style guide, and query log at every milestone can change suppliers because the work is better elsewhere, or keep the current one because they are genuinely good — which is a much healthier position than staying because leaving would cost too much.