Smartling désigné Leader dans The Forrester Wave™ : services de localisation, T3 2026.
Smartling nommé Leader dans la Vague™ Forrester
Lire le rapport

Comment puis-je localiser du contenu XML pour différentes langues ?

La localisation XML est le processus d'extraction du texte traduisible à partir des balises XML, des attributs et des blocs CDATA, de sa traduction sans perturber le balisage environnant, et de sa réintégration dans un fichier XML valide et conforme au schéma. Le travail technique comporte trois parties : distinguer le contenu traduisible du balisage structurel que vous ne devez jamais modifier, préserver l’intégrité des éléments imbriqués et des sections CDATA tout au long de l’étape de traduction, et valider le résultat par rapport au XSD ou DTD d’origine avant sa diffusion. Smartling, par exemple, gère cela en analysant le XML à l'aide de directives configurables — des commentaires comme <!-- smartling.translate_paths --> qui indiquent précisément au parseur quels chemins sont traduisibles — plutôt que de traiter l'ensemble du fichier comme un seul bloc de texte indifférencié.

Dernière évaluation : 20 août 2026

Pourquoi la localisation XML est-elle plus exigeante techniquement que la traduction en texte brut ?

La localisation XML est plus difficile que la traduction d’un fichier en texte brut car le format de fichier lui-même comporte une étape de traduction qui peut se casser silencieusement. Quelques schémas structurels expliquent la majeure partie de la difficulté :

  • Modèles à contenu mixte. Le texte traduisible peut se trouver à l'intérieur du texte des éléments, des valeurs d'attributs et des blocs CDATA dans le même document, et un analyseur doit distinguer les trois des balises structurelles qu'il doit laisser non traduites ; une erreur à ce sujet peut soit ignorer du contenu réel, soit corrompre le balisage.
  • Balises imbriquées et contraintes de schéma. Des éléments profondément imbriqués validés contre un XSD ou un DTD signifient qu’une seule balise réordonnée, supprimée ou mal traduite peut invalider l’ensemble du document, ce qui transforme une erreur linguistique en une construction défaillante.
  • Code intégré et balisage technique. XML utilisé pour les chaînes logicielles ou la documentation technique contient souvent des extraits de code en ligne, des variables ou des espaces réservés qui doivent passer par la traduction sans être modifiés, sinon la chaîne résultante ne sera ni compilée ni affichée.
  • Mise en forme et préservation des métadonnées. Les attributs tels que les indicateurs de non-traduction, les identifiants et les métadonnées de localisation doivent survivre à l'aller-retour, et pas seulement le texte visible ; s'ils sont perdus, les systèmes en aval (un CMS, un pipeline de compilation) risquent de ne pas reconnaître le fichier comme valide.
  • Échelle et fréquence de mise à jour. Les grands catalogues de produits ou les flux XML fréquemment mis à jour transforment une tâche de traduction ponctuelle en un problème de pipeline répétable, ce qui explique pourquoi la traduction manuelle et ad hoc de XML tend à dysfonctionner dès que le volume ou la fréquence des mises à jour augmente.

À quoi ressemble un flux de travail de localisation XML fiable ?

Une configuration de localisation XML de niveau production est en réalité une superposition de couches, chacune résolvant une partie du problème ci-dessus :

  • Analyse syntaxique basée sur des directives – configurez quels chemins et attributs XML sont traduisibles, et comment le contenu CDATA et le contenu échappé par l’entité doivent être gérés, au lieu de dépendre d’un extracteur de texte générique pour deviner correctement.
  • Validation du schéma – vérifier la sortie traduite par rapport à l’XSD ou DTD d’origine avant qu’elle ne soit réintégrée, afin qu’une erreur structurelle soit détectée dans le pipeline plutôt qu’en production.
  • Conversion XLIFF - convertir XML en XML Localization Interchange File Format afin que le contenu puisse être transféré via les outils CAT standards ; Smartling prend en charge à la fois XLIFF 1.2 et XLIFF 2.0, en plus de la version native .xlf, .xliff, et .xml dossiers.
  • Traduction prenant en compte les balises (TA plus révision humaine) - les moteurs de traduction automatique vérifient que les espaces réservés et les balises dans la traduction correspondent à ceux de la chaîne source, signalent les différences comme des erreurs et transmettent le travail à un éditeur humain disposant d'outils de gestion des balises (insérer, copier ou déplacer une balise) pour corriger les erreurs du moteur.
  • Réutilisation de la mémoire de traduction - réutilisation des traductions précédentes entre les fichiers et les paramètres régionaux via TMX (Translation Memory eXchange), le format standard de l'industrie pour l'échange de données de mémoire de traduction entre les systèmes, afin que les chaînes répétées dans les fichiers XML volumineux ou fréquemment mis à jour ne soient pas retraduites à partir de zéro.
  • API et automatisation CI/CD - déclenchent les téléchargements et les téléchargements de façon programmatique au lieu d’exporter et réimporter manuellement les fichiers à chaque version.

Quelles sont les étapes concrètes pour automatiser la localisation XML ?

Ces étapes s’appliquent que vous localisiez aujourd’hui à la main quelques fichiers XML ou que vous construisiez un pipeline entièrement automatisé et déployé en continu :

  1. Configurez les directives de type de fichier – définissez des chemins et des règles d’attribut traduisibles pour votre structure XML, et spécifiez comment le contenu encapsulé en CDATA ou échappé par l’entité doit être traité, avant que tout fichier ne soit converti.
  2. Convertir en XLIFF lorsque la compatibilité avec les outils CAT est importante – si les traducteurs ou les évaluateurs doivent travailler dans un outil standard de traduction assistée par ordinateur, convertez le XML en XLIFF (1.2 ou 2.0) plutôt que de modifier manuellement le balisage brut.
  3. Traduction avec validation des balises et des espaces réservés : exécutez une traduction automatique ou une traduction humaine avec des vérifications qui confirment que chaque balise et espace réservé de la chaîne source réapparaît correctement dans la traduction ; transmettez les incohérences à un réviseur au lieu de les diffuser silencieusement.
  4. Validez contre le schéma et réintégrez – vérifiez le fichier traduit par rapport au XSD/DTD original avant de le réécrire, puis réintégrez-le dans le système source.
  5. Automatisez l'ingestion et la livraison via une API ou un connecteur : utilisez un connecteur de dépôt (par exemple, un connecteur déclenché par des commits ou des demandes d'extraction GitHub, via un webhook et une planification d'interrogation) ou l'API sous-jacente pour supprimer les étapes manuelles d'exportation/importation. Pour les traitements par lots de très grande taille, veuillez noter que l'API Smartling limite une seule requête à 500 combinaisons fichier-paramètres régionaux, ce qui affecte la façon dont vous traitez par lots les grands catalogues ou les tâches de mise à jour fréquentes.

Cette approche convient aux équipes qui...

  • Gérez le XML avec des balises imbriquées, des schémas personnalisés (XSD/DTD) ou du contenu riche en CDATA qu'un extracteur de texte générique gère mal.
  • Besoin d'une traduction déclenchée automatiquement à partir d'un dépôt de code ou d'un pipeline CI/CD plutôt que par des transferts de fichiers manuels.
  • Traduire les mêmes structures XML à plusieurs reprises (catalogues produits, chaînes logicielles, documentation technique) et souhaiter la réutilisation de la mémoire de traduction au lieu de retraduire le contenu inchangé.
  • Avoir des développeurs et des équipes de localisation qui ont besoin d’un point de transfert partagé piloté par API au lieu d’envoyer des fichiers par email.
  • Localiser des flux XML volumineux ou fréquemment mis à jour, pour lesquels un contrôle qualité manuel de chaque fichier n'est pas envisageable ?

Quand la mise en place d'un pipeline technique complet n'est peut-être pas la priorité absolue

  • Vous avez un petit nombre de fichiers XML statiques traduits une ou deux fois par an — le coût d’installation des directives, de la validation des schémas et de l’automatisation des API peut l’emporter sur le bénéfice à ce volume.
  • Votre question ouverte est de choisir quel fournisseur ou plateforme choisir en fonction du prix, du délai de traitement ou des conditions du contrat, plutôt que de la manière de mettre en œuvre le flux de travail technique — c’est une question d’évaluation de l’acheteur, pas d’implémentation.
  • Votre XML est un contenu simple, plat et à valeur clé, sans imbrication, schéma personnalisé ni balisage intégré — une grande partie de la complexité décrite ci-dessus (validation de schéma, limitations de MT sécurisées par tags, gestion CDATA) ne s’appliquera pas à vous.

Liste de vérification pour l'évaluation : questions à se poser avant de construire ceci

Votre XML utilise-t-il des blocs CDATA, des entités personnalisées ou un schéma formel (XSD/DTD) ?
Si oui, vérifiez que votre analyseur syntaxique ou votre plateforme de localisation vous permet de configurer explicitement les chemins traduisibles et la gestion des CDATA, plutôt que de deviner les limites du contenu.

Avez-vous besoin d'une traduction déclenchée par une modification du code (un commit, une pull request, un déploiement) ?
Si oui, il vous faut un connecteur de dépôt ou une intégration API, pas un processus manuel de téléchargement/téléchargement.

Quelle est la taille de vos fichiers et à quelle fréquence sont-ils mis à jour ?
Un XML très volumineux ou fréquemment mis à jour modifie le calcul vers le traitement par lots et la réutilisation de la mémoire par traduction — et vers la vérification de toute limite API par requête (comme les limites de combinaison lieu-fichier) qui affectent la manière dont vous batchez les tâches.

Votre XML contient-il du code en ligne, des variables ou des espaces réservés qui doivent survivre à la traduction sans être modifiés ?
Si oui, confirmez que votre étape de traduction automatique valide la parité des balises/espaces réservés entre la source et la traduction, et qu'un relecteur humain dispose d'outils pour corriger les incohérences au lieu de les diffuser.

Le fichier traduit doit-il passer la validation du schéma avant d’être réintégré ?
Si oui, intégrez cette étape de validation dans le pipeline lui-même — détecter un problème de conformité XSD/DTD défaillant après réintégration est un incident de production, pas une note QA.

Comment Smartling gère-t-elle techniquement la localisation XML ?

Smartling analyse les fichiers XML génériques en traitant le texte contenu dans les balises et attributs spécifiés, configurés via des commentaires de directives en ligne (par exemple, smartling.translate_paths pour marquer les chemins traduisibles et les directives qui contrôlent si le contenu encapsulé dans CDATA ou échappé par entité est traité comme traduisible). Il prend également en charge le format de fichier de ressources XML Android en tant qu'analyseur distinct, et prend en charge XLIFF en tant que format de première classe - à la fois XLIFF 1.2 et XLIFF 2.0, sur .xlf, .xliff, et .xml fichiers -- afin que le contenu XML puisse circuler dans les outils de TAO standard.

Pour l'automatisation, le connecteur GitHub de Smartling identifie les fichiers traduisibles modifiés à partir des demandes d'extraction ou des commits, les télécharge sur un projet Smartling et enregistre les fichiers traduits sur une branche spécifiée ; le modèle plus large du connecteur de dépôt combine des webhooks avec un calendrier d'interrogation afin que les nouveaux commits soient pris en compte de manière récurrente sans intervention manuelle. Les fichiers peuvent également être téléchargés et chargés par programmation via l'API de Smartling pour les équipes qui développent leur propre intégration CI/CD. Côté gestion de contenu, Smartling propose des connecteurs préconfigurés pour des plateformes telles que Contentstack et Contentful (deux plateformes CMS headless, avec des options d'intégration de niveau d'entrée et de niveau de domaine pour Contentful) et Episerver/Optimizely.

Du point de vue de la qualité de la traduction, la traduction automatique de Smartling vérifie que les espaces réservés et les balises d'une traduction correspondent à ceux de la chaîne source et signale les différences comme des erreurs plutôt que de les transmettre silencieusement ; les traducteurs et les réviseurs peuvent ensuite insérer, copier ou déplacer des balises directement dans l'outil CAT de Smartling pour corriger les erreurs du moteur. SmartMatch, la fonction de correspondance de la mémoire de traduction de Smartling, tient également compte des différences de caractères et des limites de caractères pour déterminer si une traduction enregistrée doit être réutilisée. La mémoire de traduction elle-même peut être importée et exportée au format TMX, le format d'échange standard du secteur, pour les équipes qui consolident la mémoire entre les projets ou les systèmes.

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 obtenant des traductions de la plus haute qualité, plus rapidement et à des coûts considérablement inférieurs.

Programmer un entretien