Projet Cortina

Cortina est un projet de recherche du Département Informatique, Systèmes et Collaboration (ISC) au sein du CRP – Gabriel Lippmann dont le but était la réalisation d’un correcteur orthographique informatique appliquée à la langue luxembourgeoise.

Historique du projet

Le 5 janvier 1998 a été créé, par règlement ministériel, un « conseil permanent de la langue luxembourgeoise ». Le conseil permanent, observatoire de la langue luxembourgeoise, a pour missions l’étude, la description et la diffusion de la langue luxembourgeoise. ll coordonne les travaux des différents groupes de travail, chargés par le Gouvernement de l’élaboration de nouveaux dictionnaires du luxembourgeois ainsi que de toutes mesures pouvant aider à mieux faire connaître la langue. Les différents groupes de travail sont :

  • un groupe de travail chargé de suivre l’évolution de la langue luxembourgeoise et notamment de fixer une orthographe simplifiée du luxembourgeois ;
  • un groupe de travail chargé d’élaborer un dictionnaire pratique du luxembourgeois en un volume ;
  • un groupe de travail chargé d’élaborer une nouvelle version de l’ancien « Luxemburger Wörterbuch » ;
  • un groupe de travail chargé d’élaborer un dictionnaire plurilingue du luxembourgeois.

Afin de consolider le statut de langue écrite du luxembourgeois, le CPLL envisage de réaliser une série d’outils informatiques permettant de traiter le Luxembourgeois sur ordinateur.

Dans un premier temps, le CPLL souhaiterait développer un programme de correction orthographique pouvant être intégré dans des outils de traitement de texte divers. Le CPLL s’est adressé au CRP – Gabriel Lippmann pour lui confier l’implémentation informatique de ce correcteur. Dans la mesure où la cellule CREDI du CRP – Gabriel Lippmann a déjà mené avec succès des projets dans le domaine de la linguistique informatique (projets DOHM, ANTHEM et APOLLO), celle-ci a accepté cette mission.

Ces travaux sont financés par deux ministères :

  • le Ministère de la Culture, de l’Enseignement Supérieur et de la Recherche et
  • le Ministère de l’Education Nationale, de la Formation Professionnelle et des Sports

Fonctionnalités

Le but du projet CORTINA est de réaliser un prototype de correcteur orthographique pour la langue luxembourgeoise. Dans un premier temps, notre objectif est d’implanter un correcteur offrant certaines fonctionnalités de base. Ces fonctionnalités se résument comme suit :

  • Le correcteur orthographique doit pouvoir vérifier l’orthographe de mots hors de tout contexte syntaxique, sémantique ou pragmatique et indiquer si les mots sont correctement orthographiés ou non.
  • Si un mot est mal orthographié, le correcteur doit pouvoir proposer des alternatives « raisonnables ».
  • Le correcteur doit pouvoir détecter les débuts de phrases afin de vérifier si le premier mot d’une phrase commence avec une majuscule.
  • Le correcteur doit pouvoir vérifier l’application pertinente de la « Äifeler Regel ».

Vérification de l’orthographe

Pour vérifier l’orthographe des mots, le correcteur dispose d’une liste de mots appelée « dictionnaire ». Ce dictionnaire contient toutes les formes fléchies des mots. Plus spécifiquement, on y retrouve :

  • les substantifs au singulier et au pluriel (par exemple « Fra » et « Fraen ») ;
  • les verbes fléchis à toutes les personnes du singulier et du pluriel dans les différents temps (par exemple « iess », « iessen », « giess » etc.) ;
  • les adjectifs accordés au genre (par exemple « schéin », « schéint » etc.).

Un mot est considéré comme étant correctement orthographié s’il appartient au dictionnaire. S’il n’y appartient pas, il est considéré comme étant mal orthographié. Dans ce dernier cas, le correcteur propose (si possible) des alternatives au mot mal orthographié.

Proposition d’alternatives

Pour proposer des alternatives lorsqu’un mot est mal orthographié, le correcteur doit sélectionner, dans le dictionnaire, une liste de mots « proches » du mot mal orthographié. Cette liste est construite comme suit :

  1. Le correcteur orthographique calcule une « distance » entre les mots du dictionnaire et le mot mal orthographié.
  2. Les mots du dictionnaire dont la distance au mot mal orthographié est en dessous d’un « seuil acceptable », sont sélectionnés.
  3. Les « quelques premiers » mots de la sélection, dans l’ordre croissant des distances, sont considérés comme alternatives « raisonnables ».

Distance entre deux mots

Le calcul de la distance fait appel à une fonction lcs, fournissant, pour deux mots, la sous-séquence la plus longue (des informations supplémentaires sur le problème de la sous-séquence la plus longue sont disponibles).

Soient m1 et m2 deux mots, un mot étant une séquence de caractères :

lcs(m1, m2) = séquence de caractères la plus longue qui est à la fois une sous-séquence de m1 et une sous-séquence de m2.

Soit m une séquence de caractères :

l(m) = nombre de caractères de la séquence m.

Soient m1 et m2 deux mots, nous définissons la distance entre ces deux mots comme suit :

distance(m1, m2) = (l(m1) – l(lcs(m1, m2))) + (l(m2) – l(lcs(m1, m2)))

De manière plus prosaïque, la distance exprime le nombre de caractères qu’il faut enlever de m1 et ajouter ensuite pour obtenir m2 (ou inversement, qu’il faut enlever de m2 et ajouter ensuite pour obtenir m1).

Seuil d’acceptabilité

Pour qu’un mot du dictionnaire puisse être sélectionné comme alternative potentielle à un mot mal orthographié, sa distance à ce dernier ne doit pas dépasser un certain seuil.

Soit m le mot mal orthographié et c une constante déterminée empiriquement, nous définissons le seuil d’acceptabilité comme suit :

seuil = min(c, l(m) + 1)

Sélection d’alternatives raisonnables

Les mots qui sont finalement sélectionnés comme alternatives sont ceux qui se trouvent à la distance la plus faible du mot mal orthographié.

Soit li la liste des mots du dictionnaire dont la distance au mot mal orthographié est inférieure au seuil d’acceptabilité (la liste étant triée dans l’ordre croissant des distances), et t(li) le nombre de mots de cette liste. Soit c une constante déterminée empriquement, le nombre n des premiers mots de li qui seront retenus comme alternatives au mot mal orthographié est défini comme suit :

n = min(c, t(li))

Optimisations

Afin d’accélérer les calculs, le correcteur procède à quelques optimisations. Ces optimisations sont de deux types :

  • Optimisation par normalisation.
  • Optimisation par réduction.

Optimisation par normalisation

La forme « normalisée » d’un mot s’obtient en transformant toutes les lettres du mot en minuscules et en supprimant tous les accents. Ainsi, par exemple, la forme normalisée du mot « Méiglechkeet » est « meiglechkeet ».

Pour procéder à des optimisations par normalisation, le correcteur orthographique gère, à côté du dictionnaire mentionné ci-dessus, un dictionnaire dit « normalisé ». Le dictionnaire normalisé est un dictionnaire qui nous permet de connaître, pour une forme normalisée donnée, tous les mots du dictionnaire partageant cette forme normalisée.

Soit m un mot :

norm(m) = forme normalisée de m.

Grâce à cette forme normalisé, nous pouvons redéfinir la distance entre deux mots dans certains cas particuliers. Soit m1 le mot à vérifier et m2 un mot du dictionnaire :

Si norm(m1) = norm(m2) alors distance(m1, m2) = 0

Comme le dictionnaire normalisé, pour un mot à vérifier, peut fournir au correcteur la liste de tous les mots qui ont la même forme normalisée, le correcteur n’a plus besoin de calculer la distance de ces mots au mot à vérifier, la distance étant donnée par définition.

L’idée centrale de ce procédé consiste à considérer des mots, qui ne diffèrent du mot à vérifier que par les accents et le caractère majuscule ou minuscule de la première lettre, comme des alternatives de premier choix au mot à vérifier si ce dernier n’est pas retrouvé dans le dictionnaire.

Optimisation par réduction

Une deuxième façon d’optimiser les calculs consiste à réduire l’ensemble des mots dont on calcule la distance au mot à vérifier.

Soit m1 le mot mal orthographié, m2 un mot du dictionnaire et c une constante déterminée empiriquement. Le correcteur ne calcule la distance entre les mots m1 et m2 que si :

| l(m1) – l(m2) | < min(c, l(m1)/2)

L’idée centrale de ce procédé consiste à considérer qu’il est intutile de calculer la distance entre le mot à vérifier et un mot du dictionnaire si la différence de taille entre les deux mots dépasse un certain seuil.

Majuscules en début de phrase

Le correcteur orthographique traite également les débuts de phrase. Lorsqu’il détecte un point devant un mot à corriger, il vérifie si le mot qui précède le point appartient à une liste d’abréviations.

S’il s’agit d’une abréviation, le mot à corriger est traité comme tous les autres mots.

S’il ne s’agit pas d’une abréviation, le mot à corriger se trouve donc en début de phrase et le correcteur procède de la manière suivante pour la vérification :

Si le mot à vérifier commence avec une lettre majuscule et se trouve dans le dictionnaire, il est considéré comme étant correctement orthographié. Si le mot commence avec une lettre majuscule mais ne se trouve pas dans le dictionnaire, le correcteur vérifie si l’équivalent minuscule du mot se trouve dans le dictionnaire. Si oui, le mot est consid&eacuteré comme étant correctement orthographié. Sinon, le correcteur calcule des alternatives au mot selon la méthode décrite ci-dessus, en prenant soin de remplacer la première lettre de chaque alternative par son équivalent majuscule.

Si le mot à vérifier ne commence pas avec une lettre majuscule mais se trouve dans le dictionnaire, le correcteur propose comme unique alternative l’équivalent majuscule du mot. Si le mot ne commence pas avec une lettre majuscule et ne se trouve pas dans le dictionnaire, le correcteur vérifie si l’équivalent majuscule du mot appartient au dictionnaire. Si oui, le correcteur propose ce mot comme unique alternative. Sinon, il calcule des alternatives selon la méthode décrite ci-dessus, en prenant soin de remplacer la première lettre de chaque alternative avec son équivalent majuscule.

« Äifeler Regel »

Les dernières versions du correcteur tiennent compte de « l’Äifeler Regel ». Vous pouvez trouver des informations supplémentaires dans l’article Wikipedia.

L’architecture

Choix fondamentaux

Deux objectifs ont fortement orientés nos choix techniques :

  • Dans la mesure du possible, le correcteur orthographique devait être indépendant d’une plateforme système particulière.
  • Dans la mesure du possible, le correcteur orthographique devait pouvoir s’intégrer dans n’importe quel outil de traitement de texte.

A priori, ces deux objectifs semblent difficilement conciliables. En effet, pour pouvoir intégrer le correcteur orthographique dans des applications existantes, on peut, de manière générale, être amené à recourir à des technologies propriétaires et, par conséquent, spécifiques à une plateforme donnée.

Imaginons qu’on souhaiterait, sans autre objectif, implémenter un correcteur orthographique devant s’intégrer au traitement de texte « Word » de la société Microsoft. La solution la plus simple consisterait à étendre ce logiciel bureautique au moyen d’une macro écrite en VBA (VisualBasic for Applications). On aurait alors réalisé une solution dépendant d’une plateforme particulière, dans la mesure où VBA est un langage de programmation propriétaire, disponible sur les systèmes Windows exclusivement.

De ce fait, l’approche ébauchée ci-dessus était exclue d’office.

Pour répondre au premier objectif, nous avons décidé d’implémenter l’essentiel du correcteur orthographique en Java. Le langage de programmation Java a atteint un degré de maturité tel que rien ne s’oppose à son utilisation dans des projets d’envergure. Comme, par conception, le langage Java est indépendant d’une architecture matérielle et d’une plateforme système particulières, la portabilité de la plus grande partie du correcteur était garantie.

Néanmoins, afin de pouvoir intégrer le correcteur orthographique dans des outils existants (Word, StarOffice etc.), certaines parties ont dû être implémentées au moyen de langages propriétaires (VisualBasic, StarBasic, etc.). De manière à minimiser l’effort de portage (nécessaire pour intégrer le correcteur dans un nouvel outil), cette partie du correcteur devait être réduite au maximum.

Architecture client/serveur

Le problème qu’il faillait ensuite résoudre consistait à faire communiquer la partie la plus importante du correcteur, écrite en Java, avec la partie intégrée à l’application hôte, écrite dans un autre langage de programmation.

Ici encore, notre souci était d’être liés le moins possible à une plateforme spécifique. Afin de garder une flexibilité maximale, nous avons décidé de nous orienter vers une solution client/serveur, le client et le serveur communiquant au moyen de « sockets ». En effet, le mécanisme de communication inter-processus des « sockets » est un mécanisme qui est disponible pratiquement sur tous les systèmes et peut être utilisé à partir de n’importe quel langage de programmation. Qui plus est, ce mécanisme permet de distribuer les processus communiquant à travers un réseau informatique, ajoutant encore à la flexibilité.

Fin du projet

Le projet CORTINA s’est terminé en septembre 2002, l’objectif était de pouvoir corriger du luxembourgeois en ligne ou sur un traitement de texte. Il n’est désormais plus disponible en ligne.

Pour aller plus loin : article source à lire sur https://web.archive.org/web/20140420193019/http://cortina.lippmann.lu/site/