Wenn Coding-Agents Ihre App übersetzen: Was kaputtgeht, was Sie behalten sollten

Agentengestützte Übersetzung (agent-assisted translation) ist die Praxis, einen KI-Coding-Agent, also den Assistenten, der Ihre Codebasis ohnehin liest und bearbeitet, Übersetzungs-Keys anlegen und die übersetzten Strings als Teil einer Codeänderung entwerfen zu lassen, statt die Strings danach an einen separaten Übersetzungsschritt zu übergeben. Das ist schnell, günstig und für einen einzelnen Pull Request oft gut. Die Probleme stecken nicht in diesem Pull Request. Sie stecken im zwölften.

Dieser Beitrag ist ein Kategorie-Beitrag, kein Vergleich. Es geht darum, was Agents wirklich gut machen, was von einem Release zum nächsten nicht erhalten bleibt, und um das Muster, das die Geschwindigkeit behält, ohne die Aufzeichnung zu verlieren.

Was Agents wirklich gut können

Die ehrliche Version beginnt mit den Stärken, denn sie sind echt. Ein Coding-Agent, der einen Einstellungs-Screen in sechs Sprachen anlegen soll, hat in dem Moment, in dem er das deutsche Label schreibt, mehr Kontext als eine Übersetzerin mit einer Tabelle: Er weiss, dass die Komponente ein Button ist, dass {{count}} eine Zahl ist und kein Name, was die Nachbar-Strings sagen, wie der vorherige Entwickler ähnliche Keys benannt hat und ob der Wert in einen Satz interpoliert wird. Er schreibt Key, Standardwert und Übersetzungen in einem Durchgang, ohne Übergabe, ohne Export, ohne Warten.

Er ist auch gut in der Verkabelung, die Lokalisierung früher ganz blockiert hat. Agents binden eine i18n-Bibliothek ein, wickeln hartcodierte Strings ein, extrahieren Keys und starten den Sync-Befehl, und sie tun das für das Nebenfeature, für das kein Team je eine Übersetzungsrunde budgetiert hätte. Features, die früher nur auf Englisch erschienen, erscheinen jetzt in jeder Sprache des Projekts. Das ist keine Kleinigkeit, und keine Kritik an Agent-Übersetzung sollte so tun, als wäre es eine.

Was über die Zeit kaputtgeht

Alles Folgende ist in einem einzelnen Pull Request unsichtbar. Es zeigt sich über Pull Requests hinweg, weshalb Teams es spät entdecken.

Konsistenz über Releases hinweg

Jeder Agentenlauf startet mit leerem Kontext. Nichts in der Sitzung erinnert sich daran, dass der Produktname unübersetzt bleibt, dass "subscription" vor drei Releases zu "Abo" und nicht zu "Abonnement" wurde, oder dass das Spanische "tú" verwendet und nicht "usted". Der Agent wählt eine Wiedergabe, die isoliert vertretbar ist, und im nächsten Monat eine andere vertretbare. Die Anrede ist der unangenehmste Fall: In Sprachen, in denen der Unterschied grammatikalisch ist, wirkt ein Screen, der siezt, neben einem, der duzt, wie kaputt, nicht wie eine Stilentscheidung.

Review und Provenienz

Wenn ein Kunde, eine Anwältin oder ein Auditor fragt, warum die App auf Italienisch gesagt hat, was sie gesagt hat, hat eine Pipeline aus agentenbearbeiteten Dateien eine Antwort: ein Commit von einem Bot, freigegeben von einem Reviewer, der kein Italienisch lesen konnte und den Diff auf Syntax geprüft hat. Es gibt keinen Reviewer, der dafür einsteht, keinen Entscheidungspfad pro String, und keine Möglichkeit, die Vermutung eines Agenten von der Wahl einer Übersetzerin zu unterscheiden, sobald beide in derselben Datei stehen. Seit dem 2. August 2026 ist das auch eine regulatorische Frage: Artikel 50 der EU-KI-Verordnung gilt, und nach den finalen Leitlinien der Kommission ist eine originalgetreue KI-Übersetzung von der maschinenlesbaren Kennzeichnung ausgenommen, während Texte, die die Öffentlichkeit über Angelegenheiten von öffentlichem Interesse informieren, eine sichtbare Offenlegung brauchen, es sei denn, sie haben eine dokumentierte menschliche Überprüfung durchlaufen und eine Person trägt die redaktionelle Verantwortung. Die juristischen Details stehen im Erklärstück zu Artikel 50; die praktische Konsequenz ist, dass "geprüft" etwas sein muss, das Sie pro Segment vorzeigen können, und ein Review-Workflow ist das, was diesen Nachweis erzeugt. Nichts davon ist Rechtsberatung.

Terminologie-Governance

Das Glossar existiert, meist als Dokument. Der Agent liest es vielleicht, vielleicht nicht, liest es in einer Sitzung und in der nächsten nicht, und kann nicht wissen, dass nach seinem letzten Lauf ein Begriff hinzugekommen ist. Verbotene Begriffe kommen zurück. Produktnamen werden übersetzt. Der Fix, der dann vorgeschlagen wird, "das Glossar in die Anweisungen des Agenten packen", funktioniert, bis das Glossar vierhundert Einträge hat und die Anweisungen auch noch alles andere abdecken müssen. Terminologie ist ein Datenproblem, und Daten, die sich ein zustandsloser Prozess merken muss, sind nicht gesteuert, sondern erhofft. Das Glossar gehört in ein System, das der Agent abfragen kann, nicht in einen Prompt.

QA über den Korpus, nicht über den Diff

Ein Agent prüft die Strings, die er angefasst hat. Die Defekte, die tatsächlich in die Produktion gelangen, sind Key-übergreifend: derselbe Quellwert, über Namespaces hinweg auf drei Arten übersetzt; ein Platzhalter, der in elf Sprachen vorhanden ist und in der zwölften fehlt; eine Zahl, die sich unterwegs verändert hat. Die findet man, indem man jeden Wert einer Sprache mit seiner Quelle und mit dem Rest dieser Sprache vergleicht, bei jedem Speichern, was kein Pull-Request-Review tut. Die Taxonomie und wie automatische Checks sie abfangen, steht in Was in Übersetzungen wirklich kaputtgeht.

Plurale, Platzhalter und die Strings mit Risiko

Sprachen mit mehr als zwei Pluralformen (Polnisch, Arabisch, Russisch) brauchen Formen, die die englische Quelle nicht hat. Agents erzeugen sie isoliert korrekt und in der Masse inkonsistent, und ein falscher _few-Key ist ein Laufzeitfehler, kein Stilproblem. Dann gibt es die Strings, bei denen "das Modell liegt meistens richtig" kein akzeptabler Massstab ist: rechtliche Hinweise, Preisangaben, medizinische und sicherheitsrelevante Formulierungen, Labels für Barrierefreiheit. Ein Agent behandelt sie wie jeden anderen String, weil sie im Diff wie jeder andere String aussehen.

Wie Teams Coding-Agent-Übersetzung heute handhaben

Vier Setups decken das meiste ab, was wir sehen, und die ehrliche Anmerkung ist, dass das erste für manche Teams das richtige ist.

• Der Agent bearbeitet die Sprachdateien im Pull Request. Am schnellsten, am günstigsten, und in Ordnung, solange die Leute im Team jede Sprache lesen können und nichts am Text hängt. Die oben beschriebene Drift beginnt am ersten Tag und wird ungefähr beim zehnten Release sichtbar.
• Der Agent plus ein LLM-Schritt in der CI. Der Agent legt die Keys an, ein Workflow beim Push übersetzt die fehlenden Werte maschinell. Beseitigt den manuellen Teil vollständig und reproduziert dieselben Fehlermodi in Pipeline-Geschwindigkeit: ungeprüfter Output, kein Gedächtnis zwischen Läufen, keine Durchsetzung der Terminologie. Der Weg aus diesem Setup heraus steht in Wenn KI-Übersetzungen kaputtgehen.
• Der Agent entwirft, eine Person prüft den Diff. Vom Geist her besser, in der Praxis schwach: Ein Pull-Request-Reviewer sieht zwölf Sprachdateien und kann eine oder zwei davon beurteilen. Das Review ist echt für die Sprachen, die der Reviewer liest, und Theater für den Rest.
• Der Agent entwirft durch ein Translation-Management-System. Der Agent entwirft weiter, aber Terminologie, das Gedächtnis vergangener Entscheidungen, die Review-Warteschlange und die Historie leben im System, und der Agent liest daraus und schreibt hinein. Das ist das Muster, das der Rest dieses Beitrags beschreibt.

Das Agent-in-the-Loop-Muster: Was Sie behalten sollten

Unabhängig vom Werkzeug hat das Muster fünf Regeln.

1. Terminologie und Tonfall kommen aus dem System, nicht aus dem Prompt. Bevor der Agent einen String entwirft, holt er das Glossar des Projekts (bevorzugte, erlaubte und verbotene Begriffe pro Sprache) und den Styleguide (Ton, Anrede, Zielgruppe). Die Anweisung lautet "schlag das nach", nicht "hier sind vierhundert Begriffe".
2. Wiederverwenden vor Erfinden. Eine Translation-Memory-Suche nach ähnlichen Quell-Strings kommt zuerst. Ein Treffer mit hohem Score wird wiederverwendet, und so bleibt das zwölfte Release konsistent mit dem ersten.
3. Provenienz wird deklariert, nicht erschlossen. Der Output des Agenten wird als KI-Output übermittelt, was ihn in die Review-Warteschlange stellt statt in die Produktion. Die Bearbeitung einer Person wird als Bearbeitung einer Person übermittelt. Sobald beides ohne Markierung in derselben Datei steht, ist die Unterscheidung für immer verloren.
4. Review pro Segment, durch jemanden, der die Sprache liest, und aufgezeichnet. Keine Pull-Request-Freigabe, keine Stichprobe in zwei Sprachen: Ein Reviewer bestätigt oder bearbeitet jeden Wert in einem Editor, der Quelle, Kontext und Glossar zeigt, und die Entscheidung wird mit Name und Zeitpunkt in die Historie geschrieben.
5. Checks laufen nach dem Merge über den Korpus, nicht nur vor dem Merge über den Diff. Konsistenz, Platzhalter, Zahlen, Tags: Die Checks, die gegen die ganze Sprache vergleichen, müssen dort laufen, wo die ganze Sprache ist.

Was das nicht löst

• Jemand muss weiterhin Polnisch lesen. Das Muster macht Review günstig und gezielt; es lässt es nicht verschwinden. Quality Estimation kann die zuverlässigen Entwürfe durchwinken und die zweifelhaften zurückhalten, aber die Entscheidung über einen zweifelhaften String ist menschliche Arbeit.
• Auch der Quelltext ist agentengeschrieben. Agents schreiben das Englische genauso wie das Deutsche, und englische Strings driften in der Terminologie genauso wie Übersetzungen. Ein Lint auf verbotene Begriffe in neuen Quell-Strings fängt einen Teil davon ab; eine Texterin den Rest.
• Risiko-Strings bleiben eine Policy-Frage. Welche Strings unabhängig von der Konfidenz eine Person brauchen, welche Inhalte unter die Offenlegung im öffentlichen Interesse fallen und wer die redaktionelle Verantwortung für eine Veröffentlichung trägt, sind Entscheidungen, die ein Werkzeug festhält, aber nicht trifft.
• Kleine Projekte können das alles überspringen. Zwei Sprachen, die das Team liest, kein Umsatz und keine Compliance am Text: Lassen Sie den Agenten die Dateien bearbeiten. Das Signal für den Wechsel ist die erste Sprache, die niemand im Team liest.

Wie das in Locize funktioniert

Locize stellt Agents die Systemseite des Musters über seinen MCP-Server zur Verfügung, erreichbar unter https://mcp.locize.app aus Claude, Cursor, GitHub Copilot und anderen MCP-Clients, mit insgesamt 26 Werkzeugen. Agentengetriebene Übersetzungsschleifen (fehlende Keys finden, Quelle holen, Entwürfe schicken, Review-Warteschlange lesen) sind ein sichtbarer und stetig wachsender Anteil des Traffics auf diesem Server.

• Kontext vor dem Entwurf. get_glossary liefert bevorzugte, erlaubte und verbotene Begriffe pro Sprache; get_styleguide liefert Ton, Anrede, Zielgruppe und Verwendungsregeln; search_translation_memory findet frühere Übersetzungen ähnlicher Quell-Strings, exakt und unscharf; get_screenshot_context zeigt, wo ein mehrdeutiger Key erscheint. Alle vier sind schreibgeschützt, und der Beitrag zu den Kontext-Werkzeugen geht sie durch.
• Entwürfe landen im Review, nicht in der Produktion. report_missing_keys legt neue Keys an, ohne bestehende zu überschreiben (und löst die automatische Übersetzung aus, wo sie aktiviert ist). update_translations nimmt eine quality von AI für Texte, die der Agent erzeugt hat, oder HT für den Text einer Person; KI-Werte werden gemäss der Projektregel als zu prüfen markiert (immer, oder nur wenn der Score der Quality Estimation unter dem Schwellenwert liegt), und mit find_missing_translations und get_translations mit needsReviewOnly kann der Agent die Warteschlange lesen, die er gerade gefüllt hat.
• Eine Person entscheidet, und die Historie sagt wer. Reviewer bestätigen, bearbeiten oder lehnen im Editor ab; der Review-Workflow zeichnet jede Entscheidung auf, und der Provenienz-Export aus dem Leitfaden zum Artikel-50-Workflow verpackt sie als CSV und JSON.

Die Warteschlange "needs review" im Locize-Editor: markierte Werte und offene Vorschläge, pro Wert von einem Reviewer bestätigt

• Standardeinstellungen, damit sich niemand die Regeln merken muss. Das öffentliche Repository locize-agents enthält Konventionsdateien (CLAUDE.md, AGENTS.md, .cursorrules), die einen Agenten dazu bringen, vor dem Übersetzen Glossar, Styleguide und Memory abzurufen und Pull Requests auf verbotene Begriffe zu linten. Für Projekte, die noch nicht angebunden sind, hängt npx i18next-cli init --agent-note (i18next-cli 1.73 oder neuer) eine kurze Internationalisierungs-Notiz an AGENTS.md an, damit die nächste Agentensitzung weiss, wo die Sprachdateien liegen, welche Befehle sie ausführen soll, und dass sie nachfragen soll, bevor sie einen Übersetzungsdienst verdrahtet.

Der Agent behält seine Geschwindigkeit. Was sich ändert: Seine Entwürfe kommen an einem Ort an, der ein Gedächtnis, einen Reviewer und eine Aufzeichnung hat. Wenn Ihr Agent bereits übersetzt: Erstellen Sie ein Projekt, verbinden Sie den MCP-Server und lassen Sie den nächsten Pull Request hindurch entwerfen; die Review-Warteschlange zeigt Ihnen, was die vorherigen ausgeliefert hätten.

Häufig gestellte Fragen

Können KI-Coding-Agents eine App übersetzen? Ja, und für eine einzelne Änderung oft gut: Mit der Codebasis im Kontext sieht ein Agent die Komponente, die Typen der Platzhalter, den umliegenden Text und die Git-Historie. Was er über die Zeit nicht mitnimmt, sind Konsistenz über Releases hinweg, eine Aufzeichnung darüber, wer was freigegeben hat, Terminologie, die ausserhalb der aktuellen Sitzung entschieden wurde, und Qualitätsprüfungen über den gesamten Korpus. Der Agent ist ein guter Entwerfer; die Entwürfe brauchen ein System dahinter.

Was geht kaputt, wenn ein Coding-Agent Übersetzungsdateien direkt bearbeitet? Nichts, was im Pull Request sichtbar wäre. Über Pull Requests hinweg wird dasselbe Konzept unterschiedlich wiedergegeben, die Anrede kippt zwischen Screens, Pluralformen für Sprachen mit mehr als zwei Formen werden inkonsistent geraten, und die einzige Aufzeichnung einer Entscheidung ist ein Commit von einem Bot. Checks, die eine Übersetzung mit ihrer Quelle und mit dem Rest der Sprache vergleichen, laufen nicht auf einem Diff, also sammeln sich Defekte unbemerkt an.

Was ist das Agent-in-the-Loop-Muster für Übersetzungen? Der Agent bleibt der Entwerfer, entwirft aber durch das Translation-Management-System: Er holt vor dem Schreiben Glossar, Styleguide und passende Translation-Memory-Einträge, meldet neue Keys und schickt seine Übersetzungen als KI-Output deklariert, was sie in die Review-Warteschlange stellt; eine Person, die die Sprache liest, bestätigt oder bearbeitet jeden Wert, und die Entscheidung wird aufgezeichnet.

Gilt die EU-KI-Verordnung für Übersetzungen, die ein Coding-Agent entworfen hat? Artikel 50 gilt seit dem 2. August 2026. Nach den finalen Leitlinien der Kommission vom 20. Juli 2026 ist eine originalgetreue KI-Übersetzung von der maschinenlesbaren Kennzeichnung ausgenommen; die sichtbare Offenlegungspflicht betrifft nur Texte, die veröffentlicht werden, um die Öffentlichkeit über Angelegenheiten von öffentlichem Interesse zu informieren, und entfällt bei dokumentierter menschlicher Überprüfung unter einer Person mit redaktioneller Verantwortung. Ein aufgezeichneter Review-Schritt ist der Weg zur Ausnahme. Das ist keine Rechtsberatung.

Wie bringe ich meinen Coding-Agent dazu, Glossar und Styleguide zu nutzen? Geben Sie ihm Werkzeuge statt Dokumente: Über den Locize-MCP-Server ruft er vor dem Entwerfen get_glossary, get_styleguide und search_translation_memory auf und bei mehrdeutigen Strings get_screenshot_context; die Konventionsdateien im Repository locize-agents machen das zum Standard. Für noch nicht angebundene Projekte hinterlässt i18next-cli init --agent-note eine Notiz in AGENTS.md, damit die nächste Agentensitzung das Setup kennt und nachfragt, bevor sie etwas verdrahtet.