SpBot archives all sections tagged with {{section resolved|1=~~~~}} after 3 days and sections whose oldest comment is older than 30 days.

Announcements[edit]

May Monthly Challenge[edit]

The contributors to the Monthly Challenge of May processed 6306 pages in all, increasing both the number of proofread and validated pages compared to the April challenge. Again, more than one work per day was promoted to proofread and/or validated status. The works processed included:

• Index:Dobbs_v._Jackson_Women's_Health_Organization_-_Court_opinion_draft,_February_2022.pdf
• The Kobzar of the Ukraine was proofread, a work requiring lots of poem formatting and images.
• Several works of the Anne of Green Gables series. The transcription of this series has seen enormous progress over the last two months.
• The last two volumes of George Eliot's Daniel Deronda. After completing the transcription of the Brontë sisters' works, the MC contributors are making rapid progress at transcribing also a complete set of Eliot's most well-known works.
• The Orley Farm series was finalized with the validation of the last two volumes.
• Several long-term projects/series made significant steps forward: Sherlock Holmes, The Philippine Islands, Historic Highways of America, to name only a few.

Everyone is welcome to the challenge for June. Good transcribing to all!--Tylopous (talk) 18:57, 3 June 2022 (UTC)[reply]

Proposals[edit]

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 for creation of local Exemption Doctrine Policy (EDP)[edit]

The English Wikisource hosts many texts based on the justification that they are “government edicts,” and are thus in the public domain. (See {{PD-EdictGov}}.) In a recent case (decided March 31, 2022), Judge Chutkan of the District of Columbia determined that certain works, which are law, are not government edicts, but may be hosted under the statutory doctrine of “fair use.” This opinion is at odds with an earlier opinion; however, to avoid legal and WMF Legal issues, I propose that certain copyrighted works may be uploaded if they fall under Chutkan’s “fair use” analysis of legally binding works. Specifically, I propose that works incorporated by reference into binding law or regulation, by the federal government or any state or municipal government, be allowed on the English Wikisource. These works may need a new license tag template, which would mention the “government edicts” doctrine, ASTM II, and the new EDP. TE(æ)A,ea. (talk) 21:09, 6 April 2022 (UTC)[reply]

I would be inclined to oppose for two reasons:

• The "fair usage" analysis implies usage restrictions, effectively making these works non-commercial which we explicitly prohibit already
• The "fair usage" analysis depends on the economic impact on the holder of the work, exactly which parts are incorporated by reference based on the statue, etc. This and the other work-by-work analysis would need to be explained and included in whatever license template we create. This seems quite difficult to manage given it is fundamentally a subjective and opinionated exercise.

The proposed template maybe can include a disclaimer calling out that it is non-commercial and update the licensing policy to mention this exemption?

MarkLSteadman (talk) 02:29, 7 April 2022 (UTC)[reply]

• MarkLSteadman: Well, any “fair use” work would have usage restrictions—that’s why it’s “fair use,” and not “public domain.” There are many images on enWP, for example, which it would be inappropriate to reuse commercially, but which are used anyway under the doctrine of “fair use.” The judge states the following in the fair-use analyses:

  The “express text of the law falls plainly outside the realm of copyright protection.” ASTM, 896 F.3d at 451. Here, the standard is incorporated into law without limitation such that “the consequence of the incorporation by reference is virtually indistinguishable from a situation in which the standard had been expressly copied into law.” Id. at 452. Accordingly, “this factor weighs heavily in favor of fair use.” Id.

• This paragraph seems to closely parallel the language of Judge Marrero and the various circuit judges, when those Honorables chose to declare such works in the public domain. My proposal is mainly to accomodate Judge Chutkan’s opinion with the opinion and practice of other district and circuit courts. As for your second claim, that the fair use analysis is lengthy, this is another problem answerable to enWP practice. See, for example the “Summary” section of this file. The detailed sections allow for a thorough analysis of the statutory fair use factors, which would, of course, be done on a work-by-work basis. The proposed license template, to be included at the bottom of the page, should then link to an explanation of the justification for hosting the file, which would either be in Talk: or File talk: (depending on whether the work is scan-backed at the moment). TE(æ)A,ea. (talk) 03:25, 7 April 2022 (UTC)[reply]

  If the community decides that it wants to host non-commercial / non-derivative works in some form as is practice at other hosting sites there is no legal issue stopping us but do we want to? Why is this any different from the other non-commercial works we routinely delete as not hostable? For a document that is licensed under CC NC and then referenced here would we prefer to host it under this more restrictive exemption and delete the other portions? Given an update to the licensing policy we may be able to come up with a structured process to allow hosting them (e.g. mandatory additional fields, link to the relevant legal code etc.) but it would beyond just mentioning the policy (like other licensing templates). MarkLSteadman (talk) 12:04, 7 April 2022 (UTC)[reply]

  it is different because US laws are PD, and the code is incorporated into law. but we have code officials trying to use copyright to charge rents. see also https://archinect.com/news/article/150195411/supreme-court-rules-that-building-codes-cannot-be-copyrighted --Slowking4 亞 Farmbrough's revenge 21:12, 9 April 2022 (UTC)[reply]

  The ruling says explicitly that is not the case citing that case: "Defendant’s second and related argument—that the standards are “government edicts”—fails.", "A government body that merely incorporates a standard by reference does not independently create any content, and therefore does not become an “author” of the standard. Defendant points to no authority to the contrary." The proposal explicitly says "copyrighted works may be uploaded if they fall under Chutkan’s “fair use” analysis" which is explicitly not public domain, and why would we ask for a specific exemption and new license tag if these works fall under the existing "US laws are PD" category instead of creating a new "Chutkhan fair use" category? MarkLSteadman (talk) 02:03, 10 April 2022 (UTC)[reply]

  who is "we"? you are inclined to oppose because "we can’t have an exemption policy because we already delete that stuff" = tautologies are us. --Slowking4 亞 Farmbrough's revenge 00:11, 14 April 2022 (UTC)[reply]

  No, my point is that why would Wikisource create an exemption to host works Wikisource can already host because they are in the public domain. If work X is public domain, why not just use a PD license? Work X can't be both in the public domain and in need of an exemption because it is not in the public domain. MarkLSteadman (talk) 20:02, 15 April 2022 (UTC)[reply]

  Would de minimis apply here?--Jusjih (talk) 01:58, 22 April 2022 (UTC)[reply]

  Not generally, no. Xover (talk) 06:37, 22 April 2022 (UTC)[reply]

  How strict will we enforce the URAA restoration? I ask while we consider amending how strict our copyright enforcement will be, in case certain works are law while not government edicts.Jusjih (talk) 22:42, 25 April 2022 (UTC)[reply]

  yeah, for File:Report On The Investigation Into Russian Interference In The 2016 Presidential Election.pdf they claimed "(Volume I pages 31, 34, 86, 91, 92, and 113) that may be copyrighted) are not fully free but believed to be de minimis for this work" ; this is a continuing problem with government documents, and their copyrighted diagrams and extended quotations. need an EDP since we cannot rely on commons to apply their extra-legal interpretation consistently. --Slowking4 亞 Farmbrough's revenge 19:46, 9 May 2022 (UTC)[reply]

  • MarkLSteadman: Actually, that is the very reason I proposed the new EDP. It is because there are varying interpretations of the law that I saw a need for the policy, not counting the other reasons listed by other participants. The case of Chutkan’s opinion illustrates my point: some codes adopted into law, like those at issue in ICC v. UpCodes, are in the public domain; while others, like those at issue in ASTM v. PRO, can be posted only through the “fair use” doctrine. I believe that these two cases argue two different positions regarding the copyrightability of materials incorporated by reference into law. It is by this type of legal disagreement that a work “can[] be both in the public domain and in need of an exemption because it is not in the public domain.” At this stage in legal development, there are multiple views put forward in different cases by different judges, and I believe that Wikisource should accomodate these different views. TE(æ)A,ea. (talk) 02:47, 23 May 2022 (UTC)[reply]

  and for example, Korean Air Flight 801 - Aircraft Accident Report (NTSB), Jeppesen charts deleted at commons, [1], preventing the completion of the work. no de minimus there. --Slowking4 亞 Farmbrough's revenge 01:15, 26 May 2022 (UTC)[reply]

  If this is meant to cover the period of uncertainty because of the conflicting rulings, then that should be included in the policy statement. If the courts do decide on the Chutkan version and resolve the ambiguity in favor that these works are not PD-Edict is the plan to continue hosting them purely under a "fair use" license under this exemption policy? As currently proposed, I would interpret this as yes. MarkLSteadman (talk) 13:50, 9 June 2022 (UTC)[reply]

  • MarkLSteadman: Obviously, I prefer the result in the UpCodes case, where the works enter the public domain, rather than allowing the posting under the “fair use” standard. My proposal is entirely a stop-gap measure: it is intended to allow the posting of materials of this type while there is currently uncertainty in the law. If, at some point in the future, the law is resolved in favour of Chutkan’s approach, I think there would need to be a separate discussion on whether the use of the “fair use” doctrine is appropriate. The license which would be used to mark the works in question would have to mention the uncertainty, of course, warning potential reusers about the situation. This is similar to how U.S.-specific licenses warn reusers that the works in question may be copyrighted in different countries; as the law is uncertain, different judges may interpret the rules in different ways. If that is your concern, I will state clearly that this proposed policy would only exist so long as the law is uncertain. If Marrero’s interpretation wins, the license can be removed, and replaced in its entirety with PD-EdictGov; if Chutkan’s interpretation wins, a separate discussion can be had on how to proceed. TE(æ)A,ea. (talk) 16:39, 9 June 2022 (UTC)[reply]

    @TE(æ)A,ea. That addresses my first concern. If the template has enough info for actually doing the fair use analysis rather than merely being a pro forma hand wave then the second might be also be overcome. MarkLSteadman (talk) 16:50, 9 June 2022 (UTC)[reply]

    • MarkLSteadman: I think the focus would be on when works are incorporated by reference in whole. The inclusion of parts o8f works, where only parts are so incorporated, would be confusing and very case-specific, so I won’t focus on such a case. The license template could require parameters to allow a default fair-use declaration to be filled out. These would include mentioning the specific provision of law which incorporates the work by reference. Quoting from Chutkan: “Defendant’s ‘attempt to freely distribute standards incorporated by reference into law qualifie[s] as a use that further[s] the purposes of the fair use defense.’” “The ‘express text of the law falls plainly outside the realm of copyright protection.’” “The incorporating regulation does not specify that only certain provisions of this standard are incorporated by reference into law, nor does it indicate which specific provisions of the standard are relevant for regulatory compliance, suggesting that ‘a greater amount of the standard’s text might be fairly reproduced.’” These would all apply in such a case, so I think the process could work smoothly. TE(æ)A,ea. (talk) 17:29, 9 June 2022 (UTC)[reply]

  • "If this is meant to cover the period of uncertainty because of the conflicting rulings" - no, this is meant to cover the period of uncertainty of commons conflicting deletion decisions. when the courts or commons change their decisions, then the license can change, but i would not hold my breath. the PD US only local copies, will eventually be PD everywhere as well --Slowking4 亞 Farmbrough's revenge 20:01, 15 June 2022 (UTC)[reply]

Bot approval requests[edit]

• See Wikisource:Bots for information about applying for a bot status
• See Wikisource:Bot requests if you require an existing bot to undertake a task

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

Index:Memorials of Capt. Hedley Vicars, Ninety-seventh Regiment by Marsh, Catherine, 1818-1912.djvu[edit]

 This section is considered resolved, for the purposes of archiving. If you disagree, replace this template with your comment. CharlesSpencer (talk) 13:36, 13 May 2022 (UTC) (Confirmed from two other editions that no text is missing)[reply]

Apologies - I have not requested one of these before, so I will be a little bit more verbose than more experienced colleagues in an effort to get it right first time! I have two pages missing between /127 and /128, so I hope that my request is correctly formed as follows:

Starting at Page:Memorials_of_Capt._Hedley_Vicars,_Ninety-seventh_Regiment_by_Marsh,_Catherine,_1818-1912.djvu/128 until the end, please move the text by +2. Thank you. CharlesSpencer (talk) 13:14, 3 May 2022 (UTC)[reply]

Bizarrely, on consulting another version of the text, it appears that the typesetters may only have skipped two on the page numbers, while the text itself may in fact be complete! Please hold off until I can triangulate from further editions. Thanks. CharlesSpencer (talk) 13:27, 3 May 2022 (UTC)[reply]

Index:The future of Africa.djvu[edit]

 This section is considered resolved, for the purposes of archiving. If you disagree, replace this template with your comment. --Mpaa (talk) 20:06, 12 May 2022 (UTC)[reply]

Starting at Page:The future of Africa.djvu/9 until the end, please move the text by +4. Languageseeker (talk) 06:07, 4 February 2022 (UTC)[reply]

Done Mpaa (talk) 21:22, 4 February 2022 (UTC)[reply]

@Mpaa Thank you!

Index:Incidents in the life of a slave girl.djvu[edit]

 This section is considered resolved, for the purposes of archiving. If you disagree, replace this template with your comment. --Mpaa (talk) 20:06, 12 May 2022 (UTC)[reply]

[[Starting at Page:Incidents in the life of a slave girl.djvu/5 until the end, please move the text by +4. Languageseeker (talk 01:05, 5 February 2022 (UTC)[reply]

Done Mpaa (talk) 11:10, 5 February 2022 (UTC)[reply]

@Mpaa Thank you!

Index:A history of Hungarian literature.djvu[edit]

 This section is considered resolved, for the purposes of archiving. If you disagree, replace this template with your comment. --Mpaa (talk) 20:06, 12 May 2022 (UTC)[reply]

Starting at Page:A history of Hungarian literature.djvu/3 until the end, please move the text by +4. Languageseeker (talk) 14:44, 16 April 2022 (UTC)[reply]

Done Mpaa (talk) 20:06, 12 May 2022 (UTC)[reply]

@Mpaa Thank You!

Clotel[edit]

Please move the pages from Index:Clotel, or, The President's daughter - a narrative of slave life in the United States (IA 70979078-9a98-41a4-8db9-1076b6b1186a).pdf to Index:Clotel (1853).djvu. The PDF is basically unreadable. Languageseeker (talk) 23:36, 22 May 2022 (UTC)[reply]

Index:Cambridge by lamplight - 9 woodcuts.djvu[edit]

 This section is considered resolved, for the purposes of archiving. If you disagree, replace this template with your comment. — ineuw (talk) 02:32, 31 May 2022 (UTC)[reply]

Please move the backing file and associated images from commons to wikisource as it is by a UK author who died in 1975. 19:06, 30 May 2022 (UTC)

Done.--Prosfilaes (talk) 19:22, 30 May 2022 (UTC)}}[reply]

Index:Karl Kautsky - Georgia - tr. Henry James Stenning (1921).pdf[edit]

Sorry about this but the backing pdf needs to move from commons to wikisource because Stenning died in 1971 so it still has UK copyright. MarkLSteadman (talk) 14:01, 2 June 2022 (UTC)[reply]

Index:The Country of Pointed Firs - Jewett - 1896.djvu[edit]

Two pages are missing: Pages 101 and 102. Currently, page 100 corresponds to Page:The Country of Pointed Firs - Jewett - 1896.djvu/114 and page 103 corresponds to Page:The Country of Pointed Firs - Jewett - 1896.djvu/115.--Tylopous (talk) 09:42, 12 June 2022 (UTC)[reply]

Pages 101 and 102 can be found here: https://archive.org/details/countryofpointed00jewerich/page/100/ MarkLSteadman (talk) 14:01, 12 June 2022 (UTC)[reply]

Thanks for this information. I'm still grateful for further assistance, because I've never added pages to djvu files.--Tylopous (talk) 16:40, 12 June 2022 (UTC)[reply]

Done. Mpaa (talk) 20:41, 12 June 2022 (UTC)[reply]

Thanks for the quick help.--Tylopous (talk) 05:41, 13 June 2022 (UTC)[reply]

@Mpaa: On closer inspection, now pages 103 and 104 of the book are twice contained in the djvu file. The four pages

Page:The Country of Pointed Firs - Jewett - 1896.djvu/115 to Page:The Country of Pointed Firs - Jewett - 1896.djvu/118 now contain 103,104,103,104 instead of 101,102,103,104. Sorry that I didn't notice this earlier.--Tylopous (talk) 15:53, 13 June 2022 (UTC)[reply]

@Tylopous I think you are seeing cached pages, try to purge the pages. See e.g. page 115 in the djvu file. Mpaa (talk) 21:35, 13 June 2022 (UTC)[reply]

@Mpaa: Now it's clear. Thank you very much again.--Tylopous (talk) 05:19, 14 June 2022 (UTC)[reply]

Index:IA Query "sponsor-(Sloan) date-(1000 TO 1925) publisher-((New York) OR Chicago OR Jersey OR Illan)" (IA conductorgeneral00park).pdf[edit]

Please move this to a new title of Index: Conductor Generalis (1788) (IA conductorgeneral00park).pdf which is a more sensible name. This would also involve a rename at Commons. ShakespeareFan00 (talk) 07:08, 23 June 2022 (UTC)[reply]

Her Benny[edit]

FYI the index file is at Index:Her Benny - Silas K Hocking.djvu with proof read pages while the commons backing file is at "Her Benny - Silas K Hocking (Warne, 1890).djvu" which is breaking the internal links as things pint towards the nonexistent Index:Her Benny - Silas K Hocking (Warne, 1890).djvu. MarkLSteadman (talk) 07:21, 23 June 2022 (UTC)[reply]

done. Mpaa (talk) 18:30, 24 June 2022 (UTC)[reply]

'Transcribe text' script termination[edit]

If possible, I request that any person who is authorized to make a change, to add to the end of the Transcribe text script that termination should be in the textbox first row, and not somewhere in the browser window. — ineuw (talk) 02:32, 31 May 2022 (UTC)[reply]

Moved to Help. — ineuw (talk) 08:52, 4 June 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:

• Auction Prices of Books, a four volume set of auction listings, by author. No scans, no content and a couple of notes in the header.
• Central Law Journal/Volume 1, a single volume from a periodical, with a AuxTOC of numbers, and a title page, but otherwise empty. Has scans and Index.
• A Critical Dictionary of English Literature, a three-volume dictionary by author. Currently has no scans, no title page, and a single non-scan backed article.
• Bradshaw's Monthly Railway Guide, a top-level periodical page with a single volume number and no other content. No scans linked, though Bradshaw's Monthly Railway and Steam Navigation Guide (XVI) did once exist, it was deleted and Index:Bradshaw's_Monthly_(XVI).djvu exists and is partly proofread.

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. Inductiveload—talk/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. Inductiveload—talk/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. Slowking4 ⚔ Rama'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. Slowking4 ⚔ Rama'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. Inductiveload—talk/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. Slowking4 ⚔ Rama'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. Inductiveload—talk/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. Slowking4 ⚔ Rama'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.)
4. EITHER
   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]
•  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. Inductiveload—talk/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. Inductiveload—talk/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. Inductiveload—talk/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. Inductiveload—talk/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]

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]

Proposal[edit]

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. Inductiveload—talk/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? Inductiveload—talk/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? Inductiveload—talk/contribs 20:29, 1 November 2021 (UTC)[reply]

Universal Code of Conduct News – Issue 1[edit]

—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) 18:13, 16 June 2021‎ (UTC)[reply]

J3l[edit]

The Works of the Late Edgar Allan Poe/Volume 1/The Domain of Arnheim —unsigned comment by 202.165.87.161 (talk) 18:52, 25 December 2021 ‎(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 spatnaikwikimedia.org.

Categorization of Canadian statutes[edit]

I believe it would be best if there were a centralized mainspace umbrella for Canadian Statutes (similar to the one United States Statutes at Large uses). The way statutes are currently listed, there is no structure beyond "next section" and "previous section" links.

Since statutes are listed by reign and chapter in each volume, Wikisource should use the same system. For example, It would be useful if An Act for the organization of the Department of Marine and Fisheries of Canada should be moved to Canadian Statutes/31 Victoria/Chapter 57 while keeping a redirect from the short title of each bill. If anyone has any input, please let me know. I’m mender? :/ (talk) 17:30, 24 May 2022 (UTC)[reply]

• I’m mender? :/: If the intent is to work from the Canadian Statutes out, then I think that would wise. The pattern you have is probably good for how to notate the laws. For this Act, and most others that don’t need to be split, the “Schedule” should be on the same page. For the United States Statutes, there are no redirection pages for the long titles of laws to the formal name; thus, I don’t think it is necessary for the Canadian Statutes, either. Of course, if any law is well-known by a certain title, a redirection should exist, but otherwise, it is not necessary, as a search for the title would reveal the full name anyway. For sidenotes, I would recommend using {{USStatSidenote}}, as it is optomized for use in statutes publications. TE(æ)A,ea. (talk) 18:05, 24 May 2022 (UTC)[reply]
  • TE(æ)A,ea.: Thanks for the recommendation. Only mainspace pages with a Short Title as their name will be used as redirect pages, and links to long titles will be adjusted manually. I’m mender? :/ (talk) 18:16, 24 May 2022 (UTC)[reply]

    Upon further consideration, pages in Statutes of Canada will be listed by Parliament and Session, as the year of the Gregorian calendar and the year of the reign of the monarch can be ambiguous (e.g. there are two sessions called "5 George V" and two sessions which take place in 1896). I’m mender? :/ (talk) 08:18, 30 May 2022 (UTC)[reply]

    Further update: The Statutes of Canada are now classified by year, in the same manner as more recent annual statutes. For instance, the edition titled Acts of the Parliament of the Dominion of Canada passed in the Session held in the Fourth year of the Reign of His Majesty King George VI being the First Session of the Nineteenth Parliament Begun and holden at Ottawa, on the Sixteenth day of May, 1940, and closed by Prorogation on the Fifth day of November, 1940, short title Statutes of Canada, 1940, 4 George VI will be located at Statutes of Canada/1940. I’m mender? :/ (talk) 22:49, 17 June 2022 (UTC)[reply]

The Collected Works of Mahatma Gandhi[edit]

Hi, As I am finishing importing the files to Commons (having already done the Gujarati and Hindi versions), I have (again) a question about the best way to handle this. I found 2 different scans of this work. The first ones are 1,239 × 1,906 pixels scans with an intrusive watermark (e.g. [2], the others are 2,025 × 3,043 pixels (e.g. vol. 3), but not really scans, but rather recreation of the books, after removing blank pages. The second set is of better quality and has no watermark, but not exactly a copy of the original work, although the text is the same. Which set do we want for proof reading on WS? Thanks, Yann (talk) 09:58, 26 May 2022 (UTC)[reply]

@Yann: I don't understand what you mean by "recreation of the books"? Scans are just a technical representation of a published work, and as such should reflect what was actually published. If the latter scan does not match what was actually published on paper then we can't use it. Xover (talk) 07:16, 28 May 2022 (UTC)[reply]

@Xover: I am not sure, as there is no information on the source website. But my deduction after examining the files is that these are the exact same text, but are not technically scans. This set does reflect the text that was actually published, but not the formating of the original books. Thanks, Yann (talk) 12:20, 29 May 2022 (UTC)[reply]

@Yann: The scan at gandhiserve.net appears to be a second edition published in June 1979, by the Navjivan Trust in Ahmedabad. I cannot judge its fidelity to Gahndi's original writings, but I see no obvious reason to suspect that the scan doesn't match the physical book as it was then published. The scan at IA looks like the April 1960 first edition of the same work, except scanned by someone even less skilled than your average Google Books scanner, and thus has major problems. Of the two, I would be most inclined to trust the scan at gandhiserve.net for the simple reason that it appears to have been scanned by someone with a modicum of skill and care, which usually means they have tried to be faithful to the work they are preserving. Since it is also, modulo that annoying watermark, the technically superior scan (higher resolution, full colour, consistent page size, etc.) my suggestion would be to focus on that.

PS. I'll assume you have the copyright issue in hand (since we're talking books with a 1960–1979 printed copyright date), so I haven't looked into that at all. Xover (talk) 07:13, 30 May 2022 (UTC)[reply]

OK thanks. Then I will use the set from gandhiserve.net to create DjVu files. I will delete the volumes not yet in the public domain after uploading. Yann (talk) 08:00, 30 May 2022 (UTC)[reply]

Are you all set for tools to create DjVu with an OCR text layer? Xover (talk) 08:05, 30 May 2022 (UTC)[reply]

I am not sure what you mean, but I create DjVu after generating PDF from the online images. Yann (talk) 20:57, 30 May 2022 (UTC)[reply]

Template:Advertisements[edit]

The template {{Advertisements}} is no longer a collapsed section when a page is loaded, neither can it be collapsed. See (e.g.) Snow-Bound: A Winter Idyl. I do not see any recent changes to the template or to the templates it calls. There may be a Module or update that has changed the functionality. --EncycloPetey (talk) 18:13, 26 May 2022 (UTC)[reply]

@EncycloPetey: Fixed, I think. It was using some seriously obsolete code and was only still working because we had some stuff hardcoded in site-specific code. When that got cleaned up this template just fell over. I've updated it to use the current implementation now.

PS. Collapsible content (irrespective of implementation) is not the best practice for several aspects of accessibility, so I recommend against using this template for any new works added. Xover (talk) 18:45, 27 May 2022 (UTC)[reply]

There is no "standard" for dealing with large Advertisements that appear among the Front Matter. Recommending against a workable practice isn't helpful if there are not suitable alternatives. --EncycloPetey (talk) 21:50, 29 May 2022 (UTC)[reply]

@EncycloPetey: Turn it on its head, rather: the basic state is to include the advertisements as they were published. Granted a lot of them are very large and annoyingly placed, but then, that was the case when they were originally published too. What I'm saying is that {{advertisements}} is not a "suitable alternative". But it's just my recommendation, and not even anywhere near the top of my list of hobby-horses, so you'll need to make up your own mind on that. Xover (talk) 06:44, 30 May 2022 (UTC)[reply]

I disagree about the "basic state". Advertisements are not part of the work proper, but are added by the publisher. Unlike ex libris book plates and library stamps, they were present when the book was printed, and there can be useful information about other publications by the same author, so they are more meaningful than marks printed solely for collating pages. But only just. There is a very broad spectrum of what is and isn't transcribed from scans, and not everyone here agrees about what to do for all of those items. --EncycloPetey (talk) 17:18, 30 May 2022 (UTC)[reply]

MediaWiki:IndexForm.js[edit]

I tried importScript('MediaWiki:IndexForm.js'); on edit page of Index page and it seems like this script is broken because it removes the Type dropdown instead. --Bebiezaza (talk) 13:54, 29 May 2022 (UTC)[reply]

@Bebiezaza nearly all the JS in the Mediawiki namespace that does not start with "Gadget-" is probably only for historical interest. If it's currently in use, it'd be a gadget. In this case, the script probably dates back to when the index edit form was generated entirely client side (these days, the form is created server side by the ProofreadPage extension). Inductiveload—talk/contribs 18:47, 29 May 2022 (UTC)[reply]

MediaWiki:IndexForm.js is not in use on enWS and hasn't been since 2018 (and is in fact entirely broken). Xover (talk) 06:49, 30 May 2022 (UTC)[reply]

Tech News: 2022-22[edit]

20:28, 30 May 2022 (UTC)

"Wikisources"[edit]

I wanted to let you guys know about this domain name I found recently called https://www.wikisources.org/, which appears to function as a mirror site of Wikisource. They are "dedicated to providing you the best of Library", but they give no acknowledgment whatsoever that the content all comes from Wikisource anywhere on the site that I can find, including in their terms of service or about us pages. I thought this was pretty peculiar, and I'm not really sure what to think about this weird site. But thought I'd get the word out just in case anything needed to be done, and because of how funny it all is. PseudoSkull (talk) 06:14, 5 June 2022 (UTC)[reply]

@PseudoSkull: *shrug* Amateurish mirrors of Wikimedia content pop up from time to time. On Wikisource, most of our content is freely reusable (unlike Wikipedia, where the otherwise free content requires attribution) so there's not much point pursuing things like this. I suppose we could throw them an email asking them to acknowledge the source of the content, but given the site looks pretty skeevy I very much doubt they'd listen (and gods only know what they'd do with the email address you used). It's good to be aware of sites like this, but beyond keeping half an eye on what they do we should probably just ignore them. Xover (talk) 07:05, 5 June 2022 (UTC)[reply]

Those names and photos look awfully generic.. Someone's using a web template? ShakespeareFan00 (talk) 12:32, 5 June 2022 (UTC)[reply]

My favorite is that the html contains such bits as <a dir="ltr" href="https://en.wikisource.org/w/index.php?title=The_Rock_of_Wisdom;_An_Explanation_of_the_Sacred_Scriptures/Biography_of_the_Author&oldid=12120013">https://en.wikisource.org/w/index.php?title=The_Rock_of_Wisdom;_An_Explanation_of_the_Sacred_Scriptures/Biography_of_the_Author&oldid=12120013</a>. It's clearly a rip-off, but, as Xover said, our works are in the public domain and anything can do anything with them legally. Languageseeker (talk) 12:57, 5 June 2022 (UTC)[reply]

Those are most likely stock photos or photos similarly ripped from some random website, yes. Xover (talk) 16:08, 5 June 2022 (UTC)[reply]

If they are using the name Wikisource on their site, there may be legal action from our parent corporation, as use of the name may be protected as a trademark. --EncycloPetey (talk) 18:22, 5 June 2022 (UTC)[reply]

I see "2022 © WikiSources. All rights reserved." The Wikimedia Foundation better pursue a very serious legal action.--Jusjih (talk) 02:33, 8 June 2022 (UTC)[reply]

i have yet to see any case law enforcing SA. the closest has been the Highsmith case, [8] they might try a stern letter about copyfraud. so it goes. --Slowking4 亞 Farmbrough's revenge 00:52, 11 June 2022 (UTC)[reply]

Our source material is public domain, but our discussion pages aren't. They're licensed under Creative Commons Attribution-ShareAlike, as it says at the bottom of the page. And yet this strange site has scraped this very discussion page and copied it... Also, is there any copyright/licensing to be had on our particular rendering of the works? If they take the text, that's fine, but if they take all the HTML/template rendering, does it then have to be CC-BY-SA? — Dcsohl (talk)
(contribs) 16:36, 8 June 2022 (UTC)[reply]

No. None of the formatting we do in texts is independently copyrightable, especially because our formatting aims to mimic the originally published version. Anything copyrightable as layout would be out of scope. But all other parts of the site are, as you note, licensed under {{CC-BY-SA-3.0}} which both requires attribution of the source (i.e. a link back to the original page here) and re-sharing derivative works under the same license terms. Xover (talk) 08:10, 11 June 2022 (UTC)[reply]

Tech News: 2022-23[edit]

02:46, 7 June 2022 (UTC)

California Child Actor's Bill[edit]

Anybody interested in California, or law, or both? There's a bill called the California Child Actor's Bill, also known as the Coogan Bill, that I would like to see transcribed. It "is a law applicable to child performers, designed to safeguard a portion of their earnings for when they reach the age of majority, and protect them from exploitation and abuse. The original Bill was passed in 1939 by the State of California in response to the plight of Jackie Coogan, who earned millions of dollars as a successful child actor only to discover, upon reaching adulthood, that his mother and stepfather had spent almost all of his money."

As a California law it is an edict of a government, and therefore in the public domain. Law isn't my area, so this is a request. PseudoSkull (talk) 16:54, 7 June 2022 (UTC)[reply]

• PseudoSkull: There are two relevant versions of the law: the law as it was originally enacted, and the law as it stands to-day. The law is chapter 637 of 1939, and may be found on pp. 2064–2065 of the California Statutes for 1939, or pp. 2065–2066 of this PDF. According to the Wikipedia article, the law as it exists is spread across fives sections in two codes: sections 6750–6753 of the Family Code and section 1700.37 of the Labor Code. The most specific, relevant part is chapter 3 of part 3 of division 11 of the Family Code, which contains the abovementioned sections of the Family Code, and contain the central part of the act, as it is currently codified; that can be accessed here. The latter appears to be the official version, despite the lack of a PDF; for an “official” PDF, I would recommend collating the official PDFs of the four relevant sections. TE(æ)A,ea. (talk) 03:38, 8 June 2022 (UTC)[reply]

Headers generated by pages tag[edit]

Owing to a current dispute (see User talk:EncycloPetey § Index:As a Man Thinketh), there seems to be necessary a clarification regarding the use of headers. The “pages” tag, used for transcluding text from the “page” namespace, can, with “header=1,” call on the bibliographical fields of the “index” page to automatically generate a header. EncycloPetey has continued to mark As a Man Thinketh as being in need of standardisation because it uses the header generated through the “pages” tag, rather than through the “header” template. Does using the header generated by the tag meet the requirement of having a header? If not, what is the purpose of the “header” function of the “pages” tag? TE(æ)A,ea. (talk) 20:17, 8 June 2022 (UTC)[reply]

Wikisource:Style guide#Formatting item number 1: "The {{header}} template should be used at the top of every article page". That's pretty straightforward. The pages-header implementation exists so that bots have the means to auto-generate a "quick-and-dirty" work once the table of contents is completed. It is possible to use the pages tag generated headers, but only as a stop-gap while setting up a work. A completed work should not have them. --EncycloPetey (talk) 20:20, 8 June 2022 (UTC)[reply]

• EncycloPetey: Your very quote belies your point: “The [template] should be used”! An obvious alternative to the use of the template is the use of the “header” function of the “pages” tag. From Help:Transclusion: “Generates and inserts a {{header}} at the top of the page, using the information from the Index page. This is an alternative to adding a manual header.” TE(æ)A,ea. (talk) 20:24, 8 June 2022 (UTC)[reply]

  You're quibbling over "should"? Then see the first definition under wikt:should: "Ought to; indicating opinion, advice, or instruction, about what is required or desirable." --EncycloPetey (talk) 20:29, 8 June 2022 (UTC)[reply]

  • EncycloPetey: Again, your quote belies your point: “indicating opinion, advice, or instruction, about what is required or desirable.” The word “should” never indicates a requirement. TE(æ)A,ea. (talk) 20:31, 8 June 2022 (UTC)[reply]

    What? It's right there in the definition, and I bolded it, yet you claim that it never does this? A wikt:requirement is, quite literally, something that is required. --EncycloPetey (talk) 20:34, 8 June 2022 (UTC)[reply]

    • EncycloPetey: You misunderstand the definition of “should.” It is not “what is required or desirable,” but “opinion, advice, or instruction, about what is required or desirable.” The “opinion, advice, or instruction, about” modifies the “what is required or desirable,” making it clear that “should” is not a requirement, but “opinion, advice, or instruction” about some requirement. TE(æ)A,ea. (talk) 20:37, 8 June 2022 (UTC)[reply]

      The word "should" is a verb, so of course it is not "what is required or desirable", which is a phrase defining a noun. If this discussion hinges entirely on the meaning of "should", then please note that the Style Guide uses "should" throughout. There are 32 instances of "should" in the Style Guide and 0 instances of "must". This does not mean that the Style Guide is devoid of policy, nor that the Style Guide can be ignored. --EncycloPetey (talk) 20:44, 8 June 2022 (UTC)[reply]

      • EncycloPetey: Exactly! The style guide is a guide, not the law, so there are no requirements. So why do you require the “header” template to be used? TE(æ)A,ea. (talk) 20:46, 8 June 2022 (UTC)[reply]

        From the Style Guide: "Unless there is a good reason for deviating, the standard should be presumed correct." and "These are not hard rules, and can be ignored where necessary. However, users should follow these guidelines where possible to ensure that Wikisource is consistent and maintains a high standard of quality." So why is it not possible to follow the Style Guide in this instance? Why is it necessary to not follow them? What good reason is there for deviating from the Style Guide? --EncycloPetey (talk) 20:48, 8 June 2022 (UTC)[reply]

        • EncycloPetey: The style guide, and other “help” documents that it references, allow for the use of the “header” function of the “pages” tag: Help:Transclusion says so explicitly. And, again, the “header” template is being used, just through the “pages” functionality. TE(æ)A,ea. (talk) 21:19, 8 June 2022 (UTC)[reply]

          The Style Guide does no such thing. Nowhere does it allow for the pages tag use in place of templates. Help:Transclusion points out that the functionality exists, without recommending it. Nor is it a policy page; it's a Help page. So again, what is the reason for a deviation from the Style Guide in this instance? --EncycloPetey (talk) 21:24, 8 June 2022 (UTC)[reply]

          • EncycloPetey: Just because you claim something isn’t true, doesn’t make it false. The style guide is written in general terms, with references to more detailed help pages. One of those is Help:Transclusion, which gives detailed information on transclusion. That page mentions “header=1,” and states: “Generates and inserts a {{header}} at the top of the page, using the information from the Index page. This is an alternative to adding a manual header.” Given the style guide’s reference to the use of a header, and to this specification “help” page, it is clear that the style guide allows the use of the “header” functionality of the “pages” tag. You have claimed that the “header=1” functionality is used only for bots, and that it is not a substitute for the template itself; but this is directly contradicted. TE(æ)A,ea. (talk) 21:53, 8 June 2022 (UTC)[reply]

            You've made several misleading and false claims there, including a patently false claim that I said anything was "only for bots". But to address the central issue: Yes, the page mentions the header generation; says that this is an "alternative", but nowhere is this recommended or advocated in any way. The fact that a page notes that something is possible does not make it good practice. The fact that something appears on a Help page (which can be edited as needs) does not affect Policy pages (which are voted on by the Community). Your issue seems to be a misunderstanding about the status of (and relationship between) Policy and Help materials. --EncycloPetey (talk) 22:19, 8 June 2022 (UTC)[reply]

            • EncycloPetey: “The pages-header implementation exists so that bots have the means to auto-generate” works: your words, not mine. Your casting of aspersions is not appreciated. The “header=1” functionality is declared as an “alternative,” as you have now admitted; nowhere is it described as an inferior alternative, or a deprecated system. The use of the “header” template and the use of the “header” function of the “pages” tag are two alternatives to meet the style guide’s mention of a header; thus, you cannot claim (as you had previously) that the work in question “need[s] to be standardized using Wikisource's style guidelines.” There are many things which are technically possible, though not recommended; for example, the use of the “page” template or direct transclusion in the place of the “pages” tag for transclusion. Both of those are technically possible, but they are both explicitly disapproved of, and deprecated. That is not the case here; the “header” function of the “pages” tag is not listed as an inferior system, but just as an “alternative.” The fact that there is no mention that the “header” function of the “pages” tag is deprecated or in any way not recommended means that its use is good practice—an alternative to the use of the “header” template, but good practice nonetheless. TE(æ)A,ea. (talk) 23:03, 8 June 2022 (UTC)[reply]

              You have taken free liberty with reinterpreting what I have said. I did not say "only", and you quoted a statement that did not say "only", but seem to maintain that I said "only" nonetheless. I stated a rationale, in response to your query as to why the option exists. You clearly misconstrued the context of my reply. An explanation as to the cause of a thing existing does not imply sole function. This is why I let you know that you have made false and misleading claims. This is very bizarre to me, considering the previous surgical argument placed on the meaning of the single word "should".

              But the issue: Yes, Help pages exist and are linked from Policy pages, but that does not give the information them the weight of Policy. The fact that an alternative has not been explicitly forbidden is a far cry from a recommendation as good practice. Those are two ends of a broad spectrum, and not the same thing. Why do you think that "good practice" is the default assumption here? Or do you consider anything that has not been deprecated or expressly forbidden to be automatically "good practice"? Recall that "good practice" is "not only a practice that is good, but a practice that has been proven to work well and produce good results, and is therefore recommended as a model." The use of the header function for the pages tag has not been recommended anywhere. So why do you think it is good practice? --EncycloPetey (talk) 00:07, 9 June 2022 (UTC)[reply]

              • EncycloPetey: You said that the “header” function of the “pages” tag “exists so that bots” can do something. This claim seems to me to mean that it was created for that purpose, and exists only for that purpose, as “exists” is a very strong word in this context. You seem to think that there can be only one way of doing something; that is counter to the very nature of English Wikisource. Different editors can work on different projects with different work styles; and yet, their respective works may all be in compliance with the style guide. As an example, either straight or curly quotes may be used in a work, and the work may be in compliance, so long as the use is consistent. In such a case, the use of straight quotation marks consistently is a “good practice,” and the use of curly quotation marks consistently is a “good practice;” the two methods are alternatives, and are both valid. That is the case here; either the “header” template may be used, or the “header” function of the “pages” tag, which are two alternatives, both of which are valid. There need not be one singular method of performing all of the functions of this project; that would interfere with the autonomy of the individual editor. The style guide sets out general goals and recommendations, but, so long as those are being met, I do not see why a complying practice would not be “good practice.” I do not see how your claim that you do not like a certain method of doing something makes an equally valid alternative method out of line with standard practice; you have made that claim against me before, and have been rebutted. TE(æ)A,ea. (talk) 00:25, 9 June 2022 (UTC)[reply]

                You have tried to put words in my mouth again; this is not an issue of "not liking" a method. Straight and curly quotes are both acceptable because we had a discussion and changed policy to allow either, so long as there is consistency. The two options are both noted in the Style Guide. That is not the case for the topic of discussion, and so the punctuation situation has no relevance to the current discussion. It is not an analogous issue. No discussion has ever permitted use of the page tag in place of the Header template, and the Style Guide makes no mention of such usage. The pages tag itself has functionality issues. Among those issues, the Pages tag transclusion product violates the basic recommendation for use of the {{Header}} template. The standard is to include chapter titles in the "section" field, but to avoid including them in the "previous" and "next" fields. The pages tag displays the opposite of this recommendation; it displays the chapter title instead of the chapter number. The pages tag also pulls data that, if altered by an editor at the source, will silently break chapter linkages throughout the work. There are additional issues, but these two alone show why the pages tag method is not "equally valid", but is out of step with standards. I ask again: why do you think use of the pages tag to generate header is good practice? and: why is it necessary to deviate from the standard? You have not answered these questions. --EncycloPetey (talk) 02:46, 9 June 2022 (UTC)[reply]

                • EncycloPetey: Before the policy change, only straight quotation marks were allowed. At the time, only straight quotation marks were considered to be “good practice.” Now, after the change, both are allowed. The fact that both are allowed, and neither is given a superior place, is the fact I was emphasizing. That is the state of affairs as regards headers: there are two methods, the “header” template and the “header” function of the “pages” tag, and, despite your protestations to the contrary, neither is given a superior place in the style guide, and neither is discouraged. The only discouragement to the use of the latter method is your persistent hounding of people who do things differently than you do. As to your two questions, I have already answered the first, and the second is based on an understanding of facts at odds with reality. Absent a contrary statement by the style guide, either method of generating a header is “good practice,” assuming that the use of a header is good practice. There is no deviation from “the standard,” because the use of the “header” function of the “pages” tag is standard: again, despite your claims to the contrary. The second question is premised on the response to the first question being that the use of the “header” function of the “pages” tag is not good practice, which is your claim, but it is not my claim. TE(æ)A,ea. (talk) 13:26, 9 June 2022 (UTC)[reply]

                  @EncycloPetey, @TE(æ)A,ea.: In my opinion, creating a header via the pages tag should be accepted as long as it has not been deprecated.

                  The help pages are at the top of the list of links that new users are given in a welcome message. The help page for transclusion states that using the "header=1" option in the pages tag generates and adds a header and that it is an alternative to a manual header. The style guide says that every article should include a header.

                  Thus, it is at least not surprising that many users, especially newer users, will use the "header=1" option of the pages tag. With the information given, they will assume that they have added a header and followed the style guide.--Tylopous (talk) 08:37, 10 June 2022 (UTC)[reply]

Ignoring most of the robust discussion above as TL;DR. Help:Beginner's guide to transclusion tells newbies to use the header=1 option when transcluding. It then goes on to imply that there may be problems with this approach, or that more control might be needed. The "simple" method is fine for works that flow in a straightforward manner and there is a single author. However, as soon as there are editors, contributors, different authors for different sections, sections being cross-transcluded outside a chapter structure, &c., &c., then a manual header is the only workable method. For those of us who have the "Preload useful templates" gadget switched on, the simple header is never used, as the appropriate header template appears automatically when creating a new page. Of course, even for the simple method, if the fields on the Index page are filled with garbage, then the header will be useless. This means that, regardless of the method used to create the header, the onus is on the transcluding editor to make sure it's as good as it can be. Beeswaxcandle (talk) 09:37, 10 June 2022 (UTC)[reply]

Copyright Status of the Sonic Bible (I'm serious)[edit]

Hello.

So here's an introduction of what the Sonic Bible is.

So the Sonic bible is the guide for Sega employees and developers to represent Sonic the Hedgehog in the way that Sega wants and requires. I am not joking. This thing actually exists. You can find more information here: https://sonic.fandom.com/wiki/Sonic_Bible

But here is the kicker, are these sets of documents subjected to copyright?Blahhmosh (talk) 21:08, 8 June 2022 (UTC)[reply]

• Blahhmosh: In short, yes, the “Sonic Bible” is copyrighted, and cannot be uploaded. The standard tool of reference for historical U.S. copyrights is the Hirtle chart. According to the reference you gave, the “Bible” was produced in 1991; thus, it was published in “1 March 1989 through 2002” and “Created after 1977.” Following the chart, the copyright lasts from 95 years after official publication, or 120 years after creation, if the author(s) is/are never identified. The cutoff date is March 1, 1989, though, so if you have anything from before then, it might be in the public domain. TE(æ)A,ea. (talk) 21:15, 8 June 2022 (UTC)[reply]

New Talk page creation text[edit]

Has anyone else noticed the new text that gets displayed when someone creates a Talk page? I foresee problems if that's the text we're going to have.

Start a discussion about Agreement on Trade-Related Aspects of Intellectual Property Rights

Talk pages are where people discuss how to make content on Wikisource the best that it can be. You can use this page to start a discussion with others about how to improve Agreement on Trade-Related Aspects of Intellectual Property Rights.

Do others see a potential problem? --EncycloPetey (talk) 03:23, 9 June 2022 (UTC)[reply]

I see what you mean—one could easily construe this in a misleading way. New users especially might get a false impression (which is an issue, as the text is clearly directed at new users). Can the default text be changed? Shells-shells (talk) 18:09, 23 June 2022 (UTC)[reply]

Half a million were uploaded as part of the "library back up project". Welcome to participate to upload all public domain books in the world![edit]

In 213 BCE, Qin Shi Huang destroyed all privately-held unorthodox books in by fire. In 206 BCE, Xiang Yu set a fire on the governmental library containing unique copies of the books, sounding the death of ancient Chinese thoughts and history. Yongle Encyclopedia was finished in 1408. It comprised 22,937 chapters in 11,095 volumes and 917,480 pages. Only one copy after that original copy was made. Most of them are lost in history and only about 800 chapters survive today. In 1932, 463 thousand Han Fen Lou rare books were burned in war.

To prevent such regrettable things that destroy the memory of mankind ever happen again, let's systematically back up the world's all surviving books in public domain to Wikimedia Commons.

Half a million book files were uploaded as part of the project. Currently only Chinese and Japanese books were uploaded, but the ultimate goal is ALL books in ALL languages from ALL countries as long as in public domain. Welcome to participate to accomplish the grand goal! 維基小霸王 (talk) 05:40, 9 June 2022 (UTC)[reply]

Recent Changes does not link to other languages[edit]

Special:RecentChanges does not link to the other languages (see de:Special:RecentChanges or bs:Special:RecentChanges for how it should look. NilsLindenberg (talk) 20:59, 12 June 2022 (UTC)[reply]

Category:Index_-_File_to_check[edit]

Can someone consider putting in the effort to get the remainder of works in this folder pagelisted? I didn't feel comfortable doing this on the remainder in that category, some of which seem to need compiling into DJVU collections of the relevant scans. ShakespeareFan00 (talk) 07:34, 13 June 2022 (UTC)[reply]

For anyone considering this now, the Epigraphia Indica volumes are pretty straightforward, if somewhat time-consuming due to the large number of image pages. —CalendulaAsteraceae (talk • contribs) 12:33, 20 June 2022 (UTC)[reply]

Tech News: 2022-24[edit]

16:58, 13 June 2022 (UTC)

Poll regarding Fourth Wikisource Triage meeting[edit]

Hello fellow Wikisource enthusiasts!

We will be organizing the fourth Wikisource Triage meeting in the last week of June and we need your help to decide on a time and date that works best for the most number of people. Kindly share your availabilities at the wudele link below by 20th June 2022:

https://wudele.toolforge.org/wstriage4

Meanwhile, feel free to check out the page on Meta-wiki and suggest topics for the agenda.

Regards

Sam Wilson (WMF) and Satdeep Gill (WMF)

Sent via MediaWiki message delivery (talk) 13:22, 14 June 2022 (UTC)[reply]

Are we allowed to link names in the djvu files to Wikidata[edit]

Are we allowed to link names in the djvu files to Wikidata? Lets say there is an obituary stored as a djvu file and names a few people that already have a Wikidata entry? Can I link to them? RAN (talk) 02:51, 17 June 2022 (UTC)[reply]

A good question. But why not? I constantly link to Wiktionary and Wikipedia. — ineuw (talk) 05:33, 17 June 2022 (UTC)[reply]

• I agree 100%, but in the past all my links had been removed. I prefer linking to Wikidata since the links are more stable, and you can always add in a person, they do not have to be famous. --RAN (talk) 05:39, 17 June 2022 (UTC)[reply]

However, I can see why it is removed, I guess because of double linking. Were they all removed? — ineuw (talk) 05:48, 17 June 2022 (UTC)[reply]

The relevant section of the draft policy on linking (which I must get back to and finish tidying up):

The default item view on Wikidata is not user friendly or useful for most people, and for this reason direct wikilinks to Wikidata are not permitted in presentation namespaces. In some cases, however, it may be useful to identify a person or work for which a Wikidata item exists, but for which there is no suitable link target on Wikisource or the permitted sister projects. In these cases it is acceptable to link to Wikidata using the {{wdl}} template, which dynamically displays a link to the most suitable destination based on which targets are available.

Beeswaxcandle (talk) 06:00, 17 June 2022 (UTC)[reply]

For an obituary, I'd say so. Generally, I link to other projects (Wikipedia, Commons categories, or Wikidata via Reasonator) in non-fiction and not in fiction. And yep, as Beeswaxcandle says, using the {{wdl}} template makes it easy (it'll start of linking to Wikidata, but if someone makes an English Wikipedia article it'll change to that without anyone at Wikisource having to do a thing). Sam Wilson 11:26, 17 June 2022 (UTC)[reply]

Paragraphs HTML not closed[edit]

I noticed that in the HTML code when there's an image inserted into a paragraph, the closing tag will be missing (no </p>). -- bp

@BluePrawn: P-tags are allowed to be unclosed in HTML5 (unsure about prior versions): MDN docs. Inductiveload—talk/contribs 21:52, 18 June 2022 (UTC)[reply]

Oh ok html5 became permissive again like html3 was. Html4 was more strict indeed. When there is an image inserted in a paragraph, then opening p tag is also sometimes missing too. Even if it's allowed, closing it would be nicer, and I don't think this is intentional because it's only when there is an image inserted that the closing p tag is missing. -- bp

Tech News: 2022-25[edit]

20:18, 20 June 2022 (UTC)

Validation request Index:My Mysterious Mademoiselle Frank Leslie.pdf[edit]

Short story by Louisa May Alcott (published anonymously and attributed to her in 1993). If anyone wants to take a look, I'd appreciate it :) —CalendulaAsteraceae (talk • contribs) 12:21, 21 June 2022 (UTC)[reply]

Common.js: faux red links?[edit]

(@Inductiveload:) There's a script in th:MediaWiki:Common.js, which I found out to be the same one as MediaWiki:Common.js#L-33 (to line 34) here. I wonder what this script actually does because from asking around in Wikimedia Community Discord, they assume that the script wasn't even necessary.

I would guess that a.stub was added by the automatic stub threshold setting that may or may not have been removed in the recent past
[picture]
yep
so in addition to being poorly documented, that user script/JS snippet wasn't even necessary; the user just needed to disable the stub link formatting threshold in their preferences
-- Dinoguy1000 on Discord

it looks through all links in the div.mw-body (more or less the content area at a guess), and removes the .stub class from any links that have it
if the comment is anything to go by, it was added because of a misunderstanding
and even before the relevant preference was removed, it would've been useless for >99.9% of visitors
basically, if you're looking for JS to axe, that snippet is a trivially easy gain
I'd also suggest to leave a comment on en.WS to have them remove it from their file, too
.
.
make sure to clearly note that that preference no longer exists on WMF wikis, so even for the handful of editors who might've set it once upon a time, the snippet no longer does anything
it probably wouldn't hurt to also note that just disabling that preference would've been the way to disable the link coloring even before the pref was removed, too
-- Dinoguy1000 on Discord, some time after above quote

stjn on Discord told me it's removed in phab:T284917. The script came in revision Special:Diff/5230099. --Bebiezaza (talk) 13:19, 21 June 2022 (UTC)[reply]

@Bebiezaza: Removed. I can't find any context for why it was added, but I'd guess it was an attempt to override a feature added for Wikipedia that made zero sense for Wikisource (what the heck would a "Stub" be on Wikisource?). Thanks for the headsup! Xover (talk) 16:13, 21 June 2022 (UTC)[reply]

J. Michael Luttig[edit]

Judge J. Michael Luttig is very much in the news in the United States since he testified before the January 6 Select committee. Are there any thoughts about adding his testimony to Wikisource? Just curious. Ottawahitech (talk) 15:44, 21 June 2022 (UTC)[reply]

Desktop Improvements update[edit]

Making this the new default

Hello. I wanted to give you an update about the Desktop Improvements project, which the Wikimedia Foundation Web team has been working on for the past few years. Our work is almost finished! 🎉

We would love to see these improvements become the default for readers and editors across all wikis. In the coming weeks, we will begin conversations on more wikis, including yours. 🗓️ We will gladly read your suggestions!

The goals of the project are to make the interface more welcoming and comfortable for readers and useful for advanced users. The project consists of a series of feature improvements which make it easier to read and learn, navigate within the page, search, switch between languages, use article tabs and the user menu, and more. The improvements are already visible by default for readers and editors on more than 30 wikis, including Wikipedias in French, Portuguese, and Persian.

The changes apply to the Vector skin only, although it will always be possible to revert to the previous version on an individual basis. Monobook or Timeless users will not notice any changes.

The newest features

• Table of contents - our version is easier to reach, gain context of the page, and navigate throughout the page without needing to scroll. It is currently tested across our pilot wikis. It is also available for editors who have opted into the Vector 2022 skin.
• Page tools - now, there are two types of links in the sidebar. There are actions and tools for individual pages (like Related changes) and links of the wiki-wide nature (like Recent changes). We are going to separate these into two intuitive menus.

How to enable/disable the improvements

Global preferences

• It is possible to opt-in individually in the appearance tab within the preferences by selecting "Vector (2022)". Also, it is possible to opt-in on all wikis using the global preferences.
• On wikis where the changes are visible by default for all, logged-in users can always opt-out to the Legacy Vector. There is an easily accessible link in the sidebar of the new Vector.

Learn more and join our events

If you would like to follow the progress of our project, you can subscribe to our newsletter. You can read the pages of the project, check our FAQ, write on the project talk page, and join an online meeting with us.

Thank you! SGrabarczuk (WMF) (talk) 16:59, 21 June 2022 (UTC)[reply]

Join us on Tuesday

Join an online meeting with the team working on the Desktop Improvements! It will take place on 28 June 2022 at 12:00 UTC and 19:00 UTC on Zoom. Click here to join. Meeting ID: 5304280674. Dial by your location. The following events will take place on 12 July and 26 July.

The meeting will not be recorded or streamed. Notes will be taken in a Google Docs file and copied to Etherpad. Olga Vasileva (the Product Manager) will be hosting this meeting. The presentation part will be given in English. At this meeting, both Friendly space policy and the Code of Conduct for Wikimedia technical spaces apply. Zoom is not subject to the WMF Privacy Policy.

We can answer questions asked in English and a number of other languages. If you would like to ask questions in advance, add them on the talk page or send them to sgrabarczukwikimedia.org. We hope to see you! SGrabarczuk (WMF) (talk) 21:43, 23 June 2022 (UTC)[reply]

I can already see how these changes are very Wikipedia-centric. (1) For example, things like "Wikidata item" and "Upload file" are not "article-specific" on Wikisource. Nor does Wikisource even have pages that are "articles" unless they are magazine articles or articles from other periodicals. Most pages in the main namespace are not articles, and most mainspace entities consist of multiple pages which together have one Wikidata item. (2) How will the new table of content affect the layout of works on Wikisource that require placing sidenotes in the margins, or rely on other multi-page formatting? (3) Also, will the changes make it possible to find links to a redirect, which used to be possible? Currently, such searches are suppressed, and the supposed way to do such a search does not function. --EncycloPetey (talk) 01:33, 24 June 2022 (UTC)[reply]

Hello @EncycloPetey, thanks for this comment.

1. Some details may be Wikipedia-centric despite of our general approach - sorry for that. I've just replaced every single use of "article" on the documentation page about the page tools menu. I'm well aware that different sister projects have different natures, not everything is an article, not everyone is a Wikipedian.
2. Could you provide some examples? When it comes to Proofread and the Page namespace, we've restored the full width (made an exception to the limited width feature). Works requiring placing sidenotes in the margins - could you share some links?
3. I'll ask, but I doubt if this is about the skin. Perhaps it's more about the search itself... (@Sannita (WMF), FYI.)

SGrabarczuk (WMF) (talk) 02:04, 24 June 2022 (UTC)[reply]

1. It's more than just the label; it's also the placement of those two items which, on Wikisource, are broader (even site-wide) rather than specific to one work. (a) When we upload a DjVu file, for example, it applies to a multi=page work that does not yet exist here, and not to some existing page. And nearly all files should instead be uploaded to Commons; those that are loaded here are either specific to something in the Page namespace or else apply to all the pages of a work. Nothing is ever uploaded for something in the Main namespace. (b) Likewise, Wikidata items usually apply to whole groups of pages and their subpages, and not just to one page.
2. An example of a Page namespace item with Sidenotes is Page:The Solar System - Six Lectures - Lowell.djvu/20 and it is transcluded to The Solar System/Chapter 1 (activate Layout 1 or Layout 2 from the margin to put the Sidenotes into the side; or use default Layout 1 to be them "embedded" in the text. It is unlikely that a ToC will be used in the Main namespace, but there is potential for unforeseen interactions in various namespaces with any new change that alters page layout. This is also true for works that apply a Layout, such as at Coriolanus (1924) Yale/Text/Act III, where the margins are changed by the applied layout. The ToC appears most often on Wikisource in the Author namespace and the Portal namespace. Have these been checked? Such as, against Portal:Ancient Greek drama; Portal:Ancient poetry; Author:Aristophanes; and Author:Henry David Thoreau, to be sure the new ToC interacts appropriately in those namespaces with Wikisource namespace headers? The headers should be full-page width along with the notes displayed below them. The content of a page in the Portal namespace may be full width in content boxes, or may be sections of bulleted lists. And I note that Page Layout is not listed in either sub-menu for the change. Where will it appear?
3. The method for enabling the Search is supposed to be toggable in the Preferences, but the toggle makes no difference. I do not know enough to determine why it isn't working, but it makes page moves a nightmare here, since when a work with multiple chapters gets moved, links to the various chapters need to be checked, including redirects to those targets. It used to be that redirects automatically showed up in searching, but they do not anymore.
4. I did not notice before that there is a plan to move the page-specific Tools to the right-hand side of the page. This will be problematic for Wikisource as a whole. Will users be able to opt out of this placement, or can specific projects opt to not have an additional menu on the right side of the page? For Wikisource, this will be distracting and horizontally compress works, which is a huge problem for poetry, plays, and other kinds of works that need horizontal space for formatting.
5. Moving the Page title above the Tools is also problematic for Wikisource. I would like to know which Wikisource projects thought this would be a good idea?

--EncycloPetey (talk) 02:42, 24 June 2022 (UTC)[reply]

@EncycloPetey, thanks for all these arguments and examples. I'm not familiar with all the workflows and peculiarities of Wikisource, so I've asked @Samwilson to help me assess to what degree your comments are related to the skin itself. SGrabarczuk (WMF) (talk) 19:24, 27 June 2022 (UTC)[reply]

@SGrabarczuk (WMF), @EncycloPetey: Hello! I don't know if I'm totally across everything, but can try to help. :)

1. "Wikidata item" and "Upload file" are not "article-specific" on Wikisource. As far as I can see, these are in the same part of the sidebar that they've always been. I agree that it'd be nice to display the relevant Wikidata item link on every page of a work (in all namespaces) but I don't think Vector-2022 has anything to do with that.
2. The layouts in question are from the PageNumbers gadget (not the best name :-P), see its source for details. It's a default gadget, so everyone sees the new part of the sidebar. I note that Page Layout is not listed in either sub-menu for the change. I see it in the main sidebar in Vector-2022. Is this not what we'd expect? It's pretty independent from the ToC.
3. Search is a separate thing, and I'm not sure it's changed with Vector-2022.

In general, I totally think there's plenty of Wikisource-specific stuff that could be improved! I guess we're just looking for things that are actively broken with Vector-2022 at the moment though.

—Sam Wilson 07:55, 28 June 2022 (UTC)[reply]

@SGrabarczuk (WMF) After using the skin for two or three months, I have noticed a minor issue—the small popup that appears after successfully creating or editing a page perfectly covers the Edit and View History buttons (on my machine, at least), which is slightly inconvenient. Is there an option to turn it off, or shift its location slightly?

Also, can individual wikis change the text displayed when a new talk page is created? Currently it might be easily misconstrued (especially here on WS), as mentioned above.

Besides these quibbles, I have not had a specifically negative experience with the new skin, and some new features are quite nice—for example, the toolbar docked to the top of the window is useful, and I like the use of icons instead of text in both the docked and top-of-page toolbars. Shells-shells (talk) 03:15, 24 June 2022 (UTC)[reply]

The popup issue that Shells-shells mentions in their first paragraph is not unique to the new skin. It happens in Monobook as well. Beeswaxcandle (talk) 03:25, 24 June 2022 (UTC)[reply]

Thank you @Shells-shells. Indeed, @Beeswaxcandle is correct, this popup is related to the editing tools. I think @Whatamidoing (WMF) might help you. SGrabarczuk (WMF) (talk) 03:31, 24 June 2022 (UTC)[reply]

I just tried the new skin and I like it and have made it my default. I like the table of contents on the side but I would prefer it to be collapsible since I use a small screen and it takes up some space. Jpez (talk) 04:06, 27 June 2022 (UTC)[reply]

Thank you @Jpez. Look at the newest prototype. Both the table of contents and the sidebar will be nicely collapsible. SGrabarczuk (WMF) (talk) 17:10, 27 June 2022 (UTC)[reply]

Perfect! Jpez (talk) 18:46, 27 June 2022 (UTC)[reply]

Invitation to join the fourth Wikisource Triage meeting (29th June 2022)[edit]

Hello fellow Wikisource enthusiasts!

We are the hosting the fourth Wikisource Triage meeting on 29th June 2022 at 10:00 AM UTC / 3:30 PM IST (check your local time) according to the wudele poll.

There is some exciting news about a few technical projects related to Wikisource that are getting started right now and we will be sharing more information during the meeting.

As always, you don't have to be a developer to participate in these meetings but the focus of these meetings is to improve the Wikisource infrastructure.

If you are interested in joining the meeting, kindly leave a message on sgill@wikimedia.org and we will add you to the calendar invite.

Meanwhile, feel free to check out the page on Meta-wiki and suggest any other topics for the agenda.

Regards

Sam Wilson (WMF) and Satdeep Gill (WMF)

Sent using MediaWiki message delivery (talk) 07:39, 23 June 2022 (UTC)[reply]

Tech News: 2022-26[edit]

20:02, 27 June 2022 (UTC)