Olivier a écrit 316 commentaires

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.

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

ç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. :)

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.

Alors, oui, le code sera libre. :)

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.

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.

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. :)

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.

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).

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.

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.

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

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.

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.

commentaire supprimé