"Down-to-earth Terminology" Une nouvelle approche pour intégrer la gestion de la terminologie dans la traduction automatique à Autodesk

Transcription

1 Master "Down-to-earth Terminology" Une nouvelle approche pour intégrer la gestion de la terminologie dans la traduction automatique à Autodesk FREUND, Kirsten Magdalena Abstract Ce travail vise à décrire et analyser l'approche d'automatisation pour intégrer la gestion de la terminologie dans la traduction automatique mise en place lors de l'initiative "Terminologie terre-à-terre" à Autodesk. Il comprend une étude de cas détaillée, incluant une enquête auprès des traducteurs, ainsi qu'une évaluation systématique des résultats de l'initiative à l'aide de l'indice de Cohérence Terminologique introduit par Itagaki et al. en This paper describes and analyses the automation approach aimed at integrating the terminology management into machine translation that has been put into place as part of the Down-to-earth Terminology Initiative at Autodesk. It includes a detailed case study, part of which is a translator survey, as well as a systematic evaluation of the initiative's results by means of the Terminology Consistency Index proposed by Itagaki et al. in Reference FREUND, Kirsten Magdalena. "Down-to-earth Terminology" Une nouvelle approche pour intégrer la gestion de la terminologie dans la traduction automatique à Autodesk. Maîtrise : Univ. Genève, 2014 Available at: Disclaimer: layout of this document may differ from the published version. [ Downloaded 05/07/2016 at 11:21:02 ]

2 Kirsten Magdalena Freund «Down-to-earth Terminology» Une nouvelle approche pour intégrer la gestion de la terminologie dans la tradu ction automatique à Autodesk Directrice : Pierrette Bouillon Juré : Mirko Plitt Mémoire présenté à la Faculté de traduction et d interprétation (Département de traitement informatique multilingue) pour l obtention de la Maîtrise universitaire en traduction, mention technologies de la traduction Semestre de printemps 2014 / Session extraordinaire Université de Genève

3 1

4 Sommaire 1 Introduction Hypothèses et plan du travail La traduction automatique Introduction Typologie de systèmes Le moteur de traduction automatique statistique «Moses» Les composants principales : le pipeline d entraînement et le décodeur Le processus de traduction avec le modèle de traduction à base de séquences de mots Conclusion La traduction automatique statistique et la terminologie Introduction Le rôle de la terminologie dans le domaine de la traduction automatique statistique Projets de recherches sélectionnés Conclusion Outils de terminologie employés dans la post-édition par Autodesk Introduction La localisation à Autodesk, ses techniques et outils principaux L ancien processus de terminologie Extraction des termes Traduction et mise à disposition des termes Les bases de données terminologiques existantes Évaluation des bases de données terminologiques existantes Rappel : complétude des bases de données Précision : pertinence de termes

5 4.5.3 Résultats des évaluations Enquête sur l usage des outils de terminologie d Autodesk Les résultats de l enquête, par outil Conclusion Nouvelle approche d intégration de la terminologie dans la TA à Autodesk Introduction Préliminaires du nouveau processus de terminologie Extraction automatique de terminologie La pré-traduction de terminologie L intégration de la terminologie dans «Moses» Conclusion et mise en perspective Analyse : l efficacité de la nouvelle approche de terminologie d Autodesk Introduction Mesurer la cohérence terminologique L indice de cohérence terminologique Analyse : le TCI Les données analysées et leur préparation L extraction des «termes» Calcul du TCI et résultats Contraintes Conclusion Conclusion Références Figures Annexe

6 4

7 1 Introduction L unité «Language Technologies», qui fait partie du département de «Localization Services» de la société Autodesk, s est spécialisée en traduction automatique et développe depuis plusieurs années un système de traduction automatique statistique open source. Suite à une restructuration récente, il s est révélé nécessaire de réorganiser la gestion de la terminologie d Autodesk. À cette fin, l unité «Language Technologies» a développé et piloté une nouvelle approche d automatisation pour intégrer la gestion de la terminologie dans la traduction automatique. En tant que stagiaire au sein d Autodesk, j ai accompagné de près le passage au nouveau processus de terminologie, mené des enquêtes pour évaluer l usage des outils terminologiques auprès des traducteurs et analysé les outils terminologiques de l ancien processus pour évaluer leur efficacité. Deux aspects m ont particulièrement intéressée : 1) L estimation de la mesure dans laquelle les traducteurs qui travaillent pour Autodesk utilisent réellement les outils de terminologie mis à leur disposition ; 2) L évaluation de l impact, sur la qualité et en particulier sur la cohérence terminologique des textes traduits, du nouveau processus et des changements effectués suite à la restructuration. L objet de ce mémoire est donc la description, l étude, ainsi que l analyse de l approche d automatisation et d intégration de la gestion de la terminologie d Autodesk. 1.1 Hypothèses et plan du travail Avant la restructuration, la gestion de la terminologie à Autodesk était assurée par l équipe «TQLM» et incluait un processus pour établir et maintenir des «glossaires» et des bases de données terminologiques multilingues dans le système de gestion de contenu global (GCMS) de l entreprise. Dans ce contexte, les nouveaux candidats-termes étaient d abord extraits automatiquement des nouveaux textes au début des projets de localisation. Ensuite, la liste des candidats était nettoyée manuellement par un linguiste spécialisé, puis traduite par les linguistes spécialisés respectifs vers les langues requises. Les termes sélectionnés et leurs traductions 5

8 étaient enfin stockés dans une base de données terminologique faisant partie du GCMS et mise à disposition des responsables de projets et des traducteurs employés par Autodesk. Le but global de ce processus était de garantir la cohérence terminologique. Même si l équipe en charge de la terminologie suivait des processus assez précis, il ne s agissait pas d une gestion de «terminologie» au sens propre. Les bases de données terminologiques n étaient pas maintenues de manière systématique ; il n y avait pas de définition standardisée des termes ou de leurs propriétés, etc., comme nous le verrons dans le chapitre 4. Suite à une réduction importante du personnel incluant l équipe «TLQM» («Terminology and Language Quality Management»), l unité «Language Technologies», qui avait reçu comme mission d'automatiser autant que possible les anciennes activités de «TLQM», a décidé de monter un projet visant une automatisation plus poussée du processus d extraction de terminologie et une intégration de la terminologie dans la traduction automatique. Cette nouvelle approche devait à long terme combler certaines lacunes de l ancien processus, dont le caractère statique était de moins en moins en phase avec le cycle de vie du contenu source et dont l étendue était délibérément partielle puisque limitée au contenu software. Un autre effet visé, mais plutôt «secondaire», était l amélioration de la traduction automatique statistique. Le défi auquel l unité «Language Technologies» devait faire face n est pas rare dans le secteur de la localisation. L importance d une gestion de terminologie est largement reconnue de nos jours, mais la réaliser de manière efficace et économique est difficile. Ce qui est original et novateur dans l approche d Autodesk, c est l idée de fusionner terminologie et traduction automatique statistique. Ce travail peut servir d exemple pour d autres entreprises et guider aussi la recherche quand il s agit d améliorer et de façonner des systèmes de traduction statistique, même si les conditions et circonstances précises qui ont permis à Autodesk de déployer une telle approche en peu de temps et à faible coût sont assez uniques. L unité disposait en effet de son propre moteur de traduction automatique, d un grand corpus bien géré et de connaissances techniques pour développer les outils nécessaires et les intégrer dans le moteur de traduction automatique, etc.. 6

9 Comme annoncé, le but de ce mémoire est de décrire, d étudier et d analyser l approche d Autodesk. Pour ce faire, notre travail comprend une partie théorique visant à introduire les bases (chapitres 2 et 3), une partie plutôt descriptive (chapitres 4 et 5) et une partie analytique (chapitre 6). Dans le chapitre 2, nous situerons l approche dans le contexte, à savoir la traduction automatique. Nous rappellerons la typologie de systèmes (section 2.2) et présenterons en détail le moteur de traduction automatique statistique «Moses», le système utilisé par Autodesk (section 2.3), avec ses composantes principales (section 2.3.1) et son modèle de traduction à base de séquences de mots (section 2.3.2). Dans le chapitre 3, nous nous pencherons sur le rôle de la terminologie dans la traduction automatique statistique. Nous regarderons de plus près le rôle de la terminologie dans la TA (section 3.2) et présenterons ensuite des articles de recherche sélectionnés traitant de projets qui intègrent la terminologie dans la traduction automatique statistique (section 3.3). Dans le chapitre 4, nous présenterons le cas d Autodesk. Nous décrirons la localisation dans cette entreprise et ses techniques et outils principaux (section 4.2). Nous regarderons l ancien processus de terminologie (section 4.2) : l extraction des termes (4.3.1), ainsi que leur traduction et leur mise à disposition (4.3.1). Ensuite, nous présenterons les bases de données terminologiques existantes (section 4.4) pour les évaluer à l aide des mesures de «rappel» et de «précision» (section 4.5). Enfin, nous présenterons les résultats d une enquête menée auprès des traducteurs concernant l usage d outils de terminologie mis à disposition par Autodesk (section 4.6) et nous indiquerons les conclusions à en tirer (section ). Dans le chapitre 5, nous nous focaliserons sur la nouvelle approche mise en place par l unité «Language Technologies» pour intégrer la terminologie dans la traduction automatique. Nous décrirons ce qui a mené à la mise en œuvre de ce nouveau processus (section 5.2) et expliquerons en détail l extraction automatique de terminologie (section 5.3), ainsi que la solution mise en place pour faciliter la pré-traduction de la terminologie 7

10 par les linguistes/traducteurs spécialisés (section 5.4). Enfin, nous montrerons comment la terminologie est intégrée dans le système «Moses» (section 5.5). Dans le sixième et dernier chapitre, nous reviendrons sur la question de l impact du nouveau processus et procéderons à une analyse de son efficacité. Nous établirons l importance de la cohérence terminologique et de sa mesure pour le cas d Autodesk (section 6.2) et présenterons un indice de cohérence terminologique (section 6.3). Ensuite, nous appliquerons cet indice pour mesurer la cohérence des quatre produits «Autodesk», «Revit», «AutoCAD Mechanical», «AutoCAD Electrical» et «AutoCAD Architecture» avant et après l introduction du nouveau processus de terminologie, afin d évaluer l impact des changements opérés (section 6.4). 8

11 2 La traduction automatique 2.1 Introduction Ce chapitre a pour objectif de situer et mettre en perspective l approche d automatisation et d intégration de terminologie mise en place à Autodesk. Nous allons d abord parcourir les différents types de systèmes de traduction automatique (TA) (section 2.2). Ensuite nous présenterons les composantes principales de «Moses», le système de traduction automatique statistique (TAS) utilisé à Autodesk (section 2.3). 2.2 Typologie de systèmes Avant de nous pencher sur le système «Moses» lui-même, nous aimerions le situer dans le vaste champ que représente aujourd hui la traduction automatique (TA). Nous ne parcourrons pas de manière exhaustive l histoire de la TA, qui est présentée de manière très complète dans la littérature (cf. KOEHN 2010, 14 et suiv. ; HUTCHINS et SOMERS 192, 5 et suiv. ; etc.) ; nous mettrons plutôt l accent sur ce qui, dans cette histoire, nous semble important pour mieux comprendre l approche employée à Autodesk. Traditionnellement, on distingue les systèmes directs, de transfert et par interlangue parmi les premiers systèmes de TA qui ont émergé à partir des années 1950 et 1960 (cf. KOEHN 2010, 15 ; HUTCHINS et SOMERS 1992, 4 ; BOUILLON et CLAS 1993, 16). Peu à peu la distinction s est faite entre les systèmes de Traduction Automatique à Base de Règles (TABR) et les systèmes de Traduction Automatique à Base de Corpus (TABC). Aujourd hui, les frontières entre TABR et TABD s estompent de plus en plus avec des approches hybrides qui cherchent à les combiner. De manière générale, la TABR se fonde sur des connaissances linguistiques et regroupe les successeurs des systèmes directs, de transfert et par interlangue. Les systèmes directs n analysent pas la syntaxe du texte source et produisent une traduction mot à mot, en cherchant les traductions dans une liste d équivalence. Les systèmes de transfert transposent la langue source dans une représentation intermédiaire (étape appelée analyse) qui à son tour est transformée dans une représentation adéquate pour la langue 9

12 cible (étape appelée transfert) à partir de laquelle on génère la langue cible (étape de génération). Les systèmes par interlangue représentent le sens de la phrase à traduire dans un langage neutre indépendant des langues naturelles. La traduction se fait en deux étapes : de la langue source à l interlangue et de l interlangue à la langue cible (cf. BOUILLON 1993, 16). La TABC se passe de règles linguistiques. Elle englobe les systèmes à base d exemples et les systèmes de traduction statistique. La traduction automatique à base d exemples (TABE) utilise des phrases similaires, des exemples puisés dans un corpus parallèle pour produire une traduction par analogie. La traduction automatique statistique (TAS) utilise des corpus, des textes mono- et bilingues, pour trouver la traduction la plus probable d une phrase ou d une séquence de mots. Étant donné que la TAS se fonde sur des probabilités, elle était et est toujours plutôt développée par des informaticiens linguistes (cf. BOUILLON 1993, 16 ; KOEHN 2010, 17 et suiv.). Les tout premiers essais de TA étaient des approches de TAS, qui, faute de machines suffisamment performantes, ont été abandonnées pour des systèmes de TABR. Les systèmes TAS ne sont donc pas nouveaux : ce sont plutôt des revenants (cf. cours sur la traduction automatique donné par BOUILLON, Université de Genève, 2013). La recherche sur les systèmes TAS a (re)commencé dans les années 1990, même si la majorité des systèmes commerciaux étaient encore basés sur des règles. Ce n est qu à partir des alentours de l année 2000 que la TAS s est répandue. Google Translate et Bing Translator (Microsoft) en sont aujourd hui les exemples phares. Deux facteurs ont contribué au succès de la TAS : d abord l accroissement des capacités techniques, en particulier quant à la performance des ordinateurs et aux possibilités en stockage de données ; ensuite l avènement d internet, qui permet l accès instantané à de vastes corpus (cf. KOEHN 2010, 17-18). 10

13 Pour traduire, un système de TAS se fonde sur un modèle de langage et un modèle de traduction. À partir des probabilités calculées à l aide du corpus monolingue, le modèle de langage détermine si une séquence de mots est fluide, c est-à-dire naturelle et formellement juste, dans la langue donnée. Le modèle de langage se base sur des n-grammes. Un n- gramme est une séquence de n éléments extraits d un texte, par exemple un bi-gramme consiste en une séquence de deux mots. Un modèle n-gramme indique aussi la probabilité que n-1 mots soient suivis par un n e mot (par exemple, pour un tri-gramme la probabilité que «this is» soit suivi de «correct», etc.). Le modèle de traduction, de son côté, détermine, à partir des probabilités calculées à l aide du corpus bilingue, si une traduction d une séquence de mots est fidèle, c est-à-dire si la séquence cible correspond au mieux au contenu de la séquence source (cf. cours sur la traduction automatique donné par BOUILLON, Université de Genève, 2013.) Les probabilités qu une séquence de la langue source soit traduite par une autre de la langue cible sont répertoriées dans le tableau de traduction («translation table» ou «T-table», cf. Figure 1). Figure 1. Exemple d un «T-table» simple : tableau de probabilité d'une traduction lexicale pour quatre mots allemands vers l anglais (Source: KOEHN 2010, 84). «Moses», le système de TAS utilisé à Autodesk, est un système de TAS. Nous le décrirons plus en détail par la suite. 2.3 Le moteur de traduction automatique statistique «Moses» Le système «Moses» fut présenté au public pour la première fois en 2007 par KOEHN et al. lors de la réunion annuelle de l «Association for Computational Linguistics» (ACL) à 11

14 Prague (KOEHN et al. 2007). À plusieurs reprises, le développement de «Moses» a été soutenu par l Union Européenne. «Moses» représente une «boîte à outils» de TAS, en open source et prête à l emploi. Cette boîte à outils contient tous les éléments pour préparer les données, entraîner les modèles de traduction et de langage, ainsi que les régler (cf. KOEHN 2007, 178). Les deux composantes principales du système sont le pipeline d entraînement («training pipeline») et le décodeur («decoder»). La «boîte à outils» inclut aussi des logiciels supplémentaires pour améliorer et faciliter la traduction automatique, par exemple pour rendre possible la traduction de sites web, ce qui en fait un outil assez performant et populaire. Les sections suivantes décriront les composantes principales de «Moses», le pipeline d entraînement et le décodeur ; elles se fondent essentiellement sur KOEHN, Moses User Manual Les composants principales : le pipeline d entraînement et le décodeur Le pipeline 1 d entraînement, qui consiste en plusieurs outils différents, sert à construire le modèle de traduction à partir des corpus. «Moses» permet aussi d ajouter des outils externes au pipeline. Dans un premier temps, les données des corpus doivent être préparées (segmentation, conversion en typographie standard, etc.), alignées et nettoyées. On reçoit ce qui est souvent appelé des «bi-textes». Puis, les bi-textes sont alignés au niveau des mots ; pour ce faire, la bibliothèque de «Moses» propose l outil «GIZA++», une extension de «GIZA» (issu du «Center for Language and Speech Processing» de l Université Johns-Hopkins), développé par Franz Josef OCH, mais d autres outils peuvent aussi être utilisés. Les données alignées au niveau des mots permettent soit l extraction des traductions séquence par séquence (modèle de traduction à base de séquences de mots), soit celle de règles hiérarchiques (modèle de traduction en arbre) pour le calcul des probabilités. «Moses» 1 En informatique, le mot «pipeline» désigne un ensemble d éléments destinés au traitement de données mis en série. La sortie d un élément est l entrée du prochain, et ainsi de suite. 12

15 permet aussi une troisième forme de modèle de traduction, la traduction factorisée («factored translation»), où des informations linguistiques sont ajoutées au modèle de traduction à base de séquences de mots. La configuration de «Moses» employée à Autodesk utilise un modèle de traduction (non-factorisé) à base de séquences de mots («phrase-based translation model»). Pour ce qui est du modèle du langage, «Moses» se base sur des outils externes qui sont repris par le décodeur. Le décodeur est une application C++ qui va, à l aide du modèle de traduction issu du pipeline et du modèle de langage récupéré, effectuer la traduction proprement dite de la phrase source vers la phrase cible. Sa tâche principale est de trouver la traduction la plus «fidèle» dans la langue cible pour la phrase source selon le modèle de traduction et de trouver la phrase la plus «fluide» dans la langue cible selon le modèle de langage (cf. aussi les explications sur les systèmes TAS, p. 8). Le décodeur de «Moses» utilise un algorithme de recherche en faisceau («beam search algorithm») pour satisfaire à ces deux objectifs et trouver la meilleure traduction (pour les détails, cf. KOEHN, Moses User Manual, 251). Le décodage est d abord un problème de recherche, et «Moses» se base sur des stratégies différentes, dites heuristiques 2, pour effectuer cette recherche le plus efficacement possible. Le processus de décodage de «Moses» est modulaire et peut être adapté. Il est aussi possible d ajouter des traits («features») au décodeur avec des informations supplémentaires, une fonctionnalité qui sera utilisée pour faire marcher le nouveau processus de terminologie à Autodesk Le processus de traduction avec le modèle de traduction à base de séquences de mots L idée de base d une approche à base de séquences de mots est de segmenter la phrase à traduire, traduire les séquences et composer la phrase cible à partir des séquences traduites. Le modèle de traduction à base de séquences de mots (MBSM) utilisé par 2 En informatique, la recherche heuristique désigne une recherche combinatoire qui sert à résoudre un problème complexe de manière rapide et qui emploie pour se guider des informations supplémentaires, puisées dans le savoir ou bien dans des principes de bases (cf. RAPHAEL et SMITH 2013, 204, ainsi que CHRISLEY et BEGEER 2000, 44). 13

16 «Moses» a été proposé par KOEHN et al Le MBSM se base sur le modèle du canal bruyant, un modèle commun en linguistique informatique qui sert à trouver le mot d origine à partir d un mot brouillé sous une forme quelconque en passant par un canal bruyant («noisy channel»). KOEHN décrit la logique de son application en traduction automatique comme suit : We can also apply the noisy channel model to the translation problem. Somewhat presumptuously, we assume that the foreign speaker actually wanted to utter an English sentence, but everything got distorted in a noisy channel and out came a foreign sentence. (KOEHN 2010, 96) Le MBSM utilise le modèle de canal bruyant pour combiner son modèle de traduction, p(f e), et le modèle de langage, p(e). Le but est de trouver la traduction la plus probable, (e), parmi toutes les possibilités, (argmaxe), pour une phrase donnée, (f). Pour ce faire, le modèle applique le théorème de Bayes 3 pour inclure p(e) : argmaxe p(e f) = argmaxe p(f e) p(e) Le processus de traduction selon le MBSM consiste en trois étapes principales : la segmentation de l entrée en séquences de mots : (f) est segmentée en séquences (f i ) la traduction des séquences sources vers les séquences cibles : (f i ) est traduit vers (e i ) si nécessaire, la réorganisation de l ordre de mots dans la sortie, selon un modèle basé sur la distance qui la décourage en lui attribuant un coût 4 : p(f e) est décomposé en p (f 1 I e1 I ) = I i=1 (fi e i ) d(start i end i 1 1), où (start i end i 1 1) est la distance et d le coût de réorganisation 5. 3 Le théorème de Bayes exprime des probabilités conditionnelles : étant donnés deux évènements X et Y, on peut déterminer la probabilité de X sachant Y, si l on connaît les probabilités de X, de Y et de Y sachant X. 4 Le modèle de réorganisation basé sur la distance («distance-based reordering model»), aussi appelé modèle de distorsion, est le modèle de réorganisation par défaut de «Moses», mais il est pas très efficace et est donc souvent remplacé par des modèles dits «lexicalisés» (cf. KOEHN, Moses User Manual, 64). 5 Pour des raisons de simplification, voir KOEHN 2010, p pour les détails du modèle et un exemple. 14

17 Afin de régler la longueur de la sortie et augmenter la performance, un facteur ω («coût de mots») est ajouté en plus du modèle de langage qui est un modèle tri-gramme (plm). En résumé, la meilleure phrase traduite (ebest) rendue pour une phrase source (f) selon le MBSM est 6 : ebest = argmaxe p(e f) = argmaxe p(f e) plm(e) ω longueur(e) 2.4 Conclusion Ce chapitre prépare à la description de l approche d automatisation et d intégration de terminologie d Autodesk en la contextualisant. Nous avons d abord esquissé une typologie de systèmes de traduction linguistique (systèmes directes, de transferts et par interlingue) et à base de corpus (systèmes à base d exemples et de traduction statistique). Ensuite, nous avons vu comment fonctionne le système open source de traduction automatique à base de corpus voire statistique utilisé par Autodesk, «Moses». Nous avons exploré les composantes principales de «Moses», le pipeline d entraînement qui construit le modèle de traduction et le décodeur qui effectue la traduction à partir de ce premier modèle et du modèle de langage. Nous avons aussi vu que la configuration employée à Autodesk utilise un modèle de traduction non-factorisé à base de séquences de mots et donc présenté brièvement les trois étapes du processus de traduction avec le modèle de traduction à base de séquences de mots (segmentation, traduction, réorganisation) qui a pour but de trouver la traduction la plus probable pour une phrase donnée. Ces connaissances nous seront fort utiles, voire indispensables, au cours de ce mémoire, particulièrement quand nous allons décrire les aspects techniques de l intégration de la terminologie dans «Moses» à Autodesk (section 5.5). Mais avant de nous pencher sur le cas particulier d Autodesk, nous aimerions encore mettre en lumière quelques aspects plus généraux de l état de la recherche. 6 Pour plus de détails sur ces explications assez techniques et le MBSM, voir KOEHN 2010, 69 & 95, ainsi que KOEHN, Moses User Manual,

18 3 La traduction automatique statistique et la terminologie 3.1 Introduction Ce chapitre est un parcours de la littérature et la recherche pertinentes pour notre travail. Il est organisé en deux parties. D abord, nous examinerons la position de la terminologie dans le domaine de la traduction automatique (section 3.2). Ensuite, nous présenterons, à titre d exemple, quatre projets de recherche qui intègrent la terminologie dans la traduction automatique statistique (section 3.3). 3.2 Le rôle de la terminologie dans le domaine de la traduction automatique statistique Depuis quelque temps déjà, la terminologie 7 est devenue un sujet important dans les études et recherches scientifiques en traduction. De nombreux manuels ont été publiés et le métier de terminologue est devenu une profession à part entière. De plus, des connaissances méthodiques en terminologie sont de plus en plus attendues des traducteurs professionnels. En ce qui concerne les outils, les applications informatiques de la terminologie font aussi partie intégrante des technologies de traduction. Actuellement, la recherche en terminologie informatique (appelée «computational terminology» par BOURIGAULT et al., 2002.) se penche principalement sur les extracteurs automatiques des termes et les systèmes de gestion de terminologie (banques/bases terminologiques). La terminologie est également cruciale pour la traduction automatique du moins quand celle-ci est censée traduire des textes spécialisés : 7 La littérature différencie souvent la terminologie de la terminographie : «La terminographie regroupe les diverses activités d acquisition, de compilation et de gestion des termes. La terminologie se penche sur les questions fondamentales que soulève l étude des termes et propose un cadre conceptuel pour les appréhender» (cf. L HOMME, 2004, p. 15). Tandis que cette distinction semble adéquate pour les sciences de terminologie, elle semble être moins pertinente pour les employés et free-lancers dans le secteur de traduction et localisation qui appliquent la terminologie dans leur travail quotidien. En pratique, on y parle toujours de «terminologie». Nous resterons donc dans la logique des praticiens et parlerons de «terminologie» pour désigner un sujet que les terminologues qualifieraient plutôt de «terminographie» : la gestion des termes spécialisés d un domaine spécifique afin d améliorer et d assurer la qualité des traductions. 16

19 En fait, une des premières tâches du traducteur est souvent celle de la recherche terminologique; étape souvent prise en charge dans les organismes de traduction par des traducteurs terminologues (Langlais et al., 2001). Il semble donc naturel d un point de vue utilisateur d ouvrir un système de traduction à des ressources terminologiques existantes (ou lexiques terminologiques dans la suite). (LANGLAIS 2002, 49) Une telle approche ne permettrait pas seulement d exploiter au mieux les ressources terminologiques existantes, mais aussi d améliorer la qualité de la traduction automatique. La traduction automatique en tant que technologie de traduction se développe aujourd hui rapidement, soit accompagnée de post-édition (l édition de traductions automatiques brutes par des humains), soit dans des situations où une traduction «parfaite» n est pas requise et où il s agit plutôt de comprendre l essence d un texte en langue étrangère. Le succès et la demande croissante pour la traduction automatique pousse les recherches dans ce domaine. Cependant, on ne discute encore que peu du lien entre traduction automatique et terminologie spécialisée. Dans les systèmes de TABR, le rôle de la terminologie est généralement évident. Ces systèmes disposent, en plus de grammaires (quelle qu en soit la forme), de «dictionnaires» qui, dans la plupart des cas, peuvent être alimentés de vocabulaire supplémentaire pour les spécialiser. En conséquence, du point de vue technique, l intégration et le respect d une terminologie spécialisée dans un tel système est plus ou moins facile. Une fois la terminologie répertoriée dans les dictionnaires, le système l applique de façon cohérente. Bien sûr, il y a aussi des défis, mais ils relèvent souvent plutôt de la linguistique, comme la délimitation de l unité lexicale (cf. FONTANELLE et al. 1993, 364 et suiv. qui présentent l exemple d un système de transfert appelé «METAL»), ou bien les divergences et décalages entre les langues (cf. HEID 1993, 173 et suiv.). Dans les systèmes statistiques, la question de la terminologie se pose différemment. La traduction dans ces systèmes étant basée sur des probabilités, un mot de la langue source ne se traduira pas toujours par le même mot dans la langue cible. Comme nous l avons vu, le système de traduction automatique utilisé par Autodesk, «Moses», se fonde sur des séquences de mots, et non pas sur des mots isolés. Selon le corpus exploité pour l entraînement et la séquence des mots à traduire, le même mot peut donc se traduire de 17

20 différentes manières. Bien que la TAS ait eu beaucoup de succès récemment et, au moins en ce qui concerne la langue générale, obtienne souvent des résultats supérieurs, la question de la terminologie en général, et en particulier celle de savoir comment intégrer une terminologie spécialisée dans la TAS, ne figurent pas vraiment parmi les priorités des chercheurs ou des praticiens du domaine. Pourtant, des initiatives, quoique dispersées, ont bel et bien eu lieu, qui ont tenté de répondre à ces questions. Nous allons en présenter quelques-unes (nous ne prétendons pas ici à l exhaustivité). Cela nous permettra de mieux situer l approche que nous décrirons par la suite. 3.3 Projets de recherches sélectionnés Partant de l observation que des bases de données terminologiques bilingues peuvent améliorer la performance d un système TAS, CARL et LANGLAIS (2002) présentent une «base de données terminologique intelligente» qui est capable de détecter des termes et leurs variantes et de régénérer les termes cibles autorisés. La base de données terminologique intelligente (BTI) se fonde sur un outil de terminologie monolingue développé auparavant par LANGLAIS. Il consiste dans un formalisme à base de règles et un système de traduction basé sur des exemples. La BTI présuppose une terminologie bilingue avec des termes non-ambigus. Les variantes des termes sont générées par le formalisme à base de règles dans un processus d «abduction» (opposé à l induction) 8 et stockées dans une base de données. Par le mot «variante», CARL et LANGLAIS endentent plusieurs phénomènes : la variation par omission (par exemple : «general purpose weapons oil» = huile polyvalente pour armes ; huile polyvalente), la variation par insertion (par exemple : «prone position» = position couchée ; «prone supported position» = position du tireur couché) et le synonyme (par exemple : «spotting telescope» ; «spotting scope» = lunette d observation). Le système de traduction basé sur des exemples identifie les termes et leurs variantes dans des textes selon les entrées de la base de données. Dans une deuxième expérience, CARL et LANGLAIS ont intégré la BTI dans un système TAS développé 8 CARL et LANGLAIS se réfèrent à Raymond Mooney qui présente une approche pour intégrer l abduction et l induction dans l apprentissage automatique (cf. CARLS et LANGLAIS 2002, 4). 18

21 auparavant par LANGLAIS. La BTI identifie et marque les termes et leurs variantes dans le texte source et régénère les termes cibles autorisés. Les termes cibles sont annotés dans le texte source et ceci est traité par le système TAS ; tandis que la position du terme cible est décidée par le système TAS, sa forme est donc générée par la BTI, dans l alignement cible. CARL et LANGLAIS ont calculé pour deux textes (SNIPER2 et SNIPER3) le taux d'erreur de mots (word error rate = WER) et le taux d'erreur de phrases (sentence error rate = SER) de leur moteur de traduction sans terminologie ajoutée («WITHOUT»), avec terminologie ajoutée («T») et avec terminologie et variantes ajoutées («T+A») (pour une brève explication des mesures automatiques, cf. section 6.2 ; pour les résultats de calcul de CARL et LANGLAIS, cf. Figure 2). Figure 2. Résultats de la traduction automatique après et avant application de la BTI (Source : CARL et LANGLAIS 2002, 21). Après l ajout de la terminologie, ils observent une amélioration importante du WER (SNIPER2 : 77,1 au lieu de 82,9 ; SNIPER3 : 79,4 au lieu de 82), mais l ajout de terminologie et de variantes n améliore encore davantage le WER que de l un des deux textes, et seulement dans une faible mesure (SNIPER2 : 76,6 au lieu de 77,1 ; SNIPER3 : toujours 79,4). CARLS et LANGLAIS concluent donc que la BTI montre de bons résultats, mais qu il faut encore réviser et modifier l interaction des deux systèmes, BTI et TAS, ainsi que réduire le bruit de la BTI et augmenter sa couverture. OKUMO et al. (2008) ont proposé une méthode pour intégrer un dictionnaire dans un système TAS basé sur des séquences de mots. Au lieu d ajouter des paires de termes et leurs traductions dans le tableau de traduction avec des probabilités appropriées (les mots non-entraînés causeraient alors des problèmes d ordre de mots, surtout si l ordre des mots de la langue source s avérait très différent de celui de la langue cible), OKUMO et al. présentent un algorithme pour remplacer des termes dans le texte source avec des mots de 19

22 haute fréquence dans le corpus d entraînement qui appartiennent à la même catégorie et substituer ces mots de haute fréquence dans le texte traduit par des termes cibles. L idée est que les mots de haute fréquence seraient bien représentés dans le tableau de traduction du système TAS. Toutefois, les mots de haute fréquence doivent appartenir à la même catégorie (p. ex. «lieu-nom») que les mots non-entraînés qu ils remplacent, afin qu ils partagent avec eux le même contexte. En détail, le processus de traduction selon OKUMO et al. (2008) se caractérise comme suit (cf. Figure 3). Tout d abord, le mot non-entraîné «kadifu» est remplacé, dans la phrase source, par le mot de haute fréquence et bien entraîné «nyuyoku». «kadifu» et «nyuyoku» appartiennent à la même catégorie «lieunom». Ensuite, la phrase modifiée entière est traduite et la phrase cible acquise. Enfin, le mot traduit «new york» est cherché dans la phrase cible et le mot de haute fréquence «new york» est remplacé par «cardiff». Pour évaluer leur méthode, OKUMA et al. l ont comparée aux résultats d une TAS avec des paires de termes ajoutés dans le tableau de traduction pour une traduction entre l anglais et le japonais et vice-versa, et constatent que leur méthode engendre un score BLEU supérieur. En même temps, OKUMA et al. remarquent qu ils se sont limités aux substantifs, qu ils ont utilisé un corpus de test trop limité et qu il faudrait automatiser la catégorisation des mots. Figure 3. Processus de traduction selon OKUMO et al. (2008) (Source : OKUMO et al. 2008, 2053). ITAGAKI et AIKAWA (2008) ont développé un prototype, appelé «Term Swapper», pour échanger automatiquement des traductions de mots avec des termes prédéfinis dans 20

23 l output d un système TAS. Le «Term Swapper» ne touche pas au processus de TAS, mais se base sur des modèles linguistiques, similaires à des règles, pour reconnaître les termes à changer dans les traductions d un TAS. IRAGAKI et AIKAWA ont testé le «Term Swapper» avec 500 phrases d un jeu vidéo et leurs traductions vers le japonais, chinois et coréen. Il y avait quelques termes qui n étaient pas changés, ce qu ils attribuaient au fait que la sortie du TAS était déjà fautif. Malgré ceci, ils ont mesuré une amélioration importante de qualité de la paire anglais japonais en utilisant le score BLEU et l indice de distance d édition «basé sur des caractères 9». Mais ITAGAKI et AIKAWA notent aussi que le «Term Swapper» obtient des résultats plus faibles avec d autres systèmes TAS que celui utilisé dans leur test, que les modèles ne seraient pas encore «parfaits», qu il faudrait les tester avec d autres langues, avec d autres caractéristiques linguistiques, et que finalement, on devrait aussi étendre la couverture des modèles à d autres POS que les substantifs. Contrairement à OKUMO et al., ITAGAKI et AIKAWA n expliquent pas pourquoi ils ont choisi une méthode qui applique la terminologie après la traduction proprement dite. PINNIS et SKANDINŜ (2012) ont exploré plusieurs méthodes pour adapter un TAS («Moses») à un domaine spécifique, parmi lesquelles figure aussi l intégration de terminologie. Dans un premier temps, ils ont testé l ajout de paires de termes des termes source extraits accompagnés de leurs traductions à un corpus parallèle et celui de traductions des termes seuls à un corpus monolingue intra-domaine. Ces deux corpus étaient destinés à l entraînement d un système TAS. Ces ajouts auraient considérablement augmenté le score BLEU comparé à la valeur de base (17,8 % et 23,1 % après ajout de paires de termes supplémentaires récupérées d Internet). Dans un deuxième temps, une caractéristique supplémentaire a été ajoutée à celles par défaut du tableau de traduction du modèle de traduction de Moses (cf. KOEHN, Moses User Manual, 289 sur les caractéristiques). Cette dernière identifie des phrases contenant des traductions des termes spécifiques au domaine et permet d exclure les fausses traductions non-spécifiques au domaine lors du processus de traduction. Pour ce faire, la caractéristique introduit deux 9 ITAGAKI et AIKAWA ne donnent pas davantage de détails sur la mesure de distance d édition appliquée, pour laquelle il y a plusieurs variations (cf. aussi section 6.1) ; à les lire, il est donc difficile de savoir quelle variation de cette mesure ils ont utilisée. 21

24 valeurs : «1» pour les séquences qui ne contiennent pas les termes répertoriés sur une liste bilingue, ni sur le côté source ni sur le côté cible ; «2» pour les séquences qui ne contiennent un terme que sur un côté pour indiquer une possible traduction nonspécifique au domaine (c est-à-dire fausse). Ensuite, les traductions non-spécifiques au domaine (fausses), portant donc la valeur «2», peuvent être exclues lors du processus de traduction automatique. Selon PINNIS et SKANDINŜ, la caractéristique supplémentaire aurait encore plus augmenté le score BLEU comparé à la valeur de base (24,1 %). Ils ont donc conclu que l intégration de terminologie augmenterait la qualité des systèmes TAS. 3.4 Conclusion Dans la première partie de ce chapitre (section 3.2), nous avons examiné le rôle de la terminologie dans le domaine de la traduction automatique. Nous avons vu que la terminologie joue un rôle crucial dans le domaine de la traduction «classique». Cependant, le rôle de la terminologie est moins évident dans le domaine de la traduction automatique statistique, une technique qui se répand de plus en plus rapidement. Tandis que dans les systèmes de TABR, la terminologie s intègre plus ou moins facilement, il n en est pas de même dans les systèmes de TAS. Dans ces derniers, la recherche et la pratique ne se sont pas encore penchées de manière intensive sur ce sujet. Néanmoins, il y a eu des initiatives dispersées. Nous en avons résumé quatre dans la deuxième partie de ce chapitre (section 3.3). En résumé, il s agit d approches assez différentes qui intègrent la TAS et la terminologie. Les trois premières méthodes utilisent des outils, ou mécanismes, supplémentaires qui sont indépendants du système TAS appliqué, pour identifier et insérer la terminologie. CARL et LANGLAIS (2002) utilisent des règles pour créer des variantes des termes donnés. Ils les identifient dans le texte source à l aide d un système de traduction basé sur des exemples, puis ils les intègrent dans un système TAS, en passant la terminologie cible par la traduction. OKUMO et al. (2008) utilisent une méthode de remplacement afin d assurer le bon ordre des mots dans la traduction. Il s agit d un algorithme pour remplacer des termes dans le texte source par des mots de haute fréquence dans le corpus de l entraînement et ensuite remplacer dans la traduction ces 22

25 mots de haute fréquence par les termes cibles. ITAGAKI et AIKAWA (2008) emploient des modèles linguistiques, semblables à des règles, pour changer les termes dans l output d un système TAS. La dernière méthode, PINNIS et SKANDINŜ (2012), travaille par contre directement avec le système de TAS («Moses» dans ce cas), qui est adapté pour identifier des termes et exclure/appliquer le faux/bon terme 10. Pour finir, nous aimerions attirer l attention sur la manière dont l efficacité des méthodes employées est vérifiée et mesurée ce qui nous intéressera tout particulièrement dans le chapitre 6 (section 6.1). CARL et LANGLAIS (2002) se réfèrent au taux d'erreur de mots et au taux d'erreur de phrases (ce dernier étant comparé à une traduction de référence) ; OKUMO et al. (2008) au seul score BLEU ; ITAGAKI et AIKAWA (2008) au score BLEU et à la distance d édition ; enfin, PINNIS et SKANDINŜ (2012) se réfèrent eux aussi au seul score BLEU. Par la suite, nous allons présenter le cas d Autodesk. Nous commencerons par la description du statu quo qui précédait l introduction de la nouvelle approche de terminologie dans la traduction automatique, puis mettrons l accent sur les outils de terminologie employés par Autodesk. 10 À noter que les «caractéristiques» ajoutées dans cette approche ne sont pas de la même nature que les caractéristiques du décodeur utilisées par Autodesk (cf. section 5.5) et nécessitent un développement plus approfondi. 23

26 4 Outils de terminologie employés dans la post-édition par Autodesk 4.1 Introduction Ce chapitre est dédié à la description de la situation à Autodesk avant l introduction de la nouvelle approche destinée à intégrer la gestion de la terminologie dans la traduction automatique. Tout d abord, nous allons brièvement décrire comment est organisée la localisation à Autodesk, ainsi que les techniques et outils utilisés (section 4.2). Ensuite, nous présenterons l ancien processus de terminologie, notamment l extraction, la traduction et la mise à disposition des termes (section 4.3). Une attention particulière sera portée aux bases de données terminologiques, l élément clé de l ancien processus (section 4.4), qui feront l objet d une évaluation systématique (section 4.5). Nous conclurons ce chapitre par une enquête sur l utilisation des outils de terminologie présentés dans la section 4.2 (section 4.6). 4.2 La localisation à Autodesk, ses techniques et outils principaux Dès le début, la localisation à Autodesk s est divisée en deux champs : la localisation du contenu software, c est-à-dire des chaînes de caractères provenant de l interface des logiciels, et la localisation du contenu documentation, c est-à-dire des documents d appui relatifs aux produits et logiciels (comme des manuels). Les deux suivent des processus différents et utilisent des outils différents. Afin d optimiser le flux de travail et réduire les efforts, le département de localisation et ses agences tirent à présent parti des outils de Traduction Assistée par Ordinateur (TAO). Depuis plus de 10 ans, Autodesk utilise en effet des mémoires de traduction pour stocker, récupérer et réutiliser des traductions antérieures. De plus, le département de localisation a été novateur en mettant en place son propre moteur de traduction automatique, «Moses» (Cf. section 2.3), et en appliquant depuis 24

27 quelques temps déjà de manière générale la «post-édition» 11. Les traducteurs qui travaillent pour «Autodesk» ne partent donc pas de rien pour la traduction : ils reçoivent des textes «pré-traduits» par «Moses» qu ils doivent réviser et corriger : Pour les segments qui ont une correspondance de moins de 75 % dans les mémoires de traduction, les traducteurs doivent éditer la traduction automatique brute ; Pour les segments qui ont une correspondance de plus de 75 %, ils doivent vérifier les résultats des mémoires de traduction 12. La post-édition à Autodesk se fait d habitude dans «WorldServer Desktop Workbench» pour le contenu documentation et dans «Passolo» pour le contenu software. Les deux outils sont mis à disposition par Autodesk. Le contenu documentation à traduire est mis à disposition sur «WorldServer» et le contenu software à traduire est envoyé aux agences de localisation sous forme de bundles 13. Les deux outils TAO destinés aux traducteurs incluent des fonctionnalités de terminologie qui nécessitent des «glossaires», des fichiers exportés des bases des données terminologiques gérées sur le GCMS «WorldServer» 14. Le logiciel «WorldServer Desktop Workbench» dispose des fonctionnalités «Auto Search for Terminology Matches» et «Consistency Check» et «Passolo» dispose d un addin pour la terminologie. Ces fonctionnalités permettent de repérer des termes dans le texte source et d afficher ou d insérer sa traduction récupérée des bases de données terminologiques, voire des «glossaires». 11 La post-édition est une technique récente, rendue possible par les développements dans le domaine de la traduction automatique. Le processus de post-édition diffère de celui-ci de la traduction «classique» en ce que les traducteurs modifient le texte issu de TA le moins possible, mais suffisamment pour le rendre lisible et fonctionnel. Il existe des directives et des formations spécialisées pour initier à la post-édition, car elle demande des qualités et des stratégies spécifiques que le traducteur «classique» ne possède pas toujours naturellement. 12 Davantage de détails sur le processus de post-édition à Autodesk, ainsi que les résultats d une enquête auprès des traducteurs se trouvent dans le mémoire de Mary GIACHETTI (GIACHETTI 2013, particulièrement 51 et suiv.). 13 À noter qu Autodesk s attend à ce que les traductions soient téléchargées, voire fournies, dans le format approprié. Comme la traduction est entièrement externalisée, il se peut que les agences utilisent d autres outils TAO que ceux mis à disposition par Autodesk («Workbench», «Passolo»). 14 D habitude, les traducteurs et les LSDVs d Autodesk appellent ces fichiers (et souvent aussi les bases de données) des «glossaires». 25

28 «Autodesk» propose encore des outils de terminologie supplémentaires. Tout d abord, les bases de données sur le GCMS sont aussi disponibles directement en ligne (sur login) pour les agences et leurs traducteurs. De plus, Autodesk offre un corpus en ligne, «NeXLT», qui est accessible au public. Cependant, les ressources mises à la disposition des traducteurs peuvent varier avec le projet, la langue, l agence, etc.. Avant de procéder à l évaluation approfondie des bases de données terminologiques (section 4.5) et à la présentation des résultats d une enquête sur l usage effectif des fonctionnalités de terminologie d Autodesk (section 4.6), nous allons nous pencher sur les différents éléments de l ancien processus de terminologie à Autodesk pour le saisir dans son ensemble. 4.3 L ancien processus de terminologie Dans le passé, le processus de terminologie à Autodesk reposait principalement sur les bases de données terminologiques qui étaient gérées sur le GCMS «WorldServer» et étaient spécifiques aux produits «Autodesk» (plus de 70 actuellement) et à la langue cible. Le processus consistait en deux étapes principales, l extraction des termes, puis la traduction, que nous allons décrire dans la suite Extraction des termes D abord, les candidats pour les nouveaux termes étaient extraits de manière semiautomatique du nouveau contenu software à l aide du «Acrocheck Batch Client» d Acrolinx 15. Bien que l extraction elle-même soit automatique, il fallait la lancer et la préparer (choisir et/ou établir des règles et choisir les options, etc.) manuellement. Cette tâche était assurée par l équipe «TLQM» («Terminology and Language Quality Management»). «Acrocheck» utilise des règles linguistiques qui reposent sur les résultats de l étiquetage syntaxique (des informations sur les partie du discours = «part of speech» ou «POS») pour reconnaître des candidats-termes. Il dispose de règles par défaut pour 15 «Acrolinx» est une entreprise basée en Allemagne, fondée par le Dr. Andrew Bredenkamp et le Dr. Sabine Lehmann. Auparavant, les deux fondateurs menaient des recherches sur le langage contrôlé à l institut «Deutsches Forschungszentrum für Künstliche Intelligenz». 26

29 chaque langue qui, idéalement, doivent être étendues selon les besoins et les textes exploités en appliquant des connaissances linguistiques afin d améliorer les résultats d extraction (cf. SMAADAHL et FOUVRY 2007, 6 et suiv.). 16 Il faut noter que l extraction des nouveaux termes ne couvrait que le contenu software, et pas le contenu documentation, parce que, étant donné que la documentation portait sur le software, on considérait qu elle ne devait pas contenir de termes différents. Ensuite, la liste des candidats-termes obtenue était nettoyée manuellement par le «LSDV» («Language Services Dedicated Vendor») allemand, un linguiste spécialisé. Une extraction automatique contient en effet toujours du «bruit», c est-à-dire des termes non-pertinents. Pour identifier les termes pertinents et exclure les termes non-pertinents, il faut donc toujours une intervention humaine. L acquisition et la reconnaissance automatique des termes restent un des défis principaux de la terminologie informatique (cf. VAN CAMPENHOUDT et al. 2009). Dans le cas d Autodesk, c était le linguiste spécialisé allemand qui avait seul la responsabilité de décider ce qui avait valeur de terme ou pas. Si possible 17, le linguiste spécialisé allemand fournissait, avec les termes, une description sur laquelle les autres LSDVs pouvaient se baser pour leur traduction Traduction et mise à disposition des termes Une fois les termes validés, ceux-ci étaient traduits dans une deuxième étape vers les langues requises par les LSDVs respectifs, puis ces traductions étaient vérifiées par des spécialistes du domaine, les «SMEs» (Subject Matter Experts»). Toutes les traductions et révisions dans l ancien processus se faisaient en format Excel, les fichiers étaient envoyés par ou mis en ligne pour téléchargement. Les termes finals et leur traduction vérifiée étaient importés dans la base de données terminologiques correspondante dans «WorldServer» et mis ainsi à disposition des traducteurs d Autodesk. Les détails du processus pouvaient légèrement varier selon la langue cible de localisation. Par exemple, le processus du japonais était plus détaillé et aussi bien documenté (cf. Figure 4). 16 Selon nos informations, l équipe «TLQM» cherchait, en coopération avec Acrolinx, à étendre les règles pour l extraction. Mais l équipe n existant plus, nous n avons pas pu trouver davantage de détails à ce sujet. 17 Parfois, les rédacteurs techniques mettent à disposition une description des termes clé anglais. 27

30 Figure 4. Organigramme de l'ancien processus de terminologie, spécifique au japonais (Source : Autodesk). 28

31 En plus de la révision obligatoire par un spécialiste du domaine, le «SME», le japonais demandait une révision étendue par le bureau local national d Autodesk (CO = «Country Office»). Étant donné que les bases de données terminologiques représentaient le cœur du travail terminologique dans l ancien processus, nous allons maintenant les regarder de plus près, pour ensuite les évaluer de manière systématique. 4.4 Les bases de données terminologiques existantes Les bases de données sur «WorldServer» sont disponibles en ligne, avec un login. Leurs noms suivent, en général, les abréviations des produits Autodesk. Ils sont soit regroupés par langue (pour les langues européennes, c est «FIGS» - «French», «Italien», «German», «Spanish», donc français, italien, allemand et espagnol), soit ils contiennent toutes les langues («all_langs»), comme dans l exemple de la Figure 5 (page suivante). Les entrées consistent principalement dans les termes eux-mêmes. Des informations supplémentaires sont disponibles sur clic (date de création, auteurs, etc.), ainsi qu une description, s il y en a ce qui n est pas le cas dans la plupart des entrées. Les entrées peuvent être parcourues (par ordre alphabétique) ou recherchées suivant différents modes de recherche. Dans la section 4.5, nous allons présenter une évaluation systématique des bases de données terminologiques d Autodesk qui utilise deux mesures courantes. En terminologie, les candidats-termes indésirables identifiés sont «regroupés sous le générique bruit» et les termes omis «sous le générique silence» (L HOMME 2004, 192) : La précision estime la proportion de bons candidats extraits dans la liste de candidats-termes. Lorsque la précision est élevée, il y a peu de bruit. Le rappel évalue la proportion de bons termes extraits parmi les possibilités dans le texte. Le rappel est élevé lorsqu il y a peu de silence. (L HOMME 2004, 193) En général, ces mesures sont employées pour évaluer la performance des extracteurs automatiques, d habitude en comparant leurs résultats (candidats-termes) à une liste de référence des termes, dépouillés par des terminologues expérimentés. 29

32 30 Figure 5. L'interface d'une base de données sur «WorldServer».

33 Nous allons utiliser les mesures de précision et de rappel dans une optique un peu modifiée : il s agira d évaluer la complétude et la pertinence des bases de données terminologiques en vue de l usage effectif des termes contenus. Outre les mesures, les hypothèses suivantes, formulées par l équipe «Language Technologies» (elles provenaient des observations faites au long des projets de localisation), guidaient nos observations et devaient être vérifiées lors de l analyse : Les données de terminologie sont incohérentes à travers les langues différentes. Les bases de données ne contiennent pas tous les termes nécessaires à la traduction, c est-à-dire qu elles ne sont pas complètes ( rappel bas, beaucoup de silence). Les bases de données contiennent des termes non-pertinents qui ne sont pas utilisés en traduction ( précision basse, beaucoup de bruit). Dans la suite, nous présenterons les résultats de l évaluation en termes de précision/rappel. 4.5 Évaluation des bases de données terminologiques existantes Partant des hypothèses formulées par l équipe «Language Technologies», nous avons donc appliqué les deux mesures décrites plus haut, le rappel et la précision, pour évaluer la complétude et la pertinence de bases de données terminologiques Rappel : complétude des bases de données Afin d établir combien de termes pertinents sont effectivement contenus dans les bases de données terminologiques d Autodesk sur «WorldServer», nous avons prélevé un échantillon et mené une évaluation systématique. Le matériel d évaluation était une liste des candidats-termes ambigus (anglais français) extraits automatiquement du corpus des traductions «Autodesk» existantes. Dans ce contexte, «ambigu» se réfère aux termes en langue source (anglais) qui ont plus d une traduction en langue cible, par exemple dans la Figure 6, le mot anglais «polyline», qui se traduit à la fois par le mot français «polyligne» et par «multiligne». Le corpus «Autodesk» exploité pour l extraction des termes consiste 31

34 Figure 6. Liste de candidats-termes nettoyés et vérifiés. dans les données (segments) des traductions d Autodesk existantes sauvées dans les mémoires de traduction et donc alignées. L échantillon et la méthode : la liste des candidats-termes ambigus a été extraite du corpus «Autodesk» par l équipe «Language Technologies» avec un script PERL développé par Ventsislav Zhechev et une liste des mots exclus 18 pour la langue source (EN) et la langue cible (FR) 19. Ensuite, la liste a été filtrée selon la fréquence d occurrence des termes sources dans les données. Dans une deuxième étape manuelle, des erreurs évidentes dans 18 Des mots vides («stop words») classiques comme «a», «about», «above» (anglais) ou «alors», «aucun», «aussi» (français). 19 A l origine, cette liste était utilisée pour identifier automatiquement des ambiguïtés de terminologie dans les traductions «Autodesk» japonaises afin que le LSDV japonais décide si elles étaient souhaitées ou non. Nous pensons que, puisque la liste identifie des ambigüités existantes, c est-à-dire publiées dans les traductions réelles, on devait au moins en trouver des «traces» en forme d entrée dans les bases de données terminologiques respectives. 32

35 l alignement et au niveau des variations morphologiques et orthographiques ont été identifiées (elles s élevaient à 25 % du total environ). Ces erreurs généraient de «fausses» ambiguïtés. En les excluant, les premiers 149 candidats-termes ont été retenus en tant qu échantillon. À noter que ce sont les candidats les plus fréquents (terme source). Ils devaient se trouver dans les bases de données terminologiques respectives sur «WorldServer», comme nous l avons vérifié pour les 149 candidats. Les bases de données terminologiques utilisées : les bases de données «Autodesk» sur «WorldServer» sont spécifiques aux produits. Toutefois, quelques produits (souvent les plus petits) n ont pas de base de données terminologiques spécifique (par exemple «Autodesk 360»). Les données dans les bases examinées étaient très hétérogènes. Pour les bases contenant les langues «FIGS» (français, italien, allemand et espagnol), le nombre d entrées varie entre 2073 («Inventor») et 56 («Homestyler») 20. Pourtant, le nombre d entrées n augmente pas linéairement avec la taille du produit et/ou le contenu traduit. À titre d exemple, en octobre 2013, le corpus des traductions existantes contenait presque deux fois plus de segments provenant d «AutoCAD» ( ) que d «Inventor» (89.000), mais la base de données terminologique d «AutoCAD» était plus petite (1.500 entrées) que celle d «Inventor» (2.000). Dans ce contexte, il faut rappeler qu Autodesk ne disposait pas de lignes directrices ni de définition universelle du concept de «terme» dans l ancien processus de terminologie. Mesure : nous avons calculé le rappel des termes : A A+B x 100 %, où A est le nombre de termes pertinents contenus dans les bases de données terminologiques et B et le nombre de termes pertinents non contenus dans les bases de données. Résultats : comme nous avions mené l évaluation de manière manuelle, les résultats ont été rapportés sur une feuille Excel. Sur 149 candidats-termes, 69 n étaient pas contenus dans les bases de données terminologiques respectives et 80 y étaient contenus. Ainsi, le rappel était de x 100 % = 54%, et le silence égal à 46 %. 20 Ces chiffres datent d août

36 Du fait de la nature de l extraction automatique, les candidats-termes extraits peuvent être des composés de termes et non des termes au sens strict. Pour cela, nous avons considéré cependant que les candidats-termes qui faisaient partie d une séquence plus grande contenue dans une base de données étaient aussi «contenus» dans les bases de données. Nous n avons donc pas seulement cherché des termes exacts, mais aussi, dans la limite du raisonnable, des sous-ensembles de termes. À titre d exemple, sur la liste des candidatstermes ambigus extraits figurait le terme «layer key» = identificateur calque, mais la base de donnée terminologique correspondante («AME_all_grp») contenait la séquence plus grande «layer key style» = style d'identificateur de calque. Nous avons considéré ce terme comme contenu. Ceci a été le cas pour 48 des 80 candidats-termes confirmés. Globalement, nous pouvons dire que les candidats-termes avec la plus haute fréquence pour les paires de traduction, par exemple «layer key» = identificateur calque, étaient souvent présents dans les bases de données terminologiques. Toutefois, il y avait aussi quelques exceptions surprenantes, comme «show» = afficher 21. Il y aussi un nombre considérable de paires de traduction avec une fréquence inférieure ou égale à deux qui n étaient pas inclues dans les bases de données terminologiques. Si l on considère que ces paires sont simplement des erreurs de traductions (ce qui peut être discuté), le nombre total des termes non inclus dans les bases de données se réduit à 47 (31 %). En résumé, les résultats d évaluation sont plutôt inquiétants : 31 % ou même 46 %, en fonction de la mesure appliquée des 149 premiers termes ambigus extraits automatiquement ne sont pas inclus dans les bases de données terminologiques. Les bases de données ne peuvent donc pas être considérées comme complètes. De plus, lors de leur examen, nous avons constaté qu elles sont hétérogènes et que toutes ne sont pas disponibles pour tous les produits «Autodesk». Cela représente une lacune non 21 A noter que, bien qu il n y ait pas de règle générale pour exclure les verbes des bases de données, les linguistes impliqués dans l ancien processus de terminologie semblent avoir eu l habitude de plutôt favoriser les substantives. 34

37 négligeable quand il s agit d assurer la cohérence terminologique à l aide des bases de données terminologiques seules Précision : pertinence de termes Afin d établir combien de termes contenus dans les bases de données terminologiques «Autodesk» sur «WorldServer» sont effectivement pertinents, nous avons prélevé un deuxième échantillon et mené une autre évaluation. La base d évaluation était une liste de termes et de leurs traductions prélevée de manière aléatoire sur un groupe de 42 bases de données terminologiques d Autodesk et vérifiée par la suite dans le corpus «NeXLT». «NeXLT» est un service en ligne qui permet de faire des recherches dans des traductions d Autodesk. L échantillon et la méthode : La liste des termes a été établie en utilisant 42 bases de données terminologiques regroupées sur «WorldServer» (cf. Annexe 1). Ce groupe contient les produits «Autodesk» les plus importants et couvre les langues «FIGS» (cf. cidessus), ainsi que le portugais brésilien. Au total, les bases de données regroupées comprennent entrées, sur lesquelles nous avons prélevé un échantillon aléatoire 22 de 149 entrées. Ces entrées ont été vérifiées dans «NeXLT». La source (EN) et la traduction française de chaque entrée ont été recherchées manuellement dans «NeXLT» pour vérifier si elles étaient effectivement utilisées en traduction. «NeXLT» est un service en ligne qui est accessible au public (url : Il comprend toutes les traductions récupérées des mémoires de traduction d Autodesk et contient en général la version la plus récemment publiée d un produit donné. Le service utilise la technologie d «Apache Solr», une plate-forme de recherche open source. Pour gagner du temps, nous n avons pas vérifié toutes les traductions, mais seulement les traductions françaises. Bien que nous présumions que cet échantillon soit représentatif 23, l analyse produirait probablement des résultats légèrement différents pour d autres 22 Nous avons exporté les bases de données regroupées en fichier CSV, puis pris l échantillon aléatoire avec Excel (méthode décrite ici, p. ex. page consulté le 5 février 2014). Pour davantage de détails sur les bases de données en tant que telles, cf. la section Tous les produits «Autodesk» sont localisés en français. 35

38 langues, car le processus de localisation et le contenu varient d une langue à une autre chez Autodesk. Mesure : nous avons calculé la précision des termes selon la formule A A+C x 100 %, où A est le nombre de termes pertinents contenus dans les bases de données terminologiques et C est le nombre de termes non-pertinents contenus dans les bases de données terminologiques. Résultats : comme nous avions mené l évaluation de manière manuelle, les résultats ont été rapportés sur une feuille Excel. Sur 149 entrées, 35 n étaient pas présentes dans «NeXLT» et 101 y étaient présentes. De plus, il y avait 13 entrées erronées dans les bases de données terminologiques (9 % de l ensemble des entrées). Ces entrées étaient principalement des termes qui n avaient pas de traduction (champ vide). Ainsi, la précision de termes est x 100 % = 68 %, et le bruit s élève à 32 % Globalement, les résultats de cette évaluation étaient un peu plus rassurants que ceux du rappel. La majorité de termes contenus dans les bases de données terminologiques peuvent être considérés comme pertinents et utiles car ils sont effectivement utilisés dans les traductions «Autodesk». Toutefois, 23 % d entre eux semblent être inutiles et créés inutilement. Ils n ont jamais été utilisés en traduction, comme «faulty component» par exemple ; ou bien ils ont été traduits différemment, comme «jumper» dont la traduction dans la base de données terminologique respective est «relier» mais qui a été en réalité traduit par «cavalier/utilisation d un cavalier». De plus, 9 % des entrées ont été identifiées comme erronées, ce qui indique un certain degré d erreur dans l ancien processus de terminologie. En résumé, nous pouvons dire que la précision, et donc la pertinence de terminologie d Autodesk répertoriée peut certainement être encore améliorée. 36

39 4.5.3 Résultats des évaluations Les évaluations des bases de données terminologiques nous permettent donc de tirer les conclusions suivantes : Les bases de données terminologiques sont effectivement incohérentes à travers les langues différentes. De plus, les différences ne sont pas proportionnelles à la taille des produits ou du contenu traduits. Les incohérences et différences semblent donc plutôt être dues à l organisation de l ancien processus de terminologie et à certaines lacunes (définition du concept «terme» et lignes directrices manquant). En effet, les bases de données ne contiennent pas tous les termes nécessaires à la traduction ; il en manque presque la moitié, c est-à-dire que les bases de données ne sont pas complètes ( rappel de 54 %, silence de 46 %). Les bases de données contiennent aussi des termes non-pertinents environ un tiers de l ensemble qui ne sont pas utilisés en traduction ( précision de 68 %, bruit de 32 %). Etant donné que les bases de données terminologiques représentent le cœur du travail terminologique dans l ancien processus d Autodesk, leurs lacunes suggèrent que l équipe de «Language Technologies» avait eu la bonne intuition et qu il était temps de repenser leur rôle primordial, comme on le fera dans ce travail. La terminologie issue de l ancien processus de terminologie décrit dans la section 4.3, les bases de données terminologiques décrites dans la présente section et la section 4.4, ainsi que les outils et fonctionnalités de terminologie décrits dans la section 4.2 étaient mis à disposition des traducteurs par Autodesk pour simplifier et rationaliser leur travail et améliorer la qualité de traduction. Pourtant, l on savait peu de choses, à Autodesk, concernant l utilisation effective de la terminologie et des outils respectifs. Nous avons donc enquêté sur l usage des outils de terminologie d Autodesk. 37

40 4.6 Enquête sur l usage des outils de terminologie d Autodesk Pour évaluer l usage des outils présentés dans la section 4.2, nous avons mené une enquête auprès des traducteurs pour déterminer si les outils et fonctionnalités de terminologie d Autodesk étaient effectivement utilisés par les traducteurs, et, dans cas où ils l auraient bel et bien été, sur leur mode d utilisation. En amont de l enquête, nous avons élaboré avec l aide de l équipe de localisation à Autodesk une liste des outils et fonctionnalités importants destinés à vérifier et à rechercher la terminologie d Autodesk. Cette liste contenait : 1. Les fonctionnalités intégrées dans les outils TAO : l «Auto Search for Terminology Matches» et le «Consistency Check» dans «WorldServer Desktop Workbench» et l addin de terminologie de «Passolo» (cf. section 4.2) 2. Les outils supplémentaires : les bases de données terminologiques de «WorldServer» disponibles en ligne et le corpus en ligne «NeXLT» (cf. section 4.2). Ensuite, nous avons créé un questionnaire sur «Google forms» (cf. Annexe 2). Il était rédigé en anglais, la langue de travail à Autodesk, et était constitué d une introduction et de neuf questions complétées par des explications, comme des liens ou des captures d écran 24. Les informations supplémentaires ont été ajoutées pour faciliter la compréhension, afin de récupérer le plus de réponses valides possible, mais aussi pour offrir une valeur ajoutée à ces traducteurs qui ne connaissaient pas l outil ou la fonctionnalité demandée, afin qu ils tirent un bénéfice de leur participation. Avant d être envoyé, le questionnaire a été relu et testé par deux étudiantes en traduction (M.A.). Une fois fini, un lien vers le questionnaire a été envoyé à tous les traducteurs d Autodesk. Pendant deux semaines, nous avons recueilli 117 réponses au total. 30 réponses ont été ensuite exclues, car les participants avaient répondu «oui» à une question-piège qui portait sur l usage d une fonction «Term Alert» dans le «Workbench» qui n existe pas (question 4, cf. Figure 7, page suivante). L idée était de vérifier si les réponses données par 24 Lors de la création des questionnaires, nous avons consulté PILSHOFER

41 les participants étaient fiables ou non. Ceci dit, l exclusion n a pas considérablement changé les tendances globales des résultats. Yes, I use the Term Alert function on a regular basis: 17 Yes, but I use the Term Alert function only occasionally: 15 No, although I know the Term Alert function, I have never used it: 21 I did not know about the Term Alert function until now: 66 Figure 7. Réponses reçues à la question 4 portant sur le «Term Alert» Les résultats de l enquête, par outil Nous avions organisé les questions en trois parties : 1. Les fonctionnalités intégrées dans les outils TAO ; 2. Les outils supplémentaires ; 3. Demande d avis sur la fiabilité des outils. Toutes les fonctionnalités intégrées (première partie) requéraient l import d un fichier glossaire en format TBX exporté des bases de données terminologiques du GCMS «WorldServer». Avec la première question de l enquête, nous enquêtions sur l emploi d un addin de terminologie de «Passolo» (cf. Figure 8, page 40) qui est utilisé pour la traduction de software (cf. section 4.2). Cet addin permet de repérer des termes dans les segments source et cible et d afficher par un clic droit l entrée respective récupérée des bases de données terminologiques d Autodesk. 39

42 Avec la deuxième et la troisième question, nous enquêtions sur l emploi de deux fonctionnalités disponibles dans le «Workbench» de «WorldServer», l outil TAO utilisé pour la traduction de documentation : l «Auto Search for Terminology Matches» (Recherche automatique des correspondances de terminologie, cf. Figure 9, page suivante) et le «Consistency Check» (Contrôle de cohérence, cf. Figure 10, page suivante). Figure 8. Capture d'écran présentant la fonction de l addin de terminologie de «Passolo». L «Auto Search» met en évidence les termes dans le segment source et affiche les traductions provenant des bases de données terminologiques dans un onglet séparé. Le «Consistency Check» permet de visualiser sous la forme d une liste tous les segments contenant des termes et de contrôler la cohérence des traductions. 40

43 Figure 9. Capture d'écran de l' «Auto Search» dans «Workbench». Figure 10. Capture d'écran du «Consistency Check» dans «Workbench». 41

44 Notre questionnaire démontrait que l «Auto Search» dans «Workbench» était la plus utilisée de ces trois fonctionnalités (cf. Figure 11): 67,8 % des traducteurs l utilisaient régulièrement et 20,7 % de temps en temps. Yes, I use the Terminology Matches function on a regular basis: 59 Yes, but I use the Terminology Matches function only occasionally: 18 No, although I know the Terminology Matches function, I have never used it: 5 I did not know about the Terminology Matches function until now: 5 L addin de «Passolo» (cf. Figure 12) figurait à I la did seconde not know place, about the 51,7 Terminology % des traducteurs Matches l utilisant régulièrement et 18,4 % l utilisant occasionnellement. Toutefois, presque 30 % des traducteurs répondaient qu ils ne l utilisaient jamais. Yes, I use the Terminology Matches function on a regular basis: 59 Yes, but I use the Terminology Matches function only occasionally: 18 No, although I know the Terminology Matches Figure 11 Réponses à la question 2 sur l «Auto Search Terminology Matches». function, I have never used it: 5 function until now: 5 Yes, I use the Passolo addin on a regular basis: 45 Yes, but I use the Passolo addin only occasionally: 16 No, although I know the Passolo addin, I have never used it: 11 I did not know about the Passolo addin until now: 15 Figure 12. Réponses à la question 1 sur l addin de «Passolo», La fonctionnalité la moins utilisée semblait être le «Consistency Check» (cf. Figure 13). 23 % des traducteurs l utilisaient régulièrement, 35,6 % seulement occasionnellement ; 28,7 % le connaissaient mais ne l utilisaient jamais, et 12,6 % ne connaissaient pas du tout cet addin. À noter que le résultat faible du «Consistency Check» n est pas surprenant car 42

45 cette fonctionnalité n apporte pas beaucoup de valeur ajoutée, si on la compare à l «Auto Search», qui est largement utilisée. Yes, I use the Consistency Check function on a regular basis: 20 Yes, but I use the Consistency Check function only occasionally: 31 No, although I know the Consistency Check function, I have never used it: 25 I did not know about the Consistency Check function until now: 11 Figure 13. Réponses à la question 3 sur le «Consistency Check» de «Workbench». Figure 14. Capture d écran présentant le corpus «NeXLT». 43

46 La première conclusion à tirer de ces résultats est que, afin d augmenter l usage des fonctionnalités et des outils de terminologie d Autodesk, il semble opportun de repenser la manière dont les traducteurs d Autodesk sont informés de ces fonctionnalités et outils disponibles, et surtout de l addin de «Passolo». Dans ce contexte, il pourrait aussi être utile d examiner si les vendeurs et les agences de localisation avec lesquelles Autodesk travaille, représentent un point critique en ce qui concerne la communication 25. Les outils supplémentaires mis à disposition par Autodesk constituaient la deuxième partie de notre questionnaire. Cette partie concernait les bases de données terminologiques de «WorldServer» (cf. Figure 5, page 30) et le corpus en ligne «NeXLT» (cf. Figure 14), ainsi que l usage d autres outils que ceux offerts par Autodesk. Yes, I use the TDs frequently for this purpose: 48 Yes, but I use the TDs only occasionally for this purpose: 23 No, although I know the TDs, I have never used them for this purpose: 9 I did not know about the TDs until now: 7 Figure 15 Réponses à la question 5 sur les bases de données terminologiques. En ce qui concernait les bases de données terminologiques, 80 % des traducteurs les utilisaient pour les recherches de terminologie, dont 55,2 % fréquemment et 26,4 % seulement de temps en temps. 8 % des traducteurs ne connaissaient pas les glossaires sur «WorldServer» (cf. Figure 15). 25 Autodesk offre aux traducteurs une sorte de wiki interne, appelé «Confluence», qui contient le «Translators Learning Path» (chemin d apprentissage pour les traducteurs). Il couvre l addin de «Passolo» et l «Auto Search de Workbench», mais pas le «Consistency Check» de «Worksbench» (cf. accès sécurisé, une inscription est nécessaire). 44

47 Pour ce qui était du corpus, environ 85 % des traducteurs utilisaient «NeXLT» pour rechercher des termes, dont 65,5 % fréquemment et 20,7 % occasionnellement. Par contre, 9,2 % des traducteurs ne connaissaient pas cet outil au moment de l enquête (cf. Figure 16). Yes, I use the corpus frequently for this purpose: 57 Yes, but I use the corpus only occasionally for this purpose: 18 No, although I know the corpus, I have never used it for this purpose: 4 I did not know about the corpus until now: 8 Figure 16. Réponses à la question 6 sur le corpus «NeXLT». Pour ce qui était des autres outils, 37,9 % des traducteurs répondaient qu ils n en utilisaient pas (cf. Figure 17). Toutefois, 58,6 % disaient qu ils utilisaient d autres outils de terminologie pour rechercher des termes et assurer la cohérence terminologique, en plus des outils mis à disposition par Autodesk. Enfin, 3,4 % des traducteurs indiquaient qu ils utilisaient exclusivement d autres outils à ces fins et pas ceux d Autodesk. Yes, I use other terminology tools and I use them in addition to those offered by «Autodesk»: 51 Yes, I use other terminology tools and I exclusively use those, not the tools offered by «Autodesk»: 3 No, I do not use other terminology tools than those offered by «Autodesk»: 33 Figure 17. Réponses à la question 7 sur les autres outils. 45

48 A cet égard, nous demandions aussi, aux traducteurs qui avaient répondu qu ils utilisaient d autres outils, de spécifier le nom et les fonctionnalités de ces derniers, ainsi que le processus dont ils se servaient (question 8, cf. Annexe 2). Le résultat le plus remarquable fut que la grande majorité de ces personnes (62 réponses) indiquaient qu ils utilisaient «Xbench», un outil pour l assurance qualité et la gestion de terminologie offert par l agence de traduction espagnole «ApSIC» 26. Cette information est importante pour l équipe de «Language Technologies» et le département de localisation, car elle donne des pistes pour optimiser les ressources de localisation mises à disposition par Autodesk. Il s agirait par exemple d adapter le format fichier des ressources de traduction à «Xbench», etc.. Dans la perspective des adaptations du processus de terminologie qui étaient envisagées, nous demandions également aux traducteurs leur avis sur la fiabilité des bases de données terminologiques et du corpus «NeXLT» (question 9, cf. Annexe 2). Dans leur majorité, Figure 18. Répartition des avis récoltés par rapport à la question 9 sur la fiabilité des outils. 26 D après le slogan du produit sur le site-web d ApSIC : consulté le 12 février

49 (73 %), les traducteurs indiquaient qu ils jugeaient les bases de données plus fiables (cf. Figure 18). Ce résultat est quelque peu étonnant si l on considère que, d après les réponses aux autres questions de l enquête, les traducteurs utilisaient «NeXLT» plus fréquemment que les bases de données sur «WorldServer» (cf. ci-dessus). Cependant, il paraît important que l équipe de «Language Technologies» tienne compte de ce résultat, afin de préparer les traducteurs d Autodesk de manière optimale au nouveau processus de terminologie qui se fondera sur la traduction automatique et le corpus «NeXLT» (cf. section 5.2) Conclusions sur les résultats de l enquête Tout d abord, nous avons pu établir le taux d usage des différentes fonctionnalités et outils mis à disposition par Autodesk. Pour ce qui est des fonctionnalités intégrées : L «Auto Search for Terminology Matches» était la plus utilisée (87 % d usage fréquent et occasionnel) L addin de «Passolo» était à la deuxième place (70 % d usage fréquent et occasionnel) Le «Consistency Check» était la fonctionnalité la moins utilisée (58% d usage fréquent et occasionnel). Comme les trois fonctionnalités requièrent une base de données terminologique exportée de «WorldServer», l équipe de «Language Technologies» a particulièrement pris note de ces résultats pour l organisation du nouveau processus qui réduit autant que possible l usage des bases de données et doit donc offrir des solutions alternatives. Pour les outils supplémentaires, notre enquête a montré que : Les deux outils «NeXLT» et les bases de données terminologiques sur «WorldServer» étaient largement utilisés ; «NeXLT» était légèrement plus utilisé (86 %) que les bases de données terminologiques (81 %) et avait davantage d utilisateurs fréquents. 47

50 L enquête sur l usage d autres outils a révélé qu une grande majorité des traducteurs (62 % au total) s en servaient. En particulier, les résultats montraient que le «Xbench» d ApSIC était très utilisé, ce qui n était pas connu auparavant et qui permettra d améliorer les ressources mises à disposition par Autodesk. Selon les résultats de la demande d avis sur la fiabilité de «NeXLT» et les bases de données terminologiques, les traducteurs jugeaient les bases de données plus fiables. Cette estimation est aussi utile à connaître pour l organisation du nouveau processus de terminologie. 4.7 Conclusion Ce chapitre s intéressait au moment du statu quo, avant l introduction de la nouvelle approche pour intégrer la gestion de terminologie dans la traduction automatique à Autodesk. Dans la section 4.2, nous avons brièvement décrit l organisation de la localisation à Autodesk et les techniques et outils principaux utilisés : le contenu traité (software, documentation), les outils TAO (mémoires de traduction, TA, «Workbench», «Passolo»), les principes de post-édition, ainsi que les fonctionnalités et outils supplémentaires de terminologie (bases de données terminologiques, «NeXLT»). La section 4.3 a décrit l ancien processus de terminologie : l extraction des candidatstermes à l aide d «Acrocheck» et leur traitement manuel par le LSDV allemand, ainsi que la traduction des termes validés par les autres LSDVs et la mise à disposition des termes finals dans les bases de données terminologiques sur «WorldServer». Dans la section 4.4, nous avons examiné de plus près les bases de données terminologiques et leur fonctionnement et avons introduit deux mesures courantes (précision, rappel) pour évaluer la complétude et la pertinence des bases de données. La section 4.5 a présenté les résultats de cette évaluation systématique : les bases de données terminologiques manquent de lignes directrices ; elles ne sont pas complètes (environs 50 % de rappel) et contiennent aussi des termes non-pertinents (environ 70 % de précision). 48

51 Enfin, nous avons examiné l usage des outils de terminologie présentés dans la section 4.2 par le biais d une enquête menée auprès des traducteurs d Autodesk (section 4.5). Grâce à cette enquête, nous avons évalué les fonctionnalités intégrées dans les outils TAO (l «Auto Search for Terminology Matches», le «Consistency Check» dans «WorldServer Desktop Workbench» et l addin de terminologie de «Passolo»), ainsi que les outils supplémentaires (les bases de données terminologiques de «WorldServer» disponibles en ligne et le corpus en ligne «NeXLT»). De plus, nous avons interrogé les traducteurs sur les autres outils utilisés et la fiabilité des outils supplémentaires. Pour ce qui est des fonctionnalités intégrées, nous avons vu que l «Auto Search for Terminology Matches» était la plus utilisée, suivi de l addin de «Passolo», et que le «Consistency Check» était la fonctionnalité la moins utilisée. Pour les outils supplémentaires, l enquête a montré que «NeXLT» et les bases de données terminologiques sur «WorldServer» étaient largement utilisés, avec un usage de «NeXLT» légèrement plus important. Il est également apparu que les traducteurs d Autodesk utilisaient en majorité d autres outils en complément et en particulier l «Xbench», un outil pour l assurance de qualité et la gestion de terminologie offert par ApSIC. En ce qui concerne la fiabilité de bases de données terminologiques, ainsi que celle de «NeXLT», la majorité des traducteurs ont jugé les premières plus fiables un point important à prendre en compte pour l équipe de «Langauge Technologies» lors des changements des processus de terminologie. De la situation initiale, nous allons maintenant passer à la présentation de la nouvelle approche pour intégrer la gestion de la terminologie dans la traduction automatique à Autodesk. 49

52 5 Nouvelle approche d intégration de la terminologie dans la TA à Autodesk 5.1 Introduction Face au défi de devoir redéfinir le processus de terminologie, l unité «Language Technologies» d Autodesk a trouvé une solution assez complexe du point de vue technique en ce qui concerne la réalisation, mais qui offre des avantages importants quant à l organisation sur le long terme. Partant de l idée d exploiter le moteur de traduction automatique qui représente depuis quelques temps déjà un élément novateur du processus de traduction à Autodesk, l unité «Language Technologies» a établi un nouveau processus de terminologie qui consiste à extraire automatiquement la terminologie source du nouveau contenu (1), à faire prétraduire cette terminologie par des traducteurs humains (2) et à intégrer la terminologie cible directement dans la traduction automatique statistique brute destinée à la postédition (3) (cf. Figure 19, page 52). Dans la suite, nous verrons successivement les trois étapes, même si cette division est quelque peu artificielle. En fin de compte, ce chapitre a pour objectif de présenter au lecteur la solution de «Language Technologies» sous toutes ses facettes. Mais avant d entrer dans le vif du sujet, nous allons décrire le cadre général de l application du nouveau processus (section 5.2). Ensuite, nous nous intéresserons aux trois étapes précitées et expliquerons le fonctionnement de l extraction automatique dans le nouveau processus (section 5.3), la pré-traduction qui se fera sur un site-web appelé «Term Translation Central» (section 5.4) et l intégration de la terminologie dans le moteur de TA, «Moses» (section 5.5). 5.2 Préliminaires du nouveau processus de terminologie Avant de procéder à la réalisation du projet, l équipe de «Language Technologies» en avait fixé le cadre général et le projet était devenu une initiative officielle d Autodesk dénommée «Down-to-earth Terminology» («terminologie terre-à-terre»). L objectif officiel de cette 50

53 initiative 27 était de «réduire la complexité de la traduction», ce qui était exprimé jusque dans le nom de «terminologie terre-à-terre». Il s agissait notamment : 1. D améliorer la productivité des traducteurs ; 2. De faciliter le recrutement des traducteurs ; 3. De favoriser des traductions de qualité. Lors de la présentation de l initiative en juillet 2013, Mirko Plitt a indiqué trois scénarios possibles nécessitant de la terminologie afin d éviter toute implication du personnel du département de localisation et d'accélérer, de simplifier et de rendre plus prévisible le processus de terminologie : Difficulté : un nouveau terme requiert une traduction appropriée qui nécessite une recherche (dépense supplémentaire) ou, au moins, dépend de l expertise que l on ne peut pas exiger de tout traducteur ; Cohérence : un terme apparait plusieurs fois et n est pas toujours traduit par le même traducteur, mais afin d améliorer la compréhension des lecteurs, il importe que la même traduction soit utilisée ; Conflit : un homonyme dans la langue source requiert des traductions différentes dans des contextes différents (des conflits ayant le même contexte doivent être résolus dans la source). Sur la base de ces scénarios, Mirko Plitt a proposé des solutions concrètes : Difficulté : comme dans le passé, les nouveaux termes seront extraits et prétraduits, mais la couverture du processus sera étendue afin d inclure tous les nouveaux syntagmes nominaux présents dans le nouveau contenu entier (et pas seulement dans les chaînes de caractères du software) ; Cohérence : la traduction automatique imposera une traduction cohérente, soit directement à travers les nouveaux termes, soit de manière implicite à travers les 27 Présentation «All hands» à Autodesk, Neuchâtel, fin juillet

54 données de traductions existantes (le corpus exploité pour l entraînement du moteur de traduction) ; Conflit : la traduction automatique imposera des traductions spécifiques aux produits «Autodesk», soit de manière explicite 28 pour les termes qui sont nouveaux pour un produit donné, soit de manière implicite 29 les conflits des termes présents dans les données existantes seront identifiés et respectés. (En cas de doute sur la terminologie existante, les traducteurs furent encouragés à consulter le corpus «NeXLT» qui contient toutes les traductions existantes.) L idée était donc de prendre en compte les besoins réels des traducteurs et de concevoir un processus qui s adapte mieux à leur besoins. En même temps, le nouveau processus devait Figure 19. Organigramme du nouveau processus de terminologie. 28 (Via le nouveau processus de terminologie). 29 (Via les mémoires de traduction qui servent de corpus d entraînement). 52

55 aussi combler quelques-unes des lacunes de l ancien processus que nous avons mises en évidence, et confirmées, dans le chapitre 4, notamment concernant les bases de données peu efficaces, la concentration sur le contenu software seul, et, plus globalement, l «illusion» d un concept commun de «terme» et d une gestion des termes systématique. Un autre effet supposé, mais plutôt d importance «secondaire», était une possible amélioration de la traduction automatique statistique. 5.3 Extraction automatique de terminologie Dans l ancien processus, l extraction se faisait de manière semi-automatique : les candidats-termes étaient d abord extraits avec l «Acrocheck Batch Client», pour être ensuite vérifiés manuellement (cf. chapitre 4, section 4.3.1). Dans le nouveau processus, l extraction se fait de manière complètement automatique afin d éviter toute implication du personnel du département de localisation. De plus, l extraction est étendue à tous les nouveaux syntagmes nominaux, l idée étant d omettre la vérification manuelle qui dépendait entièrement du jugement d une seule personne, le LSDV allemand, et d assurer une couverture plus complète. À noter que dans l ancien processus, le silence et le bruit d «Acrocheck» dépendait de l efficacité des règles linguistiques de ce logiciel. Nous avons effectué une vérification ponctuelle, donc nonreprésentative, des candidats-termes extraits du contenu «Autodesk» à l aide d «Acrocheck» (sans règles spécialisées) et trouvé que les résultats étaient hétérogènes et qu il y avait du silence et du bruit. Pour ce qui était du bruit dans l ancien processus, c était au LSDV allemand de le juger et de le «réduire». Le silence par contre demeurait dans la plupart des cas sans correction 30. Les résultats de notre analyse des bases de données terminologiques (un bruit de 32 % et un silence de 46 %, cf ), démontrent aussi que le silence était plus important dans ce qui était retenu de l extraction. Dans cette perspective, une extension de la couverture de l extraction, qui pourrait réduire le silence, semblait plutôt positive. D autant plus que les traducteurs humains qui effectueront la pré- 30 Interviewés à propos des changements du processus, certains des LSDVs, qui effectuaient la pré-traduction des termes dans l ancien processus, indiquaient qu ils ajoutaient des nouveaux termes tout au long des projets de traduction qui n étaient pas inclus dans la liste des termes initiale ; d autres disaient ne jamais en ajouter. Les pratiques semblent donc avoir varié. 53

56 traduction assureront une sorte de contrôle : on leur demandera de marquer des termes inutiles, ce qui permettra de limiter à peu près le bruit qui, quant à lui, risquerait d augmenter. Faute d une fonctionnalité d automatisation équivalente dans «Acrocheck» 31, Autodesk a développé une interface de programmation applicative (API) pour un programme d extraction automatique de syntagmes (quasi-)nominaux, un script «Python», développé auparavant par l unité «Language Technologies». L API fournit de nouveaux termes chaque fois qu un nouveau contenu est mis à disposition pour la localisation. Cette API est déjà intégrée dans le processus de traduction de software et peut aussi l être dans celui de la documentation. Toutefois, l intégration dans le processus de traduction de la documentation est plus complexe du point de vue technique et nécessite un développement des outils et une adaptation des processus liés plus approfondis, c est pour cela que cette intégration est toujours en cours pour le moment (état au 8 août 2014). Le cœur de l API est le script «Python». Il traite le nouveau contenu et extrait les nouveaux syntagmes (quasi-)nominaux. Le script présuppose l usage du «Natural Language Toolkit» (NLTK), une bibliothèque de logiciels pour le traitement automatique des langues (TAL) (pour le TAL avec Python et NLTK, Cf. BIRD, KLEIN et LOPER 2009). L élément préparatoire le plus important du script est l entraînement de l étiqueteur. Par défaut, le script utilise le «Brill Tagger» de NLTK, un étiqueteur à base de règles qui effectue un premier étiquetage et l améliore ensuite en appliquant des règles transformatives apprises à partir d un corpus d entraînement (cf. consulté le 24 février 2014). Pour le script d extraction, «Brill» est entraîné à l aide des données rassemblées à partir du corpus 31 L unité de «Language Technologies» a souligné que la raison pour laquelle «Autodesk» visait à développer son propre programme d extraction automatique de terminologie, et l API correspondante, n était pas la performance au niveau de l extraction qui était satisfaisante mais le fait que l entreprise Acrolinx, au moment de la préparation de l'initiative «Down-to-earth», ne pouvait pas proposer une API équivalente pour automatiser complétement l extraction des candidats-termes qui aurait pu être intégrée dans le processus de localisation d Autodesk. 54

57 «Autodesk». Alternativement, le script pourrait également permettre l utilisation du tagger «TNT» de NLTK. L étiquetage est effectué après la «tokenisation» (segmentation en unités) à l aide du «Line Tokenizer» et du «Treebank Word Tokenizer» de NLTK. Puis le contenu étiqueté est soumis à une analyse syntaxique de surface («chunking») qui récupère les unités («chunks») correspondant aux trois modèles suivants qui sont définis dans le script, c està-dire à des syntagmes (quasi-)nominaux : 1) {(<Unk UNK NN.* VBN>*)(<JJ.* VBN>*)(<Unk UNK NN.* VBN>)(<Unk UNK NN.*>+)} Lire : zéro ou plus (mot inconnu ou toutes les formes de substantif ou verbe au participe passé) suivi de zéro ou plus (toutes les formes d adjectif ou verbe au participe passé) suivi de (mot inconnu ou toutes les formes de substantif ou verbe au participe passé) suivi de un ou plus (mot inconnu ou toutes les formes de substantif) 32. Pour des exemples, voir la Figure 20. PanoViewerWidget Prototype Test Harness saved limit box style multiple scale factors power grid aberrations Figure 20. Exemples pour des syntagmes correspondants au modèle 1. 2) {<Unk UNK NN.* VBN> <VBG> <Unk UNK NN.*>} Lire : (mot inconnu ou toutes les formes de substantif ou verbe au participe passé) suivi de (verbe au participe passé ou au gérondif) suivi de (mot inconnu ou toutes les formes de substantif) Pour un exemple, voir la Figure L explication des tags peut être obtenue dans NLTK avec la commande : nltk.help.upenn_tagset() (cf. BIRD et al. 2009, chap. 5.9, URL : 55

58 Elements limiting slenderness Figure 21. Exemple pour des syntagmes correspondants au modèle 2. 3) {<Unk UNK NN.* VBN JJ.*>} Lire : (mot inconnu ou toutes les formes de substantif ou verbe au participe passé ou toutes les formes d adjectif) Pour des exemples, voir la Figure 22. net tilted Figure 22. Exemples pour des syntagmes correspondants au modèle 3. Ensuite, les chunks récupérés sont nettoyés en enlevant la ponctuation, ainsi que d autres symboles («*»), des doubles espaces, des «nowords» (une liste prédéfinie des mots à exclure), etc.. La dernière étape effectuée par le script est la comparaison des chunks récupérés avec les traductions existantes dans le but de ne retenir que les nouveaux syntagmes (quasi-) nominaux. Afin de gagner en rapidité, cette comparaison se fait en deux temps. D abord les chunks sont comparés avec une liste de séquences anglaises (jusqu à 5-grammes au maximum) extraite du tableau de traduction du moteur de TA «Moses» : cette action est rapide, elle permet de gagner du temps. Le tableau de traduction contient les résultats du dernier entraînement avec le corpus de traductions «Autodesk» (pour le tableau de traduction, cf. aussi la section 2.2). Puis, les chunks restants sont encore nettoyés en enlevant ceux des chunks à plusieurs mots retenus qui contiennent en eux-mêmes d autres chunks à plusieurs mots plus petits déjà retenus : par exemple, «calculation configuration» et «dialog box» resteront, mais «calculation configuration dialog box» sera enlevé. Dans un deuxième temps, étant donné que le tableau de traduction de «Moses» contient uniquement les données du dernier entraînement, le corpus «NeXLT» est consulté pour récupérer la différence symétrique (le delta, Δ) entre le tableau de traduction de «Moses» et le contenu traduit le plus récent (qui n a pas encore fait partie de l entraînement de 56

59 «Moses»). Cela requiert beaucoup de capacités de calcul et prend davantage de temps. Afin d être optimisé, ce processus est donc effectué en deux parties : tout d abord, une comparaison est opérée avec le corpus spécifique au produit (d où provient le nouveau contenu), ce qui est plus rapide ; puis, l on opère, pour les chunks qui n ont pas été trouvés, une comparaison avec le corpus entier (contenant tous les produits), ce qui prend plus de temps. Ensuite, les segments source dont les termes étaient extraits, ainsi que des informations sur le produit et le corpus, sont ajoutés aux nouveaux termes. Enfin, tous les termes sont triés et sauvés dans une base de données MySQL. 5.4 La pré-traduction de terminologie Les termes extraits par l API sont automatiquement publiés sur un site web appelé «Autodesk Term Translation Central» 33 (cf. Figure 23, page 59). Ils sont disponibles au public mais ne peuvent être édités que par un utilisateur connecté en tant que tel. L accès à ce site en tant qu utilisateur est géré par Autodesk. L objectif est que l organisation de la pré-traduction se passe de manière plutôt fluide et communautaire ; il n y pas de plan de travail prescrit, et ce sont les «Program Managers» qui en sont responsables. Toutefois, l unité «Language Technologies» a mis à disposition sur le site interne, «Confluence», un bref guide («How to») ; elle a également mis en ligne sur YouTube (de façon publique) 34 de courtes vidéos qui sont des tutoriels expliquant comment utiliser le «Term Translation Central». Bien qu il n y ait pas de processus précis pour la pré-traduction, quelques points importants sont à observer. Le site permet plusieurs types de requêtes, mais, pour la prétraduction, les traducteurs et linguistes travaillent plutôt avec des listes de termes spécifiques à une langue et à un produit «Autodesk» accessibles par le bouton «Quick Access». En général, il y a trois opérations principales à effectuer : la traduction des termes, la révision des traductions des termes et la validation des traductions des termes. La traduction des termes, en principe assurée par les traducteurs principaux des agences ou 33 (état au 20 août 2014) 34 (état au 20 août 2014 : indisponible) 57

60 bien les LSDVs, se fait directement sur le site dans la colonne «Term Translation», en tapant directement le terme cible. La révision des traductions, en principe assurée par les SMEs, se fait dans la colonne «SME reviewed» en faisant glisser le bouton sur «yes» (cf. la quatrième colonne de droite dans la Figure 23). Le nom de la personne qui a effectué la révision est enregistré et affiché sous «Reviewed by» dans la colonne à côté. La validation des traductions, faite soit par les traducteurs principaux, soit par les LSDVs (selon l organisation respective), se fait dans la colonne «Approved» en faisant glisser le bouton sur «yes» (cf. la deuxième colonne de droite dans la Figure 23). Le nom de la personne qui a effectué la validation la traduction est enregistré et affiché sous «Reviewed by» dans la colonne à côté. En plus des termes sources, plusieurs informations supplémentaires peuvent être consultées dans la première colonne du «Term Translation Central» pour faciliter la traduction, la révision et la validation des termes (dans la Figure 23, on ne voit que les symboles ; il faut passer la souris pour voir les commandes). Ces informations supplémentaires sont les traductions antérieures du terme, s il y en a eu («show translation history»), le contexte du terme source, s il y en a («show source contexts») et les éventuels commentaires («show comments»). On trouve aussi dans le «Term Translation Centrale» le code du produit d où vient le terme source (cf. la deuxième colonne de gauche dans la Figure 23), la date de la dernière traduction et la dernière mise à jour (cf. 6 e et 7 e colonnes de droite dans la Figure 23), ainsi que l information indiquant si le terme est nouveau pour le produit ou nouveau pour le corpus entier (cf. la sixième colonne de gauche dans la Figure 23). La fonctionnalité «Ignore» dans la troisième colonne permet aux utilisateurs d ignorer les termes qui ne sont pas pertinents, contiennent des erreurs d orthographie, etc.. La traduction des nouveaux termes de manière centralisée sur une plateforme publique a plusieurs avantages, qui mènent le travail des collaborateurs externes d Autodesk à devenir plus transparent. Tandis que les détails du processus de pré-traduction de termes restaient «cachés» dans l ancien processus, l équipe de «Language Technologies» et le département de localisation peuvent désormais accéder directement aux traductions, à leurs versions antérieures, aux commentaires, etc. et ainsi se faire une vue d ensemble ou identifier des problèmes. 58

61 59 Figure 23. Capture d'écran du «Term Translation Central».

62 5.5 L intégration de la terminologie dans «Moses» Une fois les traductions des termes sur «Term Translation Central» approuvées, elles sont renvoyées pour être enregistrées dans une base des données. Le mécanisme du moteur de traduction automatique, «Moses», utilisé pour intégrer les traductions, est le balisage XML («XML markup»), une caractéristique avancée du décodeur de Moses (cf. KOEHN, Moses User Manual, 151). Il s agit d une méthode pour ajouter des informations supplémentaires au décodeur sans changer le modèle de traduction (cf. aussi le chapitre 2.3.1). 35 Dès avant l introduction du nouveau processus de terminologie, «Language Technologies» maintenait une liste de termes (glossaire). Ce fichier texte se trouvait sur le serveur de «Moses» : les termes y étaient recherchés avant de procéder à la traduction automatique proprement dite. La Figure 24 ci-dessous présente un exemple de glossaire. "RSA_gloss" => { terms => [ { term => "Grid Align", de => "Raster ausrichten", fr => "Aligner grille", } ], languages => {de => 1, fr => 1} } Figure 24. Exemple de glossaire. Si une correspondance apparaissait lors de la requête dans le glossaire, la séquence source correspondante (les formes singulier et pluriel d une entrée de glossaire sont reconnues) était balisée en XML, comme dans l exemple ci-dessous (Figure 25) : For example, if the Front viewport is active, <gloss translation="grid Align">Aligner grille</gloss> uses the XZ plane. Figure 25. Exemple de balisage des termes. 35 Nous tenons beaucoup à remercier Ventsislav Zhechev qui a mis à notre disposition les informations techniques nécessaires contenues dans cette section (5.5), ainsi que dans la section

63 Cette phrase source va donc être traduite vers le français comme dans la Figure 26: Par exemple, si la fenêtre Face est active, Aligner grille utilise le plan XZ. Figure 26. Exemple de traduction. Dans le nouveau processus de terminologie, il y aura, en plus du glossaire, une requête automatisée dans la «Term Translation Central» par le biais d un bref script développé par «Language Technologies» pour récupérer une liste de (nouveaux) termes spécifiques à une langue et un produit «Autodesk». En même temps, l ancien fichier glossaire sur le serveur «Moses» est maintenu : il y aura donc deux «sources» différentes qui vont «alimenter» «Moses» avec la terminologie prédéfinie, le glossaire sur le serveur et le «Term Translation Central». La fonctionnalité du balisage XML est appliquée en mode exclusif, c est-à-dire que les traductions des termes qui ont été balisés sont utilisées directement et les propositions du tableau de traduction sont ignorées. (Entre autres, «Moses» propose aussi un mode inclusif où la traduction va concourir avec les propositions du tableau de traduction. Il faut donc indiquer une probabilité pour chaque traduction, ce qui se fait aussi dans le balisage). À noter que «Moses» n appliquera pas de morphologie aux traductions des termes introduites par le balisage XML (par contre, comme mentionné ci-dessus pour le glossaire, les formes singulier et pluriel sont reconnues pour l anglais, seule langue source à Autodesk). Les mots répertoriés n ont pas fait partie de l entraînement du modèle de traduction, ce qui, dans les systèmes TAS non-hybrides, est nécessaire au moteur de traduction pour apprendre leurs usages et formes potentielles. Il n y aura donc que la forme répertoriée dans le glossaire, voire dans la «Term Translation Central» qui sera insérée : il n y aura pas d adaptation au singulier, au pluriel, etc.. C est aux traducteurs/post-éditeurs de choisir la forme appropriée. En même temps, si la terminologie pré-traduite est pertinente et est donc effectivement utilisée en traduction, les nouveaux termes enteront dans les mémoires de traduction et seront de cette manière, sur le long terme, également utilisés pour l entraînement. 61

64 5.6 Conclusion et mise en perspective Ce chapitre devait présenter la nouvelle approche pour intégrer la gestion de la terminologie dans la traduction automatique à Autodesk sous toutes ses facettes. La section 5.2 a introduit le cadre général de l application du nouveau processus. Nous avons vu les défis relevés par l ancien processus de terminologie : la difficulté, la cohérence et le conflit, ainsi que les solutions apportées par le nouveau processus : l extension de l extraction de terminologie, l intégration de la terminologie dans la TA et la consultation du corpus, ainsi qu une terminologie spécifique aux produits. Ensuite, nous avons regardé de plus près les technologies employées par Autodesk pour atteindre ces buts : L extraction de terminologie, l API et le script «Python» ont été décrits en détails dans la section 5.3 ; L interface Web et l organisation de la pré-traduction de la terminologie dans le «Term Translation Central» ont été présentés dans la section 5.4 ; L intégration de la terminologie dans le moteur de TAS, «Moses», à travers le balisage XML, a été décrite dans la section 5.5. Nous pouvons maintenant revenir sur la sélection de littérature qui a été présentée dans la section 3.3 pour mettre en perspective l approche d Autodesk. Les approches décrites semblent toutes plus complexes au niveau technique. Comme nous l avions vu, elles utilisent : une méthode intégrée dans un système TAS pour créer des variantes des termes donnés, les identifier à l aide d un système de traduction basé sur des exemples et passer les termes cibles par la traduction ; un algorithme pour remplacer des termes dans le texte source avec des mots de haute fréquence dans le corpus de l entraînement et remplacer ces mots de haute fréquence par les termes cibles ; ou des modèles linguistiques pour changer les termes dans la sortie d un système TAS. Seule l une de ces approches (PINNIS et SKANDINŜ 2012) intervient directement dans le système de TAS, comparable en cela à l approche d Autodesk. 62

65 Nous pourrions donc avancer les hypothèses suivantes : 1. Les approches présentées dans la section 3.3 cherchent à perfectionner le rendu, la «qualité» de la TA en ce qui concerne la morphologie, l ordre de mots, etc. ; 2. Elles représentent des projets de recherche quelque peu expérimentaux et théoriques, nous ne savons rien sur leurs applications pratiques. En comparaison, l approche d Autodesk présente plusieurs particularités : 1. Elle entend mettre l accent sur la faisabilité et la simplicité. La qualité de la TA brute (après la première insertion des nouveaux termes et leurs pré-traductions) importe moins, car les post-éditeurs humains devront de toute façon corriger la TA. De plus, on s attend à une amélioration et à une correction de la qualité de la TA sur le long terme, par le biais des mémoires de traduction (cf. section 5.5). 2. Elle est centrée sur l applicabilité dans l environnement du département de localisation. Elle va donc, dans la pratique, plus loin qu une conception technologique ou qu un projet de recherche : elle doit satisfaire aux exigences de toutes les parties concernées (LSDVs, SMEs, Program Managers, traducteurs, etc.) et s intégrer de manière souple dans les flux de travail existants. Ces observations vont nous guider dans le chapitre suivant qui va explorer l impact de la nouvelle approche pour intégrer la gestion de terminologie dans la TA en évaluant son efficacité. 63

66 6 Analyse : l efficacité de la nouvelle approche de terminologie d Autodesk 6.1 Introduction Comment étudier l impact de la terminologie? Si nous regardons encore la littérature présentée dans le chapitre 3.3, nous y trouvons certaines mesures couramment appliquées pour évaluer la qualité de la TAS après l intégration de terminologie : le taux d'erreur de mots (WER), le taux d'erreur de phrases comparé à une traduction de référence (SER), le score BLEU, la distance d édition. Ces mesures servent toujours à évaluer la TA/TAS. Elles sont dites «automatiques». Elles ont été développées pour évaluer la performance d un système TA sans devoir recourir au jugement humain qui est couteux, subjectif et lent à grande échelle. Dans la plupart des cas, les mesures automatiques comparent la traduction TA à une ou plusieurs traductions (humaines) de référence. Le taux d erreur de mots (WER = Word Error Rate) est l une des premières mesures automatiques, c est la «distance Levensthein» entre les mots de la TA et les mots d une traduction de référence, divisée par la longueur de la traduction de référence (cf. OLIVE et al. 2011, 815). La distance de Levensthein est calculée en alignant la TA et la traduction de référence et en additionnant les suppressions (mots de la traduction de référence non alignés), les insertions (mots de la TA non alignés) et les substitutions (mots de la TA alignés à un mot de la traduction de référence mais qui sont différents de ce dernier). Le WER est généralement vu comme inadéquat pour évaluer la TA de manière pertinente, car il intègre mal plusieurs traductions de référence, ne prend pas en compte un ordre de mots divergent (cf. OLIVE et al. 2011, 816) et, plus globalement, dépend de la traduction de référence, tandis qu en traduction il y a un nombre illimité de solutions (cf. TOMAS 2003, 28). 64

67 Le taux d erreur de phrases (SER = Sentence Error Rate) est le pourcentage de phrases qui différent de la traduction de référence (cf. TOMAS 2003, 28). Cette mesure ne s utilise pas beaucoup en TA et présente les mêmes problèmes que le WER. De plus, le SER est encore moins précis que le WER, car l unité de comparaison est plus grande (la phrase). Le score BLEU est la mesure automatique la plus utilisée aujourd hui. Il a été développé par IBM et se base sur la mesure de précision (cf ). BLEU calcule le nombre des n- grammes, des séquences de mots, dans la traduction du système de TA, qui équivalent à un jeu de traductions de référence. Il s y ajoute une pénalité de brièveté («brevity penalty») pour les candidats-traductions qui sont plus courts que la référence, car ceux-ci risquent de recevoir un score trop élevé ; sans cette pénalité, une traduction automatique qui est plus courte que la référence mais contient des mots identiques à celle-ci obtiendrait un score parfait. La pénalité de brièveté assume une sorte de rôle de contrôle de rappel (pour la mesure de rappel, cf. section 4.5.1) 36. Il existe plusieurs variantes du score BLEU. Malgré son succès, BLEU a plusieurs désavantages : les résultats ne sont très fiables que pour un grand corpus et comme toutes les mesures qui ne se fondent que sur les références, BLEU ne prend pas en compte des synonymes ou un ordre de mots divergents (cf. OLIVE et al. 2011, 817). La distance d édition (Edit distance) est une mesure pour quantifier la similitude ou différence de deux séquences. Il existe plusieurs variations, la distance Levenshtein que nous venons de décrire ci-dessus étant la plus commune. Pour savoir comment nous pourrions évaluer l efficacité de la nouvelle approche d Autodesk à l aide de mesures, il convient dans un premier temps de définir ses objectifs et de rappeler son contexte. Tout d abord, ce qui nous intéresse dans le cadre de cette évaluation, c est plutôt la cohérence terminologique que la qualité globale de la TAS en tant que telle. De plus, étant donné les conclusions présentées à la fin du chapitre 5, nous retenons que ce qui importe 36 Pour davantage de détails, cf. OLIVE et al. 2011, , ainsi que l article original sur BLEU publié par PAPINENI

68 est avant tout la terminologie dans le produit final (les traductions post-éditées), plutôt que la terminologie dans la TA brute (cf. la fin de la section 5.6). Bien que l impact de l approche sur la TA brute soit un sujet important et intéressant à étudier, le nouveau processus de terminologie d Autodesk n avait pas comme premier objectif d améliorer la TA, mais de faciliter une traduction de qualité, tout en prenant en compte les besoins réels des traducteurs-postéditeurs (cf. aussi la section 5.2). On cherche donc à évaluer l impact de la terminologie dans des conditions bien déterminées, qui incluent la TA. Ainsi, dans le contexte des projets de recherches décrits dans la littérature présentée dans la section 3.3, il a peut-être semblé raisonnable 37 de recourir aux mesures automatiques énumérées ci-dessus qui sont réservées à l évaluation de la qualité et de la performance de la TA, mais pour évaluer l efficacité de la nouvelle approche d Autodesk, nous ne pourrons pas y recourir. Il nous faut plutôt une mesure de cohérence terminologique qui puisse être calculée de manière automatique, en prenant en compte le corpus étendu des traductions post-éditées d Autodesk. Ce chapitre va donc d abord discuter l importance de la cohérence terminologique et de sa mesure en prenant comme exemple le cas d Autodesk (section 6.2). Nous présenterons ensuite une mesure de cohérence terminologique introduite par ITAGAKI et al., le «Terminology Consistency Index» (TCI), qui servira à vérifier la cohérence terminologique et évaluer l impact du nouveau processus de terminologie sur les traductions finales d Autodesk (section 6.3). Enfin, la dernière partie de ce chapitre sera consacrée à l analyse des traductions avec le TCI (section 6.4). Nous allons décrire en détail comment nous avons préparé les données pour l analyse (section 6.4.1) et extrait les «termes» nécessaires 37 Il n empêche que l on pourrait aussi avancer plusieurs arguments contre l application de ces mesures dans ces contextes. D abord, un petit changement dans la terminologie (supposons que dans quelques phrases il y ait un mot qui soit préféré à un autre) ne va pas être assez significatif pour influencer significativement une mesure automatique, cette dernière n étant, comme nous l avions vu, déjà pas très précise au départ. De plus, les mesures automatiques se basent d habitude sur des traductions de références. Ainsi, ces mesures ne peuvent servir que si la traduction de référence contient (seule) la terminologie clé ; dans le cas contraire, la terminologie correcte sera en réalité pénalisée 66

69 (section 6.4.2). Puis, nous allons expliquer comment le TCI a été calculé et présenter les résultats d analyse (section 6.4.3). Nous conclurons cette partie avec quelques remarques sur les contraintes de l analyse et leurs implications quant à l interprétation des résultats (section 6.4.4). Mais d abord, il nous faut dire quelques mots sur l importance de la cohérence terminologiques pour les traductions d Autodesk. 6.2 Mesurer la cohérence terminologique Il est peu contesté que la cohérence terminologique représente un facteur majeur de la qualité de traduction. Ceci est d autant plus vrai quand il s agit de la traduction spécialisée, c est-à-dire de traduction de textes qui ciblent un public professionnel, averti ou spécialisé et qui couvrent un domaine bien défini, comme dans le cas d Autodesk. Mais à quoi ce concept de «cohérence terminologique» se réfère-t-il? Pour donner un exemple, si un utilisateur du logiciel «AutoCad Mechanical», un logiciel de conception ou CAO (conception assistée par ordinateur) conçu pour l'industrie manufacturière, se sert du manuel correspondant, il faut qu une fonctionnalité soit toujours désignée de la même manière, comme «Properties Inspector palette» par exemple, et ceci à la fois dans le logiciel lui-même, dans le mode d emploi, ainsi que dans toute autre documentation liée. Ceci afin que l utilisateur puisse comprendre et, le cas échéant, appliquer les descriptions et les instructions. Si le mode d emploi parle de «Properties Inspector palette» mais que, dans le logiciel, la fonctionnalité s appelle «Inspector Options palette», l utilisateur aura du mal à s y retrouver ou perdra du temps pour s assurer que l on se réfère bien à la même chose dans les deux cas. Pourtant, une traduction cohérente de «Properties Inspector palette» n est pas évidente, car toute séquence source peut potentiellement être traduite par une multitude de séquences de mots dans la langue cible. C est pourquoi on définit et gère la terminologie à grande échelle. Dans le chapitre 4, nous avons vu les processus et les outils qu Autodesk met à disposition des traducteurs pour les soutenir le plus possible dans leur travail terminologique. 67

70 Néanmoins, l observation quotidienne et les premières analyses d échantillon ont démontré qu en plus des problèmes relevés quant au rappel et à la précision des bases de données terminologiques (cf. section 4.5), la terminologie «Autodesk» n avait pas été, dans le passé, toujours respectée et appliquée correctement. 38 Le nouveau processus de terminologie est censé améliorer le respect de la terminologie pré-traduite à travers son insertion dans la TA. En conséquence, et si le nouveau processus s avère efficace, la cohérence terminologique dans les produits et documents localisés devrait augmenter. 6.3 L indice de cohérence terminologique Pour vérifier la cohérence terminologique et évaluer l impact du nouveau processus de terminologie sur les traductions finales, nous allons recourir à l «indice de cohérence terminologique» (Terminology Consistency Index = TCI), proposé par ITAGAKI et al ITAGAKI et al. ont utilisé cette mesure pour vérifier automatiquement si des substantifs étaient traduits de manière cohérente dans le corpus d un produit spécifique et à travers des corpus de différents produits. Pour diverses raisons la méthode appliquée va plus loin et est plus sophistiquée que la nôtre. Mais ce que nous intéresse principalement, c est la mesure en tant que telle. ITAGAKI et al. ont adapté l indice Herfindahl-Hirschman (HHI), une mesure économique qui sert à estimer la concentration du marché et les parts de marché d une entreprise. Entre autres, l'ihh est utilisé en droit de concurrence («anti-trust laws») par les autorités des États-Unis pour statuer sur l autorisation de fusion des entreprises (cf. BIKKER 2004, 51). n 2 La formule de cet indice est : HHI = i=1 S i 38 Les analyses correspondantes faisaient partie du projet pivot décrit dans le chapitre (voir en particulier la note 18) qui était mené par l équipe de «Language Technologies» pour identifier automatiquement des ambiguïtés de terminologie, donc des termes qui ont plus qu une traduction, dans le corpus des traductions «Autodesk» EN > JA, puis EN > FR. Deux listes importantes furent créées, dont la vérification manuelle par les traducteurs/linguistes est toujours en cours. 68

71 S est la part de marché d une entreprise et n le nombre d entreprises. Le HHi est égal à (100x100) quand une entreprise détient tout le marché ; quand 10 entreprises possèdent 10 % du marché chacune, le HHI est égal à pour chacune (cf. ITAGAKI 2007, 273). Appliqué au domaine de la traduction, S devient le rapport de chaque traduction (i) sur le nombre total de traductions dans un produit, un texte, etc. (n). Nous calculerons donc : TCI = n ( f i=1 x100) k i 2, où f est la fréquence d une traduction et k l occurrence totale du terme source. Si un terme source n a qu une traduction, le TCI égale , le score parfait. Si un terme source a plusieurs traductions différentes, le TCI baisse en fonction. Par exemple, un terme source avec deux traductions (=> f=1 et k=2) aurait un score de ( ). Comme nous l avons annoncé, nous allons analyser quatre produits «Autodesk» : «Revit», «AutoCAD Mechanical», «AutoCAD Electrical» et «AutoCAD Architecture». Pour déterminer la cohérence terminologique intra-produit, nous calculerons les TCIs pour tous les termes source extraits d un produit et prendrons ensuite la moyenne. À noter que nous allons regarder la cohérence terminologique produit par produit, car le nouveau processus de terminologie d Autodesk continuera d imposer des traductions et une terminologie spécifique au produit (voir aussi le point «Conflit» dans la liste des solutions concrètes apportées qui se trouve dans la section 5.2). 6.4 Analyse : le TCI Les données analysées et leur préparation Autodesk a mis à notre disposition le corpus entier de toutes ses traductions post-éditées 39. Plus précisément, nous avons reçu deux corpus que ne nous allons comparer par la suite : l état avant l introduction du nouveau processus de terminologie datant de novembre 39 Nous tenons à remercier vivement Ventsislav Zhechev et Mirko Plitt pour tout le travail qu ils ont consacré à cette mise à disposition. 69

72 2012 (ci-après : «Corpus 1») et l état après l introduction du nouveau processus datant d avril 2014 (ci-après : «Corpus 2»). Pour gagner du temps, nous avons décidé de ne regarder que les traductions vers l allemand et le français (la source étant toujours l anglais à Autodesk). Il faut noter que le nouveau processus, avec l implémentation du «Term Translation Central» et ce qui s en suit, n a été mis en place qu en décembre 2013, mais que des termes pré-traduits étaient déjà introduits dans la TA auparavant, par le biais de la liste de termes (glossaire en format texte) décrite dans la section 5.5. La date exacte de l introduction de ce fichier nous est inconnue, mais elle a eu lieu entre novembre 2012 et décembre Figure 27 Un extrait des données du Corpus 2 pour le produit AutoCAD Architecture (EN DE). Pour analyser les données, une préparation était nécessaire. D abord, il a fallu extraire des deux corpus les données spécifiques aux quatre produits qui nous intéressaient, «Revit», «AutoCAD Mechanical», «AutoCAD Electrical» et «AutoCAD Architecture». Ceci a été réalisé sous UNIX, en rassemblant les données qui portaient les codes produit respectifs (nous avons utilisé les commandes «grep», «cat», etc.). Un exemple pour les données 70