Du hast deinen Coding-Agent die App in einem einzigen Prompt übersetzen lassen. Was solltest du prüfen, bevor du sie auslieferst?

Prüfe sieben Dinge, bevor du eine App auslieferst, die Codex, Claude Code oder Cursor in einem Prompt übersetzt haben: ob lange Strings passen, ob die Pluralformen zu jeder Sprache passen, ob die Variablen erhalten geblieben sind, ob die Begriffe konsistent bleiben, ob die Tonalität für Muttersprachler stimmt, ob jeder Key in jedem Locale existiert und ob das nächste Feature überhaupt übersetzt wird. globalize.now ist KI-gestützte Lokalisierungsinfrastruktur, und das meiste, was wir nach einer Ein-Prompt-Übersetzung schiefgehen sehen, ist mechanisch – das ist die gute Nachricht, denn mechanische Probleme lassen sich prüfen.

Der erste Durchlauf ist selten das Problem. Moderne Agents liefern schnell gut lesbare Übersetzungen. Was ein einzelner Prompt nicht enthält, ist irgendein Schritt, der die Ausgabe verifiziert – und genau diesen Schritt liefern diese Checks.

Passt der Text nach der Übersetzung noch?

Oft nicht, und Buttons brechen zuerst. Die W3C-Hinweise zur Textgröße bei Übersetzungen halten fest: Je kürzer die Quellnachricht, desto stärker fällt die Expansion voraussichtlich aus – ein Button-Label mit zwei Wörtern wächst also proportional mehr als ein Absatz. Außerdem weisen sie darauf hin, dass Komposita in Sprachen wie Deutsch möglicherweise nicht umbrechen und dass manche Schriften mehr horizontalen oder vertikalen Platz brauchen als lateinischer Text.

Ein Agent, der Strings in einer JSON-Datei übersetzt, sieht den Screen nie. Er kann also nicht wissen, dass „Save changes“ den Button jetzt von Kante zu Kante ausfüllt. Starte die App im längsten Locale, das du auslieferst, geh die wichtigsten Flows durch und halte Ausschau nach abgeschnittenem Text, umbrochenen Buttons und gekürzten Tabellenköpfen. Wenn du Right-to-left-Sprachen unterstützt, mach denselben Durchlauf in einer davon; der Leitfaden zu Arabisch und RTL für Lovable-Apps behandelt die Schreibrichtung, die Overflow-Checks allein nicht abdecken.

Die dauerhafte Lösung liegt im Layout, nicht in kürzeren Übersetzungen: Lass Container wachsen, vermeide feste Breiten für Text und kürze nicht ab, nur damit es passt. Lass das deinen Agent erledigen, denn das ist Code.

Passen die Pluralformen zur Zielsprache?

Prüfe das früh, denn es scheitert still. Unicode CLDR definiert sechs Pluralkategorien: zero, one, two, few, many und other. Englisch nutzt nur one und other. Russisch nutzt one, few, many und other. Walisisch nutzt alle sechs, und auch die Dokumentation von i18next zeigt Arabisch mit allen sechs Plural-Keys.

Ein Agent, der das englische Paar in eine russische oder arabische Datei kopiert, erzeugt einen Katalog, der sich parsen und rendern lässt und für jede Zahl, die eine in der Datei fehlende Kategorie braucht, die falsche Form anzeigt. Einen Fehler gibt es dabei nicht. Bei i18next muss die Variable exakt count heißen, und laut Dokumentation gibt es keinen Fallback auf den einfachen Key, wenn sie fehlt. Derselbe Agent, der count === 1 ? 'item' : 'items' in eine Komponente schreibt, hat denselben Bug schon vor der Übersetzung; was ICU MessageFormat ist und warum es KI-generierte Apps ins Stolpern bringt behandelt die Syntax-Seite.

Der Check ist mechanisch: Vergleiche für jedes Locale die Plural-Keys mit den Kategorien, die diese Sprache braucht.

Sind die Interpolationsvariablen erhalten geblieben?

Nicht immer, und ein Skript klärt das. Interpolationsvariablen wie {{name}} oder {count} müssen in jeder Übersetzung exakt so stehen, wie sie geschrieben sind. Agents, die eine lange Datei übersetzen, formulieren Variablen manchmal um, lassen eine weg, weil der Satz ohne sie besser klingt, oder übersetzen den Inhalt eines Tags. Das Ergebnis erscheint als Leerstelle, als wörtliche Klammer oder als Absturz.

Vergleiche die Variablen jedes übersetzten Strings mit denen des Quell-Strings. Dieses kurze Node-Skript erledigt das und meldet zusätzlich Keys, die auf Englisch existieren, in einem anderen Locale aber fehlen:

import fs from "node:fs";

const [src, ...targets] = process.argv.slice(2);
const read = (f) => JSON.parse(fs.readFileSync(f, "utf8"));
const vars = (s) =>
  [...String(s).matchAll(/\{\{?\s*[\w.]+\s*\}?\}/g)].map((m) => m[0]).sort().join(",");

const base = read(src);
let problems = 0;
for (const file of targets) {
  const loc = read(file);
  for (const [key, text] of Object.entries(base)) {
    if (!(key in loc)) { console.log(file, "missing", key); problems++; continue; }
    if (typeof text === "string" && vars(text) !== vars(loc[key])) {
      console.log(file, "variable mismatch", key); problems++;
    }
  }
}
process.exit(problems ? 1 : 0);

Lass es als node check-locales.mjs locales/en.json locales/de.json locales/ru.json in der CI laufen. Es setzt Dateien mit einer einzigen Key-Ebene voraus; passe die Schleife an, wenn dein Katalog verschachtelt ist.

Ist die Terminologie konsistent?

Innerhalb einer einzigen Antwort ja, über mehrere hinweg driftet sie. Wird die Übersetzung einer großen App auf Dateien, Sessions oder Batches verteilt, erzwingt nichts, dass „Workspace“, „Project“ und dein Produktname jedes Mal gleich herauskommen. Am Ende steht auf einem Button das eine und auf der Hilfeseite das andere.

Halte die Begriffe einmal fest: ein Glossar mit Produktnamen, Feature-Namen und Wörtern, die nicht übersetzt werden dürfen, und der Übersetzungsschritt muss es lesen. globalize.now erzeugt beim Konvertieren der Codebase ein gemeinsames Glossar, sodass die Begriffe als Daten vorliegen, bevor irgendeine Übersetzung stattfindet. Ohne Tool ist eine kurze Glossardatei, auf die deine Agent-Anweisungen verweisen, das Minimum; der Beitrag zu den AGENTS.md-Regeln zeigt, wo diese Anweisungen liegen.

Klingt es für Muttersprachler richtig?

Das ist die eine Prüfung, die kein Skript übernehmen kann. Register, Förmlichkeit und Schreibweise sind die Stellen, an denen Übersetzungen per Einzelprompt nach Maschine klingen: die falsche Anredeform, Buttons im Imperativ, die wie Befehle wirken, oder eine Überschrift in Großbuchstaben in einer Sprache, in der das wie Schreien wirkt.

Prüfe nicht jeden String. Such dir pro ausgelieferter Sprachfamilie eine Sprache aus und lass eine muttersprachliche Person die First-Run-Screens, den Checkout- oder Signup-Flow und die Fehlermeldungen lesen. Auf diesen Screens kostet dich die Tonalität Nutzer. Trage die Korrekturen ins Glossar ein, damit der nächste Durchlauf darauf aufbaut.

Existiert jeder Key, und hat es jeder String in den Katalog geschafft?

Zwei verschiedene Lücken sehen auf dem Screen gleich aus. Ein Key kann auf Englisch existieren und in einem Locale fehlen – das fängt das Skript oben ab. Oder ein String wurde in der Komponente hartcodiert und gelangte nie in den Katalog, sodass keine Übersetzung ihn abdecken konnte. Agents lassen die zweite Sorte häufiger in Attributen, Toasts und Fehlermeldungen zurück als in sichtbarem Text; warum Agents immer wieder hartcodierte Strings einbauen behandelt das Muster und die Lint-Regel, die es abfängt.

Stell die App auf ein nicht-englisches Locale um und klick dich durch. Jedes verbleibende Englisch ist entweder ein fehlender Key oder ein String, der nie ins System gelangt ist – und die Lösung unterscheidet sich.

Wird das nächste Feature übersetzt?

Nur, wenn Übersetzung fester Teil davon ist, wie Code ausgeliefert wird – und genau diese Prüfung kann ein Lauf mit einem einzigen Prompt nicht bestehen. Der Prompt hat die App so übersetzt, wie sie an diesem Nachmittag aussah. Das nächste Feature, das dein Agent baut, kommt auf Englisch, in denselben Dateien, und die Locales fallen Feature für Feature zurück. Warum Übersetzungsdateien aus dem Sync laufen beschreibt, wie sich das anhäuft.

Hier trennen sich der Einmal-Ansatz und eine Pipeline. Lokalisierung, die in den Dev-Loop wandert legt dar, warum diese Position richtig ist; praktisch heißt das: Die Konvertierung passiert einmal, und spätere Änderungen werden dort übersetzt, wo sie entstehen. Mit globalize.now verbindest du das Repo in der App, die Codebase wird einmal konvertiert, und danach übersetzen Push-Jobs neue Katalogeinheiten – die Ergebnisse kommen als Änderungen zurück, die du prüfst und mergst. Die Runtime-Bibliothek und das Katalogformat bleiben deine. Teams, die bereits eine menschliche Übersetzerin oder einen menschlichen Übersetzer haben, behalten diesen Review-Schritt; er ist dann nur nicht mehr das Einzige, was zwischen rein englischem Code und einem Release steht.

Wenn du es lieber in deinen eigenen Skripten halten willst, ist das Minimum das Skript von oben in der CI plus eine Regel, dass neue Strings durch den Katalog laufen. Wie du eine KI-generierte App lokalisierst führt durch den gesamten Weg, und der Claude-Code-Leitfaden behandelt speziell diesen Agent.

Wo fängst du an?

Lass das Skript noch heute über deine aktuellen Locale-Dateien laufen; es dauert eine Minute und zeigt dir, ob die Struktur stimmt. Öffne dann die App in deinem längsten Locale und klick den First-Run-Flow durch. Wenn du eine KI-gebaute App veröffentlicht hast und Konvertierung, Übersetzung und spätere Updates erledigen lassen willst, statt sie von Hand zu pflegen, bietet die Seite für Vibe Coder den Überblick, die Developer-Referenz behandelt Agent-Setups, und die Preise findest du auf einer eigenen Seite.