Wie füge ich einer mit Cursor gebauten Next.js-App in 15 Minuten i18n hinzu?

Du installierst eine CLI, schickst Cursor einen Prompt, und dein Next.js-Projekt wird aus reinem Englisch-JSX zu einer funktionierenden mehrsprachigen App – mit [locale]-Routing, generierten Keys und Auto-Sync bei jedem Push. globalize.now ist KI-gestützte Lokalisierungsinfrastruktur, die genau die i18n-Arbeit übernimmt, die Cursor ausgelassen hat: hartcodierte Strings extrahieren, next-intl-Keys und Übersetzungsdateien generieren und Übersetzungen bei jedem Git-Push synchron halten. Der folgende Walkthrough geht von einem Standard-App-Router-Projekt aus. Gesamtdauer auf unserem Test-Repo: 13 Minuten 40 Sekunden.

Was ist eigentlich kaputt, wenn Cursor deine Next.js-UI baut?

Cursor optimiert für funktionierende UI, nicht für Architektur. Es erzeugt Code aus natürlichsprachlichen Anweisungen und aktualisiert Codeteile über Prompts – das JSX wird so geschrieben, wie ein Mensch schnell einen Prototyp bauen würde: Text inline, keine Keys, keine Übersetzungsdateien, kein [locale]-Segment.

Eine typische von Cursor generierte Next.js-Seite sieht so aus:

// app/page.tsx
export default function Home() {
  return (
    <main>
      <h1>Welcome to Acme</h1>
      <p>Get started in seconds.</p>
      <button>Sign up</button>
    </main>
  )
}

Drei hartcodierte Strings auf einer Seite. Eine echte App hat Hunderte davon, verteilt auf Dutzende Komponenten. Der Pages Router lieferte früher eine eingebaute i18n-Konfiguration mit, die aber entfernt wurde, als der App Router zum Standard wurde — seither müssen Entwickler:innen Middleware, dynamische Route-Segmente und eine externe Bibliothek wie next-intl selbst verdrahten. Nichts im Standardverhalten von Cursor übernimmt das für dich.

Das Ergebnis ist das Muster, das wir in Warum die Übersetzungen deiner Lovable-App bei jedem Release brechen beschrieben haben: Die Codebase wächst, hartcodierte Strings häufen sich an, und aus „nächsten Monat Spanisch hinzufügen“ wird ein mehrwöchiges Refactoring.

Wie richte ich globalize.now in einem Cursor-Projekt ein?

Verbinde dein Repository auf globalize.now. Die erste Konvertierung läuft einmalig, in der App: Sie liest das Repo, ersetzt die hartcodierten Strings durch Keys und öffnet einen Pull Request zur Überprüfung. Jeder Push danach übersetzt, was neu dazugekommen ist.

Um diesen ersten Durchlauf stattdessen von Cursor aus anzustoßen, installiere die Skills vom Projekt-Root aus:

npx skills add globalize-now/globalize-skills

Die CLI erkennt deinen Stack, wählt das passende Preset für Cursor und installiert Agent-Regeln in deinem Projekt. Bei einem Next.js-16-App-Router-Projekt sieht die Ausgabe so aus:

✓ Stack detected: Next.js 16 (App Router)
✓ Editor detected: Cursor
✓ Preset selected: globalize-guide + next-intl
✓ Installed 4 skill files to .cursor/rules/
Done in 1.2s

Die Skill-Dateien liegen neben deinen bestehenden Cursor-Regeln. Sie sagen dem Cursor-Agenten, wie er String-Extraktion handhabt, wie er Keys konsistent mit next-intl-Konventionen generiert und wie er das [locale]-Route-Segment verdrahtet. Nichts verlässt deinen Rechner. Dein Code wird nicht hochgeladen.

Falls du statt Cursor Claude Code oder Codex verwendest, installiert die CLI die entsprechenden Skill-Dateien für diese Tools. Der nachgelagerte Ablauf ist identisch.

Wie extrahiert der Agent hartcodierte Strings aus einer Cursor-Codebase?

Öffne das Agent-Panel von Cursor und sende einen Prompt:

Set up i18n for this project. Use English, Spanish, German, and Arabic.

Der Agent lädt die installierten Regeln, scannt die Verzeichnisse app/ und components/ und meldet die Ergebnisse zurück. Bei einer 12-seitigen Marketing-Site sieht der Bericht typischerweise so aus:

Detected Next.js 16 with App Router.
Found 47 hardcoded strings across 12 components.
Best fit: next-intl. RTL required for Arabic.

Plan:
- Install next-intl
- Move app/* into app/[locale]/*
- Generate i18n/request.ts and middleware.ts
- Extract 47 strings to messages/en.json
- Convert JSX to useTranslations / getTranslations calls

Proceed? (y/n)

Der Agent übernimmt das, was die next-intl-Dokumentation den mühsamen Teil nennt: Middleware, dynamische Route-Segmente, Request-Konfiguration und die Konvertierung Komponente für Komponente auf Translation-Hooks. Du prüfst den Plan und bestätigst ihn. Der Agent setzt die Änderungen als einen einzigen Multi-File-Edit um, den du in Cursors Diff-Ansicht annehmen oder ablehnen kannst.

Wie generiert er next-intl-Keys und Übersetzungsdateien?

Nachdem du den Plan freigegeben hast, generiert der Agent das Standard-next-intl-Layout. Das Repo erhält vier neue Dinge:

i18n/
  request.ts
  routing.ts
middleware.ts
messages/
  en.json
  es.json
  de.json
  ar.json
app/
  [locale]/
    layout.tsx
    page.tsx
    ...

Innerhalb von messages/en.json werden die 47 extrahierten Strings zu namespacebasierten Keys, gruppiert nach Komponente oder Route:

{
  "Home": {
    "heading": "Welcome to Acme",
    "lede": "Get started in seconds.",
    "signupCta": "Sign up"
  }
}

Die ursprüngliche page.tsx wird so umgeschrieben, dass sie useTranslations für Client-Komponenten und getTranslations für Server-Komponenten verwendet. Die Aufteilung erfolgt automatisch. Der Agent liest, welche Komponenten die "use client"-Direktive haben, und wählt den passenden Hook.

Die JSON-Dateien für Spanisch, Deutsch und Arabisch werden mit ersten Übersetzungsentwürfen generiert, die ein Glossar respektieren, das der Agent aus deinen Komponenten- und Prop-Namen aufbaut. Markenbegriffe bleiben auf Englisch. RTL-Handling ist ins Layout eingebaut: Das dir-Attribut wird anhand der Locale gesetzt, und CSS Logical Properties ersetzen feste Links/Rechts-Utilities dort, wo der Agent sie erkennen kann.

Das ist dasselbe End-to-End-Muster, das wir bei einem Produktions-Monorepo in Was passiert, wenn ein KI-Agent ein echtes Monorepo internationalisiert? durchgeführt haben. Das Walkthrough-Format ist dasselbe, nur die Inputs unterscheiden sich.

Wie funktioniert die Git-Push-Synchronisation nach dem ersten Durchlauf?

Der erste Durchlauf ist einmalig. Die Synchronisation läuft für immer.

Sobald der Agent fertig ist, verbindest du das Repo im Dashboard mit globalize.now. Ab diesem Zeitpunkt:

Push to main
   ↓
globalize.now diffs against last synced state
   ↓
New hardcoded strings get extracted + keyed
   ↓
Translations generated for every configured locale
   ↓
PR opened with locale file updates

Cursor muss nicht geöffnet sein. Claude Code muss nicht laufen. Die Synchronisation passiert auf Git-Ebene – sie funktioniert unabhängig davon, welches Tool die nächste UI-Charge geschrieben hat. Wenn Cursor nächste Woche eine Komponente neu generiert und drei neue Buttons hinzufügt, landen diese Buttons übersetzt im nächsten PR.

Kein manueller Export. Keine Review-Queue. Kein CSV-Hin-und-her. Das Produktversprechen ist dasselbe, das wir in So globalisierst du deine App mit globalize.now dokumentiert haben: einmal einrichten, bei jedem Push automatisch synchronisieren.

Was, wenn du schon ein handgeschriebenes next-intl-Setup hast?

Der Agent liest es zuerst.

Falls i18n/request.ts bereits existiert, übernimmt der Agent deine Konfiguration, statt sie zu überschreiben. Falls messages/en.json bereits Pricing.heading enthält, verwendet der Agent diesen Key erneut, statt einen neuen zu generieren. Falls deine Namespace-Konvention pricing.heading (kleingeschrieben, mit Punkten) statt Pricing.heading (PascalCase, verschachtelt) ist, passt sich der Agent daran an.

Das Einzige, was der Agent verweigert, ist das stillschweigende Überschreiben einer bestehenden Übersetzungsdatei. Kommt es zu einer Key-Kollision, stoppt er und fragt nach. Dieses Verhalten ist in den von npx skills add globalize-now/globalize-skills installierten Skill-Regeln festgelegt – nichts, was du konfigurieren musst.

globalize.now übernimmt das für dich. Verbinde dein Next.js-Repository, die Konvertierung läuft einmalig in der App; die npx skills add globalize-now/globalize-skills-Skills decken die Arbeit ab, die danach in deinem Editor folgt. Schau dir an, wie es funktioniert, auf globalize.now.