Re: Résolution des rapports pology check_rules
Côme Allart
come.allart at netc.fr
Dim 30 Aou 20:00:09 BST 2026
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/20260830/07f3aad0/attachment-0001.htm>
Plus d'informations sur la liste de diffusion kde-francophone