8 677 UI-Strings in einer Stunde: KI-Automatisierung mit Prüfschritten

KI-Automatisierung lohnt sich dort, wo Arbeit viel, gleichförmig und gut prüfbar ist: 8 677 Übersetzungsschlüssel einer Anwendung standen zwischen einem Kunden und einer türkischen Oberfläche. Die reine Arbeitszeit für Übersetzung und Einbau lag bei etwa einer Stunde. Was in dieser Stunde steckt und was nicht, steht hier.

Ausgangslage: vier Sprachen, ein neuer Kollege

Der Kunde stellt einen Vertriebsmitarbeiter ein, der nur Türkisch spricht. Das Panel, mit dem er arbeiten soll, gibt es in vier Sprachen: Russisch, Ukrainisch, Deutsch, Polnisch. Eine fünfte galt bei uns bis dahin als Vorhaben für mehrere Monate – die Schlüssel verteilen sich über alle Bereiche der Anwendung.

Technisch war die Anwendung vorbereitet: eine JSON-Datei pro Sprache, Schlüssel nach Bereichen gruppiert. Das Problem war nie die Architektur, sondern die Menge. Übersetzen lassen, prüfen, einspielen, dazu die Stellen im Code finden, die eine Sprachliste fest verdrahtet haben – das ist die Art Arbeit, die in Planungen immer wieder nach hinten rutscht.

KI-Automatisierung heißt Arbeitsteilung, nicht Ersatz

Die erste Entscheidung war nicht, welches Modell zum Einsatz kommt, sondern wer was macht. Ein Sprachmodell kann übersetzen; Verantwortung tragen kann es nicht.

• Mensch: Glossar festlegen, Blöcke schneiden, Prüfregeln definieren, die Stichprobe des Reviews lesen, Code-Stellen anpassen, freigeben.
• Modell: die eigentliche Übersetzung der Blöcke, ein zweites, unabhängiges Review der Stichprobe, Vorschläge für die Code-Stellen.

Das Glossar war der teuerste Teil der menschlichen Arbeit und zugleich der wichtigste: Bereichsnamen, Statusbezeichnungen, Rollen, Produktnamen, die nicht übersetzt werden dürfen. Ohne Glossar übersetzt ein Modell denselben Begriff im letzten Block anders als im ersten, und die Oberfläche wirkt an vielen Stellen leicht fremd. Ein Anwender merkt das nicht als Fehler, sondern als Misstrauen.

Die Pipeline: Blöcke, Glossar, harte Gates

1. Schneiden. Die Schlüssel wandern in Blöcke, geschnitten nach Bereichen der Anwendung. Parallel verarbeitet, damit die Wandzeit nicht von der Reihenfolge abhängt.
2. Übersetzen. Jeder Block bekommt denselben Prompt: Glossar, Kontext des Bereichs, Regeln für Platzhalter. Ausgabe strikt als JSON mit unveränderten Schlüsseln. Warum dieser Aufbau und nicht ein freundlicher Fließtext, beschreibt der Artikel über Prompt Engineering.
3. Gates. Drei automatische Prüfungen vor dem Merge: Platzhalter wie „{count}“ müssen unverändert vorhanden sein; Namen aus dem Glossar dürfen nicht übersetzt sein; ein Begriff muss über alle Blöcke gleich übersetzt sein.
4. Review. Ein zweiter, unabhängiger Modelldurchlauf bewertet eine Stichprobe. Das Ergebnis war gut, aber nicht perfekt – und genau so haben wir es dem Kunden berichtet.
5. Sprach-Reinheits-Gate. Ein bestehender Build-Check prüft, ob in einer Sprachdatei Fragmente einer anderen Sprache stehen. Grün.

Zwischen dem ersten Block und dem grünen Gate lag ungefähr eine Stunde. Nicht enthalten: die Zeit, das Glossar zu schreiben, und die Zeit, die verstreuten Code-Stellen zu finden – Sprachumschalter, Labels in Statistiken, Prüfungen auf erlaubte Sprachen, Sortierungen, Datumsformate. Beides zusammen machte aus der Stunde einen Arbeitstag.

Wo es hakte

Die Gates gibt es nicht aus Vorsicht, sondern aus Erfahrung. Drei Fehlerklassen tauchen bei Übersetzungen mit Sprachmodellen regelmäßig auf, und genau darauf sind sie gebaut:

• Platzhalter. Ein Modell „verbessert“ gern „{name}“ zu einem türkischen Wort oder verschiebt den Platzhalter grammatisch korrekt an eine Stelle, an der die Anwendung ihn nicht mehr findet. Dagegen hilft nur ein harter Vergleich vor und nach der Übersetzung.
• Eigennamen und Fachbegriffe. Ohne Glossar wird der Name eines Bereichs übersetzt, obwohl er im ganzen Unternehmen als Eigenname gilt.
• Konsistenz zwischen Blöcken. Der Preis der Parallelisierung: Ein später Block kennt die Entscheidungen des ersten nicht. Das Glossar fängt die wichtigsten Begriffe ab, den Rest fängt die Stichprobe – oder der erste türkischsprachige Anwender.

Die Bewertung der Stichprobe ist so zu lesen: Für den Entwicklungsstand und für einen Anwender, der zur Not auch eine der vier anderen Sprachen versteht, reicht die Qualität. Für ein Produkt, das ausschließlich auf Türkisch verkauft wird, würden wir eine menschliche Korrektur des Glossars und der meistgenutzten Texte einplanen. Der Grund steht im Artikel über Halluzinationen: Auch beim Übersetzen erfindet ein Modell im Zweifel lieber etwas, als eine Lücke zu lassen.

Was KI-Automatisierung nicht abkürzt

• Die Sprachliste gehört an eine Stelle. Die verstreuten Code-Stellen sind eine Altlast. Eine zentrale Liste, aus der alles andere abgeleitet wird, hätte den Tag auf die Stunde reduziert.
• Das Glossar entsteht vor dem ersten Block – aber nicht aus dem Kopf. Die Begriffe lassen sich aus den bestehenden vier Sprachen automatisch ziehen; der Mensch bestätigt dann nur noch.
• Die Stichprobe gehört gewichtet. Zufällige Schlüssel sagen wenig über die Texte, die ein Anwender täglich sieht. Beim nächsten Mal prüfen wir die Startseite und die meistgenutzten Formulare.
• Wir verkaufen den Tag, nicht die Stunde. „8 677 Strings in einer Stunde“ ist wahr und beschreibt den Kern der Arbeit. Der Kunde bekommt von uns die vollständige Rechnung: ein Arbeitstag inklusive Glossar, Code und Review.

Wie wir solche Abläufe in bestehende Kundensysteme bringen und was vorher als Kriterium der Abnahme feststeht, steht unter KI-Implementierung für den Mittelstand.