Wie fügst du i18n zu einer mit GitHub Copilot gebauten App hinzu?

Füge eine Runtime-i18n-Bibliothek hinzu, konvertiere dann die Strings, die Copilot bereits geschrieben hat, und halte anschließend neue davon fern. Den letzten Schritt bekommen die meisten Teams falsch hin, denn eine Repository-Instructions-Datei erreicht nicht jede Oberfläche, aus der Copilot Code schreibt. Chat und der Coding Agent lesen sie. Inline-Autocomplete nicht. globalize.now ist KI-gestützte Lokalisierungsinfrastruktur, die die Codebase einmalig konvertiert und die Schlüssel sowie Übersetzungsdateien erzeugt, die deine i18n-Bibliothek liest.

Warum hartcodiert Copilot immer noch Strings, nachdem ich eine Instructions-Datei hinzugefügt habe?

Weil die Instructions-Datei nicht in den schnellsten Pfad eingebunden ist. Die Dokumentation von VS Code stellt klar, dass Custom Instructions bei den Inline-Vorschlägen, die du beim Tippen erhältst, nicht berücksichtigt werden. Das ist der Modus, in dem die meisten Menschen den Großteil ihres Tages verbringen.

Die Regel, die du geschrieben hast, ist also real und greift, wenn du Copilot im Chat eine Frage stellst oder dem Coding Agent eine Aufgabe übergibst. Sie greift nicht, wenn du ein JSX-Tag tippst und bei einer ausgegrauten Vervollständigung Tab drückst. Beide Wege erzeugen committeten Code. Nur einer davon hat deine Regel gelesen.

Welche Copilot-Oberflächen lesen deine Instructions?

Drei Oberflächen schreiben Code in dein Repository, und sie verhalten sich nicht gleich.

Der Coding Agent ist von den dreien der freundlichste für dieses Problem. Du weist ihm ein Issue zu, er arbeitet im Hintergrund und öffnet einen Entwurfs-Pull-Request, sodass seine Ausgabe dort ankommt, wo ohnehin schon jemand hinschaut. Inline-Vervollständigungen kommen völlig ohne Kontrolle an.

Wie richtest du i18n in einem Copilot-Projekt ein?

Wähle zuerst die Runtime-Bibliothek, die zu deinem Framework passt. next-intl für den Next.js App Router, react-i18next für jede andere React-App, Lingui, wenn du Compile-Time-Extraktion und PO-Kataloge willst. Wir haben die drei in next-intl vs react-i18next vs Lingui verglichen.

Copilot ist nicht so framework-spezifisch wie Lovable oder Bolt – die Stack-Frage ist also wirklich offen, und die Wahl der Bibliothek liegt bei dir. Nicht offen ist die Reihenfolge. Installiere die Bibliothek, konvertiere die bereits vorhandenen Strings, und kümmere dich erst danach um Prävention. Eine Präventionsregel für eine Codebase, die noch zu 90 Prozent hartcodiertes Englisch enthält, liefert dir nichts, was du messen könntest.

Was gehört in .github/copilot-instructions.md?

Eine Repository-Instructions-Datei an diesem Pfad wird automatisch erkannt und auf Chat-Anfragen im Workspace angewendet. GitHubs eigene Empfehlung lautet, jede Instruction kurz und in sich abgeschlossen zu halten, die Begründung zu erklären und alles wegzulassen, was ein Linter ohnehin schon durchsetzt. Ein i18n-Abschnitt, der dieser Empfehlung folgt, ist klein:

## User-facing text

- User-facing text belongs in the message catalog, never in a component literal.
- Use the translation function from our i18n library for every visible string.
- Reason: a literal cannot be translated and does not show up as a missing key,
  so it ships silently in one language.
- Add new English values to the source catalog only. Never hand-edit other locales.
- Not user-facing: test names, log lines, error codes, internal constants.

Die letzte Zeile ist wichtiger, als es scheint. Regeln, die zu breit angewendet werden, werden ignoriert, und eine Regel, die einem Agent sagt, Log-Meldungen einzupacken, bringt ihm bei, dass der ganze Abschnitt Rauschen ist. Falls du noch gar keine Instructions-Datei hast, kann VS Code über den init-Befehl im Chat einen Entwurf aus deiner Codebase erstellen – ein besserer Startpunkt als eine leere Datei.

Kann eine pfadspezifische Instructions-Datei besser sein?

Ja, und das ist der eine Hebel, den Copilot hat, den Editor-Regeldateien anderswo nicht bieten. Dateien mit der Endung .instructions.md, abgelegt unter .github/instructions, tragen ein applyTo-Glob-Muster im Frontmatter und werden nur geladen, wenn der Agent eine passende Datei anfasst.

---
name: 'UI strings'
description: 'String handling rules for components'
applyTo: '**/*.{jsx,tsx}'
---
Every visible string in this file must come from the catalog.
Key format is feature.element.state, lowerCamelCase.
If you add a key here, add its English value to the source catalog in the same change.

Die Regel auf Komponenten-Dateien zu begrenzen, ist genau das, was sie glaubwürdig hält. Sie greift dort, wo nutzerseitiger Text lebt, und bleibt still in deinen API-Routen und Migrationsskripten. Wenn du bereits eine AGENTS.md oder eine CLAUDE.md im Repository-Root pflegst, liest Copilot diese ebenfalls als dauerhaft aktive Instructions – ein Team mit mehreren Agents braucht also keine separate Datei pro Tool.

Was fängt die Strings ab, die Instructions übersehen?

Eine Lint-Regel in der CI, denn das ist die einzige Ebene in diesem Stack, die einen Build tatsächlich fehlschlagen lässt. Instructions verändern die Wahrscheinlichkeit; ein fehlgeschlagener Check verändert das Ergebnis. Wir haben diese Durchsetzungsebene ausführlich in warum KI-Agents immer wieder hartcodierte Strings hinzufügen behandelt, und das Setup lässt sich unverändert auf ein Copilot-Repository übertragen.

Die Copilot-spezifische Ergänzung ist der Pull Request. Repository-Instructions gelten auch für Copilot Code Review, nicht nur für den Chat – dieselbe Datei, die die Generierung prägt, prägt also auch die Review-Kommentare zum Entwurfs-PR des Coding Agents. Das gibt dir eine Kontrollstelle, an der Inline-Autocomplete nicht vorbeikommt – das kommt einer Lösung für die eingangs beschriebene Lücke am nächsten.

Nichts davon tilgt die bereits im Repository vorhandenen Altlasten, und nichts davon füllt eine Übersetzungsdatei. Wenn im Review ein Literal auffällt, weißt du nur, dass ein String fehlt. Jemand muss ihn trotzdem verschlüsseln, übersetzen und dafür sorgen, dass die anderen Locales nicht aus der Synchronisation geraten.

Wo setzt globalize.now an?

Auf der Ebene, die den Katalog erzeugt – genau der Teil, den weder deine i18n-Bibliothek noch deine Instructions-Datei übernehmen. Du verbindest das Repository in der App, und es konvertiert die Codebase einmalig, ersetzt hartcodierte Strings durch Schlüssel und generiert die Übersetzungsdateien. Nach dieser einmaligen Konvertierung übersetzen Push-Jobs die neuen Katalog-Einträge, die deine Commits einbringen.

Die Ausgabe erfolgt als JSON oder PO, sodass die Kataloge genau in der Form ankommen, die deine Runtime-Bibliothek ohnehin liest. Derselbe Ansatz deckt die anderen agentischen Editoren ab: Claude Code und Cursor stoßen aus einer anderen Richtung auf dieselbe Wand, und es gibt eine Schritt-für-Schritt-Anleitung für eine Next.js-Codebase unter i18n zu einer KI-gebauten Next.js-App hinzufügen. Die Developer Docs behandeln die Konvertierung ausführlicher, und die Pläne findest du auf der Pricing-Seite.

Die Kurzfassung

Schreib die Instructions-Datei, begrenze eine pfadspezifische Regel auf deine Komponenten-Dateien und richte eine Lint-Regel in der CI ein, damit die Lücke zwischen dem, was Copilot gesagt wurde, und dem, was Copilot getippt hat, zu einem roten Build wird statt zu einem ausgelieferten englischen String. Konvertiere dann den Rückstand einmalig, damit die Regel etwas Konsistentes hat, das sie schützen kann.