Grammalecte, correcteur grammatical

Posté par  . Édité par Benoît Sibaud, palm123 et Nils Ratusznik. Modéré par Nils Ratusznik. Licence CC By‑SA.
Étiquettes :
233
22
avr.
2015
Bureautique

Grammalecte logo

Grammalecte est un correcteur grammatical récent (né en janvier 2011), écrit en Python, dédié à la langue française, et, pour l’instant, uniquement disponible pour LibreOffice et OpenOffice. Une campagne de financement participatif est lancée pour porter Grammalecte sur Firefox et Thunderbird et en faire par ailleurs un serveur indépendant (voir plus bas). Cette dépêche peut donc intéresser tous ceux qui s’intéressent à la grammaire.

Sommaire

Grammalecte est un dérivé de Lightproof, un correcteur écrit initialement pour le hongrois. Le logiciel s’est peu à peu éloigné de Lightproof avec les années. Même si Lightproof a été conçu pour gérer diverses langues, j’ai eu besoin de modifier nombre de choses dans le moteur interne pour le rendre efficace pour le français. Sans cela, pas grand-chose n’aurait été possible.

Ce correcteur est né un peu par hasard. En 2010, j’avais décidé de m’occuper de la partie française de LanguageTool, avec réticence, car je n’aime ni le Java et ni le XML dans lequel sont écrites les règles de grammaire. Par ailleurs, je voulais contrôler le processus de création des règles de contrôle. Or, à l’époque, LanguageTool possédait de nombreuses règles que je n’aimais pas, qui généraient beaucoup de faux positifs, mais il eût été indélicat d’envoyer à la benne tout ce qui me déplaisait. Enfin, comme je ne pouvais pas non plus ajuster certaines règles typographiques comme je l’aurais voulu (le développement étant centralisé, il fallait convaincre), j’ai finalement laissé tomber et je me suis penché sur Lightproof, qui avait l’avantage de fournir un kit minimal à partir duquel je pouvais faire comme je l’entendais. Je voulais me concentrer sur l’essentiel, éviter autant que possible les faux positifs, et être assez strict sur les questions typographiques. J’ai d’abord travaillé pour moi, surtout par curiosité, afin de voir ce qui était possible.

Après pas mal de déboires divers, la première version alpha paraît en janvier 2011 et connaît un petit succès d’estime. Du coup, bien que je n’avais pas vraiment l’intention de me consacrer à ça, j’ai mis le doigt dans l’engrenage.

Principes de fonctionnement

D’une manière générale, Grammalecte est un correcteur utilisant les motifs de correspondance (“pattern matching”) pour détecter les erreurs. Il examine le texte qu’on lui passe en se basant sur une liste de règles de contrôle, qu’il faut bien sûr écrire à l’avance parce que le correcteur ne peut pas deviner ce qui est une erreur, il ne fait pas de suppositions. Pour savoir à quoi correspondent les mots, il se base sur un lexique qui lui indique leur nature grammaticale. Les règles de contrôle sont décrites par un motif de détection d’erreur, des conditions d’application, un message informatif et si possible des suggestions. (Détecter une erreur et suggérer une correction sont deux choses plus distinctes qu’il n’y paraît. Suggérer peut s’avérer plus difficile que détecter une erreur, je reviendrai sur ce point plus tard.)

Un motif de détection est une expression régulière plus ou moins complexe. Une fois un motif détecté, il est en général nécessaire de faire une analyse plus poussée des éléments, notamment en examinant la nature grammaticale des mots du motif repéré, ce qui se fait par d’autres expressions régulières. Bref, on lance des expressions rationnelles tous azimuts, tout le temps. Les conditions d’application et l’analyse des motifs trouvés se font avec du code ad hoc en Python, simple ou complexe, c’est selon.

La difficulté de fonctionner avec des motifs de correspondance, c’est que les règles à écrire sont innombrables, tant l’écriture d’une langue humaine recèle de possibilités, tant le nombre d’erreurs possibles est grand. Par ailleurs, les faux positifs (ou fausses alertes) sont très difficiles à éviter. Car, s’il est facile d’écrire une règle pour détecter une erreur dans un contexte donné, il est difficile d’écrire une règle valable pour tous les cas de figure possibles.

L’atout de Grammalecte pour faire face à l’explosion combinatoire des possibilités, c’est son préprocesseur de texte.

Le préprocesseur de texte est un outil qui transforme en interne le texte à corriger. Il le modifie pour simplifier le travail des règles de contrôle. Pour ce faire, il dispose de règles de transformation qui sont décrites par un motif de détection, des conditions d’application et une chaîne ou une fonction de remplacement.

Néanmoins, toutes les transformations ne peuvent être mises en œuvre en une seule fois. C’est pourquoi le correcteur va effectuer plusieurs passes sur le texte. Chaque passe s’effectue en deux temps : d’abord l’application des transformations du préprocesseur de texte, puis les règles de contrôle. Ceci permet de simplifier le texte au fur et mesure des analyses et de supprimer les éléments qui ont été vérifiés ou qui n’ont pas besoin de l’être, puis de se concentrer lors de la passe suivante sur d’autres points.

Le correcteur effectue à l'heure actuelle six passes sur le texte. (Théoriquement, il peut en faire un nombre infini, il suffit de spécifier dans le fichier des règles qu’on veut une nouvelle passe et d’écrire de nouvelles instructions.)

  • La première passe contrôle les paragraphes entiers et sert notamment à vérifier tous les aspects typographiques, les espaces insécables, les guillemets, les espaces surnuméraires.
  • Après cette première passe, le paragraphe est scindé en phrases.
  • La seconde et la troisième passe servent à contrôler notamment les accords entre les noms et les adjectifs, les pluriels, le genre, etc.
  • Les trois passes suivantes vérifient principalement les accords des verbes avec leur sujet, les participes passés, les formes interrogatives ou impératives.

Il n’est pas du tout exclu d’ajouter de nouvelles passes.

Historique des fonctionnalités

Grammalecte n’a pas toujours fonctionné ainsi. Dans la version 0.1, comme Lightproof, il faisait tout le travail en une seule passe, paragraphe par paragraphe. Il m’est vite apparu qu’il serait pratique d’effectuer le contrôle en deux temps, paragraphe par paragraphe, puis phrase par phrase. Et il m’a semblé judicieux de simplifier le texte entre les deux passes. Ainsi naquit la version 0.2, qui prenait déjà pas mal de distance avec Lightproof. Le préprocesseur de texte, qui n’était au commencement qu’une commodité, m’est apparu peu à peu comme un élément essentiel, un outil susceptible de résoudre des problèmes quasi insurmontables sans lui. C’est pourquoi, à partir de la version 0.3, le préprocesseur est devenu la baguette magique avec laquelle une quantité gigantesque de difficultés ont été résolues. À ce stade, le correcteur effectuait déjà cinq passes, et il a fallu plus tard en rajouter une sixième.

Avec la version 0.3 sont apparus les outils annexes : le lexicographe, le formateur de texte, puis le conjugueur.

Le lexicographe et le conjugueur sont deux outils dont le rôle est pédagogique : informer et aider l’utilisateur en cas de doute. Le lexicographe, avec un clic droit, donne de la nature grammaticale de n’importe quel mot. Le conjugueur permet de connaître, là encore en quelques clics, la conjugaison de n’importe quel verbe. Par exemple, un clic droit sur le mot “suis” vous permet d’accéder immédiatement à la conjugaison d’être et de suivre, ce qui évite la peine d’avoir à chercher sur le Net ou dans son dictionnaire. Comme un correcteur grammatical ne saurait corriger toutes erreurs possibles, il m’a toujours paru utile de fournir une aide pédagogique à l’utilisateur, car lui seul peut vraiment décider.

Grammalecte - lexicographe
Grammalecte - conjugueur

Le formateur de texte est un outil de correction typographique automatisé, qui propose de corriger la plupart des erreurs en un seul clic, même s’il en y a des milliers. Il propose aussi quelques fonctions de nettoyage et de restructuration d’un texte. Cet outil, que je jugeais anecdotique au commencement, est celui qui a suscité le plus d’engouement et que les utilisateurs ont le plus sollicité. Les outils qui bossent tout seul, ça semble beaucoup plaire. ;)

Grammalecte - formateur de texte

La version 0.4 apporte beaucoup d’améliorations internes, mais surtout des mécanismes de suggestion qui permettent enfin d’offrir dans la plupart des cas autre chose qu’un simple message d’erreur (parfois mystérieux pour ceux qui ne savent plus ce qu’est un COD ou un participe passé).

Grammalecte - suggestions

Comparaison avec LanguageTool

LanguageTool, comme Grammalecte, fonctionne avec des motifs de correspondance (“pattern matching”) chargés de déceler les erreurs. Et les similitudes s’arrêtent là. Dans le détail technique, tout est différent, et ces différences font que le potentiel qu’on peut tirer de ces deux logiciels n’est pas le même.

LanguageTool est très formaliste, il faut écrire des règles en XML. C’est descriptif, rigide et assez contraignant, mais il n’est pas difficile de rentrer dans le code des règles. Tout est assez intelligible, même si c’est verbeux.

Grammalecte, en revanche, est beaucoup moins formaliste, c’est plutôt un vaste chantier en cours de construction, avec pas mal de bizarreries, mais c’est plutôt souple, et on peut se permettre bien plus de fantaisies. En revanche, concernant la lisibilité des règles, disons que ce n’est pas son point fort, car les règles appellent directement du code en Python et il faut toujours garder à l’esprit qu’on analyse un texte qui va être modifié par le préprocesseur de texte. De plus, il faut se plonger dans le code du moteur pour comprendre ce que font certaines fonctions. Par ailleurs, l’ordonnancement des règles est primordial. Si vous déplacez quelque chose sans comprendre comment ça fonctionne et les principes généraux, il est fort probable que vous cassiez quelque chose. Même quand on connaît bien l’ensemble, c’est assez difficile, attendu que les effets de bord ne sont pas toujours évidents à estimer.

LanguageTool ne possède pas de préprocesseur de texte, il lui faut plus de règles de détection que Grammalecte pour faire des choses similaires. Il en faut tellement plus qu’il est peu probable qu’en l’état actuel, LanguageTool puisse faire bien des choses que fait Grammalecte aujourd’hui relativement aisément, car il faudrait écrire énormément de règles.

Mais LanguageTool dispose d’un outil que Grammalecte ne possède pas : un désambiguïsateur. LanguageTool n’effectue qu’une seule passe sur le texte, phrase par phrase. En premier lieu, il découpe les phrases en “tokens” (mots, ponctuations, guillemets, etc.). Puis, grâce à son désambiguïsateur, il fait de la désambiguïsation sur les “tokens” ambigus, c’est-à-dire qu’il détermine la nature grammaticale d’un mot quand il en a plusieurs (par exemple : “est” peut être un nom masculin, une conjugaison du verbe être, un élément d’une locution adverbiale “id est”). En somme, grâce à cet outil, LanguageTool pose des étiquettes explicatives sur les tokens. Puis, il analyse la succession des tokens selon les règles écrites. Il renvoie les erreurs et c’est fini. Ce qu’il faut retenir, c’est que la désambiguïsation permet d’avoir plus de certitudes dans l’analyse du texte.

De son côté, Grammalecte ne découpe pas les phrases en tokens. Dans Grammalecte, il n’y a pas de tokens ni même de mots à proprement parler, il n’y a que des zones de texte définies par des expressions régulières qui servent de déclencheurs pour une analyse spécifique des passages correspondant aux motifs trouvés. On ne travaille pas sur des éléments déterminés à l’avance, mais sur des zones, souvent des mots bien sûr, mais aussi des bouts de phrases ou des motifs de caractères sans nécessairement se soucier des délimitations des mots et de leur position dans le texte (même si on s’en soucie assez souvent comme vous pouvez l’imaginer). Je peux par exemple chercher un motif “ni… ni…” sans me soucier du nombre de “tokens” qu’il pourrait y avoir entre les deux “ni”, sans me soucier où c’est précisément. C’est souple, mais cette souplesse se paye par une plus grande complexité et c’est régulièrement l’occasion de faire des nœuds mentaux pour comprendre ce qui se passe, surtout pour gérer toutes les questions d’apostrophes, de majuscules, de traits d’union, de délimitations des mots (plus problématique que ce que vous pouvez supposer) et divers détails subtils qui n’ont l’air de rien, mais qui compliquent souvent la tâche de manière imprévue. Certains problèmes, on ne les auraient pas, ou seulement à moindre degré, avec des phrases découpées de manière prédictible et uniforme en “tokens”. Cela dit, la tokenisation ne semble pas la solution miracle non plus, si j’en crois ce que j’ai lu parfois sur la liste de discussion de LanguageTool, car il ne semble pas évident de gérer la question des apostrophes et des traits d’union.
Par ailleurs, dans Grammalecte, comme à chaque passe le texte est transformé, un même motif de correspondance ne renverra pas forcément la même chose selon la passe dans lequel il est lancé. Il faut toujours garder à l’esprit où on est dans le flux des règles de transformation et estimer ce qui se passe globalement.
Et, comme il n’y a pas de “tokens” dans Grammalecte, il n’y a pas non plus de désambiguïsateur qui pose des étiquettes sur les mots. Le correcteur fait quand même de la désambiguïsation, mais à la volée, c’est-à-dire que chaque règle se charge elle-même de s’y retrouver parmi les ambiguïtés du texte. C’est un désavantage par rapport à LanguageTool. Ce dernier permet d’écrire des règles dans un environnement plus “sûr” que dans Grammalecte où règnent l’incertitude et le flou. Cela dit, le préprocesseur de texte, encore lui, va nous épargner bien des peines et solutionner nombre de cas difficiles, en faisant faire de la “désambiguïsation” à sa manière, c’est-à-dire en supprimant tout simplement des zones de texte.
Les règles de transformation du préprocesseur de texte consistent pour la très grande majorité à faire du nettoyage, c’est-à-dire à effacer le superflu, ce qui, de fait, nous évite de faire un gros travail d’analyse. Certaines règles de transformation introduisent aussi dans le texte des caractères signalétiques que certaines règles de contrôle savent reconnaître. Et quelques règles servent réellement à modifier ce qui est écrit, là encore pour simplifier. Cette manière de faire apporte beaucoup d’avantages par rapport à LanguageTool, mais dans certains cas s’avère moins efficace que l’étiquetage. Le problème de Grammalecte, c’est une certaine forme d’amnésie, le préprocesseur nettoie et fait parfois du signalement, mais après ça chaque règle se débrouille seule.

Hormis les différences techniques inhérentes aux logiciels, la manière d’écrire les règles peut aussi faire varier grandement leurs capacités de détection. On peut écrire les règles de manière stricte (moins de détection d’erreurs, moins de faux positifs) ou audacieuse (plus de détection, plus de faux positifs). LanguageTool possède des règles de contrôle que je n’ai pas implémentées dans Grammalecte parce que je les trouve trop susceptibles de générer des faux positifs en l’état actuel des choses. Il y a des vérifications que Grammalecte fait que son rival n’essaie pas de faire (trop risqué ou compliqué pour lui). Ensuite, il y a les règles qu’un correcteur peut juger superflues. Par exemple, LanguageTool vérifie si vous écrivez correctement Britney Spears, Warren Buffett et des tas d’autres célébrités, ce que Grammalecte ne prend pas la peine de contrôler.

Le préprocesseur de texte par l’exemple

Mettons que nous tapons dans Writer :

Cette pièces de théâtre-là (http://www.site.fr/blabla) d’Albert Camus² sur «l’absurde» étaient, comme d’habitude, passionnants.

Trois erreurs grammaticales, deux typographiques.

Sachez d’abord que le texte que le correcteur reçoit ne correspond pas toujours au texte que voit l’utilisateur. En effet, les marques de formatage sont effacées. Si vous tapez des passages en italique ou gras, l’italique et le gras vont disparaître. Dans notre exemple, il y a le caractère “²”. Il peut être obtenu en tapant le caractère “²” ou tapant le caractère “2” et en le mettant en exposant. Dans le second cas, la mise en exposant est une marque de formatage. C’est probablement ainsi que l’utilisateur a obtenu ce caractère. Dans ce cas, le correcteur reçoit :

Cette pièces de théâtre-là (http://www.site.fr/blabla) d’Albert Camus2 sur «l’absurde» étaient, comme d’habitude, passionnants.

Autrement dit, même si l’utilisateur voit le caractère “²”, le correcteur reçoit le caractère “2”.

Passe 1. Pour commencer, le préprocesseur de texte va supprimer les URL (entre autres choses).

Cette pièces de théâtre-là (@@@@@@@@@@@@@@@@@@@@@@@@@) d’Albert Camus2 sur «l’absurde» étaient, comme d’habitude, passionnants.

Ensuite, les règles de contrôle vont vérifier les espacements, la ponctuation, les guillemets, etc. C’est lors de la première passe que le correcteur signalera qu’il faut des espaces insécables autour de “l’absurde”.

Passe 2. Les arobases sont supprimées. La note de référence “2” qui suit Camus est supprimée, ainsi que les guillemets. On obtient alors :

Cette pièces de théâtre-là (_________________________) d’Albert Camus_ sur _l’absurde_ étaient, comme d’habitude, passionnants.

Passe 3. C’est dans cette passe qu’on nettoie le plus. On supprime le “-là” qui suit “théâtre”. Le patronyme “Camus” est supprimé. Puis “d’Albert” est supprimé, ainsi que “comme d’habitude”. Puis “pièces de théâtre” est simplifié et réduit à un seul mot : “pièces”. Comme il n’y a plus que du vide entre les parenthèses et les virgules, on les supprime aussi. Ce qui donne :

Cette pièces _________________________________________________________ sur _l’absurde_ étaient __________________ passionnants.

Lors de cette passe, la première erreur d’accord sur “pièces” est repérée.

Passe 4, 5 et 6. Après la 3 ème passe, on considère que les accords dans les groupes nominaux ont été vérifiés. Donc on simplifie les groupes nominaux afin de pouvoir vérifier l’accord avec les verbes. Ce qu’on fera dans les 3 passes suivantes. Ici, “sur l’absurde” est supprimé puisqu’il ne peut être un sujet. Il reste :

Cette pièces _________________________________________________________________________ étaient __________________ passionnants.

À présent, il n’y plus rien à simplifier. Après la correction de “pièce”, le correcteur verra l’erreur sur “étaient” et après la correction de ce dernier, il pourra faire les bonnes suggestions sur “passionnants”.

Ce système n’est pas parfait. Voici un autre exemple.

Les petits étais endormis.

Ici, le correcteur ne détecte rien, car “étais” est aussi un nom masculin pluriel.

D’autres erreurs que le correcteur peut trouver grâce au préprocesseur de texte :

L’homme sur le bateau de Patrick viens de temps en temps mangé chez moi.
Ces marchands passe leur temps à se quereller.
Ils jugeront en toute impartialité de ce cas délirante.
Ils sont de manière si étonnante et si admirable arrivé à ce résultat…
Les tests grand public de Jean-Paul montre des résultats surprenants.
Ils ont à plusieurs reprises perdus leur sang-froid.
Ces attaques à main armée donne la chair de poule.
Réfléchir à tête reposée prends du temps.
Des chambres plus ou moins fortement éclairé.
Ce qui, la plupart du temps, donnes des maux de tête.
La N.S.A. espionneras toujours tout le monde.

Avec le dernier exemple, vous verrez l’une des choses que le préprocesseur réécrit pour faciliter le travail du correcteur. En interne, la graphie “N.S.A.” a été transformée en “NSA” (le message d’erreur trahit cette modification).

Le préprocesseur fait aussi de la simplification de certains syntagmes nominaux. Exemples :

armé jusqu’aux dents --> armé
fille au pair ---------> fille
médecin de garde ------> médecin

Le préprocesseur peut faire énormément de choses, mais il ne peut en l’état actuel résoudre tous les problèmes, car il doit lui-même demeurer prudent quand il fait face à des ambiguïtés. Dans bien des cas, il arrivera à simplifier les groupes nominaux. Dans d’autres cas, il n’y arrivera pas. Il y a encore beaucoup de progrès à faire sur ce chapitre. Concevoir un désambiguïsateur aiderait beaucoup. Un préprocesseur de texte associé à un désambiguïsateur, ce serait une combinaison utile pour accroître notablement la détection des erreurs.

Le dictionnaire

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. Le dictionnaire français pour Hunspell, le correcteur orthographique, est actuellement la source directe de Grammalecte.

Quelques données sur le dictionnaire :

  • plus de 77000 entrées,
  • toutes les entrées sont grammaticalement étiquetées,
  • environ 12 % 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.

Ce dictionnaire, vous l’avez probablement tous utilisé, puisqu’il est inclus dans Firefox, Thunderbird, LibreOffice, Chrome, Opera et une multitude de logiciels dont je serais bien en peine de faire la liste si on me la demandait. Cela dit, vous en utilisez peut-être une vieille version, je ne l’intègre qu’à LibreOffice et ne fournit des extensions que pour OpenOffice, Firefox et Thunderbird. L’intégration dans les autres logiciels est faite par d’autres personnes à des rythmes très divers.

Tout le travail sur le dictionnaire se fait sur Dicollecte, où sont collectées les propositions des utilisateurs.

Pourquoi la correction grammaticale est difficile

Commençons par un exemple :

Il est conseiller à la mairie. [Correct]
Il est aller à la mairie. [Incorrect]

Pourtant, l’étiquetage grammatical de ces phrases est strictement identique. Les mots “conseiller” et “aller” sont tous les deux à la fois un verbe à l’infinitif et un nom masculin. Or, un correcteur grammatical ne comprend absolument rien à ce que vous écrivez, même si vous ne faites aucune erreur. Il ne peut se baser que sur une suite d’étiquettes grammaticales.

Il est parfois irritant de s’entendre dire : “il y a une erreur ici, c’est évident”. Car, en fait, il y a rarement quoi que ce soit d’évident pour un correcteur grammatical. Le mot “évident” n’est lui-même pas seulement un adjectif, c’est aussi la conjugaison du verbe “évider” à la 3e personne du pluriel au présent. D’une manière générale, il semble souvent facile d’écrire une règle qui détecte les erreurs dans une phrase ou un contexte spécifique. En revanche, il est souvent difficile, voire impossible, d’écrire une règle qui détecte les erreurs dans tous les contextes sans générer nombre de faux positifs. Du coup, l’écriture des règles, c’est très souvent un compromis entre ce qu’on voudrait détecter et la tolérance pour les fausses alertes (la mienne est assez basse).

Autres exemples :

Des caractéristiques matériels [Incorrect]
Des matériels caractéristiques [Correct]
Des nouvelles caractéristiques [Correct]
Des matérielles caractéristiques [Incorrect]

Vous, humains, savez que “caractéristiques” est dans le premier cas un nom féminin. Mais c’est aussi un adjectif épicène. Le correcteur grammatical ne sait pas décider si ce doit être un nom ou un adjectif. Pour lui, “matériel”, “caractéristique” et “nouvelle” sont dans tous les cas nom et adjectif.

Autrement dit, l’étiquetage grammatical ne suffit pas. Seul le sens permet aux humains de trouver les erreurs. Mais, comme je l’ai dit, le correcteur ne comprend rien du tout. Il faudrait prendre le temps d’étiqueter les entrées avec des informations plus spécifiques, susceptibles de nous aider à contextualiser ce qu’on corrige. Une tâche titanesque. Nous en sommes encore loin.

Et ce ne sont là que des exemples très simples, très loin des phrases complexes qu’on peut écrire.

Parmi les difficultés du français, l’une des principales, c’est qu’il y a énormément de mots dont la nature grammaticale dépend du contexte :

tu ________ pronom personnel sujet épicène singulier // participe passé du verbe taire
lui _______ pronom personnel sujet masculin // pronom personnel objet masculin et féminin // participe passé du verbe luire
sommes ____ forme conjuguée de être // forme conjuguée de sommer // nom féminin ou masculin pluriel
ton _______ déterminant // nom masculin
son _______ déterminant // nom masculin
la ________ déterminant // nom masculin // pronom personnel objet
avoir _____ nom masculin // verbe auxiliaire
été _______ participe passé du verbe être // nom masculin
est _______ forme conjuguée de être // nom masculin // élément d’une locution latine (id est)
a _________ forme conjuguée de avoir // nom masculin invariable
avions ____ forme conjuguée de avoir // nom masculin pluriel
pas _______ adverbe de négation // nom masculin
une _______ déterminant // nom féminin (la une des journaux)
aura ______ forme conjuguée de avoir // nom féminin
as ________ forme conjuguée de avoir // nom masculin
contre ____ préposition // nom masculin singulier // forme conjuguée de contrer
vers ______ préposition // nom masculin singulier ou pluriel
mais ______ conjonction de coordination // adverbe // nom masculin pluriel
si ________ conjonction de subordination // adverbe // nom masculin
évident ___ adjectif masculin // forme conjuguée de évider
dément ____ adjectif masculin // forme conjuguée de démentir
prise _____ nom féminin // participe passé de prendre // forme conjuguée de priser
courant ___ nom masculin // participe présent de courir // préposition
or ________ conjonction de coordination // nom masculin singulier
plus ______ adverbe // adverbe de négation // nom masculin
point _____ adverbe de négation // nom masculin singulier
vis _______ nom féminin // forme conjuguée de voir et de vivre
montre ____ nom féminin // forme conjuguée de montrer
partis ____ forme conjuguée de partir // participe passé pluriel // nom masculin pluriel
vous ______ pronom personnel sujet ou objet.
nous ______ idem
etc.

Il y a de nombreux mots qui ont plusieurs natures grammaticales, et le correcteur doit trouver laquelle s’applique dans le contexte. Il faut constamment faire attention à ça, sinon c’est d’explosion de faux positifs assurée. Pourtant, malgré les règles de prudence, il y a toujours des faux positifs. Parce que si on ne signalait que les erreurs certaines, on ne signalerait pas grand-chose.

L’autre problème, c’est que les homonymes en français sont nombreux et les confusions pas forcément faciles à détecter.

  • a / à / as / ha
  • est / et / es / ai / ait / aie / aies / ais / hé / eh / haie / hais
  • été / étai / était / étais
  • dans / d’en / dent
  • desceller / déceler / desseller
  • faite / faîte / fête
  • la / là / l’a / l’as / las
  • mal / mâle / malle
  • or / hors
  • ou / où
  • on / ont
  • notre / nôtre
  • par / part / pare
  • prêt / près / pré
  • quand / quant / qu’en
  • sans / s’en / sens / c’en / cens / sent / cent / sang
  • serre / serf / sers / cerf
  • sot / seau / sceau
  • soi / soie / soit / sois
  • son / sont
  • soutien / soutiens / soutient
  • suis / suie / sui / suit
  • tort / tore / taure / tord
  • ver / vers / vert / verre

Ajoutons à cela les conjugaisons homophones :

  • manger / mangé / mangez / mangeais / mangeait
  • fus / fut / fût

En bref, la difficulté du français, c’est qu’il est rempli de nombreux mots qui s’écrivent de la même façon avec des natures différentes et de nombreux mots différents qui se prononcent de la même façon et qui engendrent nombre de confusions à l’écrit.

Les manières d’écrire en respectant la grammaire sont extrêmement nombreuses, mais les manières de mal écrire sont illimitées.

Campagne de financement

Campagne de financement participatif

Pour ceux que ça intéresse, c’est sur Ulule.

Je vais évoquer ici quelques aspects techniques dont je ne parle pas sur Ulule.

Fournir de meilleures suggestions

Détecter les erreurs et suggérer quelle est la bonne graphie sont deux choses bien différentes. Dans certains cas, il est plus facile de détecter les erreurs que de savoir que suggérer. Mais l’inverse est aussi vrai, il existe des erreurs difficiles à détecter où il serait pourtant facile de suggérer la graphie correcte.

Grammalecte parvient à présent à faire des suggestions dans la plupart des cas, mais il reste quand même du travail à faire sur ce point. Prenons un exemple simple, une erreur que j’ai fréquemment vue sur ce site :

Je m’en fou.

Erreur fréquente sur LinuxFR

Ici, le correcteur voit l’erreur mais est incapable de fournir une suggestion, parce qu’il n’existe aucun lien entre l’entrée “fou” et l’entrée “foutre” d’où dérivent toutes ses conjugaisons. Le correcteur ne sait pas où chercher une conjugaison adéquate. Pour parfaire le système de suggestion, il faudrait établir des passerelles entre tous les mots grammaticalement distincts sur leurs liens phonétiques éventuels.

Évidemment, si on prend la peine d’écrire des règles spécifiques pour gérer les cas particuliers, c’est possible de suggérer correctement, mais ce ne serait guère efficace dans la mesure où les mots homophones sont nombreux. Il faudrait écrire trop de règles.

Améliorer la détection des erreurs

Pour l’instant, si le préprocesseur de texte est déjà très employé, il est encore sous-exploité et on peut aller plus loin, mais cela réclame du temps et beaucoup de tests et de patience. La correction grammaticale est encore grandement améliorable, même si les choses “faciles” à faire sont de moins en moins nombreuses. La simplification des groupes nominaux pourrait être bien meilleure, c’est un vaste chantier qui est entamé depuis environ un an. Le principal obstacle à son renforcement, c’est justement l’absence d’une désambiguïsation efficace.
Il y a encore aussi pas mal de vérifications simples à écrire sur des tas de confusions possibles. Je me suis assez peu occupé de ça jusqu’à présent.

Le développement du correcteur suit depuis le commencement la même logique : une montée en puissance progressive en essayant d’éviter les faux positifs.

É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ù 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.

Désambiguïsation

Bien que le correcteur fasse déjà de la désambiguïsation à sa manière, brutalement, améliorer cet aspect ne serait pas du luxe pour la connaissance du contexte des erreurs. J’hésite encore sur la mise en œuvre. “Tokeniser”, pourquoi pas, mais ce n’est pas ma solution favorite. Utiliser le préprocesseur de texte pour créer un genre de carte signalétique, c’est pas mal, mais ça ressemble à de la bidouille. Employer des trucs et astuces, comme je le fais déjà maintenant, toujours via le préprocesseur de texte, ce n’est pas ce qu’il y a de plus commode, surtout pour l’intelligibilité de l’ensemble des règles. Je n’ai pas encore trouvé une solution simple et efficace. En rédigeant ce billet, une solution plaisante m’est venue. Ce sera un désambiguïsateur multi-passes sans tokenisation. Il fonctionnera en dressant un index de balises grâce des règles de désambiguïsation qui seront exécutées au commencement de chaque passe, avant même le préprocesseur de texte. Il suffira, lors de l’analyse lexicale, que le correcteur interroge en premier lieu cet index. Ce mécanisme devrait accroître grandement la capacité de reconnaissance des erreurs, car le désambiguïsateur diminuera les incertitudes.

Fiabilité des versions (tests unitaires)

Triste à dire, mais il n’y a à l’heure actuelle aucun test unitaire dans Grammalecte. Tout simplement parce que le correcteur est pour l’instant incapable de fonctionner hors de Writer. Les tests faits avant chaque publication se limitent à deux fichiers ODT que j’ouvre dans le traitement de texte : un qui référence les faux positifs éventuels, un autre qui liste des erreurs grammaticales à détecter. J’ouvre encore quelques autres fichiers pour voir si tout va bien. Mais ce n’est pas du tout pratique. Les tests unitaires accéléreraient beaucoup le développement, car les bugs et les régressions seraient détectés aussitôt, ce qui ne serait pas du luxe.

En finir avec la dépendance à Hunspell et à LibreOffice/OpenOffice

La raison pour laquelle Grammalecte est pour l’instant dépendant de LibreOffice/OpenOffice, c’est sa dépendance à Hunspell, le correcteur orthographique, qu’il interroge sans cesse pour connaître la nature grammaticale des mots.

Hunspell remplit sa tâche, mais les informations qu’il fournit sont présentées en vrac. Il faut traiter les données avant de pouvoir les exploiter. Quand vous demandez la nature grammaticale d’un mot, vous récupérez en fait toutes les étiquettes que le dictionnaire contient (et il y en a potentiellement pas mal). Il faut trier. Du coup, pour l’instant, je limite les données incluses dans le dictionnaire aux seules étiquettes grammaticales, afin d’éviter d’alourdir le boulot.

Plutôt que de recréer Hunspell en Python, il est préférable de créer un dictionnaire binaire indexable bâti sous la forme d’un gigantesque graphe de mots, facilement parcourable, ce qu’on peut appeler aussi un automate à états finis.

Un graphe de mots, ça ressemble à ça :
Graphe de mots

Pour savoir si un mot existe dans un graphe, on part de l’état initial et on suit les arcs représentés par les flèches, et si l’on parvient jusqu’à l’état final, le mot est considéré comme existant. Pour le correcteur, le graphe devra contenir tous les mots du français, et à la suite de chaque mot les informations grammaticales. Cette construction se fait à partir d’un simple fichier texte listant toutes les formes fléchies du français, leur lemme et les étiquettes informatives.

Les principales fonctions de cet automate seront de dire si un mot existe dans le lexique, donner son lemme (“aimer” est le lemme de “aime”), fournir ses étiquettes grammaticales, et éventuellement d’autres. Doté d’un module de suggestion, il peut même servir de correcteur orthographique.

Grammalecte existera bien sûr toujours comme extension pour Writer mais, grâce à cela, il pourra exister comme serveur autonome capable de fournir des corrections grammaticales à tout programme lui passant du texte à analyser, au format JSON. Chaque erreur contiendra les informations suivantes :

  • position de l’erreur,
  • type d’erreur (pour les applications qui auraient l’intelligence de souligner avec différentes couleurs),
  • message explicatif,
  • suggestion(s),
  • [optionnellement] hyperlien vers une page explicative plus complète,
  • identifiant de la règle détectant l’erreur (utile seulement pour le débogage).

Conversion du code en JavaScript pour l’extension Firefox/Thunderbird

Pour rappel, le but est bien d’avoir une extension qui peut fonctionner sans faire appel à un serveur local ou distant. Il faudra tout réimplémenter en JavaScript. Pour Firefox, je voudrais que le correcteur puisse aussi analyser le contenu d’une page web et pas seulement les zones d’édition de texte. Pour l’instant, Firefox, contrairement à LibreOffice et OpenOffice, ne possède pas (encore) d’API pour la grammaire, ce qui complique l’interfaçage avec les utilisateurs, mais ça ne semble pas insurmontable. À part ça, il n’a pas grand-chose à dire si ce n’est qu’il y a des épines et des ronces en perspective.

Autres considérations

Les autres langues ?

Bonne nouvelle ! Même si je n’ai pas l’intention de m’occuper des autres langues, ce qui sera fait pour le français sera également possible pour bien d’autres. L’une des raisons pour lesquelles Lightproof est peu employé, c’est l’absence de ressources lexicales. Lightproof utilise les dictionnaires pour Hunspell, dont bien peu peuvent servir à la correction grammaticale puisque seuls les dictionnaires français et hongrois sont grammaticalement étiquetés. Or, le compilateur de lexique en dictionnaire binaire indexable dont j’ai parlé ci-dessus pourra réutiliser tous les lexiques de LanguageTool. Autrement dit, toutes les langues qui disposent d’un lexique chez LanguageTool pourront utiliser le moteur de Grammalecte.

Et la gestion du dictionnaire ?

Le site qui gère le dictionnaire français a fait son temps. Il est encore utile et assez pratique, mais il pourrait être bien mieux, plus simple notamment. Même s’il n’est pas difficile de participer, il faut quand même un peu de temps pour comprendre la logique. Mais comprendre n’est même pas exigé, il suffit de proposer de nouveaux mots. Malheureusement ça rebute apparemment beaucoup de monde. Les utilisateurs veulent aller vite et ne voient les résultats de leur participation que des mois plus tard, quand une nouvelle version est publiée. Le site est pensé sur un mode cathédrale et non sur un mode bazar. Après des années d’utilisation, j’en vois les limites, et je pense qu’il aurait dû être conçu autrement. Le refonte du site ne fait pas partie de la campagne de financement participatif. Idéalement, j’aimerais avoir un jour le temps de tout réécrire en Python (avec un framework comme Flask) en utilisant un autre concept que celui d’aujourd’hui, permettant une plus grande personnalisation, une plus grande modularité, un contrôle plus simple. C’est un vaste chantier.
Pour pallier ce problème, je prévois de créer dans le correcteur de LibreOffice et de Firefox un assistant qui simplifiera toute la procédure.

Les correcteurs grammaticaux servent-ils à quelque chose ?

Certaines personnes, en général avec une forte estime de leurs connaissances en orthographe et en grammaire, pensent que les correcteurs grammaticaux sont tous mauvais et ne servent à rien, et surtout pas à eux. Cette opinion est en partie légitime et en partie fausse.

Les correcteurs informatiques, ne comprenant rien à ce que vous écrivez, ont bien sûr du mal à détecter les erreurs dans les phrases complexes et parfois même dans des contextes simples. Dans bien des cas, les connaissances en grammaire d’un utilisateur bien instruit lui permettront de trouver plus d’erreurs que le correcteur grammatical.

Néanmoins, ceux qui pensent que connaître la langue parfaitement suffit à ne jamais faillir se trompent, car nombre d’erreurs sont dues à l’inattention, à la fatigue, à des copier-coller mal ajustés, à des défauts de reconnaissance optique. Or, l’ordinateur ne relâche jamais son attention, son œil ne fatigue jamais et il examine même ce qui ne vous vient pas à l’esprit.

Par ailleurs, pour les personnes dont les connaissances sont lacunaires, il peut se révéler pédagogue. Si par exemple vous ne connaissez pas le participe passé du verbe “avoir” (“eu”, que beaucoup écrivent erronément “eut”) ou du verbe “lire” (“lu”, et non “lut”), le correcteur finira immanquablement par trouver des occasions de vous signaler vos erreurs, même s’il peut ne pas toujours les repérer dans les contextes complexes, car il les détectera dans les contextes simples (Erreurs détectées dans “j’ai eut”, “ils n’ont pas eut”, etc.).

Le mot de la fin

Merci de m’avoir lu jusqu’ici.

Il semble que l’orthographe et la grammaire françaises soient de plus en plus ignorées, même des personnes les plus instruites. C’est du moins ce que disent souvent des articles alarmistes. J’ignore si cela est vrai, mais ce que je lis sur le Web m’étonne parfois, tant les bases de la grammaire semblent parfois méconnues. Qu’on ne connaisse pas la conjugaison de tous les verbes, c’est compréhensible, mais confondre “ça” et “sa”, “ce” et “se”, “quand”, “quant” et “qu’en” semble signifier qu’il faudrait une remise à niveau pour pas mal de monde. Cela dit, ce n’est peut-être pas si étonnant si l’on songe que le Web a remis à l’écriture des personnes qui n’écrivaient plus rien depuis fort longtemps.

Si vous pensez que Grammalecte mérite de s’étendre hors de LibreOffice, si vous trouvez que la langue française est maltraitée et qu’il faudrait avoir un outil pour dénicher les erreurs sur le Web, si vous voulez voir des mots normalement rejetés intégrés dans le correcteur, c’est sur Ulule que ça se passe.

Aller plus loin

  • # Bravo

    Posté par  (site web personnel) . Évalué à 10.

    Franchement, bravo pour tout ce travail. Nul doute que ce serait un grand pas en avant pour limiter les fautes basiques dans de nombreux documents ou sites webs. Il est vrai que les outils proprio ont une grande avance sur ces questions.

    Est-ce que tu penses qu'il est aisé de rendre ton programme portable vis à vis d'une autre langue ? As-tu essayé de discuter avec LibreOffice et Mozilla pour une possibilité d'inclusion par défaut ?

    Bonne continuation, j'espère que tu pourras poursuivre ton développement. :)

    • [^] # Re: Bravo

      Posté par  . Évalué à 10.

      Est-ce que tu penses qu'il est aisé de rendre ton programme portable vis à vis d'une autre langue ?

      Pour l’instant, non, attendu que les autres langues ne disposent pas des ressources linguistiques nécessaires. Par ailleurs, l’absence de module autonome et de tests unitaires, ça ne facilite pas la tâche.

      Mais, concevoir le correcteur pour Firefox ou comme serveur va justement ouvrir cette possibilité, car les lexiques de LanguageTool seront réutilisables (il suffira de les recompiler) et il y aura des tests unitaires. Après ça, oui, il sera facile d’utiliser le système de Grammalecte : règles de contrôle, règles de transformation du préprocesseur de texte, règles d’étiquetage du désambiguïsateur (à venir), tout ça pourra être utilisé en créant son propre fichier de règles. En revanche, la plupart des mécanismes de suggestion sont bien trop étroitement liés à la langue. Il faudra écrire ses propres fonctions de suggestion. Quant aux modules annexes, ils nécessiteront pour la plupart une adaptation, mais rien d’insurmontable de mon point de vue.

      As-tu essayé de discuter avec LibreOffice et Mozilla pour une possibilité d'inclusion par défaut ?

      I. Avec Mozilla, non, je n’ai pas discuté d’un module qui n’existe pas encore. :) Par ailleurs, j’ai lu je ne sais plus où qu’ils n’ont pas l’intention d’inclure ce genre d’extensions par défaut. En revanche, ils prévoient de concevoir une API grammaticale pour aider à l’intégration dans leur navigateur (et j’espère bien Thunderbird).

      II. Avec LibreOffice, l’intégration est déjà possible. Je pourrais le faire si je le voulais. Mais je ne le veux pas (encore) pour plusieurs raisons :

      a. Grammalecte n’est pas encore assez bien à mes yeux. Même s’il reste peu de faux positifs, c’est toujours trop pour moi. J’aimerais avoir le temps de créer une option zéro faux positif, qui exclurait les règles de contrôle qui en font parfois. Pour l’instant, sans tests unitaires, c’est peine perdue.

      b. Il faudrait réécrire une grosse partie du code concernant les outils annexes juste pour satisfaire les normes de LO sur l’interface et leur traduction. Actuellement, les chaînes de caractères sont décrites dans des fichiers en Python. Il faudrait mettre tout ça dans des fichiers en XML, générer l’UI autrement que ce que je fais jusqu’à présent (Grammalecte commande directement l’API de LO pour créer ses fenêtres). Par ailleurs, faire cela signifie que je renonce à écrire moi-même le texte en français. Tout sera écrit en anglais puis traduit. Je suis réticent à cette idée. Par ailleurs, j’écris en anglais, mais je ne suis pas assez doué pour le faire sonner nativement, et il est certainement parfois incorrect.
      Si un anglophone me lit, je suis partant pour qu’on me fasse des retours sur l’anglais de l’UI (il suffit de passer l’interface de LO en anglais pour avoir Grammalecte anglais, sauf les messages d’erreurs et le conjugueur).

      c. Inclure Grammalecte dans LO signifie qu’une partie de la gestion du projet va transiter chez eux, dans leur bugzilla, ce qui ne me motive pas du tout. Ne pas inclure Grammalecte dans LO me permet de conserver l’indépendance dans la conception et la gestion du projet. Je trouve que c’est plus souple ainsi. Si un jour, je cède ça à LO, je vais mettre la pression pour faire modifier l’API grammaticale qui n’est pas terrible en l’état actuel. Ce sera donnant-donnant. :) Mais je ne suis pas encore prêt pour ça, et je suis heureux de mon indépendance.

      Je profite de ce message pour ajouter une chose que j’ai oubliée dans l’article : Grammalecte est encore un projet assez peu connu, même parmi les utilisateurs de LibreOffice/OpenOffice. C’est la première fois que j’en parle en dehors de leurs mailing-lists/forums. Donc, si vous voulez voir la campagne de financement réussir, je vous invite à en parler sur vos blogs, réseaux sociaux et autres lieux de discussion. C’est un logiciel encore très peu connu.

      • [^] # Re: Bravo

        Posté par  . Évalué à 2.

        Pour inclure Grammalecte par défaut dans LibreOffice, il me semble qu'il y a aussi un problème d'incompatibilité à régler entre Grammalecte et LanguageTool. Sauf erreur de ma part, on ne peut pas avoir les 2 en même temps, ce qui serait pourtant utile pour les personnes qui écrivent en plusieurs langues. Je ne sais pas s'il serait compliqué dans LibreOffice d'orienter les portions de texte en anglais vers LanguageTool et les portions de texte en français vers Grammalecte.

        Mille mercis pour cette excellente extension pour LibreOffice que j'espère bientôt pouvoir installer aussi sur Thunderbird.

        • [^] # Re: Bravo

          Posté par  . Évalué à 3.

          En fait, Grammalecte et LanguageTool ne sont pas tout à fait incompatibles. Mais il ne peut y avoir qu’un seul correcteur grammatical par langue. Le problème, c’est que LanguageTool n’est pas modulaire, il s’installe sur une vingtaine de langues. Donc il est déjà en conflit avec d’autres correcteurs préinstallés avec LO, je pense.

  • # Wahou

    Posté par  . Évalué à 9.

    Je n'ai pas l'habitude de commenter juste pour dire ça, mais GG pour le journal et son contenu.

    • [^] # Re: Wahou

      Posté par  (site web personnel, Mastodon) . Évalué à 3.

      Pareil ! Article très intéressant sur un outil très utile.

      Au fait, comme s'en sort Grammalecte sur :

      Contre nous de la tyrannie
      L'étendard sanglant est levé

      C'est typiquement la phrase qui doit paraître incompréhensible aux étrangers débutant l'apprentissage du français.

      • [^] # Re: Wahou

        Posté par  (site web personnel) . Évalué à 3.

        Au fait, comme s'en sort Grammalecte sur :

        Contre nous de la tyrannie
L'étendard sanglant est levé

        C'est typiquement la phrase qui doit paraître incompréhensible aux étrangers
        débutant l'apprentissage du français.

        Autant demander à Google de traduire des poèmes !

      • [^] # Re: Wahou

        Posté par  . Évalué à 5.

        Il n’y comprend rien, mais il s’en sort comme il faut, en disant rien, hormis qu’il faudrait une apostrophe typographique. ;)

  • # Génial !

    Posté par  . Évalué à 10.

    Excellent travail.

    Je vais me dépêcher de l'installer, de le tester et de diffuser la nouvelle.
    Je pense que des millions de rapports de stage vont pouvoir te remercier.
    Bon travail.

    • [^] # Re: Génial !

      Posté par  . Évalué à 0.

      Je pense que des millions de rapports de stage vont pouvoir te remercier.

      Ça m'a fait rire :)

  • # Erreur

    Posté par  (site web personnel) . Évalué à 4.

    Il faut traiter les données avant de les pouvoir les exploiter.

    Il faut traiter les données avant de pouvoir les exploiter.

    Grammalecte ne peut pas détecter ce genre d'erreur ? :)

    • [^] # Re: Erreur

      Posté par  (site web personnel) . Évalué à 3.

      Corrigé, merci.

    • [^] # Re: Erreur

      Posté par  . Évalué à 5.

      Je suis le moins bien placé pour trouver mes propres erreurs. Il faudrait que je crée une règle pour ça. :)

      • [^] # Re: Erreur

        Posté par  (site web personnel) . Évalué à 3.

        Il y avait quand même une vraie question dans ma remarque : Grammalecte ne pouvait pas voir « les pouvoir » comme une faute potentielle ?

        • [^] # Re: Erreur

          Posté par  . Évalué à 8. Dernière modification le 22 avril 2015 à 17:29.

          Oui, mais prudence. Dans les écrits anciens, il n’est pas pas rare de mettre le COD “les” avant le verbe pouvoir suivi d’un verbe à l’infinitif.
          https://www.google.fr/search?q=%22de+les+pouvoir%22&ie=utf-8&oe=utf-8&gws_rd=cr&ei=2bs3VbujLtPjas-4gPAI#q=%22de+les+pouvoir%22&tbm=bks

          Aujourd’hui, on écrit “de pouvoir les exploiter” mais on pouvait écrire autrefois “de les pouvoir exploiter”.

          Mon erreur aurait effectivement pu être détectée (à cause de la répétition de “les”) si j’avais écrit une règle spécifique pour ça. J’ai ajouté ce point à ma liste de cas à étudier. Je suis en général prudent avec l’ajout de nouvelles règles. Il faut toujours essayer de trouver s’il n’y a pas d’autres cas possibles qui pourrait être valides, afin d’éviter les faux positifs.

          • [^] # Re: Erreur

            Posté par  (site web personnel) . Évalué à 3.

            Oui, cela ne doit pas être évident. Est-ce que dans un Français moderne cela serait accepté ? Puis-je encore écrire « de les pouvoir les envoyer » sans que l'on ne puisse me le reprocher ?

            • [^] # Re: Erreur

              Posté par  . Évalué à 3.

              Avec le double "les", ça m'étonnerait que ça passe, ancien comme moderne.

          • [^] # Re: Erreur

            Posté par  (site web personnel) . Évalué à 3.

            Je me demandais aussi : est-ce qu'il serait possible de déclencher des avertissements pour les structures grammaticalement correctes mais peu courantes ? Une erreur classique est d'utiliser un homophone et il serait dommage que le correcteur ne me dise pas : « Hey, c'est correct mais jette quand même un coup d'œil, on sait jamais. », sous prétexte qu'aucune règle n'est transgressée.

            • [^] # Re: Erreur

              Posté par  . Évalué à 5.

              les structures grammaticalement correctes mais peu courantes

              Ça dépend de ce dont il s’agit. Mais oui, probablement.

              Une erreur classique est d'utiliser un homophone

              Il y a quand même une question de ressources, mais ça dépend de ce dont il s’agit. Ce que j’aimerais c’est correcteur orthographique capable de signaler les mots rares ou douteux si l’utilisateur le souhaite, un correcteur orthographique capable de dire : « oui, ça existe, mais… c’est super rare / un anglicisme / un terme vieillot… » Pour l’instant, il peut juste dire si un mot existe ou pas. Et le correcteur grammatical lui-même n’est pas fait pour ça.

    • [^] # Re: Erreur

      Posté par  . Évalué à 3.

      Il faut traiter les données avant de les pouvoir les exploiter.

      (…)

      Grammalecte ne peut pas détecter ce genre d'erreur ? :)

      Ça ne doit effectivement pas être facile à détecter. En tout cas, LanguageTool ne voit rien et quant à Antidote, il voit bien que quelque chose cloche dans la phrase, mais n’arrive pas à indiquer quoi (il indique une rupture au niveau de « de », et n’est donc pas capable d’attribuer le premier pronom personnel « les ». Donc, en lisant l’analyse détaillée, ce qu’on ne fait jamais, il est possible de voir d’où vient le problème. Mais Antidote, lui, ne voit pas).

  • # Extensions et JavaScript

    Posté par  . Évalué à 6.

    Pour rappel, le but est bien d’avoir une extension qui peut fonctionner sans faire appel à un serveur local ou distant. Il faudra tout réimplémenter en JavaScript.

    Une idée pourra être de regarder du côté des langages Pythonesques qui compilent vers JavaScript. Certains ont une syntaxe proche de Python, ce qui pourrait accélérer la conversion. D'autres, comme pypyjs, proposent de une implémentation complète de Python compilée via emscripten vers JavaScript. Cela peut paraître insensé mais au final l'efficacité du code Python est meilleure que l'implémentation officielle du langage et le poids d'une telle conversion (5Mo compressés, quand même) serait moins douloureusement ressentie dans le cadre d'une extension.

    • [^] # Re: Extensions et JavaScript

      Posté par  . Évalué à 4.

      Je n’ai pas l’intention de procéder ainsi. D’abord, parce qu’en l’état des choses, ça ne donnera pas grand-chose d’utile. Pour l’instant, il n’y a pas d’API grammaticale sur Firefox et Thunderbird, on ne peut pas interroger Hunspell pour obtenir les données lexicales (et même si on pouvait, de toute façon, je veux me débarrasser de cette dépendance). Les expressions régulières de Javascript ne permettent pas tout ce que font celles de Python. Grammalecte fait appel souvent à la fonction eval(), car, comme je l’ai dit, il y a du code Python ad hoc dans les règles. Quant aux modules annexes, ils se servent énormément de l’API de LibreOffice. Au final, il n’y a pas tellement de code récupérable tel quel qu’on puisse convertir en JS. Grammalecte, c’est du Python lové tout autour de LibreOffice. On ne l’en ôtera pas en convertissant simplement du code. Et avant même de me lancer dans le JS, il faut refondre les données du dictionnaire, modifier quasiment toutes règles conditionnelles d’analyse, et rajouter toutes les nouvelles règles nécessaires dues changement de format du dictionnaire. J’en oublie probablement.
      Cela dit, je regarderai quand même ce qu’on peut tirer de tes liens.

      • [^] # Re: Extensions et JavaScript

        Posté par  . Évalué à 4.

        Oui bien sûr, le seul intérêt de tels outils est de permettre un emploi des codes Python tels quels (ou d'accélérer le portage). Cela ne résoudra pas le problème des dépendances, à moins de porter également tout ou partie de celles-ci via emscripten.

        Je partage aussi l'idée que, comme cela a été dit ailleurs, une stratégie intéressante consisterait à d'abord produire la version serveur indépendante. Puis de s'y interfacer pour minimiser le code spécifique nécessaire (comme c'est par exemple le cas dans le monde du développement avec des serveurs d'analyse de code comme Jedi pour Python ou Tern pour JavaScript).

  • # Le serveur d'abord ?

    Posté par  (Mastodon) . Évalué à 10.

    Quel boulot déjà effectué, mais aussi quel boulot il reste devant toi ! Bravo… et bon courage.

    Je suis étonné de l'ordre dont tu procèdes. Personnellement je me serai d'abord jeté sur le serveur, qui au passage résoudrait admirablement les soucis de test unitaire (ô combien important, j'en suis persuadé). Ensuite j'aurais développé les modules OpenOffice, Firefox, Thunderbird uniquement en interfaces avec ce serveur.

    Ensuite seulement, j'aurais éventuellement décidé de recoder les différents modules afin d'être autonomes (je ne suis pas personnellement convaincu que ce soit un si grand bienfait, mais je suppose que tu as tes raisons pour ça).

    Peux-tu nous expliquer pourquoi tu as choisi cet ordre ?

    En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

    • [^] # Re: Le serveur d'abord ?

      Posté par  . Évalué à 10.

      Je suis étonné de l'ordre dont tu procèdes. Personnellement je me serai d'abord jeté sur le serveur, qui au passage résoudrait admirablement les soucis de test unitaire (ô combien important, j'en suis persuadé).

      À l’origine, je comptais procéder comme ça. Mais sur Ulule, ils m’ont demandé de découper la campagne en segments. Et j’ai pensé que le port pour Firefox et Thunderbird était bien plus susceptible d’intéresser les gens que le serveur (qui, pensais-je peut-être à tort, ne peut motiver que les plus geeks des geeks). Alors j’ai placé le port pour Firefox et Thunderbird en premier. Mais de toute façon, effectivement, pour faire les extensions pour Firefox et Thunderbird, je suis obligé de commencer par certaines parties qui seront utilisés par le serveur. En fait, même s’il n’y a que le premier palier financé, le serveur verra le jour, puisque c’est lui qui, à la fin, servira de colonne vertébrale à tout le reste. Mais, pour une campagne de financement sur Ulule, je pouvais difficilement embêter les contributeurs avec du prêchi-prêcha technique.

      Donc, la seule raison pour laquelle le serveur sera finalisé après les extensions, c’est le marketing.

      Ensuite j'aurais développé les modules OpenOffice, Firefox, Thunderbird uniquement en interfaces avec ce serveur.

      Je ne suis pas sûr de ce que tu veux dire par là, mais toutes les extensions prévues fonctionneront sans avoir à faire appel au serveur. Le serveur ne servira que pour les tests, les applications sans extensions prévues et en mode autonome.

      • [^] # Re: Le serveur d'abord ?

        Posté par  (Mastodon) . Évalué à 5.

        Je signifiais exactement l'inverse… mais dans un premier temps :) J'ai en tête (sans trop savoir, ce n'est pas vraiment mon domaine de programmation) que réaliser un plugin FF/OOO/Thunderbird ou je ne sais quoi est "facile" une fois que t'as le serveur et qu'il ne s'agit alors que de t'interfacer avec lui.

        Ensuite, si tu veux éviter à l'utilisateur de devoir installer un serveur, tu peux, dans un deuxième temps donc, porter le code du serveur dans ton plugin.

        Mais pour moi, la difficulté de ton projet est essentiellement "métier", c'est à dire dans le moteur grammatical lui-même. Autant l'implémenter une bonne fois pour toutes, dans le confort (par exemple tu choisis le langage comme bon te semble), pour le mettre à la disposition de n'importe quelle appli/plugin.

        En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

    • [^] # Re: Le serveur d'abord ?

      Posté par  . Évalué à -2.

      Comme expliqué dans ce forum http://www.dicollecte.org/thread.php?prj=fr&t=457 c'est un choix lié à la formule de financement participatif : mettre en avant les fonctions sexy (celles susceptibles d'intéresser le plus de monde) en avant :)

      • [^] # Re: Le serveur d'abord ?

        Posté par  (Mastodon) . Évalué à 4.

        … ou comme expliqué par l'auteur il y a 2 heures :)

        C'est triste, mais je le comprend parfaitement. Par contre, je ne suis pas sûr du tout que ça optimise la dépense budgétaire.

        En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

  • # Standalone

    Posté par  (site web personnel) . Évalué à 10.

    Perso, une version standalone sans dépendance à LibreOffice m'intéresserait bien, pour l'instant j'utilise LanguageTool pour vérifier et corriger (quand c'est possible - peu de règles en français sont corrigées automatiquement par LanguageTool) les messages de @dee_plop sur Twitter, mais d'après ce que j'en ai vu, Grammalecte me semble meilleur au moins pour le français.

    Mais tant que Grammalecte dépend de LibreOffice, je ne peux évidemment pas l'utiliser sur mon serveur (toutes les ressources de LibreOffice sont pour l'instant dédiées à la fonction firewall).

    • [^] # Re: Standalone

      Posté par  . Évalué à 4.

      Je suis également très intéressé par une version standelone, ce qui me permettrait de l'utiliser dans vim/neovim en complément de LanguageTool.

      bépo powered

      • [^] # Re: Standalone

        Posté par  . Évalué à 3.

        Je me suis inscrite tout exprès pour dire que moi aussi, je serais très intéressée par une version utilisable dans vim/neovim.

  • # Dépêche très agréable à lire

    Posté par  (site web personnel) . Évalué à 10.

    De l'informatique, de la grammaire, de la typographie, du libre, de l'humour et de la passion. Tout ça dans une seule dépêche, c'est un régal !

  • # Encore un commentaire inutile

    Posté par  . Évalué à 10.

    Oui, ceci est un commentaire inutile. Mais puisque tu as pris le temps de bien écrire une dépêche de qualité, j'ai trouvé normal de prendre un peu de temps pour formuler des compliments aussi sincères que profonds.

    Ah, j'oubliais, c'est très intéressant aussi à lire. Surtout quand on voit les exemples de phrases ambiguës, ça donne à réfléchir sur sa propre langue maternelle.

    • [^] # Re: Encore un commentaire inutile

      Posté par  . Évalué à 6.

      ça donne à réfléchir sur sa propre langue maternelle.

      Je ne vais pas parler de ça. C’est encore plus trollogène que systemd. :)

  • # IA

    Posté par  . Évalué à 10.

    J'imagine que des millions de personnes y ont pensé avant, mais au vu des problèmes très difficiles que posent les correcteurs de grammaire "algorithmiques", est-ce qu'il ne serait pas plus efficace d'utiliser des IA connectées à des bases de données et entrainées sur un corpus lexical représentatif de la langue (des milliers de livres, par exemple) pour détecter les erreurs, indiquer les tournures douteuses, et lever les ambiguités? La différence entre "Il est conseiller à la mairie" et "Il est aller à la mairie", c'est surtout un rapport de 10000:1 sur Google, par exemple. C'est comme ça que notre cerveau fonctionne, les bouts de phrase semblent "naturels" quand on les a lus des centaines de fois. Si, au moment de l'analyse syntaxique de la phrase, il était possible de se concentrer sur les tournures inhabituelles, ça permettrait de réduire énormément le taux de faux positifs.

    • [^] # Re: IA

      Posté par  . Évalué à 4.

      Je ne m’appelle pas Google. Je n’ai pas des fermes de serveurs prêts à répondre à toutes les questions bizarres des gens. :D

      Cette solution ne peut guère être mise en œuvre qu’avec beaucoup de ressources ou en offrant un énorme logiciel à télécharger.

      Ensuite, je ne sais pas si on peut enseigner une IA à faire ça proprement. Je ne connais pas le domaine. À moins que l’IA soit vraiment habile, j’imagine qu’il faudra lui enseigner les types d’erreurs possibles et les suggestions à faire. J’ai un peu l’impression qu’on finirait par faire plus ou moins ce que je fais.

      • [^] # Re: IA

        Posté par  . Évalué à 4. Dernière modification le 22 avril 2015 à 13:19.

        J'imagine qu'on est un peu à la frontière entre la recherche et les solutions vraiment fonctionnelles, et je suis conscient que, dans une certaine mesure, certaines solutions peuvent être inapplicables. Cependant, je ne pense pas qu'une base de données d'expressions prenne forcément beaucoup de place: une fois le vocabulaire indexé, il suffit de construire une base de données d'enchainements de mots, et ça fait beaucoup, beaucoup moins de combinaisons qu'on pourrait estimer par une analyse mathématique. Un correcteur basé sur des constructions grammaticales comme le tien doit déja, j'imagine, avoir une telle base, histoire de ne pas mettre du rouge partout sur les expressions non-grammaticales ("il faut raison garder", "autant que faire se peut", "entre quatre-z-yeux", etc). Il est clair que "est aller" n'est pas une expression correcte, alors que "est conseiller" l'est ; plutôt que d'essayer de construire une bdd hyper-complexe sur les catégories grammaticales des mots (verbe transitif sauf au passé simple dans l'expression xxx, sauf s'il y a un attribut du sujet), ma flemmardise naturelle me pousserait à concevoir une bdd automatiquement en analysant des textes, quitte à éventuellement limiter la taille de la base quand on la distribue. Rien que la liste des doublets de mots possibles corrigerait, à mon avis pifométrique, une majorité des erreurs de grammaire. D'ailleurs, tous les exemples que tu as cités seraient corrigés avec une bdd de doublets de mots corrects : le coup des "erreurs materiels", le coup de "est aller", etc. Et une telle base prendrait que dalle en espace disque (probablement moins que l'index des mots).

        • [^] # Re: IA

          Posté par  . Évalué à 3.

          Un algo qui va dénicher les erreurs sur une base statistique, ça me semble audacieux, et, en plus, il ne prend pas beaucoup de place. Oui, j’avoue que ça me laisse dubitatif, mais je ne demande qu’à voir. :)

          Sur Google n-grams, tu as des listes de successions de mots référencés dans les livres:
          http://storage.googleapis.com/books/ngrams/books/datasetsv2.html

          Ça permet de voir l’évolution de l’emploi du vocabulaire au fil du temps :
          https://books.google.com/ngrams

          • [^] # Re: IA

            Posté par  (site web personnel) . Évalué à 4.

            Je pense qu'une analyse statistique peut être intéressante. Concernant par exemple l'étiquetage morphosyntaxique, on utilise les modèles de Markov cachés qui reste un outil statistique auquel on va lui apprendre (il semble d'ailleurs possible de faire de l'apprentissage semi-supervisé) l'étiquette que peut avoir le mot. Cela m'étonnerait pas que tu en trouve dans les autres correcteurs orthographiques puisque c'est typiquement un outil qu'on utiliserait dans la phase d'analyse lexicale d'une langue naturelle.

            Bien entendu, il y a une limitation de moyen derrière. Certains laboratoires de recherche comme le LIRMM ont des BDDs contenant une centaine d'articles du journal Le Monde auxquels des linguistes ont étiquetés chaque mot. Mais cela ne veut pas dire qu'il ne faut pas creuser de ce côté !

    • [^] # Re: IA

      Posté par  . Évalué à 5.

      Linguee utilise cette approche pour la traduction.

      http://www.linguee.fr/

      C'est assez intéressant pour les expressions comme "to burn the midnight oil" (un exemple que l'androïde Data a du mal à comprendre dans Star Trek).

      http://www.linguee.fr/francais-anglais/search?query=I%27m+burning+the+midnight+oil.
      https://translate.google.fr/?hl=fr#en/fr/I%27m%20burning%20the%20midnight%20oil.

  • # joli travail !

    Posté par  (site web personnel) . Évalué à 5.

    Bon travail ! Vu le nombre de fautes que j'écris, je pensais en écrire un, un jour :)

    Juste une suggestion à faire entre le préprocesseur et le passage des règles : pourquoi ne pas chercher à étiqueter chaque mots avec son type grammatical précis ? Cela aiderait beaucoup les règles suivantes. Tu te bases uniquement sur le mot pour faire ton choix, mais si tu prends une phrase entière, les choix réels diminuent fortement.

    Ensuite, tu peux utiliser quelques heuristiques (niveau de langage du reste du texte, qui permet de choisir une des signification plutôt qu'une autre, domaine de langage du reste, etc…).

    Au lieu de chercher à réduire à une étiquette par mot, je laisserai l'ensemble des possibles (pourquoi pas avec un pourcentage de probabilité) et je couperais les étiquettes fausses si on prend la phrase entière. Les probabilités peuvent servir pour trier les suggestions de correction.

    "La première sécurité est la liberté"

    • [^] # Re: joli travail !

      Posté par  . Évalué à 6.

      pourquoi ne pas chercher à étiqueter chaque mots avec son type grammatical précis ?

      C’est ce que je vais faire à l’avenir. Je pensais qu’il était nécessaire de tokeniser pour ça, puisque c’est ce que font les autres correcteurs grammaticaux. Ça m’a longtemps fourvoyé. Mais Grammalecte suivant une autre logique (pas de tokenisation), j’étais réticent à procéder de la sorte (pour une question de performances). Mais à présent que je sais comment étiqueter sans tokeniser (avec ce que j’ai appelé “désambiguïsateur multi-passes sans tokenisation” dans le billet), ça va se faire.

      Ensuite, tu peux utiliser quelques heuristiques (niveau de langage du reste du texte, qui permet de choisir une des signification plutôt qu'une autre, domaine de langage du reste, etc…).

      Stop. On est vraiment encore très loin de pouvoir faire ça. Seules 12 % des entrées du dictionnaire sont sémantiquement étiquetées.

      Au lieu de chercher à réduire à une étiquette par mot, je laisserai l'ensemble des possibles (pourquoi pas avec un pourcentage de probabilité)

      Une chose à la fois. Il faudrait déjà que je dispose d’un indice de fréquence fiable, ce qui n’est pas le cas. Par ailleurs, l’intérêt du désambiguïsateur, c’est d’étiqueter sur des certitudes. Les probabilités ne seront utilisées un jour que lorsque le désambiguïsateur ne suffira pas.

      Les probabilités peuvent servir pour trier les suggestions de correction.

      Pas en grammaire. Mais sur les mots mal orthographiés, oui. Encore faudrait-il avoir un correcteur orthographique qui puisse se servir de ça.

  • # outils python pour le tagging et l'analyse grammaticale

    Posté par  . Évalué à 10.

    Bonjour Olivier,

    Merci pour cet article intéressant. Et merci pour Grammalecte, qui comble un manque important dans l'univers du Libre francophone.

    J'avais travaillé au début des années 2000 des outils de traitement du langage naturel, en Python, basés sur le livre "Speech and Language Processing: An Introduction to Natural Language Processing, Computational Linguistics and Speech Recognition" de Dan Jurafsky et James H. Martin. Je ne trouve pas le code sur http://www.logilab.org/ (société pour laquelle je travaillais à l'époque), mais peut-être qu'en leur demandant gentiment, les responsables actuels accepteraient d'ouvrir le code pour inclusion dans grammalecte (Logilab est une société attachée à l'Open Source et je ne pense pas qu'ils valorisent ces entrepôts de code actuellement).

    On y trouvait en particulier un tokeniseur (simpliste) et un parser de Earley (http://fr.wikipedia.org/wiki/Analyse_Earley), et un embryon de grammaire française, qui pourraient peut-être utile pour la tokenisation dans Grammalecte.

  • # spaCy Industrial-strength NLP

    Posté par  . Évalué à 3.

    J'ai vu ce projet il n'y a pas longtemps :https://honnibal.github.io/spaCy/.
    Je n'ai pas encore vraiment regardé, mais c'est peut-être une solution intéressante sur laquelle s'appuyer pour faire un tokenizer et plis si affinité…

  • # On dirait de la compilation ... mais en plus difficile

    Posté par  (site web personnel) . Évalué à 9.

    Super chouette article, merci de partager cela. La partie technique me fait penser aux techniques de compilation : tokenisation, reconnaissance de motifs, optimisations (suppression ou remplacement de motifs par d'autres). Quelques remarques qui peuvent t'intéresser ou pas :
    - Tu opposes le traitement par tokenisation et l'analyse de zones de textes. En réalité tu n'as pas besoin de choisir, tu peux avoir les deux, vu que d'une série de tokens tu sais revenir à un morceau de texte brut (si ta tokenisation ne perd pas d'information importante), et d'un morceau de texte brut retourner à une séquence de tokens
    - En compilation, les tokens ne sont en général pas conservés sous forme de séquence mais sous forme d'arbre (Arbre de syntaxe concrète et/ou abstraite) en fonction de règles de … grammaire.
    Les différentes passes de vérification (pare exemple le typage) se font sur ces arbres.
    - Quand tu as des ambiguïtés que tu ne peux résoudre, rien ne t'empêche d'avoir des branches OU dans ton arbre, du type
    (Sujet (Article * Nom * Adjectif) | (Sujet (Article * Adjectif * Nom))) * Verbe * Complément
    - Certains langages sont mieux équipés que d'autres pour ce genre de traitements. Un langage proposant de la reconnaissance de motifs en natif est d'une valeur inestimable. Je connais et utilise ocaml qui a fait ses preuves dans ce domaine, mais je suis sur qu'il en existe plein d'autres. Il est possible/facile de générer du js de manière efficace depuis du code ocaml avec js_of_ocaml.

    • [^] # Re: On dirait de la compilation ... mais en plus difficile

      Posté par  . Évalué à 8.

      Pour m'être brièvement intéressé à la question de l'analyse grammaticale, l'analyse syntaxique de langue naturelle est beaucoup plus compliquée que celle pratiquée dans les compilateurs: la plupart des grammaires des langues naturelles sont des grammaires contextuelles fort propices aux ambiguïtés. Pour le peu que je comprend le sujet, il semble exister une recherche fort active sur cette question autour des grammaires d'arbres adjoints et le développement de méta-grammaires pour générer automatiquement des grammaires à partir d'un corpus de texte.

      Par contre, les applications pratiques de ces modèles pour faire de la correction grammaticale semblent manquer. Il est d'ailleurs un peu déconcertant de voir grammalecte utiliser des simples expressions régulières pour faire de l'analyse grammaticale. Enfin, le pragmatisme a ses vertus.

      • [^] # Re: On dirait de la compilation ... mais en plus difficile

        Posté par  . Évalué à 6.

        Et ses limites, ça devient vite un sac de noeud de l'aveu même de l'auteur ou il ne peut toucher à un truc sans être sur d'en casser un autre et ou c'est difficile de se plonger dans la base de code :)

      • [^] # Re: On dirait de la compilation ... mais en plus difficile

        Posté par  . Évalué à 10.

        Je n’ai aucune prétention académique. Je suis parti sur les bases existantes que j’ai trouvées et j’ai amélioré, transformé, supprimé, ajouté tout ce qui me semblait nécessaire au fur et à mesure que les problèmes se présentaient. Comme le logiciel a toujours eu bon accueil, j’ai continué. Des papiers théoriques sur la correction grammaticale, j’en ai vu passer pas mal, et pour ce que j’en ai lu, ça m’a paru souvent assez éloigné de ce que je faisais et parfois assez éthéré, même si ça pouvait donner des idées. Finalement, je n’en ai pas retenu grand-chose. Grammalecte doit faire avec ses propres limites, son propre potentiel, et ça ne correspond pas à ce dont les papiers parlent en général.

        Par ailleurs, j’ai tendance à penser qu’il est difficile de croire aux solutions qu’on ne met pas en œuvre. Il faut mettre les mains dans le cambouis pour constater les innombrables micro-problématiques auxquelles il faut faire face. Je l’ai dit, mais je n’ai sans doute pas assez insisté sur ce point : les détails sont vraiment ce qui prend le plus de temps.

    • [^] # Re: On dirait de la compilation ... mais en plus difficile

      Posté par  . Évalué à 4.

      Tu opposes le traitement par tokenisation et l'analyse de zones de textes. En réalité tu n'as pas besoin de choisir, tu peux avoir les deux

      En effet, mais puisque je me suis passé de tokenisation jusqu’à présent, ça me semblait bête de l’introduire maintenant. Ce n’est pas une opération négligeable en termes de ressources. Découper chaque phrase en tokens, les mémoriser, les étiqueter, les classer, etc. ce n’est pas rien. Du coup, ma solution d’étiquetage, qui se passe de tout ça, est plus simple.

      Avec le préprocesseur de texte, on part sur une logique opposée à l’arborescence. Au lieu de composer des syntagmes étiquetés, on réduit les syntagmes à leur plus simple élément, voire on les élimine complètement quand ils ne servent plus.

      Si un jour, je fais de la tokenisation dans Grammalecte, il sera sans doute cohérent de revoir complètement son mode de fonctionnement.

  • # Linguistes ?

    Posté par  . Évalué à 5.

    Bravo pour ce travail énorme et pour ce journal très détaillé.
    Est-ce qu'il ne serait pas utile, pour améliorer encore cet outil, de trouver des collaborations avec des linguistes ou des enseignants dans ce domaine ? La collaboration pourrait se révéler fructueuse !

    • [^] # Re: Linguistes ?

      Posté par  . Évalué à 4.

      Je lis le blog des correcteurs du Monde, peut-être seraient-ils intéressés de savoir qu'une telle application existe, ne serait-ce que pour en parler ou pour l'améliorer ?

    • [^] # Re: Linguistes ?

      Posté par  . Évalué à 8.

      Quand je veux savoir quelque chose que je ne sais pas, j’utilise Google pour trouver des papiers, des idées, etc. Le Net regorge déjà de ressources. Il y a déjà plus de choses à lire que je n’ai de temps à y consacrer. :)

      Par ailleurs, ne prenez pas Grammalecte pour ce qu’il n’est pas. C’est encore un petit projet, avec des mécanismes simples, une mise en œuvre basée sur un déroulé d’opérations qui vise à la simplification du texte. Mais je passerais plus de temps à expliquer ce que ça fait dans le détail qu’à améliorer l’existant. Ce que j’ai décrit dans l’article, c’est assez grossièrement ce qui se passe vraiment. Je vous assure que s’occuper d’un correcteur grammatical, c’est gérer des détails, encore des détails, des cas particuliers, des exceptions et des exceptions aux exceptions, etc. Et si l’amélioration d’un correcteur peut ressembler, vu de loin, à la composition d’un bel algorithme qui va résoudre tous les problèmes, soyez sûrs que c’est une illusion.
      Prenons le cas du désambiguïsateur que je prévois de créer, son code devrait être relativement rapide à concevoir. En revanche, écrire toutes les règles nécessaires va nécessiter la mise au point d’innombrables détails, comme réviser les règles existantes.
      Tout ça pour dire que les pauvres linguistes à qui je pourrais demander un avis vont me regarder bizarrement si je leur dis : « Voudriez-vous lire ces milliers des règles écrites sous forme d’expressions régulières avec du code inclus dedans et me dire ce que vous en pensez ? Ah oui, et ces étiquettes, c’est codé, voilà la traduction en clair… J’espère que vous comprenez le Python… »

  • # Licence

    Posté par  (site web personnel) . Évalué à 5.

    Avant de donner, sur ullule, il me manque une mention à propos de la licence qui sera choisie pour les divers composants (serveur, modules…). De plus, l'en-tête du site parle d'open source alors qu'il pourrait parler de libre puisque ce qui existe déjà est sous GPL et MPL.

    Merci.

    • [^] # Re: Licence

      Posté par  . Évalué à 3.

      Lightproof est publié sous triple licence: GPL 2.0/LGPL 2.1/MPL 1.1 + les versions ultérieures. Ça m’a toujours ennuyé d’avoir autant de licences. Donc j’avais choisi la GPL 3 pour être tranquille, mais sans y réfléchir vraiment, pour tout dire, avec l’idée d’en changer si besoin. Mais je n’y ai plus du tout songé depuis lors.

      Cela dit, dans mon esprit, en fait, la GPL, c’est seulement pour les règles d’analyse du français. Pour tout le reste, c’est-à-dire le code lui-même, le dictionnaire, les modules annexes, la MPL 2 me convient tout à fait.

      Comme c’est la deuxième fois qu’on me pose la question, je présume que ça a une importance qui m’échappe.

      Du coup, pour éviter les prises de tête, je vais tout mettre tout ce que je peux en MPL 2.
      J’imagine que ça concerne l’ensemble, sauf le dictionnaire des synonymes et le dictionnaire des césures qui resteront en LGPL (je n’ai aucun droit sur ça).

      • [^] # Re: Licence

        Posté par  (site web personnel) . Évalué à 3.

        Ma question était de prime abord de savoir si le code serait libre ou non (parce que ce n'était pas dit ou je n'ai pas vu), parce que je veux donner à du code libre ;)
        Ensuite, le choix, je le laisse à ta discression en fonction des contraintes que tu as et des libertés que tu veux donner aux utilisateurs.

        Merci ! :)

        • [^] # Re: Licence

          Posté par  . Évalué à 9.

          Alors, oui, le code sera libre. :)

  • # wictionnaire

    Posté par  . Évalué à 3.

    En complément d'Hunspell, tu pourrais peut-être utiliser le wictionnaire. En général il donne une version phonétique des mots, ce qui permettrais de donner des suggestions en cas d'homonymes.

    bépo powered

  • # Debian

    Posté par  . Évalué à 3.

    Super projet, d'autant que refaire tout ça en javascript permettrait aussi de l'utiliser dans des applications firefox os (et android).

    Sinon, je remarque qu'il n'y a pas de paquet debian pour Grammalecte. C'est pas tellement que je ne peux pas installer une extension à la main, mais j'ai l'impression qu'il n'y a du coup pas de compatibilité :
    Avec libreoffice 4.3 et grammalecte 0.4.9, tout marche … sauf la correction grammaticale (note : j'ai bien python3 installé et j'ai supprimé mon profile libreoffice au cas où).

    • [^] # Re: Debian

      Posté par  . Évalué à 4.

      Il faut veiller à ce qu’il y ait Python 3, mais aussi à ce que ce soit la «passerelle Python-UNO» pour Python 3 qui soit installée. Ce que tu dis me fait penser que LO utilise peut-être Python 2, qui, j’imagine, est installé parallèlement à Python 3.

      • [^] # Re: Debian

        Posté par  . Évalué à 1.

        C'était ça (python3-uno), merci !
        Il faudrait peut-être l'indiquer quelque-part.

        Par contre, je note qu'il corrige

        Ils écrivez.

        Mais pas

        Nous écrivez.

        Je sais que nous peut-être parfois ambigu, mais pas ici.

        • [^] # Re: Debian

          Posté par  . Évalué à 4.

          Nous écrivez.

          Je sais que nous peut-être parfois ambigu, mais pas ici.

          Peut-être à cause de formules du genre : « Vous nous écrivez que vous avez rencontré un problème avec systemd. Mais ce que vous nous écrivez n'a ni queue ni tête blabla… », etc ?

          • [^] # Re: Debian

            Posté par  . Évalué à 1.

            Oui mais là il n'y a pas d'ambiguïté, il n'y a rien d'autre dans la phrase.

            • [^] # Re: Debian

              Posté par  . Évalué à 9.

              En effet. Mais ici il faut que j’aborde la stratégie du correcteur.

              Il existait à un moment une règle pour les cas comme “nous écrivez”, puis je l’ai assez rapidement supprimée. Car il y a des tas de cas où cette suite de mots est correcte. Par ailleurs, ce n’est pas une erreur que les gens font usuellement. Il y a vraiment des tas d’autres erreurs bien plus communes que celles-là. Qui écrit “nous écrivez” au lieu de “nous écrivons”? Il y a rarement des erreurs sans confusion basée sur la phonétique. En bref, les ressources sont limitées. Je préfère les consacrer à autre chose.

              J’ai le sentiment que, cette erreur, les gens ne la font que lorsqu’ils veulent tester le correcteur (on ne m’en parle qu’à ces moments-là). Finalement, pour la crédibilité du correcteur, ça a peut-être un intérêt, mais juste pour ça. :)

              • [^] # Re: Debian

                Posté par  . Évalué à 2.

                Probablement, merci pour les explications ;)

              • [^] # Re: Debian

                Posté par  . Évalué à 0.

                Qui écrit “nous écrivez” au lieu de “nous écrivons”?

                Un non francophone?

              • [^] # Re: Debian

                Posté par  . Évalué à 2.

                Je me disais bien aussi… ce n’est pas si simple, j’aurais dû vérifier avant de répondre.
                J’avais donc bien créé ces règles, puis je les ai supprimées. Et, bien plus tard, j’ai fini par les réintégrer sous une forme a priori avec de peu de risques d’erreur. Mais il se trouve que certaines règles du préprocesseur les rendent inopérantes. À revoir donc.

  • # Suggestion : Correction grammaticale de texte latex

    Posté par  . Évalué à 8.

    Je réalise qu'une extension possible grâce à ton préprocesseur serait de pouvoir faire de la correction de grammaire d'un texte en latex. Actuellement j'utilise LanguageTool dans vim, et pour un texte d'environ une page, j'ai déjà une centaine de faux positifs ! En ajoutant une passe à l'étape 0 qui vire toutes les macros, on pourrait donc les éviter facilement.

    bépo powered

    • [^] # Re: Suggestion : Correction grammaticale de texte latex

      Posté par  . Évalué à 6. Dernière modification le 22 avril 2015 à 14:31.

      En ajoutant une passe à l'étape 0 qui vire toutes les macros, on pourrait donc les éviter facilement.

      Oui.
      C’est aussi grâce à ça que le correcteur va fusiller les balises HTML qui croiseront son chemin. :)

  • # Recherche par index phonetique

    Posté par  . Évalué à 5. Dernière modification le 22 avril 2015 à 14:17.

    Tu dis: "Le correcteur ne sait pas où chercher une conjugaison adéquate. Pour parfaire le système de suggestion, il faudrait établir des passerelles entre tous les mots grammaticalement distincts sur leurs liens phonétiques éventuels."

    Il me semble qu'il existe dans les entrées du dictionnaire un représentation phonétique de chaque mot (sinon, ces dictionnaires existent en opensource, par exemple chez eSpeak pour la synthèse vocale, LLIUM pour la reconnaissance vocale, etc…).
    Du coup, en ajoutant une n-ième passe au préprocesseur (lors de la détection d'une erreur), qui aurait pour entrée l'index des mots en "phonétique" qui, par définition est un mapping 1:n, pourrait lors d'un mot incongru (Il s'en "fou"), chercher si un des résultats pour l'entrée phonétique "fu" pourrait convenir. Dans ce cas aussi simple, il trouverait immédiatement le verbe conjugué, et n'aurait plus qu'à choisir la bonne conjugaison parmi "fous, fout".

    Après, avec un TernarySearchTree indexé sur les clés phonétiques, on pourrait même envisager une recherche approximative (type Levenshtein, distance de Hamming) pour trouver des mots dont la phonétique est "proche" de l'item erroné - Cela ne donnerait pas de faux positif puisque ceci démarrerait uniquement sur détection d'une erreur, tel qu'actuellement. On est alors clairement dans l'aide à l'utilisateur, au lieu de détecter une erreur et de ne pas savoir quoi suggérer, on pourrait envisager un menu "Ils son faux." => "son" est erroné, vouliez vous dire "sont", "sonnent" etc…

    Concernant "Il est aller à la mairie", je pense qu'une dernière passe de pre-processing utilisant la technique des n-gram, (c'est à dire la découpe en entités de 3/4 lettres), puis comparaison avec un modèle statistique du langage (tel que fournis par Google en opensource), repèrerait l'incongruité statistique de la suite "est aller". C'est ce que fait Google pour ses suggestions de correction de recherche. Il faut définir des seuils (donc risque de faux positifs) quitte à laisser le seuil à 0 par défaut et laisser les utilisateurs aventureux à monter le seuil.

  • # Compétition

    Posté par  (site web personnel) . Évalué à 5.

    Il se compare comment au niveau de la correction de syntaxe, grammaticale… face à

    Cordial
    Antidote
    Prolexis
    Correcteur 101 (semble abandonnée)

    www.solutions-norenda.com

    • [^] # Re: Compétition

      Posté par  . Évalué à 5.

      Je ne possède aucun des logiciels ci-dessus. Je présume qu’ils sont meilleurs. Le numéro de version de Grammalecte se veut assez réaliste. Il y a encore beaucoup à faire.

  • # Biens mé...

    Posté par  (site web personnel) . Évalué à 4.

    J sui pa sur ke sa sere à tou le monde !! :-o

    PS : O fète, sa veu dir koi quan lé mos ke j écrie son pa souligner en rouge ?

  • # Utilisation dans l'administration

    Posté par  . Évalué à 4.

    Sur la page ulule tu évoques l'utilisation de grammatical dans l'administration, est-ce que tu en sais plus ? À quelle échelle ? As-tu des retours de leur part ?

    Ce qui me fait d'ailleurs pensé que j'apprécierai que mes impôts financent de tels projets (d'intérêt public) plutôt que des produits privés qui ne profiterons pas aux contribuables.

    En ce qui concerne l'implémentation des tests, je pense qu'il est déjà possible de créer quelques cas unitaires qui se focalisent sur des fonctions élémentaires (c'est d'ailleurs une bonne pratique dans le domaine de commencer ainsi,) puis sur des fonctions un peu plus évolués et ainsi de suite (par exemple, les deux premières phases du préprocesseur ne font, a priori, pas appel au correcteur orthographique.
    Enfin, une autre technique serait le bouchonnage, pour simuler les appels au correcteur orthographique et renvoyer les valeurs attendues pour une petite liste de terme.

    J'entends bien que ce n'est pas la solution idéal, mais c'est un premier pas qui t'aidera un peu dans l'immédiat et qui te permettra également de développer plus rapidement tes tests lorsque tu sera en mesure d'utiliser une implémentation complète.

    Toujours dans le même sujet, tu utilise un corpus d'erreurs grammaticales, est-ce toi qui l'a créé ? Car il en existe quelques-uns qui ont été créés dans le but justement de tester des outils de vérification grammaticale. ;)

    PS : vu l'heure, j'affirme, sans trop prendre de risque que, oui, j'aurai bien besoin d'une intégration de grammalecte dans Firefox. :°

    • [^] # Re: Utilisation dans l'administration

      Posté par  . Évalué à 5.

      Sur la page ulule tu évoques l'utilisation de grammatical dans l'administration, est-ce que tu en sais plus ? À quelle échelle ? As-tu des retours de leur part ?

      Sauf erreur de ma part, Grammalecte est installé dans la version de LibreOffice du SILL (Socle Interministériel de Logiciels Libres). Les administrations et institutions publiques qui installent LibreOffice le font en principe à partir du SILL et donc disposent de Grammalecte.

    • [^] # Re: Utilisation dans l'administration

      Posté par  . Évalué à 6.

      Sur la page ulule tu évoques l'utilisation de grammatical dans l'administration, est-ce que tu en sais plus ?

      Grammalecte fait partie du socle interministériel des logiciels libres. Il est utilisé dans certaines administrations, mais je ne sais plus lesquelles.
      https://references.modernisation.gouv.fr/sites/default/files/SILL-2015-socle-interministeriel-logiciels-libres.pdf

      Grammalecte fait aussi partie du DVD fourni par MIMO.
      http://www.journal-officiel.gouv.fr/mimo/

      À quelle échelle ? As-tu des retours de leur part ?

      À quelle échelle, je ne sais pas. En janvier 2012 et en juin 2013, j’ai fait une présentation de Grammalecte lors de la réunion interministérielle du groupe MIMO. À part ça, j’ai eu peu de contacts avec l’administration.
      Il y a environ deux ans, quelqu’un qui a une adresse au Développement Durable (probablement la personne chargée d’évaluer les versions à déployer) m’a rapporté des problèmes avec le correcteur, et c’est à partir de ce moment que j’ai commencé à mettre en place une procédure de tests un peu plus sérieuse. Mais c’est tout.

      les deux premières phases du préprocesseur ne font, a priori, pas appel au correcteur orthographique.

      Toutes les passes font appel au correcteur orthographique. Ce que j’ai décrit est une version simplifiée de ce qui se déroule vraiment.

      tu utilise un corpus d'erreurs grammaticales, est-ce toi qui l'a créé ?

      Oui. Je teste ce que le correcteur est censé détecter (ce point est à améliorer). Et je conserve surtout une batterie de faux positifs déjà rencontrés pour éviter qu’ils reviennent.

      • [^] # Re: Utilisation dans l'administration

        Posté par  (Mastodon) . Évalué à 10.

        Je le déploie dans un Établissement Public Administratif rattaché au ministère de la culture sur environ 400 postes de travail. C’est relativement récent (la gestion du packaging était moins souple et on utilisait une version « obsolète » d’OpenOffice.org précédemment).
        La suite étant installées en parallèle de celle de Microsoft, j’ai pu faire quelques comparaisons du correcteur grammatical. Je retrouve au doit mouillé les mêmes taux de détection / faux positifs, mais les erreurs détectées ne se recouvrent pas tout à fait. Par contre, Grammalecte est bien plus strict et pertinent sur la typographie (au passage, serait-il possible de détecter les doubles retours à la ligne et de suggérer de régler les interlignes dans le style de paragraphe ?).

        En tout cas, merci pour ce super boulot.

        Concernant la mise en place des tests, tu as pensé à en faire en automatique en pilotant un LibreOffice headless (ouverture des fichiers de référence, lancement d’une correction automatique, enregistrement en tant que fichier texte, diff avec le résultat attendu) via l’API UNO ?

        • [^] # Re: Utilisation dans l'administration

          Posté par  . Évalué à 3.

          Bonne idée pour les tests unitaires.

          • [^] # Re: Utilisation dans l'administration

            Posté par  . Évalué à 4.

            --pedantic: Ce type de test n'a rien d'unitaire. Ce sont des tests end-to-end.

            Ça parait très bien quand tu t'es foiré et que ton design ne te permet pas de faire des tests unitaires ou d'intégration, mais ce que ça provoque en vrai ce sont des tests suites extrêmement lentes et des causes d'échecs difficiles à analyser.

            Le lecteur intéressé pourra trouver pleins de choses intéressantes en cherchant "test(ing)? pyramid" dans son moteur de recherche préféré.

            • [^] # Re: Utilisation dans l'administration

              Posté par  . Évalué à 4.

              Tu as tout a fait raison pour la pyramide des tests et sur le fait que ce ne sont pas des tests unitaires.

              Cependant, il faut comparer cette solution avec l'existant a base de vérifications manuelles.
              Je trouve que l'approche présentée par Landry MINOZA permettrait d'avoir des aujourd'hui des tests automatisés, bien plus sûrs et rapides que les vérifications manuelles. Certes ce n'est pas l’idéal, mais ce serait déjà un grand pas en avant à mon humble avis.

              Lorsque le code s'y prêtera mieux (avec un bon design comme tu le soulignes), alors il sera toujours possible de passer sur des tests vraiment unitaires.
              Mais ce jour n'est pas encore là.
              D'ailleurs c'est un des buts du financement participatif présenté dans la dépêche.

        • [^] # Re: Utilisation dans l'administration

          Posté par  . Évalué à 4.

          serait-il possible de détecter les doubles retours à la ligne et de suggérer de régler les interlignes dans le style de paragraphe ?

          Non, le correcteur grammatical n’a aucun pouvoir sur les styles et le formatage, il ne voit le texte que paragraphe par paragraphe et il ne choisit pas l’ordre dans lesquels les paragraphes lui sont passés.

          Le formateur de texte pourrait en revanche supprimer les paragraphes vides.

          tu as pensé à en faire en automatique en pilotant un LibreOffice headless

          Non, je n’y avais pas pensé. Je n’ai jamais essayé le mode headless. Maintenant je vais attendre la fin de la campagne. :)

  • # Prolog et Chercheurs ?

    Posté par  (site web personnel) . Évalué à 2.

    Salut, super travail.

    Je comprends bien que tu as écrit Grammalecte en Python pour des cotés pratique et d'interfaçage avec LO et OOo.

    Cependant, pour ta nouvelle version (le fameux serveur) envisages-tu d'utiliser un langage d'IA (par exemple, Prolog ou Lisp) qui est adapté à ce genre de choses ?
    Comme l'a suggéré lucio, tu pourrais prendre contact avec des chercheurs avec qui tu pourrais travailler. Je connais le département Informatique et Intelligence Artificielle de Luminy (à Marseille - j'y ai fait mes études), et certains chercheurs travaillent sur la reconnaissance du langage naturel : il y aurait peut-être une synergie à créer ?
    Certains passages de ton article m'ont rappelé mes années d'étudiants (je ne fais plus d'IA depuis que j'ai quitté la Fac).

    Bonne continuation.

    • [^] # Re: Prolog et Chercheurs ?

      Posté par  . Évalué à 8. Dernière modification le 23 avril 2015 à 19:46.

      Ce que j’envisage, pour l’instant, c’est de faire ce qui est décrit dans la campagne de financement. Et c’est déjà pas mal. Comme je l’ai dit plus haut, je n’ai pas de prétention académique. J’essaie de résoudre les problèmes un par un en pensant à l’étape n+1 quand certains problèmes sont trop compliqués à résoudre en l’état actuel des choses. J’ai commencé en tâtonnant un peu, mais depuis lors j’ai avancé et j’ai les idées plus claires avec une feuille de route déjà bien chargée. Je n’ai pas le temps de me documenter sur les problèmes qui ne sont pas encore à ma portée, car il y a déjà toujours quelque chose à améliorer en l’état. Les questions d’IA, j’en suis très loin. Je constate effectivement, parmi les limitations du correcteur, qu’il bute sur les ambiguïtés sémantiques, mais ça c’est l’étape n+2. Il faudrait déjà résoudre les ambiguïtés grammaticales. Bref, je ne vais éviter de mettre la charrue avant les bœufs. Grammalecte est encore un petit projet.

  • # Bravo!

    Posté par  . Évalué à 4.

    Bravo pour ton travail Olivier!
    Bravo pour la dépêche très détaillée!

    En plus, tu as devancé ma question sur la comparaison avec LanguageTools :)

    C'est rigolo, il y a un gros parallèle entre ce que tu fais et ce que je fais (http://linuxfr.org/redaction/news/modernisez-votre-code-java-en-un-clic-avec-autorefactor-v1-0-0, hum dépêche à compléter).
    J'ai la chance de pouvoir travailler sur un langage informatique d'où une syntaxe très bien définie (je ne parle pas du C++ ;) ). Je peux m'appuyer sur Eclipse JDT pour les analyses lexicales, syntaxiques et sémantiques (analyse des types, des variables, etc.).
    Malheureusement, la langue naturelle n'est pas aussi logique, et le processus classique des compilateurs ne fonctionnent pas ou difficilement.
    Je te tire mon chapeau pour oser t'attaquer à ce problème très difficile.

    Ton analyse en plusieurs passe qui transforme le texte est une idée très intéressante pour palier aux multiples formes que permet un langage naturel. Merci d'en avoir expliqué le concept.
    Comme tu l'as fait remarquer, j'y vois hélas un inconvénient majeur: c'est lorsqu'il s'agit de rapporter les erreurs sur du texte modifié.
    Les compilateurs transforment plusieurs fois le code source en interne pour finalement parvenir à générer du code. GCC a au moins 3 représentations internes: GIMPLE => GENERIC => RTL .
    Pour pouvoir correctement rapporter les erreurs a n'importe quel moment de la phase de compilation, il est impératif de pouvoir toujours revenir vers le texte initial en gardant des marqueurs ou des informations de localisation sur le texte source original. C'est aussi ce qui est fait dans le code généré pour pouvoir se référer au code source original lors de séances de débogage (Voir DWARF ou les source maps en javascript).
    C'est comme ça que le problème est résolu dans les compilateurs. Je ne sais pas si c'est applicable a ton cas ou bien si cela ferait exploser la consommation mémoire, mais bon je me suis dit que ça pourrait être utile d'en parler.

    Sur l'utilisation des expressions rationnelles, je sais a quel point cela peut être difficile. J'ai commencé comme ça avant de créer sur AutoRefactor a cause de la difficulté a les utiliser correctement et a les maintenir. Elles sont souvent imprécises (la plupart de l'espace pris par une regexp c'est uniquement pour la gestion des espaces), complètement ignorante de la sémantique de ce qu'elles traitent (pas d'informations de type!) et redondantes (Comment reconnaître a == b et b == a? Réponse: 2 regexps avec duplication de code. grmbl!.
    Je pense que tu dois passer beaucoup de temps a les mettre au point. Tu as beaucoup de courage.

    La ou je te plains, c'est que tu n'as pas de tests unitaires :(
    J'ai commence par un truc sale pour faire les tests: un booléen dans le code du plugin qui exécute les tests sur des exemples de code: Je lançais Eclipse sur le projet avec les exemples. Si la variable booléenne test valait vrai, alors le plugin parcourait le projet pour trouver les exemples avec le code d'entree et le code en sortie, il appliquait les transformations et vérifiait que le résultat final était obtenu. Il affichait alors une fenêtre avec les résultats.
    S’était bien, mais lorsque j'ai pu automatiser les tests avec JUnit dans le processus de production (build en anglais), et bien ma productivité a été décuplée et j'ai pu ajouter beaucoup plus de regles avec une grande confiance sur l’absence de régressions.
    Je t'encourage a faire ça en premier, c'est une investissement qui vaut vraiment le coup. Le temps passé dessus est récupéré plusieurs fois au fil du temps.

    Finalement, je vois que tu as créé un outil que l'on retrouve dans le développement: un formatteur. De même dans l'Analyse statique de programmes, on retrouve le problème des faux positifs.
    Comme je l'ai déjà dit, les parallèles sont rigolos :)

    Encore une fois bravo pour ton courage et ta motivation!

    • [^] # Re: Bravo!

      Posté par  . Évalué à 5.

      Comme tu l'as fait remarquer, j'y vois hélas un inconvénient majeur: c'est lorsqu'il s'agit de rapporter les erreurs sur du texte modifié.

      Cet inconvénient, jusqu’à présent, ne s’est pas révélé si problématique que ça, mais il est exact que, dans certains cas, il serait utile de pouvoir connaître le texte originel. Ça va bientôt se faire. J’hésite entre une méthode simple et une autre plus coûteuse en ressources.

  • # sais tous buggait

    Posté par  . Évalué à 4.

    Ceux programme ait tous buggais : ils sais mi a clignotez de par-tout puit n'autre ordinateurs as commencer a fumée.
    Esse nord mâle ?

    Odette et Édouard Bled

  • # Inférence de type, ou preuve automatique ?

    Posté par  . Évalué à 3.

    Bonjour Olivier,

    Il a été fait mention, dans d'autres commentaires, au parallélisme entre la correction grammaticale et la compilation de code informatique. Et ta description du fonctionnement de grammalecte n'y ai sans doute pas étrangère.
    S'il est bien vrai que les compilateurs vérifient la syntaxe et la grammaire du code, ils font aussi de la traduction : c'est leur fonction première. ;)

    Par contre, il t'a été proposé de regarder du côté du langage Ocaml pour écrire ton moteur d'analyse grammaticale. Je pense que ce pourrait être une bonne idée. La manipulation d'arbre de syntaxe abstraite (AST), ainsi que leur création, est un domaine dans lequel ce langage excelle. Les compilateurs manipulent essentiellement ce type de structure de données; et après la lecture de l'article wikipédia sur les syntagmes, il me semble que c'est la structure la mieux adaptée pour résoudre les questions d'analyse grammaticale (je ne suis pas programmeur, donc je me trompe peut être).

    Gérard Huet (informaticien émérite français, chercheur inria) a publié un article sans rapport apparent : Fondements de l'informatique, à la croisée des mathématiques, de la logique et de la linguistique (étonnement c'est un docx !? mais pas de soucis avec LibreOffice), et pourtant…
    Aux pages 22 et suivantes, lorsqu'il aborde la question de l'enseignement de l'informatique à l'école, on y trouve ce passage :
    « Je vais prendre un autre exemple dans un domaine complètement différent, c’est l’analyse grammaticale dans la
    classe de français. Je ne sais pas si on fait encore beaucoup ça, mais de mon temps on décortiquait les phrases : toute phrase doit avoir un verbe, tout verbe doit avoir un sujet. Là, il y a un petit bout de raisonnement aussi. Comment est-ce que l’on obtient une phrase à partir d’un verbe ? Prenons d’abord un verbe intransitif. Un verbe intransitif a besoin d’un sujet pour exprimer son action. Donc, vous pouvez voir le rôle fonctionnel de ce verbe comme utilisant le syntagme nominal représentant le sujet pour construire la phrase représentant l’action. De même, un verbe transitif peut être vu comme une fonction qui
    prend son complément d’objet pour construire un syntagme
    verbal, se comportant comme un verbe intransitif. Vérifier que « le chat mange la souris » est une phase correcte devient un petit raisonnement où le verbe « mange » prend la souris pour construire « mange la souris », objet fonctionnel qui peut maintenant manger le chat, si je puis dire, pour donner la phrase. Le petit arbre de raisonnement, qui exprime la composition des deux fonctions en vérifiant leurs types, hé bien, c’est ce qu’on appelle l’analyse grammaticale de la phrase. »

    Suivent quelques considérations sur des différences entre les grammaires françaises et anglaises, tout en soulignant leurs points communs (et c'est le commun, l'important ;).
    Et tout cela, dans l'exemple français choisi, n'est qu'une double application de la règle d'inférence logique dite du Modus Ponens (si A alors B, or B donc A).
    L'exemple qui précède celui-là est le cas d'une machine à laver vue comme une fonction qui transforme des watts en euros (la facture EDF ;). En Ocaml c'est une fonction de type watt -> euro (la flèche dénote l'implication logique, si watt alors euro, d'où le modus ponens).
    De plus, le même chercheur a en ligne un dictionnaire de sanskrit avec de l'analyse de lexème et de grammaire pour cette langue. Sans doute a-t-il utilisé ce type de technique, et le contacter pourra t'être utile ?

    Dans le fond, au premier abord, si l'on travaille sur un AST représentant des syntagmes, vérifier la bonne formation grammaticale d'un syntagme me fait penser à de l'inférence de type, voire de la preuve automatique si l'on cherche des suggestions à soumettre à l'utilisateur.

    En espérant que mon commentaire puissent t'être bénéfique,
    Cordialement.

    P.S : avec js_of_ocaml, tu obtiens direct du code javascript à partir de ton code OCaml.

    Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

    • [^] # Re: Inférence de type, ou preuve automatique ?

      Posté par  . Évalué à 3.

      Grosse correction : le modus ponens ce n'est pas si A alors B, or B donc A mais bien si A alors B, or A donc B (j'ai honte).

      Il y a aussi des fautes de grammaire, comme quoi ce genre d'outil intégré à Firefox serai d'une grande utilité. ;)

      Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

    • [^] # Re: Inférence de type, ou preuve automatique ?

      Posté par  (site web personnel) . Évalué à 2.

      Faisant de l'OCaml tout les jours, je ne peux que approuver ce conseil.

      Il faut bien le dire avant toute chose, OCaml est un langage qui brille dans le domaine de l'analyse statique et la compilation. Il y a plusieurs raisons à cela.

      La première concerne la programmation fonctionnel. Le principe de la programmation fonctionnel est que tout est fonction. Mais en disant cela, on a rien dit. En vérité, la programmation fonctionnel offre une manière de penser qui, justement, est parfaite pour ce qui est de l'analyse et de la transformation. Un langage impératif offre une vision d'états de la machine (un nombre d'état qui peut devenir exponentielle dès qu'il s'agit de faire de multi-threads) de manière séquentielle comme la recette de cuisine qu'on nous ressort à chaque fois qu'on souhaite apprendre l'informatique. Mais dans une problématique de recherche et de transformation, cette notion d'état n'a pas grande importance. Ce qui est important dans un compilateur par exemple, ce n'est pas l'état de celui-ci, c'est les règles de transformations qu'il va appliquer, et c'est bien là la nature d'un compilateur, c'est les règles lexicales, syntaxiques et sémantiques de transformation qui nous intéresse. C'est en ce premier point qu'OCaml (mais tout langage fonctionnel de manière général) est plus propice au travail de compilation et d'analyse du code.

      La deuxième concerne le milieu d'OCaml. OCaml est un langage qui vient de l'Inria et qui est encore maintenu par pas mal de chercheur (notamment le laboratoire Gallium). Il est au final très plaisant de travailler avec où l'important n'est pas la date de la prochaine release d'OCaml mais l'intégration d'un travail qui correspond à l'état de l'art de toutes leurs recherche. Ceci donne alors un compilateur associé à pas mal de papiers de recherches (pas si difficile à lire que ça) qui offre un aspect qui va bien au delà du simple hype au langage. En somme, je considère que tout travail dans OCaml fait objet d'une confiance difficile à rétorquer sous le coup de l'humeur - comme par exemple, pourquoi on a l'opérateur (+.) pour les flottants - car chaque choix est argumenté en prenant compte un point de vu de recherche mais aussi, il y a peu, d'industrie. Et c'est bien un des rares langages à pouvoir mélanger les deux.

      La troisième raison concerne bien entendu son système de type qui fait qu'OCaml est OCaml. Dans un domaine comme celui de la compilation, le premier point le plus important est que le compilateur ne produise pas quelque chose qui ne fonctionne pas. Ce serait bête de faire un "Hello World!" en C et que gcc nous produise un "Hello Toto!". Sur ce point qui parait bête, les problématiques de la compilation vont bien plus loin que de simplement produire ce qu'on nous demande. On doit aussi vérifier ce que nous produisons. Une des solutions aujourd'hui est le test unitaire qui permet à fortiori de savoir si le comportement de notre programme correspond à nos attentes. Bien que cette manière est très bien, elle n'est pas exhaustive, elle se limite à l'imagination que peut avoir le développeur sur les cas d'utilisations possibles de son logiciel. Ainsi, les chercheurs ont cherché (c'est leurs jobs il parait) une solution permettant de vérifier statiquement la validité d'un programme. Bien entendu, ce n'est pas possible de vérifier qu'un programme ne plantera jamais mais on a déjà pas mal de piste qui permettent d'élaguer le plus de bugs possibles et l'une de ces solutions est le système de type. C'est bien pour cette raison qu'on dit qu'un programme OCaml qui compile à 90% de chance de ne pas planter.

      Au final, au travers de ces trois points, et de manière simplifié, on comprends pourquoi OCaml brille dans ces domaines là mais le mieux reste de le pratiquer pour s'en rendre compte. J'ai vraiment l'intime conviction qu'OCaml peut être une très bonne solution pour ton logiciel bien qu'il faut ré-apprendre un nouveau langage et surtout ré-implémenter le moteur dans ce langage. Cela peut paraître chiant (et ça l'est je pense) mais le gain que tu gagneras est juste énorme. Un vieux fou m'a demandé de faire mon petit interpréteur de Scheme en OCaml alors que je le faisais en C, il reste fou mais il avait raison de me demander ça et c'est bien un des meilleurs conseils qu'on m'ai donné. J'ai perdu alors pas mal de temps à ré-implémenter mais force est de constater que je suis allé beaucoup plus loin qu'un simple interpréteur de Scheme aujourd'hui et c'est bien grâce à OCaml.

  • # Exemples de limites en vrai

    Posté par  (site web personnel) . Évalué à 5. Dernière modification le 23 avril 2015 à 21:17.

    Je viens d’installer Grammalecte pour la première fois et je viens de le tester sur une lettre que je suis en train d’écrire, il m’a trouvé plein de vrais problèmes, mais aussi des faux positifs comme celui-ci :

    Pour que le don soit gratuit, il ne suffit pas que celui qui donne donne gratuitement, mais il faut aussi que celui qui reçoit reçoive gratuitement.

    Dans « celui qui donne donne », « celui qui donne » est sujet du verbe « donne », comme « celui qui reçoit » est le sujet du verbe « reçoive », mais dans le premier cas Grammalecte lève une répétition en me disant qu’elle n’a pas lieu d’être alors que si, parce que le présent de l’indicatif et le présent du subjectif sont homonymes dans ce cas. ;-)

    Aussi, je m’interroge (c’est peut-être moi qui ne sait pas écrire français), Grammalecte n’aime pas cette forme :

    Je sais ce qu’est aimer.

    Il accepte ces formes par contre :

    Je sais ce qu’est d’aimer.

    Je sais ce que c’est d’aimer.

    Mais il me semble que c’est plus une affaire de style que de grammaire ici, car cette forme est valide :

    Je sais ce que signifie aimer.

    Grammalecte me dit qu’après le verbe être le verbe ne peut pas être à l’infinitif, j’imagine qu’il suppose que c’est une forme composée et que le verbe être est un auxiliaire et donc que le verbe aimer devrait être au participe passé, hors ici c’est bien un infinitif que je veux écrire, employé comme un COD, le sujet étant le pronom « ce » ici si je ne dis pas de bêtise, peut-être que Grammalecte n’identifie pas le pronom comme un sujet ?

    Si j’écris (ne pas chercher de sens) :

    Je sais que manger c’est aimer.

    Grammalecte est content, j’imagine qu’il sait que « manger » est le sujet du verbe « est » et que « aimer » est ici employé comme un COD.

    Bon mais tout ça n’est rien à coté de tout ce qu’il peut trouver, il vaut mieux ignorer quelques faux positifs et corriger des dizaines de fautes que rien du tout. ;-) Merci !

    ce commentaire est sous licence cc by 4 et précédentes

    • [^] # Re: Exemples de limites en vrai

      Posté par  (site web personnel) . Évalué à 4.

      Ton exemple ressemble beaucoup à l'exemple classique :

      les poules du couvent couvent

      ;-) (bien géré par eSpeak iirc).

    • [^] # Re: Exemples de limites en vrai

      Posté par  . Évalué à 6.

      Je sais ce qu’est aimer.

      Oui, c’est correct. C’est Grammalecte qui se trompe. J’ajoute le cas à ma liste de faux positifs à résoudre. Celui-là devrait être simple à éradiquer.

      Merci pour le test du logiciel.

      • [^] # Re: Exemples de limites en vrai

        Posté par  . Évalué à 6.

        Comme beaucoup de monde, à la suite de cette dépêche, j'utilise Grammalecte. Et il est fort utile ! Merci.

        Je ne sais pas si c'est le bon endroit pour rapporter un faux positif, mais vu que tu as l'air d'y tenir, j'en ai détecté un en rédigeant un rapport :
        En régime stationnaire, cette hypothèse est tout à fait valable, comme le montre le graphe ci-dessous.

        L'erreur est la suivante au niveau de le montre : Acccord de genre érroné : "montre" est féminin.

        • [^] # Re: Exemples de limites en vrai

          Posté par  . Évalué à 4.

          Noté. Merci. Les rapports de faux positifs se font dans un fil dédié. Le fil fait peur, mais c’est juste un mémo. Les nouveaux faux positifs arrivent au fur et à mesure des nouvelles versions et sont résolus plus ou moins vite.

    • [^] # Re: Exemples de limites en vrai

      Posté par  . Évalué à 3.

      Par curiosité, je viens aussi de tester avec LanguageTool et antidote

      Pour que le don soit gratuit, il ne suffit pas que celui qui donne donne gratuitement, mais il faut aussi que celui qui reçoit reçoive gratuitement.

      Je sais ce qu’est aimer.

      Je sais ce que signifie aimer.

      les poules du couvent couvent.

      LanguageTool (2.9, dans LO) ne voit rien du tout dans les 4 phrases…

      Antidote (8 v4) voit des choses :

      • phrase 1 : il voit un pléonasme entre don et gratuit.
      • Phrase 2 et 3, il voit une rupture au niveau de « ce » et donc vérifie mal la suite de la phrase. Ainsi il n’arrive pas à gérer « aimer » dont il veut faire un participe passé, noyau de la préposition… En y réfléchissant Antidote a raison : le « ce » n’est pas vraiment correct.
      • phrase 4 : à part l’absence de majuscule en début de phrase, Antidote ne tique pas. Dans l’analyse détaillée, le premier « couvent » est bien vu comme nom qui est le complément du nom « poule » (sans doute grâce au « du» ?) et le second « couvent » est bien compris comme le verbe « couver » (et il accorde bien, car si je mets « couve » la faute est détectée).

      • [^] # Re: Exemples de limites en vrai

        Posté par  . Évalué à 3.

        Il me semble qu'Antidote se trompe pour les phrases 2 et 3.
        L'expression "ce que" introduit le pronom relatif "que" avec un antécédent indéterminé, d'où le "ce" (la construction "celui qui" est identique), est joue le rôle de complément d'objet de sa subordonnée ("celui qui" joue le rôle de sujet indéfini quant à lui). Ce qu'il y a, c'est que le verbe "aimer" est le sujet du verbe "signifie" dans la subordonnée, et cela il ne le voit pas. Cela étant, faire du verbe "aimer" le sujet du verbe "être" dans le cas de la phrase 2 est discutable d'un point de vue sémantique.
        En résumé :
        - "aimer signifie quelque chose" est correcte
        - "je sais ce que signifie aimer" l'est aussi, la proposition est devenue complément d'objet du verbe "savoir" et "ce que" joue le rôle de "quelque chose"
        - "je sais ce que aimer signifie" l'est tout autant

        Antidote ne tiquerai peut-être pas sur une phrase du genre : je sais ce que je veux dire (ici le sujet de la subordonnée étant "je").

        Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

  • # LaTeX

    Posté par  . Évalué à 9.

    Très très belle dépêche. Ça fait plaisir à lire.
    Petite question : la campagne de financement participatif actuelle vise à porter grammalecte sous Firefox et Thunderbird. Est ce qu'ensuite il est prévu de fournir une sorte de module autonome de manière à pouvoir l'utiliser sur un texte brut ou avec LaTeX par exemple, genre un truc comme aspell qui peut s'utiliser en ligne de commande. Ça serait vraiment une super avancée

    • [^] # Re: LaTeX

      Posté par  . Évalué à 8.

      Je n’avais pas songé à la ligne de commande, mais rien ne s’y oppose. Ça ne devrait pas être bien compliqué d’ajouter une interface en ligne de commande pour traiter des fichiers de texte brut. Si j’ai le temps, je ferai ça en même temps que la finalisation du serveur.
      En revanche, je n’ai pas prévu de m’occuper du format LaTeX. Mais les gens motivés pourront ajouter des règles optionnelles dans le préprocesseur de texte pour effacer les balises qui gênent.

      • [^] # Re: LaTeX

        Posté par  . Évalué à 2.

        <futur condition="serveur finalisé">
        Si c'est assez facile de rajouter des règles dans le préprocesseur, on pourrait voir florir des préprocesseurs pour les différents langages de balisage. Par exemple, en vérifiant un commentaire linuxfr avec LanguageTool, je me suis aperçu que j'avais également des faux positifs du markdown.
        </futur>

        bépo powered

      • [^] # Re: LaTeX

        Posté par  (site web personnel, Mastodon) . Évalué à 2.

        Le principal est qu’il sache traiter du texte brut. Après, on peut toujours utiliser des utilitaires tels que spellutils ou pospell, pour dépouiller le texte de ses attributs, comme on le fait avec Aspell.

    • [^] # Re: LaTeX

      Posté par  . Évalué à 4.

      Merci pour ce super article.

      Très bonne idée ! Je serais aussi très intéressé par un programme indépendant, pour parser du latex ou un texte brut !

  • # Pourquoi Ulule ?

    Posté par  . Évalué à 2.

    C'est une question plus a titre informatif qu'autre chose. Pourquoi est-tu passé par ulule pour faire une campagne de financement participatif plutôt qu'autre chose ?
    D'autre part, il me semble que si les 15 000 € ne sont pas atteint, alors tu ne toucheras rien. Ça me parait dommage dans le sens ou un financement flexible aurait peut-être été plus adapté (si l'objectif n'est pas atteint, alors tu y consacres moins de temps).

    bépo powered

    • [^] # Re: Pourquoi Ulule ?

      Posté par  . Évalué à 7.

      Pourquoi est-tu passé par ulule pour faire une campagne de financement participatif plutôt qu'autre chose ?

      Même s’il existe depuis quatre ans, Grammalecte n’est pas un logiciel très connu, et je pensais qu’une campagne n’avait guère de chances d’aboutir si je la montais sur mon propre site. C’est une question de confiance. Passer par Ulule, c’est choisir un intermédiaire qui apporte une visibilité hors du milieu des geeks et des technophiles, et surtout de la crédibilité.

      Ensuite, entre Ulule, KissKissBankBank et MyMajorCompany, le choix s’est porté sur la plateforme avec le nom le plus court, les conditions d’utilisation les plus courtes et le site qui avait la plus belle allure à mon goût.

      il me semble que si les 15 000 € ne sont pas atteint, alors tu ne toucheras rien.

      En effet.

      Ça me parait dommage dans le sens ou un financement flexible aurait peut-être été plus adapté.

      L’idée d’origine, c’était d’essayer de me consacrer environ un an à ça. Parce qu’il y a énormément à faire. Par ailleurs, cette campagne est une sorte de test pour mesurer l’intérêt que les millions d’utilisateurs francophones de Firefox et Thunderbird peuvent porter à ce genre de projet.

      • [^] # Re: Pourquoi Ulule ?

        Posté par  . Évalué à 7.

        En cas d'échec de la campagne (ce que je ne te souhaite pas) ou en complément, tu pourrais peut-être créer un projet sur patreon. J'en avais fait une présentation ici. Contrairement à Ulule/Indiegogo/kisskissbankbank, … le paiement se fait chaque mois, ou à chaque objectif atteint, au lieu d'avoir une grosse somme d'argent au départ. De plus, tu peux mettre des paliers (ex: pour 500€ par mois, tu t'engages à bosser un jour par semaine sur Gramalecte, pour 1100€ tu t'engages à bosser 2 jours, …). Ça permet un peu plus de souplesse sur le temps et la vitesse de développement.

        bépo powered

  • # Questions en vrac

    Posté par  . Évalué à 2.

    Merci pour cette article passionnant qui m'a permis de découvrir ce domaine.

    A travers cette lecture plusieurs question mon traversé l'esprit.

    Pourquoi es-tu si réticent vis-à-vis de la "tokenisation" ?
    Après-tout la grammaire se base dessus, et c'est le processus "naturel" que chacun applique.
    Ne crains-tu pas que l'explosion combinatoire des règles que tu mets en place (même après les phases de simplification) et la cohérence entre ces règles ne finissent par rendre le logiciel trop lent ?

    Concernant le lien avec Hunspell:
    Il semple qu'il soit disponible sous forme d'un lib C++ et également d'un service.
    Es-t'on vraiment obligé d'en passer par un couplage avec OO/LO ?
    Pourquoi ne pas analyser des textes bruts plutôt que des ODF pour tes TUs ?

    De même pourrais-tu détailler un peu la solution que tu envisages pour la "désambiguisation", car même après la lecture de ton billet je ne comprends pas très bien ce que serait un "index de balises" ?

    Concernant ta structure pour stocker le vocabulaire et la nature grammaticale des mots, ne crains tu pas que ceci ne puisse plus te permettre de proposer des suggestions sur des mots mal orthographiés dès le début.
    Par exemple: embiguïté

    Enfin aurais-tu quelques références à nous indiquer pour effleurer ce sujet, car des adjectifs épicènes, des lemmes, des thesaurus, …, je comprends un peu ce dont il pourrait s'agir mais j'imagine que ca doit être bien décrit de façon formelle quelque part.

    Encore merci pour ce billet captivant et très bien écrit et bonne chance pour ta campagne de dons.

    • [^] # Re: Questions en vrac

      Posté par  . Évalué à 4. Dernière modification le 28 avril 2015 à 15:47.

      Diantre ! Autant de fautes dans un commentaire sur les correcteurs grammaticaux. Je la refais

      Merci pour cet article passionnant qui m'a permis de découvrir ce domaine.

      A travers cette lecture plusieurs questions m’ont traversé l'esprit.
      Pourquoi es-tu si réticent vis-à-vis de la "tokenisation" ?
      Après tout la grammaire se base dessus, et c'est le processus "naturel" que chacun applique.
      Ne crains-tu pas que l'explosion combinatoire des règles que tu mets en place (même après les phases de simplification) et la cohérence entre ces règles ne finissent par rendre le logiciel trop lent ?

      Concernant le lien avec Hunspell:
      Il semble qu'il soit disponible sous forme d'un lib C++ et également d'un service.
      Est-on vraiment obligé d'en passer par un couplage avec OO/LO ?
      Pourquoi ne pas analyser des textes bruts plutôt que des ODF pour tes TUs ?

      De même pourrais-tu détailler un peu la solution que tu envisages pour la "désambiguisation", car même après la lecture de ton billet, je ne comprends pas très bien ce que serait un "index de balises" ?

      Concernant ta structure pour stocker le vocabulaire et la nature grammaticale des mots, ne crains tu pas que ceci ne puisse plus te permettre de proposer des suggestions sur des mots mal orthographiés dès le début.
      Par exemple: embiguïté

      Enfin aurais-tu quelques références à nous indiquer pour effleurer ce sujet, car des adjectifs épicènes, des lemmes, des thesaurus, … Je comprends un peu ce dont il pourrait s'agir, mais j'imagine que ça doit être bien décrit de façon formelle quelque part.

      Encore merci pour ce billet captivant et très bien écrit et bonne chance pour ta campagne de dons.

      • [^] # Re: Questions en vrac

        Posté par  . Évalué à 4.

        Autant de fautes dans un commentaire sur les correcteurs grammaticaux.

        Moi aussi, j’en fais. Être attentif à tout, ce n’est pas facile.

        Pourquoi es-tu si réticent vis-à-vis de la "tokenisation" ?

        Je ne suis pas réticent vis-à-vis de la tokenisation en général. J’y suis réticent dans Grammalecte en l’état des choses. Parce que Grammalecte est basé sur un autre concept, pas incompatible avec la tokenisation, mais utiliser cet autre procédé juste pour faire de la désambiguïsation, ce serait du gaspillage de ressources. Ou alors il faudrait que ça serve à autre chose, ou tout réécrire depuis le commencement. Pour l’instant, l’étape suivante, c’est faire ce que j’ai proposé dans la campagne de financement.

        Ne crains-tu pas que l'explosion combinatoire des règles que tu mets en place (même après les phases de simplification) et la cohérence entre ces règles ne finissent par rendre le logiciel trop lent ?

        Ça fait partie des problèmes à gérer. J’y suis attentif. Il y a encore pas mal de choses optimisables çà et là. Il y a justement le remplacement de Hunspell qui fournit les données en vrac en XML, la refonte des dictionnaires avec des étiquettes plus adaptées, et diverses parties du code qui peuvent être améliorées.

        Est-on vraiment obligé d'en passer par un couplage avec OO/LO ?

        Non, mais si on veut s’en passer et pouvoir faire des choses intéressantes par la suite, il y a pas mal à faire.

        Pourquoi ne pas analyser des textes bruts plutôt que des ODF pour tes TUs ?

        Ça, c’est ce qu’on me proposait de faire temporairement en attendant une solution plus efficace, mais c’est sur des textes bruts que je compte faire des tests.

        De même pourrais-tu détailler un peu la solution que tu envisages pour la "désambiguisation", car même après la lecture de ton billet je ne comprends pas très bien ce que serait un "index de balises" ?

        Plutôt que tokeniser et faire l’étiquetage de tous les tokens, je vais dresser avec des règles de désambiguïsation un dictionnaire temporaire avec pour clés les positions des mots désambiguïsés et pour valeurs les étiquettes grammaticales à utiliser.
        Ensuite, lors des règles de contrôle, lorsqu’on fait appel à la commande d’analyse lexicale, celle-ci, avant d’interroger le lexique, va regarder si la position du mot à analyser existe dans le dictionnaire comme clé (ce que j’ai appelé une balise). Si c’est le cas, pas besoin d’interroger le lexique, le correcteur utilisera la valeur indiquée par le dictionnaire temporaire. Sinon il interrogera le lexique.

        Concernant ta structure pour stocker le vocabulaire et la nature grammaticale des mots, ne crains tu pas que ceci ne puisse plus te permettre de proposer des suggestions sur des mots mal orthographiés dès le début.

        Pour commencer, il est prévu de se passer de Hunspell pour la grammaire, mais pas pour l’orthographe. Ensuite, avec le temps, j’espère aussi remplacer Hunspell pour l’orthographe, mais peut-être que ce ne sera pas toujours possible partout à cause des performances. Le graphe de mots devrait pouvoir servir de base pour faire des suggestions orthographiques (reste à trouver un algo efficace). Quoi qu’il en soit, le dictionnaire pour Hunspell va subir une grosse cure de simplification de ses règles internes, et ça devrait le rendre plus efficace.

        aurais-tu quelques références à nous indiquer pour effleurer ce sujet, car des adjectifs épicènes, des lemmes, des thesaurus

        Pour le vocabulaire, Wikipédia, c’est pas mal. Sinon, il y a des masses de papiers trouvables en ajoutant “filetype:pdf” à vos recherches dans Google, plus que vous ne pourrez en lire. Je ne sais pas quoi conseiller. :)

  • # Disponibilité du code source

    Posté par  . Évalué à 7.

    Très bonne initiative, un bon correcteur orthographique/grammatical libre qui puisse être comparé aux solutions propriétaires manquait vraiment. J'ai vu que le code source était disponible sur le site du projet, mais pas sous une forme très accessible (un fichier 7z). Ne serait-il pas plus simple de le mettre à disposition dans un dépôt git ? Surtout que vu l'enthousiasme qu'a suscité le projet, des contributeurs pourraient aider à améliorer le correcteur.

    • [^] # Re: Disponibilité du code source

      Posté par  . Évalué à 2.

      J’aime travailler seul. Mais oui, si la campagne réussit, ce sera l’occasion de revoir l’organisation du site et d’ouvrir un dépôt. Je pense changer de nom de domaine au passage. Dicollecte, c’était avant tout un site pour travailler sur les dictionnaires.

  • # Moi je suis content

    Posté par  . Évalué à 4.

    Comme ta conclusion l'évoque, je ne crois pas que l'on soit obligé de désespérer à l'idée que les gens n'écrivent pas bien notre langue.

    Une langue n'est belle que parce qu'elle est utilisée et comprise. Je crois avoir lu une étude quelque part indiquant qu'il y avait tout autant de fautes d'orthographe dans les copies des certificats d'études d'hier que dans celles du brevet (et pourtant…)

    Seulement aujourd'hui, tous peuvent écrire. La réduction du nombre de correcteur dans les journaux, l'auto-publication (qui n'a jamais écrit une phrase publique sur Internet), la multiplication des supports de communication écrits sont autant d'occasion de voir faire des fautes ceux qui les cachaient auparavant. Je ne crois pas que cela soit bien en soi, mais ce dont je suis convaincu c'est qu'il est bien en soi que les gens écrivent. C'est en forgeant qu'on devient forgeron, non ?

    "The trouble with quotes on the internet is that it’s difficult to discern whether or not they are genuine.” Abraham Lincoln

    • [^] # Re: Moi je suis content

      Posté par  . Évalué à 2.

      La morale de cette histoire, c’est peut-être aussi que la langue est trop compliquée.

      Écrit en Bépo selon l’orthographe de 1990

  • # Je me jette

    Posté par  (site web personnel) . Évalué à 3.

    Bon, puisque tout le monde dit du bien, je dis du mal : c'est moi, ou il manque tout plein de temps au conjugueur ?

    • [^] # Re: Je me jette

      Posté par  . Évalué à 3.

      Il manque tout plein de temps au conjugueur parce qu'il manque tout plein de temps au concepteur!

      Cela dit, pour avoir déjà communiqué avec ce concepteur, pour l'autre projet, Dicollecte, bien avant cette campagne de financement, je l'ai trouvé à l'écoute des utilisateurs. Il est au présent ce qu'il était au passé et ce qu'il sera au futur, à moins que j'eusse eu tort, ce qui serait moins-que-parfait…

      L'auteur dit aimer travailler seul. J'aurais préféré une équipe de développeurs ou une équipe avec un chef pour un projet de cette ampleur.

      Il dit plus loin au sujet de la licence:
      Comme c’est la deuxième fois qu’on me pose la question, je présume que ça a une importance qui m’échappe.

      Je pense que c'est encore plus que recommandé dans le monde où nous vivons de spécifier la licence d'une création. Ça protège l'auteur et permet, dans le cas des utilisateurs d'une création sous licence libre, de continuer à utiliser le code peu importe les aléas de la vie si belle ou si cruelle soit-elle. Combien de fois ai-je entendu "je n'ai plus de temps à consacrer au projet" de la part de développeurs, cavaliers seuls, autrefois si motivés… Merci à l'auteur d'avoir fait un choix (spécifié dans le lien licence)!

      Pour conclure, quels temps manquent pour faire une critique encore plus constructive pour les lecteurs de la dépêche? Ce n'est pas vraiment en dire du mal ce que tu as fait, c'est de donner un retour d'un point que tu juges négatif.

      Il ne manque que des exemples pour voir si tes temps existent ou si tu n'as pas fait tout plein d'erreurs parce qu'il te manquait tout plein de temps pour apprendre cette langue avec tout plein de temps et tout plein d'exceptions! Mon texte est tout plein de mots, il doit y avoir tout plein d'erreurs. Vivement un bon correcteur!

      Correcteur : Il y a tout plein de tout plein dans ton texte!
      Moi : Mauvais correcteur, tai-toi!
      Correcteur : Mauvais correcteur, tais-toi!
      Moi : A-tu fini le perroquet?
      Correcteur : As-tu fini le perroquet?
      Moi : Bon correcteur, donne la pâte!
      …

      • [^] # Re: Je me jette

        Posté par  (site web personnel) . Évalué à 3.

        Il manque dans l'image quatre temps de l'indicatif (présent, imparfait, passé simple, et futur simple), deux du subjonctif (présent et imparfait), un du conditionnel (présent), un de l'impératif (présent), un de l'infinitif (passé), et les deux gérondifs.
        Peut-être sont-ils présents dans le logiciel…

        • [^] # Re: Je me jette

          Posté par  . Évalué à 5.

          Oui, ils sont présents dans le logiciel. Il suffit de décocher la case “temps composés”, qui active le mode que l’on voit sur l’image.

          En fait, il ne manque pas de conjugaisons dans dans le conjugueur, mais l’étiquetage de tous les verbes n’ayant pas été contrôlés et mis à jour depuis 2008 pour beaucoup d’entre eux (à l’époque où Grammalecte n’existait pas encore), j’ai préféré désactiver le mode “temps composés” et “pronominal” par précaution. Il est prévu d’améliorer l’interface pour pouvoir compléter l’étiquetage manquant (sans jargon) et transmettre l’information en ligne à la base de données. En fait, il manque juste de spécifier si le verbe auxiliaire est “être” ou “avoir” (pour voir les temps composés) et de vérifier si le verbe peut être utilisé pronominalement.

      • [^] # Re: Je me jette

        Posté par  . Évalué à 1.

        Moi : Bon correcteur, donne la pâte!

        Finir un commentaire parlant d’orthographe sur une faute d’orthographe, c’est plutôt amusant!

        Écrit en Bépo selon l’orthographe de 1990

      • [^] # Re: Je me jette

        Posté par  . Évalué à 3.

        Je pense que c'est encore plus que recommandé dans le monde où nous vivons de spécifier la licence d'une création. Ça protège l'auteur […]

        Non, les licences libres permettent de céder des droits. Par défaut l'auteur est tout puissant sur sa création.

        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • # errare humanum est ?

    Posté par  . Évalué à 4.

    En commençant à lire l’article, « des conditions d’applications » ne me paraît pas très correct.
    J’aurais mis « application » au singulier. Même si l’application venait à se répéter, elle est ici désignée comme une pratique, par essence indénombrable : le pluriel semble ici donner un sens impossible à la phrase.

    Corrigez-moi si je me trompe…

  • # J'ajoute ma pierre

    Posté par  . Évalué à 1.

    à l'édifice et participe au financement de ce projet !

    Merci Olivier pour ton travail et à toute la communauté pour l'ajout de mots au dictionnaire.

  • # Ulule, affichage des noms contributeurs

    Posté par  (site web personnel) . Évalué à 2.

    Attention, par défaut Ulule permet de consulter les prénoms et noms des contributeurs. Dans les préférences du compte, il est possible d'être anonyme ou d'afficher un pseudo (personnellement, je trouve ça plus normal qu'un site utilise les pseudos par défaut).

  • # Dictionnaire grammatical anglais

    Posté par  . Évalué à 1.

    @Olivier: J'essaye de trouver des informations sur l'existence d'un dictionnaire grammatical pour l'Anglais. Est-ce qu'il existe? Si non, est-il prévu?

    Merci!

    • [^] # Re: Dictionnaire grammatical anglais

      Posté par  . Évalué à 1.

      Oui, il existe un dictionnaire grammatical pour l’anglais. Celui de LanguageTool, qui contient environ 354000 formes fléchies. L’anglais est probablement la langue la mieux fournie en ressources. Mais j’ignore s’il existe d’autres dictionnaires libres.

  • # Génial !

    Posté par  (site web personnel) . Évalué à 1. Dernière modification le 05 juin 2015 à 19:15.

    Bonjour,

    Juste pour informer que j'utilise ce dictionnaire avec LibreOffice depuis plus ou moins la sortie de l'article sur Linuxfr.org, et je dois l'avouer, l'extension est vraiment bluffante !

    En plus de souligner et proposer le mot corrigé, il y a une petite explication du pourquoi du comment. D'autres trucs bien sympathiques comme les tables de conjugaisons. Non vraiment je fus très surpris par la qualité et les options que proposent cette extension.

    Je ne manquerais pas de l'utiliser dans les deux logiciels de Mozilla dès la disponibilité, et en faire la promotion autour de moi.

    Merci.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.