Your Translation Memory Is Faithfully Preserving Your Mistakes

2026-02-19 by Ryder Wishart

There's a quality problem hiding inside every translation memory database, and it compounds quietly for years before anyone notices.

The problem isn't that translation memory (TM) is a bad idea. When it was invented, it was a genuinely elegant solution: store every approved translation, match new content against it, save time. The logic is sound. The problem is what happens to that database over the next five years.

Errors Don't Expire

Here's the thing nobody tells you when you set up your first TM: the database doesn't know the difference between your best work and your worst.

A mistranslation approved on a Tuesday in 2019 gets stored with exactly the same confidence as a carefully reviewed segment that took two hours to get right. Industry forums have been documenting this frustration for over a decade. One translator put it plainly: TMs "contain mistranslations, sloppy work and out-and-out errors, which are then perpetuated in the company's documentation for all eternity."

That word—perpetuated—is the right one. The TM doesn't let errors age out. It doesn't flag segments that were approved under time pressure, or segments where the translator was working outside their domain, or segments where a theological decision was made informally and never documented. It just stores the output. And then it serves that output back the next time a similar string appears, with a match percentage that implies confidence the system was never designed to have.

The result, as one industry analysis put it, is that a TM "populated with inconsistent, unverified, or poorly translated content will do more harm than good, propagating errors and undermining" consistency across the whole project.

Fragmentation No One Notices Until It's Too Late

Even when individual segments are correct, there's a second problem: they stop fitting together.

Translation memory is built on segments. It scores matches sentence by sentence, sometimes phrase by phrase. But meaning doesn't live in sentences. It lives in the flow between them—the way a passage builds, the way a term introduced in verse 3 pays off in verse 11, the way the register established in chapter 1 carries through to chapter 40.

When different translators work on different segments across different years, that connective tissue gets lost. As one localization professional described it: "Translators work on pieces of sentences and those pieces stop 'fitting together.'" The TM treats each segment as independent. It has no concept of what came before or what comes after.

Some tools make this worse structurally. Translated segments disappear from the screen once approved, making it "almost impossible to create a text that has a cohesive tone." The translator approves a segment and moves on—but they've lost the ability to see whether the passage is still reading as a whole.

The Maintenance Team You Never Budgeted For

Once a TM database has been running for a few years, organizations typically discover something they weren't expecting: maintaining the database has become a job.

Not a task. A job. TM managers. QA specialists. Governance processes. Cleanup sprints before major projects. Industry analysts now describe routine pre-translation steps—"validating terminology, cleaning up translation memories, and checking source content for clarity"—as requirements, not optional best practices. Steps that "used to happen late—or not at all—are now required to keep things moving smoothly."

The symptoms in a long-running TM include: multiple translations for the same source string, different linguists applying different personal preferences over time, context and instructions that changed but never got reflected in the database. One resource lists these as the standard "symptoms of a faulty TM"—common enough to have a checklist.

For organizations with limited resources—a faith-based translation agency, a university linguistics department, an NGO with a three-person team—this maintenance burden isn't just inconvenient. It's often invisible until it breaks something important.

The Deeper Problem: TM Only Knows What, Never Why

All of the above are real and fixable, to a degree. You can audit your TM. You can hire a TM manager. You can build a governance process.

But there's a problem underneath all of those problems that those solutions don't touch.

Translation memory is a lookup table. Its entire function is to answer one question: Have I seen this string before? If yes, retrieve it. If close enough, fuzzy-match it. The architecture assumes that what was correct before is probably correct now, and that correctness is a property of the string itself—independent of audience, register, theological intent, or communicative context.

That assumption breaks down in real translation, because language is fundamentally a functional system. Any given unit of language means what it means because of the context it's used in and what else might have been said in precisely that context.

Nerdy detail: Context is both syntagmatic (i.e., preceding and following the current string) and paradigmatic (i.e., the wordings that might have been said instead of the current string).

A translation team working on Scripture for a specific language community isn't just converting words. They're making hundreds of ongoing decisions about register, about which theological terms have been adopted into the local language, about how abstract concepts map onto culturally available metaphors, about what the community needs to hear and how they're most likely to hear it. Those decisions don't live in approved segments. They live in the minds and collective experiences of the translation team—and a TM database has no mechanism to capture them.

This is why TM systems produce what they produce: outputs that are locally correct but globally incoherent. Each sentence matches an approved precedent. The passage sounds like it was written by committee, because in a very real sense it was, by a committee distributed across years, whose members never spoke to each other.

A Different Approach: Living Memory

What if the memory wasn't a database of outputs, but a living, context-aware representation of a team's intent?

That's the premise behind what we call Living Memory in Codex. When a translator clicks the sparkle button, the system doesn't find string matches from a corporate TM. It does three things simultaneously:

It retrieves semantically similar translations from this project's own work, ranked not just by string similarity but by how much vocabulary they share with the current task. Not what someone else translated. What this team and project translated (along with any relevant context provided by the translators or PM).

It reads the surrounding context—the preceding verses, both source and target, so the model understands not just the sentence but the flow it belongs to.

And it consults the translation philosophy the team wrote for themselves: the audience they're translating for, the register they've chosen, the theological and communal decisions they've made. This isn't a default system prompt. It's the distilled voice of the translation team, written by them, applied to every suggestion the system generates.

The result is a collaborator that has read everything the team has produced and internalized why they made the choices they made—not just what choices they made.

Traditional Translation Memory	Living Memory
Matches strings	Learns from context
Stores outputs, not intent	Encodes the team's voice
Enforces exact reuse	Integrates team style
No concept of audience and register	Audience is part of every suggestion
Consistency by repetition	Consistency by understanding
Gets worse over time even as matches increase	Gets better and more subtle as the project grows

An Honest Question

Set aside cost bands and local efficiency for a moment. If your translation memory database disappeared tomorrow, would your translation quality get worse—or would you finally be free to translate?

If the answer is somewhere close to the second option, it might be worth seeing how Codex handles this differently. The goal isn't to replace human translators or human judgment. It's to give that judgment somewhere to live—so it accumulates with the project instead of quietly eroding inside a database no one has time to clean.