Je note ce que je vois à ce stade, qu'il s'agisse de considérations techniques ou d'organisation.
Il faut pouvoir choisir d'inclure ou d'exclure des espaces de nom (c'est à dire des dossiers et ce qu'ils contiennent), de façon récursive ou non. Exemple sur le wikhan : la liste des primitives (plusieurs centaines d'articles, dans un dossier) est intéressante seule et pour une impression, pas forcément inclut avec tout le reste et dans un document à lire page à page à l'écran.
Il faut prendre en compte la syntaxe dokuwiki et les plugins ajoutés. Là-dessus, deux trucs :
- la syntaxe par défaut est bien documentée, donc ça ne devrait pas poser souci,
- les plugins ont leur syntaxe de code toujours incluse soit dans
< >, soit dans
{{ }}. Et je crois que c'est tout.
Dans ce second cas, il faudrait donc dans un premier temps faire tourner un script sur les pages des wikis, chargé de collecter toutes ces balises. Il n'y en a quand même pas tant que ça. Il y a un risque de récupérer des codes non wiki (les exemples de code), il faut donc détecter de ne pas intérepréter ce qui est entre
<code><code>.
Une fois tous les codes syntaxes récupérés, il faudra voir comment les traduire en un autre langage (probablement html).
Il faut aussi décider de quel format en sortie nous voulons.
- L'epub me semble le plus intéressant car c'est assez riche au niveau mise en page et il y a des logiciels pour lire les epub sur ordi, smartphone, bref, ça le fait. Sachant aussi qu'un epub, en fait, c'est du css et des pages html, il est donc possible aussi de proposer ça en mode "site hors ligne" pour celles qui n'aiment pas les epubs.
- Envisager le pdf peut être intéressant si certaines souhaitent imprimer, car ça permet une mise en page bien calibrée. Mais c'est un peu plus hasardeux donc uniquement si y'a vraiment une demande...
- Je ne suis pas très motivée par le .doc, .txt et autres formats de document texte, ça ne me semble pas adapté... mais suivant vos retours, c'est à voir.
Sur la façon donc le script de génération peut tourner, pour moi ce sera un truc que je mettrais sur le serveur, et que je lancerais via une commande. Après, les wikis sont aussi archivés sur git, donc n'importe qui peut les récupérer ainsi que le script et se faire sa propre édition si des admin ne sont pas dispo. On peut aussi envisager une interface web qui permettrais de lancer le script python, accessible uniquement à un groupe donné (genre collège+gens de confiance). Lancer des scripts en boucle est toujours un peu risqué pour un serveur, je préfère limiter ce genre d'accès.
Autre option à envisager (potentiellement dans un second temps) : pouvoir préciser l'ordre de certaines pages, certains dossiers ? genre mettre "géographie" avant "histoire" ? Je ne suis pas sûre que ce soit très utile.
J'ai ajouté aussi le plugin
"mardown", qui permet aux gens habitués à écrire en mardown de passer par cette syntaxe. Cela veut dire que le script doit analyser que ce qui est compris entre les balises <mardown></mardown> comme étant du mardown et plus du dokuwiki... Y'en a pas trop pour le moment.
