From Wikisource
(Redirected from Wikisource:S)
Jump to navigation Jump to search

The Scriptorium is Wikisource's community discussion page. Feel free to ask questions or leave comments. You may join any current discussion or start a new one; please see Wikisource:Scriptorium/Help.

Some announcements and newsletters are subscribed to Announcements.

Project members can often be found in the #wikisource IRC channel webclient. For discussion related to the entire project (not just the English chapter), please discuss at the multilingual Wikisource. There are currently 391 active users here.


December 2021 Monthly Challenge[edit]

Wikisource laurier.svg

Oh, Come All Ye Faithful! Hear the joyful and triumphant news (well it was Christmas...): the Monthly Challenge again broke its record and reached 7056 processed (proofread, validated or marked without text) pages, surpassing the record set in November by another 977 pages. This represents roughly a third of all processed pages at Wikisource in December (~21k).

In total, the eight Monthly Challenges of 2021 have processed 28,251 pages. If we maintain the December velocity, this will be about 87k at the end of 2022. Can it happen? There's only one way to find out (well two, if you include time-travel, but The Time Machine was already proofread way back in MC #1 in May).

A selection of proofread works from December:


Moving into the bright new year of 2022, we have a new thing for the MC: Public Domain Day! The primary focus in January is works that have fallen into the PD:

And some other works in the Challenge:

In short: fun for all the family, regardless of whether that family is nuclear, biological or chemical! It's cold and/or damp out there for the Northerners and there might even be hungry bears. Stay at home, safe, warm and dry with the only good hungry bear: pooh bear! For the Southerners, drop-bears aside, that near-zenith Sun is trying to mutate your very skin: the The Sun Also Rises wouldn't do that to you! Stay safe, stay inside, and stay proofreading. Inductiveloadtalk/contribs 16:37, 3 January 2022 (UTC)[reply]


New Request for Comment on Wikilinking Policy is open[edit]

I have just opened Wikisource:Requests for comment/Wikilinking policy. You will find there a proposed complete overhaul/rewrite of the current policy, which is now ready for review by the wider Wikisource community. It is proposed that the RfC will be open for two weeks. Please make your comments there rather than here. Beeswaxcandle (talk) 08:33, 14 March 2021 (UTC)[reply]

@Beeswaxcandle: I think 2 weeks / 72 hours is a little bit too aggressive, even for a presumed uncontroversial policy proposal like this. I understand the reasoning, but I just don't think the community is able to move that fast. For example, we have several long-time contributors that are currently in a phase where they check in only every couple of weeks. And I know for my own part that the local Covid status could easily make me too busy to check in here for weeks on end. We could still have an accelerated timeline (just not quite as accelerated as 2/72) if we notify of the proposal in an site notice and maybe even a talk page message to any established contributor that has been active in the last three months (or similar).
PS. And let me repeat my previous private kudos in public: you took my ongoing whining about the old policy and turned it into a concrete proposal for a new policy. Great work, for which I am extremely grateful! --Xover (talk) 09:25, 14 March 2021 (UTC)[reply]

Proposal to delete The Count of Monte Cristo 1844 publication[edit]

This The Count of Monte Cristo is a problematic version. It mentions no source except Wikipedia, and it has no affiliated source file. The title is also problematic. French language publications hyphenated Monte-Cristo. Only two English publications did so, while every other Latin alphabet publication did not. I propose to delete it.— Ineuw (talk) 06:11, 7 December 2021 (UTC)[reply]

@Ineuw: Use WS:Proposed deletions to, uhm, propose something for deletion. :) Xover (talk) 06:42, 7 December 2021 (UTC)[reply]
@Xover: It is posted there as well. The problem is that I had to usurp the disambiguation page for the 1887 version.
Checkmark This section is considered resolved, for the purposes of archiving. If you disagree, replace this template with your comment. 2022-1-5

Ineuw (talk) 17:59, 5 January 2022 (UTC)[reply]

Proposal to create an Image Lab[edit]

Many books have images that either need to be added or updated with higher quality versions. Currently, there is no place on enWS to request the addition of such images. Therefore, I propose to create an Image Lab page similar to the Scan Lab one where users can request the addition of images to a text. This page would also have a ping function so that users capable of adding images can be notified when a new request is posted. Such requests will be limited to texts that the user is currently working on or texts in a community challenge. Languageseeker (talk) 14:58, 8 January 2022 (UTC)[reply]

I think few add images because the process is super-tedious. Smoothing the workflow might help more than adding a request channel.
  • integrating Common's Croptool into the workflow here, and making it so it can cut out multiple images from a page at once, white-adjust and sharpen, and copy the new file and its caption/name to commons.
  • digital-native files, like Journal of Glacial Archaeology/Volume 3/Prehistoric and Medieval Skis from Glaciers and Ice Patches in Norway, have internal image files intrinsically separate from the text. I, on request, manually extracted, named, uploaded, and captioned the images in that short work, and it took forever. I wouldn't mind it taking forever, but it could have been done by a bot.
Anything we can do to speed the extraction and integration of images will improve our texts and save a lot of volunteer time for other purposes. I suggested this in a Community Wishlist, but the idea was rejected for lack of a clear description of the problem. The WMF Growth Team are/were also looking for simple tasks to add to their edit-WP app (meta:Growth/Personalized first day/Structured tasks). Fixing missing-image templates would work well, and we might try for a Wikisource consensus to request it. While I somewhat doubt new editors will stick around because we gave them simple, tedious, semi-automatable tasks, they might discover Wikisource, use our material, and then start editing. HLHJ (talk) 20:27, 9 January 2022 (UTC)[reply]
@HLHJ Plug time: something that might help is toolforge:ws-image-uploader. It's supposed to make uploading images from a book a (bit) less painful. It will eventually also do the SDC data where possible, but for now it just does a normal information template, since there is no useful Commons template for this data that I know of (see commons:Module_talk:Artwork#Entry_point_for_illustration-type_images for a resounding silence on the subject).
What WSIU doesn't do, quite deliberately, is auto-extract from the file. This should never be done if it can be avoided, because the images found in PDFs and DjVu are completely trashed by the compression (see H:EXTRACT for some representative examples). The image should always be extracted from the "most original" file at the source (often a JPG, PNG, JP2 or TIFF, depending on the source). User:Inductiveload/jump to file will get you a direct link to the image in many cases. Thus, better integration of CropTool as it stands would only help users produce "Placeholder" quality images that will need to be replaced with properly extracted images.
Sadly, properly extracting images is quite difficult in the general case, since it's extremely easy to trash fine detail in an image while trying to eliminate paper texture. Help:Image extraction/With GIMP provides a method to extract images using GIMP, but it's certainly not the only way. However, I know of no automatic way to extract images that works for any but the simplest cases: human judgement seems pretty hard to eliminate. Inductiveloadtalk/contribs 20:57, 9 January 2022 (UTC)[reply]
Inductiveload, thank you. toolforge:ws-image-uploader does look useful. Automated image numbering and copying of metadata would be nice; I will try it when next I need to upload such a series. The skis article has higher-res images, on the source website and on Google Drive; I linked them from the Commons PDF-file page but I think it wasn't clear to me if they are under a suitable license; I'm glad to learn there's a tool for getting higher-res images, too. Maybe we also need better discoverability of existing tools.
If we asked academics, they'd upload their own images to Commons instead of Google, which would save us time; maybe I should make a get-outreach-impact-on-your-CV-fast-with-Wikimedia poster and send it round some academic librarians? I did some how-to-guide writing a while back at Wikiversity:Ga naar Wikipedia and Wikipedia:Help:Wikipedia editing for researchers, scholars, and academics, I don't know how useful it's been.
I've traced some into SVG manually; Inkscape's new centerline tool actually does surprisingly well with straight-line parts of line diagrams. This Imagemagick command for de-yellowing images has in practice worked pretty well for me, but that's probably partly luck. Examining the results of a bunch of preset filters to see which one looks best is certainly the sort of semi-automated task the Growth app could do. I think they should build a Wikicaptcha, especially now Google charges all the larger websites hefty fees for training Google's self-driving car software; it would get us a lot of socially-useful work. After all, reCAPTCHA used to do charitable PD-text OCR before Google bought it. I don't think they will, tho. HLHJ (talk) 01:15, 10 January 2022 (UTC)[reply]
@HLHJ a palette of presets is an intriguing idea. That could be a fun project, though the end-to-end integration will be quite some work, since it has to essentially combine "jump to file", "crop tool", a parametric image processing pipeline, metadata collection and upload (i.e. WSIU). So it probably will not be achieved by any WMF team since they will likely not be assigned time to implement it.
As for the ImageMagick command, yes, that does work for images with very good fore/background separation and no pale grey parts that are similar in lightness to the background. For the very simple images, indeed, a tool to do that kind of processing might be good. Though as soon as there's a single splotch that needs the eraser tool, you have to abort and go to a real image editor anyway (or re-implement GIMP/PS as a Toolforge tool!). Inductiveloadtalk/contribs 07:53, 10 January 2022 (UTC)[reply]
GIMP as a Toolforge tool... sounds like a bit more than an afternoons' coding wink. A Commons-API plugin for the GIMP sounds more feasible. On the simpler end, a Toolforge tool to adjust whitebalance would be useful for photos and might be made usable to improve greyscale and black-and-white diagrams on yellowing paper, which are a large proportion of PD book illustrations (UI of colour and contrast curves, with some common presets on buttons?). Serial improvements seem acceptable here; if there's still a print-coloured splotch to remove, at least it's better than when it was discoloured with a print-coloured splotch. I"ve used the Commons API, but never written a Toolforge tool, so I have little idea of what this entails. HLHJ (talk) 18:42, 15 January 2022 (UTC)[reply]

Bot approval requests[edit]


user:prinssbot will run the script Wikipedia:User:Ahechtbot/ to update the data for module:transclusion count to ensure up to date data for template:high-use. it will run at a rate of one edit every 30 seconds. and will be monitored while running. it will only edit subpages of module:transclusion count/data. Serprinss (talk) 00:58, 4 January 2022 (UTC)[reply]

forgot to mention it will run on a weekly basis Serprinss (talk) 01:06, 4 January 2022 (UTC)[reply]

Repairs (and moves)[edit]

Designated for requests related to the repair of works (and scans of works) presented on Wikisource

See also Wikisource:Scan lab

Indexes with deleted files[edit]

I suspect each of these will need a discussion, so might as well start listing them now. PseudoSkull (talk) 16:04, 9 January 2022 (UTC)[reply]

Index:Constitution of India (2019).pdf[edit]

We'll start with this one. @MSG17, @CalendulaAsteraceae, @Hrishikes: This file was deleted at Wikimedia Commons, per c:Commons:Deletion requests/File:Constitution of India (2019).pdf, and apparently a similar or the same file was deleted earlier at c:Commons:Deletion requests/File:Constitution of India, As on 09 September 2020.pdf. As it is an edict of a government, it may not be public domain in India as was noted in the earliest of the deletion requests, however it would be PD in the US (presumably), so I think the file could be transferred to Wikisource and the index and the pages can be transferred to link to that file. PseudoSkull (talk) 16:04, 9 January 2022 (UTC)[reply]

Noting pages existing in this index, in case of deletion: 1, 3, 22, 221. PseudoSkull (talk) 16:06, 9 January 2022 (UTC)[reply]
@PseudoSkull: -- Please see 1 for my opinion on the matter (Please note that the closing admin's opinion was presented without evidence and is merely a personal opinion), as well as 2. Hrishikes (talk) 16:52, 9 January 2022 (UTC)[reply]
@Hrishikes: Sounds like a more convoluted and controversial issue than I initially realized. It looks like this then failed WS:CV, so should I then delete the material presented? Or does there perhaps need to be another WS:CV debate about it? As an uninvolved party, I am interested in your opinion on next actions. PseudoSkull (talk) 17:06, 9 January 2022 (UTC)[reply]
@PseudoSkull: -- I don't have objection to the presence of those works. I merely objected to the label of edict-gov. If you go through the contents of c:Template:EdictGov-India and Template:PD-INGov, you will realize that those templates are not applicable in this case. Anyway, I have discussed this matter enough times. I am not going to engage this time. Let others debate and decide. Regards -- Hrishikes (talk) 17:18, 9 January 2022 (UTC)[reply]
@Hrishikes: See Georgia v. Public.Resource.Org, Inc.. Xover (talk) 18:24, 9 January 2022 (UTC)[reply]
@Xover: -- That judgement is not related to the present case. As ruled by the Court, the Code Review Commission functioned as an arm of the Georgia Legislature, therefore annotations done by them fell into the public domain. But India's Law Ministry does not function as an arm of the Parliament. Therefore the Georgia case does not apply here. Hrishikes (talk) 03:38, 10 January 2022 (UTC)[reply]
@Hrishikes: If you think the outcome of the copyright discussion was incorrect then please feel free to open an undeletion discussion. But you asserted that my close "was presented without evidence" so I linked you to Georgia v. PRO, which was the SCOTUS decision I referred to in my closing comment. Xover (talk) 08:34, 10 January 2022 (UTC)[reply]
@Xover: -- I did not object to the outcome of delete; I objected to the closing comment. The closing comment should be confined to the points raised within the discussion, especially the final outcome, if any, of the discussion. But your closing comment had a lot of extra elements, without appropriate evidence. If you felt like making such additional points, then, instead of closing the discussion, you should have participated in it and made your points in the discussion itself, so that others could respond. I object to this kind of closing comment. Hrishikes (talk) 08:49, 10 January 2022 (UTC)[reply]
@Hrishikes: And yet the first I hear of it is in a backhanded comment in an unrelated forum, in a conversation in which I am not involved, ten months after the fact… If you have any complaints about my actions in any context then I would ask that you take it up with me directly, preferably on my talk page but at a minimum somewhere I am notified that you are discussing me. It is certainly possible that I made a mistake or acted on imperfect information in any given close, and there are numerous issues on which a reasonable person might disagree with me. But thankfully our processes are designed such that I do not actually need to be infallible: they are open to all, publicly archived, can be challenged or reopened, and issues can be raised both with the closer and with the community at large. In other words, the kind of sniping you're indulging in here is both unnecessary and counter-productive. Xover (talk) 09:22, 10 January 2022 (UTC)[reply]
@Xover: -- I'm sorry if you think it's sniping; it was not intended as such. I did not raise the issue previously, because the outcome of the discussion was deletion which I had supported, so there was no need for me to raise any issue, although I was not happy with the closing comment. But now I referred another user to that discussion. When someone visits an archived discussion, the closing comment is the one which first draws attention, and it creates the first impression about a given topic. This particular closing comment had raised doubts about the points I had made in the discussion, by using terms like, "not plausible", "incorrect", "arguable" etc. So I had felt the need to suggest to the user I had referred, that the closing comment was not evidence-based. My comment, to which you responded, was solely about another, historical, comment, and not directed against you personally. My further explanation was in response to your response, it was not "sniping". So please do not take it personally. Hrishikes (talk) 12:52, 10 January 2022 (UTC)[reply]
@Hrishikes, @Xover: Alright, well, due to the above comments, it seems it was the right decision to then delete the pages and the index page both, entirely. Not only did the WS:CV discussion end in a deletion (and two Commons deletion debates on the files also ended in delete to top that off), but both of you seem to agree on the fact that the entry should stay deleted if I am interpreting correctly, while I get that you may not agree on the details as to why. So, I deleted the pages and index both on the basis of them being copyright infringement, and because the source file was deleted at Wikimedia Commons anyway. It doesn't seem likely that the 2019 Indian Constitution issue will end in a keep, but I am no crystal ball. If at any point in the future it is conclusively determined this is not in fact copyright infringement, the work can be re-proofread (the pages I deleted were marked as "Not proofread" anyway so not too much of a biggie). Resolved. PseudoSkull (talk) 02:42, 11 January 2022 (UTC)[reply]
@PseudoSkull: So long as the outcome on WS:CV was delete (right or wrong) then these related pages should indeed be deleted too. If there is a genuine disagreement about the WS:CV outcome (which I am not aware that there is) then that needs to be brought up in the form of an undeletion discussion on WS:CV. If, for whatever reason, the outcome of that should differ from the original, then the specific consequences would need to assessed at that point. Xover (talk) 07:08, 11 January 2022 (UTC)[reply]

Index:The works of Plato, vol 2 (Dacier, 1701).pdf[edit]

This file was formerly File:Worksplatoabrid00stengoog.pdf until it was moved to this name by Jelican9 on 2 December 2021 as a "meaningless or ambiguous name". Later, on 8 December 2021, it was deleted by @Infrogmation: "per uploader del req". Without knowing why on earth the creator wanted it deleted, or who the creator was, it's hard for me to say if a better version of the file exists or might have been uploaded. If it was, it might be a better idea to move the pages in this index to that hypothetical file instead of deleting the pages altogether.

Pinging also @Oryang7, @ShakespeareFan00, @Inductiveload, @CalendulaAsteraceae: who were known to be involved with this transcription in some way. List of pages: 2, 3, 4, 5, 6, 7, 8, 9. PseudoSkull (talk) 16:28, 9 January 2022 (UTC)[reply]

(Although I deleted most of the pages except 8, because they were all meaningless. Only 8 had any actual content.) PseudoSkull (talk) 16:34, 9 January 2022 (UTC)[reply]
From what I remember I had mistakenly uploaded a duplicate of File:Works_of_Plato,_vol._1_(Dacier,1701).pdf (formerly File:Worksplatoabrid01stengoog.pdf) under the filename File:Worksplatoabrid00stengoog.pdf as detailed in the deletion log here. However pointed out that it didn't appear to be a duplicate and it may have been the case that I got confused as I had originally cited the source of File:Worksplatoabrid01stengoog.pdf as also being the source of File:Worksplatoabrid00stengoog.pdf as seen here. Either way I'll attempt to submit an undeletion request for the 2nd volume. Oryang7 (talk) 01:21, 10 January 2022 (UTC)[reply]
@Oryang7: Alright then, I removed the speedy deletion template. Resolved. PseudoSkull (talk) 02:35, 11 January 2022 (UTC)[reply]

Index:The fleshly school of poetry and other phenomena of the day (IA cu31924013268887).pdf[edit]

@, @Chrisguise: This file appears to be broken, as in the pages are not showing on the Index main page or on any of the page namespace pages. Opening it on the Commons PDF viewer does work though. Is this just on my end, or are others experiencing this issue? PseudoSkull (talk) 16:18, 9 January 2022 (UTC)[reply]

@PseudoSkull I see it too. Could be anything, I suppose. I've just done the lazy thing and used the DJVU instead: Index:The Fleshly school of poetry - Buchanan - 1872.djvu. Inductiveloadtalk/contribs 21:35, 9 January 2022 (UTC)[reply]
@PseudoSkull@ Both of the scans of this edition of the work on IA had problems and I made multiple attempts to reconstruct a single complete PDF, from simply moving pages between the two PDF files, to reconstructing a new one from the individual page scan images. Although the resultant files always opened correctly in PDF software (Acrobat, Foxit (reader and editor), they would not display when pulled through into Wikisource from Commons. The information summary on Commons gave the correct file size but after initially showing the correct number of pages, the number of pages collapsed to zero. I'll do work on the transcription but the file may yet require some work. Chrisguise (talk) 16:27, 10 January 2022 (UTC)[reply]

Other discussions[edit]

Policy on substantially empty works[edit]

[This is imported from WS:PD, where it applies to multiple current proposals, and several other works].

We have quite a few cases of works that are "collective" or "encyclopaedic" in that they comprise many standalone articles of individual value, which are basically just "shell pages", with no substantial content of any sort, not even imported scans or Index pages. For example, and this isn't intended to make any statement about these specific works, they're just examples and they may well get some work done soon during their respective WS:PD discussions:

Based on the usual rate of editing for things like that, unless dragged up into a process like WS:PD, they'll remain that way a very, very long time. I think it is perhaps there might be a case to host a mainspace page for this work, even though there is zero, or almost zero actual content. Do we want:

  • Mainspace pages where this is a tiny bit of information like header notes, scan links and maybe detective work on the talk page (not in this case). This provides a place for people to incrementally add content. Also gives "false positive" blue links, since there is actually no "real" content from the work itself, or
  • Do not have a mainspace page until there's some content. Only host this in terms of scan links author/portal scan links, much like we do for something like a novel.

Personally, I lean (gently) towards #2, but with a fairly low bar for how much content is needed. Say, Indexes, basic templates, a title page and one example article. Ideally, a completed TOC if practical, especially for periodical volumes/numbers. It is fair to not wish to transcribe entire volumes of these work, it is fair to not want to import dozens of scans when you only wanted one, it is fair to only want an article or two, but it's not fair, IMO, to expect the first person who wants to add an article to have to do all the groundwork themselves, despite having been lured in with a blue link. That onus feels more like it should be on the person creating the top-level page in the first place.

I do see some value in periodical top pages with decent lists of volumes and scans where known, because these are often tricky and fiddly to compile from Google books/IA/Hathi, so it's not useless work, even if there are no imported scans (though imported is better than not).

We currently have a large handful of collective works listed for deletion right now in various levels of "no real content", and, furthermore, every single periodical that gets added can fall into this situation unless the person who adds, so I think we could have a think about what we really want to see here. Inductiveloadtalk/contribs 15:43, 3 July 2020 (UTC)[reply]

  • I believe that, if there is no scan as an Index: page, the main-namespace page should not exist unless it is being actively completed or is already mostly completed. A few pages (of the volume itself) is not very helpful, and is entirely useless if their is no scan given. TE(æ)A,ea. (talk) 15:59, 3 July 2020 (UTC).[reply]
  • I think such preparatory information would ideally be on more centralized WikiProject pages (for the broad subject), both for clarity and to assist in keeping different efforts consistent -- but that it certainly should be retained as visible to non-admins. I think that the red vs blue link issue is minor (but not totally negligible) and outweighed by the disadvantages of hiding the history of previous efforts. I strongly encourage redirecting such pages to appropriate WikiProject pages (after copying over the details there). JesseW (talk) 18:11, 3 July 2020 (UTC)[reply]
  • @JesseW: I agree that history shouldn't be deleted, but I think we should approach this in terms of what we want to see from these works, rather than what to do with the handful of examples at PD. There are hundreds of periodicals we could have but don't, and this applies to those as well. If we can come to a conclusion about what is and isn't wanted, we can make all the deletion requested works conform to that easily enough. Inductiveloadtalk/contribs 20:55, 3 July 2020 (UTC)[reply]
  • I think these pages are necessary to list index pages and external scans of multi-volume works (such as encyclopaedias and periodicals) especially if they are wholly or partly anonymous or have many authors or are simply large. I think it makes no difference whether such pages are in the mainspace, the portal space or the project space (except that it is harder to find pages outside the mainspace). The point is that these works often have so many volumes (often dozens or hundreds) that they must have their own page, and cannot be merged into a larger portal or wikiproject. If the community starts insisting on index pages, what will happen is the rapid upload of a large number of scans for the periodicals that already have their own page. Likewise if the community insists on transclusion. I also think it is reasonable to have a contents page in the mainspace, as it allows transclusion of articles. Most importantly, new restrictions should not immediately apply to existing pages that were created before the introduction of the restrictions. This is necessary to prevent a bottleneck. James500 (talk) 23:55, 3 July 2020 (UTC)[reply]
move the works to a maintenance category, and i will work them; delete them and i will not: i find your sword of Damocles demotivating. Slowking4Rama's revenge 01:55, 5 July 2020 (UTC)[reply]
@User:Slowking4: I am not proposing a sword of Damocles. I agree that the imposition of deadlines is counter-productive. I do not support the deletion of any of these pages. I would prefer to see them improved. James500 (talk) 04:38, 5 July 2020 (UTC)[reply]
TEA is on his usual deletion spree. not a fan. will not be finding scans to save texts, any more. he can do it. Slowking4Rama's revenge 00:15, 6 July 2020 (UTC)[reply]
The entire point of moving this here, and not staying at WS:PD is to decouple from the emotions that get stirred up in a deletion discussion. Let's keep deletion out of this. If we come up with some idea of what we do and don't want, then we can go back to WS:PD and decide what to do. I imagine that all that will be needed will be a fairly limited amount of housework to bring those works up to some standard that we can decide on here, and all the collective works there will be easy keeps. Hopefully with some kind of consensus that we can point at to outline a minimum viable product for such works going forward. There are hundreds and thousands of dictionaries, encyclopedias, periodicals and newspapers that we could/will, quite reasonably, have only snippets of. How do we want to present them? What, exactly, is the minimum threshold? Let's head of all those future deletion proposals off at the pass, because deletion proposals often cause friction. Inductiveloadtalk/contribs 00:47, 6 July 2020 (UTC)[reply]
and yet deletion is the default method to "motivate" quality improvement. i reject your assertion that "emotions get stirred in a deletion discussion", rather, anger is a valid response to a repeated broken process being kicked down on the volunteers. it is unclear that a minimum threshold is necessary, rather a functional quality improvement process is. until we have one, you should expect to see this periodic stirring of emotions, as the non-leaders act out. Slowking4Rama's revenge 11:53, 9 July 2020 (UTC)[reply]
@Slowking4: Thank you for presenting this opinion, and I'm sorry if I have not made myself clear. We do need to figure out how to avoid a de-facto process of using WS:PD as an ill-tempered ad-hoc venue for "forcing" improvements on people who have somehow managed to generate works that are so in need of improvement that another user has nominated them for deletion. Please also consider looking at #Re-purpose_WikiProject_OCR_to_WikiProject_Scans for an idea to have a "functional quality improvement process" to which such works could be referred upon discovery rather than kicking them straight to WS:PD. If you have other ideas or you have previously suggested something similar to address these frustrations, you could detail them there. Personally, I think we should always prefer improvement over deletion. Exactly what the remediation is (refer to a putative WP:Scans, WS:Scriptorium/Help, directly WS:PD as now, or something else) is not what this thread is for. This thread is for discussing, what, if anything, should be the tipping point for deeming a page "lacking" and doing something about, whatever "something" is. I don't think I can be much clearer that this is not about deletion. If we also have a better venue for improvements, then that's even better.
For example, my personal feeling and !vote on A Critical Dictionary of English Literature is "keep and improve", despite it lacking scans or even links to scans, having only one article and no other content, not even a title page: in short, failing almost every criterion suggested so far in this thread. The only thing it does have is have is good text quality of the one entry. I personally do not think this work should be deleted, but I do think it should be improved in specific ways. The first half of that sentence is not the focus of this discussion, the second half is. Inductiveloadtalk/contribs 14:18, 9 July 2020 (UTC)[reply]
deletion threat has been an habitual method of communicating by admins since the beginning of the project. and text dumps have been habitual following in the guttenberg example. culture change and process change would be required to change those behaviors. we could may it easier to start scan backed works, but the wishlist was not supported. Slowking4Rama's revenge 21:00, 14 July 2020 (UTC)[reply]

I don't think this needs to be much of an issue going forward -- we all agree that it's OK to create Index pages for scans, even if none of the Pages have been transcribed yet; so the only case where this would come up is recording research where no scan has yet been identified as suitable to be uploaded. And for that, I still think a WikiProject page is the right location, not mainspace. (Or, if you must, your userpage.) JesseW (talk) 00:59, 6 July 2020 (UTC) I realized I may not have been clear enough here -- in my view, the ideal process goes like this:[reply]

  1. Decide on a work you are interested in (in this case, a periodical/encyclopedic one) -- don't record that anywhere on-wiki (except maybe your user page)
  2. Find and upload (to Commons) a scan of one part/issue/etc of the work.
  3. Create a ProofreadPage-managed page in the Index: namespace for the scan. (You can stop after this point, without worry that your work will later be discarded.)
    1. Put further research (on other editions, context, possible wikification, etc.) on that Index_talk page.
    2. Proofread a complete part of the scan (an article from the magazine issue, a chapter from the book, a entry from an encyclopedia, etc.) and transclude it to the mainspace (and create necessary parent pages), and put the further research on the Talk: page of the parent mainspace entry.

If you can't find any scan, and don't want to leave your working notes on your user page, put them on a relevant WikiProject's page.

If you come across such research done by others and misplaced, follow the above process to relocate it to an appropriate place, then redirect the page where you found it to the new location. That's my proposal. JesseW (talk) 01:08, 6 July 2020 (UTC)[reply]

@JesseW: It's not clear to me in your above whether when you use the term "index" you refer to a ProofreadPage-managed page in the Index: namespace, or a general wikipage in the main namespace on which an index-like structure (and/or a ToC, or similar) is manually created. Could you clarify? --Xover (talk) 05:14, 6 July 2020 (UTC)[reply]
I meant the namespace. Clarified now. JesseW (talk) 05:17, 6 July 2020 (UTC)[reply]
  • Hoo-boy. Y'all sure know how to pick the difficult issues…
    My general stance is that: 1) scans and Index: (and Page:) namespace pages have no particular completion criteria to meet to merit inclusion, and can stay in whatever state indefinitely (there may be other reasons to get rid of them, but not this); and 2) the default for mainspace is that only scan-backed complete and finished works that meet a minimum standard for quality should exist there.
    That general stance must be nuanced in two main ways: 1) there must be some kind of grandfather clause for pre-existing pages; and 2) there must exist exceptions for certain kinds of works that meet certain criteria. I won't touch on the grandfather clause here much, except to say I'm generally in favour of making it minimal, maybe something like "No active effort to get rid of older works, but if they're brought to PD for other reasons they're fair game". The design of a grandfather clause for this is a whole separate discussion, and an intelligent one requires analysis of existing pages that would be affected by it. It is always preferable to migrate pages to a modern standard, so a grandfather clause is by definition a second choice option.
    Now, to the meat of the matter: the exceptions…
    We have a clear policy to start from: no excerpts. Works should either be complete as published, or they should not be in mainspace. But quite apart from the historical practices that modify this (which are somewhat subjective and inconsistent, so I'll ignore them for now), there are some fairly obvious cases that suggest a need for more nuance than a simple bright-line rule alone provides. The major ones that come to mind are: 1) massive never-completed projects like EB1911 or the New York Times (EB because it's big; NYT because new PD issues are added every year); 2) compilations or collections of stand-alone works with plausible claim to independent notability.
    For encyclopedias and encyclopedia-like things, we have to accept some subsets due to sheer scale of work. But when that is the grounds for exception, there needs to be some minimum level of completion. I'm not sure I can come up with a specific number of pages/entries or percentage, but it needs to be more than just a single entry (and, obviously, only complete entries). For this kind of exception to apply, I think it needs to be a requirement that the framing structure for it is complete: that is, the mainspace page should give a complete overview of the relevant work even if most of it is redlinks. That includes title pages and other prolegomena when relevant. For a periodical like the NYT, that means complete lists of issues with dates and other such relevant information (e,g. name changes etc.). For preference, these kinds of things should be in Portal: namespace or on a WikiProject page until actually complete, but that will not always be practical (EB1911 and NYT are examples of this). Mainspace or Portal:-space should never contain external links (i.e. to scans) or links to Index: or Page: space (except the implied link of transclusion and the "Source" tab in the MW UI provided by ProofreadPage).
    For exception claimed under independent notability there are a couple of distinct variants.
    Newspaper or magazine articles need to have a certain level of substance in addition to a specific identifiable byline (possibly anonymous or pseudonymous, and possibly identified after the fact by some other source, such as the Letters of Junius) in order to qualify. It is not enough to ipso facto be a newspaper article, a magazine article, a poem, or an encyclopedia entry. On the one hand we have things like dictionaries and thesauri, where an entry could be as little as two words. Or a one-sentence notice without byline in a newspaper. Or two rhymed lines (technically a poem) within a 1000-page scholarly monograph.
    To merit this exception it should be reasonable to argue that the "work" in question should exist as a stand-alone mainspace page (not that we generally want that; but as a test for this exception, it should be reasonable to make such an argument). This would clearly apply to moderately long entries in the EB1911 written by a known author that has their own Wikipedia article. It would apply to short stories or novella-length serialisations in literary magazines by authors that have later become famous (or "are still …"). It would apply to various longer-form journalistic material from identifiable journalists (again, rule of thumb is notable enough for enWP article), including things in magazines that have similar properties. For most periodicals the most relevant atomic (indivisable) part is the issue not the entry or article, but with some commonsense exceptions.
    It would, generally, not apply to things that are works by a single author, like a scholarly monograph that just happens to be arranged in "entries" rather than chapters. It would not apply to things that are essentially lists or tables of data. It would not apply to short entries in something encyclopedia-like or entries that are not by an identifiable author. The OED for example, iirc, is a collective work where entries are by multiple not individually identifiable authors (and each entry is mostly very short too); only the overall editor is usually cited.
    For works claiming this exception too the framing structure should be complete, even if most of it are redlinks. The same general rules about Portal:/WikiProject and no external or Index:-space links apply. An exception would be for periodicals where new issues enter the public domain every year; and we should generally avoid including even redlinks for the non-PD issues here (but may allow them in a WikiProject page). For non-periodical works in multiple volumes where some volumes were published after the PD cutoff, including listings for the non-PD volumes (but not links to scans; those are a copyvio issue) is ok.
    Poems, short stories, and novellas are a special class of works here. A lot of these were first published in a magazine (possibly serialized), and a lot of them exist as multiple editions in substantially the same form. Some exist in multiple versions. These should all primarily exist the same way as chapters as part of their various containing works; but there are some cases where we might want to have, for example, a series of connected pages of the poems of Emily Dickinson. I am significantly ambivalent about this practice, as it amounts to making our own "edition" or "collection" of her poems (in violation of several of our other policies), but I acknowledge that it is an established practice and it is something that has definite value to our readers. It may be that it is actually a practice that should be governed by its own dedicated policy rather be attempted to be handled within these other general policies.
    For the sake of example; applying this to the works Inductiveload listed at the start of this thread would shake out something like this:
    Auction Prices of Books—This work appears to have no sensible subdivisions and is in any case by a single author. I see no obvious reason to grant this work an exception, except under sheer volume of work and even there I would want to see both a substantial proportion completed and some kind of ongoing effort towards completion (no particular time frame, but definitely not infinite and definitely not as an effectively abandoned project). In a deletion discussion I would very likely vote to delete the mainspace pages here (but, as nearly always, to keep the Index: and Page: namespace artifacts). I don't see this as a reasonable candidate for a Portal:, nor really a good fit for a WikiProject (though I probably wouldn't object to a WikiProject if someone really wanted one).
    Central Law Journal/Volume 1—A single volume is too little, so I would want to see a complete structure for the entire Central Law Journal, with level of detail for each volume similar to the one existing volume. Each article in the journal can be individually considered for a stand-alone work exception; but for the collection I would want to see at minimum a full issue finished to justify having the mainspace structure, and preferably multiple issues (in a deletion discussion I might insist on multiple issues). Index: and Page:-space artefacts can, of course, stay. A Portal: might make sense for selections from the journal, of articles that meet the standalone work exception. A WikiProject to coordinate work and track links to scans etc. might be a decent fit here, if someone wanted that. As it currently stands I would probably vote delete for the mainspace artefacts (with option to move whatever content has reuse value to a non-mainspace page for preservation; and undeleting if someone wants to work on something is a low bar).
    A Critical Dictionary of English Literature—The top level mainspace page has near-zero value, existing only to link to the single transcribed entry. For a credible claim to exception to exist it would need to be a complete framework for the work as a whole, and significantly more than a single entry must be complete. I would probably also want to see ongoing work, unless a substantial percentage of the entries were complete. The single finished entry is eligible to claim a standalone work exception, but I think it probably would not meet my bar for that (I might be wrong; and the rest of the community might judge it differently). In a deletion discussion I would probably vote to delete all the mainspace artifacts here (as always keeping Index:/Page: stuff) but with a definite possibility that I might be persuaded on the one completed entry (an absolute requirement for convincing me would be to scan-back it: as a separate issue, my tolerance for grandfathering of non-scan-backed works is small, and effectively zero for new/non-grandfathered works).
    Bradshaw's Monthly Railway Guide—Would need a full framework and a number of individual issues finished to merit a mainspace page. I see no credible subdivisions for a standalone work exception, but might be persuaded otherwise if, say, one of the train tables was used as a (reliable primary) source in a Wikipedia article (implying some sort of notability beyond just being raw data). In a deletion discussion I would probably vote to delete all mainspace artifacts here. If anyone made the argument, I would entertain the notion that there is value in treating train tables like poems, and hosting a series of train tables like we do Dickinson's poems; but that would require a substantial number of them completed.
    For everything above my stance is nuanced by a willingness to accept temporary exceptions for things that are actively being worked: active being operative, but with no particular deadline to complete the work. We have differing amounts of time available, and some works are so labour-intensive or tedious to do, that my person threshold for "active" is a pretty low bar to clear. If it's months and years between every time you dip in and do a bit I might start to get antsy, but days or weeks probably won't faze me. And that the projected time to completion is very long at that pace is not particularly a problem so long as it is not infinite. Within those parameters I would always tend to err on the side of letting contributors just get on with it in peace, regardless of any of the policy-like rules sketched above.
    I also want to emphasise that I think this is a very difficult issue to deal with. There are a lot of competing concerns, and a lot of grey areas that will likely take individual discussions to resolve. My balance point on this issue is partly formed by a broader concern about our overall quality (we have waay too many works of plain sub-par quality, and too many not up to modern standards) and a hope that by preventing the creation of these kinds of works (rather than deleting them after creation) we will be able to retain the good and desirable exceptions without dragging down quality, and without the traumatic and stressful events that deletions and proposed deletion discussions are.
    And for that very reason I am grateful this issue was brought up here for discussion, and I hope we can end up with some clear guidance, possibly in the form of a policy page, going forward. And in any case, since it will create de facto policy, this is a discussion that needs to stay open for a good long while (there are several community members that have not yet commented whose opinion I would wish to hear before closing this), and depending on how well we manage to structure the consensus, may also require a formal vote (up in the #Proposals section). --Xover (talk) 09:03, 6 July 2020 (UTC)[reply]
  • Symbol oppose vote.svg Oppose. It is becoming clear that a policy on incomplete works in the mainspace is going to place enormous pressure on individual editors. I think it would be more effective to start a wikiproject devoted to scan-backing works that lack scans and so on. James500 (talk) 12:14, 6 July 2020 (UTC)[reply]
    • @James500: FYI, this thread was made in order to provide an exception to the current policy of "no excerpts". A literal reading of the policy as it stands has a plausible chance of coming down delete on the mainspace pages over at WS:PD. This thread is a chance to come up with a better way to support such partial collective works. That we have several substantially incomplete and abandoned collective works lolling around in mainspace is actually the result of laxity in respect to stated policy (not to say I think it's a bad thing). The deletion proposals, whatever you may think of them, are actually not in contradiction to policy. That said, as always, there is scope to adjust policy. Which is what this is.
    • Now, in terms of a WikiProject to scan back works, I think that is a good idea. See #Re-purpose_WikiProject_OCR_to_WikiProject_Scans above, which proposed to reboot Wikiproject OCR as a scan-backing Wikiproject. Inductiveloadtalk/contribs 14:40, 6 July 2020 (UTC)[reply]
      • The policy says "When an entire work is available as a djvu file on commons and an Index page is created here, works are considered in process not excerpts." A literal reading of that policy is that no scan-backed work is an excerpt (it is expected to be completed eventually). Further the policy refers to "Random or selected sections of a larger work". A literal reading of that expression is that it does not include lists of scans, or auxilliary content tables, as they are not "sections" (they are not part of the work), and that not every incomplete portion of a work is either "random or selected" (which would not include starting from the beginning and getting as far as you can, with intent to finish later). I could probably argue that an encyclopedia article or periodical article is a complete work. James500 (talk) 15:16, 6 July 2020 (UTC)[reply]
  • Nice wall of text, Xover (and I say that with great respect!) -- it generally makes sense and sounds good to me. As another hopefully illustrative example, take The Works of Voltaire, which I've been digging thru lately. I think this would very much satisfy your criteria as a large work, with sufficient scaffolding to justify the mainspace pages that exist for it. I would love to hear others thoughts on that. JesseW (talk) 16:07, 6 July 2020 (UTC)[reply]
    @JesseW: Yeah, apologies for the length. Brevity is just not my strong suit.
    The Works of Voltaire probably qualifies on sheer scale of work, yes. I don't think the current wikipage at The Works of Voltaire is quite it though: as it currently stands it is more WikiProject than something that should sit in mainspace (its contents are for Wikisource contributors, to organise our effort, not our readers, who want to read finished transcriptions). It also mixes a work page with a versions page in a confusing way. So I would probably say… Move the current page to Wikisource:WikiProject Voltaire; create a new The Works of Voltaire as a pure versions page, linking to…; The Works of Voltaire (1906), that is set up as a work page with the cover and title (and other relevant front matter) of the first volume, and an AuxTOC (and possibly also the {{Works of Voltaire}} volume navigation template). I don't know how tightly coupled the volumes of this edition are (does the first volume have a common ToC or index of works for all the volumes?), so some flexibility on format may be needed to make sense. But as a base rule of thumb it should start from a regular works page and deviate only as needed to accommodate this work (mainly the size is different).
    In any case… With a volume or two completed (they're only ~350 pages each) I'd be perfectly happy having something like that sitting around. With less then that I'd possibly be a bit more iffy, but it's hard to put any kind of hard limit on that. And with somebody actively working on it I'd be in no hurry whatsoever regardless of current level of completion.
    PS. I'm pretty sure a large proportion of the contents of these volumes are works that would qualify under "standalone works" that could exist independently in mainspace, regardless of what's done with the The Works of Voltaire page. Even his individual poems and essays can presumably make a credible claim here (because it's Voltaire; less famous authors would have a higher bar). Better as part of the edition, but also acceptable on their own. --Xover (talk) 16:56, 6 July 2020 (UTC)[reply]
  • @JesseW: I personally take no issue with this page's existence (actually I think it's a nice work and good way to allow an important author's works to be slotted in piece-by-piece. I have some general comments which overlap with this thread (written before Xover's reply, so pardon overlap):
    • First off, I differ with Xover in terms of the scan links: I think they're better than nothing, and I don't see much value in duplicating the volume list onto an auxiliary page just to add scan links. However, I can sympathise with the sentiment that our mainspace shouldn't direct users off-wiki (or at least off-WMF). But if we don't have the scans, and that's what the user wants, they're leaving anyway. Real answer: import moar scans!
    • No scan links are necessary where the volume exists in mainspace and is scan-backed (e.g. v3)
    • Ext scan links should only be used when there is no Index page or imported scan. Use {{small scan link}} or {{Commons link}} when possible (e.g. v2)
    • The first volume list could probably be in an AuxTOC to mark it out as WS-generated content.
    • The "Other editions" section belongs on an auxiliary namespace page (Talk, Portal or Wikisource). I suggest the Talk page is best in this case. Inductiveloadtalk/contribs 17:35, 6 July 2020 (UTC)[reply]
  • @Xover: I am in agreement with the majority of what you say. Particularly, I think a framework around any collective work (be it a single-volume biographical dictionary or a 400-issue literary review spanning 80 years) is the critical prerequisite, plus at least some scans, the more the merrier. Where I think I differ:
    • I am inclined to be a bit more relaxed in terms of how much of a work we need. As long as a single article exists, it's not "trivial" (e.g. only a short advert or some incidental text like a "note to correspondents", as opposed to an actual article), it's well-formatted and scan-backed, and a complete framework exists, including front matter and a TOC, such that's it is easy for anyone to slot in new pieces, I'd be fairly happy. Lots of periodicals have all sort of tricky bits like tables of stocks or weather tables and writing into policy that those must be proofread in order to get the "real" articles into mainspace would be a chilling effect, in my opinion. If you allowed an exception, it would be verbose and tricky to capture the spirit without saying "unless, like, it's totally, like, hard, man".
    • I am not dead against scan links in the mainspace at the top level, when such a top-level page exists. See my comments on Voltaire above. I am against them where they could sensibly be on an Author page and they are the only mainspace content.
    • I am ambivalent on the presence of, e.g., disjointed train timetables. It's not my thing to have a smattering of random timetables, but as long as they're individually presented nicely, it's not too offensive to my sensibilities. I might question the sanity of someone who loves doing tables that much, but whatever floats the boats! Also, I think that this might circle back to "good for export" - a mark which certainly would require completed issues or volumes. If you want to get that box ticked, you have to do it all.
    • Re the "notability" aspect of individual articles, I'm not really bothered by that, as I don't think we'll see a flood of total dross because few people really want to take the time to transcribe 1867 articles about cats in a tree from the Nowhere, Arizona Daily Reporter, and, actually I think some of the "dross" can be quite interesting in a slice-of-life kind of a way (always assuming well-formed and scan-backed). And the real dross is usually so bad (no scans, raw OCR, etc) that it can be dealt with outside of this topic. I think part of the value of WS is the tiny, weird and wonderful, not just in blockbusters like War and Peace and Pultizers. I think I might like to see more of our articles strung together thematically via Portals, but that's another day's issue. Inductiveloadtalk/contribs 17:35, 6 July 2020 (UTC)[reply]
      • @Inductiveload: We appear to be mostly in agreement. But… instead of me dropping another wall of text on the remaining points of disagreement, maybe that means we're in a position to try to hash out a draft guidance / policy type page with the rough framework? Then we could go at the remaining issues point by point. Because I think I'm in with a decent chance to persuade you to my point of view on at least some of them, but this thread is fast getting unwieldy (mostly my fault). It would also probably be easier for the community to relate to now, and much easier to lean on in the future. --Xover (talk) 18:31, 6 July 2020 (UTC)[reply]
        • @Xover: If there are no more comments forthcoming after a couple of days, I think that makes sense. I don't want to railroad it: considering we have at least one !vote for "do nothing", I'd like to see if there are any other substantially different opinions floating about. Inductiveloadtalk/contribs 17:41, 7 July 2020 (UTC)[reply]

The quantity of text here has grown far faster than my ability to absorb it, so rather than continue to put it off, here's my position: I don't see any problem with transcriptions that are scan-backed, even if the transcription only covers a small fraction of the entire scan. If Sally chooses (say) to transcribe a favorite story, that happened to be published in an issue of Harper's back in the 1890s, and goes to the trouble of uploading the full issue, but only creates pages for the one story that interests her, I think that's great. It doesn't matter to me whether she intends to work on the other pages or not. If it's not scan-backed, but it's fairly high quality, I am personally willing to do some work trying to locate a scan and match it up to the text; I'd rather we take that approach, than deletion, though of course deletion is the better option in some cases where the scan is very hard to come by.

If all this has been said above, or if I've misunderstood the topic, my apologies. Please take this comment or leave it, as appropriate. -Pete (talk) 02:00, 8 July 2020 (UTC)[reply]

Apologies, I see I had missed the point.

I disagree with Xover's statement that a top-level page for a publication, with a link only to a single article within the publication, has "near-zero value." Such a page can serve an important function linking content together in ways that help the reader (and search engines) find the content they're looking for, or understand the context around it. For instance, A Critical Dictionary of English Literature is linked from the relevant Wikidata entry. The banner on the Wikisource page clearly tells a Wikisource reader that they won't find a full transcription here; and with a simple edit, it could link to a full scan on another site, or (with perhaps a little more effort) even transcription links here on Wikisource. This page has been here since 2010; we don't have any way of knowing what links might have been created elsewhere in the intervening decade. (I do think that new pages like this should not be created without a scan at Commons to be linked to.) -Pete (talk) 02:12, 8 July 2020 (UTC)[reply]

I'm really bad with walls of text, so I have only read a tiny portion of the above discussion. But I want to mention a couple of things that I think are worth considering in this discussion.
  • Most of the time, a mainspace "work" that is only a table of contents, but which has none of the actual content, and is not actively being worked on, can be (and should be) deleted as No meaningful content or history under our deletion policy.
  • A mainspace work that has only a little bit of content, but that content is a work unto itself within the scope of Wikisourse, should be kept. Most periodicals are like this. For an example, see the Journal of English and Germanic Philology which only has one hosted article, but that hosted article is scan-backed and firmly within scope.
  • On some occasions, empty mainspace works do have value. I ended up creating the page The Roman Breviary, depsite containing no actual content, mostly because there are a lot of works that link to it, using many different titles, and if someone uploaded a copy of the work under one title then many of the links would remain red because they point to different titles of the work. This could be easily solved by creating redirects to a simple placeholder page, so I did. I tried to make the placeholder page as useful as a placeholder page can be, as it contains useful information about the history and authorship of the work, and links to the Index pages where the transcription will take place.

Anyway those are my 2 cents, sorry if they are redundant —Beleg Tâl (talk) 00:40, 29 July 2020 (UTC)[reply]


Since there has been no extra input for a month, and not wanting this section to get archived without at least attempting a proposal, I have started a proposal #Collective work inclusion criteria above. Inductiveloadtalk/contribs 11:00, 25 August 2020 (UTC)[reply]

Since the proposal has now slipped off the main page (to here), with vague support for the first part (collective work inclusion criteria) and a fairly consistent opposition to the second (no-content pages), my plan is to transfer the first part, as guidelines rather than policy, to Wikisource:Periodical guidelines. As non-binding guidelines, they can then be worked on further in situ. Sound OK? Inductiveloadtalk/contribs 08:10, 16 April 2021 (UTC)[reply]
The example given in Wikisource:Periodical guidelines might be improved, PSM is and was an exercise that has gone its own way (no offense to @Ineuw:, this is a site under development and that is only one example).CYGNIS INSIGNIS 13:05, 17 April 2021 (UTC)[reply]
@Cygnis insignis: You would be wrong to think that I am offended. Remember that when I started, I knew everything. By now, so much of that knowledge is lost that I am happy to listen. Would you elaborate please? — Ineuw (talk) 19:50, 17 April 2021 (UTC)[reply]

I've created Bradshaw's Monthly Railway and Steam Navigation Guide (XVI) - it couldn't be done on one page, due to the very high number of template transclusions. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:52, 1 September 2020 (UTC)[reply]

@Pigsonthewing: The links in the toc on that page appear non-functional. Also, depending on just exactly which templates were the culprit, it is possible that you may be able to put all the content you wanted onto one page now due to some recent technical changes (template code moved to a Lua module which drastically improves performance and prevents hitting transclusion limits until much later). Xover (talk) 11:17, 14 September 2021 (UTC)[reply]
Create the Draft namespace to hold substantially empty works? Then delete if no improvement after months?--Jusjih (talk) 19:22, 1 November 2021 (UTC)[reply]
The issue is that the "substantially empty works" can have useful and complete content that stands alone. For example, an article from a scientific journal.
I would not want to see that either shunted into a Draft namespace to rot or deleted a few weeks down the line.
Index and Page namespaces provide our long term staging areas, and works can and do remain unfinished there for years. But what do we do when a self-contained piece of a larger work is ready? Inductiveloadtalk/contribs 20:29, 1 November 2021 (UTC)[reply]

Universal Code of Conduct News – Issue 1[edit]

Universal Code of Conduct News
Issue 1, June 2021Read the full newsletter

Welcome to the first issue of Universal Code of Conduct News! This newsletter will help Wikimedians stay involved with the development of the new code, and will distribute relevant news, research, and upcoming events related to the UCoC.

Please note, this is the first issue of UCoC Newsletter which is delivered to all subscribers and projects as an announcement of the initiative. If you want the future issues delivered to your talk page, village pumps, or any specific pages you find appropriate, you need to subscribe here.

You can help us by translating the newsletter issues in your languages to spread the news and create awareness of the new conduct to keep our beloved community safe for all of us. Please add your name here if you want to be informed of the draft issue to translate beforehand. Your participation is valued and appreciated.

  • Affiliate consultations – Wikimedia affiliates of all sizes and types were invited to participate in the UCoC affiliate consultation throughout March and April 2021. (continue reading)
  • 2021 key consultations – The Wikimedia Foundation held enforcement key questions consultations in April and May 2021 to request input about UCoC enforcement from the broader Wikimedia community. (continue reading)
  • Roundtable discussions – The UCoC facilitation team hosted two 90-minute-long public roundtable discussions in May 2021 to discuss UCoC key enforcement questions. More conversations are scheduled. (continue reading)
  • Phase 2 drafting committee – The drafting committee for the phase 2 of the UCoC started their work on 12 May 2021. Read more about their work. (continue reading)
  • Diff blogs – The UCoC facilitators wrote several blog posts based on interesting findings and insights from each community during local project consultation that took place in the 1st quarter of 2021. (continue reading)

unsigned comment by SOyeyele (WMF) (talk) 22:37, 10 June 2021‎.

Index:Robert Carter- his life and work. 1807-1889 (IA robertcarterhis00coch).pdf[edit]

First run through is done, and it's transcluded. Needs validation. Thanks in advance for any help. Jarnsax (talk)

Request for comment notification[edit]

Here is a link to a RFC on Meta concerning all Wikimedia projects. unsigned comment by Lionel Scheepmans (talk) .

Page image vanishes after loading[edit]

Whenever I try to edit in Page: namespace, the page image loads, and then immediately vanishes. I am proofreading against an empty box. I have blanked my .js and .css files, tried another djvu file, tried changing skins, tried changing browsers. Am I the only person experiencing this? This is a total blocker for me -- I might as well quit Wikisource if I can't get this fixed. Hesperian 23:24, 16 December 2021 (UTC)[reply]

After noticing RaboKarbakian's comment above, I discovered that the problem goes away if I "Enable the editing toolbar" in my preferences. I'm not exactly happy at being forced to turn on a toolbar that I don't want, but at least there is a workaround. Hesperian 23:31, 16 December 2021 (UTC)[reply]
Yeah, I tried it without the toolbar today and nothing has changed. Even with the toolbar, today I had to reload every other page to get the djimage to load. To the best of my knowledge, the only complaints have been about the changes in zoom and not being able to change the orientation and I wonder if people actually use the tools or just have them enabled....--RaboKarbakian (talk) 23:38, 16 December 2021 (UTC)[reply]
yeah, i have the new OCR button enabled but do not use it. no improvement to require the learning curve. this is visual editor redux, where the devs make their "improvements" without UX. it was hard enough getting the devs to put their button on the toolbar, rather than hovering over the image in the way. --Slowking4Farmbrough's revenge 01:14, 17 December 2021 (UTC)[reply]
This was fixed within hours over a week ago, but wasn't merged until today: Since today is Friday, there are now no backport windows until Monday. I'm personally not available today at the normal window times of 1200, 1900 and 0000 UTC anyway; if anyone wants to request an emergency backport, they'll have to do it themselves or find someone who can. I have, however, done a backport patch for that person to use:
The whole torture of actually getting OSD deployed properly (there have been a lot of compounding issues, including the main developer going AWOL, the usual lack of review capacity/interes, a near total lack of engagement on outstanding UX questions and, unrelated to WS, missed MW releases for weeks at a time) is why Wikisource needs a proper Code Steward to take point and make sure important fixes don't just rot on Gerrit and, when fixed, get backported promptly. Inductiveloadtalk/contribs 11:28, 17 December 2021 (UTC)[reply]
huzzah, and beware, you may have self-nominated. i would support a individual grant, or set up the go fund me / patreon. --Slowking4Farmbrough's revenge 03:49, 18 December 2021 (UTC)[reply]

So, that magical Monday has come and gone, and the problem still persists.--RaboKarbakian (talk) 15:39, 24 December 2021 (UTC)[reply]

There are actually no Release Engineering backports (or deploys) this week or next because of the holidays. I didn't realise there wasn't even a window on Monday when I wrote that. This will not, therefore, be resolved until the 5th Jan at the earliest. Inductiveloadtalk/contribs 16:01, 24 December 2021 (UTC)[reply]
Please excuse me for whining on a holiday. Thank you for the information, and eh, Seasons Greetings!--RaboKarbakian (talk) 17:02, 24 December 2021 (UTC)[reply]

Help with columns spanning page breaks[edit]

For the text Index:Axiochus (Spenser, 1592).pdf, I have implemented two columns for the purpose of presenting both the original and a modernized version (without archaic spellings) of the source text. In the Transcluded text however, Axiochus (Spenser)/Axiochus, page breaks are causing new lines between pages. How would I go about fixing this, such that transitions are seamless between pages. On Help:Page breaks I saw templates relating to lists and tables, so might it be advised to use the "Column list" template as opposed to "columns" to fix this? Oryang7 (talk) 05:09, 17 December 2021 (UTC)[reply]

I hate to say this, but I personally don't think you should try to do any such thing. Wikisource is about presenting (relatively) faithful digitized versions of the source document, even when that source uses archaic spellings or may be otherwise difficult to read/comprehend by modern readers. I can see you've put a fair bit of effort into this, so I don't say this lightly, but I think you should just be presenting the text as written, rather than trying to modernize it. — Dcsohl (talk)
18:43, 17 December 2021 (UTC)[reply]
Do you know if it's possible to someway preserve the modernized version on wikisource? If I removed the modernized version from the transcluded text might it be possible to create another page, unsourced, of the modernized version? Or, if it needs to be sourced, may uploading a pdf of the modernized version, which I assume could be done as the original is out of copyright, and transcluding it to a seperate page suffice? Or, and I don't know if this is already present on wikisource, is there a way to implement a feature allowing readers to toggle between the original and modernized versions on the single transcluded page? Oryang7 (talk) 23:49, 17 December 2021 (UTC)[reply]
I'm not entirely sure whether to point you to Wikisource:Annotations or Wikisource:Translations, but I would think reviewing those two pages might be helpful to you. — Dcsohl (talk)
19:51, 22 December 2021 (UTC)[reply]

Tech News: 2021-51[edit]

22:05, 20 December 2021 (UTC)


I would like to propose bringing InternetArchiveBot to Wikisource to fix dead links on the wiki. Although individual pages in the page namespace on Wikisource tend to not have external links, a recent database query found that there are over 1.3 million external links on English Wikisource. Given that any website can go offline at any time, that is a potentially large number of broken links on Wikisource. InternetArchiveBot is very flexible and customizable, designed to run on small and large wikis alike. The InternetArchiveBot development team is happy to work with the Wikisource community to make sure the bot recognizes all the local reference, web archive, and dead link templates. We are happy to answer any questions you have. Harej (talk) 23:47, 20 December 2021 (UTC)[reply]

What? No, absolutely not. For one thing, and despite your fondness for throwing around large numbers, enWS generally does not use external links except those to… the Internet Archive and other archives that can be presumed to be stable and persistent. That other external links occasionally occur and occasionally break barely rates as an annoyance. But more importantly, no external entity with goals and priorities different from the Wikimedia movement—but who seems happy to spend significant chunks of change paying people to edit the projects, act as their advocates, and developing and running bots—should be allowed to run a bot designed to add the largest possible number of links from Wikimedia projects to their own service. And it certainly doesn't help that whenever this paid team has met with community pushback and criticism they've refused to engage with, much less address the concerns of, the community; opting instead to rely on proxy champions extolling the virtues of the bot and its big huge number of edits ("Look look, lots of edits! Millions of links!").
I've told you (the collective you) before: if you want to contribute to the Wikimedia movement projects rather than just inflate the number of high-value incoming links to the WayBack Machine, put some effort into your bibliographic metadata story. We very much rely on the IA book scans, and the state of their bibliographic data is just atrocious. Competing for the same volunteers through OpenLibrary instead of joining forces is just dumb. Building a pretty (user friendly) frontend to crowd-source and manage that data on Wikidata (or something else Wikibase-based) and integrating with WikiCite for the Wikipedias and integrating tightly with Proofread Page for the Wikisourcen would have great synergies for both communities; and it would put the volunteer effort towards increasing quality rather than mere number of links. The Wikisourcen spend a significant amount of volunteer effort researching, documenting, and managing bibliographic metadata connected to book scans sourced from the IA; and all that effort currently stays locked up in unstructured form, instead of directly and immediately contributing value to the global bibliographic web including IA. Xover (talk) 08:00, 21 December 2021 (UTC)[reply]
Yes please. Excellent idea. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:44, 21 December 2021 (UTC)[reply]
Weak support: the vast, vast majority of external links are to the IA itself, Hathi, Google or some other text repository. However, we do have a non-zero number of links, especially in, Author talk spaces which represent valuable contributor research and can indeed sometimes go dead.
But I'll agree with Xover: this is not the best way that the IA can assist Wikisource. Critically, archiving a handful (and on the scale of the WBM, it's a very small handful) of enWS links is also not the best way that Wikisource can assist the IA: the biggest moan about the IA, that almost literally everyone Wikisourcerer who has been to the IA has, is not that the metadata is very bad, that's just life in the library, but that it cannot be changed. If nothing else: Internet Archive ID (P724) provided perfect access to Wikidata metadata which is much better, when it exists! Inductiveloadtalk/contribs 10:57, 21 December 2021 (UTC)[reply]
meh effort better spent at wikidata, the notion of IA archiving its own website, seems a little circular, but there is also google books, and hathi trust. and yeah, a metadata cleanup drive with some mechanism for crowdsourcing IA metadata is more a priority for this community. but thanks for thinking of us. cheers, racer x.--Slowking4Farmbrough's revenge 23:36, 21 December 2021 (UTC)[reply]
and thanks for the linking Introducing Trusted Book Providers, maybe some round tripping of metadata would improve trust. --Slowking4Farmbrough's revenge 15:54, 22 December 2021 (UTC)[reply]

Template:Highlights - change to rotating highlights[edit]

Hi all, new here but wanted to pick up what has been said on the Template:Highlights talk page and further back in the main discussion archives.

Currently, the highlights section on the main page is a static depiction of what this project has to offer with some US-centric elements. It would be better to change to a rolling display of validated articles that are of interest to the wider community. Whether this is done randomly throughout the high-quality sources or leans on nominated/ voted for sources, I am sure there is a way to modify this to better reflect both the diversity of content across a global setting. Jamzze (talk) 06:03, 22 December 2021 (UTC)[reply]

Symbol support vote.svg Support doing something different. I'm not sure if rotating or just a bigger/wider list of portals is better. We have a lot more chunkier portals now than we did when that list was created (but still lacking).
I do not support a voting system, that's just going to rot and go stale. If we wanted a way to highlight excellent portals, we can do that better (e.g. include in Featured Texts, have a Featured Portal, or whatever). However, we don't really have enough Portals that good. Inductiveloadtalk/contribs 08:36, 22 December 2021 (UTC)[reply]
Yeah I think a new list of highlighted areas would be good! Who could action this, though? Jamzze (talk) 21:48, 27 December 2021 (UTC)[reply]
Two out of six of the lines are US-centric. For an English-language project, that's entirely reasonable and not something that needs to be "remedied". {{highlights}} is Used on the Main Page to display highlighted collections and areas on Wikisource. and is paired with the "Explore Wikisource" box just below it. Together they provide visitors with a broad overview and multiple ways to start navigating Wikisource.
That they should point to high-quality content is a requirement, but is not their main purpose: these are not "featured" areas of Wikisource (nor do or should all the links point to portals). We could have featured portals etc. too, but that's a separate issue: our featured content is up in the top left monthly featured text box. Any further "featured something"should take that as a starting point.
In other words, {{highlights}} can almost certainly be improved, but that would be "further improve" and not "fix a big problem with". And Wikisource not being Wikipedia, we don't really need to worry about a "global perspective" except to the extent that English is a world language for which we have content from literally every continent (including Asia). If we can find better places to direct visitors than the "US history" and "US laws" collections then by all means, but I'd need to see some concrete proposals for that. Xover (talk) 09:34, 22 December 2021 (UTC)[reply]
  • Pictogram voting comment.svg Comment I would agree that a static highlight section is not helpful for us with all our content. Whether a dynamic list is the best, or a curated list based on our input, I am not sure. We are not brilliant at curating portals for display. — billinghurst sDrewth 12:13, 22 December 2021 (UTC)[reply]
  • Pictogram voting comment.svg Comment Just adding to this as I haven't seen any changes come about because of the above discussions. Just wondering who would be able to mix-up the highlights section to include other things? Jamzze (talk) 13:30, 7 January 2022 (UTC)[reply]
  • Pictogram voting comment.svg Comment The last time that I made changes to the Highlights, I had the sense that the listings were selected because they are larger and/or general listings by topics and genre. Yes, the History listings are US-centric, and if someone could identify a better set of Portals in good shape, I'd certainly favor changing that line. But I'm not sure that having a rotating list would help anyone, as that means that the section is randomized for readers, which I don't think would be popular with visitors who return only to discover they cannot find the listing they followed previously. The "Highlights" are essentially the topical listings, as opposed to the Author / Era listings which appear below that section. IMO, the best way to improve this section is to work to improve key Portals on Wikisource. This can take a lot of work, but it can be done. --EncycloPetey (talk) 01:14, 11 January 2022 (UTC)[reply]


The documentation to the template {{Lang}} says that the code for the language being displayed should be provided using ISO 639. However, there many languages have different codes in ISO 639-1, ISO 639-2 and ISO 639-3. Which of these should be used? --Jan Kameníček (talk) 18:57, 22 December 2021 (UTC)[reply]

@Jan.Kamenicek as far as I know, they HTML lang attribute can use either two or three-letter language codes (so ISO 639-1 or -2), as well as a two-letter country code suffix. According to, this is RFC 3066, and you can also have other IANA "subtags" for "variants", the example given is "en-scouse", but there are lots.
Generally, just the two letter one will do in most cases unless you really need to drill down into the language variant. Inductiveloadtalk/contribs 19:11, 22 December 2021 (UTC)[reply]
According to this document from W3C, the standard is IETF BCP 47, which is something of a catchall that "combine[s] subtags from other standards such as ISO 639, ISO 15924, ISO 3166-1 and UN M.49." — Dcsohl (talk)
19:12, 23 December 2021 (UTC)[reply]

Naming convention[edit]

I have a question that is not yet governed by Wikisource:Naming conventions & Help:Disambiguation.

A work has two different editions published in the same year. How should we name these editions, such as

  1. "aaa (2021a)" and "aaa (2021b)",
  2. "aaa (1st edition)" and "aaa (2nd edition)",
or otherwise?

Thank you.

--Miwako Sato (talk) 11:41, 23 December 2021 (UTC)[reply]

@Miwako Sato: What actually distinguishes the editions? The usual go-to for disambiguation are publisher and place of publication. If neither is sufficient we have to get more creative. "1st edition" and "2nd edition" may be reasonable options for some cases. For laws and similar it may make sense to use both month and year, or even a full date. It's a bit of an edge case, so we don't really have firm guidance or practice on it, and the details of your particular case will be necessary to suggest anything sensible. Xover (talk) 11:50, 23 December 2021 (UTC)[reply]
The editions in question were published in the same year, by the same publisher, and at the same place. The only thing that distinguishes them is their contents (the subsequent edition contains revised & additional contents). So, in this case, I think "1st edition" and "2nd edition" would be appropriate (because it's a book). Thank you so much, and special kudos for a very quick response! --Miwako Sato (talk) 12:04, 23 December 2021 (UTC)[reply]


The Works of the Late Edgar Allan Poe/Volume 1/The Domain of Arnheim

Wikipedia @ 20 (published by MIT Press)[edit]

I am starting to translate individual essays from Wikipedia @ 20 (published by MIT Press) to Croatian and I wonder if it would be good to import the whole book (licence), as well as to advance with translations here on Wikisource? --Zblace (talk) 15:27, 26 December 2021 (UTC)[reply]

Upcoming Call for Feedback about the Board of Trustees elections[edit]

You can find this message translated into additional languages on Meta-wiki.

The Board of Trustees is preparing a call for feedback about the upcoming Board Elections, from January 7 - February 10, 2022.

While details will be finalized the week before the call, we have confirmed at least two questions that will be asked during this call for feedback:

  • What is the best way to ensure fair representation of emerging communities among the Board?
  • What involvement should candidates have during the election?

While additional questions may be added, the Movement Strategy and Governance team wants to provide time for community members and affiliates to consider and prepare ideas on the confirmed questions before the call opens. We apologize for not having a complete list of questions at this time. The list of questions should only grow by one or two questions. The intention is to not overwhelm the community with requests, but provide notice and welcome feedback on these important questions.

Do you want to help organize local conversation during this Call?

Contact the Movement Strategy and Governance team on Meta, on Telegram, or via email at msg(_AT_)

Reach out if you have any questions or concerns. The Movement Strategy and Governance team will be minimally staffed until January 3. Please excuse any delayed response during this time. We also recognize some community members and affiliates are offline during the December holidays. We apologize if our message has reached you while you are on holiday.


Movement Strategy and Governance --Civvi (WMF) (talk) 10:57, 27 December 2021 (UTC)[reply]

112 Days' Hard Labour[edit]

The work of Hubert W. Peet, Quaker journalist and imprisoned WWI conscientious objector, who died in 1951, just fell out of copyright.

So here's his 1917 essay "112 Days' Hard Labour", which I have just transcribed. A safe, healthy and happy new year to you all. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 00:00, 1 January 2022 (UTC)[reply]

This is very relevant to my interests! Thanks. —Justin (koavf)TCM 05:07, 2 January 2022 (UTC)[reply]

A Study in Scarlet[edit]

So, basically in Monthly Challenge (January 2022), we have Index:Beeton's Christmas Annual 1887.pdf that contains A Study in Scarlet. However, there is already A Study in Scarlet (Index:A study in scarlet.djvu). What's next? Mnafisalmukhdi1 (talk) 12:07, 6 January 2022 (UTC)[reply]

@Mnafisalmukhdi1: See Help:Disambiguation. Xover (talk) 12:32, 6 January 2022 (UTC)[reply]

Unnecessary changes without community consultation.[edit]

Some time ago, keeping header/footer open on first edit was removed and changed to a guessing game. I ask that this feature be restored. There is no logic to it's current implementation because after editing the header, I close it to gain more vertical editing space. Opening a new page for edit, I want it open. I consider this a reasonable request for an unnecessary change. Ineuw (talk) 17:53, 6 January 2022 (UTC)[reply]

That has never, to my knowledge, been the intended behaviour. It's always just been a simple binary on/off based on the proofreadpage-showheaders option (which is usually controlled by the icon in the toolbar), and doesn't have (and never had) special handling for non-existing pages. Inductiveloadtalk/contribs 18:07, 6 January 2022 (UTC)[reply]
There was an option on the Preferences/Edit, grouped near the top of the page which is now titled "General". It either opened the header, or kept it closed when opening a Page for edit. It might be worth to take a look at the edit history of the module.Ineuw (talk) 18:17, 6 January 2022 (UTC)[reply]
The only header/footer-related setting that has ever been in the ProofreadPage module is "header & footers on/off". As it has always been stored in the user preferences, it has always been persistent (i.e. when you reload a page, it takes the setting it last had). Recently, the location in preferences was moved within the Editing tab from "Editing → General" to "Editing → Proofreading interface options". Just as before, it's hidden when you have the editing toolbar on (the logic there apparently being that there's an icon for you if you have the editing toolbar, so you don't need the preferences entry too, not sure I agree that really avoids confusion, but there it is). Inductiveloadtalk/contribs 11:06, 7 January 2022 (UTC)[reply]

A Study in Colour[edit]

I was just going to add the images for page 16 however the page appears out of alignment by one place. The image should be on the page before. Can this be realigned please? Thanks Sp1nd01 (talk) 22:04, 6 January 2022 (UTC)[reply]

@Sp1nd01: Nothing is missing. You picked a Google scan pdf, where at one time they deleted all graphics. The missing picture is a page decoration. Perhaps you can find a djvu copy on the internet archive. Ineuw (talk) 23:13, 6 January 2022 (UTC)[reply]
Thanks, I am unable to find a copy on the internet archive, however hathi trust appear to have the same text with better quality images here, so I added those. Hope that's ok for now. Sp1nd01 (talk) 10:32, 7 January 2022 (UTC)[reply]

Creating a category for an author[edit]

Hi all!

Can a category be created for a specific author? E.g. I would like to create a category such as "William Morris" to tag onto the documents they have authored so these can show up easily on a category page. Or, is there already a way to see all the documents that are assigned to a specific author? I know William Morris has an author page, but I feel like this does not include all their work, so I am more interested in understanding if their is meta data that can be used to find all their bits of work that might already exist, and not if creating a category for that specific author might be possible. Best - Jamzze (talk) 13:34, 7 January 2022 (UTC)[reply]

There are two way to handle this:
  1. All Morris's works at Wikisource (and any not at Wikisource) should be on his author page. If they are not, they should be added. Thus, there should be no pages that would be in a hypothetical category that are not also on the author page, so the category doesn't do anything new.
  2. For the technical side of things (i.e. finding a list of all works by Morris), you'd be better off with a query like this: than relying on Wikisource to keep thousands and thousands of categories correctly filled. Also, a category can get very fuzzy as to whether it contains works, editions, parts of works, disambiguations, versions, translations or what. A Wikidata query will let you target exactly what you want. Indeed, one day, Wikisource should probably be pulling that data from Wikidata itself rather than maintaining it separately. If any data is missing, the correct thing to do is add it at Wikidata rather than construct a parallel system here.
Inductiveloadtalk/contribs 14:31, 7 January 2022 (UTC)[reply]
Interesting note, I believe (IIRC) that the way WS historically used to deal with authors, way back when, was by using categories, but the community came to the determination that the categories were not as efficient as the extra namespace. PseudoSkull (talk) 15:19, 7 January 2022 (UTC)[reply]
Thank you for this! I agree with the future aspect of pulling data from wikidata - seems more effective. Thanks again. Jamzze (talk) 23:46, 7 January 2022 (UTC)[reply]
yeah, categories are a crowd source hack, for subject indexing, from before wikidata. (and maintenance pain point) we should implement a "wikisource author" item like "commons category" [6] so we could leverage search, and use wikidata to generate lists of works. --Slowking4Farmbrough's revenge 23:49, 7 January 2022 (UTC)[reply]

List author works[edit]

@Inductiveload: Piggybacking off of your comment above, just to confirm, your understanding of Wikisource policy and best practice is that we should list all works on an author page, even if some of them have unacceptable copyright restrictions to actually host said works here, correct? —Justin (koavf)TCM 01:50, 8 January 2022 (UTC)[reply]

Well I don't know if it's policy policy, but if I'm adding a list of works, I'll often add copyrighted ones too and an explanation (eg {{copyright renewal}}). You can also link to the work externally if it's hosted legally elsewhere. This can happen, e.g. non-US sites like bibliowiki was, as well as sites that present work under licences like CC-BY-SA. There's obviously a limit, as current authors like JK Rowling are around 100 years from any PD work, so there's not much point, but sometimes there are exceptions like Cory Doctorow. Inductiveloadtalk/contribs 11:13, 8 January 2022 (UTC)[reply]


I don't know that I can really point at this template as being inherently bad (or else I would've sent it to WS:PD), but one issue I have with the template is that in some cases we may never know what the author's full name was beyond initials. Especially considering that most of the people we collect data for lived in times when documentation was scarce and much harder to come by than today (and it gets worse the further back in time you go), a part of me doesn't think we should put so much emphasis on the research by means of a large maintenance template. Also, for more modern and perhaps obscure authors, finding a middle name may require research that the author, who is still alive and well today, doesn't want you doing, and I need not elaborate what kind of research I'm talking about. I think that wanting further information on an author's name is a valid sentiment to have, but there should be another way to resolve this sentiment; perhaps a category, or a less in-your-face notice. Thoughts? Pinging @Beleg Tâl, @Billinghurst: PseudoSkull (talk) 23:26, 8 January 2022 (UTC)[reply]

Middle names only became more customary in the 19th century as the newly rich looked to mimic a practice that was used by the truly rich/nobles. I think that it may also align with families decreasing in size. If you feel that a person has a doxing issue, omit it, or stick it on the talk page. Typically when I am researching middle names and have no luck determining what they are, then I move them to the talk page with commentary, so using the difference between author and author talk as my indicators. Part of the reason that the template is of use is where we have 19th century authors with just initials, no first or middle name. Be guided by sense, it is not a policed area. — billinghurst sDrewth 00:38, 9 January 2022 (UTC)[reply]
@Billinghurst: I think slapping it on a talk page is much more reasonable; I just think a box like this shouldn't be slapped onto a main page unless absolutely crucial. The names you mentioned with both the first and middle initial missing are a good case for that, while I don't know that I can say the same for one with just the middle initial missing. PseudoSkull (talk) 00:50, 9 January 2022 (UTC)[reply]
The current process came about for good reasons as we were having page duplicates and there were not reasonable efforts being made to expand names. Your thoughts don't solve the problem or better resolve the issue so I am not inclined to agree with your concerns. In short I still prefer the current methodology. My moving the template to talk pages was to help me to know what I had investigated and what I had not and where in my estimation that I was not going to progress further. If there is a concern about doxing having a wikidata page is going to be way more problematic than an author page, and as there are means to manage those problematic cases, I don't see a requirement for change. If you have concerns over the look of the template, or the positioning of the template, then have that as a conversation, not roll it all up into the "I don't like it" argument. — billinghurst sDrewth 20:42, 9 January 2022 (UTC)[reply]

Wiki Loves Folklore is back![edit]

Please help translate to your language

Wiki Loves Folklore Logo.svg

You are humbly invited to participate in the Wiki Loves Folklore 2022 an international photography contest organized on Wikimedia Commons to document folklore and intangible cultural heritage from different regions, including, folk creative activities and many more. It is held every year from the 1st till the 28th of February.

You can help in enriching the folklore documentation on Commons from your region by taking photos, audios, videos, and submitting them in this commons contest.

You can also organize a local contest in your country and support us in translating the project pages to help us spread the word in your native language.

Feel free to contact us on our project Talk page if you need any assistance.

Kind regards,

Wiki loves Folklore International Team

--MediaWiki message delivery (talk) 13:14, 9 January 2022 (UTC)[reply]

Cleanup of "External Links", "See Also" sections in the mainspace[edit]

Does anyone know how to generate a list of every page in the mainspace that has a "See also" L2 section (with any capitalization, i.e. "See Also" as well), "External links", "External links and ...", or "... and external links"? I see there are quite a lot of works (all seem to be unsourced works), which use these sections for listing out external links and related works, in the style that we all know Wikipedia uses, and it is inappropriate for Wikisource. External links related to the content presented, that would help with transcription etc., are arguably appropriate to link in the talk page, or maybe even in the header template if absolutely necessary, but definitely not in the transcription space. I'd like to do a mass cleanup of all of these. Can anyone produce a script that lists all instances of this? @Inductiveload, @Billinghurst: PseudoSkull (talk) 16:57, 9 January 2022 (UTC)[reply]

Rough search

Long-inactive WikiProjects[edit]

I notice there are several projects in Category:WikiProjects that are inactive and have apparently been inactive for over 10 years, for example Wikisource:WikiProject Barack Obama. Is there a way we can tag these as inactive with a template, or at least a category? Or is there another preferred method of communicating that the information there is largely historical? PseudoSkull (talk) 19:15, 9 January 2022 (UTC)[reply]

Why? What is the purpose? Projects are projects, they are only inactive when someone isn't working on them, how do we know? What are we achieving? — billinghurst sDrewth 20:55, 9 January 2022 (UTC)[reply]
@Billinghurst: Okay, I didn't think there'd be opposition, so here we go. Q: Why? A: Maintenance. Q: How do we know? A: Given the example I gave above of WikiProject Barack Obama, the evidence I presented indicates to me that the WikiProject itself is not being actively worked on and hasn't been for at least 10 years. Whether or not individuals have edited or created transcriptions related to or by Barack Obama is unrelated however, because those editors may not have even been aware that a WikiProject for it existed. Q: What is the purpose? What are we achieving? A: I think that having a Category:Inactive WikiProjects is useful because it takes out the clutter that exists currently in Category:WikiProjects of many that are clearly abandoned. I get what you're saying, the line between active and inactive is somewhat hard to establish—but the line I suggested was some evidence of complete inactivity on the project within a roughly 10-year period, that is, never having been used by anyone. Note I am not suggesting to do this for projects with only one contributor, who has been active in that project. The category would show the difference between abandoned projects and active ones. I feel like the main category should be for those who are looking for active projects specifically. An inactive template at the top of the page would serve a similar purpose: that is, to let users know the project has been inactive for a long time. If someone wants to reinstate the project, or disagrees with the template/category being placed there, they can remove the template and the category and just start working on it again. Priority: Not a pressing issue, but not every issue has to be pressing to be brought up here—just a convenience and it cleans up a bit. PseudoSkull (talk) 22:47, 9 January 2022 (UTC)[reply]
you are importing some wikiproject drama from english, and using maintenance categories, which we really don't do. tidying up inactive projects is a waste of effort. an inactive project is better than none: like a started index, it provides a place for future collaboration. but editors have moved off-wiki in content collaboration, in response to drama such as this on english. --Slowking4Farmbrough's revenge 00:07, 11 January 2022 (UTC)[reply]
@Slowking4: It is unfortunate that you believe I am trying to "import drama" from somewhere because I had no such intentions. I had not even remembered that enwiki had such a system. I ragequitted enwiki long ago and will not be active there again. Very well, there are decent arguments for lacking the template and as I said it is not a pressing issue. If the community doesn't want it, I'll respect it. There are better battles to fight. PseudoSkull (talk) 00:44, 11 January 2022 (UTC)[reply]
There is indeed someone being very dramatic here…
@PseudoSkull: I think tagging inactive WikiPojects as {{historical}} is a good idea (and we can make a dedicated template for this if we want a tracking category). It's about managing user expectations: there's nothing worse than being led to believe there is a venue for assistance or source of good practice, only for requests to languish unanswered indefinitely or the guidelines turning out to be way outdated (usually because a patrolling admin drops by your talk page with stern admonishments). There's no need to be aggressive in such tagging (most of them are moribund for 5+ years anyway), and anyone should feel free to remove the tag and start a given project up again at any time, but for most such projects adding the tag should be entirely uncontroversial.
My only real caution would be things like EB1911 where the WikiProject pages might not see any activity but the associated work has ongoing efforts. In those cases the WikiProject might have good and current best practice guidance, and might conceivably run into issues needing discussion (and hence get active discussion on the WikiProject talk page) only every several years. Xover (talk) 06:57, 11 January 2022 (UTC)[reply]

Wikisource:WikiProject Biographical dictionaries is a long term project where you would hardly ever see activity on the project page except when I occasionally add works. The project in itself has lots of uses, even just for myself to see what and where. None of the activity takes place there. So again what is an active project and what is an inactive project. We seem to have an solution in search of a problem. Using one project as the source of a holisitic problem is not useful. Work out what it is the real issue with that project and look to see whether it is actually close to complete, or whether it needs a synopsis that addresses the current situation and reflects a new reality of "moribund" though incomplete. The DNB and EB1911 are other projects that don't have high activity on the project pages though on the odd occasion something pops up. So, again, no, go back to my original questions they are not suitably addressed. Otherwise sorting/scoping the projects may be another solution. Working out a better scope for highly active, or long term projects. The problem here isn't activity.
user:slowking4 that was a really unhelpful comment. Your issues with enWP are yours, and you do more importing of the difficulties than anyone else. Get over enWP. — billinghurst sDrewth 10:43, 11 January 2022 (UTC)[reply]

other wikis are a cautionary tale. the pattern is clear: "smartest problem solver in the room" + "let's impose order on the chaos" = "hell is other people". you see the same thing at wikidata, where people mass change descriptions to include dates, as discussion continues. i.e. "my ontology" > "your ontology". we need sociological methods in a distributed environment, but the STEM problem solvers do not do soft solutions. we need to adopt librarian standards of practice, but without cataloging hard coding. we could do a wikiproject quality circle, but you would be distracting from editing page space. --Slowking4Farmbrough's revenge 14:28, 11 January 2022 (UTC)[reply]
I think the "issue" (scary quotes intentional) here is that if a user assumes a WikiProject is active, questions can go unnoticed and therefore unanswered. I know from experience at other projects how annoying that can be and how dispiriting it can be. I do not know if that's actually happening, but it's quite possible: not all the WikiProjects will be carefully watched years or even decades after activity, so I think it's not unfair to warn users who don't know that the answers to their questions may be better at WS:S or WS:S/H. Inductiveloadtalk/contribs 14:48, 11 January 2022 (UTC)[reply]

Text to follow a circular path[edit]

Is there any way, short of SVG, to wrap six or eight Unicode characters into a circle? The ones in rectangular arrays can be managed with Template:Aligned couplet, but I'm stuck on how to do circles. (use case). HLHJ (talk) 20:54, 9 January 2022 (UTC)[reply]

The extensions of score and math are the most likely avenues. If it was me I would have just do a screenshot and add it as an image. Don't overthink it in my opinion, as it is not obvious to me that it has value as text. — billinghurst sDrewth 20:57, 9 January 2022 (UTC)[reply]
Messy but possible in CSS:
But I agree with billinghurst: just use an image. Hesperian 23:05, 9 January 2022 (UTC)[reply]
Yes, Javascript seems worse than an image, really. I'll do that, with a good alt text. Thank you. HLHJ (talk)
Another pretty gross hack is using a table. You can individually rotate characters x degrees with CSS and put them all in cells. :/ —Justin (koavf)TCM 17:48, 10 January 2022 (UTC)[reply]

Community Wishlist Survey 2022[edit]

Community Wishlist Survey Lamp.svg

The Community Wishlist Survey 2022 is now open!

This survey is the process where communities decide what the Community Tech team should work on over the next year. We encourage everyone to submit proposals until the deadline on 23 January, or comment on other proposals to help make them better. The communities will vote on the proposals between 28 January and 11 February.

The Community Tech team is focused on tools for experienced Wikimedia editors. You can write proposals in any language, and we will translate them for you. Thank you, and we look forward to seeing your proposals! SGrabarczuk (WMF) (talk) 18:10, 10 January 2022 (UTC)[reply]

Tech News: 2022-02[edit]

01:23, 11 January 2022 (UTC)

Call for Feedback about the Board of Trustees elections is now open[edit]

You can find this message translated into additional languages on Meta-wiki.

The Call for Feedback: Board of Trustees elections is now open and will close on 7 February 2022.

With this Call for Feedback, the Movement Strategy and Governance team is taking a different approach. This approach incorporates community feedback from 2021. Instead of leading with proposals, the Call is framed around key questions from the Board of Trustees. The key questions came from the feedback about the 2021 Board of Trustees election. The intention is to inspire collective conversation and collaborative proposal development about these key questions.

Join the conversation.

Best regards,

Movement Strategy and Governance

Xeno (WMF) (talk) 01:50, 13 January 2022 (UTC)[reply]

I for one am utterly thrilled that the BoT has elected a serial startup founder involved in fintech, property and recruitment "tech" with an crypto-monkey avatar who hypes NFTs on Twitter and co-founds companies with illegal cookies (there's no option but to accept ad/tracking cookies, which is illegal in Europe). Just the kind of disruption needed. After all, he used to work closely with communities at Reddit and that's a healthy community with a perfectly fine relationship with the parent organisation and the site certainly doesn't push unpopular design decisions top-down and use dark patterns like requiring use of apps to simply read content. Oh and by the way, the way to access some of "the conversation" on the BoT election also needs you to install Telegram on your phone. Inductiveloadtalk/contribs 11:03, 13 January 2022 (UTC)[reply]
In anyone wonders why the link doesn't show it, he got rid of the NFT ape avatar and deleted the retweet. Inductiveloadtalk/contribs 15:15, 13 January 2022 (UTC)[reply]
don't know why you are grumpy about BoT now. he merely validates the NFT attitude of Jimbo. it is the same old techno-idealism, with little experience of non-profit governance. they think he has some knowledge of global south. so it goes. --Slowking4Farmbrough's revenge 03:38, 15 January 2022 (UTC)[reply]

The Kreutzer Sonata translator[edit]

This is an unsourced work that appears to have been taken from this collection, but I'm unsure.

Our work lists Isabel Florence Hapgood as the translator. However, the book I believe was the source lists a "Benj. R. Tucker" as the translator. However we have a problem yet again, because the translator's preface is apparently verbatim the same as this, and that listed there as written by Adolphus Norraikow, suggesting he is the translator.

This was first doubted by an IP on the work's talk page.

So then who is the real translator? PseudoSkull (talk) 17:08, 13 January 2022 (UTC)[reply]

@PseudoSkull: The Wikipedia article w:Church_and_State_(by_Leo_Tolstoy) seems to indicate that Benjamin R. Tucker did translate some texts by Leo Tolstoy. I have also found some article on the web explicitly stating that Tucker translated the Kreutzer sonatas Tylopous (talk) 17:37, 13 January 2022 (UTC)[reply]
In general, I would say we should proofread one translation. The whole work isn't that long... In general the Tolstoy works we have were not in good shape and these unsourced translations can be confused between translators, editors etc. One problem we had is that a bunch of the texts were of very poor quality (copied pasted raw OCR) and then someone else might have been replaced by a different version that was cleaner but a different translation but not updated the translator etc. MarkLSteadman (talk) 17:57, 13 January 2022 (UTC)[reply]

obsolete licence template offered when uploading a file to WS[edit]

When uploading a file to WS, text of one of the licenses offered by Special:Upload says "First published in the United States before 1925", which is an obsolete offer and should be replaced by "1927". When this offer is chosen, the obsolete template {{PD-1923}} is added to the file page. Could this be fixed and if possible, set so that the text offered by kept changing every year? --Jan Kameníček (talk) 17:49, 15 January 2022 (UTC)[reply]

Merge two Indexes and Delete One[edit]

Can someone merge Index:Seven Poems, E. E. Cummings, 1920.djvu into Page:The Dial (Volume 68).djvu/30 and delete the first Index? Languageseeker (talk) 19:43, 15 January 2022 (UTC)[reply]

Yes check.svg Done --Jan Kameníček (talk) 21:43, 15 January 2022 (UTC)[reply]

Tech News: 2022-03[edit]

19:55, 17 January 2022 (UTC)

Talk to the Community Tech[edit]

Community Wishlist Survey Lamp.svg


We, the team working on the Community Wishlist Survey, would like to invite you to an online meeting with us. It will take place on 19 January (Wednesday), 18:00 UTC on Zoom, and will last an hour. This external system is not subject to the WMF Privacy Policy. Click here to join.


  • Bring drafts of your proposals and talk to to a member of the Community Tech Team about your questions on how to improve the proposal


The meeting will not be recorded or streamed. Notes without attribution will be taken and published on Meta-Wiki. The presentation (all points in the agenda except for the questions and answers) will be given in English.

We can answer questions asked in English, French, Polish, Spanish, and German. If you would like to ask questions in advance, add them on the Community Wishlist Survey talk page or send to

Natalia Rodriguez (the Community Tech manager) will be hosting this meeting.

Invitation link

We hope to see you! SGrabarczuk (WMF) (talk) 00:21, 18 January 2022 (UTC)[reply]

Subscribe to the This Month in Education newsletter - learn from others and share your stories[edit]

Dear community members,

Greetings from the EWOC Newsletter team and the education team at Wikimedia Foundation. We are very excited to share that we on tenth years of Education Newsletter (This Month in Education) invite you to join us by subscribing to the newsletter on your talk page or by sharing your activities in the upcoming newsletters. The Wikimedia Education newsletter is a monthly newsletter that collects articles written by community members using Wikimedia projects in education around the world, and it is published by the EWOC Newsletter team in collaboration with the Education team. These stories can bring you new ideas to try, valuable insights about the success and challenges of our community members in running education programs in their context.

If your affiliate/language project is developing its own education initiatives, please remember to take advantage of this newsletter to publish your stories with the wider movement that shares your passion for education. You can submit newsletter articles in your own language or submit bilingual articles for the education newsletter. For the month of January the deadline to submit articles is on the 20th January. We look forward to reading your stories.

Older versions of this newsletter can be found in the complete archive.

More information about the newsletter can be found at Education/Newsletter/About.

For more information, please contact spatnaik at

About This Month in Education · Subscribe/Unsubscribe · Global message delivery · For the team: ZI Jony (Talk), Wednesday 3:35, 19 January 2022 (UTC)