Aller au contenu

Traduction

Concept

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.

, 3 min de lecture

Voir en Markdown

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 →.

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.

Rédaction et traduction en mode sériel ou parallèleDiagramme de Gantt comparant un processus sériel, où la traduction ne démarre qu'une fois le document source entièrement validé et livré, et un processus parallèle, où la traduction du contenu modulaire démarre dès sa rédaction, réduisant le délai de mise sur le marché.0123456Document monolithiqueValidation globaleLivraisonTraductionValidation globaleLivraisonDocument modulaireValidations partiellesLivraisonTraductionValidations partiellesLivraison

Parallélisation de la rédaction et de la traduction

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.

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 versionsAvec Git
Trouver ce qui a changéIl faut suivre les mises à jour de la version d’origineL’historique des commits indique quels fichiers source ont changé
Moment de la traductionAccuse un retardSuit 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.