et instanciation sur des sites i MAG concrets a interactive Multilingual Access Gateway

INP Grenoble ENSIMAG École Nationale Supérieure d Informatique et de Mathématiques Appliquées de Grenoble Rapport de projet de fin d études Effectué au LIG - GETALP : Laboratoire d Informatique de Grenoble Groupe d Etude en Traduction/Traitement Automatique/Automatisé des Langues et de la Parole Développement d un site Web imag a générique et instanciation sur des sites i MAG concrets a interactive Multilingual Access Gateway Carlos RAMISCH 3e année Option ISI 25 mars 2008 29 août 2008 LIG - GETALP Responsables de stage 385, Rue de la Bibliothèque Christian BOITET et Valérie BELLYNCK BP 53 Tuteur de l école 38041 GRENOBLE CEDEX 9 Pierre BERLIOUX

Remerciements Tout d abord, je remercie, par sa confiance et patience, mon tuteur au GETALP, Christian Boitet, qui a été un toujours accessible pour répondre à mes questions et qui m a motivé et guidé durant tout le travail effectué au sein du GETALP. Je voudrais également remercier Valérie Bellynck, cotutrice de stage, pour sa patience et son intérêt aux problèmes de conception et de développement, aussi que pour ses précieuses suggestions qui m ont permis de toujours avancer. Troisièmement, je voudrais remercier les personnes de l ENSIMAG qui m ont aidé à surmonter les difficultés qui se sont présentées au long du chemin, spécialement Pierre Berlioux, mon tuteur, tout comme Marie-Laure Potet, Marianne Genton et Sébastian Viardot. Je reconnais que, sans leur support et leur aide, ce travail n aurait pas été possible. Je remercie vivement Aline Villavicencio, pour les opportunités qu elle m a offertes, et pour la confiance qu elle me porte. Elle partage avec moi non seulement la passion pour le traitement automatique des langues, mais aussi son amitié. L équipe du GETALP a aussi été importante pour l aboutissement de ce projet : j adresse mes remerciements à toute l équipe, spécialement à Mathieu Mangeot, à Huynh Cong-Phap et à Hong-Thai Nguyen, qu ont été de très bons collègues de travail. Merci aussi à Hervé Blanchon et à Floralis, responsables du support financier du projet. Je remercie les professeurs de l ENSIMAG et les professeurs de mon université d origine, UFRGS, pour leur grande compétence dans leur métier et pour la qualité de leur enseignement qui m a permis de résoudre avec maturité les défis de la vie professionnelle. Je remercie également la commission de sélection du projet SCISTEMA, qui m a fait confiance pour participer de cet échange international avec l INP Grenoble et l ENSIMAG. Finalement, j exprime ma gratitude vis-à-vis de ma famille et de mes amis, sans lesquels rien ne serait possible. Le travail de l ingénieur et du scientifique ne se fait pas, comme dans les caricatures, enfermé dans un laboratoire solitaire, mais il est le résultat d un effort collectif. À tous ceux qui, de façon directe ou indirecte, ont contribué à la réussite de ce travail, je vous dis Muitíssimo Obrigado! 2

Résumé Ce rapport décrit le travail effectué au cours du stage de Carlos Ramisch au sein du GETALP durant la première moitié de 2008, dans le cadre de son projet de fin d études à l ENSIMAG. Tout d abord, nous placerons le travail du groupe et du stagiaire dans le contexte global de la traduction automatique. Ensuite, nous définirons la notion de site et de page Web, tout comme les défis posés par ces objets de constitution diverse, justifiant ainsi la proposition de la solution i MAG. Les quatre étapes nécessaires pour l implémentation d un prototype seront détaillées à travers une conceptualisation suivie d une description des choix effectués lors de la mise en œuvre des concepts. Cette méthodologie est employée pour décrire le traitement des pages, leur segmentation en unités de traduction minimales (phrases ou titres), dites segments, le traitement des segments par les mémoires et systèmes de traduction et la génération de la page cible. Avant les conclusions, nous détaillerons les phases d analyse, de conception et d implémentation du prototype, avec une étude sur son déploiement sur le site du LIG. Finalement, nous présenterons ce qui a été fait, ce qui reste à faire et les contributions de ce projet sur le plan professionnel, académique et personnel. Abstract This report covers the work accomplished by Carlos Ramisch during the first semester of 2008 regarding an internship in the GETALP, in order to obtain the degree of ENSIMAG engineer. First, we will describe the context of machine translation and then situate the group and the internship in this global picture. The motivation of the imag concept relies on the existing problems in the multilingual access to online information systems, and therefore we will define these heterogeneous objects and present the challenges we meet once we need to internationalise and localise them. The four steps needed to implement a prototype are detailed through a brief theoretical discussion followed by an explanation of the choices we made when we implemented the discussed concepts. This methodology will be used throughout the chapters that depict the processing of the original Web page, its segmentation by sentence detection, the use of translation memories and systems to process it and the generation of a new target page using the skeleton of the source page, the translated segments and some interaction functionalities. Before we show our conclusions, we will study the analysis, design and development of the prototype, along with a test instantiation over the LIG s Web site. Finally, we will specify what has effectively been done, what is left to be done and what are the contributions of this project to its participants from the professional, academic and personal points of view. 3

Table des matières Introduction 5 1 Problématisation de la traduction des systèmes Web 7 1.1 Concepts......................................... 8 1.2 Techniques de localisation................................ 9 1.2.1 Localisation interne............................... 9 1.2.2 Localisation externe............................... 11 1.3 Une solution possible : imag............................. 13 2 Les défis du Web 15 2.1 Qu est-ce qu un site Web?............................... 15 2.2 Qu est-ce qu une page Web?.............................. 17 2.3 Le relai de traduction.................................. 19 3 Segmentation 20 3.1 Taille de segment.................................... 20 3.2 Cas problématiques................................... 21 3.3 Le format appartient-il au segment?......................... 21 3.4 Méthodes et outils................................... 23 4 Traduction : mémoires et systèmes 24 4.1 Mémoires de traduction................................ 24 4.2 Systèmes de traduction automatique......................... 26 5 Génération de la page cible 27 5.1 Post-édition....................................... 27 5.2 Affichage des correspondances.............................. 27 5.3 Interface avancée de traduction............................. 28 6 Mise en œuvre 30 6.1 Architecture........................................ 30 6.1.1 Modélisation du contexte............................ 30 6.1.2 Architecture conceptuelle............................ 31 6.1.3 Architecture dynamique............................. 32 6.1.4 Architecture physique.............................. 32 6.2 Conception........................................ 34 6.3 Codage et instantiation................................. 35 7 Conclusions 39 Références 40 A Planning comparatif 43 4

Introduction La langue française, comme d ailleurs toutes les autres langues naturelles (que l on peut aussi appeller langues humaines pour les opposer aux langues artificielles et aux langages informatiques), n est pas uniquement un ensemble de mots et de règles grammaticales pour regrouper ces derniers et créer des phrases. Une langue est composée de ses expressions idiomatiques, ses habitudes, ses nuances, ses aspects historiques, son usage, ses références culturelles, etc. Le langage humain est ainsi un objet complexe par sa dépendance au contexte où il est employé. La traduction peut être définie comme le processus de transformation d une information exprimée dans une langue (la langue source) en une information correspondante dans une autre langue (la langue cible). Puisque les langues, source et cible, sont des structures complexes, la traduction est une tâche qui, elle aussi, est complexe et par conséquent coûteuse. Cependant, la traduction est essentielle dans plusieurs contextes, sans être exhaustif : les communautés et organisations composées par plusieurs pays (comme l Union européenne, l ONU, l UNESCO, le FMI) ; les pays où plusieurs communautés linguistiquement diverses cohabitent (comme le Canada, la Suisse et la Belgique, où le français n est pas la seule langue officielle) ; les entreprises multinationales, de par leurs collaborateurs, leurs partenaires ou leurs clients ; les communautés virtuelles (comme Pax Humana 1, où des individus du monde entier collaborent pour la défense des Droits de l Homme). Les premiers pas vers l automatisation de cette tâche, au début des années 1950, ont pour origine l euphorie provoquée par le succès des machines à décrypter durant la seconde guerre mondiale. L analogie peut être enoncée de la façon suivante : si un texte écrit dans une langue peut être considéré comme un message dans la langue cible qui est encodé dans une langue source, alors traduire n est que déchifrer ce message (Arnold et al., 1993). Cette analogie a mené à un optimisme exagéré et à de grands espoirs quant à la Traduction Automatique (TA, anglais Machine Translation, MT ). À l époque2, les chercheurs disaient que dans dix ans, un ordinateur générerait une traduction de haute qualité (i.e. comparable à la qualité d un traducteur humain) de n importe quelle information exprimée dans une certaine langue source. Nous savons aujourd hui que ce n est pas le cas, et même que nous ne pourrons jamais obtenir à la fois un maximal en couverture, qualité et automaticité, l amélioration de deux de ces aspects se fait toujours en détriment du troisième. Pour autant cela ne veut pas dire que la TA n est pas utile. Elle est souvent très efficace, par exemple, pour des sous-langages et domaines spécifiques, ou quand une traduction de haute qualité n est pas necéssaire (pour une compréhension globale d une information dans une langue complètement inconnue du lecteur). Dans ce travail, nous montrerons qu une de ses utilités est d aider les traducteurs humains à augmenter la performance de leur travail de façon significative. Néanmoins, nous supposons que la traduction complètement automatique et avec haute qualité de n importe quel texte issu de n importe quel contexte est impossible, car elle est dépendante d une connaissance du monde qui ne peut pas être représentée de façon raisonnable dans la mémoire d un ordinateur. Cette supposition a été présentée par Bar-Hillel (1960), et est soutenue de façon crédible par la plus grande partie de la communauté scientifique (Boitet et al., 1980). 1 http ://paxhumana.info/ 2 Vers 1954, lors de la première démonstration du système GAT (Georgetown Automatic Translation) sur quelques phrases russes. 5

Cette hypothèse va être la base du travail décrit dans ce rapport : la traduction totalement automatique n étant pas assez bonne et la traduction humaine étant très coûteuse, les chercheurs ont proposé des approches hybrides, où la machine génère des pré-traductions qui sont ensuite post-éditées par des traducteurs professionnels ou volontaires. Les outils développés pour cette tâche sont classifiés comme des outils de Traduction Assistée par Ordinateur (TAO, de l anglais Computer Assisted Translation, CAT ). Nous nous intéresserons spécifiquement au développement d un outil de TAO pour la traduction des sites Web. L idée d un outil qui fonctionne comme une passerelle de traduction pour un site Web élu a été proposée par Christian Boitet (Boitet et al., 2008) et un tout premier prototype a été développé par Mohammad Daoud (Daoud, 2007). L imag (interactive Multilingual Access Gateway, ou en français Passerelle Interactive d Accès Multilingue) est un composant logiciel collaboratif qui est responsable de la gestion du multilinguisme dans un site Web. Le travail décrit dans ce rapport se déroule au sein du GETALP. Le Groupe d Étude en Traduction/Traitement Automatique/Automatisé des Langues et de la Parole a été créé à travers la fusion des anciens GETA et GEOD en janvier 2007, dans le cadre de la création du LIG Laboratoire d Informatique de Grenoble. Les travaux du groupe ont cependant commencé vers 1961, avec le CETA, postérieurement GETA et finalement GETALP. B. Vauquois et C. Boitet ont décrit les aspects pratiques et scientifiques des premières expériences du groupe de Grenoble, les outils et ressources développés dans ses premiers vingt ans d existence et les projets en cours à l époque (Vauquois et Boitet, 1985). Le groupe a donc été pionnier dans le Traitement Automatique du Langage Naturel (TALN, ou en anglais Natural Language Processing, NLP) et, dès son début, ses thèmes de recherche comprenaient la TA et la TAO (Vauquois et Boitet, 1985). Nous expliquerons, dans les chapitres qui suivent, les problèmes d ordre théorique et pratique qui ont motivé le concept d i MAG, ainsi que ses avantages et ses inconvénients. Ensuite, nous présenterons les quatre principales parties de l i MAG : la gestion des pages, leur segmentation, la traduction des segments à travers des outils de mémoire de traduction et de traduction automatique, et finalement la reconstruction de la page cible à travers la création d une interface qui permet l édition sans couture des traductions générées et l amélioration de ces dernières. Nous finirons par les aspects pratiques de la mise en œuvre du prototype d imag, avec un planning effectif du travail réalisé, une synthèse des contributions apportées par le présent travail et ses perspectives à développer. 6

Chapitre 1 Problématisation de la traduction des systèmes Web De nombreux sites Web sont disponibles en plusieurs langues. Il suffit d accéder à la page d accueil de Google 1 pour se rendre compte que l interface est disponible (au moment de la rédaction de ce raport) en 118 langues. 2 Amazon 3 est disponible en cinq langues, dont le japonais et le chinois, puisque l entreprise a des parts de marché dans les pays où ces langues sont parlées et a donc besoin de communiquer avec ses clients, surtout si ses affaires se font sur le Web. Le site de l Union européenne 4 est disponible en vingt-trois langues, même si la plupart des contenus ne sont que très partiellement traduits. L Organisation des Nations Unies ainsi que les institutions rattachées, comme l UNESCO 5, traduisent leurs sites dans les six langues officielles de l organisation. Les articles de Wikipedia sont disponibles dans un très grand nombre de langues, bien que seules vingt-deux langues aient plus d une centaine de millier d articles écrits. Ces communautés, qu elles soient concrètes ou virtuelles, ont en commun le fait de rassembler des personnes qui parlent des langues différentes, ayant ainsi besoin d intégrer le multilinguisme dans leurs sites. Même au sein d un même pays, par la coexistence de plusieurs langues officielles, les sites gouvernamentaux, comme le site de l administration fédérale Suisse 6, doivent être multilingues pour être en accord avec le principe de l égalité d accès à l information (le site cité est traduit en cinq langues). Il est de plus en plus courant de voir de petits sites personnels, des sites de PME ou d ONG, traduits dans une deuxième langue, généralement l anglais qui est la langue dite commune sur le Web. Une telle solution n est envisageable que pour de petites institutions : une grande entreprise ne peut risquer perdre des clients potentiels sous prétexte d un site non disponible dans leur langue maternelle. D un autre côté, le contenu offert par une entreprise dans un site peut être générateur de conflits. Prenons le cas du site de l Union éuropéenne : si une page d appel à projets traduit mal une des procédures administratives dans une langue, alors tous les lecteurs de cette langue auront leurs chances diminuées. Ainsi, la responsabilité de tout propriétaire de vis-à-vis de la qualité des traductions des contenus de son site est extrême. La multilinguisation des sites est très présente et essentielle pour communiquer sur ce support. Dans ce chapitre, nous présenterons certains aspects de la traduction des sites Web. Nous commencerons par l introduction de quelques concepts qui seront utilisés dans la suite pour expliquer et illustrer les techniques usuellement employées dans la traduction des sites. La présentation de 1 http ://www.google.com/ 2 En réalité, ce chiffre est un peu plus petit, puisque certaines interfaces ne sont que des variantes locales d une langue (comme le portugais du Brésil et le portugais du Portugal). De plus, parmi les options, il existent au moins cinq langues inventées à but humoristique. 3 http ://www.amazon.com/ 4 http ://europa.eu/ 5 http ://www.unesco.org/ 6 http ://www.admin.ch/ 7

ces techniques a pour but de mettre en évidence la situation actuelle avant d aborder le concept d i MAG. 1.1 Concepts Lorsque nous parlons de la traduction des systèmes informatiques, nous avons deux concepts clés : l internationalisation et la localisation. Ces concepts sont utilisés par la plupart des outils et des méthodes qui ont pour but de faciliter la traduction des logiciels. Définition 1. Un logiciel est internationalisé quand il est conçu ou modifié pour qu il puisse être facilement traduit sans que pour autant il soit nécessaire de changer son code source. L internationalisation est perceptible comme le processus de séparation des messages qui sont affichés et la partie fonctionnelle du logiciel. Définition 2. Un logiciel est localisé quand il est traduit dans une région determinée 7. La localisation comprend la traduction des textes mais aussi le format des chiffres, dates et heures, tout comme les changements qui dépendent du contexte, par exemple, changer les couleurs du logiciel qui pourraient être interprétées différemment dans deux régions. Un logiciel non internationalisé est très difficile à localiser. 8 Pour bien comprendre la différence entre internationalisation et localisation, prenons l exemple d un logiciel fictif qui est, originalement, écrit en anglais, et dont l auteur souhaite l adapter pour qu il soit aussi disponible en français. Pour cela, il devra faire attention à l encodage des caractères, vu que la langue anglaise n a essentiellement pas d accents, sauf pour quelques locutions d etymologie étrangère. Ensuite, il devra transférer tous les messages intégrés dans le code source vers un fichier texte à part, avec un identifiant pour chaque message. Les messages contenant des variables doivent, dans la mesure du possible, remplacer ces dernières par des textes spéciaux. Par exemple, pour le message : "Please, click on the " + abuttonname + " button" une traduction possible serait : "Veuillez cliquer sur le bouton " + abuttonname Néanmoins, si les deux messages Please, click on the et button sont mis séparément dans le fichier de messages, leur traduction en français sera Veuillez cliquer sur le bouton et vide, menant à croire que le mot anglais button n a pas de traduction. Puisque l ordre des mots peut changer, une meilleure solution est d extraire le message original comme Please, click on the $$abuttonname$$ button et de remplacer la chaîne de caractères $$abuttonname$$ par la valeur de la variable. De cette façon, les messages traduits peuvent placer la valeur de la variable convenablement. Toutes ces considérations appartiennent à l étape d internationalisation du logiciel. Il revient aussi à l auteur de notre exemple de faire que les formats des dates, heures et chiffres soient modifiés en fonction de la région. Des options complexes comme la direction du texte doivent être considérées selon les langues dans lesquelles le logiciel sera potentiellement localisé. Il est aussi envisageable dans cette étape que l auteur founisse un moyen à l utilisateur de pouvoir choisir la langue dans laquelle il souhaite utiliser son logiciel. Cela peut aussi se faire automatiquement comme lorsque le logiciel reconnaît la langue dans laquelle l utilisateur affiche son système d exploitation ou son navigateur Internet. 7 La notion de région est abstraite, pouvant varier selon le logiciel. Par convention, il s agit d une paire langue pays. 8 Pour les termes anglais internationalisation et localisation, deux abréviations sont couramment utilisées : i18n et L10n. Le terme globalisation est parfois employé pour remplacer les deux définitions précédentes, signifiant l adaptation d un logiciel à la traduction suivie de sa localisation. 8

Une fois que toutes les parties dépendantes de la région sont mises dans un fichier à part (le fichier n est qu un exemple, nous étudierons quelques techniques de localisation dans la partie 1.2), le logiciel doit être localisé pour la langue française. Une personne doit alors traduire tous les messages qui ont été extraits pendant l internationalisation. Si la dernière est bien effectuée, la localisation ne doit pas toucher au code source de l application. 1.2 Techniques de localisation Nous présenterons dans cette partie la classification proposée par Christian Boitet et son équipe pour la localisation des logiciels (Boitet et al., 2008). La première des deux approches consiste à effectuer une localisation interne, en traduisant les messages qui ont été séparés du code source pendant l internationalisation. La seconde propose la localisation externe, où le logiciel ne doit pas être internationalisé car il est traduit automatiquement par un composant externe. Ces deux techniques, seront présentées dans les deux parties qui suivent, avec leurs avantages, leurs inconvénients et des exemples. Les inconvénients de chaque technique seront à l origine de l introduction du concept d imag dans la partie 1.3. 1.2.1 Localisation interne La localisation interne est la façon la plus naturelle de traduire un logiciel, mais aussi la plus onéreuse. La localisation interne suppose que le logiciel est internationalisé et pour ce faire plusieurs techniques et outils sont utilisables. Le premier choix concerne la façon dont les messages sont stockés et récupérés. L approche la plus courante est l utilisation d un fichier externe qui est chargé au moment de l exécution selon la langue choisie, et où chaque message a un identifiant unique utilisé dans le code source pour le référencer. Une autre approche similaire consiste à placer ces mêmes informations dans une base de données, avec des avantages lors de la traduction puisque les messages peuvent être visualisés dans plusieurs langues simultanément. Une dernière technique possible utilise les modèles Web (de l anglais Web template). Quand il s agit de placer les messages dans un fichier externe, les mises en œuvre sont très variées. En PHP, l internationalisation est souvent effectuée à travers un tableau qui est initialisé dans un fichier à part, comme l exemple d un site de manifestation culturelle 9 montré dans la figure 1.1. Ce tableau associe un identifiant à un texte et à une région. La région est couramment représentée par une paire qui contient le code du pays et le code de la langue (par exemple fr FR ou fr BE pour le français de France et de Belgique). Les variables dans les messages utilisent la syntaxe de la fonction printf. Cette technique a plusieurs inconvénients : non seulement la performance est diminuée à cause du chargement des tableaux en mémoire, mais aussi les messages sont séparés de leur contexte, ce qui rend la traduction difficile. Cependant, cette technique est très répandue à cause de sa facilité d emploi, et plusieurs systèmes de gestion de contenu, tels que Dotclear et Joomla, l utilisent. La classe centrale de l internationalisation Java est le ResourceBundle, responsable de la gestion des fichiers de messages. Ces derniers correspondent à un fichier du type.properties contenant les messages sous la forme d une suite de lignes id = message pour chaque langue dans laquelle le système est localisé. Java fournit aussi des classes spécialisées dans l affichage des messages avec des variables (MessageFormat), des dates/heures (DateFormat, SimpleDateFormat) et des nombres (NumberFormat, DecimalFormat), tout comme pour changer la direction de l écriture (Bidi). Il est aussi possible de définir des messages qui varient selon la valeur d une variable, comme pour faire le pluriel d un mot (ChoiceFormat). La plupart des environnements intégrés de développement Java fournissent des outils pour automatiser l internationalisation des systèmes originalement monolingues. Cette approche présente les mêmes inconvénients que la précédente : la décontextualisation des messages et la baisse de performance. 9 http ://illustrerlhistoire.upmf-grenoble.fr/ 9

Fig. 1.1 Illustration de la technique d internationalisation par tableau en PHP. D autres projets dans la communauté open source vont aussi vers une internationalisation plus simple. Le projet NLSO, par exemple, a pour but fournir des outils pour l internationalisation des sites Web en PHP. Il utilise une base de données pour stocker les messages qui, ensuite, peuvent être partagés par plusieurs pages, sites ou organisations. Néanmoins, ces initiatives manquent de normalisation et offrent une très faible documentation. Finalement, la technique des modèles Web est utilisée par des frameworks tels que Dreamweaver. Dans ce cas, une page est créée dynamiquement à partir d un modèle. Pour internationaliser la page, le modèle est choisi selon la langue négociée avec l utilisateur (voir définition 3). Dans cette approche, la perte de performance est beaucoup moins importante. A priori, le site peut être traduit sans que les messages ne soient privés de leurs contextes, dans un éditeur HTML. En pratique, la plupart des pages sont composées de plusieurs modèles, ce qui rend difficile la reproduction exacte des conditions d utilisation du site. Définition 3. Le processus de Négociation de Langue a pour acteurs le serveur et le client Web. Le but est de trouver un consensus parmi les langues dans lesquelles le serveur offre son contenu et les langues dans lesquelles l utilisateur accepte de recevoir le contenu. Par convention, si aucune langue n est commune aux deux, le serveur envoie le contenu dans sa langue de défaut, communément l anglais. Analysons maintenant un exemple de localisation interne dans le système de gestion de contenu Joomla. Valérie Bellynck montre, sur son site 10, que l internationalisation de ce logiciel et sa localisation est souvent incohérente. Dans la figure 1.2, trois manières différentes d internationaliser le code ont été trouvées lors de l analyse de la version française de Joomla 11. Cela montre que même de grands systèmes ont des difficultés à adopter correctement une technique de localisation interne. 10 http ://pti.site.free.fr/wallynet/ 11 Exemples extraits du site de Valérie Bellynck 10

(a) Message traduit directement dans le code source. (b) Technique du tableau PHP. (c) Message non traduit. Fig. 1.2 Incohérence dans l internationalisation de Joomla. 1.2.2 Localisation externe Le concept de localisation externe s appui sur l existence d une passerelle de traduction, qui est un type de passerelle de navigation dont la fonctionnalité est de traduire le contenu d un site. Définition 4. Une passerelle de navigation est un système Web à travers duquel un visiteur peut accéder et explorer par navigation tout un site Web. Du point de vue du visiteur, la navigation peut sembler identique à la visite du site d origine, sauf que c est en réalité la passerelle qui accède au site et qui renvoi chaque page demandée par le visiteur, tout en effectuant des calculs et des remplacements sur son contenu. Une passerelle de navigation prend généralement la forme d un site Web (mais peut être aussi, par exemple, un service Web). Une simple redirection peut donner l illusion de constituer une passerelle, mais la différence est double : non seulement, une fois la redirection effectuée, l URL retournée est celle du site d origine, mais aussi aucun traitement n est fait ni ne peut être fait sur le contenu des pages redirigées. Les principaux problèmes de la localisation résident dans la traduction, puisque la dissociation de la structure et du contenu oblige à traduire les messages sans accès au contexte dans lequel ils sont affichés. Pour essayer de résoudre ce problème, nous analyserons brièvement les passerelles de traduction automatique : des passerelles de navigation généralement attachés à un service de traduction automatique de textes en ligne. Nous montrerons ici deux sytèmes de traduction de sites : celui de Systran et celui de Google. Le système de Systran est très simple : après avoir fourni une URL, l utilisateur peut naviguer dans le site traduit. Le traducteur de Systran réussit à traduire la plupart des éléments de la page, y compris les formulaires et champs de recherche. Les données transitent par la passerelle et le résultat de l envoi d un formulaire s affiche toujours traduit. Aucune interaction avancée n est possible : l utilisateur doit se contenter de la traduction de basse qualité fournie par le système de TA. Google permet aussi la traduction automatique d un site dont l utilisateur fournit l URL. Son interface permet d afficher les messages de la page originale en survolant leurs traductions avec le curseur. Néanmoins, seul les éléments simples en HTML sont traduits. Les formulaires, par exemple, une fois envoyés, retournent à l utilisateur la page originale. Même des champs simples comme la recherche par mots-clés n est pas fonctionelle, car le site du LIG en français est renvoyée lors d une recherche sur l annuaire traduit en portugais (fig. 1.3). Google permet aussi aux utilisateurs de suggérer une meilleure traduction. Une fois soumise, la suggestion n est pas prise en compte lors des futures traductions du même message dans le site. L utilisateur ne peut pas voir le résultat de sa contribution et recevra toujours la traduction générée par TA, de plus basse qualité que la sienne. Google justifie son approche en prétendant utiliser les 11

(a) Une recherche dans la page traduite... (b)... renvoi la page originale. Fig. 1.3 Traduction de la page du LIG par Google. 12

suggestions des utilisateurs pour améliorer la performance de leur traducteur statistique, ce qui ne résoud toujours pas le problème de ne pas donner plus de crédibilité à une traduction réalisée par un humain qu à une traduction automatique. Cette crédibilité est néanmoins soumise à une détection de SPAM et à l évaluation de la qualité de la traduction proposée. De cette analyse, nous pouvons déduire que les passerelles de TA peuvent aider à comprendre de façon globale le contenu d un site, en étant une solution de très bas coût et simple à mettre en œuvre à travers un lien vers le service de traduction. Elles ne peuvent pourtant pas être utilisées pour fournir l accès multilingue au site Web d une entreprise ou d une organisation, car la qualité de la traduction n est pas compatible avec les attentes des utilisateurs. 1.3 Une solution possible : i MAG Le panorama développé jusqu à présent illustre les limitations de la traduction des sites Web : si d un côté les techniques d internationalisation interne posent des problèmes lors de la traduction hors-contexte, car elles ont pour principe la séparation entre contenu et forme, d autre part les solutions automatiques sont incompatibles avec les besoins des développeurs des sites Web. Le concept d i MAG interactive Multilingual Access Gateway, ou Passerelle Interactive d Accès Multilingue a été proposé par Christian Boitet (Boitet et al., 2008), et propose une solution pour ce problème. i MAG est un service responsable de la gestion de l accès multilingue à un site Web, que nous nommerons dorénavant le site Web élu. Le site élu, pour des raisons comme celles enoncées dans le chapitre d introduction, souhaite ou a besoin d offrir l accès multilingue à ses utilisateurs. Lorsque l utilisateur demande à voir une page du site dans une langue pour laquelle il n existe pas de traduction interne disponible, il indique à la passerelle qu il souhaite accéder au site élu dans cette langue. L imag va alors chercher une traduction pour chaque segment de la page. Cela sous-entend que chaque segment de la page a plusieurs traductions possibles avec des niveaux de qualité corrélés à la source de traduction, et que la passerelle choisit toujours la meilleure traduction disponible. Ensuite, l utilisateur dans un contexte de lecture de la page traduite pourra proposer des traductions améliorées, et ces traductions seront prises en compte la prochaine fois où la page sera traduite, lors du choix de la meilleure traduction disponible. Les inconvénients d une i MAG par rapport aux techniques classiques d internationalisation ressemblent à ceux des sites wiki : la validité des informations fournies par les volontaires, le sabotage, le consensus entre deux traductions d une même source (i.e. des utilisateurs qui fournissent deux traductions différentes pour un même segment). De plus, il existe une perte de performance par l ajout d une couche intermédiaire entre le serveur Web et le client qui veut voir une page dans son navigateur. Néanmoins, le compromis est intéressant puisque l i MAG fournit une traduction de bas coût et de qualité croissante et maîtrisable par le proprietaire du site. Cela veut dire que, même si, initialement, la traduction de la page n est pas meilleure que celle générée par un outil de TA, la qualité des traductions tend à augmenter au fur et à mesure que la page est utilisée. En complément de l interface de localisation en contexte, la passerelle de traduction est complétée par une interface spécialisée sur la traduction collaborative. Ainsi, des traducteurs professionnels disposent d une interface de traduction avancée, où les outils nécessaires tels que les diverses propositions de segmentation et traduction et un dictionnaire du domaine seront mis à disposition. Ainsi, à travers une philosophie collaborative similaire à celle qui a fait la réussite des pages en style wiki, le site sera traduit à bas coût, à l aide de volontaires, pouvant aussi être traduit par un traducteur professionnel tout en évitant le problème de la traduction hors-contexte. Quand un niveau de qualité jugé suffisant par les développeurs du site élu sera atteint sur tout ou partie des segements, les traductions de ces éléments pourront être intégrées où il le faut dans le sit élu (en principe, dans les tableaux de messages ou dans les bases de données prévues pour les éléments textuels localisables), supprimant ainsi la perte de performance imposée par l imag. Mohammad Daoud a créé un premier prototype d i MAG (Daoud, 2007). Ce dernier n étant pas facile à adapter ou développer et n étant pas relié aux ressources linguistiques d une interface de traduction collaborative, nous avons décidé de le reprogrammer de manière modulaire 13

et en utilisant des techniques sophistiquées disponibles dans un langage à objets comme Java. Le développement du prototype peut être décomposé en quatre parties. Il doit, dans un premier temps, télécharger la page source et traiter le code HTML afin de le préparer pour la segmentation. Nous alons ensuite séparer les segments à traduire du squelette de la page, puis chaque segment sera traduit de la façon suivante : la meilleure traduction sera cherchée dans la mémoire de traduction ; si aucune traduction n est disponible, le segment sera traduit par un outil de TA ; s il n existe pas d outil pour les langues source et cible souhaitées, une traduction mot-à-mot sera employée. La dernière étape concerne la réintégration des segments traduits dans la page originale et l ajout du code source qui permettra la post-édition. Ces quatre étapes correspondent aux quatre chapitres suivants de ce rapport. 14

Chapitre 2 Les défis du Web Le World Wide Web est un milieu de diffusion démocratique. Cette liberté donne à son contenu une nature hétérogène, même si la plupart des informations sont diffusées à travers des documents HTML. Néanmoins, ces derniers ont aussi une nature très diverse, d une part à cause d une syntaxe très permissive et d autre part à cause d un manque de standards et du besoin de rétrocompatibilité des navigateurs (Zeldman, 2003). La première question qui s impose à nous en commençant à développer un prototype pour l imag est la suivante : dans cet univers hétérogène, quel est l objet de base sur lequel travaille la passerelle? La réponse la plus évidente serait de dire que le prototype travaille sur un site Web, le site élu. Cependant, les limites de la définition d un site Web sont diffuses, et la granularité n est peut-être pas adéquate. Une deuxième réponse possible est de dire que l i MAG travaille sur un ensemble de pages Web, chaqune étant définie à l aide d un document HTML 1 et de documents satellites. Dans cette partie, nous définirons la notion de site et de page Web, pour expliquer ensuite comment notre prototype traite chacun des objets. Pour terminer, nous montrerons l importance de rajouter un relai de traduction entre le client et l imag, afin de mieux gérer la séparation de tâches et permettre des interactions avancées entre les divers types d utilisateurs et la passerelle. 2.1 Qu est-ce qu un site Web? L accès à un site se fait généralement à travers un lien contenant une URL (Unified Resource Locator), qui peut aussi être directement entrée à travers la barre d adresse du navigateur. Cette URL est formée par plusieurs parties, et contient le nom de domaine du site. Ce nom est enregistré auprès d une entité responsable de diffuser aux serveurs de noms de domaine (DNS, Domain Name Server). Un site Web peut alors être défini par l ensemble des pages Web qui sont disponibles à travers un domaine. Analysons un exemple sur le site du LIG : URL : http://www.liglab.fr/ Nom de domaine : liglab.fr Pages qui appartiennent à ce site : www.liglab.fr/spip.php?article107 www.liglab.fr/spip.php?article108 www.liglab.fr/spip.php?article173 www.liglab.fr/spip.php?page=tableau_equipe&id_rubrique=7&id_form=13... Cette définition n est pas suffisante pour le site pris comme exemple, car le site du LIG contient des sous-sites concernant chacune des équipes de recherche qui composent le laboratoire. L URL du site du GETALP, par exemple, est http://getalp.imag.fr/, et le nom de domaine dans ce cas n est pas liglab.fr, même si le site du GETALP appartient au site du LIG, et si, lors de 1 Le document peut être aussi statique aussi bien que dynamiquement généré par le serveur 15

Fig. 2.1 Fragment du fichier de définition du site Web élu. la traduction du site du LIG, l utilisateur envisage aussi avoir un accès multilingue au site du GETALP. Nous pouvons donc définir, de façon plus abstraite, qu un site Web est un objet informatique qui représente une entité du monde réel et que cet objet est composé d un ensemble de pages (statiques ou dynamyquement générées par le serveur) correspondant aux parties de cette entité. Les pages Web d un site partagent, donc, ce rapport d appartenance dans le monde réel à l entité représentée par ce site. Plusieurs fois, ce rapport est directement projeté sur le nom de domaine qui forme l URL de ces pages, de telle façon que toutes les pages qui forment le site partagent le même nom de domaine. Cette tendance n est pas respectée dans les cas où le site est très vaste ou de nature très variée, comme le cas du LIG, qui a été formé par l union de plusieurs équipes de recherche affiliées précédemment à des institutions diverses. Le même problème s impose lorsque nous travaillons avec un navigateur dédié à un site qui simule une application locale. 2 Le prototype i MAG utilise la notion abstraite de site pour définir les limites de navigation traduite. En pratique, un fichier en format XML de syntaxe simple et directe, paramétrable par la personne qui va déployer le système sur un site, définit quels sont les URLs qui feront partie d un site. Dans la figure 2.1, nous voyons un fragment de ce fichier sites.xml avec quelques pages qui appartiennent au site du LIG. Cette description suppose qu une page avec un chemin de contexte (tout ce qui vient après le slash / ) qui contient l URL décrite dans sites.xml est aussi une page appartenant au site. De cette façon, l entrée http://getalp.imag.fr/ décrit aussi les pages : http://getalp.imag.fr/seminaires/ http://getalp.imag.fr/seminaires/programme.html... et ainsi de suite. Quand l utilisateur demande à l i MAG la visualisation d un site Web dans une langue cible, il souhaite aussi que les autres pages de ce site soient traduites quand, par exemple, il clique sur un lien interne de la page. Nous appellerons cette opération la navigation traduite transparente. Pour mettre cette navigation en œuvre, le prototype remplace systématiquement les liens de la page traduite par des liens vers lui-même, avec le lien original en paramètre. La définition du site Web élu à travers le fichier sites.xml a des conséquences lors de la navigation traduite. Cela signifie que l imag transformera tous les liens de la page source en liens vers la passerelle, de manière que les prochains appels à la visualisation d une page du site élu retournent une page 2 Par exemple, le navigateur Fluid, http ://fluidapp.com/ 16

traduite. Cependant, les liens externes ne seront pas redirigés vers l i MAG, puisqu une page qui n appartient pas au site élu ne doit pas être traduite par cette passerelle. À travers un fichier paramétrable contenant une liste d URL, le prototype met en œuvre un concept abstrait où la définition d un site Web est liée à l entité qu il représente. Cette approche permet une instantiation facile de l imag sur un site Web élu tout en étant suffisamment souple pour permettre à l utilisateur une navigation traduite transparente. De plus, ce même fichier ou un fichier identique peut être utilisé pour le paramétrage du rélai de traduction, dont nous parlos dans la partie 2.3. 2.2 Qu est-ce qu une page Web? Quand l imag reçoit une adresse URL, elle ouvre un flot de données pour télécharger cette page dans sa mémoire. Elle considère les éventuels redirections faites, soit à travers l en-tête Location, soit à travers la balise meta dans le document. Une fois que l adresse correcte de la page est recupérée, la page est chargée dans la mémoire de la passerelle sous la forme d un document HTML. Si la page est formée de plusieurs cadres (frames), les pages contenues dans ces cadres sont traitées une à une, comme des pages indépendantes. De la création du Web à son utilisation massive dans nos jours, l évolution a été très rapide. Au début, une page Web était un simple document HTML, unmorceau de texte avec des balises décrivant le format d affichage. Très vite, des éléments multimédia ont été rajoutés à ces documents : des images, des vidéos, des animations, etc. Ensuite, le besoin de séparer le contenu de la forme a amené à la création des feuilles de style (CSS, Cascading Style Sheets), qui ont été rajoutées aux documents. Le besoin de rajouter de la fonctionnalité à ces pages est à l origine de la création de ECMAScript, aussi connu par sa variante la plus populaire, le JavaScript. Aujourd hui, un document HTML décrit toujours le contenu d une page Web, mais il a autour de lui des documents satellites pour décrire sa forme, son comportement et ses aspects multimédia. Quand nous parlons donc de la traduction d une page Web, nous ne nous intéressons qu à son contenu. Ce travail n a pas pour but la traduction des éléments satellites appartenant à une page Web. En particulier, la passerelle ne traduit pas les éléments textuels contenus dans une animation Flash, même si cette animation prend la forme d une page ordinaire pour le visiteur non averti. 3 Pour permettre au navigateur du client de visualiser les éléments satellites, la balise base est ajoutée à l en-tête du document. De cette façon, tous les adresses relatives des éléments satellites sont cherchées en utilisant l adresse originale de la page comme base, au lieu de l adresse de la passerelle. Par exemple, si l utilisateur demande de voir la page http://liglab.imag.fr/spip.php?article107, la balise <base>http://liglab.imag.fr/</base> sera rajoutée à l élément head de la page source (aucune modification n est nécessaire si la balise est déjà présente dans la page original). Ainsi, les images, vidéos, feuilles de style et scripts pourront être localisés et la page traduite générée par l i MAG sera affichée par le navigateur avec la même forme et le même comportement que la page originale. La syntaxe d HTML a été, au début, très permissive. Dans le but d économiser de la bande passante, les concepteurs d HTML ont rendu certains éléments optionnels, comme par exemple la balise de fermeture de paragraphe (</p>). Un document HTML n est donc pas nécessairement bien formé (well formed). Les problèmes d ambiguïté de ce type de marquage ont ammené à la création de la norme XHTML, basée sur XML, où une page Web doit être bien formée et valide, selon les descripteurs (DTD, Document Type Descriptor) disponibles. Même si la tendance aujourd hui est la création de pages selon cette dernière norme, l i MAG doit aussi traiter les pages qui utilisent les vieux marquages. Par conséquent, l analyseur de documents doit permettre une certaine souplesse. Une mesure très simple a été déployée pour permettre aux développeurs du site d indiquer des parties qui ne doivent pas être traduites par l imag, tel les citations en langue originale, des bouts de code source, etc. Danc ce cas, le développeur devra mettre ce contenu dans une boîte 3 Par exemple http ://www.deezer.com/ 17

Fig. 2.2 Relai de traduction utilisé pour imag. (div) ou dans un segment (span) avec la classe notranslate. Le prototype ignorera tout le contenu de cette boîte, qui sera affiché précisement dans la langue d origine. Parmi les analyseurs HTML disponibles, deux approches sont possibles : les approches basées sur DOM (Document Object Model), où le document est converti en un arbre d objets qui pourra, alors, être traité par un langage de programmation à objets ; et les approches basées sur SAX, où le document est lu de façon séquentielle, et des événements seont déclaenchés lorsque les balises seront lues. Dans un premiers temps, par la facilité de programmation, nous avons choisi l approche DOM à partir de l analyseur fourni par la bibliothèque du projet HTTPUnit 4. L approche DOM étant trop stricte pour traiter des documents HTML, nous avons ensuite changé d approche et opté pour un analyseur SAX, disponible dans la bibliothèque CyberNeko HTML Parser 5. Cette bilbiothèque corrige des erreurs fréquentes et est indulgente avec les balises omises des documents HTML. L analyseur HTML est responsable de l extraction de segments à un premier niveau. Par exemple, il récupère le texte d un paragraphe en traitant des éventuels éléments de formatage (Voir partie 3.3). Il y a des éléments dont la traduction peut être difficile : les textes d aide sous la forme d attribut title, doivent être récupérés, ainsi que les textes des boutons, sous la forme d attribut value. Pour les boutons, certaines actions dans le serveur peuvent dépendre de ce texte, de telle façon que le traitement du formulaire doit remettre la valeur originale avant de renvoyer l information au serveur de la page. Les valeurs dans les boîtes à choix multiple sont aussi problématiques, puisque leur valeur est souvent définie par le texte qu elles affichent. Finalement, les champs de texte dans les formulaires seront remplis par les utilisateurs dans la langue cible, et le serveur de la page originale n est peut-être pas préparé pour traiter l encodage ou la sémantique de cette langue. Ce problème étant complexe, nous avons décidé de ne pas le traiter dans ce prototype, même si nous sommes conscients de son importance pour la navigation traduite transparente. Le phénomène appelé Web 2.0, produit récemment, change petit à petit la nature des pages Web, qui se rapprochent de plus en plus des applications traditionnelles. Ces nouvelles pages sont presque complètement dynamiques, et le chargement des éléments est fait de façon conditionnelle à travers des appels JavaScript, au fur et à mesure qu ils sont requis, selon les principes de la technique AJAX (Zakas et al., 2007). Dans ce travail, nous ne traitons pas les pages de ce 4 http ://httpunit.sourceforge.net/ 5 http ://nekohtml.sourceforge.net/ 18

type, car le problème n est pas intéressant du point de vue théorique, mais très vaste du côté de l implémentation. En particulier, nous retrouvons le même problème que pour les éléments et pour les valeurs des formulaires mais en plus pour beaucoup d autres éléments. Une idée de palliation temporaire est de s appuyer à nouveau sur l utilisation de la classe notranslate, laissée à l usage du développeur du site. Le comportement du développeur du site Web élu est aussi important pour la réussite de l implémentation de l i MAG. Nous attendons des développeurs de l application de bonnes habitudes de programmation menant à la production de pages Web assez propres, par exemple, en ce qui concerne l adoption de normes comme XHTML et la séparation entre forme et contenu. Les développeurs doivent aussi être conscients des limitations de la passerelle, évitant ainsi de mettre des informations textuelles qui doivent être traduites sous forme d image, d animation ou de script dynamique. Si la page est entièrement developpée sous forme d animation Flash (format propriétaire, par ailleurs), le prototype ne sera pas capable de la traduire. Le rôle des développeurs est donc aussi de faire leur partie, à travers l adoption d une programmation politiquement correcte, pour que l i MAG puisse fournir correctement l accès multilingue au site Web qu ils développent. 2.3 Le relai de traduction Le relai de traduction est un composant logiciel localisé entre le client et l imag. Il est responsable pour renvoyer les requêtes des utilisateurs vers la passerelle de traduction. Dans le cas d une seule passerelle de traduction pour un site élu, il n est pas une couche essentielle dans le processus de traduction du site. Néanmoins, lorsque nous parlons de la gestion de plusieurs sites Web traduits par plusieurs instances d i MAG, il est important de séparer la tâche de traduction des pages, concernant l i MAG, de la gestion et du routage des requêtes des utilisateurs vers les passerelles. Ainsi un site Web élu n a qu à proposer des liens vers le relai, qui, le reconnaissant, lui associera les paramètres dédiés et reliera la requête vers la passerelle i MAG. Une deuxième motivation pour l existence du relai de traduction est l existence des domaines de traduction. Un domaine de traduction est une mémoire qui contient des traductions de segments selon un domaine spécifique. Un exemple est la traduction du segment anglais Home, très fréquent dans les pages. Pour un domaine générique, il sera normalement traduit comme Page d accueil. Un site du domaine immobilier pourra, néanmoins, souhaiter que ce segment soit traduit littéralement, Maison. Par conséquent, i MAG offre la possibilité de traduire une page de façon spécifique, selon le domaine indiqué par l utilisateur. Le relai de traduction est responsable de l affectation des domaines aux sites, de façon que l utilisateur n ait pas besoin d expliciter ce paramètre. Dans la figure 2.2, nous pouvons voir l interface du relai, développé par Valérie Bellynck 6 qui a été réutilisé dans notre i MAG (le relai original utilisait le service de traduction de Google). Dans la figure, les informations entrées génèrent une requête vers la passerelle avec les paramètres correctement instanciés.. L état actuel du relai est minimal et beaucoup des informations affichées dans la page ne sont utiles qu au développement. Un travail futur et intéressant serait la création d une interface avancée de gestion de domaines, sites élus et instances i MAG pour l administration du multilinguisme des sites qui utilisent le système. 6 http ://pti.site.free.fr/wallynet/ 19

Chapitre 3 Segmentation Les informations extraites par l analyseur HTML, décrites dans la session 2.2 ne sont pas encore aptes à être directement traduites. Une segmentation non seulement structurale mais aussi linguistique est nécessaire afin de produire une traduction consistante et qui facilite la post-édition. Même si la plupart des travaux, considérant ce problème sans intérêt, négligent l importance de cette étape, le type de segmentation choisi sera décisif pour la qualité du résultat, selon les exemples illustratifs présentés par Walker et al. (2001). Dans les prochaines parties, nous discuterons les aspects qui ont été étudiés lors de la mise en œuvre de la segmentation dans le prototype imag et les choix effectués par rapport aux problèmes existants. 3.1 Taille de segment La question centrale de cette partie peut être enoncée de la façon suivante : quelle est la taille de segment idéale utilisée dans la mémoire de traduction et dans les systèmes de TA, de façon à maximiser la qualité de la traduction obtenue? Évidemment, ce n est pas une bonne idée d utiliser les mots comme segments, ignorant ainsi les constructions grammaticales et les expressions multi-mots, car la plupart des langues présentent dans le lexique un nombre d expressions multi-mots aussi grand que le nombre de mots simples (Jackendoff, 1997). Utiliser les documents entiers ou les paragraphes n est pas une bonne idée non plus, car la probabilité qu un segment de la taille d un paragraphe soit présent dans deux pages distinctes est faible. Nous éviterons donc ces solutions extrêmes et chercher une solution intermédiaire qui puisse à la fois être suffisamment grande pour que la traduction prenne en compte la polysémie et les idiosyncrasies de la langue et à la fois suffisamment petite pour que l utilisation d une mémoire de traduction se justifie par la répétition des segments à travers les pages. La tâche de segmenter un texte est plus ou moins difficile selon la langue. Pour les noms composés en allemand, par exemple, il est difficile de trouver les limites des mots car la grammaire allemande les juxtapose (par exemple Selbstbedienungtankstelle = Selbst + bedienung + tank + stelle) (Goldsmith, 1998). Certaines langues orientales comme le thaï ne possèdent pas de signe de segmentation, c est-à-dire qu il n existe pas d espace entre les mots ni de signe de ponctuation entre les phrases. Dans ce travail, nous ne considérons que les langues pour lesquelles il existe des symboles qui indiquent les limites des phrases. Nous avons décidé, dans le prototype, d employer la segmentation par phrases, pour les raisons détaillées dans les parties suivantes. Cette approche, apparemment très simple, est assez adéquate au problème, même si quelques constructions peuvent poser des problèmes pour la détection automatique des limites des phrases dans le texte brut. 20

Fig. 3.1 Exemples de cas problématiques à segmenter : équations et listes. 3.2 Cas problématiques Même si l approche choisie est directe et simple, certains types de constructions linguistiques posent des problèmes lors de la segmentation. Considérons le fragment présenté dans la figure 3.1, extrait de Wikipédia en français 1. Dans ce cas, le texte possède une équation qui le coupe en deux. Cette équation est insérée dans la page sous la forme d une image et ne peut donc pas être traitée en tant que texte. Néanmoins, ignorer son existence entraîne l extraction d une phrase où le manque d une partie peut provoquer une mauvaise traduction. Idéalement, l équation devrait être remplacée par un substitut, par exemple, par des constituants non textuels qui sont des occurrences spéciales comme $$_exp_23 (pour + 2 x e x ) ou $$_rel_37 (pour a < b) avec des 0 propriétés linguistiques facilement analysables par un analyseur morphosyntaxique. Le cas des listes est aussi difficile à segmenter. Quand la liste est, comme dans la figure 3.1, une séquence de phrases, il n y a pas de problème si nous considérons que chaque ligne correspond à une phrase. Si la liste est une séquence de compléments à une phrase, comme par exemple dans le chapitre d introductionde ce document, la solution idéale serait de rajouter de la redondance à la liste en répétant la phrase initiale avant chaque élément. Néanmoins, une solution simple pour le prblème serait de trouver les bornes des phrases et ensuite remplacer les puces et symboles spéciaux par des occurrences spéciales dynamiques du type $$<a_24... </a>, puis les traiter comme un mot composé. Nous pouvons imaginer une gamme de constructions où les algorithmes de segmentation peuvent trouver des problèmes, comme des dialogues, de la poésie, des citations imbriquées dans le texte, etc. Vu que les algorithmes d état de l art ne réussissent pas à traiter correctement une partie de ces problèmes, nous avons décidé de permettre à l utilisateur de choisir une segmentation différente de celle proposée. Cette segmentation est prioritaire par rapport à la segmentation automatique, est sera prise en compte lorsque l algorithme de détection de phrases sera appliqué sur le partie restante du texte. Cette fonctionnalité est sans doute une suggestion qui devrait être développée dans l avenir du prototype. 3.3 Le format appartient-il au segment? Le balisage HTML a pour fonction la description de la structure d un document disponible sur le Web. La définition de cette structure comprend, par exemple, la présentation des informations et leur disposition sur l écran, c est-à-dire la façon dont chaque élément (textuel, multimédia) sera affiché dans le navigateur du client. Elle comprend aussi la présentation du texte et par conséquent 1 http ://fr.wikipedia.org/wiki/information mutuelle 21

son format. L utilisation des feuilles de style CSS est une pratique recommandée dans ces cas, car elle améliore la lisibilité et la maintenabilité du document. Cependant, même s ils sont utilisés pour les paramètres globaux, certains marquages demeurent dans le texte, tels que les parties mises en relief par des caractères gras ou en police italique. Pour différencier ces balises de celles qui concernent la présentation générale de la page, nous avons récupéré depuis la spécification officielle d HTML (w3c, 1999) une liste de trente-six balises de présentation de texte acceptées dans les segments. Cette approche empirique s est montrée adéquate pour les pages sur lesquelles le prototype a été testé. L hypothèse évoquée dans la partie 2.2 sur le rôle des développeurs est toujours valable, puisque la qualité de la segmentation sera proportionelle à la propreté et à la clarté du code source. La possibilité de supprimer les balises de formatage du segment a été considérée mais abandonée pour deux raisons principales : la première concerne les systèmes de TA, qui sont assez robustes pour pouvoir travailler avec ces balises et générer une traduction cohérente. La deuxième raison pour laquelle nous n avons pas enlevé ces balises est que leur réintégration dans le segment traduit est une tâche qui n est pas triviale à résoudre, d autant plus que nous n avons pas accès aux valeurs intermédiaires générées par les systèmes de TA. Une solution considérée propose la construction d un treillis pour récupérer les traductions intermédiaires, puis le rajout des balises dans les nœuds de ce treillis, selon la figure 3.2. Nous pouvons voir que les traductions des sous-phrases ne sont pas toujours cohérentes et que l aplatissement du treillis pour la génération d une phrase avec les balises est une tâche dont la complexité est étonnamment élevée. De plus, la performance de cette méthode est inversement proportionnelle à la taille du segment à raison non-polinomiale et donc potentiellement catastrophique. Nous avons donc choisi d extraire du document les phrases avec les balises de format et de les rentrer directement dans un détecteur de phrases. Cette étape crée aussi un squelette de la page source, où chaque segment extrait est remplacé par un marqueur (par exemple $$35$$) qui sert à l identifier de façon unique. Cela est important pour la reconstruction de la page cible, comme décrit dans le chapitre 5. Analysons maintenant quelles sont les options disponibles pour cette segmentation, afin de choisir une méthode ou un outil adéquat. Fig. 3.2 Solution pour la réintégration des balises, abandonnée pour manque de performance et haute complexité. 22

3.4 Méthodes et outils Les systèmes de TA récents utilisent couramment deux tailles de segment : la phrase ou le constituent (chunk). Une phrase, dans une langue indo-européenne, est généralement identifiée à travers des signes de ponctuation. Ces signes peuvent être ambigus avec d autres types de signalisation, par exemple, le point final en français peut aussi être utilisé pour les abréviations, comme dans M. pour Monsieur, ou dans les adresses Web, comme dans www.liglab.fr. Nous nous concentrerons sur cette taille de segment, car la segmentation par constituants rend la performance du système dépendante de la performance d un analyseur syntaxique de surface (shallow parser). De plus, la segmentation par phrases est avantageuse quand les documents à traduire ont tendance à être répétitifs, comme le cas des pages Web d un site qui partagent des parties comme les menus, les en-têtes, etc. Cette décision entraîne la définition de segment dans i MAG : Définition 5. Un segment est un fragment d information sémantiquement cohérent, fréquement delimité par un signe de ponctuation, acompagné des balises de format. La définition de segment utilisée dans i MAG est, dans la plupart des cas, synonyme de la définition linguistique d une phraseou à défaut d un titre. Les algorithmes de détection de phrases sont souvent basés sur des heuristiques pour l identification des signes de ponctuation (par exemple un point final suivi d un ou plusieurs blancs ou tabulations suivi d une lettre majuscule) et sur des listes non exhaustives d exceptions, comme les listes d abréviations et les règles concernant les majuscules (Grefenstette et Tapanainen, 1994). Pour cela, les règles sont codées en dur par des d expressions régulières qui décrivent les limites des phrases et les exceptions. Cette approche a été utilisée dans de nombreux projets, par exemple le projet UNLDeco, développé au GETALP (Sérasset et Boitet, 2000). Les règles peuvent aussi être séparées de la partie fonctionnelle et être décrites dans un formalisme équivalent aux expressions régulières dans un fichier à part. Les outils à l état de l art considèrent la détection de phrases comme un problème de classification, utilisant la méthode de l entropie maximale pour classifier les séparateurs potentiels. Les attributs utilisés dans cette tâche peuvent être de haut niveau (les catégories grammaticales, ou POS, de l anglais Part Of Speech), ou bien la classification peut utiliser seulement des attributs morphologiques tels que la longueur de la phrase, la casse des mots voisins, etc. Les évaluations réalisées par Walker et al. (2001) montrent que, sur un corpus de domaine général, la dernière technique est celle qui présente la meilleure performance. Pour l i MAG, nous avons choisi d utiliser une bibliothèque, LingPipe, qui met en œuvre un algorithme de détection de phrases à l état de l art. Les expériences sur le corpus GENIA (Ohta et al., 2002), une collection de résumés du domaine biomédical, ont montré que cet algorithme atteint une performance de plus de 99,7% de précision, avec une f-mesure d environ 99,6% 2. L approche choisie réunit donc tous les segments extraits de la page dans un seul bloc de texte, qui est ensuite segmenté par le module de détection de phrases de LingPipe. Les phrases seront ensuite traduites et reintegrées dans le document, comme nous l expliquerons dans les prochains chapitres. 2 http ://alias-i.com/lingpipe/demos/tutorial/sentences/read-me.html 23

Chapitre 4 Traduction : mémoires et systèmes Nous décrirons dans cette partie deux types de systèmes de TALN dont le rapport, dans un premier temps, ne sera peut-être pas explicite, mais qui sont associés dans une i MAG. Premièrement, nous introduirons les Mémoires de Traduction (MT 1, car nous utiliserons ce mécanisme pour stocker et récupérer les traductions d un site. Ensuite, nous présenterons une très brève analyse des outils que nous utilisons pour effectuer la Traduction Automatique des segments. Tout d abord, récapitulons ce que nous avons jusqu à présent : nous avons défini nos objets de travail, c est-à-dire le site et la page Web, puis nous avons discuté du traitement des éléments de la page et de la segmentation des documents HTML. Nous avons donc, comme entrée pour la prochaine étape, un ensemble de segments en langue source et un squelette du document, contenant sa structure originale, où les segments ont été remplacés par des identifiants. Une question qui, jusqu ici, a été négligée est la détection de la langue source. L utilisateur a la possibilité d indiquer la langue source dans laquelle le site a été développé. Une page peut décrire la langue du document à travers l en-tête HTTP Language ou à travers les balises meta ou encore les attributs lang et xml-lang. Néanmoins, il est nécessaire de prévoir le cas où ces informations soient incompatibles entre elles et avec les langues dans lesquelles le document a été écrit. Par conséquent, il serait idéal de mettre en place un algorithme de détection automatique de la langue source, appliqué à chaque segment, qui utilise des informations comme les indications dans les en-têtes et balises de la page, ainsi que la langue des autres segments et, évidemment, les caractéristiques morphologiques et lexiques du segment. La suite LingPipe offre un module pour l identification de langue, qui utilise un algorithme d apprentissage et considère le problème comme une tâche de classification. Comme il s agit d une solution très souple, nous avons envisagé son utilisation. Néanmoins, entraîner le modèle est un processus qui consomme beaucoup de temps et qui n est pas dans le contexte de ce stage. Dans l état actuel, le prototype n incorpore donc pas la détection automatique de la langue, même si du point de vue théorique ce problème a été abordé. Il serait important de considérer cette fonctionnalité dans l avenir du projet. Pour étudier les MT et systèmes de TA dans les prochaines parties, nous considérerons qu ils reçoivent en entrée une suite de segments, chaque segment ayant une langue source associée, et une langue cible unique pour tous les segments étant définie par l utilisateur. 4.1 Mémoires de traduction Définition 6. Un système de Mémoire de Traductions (MT) est une base de données qui stocke des segments de texte avec leurs traductions respectives. Nous appelons ces entrées bi-segments, même si elles peuvent contenir la traduction du segment source dans plus d une langue. 1 À ne pas confondre avec l abréviation anglaise MT pour Machine Translation). Dans ce travail, nous utilisons les termes en français Traduction Automatique et Mémoire de Traduction et donc les abbréviations TA et MT. 24

Les systèmes de MT sont très populaires parmi les traducteurs professionnels qui, avec une interface adéquate, peuvent utiliser les traductions effectuées dans le passé pour traduire de façon plus performante les nouveaux documents. La réussite de ces systèmes est conditionnée à la répétitivité des documents, mais aussi à l algorithme de correspondance utilisé. La correspondance exacte atteint une très haute précision, puisque les traductions récupérées n ont besoin que de corrections minimes pour être réutilisées. Le rappel de cette correspondance est, cependant, très faible, puisque la répétition est très rare. Plusieurs systèmes de correspondance approchée (fuzzy match) ont été proposés, basés par exemple sur une simple distance d édition de caractères ou de mots (Levenshtein, 1966). La distance d édition étant une simplification trop grossière de la distance effective entre deux segments dans une mémoire de traduction, des solutions plus sophistiquées ont été créées. E. Planas utilise une combination d informations morphologiques, lexicales, syntaxiques et sémantiques pour calculer plusieurs niveaux de similarité entre les segments (Planas et Furuse, 2003). La distance entre les segments est alors une fonction de leur distance d édition sur plusieurs niveaux d abstraction. Biçici et Dymetman (2008) adaptent l algorithme présent dans le logiciel commercial TRADOS, en calculant la plus grande sous-chaîne commune (Longest Common Subsequence) entre les segments (sans considérer l ordre des mots) puis en alignant les mots des segments pour trouver les parties en commun et les parties divergentes. Le système de MT utilisé par notre prototype a été développé en interne par le GETALP. SECTra w n est pas seulement un système de MT, mais un système complet de gestion de corpus parallèles pour l aide à la traduction. Il possède des fonctionnalités de traduction, post-édition, visualisation, importation, exportation et évaluation des traductions (Huynh et al., 2008), inspiré par BEYTrans (Bey et al., 2006). Nous utiliserons uniquement la fonctionnalité de stockage et de récupération des segments, considérant le site Web à traduire comme un corpus bilingue. SECTra w a été développé sous forme de système Web, et l interaction entre une imag et sa mémoire de traduction se fait à travers une requête HTTP. Il existe deux types de requête, la demande de traduction et la mise à jour d un segment, résultat d une post-édition ou de la traduction d un segment qui n est pas présent dans la MT. Les interfaces de ces deux types de requêtes sont : Demande de traduction : Entrée : Segment source Langue source Langue cible Corpus/domaine Sortie : Identifiant du segement source Liste de traductions disponibles Demande de mise à jour : Entrée : Identifiant du segment source Nouvelle traduction Source (TA, post-édition) Ces deux interactions simples sont employées lors de la traduction d une page et lors de la suggestion, par l utilisateur, d une meilleure traduction pour un segment donné. L interface complète de SECTra w ne sera proposée à l utilisateur que s il le souhaite. Dans ce cas, le système offre un environnement complet et souple qui augmente la performance d un traducteur qui réalise de la post-édition (cf. partie 5.1). La MT peut ne pas contenir un segment spécifique demandé par l imag, si la page n a jamais été traduite ou si elle a changé. Le cas échéant, un système de TA sera appelé pour fournir une traduction de plus basse qualité. 25

4.2 Systèmes de traduction automatique Ce travail n a pas l ambition d évaluer les systèmes de TA existants. Ce type d analyse est très récurrent, par exemple, sur des blogs 2, mais aussi effectué de façon formelle par des institutions comme l agence nort américaine NIST 3 et la conférence IWSLT 4. Nous énoncerons quelques techniques utilisées pour la traduction : Traduction basée sur des règles : cette méthode est la plus ancienne, et considère que la traduction est analogue au déchiffrement d un code (Arnold et al., 1993). Dans cette approche, les règles de traduction sont spécifiées par des linguistes et des traducteurs, et la qualité du système évolue à travers les tests, dans la mesure où les erreurs de traduction sont analysées et corrigées par les spécialistes. Ces règles peuvent être implémentées dans plusieurs niveaux : Traduction par transfert : La représentation intermédiaire entre la langue source et la langue cible peut en être dépendante. Cela signifie que, généralement, le texte en entrée est analysé afin de générer une représentation intermédiaire qui sera, à travers des règles grammaticales et des dictionnaires, utilisé dans la génération du texte dans la langue cible. La plupart des systèmes de TA emploie ce type d approche. Traduction par interlangue : Dans cette approche, le texte en langue source est converti vers une représentation sémantique abstraite totalement indépendante des langues source et cible (par exemple, un graphe UNL). Le génération de la traduction se fera à partir de ce graphe. Cette methode permet la génération de traductions dans plusieurs langues cible à partir d une représentation unique et indépendante du texte en langue source. Traduction par dictionnaire : Un dictionnaire bilingue est utilisé pour remplacer directement les mots par leurs correspondances en langue cible. La traduction générée n est utilisable que dans des cas spéciaux comme des listes et des catalogues, où les contraintes grammaticales sont très simplifiées voire absentes. Traduction basée sur exemples : Technique qui emploie des algorithmes similaires aux algorithmes de correspondance présentés pour les MT pour produire une analogie entre la phrase à traduire et les phrases présentes dans le corpus d entraînement. Une fois que les analogies sont trouvées, les parties divergentes du segment sont traduites à l aide d un dictionnaire. Traduction statistique : En ustilisant un grand volume de corpus parallèles alignés, le système calcule les paramètres du modèle de la langue à travers des techniques statistiques. Des très bons résultats ont été obtenus récemment par Google avec cette approche. Nous avons étudié l utilisation de deux services de TA commerciaux disponibles en ligne : Sytran et Google. Ils sont accessibles à travers des requêtes HTTP, de la même façon que la MT de SECTra w. Systran est un des systèmes de TA les plus populaires, étant utilisé par exemple par Microsoft et par BabelFish. Le service de Google est assez récent (disponible depuis 2007) et utilise un algorithme de traduction statistique. Le choix du service de TA dansune imag a pour critère la paire de langues source et cible demandées et les paires de langues offertes par les deux systèmes. S ils possèdent les langues demandées, Systran est systématiquement choisi, même si dans l avenir un choix basé sur des paramètres plus fins, tels que le nombre de mots inchangés, est envisagé. Dans l avenir, aussi, nous souhaitons intégrer les traductions générées avec la base lexicale PIVAX, développée aussi par l équipe GETALP et décrite par Nguyen et al. (2007). L idée ici serait d utiliser les traductions obtenues de façon automatique ou à travers la post-édition pour construire une base lexicale pour un domaine spécifique ou un site Web élu. Cette base pourrait être utilisée comme outil dans l interface avancée de SECTra w, de façon à aider les traducteurs professionnels ou bénévoles. La construction de ressources lexicales comme les dictionnaires et thésaurus est importante, par exemple, pour le traitement et la traduction adéquats des expressions multi-mots d une langue (Ramisch et al., 2008). 2 Cf. blog de Jean Véronis http ://aixtal.blogspot.com/2006/01/translation-systran-or-reverso.html 3 http ://www.nist.gov/speech/tests/mt/2008/ 4 http ://www.slc.atr.jp/iwslt2008/ 26

Chapitre 5 Génération de la page cible Étant donné que, dans l étape de segmentation, les segments source ont été remplacés dans la page par leurs identifiants, la tâche de reconstruction de la page cible est réduite à la substitution des identifiants de segment présents dans le squelette par les traductions des segments qui portent ces identifiants. Cependant, nous voulons ajouter à ces segments traduits deux foncionnalités : l affichage du segment en langue source et la possibilité d envoyer une post-édition pour améliorer la traduction. Ces deux fonctionnalités ont été rajoutées à travers un script qui est décrit dans la prochaine partie. Nous proposerons également des affichages alternatifs, à être implémentés dans l avenir, de façon que l interaction avec l utilisateur soit optimisée. 5.1 Post-édition L affichage du segment source ne doit pas compromettre l affichage de la page traduite. Ainsi, le système de traduction de Google, par exemple, montre le texte original dans une boîte superposée à la page lors du passage du curseur sur le segment, comme illustré dans la figure 1.3. Nous avons choisi d employer la même approche, puisqu il s agit d une façon simple et efficace de fournir cette information à l utilisateur, et pour cela nous avons utilisé la bibliothèque JavaScript MooTools 1. Ainsi, chaque segment réinséré dans la page cible a reçu une infobulle avec le segment source, comme dans la figure 6.11. Un problème a été trouvé concernant le temps d affichage de ce message, puisque le simple mouvement de la souris entraînait le changement de position du message affiché. La solution palliative employée consiste à donner un temps d affichage très long à l infobulle, ainsi l utilisateur aura le temps de la lire et de cliquer sur Suggerer une traduction..., s il le souhaite. Nous croyons que ce problème peut être corrigé en étudiant calmement la documentation de la bibliothèque et probablement en changeant l implémentation de cette fonctionnalité. 5.2 Affichage des correspondances Une autre solution d affichage possible a été inspirée par les amphigrammes : des arbres contenant des bi-segments alignés (Chenon, 2005; Cromières, 2004, 2005). La correspondence entre les sous-phrases d un segment est trouvée à travers une approche statistique, en calculant l information mutuelle entre chaque paire de mots dans un grand volume de texte aligné, puis en choisissant la correspondence qui maximise l information mutuelle, i.e. qui minimise l indépendance entre les sous-phrases. Ainsi, en utilisant ces valeurs pré-calculées, il est possible de construire les amphigrammes dynamiquement a partir d un bi-segment, et ensuit d afficher l alignement en utilisant des couleurs foncées pour la sous-phrase selectionnée et des couleurs successivement plus claires pour les niveaux supérieurs dans la représentation en arbre du bi-segment. Cette forme d affichage a pour avantage une meilleure compréhension de la traduction générée, par exemple, par 1 http ://mootools.net/ 27

un système de TA. L utilisateur pourrait, dans ce type d approche, choisir le segment qu il pense pouvoir être mieux traduit parmi les sous-phrases affichées. De cette manière, la mise à jour du segment dans la mémoire de traduction peut être optimisée (à travers l utilisation des sous-phrases au lieu des phrases) et la récupération de ces dernières peut utiliser cette information lors de la correspondance approchée entre les segments stockés et un segment à traduire. Le calcul de l information mutuelle pour toutes les paires de mots est une opération très coûteuse et entraîne l utilisation d un volume important de données. Les ressources nécessaires pour ce calcul sont disponibles, par exemple, sous la forme de corpus parallèles, comme Europarl, extrait des transcriptions des séances du parlement européen et très populaire pour la TA statistique (Koehn, 2005). Le temps de ce stage étant limité, nous n avons pas pu obtenir ces précorrespondences entre les sous-phrases. Cette approche reste donc une suggestion d amélioration pour les prochaines étapes dans le développement du prototype. Fig. 5.1 Exemple d affichage d un amphigramme. 5.3 Interface avancée de traduction Un dernier point important à remarquer sur la génération de la page cible concerne la disponibilité d une interface avancée pour la post-édition de la page ou du site élu. Cette interface est, en fait, mise à disposition à travers un lien vers une instance de SECTra w, comme nous pouvons le voir dans la figure 5.2 (Huynh et al., 2008). Pour effectuer une édition avancée des traductions, l utilisateur aura besoin de s identifier. Même si, apparemment, l identification peut sembler sans intérêt, elle est très importante puisqu elle permet un suivi des traductions effectuées, tout comme l affectation d une crédibilité plus élevée aux traductions réalisées par les utilisateurs identifiés. 28

Fig. 5.2 Interface de SECTra w, utilisée pour la post-édition avancée dans l imag. 29

Chapitre 6 Mise en œuvre Dans les derniers chapitres, nous avons étudié d un point de vue théorique les problèmes liés à la récupération de la page source, ainsi qu à la segmentation, la traduction et la génération de la page cible dans le prototype i MAG, tout comme les décisions prises par rapport aux alternatives analysées. Lorsque le prototype reçoit une demande de traduction d une page, il la télécharge et la pré-traite, pour ensuite extraire les éléments textuels avec le format de base. Ces éléments sont ensuite segmentés par LingPipe et traduits, un à un, par la mémoire de traduction de SECTra w ou, si la MT ne contient pas le segment, par un système de TA. Finalement, les segments et les traductions sont rajoutés au squelette de la page cible avec les scripts nécessaires pour l affichage de la source et la post-édition des segments. Nous avons donc toutes les spécifications fonctionnelles nécessaires à la construction du prototype. Ci-dessous, nous donnons une liste non exhaustive d exigences non-fonctionnelles du prototype : Il doit offrir une interface Web à travers laquelle les paramètres (URL du site, langues source et cible, domaine) peuvent être entrés. Cette interface peut prendre la forme d une page Web ou d un appel à travers une méthode HTTP. L interface développée doit être sécurisée, évitant les intrusions à travers les paramètres du système. La performance de la traduction ne peut pas augmenter le temps de charge de la page au délà de la limite tolérable par l utilisateur. Les études empiriques montrent que cette valeur tourne autour de 5 secondes. 6.1 Architecture Au lieu de débuter directement la conception et le codage du prototype, il est important d établir un panorama général qui aidera la définition des frontières du problème traité. Nous exposerons ainsi un ensemble de visions du prototype, en nous servant de diagrammes formels d architecture logicielle. Ce découpage offre comme avantage d un côté l indépendance sémantique des visions et d un autre côté un niveau de détail suffisamment abstrait pour permettre des changements potentiels. 6.1.1 Modélisation du contexte Sur le diagramme de la figure 6.1, les relations entre le système et les acteurs qui interagissent avec lui sont explicitées. Afin d obtenir un diagramme simple, le prototype est modélisé comme une boîte noire dont les fonctionnalités seront peu à peu développées dans les prochaines parties. Nous observons que la plupart des acteurs sont des composants et des services logiciels, présentés dans des rectangles, tandis que les internautes sont des acteurs qui représentent des humains. Les internautes non-identifiés accèdent au service de façon anonyme et leurs post-éditions 30

advanced post-edition Identified Cybernaut <<actor>> Sectra (TM) <<actor>> HTTP Server translation segments/post-editions view a site in a target language translated page GET/POST request HTML page imag segment translation <<actor>> MT System translation request translated page <<actor>> Web Site translation request translated page <<actor>> Redirection Gateway Cybernaut view the page in another language translated page Fig. 6.1 Diagramme de contexte pour le prototype imag. ne pourront être faites que dans une interface simple. Les internautes identifiés pourront accéder à SECTra w pour disposer d un environnement plus riche de post-édition. Pour effectuer la traduction d une page Web donnée, nous imaginons ici deux cas de figure : soit l internaute non-identifié demande directement à l i MAG de voir une page Web de son intérêt dans une langue cible (en spécifiant manuellement aussi le domaine du site), soit il fait la demande à un site Web qui demandera alors à un relai de faire l interface avec l imag. Dans les deux situations, les informations d entrée sont la paire de langues, l adresse de la page à traduire et le domaine du site. Ayant reçu la demande de traduction, le prototype récupère la page auprès d un serveur sur Internet, pour ensuite utiliser un système de MT et de TA pour traduire les segments extraits de la page. Finalement, le résultat de la traduction sera retransmis au demandeur le relais ou l internaute. Pour la post-édition, l action implique les mêmes acteurs coordonnés de manière similaire à la précédente, raison pour laquelle nous ne la détaillerons pas ici. 6.1.2 Architecture conceptuelle L architecture conceptuelle concerne les modules qui composent le prototype. Un module n est pas une classe dans le sens de la programmation à objets, mais a une granularité moins fine, pouvant correspondre dans la pratique à un paquet ou à un ensemble de classes, par exemple. Nous proposons dans la figure 6.2 une division en quatre modules principaux coordonnés par un module de contrôle. Les quatre modules, à savoir pré-traitement, segmentation, traduction et reconstruction, correspondent au noyau fonctionnel du système. Parallèlement, les modules pour l interfaçage avec les acteurs composent une couche supplémentaire d abstraction, très importante étant donné la dépendance du système vis-à-vis de ces ressources externes. Le module d interface Web avec l internaute ne communique pas directement avec le module de contrôle : la communication passe à travers l interface de redirection. Cela permet que le module de contrôle traite les demandes de traduction de façon homogène et transparente. 31

HTTP Server Sectra imag Segmentation segments Translation Memory Interface translations/post-edition HTTP Interface HTML pages Control segments Translation translation request structure/translations translations Redirection Interface translated pages Page Reconstruction translation request Machine Translation Interface Human-Machine Interface Redirection Gateway Cybernaut MT System Fig. 6.2 Diagramme d architecture conceptuelle pour le prototype i MAG. 6.1.3 Architecture dynamique Les deux cas d utilisation les plus importants pour le prototype sont la traduction d une page Web et la post-édition d une traduction. Le premier est détaillé dans la figure 6.3, où nous voyons que le relai de traduction est responsable de sélectionner le domaine de la page à traduire 1. Une demande directe à l interface homme-machine peut aussi contenir un domaine spécifié manuellement par l internaute. Les appels aux interfaces de mémoire de traduction et de traduction automatique sont réalisés en boucle jusqu à ce que tous les segments soient associés aux meilleures traductions disponibles, qui seront enregistrées dans la MT. Ce diagramme met en évidence le rôle de coordination exercé par le module de contrôle. Le deuxième cas d utilisation étudié ici est la post-édition d un fragment de texte, dans la figure 6.4. Le fragment dans la langue cible et dans la langue source est envoyé au contrôle, qui se chargera de découper le fragment et sa traduction et, ensuite, de les mettre à jour dans la MT correspondant au domaine du site. 6.1.4 Architecture physique Le déploiement du prototype se fera de manière conventionnelle sur un serveur Web disponible à l accès des clients à travers un navigateur Internet. Les serveurs HTTP montrés sur la figure 6.5 fournissent à l i MAG les pages à traduire. Dans une configuration hypothétique, SECTra w et le relai de traduction peuvent être déployés sur deux machines indépendantes. Vu qu il s agit d un système disponible sur Internet, la plupart des connexions utiliseront le protocole HTTP sur la couche TCP/IP. 1 La façon dont le relai fera ce choix sera considérée, dans ce travail, hors sujet. Évidemment, nous considérons que le domaine choisi sera lié à un site, une personne, une institution, une entreprise, un groupe de personnes, etc. 32

Human-Machine Interface Redirection Interface Control Http Interface Segmentation Translation MT Interface TM Interface Page Reconstruction Cybernaut translate a page translate(addr,langpair) translate(addr,langpair,domain) getpage(addr) page split(page) segments[],structure translate(segment) translation translate(segment) translation reconstruct(structure,translation[]) translatedpage translatedpage translatedpage translatedpage Fig. 6.3 Diagramme d architecture dynamique pour la traduction d une page Web. Human-Machine Interface Redirection Interface Control Segmentation TM Interface Cybernaut post-edition postedit(source,target) postedit(source,target,domain) split(source) sourcesegs[] split(target) targetsegs[] update(sourcesegs[i],targetsegs[i],domain) Fig. 6.4 Diagramme d architecture dynamique pour la post-édition d une traduction. 33

HTTP Server HTTP Server HTTP Server Sectra Server TCP/IP - LAN TCP/IP - HTTP HTTP Translation Memory Interface Control HTTP Server HTTP Server Internet Cybernaut Cybernaut TCP/IP - HTTP Cybernaut Cybernaut Cybernaut HTTP Machine Translation Interface HTTP HTTP Interface Page Reconstruction HTTP Human-Machine Interface Translation Redirection Interface Segmentation HTTP Java EE Server (Tomcat) TCP/IP - LAN Redirection Gateway Fig. 6.5 Diagramme d architecture physique pour le déploiement du prototype i MAG. 6.2 Conception Fig. 6.6 Organisation de haut niveau des modules. Nous présenterons brièvement, dans cette partie, la conception du prototype. Dans la figure 6.6, l organisation que celle des modules est présentée selon la même organisation des chapitres utilisée dans ce rapport, permettant une bonne séparation des tâches. Un module d utilitaires a été rajouté pour les fonctions auxiliaires tels que le traitement d URL et les fonctions de tableau. Afin de gérer la possibilité de changement d implémentation d un module, nous avons utilisé intensément les interfaces pour la plupart des communications entre les modules. Cela permet à un module, par exemple celui qui fait le traitement de la page HTML, de traiter l entité abstraite représentée par l interface Page. De manière similaire, le module utilisant le traitement des pages ne connaît que l interface HTMLProcessor. Le schéma affiché dans la figure 6.7 montre une implémentation utilisant les classes natives de Java pour le téléchargement et le traitement des pages, où la classe NativePage implémente l interface Page. Pour le traitement des éléments de la page, nous avons écrit un analyseur SAX qui utilise la configuration de la bibliothèque CyberNeko, dans la classe HTMLPreprocessor (Voir partie 6.3). Dans la figure 6.8, le même type de modèle est représenté avec les classes appartenant aux modules de traitement de la page dans le paquet http et de détection de phrases, segmentation. La classe Translate est responsable de l interface entre les paramètres des appels HTTP traités 34

Fig. 6.7 Modèle conceptuel du module de traitement de pages par Struts dans une page JSP et les valeurs internes des variables Java. Les classes Segment et Skeleton représentent les objets de base de la segmentation. Nous ne présenterons qu une partie de la conception du prototype car ils ne rajoutent pas d informations pertinentes pour la discussion. Ces modèles ont été utilisés pour le codage du système 6.3 Codage et instantiation Le langage à objets Java a été choisi pour la mise en œuvre du prototype, permettant une grande portabilité et fournissant des outils sophistiqués de passage à l échelle. Vu qu il s agit d un système Web, nous avons utilisé la technologie J2EE sur un serveur Apache Tomcat. Nous avons, comme décrit dans la partie 6.2, diminué le couplage entre les modules en bénéficiant des interfaces Java pour gérer l hétérogéneité intrinsèque au projet, de façon qu un module puisse facilement changer son implémentation sans que, pour ce faire, il soit nécessaire de modifier les autres modules. La couche de présentation a été implémentée à travers les Java Server Pages, qui permettent une interaction intelligente entre la logique de programme et la visualisation, tout comme de l extension Apache Tiles, qui permet la réutilisation des tiles, c est-à-dire des carreaux, pour les parties fixes de l interface comme les menus et les en-têtes. Le contrôle du prototype n emploie pas directement les servelettes, mais est effectué de manière descriptive à travers l utilisation de la bibliothèque Apache Struts 2. Même si la mise en place de cet outillage prend plus de temps que l approche traditionnelle, elle se justifie par le gain de 35

Fig. 6.8 Modèle conceptuel général des modules de traitement et segmentation de page. 36