Migration BBcode

#182

ok pour ne pas recoder cette balise.

#183

Compte tenu de nos difficultés importantes à remettre les balises, et donc un topoguide dans un état perfectible pendant plus d’un an, je suis partisan de la solution la plus pérenne.

La stratégie V5, consistant à développer des balises, au cas par cas, sans se poser la question globalement, notamment en terme de maintenance sur le long terme, était manifestement une erreur.

Les contributeurs voulant améliorer significativement la mise en page/forme de ces pages, apprendront, ou non, à utiliser la syntaxe HTML. La syntaxe HTML n’est probablement pas beaucoup plus compliqué à apprendre que les balises [col] Camptocamp.
Avant tout, il faut prendre en compte la pérennité du système. On ne peut/doit pas avoir le topoguide en vrac pendant plus d’un ans tous les 10 ans, parce qu’on s’est fait plaisir avec une balise spécifique.

#184

Je voudrais revenir sur les L#.
Qu’est ce qui cloche dans Camptocamp.org ?

Compte tenu de ce qui va être fait, est ce que le topo est censé redevenir lisible (et utilisable) ? Si je n’ai rien raté, il y a du L#~, du L#’ et du L#_
Avec le « recul », je suis vraiment d’avis de simplifier ces topos (ou du moins d’utiliser à minima les balises L exotiques).

#185

Il y a un L#' qui n’est pas encore supporté. D’ailleurs, @rabot a commencé à nettoyer : Camptocamp.org

#186

J’ai remplacé la longueur ’ par une longueur normale. Il n’y a qu’une longueur concernée (c’est différent de certaines voies où il y a une longueur de liaison après chaque longueur grimpante).
Comme le schéma ne numérote pas les relais pour cette voie, ça ne pose pas de problème.
Et en plus, ça fait que le n° des relais communs avec la Face E est le même (3 derniers relais).

J’en ai profité pour remettre aux normes la voie de Face E : y avait du boulot ! Il manque quand même une colonne avec le nb de pitons en place dans chaque longueur. Mais il n’y a pas assez d’infos précise (juste « peu » ou « nombreux »), et c’est peut être inutile si le nb de pitons change à chaque répétition.
Par contre pour les 2 voies, il est indiqué qu’il y a des spits : ce sont des goujons ou des chevilles autoforeuses ?

#188

Bon, et sinon, [col]? D’autres avis?

Pour info, il a une cinquantaine de doc qui la contienne.

#189

Faire au plus simple à réaliser.

#190

Je suis en train de corriger des balises dans mes sorties (italique, gras, soulignement et quelques liens) puisque cela ne s’est pas fait automatiquement !
y’ a pas moyen que ces sorties n’ apparaissent pas de nouveau en page d’accueil ? (il m’en reste 150 à vérifier)

#191

Inutile de t’embêter à corriger à la main !
C’est juste que certains champs n’ont pas été corrigés. Il faut que le robot les corrige.
Il s’agit au moins des champs texte « Conditions » et « Commentaire sur l’accès », mais il y en a peut être d’autres.

Pour l’affichage sur la home, il s’agit d’un bug. Apparemment, la première fois qu’on modifie le texte d’une sortie créée sur la V4 ou la V5, ça entraine un affichage sur la home.
Un exemple de modif : Camptocamp.org

#192

Ok, merci.
Je vais arrêter là. Vu la météo, ça occupait bien.

#193

Hello @stephfb,

En effet, je n’ai pas encore passé sur les docs persos (pour une raison technique). Je les ferais en tout dernier.

#194

Dans l’aide sur la mise en forme du texte, j’ai déplacé la section concernant les sous-titres en tête de l’article.
En effet, s’il y a 1 chose à savoir, c’est l’utilisation des sous-titres.
Il ne faut pas utiliser la mise en forme des caractères (gras, souligné, etc) pour faire un sous-titre, mais utiliser uniquement la balise de sous-titre. Normalement, on n’a rarement besoin de mettre en forme des caractères. Par contre on a toujours besoin des sous-titres, dès que le document contient un peu d’info, pour le structurer.
La balise de sous-titre permet de générer du html comportant des indications que c’est un sous-titre. Ces indications de structure du texte, outre la possibilité de changer le style des sous-titres via une modif de design, permettent d’améliorer le rendu dans certains cas, par exemple avec les navigateurs conçus pour les handicapés.

#195

@bubu, je t’ai répondu sur la discussion rattaché à la page d’aide en question.

Bon, sinon, sans avis supplémentaire, je ferais une passe pour supprimer les balises col présentes sur les documents.

#196

Ce serait bien de sauvegarder la liste des articles qui contienne des col.

J’ai essayé d’utiliser un <div>. Ca fonctionne, mais si le <div> contient du L#, ça ne décode pas le L# et ça met tout au km.

#197

Oui, le code contenu dans la plupart des balises HTML n’est pas interprété. Il faut vraiment éviter pour le moment de les utiliser, tant qu’on a des inconnus la dessus.

#198

Bon, j’ai une petite nouvelle :

Ce bug est hyper pénible à fixer, ca demande d’aller bidouiller loin dans le parser, sans garantie que ca soit vraiment stable et rigoureux. C’est du coup bien plus simple et stable de recoder une extension.

En pratique :

  • La balise <span id="ancre-fixe>` pourrait être autorisée ailleurs que dans un titre. Mais je recommande très vivement de l’interdire si nous n’en avons pas l’usage. Il y a des effets de bord pénibles à trop permettre l’utilisateur de choisir des id, cf le bug de la page qui ne s’affiche plus.

  • La syntaxes suivantes pour les titres seront valides :

    Titre simple

    Titre avec # emphase

    Titre avec un id fixe {#id-fixe}

    Titre avec # emphase et avec un id fixe {#id-fixe}

  • @rabot se chargera de retransformer dans l’autre sens les balises <span id="id-fixe"></span> vers {#id-fixe}

Ok pour tout le monde (extension, et interdiction du span) ?

Désolé pour l’aller-retour :confused:

#199

Ok pour moi.
On préfixe quand même l’ID ?

#200

(Pour les autres, c’est une discussion technico-technique qu’on a sur la ML de dev.)

Le sujet est annexe mais oui, il va falloir faire quelque chose pour ce problème, on ne peut pas se permettre de péter les pages avec un markdown qui semble totalement anodin. D’ailleurs, tu n’as pas donné ton avis sur la ML :wink:

#201

PI, pas d’opposition, bye bye balise [col]!

…

Elle n’est plus.

#202

amen!