Comment traduire des fichiers DITA sans conversion XLIFF

Vous cherchez un moyen de traduire vos fichiers DITA sans avoir à subir les contraintes constantes des conversions manuelles XLIFF ? Si tel est le cas, vous êtes au bon endroit. DITA (Darwin Information Typing Architecture) est déjà la référence en matière d'efficacité et de réutilisation du contenu, pourtant de nombreuses équipes techniques de contenu se retrouvent encore coincées dans un cycle frustrant : la boucle de conversion XLIFF.

Si votre flux de travail de traduction actuel implique l'exportation de fichiers DITA au format XLIFF, l'envoi de ces fichiers à une agence, puis leur réimportation manuelle dans votre système, vous perdez probablement bien plus que du temps. Vous risquez peut-être de compromettre l'intégrité même de la documentation que vous avez mis tant d'efforts à élaborer.

Dans cet article, nous aborderons les pièges techniques de la conversion manuelle, les coûts cachés de la gestion des deltas et expliquerons pourquoi la prise en charge native de DITA change la donne pour les équipes de documentation modernes. À la fin de cet article, vous serez prêt à optimiser vos flux de travail de traduction DITA et à adopter un processus plus rapide, plus fiable et nettement plus rentable. Allons-y !

La taxe XLIFF sur la documentation technique

XLIFF (XML Localization Interchange File Format) est une excellente norme pour de nombreuses choses, mais pour les utilisateurs de DITA, elle agit souvent comme un intermédiaire qui complique plus qu'il ne simplifie. On parle souvent de la taxe XLIFF : le coût caché en temps, en argent et en travail manuel nécessaire au bon fonctionnement du format. Voici pourquoi ce processus de conversion manuelle pourrait coûter plus cher à votre équipe que vous ne le pensez.

1. Analyse de la réutilisation du contenu : Conrefs et Keyrefs

Le véritable génie de DITA réside dans sa capacité à référencer du contenu sur de multiples sujets. Lorsque vous convertissez un fichier DITA en XLIFF, ces relations complexes sont souvent aplaties ou complètement rompues. Dans un fichier XLIFF standard, une référence de contenu (conref) peut simplement apparaître comme une chaîne de texte statique.

Cela crée un problème financier important : vous pourriez finir par payer pour traduire plusieurs fois la même note d'avertissement ou la même procédure de sécurité parce que l'outil de conversion n'a pas réussi à la reconnaître comme une entité réutilisable unique. Pire encore, lorsque vous réimporterez ce texte, vous constaterez peut-être que vos références de contenu global ont été écrasées par du texte codé en dur, ce qui détruit de fait votre architecture modulaire et transforme les futures mises à jour en un véritable cauchemar.

2. Corruption des balises et erreurs de validation

Les fichiers DITA sont régis par des DTD (Définitions de Type de Document) ou des schémas XML stricts. Chaque fois que votre contenu passe du format .dita au format .xliff, puis revient au format .dita, vous risquez de créer ce que nous appelons un fouillis de balises.

Il suffit d'un seul traducteur qui ne connaît pas la structure DITA pour supprimer accidentellement un attribut obligatoire ou placer incorrectement une balise de fermeture. Une simple parenthèse manquante ou un attribut mal placé lors de cet aller-retour peut compromettre l'intégralité de votre construction DITA-OT. Nous avons tous connu ça : c'est un vendredi après-midi, vous essayez de déployer une nouvelle version, mais au lieu de cela, vos ingénieurs de support passent leur temps à parcourir des milliers de lignes de code pour trouver une simple erreur de validation.

3. Le cauchemar de Delta Management

Les flux de travail manuels XLIFF obligent souvent les rédacteurs à cesser d'être des créateurs et à devenir des gestionnaires de fichiers. Pour réduire les coûts de traduction, les rédacteurs essaient souvent d'identifier manuellement les deltas (uniquement les fichiers qui ont été modifiés depuis la dernière mise à jour). Ce processus est réputé difficile pour trois raisons :

• Elle est sujette aux erreurs : l’absence d’une seule rubrique mise à jour peut entraîner une documentation désynchronisée qui perturbe vos clients.
• C'est techniquement exigeant : votre équipe finit par passer des heures à comparer des versions au lieu de rédiger du contenu nouveau et utile.
• Il manque de contexte : si une petite modification dans un sujet affecte la signification d’un sujet connexe, une sélection manuelle des différences risque de ne pas la détecter.

Au-delà de l'étiquette : l'importance de la protection des attributs

L'un des aspects les plus négligés de la lutte entre DITA et XLIFF est la gestion des attributs XML. DITA s'appuie fortement sur des attributs pour le profilage et le filtrage, tels que le produit, la plateforme et le public. Ce sont les outils qui vous permettent de publier différentes versions d'un manuel à partir d'une même source.

Lorsque vous utilisez un flux de travail DITA natif, ces attributs sont protégés par défaut. Chez MotaWord, notre système reconnaît qu'un attribut de produit est une métadonnée qui ne doit jamais être traduite. Dans une conversion XLIFF standard, ces attributs sont souvent soit supprimés (ce qui empêche la publication conditionnelle), soit exposés au traducteur. Si un traducteur voit « pro_version » et le traduit en espagnol par « version_professional », votre logique de traitement conditionnel ne fonctionnera plus.

Pourquoi Translate=No est une solution miracle

L'attribut translate="no" est un outil essentiel pour les rédacteurs techniques qui doivent garantir la cohérence des extraits de code, des instructions de ligne de commande ou des noms de marques spécifiques dans toutes les langues. Un analyseur DITA natif respecte cet attribut au niveau du moteur. Lors des conversions XLIFF manuelles, ces instructions sont fréquemment ignorées par les filtres utilisés pour créer le fichier XLIFF, ce qui entraîne des cycles de post-édition coûteux et fastidieux pour corriger le contenu sur-traduit.

Le manque de contexte : pourquoi les traducteurs ont des difficultés avec le XLIFF

La traduction ne se résume pas à un simple échange de mots : il s'agit de comprendre le contexte. Lorsqu'un sujet DITA est converti en un fichier XLIFF plat, le traducteur voit souvent une liste de chaînes de caractères isolées. Ils perdent la vue cartographique qui donne sa structure au projet. Ils ne peuvent pas voir qu'un titre particulier appartient à une section spécifique au sein d'une tâche plus vaste.

En utilisant la traduction DITA native, le traducteur travaille au sein d'un système qui comprend réellement la hiérarchie DITA. Cela présente plusieurs avantages pour la qualité de votre documentation :

• Cela permet une meilleure clarté : le traducteur sait si un mot est une étape, un résultat ou une condition préalable.
• Il garantit une terminologie cohérente : le système veille à ce qu’un terme utilisé dans une description courte corresponde au même terme dans le corps du sujet.
• Elle préserve l'intégrité visuelle : le flux logique des informations reste intact, ce qui est particulièrement important lors de la production de manuels techniques complexes pour du matériel ou des logiciels.

Une meilleure solution : Traduction DITA native avec MotaWord

Nous pensons que les rédacteurs techniques devraient pouvoir se concentrer sur le contenu, et non pas se battre avec les formats de fichiers. C’est pourquoi nous avons travaillé à éliminer l’intermédiaire XLIFF grâce à une approche native.

Comparaison des flux de travail

Flux de travail XLIFF manuel

• Nécessite des heures d'exportation et de filtrage des fichiers.
• Comporte un risque élevé d'aplatissement des références de contenu.
• Cela entraîne souvent des métadonnées corrompues ou traduites accidentellement.
• Nécessite un contrôle qualité manuel approfondi après l'importation des fichiers.
• Des coûts cachés ont été engendrés par le travail manuel et les chaînes de caractères dupliquées.

Le flux de travail DITA natif avec MotaWord

• Cela prend quelques minutes grâce au téléchargement direct de vos fichiers.
• Garantit une protection à 100 % de l'intégrité de vos références de connexion.
• Verrouille ou ignore automatiquement les métadonnées pour garantir leur sécurité.
• Fournit des fichiers prêts à l'emploi dès leur téléchargement.
• Utilise la mémoire de traduction pour vous assurer de ne payer que pour le nouveau contenu.

Téléversez vos fichiers .dita et .ditamap bruts

Au lieu d'exportations complexes, vous pouvez simplement télécharger vos fichiers DITA bruts ou l'intégralité de votre projet Ditamap. Notre plateforme est conçue pour analyser nativement la structure DITA. Il comprend la différence entre un titre, un corps de texte et une brève description, ce qui garantit que vos métadonnées restent intactes et que votre structure demeure saine.

Automatisation au lieu de la comparaison manuelle

Grâce à la mémoire de traduction intégrée de MotaWord, vous n'avez plus besoin de perdre du temps à chercher quels fichiers ont été modifiés. Vous pouvez télécharger l'intégralité du projet et laisser le système se charger du gros du travail :

• Notre système compare l'intégralité de votre Ditamap avec vos traductions précédentes.
• Il identifie les chaînes de caractères nouvelles ou modifiées en quelques secondes.
• Vous ne payez que pour les nouveaux mots, ce qui vous permet de bénéficier des avantages économiques des deltas sans aucun des tracas liés au travail manuel.

L'économie de la documentation prête à la construction

Le véritable coût caché de la conversion XLIFF se trouve dans le cycle de publication final. Dans un flux de travail manuel, la réception des fichiers traduits ne représente que la moitié du chemin. Vous devez encore tout réimporter dans votre CCMS (Component Content Management System), exécuter une version de test à l'aide de DITA Open Toolkit et déboguer les inévitables erreurs XML.

Cette phase d'assurance qualité en matière de localisation peut prendre des jours, voire des semaines, de temps de la part d'un rédacteur. La prise en charge native du format DITA garantit que les fichiers téléchargés sont prêts à l'emploi. Comme la structure n'a jamais été démontée pour tenir dans un conteneur XLIFF, il n'est pas nécessaire de la reconstruire. Vous pouvez passer de la traduction terminée à un site web publié au format PDF ou HTML en quelques clics seulement.

Foire aux questions

1. Comment traduire des fichiers DITA sans casser les conrefs ?

Les plateformes de traduction DITA natives comme MotaWord traitent les fichiers dans leur structure XML d'origine. En évitant la conversion au format XLIFF, le système conserve les pointeurs vers vos références de contenu (conrefs) et vos références clés (keyrefs). Cela permet de garantir que les objets réutilisables sont correctement gérés sans être intégrés en dur dans le texte traduit.

2. Quel est le meilleur flux de travail de traduction DITA pour les petites équipes ?

Pour les petites équipes, le flux de travail le plus efficace est une approche directe vers DITA. Au lieu d'investir dans des intergiciels coûteux ou de passer des heures à effectuer des exportations XLIFF manuelles, les petites équipes devraient utiliser une plateforme qui accepte directement les fichiers .dita et .ditamap. Cela réduit les coûts techniques et élimine le besoin d'un ingénieur de localisation dédié.

3. MotaWord prend-il en charge les DTD DITA spécialisées ?

Oui. Étant donné que DITA permet la spécialisation (la création de types d'éléments personnalisés), notre analyseur natif est conçu pour respecter le schéma XML sous-jacent. Vos balises et attributs personnalisés sont protégés et exclus du comptage des mots, sauf s'ils contiennent du contenu traduisible.

4. DITA ou XLIFF pour la traduction : lequel est le meilleur ?

Bien que XLIFF soit un excellent format d'échange pour les chaînes de caractères logicielles générales, DITA est supérieur pour la documentation structurée car il contient plus de contexte concernant la réutilisation du contenu. La traduction native du format DITA est presque toujours préférable car elle évite les erreurs de conversion aller-retour fréquentes lors de la conversion entre deux formats de fichiers différents.

5. Puis-je utiliser la traduction DITA native avec mon CCMS existant ?

Absolument. La plupart des systèmes de gestion de contenu par composants, comme IXIASOFT, Heretto ou Oxygen Content Fusion, vous permettent d'exporter des packages DITA bruts. Vous pouvez télécharger ces packages directement dans MotaWord, puis réimporter les résultats traduits dans votre SGC sans aucune étape de conversion intermédiaire.

6. Comment réduire les coûts de traduction DITA grâce à la mémoire de traduction ?

En téléchargeant l'intégralité de votre Ditamap sur une plateforme native, le système utilise la mémoire de traduction (TM) pour identifier les correspondances exactes de vos projets précédents. Vous n'êtes facturé que pour les textes nouveaux ou modifiés, ce qui réduit considérablement les coûts des projets de documentation technique à long terme.

7. Comment gérer la localisation des images DITA et les liens hypertexte ?

Lorsque vous téléchargez votre projet DITA nativement, le système reconnaît les balises d'image et de lien. Vous pouvez indiquer si vous souhaitez que les chemins d'accès à ces images soient mis à jour vers des dossiers localisés (par exemple, en changeant le chemin de /images/en/ à /images/es/) ou conservés tels quels. Cela garantit que vos liens ne seront jamais rompus dans la version traduite.

Arrêtez la conversion et commencez la synchronisation avec MotaWord

Si votre flux de travail de traduction actuel vous donne l'impression d'être un obstacle manuel qui freine votre élan, il est probablement temps de passer de la conversion XLIFF à un flux de travail DITA natif. En éliminant ces étapes manuelles, vous réduisez le risque d'erreurs de documentation et accélérez considérablement vos cycles de publication globaux.

Votre expertise devrait être consacrée à la création de contenu de qualité, et non à la gestion des exportations de fichiers. Prêt à découvrir combien de temps et d'efforts vous pouvez économiser sur votre prochain projet ? Vous pouvez obtenir un devis instantané chez MotaWord en téléchargeant vos fichiers .dita dès aujourd'hui.

OYTUN TEZ - Directeur technique (CTO) chez MotaWord

Spécialiste en traductologie, avec une thèse sur la traduction automatique – technologue dans l'ensemble et passionné par les flux de traduction intelligents et fluides.