Re: Résolution des rapports pology check rules

Côme Allart come.allart at netc.fr
Jeu 3 Sep 10:41:50 BST 2026


 
        
        
        
     1 fichier disponible au téléchargement     
          
     
- work.tar.zst (5,1 Mo) 

Vous pouvez télécharger ce fichier en cliquant sur ce lien ou en le copiant dans la barre d'adresse de votre navigateur

https://www.mailo.com/attachlinks.php?id=MjA2OTkuPGVhLW1pbWUtNmE5OTQwZGUtNjI0OC0zZGVkODFjNkB3d3cubmV0LWMuY29tPg%3d%3d

Ce lien restera valable pendant 30 jours.
     
        
        
        
 

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 : ![desc](chemin).
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/20260903/026a62f8/attachment-0001.htm>


Plus d'informations sur la liste de diffusion kde-francophone