Comment traduire les fichiers JSON i18next dans React et Next.js (2026)

Vous venez de terminer une application React qui doit être livrée en 12 langues d'ici vendredi prochain. Vos fichiers de locale se trouvent dans public/locales/en/common.json, vous avez 340 clés par locale, et les jetons dans vos chaînes ressemblent à {{userName}} et {{count}} éparpillés dans des objets imbriqués. Vous collez le JSON dans ChatGPT, et il vous renvoie {{ nombreUsuario }}, des espaces supplémentaires et la moitié des clés de pluralisation renommées. Votre application plante à la compilation.

Si vous avez déjà essayé d'automatiser la traduction JSON i18next, vous connaissez cette douleur. Le format JSON est flexible, et c'est précisément pourquoi la plupart des outils de traduction le corrompent. Le vrai problème n'est pas la qualité du modèle linguistique - c'est que les outils d'IA grand public ne comprennent pas les règles structurelles d'i18next.

Ce guide explique ce qui rend le JSON i18next différent des autres formats de locale, pourquoi les approches de traduction naïves cassent les applications React et Next.js, et comment automatiser la traduction en toute sécurité sur des dizaines de locales sans avoir à réviser chaque clé manuellement.

Qu'est-ce que le JSON i18next et pourquoi sa traduction est délicate

i18next est la bibliothèque d'i18n la plus utilisée dans l'écosystème JavaScript. Elle alimente React (react-i18next), Next.js (next-i18next, App Router next-intl), Vue et les services backend Node. Elle stocke les chaînes traduisibles dans des fichiers JSON plats ou imbriqués, un par locale.

Un fichier typique ressemble à ceci :

{
  "welcome": "Welcome, {{userName}}!",
  "cart": {
    "empty": "Your cart is empty",
    "items_one": "{{count}} item in your cart",
    "items_other": "{{count}} items in your cart"
  },
  "errors": {
    "network": "Network error. <strong>Please retry</strong>."
  }
}

Cela semble simple, mais trois éléments le rendent dangereux à traduire avec une IA à usage général.

Les jetons d'interpolation sont structurels, pas du texte

La séquence {{userName}} n'est pas un mot - c'est un espace réservé que le runtime remplace par des données. Ajoutez un espace ({{ userName }}), renommez-le, ou traduisez l'identifiant interne et le runtime échouera silencieusement ou générera une erreur. Certains traducteurs convertissent utilement {{count}} en {{conteo}} en espagnol. Votre application tente alors d'interpoler une variable qui n'existe pas et affiche l'espace réservé brut à votre utilisateur.

Les clés de pluralisation sont des suffixes magiques

i18next détecte les pluriels par des suffixes : _zero, _one, _two, _few, _many, _other. Ce ne sont pas des chaînes arbitraires - elles doivent correspondre aux catégories de pluriel CLDR pour la locale cible. L'anglais n'utilise que _one et _other. Le russe, l'arabe et le polonais utilisent jusqu'à six catégories. Si votre traducteur supprime _other ou le renomme, la chaîne de secours est rompue.

Les clés imbriquées doivent rester intactes

Contrairement aux fichiers .po de Gettext, qui sont des paires clé-valeur plates, les fichiers i18next peuvent être imbriqués de manière arbitraire. Un traducteur paresseux pourrait aplatir la structure, modifier les noms des clés pour qu'ils correspondent au texte traduit, ou réorganiser les objets. Votre appel t('cart.items_other') dans le code ne se résout plus.

Mauvaises solutions que les développeurs essaient en premier

Chaque équipe passe par le même cycle d'échecs en trois étapes avant d'investir dans une véritable solution.

Étape un : Coller dans ChatGPT

Vous copiez 200 clés dans ChatGPT, demandez « traduire ce JSON en espagnol » et collez le résultat. Cela fonctionne pour 180 clés. Vingt ont des espaces ajoutés à l'intérieur de {{...}}, trois ont des suffixes de pluriel réécrits, et une balise <strong> a été traduite par <fuerte>. Votre build échoue ou envoie silencieusement des chaînes de caractères cassées en production.

Étape deux : API Google Translate

Vous connectez l'API REST de Google Translate, itérez sur votre JSON et envoyez chaque valeur. La vitesse est excellente. La qualité, non. L'API de Google traite chaque chaîne de caractères isolément - aucun contexte sur votre application, aucune compréhension que {{count}} est un espace réservé, aucune conscience que la clé cart.empty est différente de cart.items_one. Vous avez toujours besoin d'une révision humaine pour chaque clé.

Étape trois : Plateformes TMS commerciales

Vous vous inscrivez à un système de gestion de traduction. Ils facturent au mot, exigent des intégrations GitHub et vous lient à des licences mensuelles. Pour un projet personnel ou une application indépendante, l'économie s'effondre rapidement - et vous rencontrez toujours les mêmes problèmes de corruption d'espaces réservés si leur moteur ne pars pas spécifiquement le format i18next.

Les mêmes modes d'échec apparaissent également dans les workflows Gettext. Notre guide sur comment traduire des fichiers .po sans casser les variables de code couvre le problème parallèle pour WordPress et les autres piles basées sur Gettext.

L'approche sûre : la traduction consciente de la syntaxe

La seule façon fiable de traduire du JSON i18next à grande échelle est d'utiliser un outil qui analyse d'abord le format, verrouille la syntaxe et n'envoie que le texte traduisible à l'IA.

Voici ce que fait le traitement conscient de la syntaxe en coulisses :

1. Analyse le JSON en un arbre abstrait, préservant les chemins de clés et l'imbrication.
2. Identifie les jetons d'interpolation ({{name}}, {{count, number}}, {{date, datetime}}) et les remplace par des identifiants d'espace réservé.
3. Identifie les balises HTML à l'intérieur des composants Trans (<0>, <strong>, <br/>) et les verrouille.
4. Détecte les clés de pluriel par suffixe et les mappe aux règles CLDR de la locale cible.
5. Envoie uniquement le texte nettoyé au LLM avec le contexte du chemin de la clé.
6. Réinsère les jetons et balises originaux à leurs positions exactes.
7. Valide la sortie - si un espace réservé est manquant ou mal formé, revient à la source.

C'est le même principe qui rend sûre la traduction PO basée sur le cloud. Si l'architecture sous-jacente vous intéresse, notre comparaison de la qualité de traduction par IA détaille comment différents LLM gèrent ces contraintes.

Étape par étape : traduire le JSON i18next avec SimplePoTranslate

SimplePoTranslate prend en charge le JSON i18next nativement avec les forfaits Pro et Lifetime. Le niveau gratuit couvre actuellement les fichiers .po et .pot - mettez à niveau ou utilisez un essai pour accéder au JSON.

1. Préparez votre fichier source

Utilisez votre fichier anglais (ou de locale source) comme maître. Assurez-vous qu'il s'agit d'un JSON valide et qu'il contient toutes les clés utilisées par votre application. Une erreur courante est de laisser des clés obsolètes ou inutilisées, ce qui consomme votre quota de traduction pour des chaînes que vous ne rendrez jamais.

# From your project root
cp public/locales/en/common.json ~/Desktop/common.json

2. Téléchargez sur SimplePoTranslate

Connectez-vous à votre tableau de bord, cliquez sur Nouvelle traduction et téléchargez common.json. La plateforme détecte automatiquement le format i18next. Choisissez votre langue cible parmi les 41 locales prises en charge, sélectionnez un ton (professionnel, décontracté, marketing) et soumettez.

3. Laissez le moteur travailler

En coulisses, le fichier est analysé, divisé en lots sécurisés et traduit en parallèle. Les jetons d'interpolation sont verrouillés. Les suffixes de pluriel sont préservés et mappés aux règles CLDR de la locale cible. Le HTML à l'intérieur des composants Trans reste intact.

4. Téléchargez le ZIP

Vous recevez un ZIP contenant le JSON traduit ainsi que des formats alternatifs (.php pour les applications PHP, .po pour la compatibilité inter-outils). Déposez le JSON dans public/locales/es/common.json et redéployez.

unzip common_es.zip
mv common.json public/locales/es/common.json
npm run build

5. Répéter ou Traiter par lots

Pour les 12 locales cibles, soumettez 12 tâches. Les quotas du forfait Pro couvrent des dizaines d'applications SaaS typiques. Pour les monorepos avec plusieurs fichiers de namespace, téléchargez-les séparément ou traitez-les par lots séquentiellement.

Intégrer les traductions dans votre application

Une fois que vous avez des fichiers JSON traduits, l'intégration est la partie facile. Quelques pièges :

• Vérifiez les catégories de pluriel. Effectuez un rapide test de fumée par locale : affichez un composant avec count={0}, count={1}, count={5} et confirmez que les trois produisent la bonne chaîne.
• Vérifiez les locales RTL. Si vous avez traduit en arabe, hébreu ou persan, votre UI nécessite un CSS prenant en charge le RTL. Notre guide de traduction RTL WordPress couvre les modèles CSS qui s'appliquent également aux applications React.
• Mettez en place une chaîne de secours. Configurez i18next pour qu'il revienne à l'anglais si une clé est manquante, afin que les états intermédiaires de déploiement ne fassent pas planter les utilisateurs.
• Verrouillez votre fichier source en CI. Ajoutez une vérification qui rejette les PR où en/common.json change sans régénérer les autres locales. La dérive de traduction est la principale cause de bugs d'i18n en production.

Pour les équipes déployant sur React, Next.js et le côté serveur, produire tous les formats à partir d'une seule source est un énorme avantage. Notre article sur un fichier en entrée, cinq formats en sortie explique pourquoi la sortie multi-format est importante pour la maintenance à long terme.

Quand le JSON ne suffit pas : gérer les cas complexes

Quelques cas limites nécessitent une attention particulière.

Format de message ICU

Si votre projet utilise la syntaxe ICU ({count, plural, one {1 item} other {# items}}), i18next la traite comme une interpolation, mais la structure est plus complexe. Assurez-vous que votre outil de traduction reconnaît les paramètres ICU et ne traduit pas les noms de catégories comme one, other, ou les identifiants de format comme plural, number, date.

Composant Trans avec des nœuds React

<Trans> rend des composants React à l'intérieur de chaînes traduites, indexés par (<0>, <1>). Le traducteur doit préserver l'ordre exact des balises. Le verrouillage de syntaxe de SimplePoTranslate gère cela, mais si vous utilisez un autre outil, vérifiez avant de livrer.

Fichiers de namespace

Les grandes applications divisent les locales en namespaces : common.json, dashboard.json, checkout.json. Traduisez chaque fichier indépendamment - ne les fusionnez pas. La qualité du contexte est meilleure lorsque les chemins de clés de chaque namespace restent délimités.

En résumé

Traduire le JSON i18next pour une application React ou Next.js ne consiste pas à choisir le meilleur modèle d'IA. Il s'agit de respecter les règles structurelles du format : les interpolations, les suffixes de pluriel, les clés imbriquées et les balises HTML doivent survivre à l'aller-retour. Les outils d'IA grand public traitent le JSON comme du texte non structuré. Les outils conscients de la syntaxe l'analysent comme des données structurées et ne touchent que les surfaces traduisibles.

Si vous déployez une application multilingue et que vous avez copié-collé du JSON dans des interfaces de chat, vous connaissez déjà le coût : des heures de révision manuelle par locale, des bugs de production aléatoires et une pile croissante de formes plurielles cassées. Un pipeline conscient du format élimine chacun de ces modes d'échec.

Prêt à traduire vos fichiers JSON i18next en toute sécurité ? Essayez SimplePoTranslate gratuitement - aucune carte de crédit requise. Téléchargez une fois, livrez en 41 langues.