Vote : utilisation des abréviations dans le topoguide

Bien que peu probable, il faut peut-être ajouter « s » à ta liste.

Sinon, d’accord avec @Bubu : transformer mn en min
Petit risque : n est à côté de la virgule sur le clavier, donc un « mn » pourrait être une coquille pour « m, ».

Autre remarque : pour les heures, il faut traiter le cas 5h30 => 5 h 30, donc h suivi de chiffre(s) (éventuellement restreindre au cas 2 chiffres ?) transformé en h suivi d’espace insécable suivi des chiffres.

  • Pour tout ce qui est transformation de mot (mn vers min, metres vers mètres ou m, mais aussi bcp d’autres), je ferais un projet un peu plus tard, il y a des dizaines de fautes de frappes et erreurs courantes à gérer, et ça pose quelques questions, et demande des précautions à prendre (cf la remarque pertinente de Lutin).
  • Je rajoute s,
  • Le cas de 5h30, il est un peu pénible : je peux le corriger facilement, mais le parseur actuel ne rajout pas d’espace insécable entre le h et le 30. A voir si il est plus pertinent de faire évoluer le parser, ou de mettre cet espace insécalbe directment dans le markdown.

Une question stupide, Charles : ton robot doit être au point, bien sûr, mais il ne va pas transformer
« amnésie » en « aminésie » ?

Non bien sur, ou alors j’aurais fait un grosse betise.

Pour ces corrections orthographiques, le temps venu, je décrirais précisément le comportement (comme je l’ai fait ci dessus) avant de lancer le tout.

C’est quoi le process de test de ces modifs en masse (irréversibles) ? A minima, je pense qu’il faut les faire tourner sur la démo avec une copie de la base de prod, et on fait un peu d’échantillonnage à la mano pour vérifier qu’il n’y a pas d’effets de bord.

Tu as pour exemple ici les tests pour le code de migration bbcode > markdown :

https://github.com/cbeauchesne/CampBot/blob/master/campbot/processors.py#L71-L243

Après, la magie du truc, c’est justement que c’est reversible : chaque modif donne une nouvelle version en base, et est donc annulable, et si besoin massivement.

Pour info, le process que j’utilise est le suivant :

  1. Ecriture des tests
  2. Ecriture du code
  3. execution avec validation systématique de chaque modification
  4. Retour à l’étape 1 en cas de souci
  5. Si non, au bout d’un certain moment (à mon appréciation, en fonction de la complexité de la modification), je passe le bot en mode auto. La, les modifs défilent sous mes yeux sans action de ma part, et j’ouvre à mon rythme des docs au hasard pour vérifier que tout est bon.

Premiers essais : Camptocamp.org

1 Like

Migration faite, 37,000 modifications :sunglasses:

2 Likes

Et en plus avec le second passage du robot hier, ça rend vraiment les textes plus aérés.