Localisation React & Next.js
Organisez les traductions i18next en espaces de noms — un fichier JSON par domaine fonctionnel plutôt qu'un fichier volumineux par locale. Une structure typique comprend un espace de noms commun pour les libellés d'interface partagés, des espaces de noms séparés pour l'authentification, la caisse et le tableau de bord, et un espace de noms par route de page. Chargez les espaces de noms de manière différée à l'aide du plugin backend i18next afin que chaque route ne charge que les chaînes dont elle a besoin, ce qui réduit la taille initiale du bundle. Cela facilite également l'attribution des tâches de traduction par domaine fonctionnel sans que les traducteurs ne touchent à des chaînes non pertinentes.
Nommez les clés de traduction de manière sémantique : button.submit est plus stable que submit_button_label_text et survit à un changement de texte sans nécessiter de renommage de clé ni de mise à jour du code. Évitez de construire des clés dynamiquement à l'exécution — la construction de clés dynamiques brise les outils d'analyse statique qui analysent les chaînes non traduites et empêche Language Monster de détecter de manière fiable le nouveau contenu. Dans React, utilisez le composant Trans pour les chaînes qui intègrent des éléments JSX tels que des liens ou des balises bold — ne divisez jamais une phrase en plusieurs clés juste pour insérer un élément inline.
Dans Next.js, configurez i18n dans next.config.js avec votre liste complète de locales, defaultLocale, et envisagez de désactiver localeDetection si vous gérez la détection dans le middleware. Utilisez next-i18next pour les pages rendues côté serveur — il charge uniquement les espaces de noms dont chaque page a besoin via getServerSideProps ou getStaticProps, évitant le bundle complet de la locale à chaque requête. Pour l'App Router, suivez le modèle de groupes de routes parallèles par locale pour maintenir une résolution de locale SSR propre.
Connectez votre dépôt GitHub, Bitbucket ou Azure Repos à Language Monster. Language Monster détecte automatiquement la structure de vos fichiers de locale, mappe les clés sur tous les fichiers de langue et repousse les traductions complètes vers une branche pour votre revue de pull request standard — en gardant la traduction dans votre pipeline de révision de code existant. La structure JSON imbriquée, les espaces réservés d'interpolation et les suffixes de clés plurielles i18next sont préservés à travers chaque travail de traduction.
Exécutez eslint-plugin-i18next dans votre pipeline CI pour détecter les chaînes codées en dur qui n'ont pas été extraites vers des clés de traduction. Les contrôles qualité de Language Monster vérifient l'intégrité des espaces réservés, l'orthographe, la grammaire et le formatage des nombres sur chaque chaîne enregistrée — les erreurs sont détectées au moment de la traduction plutôt que lors de la révision du code. La Translation Memory signifie que les chaînes identiques entre les espaces de noms sont correspondues et appliquées sans coût de retraduction.
En savoir plus i18suivant V4 (json)