Comment créer un glossaire de traduction que les traducteurs et l'IA peuvent réellement utiliser

Pour créer un glossaire de traduction, choisissez les concepts qui nécessitent une formulation contrôlée, définissez ce que chacun signifie dans votre document, approuvez un terme cible pour chaque langue et contexte, et désignez un responsable chargé de maintenir ces décisions. Testez ensuite les entrées dans de vrais passages avant de les confier à des traducteurs ou à un outil de traduction.

La distinction la plus utile est entre le glossaire maître qui consigne vos décisions et l'export réduit qu'un outil peut consommer. Un fichier d'import à deux colonnes peut être nécessaire, mais il ne peut pas remplacer le contexte, les preuves et l'historique d'approbation qui ont rendu ces deux colonnes fiables.

Commencez par le modèle de glossaire vierge et l'exemple de glossaire renseigné. Ce sont deux fichiers CSV encodés en UTF-8. L'exemple utilise un produit fictif et des décisions illustratives de l'anglais vers le français ; ce n'est ni une liste de terminologie certifiée, ni un projet client, ni un préréglage d'import prêt à l'emploi pour BookTranslator.

Gardez le glossaire plus petit que le dictionnaire

Incluez un terme lorsqu'un choix incohérent ou ambigu modifierait le sens, perturberait la navigation, affaiblirait une distinction importante ou entraînerait un travail de révision évitable. Ne collectez pas chaque nom simplement parce qu'un logiciel l'a extrait.

Une bonne passe de sélection pose les questions suivantes :

• Ce concept revient-il dans plusieurs sections, fichiers ou contributions ?
• Le mot source a-t-il plus d'un sens pertinent ?
• L'organisation, l'auteur ou le domaine exige-t-il une forme cible spécifique ?
• Un choix différent rendrait-il un avertissement, une instruction, une interface ou un argument plus difficile à suivre ?
• Le terme est-il nouveau, contesté, ou connu pour avoir déjà provoqué une correction dans ce projet ?

Un terme rare mais lourd de conséquences peut mériter une entrée avant un mot ordinaire fréquent. Un terme standard sans ambiguïté réaliste peut ne pas en avoir besoin du tout.

Le guide de démarrage sur la gestion terminologique pour la traduction du COTSOES recommande une terminologie pertinente pour l'organisation et des responsabilités de validation explicites. Il avertit aussi que le nombre d'entrées ne suffit pas à établir la qualité. Ces principes comptent davantage ici que l'ancienneté de ses exemples logiciels.

L'extraction de candidats n'est que la boîte de réception. Une expression extraite devient une terminologie utile lorsque vous savez ce qu'elle signifie, quand elle s'applique et qui a approuvé la formulation cible.

Construisez un enregistrement autour d'un seul sens

Ne confiez pas la propriété exclusive de l'enregistrement à la chaîne source. Le mot anglais « charge » peut désigner une propriété électrique ou un montant facturé. Une ligne qui associerait chaque occurrence à un seul mot français encoderait une erreur, pas une cohérence.

Donnez à chaque concept un identifiant stable, puis ajoutez la décision propre à la langue. Dans un tableur simple, utilisez une ligne par concept et paire de locales source/cible. Deux lignes peuvent partager une même orthographe source sans représenter le même concept.

Le modèle contient ces champs :

Une référence contextuelle doit permettre à un relecteur de retrouver le passage : une version de fichier et une section, une fiche terminologique faisant autorité, ou une autre source durable. « Sur Internet » ne suffit pas. Pour un concept original défini par l'auteur, la définition du manuscrit lui-même peut constituer la preuve pertinente.

Gardez la définition séparée du contexte source. La définition dit ce qu'est le concept ; le contexte montre comment il est utilisé. Une phrase telle que « Sélectionnez l'espace de travail » illustre l'usage mais n'explique pas ce que contient un espace de travail ni en quoi il diffère d'un projet.

Corriger cinq entrées de glossaire courantes

Les corrections suivantes appartiennent à l'exemple fictif téléchargeable. Elles illustrent des décisions éditoriales, et non des règles terminologiques françaises universelles. Les passages d'exemple fournissent le texte environnant.

1. Un mot polysémique avec une seule cible forcée

Entrée faible : charge → charge

Correction : créez des concepts distincts :

• Propriété électrique : source charge ; cible charge électrique ; domaine « électronique d'initiation » ; contexte « Le condensateur stocke une charge électrique. »
• Montant facturé : source charge ; cible frais ; domaine « facturation » ; contexte « Les frais de livraison sont affichés avant le paiement. »

Cela ne signifie pas que l'une ou l'autre correspondance doit primer sur chaque occurrence de « charge ». Le domaine et le contexte de l'entrée font partie de la décision. Si l'outil choisi ne peut pas les distinguer, utilisez des exports de projet séparés, une phrase plus longue et sans ambiguïté, ou une révision humaine plutôt qu'une substitution globale.

2. Un terme sans sa catégorie grammaticale

Entrée faible : seal → sceller

Correction : distinguez le verbe du composant :

• « Sceller l'enveloppe » : un verbe, avec pour cible illustrative sceller dans ce projet.
• « Remplacer le joint en caoutchouc » : un nom désignant un composant, avec pour cible joint.

Le tableur décrit désormais deux concepts au lieu de suggérer qu'un composant en caoutchouc est une action. Pour un document technique réel, demandez au réviseur du domaine de valider le sens du composant et le terme privilégié.

3. Deux traductions acceptables sans préférence de projet

Entrée faible : workspace → espace de travail / zone de travail

Correction : approuvez espace de travail pour le conteneur nommé de l'application fictive. Consignez zone de travail comme variante rejetée pour ce concept d'interface, et non comme du mauvais français en général. Ajoutez une note d'usage précisant que l'inflexion grammaticale normale est autorisée.

Une variante rejetée a besoin d'une raison et d'un périmètre. Sinon, un réviseur risque de « corriger » une expression parfaitement valide dans un autre contexte.

4. Un nom de produit protégé uniquement par implication

Entrée faible : LeafDeck → LeafDeck

Correction : définissez do_not_translate=true, identifiez-le comme le nom du produit fictif, préservez la casse et citez la décision de nommage du projet de démonstration. Précisez que la règle ne s'applique pas aux mots sans rapport dans une description ordinaire.

Le simple fait que le texte source et le texte cible correspondent ne permet pas de savoir si la conservation est intentionnelle ou s'il s'agit simplement d'un travail inachevé. Utilisez le guide de décision sur ce qu'il ne faut pas traduire pour la liste d'exclusion plus large.

5. Une décision provisoire présentée comme approuvée

Entrée faible : sync → synchroniser / mettre à jour, sans responsable ni état.

Correction : définissez d'abord l'action. Pour la commande fictive qui synchronise la bibliothèque de l'appareil, approuvez synchroniser comme verbe et consignez l'alternative comme inadaptée à cette commande précise. Désignez un responsable et une source de décision datée.

Conservez un libellé nominal distinct à l'état draft jusqu'à ce que son réviseur le tranche. Le CSV d'exemple inclut délibérément cette ligne provisoire. Un tableur d'apparence impeccable ne prouve pas que chaque ligne est approuvée.

Utilisez un critère de qualité des entrées, pas un score décoratif

Avant d'approuver une entrée, posez six questions fermées :

1. Sens : une autre personne peut-elle distinguer ce concept des concepts voisins ?
2. Preuve : peut-elle trouver la source ou la décision d'auteur qui l'étaye ?
3. Langue : la forme cible convient-elle à la locale, à la grammaire et au domaine spécifiés ?
4. Périmètre : sait-elle où la règle s'applique et où elle ne s'applique pas ?
5. Responsabilité : un responsable est-il chargé de résoudre les modifications ?
6. Usage : l'entrée a-t-elle été vérifiée dans une phrase représentative ?

Une réponse non résolue signifie que l'entrée reste à l'état de brouillon. Il s'agit d'une grille d'acceptation éditoriale, et non d'une mesure numérique validée de la qualité de traduction.

Répartissez le travail selon les compétences. L'auteur ou le spécialiste du sujet confirme le concept ; le relecteur de la langue cible confirme l'usage ; le responsable de la terminologie consigne la décision et diffuse la version approuvée. Une seule personne peut assumer plusieurs rôles sur un petit projet, mais les questions doivent tout de même recevoir des réponses.

Si un relecteur conteste une entrée, consignez les choix concurrents et le passage qui révèle le conflit. Suivez le flux de travail des requêtes de traduction plutôt que de laisser des messages privés devenir des exceptions non documentées.

Exportez pour l'outil de destination uniquement après approbation

Votre glossaire maître et le dictionnaire d'un moteur ont des objectifs différents. Le maître explique les décisions aux personnes. Un fichier d'importation doit respecter le schéma et le comportement de correspondance d'un outil particulier.

Pour un outil qui prend en charge les importations de glossaires :

1. Sélectionnez la paire de langues source/cible requise et le domaine du projet.
2. Excluez les entrées draft et deprecated.
3. Résolvez les chaînes sources en double que l'outil de destination ne peut pas distinguer.
4. Mappez uniquement les champs pris en charge dans le format d'importation actuel de l'outil.
5. Vérifiez comment il traite la casse, les inflexions, les termes composés de plusieurs mots et le texte protégé.
6. Testez un petit échantillon représentatif et inspectez la traduction renvoyée.

Par exemple, le format CSV unidirectionnel documenté de Google Cloud Translation utilise des paires source/cible sans en-tête, tandis que son CSV d'ensemble de termes équivalents utilise des en-têtes de langue. Sa correspondance de glossaire est sensible à la casse par défaut, et certaines entrées de mots vides sont ignorées. Ce sont des règles propres à Google Cloud, et non des règles CSV générales ni des capacités de BookTranslator. Consultez la documentation actuelle de Google Cloud sur les glossaires avant de préparer un export pour ce service.

Ne téléversez pas le CSV richement annoté de cet article dans une boîte de dialogue d'importation quelconque. C'est un maître de travail. À l'inverse, ne jetez pas ses définitions et son historique d'approbation simplement parce qu'un outil n'accepte que deux colonnes.

Lorsque vous utilisez un système d'IA disposant d'un champ d'instruction pris en charge, fournissez un sous-ensemble pertinent et approuvé, ainsi que le contexte nécessaire pour distinguer les sens. Une instruction peut demander une terminologie ; elle ne garantit pas que le résultat l'a suivie. Inspectez le résultat. Si le système n'offre aucune entrée de glossaire prise en charge, conservez le maître comme référence pour les relecteurs plutôt que d'inventer un moyen de l'importer.

Pour les organisations dont les équipes de première ligne sont multilingues, la cohérence terminologique compte aussi après la traduction. Les supports de formation, les politiques et les communications opérationnelles peuvent devoir parvenir aux employés dans leurs langues préférées tout en préservant la formulation approuvée. iTacit explique comment la communication multilingue soutient l'information en milieu de travail à travers les langues, les pays et les cultures.

Ajoutez des langues sans effacer les décisions locales

Réutilisez l'ID de concept lors de l'ajout d'une autre locale cible, mais attribuez à cette locale sa propre cible, son statut, son responsable et ses preuves. Une approbation en français n'approuve pas un équivalent allemand. Une cible vide signifie « non résolu », et non « utilisez automatiquement la source ».

La même discipline s'applique au sein d'une même langue. Séparez les décisions propres à une locale lorsqu'elles diffèrent sensiblement. Ne créez pas de lignes en double simplement pour ajouter des étiquettes régionales qui ne changent rien.

Gardez ces états simples :

• Brouillon : une décision candidate ou contestée ; ne fait pas partie d'un export approuvé.
• Approuvé : accepté pour la portée et la version indiquées.
• Obsolète : conservé pour l'historique et la détection, mais non recommandé pour les nouveaux travaux.

Pour un changement substantiel, consignez l'ancienne forme, la nouvelle forme, la raison, la version effective, le responsable et les emplacements sources concernés. Reconstruisez l'export pertinent et indiquez aux traducteurs quels passages nécessitent un réexamen. Ne remplacez pas un terme en silence en cours de projet en espérant que les chapitres déjà traduits se mettent à jour d'eux-mêmes.

Révisez les entrées lorsque le produit, le manuscrit source, la norme ou l'usage accepté change. Un rappel calendaire peut aider, mais une définition modifiée est un déclencheur plus fort.

Valider le glossaire sur des passages avant de passer à l'échelle

Un glossaire peut être parfaitement ordonné en interne et échouer dans une phrase. Utilisez un petit ensemble de passages qui inclut délibérément :

• un mot source ambigu avec deux sens ;
• un terme en tant que titre et au sein d'un texte courant ;
• une variation grammaticale au singulier, au pluriel ou autre ;
• un nom protégé à côté d'un langage ordinaire ; et
• un terme dans un tableau, une légende, une instruction ou une autre structure documentaire importante.

L'exemple téléchargeable associe « delivery charge » à « electric charge » et inclut « seal » à la fois comme nom et comme verbe. Ces cas montrent pourquoi le remplacement sans portée est le mauvais test d'acceptation.

Pour chaque passage, consignez la source, la version du glossaire, la sortie cible, la décision du relecteur et la correction si nécessaire. Si vous testez réellement un service de traduction, ajoutez le service/modèle, la date, les paramètres et la sortie brute. Les exemples de cet article ne prétendent pas qu'un tel test de service a été effectué.

Une fois le document complet traduit, passez à la vérification de la cohérence terminologique. La construction du glossaire établit la politique ; la révision de la sortie détermine si le texte livré la respecte sans devenir artificiel.

Transmettez un registre de décisions, pas seulement une liste de mots

La transmission finale doit contenir la version source, le glossaire maître approuvé, l'export vers l'outil de réception le cas échéant, le journal des requêtes non résolues et des exemples représentatifs. La personne qui réalise la traduction doit savoir quel fichier fait autorité et à qui s'adresser en cas de conflit.

Pour un livre entier ou un long document pris en charge, le flux de traduction de fichiers de BookTranslator peut fournir une ébauche pour la révision ultérieure. Conservez votre glossaire approuvé à côté de cette ébauche. La feuille de travail présentée ici est une référence éditoriale externe, et non l'affirmation que BookTranslator importe des glossaires CSV gérés par l'utilisateur ou applique chaque entrée.

Commencez par quelques concepts importants, rendez les décisions inspectables et développez à partir d'ambiguïtés réelles ou de constats de révision. L'objectif est de réduire les décisions non résolues dans le prochain document, pas de produire le glossaire le plus volumineux.