L'i18n sans fichiers de traduction ? C'est possible avec i18next, dès aujourd'hui

« Les fichiers de traduction sont le problème. » C'est un argumentaire populaire en 2026 : vos composants sont la source de vérité, alors cessez de maintenir à la main du JSON par langue, laissez l'outillage générer les traductions, et considérez les fichiers de locale comme des artefacts de build. Toute une nouvelle vague d'outils i18n repose sur cet argument.

Le diagnostic est en partie juste. Éditer dix-sept fichiers JSON à la main pour ajouter une phrase n'amuse personne. Ce que l'argumentaire omet le plus souvent : l'écosystème i18next prend en charge exactement ce workflow depuis des années, avec de simples bibliothèques open source, et il peut même aller un cran plus loin, car avec la livraison CDN il n'y a aucun fichier de traduction dans votre dépôt, pas même généré. Voici la recette, suivie des compromis honnêtes.

Étape 1 : le code devient la source de vérité

Deux lignes de configuration transforment i18next en système à clés en langage naturel :

i18next.init({
  keySeparator: false,
  nsSeparator: false
})

Désormais, le texte anglais est la clé :

t('Add to cart')

Aucune entrée en.json derrière. Quand aucune traduction n'existe, i18next retombe sur la clé, et la clé est le texte source : l'application s'affiche correctement dès la première seconde. Le texte riche fonctionne de la même façon via le composant Trans, qui sérialise ses enfants JSX, balisage compris, dans la clé :

<Trans>Hello <strong>{{name}}</strong>, you have {{count}} unread messages.</Trans>

Les traducteurs voient Hello <1>{{name}}</1>, you have {{count}} unread messages. et réordonnent librement le balisage par langue ; vos composants restent propriétaires des vraies balises. Les suffixes de pluriel et de contexte continuent de fonctionner sur des clés naturelles, car ce sont des décorations de clé, pas des fichiers séparés.

Étape 2 : les nouvelles chaînes se signalent elles-mêmes

C'est la pièce qui remplace « maintenir les fichiers » : saveMissing. Avec saveMissing: true et i18next-locize-backend, chaque chaîne rendue pour la première fois par votre application est signalée automatiquement à Locize, généralement limité au développement pour que la production reste en lecture seule :

i18next.init({
  saveMissing: process.env.NODE_ENV === 'development'
})

Côté Locize, la traduction automatique prend chaque nouvelle chaîne source et remplit toutes les langues cibles, sur votre propre clé OpenAI, Gemini, Mistral ou DeepL si vous en apportez une, avec votre glossaire et votre guide de style injectés dans chaque requête. La Quality Estimation note chaque résultat de 0 à 1 : les traductions sûres sont enregistrées directement, les douteuses partent en relecture.

Vous écrivez t('Your trial ends tomorrow'), vous rechargez la page, et la chaîne existe dans toutes les langues, notée, quelques secondes plus tard. Personne n'a ouvert de fichier JSON.

Étape 3 : livrer sans fichiers (ou avec, générés)

À l'exécution, le même backend charge les traductions depuis le CDN Locize. Autrement dit, la version la plus forte de « les fichiers de traduction sont des artefacts de build » existe ici aussi, et mieux : il n'y a aucun fichier de locale dans votre dépôt. Une correction publiée dans l'éditeur est en ligne sans commit, sans build, sans redéploiement.

Vous préférez un pipeline statique, ou il vous faut des fichiers pour le SSR/SSG ? Prenez la voie CI : i18next-cli extrait les mêmes chaînes statiquement (il comprend les portées de t() et sérialise les enfants de Trans exactement comme react-i18next), et la GitHub Action locize/translate, gratuite, exécute extraction, synchronisation, traduction automatique et téléchargement à chaque push. Les fichiers téléchargés sont des artefacts générés : committez-les, ou ignorez-les dans git et téléchargez-les au build. Votre application n'est pas encore instrumentée ? npx i18next-cli localize la fait passer des chaînes en dur à localisée en une commande, et npx i18next-cli localize --print-agent-prompt imprime le même déroulé comme runbook pour votre agent de codage IA.

Les compromis honnêtes

Les clés en langage naturel sont un échange, pas une amélioration gratuite, et il faut savoir ce qu'on paie. (Pour le cadre de décision complet sur les stratégies de clés, y compris quand le content-as-key est le bon choix et quand il ne l'est pas, voir notre guide du nommage des clés i18n.)

• Modifier le texte re-clé la chaîne. Passez de « Add to cart » à « Add to basket » et c'est une nouvelle clé : retraduite, pendant que l'ancienne est supprimée à la synchronisation suivante. La mémoire de traduction amortit cela, les traductions relues reviennent comme correspondances à score élevé, mais pour les textes qui tournent chaque semaine, les clés stables avec defaultValue restent le meilleur outil. i18next permet de mélanger les deux styles dans le même projet ; beaucoup d'équipes utilisent des clés naturelles pour l'UI stable et des clés stables pour le marketing.
• Un texte long fait une clé longue. Trois paragraphes de mentions légales comme clé, c'est pénible dans tout outil qui affiche les clés. Donnez à ces chaînes une clé stable et un defaultValue.
• L'ambiguïté demande du contexte. L'anglais « Open », verbe ou adjectif, peut demander deux traductions. La fonctionnalité de contexte d'i18next (t('Open', { context: 'button' })) couvre le cas, mais encore faut-il remarquer l'ambiguïté ; un workflow centré sur les fichiers ne vous en protège pas davantage.

Ce que « zéro fichier » ne résout pas

Supprimer la maintenance des fichiers supprime une corvée. Cela ne supprime pas les vrais problèmes difficiles de la localisation, et c'est là que l'argumentaire « votre code est la source de vérité » s'arrête discrètement : la terminologie qui ne doit pas dériver, le registre qui ne doit pas basculer au milieu de l'application, les chaînes juridiques qui exigent des yeux humains, et la question « qui a approuvé cette traduction ? », à laquelle un pipeline de sortie bot non relue répond par un hash de commit. Nous avons documenté ce qui casse vraiment dans les pipelines IA seuls, et aucun des modes de défaillance ne concerne un format de fichier.

C'est la vraie différence entre les workflows, fichiers ou pas : la sortie traduite atterrit-elle dans une couche gouvernée, avec cohérence imposée par glossaire, scores de qualité, relecture humaine sélective et historique d'audit, ou directement en production ? Une entrée sans clés plus une sortie non gouvernée, c'est juste de la dérive plus rapide.

Testez toute la boucle en un après-midi

Configurez les clés en langage naturel et saveMissing dans une branche, créez un projet Locize gratuit, activez la traduction automatique, et regardez les nouvelles chaînes apparaître traduites et notées pendant que vous parcourez votre application. Si vous exploitez déjà un pipeline IA en CI et vous demandez dans quel état sont vos fichiers de locale, le bilan de santé i18n gratuit s'exécute entièrement dans votre navigateur et montre clés manquantes, doublons et incohérences d'interpolation avant que vous ne changiez quoi que ce soit.

Les fichiers de traduction n'ont jamais été l'essentiel. Des traductions fiables en production, si, que les fichiers existent ou non.