Aller au menu du forum Aller au contenu du forum Aller à la recherche dans le forum
Logo Khaganat
Menu principal

Transformer les wikis en fichiers type "pdf"

Zatalyz

Bonjour à toutes !

La demande traine depuis de longues années, récemment remise à jour par deux de nos membres (voir aussi l'issue git).

Nos wikis sont volumineux et pas forcément très pratiques à consulter en mode transport en commun, c'est à dire sur un écran minuscule et une connexion internet fluctuante. Ou tout autre circonstance où on s'ennuie facilement et où on a le temps de lire Khaganat.

L'idée serait donc de créer des fichiers pages à pages. Je parle de pdf mais ce n'est pas forcément le plus pertinent (pas d'adaptation à l'écran) ; epub me semblerais plus raisonnable, j'ai aussi entendu parler de document texte (ce qui posera souci sur les quelques images, mais on n'est pas obligé de les garder).

La vraie bonne chose à faire serait évidement d'avancer sur le guide du Khanat et de réaliser un bel epub des histoires sur la mediateki, mais c'est un gros travail et vu comme tout le monde est occupé, ça risque de prendre du temps. Or c'est maintenant que certaines souhaitent lire, sans forcément demander le top qualité.

J'aimerais donc mettre en place une solution d'automatisation, qui génèrera divers formats à partir des wikis ; suffira de relancer la génération des documents quand quelqu'un demande et ça répondra au besoin. Je n'attends pas que ce soit parfait, juste qu'on aie quelque chose. À noter que ce sera une bonne base de travail pour un recueil sur la mediateki, mais ce n'est pas ce wiki qui m'inquiète le plus.

Il existe des plugins pour dokuwiki qui font ça, mais ils souffrent de défauts :
- soit il faut sélectionner et organiser les pages une par une... ça peut marcher pour la mediateki (possibilité de faire des recueils thématiques et y'a pas tant d'articles) mais pas sur les autres wikis.
- soit c'est "automatique" en prenant tout un espace de nom sauf que, comme nous avons énormément de pages, ça prend beaucoup de temps... et comme cela se fait via php, on atteint une limite de temps qui fait planter le processus avant la fin. Un hack moche serait que je modifie la durée maximale d'exécution, mais cette durée existe pour une bonne raison et de toute façon, cette façon de faire est une aberration.

Il faut donc que nous fassions un truc dédié à ça, vu que je n'ai rien trouvé de tout fait.

Pourquoi je poste ici plutôt que dans Programmation ?

Avant de se lancer dans du code, il faut savoir exactement les contraintes et ce qu'on souhaite obtenir. Elen est passé l'autre soir et a proposé son aide pour écrire le script de traduction mais je me rends bien compte qu'il me manque des éléments pour donner des directives pertinentes.  C'est pourquoi je lance un appel ici. Que voyez-vous de nécessaire dans un outil de ce genre ? que faut-il prendre en compte ? quel est le résultat à espérer ?

Zatalyz

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.
Dernière édition: 02 Février 2018 à 10:00:48 par Zatalyz

Scoui

J ai pas tout lu mais de mémoire les pdf c est pas partie de plaisir sauf, et je dit ca sans aucun jeu de mots, pour les fans de LaTex :D

Pour les txt et les images rien empeche de mettre le lien vers le wiki a la place.

Sinon ca voir les wikis de ryzom il ont une option pour recup ube version texte ou les sources, ce dont je m etait servit pour mes scripts de recup des mots des wiki vers blablatys.
Un simple script php qui traduisait le code du wiki vers un fichier txt, formaté a ma sauce,  quej utilisai ensuite pour templir ma bdd automatiquement.

J avais meme pour veleis un script pour parser le bbcode et le traduire en version php ryzom-ig pourri ^^
Faudrai v oir si il existe une lib pour passet de dokuwiki vers latex quitte a ajouter un sctipt entre pourbles plugin non gerer.
Voir faire un plugin si rien existe ^^ et participer a ameliore ton wiki préférée :D
*tend un appât a dev en forme de manchot*

Pour passer le temps,  quand ritaline+froid font effet,  je reflechissait justement a un lib python pour faciliter les conversion d un format a un autre en fournissant juste un schema avec une liste de "regle" ^^


Sinon je sais pas si pdf serai le plus judicieux a l heure actuelle.
En fait faut voir quels outils libre et viable il existe et se decider pour le format le  mieux représenté la dedand
Souvent aussi plutot que passet directement au forma final ont peu avoir besoin d ùautre format intermediare, faut voiire avec les outils existant.

Ou sinon juste faire un script pour automatiser celui qui marche que page par page.
Je verrai bien une sorte de panier style shop ou tu marque les pages ou les section que tu veux puis sur ton panier tu lance le script d export qui fait juste les page voulu quitte a attendre si le serveur est surchargé et tevup les page une fois prete mais je verrai plus ca fait coter cluent du coup plutot que tout a dispo chasun choisi ce qu il veux et fait ca de son coter.

Bref en tout cas avoir de sui lire les aventure de Kirun offline sera top :)
[img][url="http://www.yubo-flaneur.fr/public/images_hosting/scoui_sign.jpg"]http://www.yubo-flaneur.fr/public/images_hosting/scoui_sign.jpg[/url][/img]

Zatalyz

Il existe quelques plugins, malheureusement rien qui survit à l'export de tout le wiki.

https://www.dokuwiki.org/plugin:epub : il faut entrer chaque lien de page. Ça va quand il y en a moins d'une trentaine, mais sur 1000, argh. Par contre on peut organiser dans un certain ordre les pages, ce qui est assez approprié pour les histoires de la Mediateki ou le guide du Khanat. De mémoire, l'epub généré est un peu crasseux, mais ça date d'il y a plusieurs années, ça s'est probablement amélioré (j'espère).

https://www.dokuwiki.org/plugin:bookcreator fonctionne un peu comme ce que tu décrit : tu active la fonction, puis tu met tes pages dans un panier. Idem, c'est pas mal tant que tu n'as pas des milliers de pages... Ça, c'est vraiment sympa pour l'utilisateur, assez ergonomique.

https://www.dokuwiki.org/plugin:dw2pdf exporte en pdf, et comme tu le dis, ce n'est pas forcément mon option préférée. De mémoire, il plante à un moment (trop de pages à exporter).

https://www.dokuwiki.org/plugin:siteexport : me souviens plus... mais je crois qu'il rame aussi au bout d'un moment.

Ce qui est logique : passer par le php pour exporter milles pages et plus, forcément on tombe sur le timeout de php. Enfin, c'est pas forcé, un plugin pourrait gérer ça en faisant plusieurs requêtes au lieu d'une seule grosse (puis combiner le résultat des requêtes), mais dans les faits, non.

Mes tests des plugins commencent à dater un peu, certains plugins ont été mis à jour, faudrait que je refasse le point... M'enfin pas tout de suite ^^

Licences Mentions légales Accueil du site Contact