Ce qui est soutenu par un certain nombre de personnes… On a besoin de rationaliser tout ça.
Migration BBcode
Pour l’emphase de titre, c’est clair et je préfère garder le # surtout si c’est « Assez facile à coder ».
Pour l’ancre de titre, j’ai pas compris par quoi ce serait remplacé si on la supprime.
Ah, et au passage, les archéologues, vous savez comment on doit afficher ça
### Je fais vraiment des # titres # pourris
Comme ca?
Je fais vraiment des titres # pourris
Ou bien comme ca?
Je fais vraiment des # titres pourris
Pas compris.
On peut pas le faire en html ceci ?
Zouzou
<a id=#"zouzou>renvoi vers zouzou
C’est important pour les longs articles : sommaires et se déplacer dedans. Enfin, je veux dire, avoir des ancres fixes par rapport à l’intitulé du titre. La fonctionnalité doit exister.
Ou j’ai pas compris.
Dans ton exemple, l’ancre existe, et l’URL serait un truc comme :
https://forum.camptocamp.org/t/migration-bbcode/199173/57#zouzou
Quoiqu’il arrive, ca va vers la bonne page. Mais en plus, ca scrolle au bon endroit. Avec le système actuel, si jamais tu change ton titres en zaza, les autres pages qui auront un lien vers ton article ne sscrolleront plus directement sur ton titre, car la nouvelle adresse sera :
https://forum.camptocamp.org/t/migration-bbcode/199173/57#zaza
La balise permettait de fixer l’identifiant :
### Zouzou {#fixed-link-to-zouzou}
Et d’utiliser :
https://forum.camptocamp.org/t/migration-bbcode/199173/57#fixed-link-to-zouzou
Comme ça, si un jour, tu veux mettre zaza, tu mettais :
### Zaza {#fixed-link-to-zouzou}
C’est vraiment utile quand tu fais un usage massif de ces liens vers titres et que tes titres changent tous les quatre matins.
Donc, ceux qui veulent la fonction ont toujours l’html pour contourner, c’est ça ?
Perso, pour le peu que j’écris, je préfère que l’ancre soit indépendante du texte, mais bon. Je vote pas à cette question du coup.
Pour moi, c’est important dans la mesure où ca permet de traduire un article en gardant la même structure facilement.
C’est ça. L’ancre automatique correspond au titre en lui même (modulo un peu de « normification », et si besoin un petit numéro pour garantir l’unicité).
On peut mettre du html dans le forum mais pas dans le topoguide. Tu ne peux donc pas contourner les limitations par du html.
Il y a peu d’articles avec des ancres personnalisés, par contre il y a des centaines de liens vers ces artcles.
Par exemple dans l’aide contextuelle d’une cotation, on a un lien vers l’aide complète, qui est un lien vers un article sans mention de langue mais avec une ancre.
Idem pour les liens dans les warnings des itineraires de référence, qui renvoie vers l’aide de la cotation (ex : P2+). En réalité il y a des corrections à faire, tous ces liens ne sont pas comme ça, mais le but est de ne mettre que des liens de ce genre quand on pointe vers une aide.
Une ancre titre dépendant du texte est quasi inutilisable.
C’est déjà très pénible dans un rapport de quelques pages avec un index. Mais, c’est totalement inutilisable avec les centaines de milliers de documents de c2c. Si on change le texte d’un titre (y compris pour corriger une faute d’orthographe), il faut que tous les liens pointant vers ce titre, continuent de pointer vers ce titre, ou il faut une moulinette automatique pour corriger tous les liens pointant vers le titre.
3 Likes
Ca, c’est pas un souci 
Le bot est clairement une solution incontournable pour faire des modifs en masse et s’éviter des comportements de parseur compliqués à gérer, et durs à maintenir. A ce sujet, dans la pile de todo du bot, checker la validité de tous les liens internes du topoguide. Autant vous dire que ces petites balises de titre, c’est une chiure de mouche sur un gros paquet de m…
PS : j’avais mal compris la question de @Gros : on peut contourner en utilisant les ancres automatiques, qui sont sujettes au probleme de changement du titre.
Ca m’étonnerait tout de même que le contributeur lambda puisse arriver à lancer un bot pour corriger tous les liens cassés à cause d’une de ses corrections de titre.
Qu’elle est le fonctionnement de WP ?
Les bots fonctionnent en tache de fond, et font tout un ensemble de check et modifications automatique. C’est leur dresseur qui en ont la charge, le contributeur n’a rien à faire.
En l’état, ce qui englobera le souci de ces titres, ca devrait etre une tache quotidienne qui check que tous les liens internes de C2C sont valides. Dans le cas contraire, des petits comportements automatiques, qui vont du signalement au forum, à la correction automatique si il n’y a pas d’ambiguité.
Ca ne suffit pas.
Le bot ne modifiera pas les liens dans transifex, dans le forum, dans les sites externes où les modos postent parfois pour expliquer les cotations c2c ou les licences, etc.
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.
Tiens d’ailleurs, ils ont exactement le même besoin de liens vers des titres sur Wikipédia, et leur solution, c’est ancre = titre (fonctionnement pas défaut du markdown, ce que je propose ici).
Par contre, la puissance du langage leur permet de simuler ce comportement d’ancre fixe n’importe ou (pas que dans les titres) si besoin. Le fait est que c’est très rarement utilisé (3746 fois sur 9 millions de pages). On est malheureusement à des années lumières d’avoir un parseur qui permettrai cette souplesse 
A défaut, ca sera facile et sans complexité dans notre parseur d’autoriser une petite bidouille pas très intuitive pour les quelques articles ou ca se justifie.
Détail de la bidouille :
## Zouzou ou zaza? <span id="fixed-link-to-zouzou"/>
C’est exactement ce que fait wikipédia, mais leur parseur permet d’enrober ça dans une syntaxe plus lisible :
## Zouzou ou zaza? {{Ancre|fixed-link-to-zouzou}}
La ou il ont 15 trains d’avance, c’est que leur balise Ancre n’est pas défini coté parseur, mais coté wiki : elle ne demande pas de développement spécifique. Leur langage leur permet de définir des balises de ce type avec un niveau très avancé de fonctionnalité.
Ouais, ben là, je suis resté sur le quai et j’ai raté le train, j’ai rien compris.
Dur d'être clair en quelques mots, je vais essayer :
Ils ont un mécanisme d’inclusion de modèles dans d’autre pages. Un modèle est lui même une page wiki.
Par exemple, si nous voudrions avoir un bandeau qui permet de prévenir l’interdiction de grimpe des itinéraires entre deux dates à cause de la nidification, et que nous étions sur WP, nous ferions :
Une page nommée Modèle:Interdiction pour cause de nidification qui contiendrait ce pseudo-code :
IF {{{start_date}}} < {{{today}}} < {{{end_date}}}
[warning]Pour cause de nidification, la grimpe est actuellement interdite...[warning]
ELSE
[important]Notez que la grimpe est interdite pour cause de nification entre le {{{start_date}}} et le {{{end_date}}} [important]
Et dans les pages itinéraire, nous mettrions
{{Interdiction pour cause de nidification | start_date = 01/01 | end_date = 31/06 }}
Le rendu serait dynamique en fonction de la date du jour.
La ou ca commence à vraiment etre puissant, c’est que des modèle peuvent inclure d’autre modèles, etc. C’est une fonctionnalité clé de Wikipédia, et ca permet de factoriser énormément de boulot.
Mais revez pas trop, ca va être trèèès compliqué à faire chez nous, pour autant qu’on veuille le faire…
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…