Migration BBcode

color et souligné d’accord ce sont en effet des balises inutiles pour la mise en page.
center, actuellement pour ce que je connais et que je constate de son utilité dans la mise en page, pour les photos essentiellement, je pense que l’on peut s’en passer aussi sans trop de dégâts visuels.

Note, le center, c’est juste celui pour le texte. Je ne touche pas à celui pour les images. Merci pour ton retour :slight_smile:

Edit, je ne sais pas si je suis clair. Aukazou :

  1. Je ne touche pas à ça : [img/123456 center]
  2. Mais je touche à celui la : [center] bla bla bla [/center],
  3. Et aussi celui la : [center][img/123456] [img/4568] [img/78923] [/center]

=> je pense que c’est surtout le cas trois le plus chiant. A la reflexion, ca me gène tout de même de le virer sans proposer d’alternative. Je vais peut etre voter contre ma proposition :slight_smile:

Je pense qu’il ne faut pas toucher au cas 3. avant d’avoir une solution de mise en page equivalente (plusieurs photos sur une meme ligne).

Ok pour virer 2.

Pour le 2 et le 3 je n’ai pas encore réussi à trouver un exemple d’utilisation de cette balise. Donc je me dis simplement que si elle n’a pas été vraiment utilisée jusqu’à ce jour, doit elle être une cause de retard afin de la maintenir ?
Maintenant je me trompe peut être je n’ai peut être pas, tout simplement, découvert les bons documents me démontrant son utilisation.

Ce ne me gêne pas de supprimer le center, il n’est pas très courant.
De plus, sur mobile le centrage ne change rien par rapport à un calage à gauche car le texte ou l’image prend toute la largeur de l’écran la plupart du temps.
Mais quand on réfléchira à l’amélioration des possibilité de mise en forme, ce sera peut être utile de le remettre.
Mais on ne s’amusera pas à remettre les balises dans les articles qui l’utilisaient, ces articles doivent être refondu de toute façon, s’il ne sont pas caduques.

1 Like

Bon, ce que je vous propose :

  1. Je supprime color et u sur lesquels on semble d’accord.
  2. Ca nous laisse un peu plus de temps de reflexion pour center.
  • Mais en l’état, on partirai plutot pour sa suppression. Puis une fois que tout est re d’équerre, on réfléchit à nos nouveaux besoins.
  • Oui
  • Non

0 votant

Allez, une autre que je propose de virer :

###c titre

Le petit c mettait le titre en orange. Ca concerne 444 documents (dont 244 articles, et 114 images). Même raison que pour [color], ce genre de truc doit être géré au global pour avoir un rendu cohérent.

  • Supprimer
  • Conserver

0 votant

Bonjour !

Tout va bien ?

La nouvelle mouture du parser est en test. En parallèle, j’ai besoin de vos avis sur deux balises actuellement cassées. Le point de vue que j’exprime est assez technique, n’hésitez pas à ne pas etre d’accord.

Emphase de titre

## Approche # 30mn

Rend comme ca :

Approche 30mn

Avis de dev :
Assez facile à coder. L’alternative serait d’utiliser la balise suivante : <small>30 mn</small>, ce qui est déjà codé (mais pas en prod) mais c’est clairement plus chiant.

  • Recoder une extension
  • Supprimer

0 votant

Ancre de titre

Celle la est utilisée très rarement, principalement dans les articles. Elle permet de creer des liens vers des titres :

 ### Titre qui change {#titre}

Avec ce code, je peux faire une url https://www.camptocamp.org/article/1234#titre qui ira directement sur ce titre.

Avis de dev :
Le markdown intègre deja un mécanisme similaire, en mettant le texte en identifiant (titre-qui-change dans mon exemple). Le souci est que si vous changez le titre, les liens sont cassés.
Mais en meme temps, et c’est utilisé hyper rarement, je trouve qu’on a mieux à faire.

  • Recoder une extension
  • Supprimer

0 votant

Je n’ai pas tout compris. L’emphase de titre ne fonctionne pas actuellement. O/N ?
L’emphase avec juste un # est pratique. Mais, on peut également faire avec le small. Est ce que le small fonctionne ?

L’emphase ne fonctionne pas actuellement, et le small non plus.

Si rien ne fonctionne actuellement, il est préférable d’avoir le # que le small.

1 Like

C’est une évidence, je dois juste préciser : small prend 1s à coder, l’extension un peu plus :slight_smile:

Encore une fois, je n’aime pas cette méthode de passage en force :
Tu mets des propositions de devs en vote, laissant croire que tu connais qqch concernant ces fonctionnalités, entre autres l’historique (pourquoi ont-elles été mises en place dans la V5 ?), alors que tu ne sais rien du tout ! Et pourtant c’est décrit dans l’aide de la V5.
Donc des utilisateurs vont voter sans savoir, en te faisant confiance sur ton avis (qui est de supprimer ces fonctionnalités bien sûr).
Et quand qqun qui sait donne des arguments, ceux qui ont déjà voté ne vont pas s’amuser à lire tous les nouveaux posts pour savoir s’ils doivent changer d’avis !
J’appelle ça du passage en force, et heureusement que le résultat de ce vote n’oblige pas les devs à mettre en place ce qui serait décidé.

Heureusement, j’ai vu ton post à temps, je vais pouvoir donner des arguments contre la suppression de ces fonctionnalités :

Ca ne sert pas seulement à changer la mise en forme.
L’idée est d’utiliser la place à droite du titre pour donner des infos assez courtes mais importantes, et que souvent on ne sait pas où mettre pour être assez visible (pas noyé dans le texte), sans ajouter 1 ligne juste pour ça.
Typiquement : le déniv et les cotations d’une variantes, les horaires, etc.
Mais ce texte ne doit pas être repris dans le sommaire (quand il y en a un), ni dans le slug de l’ancre.

Par défaut, il devrait y avoir une ancre automatique construite d’après le titre.
Pouvoir choisir son ancre est utile lorsqu’il y a plusieurs fois le même titre dans un document.
Exemple (je décris la hiérarchie des sous-titres par des puces pour éviter de prendre trop de place) :

  • Alpes
  • Alpi
  • Ski
  • Pyrénées
  • Alpi
  • Ski

On a 2 fois les sous-titres Alpi et Ski. L’ancre automatique est la même.
Si on veut donner un lien direct vers le sous-titre Ski dans les Pyrénées, ça ne fonctionnera pas, car ça ira vers Ski dans les Alpes.

Par ailleurs, quand un article est en plusieurs langues (cas des articles d’aides sur les cotations et sur c2c, article des licences, etc), on met une ancre perso identique pour toutes les langues.
Par exemple un lien sans indication de langue est redirigé vers la langue de l’utilisateur, en conservant l’ancre, et donc vers le bon sous-titre car on a mis une ancre identique pour le même sous titre dans chacune des langues.
Ex: Camptocamp.org
Ca ne fonctionne pas actuellement (l’ancre dans l’article est fausse, donc ça ne pointe pas vers le sous-titre, mais l’ancre est quand même conservé après la redirection), mais ça fonctionnait sur la V5.

Il existe déjà une extension markdown qui permet d’ajouter une ancre perso.

1 Like

Tant mieux, c’est déjà ça de gagner.
Mais ça ne fonctionne pas pour la redirection d’un article en plusieurs langues.

Je trouve que tu abuses. Il essaye de faire avancer le sujet, et il fait des propositions concrètes. Je ne vois pas où est le mal, et il ne force rien. Évidemment qu’il a son point de vue. Quand je fais des développements en général je fais aussi des trucs selon ma manière de voir les choses. Ici, contrairement à certaines autres personnes qui se reconnaîtrons, il demande l’avis avant de faire quoi que ce soit !

4 Likes

@Bubu
Il faut avancer. ça fait un an qu’on a le topoguide dans un état pitoyable. Ça me gêne rien que pour regarder les pages.

1 Like

Mettre le vote juste après SON avis, avec les autres avis qui sont dans les 50 posts suivants, et qui ne seront pas forcément lus, désolé, j’appelle ça du passage en force.
Une méthode équitable est de demander des avis sur chacune des propositions, de faire une synthèse des avantages et inconvénients de chaque proposition, et ensuite faire un vote.

  • Pour le texte après le sous-titre, je l’ai mis en place après que plusieurs personnes l’ai demandé. Comme ça n’entrait pas en conflit avec d’autres balises, il n’y avait pas de raison de ne pas accepter.
  • Pour l’ancre perso, je l’ai aussi mise en place après que certains aient relevé les défauts de l’ancre automatique. Idem, ça n’entrait pas en conflit avec d’autres balises. Ca interdit juste d’avoir un titre comportant {#ancre} dans le titre, mais on utilise rarement un titre de ce genre.

Tu as fait ça à l’époque en mettant en place tout ça ? Non.

En fait, désolé, je ne parlais absolument pas de toi :confounded:

Sauf qie ce que j’ai fait, sur demandes d’utilisateurs, n’a supprimé ni dégradé aucune fonctionnalité existante !
C’est toute la différence avec sa proposition, qui est de supprimer des fonctionnalités.