Bonjour,

Comme signalé dans un autre poste j'essaie de porter le code en Rust, donc je me base sur votre code mais il y a des endroits où je ne sais pas si c'est réellement un "bug" ou si c'est voulu. Dois-je donc utiliser les Tickets ou est-ce le forum (si c'est le cas il faut peut-être ouvrir un espace pour parler du code) ?

Un exemple vaut sans doute plus que de grandes explications dans ibdawg.js.

getMorph (sWord) {
// retrieves morphologies list, different casing allowed
sWord = str_transform.spellingNormalization(sWord);
let l = this.morph(sWord);
if (sWord[0].gl_isUpperCase()) {
l.push(...this.morph(sWord.toLowerCase()));
if (sWord.gl_isUpperCase() && sWord.length > 1) {
l.push(...this.morph(sWord.gl_toCapitalize()));
}
}
return l;
}

getMorph("Salut") => [">salut/:N:m:s/*"] : OK
getMorph("SAlut") => [">salut/:N:m:s/*"] : OK
getMorph("sAlut") => [] : Est-ce le comportement voulu ?

Bonjour,

Je préfère discuter sur le forum.
Ça m’ennuie d’avoir deux lieux de discussion. Je vais probablement fermer les tickets de Fossil.
Par contre ce forum n’a rien pour citer le code. Faudrait que je le retouche.

Mais, oui, c’est bien le comportement voulu, même si le deuxième cas devrait peut-être renvoyer une liste vide.

Je trouve que les tickets Fossil ne sont pas du tout pratique :s d'où ma demande ;)

Ma question pour getMorph vient du fait qu'elle est utilisé dans spellchecker.js qui est en quelque sorte l'API haut niveau et donc pour moi elle permet de corrigé quelques erreurs qui peuvent être faite et donc j'aurais plutôt pensé que le 3ème cas cette fonction devait renvoyer aussi la liste car la majuscule était une erreur de saisie (peut être que si j'avais mis comme exemple

getMorph("sALUT")

ça aurait été plus parlant).

J'avoue ne pas trop comprendre le but de cette fonction telle qu'elle est implémenté.

Pour le code peut être que juste ajouté dans le css un ferait l'affaire ;)

blockquote p {
white-space: pre;
}
blockquote p br {
display: none;
}

Je m'explique pourquoi je ne voie pas l’intérêt de la fonction telle qu'elle est actuellement car c'est un peu pareil pour isValid() et isValidToken().

Vous connaissez bien le dictionnaire donc vous savez qu'il y a :
* Principalement des mots en minuscule
* Des mots avec la première lettre en majuscule le reste en minuscule : Paris
* Des mots entièrement en majuscules ex: PDF
* Le cas aussi avec les - ex: États-Unis, sous-titre
-- Autres cas beaucoup moins courant
* Contenant un chiffre
* Contenant des exposants
* Contenant des indices
* Avec signes divers (surtout mathématique)

Je pense qu'il est donc nécessaire de :
* Vérifier telle qu'il est saisie
* Vérifier si la saisie en minuscule existe
* Vérifier si la saisie en majuscule existe
* Vérifier si la saisie en "Title" amélioré (qui met aussi une majuscule après les "-" +stopword en minuscule) existe
A se niveau il y aurais déjà la plupart des cas de vérifié.

Peut être en option :
* Vérifier avec les chiffres mis en exposant
* Vérifier avec les chiffres mis en indice

Des lettres en indice ou en exposant sont tellement anecdotique je ne pense pas qu'il soit nécessaire de faire des transformations pour géré c'est cas la.

---

Sinon, j'ai remarqué que dans la version Python self.bAcronymValid = False tandis que la version js this.bAcronymValid = true; cette variable n'est défini que dans le constructeur de IBDAWG et jamais redéfinis. Elle est utilisé dans isValid()
mais dans la version js

return !!(this.bAcronymValid || this.lookup(sWord.toLowerCase()) || this.lookup(sWord.gl_toCapitalize()));

vue qu'el est défini sur true le return sera donc toujours true quelque soit le lookup(). et dans la version python étant toujours false elle ne sert a rien.
J'ai soit loupé quelques choses soit elle peut être supprimé...

Je pense qu'il est donc nécessaire de :
* Vérifier telle qu'il est saisie
* Vérifier si la saisie en minuscule existe
* Vérifier si la saisie en majuscule existe
* Vérifier si la saisie en "Title" amélioré (qui met aussi une majuscule après les "-" +stopword en minuscule) existe
A se niveau il y aurais déjà la plupart des cas de vérifié.

C’est ce que le correcteur fait DÉJÀ.
PLUS la prise en compte des tokens à tirets multiples.
Quel problème voulez-vous corriger ?
Le correcteur est en effet relativement tolérant sur la question de la casse et des tirets, mais c’est bien le comportement voulu, tout simplement parce que, notamment sur le Web, le pullulement des sigles et des mots composés en tout genre nous ferait signaler beaucoup trop de choses.

bAcronymValid est différente en Python parce que LibreOffice gère déjà ce cas de son côté et qu’il ne faut pas ignorer ce réglage.
En effet, ce test ne sert à rien en JavaScript, sauf s’il me prend de passer cette variable à false. Et je ne vais pas m’ennuyer à chercher à savoir ce qu’il faut réécrire dans le code pour que ça fonctionne correctement. Donc, ce test reste tel quel.

Je suis d'accord sur le fait qu'il faut être tolérant mais rien n’empêche d'être en plus cohérent ;)

Il y a une incohérence par exemple pdf est signalé en tant qu'erreur alors que SALUT est valide.

Sinon l'autre incohérence est celle signalé plus haut getMorph("SAlut") retourne un résultat alors que le lexicographe dit que c'est inconnu.

Dans la fonction isValid(sWord) dans ibdawg.js il y a

if (sWord.includes("'")) { // ugly hack
sWord = sWord.replace("'", "’");
}

je pense qu'il aurait plus ça place dans le isValid(sWord) de spellchecker.js c'est inutile de faire cette transformation pour la vérification dans chaque dictionnaire.

En se qui concerne bAcronymValid vu que la version python n'a pas la même valeur ça veux dire que le serveur et le cli python ne donne pas le même résultat que le javascript dans certain cas. Donc même si LibreOffice le gère de son côté il y a quelque chose a faire avec cette variable.