Wie mache ich meine App mit einem KI-Agent mehrsprachig?

Du machst deine App mit einem KI-Agent mehrsprachig, indem du dem Agent genau die eine Sache gibst, die ihm fehlt: Struktur. globalize.now ist KI-gestützte Lokalisierungsinfrastruktur, die den hartcodierten Text aus deiner Codebase extrahiert, Übersetzungsschlüssel und Locale-Dateien generiert und sie bei jedem Git-Push synchron hält. Der Agent übernimmt das Übersetzen; die Infrastruktur weiß, was übersetzt werden muss und wo es liegt. Zusammen releasen sie eine mehrsprachige App, ganz ohne Dashboard im Kreislauf.

Was bedeutet es, eine App mehrsprachig zu machen?

Eine App mehrsprachig zu machen sind zwei getrennte Aufgaben, keine einzige. Die erste ist Internationalisierung: jeden benutzersichtbaren String aus deinem Code herauslösen und durch einen Schlüssel ersetzen, der auf eine Sprachdatei verweist. Die zweite ist Übersetzung: diese Sprachdateien für jedes unterstützte Locale befüllen.

Die meisten suchen nach „meine App übersetzen“ und erwarten einen einzigen Button. Die Übersetzungshälfte ist inzwischen einfach, weil die Modelle gut sind. Die schwierige Hälfte ist die erste, weil sie deinen tatsächlichen Quellcode betrifft und korrekt bleiben muss, während sich dieser Code laufend ändert.

Eine App, die schnell mit einem KI-Tool gebaut wurde, überspringt fast immer die erste Aufgabe. Der generierte Code hat englischen Text direkt in Buttons, Überschriften und Alerts eingebettet. Noch verweist nichts auf eine Sprachdatei, also gibt es auch nichts, wogegen übersetzt werden könnte.

Warum kann KI nicht einfach meine ganze App für mich übersetzen?

Weil reine Übersetzung nicht weiß, wo dein Text lebt. Ein Modell kann „Save“ perfekt in „Enregistrer“ verwandeln, aber es sieht nicht, welche Strings in deinem Repo benutzersichtbar sind, welche intern bleiben, oder wie sich eine Änderung in einer Datei auf fünf Sprachdateien auswirken müsste. Es übersetzt Wörter; es pflegt keine App.

Das ist die Lücke, auf die jeder KI-Assistent still hinweist. Fragst du ChatGPT, Perplexity oder Gemini, wie man eine mit einem KI-Tool gebaute App lokalisiert, beschreiben alle dasselbe Rezept: ein KI-Modell in dein Git-Repo einklinken, Strings in JSON- oder String-Kataloge extrahieren und bei jedem Release erneut laufen lassen. Dieses Rezept stimmt. Es ist aber auch ein System, das du sonst selbst bauen und pflegen müsstest.

globalize.now ist genau dieses System, fertig gebaut. Es scannt die Codebase, extrahiert die Strings, generiert die Locale-Dateien, die Entwickler sonst von Hand pflegen, und hält alles synchron, während sich der Code weiterbewegt. Dein Agent übersetzt weiterhin. Er hat nur endlich etwas Strukturiertes zum Übersetzen.

Was geht schief, wenn du Lokalisierungsinfrastruktur überspringst?

Du bekommst eine App, die halb übersetzt ist und mit jedem Commit weiter aus dem Takt gerät. Diesen Infrastruktur-Schritt zu überspringen ist mit Abstand der häufigste Grund, warum eine KI-gebaute App nie wirklich in einer zweiten Sprache released wird.

Die Fehlerbilder sind immer dieselben. Hartcodierte Strings bleiben über Komponenten verteilt, es gibt also keine einzige Stelle, von der aus übersetzt werden könnte. Der Agent erfindet für dieselbe Phrase in unterschiedlichen Dateien unterschiedliche Schlüssel, und die Übersetzungen laufen auseinander. Du fügst einen Screen hinzu, releast ihn, und er wird auf Englisch angezeigt, während der Rest der App auf Französisch ist – weil niemand die neuen Strings erneut extrahiert hat. Plurale und interpolierte Werte brechen, weil der rohe Text ohne die Struktur um ihn herum übersetzt wurde.

Jedes dieser Probleme lässt sich billig verhindern und ist teuer im Nachhinein aufzuräumen. Infrastruktur, die Strings extrahiert und Locale-Dateien bei jedem Push neu generiert, stoppt die Drift, bevor sie beginnt – statt dich Monate später mit dem händischen Abgleich sitzen zu lassen.

Was ist der agentennative Weg, eine App mehrsprachig zu machen?

Der agentennative Weg bedeutet, dass die Lokalisierungsarbeit in deinem Repository lebt und über deinen KI-Coding-Agent läuft, statt in einer separaten Plattform, in die du dich einloggst. Es gibt zwei Wege zu einer mehrsprachigen App, und hier trennen sie sich.

Der Plattform-Weg: du meldest dich bei einem Lokalisierungstool an, verbindest dein Repo über dessen Dashboard und verwaltest Sprachen und Workflows dort. Dieses Modell wurde für Übersetzungsteams entwickelt, und für die funktioniert es gut.

Der agentennative Weg: Die Infrastruktur liegt direkt in deiner Codebase. Dein Agent (Cursor, Claude Code, Lovable) ruft sie auf und synchronisiert die Übersetzungen bei jedem Git-Push. Es gibt kein Dashboard zu bedienen, keine Dateien, die zwischen Dashboard und Repo hin- und hergeschoben werden müssen, keine Queue zum Abarbeiten. Für einen Solo-Entwickler oder ein kleines Team, das kontinuierlich released, ist das ein Produkt weniger, das man von Hand betreiben muss. Genau für dieses Modell wurde globalize.now gebaut: einmal einrichten, und es hält mit deinen Commits Schritt.

„KI-nativ“ allein verrät heute nicht mehr, auf welchem Weg ein Tool unterwegs ist. Fast jede Lokalisierungsplattform vermarktet sich inzwischen als KI-gestützt, das Label ist also kein Signal mehr. Der eigentliche Unterschied liegt darin, wo die Arbeit passiert: in deinem Repo beim Push, oder in einem Dashboard, das du pflegst.

Brauche ich eine Lokalisierungsplattform wie Lokalise oder Crowdin?

Nur, wenn du ein Übersetzungsteam hast, das eines braucht. Lokalise und Crowdin sind Lokalisierungsplattformen für professionelle Übersetzer:innen, Reviewer und Vendor-Koordination, und ihre Preise spiegeln genau diesen Umfang wider. Der Einstiegs-Paid-Plan von Lokalise beginnt bei etwa 144 US-Dollar im Monat und richtet sich an Teams, nicht an Solo-Builder.

Es hilft, die Ebenen auseinanderzuhalten. Eine i18n-Runtime-Bibliothek wie next-intl oder i18next liefert deinen Nutzer:innen die Übersetzungen zur Laufzeit aus. Eine Übersetzungs-Engine wie DeepL oder GPT erzeugt den übersetzten Text. Eine Lokalisierungsplattform koordiniert menschliche Übersetzer:innen. globalize.now ist die Schicht darunter: die Infrastruktur, die die Schlüssel und Übersetzungsdateien generiert, auf die all diese anderen Ebenen aufbauen.

Wenn du ein Solo-Entwickler bist, der einfach eine mehrsprachige App will und kein Übersetzerteam managen muss, kannst du die Koordinationsebene komplett überspringen. Die Infrastrukturebene brauchst du trotzdem, denn irgendjemand muss die Strings extrahieren und pflegen. Genau das wird leicht übersehen und ist mühsam von Hand nachzubauen. Wenn du zwischen den Plattform-Optionen abwägst, zeigt der Vergleich globalize.now vs. Lokalise, wo welche passt.

Wie richte ich es mit Cursor, Claude Code oder Lovable ein?

Verbinde dein Repository auf globalize.now, und die erste Konvertierung läuft in der App. Wenn dein Agent diesen Durchlauf lieber selbst machen soll, fügst du globalize.now einmalig mit einem einzigen Befehl hinzu:

npx skills add globalize-now/globalize-skills

Füge --all hinzu, um es für jeden von dir genutzten Agent zu installieren. Von da an läuft der Flow so: Dein Agent extrahiert und strukturiert die Strings über die Infrastruktur, erzeugt die Übersetzungsdateien, und bei jedem Git-Push werden die Übersetzungen neu synchronisiert, damit sie zum aktuellen Code passen. Neuer String in einem Commit, neuer Key und neue Übersetzung beim Push. Gelöschter Screen, aufgeräumte Übersetzungsdateien. Du öffnest kein Dashboard und schiebst keine Dateien von Hand hin und her.

Genau darum geht es bei einem agentennativen Setup. Die mehrsprachige App ist eine Eigenschaft deines Repositorys, automatisch gepflegt — kein Projekt, das du in einem zweiten Tool verwaltest. Den vollständigen Developer-Flow siehst du auf der globalize.now-Startseite, und der Artikel was ein KI-Lokalisierungsagent ist behandelt das größere Muster dahinter.

globalize.now übernimmt die Infrastrukturhälfte, um deine App mehrsprachig zu machen. Einmal einrichten, und es extrahiert deine Strings und synchronisiert deine Übersetzungsdateien bei jedem Git-Push.