Dans les 2 cas, il faut détecter un motif, pour l’éliminer de l’affichage, et utiliser une partie pour créer l’ancre.
En gros, je proposerai une solution en argumentant sur sa simplicité technique, alors que je saurais qu’elle va m’être compliquée à coder, c’est bien ça que tu prétends?
Tu as bien sur eu la rigueur d’aller vérifier le code avant de poser ton accusation de mensonge?
Je sais pas quoi rajouter. Tu veux le détail de la modif à faire? je peux te les donner : il faut rajouter "id" à cette ligne.
Mais Bubu sait coder et à fortiori lire le code. Il a les moyens de vérifier lui-même les affirmations qu’il pose. Et à défaut, un peu d’éducation lui dicterait d’être un minimum prudent quand il remet en question les dires de ceux qui prennent les soucis à bras le corps. Mais il ne le fait pas, et ça lui arrive trop souvent de poser des avis péremptoires sur la base d’affirmations fausses.
C’est usant.
Le sujet me semble de plus en plus technique. AMA, vous devriez restreindre le vote aux personnes pouvant comprendre les tenants et aboutissements.
Pour ma part, je m’arrête à : il faut que les changements de texte d’un titre puissent conserver les liens en interne.
bot et parseur sont très certainement des personnes très agréables mais ils parlent un langage que je ne comprends pas. 
Je ne choisis donc pas la méthode permettant d’aboutir à la fonction. Mais, nous avons besoin de la fonction en interne, voir dans l’aide.
C’est pas si pire si on perd la fonction depuis l’extérieur.
Je sais, c’est pénible quand on a pas de background technique de se pencher sur ces questions. Mais crois-moi, il n’y a rien de pire que des devs trop en roue libre. Ca mène le plus souvent à de l’overengineering qui vous pète à la figure un jour ou l’autre. Cf l’état actuel du topoguide…
Un peu de rationnel, post en mode wiki, completez si besoin.
Le code suivant permettait d’afficher des pictogramme :
[picto pictoname /]
Vous en avez la liste ici.
Plusieurs possibilités s’offrent à nous :
Je vais essayez d’en présenter les avantages comparatifs :
| # | Extension | Syntaxe | Pro | Con |
|---|---|---|---|---|
| 1 | Rien | n.a. | Simple | Pas de picto |
| 2 | markdown-icons | &icon-name; |
Options de taille, de couleur et d'animation | Icones monochromes |
| 3 | emoji | :icon-name: |
Même syntaxe que le forum | Pas d'options |
| 4 | Extension C2C V5 | [picto pictoname /] |
Pas de migration à faire sur la DB | Syntaxe pas sexy, code à faire |
| 5 | Extension C2C | ??? | à déterminer | code à faire |
Des avis?
Ce serait bien de rester cohérent et donc d’utiliser la syntaxe markdown.
Est-il facile de faire un bot qui remplacerait la syntaxe actuelle par la syntaxe markdown ?
En fait, il n’y a pas de syntaxe markdown officielle[1] pour les picto, J’ai le sentiment que celle d’emoji (:icon-name:) est celle qui s’impose, mais c’est parce que je passe pas mal (trop) de temps sur Discourse et Github qui ont choisi cette option.
Sinon, oui, le bot fera la migration si besoin il y a, pas de souci de ce coté.
[1] Markdown « officiel » : Daring Fireball: Markdown Syntax Documentation
Ce serait top de réparer ça, pour les articles.
De toute façon, l’utilisation est plutôt pour des contributeurs experts, donc pas besoin de chercher la syntaxe la plus intuitive. Je crois.
Assez d’accord avec @Miko, le plus simple me semble de rester dans la logique de syntaxe markdown. Après, c’est pas moi le spécialiste !
La fonction principale est de pouvoir intégrer les pictos c2c, en particulier les pictos d’activité.
C’est l’utilisation la plus utile des pictos dans les articles.
Si j’ai bien compris l’extension markdown permet d’ajouter ses propres pictos (prédéfinis dans le CSS, on ne peut pas les ajouter from scratch dans un article, il faut qu’ils soient déjà utilisés ailleurs sur le site ou au moins définis dans le CSS).
C’est bien mieux !
Ca évite de se trainer N version du pictos pour chaque taille utilisé.
Et surtout, ça évite les défaut de mise en page avec un picto qui impose une ligne de 25px de haut dans un paragraphe à 20px de haut par exemple. Car un picto en font s’ajuste à la taille du texte, vu que c’est simplement un caractère mais défini par l’utilisateur (j’explique pour ceux qui se demandent ce que c’est).
emoji propose de le faire en SVG
Ah bon, ben il n’y a pas de défaut de présentation via emoji, on peut aussi avoir des pictos qui suivent la taille du texte avec un bon rendu (pas de pixelisation quand le texte est gros).
Du coup je n’ai pas d’avis pour trancher entre les 2 : emoji autorise la couleur, mais d’un autre côté tous les picto de l’interface sont en font, que ce soit sur le topoguide ou le forum.
Le vrai avantage que je vois pour les fonts, c’est les options (couleurs, tailles, animation) possibles pour le contributeur. Ca me semble à peu près comparable à l’avantage d’emoji pour les icones avec plusieurs de couleurs.
Du coup, 1 partout.
Mon avis perso penche finalement pour emoji avec cet argument : meme syntaxe que le forum. Mais c’est pas un avis fort.
Emoji
Tu verras un jour tu va nous coder l’activité spéléo 
A part ça emoji aussi pour la dernière question posée.
je vous laisse choisir.
Perso j’aimerais bien les 2 :
Ah, la, je pose un veto (si je peux en avoir 
) : pas de double solution pour un unique problème. Promis j’essaye de faire les choses carrés pour que ca soit simple en cas de modification des icones.
Bon, sauf contre-ordre, je part sur emoji. Merci pour vos avis.
Petite preview :
Et voici le retour des picto! En voici un :rock_climbing: et un autre :skitouring:
Ca donnera ça :
Et voici le retour des picto! En voici un
et un autre
@bubu : c’est en vectoriel, et ca pointera directement vers les svg deja en prod de camptocamp.
trop bien !