Migration BBcode

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 :slight_smile: 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 :frowning:

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…

Je re-propose un vote sur cette seule balise, car à 12 votants et un score proche de 50/50, c’est pas top. J’ai pas l’impression d’avoir bien manipulé tout le monde :wink:

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.
On peut autoriser les éléments span, ce qui permet tout de meme de simuler ce comportement, sans rajouter de complexité coté parseur, et prend une seconde à coder.

  • Autoriser l’utilisation de la « bidouille »
  • Supprimer
  • Recoder une extension

0 votant

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…

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. :slight_smile: 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.

2 Likes
  • Tu es prêt à utiliser une syntaxe absconse, et garder un parseur simple? Vote 1
  • Tu veux conserver une syntaxe simple, quitte à attendre un peu (voir beaucoup) et avoir un parseur un peu plus complexe? vote 3

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…

Ben voila, 82% pour une solution, c’est plus clair. Merci pour vos avis.

Pour info, l’emphase de titre est codée. Je glisserai la petite bidouille dans la grosse release du parseur. Le bot fera la migration quand elle sera en prod.

Je commence à voir la lumière au bout du tunnel :slight_smile:

2 Likes

Les pictogrammes!

Un peu de rationnel, post en mode wiki, completez si besoin.

V5

Le code suivant permettait d’afficher des pictogramme :

[picto pictoname /]

Vous en avez la liste ici.

V6

Plusieurs possibilités s’offrent à nous :

  1. ne rien recoder
  2. utiliser l’extension markdown-icons
  3. utiliser l’extension emoji
  4. Recoder notre propre extension avec la même syntaxe que la V5
  5. Recoder notre propre extension avec une autre syntaxe
  6. Autre extension que j’aurais raté ?

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?