Maschinenbau-Dokumentation lebt von Präzision und Wiederverwendung. Translation Memories (TM) verbinden beides: Einmal geschriebene Sätze müssen nicht immer neu übersetzt werden, die Produktionszeit für Dokumentation sinkt, und Budgets profitieren davon. Doch bei 100 %-Matches wird „gleich“ (gleiche Zeichenfolge) oft mit „richtig“ (im aktuellen Kontext korrekt) verwechselt – hier beginnt das Qualitätsroulette.
Um dieses Risiko zu vermeiden, lassen manche Unternehmen ihre 100-%-Matches zu einem reduzierten Preis prüfen. Das senkt zwar das Risiko falscher Übersetzungen, kann aber langfristig erheblich ins Budget gehen: 20.000, 50.000 oder gar 100.000 Euro pro Jahr sind möglich.
Die Frage lautet: Lohnt es sich, 1–2 % Restrisiko um diesen Preis zu vermeiden? Es scheint ein Missverhältnis – und doch können manche Fehler so gravierend sein, dass man auf diese Kontrolle nicht verzichten will. Die gute Nachricht: Alles oder nichts muss nicht die einzige Alternative sein.
In diesem Beitrag werfen wir einen praxisnahen Blick darauf, warum 100%-Matches aus Translation Memories nicht automatisch korrekt sind, und zeigen, wie sich durch eine durchdachte TM-Pflege, Segment-Attribute und definierte Prüfprozesse bis zu 95 % der Kosten einsparen lassen – und das bei höherer Qualitätssicherheit.
Grundlagen: Was sind 100-%-Matches und ICE-Matches?
Translation Memory (TM): Eine Datenbank, die bereits übersetzte Sätze (Segmente) speichert. Bei neuen Übersetzungen schlägt das System passende Segmente vor.
100-%-Match: Gleiche Zeichen ≠ gleiche Bedeutung
Ein 100-%-Match bedeutet: Der Quellsatz ist zeichenidentisch mit einem bereits übersetzten Segment im TM.
Beispiel aus einem TM:
Ausgangssatz (DE): Kontrolle der Anlage
Vorschlag aus dem TM (EN): system control
Doch in derselben Dokumentation finden sich auch:
– plant control (für Produktionsanlage)
– feeder control (für Zuführanlage)
– surface contact control (für Flächenberührung)
Das Problem: Der 100-%-Match bezieht sich nur auf die Zeichenfolge – nicht auf Produktvariante, Normen oder Kontext. Ohne Zusatzinformation kann die Übersetzung falsch sein.
ICE-Match (101 %): Kontext hilft – garantiert aber nicht
ICE = In-Context Exact. Je nach Software auch „Kontext-Match” oder „101-%-Match” genannt.
Ein ICE-Match bedeutet: Der Satz und sein unmittelbarer Kontext (vorheriges/nachfolgendes Segment) sind identisch. Das reduziert das Fehlerrisiko deutlich – eliminiert es aber nicht.
Warum? In modularen Redaktionssystemen können identische Kontexte für verschiedene Produkte wiederverwendet werden, die jedoch unterschiedliche Verfahren, Eigenschaften oder Zustände beschreiben.
Die sieben größten Risiken bei Matches
1. Kontextabhängige Bedeutung
Viele technische Begriffe haben je nach Kontext unterschiedliche Bedeutungen:
| Deutsch | Kontext A | Kontext B |
| Widerstand | resistor (Bauteil) | resistance (Messgröße) |
| Ventil | pneumatic valve | relief valve |
Folge: Ein 100-%-Match mit „Ventil → pneumatic valve” ist falsch, wenn ein Überströmventil gemeint ist.
2. Bezugswörter (Pronomen)
Ausgangssatz: „Ersetzen Sie es mit einem neuen.”
Das Pronomen „es” bezieht sich auf das Hauptwort im vorherigen Satz (Filter, Dichtung, Ventil). Die englische Übersetzung kann nicht beliebig wiederverwendet werden – „Replace it with a new one” funktioniert zwar grammatisch, aber das grammatische Geschlecht oder Numerus in anderen Sprachen (FR, IT, ES) erfordert Anpassungen.
3. Terminologiewandel
Terminologie entwickelt sich. Ältere TM-Einträge können veraltete Begriffe enthalten:
- 2015: „Bedienfeld” → „control panel”
- 2024: „Bedienfeld” → „HMI” (nach neuem Style Guide)
Folge: Uneinheitliche Dokumentation, wenn alte Matches blind übernommen werden.
4. Sprachspezifische Präzision
Manche Sprachen erfordern genauere Unterscheidungen:
- Deutsch: Motor
- Englisch: motor (elektrisch) / engine (Verbrennungsmotor)
Ein 100-%-Match enthält nur eine Variante – die falsche kann übernommen werden.
5. Normen- und Sprachentwicklung
TM bestehen über Jahre. In dieser Zeit ändern sich:
– Sprachgebrauch („Inbetriebnahme” → „Inbetriebsetzung”)
– Normen (EN 82079-1:2012 → 2020)
– Interne Style Guides
6. Kreuzsegmente (kritisch!)
Was sind Kreuzsegmente? Manchmal werden Sätze in zwei oder mehr Segmente aufgeteilt – etwa wegen Layout-Vorgaben oder Zeichenlimits in Displays.
Das Problem: Sprachen haben unterschiedliche Syntax. Was im Deutschen Teil A + Teil B ist, kann in der Übersetzung Teil B + Teil A werden.
Beispiel:
Die Anweisung Hauptschalter auf EIN stellen. wird in einem Display auf zwei Zeilen verteilt.
| Segment | Deutsch | Englisch |
| 1 | Hauptschalter auf EIN | Set the main switch |
| 2 | stellen. | to ON. |
| 3 | Hauptschalter auf AUS | Set the main switch |
Bei blinder Übernahme aus dem TM könnten können in einer englischsprachigen Dokumentation unerwünschte Kombinationen entsprechen wie:
Hauptschalter auf AUS stellen. → Set the main switch to ON
Folge: Sicherheitsrelevante Fehlanweisung.
7. Fehlerfortpflanzung
Auch geprüfte TM können Schreibfehler oder inhaltliche Fehler enthalten. Diese verbreiten sich ungeprüft – besonders problematisch bei sicherheitsrelevanten Texten.
Sonderfall: Handlungsverben und Handlungsnomen
Handlungsverben und ihre nominalen Formen (spannen / Spannvorrichtung) kommen in technischen Texten häufig vor und sind eine besondere Gefahrenquelle.
Warum?
– Sie werden oft nicht in der Terminologie erfasst, so dass automatische Prüftools sie nicht prüfen können.
– Sie werden in sehr unterschiedlichen Situationen verwendet, die einen unterschiedlichen Ausdruck verlangen.
– Ihre Übersetzung variiert stark je nach Kontext und Zielsprache
| Deutsch | Kontext | Englisch |
| prüfen | Sichtprüfung | inspect |
| prüfen | Funktionstest | test |
| prüfen | Rechnungsprüfung | verify / check |
| einstellen | Parameter | set / adjust |
| einstellen | Betrieb beenden | shut down |
Zusatzrisiko: Post-editierte MÜ-Segmente im TM
Viele TM-Bestände enthalten PEMT-Segmente (post-editierte maschinelle oder LLM-generierte Übersetzung). Das ist oft wirtschaftlich sinnvoll. Problematisch wird es, wenn andere Qualitätsansprüche für solche Übersetzungen gelten (“ich brauche Tausend Seiten in Italienisch bis Montag”) oder wenn Revisoren aufgrund mangelnder Erfahrung mit den Besonderheiten von maschineller Übersetzungen (Siehe unseren Artikel: Vollautomatische Übersetzungen: Traum oder bald Realität?) fehlerhafte Übersetzungen durchgewinkt haben.
Unter den typischen Fehlern von MÜ-Systemen zählen die inkonsistente Terminologieverwendung und bei LLM-generierten Übersetzungen Halluzinationen.
Aus diesem Grund ist es unabdingbar, die Herkunft solcher Übersetzungen in einem Translation-Memory zu kennzeichnen, so dass ein früher „gerade so akzeptabler“ PEMT-Satz nicht später als 100 %-Match ungeprüft übernommen wird.
Prüfentscheidung auf Text- oder auf Segmentbasis?
Wir bleiben beim Grundgedanken: So wenig prüfen wie nötig, so viel wie erforderlich. Denn es stimmt: Was bereits geprüft wurde, sollte nicht immer wieder geprüft werden. Am Ende entstehen unnötige Aufwände (Zeit und Kosten), die sich vermeiden lassen.
Die Idee ist, ähnlich wie in einer Werkstatt oder im OP, eine Priorisierung vorzunehmen. Basierend auf bestimmten Kriterien wird entschieden, welche 100 %- oder ICE-Matches zu prüfen sind. Das könnte man textbasiert machen:
– Bei Dokumenten vom Typ A werden alle 100 %-/ICE-Matches geprüft,
– bei Dokumenten vom Typ B nur die 100 %-Matches.
Aber: In der Praxis entspricht dies oft nicht der Art, wie Dokumentation heute generiert wird. Nehmen wir eine Dokumentationsreihe für verschiedene Maschinen eines Herstellers. Sie enthält bestimmte Textbausteine, die sich mit Sicherheitshinweisen befassen und in fast allen Bedienungsanleitungen vorkommen. Es wäre nicht sinnvoll, diese Inhalte immer wieder zu prüfen.
Bei Maschinen derselben Modellreihe ist das Risiko von Kontextabweichungen gering, solange die Unterschiede zwischen den Modellen eher Aspekte wie Leistung oder Masse betreffen – nicht aber Verfahren. Hier könnte man sich darauf einigen, nur die 100 %-Matches ohne Kontext zu prüfen – oder sogar vollständig auf eine Prüfung zu verzichten, wenn die Maschinen sehr ähnlich sind und die Translation Memories stimmen.
Da Dokumentationen heute jedoch oft über Redaktionssysteme oder CMS generiert werden, würde man bei einer textbasierten Vorgehensweise trotzdem viele Segmente prüfen, ohne dass dies erforderlich ist – etwa Warnhinweise, die in allen Dokumenten gleich sind.
Segmentbasierte Prüfung
Die maximale Einsparung bei hoher Sicherheit besteht also darin, die Prüfung auf Segmentbasis vorzunehmen.
Beispiel:
– Sicherheitshinweise: nicht prüfen (standardisiert, normkonform)
– Produktspezifische Beschreibungen: 100-%-Matches prüfen
– Maschinensoftware-Texte: alle Matches prüfen
So würde man in einem bestimmten Text die 100% Matches aus Sicherheitshinweisen nicht prüfen, jedoch die 100% Matches im übrigen Text.
Segment-Attribuierung für zuverlässige Prozesse
Diese feingliedrige Prüfung kann nur funktionieren, wenn Segmente im Translation-Memory die passenden Attribute erhalten. Diese Attribute hängen natürlich von den Dokumentationsinhalten und vom Herstellungsverfahren für die Dokumentation ab. Daher gibt es keine Standard-Attribuierung für alle. Aber hier sind einige Überlegungen:
Typische Attributkategorien:
| Attributtyp | Beispiele |
| Produktbezogen | Maschinentyp (X120, E-Series), Verfahren (Hydraulik, Pneumatik) |
| Dokumentationsbezogen | Bedienungsanleitung, Schulungsmaterial, Softwarehandbuch |
| Herkunftsbezogen | Segmentquelle (humanübersetzt, PEMT, NMT), Projektnummer |
| Prüfstatus | Nach ISO 17100 geprüft, einfach korrekturgelesen |
| Sicherheit/Normen | Sicherheitshinweis nach ISO 3864, EN-/ANSI-Referenz |
| Datum | Erstellungs-, Änderungsdatum, letzte Revision |
Beispiel einer Attribuierung:
Segment: „Tragen Sie Schutzhandschuhe.“
Attribute:
– Typ: Sicherheitshinweis
– Norm: ISO 3864-2
– Produkt: alle
– Status: ISO-17100-geprüft
– Datum: 2024-03-15
Dieses Segment muss nicht bei jedem Projekt erneut geprüft werden.
Natürlich wird bei einem 50-seitigen Text niemand jedes Segment manuell mit Attributen versehen. In der Praxis entstehen diese Kennzeichnungen automatisch oder halbautomatisch:
Viele Attribute lassen sich aus Projekt- oder Dokumentmetadaten ableiten – etwa Produkttyp, Dokumentart oder Revisionsdatum.
Andere entstehen durch Regeln oder KI-Erkennung, z. B. wenn Sätze mit „Achtung“ oder „Achten Sie darauf, dass …“ automatisch als Sicherheitshinweise markiert werden.
Auch der Übersetzungs- oder Prüfstatus kann direkt aus dem Workflow übernommen werden.
So entsteht eine sinnvolle Attribuierung nicht durch Handarbeit, sondern durch das Zusammenspiel von Daten, Regeln und Prozessen. Nur Sonderfälle – etwa neue Warnhinweise oder geänderte Normtexte – erfordern noch eine manuelle Freigabe.
Standardprozesse definieren: Prüfaufwand dort, wo er zählt
Mit Attributen können Sie Prüfprozesse definieren, die Risiko und Aufwand optimal balancieren.
Beispiel-Prozesse
Prozess 1: Bedienungsanleitungen
– 100-%-Matches: prüfen
– ICE-Matches: nicht prüfen
– Ausnahme: Standardtexte (Warnhinweise, Entsorgung) → nie prüfen
Prozess 2: Maschinensoftware
– 100-%-Matches: prüfen
– ICE-Matches: prüfen
– Grund: Hohe Fehlerkosten, Kontext ist kritisch
Prozess 3: Marketing-Websites
– 100-%-Matches: prüfen
– ICE-Matches: nicht prüfen
– Grund: Weniger sicherheitsrelevant, häufige Updates
Prozess 4: Interne Dokumente
– 100-%-Matches: nicht prüfen
– ICE-Matches: nicht prüfen
– Grund: Geringes Haftungsrisiko
Das Ergebnis
- Weniger manuelle Prüfung gesamt
- Aber genau dort, wo sie zählt
- Geringeres Haftungsrisiko
- Budget-Einsparung
Voraussetzung: Saubere Datenbasis
Die beschriebenen Prozesse funktionieren nur mit gepflegten Daten. Das betrifft drei Bereiche:
1. Translation Memory Pflege
Aufgaben:
– Veraltete Segmente entfernen
– Duplikate bereinigen
– PEMT-Segmente kennzeichnen
– Attribute ergänzen/aktualisieren
Aufwand: Regelmäßig, etwa monatlich
2. Terminologie-Management
Aufgaben:
– Firmenterminologie mehrsprachig pflegen
– Kontextabhängige Begriffe dokumentieren
– Relevante Handlungsverben systematisch erfassen
– Terminologie-Tools in Übersetzungsprozess integrieren
3. Quelltext-Optimierung
Das Problem: Minimale Unterschiede erzeugen neue Matches.
Beispiele:
| Variante 1 | Variante 2 | Variante 1 | Variante 2 |
| Einstellungen aufrufen | Einstellungen aufrufen. | Select settings | Open settings. |
| Motor starten | Den Motor starten | Start motor | Start the engine |
Lösung: Controlled Language, Style Guides, automatische Prüftools (z.B. Congree, Acrolinx)
Ausblick: Übersetzungsprozesse im KI-Zeitalter
Dieser Artikel fokussiert auf 100-%- und ICE-Matches aus Translation Memories. Doch das Prinzip – standardisierte Prozesse mit gezielter menschlicher Qualitätssicherung – gilt zunehmend für die gesamte Übersetzungsproduktion:
- MÜ- oder LLM-generierte Rohübersetzungen ersetzen zunehmend klassische Humanübersetzung
- Automatisierte Qualitätsprüfung durch regelbasierten und KI-Tools
- Menschliche Prüfung nur dort, wo sie echten Mehrwert bietet
Das ist der Weg, wie Übersetzungen morgen produziert werden. Übersetzungen entstehen dann nicht mehr als Einzelstücke, sondern – ähnlich wie Autos – in standardisierten, hochgradig optimierten Prozessen. Dafür braucht es neue Berufsprofile, etwa den „Übersetzungskonstrukteur“:
– Linguistische Expertise für präzise Terminologie, und Qualitätssicherung
– Technisches Know-how für KI-Tools und Systemintegration,
– Prozessdenken, um Übersetzungsworkflows in agile Produktionsketten einzubetten.
Ihre Rolle wird nicht mehr sein, Sätze zu übersetzen, sondern „Übersetzungsfabriken“ zu entwerfen – effizient, sicher und skalierbar. Am Ende geht es nicht mehr nur um 100 %-Matches, sondern darum, wie wir Qualität, Geschwindigkeit und Kosten in einer KI-gestützten Welt in Einklang bringen.
Glossar
Translation Memory (TM): Datenbank mit bereits übersetzten Segmenten, die bei neuen Projekten wiederverwendet werden können.
Segment: Kleinste Übersetzungseinheit, meist ein Satz oder Teil davon.
100-%-Match: Quellsatz ist zeichenidentisch mit einem TM-Eintrag.
ICE-Match / 101-%-Match: Satz und Kontext sind identisch mit einem TM-Eintrag.
PEMT: Post-Edited Machine Translation – maschinell übersetzt, dann manuell korrigiert.
Attribut: Metadaten-Eigenschaft eines TM-Segments (z.B. Dokumenttyp, Prüfstatus, Datum).
Controlled Language: Regelwerk zur Vereinheitlichung von Texten (begrenzte Terminologie, standardisierte Satzstrukturen).
LLM: Large Language Model – KI-Modell für Sprachverarbeitung (z.B. GPT, Claude).
Halluzination: KI-generierter Inhalt, der nicht im Ausgangstext vorhanden war.
Haben Sie Fragen zur Implementierung? Kontaktieren Sie uns für eine individuelle Beratung.
