Traduction
Planifiez la traduction dès le début du projet documentaire : anticipez-la pour réduire coûts et délais, traduisez le contenu modulaire en parallèle de la rédaction, et organisez le référentiel source par langue.
Définition
Section intitulée « Définition »Les contraintes de traduction doivent être prises en compte en amont du processus rédactionnel. Elles ont des implications autant sur le style rédactionnel que sur l’organisation du RéférentielL'endroit où une équipe documentaire conserve ses sources : répertoires partagés, base de données d'un CMS ou système de gestion de versions comme Git, qui conserve en outre l'historique complet de chaque fichier. Un référentiel Git est aussi appelé dépôt.Voir dans le glossaire →.
Pourquoi c’est important
Section intitulée « Pourquoi c’est important »Il n’y a pas de recette miracle : la livraison d’informations dans plusieurs langues demande un suivi constant. Mais la prise en compte des contraintes en amont et l’utilisation d’une méthodologie appropriée permettent d’améliorer la qualité et de diminuer les coûts et les délais de livraison des versions multilingues. La traduction doit être intégrée au workflow documentaire. Il faut également faire communiquer avec les traducteurs les différents acteurs : rédacteurs techniques, mais également ingénieurs, experts et concepteurs.
Si la documentation repose sur un ensemble de modules, la traduction peut se faire en parallèle de la rédaction, ce qui réduit les délais de livraison.
Parallélisation de la rédaction et de la traduction
Principes clés
Section intitulée « Principes clés »Séparer les langues à la racine
Section intitulée « Séparer les langues à la racine »En ce qui concerne le référentiel des fichiers sources, vaut-il mieux placer les répertoires de langue en amont ou en aval des répertoires de projets documentaires ? Autrement dit, vaut-il mieux adopter la structure suivante :
D’abord par langue
- english
- produit 1
- produit 2
- français
- produit 1
- produit 2
ou la suivante :
D’abord par produit
- produit 1
- english
- français
- produit 2
- english
- français
Dans la plupart des cas, il est préférable de placer la distinction entre les langues le plus en amont possible. Pour reprendre une terminologie utilisée dans le développement logiciel, créer une traduction d’un ensemble d’informations équivaut à créer une branche de cet ensemble. Comme il est plus facile de manipuler une BrancheLigne de travail parallèle dans un système de gestion de versions : les modifications faites sur une branche restent isolées jusqu'à leur relecture et leur fusion dans la ligne principale, ce qui permet de faire avancer en même temps plusieurs rédacteurs, versions ou langues.Voir dans le glossaire → par sa racine que par ses ramifications, à l’usage, il est beaucoup plus facile de manipuler des répertoires complets, ne serait-ce que pour les fournir aux traducteurs, qu’un ensemble de sous-répertoires.
Suivre les mises à jour : une traduction est un fork
Section intitulée « Suivre les mises à jour : une traduction est un fork »Une fois la traduction réalisée, les modifications apportées à la version source ou à la version traduite ne peuvent être appliquées automatiquement à l’autre version. Pour continuer dans la terminologie du monde logiciel, la nouvelle branche est un fork : il devient impossible d’appliquer automatiquement à l’une les modifications apportées à l’autre. Pour fournir les mêmes informations dans les différentes langues, il est donc crucial de suivre efficacement les mises à jour de la version d’origine.
Localisation continue
Section intitulée « Localisation continue »La Gestion de versionsEnregistrement de chaque modification d'un ensemble de fichiers, qui permet de restaurer n'importe quel état antérieur, de comparer les changements et de travailler à plusieurs en parallèle. Git est le logiciel de gestion de versions le plus répandu ; en docs-as-code, la documentation est placée sous gestion de versions à côté du code du produit.Voir dans le glossaire → rend ce suivi concret. Lorsque les sources sont des fichiers texte dans Git, l’historique des commits indique précisément quels fichiers source ont changé depuis la dernière traduction : les traducteurs ne reçoivent que les modifications, et la traduction peut suivre chaque version au lieu d’accuser un retard.
| Sans gestion de versions | Avec Git | |
|---|---|---|
| Trouver ce qui a changé | Il faut suivre les mises à jour de la version d’origine | L’historique des commits indique quels fichiers source ont changé |
| Moment de la traduction | Accuse un retard | Suit chaque version |
Une arborescence organisée d’abord par langue (voir l’exemple d’architecture de dépôt) fait de chaque langue une arborescence complète, qui peut être générée et vérifiée indépendamment.
La traduction automatique ou assistée par IA peut réduire l’effort à chaque mise à jour, mais son résultat doit toujours être relu par une personne qui connaît à la fois la langue et le produit.
Articles connexes
Section intitulée « Articles connexes »- Création du contenu
- Git : du fichier au contenu
- Formats et outils
- Cas concret : documentation de NuFirewall : traduire du contenu DITA XMLUne architecture de rédaction structurée et modulaire, construite autour de la typologie concept/tâche/référence et de la réutilisation de contenu via conrefs et ditamaps.Voir dans le glossaire → fondé sur les ConrefUn mécanisme DITA XML de réutilisation d'un bloc de contenu par référence : le contenu d'un nœud cible est remplacé par le contenu d'un nœud source à la compilation.Voir dans le glossaire →
- Cas concrets d’utilisation de DITA XML