Usage du robot sur le topoguide

Luberon ?

Je vais donc ajouter la correction

Devoluy >> Dévoluy

Je viendrais volontiers, mais j’ai déjà pris un engagement pour dimanche. Une autre fois donc. :wink:

Ben tout le monde l’écrit ainsi. C’est pas bon ?

Tout le monde met un accent malheureusement (au moins à l’oral)

Je ne trouve qu’un cas sur c2c : "Lubéron" -diff site:www.camptocamp.org/routes - Google-Suche

Plutôt positif alors :slight_smile:

2 Likes

propositions :

dulfer >> dülfer
Dulfer >> Dülfer

Ajouté.

Merci

17 messages ont été intégrés dans un sujet existant : Abréviations et linguistique

Un message a été intégré dans un sujet existant : Abréviations et linguistique

La partie de gauche doit commencer et finir par un caractère alphanumérique. Parenthèses, signes de ponctuation et caractères autres que chiffres/lettres ne donneront pas le résultat attendu

dommage, car celui-ci est fréquent :

De là (espace) >> De là,

En effet. C’est le prix à payer pour garder cette page simple et éditable par ceux qui ne parlent pas regex…

Cela dit, pour des remplacements plus subtils, on peux toujours le faire ponctuellement. Par exemple, je suis en train de faire une passe sur les X<sup>ème</sup> >> X<sup>e</sup> .

1 Like

Eh be dis donc, ça remue fort en fond de cale.

:+1:

Merci beaucoup !

500 iti concernés. Je ferais un truc custom qd j’aurais un peu de temps.

Fini. Ouf !

2 Likes

ok, merci !

Mais au fait, est-ce qu’il y a une raison technique à ce problème (exemple : si les titres doivent obligatoirement être précédés d’un saut de ligne), ou bien est-ce un bug (qu’il est plus simple de résoudre en ajoutant le saut de ligne) ?

Alors, c’est voulu. Les arguments qui m’ont poussé à faire comme cela (ou plutot ne pas réimplémenter cela, car ca aurait demandé du code) :

  1. Argument faible : ca rajoute de la complexité dans le parser. Pas un truc horrible, mais c’est quand meme de la complexité.
  2. Argument fort : le premier élément de logique du markdown, c’est la séparation des blocs par lignes vides. L’argument à cela est que le code « ressemble » au rendu, au moins autant que possible, et permet au débutant de ne pas trop galérer pour l’écrire. Du coup, conserver le comportement naturel du markdown (ligne vide derrière les balises L# obligatoire) m’a apparu pertinent.
    Et suffisament en tout cas pour ne pas rajouter de la complexité dans le parser. En fait, si il y a une correction à faire pour respecter l’esprit du markdown, ce serait de rendre un titre dans les cellules (cas d’usage rare, pour ne pas dire très rare, on est d’accord).

Shame on me, j’avais prévu de faire une passe de bot pour fixer les cas présent dans le topoguide. Et ca m’est sorti de la tete :blush:

Merci pour ce rappel.

Ca arrive quand on découpe une voie en section, comme ici : Camptocamp.org
On a mis des sous titres, ce qui coupe les longueurs en plusieurs tableaux de longueurs, avec donc des colonnes non alignées entre les blocs.
Si on pouvait mettre un sous titres dans un L#~, on conserverait l’alignement des colonnes entre les blocs.
Dans une version précédente du doc, il y avait des L#~ avec un faux sous-titre (texte en gras).

Le problème est que pour conserver la règle que la balise de sous-titre soit en début de ligne, ça signifie de faire qqch du genre :

L#~
### Sous titre
L# | ....

Une autre possibilité qui est plus simple côté utilisateur mais plus compliqué côté code (surtout si on veut que ces sous-titres puissent apparaitres dans un sommaire avec les autres sous-titres), serait d’ajouter une option à la balise L# :

L## Sous titre niveau 2
L### Sous titre niveau 3
L#### Sous titre niveau 4

En tout cas, ce problème mineur n’est pas du tout prioritaire.

Avec la façon dont est fait le parser markdwon, le plus simple à faire, et qui serait logique :

L#~ ### Ceci est un titre

Pour comparaison, ca marche pour les citations :

> ### Ceci est un titre

Qui rend :

Ceci est un titre

En conclusion de ce sondage, j’ai rétabli les corrections automatiques correspondantes.