Re: Résolution des rapports pology check_rules
Côme Allart
come.allart at netc.fr
Mar 1 Sep 16:28:21 BST 2026
Bonjour,
Désolé, ce message est long ! J'ai mis des « a) » si vous voulez
répondre à des points particulier.
a) J'ai récupéré ta MR, voici les nouvelles 5 règles qui produisent le
plus de rapports, par ordre croissant.
open../pology-jjazeix.yaml|last5|each{{ rule: $in.rule, reports:
($in.items|length), files: ($in.items.file|uniq|length)}}
╭──────────────────────────────────────────────────────────────rule───────────────────────────────────────────────────────────────┬─reports─┬─files─╮
│ [note] rule [pattern=MacOS] ==> MacOS -> macOS
│
206 │ 46 │
│ [note] rule [pattern=rafraîch] ==> Suppression de l'accent circonflexe
dans les dérivés de « rafraichir » (orthographe de 1990) │ 207 │ 93 │
│ [note] rule [id=apostrophe] ==> Utilisez le symbole apostrophe (touche
4 sur un clavier français) │ 294 │ 64 │
│ [note] rule [pattern=\bboîtes?\b] ==> boîte => boite (sans accent
circonflexe, réforme orthographique de 1990) │ 527
│ 158 │
│ [note] rule [pattern=`] ==> Utiliser de vrais guillemets, au lieu
d'une apostrophe (homogénéité) │ 1631
│ 204 │
╰──────────────────────────────────────────────────────────────rule───────────────────────────────────────────────────────────────┴─reports─┴─files─╯
b) Les ` sont toujours là, je peux appliquer boîte -> boite (d'après ta
modif) et ’ -> ' (comme discuté précédemment).
Ça vous va si j'applique rafraîchir -> rafraichir et MacOS -> macOS ?
c) Dans tous les cas, je ferai un envoi par application de règle si ça
vous va.
d) Concernant plus spécifiquement les !
open../pology-jjazeix.yaml|whererule=~!|each{ { rule: $in.rule, reports:
($in.items|length), files: ($in.items.file|uniq|length)}}
╭────────────────────────────────────────────────────rule─────────────────────────────────────────────────────┬─reports─┬─files─╮
│ [note] rule [pattern=gallerie] ==> Un seul « l » en français, merci !
│ 1 │ 1 │
│ rule [pattern=!] ==> Mettre une espace insécable avant et une espace
après │ 1 │ 1 │
│ [note] rule [pattern=connection] ==> La bonne orthographe est «
connexion » en français ! │ 4 │ 3 │
│ rule [pattern=text(?![e|uel|\-])] ==> Merci de mettre un « e » à la
fin de « texte » ou « contexte » │ 16 │ 10 │
│ [note] rule [pattern=!] ==> Mettre une espace insécable avant et une
espace après │ 50 │ 14 │
│ [note] rule [pattern=text(?![e|uel|\-])] ==> Merci de mettre un « e »
à la fin de « texte » ou « contexte » │ 70 │ 33 │
╰────────────────────────────────────────────────────rule─────────────────────────────────────────────────────┴─reports─┴─files─╯
e) (Je vois que je peux enlever les [note] en début de règle pour
dédupliquer, je ne sais pas pourquoi pology ajoute ça parfois mais pas
tout le temps…)
f) Si je regarde les fichiers en question
open../pology-jjazeix.yaml|whererule=~=!|getitems|flatten|each{
$"($in.file):($in.line)"}|hx...$in
g) J'ai encore quelques faux-positifs, plus subtiles car il s'agit de
code inclus dans du texte, par exemple dans les textes suivants :
* Bannir *!*@*.hôte
* « !T{TEXTE} » inclut « TEXTE » si le titre de l'album n'est pas spécifié
* La fonction FACTDOUBLE () calcule la factorielle double d'un nombre,
c'est-à-dire x ! !. -> ici il faudrait retirer les espaces, qui ne
sont pas présents dans la version originale
* Pour lancer les dés : !1d6
D'autres faux-positifs :
* Faites le nous savoir !** -> ici l'erreur ne concerne pas l'espace
avant mais l'absence d'espace après. Les ** notent ici la fin de
texte en gras en Markdown
* {{< alert color=\"danger\" title=\"Ce processus est dangereux !\">}}
-> ici c'est du texte dans du code et non l'inverse, idem c'est
l'absence d'espace après qui semble poser problème
h) Notes :
* ! [ est bien détecté comme erroné. C'est pas vraiment le bon message
d'erreur mais ce n'est pas grave, il faut juste que je colle ! et [
pour corriger
* Je vois que des espaces fines sont utilisées avant les deux-points,
il me semble que c'est un cas particulier et que c'est plutôt une
espace insécable normale qu'il faudrait mettre, contrairement à
d'autres ponctuations comme ; ! etc.
* FACTDOUBLE () devrait être FACTDOUBLE() et je n'ai pas d'idée pour
ignorer ça
i) En tout cas c'est déjà bien mieux, ton filtre me permet de trouver de
vraies occurrences de l'erreur !
j) Pour les faux positifs restants, on pourrait par exemple regarder les
caractères autour :
* Si le caractère précédent n'est pas une fin d'élément (parenthèse
ouverte, « ou autre symbole qui n'est pas une ponctuation comme * ou
@), ignorer la règle
* Sinon, le caractère précédent est une fin d'élément (lettre, » ou
parenthèse fermée), appliquer la règle
* Si le caractère suivant n'est pas un début d'élément (parenthèse
fermée, » ou autre symbole qui n'est pas une ponctuation comme * ou
@), ignorer la règle
* Sinon, le caractère suivant est un début d'élément (lettre, « ou
parenthèse ouverte), appliquer la règle
L'idée serait d'avoir une liste de symboles qui font que la règle est
ignorée, comme ça si on oublie un symbole alors la règle est appliquée
(approche allow-list préférable à deny-list).
k) Ces règles sur ! seraient applicables à ? également, je pense.
l) Pour x!! je ne sais pas trop comment faire. Peut-être mettre ! dans
les symboles qui ne peuvent pas commencer un élément ?
m) Je ne sais pas si c'est prudent de garder une seule règle avec tous
ces cas particuliers. Faudrait-il séparer en deux règles, une pour
l'espace de chaque côté du point d'exclamation ? Mais dans ce cas pour
x!! le rapport proposerait tout de même x !!
n) Finalement, est-ce que faire des dérogations très spécifiques ne
serait pas préférable dans certains cas, pour FACTDOUBLE() et x!! par
exemple ?
Si le format po acceptait quelque chose comme #; allow "FACTDOUBLE()"
au-dessus de la règle en question, ce serait pratique, qu'en pensez-vous ?
Le 31/08/2026 à 20:19, Johnny Jazeix a écrit :
> Bonsoir,
> j'ai rajouté un commit dans ma MR pour essayer de réduire le nombre de
> faux positifs pour les images markdown. Peux-tu tester si c'est mieux
> (ça a l'air, sur les quelques fichiers que j'ai regardé mais j'ai pas
> la vue d'ensemble).
> Pour les apostrophes, ça me va d'harmoniser avec ce que dit la règle.
> Merci de dépoussiérer les règles de pology !
> Johnny
>
>
> Le dim. 30 août 2026 à 21:00, Côme Allart<come.allart at netc.fr> a écrit :
>> Ok, je verrai ce que ça donne avec tes nouvelles règles alors.
>> Pour référence, je remets ici le lien vers la MR que tu mentionnais :https://invent.kde.org/sdk/pology/-/merge_requests/56
>>
>> La règle suivante concerne les espaces autour de ! (620 dans 27 fichiers) et je vois des faux positifs en markdown pour les images : .
>> Une solution serait de ne pas créer de rapport lorsque ! est immédiatement suivi par [
>>
>> Ensuite on a chaîne qui est déjà traité par ta MR (428 dans 121 fichiers)
>>
>> Puis [note] rule [id=apostrophe] ==> Utilisez le symbole apostrophe (touche 4 sur un clavier français
>> Si je comprends bien, utiliser les apostrophes droites et non typographiques (304 dans 66 fichiers)
>> J'applique celle-ci ?
>>
>>
>> Le 30/08/2026 à 20:39, Johnny Jazeix a écrit :
>>
>> Bonsoir,
>> pour la première règle, je pense qu'elle est risquée avec la
>> traduction des sites internet et l'utilisation de `` pour les liens si
>> je ne me trompe pas.
>> comme dit dans l'autre mail, je serai plus partant pour corriger la
>> règle et avoir "boite" partout (j'ai mis à jour la MR).
>>
>> Cordialement,
>> Johnny
>>
>>
>> Le dim. 30 août 2026 à 19:52, Côme Allart<come.allart at netc.fr> a écrit :
>>
>> Bonjour,
>>
>> TL;DR : J'aimerais résoudre les rapports de pology règle par règle, par nombre d'occurrences décroissant.
>> La première règle (remplacer les accents graves / guillemets arrières ` par des guillemets «») ne me semble pas pertinente car elle me semble n'avoir que des faux positifs (1728 rapports dans 203 fichiers).
>> La seconde remplace « boite » par « boîte », j'aimerais savoir si ça vous irait que j'effectue le remplacement dans tous les fichiers (1261 rapports dans 271 fichiers).
>>
>> --- Version longue ---
>>
>> J'ai commencé à regarder les règles pology sur l'ensemble des fichiers (commande nushell ci-dessous)
>>
>> let checks = glob **/*.po | path relative-to ('.' | path expand) | par-each {
>> { path: $in, result: (python3 ../pology/scripts/posieve.py -b check_rules $in | complete) }
>> }
>>
>> J'ai un fichier qui a une erreur, je vais donc l'ignorer pour la suite
>>
>> $checks | where result.exit_code != 0 or result.stderr != ""
>> ╭──────────────────path──────────────────┬───────────────────────────────────────result───────────────────────────────────────╮
>> │ websites-hugo-kde/hugo-kde._static_.po │ ╭───────────┬────────────────────────────────────────────────────────────────────╮ │
>> │ │ │ stdout │ │ │
>> │ │ │ stderr │ posieve.py: [error] There are no internal rules for language 'en'. │ │
>> │ │ │ │ │ │
>> │ │ │ exit_code │ 1 │ │
>> │ │ ╰───────────┴────────────────────────────────────────────────────────────────────╯ │
>> ╰──────────────────path──────────────────┴───────────────────────────────────────result───────────────────────────────────────╯
>>
>>
>> Je me suis dit qu'il serait intéressant de :
>>
>> regrouper les résultats par règle (group-by rule ci-dessous)
>> regarder en priorité les règles qui produisent le plus de rapports (sort-by { $in.items | length })
>> nous mettre d'accord sur l'action à effectuer
>> faire la modification sur l'ensemble des fichiers
>> relire les résultats
>> recommencer avec la règle suivante
>>
>> Donc j'ai bricolé une commande pour parser la sortie des "checks", regrouper par règle et prioriser
>>
>> $checks | where result.exit_code == 0 and result.stderr == "" | get result.stdout
>> | par-each {
>> lines | split list "----------------------------------------" | skip | drop
>> | each {
>> {
>> raw: ($in | str join "\n")
>> ...($in.0 | parse "{file}:{line}(#{nr})" | get 0 | into int line nr)
>> sources: ($in | where $it starts-with "#:" | each {
>> split row " " | skip
>> | each {
>> if $in =~ ':\d+$' {
>> let split = $in | split row :
>> { file: ($split | drop | str join :), line: ($split | last | into int) }
>> } else {
>> { file: $in }
>> }
>> }
>> } | flatten)
>> rule: ($in | last)
>> }
>> }
>> } | flatten
>> | reject raw
>> | group-by rule --to-table --prune | sort-by { $in.items | length }
>> | save ../pology.yaml
>>
>> (Je peux envoyer les résultats au format que vous voulez si vous voulez vous plonger un peu dans les données. Je ne les mets pas ici, c'est un peu gros.)
>>
>> La règle qui produit le plus de rapports est :
>>
>> open ../pology.yaml | last | { rule: $in.rule, reports: ($in.items | length), files: ($in.items.file | uniq | length) }
>> ╭─────────┬──────────────────────────────────────────────────────────────────────────────────────────────────╮
>> │ rule │ [note] rule [pattern=`] ==> Utiliser de vrais guillemets, au lieu d'une apostrophe (homogénéité) │
>> │ reports │ 1728 │
>> │ files │ 203 │
>> ╰─────────┴──────────────────────────────────────────────────────────────────────────────────────────────────╯
>>
>> Cependant, en parcourant les fichiers, je vois beaucoup de faux-positifs, parce que les fichiers sources sont en Markdown ou en ReStructuredText.
>> Si je les enlève, il ne reste plus grand chose
>>
>> open ../pology.yaml | last | get items | where { get sources.0?.file | path parse | get extension | $in not-in [rst md] }
>> ╭────────────────────file─────────────────────┬─line──┬──nr──┬───────────────────sources───────────────────╮
>> │ klevernotes/org.kde.klevernotes.metainfo.po │ 334 │ 53 │ ╭───────────────file───────────────┬─line─╮ │
>> │ │ │ │ │ org.kde.klevernotes.metainfo.xml │ 164 │ │
>> │ │ │ │ ╰───────────────file───────────────┴─line─╯ │
>> │ klevernotes/org.kde.klevernotes.metainfo.po │ 352 │ 56 │ ╭───────────────file───────────────┬─line─╮ │
>> │ │ │ │ │ org.kde.klevernotes.metainfo.xml │ 173 │ │
>> │ │ │ │ ╰───────────────file───────────────┴─line─╯ │
>> │ kile/kile.po │ 6412 │ 948 │ ╭────────file─────────┬─line─╮ │
>> │ │ │ │ │ editorextension.cpp │ 60 │ │
>> │ │ │ │ ╰────────file─────────┴─line─╯ │
>> │ kile/kile.po │ 6424 │ 950 │ ╭────────file─────────┬─line─╮ │
>> │ │ │ │ │ editorextension.cpp │ 62 │ │
>> │ │ │ │ ╰────────file─────────┴─line─╯ │
>> │ ghostwriter/ghostwriter_qt.po │ 1158 │ 177 │ ╭────────file────────┬─line─╮ │
>> │ │ │ │ │ src/mainwindow.cpp │ 1285 │ │
>> │ │ │ │ ╰────────file────────┴─line─╯ │
>> │ ghostwriter/ghostwriter_qt.po │ 1164 │ 178 │ ╭────────file────────┬─line─╮ │
>> │ │ │ │ │ src/mainwindow.cpp │ 1286 │ │
>> │ │ │ │ ╰────────file────────┴─line─╯ │
>> │ kstars/kstars.po │ 55353 │ 6693 │ ╭────file─────┬─line─╮ │
>> │ │ │ │ │ kstars.kcfg │ 4043 │ │
>> │ │ │ │ ╰────file─────┴─line─╯ │
>> ╰────────────────────file─────────────────────┴─line──┴──nr──┴───────────────────sources───────────────────╯
>>
>> En regardant les fichiers en question, il me semble qu'encore une fois il n'y a que des faux positifs pour cette règle. Devrions-nous la supprimer ?
>>
>> La règle suivante me semble plus pertinente :
>>
>> open ../pology.yaml | drop | last | { rule: $in.rule, reports: ($in.items | length), files: ($in.items.file | uniq | length) }
>> ╭─────────┬───────────────────────────────────────────────────────────────────────────────────╮
>> │ rule │ [note] rule [pattern=\bboites?\b] ==> boite => boîte (avec un accent circonflexe) │
>> │ reports │ 1261 │
>> │ files │ 271 │
>> ╰─────────┴───────────────────────────────────────────────────────────────────────────────────╯
>>
>> Est-ce que ça vous va si je l'applique dans tous les fichiers ?
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://mail.kde.org/pipermail/kde-francophone/attachments/20260901/0ba1029d/attachment-0001.htm>
Plus d'informations sur la liste de diffusion kde-francophone