En parlant avec Stéphane hier sur IRC, j’ai soudainement eu une idée à propos d’un nouveau plugin pour Dotclear. Stéphane m’ a dit que si mes messages en anglais étaient sur Github, il m’aiderait à corriger mon anglais directement en commentant[1] sur le dépôt Github — cela veut dire que nous avons besoin d’un dépôt dédié et je pense, un simple fichier pour chaque billet, peut-être dans des dossiers représentant les catégories. Ainsi, le plugin devra vérifier régulièrement le dépôt et extraire les fichiers nouveaux et/ou modifiés pour respectivement créer ou mettre à jour des billets sur le blog.
J’ai commencé à y penser tout l’après-midi, hier, en supposant que nous devions avoir quelques règles sur le contenu des fichiers. Par exemple, la toute première ligne pourrait être utilisée comme titre pour l’entrée ou peut-être que le nom de fichier suffira pour cela, l’extension du fichier pourrait être utilisée comme un indicateur sur la syntaxe utilisée — .md pour Markdown, .html pour HTML forcément, et peut-être .txt pour le wiki par défaut de Dotclear ? —, je ne sais pas encore ; nous pourrions aussi trouver un moyen de définir les balises, et pourquoi pas la date et l’heure de publication, etc…
Quoi qu’il en soit, il semble que ce n’est pas une grosse problème de récupérer du contenu de Github, nous avons besoin d’un token qui sera défini dans les paramètres du référentiel de Github, je suppose, et certains paramètres devront être pris en charge par le plugin comme l’URL du dépôt (ou URL API), le token du dépôt,…
Que pensez-vous de cette idée?
PS : Billet traduit de l’original via DeepL et (à peine) remanié par mes soins.
Note
[1] Ou pourquoi pas en faisant des pull-requests et en les fusionnant après.
1 De Bernard -
J’ai pas tout compris, mais….
J’utilise souvent google traduction et j’ai remarqué que tu peux proposer une “meilleure” traduction en cliquant sur .
Je ne sais pas ce qu’il en font, mais ça pourrait être un truc exploitable dans ton idée…
2 De Franck -
C’est un peu l’idée Bernard en créant un dépôt avec des fichiers sur Github, chacun étant ensuite libre de commenter pour corriger ou suggérer. De plus, Github permet de conserver une trace des versions successives, ça peut toujours servir :-)
À la base Github est prévu pour gérer les évolutions de code, mais d’autres s’en servent pour tout autre chose, par exemple écrire des textes, voire même générer des blogs !
3 De Sylvain -
Dans la version Node.js de TiddlyWiki, les fichier textes *.tid sont structurés comme ceci :
///
caption: Un titre de substitution
created: 20171103212431197
modified: 20171103212525475
tags: Tag2 Tag1
title: Un titre
Du contenu
///
Ici dans l’exemple caption est un champ personnalisé, on peut en créer autant que l’on veut.
Il y a un espace avant le contenu du tiddler.
4 De mirovinben -
Marrant ça, même en français je ne comprends pas tout… :-)
(et je retourne en sifflotant vers mon banc regarder passer les nuages)
5 De Franck -
Sylvain je pensais à quelque chose de plus simple encore, en particulier pour le titre, où on pourrait tout à fait s’appuyer sur la syntaxe du contenu et prendre le premier titre (au sens HTML) qui vient et s’en servir comme titre du billet.
Exemple : # titre en Markdown ou !!!!! titre par extension de la syntaxe wiki Dotclear.
L’idée est de simplifier au maximum le contenu pour qu’il ne comporte que du contenu et pas les métadonnées.
Faut encore que j’y réfléchisse…
6 De Franck -
Au passage je trouve que la syntaxe des dates et heures de TiddlyWiki pour les fichiers *.tid est particulièrement illisible !
À choisir je préfèrerais un format du style aaaa/mm/jj hh:mm qui est largement suffisant, non ?
7 De Sylvain -
Nous sommes d’accord sur le format de la date :D
En l’occurrence le timestamp est créé automatiquement, donc ça va.
Après j’ai cru comprendre que la manipulation de date est parfois problématique, pour l’internationalisation par exemple.
Reste que si je souhaite créer un tid sans TiddlyWiki (pour l’instant j’en ai pas eu besoin mais ça pourrait puisque la syntaxe est quand même très simple) c’est possible, par exemple :
title: Un titre
Du contenu
A l’import je n’aurai pas de date, ça ne semble pas le gêner. Il en mettra une si j’édite mon contenu par la suite (ainsi que d’autres champs système si besoin, comme le type de contenu, etc..).