A la sortie de la nouvelle version du site et suite au bug sur la numérotation des longueurs qui ne remonte pas dans la V6 (…) il nous avait été demandé de ne pas rectifier manuellement les fiches car cela allait être fait automatiquement. Plusieurs mois plus tard toujours rien…
Que fait on ? On passe en mode manuel et on corrige au fur et à mesure ou on continue à attendre un potentiel script salvateur ?
Numérotation des longueurs: on fait quoi ?
Bonne question…
Les cas simples fonctionnent, mais dès qu’il y a des L±, et des trucs particuliers ça ne marche pas.
Mais la commission topoguide et les dévs planchent sur le sujet, qui n’est pas simple!
Donc patience, on vous fera signe quand une solution ou une décision aura été prise.
Je n’ai pas cette interprétation : le sujet est assez simple, et relève surtout du choix stratégique (le support, ou non, des syntaxes alambiquées), mais personne de motivé pour se pencher sur la question.
- Parsing of L# tags · Issue #713 · c2corg/v6_ui · GitHub
- Code interpration, bbcode, markdown · Issue #1660 · c2corg/v6_ui · GitHub
J’avais proposé un plan d’action de simplification basé sur une analyses des syntaxes utilisés, et une migration par un robot, (lien ), mais la discussion était restée sur l’acceptation ou non du principe de robot contributeur.
Il y a peut-être un souci de gouvernance, car ce genre de sujet devrait être discuté avec l’ensemble des contributeurs, et non entre devs.
Pour ma part, j’avoue avoir eu à ce moment d’autre préoccupations.
On en est effectivement là. En gros, certains devs considèrent qu’on a mis en place trop de cas particuliers dans la version précédente et qu’il est préférable de ne plus les supporter. Il faut qu’on prenne la décision sur les balises supportées et celles qui ne le sont pas pour démarrer le nettoyage manuel. On a besoin d’un/une bénévole pour prendre en charge ce sujet.
Actuellement, les devs en cours concernent les modifications de l’API pour ajouter les informations suivantes dans les sorties: nb de photos, présence d’une trace GPS, cotation. Il y a aussi l’ajout de la langue dans les préférences du fil d’activité (eg. pour que les italiens puissent voir uniquement les documents en italien s’ils le souhaitent). Enfin, il y a aussi une tâche concernant l’infrastructure du site pour améliorer sa sécurité.
c’est bien les nerds ça… ça discute pendant des heures sur comment avoir le site le mieux développé, et ça oublie les but du truc. Résultat, ca va faire un an que la partie « topoguide escalade/glace/mixte » du site est HS. 
1 Like
Du coup après cette intervention ironique majeure et constructive, le problème va être résolu rapidement. Vivagel qui n’en manque pas une avec ses encouragements va pouvoir aussi aider positivement la communauté pour résoudre le problème.
2 Likes
Merci pour la leçon de morale. Que j’accepte. Je suis d’accord avec toi. C’était une réponse facile.
Pour te répondre : en effet la discussion sur L# n’a pas été très productive, et le manque de dev n’explique pas tout : il n’existe pas de cadre clair aujourd’hui au sein de l’assoce pour prendre ces décisions. Les discussions sont dispatchées entre github, le forum interne, et des « comités » qui discutent dans leur coin. Il en résulte une certaine aboulie… Mais le constat sur le manque de personnes souhaitant s’impliquer, qu’elles soient dev ou non reste le même.
Sur le portail escalade de glace, au contraire, ça résulte d’une décision de ne plus faire ces portails, mais de mettre une API à disposition des autre sites voulant porter ces projets pour qu’il ait un accès facile aux données camptocamp. Si techniquement c’est très réussi (pour preuve, campdebase.org, et ce test de portail qui ont été assez simple à faire), fonctionnellement, rien de probant n’a vraiment emergé.
Néanmoins, les deux problématique sont assez disjointes.
Tu comprends donc pourquoi après le lancement de la V5, on a rapidement réservé le forum « développement » aux membres de l’assoce : les posts constructifs étaient noyés dans le flood.
Et les modos forums n’avaient pas envie de passer du temps à modérer un forum dédié à une partie de la gestion du site, car à la base les modos forums sont là pour modérer les forums dédiés aux thèmes du site, et non pas les forums annexes (ils le font quand même, mais il faut que le boulot en plus soit négligeable).
Aujourd’hui les forums sont beaucoup moins actifs, donc ça flood moins et on peut avoir des discussions publiques lisibles concernant le dev.
Ben si.
D’un côté, ces centaines de contributeurs ont passé des milliers d’heures à insérer à la main des balises L#, éventuellement avec des syntaxes complexes mais qui répondaient à une demande de mise en forme pour des cas particuliers (par exemple l’alignement des colonnes entre 2 groupes de longueurs séparée par un paragraphe en pleine largeur). Tout ce travail n’était pas automatisable.
Et de l’autre, des devs voudraient tout enlever, ou revenir à une syntaxe simpliste, éventuellement avec des robots, sous prétexte de gagner du temps de dev.
On a qq milliers d’heures d’un côté, face à qq heures de l’autre, pour moi il n’y a pas photo.
En sachant qu’il faut penser aux évolutions futures possibles, il ne faut pas faire qqch qui correspond juste à un besoin aujourd’hui sans penser aux évolutions, sinon qq années plus tard on est coincé.
Les balises L#-+2 (qui donnent par exemple L1-3) sont très très pratiques
et courantes.
c’était juste un clin d’oeil hein ? Pas une engueulade… Moi aussi j’ai des fois passé plus de temps a coder une moulinette pour traiter des données que ca m’aurait pris pour les traiter manuellement. :-).
J’ai participé assez largement à la conversion des topos avec les balises L#. Je pense en avoir utilisé toutes les possibilités (pas toutes les variétés syntaxiques) et j’ai trouvé que c’était un outil très complet qui permettait de résoudre tous les problèmes de mise en page auxquels j’ai été confronté. Sont indispensables des outils pour coder les variantes et coder les liaisons (L#’ et reprise, L#_ ), très utile la balise qui permet d’insérer un texte intermédiaire sans casser la mise en page (la fameuse L#~), très utile mais moins fréquent, le groupement de longueur. De pouvoir mettre le numéro de la longueur ou de relai automatiquement dans les commentaire est un gage de pérennité en cas de modification.
J’ai déjà constaté plusieurs casses du travail accompli.
Ce serait dommage que cela disparaisse.
1 Like
Merci papidelyon tu as surement fait du bon boulot mais l’adversité est trop forte ! Franchement faudrait que vous redescendiez sur terre les nerds ! Si depuis la V6 chacun avait modifié les balises à chaque fois qu’il consultait un topo ce serait un pb réglé depuis belle lurette !
Ca me rappelle ma suggestion de pouvoir mettre le point GPS du départ de chaque grande voie dans les fiches: direct un caca nerveux de certains. Misère, misère chantait Coluche…
Oui, moi j’y participe, à la casse. Les quelques iti que j’ai repris suite à des actions de modération ont été repris sur la base de l’utilisation de la balise L# seule. Pour contourner l’absence du reste, je louvoie : plus de Rmachin, mais je m’arrange pour que le texte soit logique avec « Du relai précédent… blablabla ».
Et je vire le : ##Itineraire # 2 heures qui ne marche plus non plus. Je mets :
##Itineraire
Comptez 2 heures
Parce que sur la même ligne, ça marche dans la prévisualisation, mais pas dans la vraie page.
T’es sûr de ça ? C’est le même outil qui est utilisé dans les 2 cas, il ne devrait pas y avoir de différence.
Toujours aimable, comme d’hab. Pour le soi-disant caca nerveux, ce serait là : Ajout de point GPS dans itineraire Je cherche encore.
Perso, je supprime complètement et systématiquement toutes les mentions « depuis le relais », « aller à gauche du relai » (qui devient « partir à gauche »), « monter au-dessus du relai » (monter droit).
Car dès R1 et pour tous les relais suivants, la longueur suivante commence forcément au relai précédent, pas besoin de le préciser !
Idem avec les mentions de ce genre :
Remonter la dalle jusqu’à une vire, et la suivre vers la droite. Continuer sur la vire jusqu’à atteindre le relai. Relai sur 2 goujons.
devient :
Remonter la dalle jusqu’à une vire, et la suivre vers la droite. R3 (2g).
Car là aussi, c’est implicite qu’il faut suivre la vire jusqu’au relai, vu que le relai est équipé.
Et ce genre de mention, j’en ai supprimé qq milliers, et depuis bientôt 10 ans ! La V6 n’a rien à voir la dedans.
Ce qui est un peu embêtant, mais je ne fais pas de remarques aux personnes concernées pour ne pas les vexer, c’est que quand un itinéraire est quasi vide (juste les cotations de chaque longueur par exemple, ou juste un schéma dessiné vite fait à la main et pris en photo), et que qqun prend le temps de décrire correctement les longueurs, il y en a qui se prennent au jeu de l’écriture, et ne peuvent pas s’empêcher de faire de la littérature, et de pondre 20 lignes pour 8 longueurs.
Et quand je passe derrière, je supprime la moitié du texte, sans supprimer une seule info (et parfois en en ajoutant). C’est dommage, parce que parfois on sent qu’ils ont passé du temps à peaufiner des expressions de 10 mots (qui se résument en 2 mots), en évitant des répétitions, etc. Alors qu’il suffisait d’utiliser le style topo et ça aurait été plus rapide.
Inutile : Lionel compte réparer cette syntaxe.
Perso, je supprime juste les # en trop pour alléger le titre en attendant que la syntaxe soit décodée :
Approche #### 2h depuis le refuge
=>
Approche # 2h depuis le refuge
En gros, vous pouvez casser!
@Yoknapatawpha pour info je suis de la génération d’avant les nerds (on appelle ça un dinosaure).
J’ai appris qu’il fallait mieux utiliser des balises même si leur syntaxe peut sembler compliquée plutôt que de se palucher la mise en page à la main. Et tout le monde y gagne.
Merci de m’avoir rajeuni!
Je deterre ce sujet. Je sais ce n’est pas d’actualité, mais en faisant de la relecture, j’ai noté la remarque :
En fait, les R# ça marche (et il n’y a pas besoin du |)