Le WordPress d'aujourd'hui, décodé pour les développeurs

Multilingue

Documenter un glossaire multilingue pour qu’il survive au départ d’un traducteur

Un glossaire terminologique utile ne se résume pas à une liste de mots : sa structure détermine s'il reste exploitable une fois son auteur parti.

Par Clément Hadrot • 13 août 2025 • 5 min de lecture • Aucun commentaire
Documenter un glossaire multilingue pour qu'il survive au départ d'un traducteur

Qu’est-ce qu’un glossaire terminologique qui a réellement de la valeur ? Pas une liste de correspondances terme source / terme cible : ce format minimal fonctionne tant que la personne qui l’a constitué est disponible pour répondre aux questions, mais devient rapidement inutilisable dès qu’elle quitte le projet, parce que les choix qu’il contient ne sont jamais expliqués.

Sur un site institutionnel traduit en quatre langues, le glossaire hérité d’un ancien traducteur freelance ne contenait que deux colonnes : le terme français et sa traduction dans chaque langue. Quand un nouveau traducteur a repris le projet, il a fallu redécouvrir empiriquement pourquoi tel terme technique était traduit d’une façon inhabituelle, faute d’explication écrite quelque part. Voici la structure qui a été mise en place pour éviter que ça se reproduise.

Le problème d’un glossaire à deux colonnes

Une correspondance brute entre un terme source et un terme cible ne dit rien sur le contexte d’usage. Prenons un exemple concret : le mot « abonnement » peut se traduire différemment selon qu’il désigne un abonnement à une newsletter, un abonnement WooCommerce Subscriptions récurrent, ou un abonnement au sens d’un forfait tarifaire. Une seule ligne « abonnement → subscription » ne permet pas de savoir laquelle de ces trois traductions s’applique, ni pourquoi une distinction a été faite ailleurs dans le glossaire entre « abonnement » et « souscription ».

Ce défaut de contexte a un coût direct : chaque nouveau traducteur qui reprend le glossaire doit soit deviner, soit reposer les mêmes questions déjà tranchées par le passé, soit pire, trancher différemment et introduire une incohérence terminologique dans le contenu déjà traduit.

La structure retenue : cinq champs par entrée

L'essentiel à retenir : Une entrée de glossaire a besoin de contexte d'usage, pas seulement d'un terme cible ; Le format doit rester lisible sans l'outil qui l'a produit ; Un exemple d'usage réel vaut mieux qu'une définition abstraite

Le glossaire reconstruit tient dans un tableur partagé, mais chaque entrée comporte cinq champs plutôt que deux :

  • Terme source : le mot ou l’expression en français, tel qu’il apparaît dans le contenu.
  • Traduction retenue par langue cible.
  • Contexte d’usage : dans quel type de contenu ce terme apparaît (fiche produit, page institutionnelle, email transactionnel…).
  • Justification du choix : pourquoi cette traduction plutôt qu’une autre plus littérale, avec la date et l’auteur de la décision.
  • Exemple de phrase tirée du site, dans la langue source et dans la langue cible.

Le champ « justification du choix » est celui qui manquait le plus cruellement dans l’ancien glossaire. Une entrée type ressemble à ceci une fois complétée :

ChampContenu
Terme sourceFiche produit
Traduction (EN)Product page
Contexte d’usageCatalogue WooCommerce, jamais dans les emails transactionnels
Justification« Product sheet » écarté car trop littéral et rarement utilisé en anglais commercial ; décision du 12/03/2024
Exemple« Consultez la fiche produit complète » → « See the full product page »

Un format qui survit à l’outil qui l’a produit

Le glossaire précédent vivait dans la mémoire de traduction d’un outil professionnel spécifique. Le problème n’était pas l’outil en lui-même, mais le fait que le glossaire n’existait que sous cette forme : personne d’autre que le titulaire de la licence ne pouvait le consulter facilement, et l’export vers un format ouvert n’avait jamais été anticipé.

Le nouveau glossaire vit dans un tableur exportable en CSV, avec une copie synchronisée dans un espace de documentation partagé du projet. Cette redondance volontaire garantit que même si l’accès au tableur d’origine est perdu, le CSV reste consultable et importable dans n’importe quel autre outil, aujourd’hui ou dans plusieurs années.

Qui maintient le glossaire, et à quelle fréquence

Un glossaire non maintenu se périme aussi sûrement qu’un glossaire mal structuré. La règle adoptée sur ce projet : chaque nouvelle entrée terminologique proposée par un traducteur, qu’elle soit validée ou rejetée, est consignée avec sa justification avant même que la traduction ne soit publiée. Cela évite l’écueil classique où le glossaire n’est mis à jour qu’a posteriori, de mémoire, plusieurs semaines après la décision réelle.

  • Revue trimestrielle du glossaire par le responsable éditorial, indépendamment de tout changement de traducteur.
  • Toute nouvelle entrée validée en cours de projet, jamais différée « pour plus tard ».
  • Une entrée jugée obsolète est marquée comme telle plutôt que supprimée, pour garder la trace de la décision passée.

Un glossaire qui ne explique pas pourquoi, seulement quoi, transmet une liste de mots. Un glossaire qui explique pourquoi transmet un raisonnement, et c’est ce second type qui survit à un changement de traducteur.

Le test de transmission

Pour vérifier qu’un glossaire est réellement transmissible, une méthode simple : donner le fichier seul, sans aucune explication orale, à une personne qui découvre le projet, et lui demander de traduire une phrase contenant un terme du glossaire. Si elle applique la bonne traduction et comprend pourquoi grâce au contenu du fichier, le glossaire remplit sa fonction. Sur ce projet, ce test a été fait avec un traducteur externe non impliqué dans le site : deux entrées sur une trentaine testées se sont révélées ambiguës, ce qui a permis de les corriger avant qu’elles ne posent réellement problème lors d’une transition d’équipe.

En résumé

Un glossaire terminologique qui ne survit pas au départ de son auteur se limite presque toujours à une correspondance brute entre termes, sans contexte ni justification. La structure qui résiste au temps ajoute systématiquement le contexte d’usage, la raison du choix et un exemple concret tiré du contenu réel. Ce n’est pas plus de travail à long terme : c’est le même travail, écrit une fois plutôt que refait à chaque changement de traducteur.

Partager :

À propos de l'auteur

Clément Hadrot

Développeur WordPress, passionné par Elementor, le FSE et l’automatisation par IA.

Voir tous ses articles

Dans la même veine

À lire aussi