Wenn sich der Quelltext ändert: neu übersetzen, zusammenführen oder menschlich prüfen?

Ein Anbieter ändert zwei Sätze einer längeren Beschreibung. Ein Entwickler korrigiert einen deutschen UI-Text. Eine Redaktion ersetzt einen Fachbegriff. Für die Zielsprachen stellt sich immer dieselbe Frage:

Eine vollständige Neuübersetzung ist technisch einfach, kann aber bestätigte Formulierungen, Terminologie und manuelle Korrekturen zerstören. Nichts zu tun lässt veraltete oder fachlich falsche Zieltexte online. Ein pauschaler menschlicher Review bei jeder Änderung skaliert nicht.

Die Lösung ist ein versionierter Änderungsprozess, der Art, Umfang, Risiko und bisherige Bearbeitung der Zielversion berücksichtigt.

Alte und neue Quelle explizit vergleichen

Für jede Änderung stehen mindestens drei Versionen zur Verfügung:

• bisherige Quellversion,
• neue Quellversion,
• aktuell veröffentlichte Zielversion.

Bei einer manuell bearbeiteten Übersetzung kommt zusätzlich ihre Bearbeitungshistorie hinzu.

Beispiel:

Quelle v14: „Das Angebot kann bis 24 Stunden vorher
             kostenfrei storniert werden."
Quelle v15: „Das Angebot kann bis 48 Stunden vorher
             kostenfrei storniert werden."
Ziel FR v8 basiert auf Quelle v14 und ist manuell bestätigt.

Die Änderung betrifft eine geschäftlich relevante Frist. Die Zielversion darf nicht unverändert bleiben und sollte nicht ohne Prüfung vollständig neu erzeugt werden.

Segmentierung als Grundlage

Längere Inhalte sollten in stabile Segmente zerlegt werden:

• Überschrift,
• Absatz,
• Listenpunkt,
• strukturiertes Feld,
• Satzgruppe mit gemeinsamer Bedeutung.

Zu kleine Segmente verlieren Kontext. Zu große Segmente führen dazu, dass eine kleine Änderung einen gesamten langen Text neu übersetzt.

Jedes Segment besitzt:

• stabile ID,
• Quellversion,
• Zielversionen,
• Kontext,
• Bearbeitungsstatus,
• Prüfhistorie.

Dadurch können unveränderte Abschnitte weiterverwendet und nur betroffene Teile aktualisiert werden.

Vier Ebenen der Änderungserkennung

1. Technischer Vergleich

Hashes oder exakter Stringvergleich erkennen, ob sich Text überhaupt verändert hat.

2. Struktureller Diff

Erkennt hinzugefügte, entfernte oder verschobene Segmente und geänderte Platzhalter.

3. Semantische Klassifikation

Bewertet, ob sich die Bedeutung wesentlich verändert hat oder nur Stil und Form.

4. Fachliche Risikoklasse

Berücksichtigt, ob der Text Preis, Frist, Verpflichtung, Sicherheit oder nur redaktionellen Stil betrifft.

Keine Ebene allein genügt. Zusammen ermöglichen sie ein differenziertes Routing.

Mögliche Änderungsstrategien

Strategie A: Übersetzung unverändert weiterverwenden

Geeignet bei:

• rein formaler Korrektur,
• unsichtbarer Markup-Änderung,
• Quelländerung ohne Bedeutungswirkung auf die Zielsprache.

Der Zieltext wird auf die neue Quellversion referenziert; die Entscheidung bleibt protokolliert.

Strategie B: Nur verändertes Segment neu übersetzen

Geeignet bei:

• lokal begrenzter inhaltlicher Änderung,
• langen strukturierten Inhalten,
• nicht manuell geschütztem Zielsegment.

Unveränderte Segmente bleiben bestehen.

Strategie C: Änderung in bestätigte Zielversion einarbeiten

Geeignet bei:

• manuell optimierter Zielversion,
• kleiner, klar lokalisierbarer Quelländerung,
• hohem Wert der bestehenden Formulierung.

Die KI erhält:

• alte Quelle,
• neue Quelle,
• bestätigten Zieltext,
• Auftrag, nur die Bedeutungsänderung einzubauen und Stil beizubehalten.

Das Ergebnis wird als Vorschlag gespeichert und abhängig vom Risiko geprüft.

Strategie D: Vollständig neu übersetzen

Geeignet bei:

• grundlegend neuer Bedeutung,
• stark umstrukturierter Quelle,
• niedriger Qualität der bisherigen Zielversion,
• neuer Terminologie oder Zielgruppe.

Auch dann bleibt die alte Version für Vergleich und Rollback erhalten.

Strategie E: Menschliche Prüfung verpflichtend

Geeignet bei:

• Preisen und Fristen,
• rechtlichen oder sicherheitsrelevanten Inhalten,
• starken Abweichungen bei manuell bestätigter Fassung,
• niedriger Konfidenz,
• widersprüchlichem Quelltext.

Manuelle Korrekturen sind wertvolle Information

Eine händisch überarbeitete Übersetzung enthält oft mehr als Sprachkosmetik. Sie kann:

• eine bessere Terminologie verwenden,
• kulturellen Kontext berücksichtigen,
• an UI-Länge angepasst sein,
• fachliche Eindeutigkeit verbessern,
• absichtlich vom Satzbau der Quelle abweichen.

Die Pipeline sollte diese Fassung nicht als beliebigen alten Output behandeln. Ihr Status und die Art der Bearbeitung bestimmen die Aktualisierungsstrategie.

Mögliche Schutzstufen:

• ungeschützt maschinell,
• manuell bearbeitet,
• sprachlich bestätigt,
• fachlich bestätigt,
• rechtlich freigegeben,
• ausdrücklich fixiert.

Je höher die Schutzstufe, desto weniger darf automatisch überschrieben werden.

Änderungen an Glossar und Kontext

Nicht nur der Quelltext kann eine Zielversion veralten lassen.

Auch folgende Änderungen sind relevant:

• neuer verbindlicher Fachbegriff,
• geänderte Ansprache,
• neue Zielgruppe,
• andere UI-Komponente,
• neues Längenlimit,
• geänderter Markt,
• Korrektur eines Produktnamens,
• neues Modell oder Prompt mit bewusst verbessertem Qualitätsniveau.

Die Pipeline sollte erkennen können, welche Übersetzungen von einer Glossaränderung betroffen sind. Eine globale Terminologieänderung muss nicht blind alle Texte neu erzeugen, kann aber gezielte Review- oder Updatejobs auslösen.

Konflikte zwischen Quelle und Ziel

Manchmal enthält die Zielversion Informationen, die in der Quelle nicht vorkommen. Das kann beabsichtigt sein, etwa bei marktspezifischen Hinweisen. Es kann aber auch eine unkontrollierte redaktionelle Erweiterung sein.

Das Datenmodell sollte unterscheiden:

• reine Übersetzung,
• lokalisierte Anpassung,
• marktspezifischer Zusatz,
• eigenständiger Zielinhalt.

Ein eigenständiger Zielinhalt darf nicht durch die normale Übersetzungspipeline behandelt werden, als wäre er vollständig aus der Quelle abgeleitet.

Veröffentlichung während des Updates

Wenn eine Quelle geändert wurde, aber die neue Übersetzung noch nicht bereitsteht, existieren mehrere Zustände:

• alte Zielversion bleibt temporär online,
• Zielversion wird als möglicherweise veraltet markiert,
• Quellsprache wird als Fallback angezeigt,
• Inhalt wird in der Zielsprache ausgeblendet,
• Veröffentlichung des Quellupdates wird bis zur Übersetzung zurückgehalten.

Die Entscheidung hängt von Änderung und Risikoklasse ab.

Ein korrigierter Tippfehler darf die Plattform nicht blockieren. Eine geänderte Stornofrist darf nicht tagelang in der alten Fassung online bleiben.

Version Graph statt linearer Überschreibung

Bei komplexen Inhalten ist eine einfache Folge v1 → v2 → v3 manchmal nicht ausreichend. Zielversionen können auf unterschiedlichen Quellen und manuellen Branches basieren.

Ein Version Graph kann speichern:

• welche Quelle zugrunde liegt,
• aus welcher Zielversion eine Änderung entstand,
• ob sie maschinell oder manuell bearbeitet wurde,
• welche Version veröffentlicht war,
• welche Version ersetzt oder zurückgerollt wurde.

Das ermöglicht saubere Audits und verhindert, dass wertvolle Zielarbeit verloren geht.

Evaluation mit realen Änderungsfällen

Eine neue Update-Strategie sollte nicht nur mit isolierten Übersetzungssätzen getestet werden.

Ein Evaluationsset enthält:

• reine Tippfehlerkorrektur,
• geänderte Zahl oder Frist,
• neuer Absatz,
• entfernter Leistungsbestandteil,
• umformulierte gleiche Bedeutung,
• manuell bestätigte Zielversion,
• marktspezifischen Zusatz,
• geändertes Glossar,
• starke Neustrukturierung.

Für jeden Fall wird die erwartete Strategie festgelegt. So lässt sich messen, ob die Pipeline richtig routet.