Sujet sur Discussion utilisateur:Tpt

Aller à : navigation, rechercher
Reptilien.19831209BE1 (discussioncontributions)

Bonjour, j'ai une idée qui me trotte dans la tête depuis un petit moment et j’aimerais avoir ton avis sur la faisabilité technique, et surtout savoir si ça en vaut la peine.

La communauté s'est exprimée ici et quant au souhait d'étendre les possibilités d'exportation, à savoir : se débarrasser des s longs, ne pas inclure les images ou les liens, laisser les coquilles, supprimer les notes wikisources, activer ou non le dictionnaire de modernisation, etc...

Pour faire gagner du temps à tout le monde (surtout à toi), l'idée en question serait d'ajouter un paramètre supplémentaire à l'outil Proofread Page, appelons-la callback, qui se chargerait d'appeler un module hébergé sur chaque projet Wikisource et géré par la communauté, et dont le rôle serait de traiter le contenu pour la transclusion ou l'exportation. De cette manière pas besoin de modifier à chaque instant l'outil d'exportation, mais seulement le module en question.

J'avais tenté quelque chose, uniquement avec le s long, pour voir si l'outil d'exportation répondait correctement, mais il faut utiliser ce module à la place de la balise <pages /> pour la transclusion... ce qui est fort ennuyeux !

On aurait donc sur la page de transclusion quelque chose comme :

<pages index="..." ... callback="Module:Options_de_lecture[|option1|option2|...]"/>

où le Module:Options_de_lecture (ou peu importe) se chargerait du traitement.

Remarque, on peut aussi plus simplement ne pas mettre en place ce paramètre, et appeler un module en dur dans le code PHP de l'outil : Mediawiki:Proofreadpage callback, à l'instar de MediaWiki:Proofreadpage index template, et la communauté se chargerait de créer une redirection à sa convenance...

Pour les options (je veux les images mais pas les s longs), on pourrait imaginer mettre à la disposition des lecteurs un formulaire avec des cases à cocher :

  • transformer les s longs en s ronds
  • ne pas inclure les images
  • supprimer les liens
  • conserver les coquilles
  • ...

une fois le bouton « télécharger » pressé, les paramètres de ce formulaire seraient transmis à l'outil d'exportation et seraient considérés comme les paramètres du Module:Options_de_lecture, activant l'un ou l'autre traitement.

Pour la lecture (dans l'espace principal) par contre, je sèche car il n'est pas (encore) possible de récupérer les variables GET/POST dans un module. Du coup, comment laisser le choix au lecteur ? peut-être que l'extension Proofread Page peut prendre le relais (récupérer les variables et les transmettre au module).

Voilà, j'espère que tu as plus ou moins saisi l'idée. Peut-être qu'on pourrait faire autrement et plus simplement, à toi de me le dire.

Je crois savoir que tu es fort pris en ce moment, donc je ne m'inquiète pas si tu ne me réponds pas dans l'immédiat, mais au moins, cette idée est posée quelque part.

@ bientôt ;-)

Tpt (discussioncontributions)

Pardon pour la réponse lente, j'attendais de pouvoir te faire une réponse constructive. La voici :

Faire un formulaire changeant le rendu côté serveur des pages semble difficile à mettre en place sans investissement réel de la Wikimedia Foundation car il faudrait que le cache du rendu des pages soit compatibles avec ce genre d'options. Et, de plus, cela va dans une direction différentes de projets comme stocker les pages non plus en wikitext mais dans en HTML (avec les métadonnées Parsoïd).

Ce qu'on peut faire c'est, au lieu d'utiliser des modules Lua, d'étendre (et nettoyer) le système actuel de scripts JavaScript qui on l'avantage de tourner côté client et donc de passer au dessus du système de cache. Si on arrive à mettre en place cela de manière propre on peut tout à fait imaginer que Wsexport télécharge le script pour tel Wikisource, regarde les options disponibles, les proposes à l'utilisateur et fait tourner le script sur chaque page avant la construction de l'ePub en faisant tourner le(s) script(s) via nodejs ou quelque chose du genre.

Niveau implémentation cela n'est pas trivial mais cela semble faisable (le plus dure étant sans doute d'avoir quelque chose comme nodejs mais complètement sandboxé et qu'on puisse appelé depuis PHP).

Reptilien.19831209BE1 (discussioncontributions)

Merci d'avoir pris le temps de me répondre. Concernant le formulaire je l'imaginais tout simplement fabriqué en javascript, ne voyant pas d'autre solution. Pour ce qui est du cache, je pensais bien qu'il allait posé problème mais j'étais persuadé qu'il pouvait prendre en charge des paramètres HTTP/GET (je ne sais plus d'où je crois tenir cette info). Utiliser du javascript repris par un serveur node.js à la place de modules lua, oui, pourquoi pas, je n'y avais tout simplement pas pensé...

N'hésite pas à nous tenir informés si tu avances dans l'une ou l'autre piste.

Tpt (discussioncontributions)

Ok ! Si tu (ou quelqu'un d'autre...) as les compétences et le temps n'hésite pas à te lancer dans ce projet.

Répondre à « Proofread Page et l'outil Export »