Wikimedia Meta-Wiki

Community Wishlist Survey 2016/Categories/Wikisource

< Community Wishlist Survey 2016
Wikisource
18 proposals, 131 contributors, 228 support votes



Improvement of Phe's Statistics and Tools for Wikisource: vector graphs and a sortable table

  • Problem: Phe's Statistics and Tools for Wikisource are already a very valuable resource, but there are two features that would make it even more useful for a better insight of the activities in many small projects.
  1. Currently pages like this or this are easy to read as far as en.source or fr.source are involved, but the lines showing progress and growth in smaller projects are all flattened on the bottom of the graphs.
  2. The ProofreadPage statistics are ranked by the number of page verifications, but many users would like to read the same tables ranked by other criteria, which currently cannot be done.
  • Who would benefit: any users interested in comparing their growth with their past achievement and with other projects'; projects willing to motivate the effort of their small but working communities.
  • Proposed solution:
  1. Either the graphs could be
    • rendered in svg instead of png to let users magnify them freely and explore their bottom right corner, or
    • split into two graphs for big and small projects with the appropriate proportions in the axis scale (see for example these two graphs).
  2. The ProofreadPage Wikitables could be sortable to let users explore other rankings.
  • More comments: There's no point in the comparison between projects per se, but a fair amount of ambition between small projects has always been a motivating spring to help them grow in quality, encourage proogfreading and so on.
  • Phabricator tickets:
  • Proposer: εΔω 07:51, 15 November 2016 (UTC)

Community discussion

Good ideas but I don't feel it's for the Community Tech team, except if @Phe: need help (do you?). Cdlt, VIGNERON * discut. 09:37, 15 November 2016 (UTC)[reply]
I met Tpt at Wikimania 2016: I explained him this issues and he wrote an email to Phe, but since then we have had no feedback about it. - εΔω 23:43, 15 November 2016 (UTC)

Well I'm not sure who should do that, but I give my small support to this small improvement.--Alexmar983 (talk) 08:47, 17 November 2016 (UTC)[reply]

@OrbiliusMagister: Could you please summarize the actual "a small change for a big improvement" in the task proposal by editing your proposal, so others can immediately spot what is being proposed here? Thanks! :)
  Done - εΔω 22:21, 19 November 2016 (UTC)

Voting – Improvement of Phe's Tools

  1.   Support--Micru (talk) 13:33, 28 November 2016 (UTC)[reply]
  2.   Support plus the tool should show statistics of more wikisource language projects.--Snaevar (talk) 23:16, 28 November 2016 (UTC)[reply]
  3.   Support (for Snaevar: good idea, what language is missing?). Cdlt, VIGNERON * discut. 09:09, 29 November 2016 (UTC)[reply]
    @Phe: ang, bs, cy, fo, ht, is, li, mk, sah, sk, and yi are missing (some are closed like ang or ht :( and most are inactive, but some seems a little bit actives). Cdlt, VIGNERON * discut. 14:28, 29 November 2016 (UTC)[reply]
  4.   Support Obviously... - εΔω 20:45, 1 December 2016 (UTC)
  5.   Support--Jayantanth (talk) 20:57, 4 December 2016 (UTC)[reply]
  6.   Support --Accurimbono (talk) 05:03, 6 December 2016 (UTC)[reply]
  7.   Support --Yann (talk) 22:49, 12 December 2016 (UTC)[reply]

Integrate the CIS-LMU Post Correction Tool

  • Problem: As far as I know (based on my work in deWS) all texts in Wikisources are created either by typewriting, copying and pasting from other sources or from OCR. Mistakes are identified only by proofreading and accordingly the quality of texts are strongly dependent on the individual proofreaders.
  • Who would benefit: All Wikisources that work with OCR.
  • More comments: PoCoTo is a Open-Source-Tool, available on GitHub. It gives the opportunity to identify common OCR-mistakes and handle them easily. It would be probably a big improvement to the quality of texts with one or no proofreaders. Also texts that have been validated two times could systematically looked at for remained mistakes.

Community discussion

none

Voting – Integrate the CIS-LMU Post Correction Tool

  1.   Support Ninovolador (talk) 11:40, 28 November 2016 (UTC)[reply]
  2.   Support Tannertsf (talk) 13:38, 28 November 2016 (UTC)[reply]
  3.   Support --Micru (talk) 16:13, 28 November 2016 (UTC)[reply]
  4.   Support ShakespeareFan00 (talk) 20:56, 29 November 2016 (UTC)[reply]
  5.   Support --Alex brollo (talk) 07:53, 30 November 2016 (UTC)[reply]
  6.   Support - εΔω 20:57, 1 December 2016 (UTC) Whoever has proofread ancient texts understands the importance of this tool.
  7.   Support Libcub (talk) 03:47, 2 December 2016 (UTC)[reply]
  8.   Support Shubha (talk) 10:32, 2 December 2016 (UTC)[reply]
  9.   Support--Jayantanth (talk) 20:57, 4 December 2016 (UTC)[reply]
  10.   Support --Continua Evoluzione (talk) 10:29, 5 December 2016 (UTC)[reply]
  11.   Support Would this circumvent the current roundabout practice of uploading PDFs to Archive.org to get a DJVU which has gone through their OCR? Blue Rasberry (talk) 18:34, 6 December 2016 (UTC)[reply]
  12.   Support --Yann (talk) 22:50, 12 December 2016 (UTC)[reply]

  • Problem: Right now the editions are represented in Wikidata as separate items . See for instance The Raven, there are multiple editions linked with the property "editions". However this is not represented in Wikisource as inter-language links.
  • Who would benefit: All Wikisource editors.
  • Proposed solution: Create a plugin that will aggregate all the edition interwiki links and will display them for each item on Wikisource.
  • Phabricator tickets: T128173
  • Proposer: Micru (talk) 14:06, 8 November 2016 (UTC)[reply]

Community discussion

  Comment the interplay of book <-> edition also needs to be considered as it is a similar problem so that wikisource <-> wikipedia can also be resolved.  — billinghurst sDrewth 16:25, 8 November 2016 (UTC)[reply]

  Comment is this really a technical problem? do we really want all links? (nd just edition or works/exemplar too ? for some works, links can be longer than the text itself, eg. Tales or Bible books like Book of Genesis... for Wikisource <-> Wikipedia links, shouldn't the wikipedia article be linked to the work page on Wikisource (which is actually done I think, and it.ws has an Opera namespace dedicated for that). I wonder if we maybe don't need a whole new system for navigation on Wikisource (similarly the Author: pages done by hand seems a non-sens to me too). Cdlt, VIGNERON * discut. 16:53, 8 November 2016 (UTC)[reply]

  1.   Support JAn Dudík (talk) 22:23, 28 November 2016 (UTC)[reply]
  2.   Support Peter Alberti (talk) 11:23, 3 December 2016 (UTC)[reply]
  3.   Support--Jayantanth (talk) 20:57, 4 December 2016 (UTC)[reply]
  4.   Support -- Sergey kudryavtsev (talk) 07:12, 7 December 2016 (UTC)[reply]
  5.   Support --Yann (talk) 22:51, 12 December 2016 (UTC)[reply]
  6.   Support, I would really like to have this feature so that I do not have to copy interwikis manually to each and every edition — NickK (talk) 23:35, 12 December 2016 (UTC)[reply]

Make Wikisource "book-based"

  • Problem:

Mediawiki on Wikisource is "page-based", but Wikisource is "book-based". In WS, we use:

  • in the main namespace: 1 page for the index, N subpages for the single chapters
  • in the Index namespace: 1 page for the index
  • in the Page namespace: N pages for the pages

Examples:

This division has multiple effect, which have been discussed a lot in the past: see Book_management. In short, this affects:

  • metadata storage
  • import and export of books
  • navigation bars and automatization of task --> thus, steep learning curve for new users
  • statistics are page based, and not book-based: you never know what books are mostly read, you just know which single pages or chapters are.

At the same time, we don't know which books people look for on Wikisource, and what they don't find.

On small projects like Wikisource, it would be possible to experiment and have better analytics regarding books and also users, because numbers are small enough to be manageable. If we knew what

  • Who would benefit:

The community of editors, first, and the community of readers, later. The idea is to have better and more logic framework for Wikisource, which in time will allow better tools, a more easier workflow, and even better analytics for the community so that they understand what's liked and read on WS.

Community discussion

  • @Aubrey: Sounds interesting. I'm still reading through the documentation linked above, so apologies if my questions are answered there — but: how much of proofreadpage would need to change? And with the long-term plan of moving lots of metadata to Wikidata, I'm imagining that this would be mostly about structuring books within MediaWiki (and not so much about describing them); is that right? Sam Wilson 04:59, 17 November 2016 (UTC)[reply]
    • I think that Molly's extension was directed more at the ns0 than the ProofreadExtension. That is because the PE is its own think, and because it's in the ns0 that we need a "logic structure" of a book (meaning: Index, chapters). Of course, and there are hacks from @Alex brollo: in this direction, everything is correlated, and when you create the index in the Index page you can pre-fill the book subpages with the right data... When you have all the "structural metadata" (meaning, number of pages, which page a chapter start, which page the next chapter start, which page is the cover, etc.) you should be able to create automatically everything that use that piece of data. Which means index in the Index page, but also subpages in the ns0 that represent chapters, and also pages index tag (like <pages index="BOOK.djvu" from=544 to=548 />)...
    • These structural metadata will never go on Wikidata, but should be stored in a place that is equal for every Wikisource: at the moment, the Italian wikisource uses Alex tools to do this, which is fine for us but not for everybody else. When you have all the data you can use how you want. Descriptive metadata (author, title, publisher) will go on Wikidata. Aubrey (talk) 10:50, 17 November 2016 (UTC)[reply]

Voting – Make Wikisource "book-based"

  1.   Support--Wesalius (talk) 08:20, 28 November 2016 (UTC)[reply]
  2.   Support --Micru (talk) 16:12, 28 November 2016 (UTC)[reply]
  3.   Support Aubrey (talk) 08:49, 30 November 2016 (UTC)[reply]
  4.   Support--Satdeep Gill (talk) 17:57, 1 December 2016 (UTC)[reply]
  5.   Support NMaia (talk) 00:25, 2 December 2016 (UTC)[reply]
  6.   Support Libcub (talk) 03:48, 2 December 2016 (UTC)[reply]
  7.   Support Shubha (talk) 10:36, 2 December 2016 (UTC)[reply]
  8.   Support Csisc (talk) 10:56, 2 December 2016 (UTC).[reply]
  9.   Support Pamputt (talk) 10:48, 4 December 2016 (UTC)[reply]
  10.   Support--Jayantanth (talk) 20:57, 4 December 2016 (UTC)[reply]
  11.   Support--Alexmar983 (talk) 08:51, 8 December 2016 (UTC)[reply]
  12.   Support - DPdH (talk) 12:14, 12 December 2016 (UTC)[reply]

Semi-automated tool for importing Wikisource data from standard header template into Wikidata items

  • Problem: importing data from wikisource pages (especially transcluded pages with complete header) is very painful, while all informations are present in the header = title, author, date, publisher, pages, and for articles Periodical data and pages, + the scanned file info. A tool, allowing to automatically import those data in wikidata empty items (thousands have been imported by bots, without bothering to complete them).
  • Who would benefit: both wikidata and wikisource communities, because wikidata info for wikisource texts would be much more complete. A semi-automated tool, launchable individually on each item, would allow to complete items that need it, and control data, which a bot would not allow.
  • Proposed solution: a tool/script/gadget that would import available header data from the standard header template. @Tpt:

Community discussion

  • @Hsarrazin: I think the crucial part of this is not so much importing the data to Wikidata (which I agree is a great idea) but rather using Wikidata data back in Wikisource. If the header template were to use Wikidata more, then Wikisourcerors would keep it up to date and correct. (Really, we shouldn't have to enter the same metadata in the header template, the Index page, and the file description on Commons!) Sam Wilson 00:59, 15 November 2016 (UTC)[reply]
    For the header template vs Index page duplication there is the header=1 feature of the <pages> tags (we use it a lot on French Wikisource). For duplication between Wikidata and Wikisource, it's just a matter of using mw.wikibase API in Lua gadget (and hopefully the same process will be usable when Commons file will use Wikibase-based metadata storage). Tpt (talk) 09:44, 18 November 2016 (UTC)[reply]
    I would hope that we would be able to pull the information from Commons {{book}} or {{header}} as generally Commons is the first upload place, and header template for where the work is not scan supported.  — billinghurst sDrewth 12:55, 3 December 2016 (UTC)[reply]

Voting – Semi-automated tool for importing Wikisource data

  1.   Support--Wesalius (talk) 08:20, 28 November 2016 (UTC)[reply]
  2.   Support --Micru (talk) 16:14, 28 November 2016 (UTC)[reply]
  3.   Support Aubrey (talk) 08:49, 30 November 2016 (UTC)[reply]
  4.   Support Ankry (talk) 23:20, 1 December 2016 (UTC)[reply]
  5.   Support as this will surely let implementing Open Citations corpus in Wikidata easier Csisc (talk) 10:57, 2 December 2016 (UTC).[reply]
  6.   Support Peter Alberti (talk) 11:26, 3 December 2016 (UTC)[reply]
  7.   Support no brainer for value for WSes and WD  — billinghurst sDrewth 12:55, 3 December 2016 (UTC)[reply]
  8.   Support--Jayantanth (talk) 20:57, 4 December 2016 (UTC)[reply]
  9.   Support Risker (talk) 03:12, 9 December 2016 (UTC)[reply]
  10.   Support --Edhral 08:40, 10 December 2016 (UTC)[reply]

Spelling- and typo-checking system for proofreading

  • Problem:
    When proofreading using ProofreadPage, there is no syntax highlighting or spell-checking (other than what may be native to the web browser). This makes it hard to see typos, scannos, mis-spellings, and other problems. A font that makes greater distinctions between characters, such as WikisourceMono, can help; but it's still hard to proofread things like punctuation (e.g. new line characters where they occur within a paragraph) or archaic spellings of words (e.g. "to-day" spelt with a hyphen).
  • Who would benefit:
    1. Wikisource readers, because the texts they view will be of higher quality; and
    2. Proofreaders, because they will catch errors earlier in the proofreading cycle, and have to revisit fewer pages.
  • Proposed solution:
    A tool akin to Distributed Proofreaders' WordCheck tool, which would implement site-wide and per-work word lists against which pages could be checked. In PGDP, this checking happens as what we call the 'preview' stage (i.e. it's optional, but its use is encouraged), when the user is presented with a colour-coded display of the text.
    All punctuation characters are highlighted (just for easier viewing), and every word that doesn't exist in a 'Good word list' (or does exist in a 'Bad word list') is shown in an editable text field. The user can then correct the word, or elect to add it to one of the work's word lists. The punctuation highlighting would include paragraph marks (currently some people use the pilcrowMarkers gadget) and whitespace.
  • More comments:
    • The punctuation-highlighting aspects of this wish could be satisfied by a syntax-highlighting editor (but such a thing would have to be customisable, for example some works enforce spaces around dashes, and some prohibit them).
    • The word-correcting UI could appear in a page's preview (although it may also be good to be able to view it applied to the actual wikitext as well), and it might be useful to be able to enable it when just reading a Page namespace page.
    • The per-work word lists could be able to be copied from other works (or some sort of word list library). Although, copy and paste works for this too.
    • It should be easy to get a report of a whole work's wordcheck status (although, another approach to this could be to have the word-fix UI able to be turned on in Main namespace, or anywhere Page pages are transcluded).
    • If a word is in a Bad word list, it should be easy to replace all occurrences throughout a work (although, there's value in going the traditional per-page route, because it could be that not all occurrences are actually the same misspelling).
    • The PGDP source code is PHP/MySQL, GPL-2.0, and hosted on Sourceforge.
  • Phabricator tickets:

Community discussion

  Comment
How do they manage proper English vs. American English words?
There was an earlier discussion about having an Index: page level setting or typing error correction as the OCR for a work can have reproducible errors that could be applied. Having something like Index:workname.djvu/Badwords  — billinghurst sDrewth 15:58, 8 November 2016 (UTC)[reply]

Yes, PGDP has per-work wordlists (which, as you say, would probably be well off stored as /goodwords and /badwords or something under each Index page). This means that UK-spelling works would have US spellings in the badwords, and vice versa for US works (or 19th century vs modern, e.g. "to-day" is correct but "today" is not). I'm not sure about the idea of mass-applying fixes over a whole work—but certainly mass-reporting on misspellings would be brilliant. I'm also not sure about how to manage puntuation fixes (e.g. highlighting when someone's done a spaced em dash, or has a mid-paragraph line break); but maybe that's beyond this wordlist idea? Sam Wilson 22:05, 8 November 2016 (UTC)[reply]
Start with the framework IMNSHO, it can expand after that. Maybe phase 1 is to get the "words" pages framework set up, to do the matches in phase 1, then phase 2 is to build the regex replacer (I note something like w:Wikipedia:AutoWikiBrowser/Typos which Reedy (talk · contribs) built may be a useful model, and our required complexity is way less than that. user:Pathoschild has done some work in the area with m:TemplateScript maybe he can contibute his knowledge to this idea.)

We all know a good series of bad OCR that regularly comes through that I would happily have corrected as the page is loaded for the first time. After 20pp of a work (and s:Index:A biographical dictionary of eminent Scotsmen, vol 1.djvu is a typical example) there are 20-30 reproducible bad OCRs \bAvas\b -> was is so familiar to me from many works.  — billinghurst sDrewth 10:07, 10 November 2016 (UTC)[reply]

  Comment At WS, we "faithfully transcribe" original source texts. Therefore, addressing OCR errors is one thing, but misspellings and archaic spellings that appear in the original text should usually remain after transcription. Such a tool may confuse a new user who is prompted to make a change that shouldn't be made. Also, a spelling and typo checker may create a dependency on the tool by users, assuming that a "clean" page means all is well when other errors may be lurking. Just as many errors may be found in the end. Nothing beats old-fashioned proofreading letter-by-letter, word-by-word, line-by-line, in my opinion. Londonjackbooks (talk) 11:05, 7 December 2016 (UTC)[reply]

Voting – Spelling and typo checking

  1.   Support--Wesalius (talk) 08:21, 28 November 2016 (UTC)[reply]
  2.   Support Tannertsf (talk) 13:39, 28 November 2016 (UTC)[reply]
  3.   Support --Micru (talk) 16:14, 28 November 2016 (UTC)[reply]
  4.   Support --Alex brollo (talk) 07:54, 30 November 2016 (UTC)[reply]
  5.   Support --ShakespeareFan00 (talk) 10:28, 1 December 2016 (UTC)[reply]
  6.   Support — The preceding unsigned comment was added by Satdeep Gill (talk)
  7.   Support - εΔω 20:46, 1 December 2016 (UTC)
  8.   Support NMaia (talk) 00:15, 2 December 2016 (UTC)[reply]
  9.   Support Libcub (talk) 03:42, 2 December 2016 (UTC)[reply]
  10.   Support--Jayantanth (talk) 20:57, 4 December 2016 (UTC)[reply]
  11.   Support --Continua Evoluzione (talk) 10:32, 5 December 2016 (UTC)[reply]
  12.   Support - DPdH (talk) 12:18, 12 December 2016 (UTC)[reply]

Support Open Archives Initiative Protocol for Metadata Harvesting (OAI-PMH)

  • Problem: GLAM partners are reluctant to add material to Wikisource because (among other reasons) it's hard to incorporate back into their own catalogues.
  • Who would benefit: GLAM partners and their users (who would also thus be exposed to Wikisource, and might think it's great)
  • Proposed solution: Support the Open Archives Initiative Protocol for Metadata Harvesting (OAI-PMH).
  • More comments: This idea has been around for a long time (the ticket below dates from 2004) so I'm sure there's lots of back-story that I don't know! :-)

    One crucial part of it as it relates to Wikisource is that it's possible for OAI-PMH consumers to specify certain search criteria (such as a particular collection, or category, or author, etc.) when they only want to harvest those works.

    For example, the National Library of Australia's Trove system could harvest all Wikisource material relating to or originating in Australia, and then any library user would see Wikisource items in their search results.

Community discussion

  • Great idea Samwilson (I have an exemple with my local library tablettes-rennaises.fr/ with OAI-PMH, books in PD licence and metadata in CC0, everything perfect except I don't have the tools and I don't really know OAI-PMH), shouldn't the support be with/for Wikidata too ? Cdlt, VIGNERON * discut. 16:55, 14 November 2016 (UTC)[reply]
    • @VIGNERON: Absolutely! Good point... really, we should aim at not having metadata in Wikisource at all (one day). So do you think this proposal should just target Wikidata? If it did, it would give Wikisource another reason to shift in that direction—but it could delay making it a reality for Wikisource works too. Sam Wilson 00:41, 15 November 2016 (UTC)[reply]
      • @Samwilson: not sure if we should target Wikidata only... I'm too aiming for having all (meta)data stored into Wikidata but I know it will take quite a long time (even a simple thing as just converting the Author template to Wikidata on frws took almost year and people are still not use to it). So, targeting only Wikidata is still a good idea but it's probably too early as it seems too pushy right now ; tldr; still unsure. Cdlt, VIGNERON * discut. 09:51, 15 November 2016 (UTC)[reply]
        • Hm, yes good point @VIGNERON. I've been writing a scraper for WS that could be a useful interface, and that could be updated as data is moved to WD without the core PMH system having to change along with it. So yeah, let's say this is just for going direct from Wikisource for now. Sam Wilson 00:02, 16 November 2016 (UTC)[reply]
          • From what I understand about this problem, we should completely refactor the whole metadata system in Wikisource. It's a daunting task, but very important. In fact, we already have a OAI-PMH tool for Index pages, it was made (of course!) by @Tpt: https://it.wikisource.org/wiki/Speciale:ProofreadIndexOai
The point is, as you two wrote up here, that we need our data in a place with a good metadata system and good API. I think Wikidata is definitely good enough, so the goal, IMHO, should be "importing all the WS metadata in Wikidata". As you know, this means several things:
  • agreeing on a good bibliographic model on Wikidata
  • make it compatible with the bibliographic model in Commons (because they will have their own thing)
  • creating a very good scraper for different WS
  • importing data on WD
  • creating good documentations for GLAMs and Wikidata, for importing and exporting
Mind you: this could also mean rethinking and refactoring Wikisource "data model", Proofread extension, and other things. Meaning that We are always patching up and building on existing patches and hacks on Wikisource, but the whole project could enjoy that some good professionals look at the thing from scratch and decide if things are good enough or there is some code to be written or changed. I'm saying all this because my fear is that we try always to do small new tools on top of each other, when what we need is good, old-fashioned but serious code/system review. Aubrey (talk) 08:22, 16 November 2016 (UTC)[reply]
I strongly support Aubrey's comment. We definitely need to seat down and find a good metadata management workflow before creating more tools. It will allow us to have a clear vision of what is needed and which tool create. I have tried a few years ago to start such work. See mw:User:Tpt/RFC (most part of it have been written in 2013). Tpt (talk) 09:58, 18 November 2016 (UTC)[reply]

Voting – Support Open Archives Initiative Protocol

  1.   Support--Shizhao (talk) 03:20, 28 November 2016 (UTC)[reply]
  2.   Support--Wesalius (talk) 08:21, 28 November 2016 (UTC)[reply]
  3.   Support--Micru (talk) 13:32, 28 November 2016 (UTC)[reply]
  4.   Support Sadads (talk) 15:01, 28 November 2016 (UTC)[reply]
  5.   Support --Izno (talk) 01:33, 29 November 2016 (UTC)[reply]
  6.   Support VIGNERON * discut. 09:14, 29 November 2016 (UTC)[reply]
  7.   Support --Ernest-Mtl (talk) 17:56, 29 November 2016 (UTC) (BAnQ's national collection archivists and librarians have been dreaming of this for over 2 years! lol)[reply]
  8. My   Support is not actually related to the OAI-MPH (there is ***already*** such a tool, see my comment above) but for a rethinked-refactored metadata workflow. A simple tool won't solve the real issue (the moment you work a bit on this you will understand what I mean). We discussed a lot about this, we just need to focus on doing it. Aubrey (talk) 08:56, 30 November 2016 (UTC)[reply]
  9.   Support - εΔω 20:47, 1 December 2016 (UTC)
  10.   Support NMaia (talk) 00:15, 2 December 2016 (UTC)[reply]
  11.   Support Libcub (talk) 03:43, 2 December 2016 (UTC)[reply]
  12.   Support Pamputt (talk) 10:49, 4 December 2016 (UTC)[reply]
  13.   Support--Jayantanth (talk) 20:57, 4 December 2016 (UTC)[reply]
  14.   Support --HHill (talk) 11:04, 5 December 2016 (UTC)[reply]
  15.   Support Risker (talk) 03:13, 9 December 2016 (UTC)[reply]
  16.   Support  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  18:24, 11 December 2016 (UTC)[reply]
  17.   Support --Yann (talk) 22:57, 12 December 2016 (UTC)[reply]

Upload Wikisource text wizard

  • Problem: The text upload process is complex across many projects.
  • Who would benefit: Uploaders
  • Proposed solution: Create a wizard that includes the upload text process - search Internet Archive, use IA uploader to commons, set index at Wikisource to match Commons, adjust 'page offset' on index page.

Community discussion

  • By "adjust page offset" I assume you mean setting up the pagelist on the Index page? If so, I reckon that in itself could be a great project: a wizard for easier matching up of scan pages to work page numbers. Could be a great thing to gamify with a simple mobile interface for asking users to identify what page number a given page is; it could figure out the progression from the answers. (Maybe.)

    Also, this is about the workflow of uploading works' Djvu & PDF files isn't it? (For the benefit of non-wikisourcerers who are reading: the 'text' in this case is a book or other work containing text, not just "uploading wikitext".) —Sam Wilson 03:37, 8 November 2016 (UTC)[reply]

    @Samwilson: using the existing Book2Scroll tool on enWS index pages allows all users to see page numbering and gaps, images etc. Maybe we can work off that tool to mark pages and have that feedback the data to the <pagelist>  — billinghurst sDrewth 15:58, 8 November 2016 (UTC)[reply]
    yes, i do index pages the hard way, but an easier way would be appreciated. it is for the total process redesign, including dejavu conversion, of scanned text layers. there are a lot of steps with a lot of custom tweaking required. Slowking4 (talk) 12:18, 9 November 2016 (UTC)[reply]
    @Billinghurst: Good point about using book2scroll; it's certainly the sort of interface we'd want for page-number-correlation. And @Slowking4: Every time I recommend to someone that they add something to Wikisource, I'm reminded of quite how many steps there are! It'd be terrific to have a most-common-workflow wizard: from a pile of scan files (or a IA identifier) through to a correctly-constructed Index page. Is this what you're envisaging? Sam Wilson 04:42, 10 November 2016 (UTC)[reply]
  • Good idea --Wesalius (talk) 07:28, 8 November 2016 (UTC)[reply]
  • Good idea --Jayantanth (talk) 11:14, 8 November 2016 (UTC)[reply]
  • Good idea VIGNERON * discut. 14:25, 8 November 2016 (UTC)[reply]
  • We need a tool which can create DjVu files and OCRs, since IA doesn't do DjVu anymore. In short, to replace or improve BuB. Yann (talk) 15:55, 8 November 2016 (UTC)[reply]
  • As an occasional contributor to Italian Wikisource I agree that we need some kind of wizard to make it easier. --Jaqen (talk) 15:45, 16 November 2016 (UTC)[reply]

Voting – Upload Wikisource text wizard

  1.   Support--Shizhao (talk) 03:21, 28 November 2016 (UTC)[reply]
  2.   Support--Wesalius (talk) 08:21, 28 November 2016 (UTC)[reply]
  3.   Support--Micru (talk) 13:34, 28 November 2016 (UTC)[reply]
  4.   Support Tannertsf (talk) 13:39, 28 November 2016 (UTC)[reply]
  5.   Support very important for new contributor support, Sadads (talk) 15:02, 28 November 2016 (UTC)[reply]
  6.   Support --Consulnico (talk) 17:50, 28 November 2016 (UTC)[reply]
  7.   Support --Snaevar (talk) 23:18, 28 November 2016 (UTC)[reply]
  8.   Support John Carter (talk) 23:41, 28 November 2016 (UTC)[reply]
  9.   Support VIGNERON * discut. 09:14, 29 November 2016 (UTC)[reply]
  10.   Support a real wizard, with good quality djvu encoding, could merge existing tools and provide a real improvement to the existing workflow. I think we have all the pieces: we need to join them and make a powerful and simple tool for everyone. Aubrey (talk) 08:59, 30 November 2016 (UTC)[reply]
  11.   Support Trizek from FR 20:02, 30 November 2016 (UTC)[reply]
  12.   Support NMaia (talk) 00:16, 2 December 2016 (UTC)[reply]
  13.   Support Shubha (talk) 10:16, 2 December 2016 (UTC)[reply]
  14.   Support Pamputt (talk) 10:49, 4 December 2016 (UTC)[reply]
  15.   Support--Jayantanth (talk) 20:57, 4 December 2016 (UTC)[reply]
  16.   Support Sadads (talk) 18:45, 6 December 2016 (UTC)[reply]
  17.   Support — Nala Discuter 10:30, 7 December 2016 (UTC)
  18.   Support --Edhral 07:26, 8 December 2016 (UTC)[reply]
  19.   Support Weft (talk) 07:55, 8 December 2016 (UTC)[reply]
  20.   Support Risker (talk) 03:07, 9 December 2016 (UTC)[reply]
  21.   Support - DPdH (talk) 12:22, 12 December 2016 (UTC)[reply]
  22.   Support --Yann (talk) 22:54, 12 December 2016 (UTC)[reply]
  23.   Support — NickK (talk) 23:37, 12 December 2016 (UTC)[reply]

Visual Editor menu refresh

  • Problem: the visual editor menus could be refreshed, and improved
  • Who would benefit: new editors on wikisource
  • Proposed solution: redesign menus based on survey of workflows of most used functions, and editor feedback - do UX design.
    • for example - in page view under style text menu, you need a small caps, and larger and smaller text should be higher than strikethru or subscript ; you need an easy way to insert common templates such as running header
    • & in article view you need to move insert pages up and insert media down ; you need an easy way to insert common header templates such as EB1911 or NIE.
  • Phabricator tickets:
  • Proposer: Slowking4 (talk) 02:16, 8 November 2016 (UTC)[reply]
  • Translations: none yet

Community discussion

@Slowking4: This proposal welcomes a better problem description: What exactly you would like to achieve, and why it is currently hard or impossible to perform your work, given the current visual editor menu. "Could be more helpful" is not a problem but a solution. :) --AKlapper (WMF) (talk) 10:26, 8 November 2016 (UTC)[reply]

  • i would like to see menu redesign based on wikisource workflow and editor feedback, not on a wikipedia default. to the extent menus are not useful, then editors switch to wikicode to get work done. have you actually used VE to insert or edit a page header, because i cannot - it looks impossible to me. i also gave you four examples, to change the existing menus. or you could make the drop down menus customizable by editor. Slowking4 (talk) 19:46, 8 November 2016 (UTC)[reply]
  • It's already possible to add custom/local buttons; see mw:VisualEditor/Gadgets. I don't believe that it's currently possible re-arrange the order of items in the character formatting menu.
    Inserting a running header is possible now. You just need to go to Insert > Template and put in {{RunningHeader|left=LEFT|center=CENTRE|right=RIGHT}}. You should use the parameter names. It would be much quicker to do if the template had mw:TemplateData documentation, but it's possible now. Whatamidoing (WMF) (talk) 17:04, 2 December 2016 (UTC)[reply]

Voting – Visual Editor menu refresh

Add a 'clean' method for side-titles, and side notes to parser

The current approaches to this are not necessarily ideal, and do not necessarily render in a manner that is consistent across differing "media" formats (such as mobile), or even namespace displays at Wikisource.
  • Who would benefit: Transcribers and proofreaders at Wikisource.
  • Proposed solution:
    1. Implement an inline <sidenote></sidenote> tag pair that can be used to mark a sidenote directly to the parser.
    2. Implement a back end to process the "sidenotes", such that they are rendered using a manner consistent with the media format concerned.
    (a) For desktop and 'print', the sidenotes should be rendered as classed layout block to the appropriate side of the main content, taking into account the side 'swapping' may be be required when transcluded to Main/Article namespace. The reason for the block being classed is so that it can be style defined per work or even per page as required. (ie. left align and right align accordingly in Page: namespace, and either left or right align when transcluded to main namespace)
    (b) For 'mobile', the sidenotes could ideally be converted into either <ref></ref> pairs automatically (in an appropriate group) and rendered at the end of the document in a suitable formatable block. For sidetitles, which typically appear at the start of a paragraph, conversion of these into paragraph leaders (as suggested in the commennts) is another possible solution.

Community discussion

See Bible (King James Version, 1611)/Genesis for a current example. Kaldari (talk) 18:41, 7 November 2016 (UTC)[reply]

yes, sidenotes are a major headache stopping work on documents with them. current practice uses template:sidenote. Slowking4 (talk) 02:20, 8 November 2016 (UTC)[reply]

  Comment
Part of the issue is to also get the sidenotes to work well with the different page layouts.
For mobile version it may be more appropriate to place sidenotes as paragraph leaders rather than treat as references. Putting them as end notes does not seem to be the best solution.
Another issue is avoiding the overlapping display of sidenotes.  — billinghurst sDrewth 15:46, 8 November 2016 (UTC)[reply]

Voting – Add a 'clean' method for side-titles

  1.   Support--Wesalius (talk) 08:21, 28 November 2016 (UTC)[reply]
  2.   Support Tannertsf (talk) 13:40, 28 November 2016 (UTC)[reply]
  3.   Support--Jayantanth (talk) 20:57, 4 December 2016 (UTC)[reply]

Add simple filters to Danmichaelo's CropTool

  • Problem: CropTool by Danmichaelo (c:Commons:CropTool, and at Github) presently does an excellent job for wikisource users too, since it can retail nsPage images from multipage books, djvu and pdf, so simplifying a lot a difficult step of nsPage formatting. It would be great to add to it some filters and tools (rotation, grey and BW conversion, background removal) to enhance image quality.
  • Who would benefit: all contributors
  • Proposed solution: to implement an optional canvas environment with simple tools
  • Phabricator tickets:

Community discussion

  Comment giving crop the ability to remove and replace the first page of a djvu/pdf would have value for all the Commonists who complain about the scans opening with a Google text page (and whine about copyright).  — billinghurst sDrewth 22:32, 23 November 2016 (UTC)[reply]

A good standard to replace the Google front image could be, to replace it with a copy of title page of the book, coming from the djvu/pdf itself. The only parameter to give to a bot would be, the djvu/pdf page number of title page. --Alex brollo (talk) 19:40, 24 November 2016 (UTC)[reply]

Voting – Add simple filters

  1.   Support Ninovolador (talk) 11:40, 28 November 2016 (UTC)[reply]
  2.   Support--Alexmar983 (talk) 17:32, 28 November 2016 (UTC)[reply]
  3.   Support --Alex brollo (talk) 09:56, 30 November 2016 (UTC)[reply]
  4.   Support - εΔω 20:49, 1 December 2016 (UTC)
  5.   Support NMaia (talk) 00:17, 2 December 2016 (UTC)[reply]
  6.   Support Shubha (talk) 10:23, 2 December 2016 (UTC)[reply]
  7.   Support--Jayantanth (talk) 20:57, 4 December 2016 (UTC)[reply]
  8.   Support --Edhral 07:31, 8 December 2016 (UTC)[reply]
  9.   Support Risker (talk) 03:08, 9 December 2016 (UTC)[reply]
  10.   Support--Nizil Shah (talk) 06:29, 10 December 2016 (UTC)[reply]

AJAX editing of nsPage content

  • Problem: Opening and saving nsPage pages is slow
  • Who would benefit: Experienced contributors
  • Proposed solution: Experienced contributors edit usually a series of pages in their natural order, often with minimal changes and using the same browser environment (same tools, same nsIndex....). This job can be done by ajax API with no need of re-upload and re-compile the complex browser environment, it only needs to get text, image and some data of new page, to save edits and to get immediately the next page without leaving the edit mode. Tests are running into it.source by the tool Edit in Sequence.
  • Phabricator tickets:

Community discussion

THIS is actually a super great idea!! Specially with slow internet connections, that have to reload over and over again the same UI elements, and, in my case at least, not always all the javascripts are loaded, so i need to reload the page a few times to start working. --Ninovolador (talk) 13:09, 19 November 2016 (UTC)[reply]

Voting – AJAX editing of nsPage content

  1.   Support Ninovolador (talk) 11:39, 28 November 2016 (UTC)[reply]
  2.   Support Reptilien.19831209BE1 (talk) 14:40, 28 November 2016 (UTC)[reply]
  3.   Support --Alex brollo (talk) 09:57, 30 November 2016 (UTC)[reply]
  4.   Support Shubha (talk) 10:24, 2 December 2016 (UTC)[reply]
  5.   Support Omino di carta (talk) 12:25, 3 December 2016 (UTC)[reply]
  6.   Support--Jayantanth (talk) 20:57, 4 December 2016 (UTC)[reply]

Allow Wikisource pages to be cited correctly

  • Problem: Cite this page produces incorrect citation -

Example see this page - https://en.wikisource.org/wiki/Malthus,_Thomas_Robert_(DNB00) Cite-this-page gives (APA and MLA styles):

What it should actually cite:

It would be good if the page actually has embedded COinS metadata that can be set by editors - so that anyone can cite it correctly using the visual editor.

  • Who would benefit: Editors who understand referencing
  • Proposed solution:

Perhaps having page variables would work so that the Cite-This-Page extracts data from manually set values.

Community discussion

We have a gadget like that on French Wikisource. See the citer le texte button. Tpt (talk) 09:46, 18 November 2016 (UTC)[reply]

 Y Awesome, exactly, I just checked and it's something other language Wikisources ought to have. Shyamal (talk) 06:47, 23 November 2016 (UTC)[reply]
The js code has been installed in Bengali Wikisource. -- Bodhisattwa (talk) 06:58, 7 December 2016 (UTC)[reply]

Voting – Allow Wikisource pages to be cited correctly

  1.   Support making the citer le texte button available to all other wikisource projects. --Wesalius (talk) 08:03, 28 November 2016 (UTC)[reply]
  2.   Support — The preceding unsigned comment was added by FocalPoint (talk)
  3.   Support --R. S. Shaw (talk) 17:20, 9 December 2016 (UTC)[reply]
  4.   Oppose As noted above, this already exists; all wikis have to do is install and localize it. It's not a WMF dev job.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  18:26, 11 December 2016 (UTC)[reply]

Automated reader's portal

  • Problem: For readers it is hard to get an easy overview of the works that are available for reading from Wikisource.
  • Who would benefit: Visitors mostly.
  • Phabricator tickets:

Community discussion

none

Voting – Automated reader's portal

  1.   Support--Wesalius (talk) 08:20, 28 November 2016 (UTC)[reply]
  2.   Support (ping Ernest-Mtl ;) ) VIGNERON * discut. 09:16, 29 November 2016 (UTC)[reply]
  3.   Support --Ernest-Mtl (talk) 17:52, 29 November 2016 (UTC)[reply]
  4.   Support I wish we had something as good for commons media... but wikisource is a good start in the direction.--Alexmar983 (talk) 06:16, 30 November 2016 (UTC)[reply]
  5.   Support --Alex brollo (talk) 07:50, 30 November 2016 (UTC)[reply]
  6.   Support Aubrey (talk) 09:00, 30 November 2016 (UTC)[reply]
  7.   Support - εΔω 20:51, 1 December 2016 (UTC)
  8.   Support Jberkel (talk) 22:23, 1 December 2016 (UTC)[reply]
  9.   Support Libcub (talk) 03:45, 2 December 2016 (UTC)[reply]
  10.   Support Shubha (talk) 10:26, 2 December 2016 (UTC)[reply]
  11.   Support Peter Alberti (talk) 11:21, 3 December 2016 (UTC)[reply]
  12.   Support--Jayantanth (talk) 20:57, 4 December 2016 (UTC)[reply]
  13.   Support --Continua Evoluzione (talk) 10:34, 5 December 2016 (UTC)[reply]
  14.   Support --Edhral 06:23, 9 December 2016 (UTC)[reply]
  15.   Support --Francois C (talk) 15:11, 10 December 2016 (UTC)[reply]
  16.   Support -- Sometimes I've got a feeling that Wikisource are even less friendly for readers than for edithors Plogeo (talk) 19:29, 10 December 2016 (UTC)[reply]
  17.   Support --NaBUru38 (talk)
  18.   Support - DPdH (talk) 12:23, 12 December 2016 (UTC)[reply]
  19.   Support --Yann (talk) 22:57, 12 December 2016 (UTC)[reply]
  20.   Support — NickK (talk) 23:38, 12 December 2016 (UTC)[reply]

Create new Han Characters with IDS extension for WikiSource

於維基文庫上利用IDS描述新造漢字

  • Problem:
    • en-Han-character (en:logogram, include en:Chinese Characters, en:Hanja, and en:Kanji)- is widely used in East Asia (China, Taiwan, Singapore, Mandarin area in Malaysia, HongKong, Japan, Korea, Taiwan and Vietnam). An enduring problem unsolved for digital archiving is "lacking of characters". Not only for characters in ancient books, even modern publications lacks for characters ( i.e. Some authors may created 300-400 unique new characters in certain books). It's difficult to deal when we archive them into WikiSource. Unicode gradually add new characters into the chart, but new Uni-han extension always takes time to go live. In the past WikiSource,even Wikipedia, used to deal this problem with image files to present those characters. But images cannot be indexed, unsearchable, even not exchangeable between computer systems.
    • zh-東亞文化圈的CJKV（中國、台灣、新加坡、馬來西亞華語區、香港、日本、韓國、台灣、越南）許多地方使用漢字（更正式的名稱是「zh:語素文字」），在電腦數位文獻處理上，一直有一個大問題，就是漢字缺字問題（lacking），不單單是各國古代漢字文獻有大量缺字，近代傳統活字排版印刷時代的書籍還有各自自創的缺字（有時可能是只有某一本書，就獨特地出現了300-400個該書獨有發明的新字），當要放進維基文庫的時候，處理此問題非常地困難。這個問題的本質是漢字過去在電腦上的處理未考慮到漢字是個開放字集的事實。當今維基媒體計畫上如果有尚未被unicode所支援的方塊字，現在只有一種解決辦法，就是使用圖檔，問題是必須手工繪製而且該文字的資訊無法被排序（indexing）、搜尋（search）、交換（exchange ，copy paste到別的網站，圖片就消失了，文章裡面的缺字就變成空白）。
  • Who would benefit:
      1. en-Mostly the contributors and readers of Chinese Wikisource. However, if this way is available, all Wikimedia projects in languages that use Han characters will be benefited. (such as Japanese, Vietnamese, Korean, and Chinese dialects version like Classical Chinese, Hakka, Wu, or Gan., )
      2. Further more, even Wikipedia (Zh Wikipedia already used a lot of lacking characters,now .) and Wiktionary also are benefited.
      3. Other 2D composite characters writing system: For instance, Ancient Egypt and Maya.
    • zh-最主要會受到益處的，是中文維基文庫的編者與讀者，但使用漢字的維基媒體計畫將來都可以受益（如日文、越南文、韓文、中文、文言文、客家語、吳語、贛語等），甚至未來其他語言的維基辭典、維基百科。
  • Proposed solution:
    • en-Unicode IDS -Ideographic Description Sequence- defined how to composite Han character with components. We implement the function to dynamically render Han character with Ideographic Description Sequences(IDS) and extension in WikiSource like: <ids>⿺辶⿴宀⿱珤⿰隹⿰貝招</ids> It will generate a Han character image file(now rendered on the temporary server on wmflabs ) with IDS in metadata. This is a solution to resolve lacking of Han characters problem on all C/J/K/V books. The basis is that Han characters are not as the same level as European alphabets,but words. Han characters are an open set. They are composited on 2 dimension by more basic components which owns basic element ,like "affix" in English (English words are composite on 1 dimension). In academies,components based Han character composite technology are developed and adapted to handle ancient Han books. The most famous are Academia Sinica 's development and cbeta Sutras plan. Recent years, opensource IDS renders are developed stable, so we can use the same technology to benifit Wikisource for handling Han ancient books as the same as those academies.
    • 漢字的特殊性在於字並非像拼音字母由少數的字母以一維空間（1D）構成，而是以更多的基本表音或表意的「部件」（ Components）以2維方式在一個方塊空間內組合（compisite）而成，主要組合方式是水平組合、垂直組合、包圍組合。基本的研究，在1970年代開始，台灣中研院開始進行這方面的研究，有很豐碩的成果，而後就被應用在有超巨量缺字的cbeta佛典計畫（把日本大正藏佛典數位化）等計畫。
      而後，Unicode標準裡面也推出了Ideographic Description Sequence（IDS）規範，制定了IDC（組字符）而且是以符合電腦文字處理的先序（prefix）結構設計，從此之後，在各學術機構的中文研究（例如四庫全書，裝滿四個倉庫的圖書館的一堆書）或者佛學研究，就開始活用IDS ，催生動態組字技術來解決其缺字問題。
      過去，這類技術都在學術界內使用，最近10年，才有通用用途的開放原碼的動態組字引擎陸續研發。台灣在地的維基協會發現現在有很好的進步引擎：漢字組建，遂提出解決方案-han3_ji7_tsoo1_kian3 呈像伺服器rendering server + IDS extension，漢字缺字可以呈現、可以被搜尋定序、可以被交換。
  • More comments:
    • en-There are couple of tests in the test wiki.
    • zh-目前已經有不少測試了，詳見測試維基頁。
  • Phabricator tickets:
  • Proposer: Liang(WMTW) (talk) 16:07, 10 November 2016 (UTC)[reply]

Community discussion

@Shangkuanlc: I'm trying to understand this proposal named "Create new Han Characters with IDS extension for WikiSource" and the related Phabricator task which is about deploying (making available) the IDS extension on Wikimedia sites like WikiSource, so I have to ask for clarification when it comes to the proposed solution: Do you ask WMF's Community Tech team to create new Han characters with the IDS extension? Or the WMF's Community Tech team to extend the IDS extension to allow authors to create new Han characters? Or to deploy the IDS extension on WikiSource (which would be the same request as in the Phabricator task)? Thanks for clarifying! --AKlapper (WMF) (talk) 20:00, 14 November 2016 (UTC)[reply]

@AKlapper (WMF): I have asked the IDS extension programmer, he says we need the latter two of what you mentioned, and basically those two action items actually means the same thing -- editors can create new or ancient characters through the ids service, so deploy the software would be the easiest solution. --Liang(WMTW) (talk) 17:04, 15 November 2016 (UTC)[reply]

Some characters in s:zh:template:SKchar and s:zh:template:SKchar2 may be displayed using it.--維基小霸王 (talk) 07:31, 19 November 2016 (UTC)[reply]

Voting – New Han characters

  1.   Support--Shizhao (talk) 03:19, 28 November 2016 (UTC)[reply]
  2. Strong   Support--Liang(WMTW) (talk) 07:32, 1 December 2016 (UTC)[reply]
  3.   Support--魔法設計師(Shoichi) (talk) 08:39, 1 December 2016 (UTC)[reply]
  4.   Support--Billxu0521 (talk) 08:52, 1 December 2016 (UTC)[reply]
  5.   Support--Yannmaco (talk) 09:52, 1 December 2016 (UTC)[reply]
  6.   Support--S099001 (talk) 12:08, 1 December 2016 (UTC)[reply]
  7.   Support--Wing (talk) 12:32, 1 December 2016 (UTC)[reply]
  8.   Support--Honmingjun (talk) 12:42, 1 December 2016 (UTC)[reply]
  9.   Support--JM99 (talk) 13:40, 1 December 2016 (UTC)[reply]
  10.   Support--Csjh21010 (talk) 14:06, 1 December 2016 (UTC)[reply]
  11.   Support--Fweng322 (talk) 14:13, 1 December 2016 (UTC)[reply]
  12.   Support- Earth Saver (talk) at 14:32, 1 December 2016 (UTC)[reply]
  13.   Support--Hwayang (talk) 15:51, 1 December 2016 (UTC)[reply]
  14.   Support--Tsuna Lu (talk) 16:05, 1 December 2016 (UTC)[reply]
  15.   Support--Wolfch (talk) 17:13, 1 December 2016 (UTC)[reply]
  16.   Support--維基小霸王 (talk) 00:01, 2 December 2016 (UTC)[reply]
  17.   Support--CYLu (talk) 03:28, 2 December 2016 (UTC)[reply]
  18.   Support--John123521 (talk) 06:21, 2 December 2016 (UTC)[reply]
  19.   Support--Micru (talk) 08:18, 2 December 2016 (UTC)[reply]
  20.   Support —Jc86035 (talk) 11:23, 2 December 2016 (UTC)[reply]
  21.   Support--RJ-king (talk) 12:21, 2 December 2016 (UTC)[reply]
  22.   Support--Alex S.H. Lin 12:23, 2 December 2016 (UTC)[reply]
  23.   Support--David675566 (talk) 12:25, 2 December 2016 (UTC)[reply]
  24.   Support--BobChao (talk) 12:27, 2 December 2016 (UTC)[reply]
  25.   Support--Vel c (talk) 12:30, 2 December 2016 (UTC)[reply]
  26.   Support--Medicalwei (talk) 12:33, 2 December 2016 (UTC)[reply]
  27.   Support--Freedman.tw (talk) 16:14, 2 December 2016 (UTC)[reply]
  28.   Support--AddisWang (talk) 02:34, 3 December 2016 (UTC)[reply]
  29.   Support--Zerng07 (talk) 04:51, 5 December 2016 (UTC)[reply]
  30.   Support--Goldie_lin (talk) 05:06, 5 December 2016 (UTC)[reply]
  31.   Support--Subscriptshoe9 (talk) 13:01, 3 December 2016 (UTC)[reply]
  32.   Support--Supaplex (talk) 15:37, 3 December 2016 (UTC)[reply]
  33.   Support Pamputt (talk) 10:46, 4 December 2016 (UTC)[reply]
  34.   Support- I am Davidzdh. 12:44, 4 December 2016 (UTC)[reply]
  35.   Support--Jasonzhuocn (talk) 05:10, 5 December 2016 (UTC)[reply]
  36.   Support--Reke (talk) 06:45, 5 December 2016 (UTC)[reply]
  37.   Support--KOKUYO (talk) 08:06, 5 December 2016 (UTC)[reply]
  38.   Support--Sean9064 (talk) 10:08, 5 December 2016 (UTC)[reply]
  39.   Support ... --Liuxinyu970226 (talk) 10:21, 5 December 2016 (UTC)[reply]
  40.   Support--S8321414 (talk) 10:34, 5 December 2016 (UTC)[reply]
  41.   Support--Seadog007 (talk) 14:02, 5 December 2016 (UTC)[reply]
  42.   Support--Toppy368 (talk) 15:44, 5 December 2016 (UTC)[reply]
  43.   Support--林博仁 (talk) 17:48, 5 December 2016 (UTC)[reply]
  44.   Question: Are there so many people interested in these characters? What works are we hosting in this language? I suppose it seems like a good idea if we actually have a body of these works. Blue Rasberry (talk) 18:36, 6 December 2016 (UTC)[reply]
    @Bluerasberry:The idea of this proposal is to make the Wikimedia projects available to use the <ids> extension to make newly or ancient created han characters which has not included in unicode lists be more accessible (easier to search, index... etc). The idea is not only to create some characters, but to make the system of character creation available in Wikimedia projects. And about you mentioning "body of these works", yes, there is a work of Taiwanese-Mandarin dictionary, which donated by a passed away professor in Taiwan, will be most benefited by this <ids> technique available. You may see further discussion on google groups and meta. I hope I have answered you question, let me know if it's not clear. --Liang(WMTW) (talk) 04:22, 7 December 2016 (UTC)[reply]
    @Bluerasberry:There are still many books including en:Siku_Quanshu (36,381 books, very important and classic in east-Asia) ,its missing Han characters are not 10 or hundreds but tens of thousands. Until now its digitalization still depends on special software with IDS supporting in academies. In the past, not everyone can touch and read them on computers (even through internet) . With IDS rendering technology, books with large missing Han characters can also be put in Wikisource. Missing Han characters are also indexed,exchange-able ,searchable. I think that it's also very meaningful for WMF movement in asia. --魔法設計師(Shoichi) (talk) 14:34, 7 December 2016 (UTC)[reply]
      Support It seems like there are people who have identified books which cannot be converted to digital form without support for these characters. These books are famous and of cultural significance, so this is not just a matter of archiving works which would not be popular but actually a chance to make classical works more available to more people. Since there are already books anticipated for this, and since there is already a community organized to engage with this character support, then this seems like a good idea. Blue Rasberry (talk) 14:47, 7 December 2016 (UTC)[reply]
  45.   Support--Jesus estw (talk) 19:18, 6 December 2016 (UTC)[reply]
  46.   Support--A2093064 (talk) 10:09, 8 December 2016 (UTC)[reply]
  47.   Support given how important the Chinese language is on a global scale. This, that and the other (talk) 13:59, 8 December 2016 (UTC)[reply]
  48.   Support --MoonYaksha月夜叉 01:21, 9 December 2016 (UTC)[reply]
  49.   Support Risker (talk) 03:10, 9 December 2016 (UTC)[reply]
  50.   Support --Edhral 06:29, 9 December 2016 (UTC)[reply]
  51.   Support --10:21, 9 December 2016 (UTC)
  52.   Support--Lt2818 (talk) 10:37, 9 December 2016 (UTC)[reply]
  53.   Support--Bowleerin (talk) 13:18, 10 December 2016 (UTC)[reply]

Make the Page proofreading interface easier to use

  • Problem: The Page interface wastes screen space on tools that aren't used for proofreading, and splits the useful tools between the top and the bottom of the proofread page. You have to scroll up and down to access the useful tools. The option for setting the page status is under the window, so you have to scroll down to use it; when you're done, you can't just hit tab to get into the edit summary, and quickly move on.
  • Who would benefit: all proofreading contributors
  • Proposed solution: To implement three principles:
  1. maximize screen area devoided to edit textarea and to front image hiding anything unuseful for proofreading;
  2. move usual tools into fixed, compact areas (top/bottom of the screen); tools area should not scroll
  3. wrap unusual tools into draggable boxes that can be toggled into/ouside visibility
  • More comments: an excellent first step to get result 1 is FullScreenEditing script by Samwilson. A running example of "draggable tools" is gadget "diacritici", recently implemented into la.souce.
  • Phabricator tickets:

Community discussion

  • @Alex brollo: these sound like good ideas. Do you think the crux of this problem is something like "the proofreading interface does not make optimal use of the browser window" or similar? That it's too cluttered with UI elements that don't pertain to proofreading? The tools-shouldn't-scroll rule is great, I reckon. :-) But yeah, I think we need to clarify the title and problem statement here, so people know what they're voting for. Sam Wilson 08:14, 18 November 2016 (UTC)[reply]
@Samwilson: My English is rather poor, please feel free to change anything. An inspiring example for a good edit interface, focused on proofreading, is the Distributed Proofreaders one; nsPage edit page, on the contrary, is the same used for all wikimedia projects, with minor changes. --Alex brollo (talk) 08:40, 18 November 2016 (UTC)[reply]
Hello, I can confirm that the Wikimedia Foundation has a functional prototype of this feature. --NaBUru38 (talk) 21:49, 10 December 2016 (UTC)[reply]

Voting – Deeply review nsPage edit interface

  1.   Support--Wesalius (talk) 08:20, 28 November 2016 (UTC)[reply]
  2.   Strong support --Ninovolador (talk) 22:34, 29 November 2016 (UTC)[reply]
  3.   Support --Alex brollo (talk) 09:57, 30 November 2016 (UTC)[reply]
  4.   Support --Shubha (talk) 10:28, 2 December 2016 (UTC)[reply]
  5.   Support--Jayantanth (talk) 20:57, 4 December 2016 (UTC)[reply]
  6.   Support --Continua Evoluzione (talk) 10:28, 5 December 2016 (UTC)[reply]
  7.   Support --NaBUru38 (talk)
  8.   Support --Yann (talk) 22:56, 12 December 2016 (UTC)[reply]

Delete all NS:Page while deleting an index file

  • Problem: When an Index page is deleted, NS:page is not deleted simultaneously
  • Who would benefit: Wikisource Admins
  • Proposed solution: Option for Deletion of all NS:Page while deleting an Index page.

Community discussion

Good idea. oh yes... --Hsarrazin (talk) 13:35, 10 November 2016 (UTC)[reply]
+1, I already commented on the task but isn't this just an option to re-activate ? (@Quiddity (WMF): any thought ?) Cdlt, VIGNERON * discut. 16:59, 14 November 2016 (UTC)[reply]
  • @VIGNERON: Do you have any more info about the 'delete all subpages' feature? I can't find it anywhere. Anyway, this proposal can still stand, because there's also the added convenience of not having to create the dummy top-level page. Sam Wilson 00:40, 29 November 2016 (UTC)[reply]
  • @Samwilson: sorry, can't remember... I think it disappeared more than (around) 3 years ago.

Voting – Delete all NS:Page

  1.   Support. --Consulnico (talk) 17:45, 28 November 2016 (UTC)[reply]
  2.   Support VIGNERON * discut. 09:00, 29 November 2016 (UTC)[reply]
  3.   Support ShakespeareFan00 (talk) 20:55, 29 November 2016 (UTC)[reply]
  4.   Support --Ninovolador (talk) 22:35, 29 November 2016 (UTC) I don't think that is such a BIIIIG hack, but it would help the WS admins A LOT[reply]
  5.   Support --Alexmar983 (talk) 06:14, 30 November 2016 (UTC)[reply]
  6.   Strong support! - εΔω 20:53, 1 December 2016 (UTC)
  7.   Support --Shubha (talk) 10:29, 2 December 2016 (UTC)[reply]
  8.   Support --Framawiki (talk) 20:55, 2 December 2016 (UTC)[reply]
  9.   Support Pamputt (talk) 10:47, 4 December 2016 (UTC)[reply]
  10.   Support--Jayantanth (talk) 20:57, 4 December 2016 (UTC)[reply]

Fix Extension:Cite to allow tags and other functionality to work within ref tags

  • Problem: Extension:Cite has major issues where tags are used within tags, and pipe tricks don't work
  • Who would benefit: all wiki and mediawikis
  • Proposed solution: fix extension:cite !!!
  • More comments: here are long standing comments, and it is time that there was a plan to update and fix the extension, one of the most widely utilised extensions across wikimedia sites

Community discussion

@Billinghurst: Could you please try to name the "foibles" in the summary of this proposal (otherwise we would end up with indistinguishable generic "Fix $something to get rid of foibles" summaries for many proposals), describe who (groups/categories of users) would benefit, and describe an actual potential solution? I'm asking as proposals should be as specific as possible and explain what the problem is and who is affected by it. Thanks a lot in advance! --AKlapper (WMF) (talk) 13:20, 9 November 2016 (UTC)[reply]

The foibles are detailed in the phab bug tickets. I tried to change the summary, but I may not have characterized it correctly. - Jonesey95 (talk) 06:29, 10 November 2016 (UTC)[reply]

@AKlapper (WMF):. As Jonesey95 says! I think that I could entitle this reqeust phabricator:4700 though that ticket itself is quite imposing. As the bugmeister if you can lead us on how we can migrate ye olde bug 4700 to a series of concrete components, however, my gut feel is that the words "complete rebuild" and "anachronistic mess" and "ugh!" all swim around this matter. It needs a path to improvement. All that said I can list those items that I face.

Typical examples

  • template substitution fails inside extensions custom tags like <ref> (and <poem>). I have no idea whether that is an issue with substitution or the tags or extensions.
  • pipe trick fails within ref tags, so a common action like an author link like [[Author:John Doe|]] does not work and becomes in operative non-link

 — billinghurst sDrewth 10:21, 10 November 2016 (UTC)

That phab task has a patch, which could be code reviewed and merged. -- DannyH (WMF) (talk) 01:05, 23 November 2016 (UTC)[reply]

Voting – Fix Extension:Cite

  1.   Support --Alex brollo (talk) 07:52, 30 November 2016 (UTC)[reply]
  2.   Support--Jayantanth (talk) 20:57, 4 December 2016 (UTC)[reply]
  3.   Support, but this should not be buried in the WikiSource section; this affects all wikis. E.g., if you put a {{rs?|{{subst:DATE}}}} inside a <ref>...</ref>, the DATE template will not subst.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  18:23, 11 December 2016 (UTC)[reply]
Retrieved from "https://meta.wikimedia.org/w/index.php?title=Community_Wishlist_Survey_2016/Categories/Wikisource&oldid=26808705"