Re: Résolution des rapports pology check_rules
xavier Besnard
xavier.besnard at neuf.fr
Lun 31 Aou 16:45:34 BST 2026
Bonjour Côme.
Je relance ton sujet sur la collecte des erreurs de pology.
J'ai appris le python durant la période COVID et je l'ai utilisé pour la
gestion des traductions.
J'ai donc des scripts qui collectent des infos sur les fichiers de
traduction et les stockent dans une base de données SQLite.
Dans la base, j'ai toutes les erreurs Spell et Rules, que je traite via
un interface graphique Qt6.
J'ai un fichier d'exigences fonctionnelles associées à mes scripts.
Si cela t'intéresse, je peux te pousser le code et/ou la base.
A+. Xavier
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 ?
--
Xavier Besnard
22 Place de la halle
82330 Varen
Courriel:xavier.besnard at neuf.fr
Portable: 06 49 37 44 17
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://mail.kde.org/pipermail/kde-francophone/attachments/20260831/2fa676d8/attachment-0001.htm>
-------------- section suivante --------------
Une pièce jointe autre que texte a été nettoyée...
Nom: sJ8qV3Qt8llxnYFJ.png
Type: image/png
Taille: 290121 octets
Desc: non disponible
URL: <http://mail.kde.org/pipermail/kde-francophone/attachments/20260831/2fa676d8/attachment-0001.png>
Plus d'informations sur la liste de diffusion kde-francophone