Translation Memories: A History - From Human Scaffold to Machine Cage

1. Introduction - What Are Translation Memories?

A translator sits at a desk in Brussels in 1978, staring at yet another amendment to the European Communities' customs regulations. The text is nearly identical to one she translated three months ago - same clauses, same terminology, same legal structure. But there is no system to tell her that. She translates it from scratch, as if for the first time.

This scene, repeated millions of times across every large translation organization in the pre-digital era, captures the problem that Translation Memories (TMs) were built to solve. A Translation Memory is, at its simplest, a database of source-language segments paired with their human-approved translations. When a translator encounters a sentence that has been translated before - or something close to it - the TM offers the existing translation as a starting point. The translator never has to translate the same sentence twice.

In large localization projects, industry estimates put reusable content - exact and near matches combined - at 40–70% across versions, updates, and related products. Software strings, technical manuals, legal contracts, and medical instructions are full of sentences that appear verbatim or near-verbatim across documents. Before TM, every one of those sentences was translated from scratch - a staggering waste of human effort. After TM, the industry built an entire economic model around reuse: pay full price for new content, get a discount for matches, pay almost nothing for exact repetitions.

But this is only half the story. The other half - the one this essay will argue - is that the mechanism powering this reuse has structurally plateaued. The segment-granularity, exact-and-fuzzy string-match paradigm that sits at the very core of CAT (computer-assisted translation) tools was a brilliant piece of engineering for the 1990s. It was optimized for human cognitive efficiency on repetitive text. But the moment machines could produce fluent drafts and reason across entire documents, those same optimizations became constraints. The architecture that once saved us is now holding us back.

This is the central thesis: the asset survives, but the mechanism is dying. Translation Memory as a valuable knowledge asset - the accumulated corpus of human-approved translations - will endure and grow in value. But Translation Memory as a rigid, sentence-by-sentence retrieval engine built on lexical string matching has reached its ceiling. Understanding why requires understanding where it came from, who built it, how it evolved, and why the segment - the foundational unit of CAT - is now the very thing that limits what the technology can become.

2. Genesis - Where Did Translation Memories Come From?

Before TM: Card Files, Glossaries, and the Translator's Notebook

Before computers, translators managed repetition through sheer organizational discipline. A technical translator in the 1970s might keep a card file of frequently used terms and phrases, organized by subject area. Large organizations maintained centralized glossaries - paper documents listing approved translations for key terminology. The most diligent translators kept personal notebooks, recording tricky phrases and their solutions for future reference.

These systems worked, but only barely. They were slow to consult, impossible to search at scale, and entirely dependent on individual memory and discipline. A translator who had translated "the party of the first part" a hundred times still had to recognize it as familiar, find the card, or remember the approved rendering. There was no automated way to know that a sentence had been translated before.

The First Conception: Peter Arthern (1978)

The first person to articulate a systematic solution was Peter J. Arthern, Head of the English Translation Division at the Council of the European Communities in Brussels. Arthern was a self-taught linguist - an "old school translator," as he described himself - who had begun his career translating technical documentation for Philips Electrical in the UK before moving to Brussels in 1962 to work on Britain's first EEC accession negotiations.

What Arthern saw, day after day, was the enormous redundancy of legal and administrative texts within the European institutions. The same clauses appeared in countless regulations. The same terminology recurred across documents. Translators were reinventing the wheel with every new text.

In 1978, at the "Translating and the Computer" conference in London, Arthern presented a paper titled "Machine Translation and Computerized Terminology Systems: A Translator's Viewpoint." In it, he proposed a system he called TERRIER - a computer-based text retrieval system that would store previously translated source and target texts, allowing translators to search for and reuse existing translations. He described a workstation with two screens: the source text on top, the translation below, integrated with dictionaries and terminology systems. It was a remarkably prescient vision of what would become the modern CAT environment.

Arthern was not a technologist. He was a translator who understood that the problem was not the quality of translation but the waste of repeating work. His insistence that translators should be involved in designing the systems meant to help them - rather than being passive recipients of technology - set a philosophical foundation that would echo through the industry for decades.

The Theoretical Foundation: Martin Kay (1980)

Two years later, on the other side of the Atlantic, Martin Kay published what would become the foundational theoretical text for Translation Memories. Kay was a British computational linguist - a polyglot who had studied modern and medieval languages at Trinity College, Cambridge, before moving into computer science through the Cambridge Language Research Unit under Margaret Masterman. His career took him to the RAND Corporation, UC Irvine, and finally to the legendary Xerox Palo Alto Research Center (PARC).

Kay's 1980 report, "The Proper Place of Men and Machines in Language Translation," was a philosophical manifesto disguised as a technical paper. His central argument was that fully automatic high-quality translation (FAHQT) was a mirage - a goal that had consumed decades of research and billions of dollars with little to show for it. Instead, Kay proposed a system he called "The Translator's Amanuensis" - from the Latin for "servant" or "assistant." This system would:

• Store previously translated source-target pairs
• Retrieve matching segments when new texts were encountered
• Offer statistical suggestions for words and phrases
• Leave all final decisions to the human translator

Kay's vision was explicitly human-centered. Machines, he argued, are good at storage, retrieval, and consistency. Humans are good at understanding context, nuance, and style. The goal was not to replace translators but to amplify them - to give them a tireless assistant that remembered everything they had ever done.

Remarkably, Kay's 1980 paper does not use the term "translation memory" - where the term actually came from is a story of its own, told at the end of this chapter. But Kay described the concept with such precision that he is rightly regarded, alongside Arthern, as one of the two intellectual fathers of TM.

Kay received the ACL Lifetime Achievement Award in 2005 and served as permanent chair of the International Committee on Computational Linguistics from 1984 to 2016. He died on August 7, 2021, after a long illness. His vision - machines as assistants, not replacements - remains the philosophical backbone of the CAT industry to this day.

The First Implementation: ALPS (1980)

While Arthern and Kay were writing papers, a group of programmers at Brigham Young University in Provo, Utah, was actually building the thing.

In early 1980, ALPS - Automated Language Processing Systems - was founded by a team of programmers from Brigham Young University in Provo, Utah, including Alan K. Melby, a professor of linguistics who would become one of the most important figures at the intersection of translation practice and technology. Melby had already demonstrated a "Suggestion Box Translator Aid" in 1981 - a multi-level translator workstation integrated with a text editor, dictionaries, and MT assistance.

ALPS created a commercial product called the Translation Support System (TSS), which included a component called "Repetitions Processing." This component:

• Stored source sentences and their corrected translations in ISAM (Indexed Sequential Access Method) files
• Automatically searched for identical and similar (fuzzy matching) sentences in the database
• Presented matches to the translator for approval or editing

This was the first practical implementation of a Translation Memory mechanism - years before Trados would bring the concept to the mainstream. ALPS was doing fuzzy matching and database-driven reuse in the early 1980s, on hardware that would seem laughably primitive today.

So why did ALPS not become the Trados of its era? The answer is complex - a mix of market timing, business strategy, and the sheer difficulty of selling software to a conservative industry. ALPS later renamed itself ALPNET and shifted focus, eventually fading from the TM story. But its place as the first to build what Arthern and Kay had imagined is secure.

The Rise of Trados (1984–1992)

In 1984 - four years after ALPS had pioneered the first practical TM implementation - two translators in Stuttgart, Germany, founded a company that would define the CAT industry for the next four decades.

Jochen Hummel and Iko Knyphausen started Trados GmbH - the name is an acronym for TRAnslation & DOcumentation Software - as a language services provider (LSP), not a software company. Like Arthern before them, they were translators who built tools because they needed them. The frustration of retranslating the same content drove them to create their own solutions.

The breakthrough came in 1992 with the release of Translator's Workbench - the first Trados product to combine TM functionality with a user-friendly interface. A crucial partnership with Microsoft, which acquired a 20% stake in the company in the 1990s, gave Trados a seal of approval that no competitor could match. The full story of Trados's rise, its acquisitions by SDL and RWS, and its founder's surprising pivot away from the technology he built is told later in this article.

The Bitext Insight: Brian Harris (1988)

While Trados was building the commercial future, two theorists were laying the conceptual foundations that would outlast any single product.

The first was a Canadian linguist named Brian Harris, who provided the theoretical structure that underlies all TM systems. In a 1988 paper titled "Bi-text, a new concept in translation theory," Harris introduced the concept of the bitext - source and target texts aligned segment by segment. He extended this idea to the "hyper-bitext" - a bilingual hypertext that could be navigated and searched.

Harris's insight was that the fundamental data structure of TM - aligned source-target pairs - was not just a technical convenience but a linguistic reality. Every translation creates a bitext, whether the translator realizes it or not. TM systems simply make that bitext explicit, searchable, and reusable.

The Bilingual Knowledge Bank: Sadler & Vendelmans (1990)

At the same time, a Dutch project called DLT (Distributed Language Translation) , led by Toon Witkam at BSO in Utrecht, was exploring the boundary between TM and machine translation. Funded by the Dutch Ministry of Economic Affairs with approximately 8 million guilders, DLT was an MT system based on an interlingua (Esperanto) with a central store of bilingual segments.

Victor Sadler and Ronald Vendelmans created the Bilingual Knowledge Bank (BKB) - a structurally annotated parallel corpus designed as a general knowledge source for both MT and CAT. The BKB was neither pure TM nor pure EBMT (Example-Based Machine Translation); it was a conceptual bridge between them, containing translation units of varying sizes with cross-linguistic reference links.

The BKB was ahead of its time. It anticipated by three decades the retrieval-augmented architectures that are now at the cutting edge of translation technology.

The Four Pioneering Commercial Systems (1991–1993)

By the early 1990s, the concept had crystallized into four commercial systems that would define the market:

1. IBM TranslationManager/2 (1991) - running on OS/2, one of the first dedicated TM workstations, used primarily within IBM and by select clients
2. STAR Transit (1991) - developed by the STAR Group in Switzerland, still in use today as Transit NXT, making it the second-oldest continuously operating commercial CAT system
3. Eurolang Optimizer (1992–1993) - a Belgian system with color-coded perfect and fuzzy matches, pre-translation against terminology and TM databases
4. Trados Translator's Workbench (1992) - the system that would ultimately dominate the market

What Drove It All

Three forces converged to create the conditions for TM's emergence:

The personal computer revolution. The IBM PC (1981) and Macintosh (1984) put computing power on every translator's desk. Melby had predicted in 1981 that microcomputers would become "the home of translator tools" - and he was right.

Globalization and software localization. As software companies expanded internationally in the 1980s and 1990s, they faced an unprecedented need to translate user interfaces, documentation, and help systems into dozens of languages. The volume was too large for traditional methods.

Pressure on speed and cost. Enterprises wanted faster translations at lower prices. TM offered a way to deliver both - at least in theory.

The EU: The Institutional Engine

You can't really tell the story of TM's origins without talking about the European Union. The EU used the technology early on, but it did more than that - it helped drive its development, and the institutional environment around the EU is arguably where the whole idea took shape. Remember that Peter Arthern's vision (TERRIER in 1978) was born directly from the redundancy of the EU's legal and administrative texts.

The EU's massive multilingual needs - 24 official languages, millions of pages translated every year - created an economic incentive for TM development that no single company could match. When Trados released MultiTerm in 1990, the European Commission bought the first 200 licenses, giving the fledgling company crucial early revenue and a vote of confidence. The purchase reflected something practical: EU officials had recognized just how wasteful their translation workflow was, and they saw technology as a way to fix it.

In 1995, the European Commission's Directorate-General for Translation (DGT) launched Euramis (European Advanced Multilingual Information System) - a centralized translation memory platform that would become the backbone of all EU institutions' translation tools. Euramis today contains over one billion segments across all 24 official EU languages, covering treaties, legislation, preparatory acts, and Court of Justice case-law. It was a pioneering large-scale implementation of centralized, shared TM - a model that anticipated the server-based and cloud-based architectures that would become industry standard decades later.

In 2007, the EU began publicly releasing DGT-TM - a subset of Euramis data in TMX format, freely downloadable for research, MT training, and corpus linguistics. This made the EU one of the largest contributors to the parallel corpus ecosystem, directly enabling MT research and development worldwide. The institution that had inspired Arthern's original vision had become the world's largest producer of open translation memory data.

The Term "Translation Memory"

Who first used the term "translation memory"? The answer, unsatisfyingly, is that no one knows for certain. The concept was described by Arthern (1978) and Kay (1980). The term itself appears to have emerged organically in the CAT community of the late 1980s, with the first commercial products marketed as "translation memory systems" appearing around 1989–1992. No single individual can be definitively credited with coining the phrase. What is certain is that the term was popularized by the commercial tools of the early 1990s and has been the standard ever since.

3. The People - The Characters Who Built an Industry

Behind every technology are the people who imagined it, built it, fought for it, and sometimes - in a twist of irony - declared it obsolete. The story of Translation Memories is, at its heart, a story of individuals who saw a problem and refused to accept that the answer was "that's just how translation works."

Alan K. Melby: The Builder from BYU

A professor of linguistics at Brigham Young University, Melby led major BYU work on translator aids, while related BYU researchers and programmers moved into ALPS when the company was incorporated in early 1980. His "Suggestion Box Translator Aid" (1981) was one of the first practical demonstrations of computer-assisted translation - a multi-level workstation that integrated text editing, dictionaries, and MT assistance.

Melby's contribution was not just technical but philosophical. He insisted on human-centered design - the principle that computers provide "blind suggestions" and that the translator must always retain control. This may sound obvious today, but in the early 1980s, the dominant research paradigm was still fully automatic translation. Melby was arguing for a different path: one where the machine serves the human, not the other way around.

His work at BYU, conducted within the unique context of a university that emphasized both technological innovation and ethical responsibility, produced a generation of researchers and practitioners who carried this philosophy forward.

Yves Champollion: The Rebel with a Macro

In 1999, a French programmer and translator named Yves Champollion looked at the CAT tool market and saw a monopoly. Trados was dominating, but its licenses cost thousands of dollars, locking out freelance translators and small agencies. Champollion believed this technology should be accessible to everyone.

His solution was Wordfast—originally just a set of macros for Microsoft Word. Champollion's primary contribution was proving that translation technology didn't need to be monolithic, expensive, or opaque. He prioritized transparency over complexity, opting for simple text files over proprietary databases. While the full commercial arc of his tool (and its eventual corporate entanglements) is covered later in our look at TM's evolution, Champollion's initial act of rebellion permanently democratized access to the technology.

Toon Witkam: Memory-Based Translation

Toon Witkam is the most mysterious figure in this story. A Dutch pioneer working in the 1980s, he led the DLT project at BSO in Utrecht that we encountered in the previous chapter. His 1988 COLING paper on DLT and his later retrospective (2006) describe a system that used stored bilingual segments as a knowledge source for translation - one of the earliest practical implementations of the "memory" concept in translation technology, though he was describing an MT approach, not a CAT tool.

Almost nothing is known about Witkam's personal life. Public sources are vanishingly scarce. While he is sometimes credited with coining the term "translation memory," available evidence does not support this - the phrase he actually used was "memory-based translation."

Victor Sadler: The Bridge Builder

Victor Sadler worked at ALPS and later on the DLT project, where he and Ronald Vendelmans created the Bilingual Knowledge Bank described in the previous chapter.

Sadler's work is a reminder that the boundary between "machine translation" and "translation memory" has always been porous. The BKB was designed to serve both paradigms, and its descendants - retrieval-augmented neural machine translation (NMT), adaptive MT, RAG (retrieval-augmented generation) for translation - are now at the cutting edge of the industry.

Makoto Nagao: The Father of EBMT

No account of TM's intellectual history would be complete without Makoto Nagao, the Japanese computer scientist who, in 1984, published "A Framework of a Mechanical Translation between Japanese and English by Analogy Principle." Nagao's insight was that translation could be performed by analogy: find similar examples in a bilingual corpus, identify the correspondences, and recombine the fragments into a new translation.

This was the birth of Example-Based Machine Translation (EBMT) , a paradigm that sits at the boundary between TM and MT. EBMT and TM share a core idea - reuse of previously translated material - but differ in their goals: EBMT aims for full automation, TM for human assistance. The boundary has always been blurry, and modern retrieval-augmented NMT is, in many ways, EBMT reborn within a neural architecture.

The Thread That Connects Them

What unites these individuals - from Arthern in Brussels to Nagao in Kyoto, from Melby in Utah to Champollion in Paris - is a shared conviction that translation could be done better. None of them set out to build an industry. They set out to solve a problem: the waste of retranslating the same content, the inconsistency of unmanaged terminology, the isolation of the translator working alone.

They built tools for themselves, and the tools became an industry. That industry now faces a question that would have seemed abstract to its founders: what happens when the machine no longer needs the scaffold they built?

4. Why TM Was Needed (and Still Is)

The Problem of Repetition

Before Translation Memories, the translation industry had a dirty secret: most of the work being done had already been done before.

In software localization - the domain that would become TM's killer application - the numbers were staggering. By industry estimates, a mature product with frequent updates could see 40–70% of its content covered by exact or near matches from earlier versions. The same UI strings, the same error messages, the same help text - translated from scratch, every time, by highly skilled professionals who could have been spending their time on work that actually required their judgment. In medical and life sciences, templated regulatory documents showed 30–60% reusable content once a TM had a few release cycles. Legal contracts, built from standardized clause libraries, reached 40–70% reuse on boilerplate sections.

Every one of those reusable segments was paid for at full price and produced at full effort. The waste was not just economic - it was cognitive. Translators spent hours re-translating sentences they had already translated, their expertise deployed on tasks that required none of it.

TM promised to fix this. And in many ways, it did.

Consistency: The Same Thing, the Same Way

The most immediate benefit of TM was also the simplest: if a sentence had been translated before, it would be translated the same way again.

This sounds trivial, but in practice it was revolutionary. Without a shared memory to consult, consistency was a matter of individual memory and organizational discipline. A translator working on a 200-page technical manual might translate "press the Enter key" one way on page 3 and a slightly different way on page 47 - not because of carelessness, but because human beings do not remember every phrasing choice they made across hours of work. When multiple translators worked on the same project, the problem multiplied: each translator had their own preferences, their own habits, their own sense of what sounded natural.

TM enforced consistency mechanically. If the source segment was identical, the TM returned the same target segment every time. This was especially critical in regulated industries - medical device instructions, pharmaceutical labeling, legal contracts - where inconsistent terminology could have real consequences. A patient reading an IFU (Instructions for Use) should not encounter two different translations of the same warning. A contract should not use two different renderings of the same clause.

But TM did not guarantee consistency automatically. A poorly maintained TM - one with conflicting entries, outdated terminology, or uncleaned duplicates - could propagate errors as efficiently as it propagated good translations. The industry would learn this the hard way: TM is only as good as the data it contains, and garbage in means garbage out, repeated across every project that touches the database.

Efficiency: The Leverage Model

The economic logic of TM was built on the concept of leverage - the percentage of a document that could be reused from existing translations rather than translated from scratch.

In software localization, leverage ratios became the central metric of project planning. A mature product with a well-maintained TM might show 40–70% leverage on a new release: 40–70% of the source text already existed in the TM as exact or fuzzy matches, leaving only 30–60% as genuinely new content requiring full translation. For the client, this meant paying for less. For the LSP, it meant delivering more with the same resources. For the translator, it meant - in theory - being more productive.

The productivity data, when it finally arrived from academic studies, confirmed the broad picture but complicated the details.

Masaru Yamada (2011) conducted one of the first rigorous empirical studies of TM productivity, measuring the effect of different TM database types on translation speed. His findings: productivity gains ranged from 10% to 70% depending on the match category and the nature of the TM database. For 100% matches, the gains were strong regardless of TM type. But in the fuzzy-match zone - the 75–99% range where most of the interesting action happens - the results were more nuanced.

Yamada's most counterintuitive finding was this: highly localized or customized TMs could actually reduce productivity on fuzzy-match segments. The common assumption - that more customized, more carefully curated TM content would always be better - turned out to be wrong for fuzzy matches. When a TM entry was heavily localized to a specific context, translators spent extra cognitive effort reconciling that localized entry with the new source context. Literal, less-customized TM entries were often faster to adapt. The translator had to do less mental work to see how the stored translation could be modified to fit the new text.

This finding - that more data is not always better data - would echo through the next decade of TM research. It was a warning that the TM model, for all its power, had cognitive costs that were not captured by simple match percentages.

Quality: Fewer Errors, New Risks

TM's impact on quality was a double-edged sword.

On the positive side, TM reduced certain classes of errors dramatically. Terminology consistency improved. Number errors - a surprisingly common problem in manual translation - could be caught by automated QA checks integrated with the TM workflow. Tag handling in software localization became more reliable. The revision time for translated content dropped from roughly 25–44% of total translation time (in human-only workflows) to 12.8–19% with TM support - roughly a 50% reduction. And crucially, quality was maintained: Yamada's GTM (general text quality) scores remained above 0.95 even as revision activity decreased.

On the negative side, TM introduced new quality risks. Error propagation was the most insidious: a single bad translation stored in the TM could be replicated across dozens of projects before anyone noticed. Stylistic inertia - the tendency of TM to encourage safe, formulaic translations over creative, context-appropriate ones - was harder to measure but widely discussed. And the segment-level focus of TM encouraged sentence-by-sentence processing that could harm discourse-level coherence. A document might be perfectly translated at the sentence level but read poorly as a whole, because the TM had no awareness of the relationships between sentences.

The Migros Bank study (Läubli et al., 2019) offers a suggestive data point: when the bank's translators added MT post-editing to their segment-based TM workflow, expert raters scored cohesion slightly lower in the post-edited texts in both language pairs, even as overall quality held steady or improved. Whatever fills the segment - memory or machine - the sentence-by-sentence pipeline optimizes segments, not texts.

Economics: The Discount Grid

The most visible economic impact of TM was the match-based pricing model that emerged in the 1990s alongside the commercialization of CAT tools.

Translation had always been priced simply: X cents per word, multiplied by the word count. TM turned pricing into a negotiation over match categories. The typical grid looked something like this:

The logic seemed straightforward: if a segment had already been translated, the translator did less work, so the client should pay less. But this logic concealed a series of assumptions that would prove controversial.

First, even 100% matches required work - verification of context, terminology, and client preferences. A 100% match was not "zero work," yet the pricing model treated it as nearly free. Second, fuzzy matches in the 75–84% range often required substantial rewriting - sometimes as much effort as translating from scratch - yet the translator was paid 30–40% less. Third, the productivity gains from TM were captured primarily by agencies and clients, not by translators. The freelancer who built the TM through years of work saw their effective rate decline as the database grew, because more of their work fell into discounted match categories.

As John Hadfield put it in 2009: "The translator often has more work to do as a result of using a TM, but gets paid much less… than before the introduction of TMs."

The discount grid was not a standard set by any authority. There was no LISA, ATA, or ISO specification for pricing. The percentages emerged organically through agency experimentation, client procurement demands, and competitive pressure - a market-driven convention that became so entrenched that freelancers could not refuse it without losing work. For the individual translator, the economic reality of TM was set in stone.

The Productivity Data: What the Research Actually Says

The academic evidence on TM productivity is more nuanced than the industry's marketing would suggest.

Fotini Vallianatou found that translators using CAT tools produced 400–1,100 words per hour, compared to a baseline of approximately 250 words/hour without technological support - a relative productivity of 1.6–4.4× baseline. This sounds impressive, but the range is wide, and the upper end typically reflects high-match, repetitive content rather than genuinely new translation.

Mihaela Vela (2014) studied the effect of storing MT output in TM databases. Translators using a modified TM (post-edited MT stored as TM entries) were 28.87% faster than with no TM. Those using unmodified TM (raw MT suggestions) were 52.82% faster - a finding that surprised even the researchers. The pre-editing of MT output before storing it in the TM paradoxically reduced the productivity benefit.

The Migros Bank study (Läubli et al., 2019) - reported by Slator as the "Swiss Bank" study - compared a TM-only workflow with machine translation post-editing (MTPE) layered on top of the same TM, across two language pairs. For German→French, translators produced 585 words/hour with TM only versus 934 words/hour with MTPE - a ~60% increase, and a statistically significant one. For German→Italian, the gain was only ~9% (453 vs 495 words/hour), which did not reach significance - and one of the two Italian translators was actually slower with MT. The dramatic difference between language pairs - in the same study, on the same source texts, using the same workflow - had no single explanation: the authors point to the Italian engine's in-domain training data (roughly half what the French engine had) and to the small sample of four translators. Measured productivity gains, in other words, are a property of the whole configuration - engine, language pair, translator - not of the tool alone.

The most provocative finding came from Ana Guerberof Arenas (2008–2014) , who conducted blinded experiments in which professional translators were given segments from either TM fuzzy matches or MT output, without being told which was which. The result: translators achieved higher productivity and quality when post-editing MT output than when processing TM fuzzy matches in the 80–90% range.

This was a bombshell. The entire TM pricing model was built on the assumption that TM matches were more valuable than MT output - that human-approved translations deserved a premium over machine-generated text. Guerberof Arenas showed that, in the critical fuzzy-match zone where most TM leverage occurs, MT could actually be better - faster to edit, with comparable or superior quality.

The finding did not mean TM was obsolete. It meant that the boundary between TM and MT was not where the industry had assumed it was. The 80–90% fuzzy match - long treated as a valuable asset worth paying a premium for - might actually be less useful than a well-generated MT suggestion. The implications for pricing, workflow design, and tool architecture were profound.

Standardization: TMX, TBX, and SRX

As TM adoption grew in the 1990s, a problem emerged that no single vendor could solve: interoperability.

Every CAT tool used its own proprietary format for storing translation memories. Trados had its own. IBM TranslationManager had its own. STAR Transit had its own. A translator who switched tools - or a client who wanted to move their TM from one LSP to another - faced a data migration problem that was technically difficult and often lossy.

The solution came from LISA - the Localization Industry Standards Association - and its standards working group OSCAR (Open Standards for Container/Content Allowing Re‑use) . In 1997, they released TMX (Translation Memory eXchange) , an XML-based open standard for exchanging translation memories between tools.

TMX was a remarkable achievement. It defined a vendor-neutral format - <tu> (translation unit) elements containing <tuv> (translation unit variant) elements for each language, with <seg> (segment) elements holding the actual text - that any tool could read and write. It used ISO 8601 for dates, ISO language codes, and a consistent XML structure that was both machine-readable and human-understandable.

The standard went through several iterations: TMX 1.0 in 1997, 1.1 in 1998–1999, 1.2 around 2000, 1.3 around 2002, and TMX 1.4b in the mid-2000s - the version that would become the de facto standard and remains the current version to this day. A working draft of TMX 2.0 was produced in March 2007, but it was never finalized. LISA was declared insolvent in March 2011, and the standard was transferred to a Creative Commons license, with ETSI LIS ISG serving as a custodial steward. No new version has been published since 2005.

TMX was joined by two companion standards:

TBX (TermBase eXchange) , released around 2002, provided a standard format for exchanging terminology databases. Unlike TMX, TBX achieved ISO status - ISO 30042 - with the current version (TBX v3) published in 2019. It is maintained by ISO/TC 37/SC 3, giving it a formal governance structure that TMX lacks.

SRX (Segmentation Rules eXchange) , released in 2004 (SRX 1.0) and updated in 2008 (SRX 2.0), addressed a problem that TMX alone could not solve: segmentation. Two tools using the same TMX file could produce different matches if they segmented the source text differently. SRX provided a standard way to define and share segmentation rules, ensuring that the same text would be split into the same segments regardless of which tool processed it.

These three standards - TMX, TBX, and SRX - formed the technical backbone of the TM ecosystem. They enabled the portability of linguistic assets across tools, vendors, and projects. They made it possible for a translator to build a TM in one tool and use it in another. They gave clients confidence that their investment in TM creation would not be lost if they changed suppliers.

But the standards were not without their limitations. TMX 1.4b has been frozen since 2005 - nearly two decades without a new version. It lacks support for modern metadata requirements, inline markup handling is inconsistent across implementations, and the standard has no mechanism for representing the provenance of segments (was this entry human-approved, post-edited MT, or raw MT?). SRX, meanwhile, never achieved the adoption level of TMX - it remains a niche standard used by a subset of tools, meaning that segmentation inconsistencies remain a practical problem in TM exchange.

XLIFF and the OASIS Alternative

While LISA was developing TMX for finished TMs, another standards body - OASIS - was developing XLIFF (XML Localization Interchange File Format) for work-in-progress. XLIFF was designed to capture the state of a translation job in progress: source segments, target segments, TM matches, MT suggestions, translator notes, review comments, and approval status. It borrowed heavily from TMX 1.2 in its early versions, but evolved in a different direction.

XLIFF has been more successful than TMX in one sense: it continues to evolve. XLIFF 2.0 was released in 2014, and the standard is actively maintained by the OASIS XLIFF Technical Committee. But XLIFF and TMX serve different purposes. TMX is for finished, reusable TMs. XLIFF is for active translation jobs. They are complementary, not competing - but the fact that the industry needs both is a sign that the standardization problem was never fully solved.

The Real Picture: What TM Achieved

When the evidence is weighed together, a complex picture emerges.

TM delivered real, measurable productivity gains - a realistic average of ~30% across mixed content, with a range of 10–70% depending on domain, match type, TM quality, and translator experience. It improved consistency for repeated content, reduced certain classes of errors, and enabled a pricing model that made translation more affordable for clients. It created an industry-standard format for exchanging linguistic assets and a set of companion standards that, however imperfect, enabled interoperability across a fragmented tool landscape.

But TM also introduced new problems. It created a pricing model that systematically transferred value from translators to intermediaries. It introduced new quality risks - error propagation, stylistic inertia, cohesion loss - that the industry is still learning to manage. It locked the industry into a segment-level paradigm that, as we will see, has structural limitations that no amount of tool improvement can fully overcome.

And the most provocative finding - Guerberof Arenas's demonstration that MT post-editing could outperform TM fuzzy matches in the 80–90% range - suggested that the very foundation of TM's value proposition was not as solid as the industry believed. If a machine-generated translation was faster to edit than a human-approved fuzzy match, what did that say about the premium the industry placed on TM content?

The answer, as the next decade would show, was not that TM was obsolete. It was that TM's role was changing - from the primary engine of translation production to one component in a larger, more complex system. And the first sign of that change was already visible in the technology that had always been TM's hidden foundation: segmentation.

The way TM divided text into units - the sentence, the segment, the translation unit - was about to become the central battleground of the industry's future.

5. Segmentation - The Hidden Foundation

The Problem of Units

A Translation Memory is, at its core, a database of pairs: a source sentence and its human-approved translation. But what counts as a "sentence"? The question sounds trivial until you try to answer it with a regular expression.

Consider this innocuous English text:

Dr. Smith of the U.S. Department of Commerce arrived in Washington, D.C. on Tuesday. He was accompanied by Mr. Jones, Ph.D., and Mrs. Patel.

A human reader sees two sentences. A naive computer program - one that simply splits on periods - sees eleven. "Dr." becomes a fragment. "U." becomes a fragment. "S." becomes a fragment. "D.C." becomes three fragments. The result is not a Translation Memory but a pile of linguistic confetti, each piece too small to ever match anything useful.

This is the problem of segmentation: dividing continuous text into discrete, addressable units that become the fundamental building blocks of a Translation Memory. Without it, a TM can't store, index, or retrieve anything at all - segmentation is the foundation this technology is built on.

And it is, as we shall see, the single most consequential design decision in any TM system, receiving far less attention than it deserves.

Why Segmentation Was Needed

A Translation Memory operates on translation units (TUs) - source–target pairs that the system can match against new text. For the TM to function, the continuous flow of a document must be divided into discrete chunks. Each chunk becomes a TU: the atomic object that the system indexes, stores, and retrieves.

Without segmentation, the TM would have no way to:

• Know where one translation ends and another begins
• Index content for fast retrieval
• Compute similarity between a new text and stored content
• Align source and target texts during TM creation

The sentence was the obvious choice for early TM systems. It is a recognized linguistic unit with syntactic and semantic coherence. In most European languages, punctuation - period, question mark, exclamation mark - provides clear boundary markers. It is large enough to carry meaningful content but small enough to be reusable. And it aligns with how translators traditionally think about their work: sentence by sentence.

But the sentence is not a universal or stable unit. Different languages segment differently. Japanese uses "。" but also relies on line breaks and paragraph structure. Chinese and Thai lack explicit word boundaries entirely - you cannot find sentence boundaries if you cannot even find word boundaries. German compounds create long, complex sentences that resist clean splitting. Arabic uses different punctuation conventions and a right-to-left script that complicates any rule-based approach.

The choice of the sentence as the default segment was, in other words, a deeply Western, deeply convenient assumption that would create problems for every language and content type that did not conform to it.

A Brief History of Segmentation in TM

Paragraph-Level: The First Attempt

The earliest TM implementations of the early 1990s often worked at the paragraph level. Paragraphs were easy to detect - paragraph breaks are structural, not linguistic - and seemed like safe, self-contained units. A paragraph is clearly a coherent block of text. What could go wrong?

Almost everything. Paragraphs are rarely repeated verbatim across documents. Even in highly repetitive technical documentation, paragraphs tend to vary in length, structure, and content. Fuzzy matching on long paragraphs is computationally expensive - comparing a 200-word paragraph against a database of thousands of other paragraphs requires significant processing - and produces poor results because the similarity scores are diluted by the sheer volume of text. And most importantly, translators do not work at the paragraph level. They work sentence by sentence, phrase by phrase, word by word. A paragraph-level TM offered matches that were too coarse to be useful and too rare to justify the investment.

The Sentence-Level Revolution

The shift to sentence-level segmentation in the mid-1990s was transformative. It was enabled by better sentence boundary detection algorithms, the growing realization that most repetitive content in localization is at the sentence level, and the rise of software localization where UI strings are often exactly sentence-length.

The impact on fuzzy matching was dramatic. Sentences are more likely to repeat across documents - especially in technical manuals, legal contracts, and software strings. Fuzzy matching on shorter strings is faster and more accurate. And sentence-level TMs enabled the leverage-based discount model - described in the previous chapter - that would define the localization industry.

This shift was the revolution that made TM viable at scale. But it also locked the industry into a specific granularity - the sentence - that would prove increasingly limiting as the technology matured.

The Persistent Problems of Segmentation

False Positives: The Period That Isn't

The most persistent problem in rule-based segmentation is the false positive: a period that looks like a sentence boundary but isn't one. We saw this in the opening example - "Dr.", "U.S.", "D.C.".

The impact on a TM is devastating. Fragments like "Dr." or "The U." are stored as translation units that will never match anything useful. The remainder of the sentence - "Smith arrived." - is stored as a separate unit that may later appear without the abbreviation, causing a mismatch. A TM built with poor abbreviation handling might store "The U." as a TU. When "The U.S. economy" appears in a new document, the TM offers no match for "The U." (it is meaningless) and a poor fuzzy match for the remainder. The translator retranslates from scratch.

The solutions to this problem are varied and imperfect. Abbreviation lists - curated lists of known abbreviations like Mr., Mrs., Dr., Inc., Ltd., Ph.D. - are the most common approach, but they are labor-intensive to maintain and never complete.

Statistical detection offers a more elegant solution: the Punkt algorithm, developed by Tibor Kiss and Jan Strunk in 2006, identifies abbreviations by their "period affinity" - how often a token appears with versus without a trailing period. It uses four signals: period affinity (does this token almost always appear with a period?), length (abbreviations tend to be short, 1–4 characters), frequency (rare tokens cannot be reliably classified), and internal periods (multi-dot patterns like U.S. and Ph.D. are strong signals). The industry technically solved this problem with Punkt in 2006, though commercial adoption remains surprisingly low.

Lists, Headings, Tables: The Non-Prose Problem

Not all text is prose. Bullet lists, numbered steps, headings, tables, and code snippets all create segmentation ambiguity that no rule-based system handles well.

Should each bullet point in a list be its own segment? Or should the entire list be one segment? Should a heading be paired with the following paragraph? Should each table cell be a segment, or the entire row? What about inline code versus code blocks?

Different CAT tools answer these questions differently, and the differences cause interoperability problems when TMs are exchanged. A TM built in Trados may segment a bullet list one way; the same list imported into memoQ may segment differently. The result is misaligned TUs that lose their value.

Languages Without Clear Boundaries

CJK and Thai languages pose fundamental challenges that most TM systems were never designed to handle.

Chinese has no spaces between words. Sentence boundaries are marked by "。" but usage varies by genre and register. Word segmentation must precede sentence segmentation - a two-step process that doubles the opportunity for error.

Japanese uses "。" but also relies on line breaks, paragraph structure, and context. Research has shown that treating every "。" as a sentence boundary fails in abbreviations and parenthetical expressions. Line breaks can serve as supplementary boundary cues, but no standard approach exists.

Thai is written without spaces between words. Spaces may appear between clauses but not consistently. Word boundary ambiguity is a fundamental challenge that requires sophisticated models - CRF-based approaches combined with dictionary-based word-merging algorithms are state-of-the-art.

The impact on TM is severe. Without accurate word and sentence segmentation, TM units become either fragmented (partial words) or overly long (multiple sentences bundled together). Both scenarios destroy TM leverage. And these are not edge cases - these languages represent billions of speakers. Yet most TM systems were designed around Western punctuation conventions and handle CJK and Thai poorly, if at all.

Context Loss: The Isolated Sentence Problem

Sentence-level segmentation treats each sentence as an isolated, context-independent unit. This assumption fails in predictable ways.

Context loss: "He" in sentence 2 refers to "John" in sentence 1. The TM stores only the isolated sentence - "He arrived on Tuesday" - with no indication of who "he" is.

Gender-dependent translation: In Czech, the translation of "Project manager" differs depending on whether the manager is male or female. The context - the gender of the person - may be established several sentences earlier, in a different segment entirely.

Register and style: A formal translation of a sentence may be perfectly correct in isolation but completely inappropriate in an informal document. The TM has no way to know.

Domain ambiguity: "Charge" means different things in legal, financial, and electrical contexts. The sentence-level TM stores the translation without domain metadata.

The industry has partially addressed this through 101% matches (in-context matches), which store neighboring segment context alongside each TU. But this only captures immediate neighbors, not full discourse structure. It is a bandage on a deeper wound.

The empirical evidence for this problem is striking. Läubli et al. (2020/2022) conducted the first controlled experimental evaluation of how text presentation in CAT tools affects translator performance: twenty professional translators, three text-processing tasks, segmented versus unsegmented interfaces. The results were sharply task-dependent. Sentence-by-sentence presentation made translators significantly faster at local work - reproducing text and identifying errors within sentences. But in revision, segmentation lost its advantage. When revisers had to track anaphoric relations - a pronoun referring to an antecedent in an earlier sentence - the unsegmented document view produced markedly higher accuracy: 58% of inter-sentential errors corrected, versus 38% in the comparable segmented view. The effect was large, though it fell just short of conventional statistical significance, and revision speed did not differ significantly between the two presentations. The mechanism the authors proposed is intuitive: segment boxes place a pronoun and its antecedent further apart, obscuring the referential chain the reviser needs to see.

The deficit is measured, not merely theoretical. Notably, the authors do not conclude that segmentation should be abandoned: their recommendation is that the segmented view be complemented with an unsegmented one, chosen by task. But that is precisely the point - the interface built as a scaffold for human translators becomes a cage the moment the task requires holistic document understanding.

The Standardization Attempt: SRX

What SRX Tried to Solve

By the early 2000s, the industry had a standard for exchanging TMs - TMX - but no standard for ensuring that those TMs would segment the same way in different tools. A TM exported from Trados and imported into memoQ would produce different segments, rendering the exchange partially useless.

The Segmentation Rules eXchange (SRX) standard was developed by the LISA OSCAR group to solve this problem. SRX is an XML-based format that allows CAT tools to define and share segmentation rules. Rules are grouped into named sets activated by language code. Each rule defines text patterns before and after potential break locations using regular expressions. Rules specify whether a break should occur or not occur (break vs. no-break rules), and they are evaluated in order - the first matching rule determines the break decision.

A simplified English SRX rule set might look like this:

<srx>
  <languagerules>
    <languagerule languagerulename="English">
      <rule break="yes">
        <beforebreak>\w+[\.\?\!]</beforebreak>
        <afterbreak>\s+[A-Z]</afterbreak>
      </rule>
      <rule break="no">
        <beforebreak>(Mr|Dr|Mrs|Ms|St)\.</beforebreak>
        <afterbreak>\s+[A-Z]</afterbreak>
      </rule>
    </languagerule>
  </languagerules>
</srx>

SRX 1.0 and 2.0: A Brief Life

SRX 1.0 was published in April 2004, with basic break/no-break rules and language-specific rule sets. SRX 2.0 followed in April 2008, with improved regex support, better language mapping, and more flexible rule structure.

SRX 2.0 is the last published version. No new versions have been released since 2008. The standard is now maintained by GALA (Globalization and Localization Association) but is effectively in maintenance mode - a zombie standard, technically alive but showing no signs of growth.

Why SRX Never Achieved TMX-Level Adoption

Several factors explain SRX's limited adoption, and they reveal something important about the industry's priorities.

Complexity: Writing and maintaining SRX rules requires regex expertise that most translators and project managers do not have. A translator who can produce flawless translations in three languages may struggle to write a regular expression that correctly handles "U.S." versus "U.S.A." versus "U.S. Department of State."

Tool lock-in: CAT tool vendors invested heavily in their own proprietary segmentation engines. Trados developed its own segmentation rules, memoQ developed its own, and each vendor had little incentive to make them interchangeable. Segmentation was a competitive differentiator, not a commodity.

No killer app: TMX solved a clear, painful problem: "I need to move my TMs from Tool A to Tool B, and they don't talk to each other." SRX solved a subtler problem: "My TMs segment differently in different tools, causing misalignment." Many users did not recognize this as a problem at all, or blamed the tools rather than the lack of a standard.

Incomplete coverage: SRX handles sentence boundaries but not word segmentation (needed for CJK and Thai) or structural segmentation (tables, lists, headings). It solved only part of the problem.

Lack of enforcement: Unlike TMX, which is essential for TM exchange, SRX is optional. Tools can claim SRX support with minimal implementation, and there is no certification or compliance testing.

LISA's dissolution: LISA disbanded in 2011, and the standard lost its institutional home.

The LISA story is a cautionary tale. Standards are only as durable as the organizations that maintain them. When the organization dies, the standard enters a kind of limbo - still usable, still referenced, but no longer evolving. TMX works, but it has not kept pace with the needs of modern workflows. It has limited support for metadata, inline markup, and Unicode edge cases. It was designed for sentence-level segments, not the variable-length units that modern AI systems prefer. The industry has not replaced TMX because replacing it would require the kind of collective action that LISA once enabled - and no organization has stepped up to fill that void.

The result is a fragmented landscape. memoQ, Wordfast Anywhere, Wordbee, Crowdin, Phrase, and the Okapi Framework support SRX. Trados Studio - the market leader - does not, relying instead on its own proprietary segmentation rules.

The Relationship Between Segmentation and TM

Segmentation Is Forever

The segmentation decision at import time determines, permanently, what gets stored in the TM. A sentence split into two segments becomes two separate TUs that will never match the full sentence. A paragraph kept as one segment becomes a TU too long to match anything useful. An abbreviation-triggered false split creates a fragment TU that is useless.

Segmentation is irreversible for existing TM entries. You can re-segment a document, but the old TUs remain in the TM with their original boundaries. The only solution is to rebuild the TM from scratch - a costly and disruptive process that most organizations never undertake.

The Chain of Failure

Bad segmentation creates a chain of failure that cascades through the entire TM workflow:

1. Poor segmentation → fragmented or overly long TUs
2. Fragmented TUs → no exact matches, poor fuzzy matches
3. Poor matches → translator ignores TM suggestions
4. Ignored TM → no productivity gain → TM investment wasted

A TM built with poor segmentation is not just less useful - it is actively harmful. It wastes the translator's time by offering irrelevant suggestions, erodes trust in the technology, and undermines the business case for TM investment.

The 20% Ceiling

Here is a number that should give the industry pause - though not for the reason you might expect. In 2005, Emmanuel Planas, founder of the French CAT vendor Lingua et Machina, claimed that sentence-level TM usefully applies to only about 20% of the documents translated daily worldwide - and that his chunk-based system could raise that to 80%. The numbers were a vendor's assertion, presented without measurement, and they have never been independently verified. But they have never been seriously refuted either, and the intuition behind them is sound: sentences repeat verbatim only in the most formulaic content. Marketing copy, creative writing, legal arguments, and conversational text all resist sentence-level reuse, however well the TM is maintained.

What should actually give the industry pause is that in twenty years, nobody has checked. A number that defines the addressable market of the industry's core technology has sat untested since 2005 - repeated when convenient, ignored when not. Wherever the true ceiling lies, it is not a law of nature - it is a consequence of a design choice made in the 1990s and never revisited. The sentence-level segment, which once served as a scaffold for human translators, has become a cage that limits what the technology can achieve.

Beyond the Sentence: The Sub-Segment Future

SIMILIS: The 80% Claim (2005)

The 20/80 numbers come from SIMILIS, a commercial CAT tool built by Planas's company, Lingua et Machina. SIMILIS applied light linguistic analysis to break sentences into chunks - nominal and verbal groups identified through monolingual lexicons and grammatical categorization - and stored these chunks as translation units alongside full sentences, aligning them across languages by comparing the grammatical structures of source and target segments. A sentence with no usable fuzzy match could still yield exact matches at the chunk level, and the same analysis extracted bilingual terminology as a by-product.

Planas published no formal evaluation - the 80% was a claim about what chunk-level reuse opens up, not a measured result. But the mechanism was real, the product shipped to paying customers, and the question it raised is one the industry has never fully answered: if chunk-level reuse was commercially available in 2005, why are we still working at the sentence level in 2026?

Déjà Vu X: Assemble from Portions

One commercial system did implement sub-segment matching. Déjà Vu X, developed by Atril, included a feature called "Assemble from portions" that stored and retrieved phrase-level translations within sentences and assembled translations from multiple fragment matches when no full sentence match existed.

This was, in effect, an EBMT (Example-Based Machine Translation) mechanism inside a commercial CAT tool - a blurring of the boundary between TM and MT that most of the industry has been reluctant to embrace.

Neural Fragment Recall (Trados, Q4 2024)

In its Q4 2024 Trados update, RWS introduced Neural Fragment Recall as the AI-enabled successor to its earlier upLIFT Fragment Recall feature. Neural Fragment Recall uses a multilingual neural alignment model operating at the subword level (byte-pair encodings) to automatically align source and target words and phrases when TUs are added to the TM. It requires no minimum TM size - it works from the first segment - and delivers real-time alignment and retrieval in both desktop and online editors.

This is the first major innovation in TM segmentation in over a decade. But it comes with significant limitations: it is initially limited to three language pairs (EN↔DE, EN↔FR, EN↔ES), it operates within the sentence-level paradigm rather than replacing it, and it is Trados-only.

Why Hasn't the Industry Moved?

If chunk-level TM promised to quadruple reuse, why did the industry stay at the sentence level? The answer is a combination of technical, economic, and psychological barriers.

TMX is flat: The standard exchange format stores sentence-level TUs. No hierarchical or phrase-level structure is standardized. There is no "TMX 2.0" that could carry fragment-level data.

Computational cost: Fragment alignment and indexing is resource-intensive, especially for large TMs. The industry's infrastructure was built for sentence-level matching.

Noise and configurability: Sub-segment recall can produce excessive suggestions if not carefully tuned. Translators need control over what fragments are shown, and too many suggestions can be as bad as too few.

Backward compatibility: Existing TM assets are sentence-level. Migrating to a fragment-level system is non-trivial and risky.

Vendor lock-in: Neural Fragment Recall is Trados-only. No cross-vendor standard for fragment-level TM exists, so no vendor has an incentive to invest in interoperability.

Cognitive trust: Translators need context to trust fragment suggestions. Showing the full originating TU alongside a fragment is essential, but it complicates the user interface and the matching logic.

Coda: The Punkt Algorithm, Twenty Years On

One final observation before we move on. It is 2026, which means the Punkt algorithm—the gold standard for unsupervised abbreviation detection discussed earlier—is twenty years old. And yet, most CAT tools still rely on hand-curated abbreviation lists that must be maintained manually, language by language, client by client. The industry has the statistical tools to solve this problem automatically; it simply has not chosen to deploy them.

This is not a technical failure. It is a failure of attention. Segmentation has always been the hidden foundation of TM - invisible, unglamorous, and critically important. The industry has invested in matching algorithms, TMX exchange, and user interfaces while neglecting the single most impactful design decision in the entire system.

The story of segmentation is the story of a technology that made a reasonable design choice in the 1990s - the sentence as the unit of translation - and then spent three decades discovering the limits of that choice. The sentence is not a universal unit. It does not work equally well across languages, content types, or use cases. And the reuse ceiling it imposes - wherever exactly it lies - may be the single greatest constraint on the future of Translation Memory.

But segmentation is only one dimension of the TM architecture that is showing its age. The matching algorithms themselves - the fuzzy matching engines that compute similarity between strings - have their own history, their own limitations, and their own surprising relationship with the machine translation systems that were supposed to replace them.

Before we can understand where segmentation is heading, we need to understand how the TM systems that depend on it evolved. The three generations of TM architecture - local, server, cloud - each shaped the segmentation problem in different ways, and each embedded the segment-level paradigm more deeply, making it harder to escape.

6. Evolution - Three Generations of TM

The Translation Memory did not spring into existence fully formed. It evolved through three distinct architectural generations, each shaped by the hardware and business realities of its era. Understanding this evolution is essential to understanding why the technology looks the way it does today - and why its limitations are structural, not incidental.

Generation 1: Local Databases (1990s–mid-2000s)

The first generation of TM tools was defined by a simple constraint: the translator's computer was the only computer that mattered. There was no cloud, no server, no network to speak of. The TM lived on the translator's hard drive, as a file.

Trados Translator's Workbench, first released in 1992 for DOS and ported to Windows in 1994, was the archetype of this generation. Its architecture was straightforward: a local database (initially proprietary binary formats, later a Microsoft Access .mdb file) stored source-target segment pairs. The translator worked in Word or TagEditor, and Workbench sat in the background, querying the database as each new segment was encountered. When it found a match - exact or fuzzy - it displayed the suggestion in a floating window.

The fuzzy matching algorithm was the real innovation. Trados used a character-level edit distance calculation - essentially, how many characters would need to be changed to turn the source segment into a stored segment. A 70% match meant that 70% of the characters were identical. This was crude by modern standards - it had no understanding of morphology, syntax, or semantics - but it worked well enough on the repetitive technical content that dominated localization workflows. A sentence like "Click OK to confirm the operation" would match at 100% with itself, and at perhaps 80–85% with "Click Cancel to abort the operation." The translator could see the differences highlighted in color and make the necessary adjustments.

Wordfast Classic, released in 1999, took a radically different architectural approach to the same problem. Where Trados was a complex, multi-file application with a proprietary database, Wordfast Classic operated entirely as a set of macros embedded inside Microsoft Word.

Its TM was a simple tab-delimited text file—you could open it in Notepad, edit it by hand, and understand exactly what it contained. Each line held a source segment, a target segment, and basic metadata, separated by tabs. The fuzzy matching was done within Word's macro environment using a character-level algorithm. It was slower and less sophisticated than Trados, but the simplicity of its format turned it into a de facto standard for lightweight exchange.

The limitations of Generation 1 are obvious in retrospect. TMs were siloed on individual machines. A translator working on a team project could only access matches from their own previous work, not from colleagues' TMs. Consistency across a team depended entirely on manual coordination - sharing TM files via email or floppy disk, merging them by hand, hoping that no one overwrote anyone else's work. There was no central repository, no version control, no way to know whether the segment you were reusing had been approved by a reviewer or was still in draft.

Yet for the individual translator, Generation 1 was transformative. The TM on your hard drive was your personal knowledge base - a record of every translation you had ever done, instantly searchable, always available. Translators who had spent years retranslating the same sentences suddenly found themselves working at speeds they had never imagined possible. The TM was not just a tool; it was a personal asset, accumulated over years of work, growing more valuable with every project.

Generation 2: Server/Network-Based (mid-2000s–2010s)

The second generation solved the siloing problem by moving the TM from the desktop to the server. Instead of each translator querying a local file, all translators on a project queried a shared database running on a central server. When one translator confirmed a segment, it became available to everyone else in real time.

Trados Server was the flagship of this generation. Released in the mid-2000s, it allowed organizations to host their TMs on a central Microsoft SQL Server database, accessible to any number of translators over a local network or VPN. The server handled concurrent access, locking, and conflict resolution - if two translators tried to translate the same segment simultaneously, the server decided who got there first.

memoQ, developed by the Hungarian company Kilgray (founded 2004), took the server concept further. memoQ's server architecture was designed from the ground up for collaborative translation. It introduced the concept of the "live TM" - a shared memory that updated in real time as translators worked, with changes propagating to all connected users within seconds. memoQ also pioneered server-side terminology management, QA checks, and workflow automation, turning the TM from a passive database into an active component of the translation process.

The server generation brought several critical innovations:

Concordance search - the ability to search the TM for any word or phrase, not just full segments. A translator wondering "how did we translate 'force majeure' in the last contract?" could type the phrase into a search box and see every occurrence, in context, across the entire TM. This was a qualitative leap from the segment-level matching of Generation 1.

Auto-propagation - when a translator confirmed a segment, the system automatically applied the same translation to all identical source segments elsewhere in the document. This eliminated the tedious work of manually copying translations for repeated sentences.

Automated QA checks - the server could run batch checks across the entire project: number consistency (did the translation preserve the digits?), tag verification (were the XML/HTML tags intact?), terminology compliance (did the translator use the approved term?), and segment-level consistency (was the same source segment translated the same way every time?).

MT integration - the first generation had treated machine translation as a separate world. The second generation began to bridge the gap. Trados and memoQ both introduced plugins that could send segments to MT engines (initially rule-based systems like Systran, later statistical engines like Google Translate) when no TM match was found. The translator would post-edit the MT output instead of translating from scratch. This was the beginning of the TM+MT hybrid workflow that would define the next generation.

The server generation also changed the economics of TM. A local TM was a personal asset; a server TM was a corporate asset. Organizations invested heavily in building and maintaining shared TMs, treating them as intellectual property that gave them a competitive advantage. The TM became a barrier to entry - a new LSP competing for a client's business would need years to build a TM of comparable size and quality.

But the server generation had its own limitations. It required dedicated IT infrastructure - servers, databases, network administration. Small agencies and freelancers could not afford it. And the server model assumed that translators were in the same office, or at least connected to the same VPN. The rise of distributed, remote workforces - translators scattered across continents, working from home on different schedules - strained the server model to its breaking point.

Generation 3: Cloud-Based (2010s–present)

The third generation solved the infrastructure problem by eliminating it. Instead of hosting a server, organizations could rent one - or rather, rent access to a platform that handled all the infrastructure transparently.

Memsource (founded 2010, which acquired Phrase in 2021 and later unified under the Phrase brand) was the pioneer of cloud-native TM. From the beginning, Memsource was designed as a web-based platform: the TM lived in the cloud, the translator worked in a browser-based editor, and everything - project management, TM management, terminology, QA, billing - was handled through a single web interface. There was nothing to install, no server to maintain, no database to back up. The platform scaled automatically: a team of two translators and a team of two hundred used the same infrastructure.

Smartcat (founded 2016) took the cloud model further by adding a marketplace. Translators could create profiles, bid on projects, and work directly with clients through the platform. The TM was a network asset, shared across projects and clients, growing with every translation done on the platform. Smartcat's AI-powered features - adaptive MT, quality estimation, automated project matching - represented a new level of integration between TM and machine learning.

Crowdin and Lokalise focused on the developer audience, integrating TM directly into software development workflows. A developer pushing code to GitHub could trigger an automatic localization workflow: new strings would be extracted, pre-translated from the TM, sent to translators, and the localized files would be pulled back into the repository - all without manual intervention. This was continuous localization, and it required a fundamentally different architecture from the project-based model of Generations 1 and 2.

The cloud generation brought several paradigm shifts:

Zero infrastructure - no servers, no databases, no IT support. The platform handled everything.

Real-time collaboration at global scale - translators in Tokyo, Berlin, and São Paulo could work on the same project simultaneously, sharing a single TM that updated in milliseconds.

API-first design - cloud platforms exposed their functionality through REST APIs, enabling integration with CMS platforms, code repositories, and custom workflows.

AI-native features - cloud platforms could afford to run expensive neural models on their servers, offering adaptive MT that learned from translator corrections, quality estimation that predicted the effort required for each segment, and automated project matching that assigned work to the best-suited translator.

Usage-based pricing - instead of buying perpetual licenses, organizations paid monthly subscriptions based on volume, number of users, or features. This lowered the barrier to entry for small teams and made TM technology accessible to organizations that could not justify a five-figure software investment.

The cloud generation also brought new concerns. Data sovereignty became a major issue: when your TM lives on a server in a jurisdiction you do not control, who owns it? Who can access it? What happens if the platform goes out of business? The TM ownership disputes that had simmered in the server era became acute in the cloud era, as platforms began using customer TMs to train their MT engines - sometimes without explicit consent.

The Trados Story: From LSP to £854 Million Exit

No company shaped the TM industry more than Trados. Its story is a classic arc of entrepreneurship, market dominance, acquisition, and reinvention - with a twist ending that no one saw coming.

Trados was founded in 1984 by Jochen Hummel and Iko Knyphausen in Stuttgart, Germany. It began as a language services provider - a translation agency, not a software company. The tools came later, born from the same frustration that had driven Peter Arthern a decade earlier: the waste of retranslating the same content.

Trados's first software product was not a TM at all. In 1990, they released MultiTerm, a multilingual terminology management system. The European Commission purchased the first 200 licenses, providing crucial early revenue and validation. MultiTerm was followed in 1992 by Translator's Workbench, the first Trados product to combine TM functionality with a user-friendly interface. A Windows version followed in 1994.

Trados was not the first TM system on the market. It was preceded by IBM TranslationManager/2 (1991), STAR Transit (1991), and Eurolang Optimizer (1992–1993). But Trados succeeded where others did not - and the reasons why, still debated in the industry today, are examined at the end of this chapter.

By the early 2000s, Trados had achieved what no other CAT tool had: it was the default. New translators learned Trados because that was what the industry used. Agencies required Trados because that was what their clients required. The circle was closed.

The SDL acquisition (2005). In June 2005, SDL plc - a British company that had built its business around web content management and translation workflow - announced plans to acquire Trados for approximately $60 million. The transaction was completed in early July 2005.

The acquisition was controversial. SDL was not a CAT company; it was a TMS (translation management system) and web content company. Many translators feared that SDL would neglect the desktop tool in favor of its server products. For a time, those fears seemed justified. The transition from "Trados" to "SDL Trados" was rocky. The release of SDL Trados Studio 2009 - the first version to replace the Workbench/TagEditor architecture with a unified editor - was met with resistance from translators who had spent years mastering the old interface.

But SDL also brought resources that Trados had lacked. SDL invested in development, expanded the product line, and - most importantly - kept the installed base intact. Trados remained the market leader, even as competitors like memoQ and Memsource gained ground.

The RWS acquisition (2020). On August 27, 2020, RWS Holdings - a British intellectual property and language services company - announced the acquisition of SDL in an all-share merger valued at approximately £854 million ($1.13 billion). The deal closed on November 4, 2020.

The RWS acquisition was a different kind of event. SDL had been a public company, valued at roughly £854 million. RWS was also a public company, larger and more diversified. The merger created a language services giant with combined revenue of over £700 million.

For Trados, the RWS acquisition brought a change of name - "SDL Trados" became "Trados Studio" again - and a renewed focus on the desktop product. RWS positioned Trados as the centerpiece of its AI-powered translation strategy, integrating it with its Language Weaver MT engine and investing in generative translation features.

But the most fascinating chapter in the Trados story is the one being written now by its founder. In recent years, Jochen Hummel has argued that traditional CAT tools are becoming obsolete - a "sunset CAT" moment. His current project, Semiox, aims to "reinvent multilingual" by moving beyond segment-based TM to concept-based knowledge systems. The man who built the industry's defining tool is now declaring its limitations. This is not hypocrisy; it is the perspective of someone who understands, better than anyone, what the technology can and cannot do.

The Wordfast Story: The Rebel That Almost Won

Wordfast Classic was initially freeware, which made it wildly popular in the freelance community. By 2002, it had thousands of users—not enough to overthrow Trados, but enough to create a genuine alternative ecosystem.

Wordfast's rise was fueled by offering the exact opposite of the market leader. As Trados raised prices and added complexity, Wordfast offered a free (or cheap), simple alternative. As Trados locked users into proprietary binary databases, Wordfast offered a transparent text file format. As Trados required a multi-step installation process, Wordfast required only that you open a Word document and run a macro.

In 2006, Wordfast LLC was formed, with ownership held by Phil Shawe and Elizabeth Elting - the founders of TransPerfect, the world's largest LSP. Champollion sold the rights to Wordfast Server but remained CEO and Chief Architect. The company expanded its product line: Wordfast Classic (the original macro-based tool), Wordfast Pro (a standalone Java application that ran on Windows, Mac, and Linux), Wordfast Anywhere (a web-based version), and Wordfast Server (for team collaboration).

Wordfast never overtook Trados. By the time it had the resources to compete seriously, Trados's network effect was too strong. But Wordfast changed the industry in lasting ways. It forced prices down. It pushed the industry toward cross-platform compatibility. It demonstrated that CAT tools did not need to be monolithic, expensive, or opaque. And it gave thousands of translators access to TM technology who would otherwise have been priced out.

The 2017 legal dispute between Wordfast LLC and TransPerfect - a messy fight over code rights and ownership - was a sad coda to a story that had always been about democratizing access to translation technology. But the legacy endures: Wordfast proved that there was room in the CAT market for something other than Trados.

Why Trados Won

The question "Why did Trados win?" is one of the most debated in the translation industry. The answer is not that Trados was technically superior - in many ways, it was not. Wordfast was simpler and more portable. Déjà Vu X had more sophisticated matching. STAR Transit had a more elegant document-based architecture. memoQ had better server collaboration.

The deeper reasons lay elsewhere:

• First, the Microsoft partnership. In the 1990s, Microsoft acquired a 20% stake in Trados and adopted its tools for internal localization. This was a seal of approval that no competitor could match. If Microsoft - the world's largest software company, the company that was defining the desktop computing experience - used Trados, then Trados must be the right choice. The Microsoft partnership gave Trados credibility, visibility, and a steady stream of revenue.
• Second, Windows dominance. Trados was a Windows-native application at a time when Windows was becoming the universal desktop platform. Competitors that ran on OS/2 (IBM TranslationManager) or required specialized hardware were fighting a losing battle. Trados rode the Windows wave.
• Third, translator-focused marketing. Trados understood that the translator, not the IT department, was the decision-maker. They marketed to translators - at conferences, in trade publications, through word of mouth. They made the tool feel like a translator's tool, not a corporate IT system. This created a grassroots adoption dynamic: translators learned Trados, demanded Trados from their employers, and the employers bought Trados licenses.
• Fourth, the network effect. As more translators used Trados, more TMs were created in Trados format. As more TMs were created in Trados format, it became harder to switch to another tool. The TM itself became a lock-in mechanism. A translator with a decade of Trados TMs could not easily move to Wordfast or memoQ - not because the formats were incompatible (TMX existed), but because the workflow, the shortcuts, the muscle memory were all Trados.

In short, Trados won on timing and critical mass. It became the standard not because it was the best, but because it was the first to reach critical mass - and once it had, the network effect made it nearly impossible to dislodge.

This is a pattern that repeats across technology history. VHS was not better than Betamax. Windows was not better than Mac OS. Trados was not better than its competitors. But in each case, the product that achieved critical mass first became the default, and the default became the standard.

The lesson for the next generation of translation technology is clear: technical superiority is not enough. Timing, partnerships, and network effects matter more. The next Trados - whatever it is - will not win by being better. It will win by being in the right place at the right time.

The evolution of TM from local databases to cloud platforms, from proprietary formats to open standards, from a single dominant tool to a fragmented ecosystem, set the stage for the industry we have today. But the story does not end with cloud migration. The next chapter examines how TM functions in the contemporary translation industry - the workflows, the economics, the ownership disputes, and the quiet crisis of a technology that has reached its architectural ceiling.

7. TM in the Industry Today

The Tools Landscape

The CAT tool market in 2026 is a study in consolidation and fragmentation at the same time. On one hand, the market has consolidated around a small number of major platforms. On the other hand, no single tool dominates the way Trados did in the 2000s.

According to the ProZ.com 2023 survey - the most recent public ranking available - the top three tools by usage are:

1. Trados Studio (RWS) - still the market leader, especially among professional translators
2. memoQ - strong in the LSP and enterprise segment, particularly in Central and Eastern Europe
3. Memsource / Phrase - the leading cloud-native platform, now unified under the Phrase brand

Below these three, a long tail of specialized and regional tools competes for market share: Smartcat with its marketplace model and 500,000+ translator network, Crowdin and Lokalise focused on developer-centric continuous localization, Wordfast still used by freelancers who prefer lightweight tools, Across strong in the DACH region, and OmegaT as the leading open-source option.

The most striking fact about the CAT tool market is that no public, vendor-neutral market share data exists. Nimdzi, Slator, and CSA Research - the three major industry analysts - do not publish numeric rankings. The best available data comes from translator surveys, which measure awareness and usage, not revenue or license counts. This opacity is itself a sign of the industry's maturity: the tools have become infrastructure, and infrastructure is invisible.

Cloud vs. Desktop

The migration to the cloud is well advanced but not complete. The majority of tools now offer cloud connectivity, but desktop clients remain important - especially for freelancers who work offline, handle sensitive data subject to localization laws, or simply prefer the performance and familiarity of a native application.

The trend is toward hybrid models: Trados and memoQ now offer cloud connectivity alongside their desktop clients, allowing translators to work online or offline and synchronize when connected. Cloud-native platforms like Phrase, Smartcat, and Crowdin have gained significant market share, particularly among organizations that want to avoid IT infrastructure entirely.

The Modern Translation Workflow

The contemporary translation workflow is a multi-stage process that integrates TM, MT, terminology, and quality assurance into a single pipeline:

1. Project preparation - the project manager identifies relevant TMs (client-specific, domain-specific, general), attaches termbases, and configures MT engines. Source documents are uploaded and segmented by the CAT tool.

2. Pre-translation - the tool auto-fills target segments with TM matches above a configurable threshold (typically 75%+). Segments without adequate TM matches may be pre-filled with MT output. A leverage report is generated, showing the percentage of exact matches, fuzzy matches, and new words - this becomes the basis for pricing.

3. Segment-level production - the translator moves through segments, with the CAT tool retrieving TM matches ranked by similarity percentage. Exact matches (100%) are reviewed and accepted. Fuzzy matches (75–99%) show differences highlighted in color. Context matches (101%) - where both the segment and its surrounding context match exactly - offer the highest reliability. For segments with no match, the translator works from scratch, possibly assisted by MT suggestions or termbase lookups.

4. Quality assurance - automated QA checks verify number consistency, tag integrity, terminology compliance, and spelling. A human reviewer then checks the translation against the source, TM suggestions, and termbase. Corrections are fed back into the TM.

5. Delivery and TM update - the finalized translation is delivered, and new segment pairs are committed to the TM, enriching it for future projects.

6. Continuous localization - in developer-focused workflows, platforms like Crowdin and Lokalise integrate with GitHub, GitLab, and Bitbucket. When new strings are pushed, the platform automatically detects changes, pre-translates from the TM, and creates tasks for translators. Localized content is pulled back into the repository automatically, enabling daily or weekly release cycles rather than traditional project-based translation.

The Economics of TM Today

The match-based pricing model that emerged in the 1990s remains the industry standard, but it is under increasing pressure. The typical discount grid still looks much as it did twenty years ago, locking freelancers into 30% to 60% discounts for fuzzy matches and up to 80% discounts for exact matches.

But the assumptions underlying this grid are being challenged from multiple directions. Guerberof Arenas's finding, discussed in Chapter 4 - that MT post-editing can outperform TM fuzzy matches in the 80–90% range - undermines the premium the grid has traditionally placed on TM content. Furthermore, the rise of adaptive MT, which learns from TM data in real time, blurs the boundary between "human-approved" and "machine-generated" translations. The growing awareness that TM productivity gains are captured primarily by agencies and clients, not by translators, has fueled intense calls for pricing reform.

The ELIS 2020 survey found that 40% of freelance translators reported being unable to earn enough from translation alone. By ELIS 2024, the financial position of independent language professionals had "further deteriorated" - the global median per-word rate fell from €0.149 to €0.101, and a majority of freelancers reported price drops. ELIS 2025 showed the trend intensifying: only 57% of freelancers earn enough (meaning 43% do not), and for the first time, actual MT usage exceeded 50% in professional work - a tipping point where increased technology use is squeezing pricing and undermining confidence in financial stability. The CIOL 2023 survey found that 59% cited low rates as their most common challenge. These numbers reflect a structural problem: the TM discount grid, combined with the increasing volume of MT post-editing work at lower rates, has compressed translator incomes even as productivity has increased.

TM Ownership and Governance

One of the most contentious issues in the industry is who owns the TM. When a translator works on a client's project, who owns the resulting translation memory - the translator, the LSP, or the end client?

The answer is entirely contractual. There is no legal default that determines TM ownership. Some contracts specify that the LSP owns the TM, others that the client owns it, and still others that the translator retains ownership of their personal contributions. The TMX format makes TMs portable - they can be exported and moved - but portability does not equal ownership.

TM ownership disputes are common and often acrimonious. A client that has paid for years of translations may expect to own the resulting TM. An LSP that has invested in building and maintaining the TM may claim it as a corporate asset. A translator who created the translations may argue that the TM represents their intellectual labor. There is no industry-wide standard for resolving these disputes, and the lack of clarity creates friction at every stage of the client-LSP-translator relationship.

The Quiet Crisis

Beneath the surface of the modern TM industry, a quiet crisis is unfolding. The technology that powered the localization boom of the 1990s and 2000s is showing its age. The segment-level, fuzzy-matching paradigm that made TM viable has reached its structural limits. The reuse ceiling, the context loss inherent in sentence-level segmentation, the lexical rather than semantic matching - these are not problems that can be solved by incremental improvement. They are architectural constraints.

The industry's response has been to layer new technologies on top of the old architecture: MT integration, adaptive MT, quality estimation, neural fragment recall. These innovations have extended the life of the TM model, but they have not addressed its fundamental limitations. The result is a system that is increasingly complex, increasingly expensive to maintain, and increasingly difficult to explain to newcomers.

The next chapter examines what comes after the segment - and why the answer may be that the segment itself was always a temporary solution, built for human translators and outgrown by the machines that now do the translating.

8. The Future - The Asset Survives, the Mechanism Is Dying

The Central Thesis

The argument of this essay can be stated simply: Translation Memory as a valuable knowledge asset will endure. Translation Memory as a rigid, sentence-by-sentence retrieval engine built on lexical string matching has reached its ceiling.

This distinction - between the asset and the mechanism - is the key to understanding what comes next. The accumulated corpus of human-approved translations that organizations have built over decades is immensely valuable. It represents millions of dollars of investment, thousands of hours of expert labor, and an irreplaceable record of terminological and stylistic decisions. No one is suggesting that this asset should be discarded.

But the mechanism that has been used to access this asset - the segment-and-fuzzy-match paradigm - is showing its age in ways that no amount of incremental improvement can fix. The problems are structural, not incidental.

Why the Mechanism Is Dying

Context Loss by Construction. Segmentation, by definition, enforces sentence-level isolation. A segment cannot see the preceding paragraph, grasp document context, or follow running terminology decisions. This is precisely where Large Language Models (LLMs) pull ahead. While NMT systems still lead on surface-level metrics like COMET in most production benchmarks, LLMs excel at the kind of contextual reasoning that segmentation destroys - inferring a character's voice, following a running joke, maintaining register across paragraphs - because they can ingest surrounding lines instead of translating in a vacuum.

Lexical, Not Semantic, Matching. Fuzzy matching scores surface-string similarity rather than true meaning. Two segments that mean the exact same thing but use different words will score as a no-match. Conversely, two textually similar segments that mean entirely different things will yield a high match. A segment reading "Press the button to start" and another reading "Press the button to begin" match highly. However, a semantically identical segment phrased as "To start, press the button" will not match at all.

Fragmented Cohesion. When we stitch independently translated segments back together, the result is often a patchwork of inconsistent pronouns, register drift, and broken terminology. The industry effectively pays twice: once to translate the fragmented pieces, and again for a human post-editor to repair the contextual seams that segmentation broke in the first place.

A Flawed Unit of Reuse. True repetition rarely lives perfectly at the sentence level. It exists at finer grains - terms and clause fragments - or coarser grains - entire chapter variants. The sentence-level segment is a compromise that systematically misses the most valuable repetition on both ends of the spectrum - which is why, by Planas's never-refuted estimate, sentence-level TM usefully applies to only a fraction of the world's translated documents.

The Decay of Translation Memory. Alignment errors and bad segments propagate and compound over time, turning the database into a liability. A corpus is only as trustworthy as its worst entries, and traditional fuzzy matching has no built-in mechanism to weight out the bad data. This is what some in the industry have begun calling "linguistic debt" - the accumulated cost of stale segments, inconsistent terminology, and error propagation that compounds over time, analogous to technical debt in software engineering. TMs degrade through poor organization, mixed translation providers, linguistic evolution, and simple neglect. The segment-level mechanism has no built-in way to detect that terminology has evolved, flag entries whose context no longer applies, or prevent a single bad translation from replicating across dozens of projects. Like financial debt, the cost compounds: the longer you defer maintenance, the more expensive it becomes to fix, and the more damage the bad entries do in the meantime.

Blindness to Audience and Intent. A segment database stores one target for one source, fundamentally ignoring that the same source text requires different translations depending on the tone, audience, and communicative intent. Purpose-adapted machine translation - where explicit intent instructions guide the output - is now a measured, viable LLM capability. A static segment cannot do this.

The New Architecture: Beyond the Segment

The replacement for this aging paradigm is not simply "throwing LLMs at the problem." Instead, the industry is converging on a sophisticated, layered architecture where the segment is demoted from the core paradigm to just one retrieval signal among many.

Full-Context Document Translation. Purpose-built LLMs are beginning to reason across entire documents, an advancement hailed as the most significant evolution since neural MT. This delivers full-document context awareness for tone, intent, and terminology. As a translation step, segmentation simply vanishes - there is no need to chop text into sentences when a model can hold the entire document in its context window.

From TMs to Semantic Vector Stores. We are not deleting our past translations; we are re-encoding them as embeddings to be retrieved semantically at inference time. Retrieval-augmented NMT can perform zero-shot domain adaptation by accessing customer-specific parallel data during inference rather than during training. Research shows that combining TM and glossary knowledge, using hierarchical chunking to preserve context, beats either method alone without requiring fine-tuning. In the market today, translation memories are operating as neural suggestion engines capable of lifting domain-specific accuracy to 90%.

This is not a theoretical future - it is already happening. Custom.MT fine-tunes GPT-3.5 and GPT-4 on TMX and TBX data to produce domain-specific translations. Crowdin pre-trains LLMs on customer TM assets so the model provides personalized results. ModernMT uses TM segments as a primary adaptation source, combining them with corrective feedback and document-level context to adjust MT output in real time. RWS Language Weaver continuously and automatically trains with user feedback, dictionaries, and uploaded TMs. The asset survives, but the retrieval mechanism has been upgraded to vector similarity and neural fine-tuning.

Adaptive MT: The Boundary Dissolves. The most vivid example of the mechanism evolving is adaptive machine translation - MT that learns during use while translators are post-editing, rather than only after batch training cycles. ModernMT uses a dual architecture: a large background model trained on billions of general-domain sentences, and a lightweight foreground model built on-the-fly for a specific project, customer, or document. When a translator corrects an MT suggestion, the correction is stored in TM and instantly processed by the foreground model - within milliseconds, without a full retrain. Lilt uses interactive, keystroke-level learning embedded directly in the translation interface. RWS Language Weaver offers continuous automatic training with feedback, dictionaries, and TMs, integrated with Trados Studio.

In adaptive MT, there is no clear line between "retrieving a stored translation" and "generating a new translation." The system does both simultaneously, using TM data to constrain and guide neural generation. The TM is no longer a lookup table - it is a continuous learning signal that shapes the behavior of a neural model in real time. The boundary between TM and MT, which the industry spent decades maintaining, has dissolved.

DeepL Smart Match: The Mechanism Evolves in Real Time. In November 2025, DeepL introduced smart match - a feature that uses AI to automatically adapt translation memory entries to new, non-identical source segments. Instead of simply copying the old TM segment (as traditional fuzzy matching does), DeepL's AI rewrites the stored translation to fit the new source: resolving discrepancies in wording and structure, adjusting grammar for number and tense, and updating variables such as dates and numbers automatically. If your TM contains "Our conference will take place in Berlin on March 15, 2025" and the new source says "March 17, 2026," smart match updates the date while preserving the approved structure and phrasing.

This is the mechanism evolving in its purest form. The asset - the TM of approved translations - is central to the system. But the mechanism has been transformed: instead of a rigid, character-level fuzzy match that shows the old translation and expects the human to adapt it, an AI system now semantically understands the differences and rewrites the translation automatically. The TM is no longer a static lookup table - it is a dynamic resource that an AI engine actively interprets and adapts. From "here's what we did last time" to "here's what we would have done, adapted for this new context."

The Rise of Agentic Pipelines. Monolithic CAT tools are giving way to orchestrated sequences of specialized steps. Extraction, drafting, automatic post-editing, terminology enforcement, and document reconstruction are each handled by small, task-specific models. This aligns with projections that organizations will increasingly rely on small, task-specific models over general-purpose LLMs, shifting the industry toward "Language Operations" where translation is just one component of a broader workflow.

Quality Estimation as the Conductor. Machine Translation Quality Estimation (MTQE) is stepping up as the new control layer. Instead of the legacy approach of reviewing every single segment, MTQE routes high-confidence output straight to publication and sends only uncertain segments to human reviewers. Here, the segment survives, but its role has inverted: it is no longer the unit you translate against; it is the unit you score against.

The Future of Segmentation

If the segment is dying as the primary unit of translation, what replaces it? The answer is not a single new unit but a flexible, context-dependent approach.

LLM-based segmentation is already a reality. The SaT model (2024) achieves state-of-the-art sentence boundary detection across 85 languages without relying on punctuation - a capability that would have seemed like science fiction a decade ago. LLMs can identify discourse units, topic boundaries, and translation-relevant chunks that no rule-based system can capture.

Sub-segment and chunk-based systems have pointed the way for two decades. SIMILIS (2005) claimed 80% reuse against ~20% for sentence-level TM - a vendor's numbers, but ones the industry never tested, let alone beat. Neural Fragment Recall (Trados, Q4 2024) brings neural alignment to subword-level fragment matching, though initially for only three language pairs. The barrier to adoption is not technical - it is economic and organizational. The industry has invested too much in sentence-level infrastructure to abandon it overnight.

Adaptive segmentation - where the CAT tool adjusts its segmentation to the translator's cognitive patterns and the text's difficulty - is an emerging research direction. Studies show that cognitive segmentation varies by expertise and text type. A tool that adapts to the translator rather than forcing the translator to adapt to the tool could significantly improve both productivity and quality.

Multimodal segmentation - for sign language video, audio transcription, and subtitle timing - represents a frontier that text-based SRX rules cannot address. As translation expands beyond written text, the concept of the "segment" will need to become more flexible and context-aware.

The Three Scenarios

Where is this heading? The industry's future can be understood through three scenarios, each with different implications for the role of TM.

Scenario A: TM Dies. In this scenario, the segment-based TM model is gradually abandoned as LLMs and NMT become good enough to handle most translation tasks without human assistance. TM survives only as training data for MT engines. This is the "sunset CAT" scenario that Jochen Hummel himself has predicted. It is the most dramatic scenario, and the least likely in the short term - but it cannot be dismissed.

Scenario B: TM Evolves into an AI Knowledge Base. This is the industry consensus. TM does not disappear, but its role shifts from the primary engine of translation production to a high-trust memory layer that grounds and constrains AI output. TM becomes the "source of truth" for regulated content, the training data for domain-adaptive MT, and the quality anchor against which AI-generated translations are measured. The asset survives, enriched and expanded, while the retrieval mechanism is upgraded to vector similarity and neural search.

Scenario C: TM Remains a Niche for Regulated Industries. In this scenario, the mainstream translation industry moves to AI-first workflows, but TM retains a critical role in regulated domains - medical, legal, financial, pharmaceutical - where traceability, auditability, and human approval are legally required. Under regulations like the EU AI Act, these domains structurally require human translation and independent revision, regardless of the underlying technology. TM provides the audit trail that regulators demand.

The most likely outcome is a combination of B and C: TM evolves into an AI knowledge base for most content, while remaining a compliance tool for regulated content. The segment-based retrieval mechanism fades, but the asset - the accumulated corpus of human-approved translations - grows in value.

The Business Reality: Navigating the Caveats

This orchestrated future is compelling, but it is not without friction. Real business constraints dictate that this transition will be selective, not uniform.

First, NMT still holds the crown for absolute fidelity in structured, high-resource content. While LLMs excel at fluency, they are more prone to hallucinating, omitting text, or producing overly literal output with lexical inconsistencies. Benchmarks show that while LLMs perform comparably to junior translators, they still lag behind senior experts and commercial NMT systems for certain language pairs.

Second, speed and cost still heavily favor the old stack at scale. LLM-based translation is substantially slower and more expensive than NMT at high volume. For massive volumes of commodity content, the traditional NMT-plus-TM combination remains the economic winner.

Third, high-risk domains remain squarely in human hands. Under regulations like the EU AI Act, medical, legal, and financial content structurally requires human translation and independent revision, regardless of what underlying tech stack or quality score is used.

Fourth, the economics of transition are daunting. TM is an asset that LSPs have invested in for decades. The pricing model is built around segments. 93% of full-time translators in ProZ.com's 2023 survey use CAT tools. Changing the paradigm means changing not just the technology but the entire economic structure of the industry - and that will not happen overnight.

The Deeper Why: The Paradigm Inverts

Step back far enough and the pattern becomes clear. Every piece of the classic CAT stack - segmentation, translation memory, fuzzy matching - was designed to help a human reuse past work, because the human was the only one who could translate. That premise no longer holds. The industry is moving from a world built to "help the human reuse segments" into a world designed to "let the model see the whole, and route the exceptions to humans." What the first world treated as its foundation, the second treats as an obstacle.

9. Conclusion - The Scaffold and the Cage

The story of Translation Memories is a story of a technology that solved a real problem - the waste of retranslating the same content - and in doing so, created an industry, a profession, and a way of working that has persisted for three decades.

It is also the story of a design decision that outlived its context. The sentence became the unit of translation at a time when computers were slow, memory was expensive, and the idea of a machine producing fluent prose was still science fiction. Three decades later, that choice - and the reuse ceiling that comes with it - still defines what the technology can and cannot do.

The pioneers who built this technology - Arthern, Kay, Melby, Hummel, Champollion, Witkam, Sadler, Nagao - were not trying to create a permanent architecture. They were trying to solve the problems in front of them: wasted work, inconsistent terminology, the isolation of the translator working alone. The tools they built for themselves grew into an industry - and that industry must now answer the question its founders never had to: what happens when the machine no longer needs the scaffold?

The answer is not that the scaffold disappears. The accumulated corpus of human-approved translations - the asset - is too valuable to discard. It will be re-encoded, re-purposed, and re-integrated into new architectures. It will become the training data for domain-adaptive models, the ground truth for quality estimation, the audit trail for regulated content. The asset survives.

But the mechanism - the segment-and-fuzzy-match paradigm - will fade. Not because it was a bad idea, but because it was a temporary solution to a problem that no longer exists in the same form. The bottleneck has moved from reuse to fidelity, from fragmentation to verification. The tools that optimized for the old bottleneck are not optimized for the new one.

The loop closes in an unexpected way. The translator in Brussels in 1978 would not recognize the tools of 2026. But she would recognize the problem: how to ensure that good translations are not wasted. Peter Arthern proposed a two-screen workstation with TERRIER - a text retrieval system for reusing translations. Retrieval-augmented NMT in 2026 does exactly the same thing - but semantically rather than lexically, holistically rather than segment by segment. The idea is the same; the implementation has changed. The asset survives. The mechanism evolves.

The real work over the next few years is liberating our data from the segment, without losing the immense value it has provided us for decades. The scaffold that helped us build an industry must not become the cage that prevents us from building the next one.

Sources and Further Reading

History & Origins

• Arthern, P. J. (1978). "Machine Translation and Computerized Terminology Systems: A Translator's Viewpoint." Translating and the Computer, London. https://aclanthology.org/1978.tc-1.5.pdf
• Kay, M. (1980). "The Proper Place of Men and Machines in Language Translation." Xerox PARC Research Report CSL-80-11. https://aclanthology.org/www.mt-archive.info/80/Kay-1980.pdf
• Harris, B. (1988). "Bi-text, a new concept in translation theory." Language Monthly, 54, 8–10.
• Nagao, M. (1984). "A Framework of a Mechanical Translation between Japanese and English by Analogy Principle." In Artificial and Human Intelligence, Elsevier.
• Melby, A. K. (1981). "A Suggestion Box Translator Aid." BYU Translation Research Group. https://www.erudit.org/en/journals/meta/1981-v26-n1-meta291/003619ar/
• Rode, T. (2000). "Translation memory: Friend or Foe?" International Journal for Language and Documentation.
• Trados Blog (2019). "The past and present of translation memory technology." https://www.trados.com/blog/the-past-and-present-of-translation-memory-technology/
• AIETI: "Translation memory systems." https://www.aieti.eu/enti/memories_ENG/entry.html
• Wikipedia: "Translation memory." https://en.wikipedia.org/wiki/Translation_memory
• Somers, H. (2003). "EBMT and TM: What's the difference?" https://personalpages.manchester.ac.uk/staff/harold.somers/ebmtvstm_ijt.pdf
• Witkam, T. (2006). "History and heritage of DLT." https://mt-archive.net/05/Witkam-2006.pdf
• ALPS/TSS history - early TM implementation. https://scholarsarchive.byu.edu/cgi/viewcontent.cgi?article=7794&context=facpub
• Hutchins, W.J. (1998). "The development of machine translation." https://aclanthology.org/www.mt-archive.info/00/HEL-2001-Hutchins.pdf

People

• Wikipedia: Martin Kay - https://en.wikipedia.org/wiki/Martin_Kay
• ACL: "Vale Martin Kay" - https://www.aclweb.org/portal/content/vale-martin-kay
• Computational Linguistics (2022). "Obituary: Martin Kay." 48(1), 1–3.
• Slator (2019). "Creator of Trados Joins Summa Linguae Board, Says CAT Tools Will Become Obsolete." https://slator.com/creator-of-trados-joins-summa-linguae-board-says-cat-tools-will-become-obsolete/
• Semiox: About - https://www.semiox.com/about
• NTIF: Jochen Hummel speaker profile - https://ntif.se/speakers/jochen/
• LocWorld: Jochen Hummel speaker profile - https://locworld.com/speakers/jochen-hummel/
• Wikipedia: Trados Studio - https://en.wikipedia.org/wiki/Trados_Studio
• Wikipedia: Wordfast - https://en.wikipedia.org/wiki/Wordfast

Segmentation & SRX

• Kiss, T. & Strunk, J. (2006). "Unsupervised Multilingual Sentence Boundary Detection." Computational Linguistics, 32(4), 485–525. (The Punkt algorithm)
• Brenndoerfer, M. "Sentence Segmentation and the Punkt Algorithm." https://mbrenndoerfer.com/writing/sentence-segmentation-punkt-algorithm-nlp
• LISA OSCAR (2008). SRX 2.0 Specification. (Maintained by GALA)
• Okapi Framework: SRX documentation - https://okapiframework.org/wiki/index.php/SRX
• CLARIN: SRX specification - https://standards.clarin.eu/sis/views/view-spec.xq?id=SpecSRX
• Lipski, J. "Using SRX standard for sentence segmentation in LanguageTool." https://jareklipski.com/static/Using_SRX_standard_for_sentence_segmentation_in_LanguageTool.pdf
• memoQ documentation: Segmentation rules - https://docs.memoq.com/current/en/Concepts/concepts-segmentation-rules.html
• Wordbee: SRX rules documentation - https://help.wordbee.com/wbt/segmentation-srx-rules
• Phrase: Segments documentation - https://support.phrase.com/hc/en-us/articles/5709678012828-Segments-TMS
• Trados: "Introducing Neural Fragment Recall." https://www.trados.com/blog/introducing-neural-fragment-recall-a-smarter-way-to-work/
• Planas, E. (2005). "SIMILIS: Second-generation translation memory software." Translating and the Computer 27, Aslib, London. https://aclanthology.org/2005.tc-1.2.pdf (Vendor presentation; the 20%/80% reuse figures are asserted, not measured.)
• Flanagan, M. (2015). "Subsegment recall in TM: perceptions and expectations." JoSTrans, 24. https://www.jostrans.org/article/view/8056
• Dragsted, B. (2005). "Segmentation in translation and translation memory systems." Target, 17(1), 1–24.
• Läubli, S., Simianer, P., Wuebker, J., Kovacs, G., Sennrich, R., & Green, S. (2022). "The impact of text presentation on translator performance." Target, 34(2), 309–342. (Preprint: arXiv:2011.05978)
• ICU: BreakIterator boundary analysis - https://unicode-org.github.io/icu/userguide/boundaryanalysis/
• WNUT (2020). "Sentence boundary detection on line breaks in Japanese." https://aclanthology.org/2020.wnut-1.10/
• Thai word and sentence segmentation using CRF - https://www.jstage.jst.go.jp/article/transinf/E101.D/12/E101.D_2018EDP7016/_article

Economics & Productivity

• Yamada, M. (2011). "The effect of translation memory databases on productivity." In Translation Research Projects 3, Intercultural Studies Group, URV.
• Guerberof Arenas, A. (2008–2014). "Productivity and quality in the post-editing of outputs from translation memories and machine translation." Various publications, DCU.
• Vela, M. (2014). "Quantifying the influence of MT output in TM on translator performance." EACL Workshop on Humans and Computer-Assisted Translation. https://aclanthology.org/W14-0314.pdf
• Vallianatou, F. (2005). "CAT Tools and Productivity." Translation Journal, 34.
• Läubli, S., Amrhein, C., Düggelin, P., Gonzalez, B., Zwahlen, A., & Volk, M. (2019). "Post-editing Productivity with Neural Machine Translation: An Empirical Assessment of Speed and Quality in the Banking and Finance Domain." Proceedings of MT Summit XVII, Dublin. https://aclanthology.org/W19-6626/
• Slator (2019). "MT Post-Editing Boosts Swiss Bank's Translation Productivity by Up to 60%, Study Finds." https://slator.com/mt-post-editing-boosts-swiss-banks-translation-productivity-by-up-to-60-study-finds/
• Slator (2023). "New Research Flips the Script on CAT Tools, Literally." https://slator.com/new-research-flips-the-script-on-cat-tools-literally/
• Reinke, U. (2013). "State of the art in translation memory technology." TC3, ACL Anthology.
• TAIA: "Translation Memory Explained." https://taia.io/resources/blog/translation-memory-explained/
• Dema Solutions: "Translation Memory: Strategic Multilingual Growth." https://dema-solutions.com/en/translation-memory-strategic-multilingual-growth/
• TranslatedRight: "TM leverage savings calculation example." https://www.translatedright.com/blog/translation-memory-leverage-savings-calculation-example/
• Tomedes: "What is the average translation speed?" https://www.tomedes.com/translator-hub/what-average-translation-speed.php

Pricing & Freelancer Economics

• Training for Translators (2008). "Translation Memory Discounts: Yes, No, Maybe?" https://www.trainingfortranslators.com/2008/05/01/translation-memory-discounts-yes-no-maybe/
• Meinrad: "How to negotiate prices and discounts with translation agencies." https://blog.meinrad.cc/en/how-to-negotiate-prices-and-discounts-with-translation-agencies
• XTM Cloud: "Translation Memory." https://xtm.cloud/lp/translation-memory/
• ELIS (2020, 2024, 2025). European Language Industry Survey. https://elis-survey.org/
• Slator (2025). "Key Findings: EU Commission-Backed 2025 European Language Industry Survey." https://slator.com/key-findings-eu-commission-backed-2025-european-language-industry-survey/
• CIOL (2023). Survey of UK freelance translators.

Standards & LISA

• LISA OSCAR (2005). TMX 1.4b Specification. (Maintained by ETSI LIS ISG under CC 3.0)
• ETSI: TMX specification - https://www.etsi.org/deliver/etsi_gs/lis/001_099/002/01.04.02_60/gs_lis002v010402p.pdf
• ISO 30042:2019. TBX (TermBase eXchange) v3.
• OASIS (2014). XLIFF 2.0 Specification.

Industry & Market

• Nimdzi 100 (2025, 2026). Language services industry rankings and market data. https://www.nimdzi.com/nimdzi-100-2025/
• Nimdzi Language Technology Atlas. https://www.nimdzi.com/language-technology-atlas/
• Slator (2025). Language Industry Market Report. https://slator.com/slator-2025-language-industry-market-report/
• CSA Research. Global Market Survey and post-localization era framework. https://csa-research.com/
• ProZ.com (2023). CAT tool usage survey.
• DataHorizzon Research: CAT tool market ~$1.2B (2024). https://datahorizzonresearch.com/computer-assisted-translation-tool-market-46068
• Grand View Research: TMS market ~$2.16B (2024). https://www.grandviewresearch.com/industry-analysis/translation-management-systems-market-report
• Bubbles Translation: "Translation Memory: The Asset You're Probably Not Using Properly." https://www.bubblestranslation.com/translation-memory-the-asset-youre-probably-not-using-properly/
• Translated.com: "Language Technology Value Shift to Language Intelligence." https://translated.com/language-technology-value-shift-to-language-intelligence

EU & Institutional

• DGT Translation Memory (Euramis). https://joint-research-centre.ec.europa.eu/language-technology-resources/dgt-translation-memory_en
• DGT-TM on data.europa.eu. https://data.europa.eu/data/datasets/dgt-translation-memory?locale=en
• DGT-TM on Sketch Engine. https://www.sketchengine.eu/dgt-translation-memory-parallel-corpus/
• Theologitis, D. "EURAMIS, the platform of the EC Translator." https://www.semanticscholar.org/paper/EURAMIS,-the-platform-of-the-EC-Translator-Theologitis/ecf0596e38354c6c6f46a6151d5d5049bbec3722
• DGT (2016). "Tools and Translation Workflow." https://www.scribd.com/document/367837209/Tools-and-Translation-Workflow-DGT-2016

Future, AI & Adaptive MT

• Translated.com: "The Evolution of Translation Memory: From Static to Dynamic." https://translated.com/resources/the-evolution-of-translation-memory-from-static-to-dynamic
• Translated.com: "Adaptive Neural Machine Translation: How ModernMT Works." https://translated.com/resources/adaptive-neural-machine-translation-how-modernmt-works
• ModernMT Blog: "Understanding Adaptive Machine Translation." https://blog.modernmt.com/understanding-adaptive-machine-translation/
• RWS: Language Weaver Adaptive Capabilities. https://www.rws.com/language-weaver/adaptive-capabilities/
• RWS: "How to Adapt Language Weaver MT in Trados Studio." https://www.rws.com/language-weaver/resources/how-to-adapt-language-weaver-mt-in-trados-studio/
• Slator: "State of the Art Machine Translation with Language Weaver's Bart Maczynski." https://slator.com/state-of-the-art-machine-translation-with-language-weavers-bart-maczynski/
• MachineTranslate.org: Adaptive MT. https://machinetranslate.org/adaptive
• DeepL (2025). "A new era for translation memory." https://www.deepl.com/en/blog/new-era-translation-memory
• DeepL: Customization Hub - Translation Memory. https://www.deepl.com/en/customization-hub/translation-memory
• Custom.MT: "Guide to Fine-Tuning GPT-3.5 for Translation." https://custom.mt/guide-how-to-fine-tune-gpt-35-for-translation/
• Crowdin Community: "Pre-translation via AI fine-tuned model vs translation memory." https://community.crowdin.com/t/what-is-the-difference-between-pre-translation-via-ai-fine-tuned-model-and-translation-memory/8204
• AILocThinkTank: "How Do We Train LLMs for Machine Translation." https://www.ailocthinktank.com/post/how-do-we-train-llms-for-machine-translation
• Translated.com: "AI Translation Model Customization Guide." https://translated.com/resources/ai-translation-model-customization-training-fine-tuning-guide
• Slator: "How Large Language Models Improve Document-Level AI Translation." https://slator.com/how-large-language-models-improve-document-level-ai-translation/
• Tradumàtica (2009). "Future of TM technology." https://ddd.uab.cat/pub/tradumatica/15787559n7/15787559n7a7.pdf
• Acolad (2024). "Machine Translation vs GenAI Translation Comparison." https://www.acolad.com/en/services/translation/machine-translation-genai-translation-comparison
• Inten.to (2025). "Generative AI for Translation in 2025." https://inten.to/blog/generative-ai-for-translation-in-2025/
• ModernMT Blog: "Comparing MT System Performance." https://blog.modernmt.com/comparing-mt-system-performance/
• TACL (2025). "Salute the Classic: Revisiting Challenges of Machine Translation." https://direct.mit.edu/tacl/article/doi/10.1162/tacl_a_00730/127458/
• Emerging Investigators (2024). "Large Language Models are Good Translators." https://emerginginvestigators.org/articles/24-020/pdf
• Alpha Omega Translations: "Top Five Causes of Translation Memory Degradation." https://alphaomegatranslations.com/business-translation/top-five-causes-of-translation-memory-degradation/
• Smartling: "What Is Translation Memory." https://www.smartling.com/blog/what-is-translation-memory
• Margolis, M. (2025). "Language Debt is the New Tech Debt." https://www.linkedin.com/posts/michaelmargolis_language-debt-is-the-new-tech-debt-heres-activity-7437207652792770561-A4pc