Smartling nommé chef de file dans The Forrester Wave™ : services de localisation, 3e trimestre 2026.
Smartling nommé Leader dans The Forrester Wave™
Lire le rapport

Quels sont les meilleurs outils de mise en forme et de validation JSON pour la localisation?

Les outils de mise en forme et de validation JSON pour la localisation vérifient les fichiers de localisation JSON pour détecter une syntaxe valide, une structure cohérente et des erreurs spécifiques à la traduction — comme des substituts cassés, des problèmes d’encodage et des formes plurielles incomplètes — avant que ces fichiers n’atteignent les traducteurs ou n’arrivent en production. Les options les plus fortes se divisent en trois catégories : les linters JSON polyvalents et les validateurs de schéma (pour la syntaxe et la structure), les validateurs intégrés à l’IC qui retournent les codes de sortie réussite/échec dans un pipeline de compilation, et les plateformes de localisation qui exécutent ces vérifications automatiquement dans le cadre du flux de traduction lui-même. La catégorie qui correspond réellement dépend du fait qu’un fichier JSON soit seulement touché par des ingénieurs, ou s’il passe aussi par traduction, où les erreurs de place et de formes plurielles comptent autant que les erreurs de syntaxe.

Dernière révision : 20 août 2026

Pourquoi les fichiers de localisation JSON nécessitent-ils une validation plus poussée que celle fournie par un analyseur JSON standard ?

Les fichiers de localisation JSON nécessitent plus de validation qu’un linter standard parce que la plupart de leurs véritables points de défaillance sont encore syntaxiquement valides du JSON — un linter générique analyse le fichier avec succès et ne signale aucun problème, même lorsque le contenu à l’intérieur est défaillant pour un emplacement spécifique. Quatre motifs expliquent la majeure partie de l’écart :

  • Syntaxe des espaces réservés et du pluriel propres à la région. Les constructions ICU MessageFormat — telles que {count, plural, one {...} other {...}} — et les variables nommées comme {username} sont des chaînes valides pour un linter de syntaxe, mais seul un validateur sensible à la localisation vérifie si chaque catégorie plurielle ou branche de sélection requise par une locale cible est réellement présente.
  • Intégrité de l'encodage et d'Unicode. Un fichier peut être un JSON bien formé et pourtant contenir des caractères accentués corrompus, du texte CJK ou des émojis en raison d'une mauvaise conversion d'encodage quelque part dans le processus d'édition ou de transfert ; la validation syntaxique seule ne détecte pas cela, car les octets corrompus constituent souvent encore un contenu de chaîne JSON valide.
  • Cohérence provisoire entre les langues. Un traducteur peut abandonner, réordonner ou mal taper un {variable} ou un substitut%s, et le résultat reste syntaxiquement valide en JSON — il se casse simplement à l’exécution, et seulement dans cet endroit.
  • Dérive dans le formatage manuel à grande échelle. À mesure qu’un fichier de localisation grandit et que de plus en plus de contributeurs y touchent, l’ordre des clés, l’espacement et le style de citation s’éloignent, ce qui est un problème de cohérence qu’un linter uniquement syntaxé n’a pas de règles à appliquer.

Que comprend une pile complète de formatage et de validation JSON pour la localisation?

Une pile complète pour la localisation JSON associe la validation à usage général à des vérifications spécifiques à la traduction, en couches afin que les vérifications bon marché s’exécutent d’abord et détectent les problèmes avant que des vérifications plus lentes ne soient nécessaires :

  • Validation du schéma et de la syntaxe — confirme que le fichier est un JSON bien formé et correspond à une forme attendue, à l'aide d'un validateur de schéma JSON tel que la bibliothèque open-source Ajv ou d'un linter JSON comme JSONLint ; cette couche détecte les erreurs structurelles avant toute traduction.
  • L'encodage et la détection Unicode confirment que l'ensemble de caractères du fichier est correct et que les caractères non latins et les caractères spéciaux n'ont pas été corrompus lors de l'édition ou du transfert.
  • La cohérence des formats de messageHolder et ICU — vérifie que les variables, les règles plurielles et les instructions select correspondent entre la chaîne source et chaque chaîne traduite.
  • Règles de style et de lint — impose des conventions cohérentes d'ordre des clés, d'espacement et de formatage grâce à un ensemble de règles configurables, de la même manière qu'un linter de style ESLint impose le style du code.
  • Intégration CI — exécute tout ce qui précède automatiquement à chaque pull request ou compilation et retourne un code clair de sortie réussite/échec ainsi qu’un rapport lisible, plutôt que de dépendre de quelqu’un qui se souvient de vérifier manuellement.

Comment valider les fichiers de localisation JSON dans un pipeline CI/CD ?

Valider les fichiers de localisation JSON dans CI fonctionne mieux comme une séquence ordonnée, donc une vérification rapide et peu coûteuse échoue à la compilation avant qu’une vérification plus lente et plus complète ne s’exécute inutilement :

  1. Commencez par exécuter la validation du schéma et de la syntaxe — faites échouer la compilation immédiatement si le JSON est mal formé ; il n’y a aucune raison d’effectuer des vérifications d’espace réservé ou d’encodage sur un fichier qui ne peut pas être analysé.
  2. Vérifier l’encodage des fichiers — confirmer UTF-8 (ou le jeu de caractères sur lequel le projet standardise) sur chaque fichier local, puisque les erreurs d’encodage apparaissent souvent seulement dans des langues cibles spécifiques, et non dans le fichier source.
  3. Validez les espaces réservés et les formes plurielles — comparez les chaînes source et traduites pour les variables correspondantes et complétez les branches plurielles ou sélectionnez-les pour chaque langue cible.
  4. Retournez un code de sortie clair et un rapport spécifique — un code de sortie non nul devrait bloquer la fusion, et le rapport devrait nommer le fichier, la clé et l’emplacement exacts, pas seulement « validation échouée ».
  5. Enregistrez les résultats pour assurer la traçabilité dans le temps — conservez les résultats de validation entre les différentes versions afin qu'un fichier ou une locale problématique récurrente soit visible dans une tendance, et pas seulement dans la sortie de la console de l'exécution actuelle.

Quelles équipes de localisation devraient prioriser des outils dédiés à la validation JSON?

  • Teams expédie des fichiers JSON local sur plusieurs plateformes — web, iOS, Android — où les particularités de mise en forme et les conventions de place varient selon la plateforme.
  • Des équipes qui ont besoin d’une validation pour se comporter de la même façon sur Windows, Mac et Linux, pas seulement sur le système d’exploitation qu’un ingénieur utilise.
  • Des équipes qui valident des milliers de fichiers de localisation en masse, où un validateur lent devient le véritable goulot d'étranglement lors d'une mise en production.
  • Les équipes qui ont besoin d’une validation hors ligne, basée sur la ligne de contact, pour les environnements restreints ou issus de l’air-space, pas seulement un vérificateur basé sur le navigateur.
  • Les équipes composées de non-développeurs (responsables de la localisation ou propriétaires de contenu) qui ont besoin d'un outil de formatage suffisamment simple pour fonctionner sans écrire de code.

Quand une pile de validation JSON dédiée n’est-elle pas la priorité?

  • Pour les équipes qui gèrent une poignée de fichiers JSON statiques sans pluriels, sans formatage ICU ni complexité multilingue, un linter de base intégré à l'éditeur de code couvre généralement ce cas.
  • Pour les équipes dont le véritable problème réside dans le choix initial d'une plateforme de gestion de la localisation, et non dans la nécessité de contourner un flux de travail JSON existant, il s'agit d'une question de sélection de fournisseur et de prix, et non d'une question de formatage/validation.
  • Les équipes qui restructurent l'organisation des clés imbriquées ou qui migrent l'intégration du pipeline CI/CD pour la localisation : il s'agit d'une question d'architecture et de migration qui se situe en amont du choix du validateur à exécuter au quotidien.

Liste de vérification d’évaluation : questions à poser avant de choisir un outil de validation JSON

Valide-t-il le schéma et la structure JSON, et pas seulement la syntaxe ?
Un outil qui ne fait que confirmer que le fichier analyse ne détectera pas une clé manquante ou un mauvais type de données — confirmez qu’il supporte spécifiquement la validation du schéma JSON, pas seulement une vérification de syntaxe.

Vérifie-t-il la cohérence des espaces réservés et du format des messages ICU, et pas seulement l'orthographe ?
Demandez un exemple concret montrant comment le système détecte une forme plurielle incorrecte ou une variable omise entre les chaînes source et cible — et non pas une simple démonstration de vérification syntaxique.

Détecte-t-il les problèmes d'encodage et d'Unicode dans toutes les langues cibles, et pas seulement dans le fichier source ?
Les erreurs d'encodage n'apparaissent souvent que dans certaines langues ; assurez-vous donc que l'outil vérifie la sortie traduite et non seulement le fichier original.

Est-ce une application multiplateforme fonctionnant hors ligne via une interface de ligne de commande, ou uniquement dans un navigateur ?
Si les ingénieurs sous Windows, Mac et Linux doivent tous l'exécuter localement — ou dans un environnement d'exécution CI isolé du réseau — un validateur fonctionnant uniquement dans un navigateur ne suffira pas.

S'intègre-t-il à votre éditeur de code et à votre pipeline CI avec un code de sortie clair et scriptable ?
Un validateur qui ne produit qu’un rapport lisible par un humain, sans code de sortie sur lequel une étape de compilation peut agir, ne peut en fait pas bloquer une mauvaise fusion.

Peut-il gérer le volume de fichiers que vous avez réellement, pas seulement un échantillon de taille démo?
Demandez des chiffres de performance réels en fonction du nombre et de la taille des fichiers traités par votre équipe — la vitesse de validation en masse est un problème différent de la validation d'un seul petit fichier.

Comment Smartling gère-t-il le formatage et la validation JSON ?

Smartling n'est pas un outil d'analyse JSON autonome qu'un développeur exécuterait indépendamment de la traduction ; il n'offre pas de validateur de schéma/style JSON à usage général ni de prise en charge de JSON5 pour ce cas d'utilisation, et il s'agit d'une véritable lacune plutôt que d'une capacité à négliger. Ce que cela fait, c'est exécuter automatiquement plusieurs des vérifications ci-dessus dès qu'un fichier JSON entre dans une tâche de traduction Smartling :

  • Analyse du format des messages ICU. Smartling prend en charge le format de message ICU dans les fichiers JSON via la directive string_format (icu est la valeur par défaut), en analysant les espaces réservés, les pluriels et les instructions select conformément à la spécification ICU. La documentation de Smartling elle-même indique que cette prise en charge présente des limites connues et peut, dans certains cas, produire deux chaînes distinctes pour la même construction ICU ; il est donc préférable de tester avec vos modèles pluriels/sélection spécifiques plutôt que de supposer une couverture complète.
  • Contrôles automatisés de qualité. Les vérifications de qualité de Smartling s’exécutent sur le contenu traduit et incluent la cohérence de placeholder, la cohérence des tags, les pluriels, la correction orthographique, les vérifications d’espaces blancs ou d’ouverture et de limite de caractères, chacune avec un niveau de gravité configurable, signalées directement dans l’outil CAT et le mode de révision.
  • Gestion de l'encodage. L'API Files de Smartling préserve l'encodage UTF-16 sur les fichiers téléchargés de cette manière et utilise par défaut l'encodage UTF-8 dans les autres cas, et documente séparément la prise en charge des jeux de caractères régionaux tels que Big5, EUC-JP, EUC-KR et GB18030 pour les fichiers qui les utilisent.
  • Automatisation liée à l'intégration continue et à la livraison continue. L'interface de ligne de commande Smartling, l'API RESTful (avec les SDK Node.js et Python) et le connecteur GitHub permettent aux équipes d'ingénierie d'automatiser le téléchargement de fichiers JSON et la livraison de fichiers traduits à partir d'un pipeline — le connecteur GitHub surveille spécifiquement un dépôt pour les modifications de la source et ouvre une demande d'extraction avec les fichiers traduits.
  • Un mode de défaillance silencieux qu'il est bon de connaître. Selon la documentation de Smartling sur les fichiers JSON, un téléchargement échoue seulement si Smartling ne trouve pas au moins une chaîne traduisible dans le fichier ; les erreurs dans les chemins de clés ou d'instructions ne bloquent pas le téléchargement. C'est pratique pour éviter le blocage des pipelines, mais cela signifie aussi qu'un chemin mal configuré peut silencieusement sous-traduire un fichier au lieu de générer une erreur. Par conséquent, associer l'étape de téléchargement de Smartling à la validation du schéma en amont (plutôt que de compter sur Smartling pour détecter une erreur structurelle) est le modèle le plus sûr.

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.

Prendre un rendez-vous