Lokalisierung wird zum Agent-Skill, nicht zum SDK

Eine App zu lokalisieren bedeutete früher, ein SDK einzubinden, einen Provider zu verdrahten und Keys von Hand zu verwalten. Mit KI-Coding-Agents gibt es einen kürzeren Weg: einen Skill installieren, und der Agent übernimmt die Verdrahtung. globalize.now ist KI-gestützte Lokalisierungsinfrastruktur, die als offener Agent-Skill ausgeliefert wird. Du führst einen Befehl aus, dein Agent liest das Playbook, und deine Codebase erhält eine übersetzungsbereite Struktur, ohne dass du neue Infrastruktur pflegen musst.

Was ist ein Agent-Skill?

Ein Agent-Skill ist ein kleines Paket aus Anweisungen, das ein Coding-Agent liest und danach handelt. Er wird über das offene Skills-Ökosystem verteilt und mit der Skills-CLI installiert, zum Beispiel npx skills add owner/repo. Derselbe Befehl funktioniert mit Claude Code, Cursor, Codex, OpenCode und über fünfzig weiteren Agents.

Der Skill selbst ist eine SKILL.md-Datei plus eventuelle unterstützende Dateien und landet in dem Verzeichnis, in dem dein Agent ohnehin nachsieht. Die CLI verlinkt ihn zu einer einzigen kanonischen Kopie und protokolliert die Installation in einer Lockfile – ein Skill wird also zusammen mit dem Rest deines Projekts versioniert, statt in einem Vendor-Account zu leben. Es gibt sogar eine öffentliche Registry, sodass ein Skill etwas ist, das du finden, lesen und pinnen kannst wie jede andere Abhängigkeit.

Die eigentliche Verschiebung: Ein Skill ist kein Produkt, mit dem sich dein Agent integriert. Es ist Wissen, das dein Agent aufnimmt und dann auf deinen Code anwendet. Dieser Unterschied zeigt sich, sobald du ein neues Teammitglied onboardest. Es klont das Repo, der Skill ist bereits da, und dessen Agent handhabt deine Lokalisierung genauso wie deiner.

Warum i18n als Skill ausliefern statt als SDK?

Weil der schwierige Teil der Internationalisierung das Refactoring ist, und ein Skill bringt deinem Agent bei, das für dich zu erledigen. Ein SDK setzt voraus, dass dein Code bereits für Übersetzung strukturiert ist. Du musst trotzdem die hartcodierten Strings finden, ein Key-Schema entwerfen, Übersetzungsdateien anlegen und die Runtime-Bibliothek anbinden.

KI-gebaute Apps verschärfen das noch, weil Coding-Agents auf einen funktionierenden Screen optimieren, nicht auf Übersetzungsarchitektur. Das Ergebnis ist meist korrekt und releasefähig – und voller Strings wie <button>Submit order</button> statt eines Keyed Calls. Multipliziert über ein ganzes Projekt wird die Lokalisierungsarbeit zum Refactoring, nicht zur Konfigurationsänderung.

Bleibt das unbeachtet, summiert es sich. Dasselbe Label wird auf drei leicht unterschiedliche Arten geschrieben, Zähler werden als 1 messages gerendert, und beim ersten Hinzufügen einer Sprache findest du Screens, die halb Englisch und halb etwas anderes sind. Ein Skill ist darauf ausgelegt, all das in einem Durchgang abzufangen, bevor daraus hundert kleine Tickets werden.

Ein Skill kodiert dieses Refactoring als Anweisungen, die dein Agent ausführen kann. Er erkennt dein Framework, bestätigt die i18n-Runtime, die du bereits nutzt, etwa next-intl oder i18next, extrahiert die englischen Strings und generiert Keys und Übersetzungsdateien. Du importierst keine neue Runtime, die du versionieren und pflegen musst. Der Skill übernimmt das Setup und zieht sich dann zurück.

Was unterscheidet einen Skill von einem MCP-Server?

Ein MCP-Server ist ein Dienst, den dein Agent aufruft, ein Skill sind nur Dateien in deinem Projekt. Das Model Context Protocol ist eine gute Möglichkeit, Agents über einen laufenden Server Zugriff auf Live-Tools und -Daten zu geben. Aber einen Server musst du oder ein Anbieter hosten, und dein Agent ist darauf angewiesen, dass er erreichbar ist.

Hinter einem Skill steht kein Dienst. Er ist Text und Code, der in deinem Repository landet, ohne Netzwerkaufruf funktioniert und wie jede andere Änderung in einem Pull Request auftaucht. Für einmalige Setup-Arbeiten wie das Internationalisieren einer Codebase schlagen Dateien einen Dienst, den du am Laufen halten musst. Du liest, was der Skill tun wird, führst ihn aus und prüfst den Diff.

Skills lassen sich auch stapeln. Du kannst mehrere installieren, und sie stehen nebeneinander, weil jeder nur Anweisungen ist, kein weiterer Prozess, den du betreiben und bezahlen musst.

Wie installiert sich globalize.now als Agent-Skill?

Ein Befehl, den Rest übernimmt dein Agent.

npx skills add globalize-now/globalize-skills --all

Das Flag --all installiert jeden Skill für jeden Agent auf deinem Rechner – der sichere Standard, wenn du dir nicht sicher bist, welchen Agent du nutzt. Die CLI legt den globalize.now-Skill dort ab, wo dein Agent nach Skills sucht. Er funktioniert mit dem Agent, den du bereits nutzt, einschließlich Claude Code und Cursor.

Von dort aus bittest du deinen Agent, i18n einzurichten, und er folgt dem Playbook: das Framework erkennen, die Runtime-Bibliothek bestätigen, die nutzersichtbaren englischen Strings finden und Keys sowie Übersetzungsdateien generieren. Das Vorher-Nachher ist der Teil, den Entwickler:innen wiedererkennen.

// before
<button>Submit order</button>

// after
<button>{t("checkout.submit_order")}</button>

Die Keys landen in Übersetzungsdateien, die der Skill für dich erstellt und pflegt:

/locales
  en.json
  de.json
  es.json
  fr.json

Deine englische Datei wird mit den vom Agent gefundenen Strings befüllt. Die anderen Sprachen werden generiert und bei jedem Push aktuell gehalten – einen Markt zu erschließen ist damit eine Übersetzungsdatei, kein Sprint.

Nach dem Setup synchronisieren sich Übersetzungen bei jedem Git-Push. Du exportierst nichts, und es gibt keine Warteschlange abzuarbeiten. Wenn du deine App per Vibe-Coding baust, ist das schon der gesamte Job. Wenn du Entwickler:in bist und die Details wissen willst: Derselbe Skill führt das Refactoring sauber durch und hinterlässt dir standardkonforme Übersetzungsdateien.

Bleiben meine Übersetzungen in meinem Repo?

Ja. Die vom Skill generierten Übersetzungsdateien werden wie jede andere Quelldatei in dein Repository committet. Das ist der Punkt, der beim Thema Lock-in am meisten zählt.

Manche Ansätze verschieben deine übersetzten Strings in einen Build-Schritt oder ein gehostetes Dashboard – verlässt du den Anbieter, verlässt dich auch deine Übersetzungsebene. Bei repo-nativen Übersetzungsdateien sind deine en.json, de.json und der Rest ganz normale Dateien in deinem Projekt. Der Skill könnte morgen verschwinden, und deine App würde trotzdem weiterhin jede Sprache ausliefern, die sie schon hat. Aufhören bedeutet lediglich, den Skill nicht erneut zu installieren – es gibt nichts zu migrieren, weil nie etwas von dir woanders lag. Deshalb sitzt globalize.now in der Infrastrukturschicht deines Stacks und generiert die Keys und Übersetzungsdateien, statt sich um deine App herumzuwickeln.

Bindet dich das Skill-Modell an einen Anbieter?

Nein, und genau das ist der Grund, es zu bevorzugen. Der Skill wird aus einer offenen Registry installiert, die jeder unterstützte Agent lesen kann, nicht aus einem geschlossenen Plugin-Store. Die Ausgabe sind Standard-Übersetzungsdateien für die Runtime-Bibliothek, die du ohnehin gewählt hast – kein proprietäres Format, das du später wieder auflösen müsstest.

Du kannst genau nachlesen, was der Skill tut, bevor du ihn ausführst, weil es nur Dateien sind. Wenn du die vollständige Schritt-für-Schritt-Anleitung statt der Argumentation willst, deckt der Guide Wie man eine KI-generierte App lokalisiert dasselbe Setup von Anfang bis Ende ab.