Jump to content

Community Wishlist Survey 2019/Wikisource

From Meta, a Wikimedia project coordination wiki
11 proposals, 170 contributors, 455 support votes
The survey has closed. Thanks for your participation :)

Ajax editing for nsPage

Français: Des outils Ajax pour l'espace Page.
  • Problem: The editing into nsPage are much slower than needed - a lot of valuable user time is wasted dealing with "easy" edits.
    Français: Les modifications apportées à nsPage sont beaucoup plus lentes que nécessaire: un temps précieux est perdu à gérer des modifications "faciles".
  • Who would benefit: Many wikisource contributors but the beginners.
    Français: Beaucoup de contributeurs à wikisource sauf les débutants.
  • Proposed solution: An AJAX environment for both edit & view can fasten edit a lot; heavy tools and settings would be loaded once for a large sequence of edits (just as wikidata does). Consider that edit conflicts are very infrequent in nsPage. A successful gadget based on AJAX edit/preview is running into itwikisource but it's a "do-it-yourself" tool.
    Français: Un environnement AJAX pour l'édition et l'affichage peut améliorer grandement la vitesse d’édition; les outils lourds et les paramètres sont chargés une seule fois pour une grande séquence de modifications (comme le fait wikidata). Considérez que les conflits d’édition sont très rares dans nsPage. Un gadget basé sur l'édition / prévisualisation AJAX fonctionne bien avec itwikisource, mais il s'agit d'un outil "à faire soi-même".
  • More comments:
  • Phabricator tickets:


Could you provide a link to the itwikisource tool? MaxSem (WMF) (talk) 22:11, 30 October 2018 (UTC)[reply]

Sure: https://it.wikisource.org/wiki/MediaWiki:Gadget-eis.js . But please catche the rough idea, the code runs and is used by many users, but it is a DIY (do-it-yourself) code. Its name is eis from "edit in sequence"--Alex brollo (talk) 19:34, 4 November 2018 (UTC)[reply]


Improve export of electronic books

Original title (Français): Améliorer l'exportation des versions électroniques des livres
  • Problem: Imagine if Wikipedia pages could not display for many days, or would only be available once in a while for many weeks. Imagine if Wikipedia displayed pages with missing information or scrambled information. This is what visitors get when they download books from the French Wikisource. Visitors do not read books online in a browser. They want to download them on their reader in epub, mobi or pdf. The current tool (Wsexport) to export books in these formats has all those problems : on spring 2017, it was on and off for over a month ; after october 2017, mobi format did not work, then pdf stopped working. These problems still continue on and off.
    Français: Imaginez si les pages Wikipédia ne s’affichaient pas pour plusieurs jours, ou n’étaient disponibles que de façon aléatoire durant plusieurs jours. Imaginez si sur les pages Wikipédia certaines informations ne s’affichaient pas ou était affichées tout croche. C’est la situation qui se produit pour les visiteurs qui désirent télécharger nos livres. Les visiteurs ne lisent pas les livres en ligne dans un navigateur, ils désirent les télécharger sur leurs lecteurs en epub, mobi ou pdf. L’outil actuel (Wsexport) permettant l’export dans ces formats possède tous ces problèmes: au printemps 2017, il fonctionnait de façon aléatoire durant un mois; depuis octobre 2017, le format mobi puis pdf ont cessé de fonctionner. Ces problèmes continuent de façon aléatoire.
  • Who would benefit: The end users, the visitors to Wikisource, by having access to high quality books. This would improve the credibility of Wikisource.

    This export tool is the showcase of Wikisource. Contributors can be patient with system bugs, but visitors won’t be, and won’t come back.

    The export tool is as important as the web site is.

    Français: L’utilisateur final, le visiteur de Wikisource, en ayant accès à des livres de haute qualité. Ceci contribuerait à améliorer la crédibilité de Wikisource. L’outil d´exportation est une vitrine pour Wikisource. Les contributeurs peuvent être patients avec les anomalies de système, mais les visiteurs ne le seront peut-être pas et ne reviendront pas. L’outil d’exportation est tout aussi important que le site web.
  • Proposed solution: We need a professional tool, that runs and is supported 24/7, as the different Wikimedia web sites are, by Wikimedia foundation professional developers.

    The tool should support different possibilities of electronic book, and the evolution of ebooks technology.

    The different bugs should be corrected.

    Français: Nous avons besoin d’un outil professionnel, fonctionnant et étant supporté 24/7, comme tous les différents sites Wikimedia, par les développeurs professionnels de la fondation Wikimedia. Les différentes anomalies doivent être corrigées.
  • More comments: There are not enough people in a small wiki (even French, Polish or English Wikisource) to support and maintain such a tool.
    Français: Nous ne sommes pas assez nombreux dans les petits wiki (même Wikisource Français, Polonais ou Anglais) pour supporter une telle application.


When it comes to PDF format, mw:Reading/Web/PDF Functionality is probably also related here? --AKlapper (WMF) (talk) 12:46, 7 November 2018 (UTC)[reply]

Yes it is a "related tool" mw:Reading/Web/PDF Functionality is not covering Wsexport features: Wikisource books are split in multiple subpages and Wsexport is able to know automatically which pages should be included and in which order. It also properly attributes the proofreaders of the Page: pages and extract the relevant metadata (e.g. the author is the original author of the work and not the Wikisource contributors).
On the technical side about Wsexport: its codebase is mostly derived from a quick PHP hack and is not able to scale with the current load on the restricted tools labs capacities. A full rewrite is I believe required in order to get this tool in a working state. Tpt (talk) 09:14, 10 November 2018 (UTC)[reply]
+1 we need to increase reading capability. downloading in e-reader format would expand off-line reader base, increasing use-ability. will require some community management. Slowking4 (talk) 22:00, 15 November 2018 (UTC)[reply]

As a writer of science (Mathematics and Physics) books, it is important for me, to be able to extract these books also in odt form. I have already written three books in both forms (wiki and odt) and the additional effort to do this was not exactly sparse. Of course I need the odt Format, in order to be able to change contents according to the needs of my pupils any time, without needing to change the wiki project. If extraction in odt format exists, then it is very easy to make a pdf out of it (the opposite is not exactly so easy). I already tried to create a Star-Basic macro, that should do part of the job, the wiki-programmers can maybe find there ideas for a wiki2odt converter. If this in not possible, a working pdf converter would also suffice... Yomomo (talk) 05:25, 20 November 2018 (UTC)[reply]


Create integrated interwiki mechanism for Wikisource

Français: Créer un mécanisme interwiki intégré spécifique pour Wikisource.
  • Problem: Interwiki mechanism based on a single Wikidata item used in Wikipedia is not suitable for Wikisource. Wikisource can present multiple editions of the same text as well as multiple translations to a single language, eg. made by various translators. The Wikidata model used to store information from Wikisource is two-level, based on "work" and "edition" Wikidata elements. The purpose of this proposal is to create an implementation of link-based interwiki system that used this model and is integrated with MediaWiki.
    Français: Le mécanisme interwiki basé sur un seul élément Wikidata utilisé dans Wikipedia ne convient pas pour Wikisource. Wikisource peut présenter plusieurs éditions du même texte ainsi que plusieurs traductions dans une seule langue, par exemple, fait par divers traducteurs. Le modèle Wikidata utilisé pour stocker les informations de Wikisource est à deux niveaux, basé sur les éléments "travail" et "édition" de Wikidata. Le but de cette proposition est de créer une implémentation du système interwiki basé sur les liens qui utilise ce modèle et qui est intégrée à MediaWiki.
  • Who would benefit: All Wikisources
    Français: Tous les Wikisources
  • Proposed solution: JavaScript based implementation is used in Swedish Wikisource. However, links created using JavaScript are visible only by browsers with JavaScript enabled. If the mechanism is integrated with MediaWiki, the links are available to any HTML parsing tool, eg. indexing machines. Another disadvantage of the Swedish solutiuon is that it needs to be maintained separately by each Wikisource. Wikisource communities are small and have no resources to do this. The suggested solution is to make the links integrated with page's HTML code by MediaWiki.
    Français: L'implémentation basée sur JavaScript est utilisée dans Wikisource suédois. Cependant, les liens créés en utilisant JavaScript sont visible uniquement par les navigateurs avec JavaScript activé. Si le mécanisme est intégré à MediaWiki, les liens sont disponibles pour n’importe quel fichier HTML, outil d'analyse, par exemple, machines d'indexation. Un autre inconvénient de la solution suédoise est qu’il doit être entretenu séparément par chaque Wikisource. Les communautés Wikisource sont petites et n'ont pas ressources pour le faire. La solution suggérée est de faire les liens intégré au code HTML de la page par MediaWiki.
  • More comments: In pre-Wikidata interwiki implementation, multiple interwikis to a single wiki worked fine and were used in Wikisource. So invention of Wikidata became actually a degradation of interwiki system in Wikisources.
    Français: Dans l'implémentation interwiki antérieure à Wikidata, plusieurs interwikis sur un seul wiki fonctionnait bien et était utilisé dans Wikisource. Ainsi, l'invention de Wikidata est devenue en réalité une dégradation du système d'interwiki dans Wikisources.
  • Phabricator tickets: phab:T128173, phab:T180304
  • Proposer: Ankry (talk) 16:04, 10 November 2018 (UTC)[reply]



Diacritics editing tool

Français: Un outil pour plus de diacritiques.
  • Problem: I't difficult and time-consuming to find Unicode for unusual characters and to build characters that have no Unicode (i. e. q̃)
    Français: Il est difficile et fastidieux de rechercher Unicode pour des caractères inhabituels et de créer des caractères sans Unicode ((i. e. q̃)
  • Who would benefit: all wikisource contributors
    Français: Tous les contributeurs wikisource
  • Proposed solution: it's possible to build a gadget to manipulate diacritics only (using standard string normalize property, decompose then compose)
    Français: Il est possible de créer un gadget pour manipuler uniquement les signes diacritiques (à l'aide de la propriété de normalisation de chaîne standard, décomposer puis composer)
  • More comments: A running draft tool to edit diacritics is running into it.wikisource.
    Français: it.wikisource est en train d'élaborer un brouillon pour éditer les signes diacritiques.
  • Phabricator tickets:
  • Proposer: Alex brollo (talk) 09:16, 6 November 2018 (UTC)[reply]


@DChan (WMF): Any thoughts on this idea? Kaldari (talk) 18:38, 8 November 2018 (UTC)[reply]

A tool for Unicode IVS input is probably also good-to-have? C933103 (talk) 08:09, 9 November 2018 (UTC)[reply]
@Kaldari: Hmm, there are many different sets of diacritics, across different scripts. Collecting and maintaining that data would be significant work. On the other hand, we don't want to end up with many versions of this tool with different hard-coded sets of diacritics.
To avoid this extra burden, it may be worth extending the jQuery.IME rules format so that a rule set can specify a list of labelled buttons, each of which performs one of the substitutions in the rule set. In particular, its IPA-SIL rule set already contains a definition of the diacritic substitutions used in the it.wikisource script. DChan (WMF) (talk) 21:18, 20 November 2018 (UTC)[reply]


ProofreadPage extension in alternate namespaces

Français: Utiliser les outils de l'espace page dans d'autres espaces
  • Problem: ProofreadPage elements, such as page numbers, "Source" link in navigation, etc. do not display in namespaces other than mainspace
    Français: Les éléments de l’espace page, tels que les numéros de page, le lien "Source" dans la navigation, etc. ne s'affichent pas dans les espaces de noms autres que l’espace principal.
  • Who would benefit: Wikisources with works in non-mainspace, such as user translations on English Wikisource
    Français: Utilisateurs Wikisource qui font des travaux qui ne sont pas en espace principal, tels que des traductions utilisateur sur Wikisource anglaise
  • Proposed solution: Modify the ProofreadPage extension to allow its use in namespaces other than mainspace
    Français: Modifier l'extension de l'espace page, ProofreadPage, pour permettre son utilisation dans des espaces de noms autres que l’espace principal.
  • More comments: I also proposed this in 2017



Wikisource Contest Tools

Français: Des outils pour concours et championnats.
  • Problem: There are so many tools about Wikipedia online Contest, but there are no tool for Wikisource, where we can judge the proofreading. It will very useful for all wikisource WS:PotM and other Wikisource contests.
    Français: Il existe plusieurs outils sur Wikipédia pour l’organisation de concours en ligne, mais aucun pour Wikisource avec lequel nous pourrions évaluer la correction. Il serait très utile d’en avoir pour les différents concours Wikisource.
  • Who would benefit: Wikisource Community
    Français: La communauté Wikisource
  • Proposed solution: https://tools.wmflabs.org/wscontest/
  • More comments:
  • Phabricator tickets: phab:T163060
  • Proposer: Jayantanth (talk) 09:18, 4 November 2018 (UTC)[reply]


  • I started helping with this at the Hackathon in Barcelona this year, but rather dropped the ball after that (sorry!). It's still on my (volunteer-time) radar, and I'd love to do more with it soon. We also talked about adding these metrics to GrantMetrics, but it's a pretty different system: GM is about metrics per event, this is per-user-and-event. Not that it couldn't be incorporated, but it might not make sense. Certainly things like the "big red button" (T197772) for announcing winners wouldn't be in scope elsewhere I think. Sam Wilson 08:19, 5 November 2018 (UTC)[reply]


Interface to display two (or more) different text from same (or different) wikisource side by side

Français:Interface permettant d'afficher deux (ou plus) textes différents provenant du même (ou différent) wikisource côte à côte
  • Problem:
    1. When a source document is in multiple languages/ancient form of language/alternative script version of a language/follow an alternative orthography/written in another language, it is useful to read the source and a translated-transliterated-modernized version of the text side-by-side, or sometimes even line-by-line.
    Français: Lorsqu'un document source est dans plusieurs langues / forme ancienne de la langue / version de script alternative d'une langue / suit une orthographe alternative / écrit dans une autre langue, il est utile de lire la source et une version traduite-translittérée-modernisée du texte côte à côte, et parfois même ligne par ligne.
    1. Some wiki try to solve the problem by hard-coding source document into different alternative version of a page, and/or having multiple versions of same text inside same page, and that create additional problem of verifiability
    Français: Certains wiki tentent de résoudre le problème en codant en dur le document source dans une version alternative différente d'une page et / ou en utilisant plusieurs versions du même texte dans la même page, ce qui crée un problème supplémentaire de vérifiabilité.
  • Who would benefit: all wikisource users
    Français: Tous les utilisateurs de wikisource.
  • Proposed solution: Create an interface that can allow the display of two (or more) different text from same (or different) wikisource side by side, either by arrangement by editor or by selection by users.
    Français: Créez une interface permettant d’afficher côte à côte deux (ou plus) textes différents provenant du même (ou différent) wikisource, soit par arrangement par éditeur, soit par sélection par les utilisateurs.
  • More comments:
  • Phabricator tickets:
  • Proposer: C933103 (talk) 01:22, 9 November 2018 (UTC)[reply]


@C933103: Isn't this Community Wishlist Survey 2019/Wikisource/Two windows view for editors? Jc86035 (talk) 14:04, 4 November 2018 (UTC)[reply]

@Jc86035: But this is for readers. I mentioned editors because in some cases automatic matching might not work so well and need editor to match and align those documents. C933103 (talk) 20:55, 4 November 2018 (UTC)[reply]

@C933103: On mul.source there is a shared script that does this kind of thing, it's the one called Compare.js. --Candalua (talk) 15:45, 5 November 2018 (UTC)[reply]

@Candalua: I see, that is useful, however there are some limitations to the script that wouldn't cut it when it come to achieving what I want to do:
  1. It requires the user to manually select which international language version would show up, instead of showing a specific language version by default (For instance for a English-French bilingual document, you would want to default it to showing English side by side with French)
  2. It seems like there is an upper limit of displaying up to two documents at a time and cannot display three or four of them together at the same time.
  3. It simply show two different pages side by side, and do not support line-be-line alignment of content of two document.
  4. It seems like the UI is limited to showing documents with interlanguage link and cannot be used to show e.g. alternative version of the document in same wiki.
C933103 (talk) 17:57, 5 November 2018 (UTC)[reply]
Point 4 can be done with a template that emulates interwikis, such as this plus a local script to load the link. Point 3 is a difficult task, that can probably be achieved only by putting line or position markers into every text so that markers can be matched side-by-side. But points 1 & 2 look feasible. It would be great to have such a functionality available by default. --Candalua (talk) 08:47, 7 November 2018 (UTC)[reply]
For point 3, it would only need to put those markers into relevant texts that are desired to have such effect, instead of literally every text. The reason why I am requesting this is that from what I see there are already some different texts on wikisources that have different versions of the same document aligned on the same page line by line using various different layouts. I think it would be easier to handle both as someone who would edit wikisource and also to people who want to copy thing from wikisource if they're separately stored in different pages and then display together than mixing all different versions together within same page. C933103 (talk) 11:35, 7 November 2018 (UTC)[reply]
Point 4 can be also done like this: https://bn.wikisource.org/s/ef54 -- Hrishikes (talk) 07:19, 18 November 2018 (UTC)[reply]


Offer PDF export of original pagination of entire books

Français: Pouvoir exporter en pdf en respectant la pagination de l'édition source.
  • Problem: Presently PDF conversion of proofread wikisource books doesn't mirrors original pagination and page design of original edition, since it comes from ns0 transclusion.
    Français: La conversion en PDF des livres Wikisource ne reflète pas la pagination et le design original des pages de l’édition originale, car la conversion provient de la transclusion et non des pages.
  • Who would benefit: Offline readers.
    Français: Lecteurs hors ligne.
  • Proposed solution: To build an alternative PDF coming from conversion, page for page, of nsPage namespace.
    Français: Élaborer un outil pour générer un PDF alternatif provenant d’une conversion page par page.
  • More comments: Some wikisource contributors think that nsIndex and nsPage are simply "transcription tools"; I think that they are much more - they are the true digitalization of a edition, while ns0 transclusioni is something like a new edition.
    Français: Certains contributeurs de wikisource pense que nsIndex et nsPage sont simplement des « outils de transcription » ; je pense qu’ils sont beaucoup plus que cela – ce sont la vraie numérisation d’une édition, tandis que la transclusion ns0 constitue une nouvelle édition.
  • Phabricator tickets: T179790
  • Proposer: Alex brollo (talk)


  • With the ws-export tool getting error messages many a times it is better to have this functionality in to the default pdf download of the mediawiki. So it would be easy to download the book and associated subpages with it in the correct order. -- Balajijagadesh (talk) 06:48, 11 November 2018 (UTC)[reply]


Better import of descriptions of images with croptool

Français: Mieux importer les descriptions d'images avec l'outil croptool.
  • Problem: many images from wikisuorce books are not correctly or fully categorized and described. I am cross-wiki user so when I crop an image with the croptool on wikisource my efforts rarely stop there. I take care to improve categorization and description and I try to inform users about that. Many cropped images are probably underused because of this aspect, the files on commons lack any information regarding descriptions or categories.
    Français: De nombreuses images de livres wikisource ne sont pas correctement ou entièrement catégorisé et décrit. Je suis un utilisateur multi-wiki alors quand j’extrais et recadre une image avec l'outil « croptool » sur wikisource, mes efforts s'arrêtent rarement là.

    Je prends soin d’améliorer la catégorisation et la description et j’essaie d’informer les utilisateurs à ce sujet. De nombreuses images recadrées sont probablement sous-utilisé à cause de cet aspect, les dossiers sur commons ne possèdent aucune information concernant les descriptions ou les catégories.

  • Who would benefit: People who need to reuse cropped images in the future and should be able to find them.
    Français: Les utilisateurs ayant besoin de réutiliser les images extraites devrait pouvoir les retrouver.
  • Proposed solution: import with croptool the content of the caption of a figure on the commons file description.

    Improving description and categorization is a lot of manual work. I think that at least for the first aspect there is a shortcut. We use Template:FreedImg which contains a "caption" entry. My idea is that when croptool is used and saves an image on commons, it reads the language domain of the current wikisource, placing such iso language code in the description on the file and adding a description in that space based on the first "caption" string going from the "=" to the next vertical bar.

    The only thing I should do as a user is to save the code of the image before cropping, but this is something I already do and it's really not a problem, especially if it saves time later.

    For example in this page I would firstly write the code for the figure (with just plain text in the caption), and than croptool will read "it.wikisource.org" and "caption=tempio di minerva" and place under int:filedesc {{Information |description={{it|tempio di minerva}} ...}}

    This will work at least for the first or single image on a page. I don't mind using it only for the pages with just one image (maybe the caption import can be an option to select), and if it is too complicated at least I hope we can start to think about this issue in the framework of c:commons:structured data in the future because we can't keep uploading thousands of files with such poor descriptions.

    In any case the description line with the iso language code should always be added by croptool even if it is left empty, IMHO.

    Preliminary discussion at itwikisource was supportive of the idea.

    Français: Importer avec croptool le contenu de la légende d'une figure dans la description du fichier des biens communs. Améliorer la description et la catégorisation nécessite beaucoup de travail manuel. Je pense qu'au moins pour le premier aspect il y a un raccourci. Nous utilisons Template: FreedImg qui contient une entrée « légende » ("caption"). Mon idée est que, lorsque croptool est utilisé et enregistre une image sur commons, il lit le domaine de langage du wikisource actuel, en plaçant ce code de langage ISO dans la description du fichier et en ajoutant une description dans cet espace en fonction du premier "libellé" chaîne allant du "=" à la barre verticale suivante.

    La seule chose que je devrais faire en tant qu’utilisateur est de sauvegarder le code de l’image avant de recadrer, mais c’est quelque chose que je fais déjà et c’est vraiment pas un problème, surtout si cela fait gagner du temps plus tard.

    Par exemple, dans cette page, je commencerais par écrire le code de la figure (avec juste du texte en clair dans la légende), et que croptool lira "it.wikisource.org" et "caption = tempio di minerva" et placer sous int:filedesc {{Information |description={{it|tempio di minerva}} ...}}

    Cela fonctionnera au moins pour la première ou une seule image sur une page. Cela ne me dérange pas de l'utilisez que pour les pages avec une seule image (peut-être que l’importation de sous-titres peut être une option à sélectionner), et si c’est trop compliqué au moins j'espère que nous pourrons commencer à réfléchir à cette question dans le cadre de c:commons:structured data à l'avenir car nous ne pouvons pas continuer à télécharger des milliers de fichiers avec de telles descriptions médiocres. Dans tous les cas, la ligne de description avec le code de langue ISO devrait toujours être ajoutée par croptool même s'elle est laissée vide, à mon humble avis.

    Une discussion préliminaire à itwikisource soutient cette idée.

  • More comments:
  • Phabricator tickets:
  • Proposer: Alexmar983 (talk) 18:04, 9 November 2018 (UTC)[reply]


  • Really CropTool is an excellent tool to import book illustrations; the problem is that a book illustration needs a set of metadata and categories very different from the book's one. The main problem is presently that CropTool uploads often a Book template for illustrations, that's completeìy unappropriate (a drawing/a picture is not a book!). I feel that the first step should be, a "translation" of Book template into a simplified and customized Info template. Next steps could be help user in the difficult task of good, and esay, descriptions and categorization. --Alex brollo (talk) 22:45, 9 November 2018 (UTC)[reply]
    Français:CropTool est un excellent outil pour importer des illustrations de livres. Le problème est qu'une illustration de livre nécessite un ensemble de métadonnées et de catégories très différentes de celles du livre. Actuellement, le principal problème est que CropTool télécharge souvent un modèle de livre pour les illustrations, ce qui est totalement inapproprié (un dessin / une image n'est pas un livre!). Je pense que la première étape devrait être une "traduction" du modèle de livre en un modèle d’informations simplifié et personnalisé. Les prochaines étapes pourraient consister à aider l’utilisateur dans la tâche difficile consistant à obtenir de bonnes descriptions et catégorisations.


XTools Edit Counter for Wikisource

Français: Compteur de modifications très amélioré.
  • Problem: There are not wikisource specific stats about user wise Proofread/validation. It is impossible to know stats about proofreading task. Wikisource workflow is different from Wikipedia. It could not be done by xtool. So we need specific Stats tools for Wikisource.
    Français: Il n’existe pas de statistiques spécifiques sur les correction/Validations par utilisateurs. Les processus de travail (workflow) de Wikisource diffèrent de ceux de Wikipédia. Ce ne peux être fait via par xtool. Nous avons besoin d’un outil statistique spécifique pour Wikisource.
  • Who would benefit: Whole Wikisource Community.
    Français: Toute la communauté Wikisource.
  • Proposed solution: Make a stats Tools for Wikisource specific.
    Français: Créer un outil de statistiques spécifiques à Wikisource.
  • More comments:
  • Phabricator tickets: phab:T173012
  • Proposer: Jayantanth (talk) 08:54, 4 November 2018 (UTC)[reply]


  • Just a note: reliable analysis of page proofread status changes would require data from page header which is a part of a specific revision text and not available in the labs database copy, AFAIK. This might be a good question: how to get access to this data eficiently. Ankry (talk) 02:58, 18 November 2018 (UTC)[reply]


Enable book2scroll that works for all Wikisources

Français: Rendre book2scroll accessible sur tous les Wikisource.
  • Problem: book2scroll is not enable for all wikisource and not working for any non -latin wikisource. It is very useful for Page markinn numbering in index: pages any more..
    Français: book2scrool n’est pas activé pour tous les wikisources et ne fonctionne pas sur les wikisources non-latin. Cet outil est très utile pour la numérotation du marquage des Pages dans l’index:page.
  • Who would benefit: Whole Wikisource community.
    Français: Toute la communauté wikisource.
  • Proposed solution: problem is that this code is very old (as in Toolserver-old), and only works with some site naming schemes. Other languages don't work either for many titles.
    Français: Le problème est que le code est très anciens (??? as in Toolserver-old), et ne fonctionne que pour la nomenclature de nommage de certains sites et ne fonctionne pas pour plusieurs titres.
  • More comments:
  • Phabricator tickets: phab:T205549
  • Proposer: Jayantanth (talk) 08:43, 4 November 2018 (UTC)[reply]


I just verified it on en.* and it appears to work fine. Lostinlodos (talk) 01:12, 20 November 2018 (UTC)[reply]

Currently enable for English French German Italian Latin Portuguese Belarusian Bengali and русский. But what about the others languages??
  • Français: Outil actif sur Wikisource Anglais, Français, Allemand, Italien, Latin, Bélarusse, Bengali et ??? Qu’en est-il des autres langues?

Jayantanth (talk) 19:45, 22 November 2018 (UTC)[reply]