# Traduction

## 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érentiel.

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

> **Schéma: Rédaction et traduction en mode sériel ou parallèle**
>
> Diagramme 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é.

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

## Principes clés

### 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](https://docs.redaction-technique.org/fr/tech-writing-process/using-branches/) de cet ensemble. Comme il est plus facile de manipuler une branche 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

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

La gestion de versions 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](https://docs.redaction-technique.org/fr/toolkit/example-repository-structure/)) 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

- [Création du contenu](https://docs.redaction-technique.org/fr/tech-writing-process/content-creation/)
- [Git : du fichier au contenu](https://docs.redaction-technique.org/fr/tech-writing-process/git-from-file-to-content/)
- [Formats et outils](https://docs.redaction-technique.org/fr/costs/formats-and-tools/)
- [Cas concret : documentation de NuFirewall](https://docs.redaction-technique.org/fr/formats/nufirewall-case-study/) : traduire du contenu DITA XML fondé sur les conrefs
- [Cas concrets d’utilisation de DITA XML](https://docs.redaction-technique.org/fr/formats/dita-xml-case-studies/)

---

Source: https://docs.redaction-technique.org/fr/tech-writing-process/translation/