Vous n'avez pas à choisir : i18next et inlang, ensemble

Si vous utilisez i18next, l'écosystème inlang vous a probablement été présenté comme une destination : migrer votre configuration, adopter un nouveau format, changer de flux de travail. Résultat : la plupart des équipes i18next n'ont jamais touché à des outils comme l'extension VS Code Sherlock, l'éditeur web Fink ou le compilateur Paraglide, même quand l'un d'eux aurait été réellement utile.

Ce « l'un ou l'autre » n'a jamais été nécessaire. Vos fichiers de traduction sont l'interface : si les outils inlang savent lire et écrire fidèlement le JSON i18next, vous pouvez utiliser les deux écosystèmes sur le même projet. Depuis cette semaine, ils le peuvent. Vérifié, réparé là où c'était cassé, et à une commande de distance :

npx i18next-cli init --inlang

Une commande, aucune migration

init --inlang (nouveau dans i18next-cli 1.63, également proposé comme question dans l'assistant init classique) génère un projet inlang prêt à l'emploi à côté de votre configuration i18next :

{
  "$schema": "https://inlang.com/schema/project-settings",
  "baseLocale": "en",
  "locales": ["en", "de", "fr", "it"],
  "modules": ["https://cdn.jsdelivr.net/npm/@inlang/plugin-i18next@6.2.1/dist/index.js"],
  "plugin.inlang.i18next": {
    "pathPattern": {
      "common": "./public/locales/{locale}/common.json",
      "app": "./public/locales/{locale}/app.json"
    }
  }
}

Tout est dérivé de ce qu'i18next-cli sait déjà : baseLocale et locales depuis votre configuration, le pathPattern depuis la structure de votre extract.output, y compris la forme par namespace, dont les noms sont découverts à partir des fichiers existants de votre langue principale. La commande ajoute aussi l'extension Sherlock aux recommandations de votre .vscode/extensions.json (fusion respectueuse des commentaires, sans rien écraser), et elle n'écrase jamais un project.inlang/settings.json existant.

L'essentiel est ce qu'elle ne fait pas : pas de conversion, pas d'export, pas de second catalogue qui commence à dériver dès sa création. Le JSON i18next de votre dépôt reste la source unique de vérité.

Ce que cela débloque

• Sherlock (VS Code) : voir et modifier les traductions en ligne, là où les clés sont utilisées, sur vos vrais fichiers.
• Fink (navigateur) : envoyez un lien à un traducteur ; ses modifications atterrissent dans le même JSON via git.
• Paraglide (compilateur) : compiler les mêmes fichiers en fonctions de message tree-shakable et entièrement typées, par exemple pour une nouvelle application SvelteKit ou SolidStart à côté de votre produit i18next existant :

npx @inlang/paraglide-js compile --project ./project.inlang

import * as m from './src/paraglide/messages.js'

m['common:friend']({ count: 1, context: 'male' }) // "A boyfriend"

Pluriels, contexte (seul et combiné aux pluriels), _zero, clés ordinales, namespaces et formatage {{count, number}} se comportent exactement comme i18next les définit. La raison pour laquelle nous pouvons l'affirmer sereinement est expliquée plus bas.

Pourquoi cela fonctionne maintenant : six bugs corrigés en quelques heures

Les promesses d'« interopérabilité » ne coûtent rien ; nous avons donc d'abord testé tout le chemin de bout en bout : du JSON i18next v4 à travers le plugin i18next d'inlang, le SDK et le compilateur Paraglide, ainsi que le chemin d'écriture retour, car des outils d'édition comme Sherlock et Fink doivent pouvoir enregistrer.

Le cœur a bien tenu, et les aspérités étaient réelles. Six bugs dans le plugin, le SDK et le compilateur : des clés de contexte résolues silencieusement vers la variante de base, des projets avec contexte impossibles à enregistrer, des projets à namespaces échouant à l'écriture, le formatage {{count, number}} silencieusement perdu, _zero qui ne correspondait jamais à count: 0, et des clés ordinales interprétées à tort comme un contexte.

La suite est la partie qui mérite d'être racontée : nous avons signalé les six avec des reproductions, et Samuel Stroschein et l'équipe inlang ont traité leur moitié en quelques heures, relu et fusionné nos correctifs du plugin tout aussi vite, puis tout publié : @inlang/plugin-i18next 6.2.0, @inlang/sdk 2.10.0, @inlang/paraglide-js 2.19.0. Le plugin est maintenu en première classe de leur côté. Cet engagement, plus cette rapidité, fait d'un pont construit dessus un pari sûr. Nous avons ensuite revérifié la matrice de test complète contre les paquets publiés : 15/15 au vert, le plugin chargé depuis le CDN exactement comme votre projet le chargera. L'équipe inlang a publié sa propre annonce de l'intégration.

Le schéma s'est répété une fois de plus pendant la rédaction de ce billet : la capture d'écran Sherlock ci-dessus a révélé un septième bug (Sherlock n'affichait silencieusement aucune annotation pour les projets i18next, et ce depuis longtemps). Signalé avec un correctif d'une ligne, fusionné et publié en plugin 6.2.1 en quelques heures. La capture montre le comportement corrigé.

Où Locize trouve sa place

Les fichiers que Sherlock et Paraglide lisent désormais sont ceux que Locize synchronise comme votre TMS hébergé :

npx i18next-cli locize-sync

La répartition des rôles reste ainsi limpide. Les développeurs travaillent dans le dépôt, avec Sherlock en ligne ou la compilation Paraglide. Les traducteurs travaillent où cela leur convient : Fink pour des modifications rapides basées sur git, Locize pour le flux complet avec étapes de relecture, traduction automatique par IA avec scores de confiance, mémoire de traduction, glossaire, gestion des versions et livraison CDN pour que les correctifs de traduction soient en ligne sans redéploiement. Un seul jeu de fichiers, et chaque outil le lit et l'écrit directement.

Détails honnêtes

• La version du plugin est épinglée volontairement. Le scaffold écrit @inlang/plugin-i18next@6.2.1, pas un @6 flottant : jsDelivr sert les alias de plage depuis des caches edge qui peuvent retarder les releases de plusieurs jours et différer selon l'emplacement. Nous avons vu @6 servir un plugin vieux de deux releases après la sortie de 6.2.0. Une URL épinglée garantit que chaque membre de l'équipe et chaque exécution CI reçoit le même plugin, celui qui a été vérifié. Montez l'URL modules dans settings.json délibérément quand de nouvelles versions sortent.
• Seul settings.json est généré, à dessein. project.inlang/ est la forme de projet unpacked (adaptée à git) d'inlang ; les outils inlang génèrent et gèrent eux-mêmes les autres fichiers (.gitignore, README.md, cache/) à la première utilisation. Attendez-vous donc à quelques nouveaux fichiers après avoir ouvert le projet avec Sherlock ou Paraglide.
• Les namespaces sont découverts au moment du scaffold. Si vous ajoutez un namespace plus tard, ajoutez sa ligne au pathPattern de settings.json ; une nouvelle exécution d'init ne touche volontairement pas un fichier existant.
• Fichiers de ressources JSON uniquement. Le plugin i18next d'inlang lit du JSON ; les structures YAML/JS sont ignorées avec un avertissement.

Pour commencer

Dans un projet doté d'une configuration i18next-cli (ou laissez l'assistant en créer une) :

npx i18next-cli init --inlang

Ouvrez le dossier dans VS Code et installez l'extension Sherlock recommandée, envoyez le lien Fink à un traducteur, ou pointez le compilateur Paraglide vers ./project.inlang. Et continuez de synchroniser exactement les mêmes fichiers avec Locize pour la partie gérée du flux. La référence complète des options se trouve dans le README d'i18next-cli, et le plugin vit sur la marketplace inlang.

Deux écosystèmes, un seul jeu de fichiers. Vous n'avez vraiment pas à choisir.