Où peut-on trouver des tutoriels JavaScript i18n, et que fait i18next-scanner?
Les meilleurs tutoriels JavaScript sur l'internationalisation (i18n) se trouvent directement dans la documentation de la bibliothèque — celle d'i18next.com. Des guides propres, ainsi que des documentations spécifiques aux frameworks react-i18next, vue-i18n et next-intl — car aucun cours tiers ne couvre l'intégration de tous les frameworks. i18next-scanner est un outil en ligne de commande distinct et open source qui analyse les fichiers sources JavaScript, JSX et TypeScript à la recherche d'appels de fonctions de traduction et extrait automatiquement les clés dans des fichiers JSON de localisation, remplaçant ainsi la pratique sujette aux erreurs qui consiste à modifier manuellement ces fichiers à mesure qu'une application se développe.
Dernière révision : 17 septembre 2026
Pourquoi le matériel d’apprentissage JavaScript i18n semble-t-il si dispersé?
- La documentation de la bibliothèque et les outils d'extraction se trouvent à des endroits différents. i18next.com La documentation explique les hooks, l'initialisation et la pluralisation, mais i18next-scanner est un projet open-source distinct, maintenu sous son propre dépôt GitHub et son propre paquet npm, avec sa propre référence de configuration ; par conséquent, un tutoriel qui ne couvre que le noyau d'i18next omet complètement l'étape d'extraction.
- Les liaisons de cadre fragmentent encore davantage la recherche. Un développeur React à la recherche d’un tutoriel i18next a besoin de l’API useTranslation basée sur les crochets de react-i18next, tandis qu’un développeur Vue a besoin du guide Composition API de vue-i18n et un développeur Angular a besoin du flux de travail basé sur le compilateur de @angular/localize — la même configuration du scanner i18next varie selon la syntaxe JSX ou modèle à analyser.
- L'extraction et la gestion des traductions sont traitées comme un seul sujet alors qu'il s'agit de deux choses distinctes. i18next-scanner ne produit que des fichiers JSON avec des clés et des valeurs de repli par défaut en anglais ; il ne transfère pas ces fichiers à un traducteur, ne suit pas l'état d'avancement de la traduction et ne gère pas les formes plurielles pour les langues cibles — il s'agit d'une couche distincte, généralement un système de gestion de la traduction.
- Les API natives des navigateurs se mélangent dans les recherches de bibliothèques i18n. La documentation Intl (API d’internationalisation) de MDN couvre la mise en page du nombre, de la date et du pluriel en fonction de la localité intégrée à JavaScript lui-même, une couche différente et complémentaire d’une bibliothèque de traduction de chaînes comme i18next.
- Les migrations de cadres rendent les anciens tutoriels monotons. Directives rédigées pour Next.js Pages Router (next-i18next) ne se transfère pas clairement sur App Router (next-intl), donc une recherche fait souvent apparaître des instructions de configuration contradictoires selon la date de publication.
Les couches d’un chemin d’apprentissage JavaScript i18n
- Concepts fondamentaux de la bibliothèque — i18next.com La propre documentation couvre l’initialisation, les espaces de noms et l’interpolation, et constitue le bon point de départ quel que soit le cadre.
- Liaison de cadre — react-i18next, vue-i18n, @angular/localize ou next-intl encapsulent chacun la bibliothèque principale dans le modèle de composants de ce cadre ; utilisez la documentation propre à la liaison, et non un tutoriel i18next générique, une fois l’initialisation terminée.
- Outils d’extraction — i18next-scanner scanne le code source pour les appels de traduction et génère les fichiers JSON locaux avec lesquels une base de code est réellement livrée; son propre README et sa référence de configuration constituent la documentation principale pour cette couche.
- Gestion de la livraison et de la traduction — le transfert des fichiers JSON extraits aux traducteurs, le suivi de l'achèvement et le maintien de l'exactitude des formes plurielles dans toutes les langues constituent une préoccupation distincte de tout ce qui précède, généralement gérée par un système de gestion de la traduction.
Comment configurer i18next-scanner pour extraire les clés de traduction ?
i18next-scanner s’exécute en temps de construction ou en pré-commit plutôt qu’à l’intérieur de l’application en cours, donc la configuration se fait une fois et reste en grande partie non pratique par la suite.
- Installez le scanner comme dépendance développeur – ajoutez i18next-scanner via npm ou Yarn aux côtés des paquets i18next et react-i18next (ou vue-i18n) déjà présents dans le projet.
- Créez un fichier de configuration de scanner – i18next-scanner.config.js définit les globs du fichier d’entrée, le chemin de sortie pour le JSON généré, ainsi que les séparateurs de clés et d’espaces de noms utilisés par le projet.
- Configurez le lexer pour la syntaxe de votre framework – un lexer JSX est nécessaire pour analyser correctement le composant Trans de React et les appels useTranslation; les modèles Vue et Angular ont besoin de leurs propres réglages lexer pour que les clés dans les directives et les pipes ne soient pas manquées.
- Exécutez le scanneur et examinez le JSON généré : chaque clé extraite est placée dans un fichier JSON de localisation avec la chaîne source capturée comme valeur par défaut, qui devient la valeur de repli anglaise jusqu’à ce qu’une traduction existe.
- Ajoutez le scan à CI pour que l’extraction ne dérive jamais du code – exécuter i18next-scanner comme hook de pré-commit ou étape CI maintient automatiquement les fichiers JSON synchronisés avec les nouveaux appels t() et Trans, au lieu de dépendre de quelqu’un qui pense à re-scanner.
Cette approche convient aux équipes qui...
- Configurez-vous pour la première fois l'extraction des clés de traduction sur une base de code React, Vue ou Angular utilisant déjà i18next ou une liaison spécifique au cadre ?
- En ce moment, je maintiens manuellement les fichiers JSON locaux et je veux un balayage automatisé pour remplacer la saisie manuelle des clés.
- Il faut une convention cohérente de nommage de clés et d’espace de noms établie avant qu’une base de code ne dépasse une ou deux langues cibles.
- Nous intégrons de nouveaux ingénieurs qui ont besoin d'un point de départ commun comprenant la documentation de base d'i18next, une liaison de cadre et des outils d'extraction.
Quand ce n’est peut-être pas la bonne priorité
- Des équipes qui décident encore quelle bibliothèque i18n correspond à leur cadre — c’est une question de sélection de bibliothèque, pas d’outils d’extraction.
- Des équipes dont la vraie question est de savoir comment faire passer un fichier JSON déjà extrait dans un flux de travail de traduction plutôt que comment l'extraire du code source.
Liste de vérification d’évaluation : questions à poser avant de créer un flux de travail d’extraction
L'analyseur lexical de votre scanneur est-il compatible avec la syntaxe JSX ou de modèle de votre cadre ?
Un projet React a besoin d'un analyseur lexical compatible JSX qui reconnaisse le composant Trans, et non pas de simples appels t() ; Vue et Angular ont besoin de leur propre configuration équivalente.
Le numériseur conserve-t-il une version anglaise de repli pour chaque clé extraite ?
Confirmer que defaultValue est rempli à partir de la chaîne source plutôt qu’il est laissé vide, puisqu’un plan de secours vide signifie qu’une traduction manquante se rend comme rien au lieu de l’anglais.
Est-ce que retirer des clés inutilisées va parfois supprimer une clé en plein milieu de la traduction?
L’option removeUnusedKeys de i18next-scanner peut retirer des clés qui ne sont plus référencées dans le code — confirmer que ce paramètre n’efface pas les clés qu’un traducteur n’a pas encore terminées.
Où vont les fichiers JSON extraits une fois le scan lancé?
Décidez si les fichiers générés s’engagent directement dans le dépôt ou s’ils passent par un connecteur vers une plateforme de traduction avant que cette étape ne soit automatisée dans CI.
Comment Smartling s'intègre-t-il une fois les clés JavaScript i18n extraites ?
i18next-scanner et ses liaisons de cadre résolvent l’extraction — transformant le code source en fichiers JSON local — mais aucun d’eux ne traduit ces fichiers ni ne garde les formes plurielles correctes entre les langues. L’analyseur JSON de Smartling lit directement les clés imbriquées et les tableaux que le scanner i18next-scanner génère, sans avoir besoin d’aplatir le fichier d’abord. Pour les pluriels spécifiquement, le format à clé plurielle de i18next n’est pas lu nativement par les outils basés sur les soins intensifs, alors Smartling a développé une extension ICU MessageFormat pour i18next qui comble cet écart sans étape de conversion manuelle (Centre d’aide Smartling, Format de messages ICU). Une fois le JSON extrait dans un dépôt, le connecteur GitHub de Smartling peut surveiller cette branche et lancer automatiquement un flux de traduction sur les clés nouvelles ou modifiées, en retournant le JSON traduit sous forme de pull request au lieu d’un téléchargement manuel.
Prêt à voir Smartling en action?
Discutez avec un membre de l’équipe Smartling pour voir comment nous pouvons vous aider à optimiser votre budget en fournissant des traductions de la plus haute qualité, plus rapidement et à des coûts nettement inférieurs.