OK
AJAX error!

Les forumsDictionnaireOrdinaux : 1er, 1ers 1re, 1res, 2e, 2es 3e, 3es, … 4321e, 4321es …

Ordinaux : 1er, 1ers 1re, 1res, 2e, 2es 3e, 3es, … 4321e, 4321es …

LanguageTool intègre le dictionnaire Hunspell de Dicollecte-4.8.

Pour LanguageTool, j’ai ajouté les chiffres à WORDCHARS dans le fichier Hunspell *.aff, afin d’accepter les mots comme CO2, MP3, CM1, CE2, …, déjà présents dans le dictionnaire dicollecte, mais pas reconnus par Hunspell, car les chiffres ne font pas partie de WORDCHARS. J'ai donc changé WORDCHARS en…

WORDCHARS -’'0123456789

Sans ce changement, CO était marqué comme erreur (fausse erreur) dans le mot CO2 par exemple.
Avec le changement, les mots CO2, MP3, CM1, CE2 (etc) sont bien reconnus.

Mais maintenant, les mots comme 1er, 1ers, 1re, 1res, 2e, 2es, (pour premier, premiers, …) sont indiqués comme erreur (absents dans le dictionnaire).

Ne devrait-on pas les ajouter au dictionnaire dicollecte ?

La doc Hunspell (sourceforge.net…) indique :

===
COMPOUNDRULE compound_pattern
Define custom compound patterns with a regex-like syntax. The first COMPOUNDRULE is a
header with the number of the following COMPOUNDRULE definitions. Compound patterns con-
sist compound flags, parentheses, star and question mark meta characters. A flag followed by a ‘*’
matches a word sequence of 0 or more matches of words signed with this compound flag. A flag
followed by a ‘?’ matches a word sequence of 0 or 1 matches of a word signed with this compound
flag. See tests/compound*.* examples.

Note: en_US dictionary of OpenOffice.org uses COMPOUNDRULE for ordinal number recogni-
tion (1st, 2nd, 11th, 12th, 22nd, 112th, 1000122nd etc.)
===
le 27 décembre 2012 à 21:51
La raison pour laquelle je n’ai jamais intégré ces entrées dans le dico, c’est que les mots contenant un chiffre sont reconnus par défaut par le correcteur orthographique, du moins dans LO/OO et Mozilla. Du coup, je n’ai jamais vu grand intérêt à les intégrer.
CO2, MP3 et les quelques autres mots de la sorte n’étaient là que parce que ce fut demandé et parce que ça pouvait éventuellement être utile à la correction grammaticale.

Je ne sais pas si c’est une bonne idée d’utiliser les règles de composition pour ça, attendu que ça ralentit pas mal le correcteur, ai-je lu plusieurs fois. Il faudrait prendre le temps de tester ça. Du coup, je préférerais sans doute qu’on ajoute les nombre ordinaux les plus courants manuellement, comme on l’a fait pour les siècles : www.dicollecte.org…

À quoi sert Hunspell dans LT ?
le 28 décembre 2012 à 10:32

les mots contenant un chiffre sont reconnus par défaut par le correcteur orthographique, du moins dans LO/OO et Mozilla.


OK, peut-être que LT devrait faire cela aussi. Je vais y réfléchir.

Je ne sais pas si c’est une bonne idée d’utiliser les règles de composition pour ça, attendu que ça ralentit pas mal le correcteur, ai-je lu plusieurs fois


Le dictionnaire Hunspell anglais-US fait déjà cela. Il serait intéressant de mesurer le ralentissement.

À quoi sert Hunspell dans LT ?


Depuis la version LT-1.8, LT est disponible dans 2 versions :

* la version LT plugin pour Libreoffice/Openoffice qui détecte les fautes de grammaire mais pas les fautes d’orthographe, car dans LibreOffice/OpenOffice on peut ajouter un dictionnaire ;
* la version LT autonome qui détecte les erreurs de grammaire ainsi que les fautes d’orthographe directement avec Hunspell ou dictionnaire FSA selon les langues. Cette version est adaptée pour l’utilisation en ligne de commande, pour un serveur, pour le plugin de Vim, etc. Le fichier autonome à télécharger est plus gros (57 MB au lieu de 33 MB) puisqu’il contient des dictionnaires orthographiques dans plusieurs langues.

Voir www.languagetool.org… et www.languagetool.org…

Ça mérite d’être mieux expliqué sur le site de LT je pense.

Étant un utilisateur de Vim, je peux enfin utiliser la correction orthographique avec le dictionnaire Dicollecte récent grâce à LT qui utilise Hunspell depuis LT-1.8. Le dictionnaire orthographique français de Vim par défaut ne fonctionnait qu’avec un très vieux dictionnaire Myspell français (d’OpenOffice-2.x).
le 28 décembre 2012 à 10:54

CO2, MP3 et les quelques autres mots de la sorte n’étaient là que parce que ce fut demandé et parce que ça pouvait éventuellement être utile à la correction grammaticale


Indiquer que 1er est masculin singulier, 1re est féminin singulier, 1ers est masculin pluriel, 1res est féminin pluriel (etc) dans le dictionnaire dicollecte pourrait aussi être utile pour la correction grammaticale.
le 28 décembre 2012 à 11:12

Depuis la version LT-1.8, LT est disponible dans 2 versions


En fait, oui, je le savais, mais c’est le doublon orthographique avec le FSA qui m’étonne. L’inclusion de Hunspell, c’est juste pour les suggestions ?

Ah non, en fait, je crois que je viens de comprendre en réfléchissant un peu. J’imagine que contrairement à la langue française les dictionnaires Hunspell ne sont pas les mêmes que ceux fournis par FSA, et que les autres dicos Hunspell sont peut-être plus fournis et plus aptes pour la correction orthographique.

Indiquer que 1er est masculin singulier, 1re est féminin singulier, 1ers est masculin pluriel, 1res est féminin pluriel (etc) dans le dictionnaire dicollecte pourrait aussi être utile pour la correction grammaticale.


En effet.

Je vais ajouter les nombres ordinaux de 1 à 9. On verra ensuite si on étend le nombre d’entrées de la sorte ou si on utilise les règles de composition pour les nombres supérieurs à 9.
le 28 décembre 2012 à 12:33

En fait, oui, je le savais, mais c’est le doublon orthographique avec le FSA qui m’étonne. L’inclusion de Hunspell, c’est juste pour les suggestions ?


Plusieurs raisons :

* suggestions de Hunspell, mais c'est tellement lent avec Hunspell que les suggestions sont désactivées pour plusieurs langues dont le français. Avec les dictionnaires FSA, les suggestions sont plus rapides mais pas aussi sophistiquées je crois.

* certaines langues utilisent différentes sources pour les dictionnaires grammatical et orthographique. Pour le breton par exemple, la grammaire utilise le dictionnaire d’Apertium (très bien étiqueté) mais qui ne contient pas autant de mot que le dictionnaire Hunspell (mal étiqueté pour la grammaire). Hunspell est donc meilleur pour l’orthographe et Apertium meilleur pour la grammaire.

* le dictionnaire grammatical utilise FSA qui ne permet pas toutes les possibilités de Hunspell. Je ne suis pas expert mais je crois que les dictionnaires FSA ne supportent pas les directives COMPOUNDRULE (important pour l’allemand je pense), ICONV et sans doute bien d’autres. Tu dois connaitre ça mieux que moi :-)

* FSA est plus rapide pour l'analyse grammaticale.

* Le découpage en tokens peut être différent pour l’analyse grammatical et pour l'orthographe. C'est le cas pour le français. Pour la grammaire, l’apostrophe coupe les mots. « J'arrive = J + ' + arrive », 3 tokens donc pour l’analyse grammaticale, alors que « J’arrive » est un seul token pour l'orthographe avec Hunspell. Peut-être qu’on devrait couper les mots de la même manière, mais cela demande de nombreuses modifications des règles de grammaire. Pour la grammaire, je préfèrerai en fait couper en 2 tokens plutôt que 3 comme cela «J’arrive = J’ + arrive » avec « j’ » qui aurait pour lemme « je ».

Il y a peut-être d’autres raisons pour la duplication des dictionnaires orthographiques et grammaticaux.

Chaque langue dans LT a un dictionnaire FSA pour les POS tags (à part l’espéranto qui est suffisamment régulier pour ne pas avoir besoin de dictionnaire).

Chaque langue a un dictionnaire pour l’orthographe: Hunspell (pour le français par exemple) ou FSA (différent du FSA pour la grammaire, pour le breton par exemple).
le 28 décembre 2012 à 15:23
OK, en résumé, c’est le boxon. :)

Note que pour la tokenization, dans un avenir indéterminé (donc pas avant longtemps, pour être plus précis), le dictionnaire pour Hunspell considérera probablement l’apostrophe comme un séparateur de mots. Ce sera alors le dictionnaire v5.0. C’est un objectif à long terme. Mais je veux que Grammalecte soit prêt pour ce changement et ce n’est pas encore du tout le cas.
Ceci dit, rien ne t’empêche dans la version pour LT d’ajouter une directive BREAK si tu en as besoin.

BREAK 4
BREAK -
BREAK .
BREAK '
BREAK ’

le 28 décembre 2012 à 15:49

Note que pour la tokenization, dans un avenir indéterminé [...] le dictionnaire pour Hunspell considérera probablement l’apostrophe comme un séparateur de mots.


Est-ce une bonne idée ? Le dictionnaire doit reconnaitre le mot « aujourd’hui » mais doit donner une erreur à « aujourd ». Il doit aussi indiquer une erreur à quelque-chose de plus probable comme « presqu’au ».

Comment va-t-on reconnaitre tout cela si l’apostrophe devient un séparateur ?

Pas facile d'ajouter ces règles à LanguageTool ou Grammalecte. Et ça ne serait pas idéal de toute façon, car pas mal de gens n’utilisent que la correction orthographique sans la correction grammaticale.

Pour BREAK, j’ai lu la documentation Hunspell mais j’avoue que je n’ai pas trouvé ça très clair. J’ai essayé ça sans succès :

BREAK 5
BREAK -
BREAK .
BREAK '
BREAK ^'
BREAK '$

Ce que je voudrais, c'est ne pas donner d’erreur dans ces exemples :

Correct : aujourd'hui.
Correct : 'exemple'
correct : presqu'ile
Correct : 'un exemple'

Mais indiquer des erreurs dans ces exemples :

Incorrect : aujourd.
Incorrect : un'deux
Incorrect : presqu'au

Mais c’est un tout autre problème que le sujet de ce fil…
le 02 janvier 2013 à 16:57
Apparemment, ceci fait ce que je désire :

BREAK 6
BREAK -
BREAK .
BREAK ^'
BREAK ^‘
BREAK '$
BREAK ’$

Étrange, j’étais sûr d’avoir déjà essayé cela sans succès auparavant, mais maintenant ça marche.
Peut-être devrait-on ajouter cela au dictionnaire officiel Dicollecte ?

Par contre je vois que les mot « aujourd » et « hui » ne sont pas signalés comme erreur :
* « hui » est dans le dictionnaire avec une proposition pour le supprimer ;
* par contre, pour « aujourd » je ne vois pas pourquoi Hunspell ne le signal pas comme erreur.

le 02 janvier 2013 à 19:22

Est-ce une bonne idée ?


C’est une bonne question. :)
Je pense que ça améliorera grandement la rapidité du correcteur, et notamment des suggestions, car la scission des apostrophes va simplifier énormément le fichier des affixes. Les milliers de règles pour gérer les élisions ne seront plus nécessaires. Beaucoup de drapeaux n’existeront plus. Plus de S*, X*, F*, W*, a1… a5, b1… b5, c1… c5, d1… d5, e1… e5, f1… f5. Même les règles qui resteront seront simplifiées. À vue de nez, je pense que ce nouveau système sera au moins dix fois plus simple que l’actuel.

Le dictionnaire doit reconnaitre le mot « aujourd’hui » mais doit donner une erreur à « aujourd ». Il doit aussi indiquer une erreur à quelque-chose de plus probable comme « presqu’au ». Comment va-t-on reconnaitre tout cela si l’apostrophe devient un séparateur ?


Il faudra ajouter les formes élidées des articles et pronoms.

Pour les quelques cas comme aujourd’hui, je crois que ça peut passer avec WORDCHARS + BREAK.
En gros, le correcteur tient compte des apostrophes dans les mots, mais scinde les deux parties si un mot n’est pas reconnu.

Pas facile d'ajouter ces règles à LanguageTool ou Grammalecte.


Pour LT, je ne sais pas. Pour Grammalecte, il faudra créer des règles supplémentaires, mais surtout démêler le sac de nœuds pour gérer les apostrophes (contrairement à LT, il n’y a pas de tokens dans Grammalecte).
Pour l’instant, l’incrédulités est considérée comme une erreur orthographique, puisque Hunspell veille à ne pas générer les pluriels avec l’. Mais c’est quand même une erreur grammaticale. Il peut y avoir des avantage à gérer ça grammaticalement.

Et ça ne serait pas idéal de toute façon, car pas mal de gens n’utilisent que la correction orthographique sans la correction grammaticale.


En effet, c’est pourquoi ce ne sera pas avant la création d’une extension pour Firefox. Autrement dit, ce n’est pas demain la veille. :)


BREAK 6
BREAK -
BREAK .
BREAK ^'
BREAK ^‘
BREAK '$
BREAK ’$

Étrange, j’étais sûr d’avoir déjà essayé cela sans succès auparavant, mais maintenant ça marche.
Peut-être devrait-on ajouter cela au dictionnaire officiel Dicollecte ?


Je ne sais pas si c’est bien utile. LO/OO et autre logiciels ont déjà leur tokenizer qui gère ça pour nous. Comme tu le constates, tu peux écrire des choses comme mot- ‘mot mot' … sans susciter d’alertes de la part du correcteur.

Mais c’est un tout autre problème que le sujet de ce fil…


Pas grave. Je vais scinder le fil et tout remettre proprement quand j’aurai le temps.
le 03 janvier 2013 à 10:44

Je ne sais pas si c’est bien utile. LO/OO et autre logiciels ont déjà leur tokenizer qui gère ça pour nous. Comme tu le constates, tu peux écrire des choses comme mot- ‘mot mot' … sans susciter d’alertes de la part du correcteur.


Oui, mais certaines personnes n'utilisent pas LO/OO. Certaines personnes utilisent Hunspell en ligne de commande par exemple.

Voici ce que donne Hunspell en ligne de commande avec le dictionnaire dicollecte-4.8 (sans modifications) :

$ echo "Il ‘fait beau’ aujourd'hui. Un'deux. Presqu’au. Presqu’ile." | hunspell -a -d fr-toutesvariantes
@(#) International Ispell Version 3.2.06 (but really Hunspell 1.3.2)
*
*
& beau’ 3 11: beau, beauf, beaux
& aujourd 1 19: aujourd’hui
*
*
*
& Presqu’au 1 41: Presque
& Presqu’ile 2 54: Presqu’ile, Resquille

Les lignes commençant par & indiquent des fautes d’orthographe trouvées par Hunspell.

Il y a plusieurs problèmes :

* Hunspell indique des fausses erreurs à beau’ aujourd et Presqu’ile (pour lequel il suggère même le même mot !?) ;
* un’deux n’est pas reconnu comme une erreur alors que c’est une erreur.

Et voici ce que donne Hunspell en ligne de commande avec le dico modifié pour LanguageTool :

$ echo "Il ‘fait beau’ aujourd'hui. Un'deux. Presqu’au. Presqu’ile." | hunspell -a -d fr_FR
@(#) International Ispell Version 3.2.06 (but really Hunspell 1.3.2)
*
*
*
*
& Un'deux 1 32: Deux-deux
& Presqu’au 3 41: Pres qu’au, Pres-qu’au, Presque
*

Maintenant, c’est parfait :

* ‘fait beau’ est bien accepté ;
* presqu’ile est bien accepté.
* Un’deux est bien reconnu comme erroné ;

Le dictionnaire Hunspell-4.8 modifié pour LT se trouve ici :

languagetool.svn.sourceforge.net…

Voici le diff entre le dictionnaire officiel dicollecte-4.8 et le dictionnaire modifié pour LT :

$ diff -c fr-toutesvariantes.aff fr_FR.aff
*** fr-toutesvariantes.aff 2013-01-03 11:37:40.379569211 +0100
--- fr_FR.aff 2013-01-03 09:51:10.987690692 +0100
***************
*** 11,17 ****

SET UTF-8

! WORDCHARS -’


TRY esntiarulodcpmévqfgbhàxèjyêMILzACçôîPâùJFSûBVœRDGNETHXkïOwKWYUëQÉZŒüãÎáöóÈíæÅñäśńÿ
--- 11,18 ----

SET UTF-8

! # D. Pelle (20121223): Changed for LanguageTool from WORDCHARS -’ in dicollecte-4.8
! WORDCHARS -’'0123456789


TRY esntiarulodcpmévqfgbhàxèjyêMILzACçôîPâùJFSûBVœRDGNETHXkïOwKWYUëQÉZŒüãÎáöóÈíæÅñäśńÿ
***************
*** 100,106 ****

KEY azertyuiop|qsdfghjklmù|wxcvbn|aéz|yèu|iço|oàp|aqz|zse|edr|rft|tgy|yhu|uji|iko|olpm|qws|sxd|dcf|fvg|gbh|hnj

! ICONV 32
ICONV à à
ICONV â â
ICONV ä ä
--- 101,108 ----

KEY azertyuiop|qsdfghjklmù|wxcvbn|aéz|yèu|iço|oàp|aqz|zse|edr|rft|tgy|yhu|uji|iko|olpm|qws|sxd|dcf|fvg|gbh|hnj

! # D. Pelle (20121223): Added ICONV ’ ' for LanguageTool.
! ICONV 33
ICONV à à
ICONV â â
ICONV ä ä
***************
*** 133,138 ****
--- 135,141 ----
ICONV Ü Ü
ICONV Ÿ Ÿ
ICONV Ç Ç
+ ICONV ’ '

OCONV 1
OCONV ' ’
***************
*** 154,163 ****
NOSUGGEST --


!
! BREAK 2
BREAK -
BREAK .

COMPOUNDMIN 2

--- 157,170 ----
NOSUGGEST --


! # D. Pelle (20130102): added BREAK rules for apostrophes/quotes.
! BREAK 6
BREAK -
BREAK .
+ BREAK ^'
+ BREAK ^‘
+ BREAK '$
+ BREAK ’$

COMPOUNDMIN 2


Même si LO/OO n’utilise pas BREAK, il n’y a pas de mal à ajouter des directives afin que Hunspell en ligne de commande fonctionne mieux à mon avis.
le 03 janvier 2013 à 11:46
OK. J’ai ajouté de nouvelles directives pour le prochain dictionnaire.

WORDCHARS -’'1234567890

ICONV 33
ICONV ’ '
[...]

BREAK 6
BREAK -
BREAK .
BREAK ^'
BREAK ^‘
BREAK '$
BREAK ’$

le 04 janvier 2013 à 12:27

OK. J’ai ajouté de nouvelles directives pour le prochain dictionnaire.


Merci !

Pour ce qui est de WORDCHARS -’'1234567890, je dois quand même avouer qu’il y a du pour et du contre.

Grâce à cette directive, les mots tels que CO2 sont bien reconnus mais en revanche les heures telles que 2h30 donnent une erreur. D’après Wikipedia (fr.wikipedia.org…) il faut des espaces de toute façon autours du h (→ 2 h 30) mais en pratique je vois souvent les heures écrites sans espace (2h30). Je me demande si LT ou Grammalecte devraient corriger « 2h30 » en « 2 h 30 » ou si c’est trop pinailler.
le 13 janvier 2013 à 22:31
Ça ne me pose pas de problème. Le rôle du correcteur est de souligner les erreurs, et c’est bien le cas ici. Effectivement, les gens ont tendance à souder les unités avec les nombres. Ça mérite correction.
Mais là, je suis en train d’essayer de déboguer Grammalecte pour LibreOffice 4 en priorité.
le 14 janvier 2013 à 13:00

Notification par e-mail    0