Community Wishlist Survey 2019/Wikisource

From Meta, a Wikimedia project coordination wiki
Jump to navigation Jump to search

Community Wishlist Survey 2019

Wikisource
11 proposals, 85 contributors, 209 support votes

Go-previous.svg Wikidata  •  Wiktionary Go-next.svg


ProofreadPage extension in alternate namespaces

Support Edit proposal/discussion

  • Problem: ProofreadPage elements, such as page numbers, "Source" link in navigation, etc. do not display in namespaces other than mainspace
  • Who would benefit: Wikisources with works in non-mainspace, such as user translations on English Wikisource
  • Proposed solution: Modify the ProofreadPage extension to allow its use in namespaces other than mainspace

Discussion

  • I think this might be be useful not only in the Translation namespace but also in the User namespace. Maybe make tha namespace list configurable per wiki? Ankry (talk) 02:37, 18 November 2018 (UTC)

Voting

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

Support Edit proposal/discussion

  • 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.
    2. 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
  • Who would benefit: all wikisource users
  • 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.
  • More comments:
  • Phabricator tickets:
  • Proposer: C933103 (talk) 01:22, 9 November 2018 (UTC)

Discussion

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

@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)

@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)

@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)
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)
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)
Point 4 can be also done like this: https://bn.wikisource.org/s/ef54 -- Hrishikes (talk) 07:19, 18 November 2018 (UTC)

Voting

Better import of descriptions of images with croptool

Support Edit proposal/discussion

  • 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.
  • Who would benefit: People who need to reuse cropped images in the future and should be able to find them.
  • 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.

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

Discussion

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)

Voting

Offer PDF export of original pagination of entire books

Support Edit proposal/discussion

  • 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.
  • Who would benefit: Offline readers.
  • Proposed solution: To build an alternative PDF coming from conversion, page for page, of nsPage namespace.
  • More comments: ome 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.
  • Phabricator tickets: T179790
  • Proposer: Alex brollo (talk)

Discussion

  • 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)

Voting

Create integrated interwiki mechanism for Wikisource

Support Edit proposal/discussion

  • 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.
  • Who would benefit: All 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.
  • 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.
  • Phabricator tickets: phab:T128173, phab:T180304
  • Proposer: Ankry (talk) 16:04, 10 November 2018 (UTC)

Discussion

  • Comment Comment @Tpt: is this linked with T180303 ? --Hsarrazin (talk) 17:25, 18 November 2018 (UTC)
    Yes, except T180303 is about the other projects sidebar and not interlanguage links. But it should be fairly easy to implement if the interlanguage links have been fixed. Tpt (talk) 20:06, 18 November 2018 (UTC)

Voting

Enable book2scroll that works for all Wikisources

Support Edit proposal/discussion

  • 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..
  • Who would benefit: Whole Wikisource community.
  • 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.
  • More comments:
  • Phabricator tickets: phab:T205549
  • Proposer: Jayantanth (talk) 08:43, 4 November 2018 (UTC)

Discussion

Voting

Improve export of electronic books

Support Edit proposal/discussion

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 informations 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.

Discussion

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)

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)
+1 we need to increase reading capability. downloading in e-reader format would expand off-line reader base, increasing use-ability. will require some ommunity management. Slowking4 (talk) 22:00, 15 November 2018 (UTC)

Voting

Wikisource Contest Tools

Support Edit proposal/discussion

  • 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.
  • Who would benefit: Wikisource Community
  • Proposed solution: https://tools.wmflabs.org/wscontest/
  • More comments:
  • Phabricator tickets: phab:T163060
  • Proposer: Jayantanth (talk) 09:18, 4 November 2018 (UTC)

Discussion

  • 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)
  • Without this contest tool it would be difficult to conduct any meaningful ediathon for wikisource. -- Balajijagadesh (talk) 06:49, 11 November 2018 (UTC)

Voting

Ajax editing for nsPage

Support Edit proposal/discussion

  • Problem: The editing into nsPage are much slower than needed - a lot of valuable user time is wasted dealing with "easy" edits.
  • Who would benefit: Many wikisource contributors but the beginners.
  • 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.
  • More comments:
  • Phabricator tickets:

Discussion

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

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)

Voting

Diacritics editing tool

Support Edit proposal/discussion

  • Problem: I't difficult and time-consuming to find Unicode for unusual characters and to build characters that have no Unicode (i. e. q̃)
  • Who would benefit: all wikisource contributors
  • Proposed solution: it's possible to build a gadget to manipulate diacritics only (using standard string normalize property, decompose then compose)
  • More comments: A running draft tool to edit diacritics is running into it.wikisource.
  • Phabricator tickets:
  • Proposer: Alex brollo (talk) 09:16, 6 November 2018 (UTC)

Discussion

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

A tool for Unicode IVS input is probably also good-to-have? C933103 (talk) 08:09, 9 November 2018 (UTC)

Voting

XTools Edit Counter for Wikisource

Support Edit proposal/discussion

  • 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.
  • Who would benefit: Whole Wikisource Community.
  • Proposed solution: Make a stats Tools for Wikisource specific.
  • More comments:
  • Phabricator tickets: phab:T173012
  • Proposer: Jayantanth (talk) 08:54, 4 November 2018 (UTC)

Discussion

  • 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)

Voting