Migration BBcode

#74

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…

#75

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?

#77

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.

#78

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
#79
  • 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…

#81

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?

#82

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 ?

#83

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

#84

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 !

#85

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).

#87

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).

#88

emoji propose de le faire en SVG :slight_smile:

#89

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.

#90

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.

Rappel : Lien vers le sujet

#91

Emoji

#92

Tu verras un jour tu va nous coder l’activité spéléo :wink:

A part ça emoji aussi pour la dernière question posée.

#93

je vous laisse choisir.

#94

Perso j’aimerais bien les 2 :

  • Font : ça permet d’insérer facilement un picto font de l’interface, de façon identique. Très utile pour l’aide. Si le picto de l’interface change, il change automatiquement dans l’aide.
  • SVG : plusieurs couleurs possible, et ça permet peut être d’ajouter des pictos plus facilement (juste un fichier en plus sur github + modif css, au lieu de fichier en plus + recompiler une font + CSS). Mais en pratique je ne sais pas si la complexité est différente.
#95

Ah, la, je pose un veto (si je peux en avoir :smile:) : 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.

#96

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 :rock_climbing: et un autre ⛷

@bubu : c’est en vectoriel, et ca pointera directement vers les svg deja en prod de camptocamp.

6 Likes