"SMS2TEXT" «Traduction Automatique du Langage SMS vers la Langue Naturelle»

Université de Caen Basse-Normandie Projet Annuel "SMS2TEXT" «Traduction Automatique du Langage SMS vers la Langue Naturelle» (Traduktion otomatik du langage SMS vr la lang naturl) Membre du groupe : Emilie Lebossé Pierre-Yves Lapersonne 21 mars 2012 Tuteur : Gaël Dias

Remerciements Tout d abord, nous tenons à remercier vivement Gaël Dias, qui, en tant que tuteur, a su nous consacrer une partie de son temps afin de nous guider tout au long du projet. De part ses explications, sa patience et l aide qu il a apportée, le projet a put finalement aboutir dans les temps. Nous tenons également à remercier les différentes équipes de chercheurs qui ont put nous envoyer sans contre partie une partie des résultats de leurs recherches afin de nous permettre de réaliser nos propres corpora de SMS. Nous faisons référence ainsi aux membres de l équipe de l Institute of Infocomm Research de Singapour (Aiti Aw, Min Zhang, Juan Xiao et Jian Su) [1] pour les données concernant le corpus en anglais. Nous citons également l équipe de chercheurs de l Université Chinoise de Hong Kong (Kam-Fai Wong et Yunqing Xia) [11] pour leur participation à l élaboration du corpus de textes en chinois. Enfin, nous faisons également référence aux membres d une équipe de recherche d Orange Labs Lannion qui a put nous fournir en données afin de constituer notre corpus de textes français (Catherine Kobus, François Yvon et Géraldine Damnati) [6]. Par ailleurs, nous tenons à remercier Adrien Lardilleux et Wigdan Abbas Mekki pour leurs explications et l aide qu ils nous ont apportées à propos d Anymalign et de Moses. Enfin, nous voulons remercier Jean-Philippe Métivier pour sa participation au projet concernant les règles d associations. Ses explications claires ont pu nous faire avancer dans notre système de traduction. i

Table des matières Remerciements Table des matières Table des figures i iii v 1 Introduction 1 1.1 Contexte.......................................... 1 1.2 Objectifs.......................................... 2 1.3 Contraintes......................................... 2 1.4 Plan............................................. 2 2 Etat de l art 3 2.1 Caractéristiques Linguistiques du Langage SMS................... 3 2.1.1 L Abréviation................................... 4 2.1.2 Le Rébus typographique............................. 4 2.1.3 La Contraction.................................. 5 2.1.4 Les Émotions................................... 5 2.1.5 La Combinaison de Procédés.......................... 6 2.2 Les Différents Modèles de Traduction Automatique................. 6 2.2.1 Les Paradigmes Basés sur la Linguistique................... 6 2.2.2 Les Paradigmes Basés sur les Statistiques................... 8 2.3 La Traduction du Langage SMS au Langage Naturel................. 9 2.4 Les Applications Existantes............................... 10 3 Normalisation du Corpus 11 3.1 Le Métalangage XML et la Validation avec une DTD................. 11 3.1.1 Qu est ce que le XML?.............................. 11 3.1.2 La DTD...................................... 12 3.2 Les Corpora formatés en XML.............................. 12 iii

iv TABLE DES MATIÈRES 4 Traduction Basée sur des Règles 15 4.1 Création du Dictionnaire................................. 15 4.1.1 La méthode de Smadja (1996).......................... 15 4.1.2 Le Dice....................................... 16 4.1.3 Des calculs suplémentaires........................... 17 4.2 Évaluation du Dictionnaire............................... 18 4.3 Règles de Traduction................................... 19 5 Traduction Basée sur des Modèles Statistiques 21 5.1 Anymalign......................................... 21 5.2 Moses............................................ 22 6 Développement 23 6.1 Traitement des données reçues............................. 23 6.2 Analyse de Système.................................... 23 6.3 Base de Données..................................... 32 7 Déroulement du Projet 35 7.1 Les étapes du projet initiales............................... 35 7.2 Les étapes du projet effectives.............................. 36 8 Conclusions et Perspectives 37 9 Lexique 39 10 Annexes 41 Bibliographie 69

Table des figures 4.1 Schéma de la méthode de Smadja............................ 15 6.1 Morceau du diagramme de classe du programme DictionnaireSMS........ 25 6.2 Morceau du diagramme de classe du programme TraducteurSMS......... 27 6.3 Morceau du diagramme de classe du programme EvaluateurSMS......... 29 6.4 MLD de la base de données............................... 32 1 Planning du projet initial (Liste des tâches)...................... 51 2 Planning du projet initial (Gantt)............................ 52 3 Planning du projet initial (Liste des tâches 1)..................... 53 4 Planning du projet initial (Liste des tâches 2)..................... 54 5 Planning du projet initial (Diagramme 1)....................... 55 6 Planning du projet initial (Diagramme 2)....................... 56 v

Chapitre 1 Introduction Le marché du smartphone est en pleine expansion depuis 2010 dû à l apparition de nouveaux appareils comme l Iphone (Apple), les Blackberry (RIM), et les dispositifs sous Android (Google). Néanmoins une grande partie de la population est «info-exclue» car elle ne se sent pas intéressée ou n est pas initiée à ces technologies de communication. L utilisation de ces appareils est à l origine d un nouveau langage le SMS (Short Message Service). Celui-ci consiste à réduire un texte en langue naturelle en utilisant par exemple des abréviations ou la phonétisation des mots. Cependant ce langage n est pas normalisé et il n est employé que par une partie des utilisateurs. De plus de nouvelles règles sont continuellement inventées ce qui le rend très dynamique. Cela a pour effet de rendre sa compréhension difficile. Nous essaierons donc de répondre à la question suivante : «Comment réaliser un outil proposant une traduction efficace du langage SMS au langage naturel dans différentes langues?». 1.1 Contexte Les technologies de communication mobiles sont essentiellement basées sur un service d échange de messages écrits (limités à 160 caractères) : le Short Message Service (SMS). Ce nouveau service a donné naissance au langage SMS faisant de très nombreux adeptes, notamment chez les jeunes générations, dû au fait de minimiser le coût des envois. Néanmoins, il a été constaté que ce langage engendre des problèmes de communication avec les autres générations, moins jeunes, qui sont ainsi info-exclues. D autre part, deux applications 1 existent déjà mais elles ne sont pas multilingues et leur dictionnaire reste limité rendant difficile la lisibilité des messages traduits. 1. www.langagesms.com & www.traducteur-sms.com 1

2 Introduction 1.2 Objectifs Ainsi, ce projet a pour objectifs d implémenter deux techniques amplement connues pour la traduction : 1. traduction basée sur les règles [10] 2. traduction statistiques [8] pour un traducteur du langage SMS au langage naturel pour trois langues différentes (chinois, anglais et français). La première version devra être basée sur une méthode de calcul prenant en compte des règles (Rule-Based Machine Translation) et sera appliquée sur les corpora de textes en anglais et en chinois à cause de leur taille minimale. La deuxième version du traducteur sera basée sur une méthode statistique (Statisitical Machine Translation) qui concernera uniquement la langue française grâce à un corpus de plus grande taille. Enfin, un service Web sera implanté afin de proposer ces services de traduction aux utilisateurs via Internet ou par le biais d une application pour smartphones. 1.3 Contraintes Ce projet devra être réalisé sur une période de 6 mois (débutant en Octobre 2011 et se finissant en Mars 2012) et avec le langage de programmation Java. Les deux méthodes citées plus haut (basées sur les règles et sur les statistiques) devront être impérativement utilisées et implantées dans des prototypes distincts. De plus, les logiciels Anymalign et MOSES [7] devront être utilisés pour le modèle statistique. Enfin, les traducteurs devront prendre en compte le chinois, l anglais et le français. 1.4 Plan Tout d abord nous détaillerons ce qu est le langage SMS, les différents principes de la traduction automatique ainsi que ce qui a été réalisé concernant la traduction du langage SMS au langage naturel. Ensuite, nous préciserons les étapes du projet qui ont déjà été réalisées ou qui sont en cours. Enfin, nous aborderons la plannification du projet.

Chapitre 2 Etat de l art 2.1 Caractéristiques Linguistiques du Langage SMS Le SMS (Short Message Service) est un service d échange de messages écrits limités à 160 caractères. Cette limitation a engendré l apparition du langage SMS qui est une nouvelle forme de communication écrite pour les nouvelles technologies de communication. Ce langage est caractérisé par des écarts importants et systématiques des normes orthographiques. De plus, s ajoute à celui-ci une utilisation non conventionnelle des symboles alphabétiques et de la ponctuation pour à la fois introduire du contenu phonétique et du méta-dialogue comme les émotions. Ces modifications du langage naturel permettent de réduire la longueur du message dans le but de ne pas dépasser cette limitation de taille pour ne pas engendrer de surcoût ou encore pour accélérer la saisie de celui-ci. Les utilisateurs vont donc privilégier d avantage le sens du message en écrivant rapidement, notamment avec peu de mots et peu de caractères mais en gardant une certaine idée de la syntaxe. Les particularités de ce langage sont sa perpétuelle évolution et sa multitude de variations possibles. La seule limite aux variations des SMS est l imagination des utilisateurs. Ainsi, la composition des mots est totalement imprévisible. De plus, certains mots peuvent apparaître seulement occasionnellement (lors d un événement sportif par exemple). Il est donc très difficile de normaliser ce langage. Néanmoins, on constate un certain nombre de procédés qui le caractérise permettant de raccourcir les phrases et les mots comme le démontrent Bove [3] et Wikipedia 2. Le langage SMS est un langage particulièrement phonétique qui tend à rendre le même son mais avec une réalisation lexicale simplifiée. 2. http ://fr.wikipedia.org/ (Article Langage SMS et Article Emoticônes) 3

4 Etat de l art 2.1.1 L Abréviation Le principe de l abréviation est de supprimer la plupart des voyelles ainsi que certaines consonnes tout en conservant un mot plus ou moins lisible et compréhensible. Cela s explique par le fait que les consonnes ont une valeur informative plus forte que les voyelles. Ce procédé permet de réduire considérablement la taille d un mot. On obtient donc une succession de consonnes principales du mot. (Voir le tableau 2.1) slt = salut prtt = pourtant tjs, tjr, tjrs = toujours lgtps = longtemps Table 2.1 Exemples d abréviations 2.1.2 Le Rébus typographique Le rébus typographique est le procédé par lequel certaines séquences de lettres, d un mot ou d une suite de mots, sont remplacées par un arrangement de chiffres et/ou de lettres correspondant au même phonème que la séquence concernée. Ce procédé est basé essentiellement sur la phonétique. On utilise la valeur épellative des lettres, des chiffres et des caractères pour obtenir le mot. (Voir le tableau 2.2) G = j ai C = c est, ces 2m1 = demain bi1 = bien gt = j étais jamé = jamais a12c4 = à un de ces quatre koi 2 9 = quoi de neuf mr6 = merci grav = gravé grav = grave Table 2.2 Exemples de rébus typographiques

2.1 Caractéristiques Linguistiques du Langage SMS 5 2.1.3 La Contraction La contraction correspond à la formation d un mot par la réunion de deux ou plusieurs unités lexicales comme illustré dans le tableau 6.4. «JE» «QUE» «CE / SE» «ME» Exemples de patrons j + pronom j + verbe k + article défini k + pronom démonstratif k + pronom personnel s + pronom s + verbe m + pronom m + verbe Exemples jte (= je te) jsui (= je suis) kle (= que le) kce (= que ce) ktu (= que tu) ske (= ce que) svoir (= se voir) mle (= me le) mparl (= me parle) Table 2.3 Exemples de contractions 2.1.4 Les Émotions Les émotions caractérisées par des émoticônes sont plus souvent utilisées dans le langage d Internet car elles nécessitent des caractères autres que des chiffres et des lettres qui sont plus difficiles d accès. Cependant, ceux-ci sont de plus en plus utilisés car ils sont limités en caractères ce qui permet d exprimer facilement des émotions. Les émotions sont représentées via certaines représentations du corps humain avec des caractères spécifiques comme le démontre le tableau 2.4. Signification Emoticônes Signification Emoticônes Sourire :-) ^^^_^ Triste, déçu :-( :( Riant de toutes ses dents :-D xd XD Clin d oeil ;-) Tirant la langue :-P Etonné, bouche bée, Oh! :-o :-O Pleurant : ( Indifférence :- Table 2.4 Exemples d émoticônes Ce procédé est hors de notre étude car il n intervient pas dans la traduction puisque ceux-ci restent identiques dans les deux cas.

6 Etat de l art 2.1.5 La Combinaison de Procédés Les procédés énoncés précédemment peuvent être combinés les uns avec les autres pour augmenter la contraction d un mot ou d une phrase. Par exemple, adm1 = à demain. Ainsi on a un rébus pour le mot "demain" (dm1) et la contraction entre deux mots (a et dm1). 2.2 Les Différents Modèles de Traduction Automatique Selon Dorr [4], différents modèles de traduction ont été réalisés afin de pouvoir traduire au mieux des ensembles de textes. Ces modèles se déclinent en deux catégories : les modèles linguistiques et les modèles statistiques. 2.2.1 Les Paradigmes Basés sur la Linguistique Il s agit de l ensemble des systèmes qui prennent en compte des informations autres que le seul lexique, par exemple la syntaxe ou la sémantique des phrases pour produire un résultat dans le langage cible. Modèle Basé sur le Lexique (Lexical-based MT) Les systèmes de traduction basés sur ce modèle font appel à des règles particulières qui réalisent la correspondance entre une entrée lexicale d un mot dans un langage vers une entrée du même mot mais dans un autre langage. Plusieurs implémentations du système ont été faites, et l une d elle se ramène à un problème de transfert de mot. Ce type d approche fait appel à des structures de données particulières (des arbres). Les relations entre un mot dans un langage et sa traduction dans un autre sont construites à partir d un lexique bilingue. Ce lexique associe deux arbres de départ et d arrivée à travers des relations entre chaque mot. De cette façon, chaque entrée du lexique contient une relation entre une phrase dans le langage source et une phrase dans le langage voulu. Un des incovénients de cette approche est qu elle nécessite d utiliser des arbres complets qui doivent être stockés en mémoire pour chaque combinaison de langage (langage source/langage cible), ceci peut s avérer être très lourd. Modèle Basé sur les Règles (Rule-based MT) Ce type de modèle est associé aux systèmes qui prennent en compte différents niveaux de règles linguistiques de traduction entre deux langages. Il est basé sur des lexiques mais aussi sur un système de règles. On trouve deux principaux types de règles : les "M-Règles" ("meaning-

2.2 Les Différents Modèles de Traduction Automatique 7 preserving rules") qui prennent en compte le sens du mot, et les "S-Règles" ("non-meaningful rules") qui traitent d avantage la syntaxe. Les "M-Règles" font d avantage appel aux lexiques pour déduire la signification du mot. Cette approche diffère de celle basée sur le lexique, car les exigences particulières de chaque mot (ou entrée lexicale) sont implémentées dans un mécanisme de contrôle plutôt que dans le lexique lui-même. On retrouve couramment certains types de règles [2]. Par exemple, il existe des règles de formation qui traitent la formation des mots composés et qui servent à mettre en correspondance les structures ainsi établies. Des règles syntagmatiques et des règles de correspondance définissent des critères linguistiques comme c est le cas avec les traducteurs en ligne comme Reverso ou Systran. Les règles syntagmatiques font appel à des règles de réécriture qui servent à décomposer des phrases. Les règles de correspondances sont employées pour faire correspondre les règles précédentes entre les langages source et cible. Le modèle basé sur les règles peut devenir complexe car il nécessite d avoir des dictionnaires bilingues conséquents avec des informations linguistiques bien précises [9]. Un autre inconvénient de cette approche est que la structure de la phrase (avec l organisation des mots à l intérieur) dépend du langage ce qui peut faire que certaines règles ne peuvent pas être applicables. Modèle Basé sur les Transferts (Transfer-based MT) Le but général de ce type de structure est de générer un texte syntaxiquement correct dans un langage précis. Ceci se fait en transformant une représentation dans le langage source en une autre représentation dans le langage cible. Les règles de transfert qui permettent cette conversion dépendent en partie des langages manipulés. Il y a deux principaux types de transfert 3 : les transferts lexicaux et les transferts structurels. Les premiers servent à affecter pour chaque mot une traduction appropriée selon le contexte de la phrase où il est. Les seconds permettent d assurer le bon ordonnancement des mots dans la phrase et entreprennent d autres adaptations structurelles (comme des transpositions de mots). Néanmoins, certaines de ces règles doivent être ajustées afin de ne pas faire de confusion, en particulier quand les langages concernés sont syntaxiquement proches d autres langages. Ce système requiert également des règles de liaisons qui permettent de faire une correspondance entre un texte avec son langage et différentes représentations internes. Cependant, ce système possède un inconvénient : les différentes représentations faites à partir de l analyse des langages utilisés dépendent très fortement des langages eux-mêmes, ce qui implique de tout reconstruire pour chaque langage utilisé. Modèle Basé sur les Inter-langues (Interlingua-based MT) Le but de ces architectures est de trouver une représentation sémantique commune entre des textes dans des langages différents. Le principe est que l analyse d un texte dans un langage source devrait aboutir à une représentation du texte qui doit être indépendante de tout langage. 3. http ://www.linguatec.fr/products/tr/information/technology/mtranslation

8 Etat de l art Ainsi, le texte dans le langage cible est généré à partir d un langage "neutre" qui est celui de la représentation du texte. On passe ainsi par une représentation intermédiaire, qui n est pas dans les langages concernés (inter-langue). Ainsi, l aspect sémantique des textes a d avantage d importance et sert à passer d une représentation à une autre. Ce genre d achitecture comporte un inconvénient : comme aucun aspect syntaxique n est pris en compte, le style original du texte est perdu, et le texte traduit est d avantage paraphrasé. 2.2.2 Les Paradigmes Basés sur les Statistiques Généralement, ces approches doivent se baser sur de très gros corpora, ce qui n est pas le cas de la majorité de nos corpora, excepté pour le français même si celui-ci contient que 40000 phrases SMS traduites. Modèle Basé sur les Statistiques (Statistical-based MT) Cette approche dépend fortement de l analyse statistique des corpora parallèles bilingues. Le modèle utilise deux modèles particuliers : un modèle de traduction et un modèle de la langue. Le modèle de traduction met en évidence la probabilité qu un mot SMS ait la meilleure traduction d un mot en langue naturelle. p(sms txt) (2.1) Le modèle de la langue détermine la probabilité que le texte concerné soit le plus cohérent possible et qu il propose la meilleure traduction possible. p(txt) (2.2) Ainsi, le produit de ces probabilités p(sms txt).p(txt) (2.3) permet de déterminer la meilleure traduction possible. L inconvénient de cette méthode est qu elle nécessite des gros corpora afin d avoir des probabilités plus précises. Modèle Basé sur les Exemples (Example-based MT) Ce paradigme de traduction est basé sur une émulation de la traduction humaine en reconnaissant les similitudes entre une phrase dans un langage source et différents éléments qui ont déjà été traduits dans le passé. Il s agit finalement d une traduction par analogie. Cela fait appel à une base de données qui contient des traductions parallèles qui permettent de trouver des phrases ou des mots qui ressemblent le plus à ce que l on cherche. Les différentes traductions

2.3 La Traduction du Langage SMS au Langage Naturel 9 trouvées sont par la suite combinées et traitées pour former une nouvelle phrase traduite. Pour déterminer si un mot peut correspondre à un autre, un "écart sémantique" est évalué entre eux. Cet écart permet de définir si les deux mots sont très proches en ce qui concerne leur sens. Cet écart est évalué avec un principes d ontologies (représentations conceptuelles des mots) ou avec un thésaurus (liste organisée de termes en rapport avec un mot défini). La précision et la qualité de la traduction dépendent très fortement de la taille de la base de données utilisée. De plus, la structure de la phrase à traiter doit être sensiblement la même que celles présentes dans la base de données, sinon il risque d y avoir des traductions incohérentes. 2.3 La Traduction du Langage SMS au Langage Naturel Afin de pouvoir réaliser notre projet de traduction de SMS, une large étude de l existant a été réalisée afin d avoir connaissance des recherches qui ont déjà été menées à ce sujet ainsi que leurs enjeux. Les recherches les plus interessantes pour notre projet ont été résumées ci dessous. Une première équipe de recherche Belge [5] a mis en place une opération de collecte de SMS permettant d obtenir 30 000 SMS en langue française. Ils ont par la suite réalisé le formatage et la traduction de ces SMS en langage naturel. Leurs recherches ont mis en évidence différents problèmes comme le fait que les utilisateurs adoptent rapidement de nouvelles habitudes d écriture. Ces utilisateurs privilégient d avantage le sens du message en utilisant peu de mots et de caractères ce qui rend la composition des SMS imprévisible. Ils ont put également mettre en évidence que le langage SMS est un mélange de codes et d expressions empruntés à d autres formes de dialogue. Par ailleurs, une équipe Française de recherche d Orange à Lannion [6] s est penchée sur le problème de la normalisation des SMS. Leur étude a mis en évidence le fait que les messages SMS sont caractérisés par des écarts importants et systématiques des normes orthographiques. Les symboles alphabétiques, la ponctuation et des contenus phonétiques sont également utilisés intensivement, notamment pour exprimer des émotions. Différentes approches ont été réalisées pour la normalisation des SMS. Le problème peut par exemple être ramené à un problème de correction d orthographe. La correction est alors basée sur du mot à mot tout en prenant en compte leur contexte. Une autre façon de faire est de considérer le langage SMS comme un langage étranger ce qui ramène la normalisation à une traduction simple. Ainsi, plusieurs mots traduits peuvent correspondre à un mot en SMS. Différents modèles comme des modèles statistiques peuvent se charger de rendre cohérent l ordre des mots traduits. Les chercheurs ont également fait appel à un modèle qui se base d avantage sur la prononciation. Cette ap-

10 Etat de l art proche part du principe que l orthographe du SMS se rapproche fortement de la prononciation du mot. Le SMS est alors vu comme une approximation syllabique de la forme phonétique. Ceci leur a permis d effectuer certains types de corrections. Afin de faire correspondre chaque mot SMS à sa traduction et d optimiser les résultats, les logiciels GIZA++ et Moses ont été utilisés. Enfin, une équipe Chinoise [11] a mis en évidence l ambiguité des mots SMS en analyant les forums de discussions (chats) chinois sur Internet. Du fait des nombreuses ressemblances entre les messages SMS et ceux envoyés sur les chats, les résultats de leur étude peuvent être facilement transposés au langage SMS. De part son étude, l équipe a put déduire que la plupart des mots de ce langage ne sont pas inclus dans le dictionnaire car le langage SMS est très dynamique et change continuellement. De plus, il peut y avoir plusieurs significations pour un mot SMS. L étude a permis de mettre en évidence que la plupart des mots des chats et donc des SMS sont crées à partir de leur prononciation et non pas de leur orthographe. 2.4 Les Applications Existantes Nous avons pu repérer et tester deux traducteurs SMS disponibles sur Internet. Le premier d entre eux est présent sur www.langagesms.com. Le deuxième est accessible sur certains réseaux sociaux, sur Internet et sur Android via le site www.traducteur-sms.com. Néanmoins, ces traducteurs en ligne sont assez limités. Le premier possède un dictionnaire de seulement 369 mots, ce qui est assez restreint pour proposer une bonne traduction. Celle-ci se rapproche essentiellement d une traduction mot à mot lorsqu elle est efficace. En effet, nous avons essayé de traduire un SMS simple provenant de notre corpus français ("keskon peu envoyé com sms"), mais le résultat produit par l application fut totalement inefficace : celle-ci produisit en traduction "keskon peu envoyé com sms". La deuxième application fut bien plus performante. Celle-ci dispose d un dictionnaire de 9961 mots en mémoire et ses traductions sont biens précises. Effectivement, nous avons utilisé le même exemple que précédement et l application nous retourna en version traduite "Qu est-ce qu on peut envoyé comme SMS". Le seul mot erroné ("envoyé") n était simplement pas présent dans le dictionnaire utilisé. Néanmoins, cette application est robuste car elle prend en compte les mots composés et de nombreuses caractéristiques propres au langage SMS (abréviations et phonétique notamment).

Chapitre 3 Normalisation du Corpus Nous avons en notre possession quatre corpora (deux en français, un en anglais et un en chinois). Les corpora français proviennent de l Université Catholique de Louvain [5] et de la société Orange Labs de Lannion [6]. Le corpus anglais provient quant à lui de l Institut pour la Recherche sur l Infocommunication de Singapour [12] et le corpus chinois de l Université de Tsinghua à Pekin [11]. Ceux-ci sont dans des formats différents. Certains sont dans un fichier texte, d autres dans un fichier Excel avec une hiérarchisation des données différentes. Il a donc fallut les normaliser pour obtenir des formats identiques et traitables de la même façon. Notre choix s est porté sur le métalangage XML. 3.1 Le Métalangage XML et la Validation avec une DTD 3.1.1 Qu est ce que le XML? Le XML (extensible Markup Language) est une spécification proposée par le W3C (World Wide Web Consortium) en 1998. C est un métalangage standardisé ouvert, à la grammaire stricte, normalisé et structuré dans un fichier texte. Il permet aussi de hiérarchiser et de parcourir des données rapidement. Elles sont encapsulées dans des balises qui peuvent être définies par l utilisateur. Les Règles Le XML respecte un certain nombre de règles telles que : 1. Le respect de la casse, 2. La fermeture de chaque balise ouverte, 3. L encadrement par des guillemets des valeurs d attributs, 11

12 Normalisation du Corpus 4. Les balises ne peuvent être entrelacées. Les Avantages et Inconvénients Le XML a pour avantages de pouvoir être utilisable pour n importe quel jeu de caractères ce qui est intéressant pour notre projet car nous traitons différentes langues (chinois, anglais et français). Il permet aussi de structurer l information sous une forme plus robuste que d autres fichiers (binaires,... ). De plus, le parcours des données s effectue de manière rapide et efficace ce qui va nous être très utile pour la création du dictionnaire à partir de ces corpora qui sont de taille plus ou moins importante. Cependant, les données stockées au format texte sont plus volumineuses qu au format binaire. 3.1.2 La DTD Un document XML est dit "valide" s il est "bien formé" et qu il possède une DTD (Document Type Definition). La DTD permet de définir la structure que l on veut donner à notre document XML (Voir le tableau 3.1). Dans celui-ci, on définit les balises pouvant être utilisées dans le document XML avec des attributs si nécessaire ainsi que la hiérarchisation entre les balises. <!ELEMENT chat (sms,txt)> <!ATTLIST chat id ID #REQUIRED> <!ELEMENT sms> <!ELEMENT txt> Table 3.1 DTD pour la validation des corpora 3.2 Les Corpora formatés en XML Ces corpora ont été construits avec plusieurs scripts AWK. Le français <chat id="18"> <sms>keskon peu envoyé com sms</sms> <txt>qu est-ce qu on peut envoyer comme SMS</txt> </chat> Table 3.2 Extrait du corpus français formaté

3.2 Les Corpora formatés en XML 13 Le chinois L anglais <chat id="17"> <sms>jj, 你 LG 坐 车 了 米 有 啊 </sms> <txt> 姐 姐, 你 老 公 坐 车 了 没 有 啊 </txt> </chat> Table 3.3 Extrait du corpus chinois formaté <chat id="50"> <sms>who r u talking 2?</sms> <txt>who are you talking to?</txt> </chat> Table 3.4 Extrait du corpus anglais formaté

14 Normalisation du Corpus

Chapitre 4 Traduction Basée sur des Règles La traduction basée sur un système de règles est l un des deux types de traduction étudiés au cours de ce projet. Elle concerne essentiellement les petits corpora (en anglais et en chinois) car ceux-ci peuvent générer d avantage de résultats. L intérêt principal de cette méthode est qu un dictionnaire regroupant des paires de mots SMS et de mots en langage naturel est établi. 4.1 Création du Dictionnaire 4.1.1 La méthode de Smadja (1996) Afin de pouvoir établir le dictionnaire, des recherches ont été réalisées concernant une méthode particulière [10]). Cette méthode utilise un modèle basé sur un système de règles qui vont servir à remplir le dictionnaire. Cette méthode est représentée par le schéma 4.1. Figure 4.1 Schéma de la méthode de Smadja 15

16 Traduction Basée sur des Règles La méthode possède deux phases qui traitent un corpus parallèle. La première phase calcule un Dice pour chaque mot de la phrase SMS avec tous les mots de la phrase en langue naturelle qui correspond. Par exemple, pour la phrase SMS "cc cv b1" et sa version texte "Coucou ça va bien", on obtient pour le mot "cc", les Dice : Dice(cc,Coucou), Dice(cc,ça), Dice(cc,va), Dice(cc,bien). La deuxième phase applique les règles que l on souhaite appliquer aux différents Dice obtenus ce qui nous permet de conserver le Dice avec la combinaison <mot sms/mot clair> la plus probable. Ce Dice pourra être stocké dans une base de données qui correspond au dictionnaire que l on souhaite obtenir. 4.1.2 Le Dice Le Dice est un coefficient utilisé par ce modèle et qui se base sur un mot écrit en langage SMS et un mot écrit en langage naturel. Il calcule dans un premier temps la fréquence du couple <texte SMS/texte clair>, c est-à-dire le nombre de fois où l on retrouve ces deux mots ensemble dans une paire de texte <texte SMS/texte clair>. f (m sms, m txt ) (4.1) Par la suite, les fréquences du mot en SMS et du mot en langage naturel sont calculées, respectivement f (m sms ) (4.2) et f (m txt ) (4.3) La formule ci-dessous permet alors de déterminer le coefficient Dice. Dice(X, Y) = 2 f (m sms, m txt ) f (m sms ) + f (m txt ) (4.4) Ceci permettra alors de déterminer quel couple de mots <texte SMS/texte clair> est le plus probable suivant le coefficient Dice et donc quel mot en langage naturel est la meilleure traduction du mot SMS.

4.1 Création du Dictionnaire 17 4.1.3 Des calculs suplémentaires Par ailleurs, des calculs supplémentaires ont été réalisés. Ces calculs permettent de voir si le Dice peut être remplacé par un autre coefficient afin d établir un meilleur dictionnaire. Pointwise Mutual Information (PMI) PMI(X, Y) = log f (X, Y) f (X) f (Y) (4.5) Mutual expectation (ME) ME(X, Y) = 2 f 2 (X, Y) f (X) + f (Y) (4.6) Jaccard Jaccard(X, Y) = f (X, Y) f (X, Y) + ( f (X) f (X, Y)) + ( f (Y) f (X, Y)) (4.7) Log Likelihood ratio (LogLike) LogLike(X, Y) = 2 (log θ s1 1 (1 θ 1) n1 s1 +log θ s2 2 (1 θ 2) n2 s2 log θ s1 (1 θ) n1 s1 log θ s2 (1 θ) n2 s2 ) et avec N = Nombre de couples formés X,Y où X est un mot SMS et Y un mot en langue naturel s1 = f (X, Y) s2 = f (Y) f (X, Y) n1 = f (X) n2 = N f (X) θ = f (Y) N θ s1 = ( f (Y) N )s1 θ 1 = s1 n1 θ 2 = s2 n2 Table 4.1 Détail du LogLike (4.8)

18 Traduction Basée sur des Règles 4.2 Évaluation du Dictionnaire Afin de voir si le dictionnaire réalisé propose des traductions acceptables des mots SMS, des évaluations ont été réalisées. Ces évaluations se basent sur le calcul d un coefficient nommé Précision. Plusieurs types de précisions allant de 1 à 5 (Précision à 1, Précision à 2,..., Précision à 5) ont été déterminés. La Précision utilise une liste de mots (ici en langage naturel) qui sont tous des traductions possibles d un mot SMS, c est à dire les mots pour lesquels un Dice (ou un autre coefficient) a été calculé. Cette liste de mots est ordonnée en fonction du coefficient visé de telle sorte à ce que le mot en tête de liste soit la meilleure traduction. A l inverse, le mot en queue de liste sera la pire traduction possible. Ainsi, pour le cas du Dice, les mots qui ont le Dice le plus élévé seront en tête de liste, il en est de même pour les autres coefficients. La Précision permet de déterminer si, pour un mot en langage SMS donné, la meilleure traduction se trouve parmi les premiers mots en langage naturel proposé. Par exemple, la Précision à 1 détermine si la meilleure traduction d un mot SMS est le 1er mot proposé. Également, la Précision à 2 détermine si la meilleure traduction d un mot est dans les 2 premiers mots de la listes et ainsi de suite. Precision à 1 = Nombre de fois que le premier mot de la liste est la meilleure traduction Le nombre de mot qui ont été traduit (=échantillon) Ainsi, plusieurs évaluations ont été réalisées permettant d évaluer la qualité des traductions avec les différents coefficients utilisés (Dice, Jaccard, ME, PMI et LogLike). Anglais Chinois Précision Dice PMI ME Jaccard LogLike @1 0.662 0.372 0.727 0.636 0.719 @2 0.797 0.511 0.835 0.771 0.805 @3 0.853 0.615 0.879 0.818 0.866 @4 0.870 0.675 0.900 0.853 0.879 @5 0.887 0.693 0.905 0.857 0.883 @1 0.912 @2 0.930 @3 0.947 @4 0.947 @5 0.947 Table 4.2 Résultat des évaluations pour l Anglais et le Chinois En analysant les résultats des évaluations faites, on peut constater la chose suivante. Pour les calculs des Précisions, plus les résultats obtenus sont proches de 1.00, meilleures sont les traductions. Ainsi, on peut constater que le PMI est le coefficient le moins adapté à notre système de traduction. En effet, parmi les 5 calculs réalisés, aucun n a une valeur qui atteint 0.7, d autant

4.3 Règles de Traduction 19 plus que la seule Précision qui s en rapproche est la Précision à 5. Néanmoins, bien que le Dice fut le coefficient utilisé par le système de traduction, celui-ci n est pas le meilleur. En effet, si on le compare au LogLike, presque toutes ses Précisions, mis à part la Précision à 5, sont inférieures à celles du LogLike. Ce dernier serait alors d avantage intéressant. Or, on peut remarquer que le ME est lui même supérieur au LogLike car les valeurs obtenues par les 5 Précisions calculées sont toutes supérieures. On peut conclure de cette évaluation que le coefficient Dice peut être remplacé par un coefficient offrant de meilleurs résultats (ME), bien qu il possède des Précisions honorables. Le Dice peut ainsi être remplacé aisément dans le système de traduction grâce aux principes de génie logiciel appliqués durant l élaboration des différents programmes. Concernant les évaluations de la traduction chinoise, on peut constater que seul la Dice a été calculé. Les autres coefficients n ont pas été déterminés pour deux raisons. Tout d abord, un manque de temps est apparu empêchant de pouvoir réaliser toutes les évaluations. Néanmoins, celle-ci peuvent être réalisées ultérieurement via le programme prévu à cet effet. La deuxième raison est que les résultats pouvant être obtenus avec ces évaluations risquent d être erronés. En effet, la langue chinoise ne repose pas sur les mêmes principes que les langues occidentales comme le français. Comme un symbole peut designer un mot ou une partie de mot, il est difficile de pouvoir déterminer quelle est la bonne traduction du symbole considéré. Ce problème s accentue d autant plus que, comme les membres du groupe n ont pas de compétences en chinois, les symboles choisis risquent d être incorrects. 4.3 Règles de Traduction La méthode de Smadja utilisée pour effectuer la traduction mot à mot utilise également un ensemble de règles qui s appliquent sur les résultats obtenus avec les différents coefficients déterminés (notamment le Dice). Ainsi, pour obtenir un dictionnaire efficace avec la meilleure traduction possible pour chaque mot, plusieurs règles seront appliquées sur chaque Dice calculé. 1. Conserver les coefficients qui ont la fréquence du couple (mot SMS/mot clair) supérieure à 5. Cela va permettre de donner plus de force aux éléments fréquents. 2. Pour chaque mot SMS, on conservera que le Dice le plus élevé. Si on a deux Dice avec la même valeur, ils seront tout les deux pris en compte.

20 Traduction Basée sur des Règles

Chapitre 5 Traduction Basée sur des Modèles Statistiques Le second type de traduction utilisé ici est une traduction basée sur des modèles statistiques. Ces modèles probabilistes sont plus élaborés et plus complexes d utilisation et de mise en oeuvre. Cependant ils offrent des traductions plus efficaces qui prennent en compte notamment les formes conjuguées et les expressions courantes. Les corpora de taille conséquente sont les plus intéressants ici car ils contiennent assez de données pour pouvoir établir de bons modèles. Ainsi, les corpus regroupant les messages en français est utilisé. Deux outils ici ont été utilisés, à savoir Anymalign et Moses. 5.1 Anymalign Anymalign est un outil crée par A. Lardilleux afin d établir un modèle de traduction. Ce modèle permet d établir un ensemble de probabilités indiquant qu un mot SMS a plus de chance d être traduit par un mot en langage naturel plutôt qu un autre. Ce programme se base sur deux corpora de textes qui contiennent tous les textes en langage SMS pour l un et tous les textes en langage naturel pour l autre. Ces corpora ont été produits à partir du corpus au format XML utilisé et sont parallèles et alignés. Ils sont parallèles car pour une ligne avec un langage et un fichier donné, on trouve à la même position dans l autre fichier la ligne équivalente dans l autre langue. Ils sont également alignés car les mots gardent leur position dans les textes et, pour un mot dans un texte d un fichier, on trouve sa traduction à la même position dans l autre fichier. Initialement, un autre programme aurait du être utilisé pour produire ce modèle de traduction : il s agissait de Giza++. Néanmoins, ce fut Anymalign qui fut choisi. Ce choix se justifie par le fait qu Anymalign est un programme qui produit rapidement des résultats et qui les améliore en fonction de sa durée d exécution. Ainsi, on exécutant le programme plusieurs 21

22 Traduction Basée sur des Modèles Statistiques heures à la suite, les résultats produits seront plus intéressants que ceux de Giza++. De plus, son utilisation est nettement plus aisée que Giza++ pour des étudiants ayant peu de connaissances dans le domaine de la traduction, car elle ne fait pas appel à des notions et des termes complexes contrairement à Giza++. L inconvénient majeur d Anymalign est que son exécution est nettement plus lente que Giza++, cette différence de temps de calculs étant expliquée par les langages dans lesquels les programmes ont été développés (Python pour Anymalign et C/C++ pour Giza++). 5.2 Moses Moses, quant à lui, est utilisé pour produire un modèle de la langue mais également pour l utiliser avec le modèle de traduction pour pouvoir traduire un texte. Ce modèle de la langue sert à déterminer les caractéristiques de la langue afin de pouvoir produire une traduction la plus proche de la langue naturelle possible. Ainsi, les formes conjuguées (comme les participes passés en français) et les expressions populaires sont d avantage utilisées par ce modèle rendant ainsi la traduction plus réaliste. Pour que Moses puisse gérer les textes à traduire et traduits, deux fichiers doivent être créés. Le texte à traduire devra être enregistré dans un de ces fichiers et sa traduction sera mise, par le programme, dans l autre.

Chapitre 6 Développement Afin de pouvoir établir le système de traduction de textes en langage SMS en textes en langage naturel, différentes technologies et différents outils ont été utilisés. 6.1 Traitement des données reçues Une des premières étapes du projet était de pouvoir récolter un grand nombre de corpora contenant des textes en langage SMS et des textes en langage naturel. Divers organismes 5 ont été contactés, et ceux-ci ont put fournir leurs données. Néanmoins, ces données ont été envoyées sous différentes formes, que ce soit au format texte (.txt) ou au format tableur (.xsl,.ods,.sxc et.csv). Ainsi, il a fallu créer pour chaque type de fichier envoyé un script AWK permettant de le traiter et de produire un fichier au format XML avec toutes les données intéressantes. Le langage AWK est un langage de traitement des fichiers très puissant qui permet à la fois de traiter très rapidement un fichier et de le manipuler facilement. C est pourquoi il a été choisi pour traiter les fichiers reçus. 6.2 Analyse de Système Un langage pour 4 programmes Pour pouvoir mettre en place le système de traduction et le tester, différents programmes (au nombre de 4) ont été réalisés. Ces programmes ont tous les quatre été implémentés avec le même langage qui est Java. Il s agit d un langage portable car le fichier exécutable produit peut être utilisé sur n importe quelle machine sans nécessiter de recompilation. Java est également 5. L Université Catholique de Louvain [5], la société Orange Labs de Lannion [6], l Institut pour la Recherche sur l Infocommunication de Singapour [12] & l Université de Tsinghua à Pekin [11]. 23

24 Développement un langage multiplateforme, c est-à-dire qu il peut s exécuter aussi bien sous Linux, Mac OSx et Windows. Ainsi, les programmes ont pu être développés plus facilement et peuvent être utilisés sous n importe quelle machine de l université. De plus, grâce à son paradigme Orienté Objet, les programmes réalisés sont d avantage modulaires et maintenables. Par ailleurs, un EDI 6 a été utilisé : il s agit d Eclipse 7. Il s agit d un logiciel permettant de développer les différents programmes tout en proposant à la fois des fonctionnalités très utiles comme la réalisation de tests unitaires (faits avec JUnit 8 ), la génération de documentation au format HTML et également la gestion des dépôts (comme Subversion 9 ). Le programme DictionnaireSMS Le premier programme (DictionnaireSMS) a été établi dans le but de traiter les corpora au format XML pour pouvoir remplir une base de données. C est ce programme qui est chargé d effectuer les différents calculs comme le Dice. Différents packages ont été construits et, avec toute la puissance du paradigme Orienté Objet de Java, ont permis d avoir une application facilement maintenable et reprenable. Différentes librairies externes ont été utilisées que ce soit pour pouvoir manipuler la base de données (JDBC) et traiter les fichiers XML (JDOM). Néanmoins, l API Java de base n était pas suffisante pour pouvoir effectuer tous les traitements. En effet, il a fallut utilisant une librairie externe proposée par Apache pour pouvoir utiliser des structures de données optimisées et efficaces pour les traitements à réaliser (commons-collections). Ainsi, des MultikeyMap ont put être utilisées pour pouvoir par exemple stocker en une seule fois un Dice avec les deux mots utilisés et leur fréquence d apparition. Grâce à la documentation integrée dans le code (sous format Javadoc) et à la modélisation du programme, DictionnaireSMS est facilement reprenable. En effet, s il est nécessaire de traiter un nouveau corpus au format XML, il suffira de le référencer dans une classe prévue à cet effet (Corpora.java). De même, si de nouveaux calculs doivent être réalisés, les développeurs n auront qu à établir des classes Java héritant de celles existantes comme AutresCalculsBuilder par exemple. Également différents types de langues peuvent être traités par ce programme. En effet, dans certaines langues (comme l anglais ou le français) les mots sont séparés dans les phrases par la ponctuation et par des espaces entre eux. Or, ce n est pas le cas dans d autres langues. Par exemple pour le chinois, les mots sont collés les uns aux autres, sans espace, et la ponctuation a une importance très faible. Ainsi, les langues ayant un type plutôt occidental sont gérées par une classe particulière (EnglishDiceBuilder), et celles qui se rapprochent du chinois sont gérées par ChineseDiceBuilder. Enfin, afin de préserver les mots des différentes langues possibles, l encodage UTF8 a été choisi. Il s agit d un encodage qui prend un compte un nombre 6. Environnement de Développement Intégré 7. http ://www.eclipse.org/ 8. http ://www.junit.org/ 9. http ://subversion.apache.org/

6.2 Analyse de Système 25 très grand de symboles protégeant ainsi les mots avec des caractères non latins comme le chinois. Figure 6.1 Morceau du diagramme de classe du programme DictionnaireSMS

26 Développement Le programme TraducteurSMS Il s agit du programme permettant de réaliser les traductions en tant que telles. Ce programme prend deux paramètres qui sont le texte en langage SMS à traduire et la langue de ce texte. Pour plus de facilités, la langue est référencée dans un fichier particulier (Langue) ce qui permet de la manipuler plus facilement, notamment avec la base de données. En fonction de cette langue, le programme instanciera le bon type de traducteur qui utilisera la base de données (pour les textes en anglais et en chinois), ou qui fera appel à Moses qui utilisera lui même les deux modèles établis précédemment (pour les textes en français). Ainsi on peut distinguer deux types de traducteurs dans le programme qui sont les traducteurs basés sur les modèles statistiques (TraducteurProbas) et ceux basés sur des règles (TraducteurRègles). Ces deux classes, héritant de la classe Traducteur, permettent à d éventuels développeurs de reprendre le programme et d y ajouter très facilement des nouveaux types de traducteurs. Les traducteurs de type TraducteurRègles vont utiliser la base de données remplie auparavant via le programme DictionnaireSMS. Le texte à traduire sera découpé en mots en respectant les normes de la langue utilisée et, pour chaque mot, une requête SQL sera construite et exécutée afin d obtenir la traduction du mot. De cette façon, on construit un nouveau texte en conservant la ponctuation et les mots dans leur langage d origine s ils n ont pu être traduits. Cependant, la mise en place d un traducteur faisant appel à un programme externe comme Moses est bien plus complexe. En effet, il faut que le programme Java puisse lancer un programme totalement étranger et plus ou moins connu, et également qu il gère l exécution de ce programme et les différents fichiers à utiliser jusqu à sa fin. Ainsi, plusieurs classes ont dû être réalisées pour pouvoir représenter ces nouveaux processus, mais aussi les commandes qui les exécutent et les programmes eux-mêmes. En effet, l exécution d un programme externe au programme TraducteurSMS est réalisée en exécutant une commande de type Bash ou Shell par exemple. Le programme Java exécute alors cette commande et attend que celle-ci soit complètement terminée. Puisqu il s agit d exécuter une commande appelant un programme externe, des questions de sécurité se sont posées. Ainsi, tous les programmes pouvant être appelés par le programme TraducteurSMS doivent être obligatoirement référencés dans le fichier ProgrammesAutorises. Ainsi, seuls les programmes indiqués dans cette énumération peuvent être appelés. Finalement, lorsque Moses termine (en étant lancé avec ce mécanisme), il suffit de lire dans un des deux fichiers précisés pour pouvoir obtenir la traduction. Néanmoins, le temps d exécution est légèrement plus long qu avec le précédent type de traducteur utilisant la base de données. En effet, Moses se base sur deux modèles (de traduction et de la langue) qui sont des fichiers textes relativement lourds. De plus, des traitements statistiques sont réalisés avec ses fichiers ce qui entraîne une hausse du temps d exécution. Par ailleurs, le programme est fortement dépendant des deux modèles utilisés. Ainsi, si ces modèles sont peu riches en information, la traduction proposée sera de qualité moindre car certains mots pourront être mal traduits voire totalement absents.

6.2 Analyse de Système 27 Figure 6.2 Morceau du diagramme de classe du programme TraducteurSMS

28 Développement Le programme EvaluateurSMS Il s agit du troisième programme réalisé pour le projet, qui a été construit dans le but de pouvoir déterminer la qualité de la traduction proposée et de pouvoir confronter les résultats obtenus avec différents calculs. Ainsi, plusieurs coefficients autres que le Dice (Loglike, PMI, ME et Jaccard) ont put être évalués grâce à ce programme. Le fonctionnement du programme comporte plusieurs étapes. Tout d abord, un nombre donné de mots en langage SMS seront tirés aléatoirement en interrogeant la base de données. Ensuite, toutes les traductions possibles de chaque mot SMS sont déterminées par lecture de la base. L étape suivante consiste à demander à l utilisateur d indiquer parmi les traductions proposées laquelle est la meilleure. Enfin, l utilisateur renseignera cette information et le programme pourra répéter cette suite d actions pour un autre mot dans sa liste jusqu à ce que tous soient traités. Étant donné que cette application fait d avantage appel à l utilisateur que les trois autres programmes réalisés, une attention particulière a été accordée à son développement. Ainsi, l utilisateur n a qu à préciser au lancement du programme le nombre de mots SMS qu il veut évaluer, la langue de ces mots et enfin le calcul qu il souhaite utiliser. Ce calcul est représenté simplement par une classe Java qui implémente une interface précisé (GenerateurTradPos). Ainsi, si l utilisateur veut évaluer avec un nouveau calcul, il n aura qu à créer une classe Java implémentant cette interface. La fonction héritée permet de définir les traductions possibles d un mot dans une langue donnée (en paramètres), et sera utilisée par la suite dans le programme (par la classe EvaluateurPrecisions). De cette façon, les classes déjà établies pour le Dice, le Jaccard et les autres coefficients se contentent d interroger la base de données via une requête SQL et de renvoyer les résultats via cette interface. Néanmoins ce programme pourrait être d avantage convivial. En effet, les interactions entre le programme et son utilisateur se font uniquement par la console. Cependant, il est tout à fait possible de réaliser une partie graphique permettant de rendre le programme d avantage chaleureux. De cette façon, les développeurs n auront qu à utiliser les interfaces UIInput et UIOutput pour que leurs objets (comme les fenêtres ou les champs de saisies) communiquent avec le programme. Ainsi, la modélisation de l évaluateur (comme des autres applications et scripts du projets) permet grandement l ajout de nouvelles fonctionnalités.

6.2 Analyse de Système 29 Figure 6.3 Morceau du diagramme de classe du programme EvaluateurSMS

30 Développement Le programme AssociatorSMS Enfin, un dernier programme qui, comme le programme EvaluateurSMS, n était pas prévu initialement, a été réalisé afin d optimiser le système de traduction. En effet, pour la traduction basée sur les statistiques, le logiciel Moses est utilisé avec deux modèles : un modèle de la langue et un modèle de traduction. Néanmoins, ces modèles ne sont pas les plus adéquats pour gérer les associations de mots. Par exemple, on retrouve de manière très fréquente dans des expressions populaires ou couramment utilisées un ensemble précis de mots. coucou ça va, je fais mon CV Table 6.1 Exemple d associations courantes Or, ces modèles ne tiennent pas compte de ces associations courantes de mots ce qui peut donner des traductions incorrectes. Par exemple, la phrase SMS cc cv peut être traduite par coucou CV au lieu de coucou ça va. De même la phrase jfé mon cv peut être traduite par je fais mon ça va au lieu de je fais mon CV. On constate alors qu il peut y avoir une confusion de mots lorsque les traductions en SMS sont semblables (ici cv fait référence à la fois à ça va et au curriculum vitae) ce qui nest pas pris en compte avec les modèles établis. Cependant, ces rapports entre les mots peuvent être représentés sous forme de règles d associations. Ces règles pourront déterminer quelle est la suite de mots la plus adéquate. Le programme AssociatorSMS a ainsi été conçu afin de créer une représentation de ces règles sous forme de matrice. Cette matrice sera ensuite utilisée par un programme conçu par Jean-Philippe Métivier afin de générer un nouveau modèle de traduction d avantage performant. Cette application va utiliser un des corpora au format XML contenant les SMS en langages SMS et naturel et comporte plusieurs phases de traitements. La première consiste à calculer tous les mots dans chaque langage et de les stocker dans des fichiers distincts pour pouvoir les exploiter ultérieurement. Ensuite, chaque paire de messages SMS/naturel est parcourue afin de comparer les mots de chaque texte de chaque langage à l ensemble de mots du fichier.

6.2 Analyse de Système 31 Ainsi pour un fichier de cette forme : <chats> <chat id="1"> <txt>je fais mon CV</txt> <sms>jfé mon cv</sms> </chat> <chat id="2"> <txt>coucou ça va</txt> <sms>cc cv</sms> </chat> </chats> Table 6.2 Extrait d un corpus formaté au format XML Le programme produira une matrice du type : 1 1 1 1 0 0 0 1 1 1 0 0 0 0 0 1 1 1 0 0 1 1 je fais mon CV coucou ça va jfé mon cv cc chat 1 1 1 1 1 0 0 0 1 1 1 0 chat 2 0 0 0 0 1 1 1 0 0 1 1 Table 6.3 Exemple matrice d association Ici, chaque ligne à un couple de messages SMS/naturels (les chats ), et chaque colonne correspond aux mots naturels et mots SMS distincts. Néanmoins, bien que l optimisation du programme fut une des principales préoccupations lors de son développement, celui-ci présente plusieurs inconvénients. Tout d abord, la rapidité d exécution dépend très fortement du corpus à traiter. Ainsi, plus le corpus est riche en mots et en couples de messages en langages naturel et SMS, plus les temps de traitements seront longs. Ceci s explique par le fait que d avantage de mots et de textes sont à traiter, ce qui a également pour effet de consommer beaucoup de mémoire. Ainsi, il est préférable d augmenter manuellement la quantité de mémoire réservée pour le programme au moment de son exécution. Par ailleurs, bien que les fichiers contenant les mots SMS et naturels soient de tailles relativement modestes (pas plus de quelques Mégaoctets), ce n est pas le cas du fichier contenant la matrice. En effet le nombre de lignes de celle-ci est égal au nombre de chats du corpus XML. De plus, son nombre de colonnes est égal à la somme de tous les mots en langages naturel et SMS. Ainsi, si le corpus est riche en mots, la matrice sera très large ce qui peut poser des problèmes de mémoire. Par exemple, avec un corpus de 37000 chats comportant 30000 mots naturels et 113000 mots SMS, la matrice produite occupera un epsace mémoire d environ 10 Go. Or, comme cette matrice doit être impérativement sous

32 Développement forme de fichier texte, elle doit être répartie dans plusieurs fichiers car les différents systèmes d exploitation imposent une limite de poids pour les fichiers. 6.3 Base de Données La base de données joue un rôle important dans le système de traductions. En effet, les traducteurs utilisant la méthode basée sur les règles doivent utiliser la base qui a servi à appliquer ces règles sur les différents mots. Effectivement, après que le Dice soit calculé et enregistré pour toutes les combinaisons de mots (par le programme DictionnaireSMS), les règles sont appliquées sur certaines tables de la base. Ces règles, au format SQL, serviront à remplir une table particulière qui représentera le dictionnaire lui même. C est cette même table qui sera utilisée par le programme TraducteurSMS pour pouvoir effectuer la traduction basée sur du mot à mot. Le Modèle Logique des Données (MLD) ci dessous 6.4 est un modélisation de la base de données ainsi que de ses tables. Figure 6.4 MLD de la base de données

6.3 Base de Données 33 Ce modèle comporte 5 tables distinctes. Deux de ces tables servent à stocker de manière unique tous les mots en langage naturel et tous les mots en langage SMS. Par ailleurs, les différentes langues traitées sont stockées dans une table à part. De cette façon, seuls les identifiants des mots et des langues sont utilisés, ce qui permet d avoir un minimum de dépendances entre les données. La table calculs sert à stocker tous les coefficients déterminés en fonction des mots naturel et SMS. Ainsi, sur un même tuple de cette table, on retrouvera les identifiants des mots SMS et naturel mais aussi la valeur des coefficients calculés, chaque coefficient étant dans une colonne particulière de la table. Enfin, la table dictionnaire permet de conserver une seule traduction en langage SMS d un mot en langage naturel. C est cette table qui est remplie grâce aux règles, et qui est interrogée par le traducteur. select ms.mot as "motsms", mn.mot as "motnaturel", l."id" from ( select "IDmotSMS","IDmotNaturel","dice" from calculs where frequence > 5 ) c join "motsms" ms on d."idmotsms" = ms."id" join "motnaturel" mn on d."idmotnaturel" = mn."id" join ( select "ID", code from langue where code = ANG ) l on l."id" = ms."idlangue" and c.dice in ( select max(c.dice) from calculs c join "motsms" ms2 on c."idmotsms" = ms2."id" where ms.mot = ms2.mot ) and ms.mot!= mn.mot ; Table 6.4 Requête SQL qui permet d obtenir le dictionnaire avec les règles Tout d abord, plusieurs SGBD (Système de Gestion de Base de Données) pouvaient être utilisés pour nos programmes, à savoir notamment MySQL et PostgreSQL. Ainsi, le SGBD choisi fut PostgreSQL. Cet outil a été choisi car il présente l avantage d être libre d utilisation (sans aucune licence contraignante). De plus, il respecte la norme SQL2003 (contrairement à MySQL) qui concerne les standards SQL. De cette façon, les requêtes SQL utilisées dépendent peu du SGBD. De plus, contrairement à MySQL, PostgreSQL est d avantage optimisé pour le traitement des données présentes en très grandes quantités (effectivement, certaines tables ont plus de 1 000 000 de lignes). Concernant l utilisation de la base de données dans les différents programmes, deux outils ont été mis en place. Tout d abord, l accès à la base se fait au travers l applciation d un design pattern particulier, le Singleton, qui permet d avoir pour tout le programme une seule et unique connexion à la base qui pourra être utilisée par le programme. De plus, une classe Java particulière (Connexion) permet de regrouper les différentes informations nécessaires à la connexion à la base, à savoir le serveur où elle se trouve (et le port utilisé), son nom mais aussi

34 Développement le nom d utilisateur et le mot de passe. Également, la connexion à la base se fait au démarrage du programme. Ainsi, si jamais elle n a pas put être établie, le programme se terminera avec un message d erreur. L ensemble de ces éléments, regroupés dans un même package, permet d avoir d avantage de sécurité vis à vis de la base et du programme.

Chapitre 7 Déroulement du Projet 7.1 Les étapes du projet initiales Notre projet a été découpé en plusieurs étapes principales pour nous permettre de réaliser deux prototypes basés sur deux modèles de traduction différents. Ces étapes sont énumérées ci-dessous. Les étapes principales du projet 1. Etat de l art 2. Regroupement des corpora 3. Charte de projet 4. Compilation des corpora en XML 5. Système de normalisation de la traduction à partir de la méthode des règles (a) Création du dictionnaire à partir des corpora chinois et anglais (b) Création du prototype de traduction pour cette méthode 6. Système de normalisation de la traduction à partir de la méthode statistique (a) Création du prototype de traduction pour cette méthode en utilisant deux outils : GIZA++ et MOSES 7. Web Service La rédaction des différents rapports (avancement, mi-parcours et final) ainsi que les réunions se font en parallèle des étapes principales définies ci-dessus 7.1. On a donc obtenu le planning initial qui se trouve en annexe 1 et 2. 35

36 Déroulement du Projet 7.2 Les étapes du projet effectives Lors du démarrage du projet, plusieurs étapes avaient été prévues. Une partie d entre elles a put être réalisée comme par exemple la normalisation des corpora, la création d un dictionnaire de SMS ou encore la réalisation des deux prototypes de traducteurs. Néanmoins, certaines phases ont du être supprimées, et d autres ont du être ajoutées. Concernant les étapes qui n ont put être réalisées, l une d entre elle concernait le Web Service. Celui-ci devait être mis en place à la fin du projet lorsque le premier prototype de traducteur allait être prêt. De même, l implémentation d une application Android était prévue aux origines du projet. Or, cette idée fut très rapidement abandonnée. L abandon de ces étapes fut justifié par le fait que de nouvelles parties devaient être ajoutées au projet, et que le temps allait manquer. Parmi ces nouvelles parties, on trouve notamment l évaluation des différentes traductions et la mise en place de règles d associations. L évaluation a été envisagée pour deux raisons. Elle allait permettre de mesurer la qualité des traductions proposées, mais également de voir quel était le coefficient le plus adéquat pour notre système afin de l optimiser d avantage. Par ailleurs, le travail réalisé sur les règles d associations va permettre de pouvoir optimiser d avantage la traduction utilisant un modèle basée sur des statistiques. Néanmoins, ce travail n est pas terminé. En effet, des enseignants chercheurs de l université vont prendre la suite de cette partie en établissant un nouveau modèle de traduction (les membres du groupe devaient seulement réaliser un programme créant une matrice représentant ces associations). Finalement, le projet a abouti bien que certaines parties prirent du retard du à l attente des données pour les corpora, mais aussi à cause de problèmes techniques concernant l installation et la configuration de Moses. Cependant, cela n a pas empêché le projet d être terminé dans le temps imparti avec toutes les parties de réalisées. Les parties supprimées, moins nécessaires, ont été considérées comme des perspectives. Ce qui nous a permi d obtenir le planning final qui se trouve aux annexes (3, 4, 5 et 6).

Chapitre 8 Conclusions et Perspectives Conclusions Depuis le démarrage du projet, plusieurs tâches ont été réalisées. La première a été d envoyer des demandes auprès de différents groupes de recherches ayant en leur possession des corpora. En attendant leur réception, plusieurs tâches ont été effectuées. La première a été un travail de compréhension des différentes méthodes qui allaient être utilisées (basée sur des règles et basée sur des statistiques) ainsi qu une recherche sur les modèles de traduction automatique afin de mieux comprendre leurs enjeux. La deuxième tâche concernait une étude détaillée du langage SMS pour comprendre ses caractéristiques. Enfin la dernière consistait à analyser les études déjà effectuées sur la traduction spécifique du langage SMS au langage naturel, ainsi que les applications déjà existantes permettant de réaliser cette traduction. Ensuite, les différents corpora recueillis au nombre de quatre (deux en français, un en anglais et un en chinois), ont été compilés au format XML et validés par notre DTD. Par ailleurs, plusieurs programmes et modèles ont été réalisés. Le premier programme consiste à appliquer une des méthodes étudiées (Smadja, 1996) dans le but de créer un dictionnaire SMS sous forme de base de données. Cette application est destinée à traiter les petits corpora, à savoir ceux en anglais et en chinois. De plus, un programme traducteur a été implémenté afin de pouvoir traduire des textes en langage SMS en nouveaux textes en langue naturelle. Ce programme est capable, en fonction de la langue naturelle dans laquelle serait traduit le texte, d interroger la base de données pour appliquer une traduction mot à mot (pour l anglais et le chinois). Il peut également faire appel à un programme externe (Moses) pour appliquer une traduction d avantage statistique pour la langue française. Pour pouvoir que Moses puisse produire une traduction convenable, deux modèles ont été construits. Un modèle de traduction a été réalisé avec Anymalign pour pouvoir déterminer, pour chaque mot, quelle est sa traduction la plus probable. De plus, un modèle de la langue a 37

38 Conclusions et Perspectives été construit via Moses pour pouvoir, par exemple, prendre en compte les différents aspects de la langue comme les formes conjuguées, dans le but de rendre la traduction plus réaliste. Par ailleurs, un troisième programme a été réalisé dans le but d évaluer la qualité de la traduction proposée. Il fait appel à différents coefficients (ME, PMI, Jaccard et Loglike) autre que celui principalement utilisé (le Dice). Néanmoins, à l heure où ce rapport est rédigé, toutes les évaluations n ont pas été réalisées mais le seront après la rédaction de ce document. Enfin, dans le but d optimiser la traduction basée sur un modèle statistique, un dernier programme a été réalisé afin de prendre en compte les expressions courantes de plusieurs mots. Ce programme consiste à produire, en fonction d un corpus au format XML, une représentation de ces relations d associations de mots sous forme de matrice binaire. Cette matrice sera utilisée à l avenir afin de produire des règles d associations permettant d optimiser les traductions proposées. Perspectives Pour pouvoir compléter ce projet et lui donner d autres aspects, plusieurs perspectives ont été envisagées. Tout d abord, la matrice d association précédemment citée sera utilisée afin d optimiser les traductions proposées dans le but de reconnaître d avantage des associations de mots. De plus, bien que prévu initialement, un Web Service basé sur le programme traducteur pourra être mis en place afin que le système de traduction puisse être accessible pour tous par exemple depuis des dispositifs nomades ou des sites Web. Par ailleurs, une application sous Android pourra être mise en place afin de pouvoir traduire des SMS. Cette application fera appel au Web Service mis en place qui sera chargé d effectuer les traductions via le programme traducteur. Enfin, dans le but de mesurer la qualité des traductions proposées, le programme servant à évaluer ces traductions pourra être amélioré dans le but d évaluer les traductions faisant appel cette fois au modèle basé sur les statistiques.

Chapitre 9 Lexique Corpora parallèles bilingues : Il s agit de corpora qui contiennent des textes en langue SMS et en langue naturelle. Le fait qu ils soient parallèles signifie qu il existe une relation très forte entre un texte en SMS et le même texte en langue naturelle. Dictionnaire bilingue : traduction la plus probable du langage naturel. Il s agit de la correspondance entre un mot du langage SMS avec sa Web Service : distribués (Internet,...). Il permet de faire la communication entre l application et les environnements AWK : AWK est une commande très puissante. C est un langage de programmation qui permet une recherche de chaînes et l exécution d actions sur les lignes sélectionnées d un fichier. 39

Chapitre 10 Annexes 1. Diagramme de classe du programme DictionnaireSMS 2. Diagramme de classe du programme TraducteurSMS 3. Diagramme de classe du programme EvaluateurSMS 4. Planning du projet initial (Liste des tâches) (1) 5. Planning du projet initial (Diagramme) (2) 6. Planning du projet final (Liste des tâches 1) (3) 7. Planning du projet final (Liste des tâches 2) (4) 8. Planning du projet final (Diagramme 1) (5) 9. Planning du projet final (Diagramme 2) (6) 10. Rapport d avancement 1 11. Rapport d avancement 2 12. Rapport d avancement 3 41

42 Annexes Diagramme de classe du programme DictionnaireSMS

43

44 Annexes

Diagramme de classe du programme TraducteurSMS 45

46 Annexes

47

48 Annexes

Diagramme de classe du programme EvaluateurSMS 49

50 Annexes

51 Diagramme de Gantt initial Figure 1 Planning du projet initial (Liste des tâches)

52 Annexes Figure 2 Planning du projet initial (Gantt)

53 Diagramme de Gantt final Figure 3 Planning du projet initial (Liste des tâches 1)

54 Annexes Figure 4 Planning du projet initial (Liste des tâches 2)

Figure 5 Planning du projet initial (Diagramme 1) 55

56 Annexes Figure 6 Planning du projet initial (Diagramme 2)

Rapport d avancement du projet SMS2TEXT «Traduction Automatique du langage SMS vers la langue naturelle» Période du 03/10/2011 au 21/11/2011 Membres du groupe : Emilie Lebossé et Pierre-Yves Lapersonne Tuteur : Gaël Dias Synthèse : L'avancement du projet est en bonne voie. Cependant un retard est apparu suite au temps important qu a demandé la lecture des différents documents. Ceci a impliqué un retard dans la rédaction de l état de l art. Pour pouvoir pallier à ce retard, une revue du jalon concernant la compilation des corpora devra être faite. Avancement des tâches et des jalons : Achèvements sur la période Charte de projet La tâche est terminée. La charte a été envoyée à notre tuteur et à l enseignant de gestion de projet. En cours sur la période Regroupement des différents corpora de SMS La tâche est bien avancée. Nous avons actuellement 4 corpora sur les 5 prévus. Un corpus a été acheté par l Université, nous attendons de le recevoir. Étude de l état de l art La lecture des différents documents est en bonne voie. Il nous reste actuellement un document concernant la méthode basé sur les règles. La rédaction de l état de l art est en cours. Actuellement, la première partie de celle-ci est terminée ainsi que la sous-partie Les caractéristiques du SMS de la deuxième partie. Il reste à rédiger l'explication des deux méthodes que l on souhaite utiliser (statistiques et règles) qui s effectuera en parallèle de la compilation des corpora. Compilation des corpora La création des DTD pour les XML est achevée. Il reste la validation par le tuteur pour pouvoir ensuite compiler les différents corpora. A venir sur la période suivante Compilation des corpora Création des programmes permettant de compiler les corpora au format XML à partir des DTD.

Le traitement des problèmes : Les problèmes apparus et résolus au cours de la période Un problème concernant le choix de la méthode à utiliser pour la traduction du langage SMS en langage naturel est apparu. Deux choix s offrent à nous : La méthode basée sur les règles qui ne nécessite pas forcément de corpora imposants. La méthode basée sur les statistiques qui est très performante si les corpora sont consistants. La solution choisie est d utiliser les deux méthodes. La première pour les petits corpora (anglais et chinois) et la deuxième pour les gros corpora (français). Les problèmes apparus et non résolus au cours de la période Le regroupement des corpora a pris beaucoup de temps car les sources sont peu disponibles. Nous pensons donc (les membres du groupe) demander à notre tuteur s il est possible d allonger le temps pour pouvoir les traiter et les compiler. 21/11/2011 04/12/2011 Récapitulatif des actions : En cours Gaël D., Valider les DTD, échéance prochaine réunion ou par mail Emilie L., Compiler le corpus Chinois, échéance 04/12/2011 Pierre-Yves L., Compiler le corpus Anglais et le corpus Français (DELIC), échéance 04/12/2011 Emilie L. et Pierre-Yves L., Lire le document «Translating Collocations for Bilingual Lexicons : A Statistical Approach» Emilie L. et Pierre-Yves L., Rédiger la partie sur la méthode basée sur les règles et la méthode basée sur les statistiques Emilie L., Modifier le planning OpenProj du projet, échéance 28/11/2011 Achevée Gaël D., Regrouper les différents corpora auprès des différents interlocuteurs contactés Gaël D., Contacter les différentes personnes susceptibles de nous fournir des corpora de SMS Gaël D., Rechercher et fournir des documents de thèses ou d études correspondant à notre sujet Emilie L. et Pierre-Yves L., Rédiger la charte de projet Pierre-Yves L., Rédiger un résumé pour chaque document Emilie L. et Pierre-Yves L., Rédiger l état de l art : Partie 1 et sous partie Les caractéristiques du SMS de la partie 2 Emilie L. et Pierre-Yves L., Création des DTD Abandonnée Aucune action n a été abandonnée

Rapport d avancement du projet SMS2TEXT «Traduction Automatique du langage SMS vers la langue naturelle» Période du 22/11/2011 au 16/01/2012 Membres du groupe : Emilie Lebossé et Pierre-Yves Lapersonne Tuteur : Gaël Dias Synthèse : Le projet avance bien. Les différents problèmes qui ont été rencontrés n ont pas retardé l avancement du projet. Ceci est dû à une bonne réactivité du groupe face à ces imprévus. Les prochains jalons seront normalement respectés. Avancement des tâches et des jalons : Achèvements sur la période Regroupement des différents corpora de SMS Les cinq corpora prévus ont été récupérés. Étude de l état de l art La lecture des différents documents de recherches et d études est achevée. D autres documents seront peut être à lire selon les besoins du projet. La rédaction de l état de l art est terminée. Un approfondissement est envisageable lorsque nous entamerons la deuxième partie du projet concernant le deuxième prototype (basé sur les statistiques). Compilation des corpora La DTD pour les XML a été créée et validée par notre tuteur. Les différents corpora (français, anglais, chinois) ont été compilés. Rapport de mi-parcours Le rapport de mi-parcours a été rédigé et envoyé le 15/12 à notre tuteur ainsi qu à l enseignante Françoise Lambert. Dictionnaire Les grandes étapes (création du parser, calcul du Dice, et enregistrement des données dans la base) du dictionnaire ont été achevées. En cours sur la période Dictionnaire Il reste cependant à appliquer les règles sur les données enregistrées dans la base de données. C est en bonne voie et ne devrait nécessiter que quelques jours. Prototype pour le modèle basé sur les règles Il est en cours de réalisation en parallèle des dernières tâches à effectuer sur le dictionnaire pour ne pas perdre de temps. Cette tâche est en bonne voie. Elle ne devrait pas engendrer de retard.

A venir sur la période suivante Prototype pour le modèle basé sur les règles Ce prototype devra être terminé et livré au tuteur. Prototype pour le modèle basé sur les statistiques Une phase d analyse des outils GIZA++ et MOSES devra être réalisée avant de commencer le développement du deuxième prototype. Ce prototype devra être terminé et livré au tuteur. Web Service Le Web Service devra être mis en place pour proposer les deux prototypes. Rapport de projet Le rapport devra être rédigé et livré comme indiqué dans le planning. Le traitement des problèmes : Les problèmes résolus au cours de la période Le regroupement des corpora a pris beaucoup de temps car les sources étaient peu disponibles et l envoi de ces documents fut plus long que prévu. Nous avons donc repoussé la date où les corpora devaient être compilés. Elle était planifiée au 21/11/2011 et a été repoussée au 04/12/2011. Ceci n engendre pas de problème pour la suite car une marge de temps avait été prévue à cet effet. Le calcul du Dice a posé quelques problèmes pour certains cas particuliers. Ce calcul doit donner un résultat compris entre 0 et 1, ce qui n était pas le cas parfois. Le problème a été rapidement identifié et a été corrigé. Les problèmes en cours sur la période Aucun problème sur la période en cours. Récapitulatif des actions : En cours Emilie L., Appliquer les règles sur les données enregistrées dans la base de données, échéance 18/01/2012 Achevée Pierre-Yves L., Régler le problème sur le calcul du Dice, échéance 18/01/12 Gaël D., Validation de la DTD Abandonnée Aucune action n a été abandonnée