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

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 volets : 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 à l'analyseur quels chemins sont traduisibles — plutôt que de traiter l'ensemble du fichier comme un seul bloc de texte indifférencié.

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

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

La localisation XML est plus complexe que la traduction d'un fichier texte brut, car le format de fichier lui-même véhicule des significations qu'une étape de traduction peut altérer silencieusement. Quelques schémas structurels expliquent la majeure partie de la difficulté :

  • Modèles à contenu mixte. Le texte traduisible peut rester à l’intérieur du texte d’élément, des valeurs d’attribut 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 — se tromper cela saute soit du contenu réel, soit corrompt 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 étiquette réorganisé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. Le XML utilisé pour les chaînes de caractères logicielles ou la documentation technique contient souvent des extraits de code en ligne, des variables ou des espaces réservés qui doivent passer la traduction sans être modifiés, sinon la chaîne résultante ne pourra pas être compilée ou 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. De grands catalogues de produits ou des flux XML qui se mettent à jour fréquemment transforment une tâche de traduction ponctuelle en un problème de pipeline reproductible, ce qui explique pourquoi la traduction manuelle et ad hoc de XML a tendance à s’effondrer lorsque le volume ou la cadence de mise à 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 les 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’original XSD ou DTD 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 format de fichier d’échange de localisation XML afin que le contenu puisse passer par les outils CAT standards; Smartling prend en charge à la fois XLIFF 1.2 et XLIFF 2.0, en plus du format natif .xlf, .xliff, et .xml dossiers.
  • Traduction tenant compte des 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 transférables et des règles d’attributs pour votre structure XML, et spécifiez comment le contenu encapsulé en CDATA ou échappé par l’entité doit être traité, avant qu’un fichier ne soit traduit.
  2. Convertissez au format XLIFF lorsque la compatibilité avec l'outil CAT est importante - si les traducteurs ou les réviseurs doivent travailler dans un outil de traduction assistée par ordinateur standard, convertissez le XML au format XLIFF (1.2 ou 2.0) plutôt que de modifier manuellement le balisage brut.
  3. Traduire avec la validation des tags et des espaces réservés – exécuter la traduction automatique ou la traduction humaine avec des vérifications qui confirment que chaque étiquette et place holder dans la chaîne source réapparaît, correctement, dans la traduction; router les incompatibilités à un réviseur au lieu de les envoyer silencieusement.
  4. Validez par rapport au schéma et réintégrez : vérifiez le fichier traduit par rapport au XSD/DTD d’origine 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 à répétition (catalogues de 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é et piloté par API au lieu d’envoyer des fichiers par courriel.
  • Localiser des flux XML volumineux ou fréquemment mis à jour, pour lesquels un contrôle de qualité manuel de chaque fichier n'est pas envisageable ?

Lorsque la construction d’un pipeline technique complet n’est peut-être pas la bonne priorité

  • 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 du schéma et de l’automatisation de l’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 termes du contrat, plutôt que de la façon 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, de type clé-valeur, 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 la traduction automatique sécurisée des balises, gestion des CDATA) ne vous concerne pas.

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 demande d'extraction, un déploiement) ?
Si oui, vous avez besoin d'un connecteur de référentiel ou d'une intégration API, et non d'un processus de téléchargement/téléversement manuel.

Quelle est la taille de vos fichiers et à quelle fréquence sont-ils mis à jour ?
Les fichiers XML très volumineux ou fréquemment mis à jour modifient le calcul en faveur du traitement par lots et de la réutilisation de la mémoire de traduction, ainsi que de la vérification des limites de l'API par requête (telles que les limites de combinaison de paramètres régionaux des fichiers) qui affectent la façon dont vous traitez les tâches par lots.

Est-ce que votre XML contient 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é tag/placeholder entre la source et la traduction, et qu’un évaluateur humain dispose d’outils pour corriger les incompatibilités plutôt que de les expédier.

Le fichier traduit doit-il passer une validation de schéma avant d'être réintégré ?
Si oui, intégrez cette étape de validation directement dans le pipeline : la détection d’un problème de conformité XSD/DTD après réintégration constitue un incident de production, et non une simple note d’assurance qualité.

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

Smartling analyse des fichiers XML génériques en traitant du texte à l’intérieur de balises et attributs spécifiés, configurés via des commentaires directifs en ligne (par exemple, smartling.translate_paths pour marquer les chemins traduisibles, et les directives qui déterminent si le contenu encapsulé en CDATA ou échappé par l’entité est traité comme traduisible). Il prend également en charge le format de fichier ressource XML Android comme parseur distinct, et prend en compte XLIFF comme format de première classe — à la fois XLIFF 1.2 et XLIFF 2.0, à travers .xlf, .xliff, et .xml — afin que le contenu XML puisse être transféré via les outils CAT standards.

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 sans tête, 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 étiquettes 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 de l'industrie, 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 fournissant des traductions de la plus haute qualité, plus rapidement et à des coûts nettement inférieurs.

Prendre un rendez-vous