React & Next.js Lokalisierung
Organisieren Sie i18next-Übersetzungen in Namespaces – eine JSON-Datei pro Funktionsbereich anstatt einer großen Datei pro Sprachvariante. Eine typische Struktur hat einen common-Namespace für gemeinsame UI-Beschriftungen, separate Namespaces für Authentifizierung, Checkout und Dashboard sowie einen Namespace pro Seitenroute. Laden Sie Namespaces mit dem i18next-Backend-Plugin lazy, sodass jede Route nur die benötigten Zeichenketten lädt und die anfängliche Bundle-Größe klein bleibt. Dies erleichtert auch die Zuweisung von Übersetzungsarbeit nach Funktionsbereich, ohne dass Übersetzer nicht verwandte Zeichenketten berühren.
Benennen Sie Übersetzungsschlüssel semantisch: button.submit ist stabiler als submit_button_label_text und übersteht eine Textänderung, ohne dass ein Schlüssel umbenannt und der Code aktualisiert werden muss. Vermeiden Sie die dynamische Konstruktion von Schlüsseln zur Laufzeit – dynamische Schlüsselkonstruktion unterbricht statische Analysetools, die nach unübersetzten Zeichenketten suchen, und verhindert, dass Language Monster neue Inhalte zuverlässig erkennt. Verwenden Sie in React die Trans-Komponente für Zeichenketten, die JSX-Elemente wie Links oder fettgedruckte Spans einbetten – teilen Sie einen Satz niemals auf mehrere Schlüssel auf, nur um ein Inline-Element einzufügen.
Konfigurieren Sie in Next.js i18n in next.config.js mit Ihrer vollständigen Locale-Liste, defaultLocale, und erwägen Sie, localeDetection zu deaktivieren, wenn Sie die Erkennung in Middleware verwalten. Verwenden Sie next-i18next für server-gerenderte Seiten – es lädt über getServerSideProps oder getStaticProps nur die Namespaces, die jede Seite benötigt, und vermeidet so das vollständige Locale-Bundle bei jeder Anfrage. Folgen Sie für den App Router dem parallelen Routengruppen-Muster pro Locale, um die SSR-Locale-Auflösung sauber zu halten.
Verbinden Sie Ihr GitHub-, Bitbucket- oder Azure-Repos-Repository mit Language Monster. Language Monster erkennt Ihre Locale-Dateistruktur automatisch, ordnet Schlüssel in allen Sprachdateien zu und überträgt fertige Übersetzungen in einen Branch für Ihren Standard-Pull-Request-Review – sodass die Übersetzung in Ihrer bestehenden Code-Review-Pipeline bleibt. Verschachtelte JSON-Struktur, Interpolationsplatzhalter und i18next-Pluralschlüssel-Suffixe bleiben durch jeden Übersetzungsauftrag erhalten.
Führen Sie eslint-plugin-i18next in Ihrer CI-Pipeline aus, um hartcodierte Zeichenketten zu erkennen, die nicht in Übersetzungsschlüssel extrahiert wurden. Die Qualitätskontrollen von Language Monster prüfen Platzhalterintegrität, Rechtschreibung, Grammatik und Zahlenformatierung für jede gespeicherte Zeichenkette – Fehler werden zum Übersetzungszeitpunkt und nicht erst beim Code-Review abgefangen. Translation Memory bedeutet, dass identische Zeichenketten in Namespaces abgeglichen und ohne Mehrkosten angewendet werden.