OK
AJAX error!

Les forumsGrammalecteVersion 0.5.0 bêta pour LibreOffice (+ CLI)

Version 0.5.0 bêta pour LibreOffice (+ CLI)

Petit retour d’expérience sur le mode console.

Étant sous un Linux utilisant python 2.7, voilà ce qui fonctionne chez moi :

cd /home/XXX/.config/libreoffice/4/user/uno_packages/cache/uno_packages/lue2ugqz.tmp_/Grammalecte-v0.5.0b.oxt/pythonpath
(là où se trouve parser)
y copier un fichier de test (en utf-8) : exemple : test.txt
/opt/libreoffice4.4/program/python parser.py -ff test.txt
(les résultats se trouvent dans test.res.txt)

Sous Windows 7, j’ai aussi récupéré la version python se trouvant dans les répertoires de LibreOffice (python.exe)
Une approche plus propre sera de modifier les “PATH” ou “ENV”

Attention avec le mode « Écrivez votre texte [entrée pour quitter]",
si vous faites un “paste” d’un texte, le parser quitte assez rapidement le texte (ligne vide ?) et le “shell” tente d’exécuter les lignes qui suivent (sous Linux).
au-delà d’une ou deux lignes, il vaut peut-être mieux passer le texte via -f

J’ai essayé la fonction avec un texte encore non retravaillé de Wikisource, et
les résultats sont dans une première passe “saturés” de blancs insécables et de blancs en fin de lignes ; il faudrait faire d’abord passer le texte dans le filtre « formateur de texte" ?

mes 2c.

P.S. : texte "validé" grâce au mode console ;-) (les corrections sont faites sous LO...)
le 05 octobre 2015 à 19:08
Hum… normalement, ça ne peut pas fonctionner avec Python 2.7. Le dictionnaire indexable utilise une fonction qui n’existe que depuis Python 3.2. (Et il y a probablement d’autres fonctions qui n’existent que depuis Python 3.3 si mon souvenir est correct.)
Il faut donc au moins Python 3.3. J’aurais dû le préciser. (J’utilise Python 3.4, pour ma part.)

Sous Windows 7, j’ai aussi récupéré la version python se trouvant dans les répertoires de LibreOffice (python.exe)


oO. Je ne sais pas trop ce que ça peut donner. Mieux vaut télécharger Python 3.4 et l’installer. :)

si vous faites un “paste” d’un texte, le parser quitte assez rapidement le texte (ligne vide ?) et le “shell” tente d’exécuter les lignes qui suivent (sous Linux).


Je n’y ai pas pensé, mais, effectivement, lorsque l’interface vous demande d’entrer du texte, implicitement, il s’agit de n’entrer qu’un seul paragraphe. Je n’ai pas songé qu’on y copierait un texte entier. Je ne sais pas trop comment ça réagit dans ce cas. À revoir donc.

Pour un texte entier, il faut utiliser la commande -f ou -ff. Sur Windows, seule la commande -ff est utile, attendu que la console n’est pas capable de gérer correctement l’UTF-8.

J’ai essayé la fonction avec un texte encore non retravaillé de Wikisource, et
les résultats sont dans une première passe “saturés” de blancs insécables et de blancs en fin de lignes ; il faudrait faire d’abord passer le texte dans le filtre « formateur de texte" ?


Oui, effectivement. Ce serait sans doute utile, ou désactiver certaines options.

Je prends note de tout ça. C’est là qu’on voit une application d’abord pensée pour le débogage plus que pour l’utilisateur final. Hmm…
le 05 octobre 2015 à 22:16

“parser.py” permet de tester le texte que vous entrez à la main.
“parser.py -f filename” pour analyser un fichier texte (UTF-8 requis).
“parser.py -ff filename” pour analyser un fichier texte (UTF-8 requis) et produire un fichier résultat.


Merci ! Je n’ai pas encore eu le temps d’essayer, mais j'ai une remarque.
Un programme en ligne de commande devrait, si possible, se comporter comme un filtre qui lit stdin et écrit sur stdout/stderr.
Les options -f ou -ff ne devraient donc pas être nécessaires je pense. On devrait pouvoir faire : parser.py < in.txt > out.txt

Je vois aussi sur la copie d'écran le message : "Écrivez votre texte [Entrée pour quitter]".

Il est préférable de rester silencieux à mon avis. Ce texte peut être ennuyeux quand on écrit un script et n’est pas très utile à mon avis. "Entrée pour quitter" semble étrange : comment ça marche si je tape un ligne vide ? Normalement, on termine avec CTRL-D (fin de fichier), qui devrait déjà fonctionner, mais je n’ai pas encore essayé…
le 06 octobre 2015 à 04:39


Hum… normalement, ça ne peut pas fonctionner avec Python 2.7. Le dictionnaire indexable utilise une fonction qui n’existe que depuis Python 3.2. (Et il y a probablement d’autres fonctions qui n’existent que depuis Python 3.3 si mon souvenir est correct.)
Il faut donc au moins Python 3.3. J’aurais dû le préciser. (J’utilise Python 3.4, pour ma part.)



justement, la technique d'aller récupérer la version python (exécutable) dans les répertoires de L.O. est que là, c'est bien une 3.3 qui s'y trouve.
Donc sous Linux cela permet d'avoir une bonne version
et sous Windows cela m'a évité de devoir installer python pour faire un test rapide...
le 06 octobre 2015 à 06:07
@dominiko
Sur Windows, stdout est pourri. Lorsqu’on fait un print, la console est susceptible de faire crasher le programme si on essaye d’imprimer un caractère non reconnu (comme l’apostrophe typographique, les points de suspension, la ligature œ, et des tas d’autres caractères). Le codage de la console Windows dépend de votre version de Windows (cp850 chez moi fr.wikipedia.org…). C’est un codage ancien, il y en a plein de la sorte, et c’est un bordel indescriptible.
Afficher quelque chose dans ce codage n’est pas compliqué (si on aime les hiéroglyphes), mais afficher quelque chose de lisible est un casse-tête sans fin. Pour ma part, j’utilise une table de transcription qui transforme les caractères problématiques en caractères affichables. Le problème, c’est comment repositionner les erreurs si je transforme par exemple “œ” en “oe”, “…” en “...” ? (C’est sûrement faisable, mais je n’ai pas pris le temps de gérer ce problème.)

Par ailleurs, si on tape “parser.py -f fichier.txt > res.txt”, on passe quand même par stdout. Du coup, même sans avoir à afficher les caractères non reconnus, ça plante, ou bien il faut modifier les caractères non reconnus pour les faire transiter, ce qui n’est pas acceptable. C’est pourquoi il y a la commande -ff (--file_to_file), qui ne passe pas par stdin/stdout et l’encodage moisi de Microsoft. Il n’y a pas de conversion et de tests à faire.
Je devrais même interdire l’option -f sur Windows, ça ne sert à rien.

Enfin, oui, ça quitte sur une ligne vide. Ctrl-D, Windows n’a pas l’air de connaître. Ctrl-C, ce n’est pas très propre, àmha.
le 06 octobre 2015 à 09:08
J’ai fait une petite mise à jour, parce qu’il y avait certains faux positifs que je trouvais gênants même pour une bêta (merci Tbj).

J’ai aussi ajouté une option -tf (formateur de texte) qui réécrit le texte avant analyse, afin d’éviter les signalements intempestifs concernant les apostrophes et les espaces. En fait, ce sont les réglages par défaut du formateur sur LO. Du coup, il y aura plein d’erreurs que Grammalecte signale usuellement qui seront réécrites au lieu d’être signalées.

Même lien que précédemment : [[ lien supprimé ]]
le 09 octobre 2015 à 18:53
J'ai fait un rapide test sur le mode console.

Si j'ai bien compris les nouvelles options s'utilisent comme suit :
python parser.py -tf -ff tst.txt ou python parser.py -ff tst.txt -tf
(j'avais d'abord essayé ... parser.py -tf tst.txt, qui m'a permis de découvrir l'option -h)

Effectivement avec la nouvelle option, les résultats sont beaucoup plus "compactés".

Pourrais-je suggérer d'ajouter pour le parser une option -v ou -V retournant la version du parser, car je me suis retrouvé avec plusieurs versions dans des chemins différents et j'ai dû nettoyer pour retrouver la bonne...

Je vais utiliser le mode normal (sous LO) sur un texte de ~150000 mots, j'espère ne pas trop alimenter les faux positifs... ;-)

le 10 octobre 2015 à 07:21
La version s’affichera dorénavant au lancement.
Quant aux faux positifs, il ne faut pas avoir peur de les rapporter. :)
le 10 octobre 2015 à 22:44
Quelques erreurs à corriger dans les traductions en anglais (Grammalecte-v0.5.0b.oxt)…

Dans pythonpath/ds_strings.py :

*erronous* (→ erroneous)

This dictionary is unadvised for those who *doesn’t* (→ don't) know very well the French language


Dans pythonpath/ab_strings.py :

More *informations* (→ information)


Dans pythonpath/tf_strings.py:

an empty *paragraphe* (→paragraph)
le 11 octobre 2015 à 02:16

J’ai encore pris un peu de retard, car j’ai passé un temps considérable à mettre en place des tests unitaires pour éviter les régressions. À vrai dire, le terme “unitaire” est ici un peu abusif, attendu que j’ai surtout mis en œuvre des vérifications sur les résultats que Grammalecte doit rendre au final. Ce n’est donc pas unitaire au sens strict du terme, mais il est toujours possible d’améliorer ce point. L’essentiel, c’est que Grammalecte entreprend à présent une masse importante de tests (encore appelée à grossir) à chaque modification des règles. C’est un énorme progrès.


Les tests de Grammalecte sont-ils disponibles librement ? C'est peut-être utile pour trouver des fausses erreurs ou erreurs non trouvées par LanguageTool, si tu es d'accord.
le 11 octobre 2015 à 02:25
Merci pour les erreurs en anglais. C’est corrigé.
Oui, les tests seront publiés avec les sources en même temps que la version finale 0.5.0.
(Je te les envoie par mail en attendant.)
le 11 octobre 2015 à 12:22
Quelques autres erreurs dans : dialog/fr_en_US.properties (v-0.5.0b3):
* glyphes → glyphs
* disactivate → deactivate
* beforce → before
* unuseful → useless
* particularily→ particularly
* Pleonasmes → Pleonasms
le 24 octobre 2015 à 15:58
Corrigé. Merci.
le 24 octobre 2015 à 16:14
Bonjour,

La correction des normes semble ne pas bien fonctionner

NF C 15-100 donne Nf c 15‑100

qui donne NF c 15‑100 en corrigeant le Nf puis ça reste sur "normes français, utiliser les espaces et tirets insécables"

Pierre
le 02 novembre 2015 à 21:29
Corrigé.
le 02 novembre 2015 à 21:44
Nouvelle bêta : [[ lien supprimé ]]
le 15 novembre 2015 à 15:32
Bonjour,

je note que les nombres avec virgule ne sont pas inclus dans la recherche des espaces insécables entre le nombre et l’unité.

30 kW oui, 25,2 kW non

17 ℃ oui, 17,3 ℃ non

Pierre
le 22 novembre 2015 à 09:38
Corrigé.
le 22 novembre 2015 à 09:45
Bonjour,

Je signale le bug suivant :

la formation d’une peau élastique qui se rétracte
^^^^^^^^^
* 24:33 # 2084-1 : Accord erroné : « élastique » devrait être au féminin singulier.

le 07 janvier 2016 à 03:56
Corrigé.
le 07 janvier 2016 à 04:18
Bonjour,
Bonne année à tous les acteurs de ce fabuleux projet.

Je note un comportement bizarre de Grammalecte.

Si j’écris : "Il sont sans rapport avec..." Grammalecte me souligne "Il" et "sont"

par contre si j’écris :"Qu’il sont sans rapport avec..." Grammalecte me souligne uniquement sont

Par ordre de priorité, il me semble que le comportement souhaité devrait être :

1 souligner "Il" car l’erreur à toute les chances d’être là lorsque l’on a écrit "sont"

2 souligner les deux mots

3 souligner "sont" ne me paraît une bonne idée

Pierre
le 13 janvier 2016 à 17:05
J’ai corrigé cela pour rendre le comportement plus homogène.
Dans ce cas, “sont” paraît nécessairement correct, parce que nous pensons phonétiquement. Mais si vous tapez “il mangent”, savoir où est l’erreur est bien plus délicat.

Bonne année à tous. Je vais fournir une autre bêta prochainement.
le 17 janvier 2016 à 20:00
Nouvelle bêta (j’ai failli oublier) : [[ lien supprimé ]]

À noter qu’il y a un nouvel outil pour surligner plus vite toutes les occurrences d’un mot ou d’une sélection de mots (si moins de 3), via le menu contextuel de Writer. Je ne sais pas si cet outil est vraiment utile et s’il demeurera. Je suis dubitatif. J’en avais besoin pour trouver des répétitions, alors je l’ai créé. Il me semble que ça peut servir à ceux qui écrivent. Mais peut-être est-ce trop spécifique ?
le 09 février 2016 à 16:16
Bonjour,
petits retours sur un test sommaire du "nouveau" parser.

1. voilà la façon dont j’ai utilisé le parser :
je me suis mis dans le répertoire de LO contenant le parser et de là :
python3.4 parser.py -ff test_parser_1.txt -tf
le résultat est intéressant (j’y reviens plus loin) mais n’y a-t-il pas moyen de récupérer un fichier de résultat ayant "subi" l’action de l’option -tf, mais ne contenant pas les "remarques" des différentes erreurs ? Peut-être plus clairement (?) on donne en entrée un fichier texte ; l’option -tf ; et on reçoit un fichier de sortie "nettoyé"

2. Si je n’ai aucun problème sous linux, j’ai aussi essayé le même genre d’opération sous Windows (7) et je n’arrive à rien à cause de l’UTF-8 requis. Apparemment le programme s’arrête dès qu’il "voit" un caractère non conforme. Peut-être le laisser continuer avec un "warning" ?

3. Ce qui suit est à la limite du faux positif et existait peut-être déjà avant...
Cela se passe aussi sous LO.
L’origine du problème est que je prends une page dans Wikisource (brut d’OCR) et je la copie dans LO ;
une passe avec le formateur de texte et enfin le correcteur orthographique/grammatical.
De cette manière, les lignes sont souvent terminées au milieu d’une phrase,
mais prennent l’indicateur de "fin de paragraphe" dans LO !
Un petit exemple :


... Ce qu’il avait entendu
dire


Cela est détecté par le parser (ou la nouvelle version de grammalecte dans LO) par


...Ce qu’il avait entendu
* 50:57 # 120p : Il manque une ponctuation finale.
> Suggestions : entendu. | entendu… | entendu ! | entendu ? | entendu : | entendu ; | entendu,
dire...


De même avec


Jamais le gentilhomme ne lui avait offert un

* 51:53 # 120p : Il manque une ponctuation finale.
> Suggestions : un. | un… | un ! | un ? | un : | un ; | un,
verre de vin


ou encore :


... et la
remplit d’une froide cupidité. Aussi Gustave dut-il lutter


avec les suggestions de remplis et lutter.

4. Je ne me souviens pas de l’option -w...
peut-être serait-il intéressant de faire accompagner le parser.py
d’un parser.readme, avec les diverses options possibles
et un peu plus de détails qu’avec l’option -h ?



J’en demande peut-être beaucoup....
... mes 2c.

Encore félicitation pour tout ce travail (de fourmis)
le 11 février 2016 à 12:23
1. Oui, il est possible de fournir un texte retravaillé par le formateur de texte sans signaler les erreurs grammaticales. Je n’ai simplement pas pensé à fournir cette option.

2. L’UTF-8 est requis, parce que c’est compliqué de gérer tous les formats et que ce n’est pas mon rôle, il y a beaucoup d’outils pour faire la conversion. En revanche, sous Windows, l’UTF-8 passe normalement tant qu’on n’essaie pas d’afficher le texte dans la console. Je ne suis pas sûr de comprendre ton problème.

3. Ici, le problème vient d’une règle expérimentale concernant les ponctuations absentes en fin de ligne. J’aurais dû la désactiver. Ça pose aussi problème sous LO puisque le correcteur a tendance à souligner le dernier mot pendant qu’on écrit. C’est un peu pénible.

4. Il n’y a pas grand-chose à dire sur les options, mais je peux être plus spécifique dans l’aide fournie avec -h.
le 11 février 2016 à 14:01
Merci pour ces réponses rapides..


2. L’UTF-8 est requis, parce que c’est compliqué de gérer tous les formats et que ce n’est pas mon rôle, il y a beaucoup d’outils pour faire la conversion. En revanche, sous Windows, l’UTF-8 passe normalement tant qu’on n’essaie pas d’afficher le texte dans la console. Je ne suis pas sûr de comprendre ton problème.



Je vais réessayer demain. Le problème est que je transfère des fichiers entre Linux et Windows et entre différents PCs, ce qui fait que je ne sais pas toujours en quel codage je suis.
le 11 février 2016 à 14:42
pour conclure (!?) :

le mystère s’épaissit : sur le Windows7 de travail cela crache, mais pourquoi ?
Car je me suis fait un fichier en UTF-8 que je trimballe de PC en PC et ce fichier est tout à fait "opérable"
en Linux et ... sur un Windows10 !
Donc c’est autre chose qui provoque le problème...

Pour info voilà la ligne de commande et le trace obtenu :


c:\Python34\python.exe parser.py -f essai_utf8.res.txt
Grammalecte v0.5.0b5
Traceback (most recent call last):
File "parser.py", line 118, in
main()
File "parser.py", line 81, in main
print("\xa7 %d\r" % i, end="", flush=True)
File "c:\Python34\lib\encodings\cp437.py", line 19, in encode
return codecs.charmap_encode(input,self.errors,encoding_map)[0]
UnicodeEncodeError: ’charmap’ codec can’t encode character ’\xa7’ in position 0: character maps to



Le fichier utilisé :


ceci est un test sans accents.

Ici ça sera l’accentué étêtée où là l’abîme crie Noël ! À plus tard sur le siège du Pô.

FIN.



et le fichier "res" partiellement obtenu :


ceci est un test sans accents.
^
* 30:31 # 182p : Espace(s) en fin de ligne à supprimer.
> Suggestions :


EDIT :
le pointeur de faute "accent circonflexe" est mal positionné ici : il est en fait au bout de la ligne
Fin EDIT

(j’ai aussi une image jpg du "dump" en hexadécimal du fichier essayé montrant que c’est de l’UTF-8 sans BOM)

Je continue mes tests sur d’autres PCs et d’autres variantes de Windows.
le 13 février 2016 à 05:59
Envoie-moi le fichier par mail. Merci.
le 13 février 2016 à 08:51
Je viens de comprendre. J’aurais dû mieux lire ton message d’erreur.
Sur ton Windows, la console utilise le codage cp437. C’est donc un Windows en langue américaine, je présume…

Ta console ne peut apparemment pas afficher le caractère § à la ligne 81 de parser.py.
Remplace ce caractère par un caractère ASCII quelconque, et ça va marcher.
le 13 février 2016 à 11:16
Merci !
Je n’aurais pas trouvé ; effectivement le PC de travail est configuré par un administrateur central et j’aurais eu "la même blague" sur les autres PC de travail où j’ai accès.
le 13 février 2016 à 15:05

Admin :
...
Remplace ce caractère par un caractère ASCII quelconque, et ça va marcher.



Essai réussi, tout fonctionne à merveille !
Un grand merci...
le 15 février 2016 à 07:11
Nouvelle bêta : [[ lien supprimé ]]
(J’ai amélioré les points que tu as mentionnés.)
le 15 février 2016 à 10:07
OK, après de rapide(s) test(s), fonctionne sous Windows7 et Linux.
L’option -tfo est très bien.
Plus de problème de ponctuation en fin de lignes (test sous LO).
L’essayer c’est l’adopter.

J’attends avec impatience la première version sous Firefox ;-)
le 15 février 2016 à 17:43
Nouvelle bêta : [[ lien supprimé ]]
le 13 mars 2016 à 18:10
Quelques corrections pour Grammalecte-v0.5.0b7 (fichier fr-rules.txt) :
* Utilisez le signe des degrés *apprioprié* (→ approprié)
* Confusion. *le* (→ Le) grès est une roche détritique.
* Confusion. L’héro est l’*abrévation* (→abréviation) de “héroïne”
* *disgestive* → digestive
le 13 mars 2016 à 19:33
Corrigé. Merci.
le 13 mars 2016 à 20:11
LanguageTool en ligne de commande a l’option --api qui est utile pour intégrer LanguageTool dans d’autres applications. Avec --api, LanguageTool génère une sortie stdout en xml, plus facile et moins ambigüe pour intégrer LanguageTool. Je l’utilise dans le plugin LanguageTool pour Vim. Serait-il possible d’avoir une option similaire pour Grammalecte en ligne de commande ? Je pense toujours créer un plugin Vim pour Grammalecte et une telle option serait utile. Malheureusement, je n’ai pas beaucoup de temps libre et il va falloir attendre un peu pour ce plugin.
le 02 avril 2016 à 09:01

Serait-il possible d’avoir une option similaire pour Grammalecte en ligne de commande ?


Absolument. Cela dit, je préfère nettement le JSON. Mais j’imagine que ce n’est pas difficile de faire du XML aussi.
le 02 avril 2016 à 09:13
Nouvelle bêta : [[ lien supprimé ]]

Avec une sortie en JSON.

À noter que l’ordre des attributs des objets n’est pas fixé, attendu que les erreurs sont sous forme de dictionnaires en Python. Si ça pose problème, je peux utiliser des dictionnaires ordonnés (c’est moins rapide, mais ça ne devrait pas être handicapant).

Finalement, j’aimerais vraiment éviter le XML, ce n’est pas aussi pratique à manipuler.

Le fichier parser.py s’appelle à présent cli.py.
le 02 avril 2016 à 16:51

Absolument. Cela dit, je préfère nettement le JSON. Mais j’imagine que ce n’est pas difficile de faire du XML aussi.


Merci. JSON est parfait. Les versions récentes de Vim disposent même d’une fonction json_decode() vimhelp.appspot.com… pour décoder JSON en structures de Vim script.
le 02 avril 2016 à 17:55
Nouvelle bêta : [[ lien supprimé ]]
le 02 mai 2016 à 11:23
Nouvelle bêta : [[ lien supprimé ]]
(Il y avait un problème avec le formateur de texte.)
le 03 mai 2016 à 19:20

Notification par e-mail    2