Warum ein Übersetzungs-Run kein Cronjob ist.

Ein technischer Scheduler kann jede Nacht alle neuen Texte laden, an ein Sprachmodell senden und die Ergebnisse speichern. Damit ist ein automatischer Prozess gebaut – aber noch keine belastbare Localization Operation.

Sobald die Plattform aktiv weiterentwickelt wird, entstehen Fragen:

• Welche Texte sind wirklich neu?
• Welche Quelle wurde nur formal, welche inhaltlich verändert?
• Welche Zielversion wurde manuell korrigiert?
• Was passiert, wenn ein Teil des Runs fehlschlägt?
• Welche Übersetzungen dürfen sofort live gehen?
• Wie wird eine schlechte Modellversion zurückgerollt?
• Wie bleibt nachvollziehbar, aus welcher Quelle ein Zieltext entstanden ist?

Ein produktiver Übersetzungs-Run ist deshalb eher eine versionierte Datenpipeline mit fachlichen Zuständen als ein einfacher Cronjob.

Quellversionen als Grundlage

Jeder übersetzbare Inhalt benötigt eine stabile Identität und eine Version.

Beispiel:

content_id:       ui.checkout.submit
source_language:  de
source_version:   7
source_text:      "Zahlungspflichtig bestellen"
context_version:  3

Eine englische Übersetzung verweist explizit auf diese Version:

target_language:          en
based_on_source_version:  7
translation_version:      12
status:                   approved

Ändert sich der deutsche Quelltext auf Version 8, ist sofort erkennbar, dass die englische Fassung nicht mehr auf dem aktuellen Stand basiert.

Nicht jede Änderung erfordert dieselbe Reaktion

Formale Änderung

Beispiel: zusätzliches Leerzeichen oder korrigierte Interpunktion.

Mögliche Reaktion: Zieltext bleibt gültig, nur Metadaten werden aktualisiert.

Kleine inhaltliche Änderung

Beispiel: „Buchung bestätigen" wird zu „Buchung jetzt bestätigen".

Mögliche Reaktion: gezielte Neuübersetzung des Segments.

Bedeutungsänderung

Beispiel: „Anfrage senden" wird zu „Verbindlich bestellen".

Mögliche Reaktion: Zieltexte werden als kritisch veraltet markiert und benötigen erneute Prüfung.

Kontextänderung

Der Text bleibt gleich, erscheint aber künftig in einem anderen Prozess oder für eine andere Zielgruppe.

Mögliche Reaktion: vorhandene Übersetzung neu bewerten.

Ein einfacher Textvergleich erkennt diese Unterschiede nicht vollständig. Hashes, strukturierte Diffs und bei Bedarf semantische Klassifikation können zusammenarbeiten.

Ein Zustandsmodell für Übersetzungen

Mögliche Zustände:

missing
queued
translating
automated_check
review_required
approved
published
stale
blocked
failed
archived

Zusätzlich kann die Herkunft gespeichert werden:

• maschinell erzeugt,
• aus Translation Memory übernommen,
• manuell bearbeitet,
• fachlich bestätigt,
• sprachlich bestätigt.

Das Zustandsmodell ermöglicht gezielte Abfragen:

• Welche französischen UI-Texte fehlen für den nächsten Release?
• Welche Anbieterinhalte sind wegen Quelländerung veraltet?
• Welche Übersetzungen warten auf Fachprüfung?
• Welche Fehler wurden nach drei Versuchen nicht gelöst?

Idempotenz und Wiederaufnahme

Ein Run kann nach 8.000 von 10.000 Texten abbrechen. Beim Neustart dürfen die erfolgreichen Ergebnisse nicht unkontrolliert neu erzeugt werden.

Dafür braucht die Pipeline:

• eindeutige Job-IDs,
• stabile Inhalts- und Versionsschlüssel,
• idempotente Verarbeitung,
• Checkpoints,
• Retry-Strategien,
• getrennte Behandlung dauerhafter und temporärer Fehler.

Beispiel:

• Netzwerkfehler: automatisch wiederholen.
• ungültiger Platzhalter: blockieren und zur Prüfung geben.
• Quelltext während des Runs geändert: Ergebnis nicht publizieren, neuen Job planen.
• Modell liefert unbrauchbares Format: mit korrigierter Strategie wiederholen oder reviewen.

Batching ohne Kontextverlust

Viele Texte in einer Anfrage zu bündeln kann Kosten und Laufzeit reduzieren. Zu große Batches erhöhen jedoch das Risiko:

• einzelne Fehler blockieren den gesamten Batch,
• Zuordnung von Ergebnissen wird unsicher,
• Kontext verwischt,
• Antwortgrenzen werden erreicht,
• unterschiedliche Risikoklassen werden vermischt.

Batches sollten nach sinnvoller Nähe gruppiert werden:

• gleiche Komponente,
• gleicher Content-Typ,
• gleiche Terminologie,
• gleiche Risikoklasse,
• gleiche Zielsprache.

Jeder Eintrag bleibt dennoch eindeutig adressierbar.

Formale Prüfungen vor fachlicher Bewertung

Bevor ein Mensch oder eine weitere KI die Qualität bewertet, können deterministische Prüfungen viele Fehler erkennen:

• alle Platzhalter vorhanden,
• HTML-Struktur erlaubt,
• Links unverändert oder korrekt angepasst,
• Zahlen und Einheiten plausibel,
• Text nicht leer,
• keine Quellsprache versehentlich unverändert,
• Länge innerhalb definierter Grenzen,
• Glossarbegriffe konsistent,
• keine unzulässigen Steuerzeichen.

Diese Prüfungen sind schnell, reproduzierbar und sollten nicht durch generative Bewertung ersetzt werden.

Review-Routing statt einer einzigen Warteschlange

Nicht jeder problematische Text gehört an dieselbe Person.

Mögliche Reviewtypen:

• sprachliche Prüfung,
• fachliche Prüfung,
• rechtliche Prüfung,
• Anbieterfreigabe,
• technische Korrektur von Platzhaltern,
• Prüfung einfacher Sprache.

Der Job enthält deshalb den Grund der Prüfung und den benötigten Reviewer-Typ. Dadurch landen technische Formatfehler nicht bei der französischen Redaktion und fachliche Preisbegriffe nicht nur beim Übersetzer.

Veröffentlichung als eigener Schritt

Eine erzeugte und geprüfte Übersetzung ist nicht automatisch live.

Die Veröffentlichung kann abhängig sein von:

• Software-Release,
• vollständigem Sprachpaket,
• Anbieterfreigabe,
• Zielmarkt,
• Gültigkeitsdatum,
• Content-Freigabe,
• Feature Flag.

Der Publish-Schritt speichert, welche Übersetzungsversion wann in welchem Kanal aktiv wurde.

Rollback und Modellwechsel

Wird ein neues Modell oder eine neue Promptversion eingeführt, sollte nicht sofort der gesamte Bestand überschrieben werden.

Sinnvoller Ablauf:

1. 1repräsentatives Evaluationsset verarbeiten,
2. 2Ergebnisse mit aktueller Produktion vergleichen,
3. 3ausgewählte neue Inhalte als Canary übersetzen,
4. 4Qualitäts- und Feedbacksignale beobachten,
5. 5schrittweise ausrollen,
6. 6alte bestätigte Zieltexte weiterhin verfügbar halten.

Da Übersetzungsversionen gespeichert werden, kann eine problematische Fassung zurückgenommen werden, ohne die Quelle erneut rekonstruieren zu müssen.

Observability für Localization

Technische Kennzahlen:

• Jobs pro Stunde,
• Laufzeit,
• Fehlerrate,
• Retry-Anzahl,
• Modell- und API-Kosten,
• Warteschlangenlänge.

Fachliche Kennzahlen:

• Abdeckung je Sprache und Content Class,
• Anteil veralteter Übersetzungen,
• Reviewquote,
• Korrekturquote,
• häufig gemeldete Begriffe,
• durchschnittliche Zeit bis Veröffentlichung,
• Anteil geschützter manueller Fassungen,
• Rückstau kritischer Inhalte.

Erst beide Perspektiven zeigen, ob der Übersetzungsprozess tatsächlich funktioniert.