Re: Résolution des rapports pology check rules
Côme Allart
come.allart at netc.fr
Mar 1 Sep 15:02:37 BST 2026
Bonjour Xavier,
Une fois que les données sont stockées sous une forme structurée (yaml, json ou dans une DBB SQLite comme tu le fais), nushell est un très bon outil pour explorer ces données.
Donc maintenant que j'ai ma petite commande pour tout parser et ainsi produire une forme structurée, je pense que le plus dur est fait et je n'ai pas trop d'intérêt à changer d'outil pour l'instant.
En revanche, je pense que la discussion sera intéressante quand mes petites commandes auront atteint leurs limites, ou si nous souhaitons pérenniser ce genre d'outil à l'avenir.
Je pense que la meilleure approche serait de faire en sorte que pology puisse sortir directement les données au format json, et pas nécessairement mis en forme comme c'est le cas actuellement.
Cette approche me semble universelle (chacun peut très facilement utiliser cette sortie dans n'importe quel langage, y compris pour ton outil qui sera plus pratique pour les personnes qui préfèrent avoir une interface graphique) et robuste (pas besoin de créer des parseurs qui ne fonctionneraient plus si la mise en forme de pology changeait).
En tout cas merci pour ta proposition !
À bientôt,
Côme
De : xavier Besnard <xavier.besnard at neuf.fr>
À : kde-francophone at kde.org
Objet : Re: Résolution des rapports pology check rules
Date : 31/08/2026 17:45:34 Europe/Paris
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/20260901/acf75f20/attachment-0001.htm>
-------------- section suivante --------------
Une pièce jointe autre que texte a été nettoyée...
Nom: part1.hDnuelyl.vxnco4XL at neuf.fr
Type: image/png
Taille: 290121 octets
Desc: non disponible
URL: <http://mail.kde.org/pipermail/kde-francophone/attachments/20260901/acf75f20/attachment-0001.png>
Plus d'informations sur la liste de diffusion kde-francophone