Re: Résolution des rapports pology check rules
Johnny Jazeix
jazeix at gmail.com
Dim 6 Sep 08:53:15 BST 2026
Merci !
J'ai mergé ma MR pour les règles pology et j'ai appliqué tes changements.
Bon dimanche,
Johnny
Le ven. 4 sept. 2026 à 10:46, Côme Allart <come.allart at netc.fr> a écrit :
> Bonjour,
>
> Ci-joint les fichiers modifiés pour la règle « boite ».
>
> Concernant e) voici les résultats en enlevant les [note]
>
> open ../pology-jjazeix.yaml | last 5 | each { { rule: $in.rule, reports: (
> $in.items | length), files: ($in.items.file | uniq | length)
> } }
> ╭───────────────────────────────────────────────────────────────rule
> ───────────────────────────────────────────────────────────────┬───reports
> ───┬───files────╮
> │ rule [pattern=rafraîch] ==> Suppression de l'accent circonflexe dans les
> dérivés de « rafraichir » (orthographe de 1990) │ 213 │
> 97 │
> │ rule [pattern=MacOS] ==> MacOS -> macOS
> │
> 237 │ 51 │
> │ rule [id=apostrophe] ==> Utilisez le symbole apostrophe (touche 4 sur un
> clavier français) │ 345 │
> 68 │
> │ rule [pattern=\bboîtes?\b] ==> boîte => boite (sans accent circonflexe,
> réforme orthographique de 1990) │ 626 │
> 186 │
> │ rule [pattern=`] ==> Utiliser de vrais guillemets, au lieu d'une
> apostrophe (homogénéité) │
> 1692 │ 205 │
> ╰───────────────────────────────────────────────────────────────rule
> ───────────────────────────────────────────────────────────────┴───reports
> ───┴───files────
>
>
>
> De : Côme Allart <come.allart at netc.fr>
> À : kde-francophone at kde.org
> Objet : Re: Résolution des rapports pology check rules
> Date : 01/09/2026 17:28:21 Europe/Paris
>
> 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 | last 5 | 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 | where rule =~ ! | 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 | where rule =~ =! | get items | 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/20260906/5f6c4156/attachment-0001.htm>
Plus d'informations sur la liste de diffusion kde-francophone