Translation Memory: Was es ist, wie es funktioniert und warum es für die KI-Lokalisierung wichtig ist

Wenn Ihr Team Produktinhalte, Support-Artikel, Dokumentationen, Kampagnen oder Software-Strings übersetzt, stehen Sie immer wieder vor demselben Problem:

• dieselben Formulierungen tauchen immer wieder auf,
• und doch kosten sie jedes Mal aufs Neue Zeit für Übersetzung, Prüfung und Freigabe.

Genau dafür wurde das Translation Memory entwickelt.

Ein Translation Memory (TM) ist der Ort, an dem Ihr Übersetzungssystem die Segmente speichert, die Ihr Team bereits freigegeben hat. Der Quelltext wird dort zusammen mit der fertigen Übersetzung abgelegt. Wenn dann das nächste Mal ein ähnlicher Inhalt auftaucht, fangen Sie nicht wieder bei Null an.

Frühere Übersetzungstools nutzten dies zur Zeitersparnis. Bei KI ist es noch wichtiger: Es zeigt dem Modell Ihren Übersetzungsstandard und welche Entscheidungen erwartet werden. Der Nutzen ist enorm:

• schnellere Bearbeitung (kein erneutes Übersetzen von Textbausteinen, Haftungsausschlüssen oder wiederkehrenden UI-Elementen)
• niedrigere Kosten, nicht nur durch die Wiederverwendung von Zeilen. Mit einer soliden TM-Basis haben wir bei Transept ein viermal günstigeres Modell auf das Niveau eines Premium-Modells gebracht.
• konsistenter Stil (Entscheidungen, die Sie vor Jahren freigegeben haben, werden bei jeder neuen Funktion wiederverwendet).

Doch wie setzt man Translation Memory bei KI-Übersetzungen um?

• Zählen Glossare und Styleguides zum TM? Und wie hält man sie aktuell?
• Wie entscheidet man, was als relevantes TM-Segment gilt?
• Wie viel Kontext benötigt die KI? Was ist zu wenig, was zu viel?
• Wie stellt man sicher, dass urheberrechtlich geschützte und sensible Informationen eines Kunden niemals an andere Kunden gelangen?

Genau das mussten wir bei Transept herausfinden. Was sollte Translation Memory bedeuten, wenn der Übersetzer nicht mehr ausschließlich ein Mensch ist? Und wie gestalten wir die Arbeit des Menschen mit diesem Memory sinnvoll, statt ihn nur eine Liste von Datenmüll abarbeiten zu lassen?

Diese Frage hat uns tief in den Kaninchenbau geführt.

Was ist Translation Memory bei der KI-Übersetzung?

Traditionell ist ein Translation Memory eine strukturierte Datenbank aus übersetzten Textpaaren. Jedes Paar enthält üblicherweise:

• Das Ausgangssegment (der Originaltext).
• Das Zielsegment (die Übersetzung).
• Metadaten – wer die Übersetzung erstellt hat, wann sie freigegeben wurde, sowie der umgebende Kontext.

Wenn ein Übersetzer ein neues Dokument öffnet, scannt die TM-Software den Text, gleicht ihn mit der Datenbank ab und schlägt bei einem Treffer die vorherige Übersetzung vor.

Das ist die klassische CAT-Definition. Sobald man jedoch mit LLMs und agentenbasierten Übersetzungssystemen arbeitet, kommen weitere Artefakte ins Spiel:

• Glossare, die während des Übersetzungsprozesses erstellt werden, um die Terminologie der KI zu stabilisieren.
• Übergabenotizen und Zusammenfassungen, die entstehen, wenn KI-Agenten Aufgaben untereinander weiterreichen.
• Denkprotokolle der Agenten aus der Übersetzung, dem Lektorat und dem Korrektorat – das Warum hinter jeder Entscheidung.
• Diskussionskontext zwischen Agenten und Menschen: Chats, Threads, Suchverläufe sowie Slack- oder Teams-Kontexte.

Figure 2 · Anatomy of a TM record

What a translation memory stores now

Traditional CATAI-era (agentic)

just the pair

SourcePure steel rejects lacquers and paints

Target«Чиста сталь відкидає лаки та фарби»

Metadataapproved by · date · file & context

…and what the agents also kept

Thinking trace

weighing  "rejects lacquers and paints"
  ├ literal    «відкидає лаки та фарби»   keeps the metaphor ✓
  ├ smoother   «не приймає покриття»      clearer, but flattens it
  └ decision   go literal, the bluntness is the point

Glossary

steel → сталь🔒paints → фарби

Handoff note

translator → editor

“Kept the steel metaphor literal. Check it reads naturally in UK.”

Discussion

Maria is «відкидає» too harsh for a product line?

Literess It mirrors the source’s bluntness. I’d keep it.

Switch to AI-era to see what an agentic pipeline adds →

Das ist für Menschen zwar weiterhin hilfreich, für KIs jedoch absolut unverzichtbar. Es ermöglicht dem Modell, jenen Kontext zu rekonstruieren, den menschliche Übersetzer in ihren Dokumenten, ihren Köpfen und ihren Gesprächen parat haben. Ironischerweise ist LLM-basierte Übersetzung sogar stärker auf TM- und CAT-Tools angewiesen als der Mensch – ein Mensch kann schließlich auch problemlos mit Stift, Papier und einem Wörterbuch übersetzen.

Wie Translation-Memory-Matches funktionieren

TM-Software unterteilt Inhalte in kleinere Einheiten, sogenannte Segmente – meist einen Satz, eine Überschrift oder eine Schaltflächenbeschriftung. Danach sucht sie nach Treffern. Wie das TM nach Treffern sucht, ist die wichtigste Disziplin in diesem gesamten Bereich.

• Exakte Treffer: Das neue Segment ist zu 100 % identisch mit einem Eintrag in der Datenbank. Die Software kann die Übersetzung automatisch einfügen.
• Fuzzy Matches: ähnlich, aber nicht identisch. Sie werden markiert, damit ein Mensch sie prüfen, anpassen oder als Inspiration nutzen kann. Meist basiert dies auf einer „Sparse Search" – dabei wird nach jedem Wort oder Lexem im Satz gesucht und Datenbank-Segmente werden danach bewertet, wie viele Übereinstimmungen sie aufweisen.
• Semantische Treffer: Ein Segment in der Datenbank hat eine ähnliche Bedeutung, auch wenn sich keine Wörter überschneiden. Hierbei kommt Dense Search zum Einsatz – Vektoreinbettungen und Retrieval. Das klassische RAG-Szenario.

Herkömmliche TMs basierten auf exakten Treffern und Fuzzy-Matches. LLMs ergänzten die semantische Ebene. Doch semantische Suche allein genügt noch nicht für eine wirklich gute Performance.

In der Literaturübersetzung sind Fuzzy-Matches entscheidend, um Eigennamen und die Lore konsistent zu halten. Im Gesundheitswesen gibt es für denselben Sachverhalt oft viele Formulierungen, weshalb semantische Suche eigentlich helfen sollte – doch oft geht der Schuss nach hinten los. Für einen Embedder im allgemeinen Bereich ist der Abstand zwischen Ileum und Ilium so gering wie der zwischen Karmesinrot und Scharlachrot.

(Das Ileum ist der letzte Teil des Dünndarms; das Ilium ist der obere Teil des Hüftknochens. Völlig verschiedene Begriffe, die in einem allgemeinen semantischen Raum einfach zu „Medizinthemen" verschwimmen.)

Man benötigt also Schutzmechanismen. Die Standarderwartung an ein Translation Memory im Jahr 2026 ist daher:

• Hybride Suche, bei der exakte, Fuzzy- und semantische Treffer kombiniert werden, um die relevantesten Ergebnisse aus der Übersetzungshistorie zu erhalten.
• Reranking, bei dem die Kandidaten im Hinblick auf den tatsächlichen Kontext neu bewertet werden, um die Relevanz sicherzustellen.
• Tree Traversal, bei dem ein Mensch oder Agent von einem Treffer zu dessen nächsten Nachbarn navigieren kann, um die Datenbank zu erkunden.

Wie der restliche Markt Translation Memory handhabt

Jedes ernstzunehmende Lokalisierungstool kann frühere Übersetzungen speichern und erneut vorschlagen. Die entscheidenden Fragen sind: Was merkt sich das System, wann vertraut es diesem Speicher und wo kommt er als Nächstes zum Einsatz?

Aus diesem Blickwinkel lässt sich der Markt in drei Ebenen unterteilen: Speicher als Wiederverwendung, Speicher als Governance und Speicher als KI-Treibstoff. Transept setzt auf eine vierte: Speicher als Entscheidungskontext.

Level 1: Memory als Wiederverwendung

Klassische CAT-Tools beantworten die älteste aller TM-Fragen: „Haben wir das schon einmal übersetzt?"

Sie sind keineswegs primitiv – viele unterstützen kontextbezogenes Matching, Fragment-Recall, MT-Plugins, Team-Server und leistungsstarke Editor-Workflows. Doch das Memory fungiert meist nur als Vorschlagsquelle neben dem Editor. Es hilft Übersetzern, vergangene Arbeit wiederzuverwenden, hält aber meist nicht fest, warum eine Version einer anderen vorgezogen wurde.

• Trados / RWS bildet den klassischen CAT-Standard – stark bei Exact Matches, Fuzzy Matches, Konkordanzsuche und In-Context Exact Matches. Das breitere Trados-Ökosystem bindet mittlerweile KI- und Language-Weaver-Workflows ein. Auf TM-Ebene bleibt der Kerngedanke jedoch die Segment-Wiederverwendung innerhalb einer CAT-Umgebung.
• memoQ geht beim klassischen TM in Bezug auf den Kontext besonders weit. Die 101 %- und 102 %-Matches prüfen, ob dasselbe Segment an derselben Stelle erscheint – was für Software-Strings, wiederkehrende Bezeichnungen und strukturierte Dateien entscheidend ist. Ein intelligenter Abruf, doch das gespeicherte Objekt bleibt das Segment im Kontext.
• Wordfast setzt auf Portabilität und Praxisnähe. Wordfast Anywhere bietet Übersetzern browserbasierte, gemeinsam genutzte TMs, Glossare, QS und MT. Der Mehrwert liegt in der Zugänglichkeit und Wiederverwendung, nicht in einer tiefergehenden Erfassung von Entscheidungen.
• OmegaT und CafeTran zeigen, dass professionelle Wiederverwendung kein reines Enterprise-Feature ist – mit kostenlosem Open-Source-Fuzzy-Matching, Match-Propagation, Unterstützung für mehrere TMs und Glossare sowie teamorientierten TM-Servern für Power-User.

Die Messlatte liegt also bereits hoch. Selbst kostengünstige und Indie-Tools beherrschen das Speichern und Wiederverwenden von Übersetzungen souverän. Der kommerzielle Wettbewerb beginnt erst dort, wo es über die reine Wiederverwendung hinausgeht.

Level 2: Memory als Governance

Die nächste Gruppe stellt eine andere Frage: „Welchem Memory sollte man für diesen Kunden, dieses Team, dieses Projekt oder diesen Workflow vertrauen?"

• Phrase TMS behandelt das Memory als eine verwaltete Ressource innerhalb einer größeren Plattform – TM, Termdatenbanken, MT-Engine-Profile, Phrase Language AI, Qualitätsbewertung, QS. Breite Abdeckung, doch das TM selbst speichert weiterhin hauptsächlich wiederverwendbare Segmente.
• Crowdin macht das Memory auf Projektebene nutzbar: durch automatisch erstellte Projekt-TMs, die Option, nur freigegebene Übersetzungen zu speichern, und die Unterscheidung zwischen einfachen 100 %-Matches und „Perfect Matches" (Text plus Kontext). Das Tool füllt Strings zwar vorab aus, speichert aber letztlich nur den freigegebenen Text und nicht die dahinterstehende Entscheidungsgrundlage.
• Smartcat organisiert das Memory entlang der jeweiligen Geschäftsbeziehung – Kunden, Abteilungen, Workspaces, KI-Übersetzungsprofile. Relevante Memories und Glossare werden automatisch eingebunden, wobei ein TM beschreibbar ist und die anderen schreibgeschützt sind. Die Stärke liegt hier im Routing und in der klaren Regelung von Zuständigkeiten.
• XTM Cloud behandelt das Memory als eine Ressource, die Status und Schutz benötigt: Einträge können freigegeben sein oder nicht, rohe MT-Ergebnisse werden nicht automatisch gespeichert, Segmente mit nachverfolgten Änderungen verbleiben im Wartestatus, bis sie akzeptiert oder abgelehnt werden, und Einstellungen regeln, ob nicht freigegebene Inhalte vorgeschlagen werden. Ziel ist die Vertrauenssteuerung.
• Wordbee trennt dauerhafte Translation Memories von temporären Projekt-Memories. Ein Projekt-Memory erfasst die Arbeit live und kann Segmente bereits während der Bearbeitung vorschlagen; im Anschluss werden die relevanten Teile in einem Master-TM konsolidiert. Das ist nah am Live-Kontext des Dokuments, bleibt aber letztlich ein Segmentspeicher.
• Bureau Works setzt konsequent auf Kontrolle: Memories sind an Abteilungen gebunden, es gibt Lese- und Schreibrechte (ausführende Übersetzer nutzen sie, nur Locale Leads dürfen sie erweitern) und ein zentraler Empfehlungs-Stream bündelt TM, LLM, klassische MT und Glossare. Das ist leistungsstark, mitunter überwältigend, und die letzte Entscheidung liegt weiterhin beim Menschen, der die Vorschläge sichtet.
• MateCat ist ein webbasierter CAT-Editor, der direkt an MyMemory für das TM und ModernMT für die MT angebunden ist. Öffentliche und private Memories speisen die MT-Vorschläge, und Live-Korrekturen verbessern die Ergebnisse noch während der Arbeit – das kommt einer „TM-gestützten adaptiven MT" näher als einem bloßen TM neben der MT. Dennoch beschränkt sich das Memory auch hier auf Segmente, Matches und Korrekturen.

Level 3: Memory als KI-Treibstoff

Die neueste Gruppe stellt die Frage, was passiert, wenn KI Übersetzungen erstellt, bearbeitet oder von ihnen lernt. Können maschinelle Ergebnisse Teil des Memorys werden? Ist vorab ein Review nötig? Kann ein Quality Score die menschliche Freigabe ersetzen? Kann das TM die Engine direkt steuern?

• Lilt nutzt das TM als Treibstoff für adaptive MT – bestätigte Übersetzungseinheiten und Termbankdaten verbessern die prädiktiven Vorschläge im Zeitverlauf. Der Ansatz setzt auf adaptive Vorhersage innerhalb der Engine statt auf ein umfassenderes Memory, das auch Kommentare, abgelehnte Alternativen und die Logik hinter den Review-Entscheidungen speichert.
• Smartling macht die Herkunft explizit: KI-Ergebnisse können in ein separates „Machine-Created Translation Memory" fließen, während menschliche oder menschlich validierte Arbeit im regulären TM bleibt. Ein starkes Vertrauensmodell – KI-Output ist wiederverwendbar, gibt sich aber nie unbemerkt als menschlich freigegeben aus.
• Lokalise nutzt das Review als Kontrollinstanz: KI- oder MT-Übersetzungen gelangen erst ins TM, wenn ein Reviewer sie in einer Review-Aufgabe akzeptiert, selbst wenn der Text nicht bearbeitet wurde. KI-Ergebnisse können so dauerhaft im Memory gespeichert werden, allerdings nur über einen menschlichen Zwischenschritt. Das sorgt für Reibungsverluste und ist suboptimal für kleine Teams, in denen Entscheidungen direkt im Tagesgeschäft fallen und sofort erfasst werden sollten.
• Transifex nutzt den TQI als Automatisierungsschranke. Normalerweise fließen generierte Übersetzungen nicht ohne Review ins TM, aber Transifex AI kann eine Übersetzung mit seinem Translation Quality Index bewerten; oberhalb eines festgelegten Schwellenwerts wird sie automatisch hinzugefügt. Der Haken dabei: Man muss dem proprietären Index vertrauen.
• Phrase Language AI fungiert als Orchestrierungsebene – sie steuert die Arbeit über verschiedene Engines und agentenbasierte Workflows, nutzt Qualitätsschätzungen, wendet Glossare an, verwaltet MT-Profile und unterstützt die Einbindung eigener Engines. Ein starkes Systemdesign, doch das TM bleibt hier nur ein Inputfaktor unter vielen neben MT, Glossar, QS und Routing.

Die Marktlücke, die wir entdeckt haben

In all diesen Bereichen beherrscht der Markt es mittlerweile gut, die finale Übersetzung zu speichern, zwischen menschlichen und maschinellen Ergebnissen zu unterscheiden, das richtige Memory anzusteuern und zu entscheiden, wann KI-Output wiederverwendbar ist. Wir haben all das als Standard vorausgesetzt.

Was man hingegen noch selten findet, ist ein Memory für den Entstehungsprozess der Übersetzung. Kaum ein Tool speichert abgelehnte Alternativen, Kommentare, den Review-Verlauf, den Suchkontext, die Freigabelogik oder den Entscheidungsweg, der erklärt, warum eine bestimmte Version den Vorzug erhielt. Beim Übersetzen fällt dieses „Datengold" ganz natürlich an – doch kaum jemand macht sich die Mühe, diesen Schatz zu heben.

Noch seltener wird dieser Verlauf in ein leistungsfähiges LLM zurückgespeist, damit die nächste Übersetzung nicht nur das Endergebnis, sondern auch die Herleitung nutzen kann.

Das ist die Wette, die wir bei Transept eingegangen sind. Ein Translation Memory sollte nicht nur den Satz erfassen – so wichtig dieser auch sein mag. Es sollte die Arbeit speichern, die den Satz erst verlässlich gemacht hat. Das TM muss zum Entscheidungskontext werden, den sich Menschen und KIs gleichermaßen teilen.

Figure 7 · Memory as decision context

Transept remembers the work behind the sentence

The approved segment · EN → FR · idiom

It costs an arm and a leg

«Ça coûte les yeux de la tête»

Everyone stores this

Context fed to the next translationkept 1 / 7

+Rejected alternativesadd

✓«Ça coûte les yeux de la tête»· the French idiom, same idea and register

✗«Ça coûte un bras et une jambe»· a literal calque, reads as a translation

✗«C’est très cher»· accurate, but flattens the colour

+Thinking traceadd

"costs an arm and a leg": an idiom, translate the meaning
  · a literal calque would read as a translation
  · plain "très cher" is accurate but loses the colour
  → use the French idiom for the same idea

+QA findingsadd

✓idiom mapped, not calqued

✓register matches source (casual)

⚠length checked, fits the button

+Version logadd

v1machine«un bras et une jambe»

v2Literess«les yeux de la tête»

v3humanapproved · current ✓

+Discussionadd

Maria Keep the body-part image, or go fully idiomatic?

Literess French has its own: «les yeux de la tête». Same register, lands natively.

+Omnichannel contextadd

🔍web: “arm and a leg french equivalent”📖dictionary: coûter les yeux de la tête💬comment: matches our playful brand voice

Reveal all layers

Right now the next translation sees only the final sentence, the same memory the market keeps. It can copy the style; it can’t replay the logic.

Wie Transept Translation Memory implementiert

Bei Transept wollen wir neue Maßstäbe für die Übersetzungsqualität setzen, die sich mit LLMs erzielen lässt.

Als wir noch als Einzelautoren und Übersetzer ohne externe Finanzierung arbeiteten, war KI die einzige erschwingliche Lösung. LLMs entfalten ihr volles Potenzial erst durch menschliches Zutun – doch dieser Input ist die kostbarste Ressource der Welt: die Lebenszeit eines Menschen. Anstatt das Translation Memory also nur als passive Datenbank zu betrachten, haben wir es als aktiven Teil des Workflows konzipiert. Es wird ständig gespeist und gibt ständig etwas zurück.

Hybride Suche und granulare Filterung

Das Translation Memory von Transept basiert auf einer hybriden Suche, die Fuzzy-Matching und Vektorsuche kombiniert – schnell und präzise. Doch das Finden von Treffern ist nur die halbe Miete; die andere Hälfte besteht in der Kontrolle darüber, was abgerufen wird.

Sie können genau filtern, was in den Speicher einfließt: Nutzen Sie die gesamte Bibliothek der Organisation, grenzen Sie die Auswahl auf das Portfolio eines Teams ein oder beschränken Sie sie auf ein einzelnes Projekt. Standardmäßig berücksichtigt das System nur Dokumente, die manuell über den TMS-Status freigegeben wurden, doch diese Einstellung lässt sich auf Team-, Dokument- oder Projektebene überschreiben.

Sowohl Menschen als auch KI-Agenten sehen die relevantesten früheren Übersetzungen – einschließlich verworfener Alternativen und der Diskussion hinter der finalen Entscheidung. Man sieht nicht nur, was gewählt wurde; man sieht auch, warum.

Abgestufte TM-Verankerung

Für automatisierte KI-Workflows haben wir die sogenannte „abgestufte TM-Verankerung" (Gradient Translation Memory Grounding) entwickelt, um die Ergebnisse von LLMs zu verbessern:

• Dokumentensynchronisierung in Echtzeit: Während der Übersetzung liest die KI nicht nur freigegebene TM-Quellen, sondern auch vorangegangene Segmente im selben Dokument. So bleiben Terminologie, Stil und getroffene Entscheidungen auch ohne striktes Glossar oder Styleguide konsistent.
• Sicheres Korrekturlesen: Wenn die KI Texte lektoriert oder optimiert, werden Segmente aus demselben Dokument erst dann als Kontext herangezogen, wenn der KI-Editor sie als „geprüft" markiert hat. Das verhindert, dass das Modell halluziniert oder frühere Fehler wieder aufgreift.
• Synchronisierung paralleler Agenten: Wenn extrem umfangreiche Dokumente von mehreren Agenten gleichzeitig übersetzt werden, synchronisieren sich deren Speicher laufend, um Entscheidungen auf den gesamten Text zu übertragen. Das war eine enorme technische Herausforderung – aber es hat die Übersetzungszeit für ein Dokument mit 40.000 Wörtern von 8 Stunden auf 50 Minuten verkürzt.

Erweiterter Kontext und Workflow-Steuerung

Nachdem wir eine Lösung gefunden hatten, um fundierte Entscheidungen und menschliches Talent festzuhalten, haben wir die Bereiche Kontexttiefe und Workflow-Komfort konsequent weiter ausgebaut:

• Omnichannel-Kontext: Chats, Kommentare und die Dokumentensuche helfen Mensch und KI gleichermaßen, den Hintergrund einer Übersetzung zu erschließen – von Websuchen und Wörterbuchabfragen bis hin zu Editor-Kommentaren und Diskussionen mit dem Team oder Literess.
• Anpassbare Workflows: Die automatisierten Workflows von Transept können Dokumente auch mithilfe von TMs optimieren. Statt ein starres Standardverhalten vorzugeben, lassen wir die Teams selbst feinjustieren, wie sich das Memory in jedem Schritt verhält.
• Versionsalternativen: Übersetzungshistorien helfen Teams dabei, nachzuvollziehen, welcher der vielen KI- oder menschlichen Entwürfe ausgewählt wurde – so kann das Memory die Logik einer Übersetzung reproduzieren, statt nur den Stil zu imitieren.
• Literess in der Review-Ebene: Literess integriert das Memory direkt in den Review-Prozess. Sie nutzt das Glossar, den Styleguide, den Dokumentkontext, vorherige Segmente, QS-Ergebnisse und die Übersetzungshistorie, um das Dokument zu kommentieren, Probleme zu erläutern, Korrekturen vorzuschlagen und den menschlichen Reviewer bei der finalen Entscheidung zu unterstützen.

Feature-Parität zwischen Mensch und KI

Ein zentraler Pfeiler der Philosophie von Transept ist die Feature-Parität. Da die Workflows von Übersetzern stark variieren, stellen wir sicher, dass jedes Tool, jede Memory-Ebene und jedes Kontextfenster menschlichen Experten und KI-Agenten gleichermaßen zur Verfügung steht.

Das Ergebnis ist eine Memory-Ebene, die aktiv am Arbeitsprozess mitwirkt. Anstatt dass ein Mensch manuell alte Dateien daraufhin überprüft, wie ein Wort übersetzt wurde, spielt das System diesen Kontext der KI bereits bei der Entwurfserstellung zu, nutzt ihn zur Fehlererkennung in der QS und macht ihn für den menschlichen Reviewer direkt sichtbar.

Das Team muss sich nicht länger mit repetitiven Konsistenzprüfungen aufhalten und kann sich wieder darauf konzentrieren, was gut klingt. Die KI stellt sicher, dass nichts in Vergessenheit gerät, während Transept jede kreative oder rechtliche Entscheidung lückenlos festhält.