Traduction du blog c-rex.net avec MT
Le scénario
Nos articles de blog c-rex.net sont créés dans oXygen XML Editor dans un environnement DITA/XML.
Les fichiers sources DITA sont traduits. Et ce, directement, sans passer par un système de mémoire de traduction.
La raison du choix de cette constellation ?
Nous sommes convaincus qu'à l'avenir, Machine Translation jouera un rôle central la traduction humaine. C'est pourquoi nous avons mis en place un scénario de traduction correspondant et vous le présentons ici.
Ce scénario n'est certainement pas adapté à tous les types de textes. Il existe encore des cas d'application pour lesquels une traduction pilotée par Translation-Memory par le biais de la traduction humaine est le choix le plus approprié.
Nous sommes en sécurité : Il y a beaucoup plus de cas que beaucoup ne le pensent dans lesquels un processus automatisé tel que nous l'avons mis en place est le bon !
Regardons le processus en détail !
Trois clics et la traduction est prête
Nous avons mis en place un paysage d'outils dans lequel la rédaction technique gère l'ensemble du processus, de la création à la publication en passant par la traduction, dans un environnement unique.
Tout d'une seule source avec une très grande part d'automatisation !
Une fois qu'un article de blog en allemand est prêt, nous lançons des scénarios de transformation préconfigurés qui exécutent l'ensemble du processus de traduction en quelques secondes.
Nous déplaçons ensuite les fichiers traduits dans le dossier de la langue cible.
Vient ensuite la publication HTML - également à l'aide d'un scénario de transformation que nous avons mis en place.
Ce qui se cache derrière cette 'magie', quels sont les processus automatiques qui s'y cachent, vous pouvez le lire dans les prochains paragraphes.
Notre environnement éditorial
Comment se déroule notre processus de traduction de la TA ? Quels sont les outils utilisés ?
l'éditeur XML Oxygen XML Editor
c-rex.net DITA-OT pour l'extension du DITA-OT Frameworks
notre service cloud Data Transformation Service DTS
du Machine Translation Engine DeepL
Nous travaillons avec les outils suivants :
Collecte et organisation des données via les DITA-OT-Plug-ins
Nous utilisons des plug-ins développés en interne qui étendent le DITA-OT-Framework pour collecter, organiser et compiler les données de manière à ce qu'elles puissent ensuite être traitées avec c-rex.net DTS.
Ces plug-ins intègrent de manière transparente la fonctionnalité et l'accès au service cloud DTS dans les processus standard DITA.
Après une phase de test, elles seront mises à la disposition de nos clientsclientesclients et clientesclient·e·s en tant qu'extensions standard de DTS à reprendre dans les DITA-OT existantes.
Collecte des fichiers à traduire. Dans notre cas, les références sont ignorées (xref, conref, graphiques). Si nécessaire, ce comportement peut être adapté par la configuration de l'interface.
Zip des fichiers
Envoi des paquets zip au service de transformation des données DTS de c-rex.net
Dans notre cas, DTS traduit les fichiers via DeepL et renvoie le paquet zip traduit.
Bien entendu, il est également possible d'intégrer des Machine Translation Engines alternatifs tels que Google, Bing ou autres.
Le paquet Zip contient
un rapport
Fichiers XLIFF dans la langue source
Fichiers XLIFF bilingues contenant la langue source et les traductions DeepL
DITA-XML traduites (dans notre cas, sans graphiques ni topics liés)
Décompression du résultat de la traduction
Copie des ressources dépendantes dans le répertoire de sortie, de sorte que la DITA-Map soit à nouveau complète
Le processus de collecte et d'organisation des données se déroule de la manière suivante :
Processus de traduction sur le serveur DTS
Génération d'un XLIFF pour chaque fichier à traduire
Marquage de la traduction à l'aide des ITS Rules
Custom Rules peuvent être fournies dans le DITA-OT-Plug-in.
Segmentation des unités de traduction sur la base de SRX Rules
Custom Rules peuvent être fournies dans le DITA-OT-Plug-in.
Résolution des variables en plain-text
Pour DeepL, nous résolvons des variables (keyrefs) et les introduisons dans la traduction en même temps que le texte à traduire. Cela s'est avéré utile pour DeepL afin d'améliorer la qualité de la traduction, notamment en ce qui concerne la grammaire.
Si on ne les indique pas et qu'on a défini un terme de genre au pluriel, DeepL renvoie par exemple la traduction pour le singulier.
D'autres Machine Translation Engines se comportent différemment à cet égard ; c'est pourquoi le comportement à ces endroits et à d'autres est configurable.
Marquage automatique de certains contenus
Pour le thème important de la terminologie d'entreprise, nous avons créé une base de données terminologique dans notre environnement de rédaction, dans laquelle nous déposons des termes, des citations et d'autres textes avec la traduction que nous souhaitons.
On pourrait aussi le faire avec des variables. Nous avons toutefois opté pour l'utilisation d'une base de données terminologique au format tbx.
La traduction correcte de ces termes est essentielle. Nous pensons même qu'elle est plus importante que la traduction correcte du texte qui l'entoure.
Et ce sont ces termes que nous recherchons dans cette étape du processus et que nous dessinons de manière automatisée afin de pouvoir les traiter de manière appropriée dans le processus de traduction.
Ainsi, personne ne doit s'en occuper lors de la création.
Préparation des données pour DeepL
Le support des données structurées est rudimentaire dans DeepL, même si DeepL dispose d'un commutateur de configuration pour XML. Toutefois, aucun XML n'est traité en tant que tel, mais d'autres routines de contrôle minimales sont utilisées dans le texte brut.
C'est pourquoi nous résolvons les structures XML profondément imbriquées dans DITA et dans les XLIFF qui en résultent de manière à ce qu'une chaîne de caractères soit générée le plus près possible du texte brut optimal et transmise à DeepL pour traduction.
Ainsi, les sources d'erreurs possibles lors du traitement des tags sont réduites au minimum.
Nous transmettons également à DeepL les contenus qui ne doivent pas être traduits, comme les variables, afin que DeepL dispose du contexte complet pour la traduction et fournisse ainsi une bonne traduction.
Les contenus traduits automatiquement sont écrits dans l'élément 'target' du XLIFF.
Ré-exporter XLIFF vers DITA
Dans le sens inverse, les contenus qui ne doivent pas être traduits sont à nouveau remplacés par le texte du document source. Cela vaut également pour les variables et les contenus auto-tagués.
Pour ce faire, nous supprimons les textes dans les 'keyrefs' et remplaçons le terme traduit par DeepL dans les contenus auto-tagués par le texte de la base de données terminologique tbx.
Cela pose parfois le problème de la suppression d'un mot ou de guillemets, car DeepL les écrit dans les balises et nous les écrasons lors du processus de remplacement.
Pour finir, le document DITA est reconstruit à l'aide du Skeleton à partir du contenu de l'élément target.
Le service de transformation des données c-rex.net effectue les opérations suivantes :
Présentation de la traduction sur le blog de c-rex.net
Notre blog intègre une possibilité de choix pour les variantes de traduction.
de la traduction automatique par DeepL,
la variante obtenue par post-traitement automatisé par c-rex.net
et une présentation comparative des deux variantes.
Vous pouvez choisir entre
Résumé et perspectives
Résumons. Que nous a montré l'envers du décor ?
L'utilisation des DITA-OT et l'intégration ainsi obtenue des DTS Cloud Services dans le processus DITA standard se traduit par un haut degré d'automatisation et des résultats de traduction très rapides.
Il est essentiel de travailler avec une base de données terminologique afin d'attribuer une traduction fixe à la terminologie de l'entreprise, aux termes importants, aux citations.
La qualité de la traduction est bonne. Il y a quelques imperfections et aussi des erreurs, mais nous pouvons très bien vivre avec. Nous espérons que nos lecteurslectriceslecteurs et lectriceslecteur·rice·s aussi !
En quoi la Machine Translation est-elle adaptée à notre blog ?
Pour le domaine de la documentation technique, le scénario décrit ici convient également très bien.
En effet, il existe des contenus qui doivent répondre à une exigence de qualité de 100% et d'autres pour lesquels ce n'est pas le cas.
Grâce aux métadonnées, notamment lors de l'utilisation du CCMS ou de DITA, il est possible de contrôler le processus et de séparer la traduction des contenus critiques (consignes de sécurité, textes juridiques) de la traduction des autres textes.
Dans un tel scénario, les contenus critiques ne passeraient jamais par le processus de TA et toujours par le Translation-Memory avec traduction humaine.
Dans d'autres cas, on peut combiner les deux, d'abord via MT à cause du temps de traitement (les utilisateurs attendent des infos) et ensuite via le processus de traduction humaine pour une exigence de qualité élevée.
Et qu'en est-il de la Machine Translation dans le domaine de la documentation technique ?