Was passiert, wenn ein KI-Agent ein echtes Monorepo internationalisiert?

Er extrahierte 28 Kandidaten für UI-Strings, schrieb 41 Übersetzungseinträge über mehrere Dateien hinweg um, konfigurierte Middleware und Routing und generierte Übersetzungsdateien für 5 Zielsprachen. Setup, Konvertierung und Übersetzung dauerten insgesamt etwa 90 Minuten. globalize.now ist KI-gestützte Lokalisierungsinfrastruktur, und wir haben sie an einem Produktions-Monorepo getestet, um zu sehen, was wirklich passiert. Keine kuratierte Demo. Kein Sicherheitsnetz. Nur eine echte Codebase mit echter Komplexität.

Die Codebase gehörte einem Veteranen der Lokalisierungsbranche, der über ein Jahrzehnt als Architekt bei einer der führenden Translation-Management-Plattformen gearbeitet hatte.

Was steckte im Monorepo?

Das war kein Tutorial-Projekt. Das Monorepo enthielt eine Next.js-Webanwendung, eine Android-App, MCP-Server und Dokumentation, die von einem Drittanbieter-Dienst gerendert wurde. Der Entwickler nutzt täglich Claude Code, baut durchgängig mit KI-Tools und hatte den gesamten Stack in drei Monaten zusammengestellt.

Das Ziel war das Next.js-Frontend. Die Android-App, die MCP-Server, die auf Mintlify gebaute Docs-Site – nichts davon sollte angefasst werden. Die Frage war, ob ein KI-Agent das herausfinden konnte, ohne es explizit gesagt zu bekommen.

Er konnte es. Der Agent scannte das gesamte Repo und konzentrierte sich auf die Next.js-Anwendung. In der Praxis war kein manuelles Scoping nötig, auch wenn der Entwickler anmerkte, dass er zur Beruhigung gerne die Möglichkeit gehabt hätte, „nur /apps/web konvertieren“ anzugeben. Das ist ein berechtigter Punkt und etwas, das sich zu ergänzen lohnt. Es blockierte die Konvertierung aber nicht.

Wie lief die Konfiguration ab?

Der Entwickler wählte den geführten Modus, um den Prozess nachzuvollziehen. Die Konfiguration umfasste fünf Entscheidungen: Paketmanager (NPM, trotz einer noch vorhandenen alten PNPM-Lockfile), Katalogformat (PO/GetText, empfohlen für Kommentar-Unterstützung), Setup-Modus (geführt), Ausgangssprache (Englisch) und Zielsprachen (Spanisch, Italienisch, Ungarisch, Tschechisch, Slowakisch).

Eine Beobachtung ist bemerkenswert: Die Frage nach dem Katalogformat sorgte selbst bei jemandem mit tiefer Lokalisierungsexpertise für Zögern. Seine Reaktion war direkt. Er fand nicht, dass die Wahl wichtig genug war, um den Nutzer danach zu fragen. Automatisieren, so seine Meinung.

Die Routing-Strategie war pfadbasiert. Kein domainbasiertes Routing, da der Entwickler keine zusätzlichen Domains besaß. Die App nutzt OAuth-basierte Authentifizierung, weshalb die Login-Abläufe bewusst auf Englisch blieben. Der Agent handhabte das korrekt.

Was macht der Konvertierungsschritt eigentlich?

Das ist der Teil, der wirklich zählt. Der Agent identifizierte 28 UI-String-Kandidaten in der Next.js-App und verarbeitete 41 Übersetzungseinträge. Er reorganisierte Dateien, aktualisierte die Middleware, passte Komponenten-Imports an und generierte PO-Übersetzungsdateien für alle 5 Zielsprachen.

Allein der Konvertierungsschritt dauerte etwa 30 Minuten. Rechnet man Setup und Konfiguration davor sowie die anschließende, eigenständig abgeschlossene Übersetzungsanbindung durch den Entwickler dazu, lag der komplette End-to-End-Prozess bei knapp 90 Minuten. Das ist nicht instant. Zum Vergleich: Eine einfache App mit ein paar Seiten durchläuft den gesamten Flow in unter 15 Minuten. Eine komplexe App mit Dutzenden übersetzbaren Oberflächen braucht länger. Die Zeit skaliert mit der Anzahl der Strings, nicht mit der Größe des Repos.

Der Entwickler beobachtete den Konvertierungsschritt und sagte Folgendes: Die String-Extraktion und das Code-Rewriting sind die eigentliche Schwerarbeit. Das ist die Arbeit, vor der Entwickler:innen sich fürchten. Bei seiner früheren Firma, einem führenden TMS-Anbieter, waren die Übersetzungsdateien im Repo nur die Spitze des Eisbergs. Die Vorbereitung und die Internationalisierungsarbeit waren der eigentliche Schmerzpunkt. Und genau dieses Teilstück hat der KI-Agent übernommen.

Das deckt sich mit dem, was wir von jedem Entwickler hören, der i18n schon einmal manuell durchgezogen hat. Über die Übersetzungen beschwert sich niemand. Beschwert wird sich darüber, 40 Dateien anzufassen, um Strings in t()-Aufrufe einzupacken, sinnvolle Keys zu generieren, Imports umzustrukturieren und die Middleware zu konfigurieren. Genau das automatisiert globalize.now.

Hat es am Ende wirklich end-to-end funktioniert?

Ja. Nach dem Ende der Live-Session hat der Entwickler die restlichen Schritte eigenständig abgeschlossen. Er hat den globalize.now-Git-Branch veröffentlicht, die App mit der Web-Plattform verbunden, das Monitoring auf den globalize.now-Branch gesetzt und bestätigt, dass die Dateien korrekt hochgeladen und übersetzt wurden.

Seine Einschätzung zur Qualität der tschechischen Übersetzung: nahezu perfekt. Das sagt jemand, der seine ganze Karriere damit verbracht hat, Lokalisierungsergebnisse professionell zu bewerten. Das ist kein pauschales Lob. Das ist ein Fachexperte, der die produktionsreife Qualität bei einem nicht-trivialen Sprachpaar bestätigt.

Nach dem eigenständigen Abschluss des Flows meldete er zwei Probleme in der Web-App. Erstens zeigte ein erneuter Scan des Repos „keine i18n-Dateien erkannt“, obwohl der Übersetzungsjob im Hintergrund tatsächlich lief. Ein irreführender UI-Zustand, kein echter Fehler. Zweitens startete der Übersetzungsjob ohne ausdrückliche Zustimmung. Jede Aktion, die Credits kostet, sollte eine Bestätigung erfordern. Beide sind valide UX-Probleme, an denen bereits gearbeitet wird.

Was ist schiefgelaufen?

Es gab Ausfälle. Das war ein echter Test, also sind wir ehrlich darüber.

Der Installationsbefehl (npx skills add globalize-now/globalize-skills) schlug unter Windows PowerShell fehl. Das war der erste Test des Tools unter Windows. Die Skills mussten nach einer Blockierung des E-Mail-Anhangs durch Google als ZIP-Datei via Swiss Transfer verschickt werden. Gesamte Setup-Reibung: rund 15 Minuten, bevor der eigentliche Flow überhaupt startete.

Mitten in der Konvertierung tauchte ein Konflikt zwischen ES Modules und CommonJS auf. Das Projekt nutzt CommonJS, der Output des Agents ging an einer Stelle jedoch von ES Modules aus. Kein Blocker, aber etwas, das beim Setup erkannt und proaktiv behandelt werden sollte.

Am Ende der Session lieferte das Verbinden des GitHub-Repos in der globalize.now-Web-App eine leere Seite. Der Entwickler nutzte Opera. Kein Login-Screen, kein Fehler, kein Inhalt. Die Session endete, bevor das Problem gelöst war.

Drei Bugs. Alle echt. Alle behoben oder in Bearbeitung.

Warum ist String-Extraktion der eigentliche Flaschenhals?

Die meisten i18n-Inhalte konzentrieren sich auf Übersetzungsqualität, Framework-Konfiguration oder TMS-Feature-Vergleiche. Damit verpasst man, wo Entwickler:innen tatsächlich Zeit verlieren.

Internationalisierung in eine bestehende Codebase einzubauen bedeutet: jede Komponente auf hartcodierte Strings scannen, entscheiden, welche Strings übersetzbar sind, sinnvolle Übersetzungsschlüssel generieren, jeden String in den passenden t()- oder <Trans>-Aufruf einpacken, Imports im gesamten Dateibaum aktualisieren, die initialen Übersetzungsdateien anlegen und die Routing-Middleware konfigurieren. Bei einem Monorepo kommt noch die Komplexität dazu, herauszufinden, welche Teile der Codebase überhaupt i18n brauchen.

Das ist mühsam, fehleranfällig — und genau die Art Arbeit, für die KI-Agenten gemacht sind. Der Entwickler, der es live erlebt hat, bringt es auf den Punkt: Aus Entwicklersicht ist das die Schwerarbeit. Das ist eine enorme Erleichterung. Vibe Coder, die mit KI-Tools bauen, können den unangenehmsten Teil der Internationalisierung jetzt komplett überspringen.

Was haben wir über Monorepo-Scoping gelernt?

Der Agent hat das Monorepo-Scoping implizit gelöst. Er konzentrierte sich auf die Next.js-Web-App und ignorierte den Android-Code, die MCP-Server und die Mintlify-Docs, ohne dass er dazu angewiesen wurde. Das ist in den meisten Fällen das richtige Verhalten.

Aber implizites Scoping ist nicht dasselbe wie explizites Scoping. Der Entwickler wollte die Möglichkeit haben, als Konfigurationsschritt zu sagen: „Konvertiere nur meine Next.js-App.“ In einem Monorepo mit mehreren Web-Frontends — etwa einer kundenseitigen App und einem Admin-Dashboard — will man präzise steuern können, welches Frontend zuerst internationalisiert wird.

Das ist eine Produktlücke, die wir gerade schließen. Aktuell trifft der Agent in der Praxis die richtige Entscheidung. Explizites Scoping sollte trotzdem ein Konfigurationsschritt sein — besonders wenn die Konvertierung Dutzende Dateien betrifft.

Wie schneidet das im Vergleich zum manuellen i18n-Setup ab?

Ein manuelles i18n-Setup dauert bei einer Codebase dieser Komplexität Tage. Nicht weil ein einzelner Schritt schwierig wäre, sondern weil es Dutzende Schritte gibt und jeder Aufmerksamkeit erfordert. Übersieht man einen String, liefert man eine halbübersetzte Seite aus. Vertippt man sich beim Key-Namen, entstehen doppelte Einträge, die einen monatelang verfolgen. Vergisst man, die Middleware zu aktualisieren, bricht das Locale-Routing lautlos zusammen.

Der KI-Agent hat die gleichwertige Arbeit end-to-end in rund 90 Minuten erledigt. Der Entwickler, der beruflich Tausende von i18n-Implementierungen gesehen hat, nannte es elegant.

Für Entwickler:innen, die mit KI-Tools bauen, ändert das die Rechnung, wann Sprachen hinzugefügt werden. Dauert das i18n-Setup eine Woche, verschiebst du es, bis der Product-Market-Fit belegt ist. Dauert es 90 Minuten, kannst du von Tag eins an mehrsprachig releasen.

globalize.now übernimmt das. Verbinde dein Repository, und die Konvertierung läuft einmalig in der App; die npx skills add globalize-now/globalize-skills-Skills decken alles Weitere direkt in deinem Editor ab. Sieh dir an, wie es funktioniert – auf globalize.now.