INP Grenoble – ENSIMAGEcole Nationale Superieure d’Informatique et de Mathematiques Appliquees de Grenoble

Rapport de projet de fin d’etudes

Effectue au LIG - GETALP :Laboratoire d’Informatique de Grenoble

Groupe d’Etude en Traduction/Traitement Automatique/Automatise des Langues et de la Parole

Developpement d’un site Web iMAGa generiqueet instanciation sur des sites iMAG concrets

ainteractive Multilingual Access Gateway

Carlos RAMISCH3e annee – Option ISI

25 mars 2008 – 29 aout 2008

LIG - GETALP Responsables de stage385, Rue de la Bibliotheque Christian BOITET et Valerie BELLYNCKBP 53 Tuteur de l’ecole38041 GRENOBLE CEDEX 9 Pierre BERLIOUX

Remerciements

Tout d’abord, je remercie, par sa confiance et patience, mon tuteur au GETALP, ChristianBoitet, qui a ete un toujours accessible pour repondre a mes questions et qui m’a motive etguide durant tout le travail effectue au sein du GETALP. Je voudrais egalement remercier ValerieBellynck, cotutrice de stage, pour sa patience et son interet aux problemes de conception et dedeveloppement, aussi que pour ses precieuses suggestions qui m’ont permis de toujours avancer.

Troisiemement, je voudrais remercier les personnes de l’ENSIMAG qui m’ont aide a surmonterles difficultes qui se sont presentees au long du chemin, specialement Pierre Berlioux, mon tuteur,tout comme Marie-Laure Potet, Marianne Genton et Sebastian Viardot. Je reconnais que, sansleur support et leur aide, ce travail n’aurait pas ete possible.

Je remercie vivement Aline Villavicencio, pour les opportunites qu’elle m’a offertes, et pourla confiance qu’elle me porte. Elle partage avec moi non seulement la passion pour le traitementautomatique des langues, mais aussi son amitie.

L’equipe du GETALP a aussi ete importante pour l’aboutissement de ce projet : j’adressemes remerciements a toute l’equipe, specialement a Mathieu Mangeot, a Huynh Cong-Phap et aHong-Thai Nguyen, qu’ont ete de tres bons collegues de travail. Merci aussi a Herve Blanchon eta Floralis, responsables du support financier du projet.

Je remercie les professeurs de l’ENSIMAG et les professeurs de mon universite d’origine,UFRGS, pour leur grande competence dans leur metier et pour la qualite de leur enseignementqui m’a permis de resoudre avec maturite les defis de la vie professionnelle.

Je remercie egalement la commission de selection du projet SCISTEMA, qui m’a fait confiancepour participer de cet echange international avec l’INP Grenoble et l’ENSIMAG.

Finalement, j’exprime ma gratitude vis-a-vis de ma famille et de mes amis, sans lesquels rien neserait possible. Le travail de l’ingenieur et du scientifique ne se fait pas, comme dans les caricatures,enferme dans un laboratoire solitaire, mais il est le resultat d’un effort collectif. A tous ceux qui,de facon directe ou indirecte, ont contribue a la reussite de ce travail, je vous dis (( MuitıssimoObrigado )) !

2

Resume

Ce rapport decrit le travail effectue au cours du stage de Carlos Ramisch au sein du GETALPdurant la premiere moitie de 2008, dans le cadre de son projet de fin d’etudes a l’ENSIMAG.Tout d’abord, nous placerons le travail du groupe et du stagiaire dans le contexte global de latraduction automatique. Ensuite, nous definirons la notion de site et de page Web, tout comme lesdefis poses par ces objets de constitution diverse, justifiant ainsi la proposition de la solution iMAG.Les quatre etapes necessaires pour l’implementation d’un prototype seront detaillees a travers uneconceptualisation suivie d’une description des choix effectues lors de la mise en œuvre des concepts.Cette methodologie est employee pour decrire le traitement des pages, leur segmentation en unitesde traduction minimales (phrases ou titres), dites (( segments )), le traitement des segments par lesmemoires et systemes de traduction et la generation de la page cible. Avant les conclusions, nousdetaillerons les phases d’analyse, de conception et d’implementation du prototype, avec une etudesur son deploiement sur le site du LIG. Finalement, nous presenterons ce qui a ete fait, ce quireste a faire et les contributions de ce projet sur le plan professionnel, academique et personnel.

Abstract

This report covers the work accomplished by Carlos Ramisch during the first semester of 2008regarding 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 internshipin this global picture. The motivation of the iMAG concept relies on the existing problems in themultilingual access to online information systems, and therefore we will define these heterogeneousobjects 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 discussionfollowed 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 originalWeb page, its segmentation by sentence detection, the use of translation memories and systemsto process it and the generation of a new target page using the skeleton of the source page, thetranslated segments and some interaction functionalities. Before we show our conclusions, we willstudy the analysis, design and development of the prototype, along with a test instantiation overthe LIG’s Web site. Finally, we will specify what has effectively been done, what is left to be doneand what are the contributions of this project to its participants from the professional, academicand personal points of view.

3

Table des matieres

Introduction 5

1 Problematisation de la traduction des systemes Web 71.1 Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.2 Techniques de localisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1.2.1 Localisation interne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.2.2 Localisation externe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

1.3 Une solution possible : iMAG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2 Les defis du Web 152.1 Qu’est-ce qu’un site Web ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.2 Qu’est-ce qu’une page Web ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.3 Le relai de traduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3 Segmentation 203.1 Taille de segment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.2 Cas problematiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.3 Le format appartient-il au segment ? . . . . . . . . . . . . . . . . . . . . . . . . . 213.4 Methodes et outils . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4 Traduction : memoires et systemes 244.1 Memoires de traduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244.2 Systemes de traduction automatique . . . . . . . . . . . . . . . . . . . . . . . . . 26

5 Generation de la page cible 275.1 Post-edition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275.2 Affichage des correspondances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275.3 Interface avancee de traduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

6 Mise en œuvre 306.1 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

6.1.1 Modelisation du contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306.1.2 Architecture conceptuelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316.1.3 Architecture dynamique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326.1.4 Architecture physique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

6.2 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346.3 Codage et instantiation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

7 Conclusions 39

References 40

A Planning comparatif 43

4

Introduction

La langue francaise, comme d’ailleurs toutes les autres langues naturelles (que l’on peut aussiappeller langues (( humaines )) pour les opposer aux langues artificielles et aux langages informa-tiques), n’est pas uniquement un ensemble de mots et de regles grammaticales pour regrouperces derniers et creer des phrases. Une langue est composee de ses expressions idiomatiques, seshabitudes, ses nuances, ses aspects historiques, son usage, ses references culturelles, etc. Le langagehumain est ainsi un objet complexe par sa dependance au contexte ou il est employe.

La traduction peut etre definie comme le processus de transformation d’une information ex-primee dans une langue (la langue source) en une information correspondante dans une autrelangue (la langue cible). Puisque les langues, source et cible, sont des structures complexes, latraduction est une tache qui, elle aussi, est complexe et par consequent couteuse. Cependant, latraduction est essentielle dans plusieurs contextes, sans etre exhaustif :

– les communautes et organisations composees par plusieurs pays (comme l’Union europeenne,l’ONU, l’UNESCO, le FMI) ;

– les pays ou plusieurs communautes linguistiquement diverses cohabitent (comme le Canada,la Suisse et la Belgique, ou le francais n’est pas la seule langue officielle) ;

– les entreprises multinationales, de par leurs collaborateurs, leurs partenaires ou leurs clients ;– les communautes virtuelles (comme Pax Humana1, ou des individus du monde entier colla-

borent pour la defense des Droits de l’Homme).Les premiers pas vers l’automatisation de cette tache, au debut des annees 1950, ont pour

origine l’euphorie provoquee par le succes des machines a decrypter durant la seconde guerremondiale. L’analogie peut etre enoncee de la facon suivante : si un texte ecrit dans une languepeut etre considere comme un message dans la langue cible qui est encode dans une langue source,alors traduire n’est que dechifrer ce message (Arnold et al., 1993).

Cette analogie a mene a un optimisme exagere et a de grands espoirs quant a la TraductionAutomatique (TA, anglais Machine Translation, MT ). A l’epoque2, les chercheurs disaient que dansdix ans, un ordinateur genererait une traduction de haute qualite (i.e. comparable a la qualite d’untraducteur humain) de n’importe quelle information exprimee dans une certaine langue source.Nous savons aujourd’hui que ce n’est pas le cas, et meme que nous ne pourrons jamais obtenir ala fois un maximal en couverture, qualite et automaticite, l’amelioration de deux de ces aspectsse fait toujours en detriment du troisieme. Pour autant cela ne veut pas dire que la TA n’est pasutile. Elle est souvent tres efficace, par exemple, pour des sous-langages et domaines specifiques, ouquand une traduction de haute qualite n’est pas necessaire (pour une comprehension globale d’uneinformation dans une langue completement inconnue du lecteur). Dans ce travail, nous montreronsqu’une de ses utilites est d’aider les traducteurs humains a augmenter la performance de leur travailde facon significative. Neanmoins, nous supposons que la traduction completement automatique etavec haute qualite de n’importe quel texte issu de n’importe quel contexte est impossible, car elleest dependante d’une connaissance du monde qui ne peut pas etre representee de facon raisonnabledans la memoire d’un ordinateur. Cette supposition a ete presentee par Bar-Hillel (1960), et estsoutenue de facon credible par la plus grande partie de la communaute scientifique (Boitet et al.,1980).

1http ://paxhumana.info/2Vers 1954, lors de la premiere demonstration du systeme GAT (Georgetown Automatic Translation) sur quelques

phrases russes.

5

Cette hypothese va etre la base du travail decrit dans ce rapport : la traduction totalementautomatique n’etant pas assez bonne et la traduction humaine etant tres couteuse, les chercheursont propose des approches hybrides, ou la machine genere des pre-traductions qui sont ensuitepost-editees par des traducteurs professionnels ou volontaires. Les outils developpes pour cettetache sont classifies comme des outils de Traduction Assistee par Ordinateur (TAO, de l’anglaisComputer Assisted Translation, CAT ).

Nous nous interesserons specifiquement au developpement d’un outil de TAO pour la traductiondes sites Web. L’idee d’un outil qui fonctionne comme une passerelle de traduction pour un siteWeb elu a ete proposee par Christian Boitet (Boitet et al., 2008) et un tout premier prototypea ete developpe par Mohammad Daoud (Daoud, 2007). L’iMAG (interactive Multilingual AccessGateway, ou en francais Passerelle Interactive d’Acces Multilingue) est un composant logicielcollaboratif qui est responsable de la gestion du multilinguisme dans un site Web.

Le travail decrit dans ce rapport se deroule au sein du GETALP. Le Groupe d’Etude en Tra-duction/Traitement Automatique/Automatise des Langues et de la Parole a ete cree a travers lafusion des anciens GETA et GEOD en janvier 2007, dans le cadre de la creation du LIG – Labora-toire d’Informatique de Grenoble. Les travaux du groupe ont cependant commence vers 1961, avecle CETA, posterieurement GETA et finalement GETALP. B. Vauquois et C. Boitet ont decrit lesaspects pratiques et scientifiques des premieres experiences du groupe de Grenoble, les outils etressources developpes dans ses premiers vingt ans d’existence et les projets en cours a l’epoque(Vauquois et Boitet, 1985). Le groupe a donc ete pionnier dans le Traitement Automatique duLangage Naturel (TALN, ou en anglais Natural Language Processing, NLP) et, des son debut, sesthemes de recherche comprenaient la TA et la TAO (Vauquois et Boitet, 1985).

Nous expliquerons, dans les chapitres qui suivent, les problemes d’ordre theorique et pratiquequi ont motive le concept d’iMAG, ainsi que ses avantages et ses inconvenients. Ensuite, nouspresenterons les quatre principales parties de l’iMAG : la gestion des pages, leur segmentation,la traduction des segments a travers des outils de memoire de traduction et de traduction auto-matique, et finalement la reconstruction de la page cible a travers la creation d’une interface quipermet l’edition (( sans couture )) des traductions generees et l’amelioration de ces dernieres. Nousfinirons par les aspects pratiques de la mise en œuvre du prototype d’iMAG, avec un planningeffectif du travail realise, une synthese des contributions apportees par le present travail et sesperspectives a developper.

6

Chapitre 1

Problematisation de la traductiondes systemes Web

De nombreux sites Web sont disponibles en plusieurs langues. Il suffit d’acceder a la page d’ac-cueil de Google1 pour se rendre compte que l’interface est disponible (au moment de la redactionde ce raport) en 118 langues.2 Amazon3 est disponible en cinq langues, dont le japonais et lechinois, puisque l’entreprise a des parts de marche dans les pays ou ces langues sont parlees et adonc besoin de communiquer avec ses clients, surtout si ses affaires se font sur le Web.

Le site de l’Union europeenne4 est disponible en vingt-trois langues, meme si la plupart descontenus ne sont que tres partiellement traduits. L’Organisation des Nations Unies ainsi que lesinstitutions rattachees, comme l’UNESCO5, traduisent leurs sites dans les six langues officielles del’organisation. Les articles de Wikipedia sont disponibles dans un tres grand nombre de langues,bien que seules vingt-deux langues aient plus d’une centaine de millier d’articles ecrits. Ces commu-nautes, qu’elles soient concretes ou virtuelles, ont en commun le fait de rassembler des personnesqui parlent des langues differentes, ayant ainsi besoin d’integrer le multilinguisme dans leurs sites.Meme au sein d’un meme pays, par la coexistence de plusieurs langues officielles, les sites gou-vernamentaux, comme le site de l’administration federale Suisse6, doivent etre multilingues pouretre en accord avec le principe de l’egalite d’acces a l’information (le site cite est traduit en cinqlangues).

Il est de plus en plus courant de voir de petits sites personnels, des sites de PME ou d’ONG,traduits dans une deuxieme langue, generalement l’anglais qui est la langue dite (( commune ))

sur le Web. Une telle solution n’est envisageable que pour de petites institutions : une grandeentreprise ne peut risquer perdre des clients potentiels sous pretexte d’un site non disponible dansleur langue maternelle. D’un autre cote, le contenu offert par une entreprise dans un site peut etregenerateur de conflits. Prenons le cas du site de l’Union europeenne : si une page d’appel a projetstraduit mal une des procedures administratives dans une langue, alors tous les lecteurs de cettelangue auront leurs chances diminuees. Ainsi, la responsabilite de tout proprietaire de vis-a-vis dela qualite des traductions des contenus de son site est extreme. La multilinguisation des sites esttres presente et essentielle pour communiquer sur ce support.

Dans ce chapitre, nous presenterons certains aspects de la traduction des sites Web. Nous com-mencerons par l’introduction de quelques concepts qui seront utilises dans la suite pour expliqueret illustrer les techniques usuellement employees dans la traduction des sites. La presentation de

1http ://www.google.com/2En realite, ce chiffre est un peu plus petit, puisque certaines interfaces ne sont que des variantes locales d’une

langue (comme le portugais du Bresil et le portugais du Portugal). De plus, parmi les options, il existent au moinscinq langues inventees a but humoristique.

3http ://www.amazon.com/4http ://europa.eu/5http ://www.unesco.org/6http ://www.admin.ch/

7

ces techniques a pour but de mettre en evidence la situation actuelle avant d’aborder le conceptd’iMAG.

1.1 Concepts

Lorsque nous parlons de la traduction des systemes informatiques, nous avons deux conceptscles : l’internationalisation et la localisation. Ces concepts sont utilises par la plupart des outilset des methodes qui ont pour but de faciliter la traduction des logiciels.

Definition 1. Un logiciel est internationalise quand il est concu ou modifie pour qu’il puisse etrefacilement traduit sans que pour autant il soit necessaire de changer son code source. L’internatio-nalisation est perceptible comme le processus de separation des messages qui sont affiches et lapartie fonctionnelle du logiciel.

Definition 2. Un logiciel est localise quand il est traduit dans une region determinee7. La loca-lisation comprend la traduction des textes mais aussi le format des chiffres, dates et heures, toutcomme les changements qui dependent du contexte, par exemple, changer les couleurs du logicielqui pourraient etre interpretees differemment dans deux regions. Un logiciel non internationaliseest tres difficile a localiser. 8

Pour bien comprendre la difference entre internationalisation et localisation, prenons l’exempled’un logiciel fictif qui est, originalement, ecrit en anglais, et dont l’auteur souhaite l’adapter pourqu’il soit aussi disponible en francais. Pour cela, il devra faire attention a l’encodage des caracteres,vu que la langue anglaise n’a essentiellement pas d’accents, sauf pour quelques locutions d’etymo-logie etrangere. Ensuite, il devra transferer tous les messages integres dans le code source vers unfichier texte a part, avec un identifiant pour chaque message. Les messages contenant des variablesdoivent, dans la mesure du possible, remplacer ces dernieres par des textes speciaux. Par exemple,pour le message :

"Please, click on the " + aButtonName + " button"

une traduction possible serait :

"Veuillez cliquer sur le bouton " + aButtonName

Neanmoins, si les deux messages (( Please, click on the )) et (( button )) sont mis separementdans le fichier de messages, leur traduction en francais sera (( Veuillez cliquer sur le bouton )) et(( vide )), menant a croire que le mot anglais button n’a pas de traduction. Puisque l’ordre des motspeut changer, une meilleure solution est d’extraire le message original comme (( Please, click onthe $$aButtonName$$ button )) et de remplacer la chaıne de caracteres $$aButtonName$$ par lavaleur de la variable. De cette facon, les messages traduits peuvent placer la valeur de la variableconvenablement.

Toutes ces considerations appartiennent a l’etape d’internationalisation du logiciel. Il revientaussi a l’auteur de notre exemple de faire que les formats des dates, heures et chiffres soient mo-difies en fonction de la region. Des options complexes comme la direction du texte doivent etreconsiderees selon les langues dans lesquelles le logiciel sera potentiellement localise. Il est aussienvisageable dans cette etape que l’auteur founisse un moyen a l’utilisateur de pouvoir choisirla langue dans laquelle il souhaite utiliser son logiciel. Cela peut aussi se faire automatiquementcomme lorsque le logiciel reconnaıt la langue dans laquelle l’utilisateur affiche son systeme d’ex-ploitation ou son navigateur Internet.

7La notion de region est abstraite, pouvant varier selon le logiciel. Par convention, il s’agit d’une paire langue— pays.

8Pour les termes anglais internationalisation et localisation, deux abreviations sont couramment utilisees : i18net L10n. Le terme globalisation est parfois employe pour remplacer les deux definitions precedentes, signifiantl’adaptation d’un logiciel a la traduction suivie de sa localisation.

8

Une fois que toutes les parties dependantes de la region sont mises dans un fichier a part (lefichier n’est qu’un exemple, nous etudierons quelques techniques de localisation dans la partie1.2), le logiciel doit etre localise pour la langue francaise. Une personne doit alors traduire tousles messages qui ont ete extraits pendant l’internationalisation. Si la derniere est bien effectuee, lalocalisation ne doit pas toucher au code source de l’application.

1.2 Techniques de localisation

Nous presenterons dans cette partie la classification proposee par Christian Boitet et son equipepour la localisation des logiciels (Boitet et al., 2008). La premiere des deux approches consiste aeffectuer une localisation interne, en traduisant les messages qui ont ete separes du code sourcependant l’internationalisation. La seconde propose la localisation externe, ou le logiciel ne doit pasetre internationalise car il est traduit automatiquement par un composant externe. Ces deux tech-niques, seront presentees dans les deux parties qui suivent, avec leurs avantages, leurs inconvenientset des exemples. Les inconvenients de chaque technique seront a l’origine de l’introduction duconcept d’iMAG dans la partie 1.3.

1.2.1 Localisation interne

La localisation interne est la facon la plus naturelle de traduire un logiciel, mais aussi la plusonereuse. La localisation interne suppose que le logiciel est internationalise et pour ce faire plusieurstechniques et outils sont utilisables.

Le premier choix concerne la facon dont les messages sont stockes et recuperes. L’approche laplus courante est l’utilisation d’un fichier externe qui est charge au moment de l’execution selonla langue choisie, et ou chaque message a un identifiant unique utilise dans le code source pour lereferencer. Une autre approche similaire consiste a placer ces memes informations dans une basede donnees, avec des avantages lors de la traduction puisque les messages peuvent etre visualisesdans plusieurs langues simultanement. Une derniere technique possible utilise les modeles Web (del’anglais Web template).

Quand il s’agit de placer les messages dans un fichier externe, les mises en œuvre sont tresvariees. En PHP, l’internationalisation est souvent effectuee a travers un tableau qui est initialisedans un fichier a part, comme l’exemple d’un site de manifestation culturelle9 montre dans lafigure 1.1. Ce tableau associe un identifiant a un texte et a une region. La region est courammentrepresentee par une paire qui contient le code du pays et le code de la langue (par exemple fr FR oufr BE pour le francais de France et de Belgique). Les variables dans les messages utilisent la syntaxede la fonction printf. Cette technique a plusieurs inconvenients : non seulement la performanceest diminuee a cause du chargement des tableaux en memoire, mais aussi les messages sont separesde leur contexte, ce qui rend la traduction difficile. Cependant, cette technique est tres repanduea cause de sa facilite d’emploi, et plusieurs systemes de gestion de contenu, tels que Dotclear etJoomla, l’utilisent.

La classe centrale de l’internationalisation Java est le ResourceBundle, responsable de la ges-tion des fichiers de messages. Ces derniers correspondent a un fichier du type .properties conte-nant les messages sous la forme d’une suite de lignes id = message pour chaque langue danslaquelle le systeme est localise. Java fournit aussi des classes specialisees dans l’affichage des mes-sages avec des variables (MessageFormat), des dates/heures (DateFormat, SimpleDateFormat) etdes nombres (NumberFormat, DecimalFormat), tout comme pour changer la direction de l’ecriture(Bidi). Il est aussi possible de definir des messages qui varient selon la valeur d’une variable,comme pour faire le pluriel d’un mot (ChoiceFormat). La plupart des environnements integresde developpement Java fournissent des outils pour automatiser l’internationalisation des systemesoriginalement monolingues. Cette approche presente les memes inconvenients que la precedente :la decontextualisation des messages et la baisse de performance.

9http ://illustrerlhistoire.upmf-grenoble.fr/

9

Fig. 1.1 – Illustration de la technique d’internationalisation par tableau en PHP.

D’autres projets dans la communaute open source vont aussi vers une internationalisation plussimple. Le projet NLSO, par exemple, a pour but fournir des outils pour l’internationalisation dessites Web en PHP. Il utilise une base de donnees pour stocker les messages qui, ensuite, peuventetre partages par plusieurs pages, sites ou organisations. Neanmoins, ces initiatives manquent denormalisation et offrent une tres faible documentation.

Finalement, la technique des modeles Web est utilisee par des frameworks tels que Dreamwea-ver. Dans ce cas, une page est creee dynamiquement a partir d’un modele. Pour internationaliserla page, le modele est choisi selon la langue negociee avec l’utilisateur (voir definition 3). Danscette approche, la perte de performance est beaucoup moins importante. A priori, le site peutetre traduit sans que les messages ne soient prives de leurs contextes, dans un editeur HTML.En pratique, la plupart des pages sont composees de plusieurs modeles, ce qui rend difficile lareproduction exacte des conditions d’utilisation du site.

Definition 3. Le processus de Negociation de Langue a pour acteurs le serveur et le client Web. Lebut est de trouver un consensus parmi les langues dans lesquelles le serveur offre son contenu et leslangues dans lesquelles l’utilisateur accepte de recevoir le contenu. Par convention, si aucune languen’est commune aux deux, le serveur envoie le contenu dans sa langue de defaut, communementl’anglais.

Analysons maintenant un exemple de localisation interne dans le systeme de gestion de contenuJoomla. Valerie Bellynck montre, sur son site10, que l’internationalisation de ce logiciel et salocalisation est souvent incoherente. Dans la figure 1.2, trois manieres differentes d’internationaliserle code ont ete trouvees lors de l’analyse de la version francaise de Joomla11. Cela montre quememe de grands systemes ont des difficultes a adopter correctement une technique de localisationinterne.

10http ://pti.site.free.fr/wallynet/11Exemples extraits du site de Valerie Bellynck

10

(a) Message traduit directement dans le code source. (b) Technique du tableau PHP.

(c) Message non traduit.

Fig. 1.2 – Incoherence 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, quiest un type de passerelle de navigation dont la fonctionnalite est de traduire le contenu d’un site.

Definition 4. Une passerelle de navigation est un systeme Web a travers duquel un visiteur peutacceder et explorer par navigation tout un site Web.

Du point de vue du visiteur, la navigation peut sembler identique a la visite du site d’origine,sauf que c’est en realite la passerelle qui accede au site et qui renvoi chaque page demandee parle visiteur, tout en effectuant des calculs et des remplacements sur son contenu. Une passerellede navigation prend generalement la forme d’un site Web (mais peut etre aussi, par exemple, unservice Web). Une simple redirection peut donner l’illusion de constituer une passerelle, mais ladifference est double : non seulement, une fois la redirection effectuee, l’URL retournee est celle dusite d’origine, mais aussi aucun traitement n’est fait ni ne peut etre fait sur le contenu des pagesredirigees.

Les principaux problemes de la localisation resident dans la traduction, puisque la dissociationde la structure et du contenu oblige a traduire les messages sans acces au contexte dans lequel ilssont affiches. Pour essayer de resoudre ce probleme, nous analyserons brievement les passerellesde traduction automatique : des passerelles de navigation generalement attaches a un service detraduction automatique de textes en ligne. Nous montrerons ici deux sytemes de traduction desites : celui de Systran et celui de Google.

Le systeme de Systran est tres simple : apres avoir fourni une URL, l’utilisateur peut naviguerdans le site traduit. Le traducteur de Systran reussit a traduire la plupart des elements de lapage, y compris les formulaires et champs de recherche. Les donnees transitent par la passerelle etle resultat de l’envoi d’un formulaire s’affiche toujours traduit. Aucune interaction avancee n’estpossible : l’utilisateur doit se contenter de la traduction de basse qualite fournie par le systeme deTA.

Google permet aussi la traduction automatique d’un site dont l’utilisateur fournit l’URL. Soninterface permet d’afficher les messages de la page originale en survolant leurs traductions avecle curseur. Neanmoins, seul les elements simples en HTML sont traduits. Les formulaires, parexemple, une fois envoyes, retournent a l’utilisateur la page originale. Meme des champs simplescomme la recherche par mots-cles n’est pas fonctionelle, car le site du LIG en francais est renvoyeelors d’une recherche sur l’annuaire traduit en portugais (fig. 1.3).

Google permet aussi aux utilisateurs de suggerer une meilleure traduction. Une fois soumise,la suggestion n’est pas prise en compte lors des futures traductions du meme message dans le site.L’utilisateur ne peut pas voir le resultat de sa contribution et recevra toujours la traduction genereepar TA, de plus basse qualite que la sienne. Google justifie son approche en pretendant 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 ameliorer la performance de leur traducteur statistique, ce quine resoud toujours pas le probleme de ne pas donner plus de credibilite a une traduction realiseepar un humain qu’a une traduction automatique. Cette credibilite est neanmoins soumise a unedetection de SPAM et a l’evaluation de la qualite de la traduction proposee.

De cette analyse, nous pouvons deduire que les passerelles de TA peuvent aider a comprendrede facon globale le contenu d’un site, en etant une solution de tres bas cout et simple a mettre enœuvre a travers un lien vers le service de traduction. Elles ne peuvent pourtant pas etre utiliseespour fournir l’acces multilingue au site Web d’une entreprise ou d’une organisation, car la qualitede la traduction n’est pas compatible avec les attentes des utilisateurs.

1.3 Une solution possible : iMAG

Le panorama developpe jusqu’a present illustre les limitations de la traduction des sites Web :si d’un cote les techniques d’internationalisation interne posent des problemes lors de la traductionhors-contexte, car elles ont pour principe la separation entre contenu et forme, d’autre part lessolutions automatiques sont incompatibles avec les besoins des developpeurs des sites Web.

Le concept d’iMAG – interactive Multilingual Access Gateway, ou Passerelle Interactived’Acces Multilingue – a ete propose par Christian Boitet (Boitet et al., 2008), et propose unesolution pour ce probleme. iMAG est un service responsable de la gestion de l’acces multilingue aun site Web, que nous nommerons dorenavant le site Web elu. Le site elu, pour des raisons commecelles enoncees dans le chapitre d’introduction, souhaite ou a besoin d’offrir l’acces multilinguea ses utilisateurs. Lorsque l’utilisateur demande a voir une page du site dans une langue pourlaquelle il n’existe pas de traduction interne disponible, il indique a la passerelle qu’il souhaiteacceder au site elu dans cette langue. L’iMAG va alors chercher une traduction pour chaque seg-ment de la page. Cela sous-entend que chaque segment de la page a plusieurs traductions possiblesavec des niveaux de qualite correles a la source de traduction, et que la passerelle choisit toujoursla meilleure traduction disponible. Ensuite, l’utilisateur dans un contexte de lecture de la pagetraduite pourra proposer des traductions ameliorees, et ces traductions seront prises en compte laprochaine fois ou la page sera traduite, lors du choix de la meilleure traduction disponible.

Les inconvenients d’une iMAG par rapport aux techniques classiques d’internationalisationressemblent a ceux des sites wiki : la validite des informations fournies par les volontaires, le sabo-tage, le consensus entre deux traductions d’une meme source (i.e. des utilisateurs qui fournissentdeux traductions differentes pour un meme segment). De plus, il existe une perte de performancepar l’ajout d’une couche intermediaire entre le serveur Web et le client qui veut voir une page dansson navigateur. Neanmoins, le compromis est interessant puisque l’iMAG fournit une traductionde bas cout et de qualite croissante et maıtrisable par le proprietaire du site.

Cela veut dire que, meme si, initialement, la traduction de la page n’est pas meilleure quecelle generee par un outil de TA, la qualite des traductions tend a augmenter au fur et a mesureque la page est utilisee. En complement de l’interface de localisation en contexte, la passerelle detraduction est completee par une interface specialisee sur la traduction collaborative. Ainsi, destraducteurs professionnels disposent d’une interface de traduction avancee, ou les outils necessairestels que les diverses propositions de segmentation et traduction et un dictionnaire du domaineseront mis a disposition. Ainsi, a travers une philosophie collaborative similaire a celle qui a faitla reussite des pages en style wiki, le site sera traduit a bas cout, a l’aide de volontaires, pouvantaussi etre traduit par un traducteur professionnel tout en evitant le probleme de la traductionhors-contexte. Quand un niveau de qualite juge suffisant par les developpeurs du site elu seraatteint sur tout ou partie des segements, les traductions de ces elements pourront etre integrees ouil le faut dans le sit elu (en principe, dans les tableaux de messages ou dans les bases de donneesprevues pour les elements textuels localisables), supprimant ainsi la perte de performance imposeepar l’iMAG.

Mohammad Daoud a cree un premier prototype d’iMAG (Daoud, 2007). Ce dernier n’etantpas facile a adapter ou developper et n’etant pas relie aux ressources linguistiques d’une inter-face de traduction collaborative, nous avons decide de le reprogrammer de maniere modulaire

13

et en utilisant des techniques sophistiquees disponibles dans un langage a objets comme Java.Le developpement du prototype peut etre decompose en quatre parties. Il doit, dans un premiertemps, telecharger la page source et traiter le code HTML afin de le preparer pour la segmen-tation. Nous alons ensuite separer les segments a traduire du squelette de la page, puis chaquesegment sera traduit de la facon suivante : la meilleure traduction sera cherchee dans la memoirede 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 souhaitees, une traduction mot-a-mot seraemployee. La derniere etape concerne la reintegration des segments traduits dans la page origi-nale et l’ajout du code source qui permettra la post-edition. Ces quatre etapes correspondent auxquatre chapitres suivants de ce rapport.

14

Chapitre 2

Les defis du Web

Le World Wide Web est un milieu de diffusion democratique. Cette liberte donne a son contenuune nature heterogene, meme si la plupart des informations sont diffusees a travers des documentsHTML. Neanmoins, ces derniers ont aussi une nature tres diverse, d’une part a cause d’une syn-taxe tres permissive et d’autre part a cause d’un manque de standards et du besoin de retro-compatibilite des navigateurs (Zeldman, 2003).

La premiere question qui s’impose a nous en commencant a developper un prototype pourl’iMAG est la suivante : dans cet univers heterogene, quel est l’objet de base sur lequel travaille lapasserelle ? La reponse la plus evidente serait de dire que le prototype travaille sur un site Web, lesite elu. Cependant, les limites de la definition d’un site Web sont diffuses, et la granularite n’estpeut-etre pas adequate. Une deuxieme reponse possible est de dire que l’iMAG travaille sur unensemble de pages Web, chaqune etant definie a l’aide d’un document HTML1 et de documentssatellites. Dans cette partie, nous definirons la notion de site et de page Web, pour expliquer ensuitecomment notre prototype traite chacun des objets. Pour terminer, nous montrerons l’importancede rajouter un relai de traduction entre le client et l’iMAG, afin de mieux gerer la separation detaches et permettre des interactions avancees entre les divers types d’utilisateurs et la passerelle.

2.1 Qu’est-ce qu’un site Web ?

L’acces a un site se fait generalement a travers un lien contenant une URL (Unified ResourceLocator), qui peut aussi etre directement entree a travers la barre d’adresse du navigateur. CetteURL est formee par plusieurs parties, et contient le nom de domaine du site. Ce nom est enregistreaupres d’une entite responsable de diffuser aux serveurs de noms de domaine (DNS, Domain NameServer). Un site Web peut alors etre defini par l’ensemble des pages Web qui sont disponibles atravers un domaine. Analysons un exemple sur le site du LIG :

– URL : http://www.liglab.fr/– Nom de domaine : liglab.fr– Pages qui appartiennent a 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 definition n’est pas suffisante pour le site pris comme exemple, car le site du LIG contientdes sous-sites concernant chacune des equipes de recherche qui composent le laboratoire. L’URLdu site du GETALP, par exemple, est http://getalp.imag.fr/, et le nom de domaine dans cecas n’est pas liglab.fr, meme si le site du GETALP appartient au site du LIG, et si, lors de

1Le document peut etre aussi statique aussi bien que dynamiquement genere par le serveur

15

Fig. 2.1 – Fragment du fichier de definition du site Web elu.

la traduction du site du LIG, l’utilisateur envisage aussi avoir un acces multilingue au site duGETALP.

Nous pouvons donc definir, de facon plus abstraite, qu’un site Web est un objet informatiquequi represente une entite du monde reel et que cet objet est compose d’un ensemble de pages(statiques ou dynamyquement generees par le serveur) correspondant aux parties de cette entite.Les pages Web d’un site partagent, donc, ce rapport d’appartenance dans le monde reel a l’entiterepresentee par ce site. Plusieurs fois, ce rapport est directement projete sur le nom de domainequi forme l’URL de ces pages, de telle facon que toutes les pages qui forment le site partagent lememe nom de domaine. Cette tendance n’est pas respectee dans les cas ou le site est tres vaste oude nature tres variee, comme le cas du LIG, qui a ete forme par l’union de plusieurs equipes derecherche affiliees precedemment a des institutions diverses. Le meme probleme s’impose lorsquenous travaillons avec un navigateur dedie a un site qui simule une application locale.2

Le prototype iMAG utilise la notion abstraite de site pour definir les limites de navigationtraduite. En pratique, un fichier en format XML de syntaxe simple et directe, parametrable par lapersonne qui va deployer le systeme sur un site, definit quels sont les URLs qui feront partie d’unsite. Dans la figure 2.1, nous voyons un fragment de ce fichier sites.xml avec quelques pages quiappartiennent au site du LIG. Cette description suppose qu’une page avec un chemin de contexte(tout ce qui vient apres le slash (( / ))) qui contient l’URL decrite dans sites.xml est aussi une pageappartenant au site. De cette facon, l’entree http://getalp.imag.fr/ decrit aussi les pages :

– http://getalp.imag.fr/Seminaires/– http://getalp.imag.fr/Seminaires/programme.HTML– . . . et ainsi de suite.Quand l’utilisateur demande a l’iMAG 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 surun lien interne de la page. Nous appellerons cette operation la navigation traduite transparente.Pour mettre cette navigation en œuvre, le prototype remplace systematiquement les liens de lapage traduite par des liens vers lui-meme, avec le lien original en parametre. La definition du siteWeb elu a travers le fichier sites.xml a des consequences lors de la navigation traduite. Celasignifie que l’iMAG transformera tous les liens de la page source en liens vers la passerelle, demaniere que les prochains appels a la visualisation d’une page du site elu retournent une page

2Par exemple, le navigateur Fluid, http ://fluidapp.com/

16

traduite. Cependant, les liens externes ne seront pas rediriges vers l’iMAG, puisqu’une page quin’appartient pas au site elu ne doit pas etre traduite par cette passerelle.

A travers un fichier parametrable contenant une liste d’URL, le prototype met en œuvre unconcept abstrait ou la definition d’un site Web est liee a l’entite qu’il represente. Cette approchepermet une instantiation facile de l’iMAG sur un site Web elu tout en etant suffisamment souplepour permettre a l’utilisateur une navigation traduite transparente. De plus, ce meme fichier ouun fichier identique peut etre utilise pour le parametrage du relai de traduction, dont nous parlosdans la partie 2.3.

2.2 Qu’est-ce qu’une page Web ?

Quand l’iMAG recoit une adresse URL, elle ouvre un flot de donnees pour telecharger cette pagedans sa memoire. Elle considere les eventuels redirections faites, soit a travers l’en-tete Location,soit a travers la balise meta dans le document. Une fois que l’adresse correcte de la page estrecuperee, la page est chargee dans la memoire de la passerelle sous la forme d’un documentHTML. Si la page est formee de plusieurs cadres (frames), les pages contenues dans ces cadressont traitees une a une, comme des pages independantes.

De la creation du Web a son utilisation massive dans nos jours, l’evolution a ete tres rapide.Au debut, une page Web etait un simple document HTML, unmorceau de texte avec des balisesdecrivant le format d’affichage. Tres vite, des elements multimedia ont ete rajoutes a ces docu-ments : des images, des videos, des animations, etc. Ensuite, le besoin de separer le contenu dela forme a amene a la creation des feuilles de style (CSS, Cascading Style Sheets), qui ont eterajoutees aux documents. Le besoin de rajouter de la fonctionnalite a ces pages est a l’origine dela creation de ECMAScript, aussi connu par sa variante la plus populaire, le JavaScript. Aujour-d’hui, un document HTML decrit toujours le contenu d’une page Web, mais il a autour de lui desdocuments satellites pour decrire sa forme, son comportement et ses aspects multimedia. Quandnous parlons donc de la traduction d’une page Web, nous ne nous interessons qu’a son contenu. Cetravail n’a pas pour but la traduction des elements satellites appartenant a une page Web. En par-ticulier, la passerelle ne traduit pas les elements textuels contenus dans une animation (( Flash )),meme 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 elements satellites, la balise base estajoutee a l’en-tete du document. De cette facon, tous les adresses relatives des elements satellitessont cherchees en utilisant l’adresse originale de la page comme base, au lieu de l’adresse de lapasserelle. 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 rajoutee a l’element head de la page source (aucune modification n’est necessaire si la

balise est deja presente dans la page original). Ainsi, les images, videos, feuilles de style et scriptspourront etre localises et la page traduite generee par l’iMAG sera affichee par le navigateur avecla meme forme et le meme comportement que la page originale.

La syntaxe d’HTML a ete, au debut, tres permissive. Dans le but d’economiser de la bandepassante, les concepteurs d’HTML ont rendu certains elements optionnels, comme par exemple labalise de fermeture de paragraphe (</p>). Un document HTML n’est donc pas necessairement bienforme (well formed). Les problemes d’ambiguıte de ce type de marquage ont ammene a la creationde la norme XHTML, basee sur XML, ou une page Web doit etre bien formee et valide, selon lesdescripteurs (DTD, Document Type Descriptor) disponibles. Meme si la tendance aujourd’hui estla creation de pages selon cette derniere norme, l’iMAG doit aussi traiter les pages qui utilisent lesvieux marquages. Par consequent, l’analyseur de documents doit permettre une certaine souplesse.

Une mesure tres simple a ete deployee pour permettre aux developpeurs du site d’indiquerdes parties qui ne doivent pas etre traduites par l’iMAG, tel les citations en langue originale, desbouts de code source, etc. Danc ce cas, le developpeur devra mettre ce contenu dans une boıte

3Par exemple http ://www.deezer.com/

17

Fig. 2.2 – Relai de traduction utilise pour iMAG.

(div) ou dans un segment (span) avec la classe noTranslate. Le prototype ignorera tout le contenude cette boıte, qui sera affiche precisement dans la langue d’origine.

Parmi les analyseurs HTML disponibles, deux approches sont possibles : les approches baseessur DOM (Document Object Model), ou le document est converti en un arbre d’objets qui pourra,alors, etre traite par un langage de programmation a objets ; et les approches basees sur SAX, oule document est lu de facon sequentielle, et des evenements seont declaenches lorsque les balisesseront lues. Dans un premiers temps, par la facilite de programmation, nous avons choisi l’approcheDOM a partir de l’analyseur fourni par la bibliotheque du projet HTTPUnit4. L’approche DOMetant trop stricte pour traiter des documents HTML, nous avons ensuite change d’approche etopte pour un analyseur SAX, disponible dans la bibliotheque CyberNeko HTML Parser5. Cettebilbiotheque corrige des erreurs frequentes et est indulgente avec les balises omises des documentsHTML.

L’analyseur HTML est responsable de l’extraction de segments a un premier niveau. Parexemple, il recupere le texte d’un paragraphe en traitant des eventuels elements de formatage(Voir partie 3.3). Il y a des elements dont la traduction peut etre difficile : les textes d’aide sousla forme d’attribut title, doivent etre recuperes, ainsi que les textes des boutons, sous la formed’attribut value. Pour les boutons, certaines actions dans le serveur peuvent dependre de cetexte, de telle facon que le traitement du formulaire doit remettre la valeur originale avant derenvoyer l’information au serveur de la page. Les valeurs dans les boıtes a choix multiple sontaussi problematiques, puisque leur valeur est souvent definie par le texte qu’elles affichent. Fina-lement, les champs de texte dans les formulaires seront remplis par les utilisateurs dans la languecible, et le serveur de la page originale n’est peut-etre pas prepare pour traiter l’encodage ou lasemantique de cette langue. Ce probleme etant complexe, nous avons decide de ne pas le traiterdans ce prototype, meme si nous sommes conscients de son importance pour la navigation traduitetransparente.

Le phenomene appele Web 2.0, produit recemment, change petit a petit la nature des pagesWeb, qui se rapprochent de plus en plus des applications traditionnelles. Ces nouvelles pages sontpresque completement dynamiques, et le chargement des elements est fait de facon condition-nelle a travers des appels JavaScript, au fur et a mesure qu’ils sont requis, selon les principesde la technique AJAX (Zakas et al., 2007). Dans ce travail, nous ne traitons pas les pages de ce

4http ://httpunit.sourceforge.net/5http ://nekoHTML.sourceforge.net/

18

type, car le probleme n’est pas interessant du point de vue theorique, mais tres vaste du cote del’implementation. En particulier, nous retrouvons le meme probleme que pour les elements et pourles valeurs des formulaires mais en plus pour beaucoup d’autres elements. Une idee de palliationtemporaire est de s’appuyer a nouveau sur l’utilisation de la classe noTranslate, laissee a l’usagedu developpeur du site.

Le comportement du developpeur du site Web elu est aussi important pour la reussite del’implementation de l’iMAG. Nous attendons des developpeurs de l’application de bonnes habi-tudes de programmation menant a la production de pages Web assez (( propres )), par exemple,en ce qui concerne l’adoption de normes comme XHTML et la separation entre forme et contenu.Les developpeurs doivent aussi etre conscients des limitations de la passerelle, evitant ainsi demettre des informations textuelles qui doivent etre traduites sous forme d’image, d’animationou de script dynamique. Si la page est entierement developpee sous forme d’animation Flash(format proprietaire, par ailleurs), le prototype ne sera pas capable de la traduire. Le role desdeveloppeurs est donc aussi de faire leur partie, a travers l’adoption d’une programmation (( politi-quement correcte )), pour que l’iMAG puisse fournir correctement l’acces multilingue au site Webqu’ils developpent.

2.3 Le relai de traduction

Le relai de traduction est un composant logiciel localise entre le client et l’iMAG. Il est res-ponsable pour renvoyer les requetes des utilisateurs vers la passerelle de traduction. Dans le casd’une seule passerelle de traduction pour un site elu, il n’est pas une couche essentielle dans leprocessus de traduction du site. Neanmoins, lorsque nous parlons de la gestion de plusieurs sitesWeb traduits par plusieurs instances d’iMAG, il est important de separer la tache de traductiondes pages, concernant l’iMAG, de la gestion et du routage des requetes des utilisateurs vers lespasserelles. Ainsi un site Web elu n’a qu’a proposer des liens vers le relai, qui, le reconnaissant,lui associera les parametres dedies et reliera la requete vers la passerelle iMAG.

Une deuxieme motivation pour l’existence du relai de traduction est l’existence des domainesde traduction. Un domaine de traduction est une memoire qui contient des traductions de segmentsselon un domaine specifique. Un exemple est la traduction du segment anglais Home, tres frequentdans les pages. Pour un domaine generique, il sera normalement traduit comme Page d’accueil. Unsite du domaine immobilier pourra, neanmoins, souhaiter que ce segment soit traduit litteralement,Maison. Par consequent, iMAG offre la possibilite de traduire une page de facon specifique, selonle domaine indique par l’utilisateur. Le relai de traduction est responsable de l’affectation desdomaines aux sites, de facon que l’utilisateur n’ait pas besoin d’expliciter ce parametre.

Dans la figure 2.2, nous pouvons voir l’interface du relai, developpe par Valerie Bellynck6 quia ete reutilise dans notre iMAG (le relai original utilisait le service de traduction de Google).Dans la figure, les informations entrees generent une requete vers la passerelle avec les parametrescorrectement instancies. . L’etat actuel du relai est minimal et beaucoup des informations afficheesdans la page ne sont utiles qu’au developpement. Un travail futur et interessant serait la creationd’une interface avancee de gestion de domaines, sites elus et instances iMAG pour l’administrationdu multilinguisme des sites qui utilisent le systeme.

6http ://pti.site.free.fr/wallynet/

19

Chapitre 3

Segmentation

Les informations extraites par l’analyseur HTML, decrites dans la session 2.2 ne sont pasencore aptes a etre directement traduites. Une segmentation non seulement structurale mais aussilinguistique est necessaire afin de produire une traduction consistante et qui facilite la post-edition.Meme si la plupart des travaux, considerant ce probleme sans interet, negligent l’importance decette etape, le type de segmentation choisi sera decisif pour la qualite du resultat, selon les exemplesillustratifs presentes par Walker et al. (2001). Dans les prochaines parties, nous discuterons lesaspects qui ont ete etudies lors de la mise en œuvre de la segmentation dans le prototype iMAGet les choix effectues par rapport aux problemes existants.

3.1 Taille de segment

La question centrale de cette partie peut etre enoncee de la facon suivante : quelle est la taillede segment ideale utilisee dans la memoire de traduction et dans les systemes de TA, de facon amaximiser la qualite de la traduction obtenue ?

Evidemment, ce n’est pas une bonne idee d’utiliser les mots comme segments, ignorant ainsi lesconstructions grammaticales et les expressions multi-mots, car la plupart des langues presententdans 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 ideenon plus, car la probabilite qu’un segment de la taille d’un paragraphe soit present dans deuxpages distinctes est faible. Nous eviterons donc ces solutions extremes et chercher une solutionintermediaire qui puisse a la fois etre suffisamment grande pour que la traduction prenne encompte la polysemie et les idiosyncrasies de la langue et a la fois suffisamment petite pour quel’utilisation d’une memoire de traduction se justifie par la repetition des segments a travers lespages.

La tache de segmenter un texte est plus ou moins difficile selon la langue. Pour les nomscomposes en allemand, par exemple, il est difficile de trouver les limites des mots car la grammaireallemande les juxtapose (par exemple Selbstbedienungtankstelle =⇒ Selbst + bedienung + tank+ stelle) (Goldsmith, 1998). Certaines langues orientales comme le thaı ne possedent pas de signede segmentation, c’est-a-dire qu’il n’existe pas d’espace entre les mots ni de signe de ponctuationentre les phrases. Dans ce travail, nous ne considerons que les langues pour lesquelles il existe dessymboles qui indiquent les limites des phrases.

Nous avons decide, dans le prototype, d’employer la segmentation par phrases, pour les raisonsdetaillees dans les parties suivantes. Cette approche, apparemment tres simple, est assez adequateau probleme, meme si quelques constructions peuvent poser des problemes pour la detection au-tomatique des limites des phrases dans le texte brut.

20

Fig. 3.1 – Exemples de cas problematiques a segmenter : equations et listes.

3.2 Cas problematiques

Meme si l’approche choisie est directe et simple, certains types de constructions linguistiquesposent des problemes lors de la segmentation. Considerons le fragment presente dans la figure3.1, extrait de Wikipedia en francais1. Dans ce cas, le texte possede une equation qui le coupe endeux. Cette equation est inseree dans la page sous la forme d’une image et ne peut donc pas etretraitee en tant que texte. Neanmoins, ignorer son existence entraıne l’extraction d’une phrase oule manque d’une partie peut provoquer une mauvaise traduction. Idealement, l’equation devraitetre remplacee par un substitut, par exemple, par des constituants non textuels qui sont desoccurrences speciales comme $$_exp_23 (pour

∫ +∞0

2xe−x) ou $$_rel_37 (pour a < b) avec desproprietes linguistiques facilement analysables par un analyseur morphosyntaxique.

Le cas des listes est aussi difficile a segmenter. Quand la liste est, comme dans la figure 3.1, unesequence de phrases, il n’y a pas de probleme si nous considerons que chaque ligne correspond aune phrase. Si la liste est une sequence de complements a une phrase, comme par exemple dans lechapitre d’introductionde ce document, la solution ideale serait de rajouter de la redondance a laliste en repetant la phrase initiale avant chaque element. Neanmoins, une solution simple pour leprbleme serait de trouver les bornes des phrases et ensuite remplacer les puces et symboles speciauxpar des occurrences speciales dynamiques du type $$<a_24. . . </a> , puis les traiter comme unmot compose.

Nous pouvons imaginer une gamme de constructions ou les algorithmes de segmentationpeuvent trouver des problemes, comme des dialogues, de la poesie, des citations imbriquees dansle texte, etc. Vu que les algorithmes d’etat de l’art ne reussissent pas a traiter correctement unepartie de ces problemes, nous avons decide de permettre a l’utilisateur de choisir une segmenta-tion differente de celle proposee. Cette segmentation est prioritaire par rapport a la segmentationautomatique, est sera prise en compte lorsque l’algorithme de detection de phrases sera appliquesur le partie restante du texte. Cette fonctionnalite est sans doute une suggestion qui devrait etredeveloppee 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 surle Web. La definition de cette structure comprend, par exemple, la presentation des informationset leur disposition sur l’ecran, c’est-a-dire la facon dont chaque element (textuel, multimedia) seraaffiche dans le navigateur du client. Elle comprend aussi la presentation du texte et par consequent

1http ://fr.wikipedia.org/wiki/Information mutuelle

21

son format. L’utilisation des feuilles de style CSS est une pratique recommandee dans ces cas, carelle ameliore la lisibilite et la maintenabilite du document. Cependant, meme s’ils sont utilisespour les parametres globaux, certains marquages demeurent dans le texte, tels que les partiesmises en relief par des caracteres gras ou en police italique. Pour differencier ces balises de cellesqui concernent la presentation generale de la page, nous avons recupere depuis la specificationofficielle d’HTML (w3c, 1999) une liste de trente-six balises de presentation de texte accepteesdans les segments. Cette approche empirique s’est montree adequate pour les pages sur lesquellesle prototype a ete teste. L’hypothese evoquee dans la partie 2.2 sur le role des developpeurs esttoujours valable, puisque la qualite de la segmentation sera proportionelle a la proprete et a laclarte du code source.

La possibilite de supprimer les balises de formatage du segment a ete consideree mais abandoneepour deux raisons principales : la premiere concerne les systemes de TA, qui sont assez robustespour pouvoir travailler avec ces balises et generer une traduction coherente. La deuxieme raisonpour laquelle nous n’avons pas enleve ces balises est que leur reintegration dans le segment traduitest une tache qui n’est pas triviale a resoudre, d’autant plus que nous n’avons pas acces aux valeursintermediaires generees par les systemes de TA. Une solution consideree propose la constructiond’un treillis pour recuperer les traductions intermediaires, puis le rajout des balises dans les nœudsde ce treillis, selon la figure 3.2. Nous pouvons voir que les traductions des sous-phrases ne sontpas toujours coherentes et que l’aplatissement du treillis pour la generation d’une phrase avec lesbalises est une tache dont la complexite est etonnamment elevee. De plus, la performance de cettemethode est inversement proportionnelle a la taille du segment a raison non-polinomiale et doncpotentiellement catastrophique.

Nous avons donc choisi d’extraire du document les phrases avec les balises de format et de lesrentrer directement dans un detecteur de phrases. Cette etape cree aussi un squelette de la pagesource, ou chaque segment extrait est remplace par un marqueur (par exemple $$35$$) qui serta l’identifier de facon unique. Cela est important pour la reconstruction de la page cible, commedecrit dans le chapitre 5. Analysons maintenant quelles sont les options disponibles pour cettesegmentation, afin de choisir une methode ou un outil adequat.

Fig. 3.2 – Solution pour la reintegration des balises, abandonnee pour manque de performance ethaute complexite.

22

3.4 Methodes et outils

Les systemes de TA recents utilisent couramment deux tailles de segment : la phrase ou leconstituent (chunk). Une phrase, dans une langue indo-europeenne, est generalement identifieea travers des signes de ponctuation. Ces signes peuvent etre ambigus avec d’autres types designalisation, par exemple, le point final en francais peut aussi etre utilise pour les abreviations,comme dans M. pour Monsieur, ou dans les adresses Web, comme dans www.liglab.fr. Nous nousconcentrerons sur cette taille de segment, car la segmentation par constituants rend la performancedu systeme dependante de la performance d’un analyseur syntaxique de surface (shallow parser).De plus, la segmentation par phrases est avantageuse quand les documents a traduire ont tendancea etre repetitifs, comme le cas des pages Web d’un site qui partagent des parties comme les menus,les en-tetes, etc. Cette decision entraıne la definition de segment dans iMAG :

Definition 5. Un segment est un fragment d’information semantiquement coherent, frequementdelimite par un signe de ponctuation, acompagne des balises de format. La definition de segmentutilisee dans iMAG est, dans la plupart des cas, synonyme de la definition linguistique d’unephraseou a defaut d’un titre.

Les algorithmes de detection de phrases sont souvent bases sur des heuristiques pour l’identi-fication des signes de ponctuation (par exemple un point final suivi d’un ou plusieurs blancs outabulations suivi d’une lettre majuscule) et sur des listes non exhaustives d’exceptions, comme leslistes d’abreviations et les regles concernant les majuscules (Grefenstette et Tapanainen, 1994).Pour cela, les regles sont codees en dur par des d’expressions regulieres qui decrivent les limites desphrases et les exceptions. Cette approche a ete utilisee dans de nombreux projets, par exemple leprojet UNLDeco, developpe au GETALP (Serasset et Boitet, 2000). Les regles peuvent aussi etreseparees de la partie fonctionnelle et etre decrites dans un formalisme equivalent aux expressionsregulieres dans un fichier a part.

Les outils a l’etat de l’art considerent la detection de phrases comme un probleme de classifi-cation, utilisant la methode de l’entropie maximale pour classifier les separateurs potentiels. Lesattributs utilises dans cette tache peuvent etre de haut niveau (les categories grammaticales, ouPOS, de l’anglais Part Of Speech), ou bien la classification peut utiliser seulement des attributsmorphologiques tels que la longueur de la phrase, la casse des mots voisins, etc. Les evaluationsrealisees par Walker et al. (2001) montrent que, sur un corpus de domaine general, la dernieretechnique est celle qui presente la meilleure performance.

Pour l’iMAG, nous avons choisi d’utiliser une bibliotheque, LingPipe, qui met en œuvre unalgorithme de detection de phrases a l’etat de l’art. Les experiences sur le corpus GENIA (Ohtaet al., 2002), une collection de resumes du domaine biomedical, ont montre que cet algorithmeatteint une performance de plus de 99,7% de precision, avec une f-mesure d’environ 99,6%2.L’approche choisie reunit donc tous les segments extraits de la page dans un seul bloc de texte,qui est ensuite segmente par le module de detection de phrases de LingPipe. Les phrases serontensuite traduites et reintegrees dans le document, comme nous l’expliquerons dans les prochainschapitres.

2http ://alias-i.com/lingpipe/demos/tutorial/sentences/read-me.HTML

23

Chapitre 4

Traduction : memoires et systemes

Nous decrirons dans cette partie deux types de systemes de TALN dont le rapport, dans un pre-mier temps, ne sera peut-etre pas explicite, mais qui sont associes dans une iMAG. Premierement,nous introduirons les Memoires de Traduction (MT1, car nous utiliserons ce mecanisme pour sto-cker et recuperer les traductions d’un site. Ensuite, nous presenterons une tres breve analyse desoutils que nous utilisons pour effectuer la Traduction Automatique des segments.

Tout d’abord, recapitulons ce que nous avons jusqu’a present : nous avons defini nos objetsde travail, c’est-a-dire le site et la page Web, puis nous avons discute du traitement des elementsde la page et de la segmentation des documents HTML. Nous avons donc, comme entree pour laprochaine etape, un ensemble de segments en langue source et un squelette du document, contenantsa structure originale, ou les segments ont ete remplaces par des identifiants.

Une question qui, jusqu’ici, a ete negligee est la detection de la langue source. L’utilisateura la possibilite d’indiquer la langue source dans laquelle le site a ete developpe. Une page peutdecrire la langue du document a travers l’en-tete HTTP Language ou a travers les balises metaou encore les attributs lang et xml-lang. Neanmoins, il est necessaire de prevoir le cas ou cesinformations soient incompatibles entre elles et avec les langues dans lesquelles le document a eteecrit. Par consequent, il serait ideal de mettre en place un algorithme de detection automatiquede la langue source, applique a chaque segment, qui utilise des informations comme les indicationsdans les en-tetes et balises de la page, ainsi que la langue des autres segments et, evidemment, lescaracteristiques morphologiques et lexiques du segment.

La suite LingPipe offre un module pour l’identification de langue, qui utilise un algorithmed’apprentissage et considere le probleme comme une tache de classification. Comme il s’agit d’unesolution tres souple, nous avons envisage son utilisation. Neanmoins, entraıner le modele est unprocessus qui consomme beaucoup de temps et qui n’est pas dans le contexte de ce stage. Dansl’etat actuel, le prototype n’incorpore donc pas la detection automatique de la langue, memesi du point de vue theorique ce probleme a ete aborde. Il serait important de considerer cettefonctionnalite dans l’avenir du projet.

Pour etudier les MT et systemes de TA dans les prochaines parties, nous considererons qu’ilsrecoivent en entree une suite de segments, chaque segment ayant une langue source associee, etune langue cible unique pour tous les segments etant definie par l’utilisateur.

4.1 Memoires de traduction

Definition 6. Un systeme de Memoire de Traductions (MT) est une base de donnees qui stockedes segments de texte avec leurs traductions respectives. Nous appelons ces entrees bi-segments,meme si elles peuvent contenir la traduction du segment source dans plus d’une langue.

1A ne pas confondre avec l’abreviation anglaise MT pour Machine Translation). Dans ce travail, nous utilisonsles termes en francais Traduction Automatique et Memoire de Traduction et donc les abbreviations TA et MT.

24

Les systemes de MT sont tres populaires parmi les traducteurs professionnels qui, avec uneinterface adequate, peuvent utiliser les traductions effectuees dans le passe pour traduire de faconplus performante les nouveaux documents. La reussite de ces systemes est conditionnee a larepetitivite des documents, mais aussi a l’algorithme de correspondance utilise.

La correspondance exacte atteint une tres haute precision, puisque les traductions recupereesn’ont besoin que de corrections minimes pour etre reutilisees. Le rappel de cette correspondanceest, cependant, tres faible, puisque la repetition est tres rare. Plusieurs systemes de correspondanceapprochee (fuzzy match) ont ete proposes, bases par exemple sur une simple distance d’editionde caracteres ou de mots (Levenshtein, 1966). La distance d’edition etant une simplification tropgrossiere de la distance effective entre deux segments dans une memoire de traduction, des so-lutions plus sophistiquees ont ete creees. E. Planas utilise une combination d’informations mor-phologiques, lexicales, syntaxiques et semantiques pour calculer plusieurs niveaux de similariteentre les segments (Planas et Furuse, 2003). La distance entre les segments est alors une fonc-tion de leur distance d’edition sur plusieurs niveaux d’abstraction. Bicici et Dymetman (2008)adaptent l’algorithme present dans le logiciel commercial TRADOS, en calculant la plus grandesous-chaıne commune (Longest Common Subsequence) entre les segments (sans considerer l’ordredes mots) puis en alignant les mots des segments pour trouver les parties en commun et les partiesdivergentes.

Le systeme de MT utilise par notre prototype a ete developpe en interne par le GETALP.SECTra w n’est pas seulement un systeme de MT, mais un systeme complet de gestion de corpusparalleles pour l’aide a la traduction. Il possede des fonctionnalites de traduction, post-edition,visualisation, importation, exportation et evaluation des traductions (Huynh et al., 2008), inspirepar BEYTrans (Bey et al., 2006). Nous utiliserons uniquement la fonctionnalite de stockage et derecuperation des segments, considerant le site Web a traduire comme un corpus bilingue.

SECTra w a ete developpe sous forme de systeme Web, et l’interaction entre une iMAG etsa memoire de traduction se fait a travers une requete HTTP. Il existe deux types de requete,la demande de traduction et la mise a jour d’un segment, resultat d’une post-edition ou de latraduction d’un segment qui n’est pas present dans la MT. Les interfaces de ces deux types derequetes sont :

Demande de traduction :Entree : – Segment source

– Langue source– Langue cible– Corpus/domaine

Sortie : – Identifiant du segement source– Liste de traductions disponibles

Demande de mise a jour :Entree : – Identifiant du segment source

– Nouvelle traduction– Source (TA, post-edition)

Ces deux interactions simples sont employees lors de la traduction d’une page et lors de la sug-gestion, par l’utilisateur, d’une meilleure traduction pour un segment donne. L’interface completede SECTra w ne sera proposee a l’utilisateur que s’il le souhaite. Dans ce cas, le systeme offre unenvironnement complet et souple qui augmente la performance d’un traducteur qui realise de lapost-edition (cf. partie 5.1).

La MT peut ne pas contenir un segment specifique demande par l’iMAG, si la page n’a jamaisete traduite ou si elle a change. Le cas echeant, un systeme de TA sera appele pour fournir unetraduction de plus basse qualite.

25

4.2 Systemes de traduction automatique

Ce travail n’a pas l’ambition d’evaluer les systemes de TA existants. Ce type d’analyse esttres recurrent, par exemple, sur des blogs2, mais aussi effectue de facon formelle par des institu-tions comme l’agence nort americaine NIST3 et la conference IWSLT4. Nous enoncerons quelquestechniques utilisees pour la traduction :

– Traduction basee sur des regles : cette methode est la plus ancienne, et considere que latraduction est analogue au dechiffrement d’un code (Arnold et al., 1993). Dans cette ap-proche, les regles de traduction sont specifiees par des linguistes et des traducteurs, et laqualite du systeme evolue a travers les tests, dans la mesure ou les erreurs de traductionsont analysees et corrigees par les specialistes. Ces regles peuvent etre implementees dansplusieurs niveaux :– Traduction par transfert : La representation intermediaire entre la langue source et la

langue cible peut en etre dependante. Cela signifie que, generalement, le texte en entreeest analyse afin de generer une representation intermediaire qui sera, a travers des reglesgrammaticales et des dictionnaires, utilise dans la generation du texte dans la langue cible.La plupart des systemes de TA emploie ce type d’approche.

– Traduction par interlangue : Dans cette approche, le texte en langue source est convertivers une representation semantique abstraite totalement independante des langues sourceet cible (par exemple, un graphe UNL). Le generation de la traduction se fera a partirde ce graphe. Cette methode permet la generation de traductions dans plusieurs languescible a partir d’une representation unique et independante du texte en langue source.

– Traduction par dictionnaire : Un dictionnaire bilingue est utilise pour remplacer direc-tement les mots par leurs correspondances en langue cible. La traduction generee n’estutilisable que dans des cas speciaux comme des listes et des catalogues, ou les contraintesgrammaticales sont tres simplifiees voire absentes.

– Traduction basee sur exemples : Technique qui emploie des algorithmes similaires aux algo-rithmes de correspondance presentes pour les MT pour produire une analogie entre la phrasea traduire et les phrases presentes dans le corpus d’entraınement. Une fois que les analogiessont trouvees, les parties divergentes du segment sont traduites a l’aide d’un dictionnaire.

– Traduction statistique : En ustilisant un grand volume de corpus paralleles alignes, le systemecalcule les parametres du modele de la langue a travers des techniques statistiques. Des tresbons resultats ont ete obtenus recemment par Google avec cette approche.

Nous avons etudie l’utilisation de deux services de TA commerciaux disponibles en ligne :Sytran et Google. Ils sont accessibles a travers des requetes HTTP, de la meme facon que la MTde SECTra w . Systran est un des systemes de TA les plus populaires, etant utilise par exemplepar Microsoft et par BabelFish. Le service de Google est assez recent (disponible depuis 2007) etutilise un algorithme de traduction statistique. Le choix du service de TA dansune iMAG a pourcritere la paire de langues source et cible demandees et les paires de langues offertes par les deuxsystemes. S’ils possedent les langues demandees, Systran est systematiquement choisi, meme sidans l’avenir un choix base sur des parametres plus fins, tels que le nombre de mots inchanges, estenvisage.

Dans l’avenir, aussi, nous souhaitons integrer les traductions generees avec la base lexicalePIVAX, developpee aussi par l’equipe GETALP et decrite par Nguyen et al. (2007). L’idee iciserait d’utiliser les traductions obtenues de facon automatique ou a travers la post-edition pourconstruire une base lexicale pour un domaine specifique ou un site Web elu. Cette base pourraitetre utilisee comme outil dans l’interface avancee de SECTra w , de facon a aider les traducteursprofessionnels ou benevoles. La construction de ressources lexicales comme les dictionnaires etthesaurus est importante, par exemple, pour le traitement et la traduction adequats des expressionsmulti-mots d’une langue (Ramisch et al., 2008).

2Cf. blog de Jean Veronis http ://aixtal.blogspot.com/2006/01/translation-systran-or-reverso.HTML3http ://www.nist.gov/speech/tests/mt/2008/4http ://www.slc.atr.jp/IWSLT2008/

26

Chapitre 5

Generation de la page cible

Etant donne que, dans l’etape de segmentation, les segments source ont ete remplaces dans lapage par leurs identifiants, la tache de reconstruction de la page cible est reduite a la substitutiondes identifiants de segment presents dans le squelette par les traductions des segments qui portentces identifiants. Cependant, nous voulons ajouter a ces segments traduits deux foncionnalites :l’affichage du segment en langue source et la possibilite d’envoyer une post-edition pour ameliorerla traduction. Ces deux fonctionnalites ont ete rajoutees a travers un script qui est decrit dans laprochaine partie. Nous proposerons egalement des affichages alternatifs, a etre implementes dansl’avenir, de facon que l’interaction avec l’utilisateur soit optimisee.

5.1 Post-edition

L’affichage du segment source ne doit pas compromettre l’affichage de la page traduite. Ainsi, lesysteme de traduction de Google, par exemple, montre le texte original dans une boıte superposeea la page lors du passage du curseur sur le segment, comme illustre dans la figure 1.3. Nous avonschoisi d’employer la meme approche, puisqu’il s’agit d’une facon simple et efficace de fournir cetteinformation a l’utilisateur, et pour cela nous avons utilise la bibliotheque JavaScript MooTools1.

Ainsi, chaque segment reinsere dans la page cible a recu une infobulle avec le segment source,comme dans la figure 6.11. Un probleme a ete trouve concernant le temps d’affichage de ce message,puisque le simple mouvement de la souris entraınait le changement de position du message affiche.La solution palliative employee consiste a donner un temps d’affichage tres long a l’infobulle, ainsil’utilisateur aura le temps de la lire et de cliquer sur (( Suggerer une traduction. . . )), s’il le souhaite.Nous croyons que ce probleme peut etre corrige en etudiant calmement la documentation de labibliotheque et probablement en changeant l’implementation de cette fonctionnalite.

5.2 Affichage des correspondances

Une autre solution d’affichage possible a ete inspiree par les amphigrammes : des arbres conte-nant des bi-segments alignes (Chenon, 2005; Cromieres, 2004, 2005). La correspondence entre lessous-phrases d’un segment est trouvee a travers une approche statistique, en calculant l’informa-tion mutuelle entre chaque paire de mots dans un grand volume de texte aligne, puis en choisissantla correspondence qui maximise l’information mutuelle, i.e. qui minimise l’independance entre lessous-phrases. Ainsi, en utilisant ces valeurs pre-calculees, il est possible de construire les amphi-grammes dynamiquement a partir d’un bi-segment, et ensuit d’afficher l’alignement en utilisantdes couleurs foncees pour la sous-phrase selectionnee et des couleurs successivement plus clairespour les niveaux superieurs dans la representation en arbre du bi-segment. Cette forme d’affi-chage a pour avantage une meilleure comprehension de la traduction generee, par exemple, par

1http ://mootools.net/

27

un systeme de TA. L’utilisateur pourrait, dans ce type d’approche, choisir le segment qu’il pensepouvoir etre mieux traduit parmi les sous-phrases affichees. De cette maniere, la mise a jour dusegment dans la memoire de traduction peut etre optimisee (a travers l’utilisation des sous-phrasesau lieu des phrases) et la recuperation de ces dernieres peut utiliser cette information lors de lacorrespondance approchee entre les segments stockes et un segment a traduire.

Le calcul de l’information mutuelle pour toutes les paires de mots est une operation trescouteuse et entraıne l’utilisation d’un volume important de donnees. Les ressources necessairespour ce calcul sont disponibles, par exemple, sous la forme de corpus paralleles, comme Europarl,extrait des transcriptions des seances du parlement europeen et tres populaire pour la TA sta-tistique (Koehn, 2005). Le temps de ce stage etant limite, nous n’avons pas pu obtenir ces pre-correspondences entre les sous-phrases. Cette approche reste donc une suggestion d’ameliorationpour les prochaines etapes dans le developpement du prototype.

Fig. 5.1 – Exemple d’affichage d’un amphigramme.

5.3 Interface avancee de traduction

Un dernier point important a remarquer sur la generation de la page cible concerne la dispo-nibilite d’une interface avancee pour la post-edition de la page ou du site elu. Cette interface est,en fait, mise a disposition a travers un lien vers une instance de SECTra w , comme nous pouvonsle voir dans la figure 5.2 (Huynh et al., 2008). Pour effectuer une edition avancee des traductions,l’utilisateur aura besoin de s’identifier. Meme si, apparemment, l’identification peut sembler sansinteret, elle est tres importante puisqu’elle permet un suivi des traductions effectuees, tout commel’affectation d’une credibilite plus elevee aux traductions realisees par les utilisateurs identifies.

28

Fig. 5.2 – Interface de SECTra w , utilisee pour la post-edition avancee dans l’iMAG.

29

Chapitre 6

Mise en œuvre

Dans les derniers chapitres, nous avons etudie d’un point de vue theorique les problemes lies ala recuperation de la page source, ainsi qu’a la segmentation, la traduction et la generation de lapage cible dans le prototype iMAG, tout comme les decisions prises par rapport aux alternativesanalysees. Lorsque le prototype recoit une demande de traduction d’une page, il la telecharge etla pre-traite, pour ensuite extraire les elements textuels avec le format de base. Ces elements sontensuite segmentes par LingPipe et traduits, un a un, par la memoire de traduction de SECTra wou, si la MT ne contient pas le segment, par un systeme de TA. Finalement, les segments et lestraductions sont rajoutes au squelette de la page cible avec les scripts necessaires pour l’affichage dela source et la post-edition des segments. Nous avons donc toutes les specifications fonctionnellesnecessaires a la construction du prototype. Ci-dessous, nous donnons une liste non exhaustived’exigences non-fonctionnelles du prototype :

– Il doit offrir une interface Web a travers laquelle les parametres (URL du site, langues sourceet cible, domaine) peuvent etre entres. Cette interface peut prendre la forme d’une page Webou d’un appel a travers une methode HTTP.

– L’interface developpee doit etre securisee, evitant les intrusions a travers les parametres dusysteme.

– La performance de la traduction ne peut pas augmenter le temps de charge de la page audela de la limite tolerable par l’utilisateur. Les etudes empiriques montrent que cette valeurtourne autour de 5 secondes.

6.1 Architecture

Au lieu de debuter directement la conception et le codage du prototype, il est importantd’etablir un panorama general qui aidera la definition des frontieres du probleme traite. Nousexposerons ainsi un ensemble de visions du prototype, en nous servant de diagrammes formelsd’architecture logicielle. Ce decoupage offre comme avantage d’un cote l’independance semantiquedes visions et d’un autre cote un niveau de detail suffisamment abstrait pour permettre des chan-gements potentiels.

6.1.1 Modelisation du contexte

Sur le diagramme de la figure 6.1, les relations entre le systeme et les acteurs qui interagissentavec lui sont explicitees. Afin d’obtenir un diagramme simple, le prototype est modelise comme une(( boıte noire )) dont les fonctionnalites seront peu a peu developpees dans les prochaines parties.

Nous observons que la plupart des acteurs sont des composants et des services logiciels,presentes dans des rectangles, tandis que les internautes sont des acteurs qui representent des hu-mains. Les internautes non-identifies accedent au service de facon anonyme et leurs post-editions

30

<<actor>>

Sect ra (TM)

iMAG

<<actor>>

HTTP Server

<<actor>>

MT System

<<actor>>

Redirect ion Gateway

Cybernaut

<<actor>>

Web S i te

Identif iedCybernaut

translation request

view a site in a target language

segments/post-editions

segment

translated page

view the page in another language

translated page

translated page

translation

translation

advanced post-edition

HTML page

GET/POST request

translated page

translation request

Fig. 6.1 – Diagramme de contexte pour le prototype iMAG.

ne pourront etre faites que dans une interface simple. Les internautes identifies pourront accedera SECTra w pour disposer d’un environnement plus riche de post-edition.

Pour effectuer la traduction d’une page Web donnee, nous imaginons ici deux cas de figure :soit l’internaute non-identifie demande directement a l’iMAG de voir une page Web de son interetdans une langue cible (en specifiant manuellement aussi le domaine du site), soit il fait la demandea un site Web qui demandera alors a un relai de faire l’interface avec l’iMAG. Dans les deuxsituations, les informations d’entree sont la paire de langues, l’adresse de la page a traduire et ledomaine du site.

Ayant recu la demande de traduction, le prototype recupere la page aupres d’un serveur surInternet, pour ensuite utiliser un systeme de MT et de TA pour traduire les segments extraitsde la page. Finalement, le resultat de la traduction sera retransmis au demandeur – le relaisou l’internaute. Pour la post-edition, l’action implique les memes acteurs coordonnes de manieresimilaire a la precedente, raison pour laquelle nous ne la detaillerons pas ici.

6.1.2 Architecture conceptuelle

L’architecture conceptuelle concerne les modules qui composent le prototype. Un module n’estpas une classe dans le sens de la programmation a objets, mais a une granularite moins fine,pouvant correspondre dans la pratique a un paquet ou a un ensemble de classes, par exemple.

Nous proposons dans la figure 6.2 une division en quatre modules principaux coordonnes parun module de controle. Les quatre modules, a savoir pre-traitement, segmentation, traduction etreconstruction, correspondent au noyau fonctionnel du systeme. Parallelement, les modules pourl’interfacage avec les acteurs composent une couche supplementaire d’abstraction, tres importanteetant donne la dependance du systeme vis-a-vis de ces ressources externes.

Le module d’interface Web avec l’internaute ne communique pas directement avec le module decontrole : la communication passe a travers l’interface de redirection. Cela permet que le modulede controle traite les demandes de traduction de facon homogene et transparente.

31

ControlHTTP Inter face

Segmenta t ion

Translat ion

Page Reconstruct ionRedirect ion Inter face

Human-Mach ine In te r face

Translat ion Memory In ter face

Machine Translat ion Inter face

HTML pages

segments

segments

structure/translations

translated pages

translation request

translations/post-edition

translations

translation request

iMAG

SectraHTTP Server

CybernautRedirection Gateway MT System

Fig. 6.2 – Diagramme d’architecture conceptuelle pour le prototype iMAG.

6.1.3 Architecture dynamique

Les deux cas d’utilisation les plus importants pour le prototype sont la traduction d’une pageWeb et la post-edition d’une traduction. Le premier est detaille dans la figure 6.3, ou nous voyonsque le relai de traduction est responsable de selectionner le domaine de la page a traduire1. Une de-mande directe a l’interface homme-machine peut aussi contenir un domaine specifie manuellementpar l’internaute. Les appels aux interfaces de memoire de traduction et de traduction automatiquesont realises en boucle jusqu’a ce que tous les segments soient associes aux meilleures traduc-tions disponibles, qui seront enregistrees dans la MT. Ce diagramme met en evidence le role decoordination exerce par le module de controle.

Le deuxieme cas d’utilisation etudie ici est la post-edition d’un fragment de texte, dans lafigure 6.4. Le fragment dans la langue cible et dans la langue source est envoye au controle, quise chargera de decouper le fragment et sa traduction et, ensuite, de les mettre a jour dans la MTcorrespondant au domaine du site.

6.1.4 Architecture physique

Le deploiement du prototype se fera de maniere conventionnelle sur un serveur Web disponiblea l’acces des clients a travers un navigateur Internet. Les serveurs HTTP montres sur la figure 6.5fournissent a l’iMAG les pages a traduire. Dans une configuration hypothetique, SECTra w et lerelai de traduction peuvent etre deployes sur deux machines independantes. Vu qu’il s’agit d’unsysteme disponible sur Internet, la plupart des connexions utiliseront le protocole HTTP sur lacouche TCP/IP.

1La facon dont le relai fera ce choix sera consideree, dans ce travail, hors sujet. Evidemment, nous consideronsque le domaine choisi sera lie a un site, une personne, une institution, une entreprise, un groupe de personnes, etc.

32

Cybernaut

Human-MachineInterface

RedirectionInterface

Control Segmentat ionHttp Interface Translation

TMInterface

MTInterface

PageReconstruction

translate a page translate(addr,langPair) translate(addr,langPair,domain) getPage(addr)

page

split(page)

segments[] ,structure

translate(segment)

translat ion

translate(segment)

translat ion

reconstruct(structure,translat ion[])

translatedPagetranslatedPagetranslatedPagetranslatedPage

Fig. 6.3 – Diagramme d’architecture dynamique pour la traduction d’une page Web.

Cybernaut

Human-MachineInterface

RedirectionInterface

ControlTM

Interface

post-edit ion postEdit(source,target) postEdit(source,target,domain)

Segmentat ion

split(source)

sourceSegs[]

spl i t( target)

targetSegs[]

update(sourceSegs[i] , targetSegs[i] ,domain)

Fig. 6.4 – Diagramme d’architecture dynamique pour la post-edition d’une traduction.

33

Internet

HTTP ServerHTTP ServerHTTP Server

HTTP Server HTTP Server

Cybernaut

Cybernaut Cybernaut Cybernaut

Cybernaut

Redirection Gateway

Java EE Server(Tomcat)

TCP/IP - HTTP

TCP/IP - HTTP

Sectra Server

Control

HTTP Inter face

Segmenta t ion

Translat ion

Page Reconstruct ion

Redirect ion Inter face

Human-Mach ine In te r face

Translat ion Memory In ter face

Machine Translat ion Inter faceHTTP

HTTP

HTTP

HTTP

TCP/IP - LAN

TCP/IP - LAN

HTTP

Fig. 6.5 – Diagramme d’architecture physique pour le deploiement du prototype iMAG.

Fig. 6.6 – Organisation de haut niveau des modules.

6.2 Conception

Nous presenterons brievement, dans cette partie, la conception du prototype. Dans la figure6.6, l’organisation que celle des modules est presentee selon la meme organisation des chapitresutilisee dans ce rapport, permettant une bonne separation des taches. Un module d’utilitaires aete rajoute pour les fonctions auxiliaires tels que le traitement d’URL et les fonctions de tableau.

Afin de gerer la possibilite de changement d’implementation d’un module, nous avons utiliseintensement les interfaces pour la plupart des communications entre les modules. Cela permet aun module, par exemple celui qui fait le traitement de la page HTML, de traiter l’entite abs-traite representee par l’interface Page. De maniere similaire, le module utilisant le traitement despages ne connaıt que l’interface HTMLProcessor. Le schema affiche dans la figure 6.7 montre uneimplementation utilisant les classes natives de Java pour le telechargement et le traitement despages, ou la classe NativePage implemente l’interface Page. Pour le traitement des elements de lapage, nous avons ecrit un analyseur SAX qui utilise la configuration de la bibliotheque CyberNeko,dans la classe HTMLPreprocessor (Voir partie 6.3).

Dans la figure 6.8, le meme type de modele est represente avec les classes appartenant auxmodules de traitement de la page dans le paquet http et de detection de phrases, segmentation.La classe Translate est responsable de l’interface entre les parametres des appels HTTP traites

34

Fig. 6.7 – Modele conceptuel du module de traitement de pages

par Struts dans une page JSP et les valeurs internes des variables Java. Les classes Segment etSkeleton representent les objets de base de la segmentation. Nous ne presenterons qu’une partie dela conception du prototype car ils ne rajoutent pas d’informations pertinentes pour la discussion.Ces modeles ont ete utilises pour le codage du systeme

6.3 Codage et instantiation

Le langage a objets Java a ete choisi pour la mise en œuvre du prototype, permettant unegrande portabilite et fournissant des outils sophistiques de passage a l’echelle. Vu qu’il s’agitd’un systeme Web, nous avons utilise la technologie J2EE sur un serveur Apache Tomcat. Nousavons, comme decrit dans la partie 6.2, diminue le couplage entre les modules en beneficiant desinterfaces Java pour gerer l’heterogeneite intrinseque au projet, de facon qu’un module puissefacilement changer son implementation sans que, pour ce faire, il soit necessaire de modifier lesautres modules.

La couche de presentation a ete implementee a travers les Java Server Pages, qui permettentune interaction intelligente entre la logique de programme et la visualisation, tout comme del’extension Apache Tiles, qui permet la reutilisation des (( tiles )), c’est-a-dire des carreaux, pourles parties fixes de l’interface comme les menus et les en-tetes.

Le controle du prototype n’emploie pas directement les servelettes, mais est effectue de manieredescriptive a travers l’utilisation de la bibliotheque Apache Struts 2. Meme si la mise en place decet outillage prend plus de temps que l’approche traditionnelle, elle se justifie par le gain de

35

Fig. 6.8 – Modele conceptuel general des modules de traitement et segmentation de page.

36

Fig. 6.9 – Capture d’ecran du projet iMAG dans l’Environnement de Developpement IntegreNetbeans 6.

performance lors du developpement du systeme, car l’abstraction fournie cache au programmeurles details d’implementation.

Une capture d’ecran contenant un fragment de code source Java et un fragment de l’ar-borescence du projet est presentee dans la figure 6.9. Nous avons utilise l’Environnement deDeveloppement Integre Netbeans 6 tout au long de ce travail, dans le but d’accelerer la pro-grammation en profitant de l’experience positive que nous avons eue avec cet environnement dansle passe.

Une interface directe avec l’utilisateur a ete developpee pour les tests du systeme et pour lesdemonstrations. La figure 6.10 montre l’apercu de cette interface, ou l’utilisateur peut parametrerla traduction du site souhaite.

Les tests du prototype iMAG ont ete effectues principalement sur le site du LIG. Ce sitepresente un code source assez propre et bien construit, selon les criteres necessaires pour le bonfonctionnement du prototype. La figure 6.11 montre le resultat du site traduit en portugais, surla page d’accueil. Des tests plus exhaustifs, concernant un autre site elu, sont envisages afind’augmenter sa robustesse.

Un projet sur la plate-forme LigForge a ete cree 2, avec notamment un depot de controle deversions SVN pour garder la trace de modifications et rendre plus facile l’extension et l’eventuellecontinuation du developpement. La mise en ligne du code source est envisagee, sous conditiond’adopter une licence qui respecte les droits d’auteur. Une documentation partielle en style Java-Doc a ete creee, mise a disposition et devra garantir la correcte maintenance du prototype.

2http ://imag.ligforge.imag.fr/

37

Fig. 6.10 – Capture d’ecran de l’interface du prototype.

Fig. 6.11 – Instance du prototype iMAG sur le site du LIG.

38

Chapitre 7

Conclusions

L’internationalisation et localisation des systemes logiciels disponibles en ligne est un reelprobleme. Si d’une part les techniques de localisation interne ont l’inconvenient d’obliger unetraduction hors-contexte et onereuse, d’autre part la qualite de la traduction des techniques delocalisation externe n’est pas suffisamment haute pour permettre leur application a des systemesde pour lesquels la qualite de la traduction est importante. Une passerelle interactive d’accesmultilingue, iMAG, est une couche logicielle permettant de gerer le multilinguisme d’un site Webelu grace a une MT et un dictionnaire dedies et a l’appel des systemes de TA avec des parametersadequats. Elle offre une solution parametrable et performante, puisqu’elle permet un melangedes deux approches de localisation en ayant comme principe de base l’utilisation de la meilleuretraduction possible.

Nous avons decrit dans ce rapport les etapes suivies durant la realisation d’un stage de find’etudes au GETALP. Nous avons conceptualise et decrit la mise en œuvre d’un prototype iMAG etson instantiation sur un site concret, le site du Laboratoire d’Informatique de Grenoble, presentantdonc une analyse des aspects theoriques et pratiques du travail effectue.

Nous avons, tout d’abord, precise les definitions d’un site et d’une page Web, en montrantainsi que le traitement de ces objets n’est pas un probleme trivial a cause de leur heterogeneiteintrinseque, surtout pour la traduction des structures complexes comme les formulaires. Ensuite,nous avons explique de quelle facon la segmentation des pages a ete implementee, a travers l’ex-traction de fragments HTML a partir de la page originale, leur traitement par un detecteur auto-matique de phrases present dans la bibliotheque LingPipe et quelques cas speciaux pour lesquelsl’approche choisie n’est pas toujours bien adaptee. Nous avons defini un segment (pour les languesindo-europeennes) comme une phrase (ou un titre) dans laquelle quelques balises de formatagesont acceptees. Apres avoir decrit le processus d’extraction de segments, nous avons introduit lesdeux types de systemes employes : les memoires de traduction et les systemes de TA. Outre laredondance des documents traduits, la taille du segment et l’algorithme de correspondance, exacteou approchee, sont decisifs dans la performance des memoires de traduction. Les systemes de TAemploient aujourd’hui une grande gamme de techniques : traduction basee sur des regles (partransfert, par interlangue et par dictionnaire), traduction basee sur exemples, traduction statis-tique. Une iMAG utilise toujours la meilleure traduction disponible pour un segment : quand latraduction est presente dans la memoire de traduction, elle est directement acceptee1, sinon le seg-ment est traduit automatiquement. Les post-editions des traducteurs professionnels et benevolessont mises a jour dans la memoire et ont invariablement plus de credibilite que les traductionsautomatiques brutes. La memoire de traduction de SECTra w a ete utilisee pour la mise en œuvredu prototype, et nous avons evoque la possibilite de creer des ressources pour l’internationalisationinterne ou la creation des ressources lexicales avec PIVAX a partir du moment ou la MT atteintun point fixe. La generation de la page cible consiste a remplacer les identifiants des segments parleurs traductions, en rajoutant des scripts qui permettent l’affichage des segments source et l’envoi

1Choisir une traduction parmi un ensemble de pre-tradutions possibles demeure un probleme ouvert et tresinteressant, qui pourra etre etudie dans l’avenir.

39

des post-editions, tout comme la mise a disposition d’un acces non anonyme sur SECTra w pourune interaction avancee avec la traduction du site.

Nous avons decrit l’analyse,la conception et le codage du prototype, en justifiant les choixde developpement. Son instantiation sur le site du LIG montre de bons resultats, puisque desbenevoles, par exemple les membres du laboratoire, peuvent ameliorer la traduction du site dansleur temps libre, ce qui demontre le bas cout et la souplesse d’une iMAG. Certaines parties decritesdans ce rapport concernent des suggestions pour l’avenir du projet, puisque les restrictions decomplexite et de temps n’ont pas permis l’implementation de toutes ces idees. Nous citons, parmiles taches qui restent a faire, l’utilisation des amphigrammes dans l’affichage des bi-segments, lechoix intelligent d’un systeme de TA et des tests plus complets sur d’autres sites elus. Nous pensonsque les benefices potentiels de ce projet peuvent etre maximises a travers ces ameliorations.

Le travail dans un groupe de recherche comme le GETALP illustre l’interaction entre lesmondes professionnel et academique, et a ete donc tres enrichissant dans la mesure ou l’echanged’experiences entre le stagiaire et les thesards, chercheurs et professeurs qui travaillent dans lelaboratoire montre une application de l’interpretation litterale de la definition de stage : uneperiode de travail mais aussi d’apprentissage et de developpement professionnel. De plus, la pos-sibilite d’appliquer les connaissances acquises precedemment dans le Traitement Automatique dela Langue Naturelle et les contacts et opportunites etablis durant cette periode sont d’extremeimportance pour l’avenir professionnel et la suite des etudes du stagiaire, qui souhaite poursuivresa carriere dans ce domaine.

Il a ete tres gratifiant pour le stagiaire de savoir son travail utile et important au developpementde la recherche en TALN, et de pouvoir apporter sa contribution sous forme d’une etude theoriqueet de l’implementation d’un prototype. Cette reconnaissance est intensifiee par le fait qu’il s’agitd’une solution logicielle d’application potentiellement vaste et qui propose une solution a unprobleme tellement important pour les entreprises, organisations et institutions non gouvernemen-tales.

De maniere generale, nous pouvons affirmer que la mise en commun des competences comple-mentaires est souvent positive. L’idee de base d’iMAG consiste a employer diverses techniquespour obtenir la meilleure traduction disponible pour un site Web, par exemple. Semblablement, laformation d’ingenieur proposee par l’ENSIMAG peut etre completee avec l’experience de travaildans un laboratoire de recherche, et le resultat est enrichissant pour toutes les parties engagees. Cetaspect complementaire est egalement present dans le projet d’echange internationale et cooperationfranco-bresilienne dans le cadre duquel ce stage a ete possible. Le melange de competences estaussi une caracteristique du traitement des langues, une science qui melange les connaissances deplusieurs autres champs comme la linguistique, la cognition, l’intelligence artificielle, la statistiqueet l’informatique. Finalement, nous suggerons qu’il est important et necessaire de continuer acombiner competences et efforts pour faire avancer la recherche dans ce champ ou nous avonsencore, malgre les nombreux efforts et progres deja faits, un grand nombre de barrieres a franchiret de defis a relever.

40

Bibliographie

HTML 4.01 Specification, Decembre 1999. URL http ://www.w3.org/TR/html401/.

D. Arnold, L. Balkan, S. Meijer, R. Humphreys, et L. Sadler. Machine Translation : an Introductory Guide.Blackwells-NCC, London, UK, 1993. URL http ://www.essex.ac.uk/linguistics/clmt/MTbook/.

Y. Bar-Hillel. The present status of automatic translation of languages. In F. L. Alt, editor, Advances in ComputersI, pages 91–163. Academic Press, 1960.

Y. Bey, C. Boitet, et K. Kageura. The TRANSBey prototype : an on- line collaborative wiki-based CAT environ-ment for volunteer translators. In LREC- 2006 : Fifth International Conference on Language Resources andEvaluation. Third International Workshop on Language Resources for Translation Work, Research & Training(LR4Trans-III), pages 49–54, Genoa, Italy, May 2006.

E. Bicici et M. Dymetman. Dynamic Translation Memory : Using Statistical Machine Translation to ImproveTranslation Memory Fuzzy Matches. In A. F. Gelbukh, editor, CICLing, volume 4919 de Lecture Notes inComputer Science, pages 454–465, Haifa, Israel, 2008. Springer. ISBN 978-3-540-78134-9.

C. Boitet, P. Chatelin, et P. D. Fraga. Present and future paradigms in the automatized translation of naturallanguages. In Proceedings of the 8th conference on Computational linguistics, pages 430–436, Tokyo, Japan,1980. Association for Computational Linguistics.

C. Boitet, V. Bellynck, M. Mangeot, et C. Ramisch. Towards Higher Quality Internal and Outside Multilinguali-zation of Web Sites. In P. Bhattacharyya, editor, Summer Workshop on Ontology, NLP, Personalization andIE/IR – ONII-08, page 8, IITB Bombay, India, 2008.

C. Chenon. Vers une meilleure utilisabilite des memoires de traduction, fondee sur un alignement sous-phrastique.These de Doctorat, Universite Joseph Fourier, Grenoble, France, Octobre 2005.

F. Cromieres. Etudes d’arbres binaires statistiques pour l’analyse bilingue. Technical report, CLIPS-GETA, 2004.

F. Cromieres. Recherche et exploitation d’alignements sous-phrastiques hierarchiques. These de Master, UniversiteJoseph Fourier, Grenoble, France, Juillet 2005.

M. Daoud. Vers des passerelles interactives d’acces multilingue (iMAG). These de Master, Universite JosephFourier, Grenoble, France, Septembre 2007.

J. Goldsmith. Automatic Collection and Analysis of German Compounds. In The Computational Treatment ofNominals, pages 61–69, Montreal, Canada, 1998.

G. Grefenstette et P. Tapanainen. What is a word, what is a sentence ? Problems of tokenization. pages 79–87,1994.

C.-P. Huynh, C. Boitet, et H. Blanchon. SECTra w .1 : an Online Collaborative System for Evaluating, Post-editingand Presenting MT Translation Corpora. In E. L. R. A. (ELRA), editor, Proceedings of the Sixth InternationalLanguage Resources and Evaluation (LREC’08), Marrakech, Morocco, Mai 2008.

R. Jackendoff. The architecture of language faculty, volume 28 de Linguistic inquiry monographs. The MIT Press,Cambridge, USA, 1997. ISBN 0-262-10059-2.

P. Koehn. Europarl : A Parallel Corpus for Statistical Machine Translation. In MT Summit X, Punket, Thailand,2005.

V. I. Levenshtein. Binary Codes Capable of Correcting Deletions, Insertions and Reversals. Soviet Physics Doklady,10 :707–+, Fevrier 1966.

H.-T. Nguyen, C. Boitet, et G. Serasset. PIVAX, an online contributive lexical data base for heterogeneous MTsystems using a lexical pivot. In A. Kawtrakul, M. Zock, et W. Phantachat, editors, The Seventh InternationalSymposium on Natural Language Processing - SNLP-07, Decembre 2007.

41

T. Ohta, Y. Tateisi, et J.-D. Kim. The GENIA corpus : an annotated research abstract corpus in molecular biologydomain. In Proceedings of the second international conference on Human Language Technology Research -HLT-02, pages 82–86, San Francisco, USA, 2002. Morgan Kaufmann Publishers Inc.

E. Planas et O. Furuse. Formalizing Translation Memories, volume 21 de Text, Speech and Language Technology,chapitre 5, pages 157–188. Kluwer Academic Publishers, netherlands edition, 2003. ISBN 1402014007.

C. Ramisch, A. Villavicencio, L. Moura, et M. Idiart. Picking them up and Figuring them out : Verb-ParticleConstructions, Noise and Idiomaticity. In CoNLL-2008 Twelfth Conference on Computational Natural LanguageLearning, pages 49–56, Manchester, UK, Aout 2008.

G. Serasset et C. Boitet. On UNL as the future “html of the linguistic content” & the reuse of existing NLPcomponents in UNL-related applications with the example of a UNL-French deconverter. In Proceedings ofthe 18th conference on Computational linguistics, pages 768–774, Saarbrucken, Germany, 2000. Association forComputational Linguistics.

B. Vauquois et C. Boitet. Automated translation at Grenoble University. Computational Linguistics, 11(1) :28–36,1985. ISSN 0891-2017.

D. J. Walker, D. E. Clements, M. Darwin, et J. W. Amtrup. Sentence boundary detection : A comparison ofparadigms for improving MT quality. In Proceedings of MT Summit VIII – MTS-2001, pages 18–22, Santiagode Compostela, Spain, 2001.

N. C. Zakas, J. McPeak, et J. Fawcett. Professional Ajax, 2nd Edition. Wrox Press Ltd., Birmingham, UK, 2007.ISBN 0470109491.

J. Zeldman. Designing With Web Standards. New Riders Publishing, Thousand Oaks, USA, 2003. ISBN 0735712018.

42

Annexe A

Planning comparatif

Une comparaison entre les plannings previsionnel et effectif est presentee dans le tableau A.Le tableau est organise selon l’organisation suggeree dans le pre-rapport et montre l’evolutiondu travail du stagiaire. Nous remarquons que les semaines 3 a 5 ont effectivement decale tout leplanning de deux semaines, car la mise en place des outils de developpelemt tels que Tomcat,Struts et Tiles, mais surtout leur mise en route en parallele, a pris plus de temps que ce qui avaitete intialement prevu. Cela a entraıne une diminution de la periode de test par rapport au planningprevisionnel. L’aspect du traitement des pages comme un probleme non negligeable et non triviala aussi retarde de peu le rythme du projet, sans graves consequences pour le resultat final.

A titre de bilan final, nous pouvons affirmer que le projet n’est pas encore clos puisque certainsaspects demeurent a explorer. Neanmoins, nous avons pu, pendant ces cinq mois, demontrer l’utiliteet l’importance du concept d’iMAG a travers la mise en œuvre d’un prototype fonctionnel et, a ladifference de ce qui avait ete fait precedemment, maintenible et extensible. Ce prototype servirade base pour la creation d’un systeme robuste et puissant avec une reelle valeur economique etd’inovation scientifique.

43

Semaine Tache prevue Tache effectuee

1 Etude bibliographique. Familiarisationavec les themes du stage.

Etude bibliographique. Familiarisationavec les themes du stage.

2 Etude technologique, preparation del’environnement de developpement.

Etude technologique, preparation del’environnement de developpement.

3, 4, 5 Etude sur la segmentation et des solu-tions existantes. Problemes lies au co-dage et aux balises HTML.

Mise en place de Java, Tomcat, Struts,Tiles. Test des bibliotheques pour trai-ter l’encodage et la syntaxe HTML.

6, 7 Envoi des segments vers systemes deTA. Etude des memoires de traduction,interface avec SECTra w .

Navigation traduite transparente.Developpement de l’interface utilisa-teur.

8, 9, 10 Generation de la page cible. Enrichisse-ment avec des fonctions d’affichage dufragment source et de post-edition.

Etude de la segmentation et des solu-tions. Mise en place de l’analyseur Cy-berNeko et du segmenteur LingPipe.

11, 12, 13 Interface avancee basee sur SECTra w .Integration avec des dictionnaires ter-minologiques, post-edition.

Appel aux systemes de TA et a la MTde SECTra w. Integration de ces outilsau prototype.

14, 15 Etude de la technique des amphi-grammes. Implementation de la tech-nique a travers du code javascript dansla page.

Appel au relai de traduction et adapta-tion du relai a l’iMAG.

16, 17 Validation, test et debogage dusysteme. Deploiement sur serveur,utilisation, test d’acceptation.

Generation de la page cible, test sur lesite du LIG.

18 Instantiation de l’iMAG sur le site del’initiative B@BEL de l’Unesco.

Rajout de scripts pour l’affichage dusegment source avec la bibliothequeMooTools.

19 Instantiation de l’iMAG sur le site del’encyclopedie EOLSS/UNL.

Rajout de scripts pour la post-editiondes segments.

20 Instantiation de l’iMAG sur le site duprojet DEMGOL.

Rajout de scripts pour la post-editiondes segments.

21 Instantiation de l’iMAG sur le site duLIG.

Debut des tests sur le site du LIG.

22 Evaluation finale des resultats, de laqualite de la traduction et de l’activitecollaborative des utilisateurs.

Correction des erreurs residuelles, pa-rametrage.

23 Bilan, redaction du rapport de stage,preparation de la soutenance.

Documentation, redaction du rapportet preparation de la soutenance.

Tab. A.1 – Planning comparatif du stage, semaine par semaine.

44