Il est où le rapport avec les titres et les ancres ? Je ne comprends pas.
OK, je vois, c’est un problème si l’ancre n’est pas fixe une fois l’ancre crée. Mais ceci dit, l’architecture même d’un document n’est pas pérenne. Si je modifie profondément le document, pleins d’ancres vont être pétées.
L’architecture des aides sur les cotations ne changent pas tous les ans.
Si on ajoute des sous-titres avant et après un sous-titres, ou même si on change le niveau d’un sous titre, il y aura toujours un sous titre « P2+ » ou « Cotation P2+ » (le titre peut changer), mais avec toujours la même ancre perso « P2-plus ».
Dans l’aide contextuelle d’une cotation, qui est un texte traduit sur transifex, il y a un lien vers l’aide complète de la cotation. Ce lien est du genre : Camptocamp.org (qui ne fonctionne pas, car l’ancre perso est cassée).
Actuellement l’aide contextuelle ne comporte pas ce lien, mais il faudra l’ajouter. Sur la V5 il y avait ce genre de liens dans l’aide contextuelle de chaque cotation, et de tous les champs dont il existait une aide plus complète sous forme d’article.
D’ailleurs il n’est pas pertinent de mettre ce lien dans transifex, c’est mieux qu’il soit en dur dans le code (avec une gestion par constante comme pour tous les liens en dur de l’interface). Il faudrait donc modifier le code sur github via le robot, super…
On pourrait éviter ça avec un système d’aide plus performant. Mais pour l’instant c’est comme ça que c’est fait.
Ouais, ben là, je suis resté sur le quai et j’ai raté le train, j’ai rien compris.
En fait c’est quoi la différence de complexité du parser entre
<span id="fixed-link-to-zouzou"/>et
{#titre}
?
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.
Si le problème est le # qui fout le bronx, on peut changer : {:titre}, ou {{titre}}, ou n’importe quoi qui est plus rapide à écrire que <span>titre<span/>
Le coup du span est une possibilité, mais ce serait plus cohérent avec la philosophie markdown si on évitait de mettre des tags, surtout que d’un autre côté un robot élimine du bbcode qu’on trouve tout moche et peu ergonomique, à cause qu’il est basé sur des tags…
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.
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 ?
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).
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.
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 :
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 !
Encore mieux qu’avant!
Nice!
Sans mise en forme particulière, donc ?
Sinon, cette proposition me va bien à première vue.