Txt2tags vous connaissez ?
C’est le grand perdant du « lightweight markup war » (la guerre des langages de balisage légers) : bien que plutôt logique dans sa syntaxe, d’ailleurs proche de la syntaxe de Creole, ce dernier justifiant ses choix dans une étude fort détaillée, donc applicable dans une certaine mesure à txt2tags, extensible sans produire des dérivés incompatibles entre eux (on expliquera comment plus loin), créé avant toutes les autres syntaxes wiki légères, il arrive pourtant bon dernier en termes de part de marché, c’est‐à‐dire d’utilisation, face à MediaWiki, Markdown, ReStructuredText, etc.
Pourquoi ? Divers paramètres entrent sans doute en compte dans cet état de fait. Néanmoins, txt2tags ayant été programmé en Python, on peut imaginer que ce langage n’étant pas disponible sur la plupart des hébergements mutualisés, il n’était pas question de l’utiliser dans des projets nécessitant un wiki en ligne, d’où un délaissement du langage de la part des utilisateurs potentiels.
Ce créneau a donc été pris dans une large part par l’implémentation en PHP de Markdown, que l’on retrouve absolument partout, et du coup la syntaxe Markdown étant connue, elle a été démocratisée selon un cercle vicieux qui a fait que de nombreux services l’ont pris en compte par ailleurs, même en utilisant une autre implémentation (Ruby, etc.). Ainsi, Markdown, ou l’une de ses versions modifiées initiées pour pallier ses limitations de base, comme Markdown Extra ou GitHub Flavored Markdown, sont la syntaxe par défaut de Diaspora, LinuxFr.org, Tumblr, GitHub, etc.
Mais la lutte n’est pas finie !
txt2tags a maintenant une implémentation en PHP lui permettant dorénavant de revenir sur le devant de la scène, même si cette nouvelle version ne remet aucunement en cause la raison d’être de la version Python, plus complète dans ses exportations possibles. Cette implémentation a été réalisée par le développeur Petko Yotov, également contributeur principal au projet PmWiki.
Le code est suffisamment clair et compact pour être réutilisé dans d’autres projets similaires (il est aisé de l’adapter à une autre syntaxe), d’autant plus qu’il est publié sous licence GPL v3. Voyons donc ce que txt2tags-php propose de bon :
- exportation uniquement vers le format HTML ;
- la syntaxe demeure inchangée ;
- les préprocesseur et post‐processeur restent bien présents ;
- les expressions régulières sont également prises en charge.
Exportation vers le format HTML : pour diffuser sur le Web, le format du Web est le seul vraiment nécessaire et suffisant. Pas la peine de s’encombrer avec de l’exportation vers les plus de 40 formats existants dans txt2tags.
La syntaxe reste la même : un document écrit pour txt2tags en Python s’affichera de la même manière dans la version txt2tags-php, ce qui bien est la moindre des choses.
Reste à réfléchir à la grande question philosophique tournant autour de txt2tags : « est‐ce que ce qui fait son essence c’est juste sa syntaxe sympa, ou bien c’est sa manière de fonctionner en entier qui est nécessaire pour rendre justice à tout le concept ? ».
En effet, les préprocesseurs et post‐processeurs intégrés donnent toute leur puissance à ce logiciel. Comme mentionné plus haut, il est possible de remplacer n’importe quelle portion de texte et ainsi d’étendre la syntaxe de txt2tags avec quelques lignes de code, dans le corps même du document, si bien que ces extensions ponctuelles sont immédiatement lisibles et visibles pour tous les utilisateurs potentiels du document en question.
Ainsi on pourra écrire pour un remplacement standard de caractères :
%!preproc: 'MEILLEUR-EDITEUR-DE-TEXTE' 'Vim'
Mes chers amis, je voulais vous présenter ce soir une petite conférence sur MEILLEUR-EDITEUR-DE-TEXTE. J’utilise tous les jours MEILLEUR-EDITEUR-DE-TEXTE pour le meilleur et pour le pire, et je ne pourrai vraiment plus me passer de MEILLEUR-EDITEUR-DE-TEXTE.
Ensuite, selon le public visé, il suffit de remplacer « Vim » par « Nano », pour ne pas froisser certaines susceptibilités.
Pour l’extension ou la modification de syntaxe, si par exemple on préfère sortir du (X)HTML strict, pour avoir <em> à la place de la balise <i> et <strong> à la place de <b>, on peut utiliser les règles suivantes :
%!postproc: '<i>' '<em>'
%!postproc: '</i>' '</em>'
%!postproc: '<b>' '<strong>'
%!postproc: '</b>' '</strong>'
Tout est possible à ce niveau.
Enfin, pour les expressions régulières, ça renforce encore l'intérêt des pré‐processeur et post‐processeur.
Par exemple, on peut créer un système simplifié de « livre dont vous êtes le héros », en rajoutant simplement ces 2 lignes :
%!preproc: '(\d+)$' '**[\1 #\1]**', pour obtentir des liens en gras pour les nombres en fin de ligne ([description lien]étant la syntaxe txt2tags pour les liens) ;%!preproc: '^== (\d+) ==' '==\1==[\1]', pour qu'un titre puisse avoir une ancre avec son propre nom.
Ainsi, on pourra créer des liens hypertextes avec ce type de fichier source :
== 1 ==
Ceci est le premier chapitre.
- Aller au chapitre 2
- Aller au chapitre 3
== 2 ==
etc.
Plutôt simple, non ?
Vous pouvez aller tester tout cela sur la page du logiciel, et télécharger l’exemple réutilisable sur n’importe quel espace d’hébergement.
Aller plus loin
- txt2tags-php en ligne, et téléchargement (144 clics)
- Le site de txt2tags (232 clics)
# Souhaitons une belle mort à PHP
Posté par gasche . Évalué à 6. Dernière modification le 28 septembre 2012 à 14:42.
Il me semble intéressant de noter que des trois services "haut profil" que tu cites (LinuxFr, Tumblr, Github), seul Tumblr utilise PHP et encore, ils essaient de s'en débarrasser en utilisant d'autres langages en backend et en limitant PHP au frontend (où ils ont aussi du Ruby sur les bords, je crois). Du coup l'argumentation selon laquelle c'est la disponibilité d'une implémentation PHP qui a fait le succès de Markdown me semble un peu curieuse (d'ailleurs l'implémentation de départ était en Perl). Alors oui les wiki privées, mais n'est-ce pas un usage de plus en plus marginal aujourd'hui, ou au moins réservé aux utilisateurs avertis qui peuvent se trouver un hébergement qui leur permet de choisir le langage serveur ?
PHP est un langage pourri qui a la chance d'être facile à déployer et d'avoir plein de tutoriels douteux qui traînent de l'époque du "web 1.0", et à qui on est ravi de souhaiter une belle mort. Ensuite on pourra se plaindre de Python et Ruby, et ce sera une douleur moins désagréable.
Si des gens trouvent encore amusant de coder des parseurs pour des langages réguliers en utilisant des expressions régulières illisibles dans un langage rétrograde, on leur souhaite bien du plaisir. Et c'est super de faire du logiciel libre, et j'aime bien la GPLv3.
[^] # Re: Souhaitons une belle mort à PHP
Posté par Creak . Évalué à 2.
J'ai encore tendance a utiliser PHP pour mes sites. Si jamais j'avais à recommencer un projet de zéro, tu me conseillerais quel nouveau langage?
Pas nécessairement en prenant en compte le coté pratique, mais aussi le coté populaire.
[^] # Re: Souhaitons une belle mort à PHP
Posté par flan (site web personnel) . Évalué à 2.
Je ne fais du dev web qu'à titre perso, mais j'ai pris la peine d'apprendre Python + Django. Ça demande un investissement initial certain, mais qui est très largement rentabilisé par rapport à du PHP basique (et je trouve Django bien plus simple à utiliser que Symfony, même si je n'ai pas eu beaucoup d'expérience avec ce dernier).
Au final, avec Django, on se retrouve à écrire quelques classes Python pour le modèle de données, quelques fonctions pour les pages appelées (une page == une fonction en gros), avec quelques templates HTML, et hop, c'est fini :) J'exagère, mais à peine ^
[^] # Re: Souhaitons une belle mort à PHP
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 2.
Sans compter le mois pour réécrire les requêtes en SQLAlchemy parce qu'elles mettent 20 s à calculer une table qui nécessite une requête s'exécutant en quelques ms :o)
[^] # Re: Souhaitons une belle mort à PHP
Posté par fravashyo . Évalué à 10.
à mon avis PHP n'est pas prêt de mourir. Et tant que la plupart des hébergeurs gratuits continueront à proposer uniquement du PHP, j'imagine que PHP continuera à rester bien utilisé.
À ce propos, Wordpress, Joomla, Drupal, Spip, Modx sont les CMS les plus utilisés par les agences Web (et de façon générale), et ce sont des compétences en PHP qui sont demandées chez la plupart des développeurs Web. Même facebook est conçu en PHP.
Non pas que je préfère tel langage ou tel autre (je ne sais pas spécialement coder à ce niveau) mais c'est un fait, même si tu n'aimes pas PHP pour diverses raisons, peut-être d'ailleurs les mêmes que celles avancées ici :
https://linuxfr.org/users/montaigne/journaux/php-a-fractal-of-bad-design
et dont une réponse possible est ici :
https://linuxfr.org/users/montaigne/journaux/php-a-fractal-of-bad-design#comment-1388432
Et en parlant de souhaiter une belle mort, c'est pas python qui a tenté de se suicider en sortant une version 3 qui est largement incompatible avec la version précédente, et qui peine à percer face à la v2 (peu de projet ayant migré vu le travail à réaliser) ?
les regex en php et python sont quasi identiques.
« I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond
[^] # Re: Souhaitons une belle mort à PHP
Posté par BohwaZ (site web personnel, Mastodon) . Évalué à 6.
Les seuls qui n'aiment pas les regexp sont ceux qui ne savent pas en faire ;)
Quand on maîtrise cette extraordinaire invention, on en vient à coder des pans entier de logiciel avec (en plus comme ça personne ne saurait reprendre le logiciel après soi, ça empêche de se faire virer ).
« Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)
[^] # Re: Souhaitons une belle mort à PHP
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
Ils utilisent pas tous les deux PRCE ?
De toute manière, les regex, cela a toujours été le dada de Perl ;-)
[^] # Re: Souhaitons une belle mort à PHP
Posté par Antoine . Évalué à 3.
Non, Python a son propre moteur d'expressions régulières.
[^] # Re: Souhaitons une belle mort à PHP
Posté par claudex . Évalué à 5.
Ref nécessaire. J'aurais plutôt tendance à dire : peu de projet n'ont pas encore migré et encore moins n'ont pas de migration en cours. Les gros projets qui manque à l'appel sont surtout les implémentations alternatives (Jython, Pypy) qui sont encore à la 2.x et n'ont pas de projet (à ma connaissance) pour migrer.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Souhaitons une belle mort à PHP
Posté par fravashyo . Évalué à 1.
https://www.archlinux.org/packages/extra/i686/python2/
fontforge, xulrunner, scribus, texmacs, txt2tags, tuxpaint, wesnoth, wicd, widelands, xbmc, ufw, trac, totem, oolite, mercurial, mapnik, lilypond, hplip, 0ad utilisent python2.
378 paquets pour python2, contre 96 paquets pour python3.
Ça me semble assez éloquent. Pour python3, les seuls paquets vraiment notables que je vois sont autojump, blender, freenx et konversation
« I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond
[^] # Re: Souhaitons une belle mort à PHP
Posté par claudex . Évalué à 5.
Je ne vois pas ce que tu essaye de montrer avec ta liste. Mon commentaire parlait aussi des projets en cours de migration :
Et de plus, elle n'est pas correcte. txt2tags, par exemple, a une version python3. Je n'ai pas envie de vérifier pour toute ta liste.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Souhaitons une belle mort à PHP
Posté par fravashyo . Évalué à 0.
ben que python3 est peu utilisé dans les faits (d'ailleurs il n'y a qu'une seule distribution qui l'utilise par défaut).
Tiens j'avais oublié FreeCAD qui utilise python2.
Pour la migration en cours, ça veut dire tout et rien (bref, "références nécessaires"), si je cherche pour quelques projets de cette liste, je ne vois pas de références à des migrations vers python3.
Tu fais bien de citer le portage de txt2tags vers python3 : le code de ce portage n'a pas évolué depuis 2 ans, et il y a eu plus de 600 commits depuis, pour enrichir et remanier le code de la version python2, autant dire qu'il faudra tout refaire si un nouveau portage est envisagé. Le développement continue sur python2 car le but est de rester compatible avec de vieux systèmes (ou des terminaux mobiles) qui utiliseraient encore une vieille version de python (le minimum requis est 2.5).
« I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond
[^] # Re: Souhaitons une belle mort à PHP
Posté par claudex . Évalué à 4.
Ça me semble logique que la migration ne soit pas instantanée mais on voit justement de plus en plus de migration. On est quand même très loin du suicide dont tu parle.
Je pense à Django par exemple, c'est un gros projet Python très utilisé qui sera compatible Python 3 dans sa prochaine version.
C'est vraiment bizarre de le présenter au même niveau que la version python 2 si c'est une vieille version.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Souhaitons une belle mort à PHP
Posté par wilk . Évalué à 3.
pypy est en cours de portage, il va y a un développeur payé pour ça (depuis 4 jours). Encore mieux, le projet prévoit de supporter la 2 et la 3 avec le même code. Le top serait de pouvoir utiliser du code 2 et du code 3 en même temps, ça serait idéal pour les migrations, sinon c'est vrai que c'est un peu le casse tête, il y a toujours une librairie qui manque…
http://morepypy.blogspot.fr/2012/09/py3k-status-update-6.html
[^] # Re: Souhaitons une belle mort à PHP
Posté par gasche . Évalué à 0. Dernière modification le 30 septembre 2012 à 11:42.
Le lien que tu cites pour critiquer PHP n'est qu'une référence à l'article originel PHP: a fractal of bad design qui est très complet (pourquoi le journal LinuxFR a choisi l'exemple de
emptyqui est parmi les moins convaincants du document, je l'ignore, tout comme l'intérêt de pointer vers ce journal et pas l'article de départ) et qui montre avec une argumentation très fournie que PHP est un langage horrible.Ton argumentation c'est "PHP est facile à déployer et utilisé par des gens". Mon commentaire porte sur le fait que, techniquement, le langage de programmation est une bouse. Je suis le premier à reconnaître qu'il est facile à déployer, et je sais que des gens l'utilisent. Justement quand je parle de "souhaiter une belle mort à PHP" c'est que j'espère qu'il va mourir, et que donc les hébergeurs feront des efforts pour rendre des langages moins pourris aussi faciles à déployer (pour un développeur sérieux il est facile aujourd'hui de trouver un hébergement web qui propose de nombreux autres langages; Alwaysdata propose un plan gratuit limité qui propose quand même PHP, Ruby, Python et Perl, MySQL, PostgreSQL, MongoDB et CouchDB), et que les gens qui font du web développeront leurs applications/bibliothèques/frameworks/whatever dans un langage moins pénible à utiliser (car oui parfois aujourd'hui on est forcés de déployer un logiciel PHP, pas à cause des qualités du langage et du plaisir de maintenance qu'on va en retirer, mais parce que les développeurs de CMS ont choisi de l'utiliser car il y quelques années il était le plus populaire sur le web).
Le contre-troll sur Python m'a l'air hors sujet et, bien qu'il a effectivement réussi à dérailler la discussion sur PHP, je ne vois pas trop quel est le rapport avec la question de l'usage du langage pour le web (et par ailleurs je n'ai pas une affection immodérée pour Python; mais au moins c'est un langage que je respecte, contrairement à PHP qui ne mérite que le mépris).
[^] # Re: Souhaitons une belle mort à PHP
Posté par fravashyo . Évalué à 1.
La raison d'être de la création de txt2tags-php c'est justement que PHP est "utilisé par des gens". Qu'il est pratique de pouvoir envoyer et interpréter directement des fichiers t2t sur 100% des hébergement web existants et savoir que ça va fonctionner dans tous les cas.
Que PHP soit réellement pourri, ou que tu abhorres ce langage parce que ta copine est partie avec un développeur PHP, ça me semble accessoire dans l'histoire, d'autant plus que txt2tags existe déjà en version python, et fonctionne donc sur un serveur web équipé de python, cf. http://txt2tags.org/online.php
Et puis quand ça sera Ruby on Rails ou autre qui sera devenu le standard, il sera toujours temps de faire une nouvelle implémentation à ce moment-là.
« I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond
[^] # Re: Souhaitons une belle mort à PHP
Posté par ZankFrappa . Évalué à 2.
Bien que des tas de gens l'aient déjà fait à ta place (avec plus ou moins de succès), je pense qu'il est un peu limite de parler de « langage pourri » sans même un lien pour te justifier. As-tu des critères objectifs, qui n'auraient rien à voir avec le goût (ou le dégoût), pour critiquer PHP ? Comment formaliser le fait qu'un langage est "mieux" qu'un autre ?
Je pense que tu voulais dire « des langages non-réguliers », sinon je ne vois pas trop ce que tu peux espérer d'autre. :)
[^] # Re: Souhaitons une belle mort à PHP
Posté par flan (site web personnel) . Évalué à 2.
Je pense que le lien plus haut ( http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/ ) donne un certain nombre de bonnes raisons :)
Je traduis l'introduction :
> * un langage doit être prédictible. […]
> * un langage doit être cohérent. […]
> * un langage doit être concis. […]
> * un langage doit être fiable. […]
> * un langage doit être débuggable. […]
> Ma position est celle-ci :
> PHP est plein de surprises : mysql_real_escape_string, E_ALL
> PHP est incohérent : strpos, str_rot13
> PHP demande de l'emballage (boilerplate), comme la gestion d'erreurs autour des appels C
> PHP n'est pas fiable (== qui n'a pas le sens habituel et qui ne sert à rien, foreach ($foo as &$bar))
> PHP est opaque (pas de stracktrace par défaut, rapports d'erreurs complexes)
>
> Ne me dites pas que « de bons développeurs peuvent écrire du bon code dans n'importe quel langage », ou de mauvais développeurs blah, blah, blah. Ça ne veut rien dire. Un bon charpentier peut enfoncer un clou avec une pierre ou un marteau, mais combien en avez-vous vus taper quelque chose avec des pierres ? […]
> Ne me dites pas que c'est la responsabilité du développeur de se souvenir des centaines d'exceptions étranges et de comportements surprenant. Oui, c'est nécessaire dans tous les systèmes. […] PHP n'est rien qu'un paquet d'exceptions […]
> Ne me dites pas que « c'est comme ça que l'API C fonctionne ». Quel intérêt d'utiliser un langage haut-niveau s'il ne fournit que quelques aides et wrappers C ? Autant écrire du C !
Le reste du texte est bien intéressant :)
# Bien !
Posté par rakoo (site web personnel) . Évalué à 4.
C'est une bonne nouvelle pour un système qui a plein d'atout, mais :
Je pense apporter une voie de réponse en disant que ce n'est pas son but. Le but de txt2tags est d’écrire un message totalement indépendant de quel logiciel le lit, dans un format qui soit transformable en une myriade d'autres formats. Ainsi il sert a créer un document, là ou Markdown et consorts servent a mettre en forme du texte qui va être inclus dans une page, et non pas exister en lui même.
Je pense par exemple aux 3 premières lignes, nécessaires dans txt2tags, mais souvent inutiles dans les endroits ou les autres formats sont utilisés. Lorsque j’écris ce commentaire, je n'ai aucune envie d'en spécifier les éléments suivants :
si ce n'est éventuellement le titre, mais je peux déjà le rentrer d'une autre manière.
Dans le même sens, je suis persuadé que générer un document HTML complet n'a pas de sens si on veut l'utiliser de la même manière que Markdown; puisque ces textes vont être inclus ailleurs, les en-têtes seront générés par l'application qui sert les pages, non par le texte que l'utilisateur tape.
Au final, la version php est utile pour la syntaxe est les pre/post process, mais la partie 2tags du titre est trompeuse; il faudrait peut-être appeler ça plutôt txt2html ?
[^] # Re: Bien !
Posté par fravashyo . Évalué à 2.
Ces 3 lignes sont réservées (on ne peut pas écrire autre chose), mais nullement nécessaires, c'est à dire que si on n'y écrit rien, rien ne sera affiché.
effectivement c'est ciblé html, forcément, mais d'un autre côté avec le système de postproc on peut exporter vers n'importe quel tag, donc le titre reste malgré tout valable
L'intérêt de ce module c'est de pouvoir éditer puis stocker des informations (document, commentaire, post de blog ou autre) au format txt2tags sur le serveur et l'afficher ensuite directement en html.
« I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond
[^] # Re: Bien !
Posté par anaseto . Évalué à 2.
Dans les extensions markdown de pandoc (implémentation en haskell), il y a aussi trois lignes optionnelles au début pour le titre, auteur et date.
Par contre haskell est beaucoup moins courant que d'autres langages.
Il y a aussi multimarkdown qui supporte assez d'extensions.
[^] # Re: Bien !
Posté par anaseto . Évalué à 3. Dernière modification le 28 septembre 2012 à 18:53.
Par contre, pour autant que je sache, pandoc n'est pas extensible dans le document même.
# la forme aussi ça compte
Posté par asteroid . Évalué à 4.
Chiant qui s'assume, je trouve l'article super intéressant, d'autant plus que j'utilise t2t, mais il est dur à lire :
72 mots, pour une seule phrase, c'est à la limite du lisible. On s'en sort bien, il n'y a qu'une paranthèse.
Merci quand même pour des nouvelles de ce super outil.
On peut aussi préciser que l'outil en ligne de commande permet de formater du t2t en ASCII Art, AsciiDoc, Creole, DocBook, DokuWiki, Google Code Wiki, HTML, LaTeX, Lout, MagicPoint, Man page, MoinMoin, Page‐Maker, Plain Text, PmWiki, SGML, Wikipedia et XHTML. Il gère aussi les TOC.
Il permet aussi de d'importer des css (et en propose une par défaut), ou de créer une présentation (options --slides).
Dans l'entête des documents.t2t on peut aussi importer ou définir différents éléments, comme des alias, …
Bref, t2t c'est bon, mangez en.
Pour apporter un élément de réponse du vendredi :
Parce que les esprits torturés qui hackent markdown trouvent plus logique d'encadrer un mot par des underscores pour le mettre en italique … le slash est tellement peu évident. Et souligner un mot de toute façon c'est sémantique faux, autant que l'underscore serve à quelque chose. Attention aussi, __ n'est pas _ en markdown (respectivement gras ou italique, ce qui semble fort logique).
En tous cas, en texte brut, celui qu'on utilise sur les mailing list, la mise en évidence est proche de txt2tags, et non de markdown :
Après, pour ce qui est des blocs, les différents langage se tiennent.
# dredi
Posté par CrEv (site web personnel) . Évalué à 2.
Say dommage, mais pour le coup je ne trouve pas que GPLv3 soit un point positif. A la rigueur du LGPLv3 oui, mais je trouve le choix de GPLv3 contraignant pour une lib du genre.
En fait j'aime bien quand les libs sont en LGPL ou, mieux de mon point de vue, BSD/MIT
Mais bon, c'est intéressant quand même
[^] # Re: dredi
Posté par fravashyo . Évalué à 2.
je crois que certaines fonctions sont dérivées de celles de PmWiki, qui est en GPL, pas en LGPL, donc j'imagine que la GPL ne permet pas de passer direct en LGPL pour le code dérivé.
« I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.