Sommaire
Ce qui a été fait
Séparation du correcteur d’avec Hunspell et LibreOffice
C’était le prérequis à l’indépendance du logiciel, et c’est la première chose qui a été faite. Au lieu de consulter Hunspell, le correcteur orthographique, pour connaître l’étiquetage grammatical des mots, Grammalecte interroge dorénavant son propre dictionnaire indexable. Il s’agit d’un graphe de mots contenant toutes les formes graphiques que peuvent avoir les mots français : les pluriels, les formes féminines et masculines, et les conjugaisons.
Le graphe contient 500 966 entrées, avec 140 caractères différents, 901 codes de suffixation, 6 066 étiquettes grammaticales, et est composé de 110 796 nœuds et 236 744 arcs (liens qui vont d’un nœud à un autre). Tout ça est compressé sous forme d’un dictionnaire binaire indexable pesant environ 1,25 Mio (le fichier texte non compressé pèse environ 18,6 Mio). Mais le principal avantage de ce dernier n’est pas sa petite taille, c’est qu’on peut le parcourir très rapidement et l’interroger sans avoir à le décompresser. Il peut fournir deux sortes d’informations : un mot est‐il présent dans le dictionnaire et, si oui, quelle est sa nature grammaticale.
Grâce à cela, Grammalecte peut fonctionner de manière autonome.
Extension pour Firefox & Thunderbird
Le correcteur a été entièrement réécrit en JavaScript avec une interface pour Firefox, qui s’appuie principalement sur l’API SDK de haut niveau et quelques fonctionnalités de bas niveau. L’interface est faite en HTML/CSS.
L’API de Thunderbird étant complètement différente de celle de Firefox, cette extension est une autre réécriture en JavaScript de l’extension, hormis le cœur du moteur grammatical, bien sûr. L’interface est bâtie avec l’ancienne technologie XUL encore en vigueur sur Thunderbird. La documentation concernant Thunderbird étant en partie tombée en déshérence (liens cassés, pages manquantes, sections disparues, sites Web à l’abandon ou évaporés), j’ai parfois fait emploi de techniques trouvées dans d’autres extensions, mais ça ne concerne qu’une minorité de problèmes, et je me suis contenté autant que possible de suivre ce qui était documenté. Le fonctionnement de l’extension est assez similaire à celle pour Firefox. Votre texte est analysé dans un panneau annexe. En revanche, contrairement à Firefox, les erreurs sont listées en dessous du paragraphe analysé. Hormis cela, tout est relativement semblable, sauf l’allure générale de l’extension, qui fait plus vieux jeu, parce que XUL est d’une conception plus ancienne.
La mauvaise nouvelle, pour Firefox, c’est qu’il faudrait déjà refaire l’interface. Quand j’ai commencé le codage de l’extension, Mozilla préparait une nouvelle API pour les extensions, appelée WebExtension, qui était alors en version alpha. C’est la quatrième API pour Firefox, les trois autres étant XUL, Bootstrapped et le SDK (haut niveau et bas niveau). Il était dit que ces trois API deviendraient obsolètes d’ici quelques années, sauf le SDK de haut niveau, et qu’il fallait utiliser ça en attendant que l’API WebExtension fût finalisée. C’est donc ce que j’ai fait. Grammalecte pour Firefox est sorti à peu près au même moment que WebExtension. Quelques mois plus tard, les trois autres API ont été déclarées obsolètes, y compris le SDK de haut niveau, contrairement à ce qui avait été annoncé, et toutes les trois seront supprimées en novembre prochain avec Firefox 57.
C’est vraiment très irritant, mais l’on n’y peut pas grand‐chose. Ceci découle probablement de la volonté de Mozilla de réécrire tout le cœur de Firefox. Ce qui n’apporte pas que de mauvaises choses, puisque, par exemple, j’ai constaté que le correcteur grammatical fonctionnait plus de deux fois plus vite à partir de Firefox 55…
Le cœur de l’extension, le moteur grammatical, n’est pas à reprogrammer, il ne s’agit « que » de l’enrobage, l’interfaçage… J’ignore si ça réclamera beaucoup de travail, je ne m’y suis pas encore intéressé. L’un des autres soucis, c’est que même si WebExtension est dorénavant le modèle d’extensions conseillé, il semble qu’il ne permette pas encore autant de choses que les API précédentes. Cette API est toujours en développement, Mozilla travaillant encore à étendre les possibilités offertes.
En ce qui concerne Thunderbird, je n’ai rien vu passer… et j’ignore si nous sommes à la veille d’une révolution surprise qui va tout casser.
Mozilla n’a pas encore vérifié le code de l’extension pour Thunderbird : la liste d’attente est très longue. Heureusement, contrairement à Firefox il est possible d’installer une extension non vérifiée et non signée. Il n’y a aucun risque de confidentialité. Le correcteur n’envoie aucune donnée en ligne, absolument rien. Ce que vous écrivez n’est pas transmis, tout se passe sur votre ordinateur.
Pour ceux que ça intéresse de tester, je viens de publier la version 0.5.17 :
-
pour Firefox (il faut un Firefox capable d’installer les extensions non signées) ;
-
pour Thunderbird (Thunderbird peut installer les extensions non signées).
Captures d’écran
Boîtes de dialogue « À propos » :
Correcteur grammatical :
Conjugueur :
Formateur de texte :
Options grammaticales et orthographiques :
Interface en ligne de commande :
Révision du moteur interne du correcteur
Désambiguïsation
Dans la précédente dépêche, je vous avais expliqué que Grammalecte ne possédait pas de processus de désambiguïsation permettant d’étiqueter les mots en fonction du contexte. Par exemple, un mot comme « porte » peut être un verbe ou un nom féminin, et il est utile, lors de l’analyse d’une phrase, d’avoir procédé si possible à la désambiguïsation de sa nature grammaticale, afin que les règles de contrôle n’aient pas à se poser la question à chaque fois.
Comme expliqué lors de la campagne de financement précédente, Grammalecte intègre désormais des fonctions de désambiguïsation capables d’étiqueter et baliser le texte. Ce désambiguïsateur fonctionne d’une manière similaire aux règles de contrôle et au processeur de texte. Une expression rationnelle déclenche une action de désambiguïsation si elle remplit la condition requise, de sorte que toutes les règles suivantes bénéficient d’un étiquetage plus précis. Il y a trois types d’actions de désambiguïsation : la sélection (qui ne retient que les étiquettes conformes à une expression rationnelle), le filtre (qui supprime les étiquettes grammaticales non conformes), l’étiquetage (qui impose une ou plusieurs étiquettes, quelles que soient celles que le mot possède alors).
Règles multi‐actions
Dans le précédent billet, je vous avais expliqué que Grammalecte fonctionnait selon une succession de passes, dont chacune était précédée d’une transformation du texte par ce que j’appelais le « préprocesseur de texte ». Ce qui permettait de simplifier peu à peu le texte pour faciliter le contrôle des règles grammaticales qui suivaient.
Pour simplifier, cela fonctionnait ainsi :
- Passe 1 (paragraphe par paragraphe) :
- règles du préprocesseur de texte ;
- règles de contrôle.
- Passe 2 (phrase par phrase) :
- règles du préprocesseur de texte ;
- règles de contrôle.
- Passe 3 (phrase par phrase) :
- règles du préprocesseur de texte ;
- règles de contrôle.
- etc.
Dans ce système, chaque règle ne pouvait faire qu’une seule chose (comme dans LanguageTool), et seulement si la condition qui contrôlait sa mise en œuvre était remplie.
Peu de temps après le début de la campagne de financement, il m’est apparu qu’il serait souhaitable de rendre plus souple ce fonctionnement. Il n’était pas prévu au programme de toucher à cela, mais j’ai préféré m’atteler tout de suite à cette tâche plutôt que de regretter plus tard de ne pas l’avoir fait. Donc, à présent, au lieu d’une succession de passes alternant transformation du texte et contrôle de la grammaire, nous sommes revenus à simplement deux passes (une pour le contrôle du paragraphe, une pour le contrôle des phrases), mais chaque règle peut dorénavant tout faire et peut accomplir autant d’actions qu’on le souhaite, chaque action se déclenchant si la condition qui y est attachée est remplie.
Donc, une règle peut dorénavant opérer plusieurs actions de contrôle, plusieurs actions de réécriture et plusieurs actions de désambiguïsation.
Au commencement, je pensais que cette modification du fonctionnement n’aurait que peu de conséquences, car elle n’était pensée que pour me faciliter la tâche dans certains cas épineux, puis il m’est apparu que ça changeait en fait de si nombreuses choses que la transition de l’ancien modèle vers le nouveau n’est toujours pas achevée à ce jour. Ça n’a pas d’importance puisque ça fonctionne aussi bien qu’auparavant, mais la souplesse de ce fonctionnement apporte tellement d’avantages que je suis loin d’en avoir profité encore pleinement.
Cela dit, depuis que Grammalecte fonctionne ainsi, des dizaines de règles complexes ont déjà été fusionnées, et cela a simplifié grandement le déroulement de nombreuses opérations.
Prenons un exemple simple. Auparavant, si vous écriviez « les ordinateur », il fallait deux règles de contrôle pour souligner « les » et suggérer « le », et souligner « ordinateur » et suggérer « ordinateurs ». À présent, une seule règle permet de faire les deux choses d’un coup.
Autre exemple. Mettons que nous rencontrons la graphie « militant(e)s ». Une même règle va permettre de faire trois choses :
- suggérer d’écrire ceci autrement (« militants et militantes », « militantes et militants », « militant·e·s ») ;
- étiqueter ce mot inexistant dans le dictionnaire comme « nom ou adjectif épicène pluriel » ;
- réécrire le mot en interne pour ôter les parenthèses gênantes.
Détection des erreurs
De nombreuses règles de contrôle ont été ajoutées… notamment concernant la détection de confusions concernant les mots grammaticaux. La dernière version du correcteur (v0.5.17) contient 21 actions de désambiguïsation, 687 actions du processeur de texte, 1 437 actions de contrôle ; ces actions sont réparties dans 1 939 règles.
À titre de comparatif, la version 0.4.10, qui suivait l’ancienne logique, contenait 540 règles de transformation de texte et 933 règles de contrôle, chacune n’effectuant qu’une seule action.
Ces chiffres ne sont pas nécessairement très évocateurs, parce que rien ne comptabilise les modifications du fonctionnement des règles qui sont les plus nombreuses, ne serait‐ce, par exemple, que sur les méthodes pour faire des suggestions.
En fait, le potentiel du correcteur est encore sous‐exploité, malgré les innombrables améliorations apportées ici et là. Je n’avais pas assez insisté sur ce point lors du dernier journal, alors je vais le répéter encore une fois : les détails sont ce qui réclame le plus de temps, car il faut songer que les possibilités d’erreurs avoisinent l’infini et que les possibilités de faire des faux positifs sont aussi nombreuses. Dans les faits, améliorer le correcteur grammatical, c’est s’occuper sans cesse de micro‐problématiques. Je réécris ici ce que j’ai dit la dernière fois : « Écrire des règles, c’est assez rapide ; détecter les faux positifs, c’est beaucoup plus long ; ceux‐ci ont tendance à survenir là où l’on s’y attend le moins. C’est ce qui est le plus exigeant : maintenir un ensemble de règles, améliorer l’existant, tester, trouver de nouvelles possibilités. Lorsqu’on s’occupe d’un correcteur grammatical, on passe surtout son temps à peaufiner des détails, à ajuster le fonctionnement de l’existant, à arrondir les angles. Oubliez l’idée de concevoir l’algorithme ultime qui saura gérer tous les cas. Même quand on est à peu près sûr d’écrire une petite règle tranquille qui ne générera aucun faux positif, la réalité va très probablement nous rappeler à l’ordre et nous obliger à slalomer sur ce qui paraissait au commencement comme une belle ligne droite. S’occuper de correction grammaticale, c’est marcher sur un chemin pavé d’embûches subtiles. »
C’est pourquoi l’évolution du correcteur se fait pas à pas, en évitant autant que possible les modifications radicales.
Le correcteur fonctionne beaucoup mieux depuis que toutes ces améliorations ont été faites, et j’espère que c’est sensible pour vous, car il m’est difficile de juger si ces améliorations sont visibles pour les utilisateurs.
Parmi toutes les nouveautés apportées, il y a notamment :
- beaucoup de règles pour détecter des confusions entre les mots homonymes (comme ce, se et ceux) ;
- beaucoup d’améliorations pour gérer les cas particuliers, clarifier le texte interne et augmenter le taux de détection ;
- toujours moins de faux positifs ;
- une option pour détecter les erreurs de reconnaissance optique de caractères bien plus développée (désactivée par défaut) ;
- beaucoup de règles de contrôle ont été améliorées.
Le moteur de suggestions
L’amélioration des suggestions est l’un des points qui ont le plus progressé depuis le précédent journal, grâce aux règles multi‐actions qui ont permis de rendre plus systématiques la possibilité de faire deux suggestions différentes lors de la constatation d’un désaccord de genre, de nombre ou de conjugaison ; mais aussi surtout grâce à la création d’une table de correspondance phonétique à partir de laquelle Grammalecte peut choisir des mots à suggérer en fonction de leur nature grammaticale.
La table de correspondance phonétique est un simple fichier qu’il est facile de compléter, c’est une succession de mots homonymes, comme :
- appareil, appareils, appareille, appareilles, appareillent ;
- mec, mecs, Mecque ;
- pouce, pouces, pousse, pousses, poussent ;
- tête, têtes, tète, tètes, tètent.
À partir de cette liste, Grammalecte construit un mini‐dictionnaire avec toutes les natures grammaticales possibles de chaque mot. Puis, au besoin, on peut demander, par exemple, de trouver un mot semblable à « tète » en spécifiant les natures grammaticales acceptables (via une expression rationnelle). Il y a aussi quelques propositions de substitutions automatisées, pas toujours opportunes, ce point reste à améliorer.
Si ça vous intéresse, cette table est consultable ici.
Cette table phonétique ne résout pas tous les problèmes, mais permet dans bien des cas de faire des suggestions de mots sans rapport grammatical avec le terme erroné. Avant cela, le correcteur se contentait de signaler l’erreur, mais ne pouvait rien suggérer. Quelques exemples :
- « Il appareil demain. » → appareille ;
- « La mec. » → Le | Mecque ;
- « Une goulet » → Un | goulée ;
- « Il pouce le bouchon trop loin. » → pousse ;
- « J’en ai marre de ces tètes de nœud. → têtes ;
- « Ils ne son pas idiot. » → sont.
Notez que le moteur de suggestions ne propose des mots ayant une autre racine que lorsqu’il constate une anomalie (si un verbe prend la place de ce qui devrait être un nom, par exemple) ou s’il constate une erreur de genre. S’il y a seulement une erreur de pluriel, il se contente de faire une correction de nombre. Mais il serait aussi possible dans ces cas‐là de suggérer des mots différents. Par exemple « Des homme » → hommes | ohms | heaumes.
Ça m’a semblé superflu de proposer de telles corrections, mais si vous jugez ça utile, dites‐le‐moi.
Modifications diverses
- l’écriture des règles a été modifiée, il est plus aisé de gérer la casse et les marges des motifs des expressions rationnelles ;
- les règles sont regroupées par option, afin de pouvoir ajouter des règles optionnelles sans gréver les performances (l’option de reconnaissance optique de caractères, par exemple) ;
- il est possible d’utiliser pour chaque action des opérateurs logiques (
__also__ et __else__) pour écrire des conditions tenant compte du résultat de la condition de l’action précédente ;
- toutes les règles ont été nommées, afin de satisfaire aux nécessités du greffon pour Vim (désactivation paramétrable de règles spécifiques) ;
- tout le processus de construction a été revu et des tests ont été intégrés pour éviter certaines erreurs d’écriture des règles ;
- des marque‐pages pour s’y retrouver dans la liste des règles, qui commence à devenir très, très longue (fonctionnalité ajoutée hier).
Capture d’écran
Voici à quoi ressemble le fichier des règles (sous SublimeText) :
Tests unitaires
Auparavant, la situation sur ce point était très mauvaise, puisqu’il n’y avait aucun test unitaire sur le correcteur, seulement des tests « manuels », c’est‐à‐dire un fichier texte que j’ouvrais de temps en temps avec Writer pour vérifier que le moteur fonctionnait comme prévu. Mais c’était loin d’être exhaustif et facile à mettre en œuvre, puisque je vérifiais « à l’œil » si à chaque ligne le correcteur trouvait bien l’erreur qu’il était censé trouver. Pénible et lent au possible.
À présent, à chaque modification, il est possible lors de la construction de tester si rien n’est cassé. Plus de 6 200 tests sont lancés (dont 2 000 repris chez LanguageTool), et chaque règle de détection doit être testée au moins une fois.
Malgré cela, les tests ne sont pas encore exhaustifs (à bien y songer, il n’est sans doute pas possible d’être exhaustif), mais la situation s’améliore indubitablement, et peu à peu le socle du correcteur devient de plus en plus solide. Grâce à cela, de nombreuses erreurs dans le fonctionnement du correcteur ont été détectées et corrigées.
Beaucoup de ces tests sont là pour vérifier qu’une règle fonctionne correctement, mais une grande partie d’entre eux existent pour éviter les faux positifs constatés lors des versions précédentes. Ce sont les tests les plus nombreux, parce que les faux positifs sont légion et qu’il est très fréquent d’en provoquer de nouveaux, quelle que soit la prudence avec laquelle on écrit les règles. Pour les éviter autant que possible, quelques textes courts ont été inclus dans les tests de Grammalecte :
-
Le Horla, de Guy de Maupassant ;
-
Le double assassinat dans la rue Morgue, d’Edgar Poe ;
-
Les vers dorés, de Pythagore ;
-
L’épître du feu philosophique, de Jean Pontanus.
Avoir écrit l’extension pour Firefox présente par ailleurs un avantage considérable pour consolider la correction grammaticale : c’est beaucoup plus facile de mettre le correcteur à l’épreuve. Presque tous les jours, je lance des analyses grammaticales sur de nombreux articles de journaux et de blogs divers ; ça me permet de repérer et corriger des faux positifs, ainsi que de nouveaux mots à ajouter au dictionnaire. Auparavant, je faisais des copier‐coller dans Writer, ce qui était bien moins commode et bien plus long.
Ces tests sont faits en Python et en JavaScript. Les deux moteurs les passent tous et fonctionnent de la même manière. Cela dit, il n’est pas malgré cela pas possible de garantir (pour l’instant) que le moteur en JavaScript fonctionne aussi bien qu’en Python.
JavaScript, mon amour Hiroshima
Passer de Python à JavaScript n’a pas été de tout repos. Et si le projet a pris du retard, ce n’est pas tellement, comme je le craignais, à cause de la difficulté de concevoir une extension pour Firefox et Thunderbird. Ce point fut plus facile que je ne le pensais, tout simplement parce que la documentation de Firefox et celle Thunderbird, quoique cette dernière soit en déshérence, sont mieux tenues et plus complètes que celle pour LibreOffice… et surtout l’API est plus simple à utiliser… Quoique… l’API de bas niveau est tout aussi compliquée, de mon point de vue… Mais comme on peut s’en passer… Bref.
La syntaxe de JavaScript ne m’a pas posé de problème. J’ai utilisé toutes les nouvelles possibilités offertes par la norme ES6 : for … of, les générateurs, les paramètres par défaut, les paramètres du reste, la décomposition, les fonctions fléchées, Map, Set, les classes, let et const, et même depuis peu les nouvelles commandes async et await. Avec tout ça, JavaScript est un langage pas aussi horrible que je l’avais craint, même assez agréable parfois… En même temps, comme je démarrais un projet à zéro, je n’ai pas eu à me coltiner toutes les bizarreries possibles de ce langage. J’ai évité toute forme de syntaxe tord‐neurones.
Ce qui m’a compliqué la vie, c’est plutôt l’écosystème de JavaScript, sa difficulté à déboguer, son comportement étrange, les incohérences et sa bibliothèque standard pauvre.
Difficulté à déboguer
Ni Firefox, ni Thunderbird (ni LibreOffice d’ailleurs) ne signalent quoi que ce soit s’il y a une erreur de syntaxe dans le code. Ça ne fonctionne tout simplement pas, et c’est tout. C’est assez pénible en Python, mais c’est bien pire en JavaScript où il est fréquent d’oublier une virgule ou un point-virgule quelque part. En outre, les messages d’erreur de JavaScript sont longs et souvent abscons, sans compter que selon le contexte d’exécution dans Firefox/Thunderbird, les messages d’erreur sont parfois encore plus imprécis, voire inexistants (le module XYZ plante, mais débrouillez-vous pour le reste, car aucune info ne sera fournie, comme où et pourquoi). Je ne vais pas rentrer dans les détails, parce que j’ai maintenant oublié la plupart d’entre eux… mais à mon avis, Mozilla ferait des heureux en améliorant les rapports d’erreur.
Inutile de s’étendre sur le comportement erratique de JavaScript et son typage faible, cela a déjà été fait par tellement de monde… Quand on vient de Python, il est facile de tomber dans tous les pièges que ce langage tend, dans lesquels même les plus experts chutent encore de temps en temps, j’imagine. La traque aux “undefined” semblant sortir de nulle part m’a particulièrement marqué.
La bibliothèque standard
La bibliothèque standard est, en restant poli, très mauvaise, notamment parce qu’elle est très incomplète, mais aussi assez peu cohérente, me semble‐t‐il. Dans beaucoup de cas, ce n’est pas bien grave, il suffit d’ajouter les fonctions dont on a besoin et c’est ce que j’ai fait, mais on se demande quand même pourquoi cette bibliothèque standard est si pauvre ou si mal foutue. Avec toute la hype autour de ce langage, c’est vraiment très étonnant.
Prenons le cas des expressions rationnelles, parce que la nullité de l’objet Regexp est navrante… et parce que c’est ce qui est le plus utile à Grammalecte :
problème 1 : pas de lookbehind assertions
Les lookbehind assertions permettent de regarder ce qui précède un motif. OK, c’est pénible, mais on peut compenser avec quelques efforts.
problème 2 : les classes de métacaractères ne comprennent que l’ASCII.
Les classes de métacaractères comme \w et \b, ne comprennent que l’ASCII.
Oui, l’ASCII ! Ce qui donne (vous pouvez essayer dans l’ardoise de Firefox) :
/^\w+$/.test("étonnant") ==> false
/\bvite\b/.test("évite") ==> true
Inutile de vous précipiter sur votre calendrier, nous sommes bien en 2017, et non en 1997. JavaScript est, paraît‐il, un langage moderne, mais seulement quand on n’y regarde pas de trop près.
Heureusement, il est facile de compenser l’absence d’un \w fonctionnel par [a-zA-Zà-öÀ-Ö0-9_ø-ÿØ-ßĀ-ʯ] (du moins, ce sont les plages de caractères que j’ai retenues, on pourrait en ajouter bien d’autres). Ce qui rend les expressions rationnelles un peu plus piquantes à lire…
Quant à \b, eh bien, on peut essayer de compenser avec des lookahead assertions et des lookbehind assertions. Seulement, voilà, ces dernières n’existent pas en JavaScript. Mais en magouillant, on peut simuler ça. Du moins dans presque tous les cas utiles. Tant pis pour les autres… on priera de ne pas tomber sur un caractère non ASCII.
Problème 3 : pas de position des groupes capturés
Les groupes capturés n’indiquent pas leur position. Ça, c’était vraiment la mauvaise surprise. Avant de proposer la campagne de financement, j’avais vérifié ce que JavaScript pouvait faire avec les expressions rationnelles, mais je n’avais pas vu que ce point manquait à l’appel, tout simplement parce que je n’avais pas imaginé que JavaScript serait incapable de fournir cette indication.
De quoi s’agit‐il au juste ? C’est très simple. Quand vous écrivez une expression rationnelle avec des groupes de capture, comme (\w+) (\w+) (\w+), Python vous renvoie les groupes capturés (ce qui est entre parenthèses) avec leur position dans le motif global. JavaScript ne renvoie que le contenu des groupes capturés, mais pas leur position. Débrouillez‐vous pour savoir où ça se trouve, et c’est bien plus épineux que vous pourriez le supposer, si, par exemple, vous capturez des mots comme « a », « le » ou « la », ou si vous capturez des groupes qui ne sont pas des mots entiers.
Ce point seul m’a fait perdre beaucoup de temps, sans compter que ce fut un cauchemar à déboguer. J’ai même cru pendant quelques jours que tout le projet allait tomber à l’eau à cause de ça.
Car, à ce moment du développement, alors même que je bataillais pour rendre le moteur fonctionnel, j’ai pris conscience que l’exécution du code en JavaScript était environ douze fois plus lente qu’en Python, au point que lorsqu’on lançait la correction grammaticale, Firefox se figeait pendant de longues secondes… C’était évidemment inacceptable.
Il était donc hors de question de ralentir encore l’exécution du code en essayant de calculer la bonne position des erreurs dans les motifs détectés (pour rappel, il y a des milliers d’expressions rationnelles dans Grammalecte). Du coup, j’ai oublié cette idée et procédé autrement : la position des groupes capturés est signalée dans le fichier des règles de grammaire. Cela rend le processus d’écriture des règles un peu plus brouillon, mais c’est assez simple pour être acceptable. Et ça ne ralentit pas le moteur outre mesure.
Ensuite, pour éviter que Firefox ne se fige, le cœur du correcteur grammatical, c’est‐à‐dire la vérification du texte, s’exécute dans un processus séparé… Et, bonne surprise, il s’avère que dans ce processus — inexplicablement, sans rien changer au code — le correcteur fonctionne vingt fois plus rapidement que dans le processus principal de Firefox, même quand ce dernier ne fait rien du tout !…
Un écosystème incohérent
Selon les contextes et l’application, les choses fonctionnent différemment et ça donne la désagréable impression de bâtir sur du sable. On ne sait pas toujours bien ce qui préexiste aux scripts qu’on conçoit. Notamment, il n’y a toujours pas de moyen conventionnel simple pour importer un module (ES6 en parle, mais aucun navigateur n’a encore implémenté ça).
Parfois, require existe par défaut. On peut faire :
const { Cu } = require("chrome");
const tabs = require("sdk/tabs");
Dans d’autres cas, require n’existe pas par défaut, donc :
importScripts("resource://gre/modules/workers/require.js");
const gce = require("resource://grammalecte/fr/gc_engine.js");
Ou bien encore dans un autre contexte, il faut faire :
const Cu = Components.utils;
const { require } = Cu.import("resource://gre/modules/commonjs/toolkit/require.js", {});
Parfois, on importe Components.utils (Cu) grâce à require. Parfois, on importe require à partir de Components.utils (Cu) ou bien d’autre chose.
On peut aussi importer des modules via XUL ou le HTML, avec des espaces de noms partagés. Il y a aussi les déclarations de ressources dans un manifeste. Bref, tout ça est contre‐intuitif au possible.
Cela dit, alors que j’écrivais ce texte, je découvre que import et export arrivent enfin dans les navigateurs ! On va peut‐être en finir avec tout ça bientôt.
Mais, ça résoudra pas tout. Comme je l’ai dit, selon les applications et les contextes, certains objets ou fonctions existent ou n’existent pas. Dans Firefox, on peut appeler directement XMLHttpRequest(), mais pas dans Thunderbird. Pour ce dernier, il « suffit » donc de faire :
let { Cc, Ci } = require("chrome");
let xRequest = Cc["@mozilla.org/xmlextras/xmlhttprequest;1"].createInstance();
xRequest.QueryInterface(Ci.nsIXMLHttpRequest);
Même pour faire un print, il n’y a pas de solution uniforme. Là encore, selon le contexte, il y a : console.log(), Service.console.logStringMessage() ou dump() ou que sais‐je encore. Il y a des contextes où rien de tout ça ne fonctionne.
Une dernière étrangeté : pour compenser la pauvreté des objets standard, j’ai ajouté des fonctions personnelles à String, Regexp et Map. Mais ce qui est curieux, c’est que dans Firefox, il faut que ces nouvelles fonctions soient déclarées dans le module où les objets sont instanciés… tandis que dans Thunderbird, il faut que ces nouvelles fonctions soient déclarées dans le module où ces fonctions sont utilisées. C’est pourtant le même moteur JavaScript.
J’arrête ici de lister les incohérences, on n’en finirait pas.
Chaque problème n’est pas dramatique en soi, mais l’accumulation de ces contretemps finit par rendre la programmation en JavaScript vraiment casse‐pieds par moments.
Et, là, on ne parle que de Mozilla. C’est encore différent ailleurs, puisque l’implémentation des nouvelles fonctionnalités du langage n’avance pas au même rythme selon les moteurs.
En résumé, JavaScript, c’est le bordel et on se demande pourquoi c’est si incohérent. À mon avis, ce qui manque particulièrement à ce langage, c’est une implémentation standard avec un comportement logique et uniforme, des rapports d’erreurs plus clairs et une bibliothèque par défaut mieux faite et plus complète. On perd un temps considérable avec ces histoires.
Je ne voulais pas particulièrement écrire un long chapitre sur ce langage, mais ça fait déjà pas mal…
De Writer à Firefox (ou de la littérature au Web) : le choc culturel
L’un des points auxquels je n’avais pas beaucoup réfléchi et qui m’a le plus surpris, bien que j’avais conscience que les textes du Web n’égalaient pas en qualité et normativité ceux sur lesquels j’avais travaillé sur LibreOffice, c’est combien l’écrit sur le Web est chaotique et exubérant, et foisonne de néologismes, d’anglicismes, de noms propres (compagnies, marques, produits, people), de sigles, de codes divers, de vocabulaire technique, de smileys, d’erreurs de syntaxe ou de formatage, sans compter les habituelles erreurs typographiques, orthographiques et grammaticales… Si bien que même lorsque Grammalecte commençait à fonctionner comme il le devait sur Firefox, il m’est vite apparu que c’était difficilement utilisable en l’état, et qu’il fallait revoir son fonctionnement pour éviter trop de signalements intempestifs, pour éviter que tous les textes soient barbouillés de toutes les couleurs. Pourtant, je n’avais pas fait faire les premières armes du correcteur sur les logorrhées de Facebook, mais sur des textes d’acteurs « sérieux », comme les journaux et les blogs grand public ou plus confidentiels, mais a priori bien tenus. Quelle déconvenue !… Entre le charabia, les hashtags et autres bidules, le formatage indigent et la novlangue du Web, Grammalecte tirait tout le temps la gueule, et il a fallu revoir beaucoup de choses pour que le correcteur se comporte moins comme un casse‐pieds permanent. J’ai passé un temps considérable à cette adaptation culturelle. J’ai fait passer au correcteur des centaines de textes tirés de blogs et de journaux. J’ai corrigé des tas de faux positifs et j’ai ajouté des centaines de mots dans le dictionnaire. Et beaucoup d’entre vous trouvent sans doute le correcteur encore trop rigide. À vous de me le dire, j’ai eu très peu de retour sur ce point…
Quoi qu’il en soit, pour s’acclimater à Internet, il a fallu assouplir grandement la politique d’intégration des néologismes, des anglicismes, des marques, améliorer l’analyseur lexical pour ignorer des tas de trucs. Par exemple, si l’on peut se passer du verbe « tweeter » quand on ne s’occupe que de LibreOffice, sur le Web, non, ce ne peut être compris des utilisateurs. Trop fréquent. Idem pour pas mal de marques et d’autres néologismes très courants.
Cela dit, je suis toujours réticent à ajouter trop de nouveautés et de bizarreries, les noms de produits sont toujours interdits (tant pis pour les Freebox, les iBidule, et autres gadgets dans l’air du temps…), et je me suis arrêté au moment où j’ai estimé que j’avais suffisamment assoupli les choses… Faites‐moi part de votre avis, en bien ou en mal. Il reste sans doute encore des rugosités à polir.
Lexique du correcteur
La graphie d’un mot français ne permet pas de déterminer sa nature. Un mot finissant par « -ent » peut être un nom, un adjectif, un adverbe ou la forme conjuguée d’un verbe. C’est pourquoi un correcteur grammatical ne peut souvent pas grand‐chose sans un lexique étiqueté référençant tous les mots d’une langue. Cet étiquetage, c’est la base de la connaissance du correcteur.
Ce lexique est généré à partir du dictionnaire orthographique pour Hunspell.
Quelques données sur le dictionnaire :
- plus de 82 300 entrées (+ 5 300 depuis le précédent journal) ;
- toutes les entrées sont grammaticalement étiquetées ;
- environ 20 % d’entre elles sont sémantiquement étiquetées (médecine, informatique, botanique, etc.), mais cet étiquetage ne sert pas encore.
Améliorer la base lexicale et son étiquetage, c’est l’une des tâches les plus importantes de la conception d’un correcteur grammatical. Tout le travail sur le dictionnaire se fait sur Dicollecte, où sont collectées les propositions des utilisateurs.
C’est toujours perfectible
Beaucoup de choses ont été faites, parfois plus que ce qui était demandé, parfois le strict minimum. Évidemment, beaucoup de choses sont encore améliorables, c’est le propre des projets informatiques. Un correcteur grammatical, ce n’est jamais fini.
Si j’ai oublié de mentionner quelque chose d’important, n’hésitez pas à m’en faire part.
Malheureusement pour certains, je n’ai pas réécrit le correcteur en OCaml, Haskell, Lisp, Cobol… [insérez ici votre langage à la mode favori]. Firefox et Thunderbird s’obstinent à ne comprendre que le JavaScript, LibreOffice le Python, le Basic et le Java. C’est barbare ou vintage si on est indulgent, mais c’est ainsi. :-)
Pour l’instant, attendu que Mozilla n’a toujours pas implémenté l’interface de programmation qui permettra de souligner les erreurs directement dans les zones de texte, la correction se fait dans un panneau annexe. Mais, dès que cette interface sera disponible, c’est bien sûr ainsi que les corrections se feront. Au cas où ceci intéresserait quelqu’un parmi vous, sachez qu’il existe une prime pour la réalisation de cette tâche sur Bountysource.
Il existe également une prime pour apporter la colorisation des erreurs dans LibreOffice. Idéalement, j’aimerais qu’on passe des vaguelettes bleues à peine visibles à des traits pleins, épais et colorés. Par exemple :
L’un des problèmes qui m’ennuie assez en ce moment, c’est que la validation des extensions proposées sur le site de Mozilla est devenue vraiment longue depuis le début de l’année. Les contrôleurs sont probablement submergés de nouvelles extensions à cause du passage obligatoire à WebExtension. Du coup, la version 0.5.16 n’est pas encore validée. La version 0.5.17 n’a pas encore été proposée, attendu que toute nouvelle version nous ramène en fin de liste d’attente.
L’avenir
Améliorer la correction grammaticale
Après le passage délicat que constituait la désimbrication de Grammalecte de LibreOffice, je vais dorénavant me concentrer sur l’amélioration du correcteur lui‐même. Avec toutes les nouvelles fonctionnalités apportées dernièrement, il est possible de faire bien mieux que ce qu’on a maintenant.
Pour l’instant, le désambiguïsateur, quoique déjà fort utile, est particulièrement sous‐utilisé, pas parce qu’il est difficile d’emploi, mais parce que cette affaire est vraiment plus délicate que je ne l’avais supposé de prime abord, et aussi parce que le processeur de texte fait en vérité déjà beaucoup de travail sur ce point (cf. le journal précédent)… Encore une fois, le diable est dans les détails, les détails, les détails…
En revanche, il m’apparaît de plus en plus évident qu’il serait utile d’adjoindre au désambiguïsateur un système d’annotation du texte, parce que tout ne dépend pas de la désambiguïsation grammaticale, et qu’il est souvent appréciable de connaître le contexte.
Le fait que les règles puissent lancer plusieurs actions va permettre de faire des examens plus complets sur des détails pour l’instant ignorés, notamment sur le contrôle des locutions adverbiales ou les syntagmes nominaux les plus fréquents. Rien de difficile à première vue. Juste un travail de tâcheron qui demande du temps.
L’autre point central à mettre en œuvre, c’est la fusion et le réajustement des règles existantes. Le fait que les règles peuvent dorénavant appliquer autant d’actions que voulu change grandement la donne. Par exemple, je vous avais expliqué dans le précédent journal que la vérification des verbes se faisait après avoir vérifié tout le reste. À présent, même s’il est encore utile de fonctionner ainsi dans bon nombre de cas, il serait appréciable de fusionner certaines de ces vérifications avec le désambiguïsateur qui, lui, est surtout utilisé dans les premières phases de traitement.
Ce travail de fusion et de réajustement des règles ne présente pas de difficultés particulières, c’est surtout une question de stratégie globale qui ne nécessite cependant qu’un travail minutieux et attentif, plutôt ennuyeux et probablement un peu répétitif. Une fois de plus, avec plusieurs centaines de règles concernées, ça ne peut pas se faire en un tour de main.
Autre objectif : bétonner les tests, bétonner les tests, bétonner les tests. Parce que c’est possible et que c’est indispensable pour éviter les bogues inattendus que la correction grammaticale peut susciter. Mais il faudra aussi consolider radicalement les tests par l’ajout systématique des erreurs les plus fréquentes.
Améliorer les suggestions… Un casse‐tête qui s’est beaucoup amélioré ces derniers temps, mais il faudrait quand même réussir à filtrer les absurdités que le correcteur sort parfois. Son défaut est d’être un peu trop ingénieux par moments… mais bon, ça peut faire rire. :-)
Parmi les suggestions, il y a particulièrement les suggestions orthographiques. Pour le moment, dans Firefox et Thunderbird, Grammalecte utilise Hunspell pour avoir des suggestions orthographiques, même s’il n’a plus besoin de lui pour savoir si un mot est présent dans le dictionnaire et récupérer les données grammaticales. Il serait utile d’adjoindre un module de suggestion orthographique en parcourant le graphe de mots à la recherche de possibles mots correspondant suffisamment à la graphie inconnue. Un domaine de recherche à part entière. À mon avis, il serait utile d’implémenter une suggestion basée sur des substitutions phonétiques.
Plus loin, plus fort ?
Ce n’est qu’une idée, pour l’instant mal formée et un peu extravagante, mais je réfléchis à la possibilité de bâtir un graphe de la grammaire française comme il a été possible de bâtir un graphe de l’ensemble des mots du français. La différence, c’est que la totalité des mots français recensés peuvent s’écrire selon un graphe acyclique, avec un début et une fin connus, tandis que si on schématise la grammaire française les boucles et les récurrences sont possibles, les embranchements innombrables, les fantaisies ne sont pas rares, la longueur de la chaîne de tokens est théoriquement sans limite… Et on ne parle là que de phrases faites avec une grammaire correcte. Comment gérer les erreurs rencontrées ? Faut‐il les intégrer dans ce même graphe en créant des branches d’erreur ?
C’est une pensée embryonnaire qui n’aboutira peut‐être à rien d’utile, mais si l’on trouve un moyen de bâtir ce graphe, il devrait être possible de gérer des cas très complexes. Ça nous permettrait de sortir du schéma [motif potentiel d’erreur → condition d’erreur → suggestions → message d’erreur] qu’on peut heureusement combiner avec diverses magouilles plus ou moins subtiles élaborées avec le processeur de texte et le désambiguïsateur.
Ce qui est sûr, c’est que le tokeniseur va prendre une place une place plus importante dans la nouvelle stratégie pour gérer la complexité.
Créer une extension pour Chrome
Pas grand‐chose de spécial à dire sur ce sujet. Il est à espérer que produire l’extension pour Chrome prenne un temps raisonnablement court, attendu que Mozilla a essayé de faire en sorte que la nouvelle API soit proche de celle de Chrome. Mais dans l’univers de JavaScript, y a‐t‐il quelque chose de stable et bien pensé ? Ce serait une bonne surprise. J’ironise et je médis, mais c’est un peu mérité, n’est‐ce pas ?
Quoi qu’il en soit, même si ça se fait plus rapidement qu’attendu – il n’est pas interdit de rêver –, le temps prévu à cette tâche sera utilisé pour renforcer le correcteur, ce ne sera donc pas perdu. En plus, moins je fais de JavaScript, plus je suis heureux… C’est donc avec bonheur que je me livrerai à une tâche plus essentielle que deviner ce que peut vouloir me dire le débogueur de Chrome.
Outils annexes
L’amélioration du lexicographe (qui donne des informations sur les mots) et l’assistant lexical (permettant l’ajout simplifié de mots au lexique) ont pour but de revisiter la manière d’améliorer la base lexicale, dont Dicollecte, le site Web existant pour cette tâche, commence à se faire vieux. J’espère inciter les utilisateurs à participer à la conception de la base en rendant l’interface plus simple et plus séduisante, et surtout directement accessible dans son logiciel. Ça a l’air insignifiant, mais c’est une question essentielle.
Le détecteur de répétitions est proposé parce que c’est un outil qui intéresse potentiellement beaucoup les écrivains soucieux de varier leur vocabulaire.
Le mot de la fin
Bon sang ! Difficile de rendre une campagne de financement attrayante quand on parle de grammaire. Au final, on veut juste de petits liserés sous les mots erronés et un menu contextuel qui explique pourquoi c’est faux et qui suggère quelque chose de crédible. Rien de palpitant à la réflexion. On peut espérer susciter l’intérêt des technophiles en parlant de l’arrière‐cuisine et du système de tuyauterie, mais j’avais déjà presque tout dit la première fois, je ne peux que rendre compte de ce qui a été fait et amélioré.
Si la première campagne vous a satisfait, si vous jugez que la correction grammaticale est trop importante pour être négligée et qu’il faut en finir avec la maltraitance de la langue française, si vous voulez peser sur les priorités du correcteur grammatical ou ajouter des mots spécifiques ordinairement interdits dans le dictionnaire, je vous invite à consulter la page de financement participatif sur Ulule.
