2 Les premiers débuts
Ainsi est-il normal qu’avec l’introduction des premiers processeurs de texte à la Commission au début des années 80 (Wang, Philips), les traducteurs se mettent à saisir et/ou retravailler électroniquement leurs propres fiches sur papier. Entretemps, la banque de données terminologiques centrale EURODICAUTOM a grossi et son utilization considérablement augmenté. Dans le souci de permettre une alimentation de cet outil aussi par les traducteurs et, partant, une mise à disposition de leurs recherches à l’ensemble de la communauté des traducteurs, les premiers efforts de saisie selon une méthodologie commune voient le jour. Jusque là, les trouvailles des traducteurs ont
été encodées au service central de terminologie avec les résultats de recherches ponctuelles effectuées pour le compte des traducteurs, et les autres grandes collections qui proviennent elles majoritairement de publications du marché (dictionnaires, glossaires ou thesaurus bi- ou multilingues). Les délais de traitement empêchent évidemment de garantir l’accès immédiat aux données locales. Au début des années 90, après l’introduction du système Q-Office sous Unix et le traitement de texte Q-One, des procédures semiautomatiques d’encodage de fiches terminologiques sont donc mises au point entre autres par l’équipe SYSLING de Luxembourg. Ces procédures (PREDIC) suivent largement les consignes de saisie D’EURODICAUTOM et nécessitent un certain nombre de démarches de la part des traducteurs. Elles garantissent l’origine locale des données entre autres par le fait que les données de gestion de chaque fiche reprennent le nom de l’unité de traduction et du traducteur qui sont à son origine. Par ailleurs, la saisie des informations essentielles est jugée suffisante étant donné que ces informations, après leur envoi à la boîte aux lettres d’EURODICAUTOM, peuvent aisément être complétées par les collègues de l’unité Terminologie, soit avant soit après leur introduction dans la mémoire centrale. La fonction grep de UNIX permet une recherche instantanée dans les nouvelles collections. A Bruxelles, un système décentralisé d’encodage de fiches a été développé sous le nom de TERMI: tournant sur Oracle il permet la saisie commune dans des bases de données locales accessibles également à la consultation. Celle-ci se heurte néanmoins à des limites jugées trop rigoureuses par les utilisateurs (accès à l’information exclusivement par les unitermes)
en comparaison avec l’interrogation de l’outil central EURODICAUTOM qui accueille les fiches TERMI après leur exportation. Ces différentes tentatives ont plusieurs traits en commun: a les trouvailles terminologiques dites locales constituent d’abord des collections personnelles et/ou d’unité accessibles à tous à un moment ultérieur (format unique de stockage et mode uniforme d’interrogation à partir d’un même outil),
b de par leur origine ces sous-ensembles terminologiques peuvent aussi être distingués d’après le domaine d’appartenance ou d’utilisation (documents provenant d’un demandeur spécifique), le degré de consolidation (mention spéciale telle que Fiche PREDIC),
etc,
c des conditions minimale doivent être remplies par les participants:
vérification préalable de la nouvelle terminologie avec le contenu d’EURODICAUTOM et présence dans la fiche d’informations minimales (p ex terme en langue source avec référence et son équivalent en langue cible ou encore terme en une seule langue
avec référence, définition ou note), d non seulement les nouveaux uni/pluritermes et expressions, mais aussi les segments plus longs, les problèmes traductionnels et les
abréviations sont considérés comme faisant partie de la terminologie,
e l’intervention de l’unité Terminologie sur les fiches des traducteurs s’inscrit dans le cadre d’une étroite collaboration.
3 La révolution technologique
Ces mêmes traits sont toujours et avant tout de rigueur lorsqu’il s’agit de porter les procédures existantes vers une nouvelle plate-forme technique, les micro-ordinateurs. En 1992, au début de la migration du SdT vers le monde PC, certains systèmes de gestion de terminologie sous DOS ont déjà fait leurs preuves sous Windows. Ainsi, des groupes de test se constituent vite au sein de notre Service pour essayer de tirer au mieux profit des nouvelles interfaces graphiques. Une bonne organisation de ces tests s’avère cependant être de mise pour garantir l’échange ultérieur des données. En effet, si jusque là des données locales ont été saisies à l’aide d’un système central ne permettant guère d’individualité, elles le seront dès à présent à l’aide d’outils locaux offrant un maximum de convivialité et de configurabilité. Pour ne pas laisser partir à la dérive les efforts menés jusque là dans le domaine de la modernisation, la réorganisation des unités du SdT potentiellement en charge du développement et de l’introduction des outils d’aide à la traduction s’impose en 1994. Elle permet aux unités restructurées (notamment AGL/3-4) de dresser d’abord un inventaire des nombreuses actions entreprises en peu de temps, de sonder ensuite les besoins réels en matière de terminologie locale et de définir finalement un cadre d’implantation régi par les dispositions en vigueur à la Commission: appel d’offres avec rédaction d’un cahier des
charges, évaluation, commande, adaptation et, en dernier lieu, installation d’un logiciel accompagnée d’une formation minimale pour les utilisateurs finaux et les gestionnaires des bases locales. Toutes ces actions sont guidées par un Comité de Pilotage nouvellement créé et associent dans la mesure du possible les traducteurs et autres
utilisateurs potentiels du système.
4 Une approche structurée
Une des premières tâches de ce comité consiste à expliciter l’objectif du projet: organiser l’ensemble de la chaîne terminologique, depuis le repérage fait par le traducteur au cours de la traduction d’un document jusqu’à la diffusion la plus large d’une terminologie multilingue solide. En deuxième lieu, il doit définir la structure de la base locale en conséquence. Par structure de la base nous entendons la totalité des
champs susceptibles de figurer dans la fiche terminologique et compatibles avec la base centrale de consultation EURODICAUTOM, bien qu’il soit évident que la fiche standard du traducteur ne constitue qu’un sous-ensemble de ces champs, tel que défini par lui, en function de ses besoins et de ses habitudes de travail. Cette structure prévoit donc tous les champs nécessaires à une gestion et à une utilization optimales des données (valables soit pour toute la fiche soit pour une langue) tout en garantissant la possibilité de conversion de celles-ci vers EURODICAUTOM qui reste l’outil principal de diffusion/consultation. Une autre tâche consiste à développer une méthodologie commune pour le captage des données. La rédaction d’un guide méthodologique qui servira aussi de support de formation, est confiée à plusieurs traducteurs. Le respect des consignes méthodologiques simples permettra en effet de réutiliser les données des traducteurs dans tous les outils informatiques existants ou à développer, et d’accroître leur efficacité. Cependant, chaque traducteur passant du papier à l’électronique se heurte naturellement au début à quelques problèmes de captage (surtout des collocations) qui sont dus aux habitudes liées à l’utilisation de dictionnaires classiques. Ainsi fallait-il, dès les premiers efforts déployés par les traducteurs, constamment leur rappeler de saisir les termes tels quels sans modifier l’ordre des mots tout en reprenant
les mots vides sans utiliser de parenthèses, p ex: at constant prices au lieu de constant prices (at -). Certains de ces mécanismes avaient même été appliqués dans le dictionnaire électronique EURODICAUTOM (voir l’article de THIERRY FONTENELLE “Conversion d’EURODICAUTOM au format SGML, p 222”).
Par ailleurs, dans cette dernière base, une entrée et ses éventuels synonymes apparaissent dans le même champ VE, comme dans l’exemple suivant:
FR VE 1) acide chloroacétique; 2) acide monochloracétique; 3) acide
chloréthanoique; 4) acide chloracétique
Comme on peut le constater, les différentes dénominations de cet acide sont numérotées et séparées par des points-virgules. A l’époque, le moteur de recherche d’EURODICAUTOM a été adapté à ce format et la présence de parenthèses et de numéros dans un champ comme VE ne gêne nullement l’indexation et la recherche. Il n’en va pas de meme pour un logiciel moderne du marché qui en général n’accepte pas la présence d’une liste de synonymes dans un même champ. Chaque information devant trouver sa place dans un champ qui lui est réservé et les mélanges étant interdits, ce qui est conforme à la philosophie des bases de données traditionnelles, le traducteur qui souhaite créer localement sa propre fiche est donc invité à se débarrasser de certains réflexes tenaces, mais dangereux, et à créer autant de champs vedette ou terme qu’il y a de synonymes. Il faut néanmoins souligner que la saisie d’après les règles modernes donne lieu à moins d’erreurs étant donné que le traducteur n’a guère à se soucier de problèmes de syntaxe (numérotation et signes particuliers à utiliser en cas de synonymes avec ou sans informations descriptives).
5 L’adaptation de l’outil
A côté de ces efforts plutôt administratifs, l’essentiel des travaux porte évidemment sur la mise au point de l’outil local (MultiTerm ‘95 Plus! De la société Trados) retenu lors de la consultation du marché au courant de l’été ‘95. L’échange des données devant être garanti avant toute autre chose, le respect par tous les utilisateurs de la structure commune des bases locales ou même individuelles est primordial. Il n’est cependant pas suffisant d’offrir et de protéger une telle structure contre l’écriture. Plutôt faut-il au moment de la création d’une nouvelle base et de la saisie d’une nouvelle fiche, prévoir des mécanismes naturels pour éviter le non-respect de la structure définie de commun accord avec les participants aux tests. Ceci est garanti notamment par la mise à
disposition de masques de saisie prédéfinis, la personnalisation de tells masques, l’utilisation de listes à choix multiples (picklists) ainsi que par des macros facilitant l’encodage des informations disponibles sur support électronique directement à partir du traitement de texte (saisie décentralisée contrôlée).
Le traducteur peut ainsi ne visualiser qu’un masque de saisie aussi dépouillé et personnalisé qu’il le souhaite; ce masque peut également déjà contenir des valeurs préétablies dans la mesure où elles sont réutilisables pour un même projet de traduction. A cet égard, les points de vue de deux groupes d’utilisateurs ont été conciliés: ceux qui veulent avant tout rapidement mémoriser des termes avec rajout éventuel d’une note en langue cible, sans interruption de leur travail de traduction, et
ceux qui souhaitent le cas échéant approfondir la recherché terminologique et enrichir de suite la saisie par des informations sémantiques supplémentaires (notes techniques ou linguistiques et/ou définitions).
A chaque étape de la mise en oeuvre du projet, des traducteurs guident les membres du comité et les unités concernées pour trouver des solutions proches du travail quotidien de la traduction. Leur apport est particulièrement riche quand il s’agit de thématiser les bases locales selon la structure thématique administrative existante. En effet, dans
chaque Groupe thématique, des traducteurs établissent les listes de descripteurs qui sont introduites dans l’outil avec la définition de la base et qui permettront de structurer les données d’après des domains d’appartenance ou même des projets de traduction. Sur la base de la classification utilisée également dans la base centrale, les onze unités
linguistiques des sept Groupes thématiques se réfèrent ainsi chacune sur les mêmes listes de valeurs, ce qui facilite non seulement l’échange des données entre elles mais aussi le transfert de ces données vers la base centrale.
6 L’organisation du partage
Dans les très nombreux contacts avec des traducteurs et dans les discussions au sein du Comité de Pilotage, il est apparu que la volonté de partager les données élaborées au niveau individuel côtoyait le désir de leur conserver un caractère soi-disant privé. Les niveaux de partage souhaités varient également considérablement. D’une façon générale, on peut dire qu’une grande majorité de traducteurs souhaitent que leurs données terminologiques connaissent une large diffusion à travers EURODICAUTOM, mais qu’ils ne souhaitent pas que l’outil local soit considéré comme l’outil de saisie de la base centrale. Ils insistent sur la nécessité de conserver localement des données dont ils jugent l’intérêt trop limité, ou dont ils estiment une validation indispensable avant de les communiquer à d’autres. Nombreux sont ceux qui voudraient travailler d’emblée avec tous les traducteurs de leur langue, moins fréquents ceux qui préféreraient collaborer avec leurs collègues du même groupe thématique. Les avantages des différentes approches sont évidents, mais il ne faut pas sous-estimer les difficultés techniques et organisationnelles pour mettre sur scène l’un ou l’autre de ces
scénarios. L’organisation retenue est basée sur l’unité de traduction (chacun
des sept groupes thématiques étant composé de onze unites linguistiques). Ainsi, la base locale est celle de l’unité. En effet, c’est au sein de l’unité que les bénéfices sont le plus directement visibles pour le traducteur, et que la collaboration est la plus facile à mettre en place. La base locale est logée sur le serveur auquel sont raccordés tous les
membres de l’unité. Le programme d’application, de son côté, réside sur l’ordinateur personnel individuel pour ne pas alourdir le réseau et ralentir inutilement la saisie et le traitement des informations. Un mécanisme de verrouillage et le système de masques personnalisés empêchent l’écrasement mutuel d’informations par des utilisateurs différents. De cette façon, une fiche préparée par un traducteur est instantanément
accessible à tous les collègues de son unité et, partant, à ceux des
utres unités qui souhaitent interroger la base en lecture. Les traducteurs sont donc amenés à utiliser une même base locale selon une méthodologie commune (picklists pour les informations structurelles telles que domaines, projets, etc).
Le gestionnaire de cette base locale décide ensuite d’organiser la validation des données et leur exportation, dans la mesure du possible, vers la base centrale EURODICAUTOM où les données seront alors accessibles à tout le SdT et au monde extérieur. Lors de l’exportation vers EURODICAUTOM, un programme se charge alors de convertir les fiches du format MULTITERM vers le format d’EURODICAUTOM. Il est
prévu de pouvoir convertir tous les champs exportés: en particulier, les champs de gestion de MULTITERM sont repris en note dans EURODICAUTOM, accompagnés des balises appropriées. La numérotation des synonymes et des sources est générée
automatiquement et figure dans EURODICAUTOM entre crochets. Le programme de conversion vérifie prioritairement la conformité des données à la syntaxe permise et détecte des erreurs éventuelles, par exemple l’utilisation de certains signes et symboles comme les parenthèses, le point-virgule et la barre oblique dont la présence dans le
champ vedette perturberait la réutilisation des données dans d’autres outils.
Le niveau traducteur ou unité permet une saisie rapide des données et un partage instantané entre collègues impliqués dans la traduction de documents du même type, facilite l’affinage progressif de l’information et le recours à une même terminologie harmonisée. Toutefois, pour garantir une optimisation de la redistribution et de la réutilisation de ce travail, il est impératif de consolider et de multilinguiser les données afin de les rendre accessibles à tous, y compris aux collaborateurs freelance, à travers la base centrale de diffusion EURODICAUTOM. Il est essentiel que les données transférées à un autre niveau de diffusion ne vivent plus dans la base locale. A cet égard, une bonne collaboration entre les unités de traduction et les unités à tâches horizontals (Terminologie et Coordination linguistique) est indispensable.
7 La recherche
D’après l’objectif du projet énoncé plus haut, la saisie locale de la terminologie ne constitue qu’un premier maillon dans la chaîne à mettre sur pied. Il s’entend en effet que le traducteur ne peut en aucun cas dissocier la recherche des termes émanant de son unité des autres recherches terminologiques. Les macros de consultation, à lancer à
partir du traitement de texte, essaient ainsi de combiner l’interrogation de la base locale avec celle de la base centrale. Les différences des écrans proposés en cas de trouvaille, et celles des touches de function requises pour réaliser p ex la coupe et colle sont évidemment un obstacle majeur qu’il s’agit de surmonter. La consultation en ligne doit
naturellement être complétée par un mode d’interrogation en lots. Dans le cadre du projet EURAMIS, il est permis de rechercher d’une façon ciblée dans EURODICAUTOM la terminologie d’une liste ou d’un document envoyé par le biais de l’interface et de la récupérer en format d’importation MULTITERM (voir l’article de FONTENELLE / MERGEN: “Les interfaces terminologiques au SdT, p 210)”.
8 Conclusion
Tout au long du développement de ce projet à longue haleine, il a fallu tenir compte des aspects les plus variés, à savoir des objets à traiter (données terminologiques, phraséologiques, abréviations), des supports (logiques et physiques), des acteurs (traducteurs, secrétaires, terminologues), des types de traitement (production, gestion), des niveaux d’intervention (individuel, unité, groupe, unités horizontales). Seul l’équilibre entre ces différents aspects a permis d’aboutir à des solutions acceptées par tous les intervenants
CARLO MERGEN
Commission européenne
Service de traduction
Carlo.Mergen@sdt.cec.be
