Wikisource:Scriptorium
Community pagesScriptoriumArchives
sister projects: Wikipedia article, Commons gallery, quotes, news, definition, textbook, course, taxonomy, travel guide, Wikidata item, Meta.
Shortcut:
WS:S
WS:SCRIPTORIUM
The Scriptorium is Wikisource's community discussion page. Feel free to ask questions or leave comments. You may join any current discussion or start a new one; please see Wikisource:Scriptorium/Help​.
Some announcements and newsletters are subscribed to Announcements.
Project members can often be found in the #wikisource IRC channel
webclient. For discussion related to the entire project (not just the English chapter), please discuss at the multilingual Wikisource. There are currently 423 active users here.


Announcements
Dynamic layout changes
Dynamic layouts has gained a couple of new functions:
  • You can choose serif or sans-serif fonts independently of the layout (previously, only Layout 2 had serif fonts)
  • You can toggle the {{default layout}} override "live", without having to find and disable a gadget
Both these options will persist across page loads. The advantages of this are:
  • It's quicker and easier to change display options
  • It allows a greater flexibility for users wanting serif fonts (which is possible in these days of ultra-sharp screens)
  • It allows even non-logged in users to configure their display options
There should be no changes to most users, but if you had the default layout gadget disabled (by default, it was enabled), you should change the new setting in the sidebar to "Default layouts off". The new-user default remains the same: "default layouts on".
This does make Layout 4 redundant, since it's just Layout 2 but with san-serifs. Inductiveload​—​talk​/​contribs 10:44, 27 August 2021 (UTC)
For works where the text will be confusing without serifs, do we (can we) create some verbiage in the form of a template that alerts readers to use a serif font and shows them how to accomplish this? I've looked at the verbiage by following the links, and it is not terribly helpful. You need to be very familiar with what is going on to understand what to do, and it took following multiple links to find even a little practical information.
I'd like to be able to alert readers for works such as The Vocabulary of Menander, where there are a lot of uses of "l" for line numbers and "I" for volumes or sections, and it is impossible to distinguish these characters in non-serif fonts. --EncycloPetey (talk) 17:11, 28 August 2021 (UTC)
Alternatively, is it possible to set the default font for a work to "use serif font" (which the reader can choose to turn off)? I see no documentation about how to accomplish this, if it is possible at all. --EncycloPetey (talk) 17:21, 28 August 2021 (UTC)
@EncycloPetey: There is currently no way to specify this. Note that overriding the user's fonts in this way is not ideal, because this also disables accessible fonts like OpenDyslexic, which are provided via ULS. So we'd have to have another switch for "disable default fonts".
Or maybe we just include it as part of the {{default layout}} and the use has both default font and layout, or neither? Inductiveload​—​talk​/​contribs 08:12, 1 September 2021 (UTC)
I also notice that the dynamic option is available in the Main namespace, but not in the Index or Page namespaces. --EncycloPetey (talk) 17:44, 28 August 2021 (UTC)
@EncycloPetey: This will probably be addressed in future as the display options, layouts and page numbering functions get split further apart (they're all kind of munged up together currently). For now, the gadget is not loaded in those namespaces. Inductiveload​—​talk​/​contribs 08:12, 1 September 2021 (UTC)
August Monthly Challenge summary
The August Monthly Challenge is now complete and the numbers are in: 1701 pages were processed (marked no text, proofread or validated), which is sadly under the target of 2000. The following works were fully proofread:
And the following were validated:
As well as quite some progress on other volumes in the challenge.
New works in September include:
Continued series in September:
We are also are starting a new series:
United States Treaty Series, beginning with (Multilateral Treaties 1776–1917), including the Geneva Convention.
And many more! Over 7000 pages of fun for all the family! As always, please drop in as you wish and nominations are open for proposals and comment. Inductiveload​—​talk​/​contribs 08:04, 1 September 2021 (UTC)
Proposals
New Request for Comment on Wikilinking Policy is open
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)
@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)
Proposal: Not proofread reduction drive
The ProofreadPage Statistics show that while we are keeping up with the French on proofread pages, we are around 1/4 validation, and 1/10 reduction of not proofread. [1] I would propose a contest, in the spirit of Tenth Anniversary Contest. We could run it like #wpwp with a hashtag in the edit summary to track contestants. perhaps #npr and #v ? November would be a good timeframe. I would be willing to throw $100 in the pot for each contest. Is there interest in such a contest? Slowking4Farmbrough's revenge 19:56, 21 August 2021 (UTC)
Would this be encouraging people who don't proofread well? (I should rename as "pirfeckshunis") Shenme (talk) 20:42, 21 August 2021 (UTC)
a general encouragement will have errors in it. the existing proofread pages have errors. that would be a problem, we wish we had. but if you want to patrol, disallow, and score keep. go for it. Slowking4Farmbrough's revenge 21:26, 22 August 2021 (UTC)
'patrol … disallow … score keep' Are you, Slowking4 Farmbrough's revenge, planning to adopt one of these roles, or designate who is, or be subject to one of those who are, or just sit back, open a bag of popcorn, and watch the fur fly when people behave in a point-scoring, competitive and inevitably vengeful environment? CYGNIS INSIGNIS 12:24, 23 August 2021 (UTC)
that was not the experience at Tenth Anniversary Contest and #wpwp, but there was some shouting by loud voices at wpwp. the vindictive environment is a product of the loud voices, not the process. Slowking4Farmbrough's revenge 13:08, 23 August 2021 (UTC)
I support the idea of contests in general (obviously, see the Monthly Challenge!), but I do wonder about the usefulness of such a diffuse goal as turning any pages from red to yellow. We have have over 1 million not-proofread pages (nearly 250k of those are from a single user just pressing "save" on the auto-loaded OCR). Any kind of contest involving those pages would spread effort so thin we'd be lucky to see any completions at all.
Also, a lot of the red pages are actually Match and Split works where the text is substantially correct, but not manually verified, so not all red pages are created equal.
I (being heavily biased and not impartial at all) would suggest that choosing specific "not-proofread" works to focus on would be better, and indeed we can do this with the Monthly Challenge. Currently Index:Mrs. Dalloway - Virginia Woolf.pdf is an example of an MC work that started as an all-red Match and Split'd index. We could even have a dedicated month to "red page reduction" where all added works are fully red. It's already been proposed (disclaimer: by me) to have ongoing maintenance as a facet of the MC (for example, reserving a slot for a work WS:Requested texts per month).
Setting up per-user edit counts on the MC is pretty easy to add to the bot, though I would first want to check if people are happy with that, and if we'd need an opt out (or in) system to exclude those who don't with to be included in that aspect of the challenge. Inductiveload​—​talk​/​contribs 06:51, 23 August 2021 (UTC)
you could make a list of red works. the object of a contest would be to recruit new editors. and the hashtag method is inherently opt in. Slowking4Farmbrough's revenge 13:28, 23 August 2021 (UTC)
This does seem interesting, but I worry more about the logistics of what types of pages are not proofread. Perhaps a more limited approach (in the line of the 10th Anniversary Contest) would be good. A careful selection of some number of works filled with NP pages, with pre-set style guides, would help. TE(æ)A,ea. (talk) 23:52, 2 September 2021 (UTC)
the not proofread pages are an ocean of bot generated red saves, which increased recently with some of the million books on commons. a small fraction are pages with tables or images or harder formatting. i do not find preselecting works to be useful, but if you want to go for it. with the hashtag method, any contribution to backlog reduction gets counted. --Slowking4Farmbrough's revenge 19:56, 11 September 2021 (UTC)
I have (without the hashtag) ran through Index:History of the First Council of Nice.djvu and Index:Arizona State Legislature v. Arizona Independent Redistricting Comm’n.pdf; the first was a “bot” save, the second more or less the same (with a few adjustments on the born-digital OCR). TE(æ)A,ea. (talk) 19:59, 11 September 2021 (UTC)
excellent, we have zoomed ahead of the French [2] at that rate after 1000 weeks the backlog should be clear. (maybe i should just send you a check) here is a work list Category:Index_Not-Proofread --Slowking4Farmbrough's revenge 13:59, 14 September 2021 (UTC)
I’ve been looking around Category:Not proofread: I’m on Index:Four and Twenty Minds.djvu now. TE(æ)A,ea. (talk) 15:21, 14 September 2021 (UTC)
Proposal: Move the Collaboration Box to above the New Text Box
Currently, the Collaboration Box is on the lower right hand corner of enWS. The proposal would move the box to the upper left hand corner just above the New Texts box. Experience on frWS has shown that this increases participation due to greater visibility. Languageseeker (talk) 11:56, 20 September 2021 (UTC)
No, absolutely not. Your project is not the top priority here. — billinghurst sDrewth 12:06, 20 September 2021 (UTC)
As the current collaboration box stands, it's far too big for the top-right spot, as it would push New texts below the fold. frWS has a much slimmer front-page box than {{Collaboration}} (or even just {{Collaboration/MC}}) currently is. I'm not dead-set against the concept (and I agree that frWS does do a much better job of driving interest, though I'm not sure that that box's position is the deciding factor), but I'm not in favour of simply re-arranging the existing elements as they are.
That said, I also quite like the slightly more in-depth presentation that the current below-the-fold position allows. Inductiveload​—​talk​/​contribs 12:37, 20 September 2021 (UTC)
@Billinghurst: It's not my project. It's an attempt to increase community collaboration.
@Inductiveload: Do you think this can be done without reducing the number of community collaborations? Currently, we have four: MC, POTM, COTW, and MoTM. Languageseeker (talk) 00:30, 21 September 2021 (UTC)
"Your project" as in "your football team". Contributions come from many sources, and having a singular focus to those additions is a limited focus, and not one that I favour. It is not the top priority. — billinghurst sDrewth 03:29, 21 September 2021 (UTC)
@Languageseeker: not in any form similar to how it is right now: the frWS model doesn't present any other collaboration on the front page. Inductiveload​—​talk​/​contribs 08:42, 21 September 2021 (UTC)
Proposal: Consolidate the Community Collaboration Projects
Currently, on enWS, there are four Community Collaboration Projects featured on the front page: Monthly Challenge, Proofread of the Month, Maintenance of the Month, and Community Collaboration. Of these, Maintenance of the Month and Community Collaboration are defunct, but still occupy the front page. As a result of these multiply collaborative projects, enWS does not have a central location to direct volunteers who wish to contribute. I propose the following. First, formally eliminating Maintenance of the Month and Community Collaboration. Their templates will be marked as deprecated and the Community Collaboration box will be reduced in size. Second, merge Proofread of the Month into Monthly Challenge. The Monthly Challenge project can easily feature a Proofread of the Month text and the Nominations page of the MC is more visible than the nomination page for PoTM. In the end, the Community Collaboration will be reduced to only the Monthly Challenge which will become the central hub for Community Collaboration on enWS. Languageseeker (talk) 13:40, 21 September 2021 (UTC)
a) I see this as the wrong question, it should be "how do we rejuvenate the two dormant collaborations?" When we get them back up and running again, then we can look at how best to represent them all on the Main page. Please offer suggestions on how to bring them back.
b) As to merging PotM with the experimental Monthly Challenge (remembering that we only agreed with setting it up as a trial), this is a premature proposal. The two currently have very different points of focus. The Monthly Challenge's principal focus is to get a certain volume of pages proofread and/or validated in a time period—and, it doesn't matter what work or works those pages come from. PotM has a focus on taking a work we don't already host and taking it through to completion. Given this disparity in approach, I can't agree with merging the two at present. Beeswaxcandle (talk) 09:10, 22 September 2021 (UTC)
Beeswaxcandle: “Experimental” seems an incorrect term; while Monthly Challenge has completed over 2000 pages this month, PotM has done nothing. (The “trial” seems rather successful.) I agree that it is preferable to rejuvenate the defunct collaborations, but such work can only come through community desire. You, too, should “offer suggestions on how to bring them back.” The work which was done through Community Collaboration, for instance, could easily be rolled into work at Monthly Challenge. Your claim regarding the focus of PotM is also rather sophistic—it has been years since that project has consistently completed works month-by-month, and that problem has only gotten worse in the past year. Even in only one month, May 2021 was the last time any work was completed on time—and that work was only 93 pages. TE(æ)A,ea. (talk) 20:36, 22 September 2021 (UTC)
Languageseeker: Oppose merging PotM and MC. At the moment, this seems premature, as those two still appeal to slightly different desires. Oppose hard-deletion of the other collaborations at the moment. Community collaboration used to be a more general place for suggesting proposals for work, but had become (before it became functionally defunct) another proofreading collaboration project. Thus, I believe that project can be phased out. As for MotM, there is much M to do, and many Ms in which to do M; certainly, I would like to see that collaboration brought back. However, the last attempt to restart that project was strongly opposed by a number of people, including you, Beeswaxcandle; but that is not relevant, as that proposal has not been raised here. TE(æ)A,ea. (talk) 20:36, 22 September 2021 (UTC)
@Beeswaxcandle, @TE(æ)A,ea.: I see both of you raising similar concerns and please allow me to answer both of you simultaneously. I am not against the ideas of these individual projects, but the administrative burden and user confusion that they generate. Four separate community collaboration project requires four different users to administer them, four different set of nomination pages, and four different places for users to visit if they wish to participate. Even worse, if a work gets nominated for one project, it cannot be nominated for another. In addition, to these four places to nominate a text, there are at least four separate places to request a text. I simply see too much confusion and fragmentation. My goal is to consolidate things to simplify and make them more efficient. As I'm running the MC, I'm trying to look for good maintenance works (i.e. works that have been worked on, but have stalled); I'm looking at texts that people have requested; I'm looking for texts that should be scan-backed; and I'm trying to think of texts that would attract a broad category of users. My ultimate desire is not merely to achieve a certain number of pages proofread/validated a month, but to increase the number of scan-backed texts and the number of volunteers willing to contribute to enWS. It is my ardent belief that one central hub will be far more effective than four separate projects of varying quality. Languageseeker (talk) 01:51, 25 September 2021 (UTC)
Bot approval requests
Repairs (and moves)
Designated for requests related to the repair of works (and scans of works) presented on Wikisource
Impressions of Theophrastus Such
The work is currently the PG version of Blackwood ed., 1879, with subpages, a new version at Impressions of Theophrastus Such. Essays and Leaves from a note-book/Theophrastus Such so the title might be a dab for these. CYGNIS INSIGNIS 10:12, 1 August 2021 (UTC)
redated to stop being archived. CYGNIS INSIGNIS 12:28, 23 August 2021 (UTC)
Cygnis insignis (talk) 17:11, 9 September 2021 (UTC)
Index:Swahili tales.djvu
The work contains English and Swahili, most of the other language, except where it intermixed with English (about half of the pages), has been done at old wikisource, eg Page:Swahili_tales.djvu/42​. I propose they be moved here CYGNIS INSIGNIS 08:24, 2 August 2021 (UTC)
CYGNIS INSIGNIS 12:28, 23 August 2021 (UTC)
Cygnis insignis (talk) 17:11, 9 September 2021 (UTC)
The Confidence-Man
Please move this work and all subpages to The Confidence-Man (Melville) and redirect The Confidence-Man to The Confidence Man. Rationale: This work needs to be disambiguated from the short story The Confidence Man (Stettenheim). PseudoSkull (talk) 23:20, 13 August 2021 (UTC)
@Billinghurst: PseudoSkull (talk) 18:37, 26 August 2021 (UTC)
Donebillinghurst sDrewth 08:50, 28 August 2021 (UTC)
Undine (1909)
1.) The work is actually from 1919, so I'm pretty sure 1909 is a typo in this title. 2.) The chapters need to be changed to "Chapter 1", "Chapter 2", etc. because according to User:RaboKarbakian, the proofreader, they are not short stories but rather logically consecutive elements of the same story. PseudoSkull (talk) 00:58, 10 September 2021 (UTC)
The translation is from 1909, as it was explained to me by whoever moved it. User:languageseeker is changing the sizes of the images, maybe there is a good reason for that, but the two were sized to go with each other.--​RaboKarbakian (talk) 02:00, 10 September 2021 (UTC)
Oh, then I apologize for the misinterpretation on my part. Anyway, I struck that part of the request out. PseudoSkull (talk) 02:11, 10 September 2021 (UTC)
@RaboKarbakian: My apologies as well. The image sizes are quite small and I wanted to increase them so that they would better match the source text. Perhaps, it would be better to merge the two images into one like we do with maps? Languageseeker (talk) 03:20, 10 September 2021 (UTC)
Inductiveload set a 360px wide limit on images, I break that all the time, but not with 1000pxs which your changes would have made. Also, the different widths had to do with having the same height, Moreover, just a few days ago, Billinghurst did some <includeonely> sourcery that caused them to appear side by side, so even more not to screw up. Did you see it in its Mainspace or just in the Page space?--​RaboKarbakian (talk) 03:25, 10 September 2021 (UTC)
@RaboKarbakian: I made no such "limit". You simply need to be aware that a typical mobile screen is roughly 360 effective pixels wide, so you should ensure that whatever you do do displays sensibly on a screen that width. However, care has been taken with the mobile website skin and some image templates like {{FI}} to make this not a problem for images with "native" sizes (i.e. the size actually served by MediaWiki) larger than that size. Most e-readers (at least all that I have tried) will also scale images to fit the screen if needed.
If in doubt, mobile simulation mode can be used in your browser to check: Help:Preparing_for_export#Online_viewing​. Inductiveload​—​talk​/​contribs 06:29, 10 September 2021 (UTC)
Done; all the chapter subpages have been moved to their proper places. I also deleted a lot of redirects from a previous move which were redundant. PseudoSkull (talk) 00:34, 24 September 2021 (UTC)
Index:The Periplus of the Erythræan Sea.djvu
I saw that the map on the front matter page of this work, at page Periplus of the Erythraean Sea, was not transcluded like the rest and was included arbitrarily. After doing a few minutes of research, I determined that (probably) the reason this was done was because the scan we have is missing the map page, even though it lists it in its table of contents. Our scan originates from https://archive.org/details/periplusoferythr00schouoft while the map was taken directly from another scan, of the same version of the same work, at https://archive.org/details/periplusoferythr00scho/page/n333/mode/2up​. Furthermore, that scan appears to be in much better quality anyway.
So unless there are any contentions, the better scan here should be uploaded to Commons and our current transcription project should be moved there. Pinging @LlywelynII: who originally uploaded the map in 2019, and @Hrishikes: who uploaded the original scan. PseudoSkull (talk) 11:18, 10 September 2021 (UTC)
If the two works have the same page numbering, we can generate a djvu file from the "new" scan and replace the "old" djvu with it,so we need to do (almost) nothing in Page: ns.Mpaa (talk) 17:03, 12 September 2021 (UTC)
Done per above proposal. Mpaa (talk) 21:09, 16 September 2021 (UTC)
John Brown (1909)
This should be moved to John Brown (Du Bois) to disambiguate it from John Brown (Chamberlin) from 1899 (a work I will eventually transcribe). Putting a year is inappropriate in this situation. If there are other versions of the Du Bois work to disambiguate from, perhaps it should be at John Brown (Du Bois, 1909). See John Brown, the disambiguation page. PseudoSkull (talk) 20:15, 12 September 2021 (UTC)
Done. Mpaa (talk) 20:45, 13 September 2021 (UTC)
Miscellanies–Thoreau
This should be moved to Miscellanies (Thoreau), especially as there is no indication that I'm aware of that the work actually includes an em dash in the title in this manner. PseudoSkull (talk) 21:29, 12 September 2021 (UTC)
WP:Be bold ;-) --Jan Kameníček (talk) 21:38, 12 September 2021 (UTC)
Done. Mpaa (talk) 20:10, 13 September 2021 (UTC)
Index:Transactions and Proceedings of the New Zealand Institute - Volume 1 (2nd ed.).djvu
Found a missing page that wasn't apparent initially. Following page position 499 there should be a blank and print page 465. https://archive.org/details/mobot31753002618145 has the needed pages at postions 494 & 495. This file has other problems, so I don't want to simply upload it over the previous. Could the missing pages please be interpolated and then all proofread pages from current position 514 through to 540 be moved down by two positions? Beeswaxcandle (talk) 04:26, 14 September 2021 (UTC)
@Beeswaxcandle:
Done Please check the results.Incidentally, Inductiveload has set up Wikisource:Scan Lab (WS:LAB) for these kinds of requests, along with a
{{ping project|Scan Lab}}
template to notify all those that have put their names down to help out when you add a new request. Xover (talk) 10:54, 14 September 2021 (UTC)
@Xover: Out of interest, how on did you get that 300MB file to upload today? I've had 13 files (out of 13) fail to upload today with stash failures (falling back to an IA upload and a server-side request: phab:T290900). All using chunked/async uploading. Inductiveload​—​talk​/​contribs 11:25, 14 September 2021 (UTC)
@Inductiveload: Just BigChunkedUpload and prayer. It is most likely not primarily the raw file size it's choking on, but the processing time of the metadata (which includes the page structure and text layer), so raw file size is only loosely correlated with upload failures. Xover (talk) 11:48, 14 September 2021 (UTC)
A Short View of the Frauds and Abuses committed by Apothecaries
There are a lot of things that need to be done here because this has become convoluted, and I'll explain each step.
  1. Delete Merret - A short view of the frauds and abuses committed by apothecaries/Title as it's just a duplication of the content at A Short View of the Frauds and Abuses committed by Apothecaries.
  2. Move A Short View of the Frauds and Abuses committed by Apothecaries to A Short View of the Frauds and Abuses Committed by Apothecaries. Reason: If we're going to do title casing, we should do it consistently.
  3. Move Merret - A short view of the frauds and abuses committed by apothecaries/Chapter 1 to A Short View of the Frauds and Abuses Committed by Apothecaries/Essay. First of all, these don't need to be chapters, because they're not really "chapters" and are not labelled as such. Secondly, the transcluded sections here have different titles than the front matter page does. The page title was clearly taken from the name of the index page, whether accidentally or not I don't know.
  4. Move Merret - A short view of the frauds and abuses committed by apothecaries/Chapter 2 to A Short View of the Frauds and Abuses Committed by Apothecaries/Postscript​. Same reasons as for #3.
Pinging @Chrisguise: to let know of move discussion. PseudoSkull (talk) 16:55, 14 September 2021 (UTC)
Done. Mpaa (talk) 05:23, 17 September 2021 (UTC)
Other discussions
Policy on substantially empty works
[This is imported from WS:PD, where it applies to multiple current proposals, and several other works].
We have quite a few cases of works that are "collective" or "encyclopaedic" in that they comprise many standalone articles of individual value, which are basically just "shell pages", with no substantial content of any sort, not even imported scans or Index pages. For example, and this isn't intended to make any statement about these specific works, they're just examples and they may well get some work done soon during their respective WS:PD discussions:
Based on the usual rate of editing for things like that, unless dragged up into a process like WS:PD, they'll remain that way a very, very long time. I think it is perhaps there might be a case to host a mainspace page for this work, even though there is zero, or almost zero actual content. Do we want:
  • Mainspace pages where this is a tiny bit of information like header notes, scan links and maybe detective work on the talk page (not in this case). This provides a place for people to incrementally add content. Also gives "false positive" blue links, since there is actually no "real" content from the work itself, or
  • Do not have a mainspace page until there's some content. Only host this in terms of scan links author/portal scan links, much like we do for something like a novel.
Personally, I lean (gently) towards #2, but with a fairly low bar for how much content is needed. Say, Indexes, basic templates, a title page and one example article. Ideally, a completed TOC if practical, especially for periodical volumes/numbers. It is fair to not wish to transcribe entire volumes of these work, it is fair to not want to import dozens of scans when you only wanted one, it is fair to only want an article or two, but it's not fair, IMO, to expect the first person who wants to add an article to have to do all the groundwork themselves, despite having been lured in with a blue link. That onus feels more like it should be on the person creating the top-level page in the first place.
I do see some value in periodical top pages with decent lists of volumes and scans where known, because these are often tricky and fiddly to compile from Google books/IA/Hathi, so it's not useless work, even if there are no imported scans (though imported is better than not).
We currently have a large handful of collective works listed for deletion right now in various levels of "no real content", and, furthermore, every single periodical that gets added can fall into this situation unless the person who adds, so I think we could have a think about what we really want to see here. Inductiveload​—​talk​/​contribs 15:43, 3 July 2020 (UTC)
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).
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)
@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)
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)
move the works to a maintenance category, and i will work them; delete them and i will not: i find your sword of Damocles demotivating. Slowking4Rama's revenge 01:55, 5 July 2020 (UTC)
@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)
TEA is on his usual deletion spree. not a fan. will not be finding scans to save texts, any more. he can do it. Slowking4Rama's revenge 00:15, 6 July 2020 (UTC)
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)
and yet deletion is the default method to "motivate" quality improvement. i reject your assertion that "emotions get stirred in a deletion discussion", rather, anger is a valid response to a repeated broken process being kicked down on the volunteers. it is unclear that a minimum threshold is necessary, rather a functional quality improvement process is. until we have one, you should expect to see this periodic stirring of emotions, as the non-leaders act out. Slowking4Rama's revenge 11:53, 9 July 2020 (UTC)
@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)
deletion threat has been an habitual method of communicating by admins since the beginning of the project. and text dumps have been habitual following in the guttenberg example. culture change and process change would be required to change those behaviors. we could may it easier to start scan backed works, but the wishlist was not supported. Slowking4Rama's revenge 21:00, 14 July 2020 (UTC)
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:
  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)
@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)
I meant the namespace. Clarified now. JesseW (talk) 05:17, 6 July 2020 (UTC)
  • 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)
  •  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)
    • @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)
      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)
  • 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)
    @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
    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)
@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)
@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)
    @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)
    @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)
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)
Apologies, I see I had missed the point.
I disagree with Xover's statement that a top-level page for a publication, with a link only to a single article within the publication, has "near-zero value." Such a page can serve an important function linking content together in ways that help the reader (and search engines) find the content they're looking for, or understand the context around it. For instance, A Critical Dictionary of English Literature is linked from the relevant Wikidata entry. The banner on the Wikisource page clearly tells a Wikisource reader that they won't find a full transcription here; and with a simple edit, it could link to a full scan on another site, or (with perhaps a little more effort) even transcription links here on Wikisource. This page has been here since 2010; we don't have any way of knowing what links might have been created elsewhere in the intervening decade. (I do think that new pages like this should not be created without a scan at Commons to be linked to.) -Pete (talk) 02:12, 8 July 2020 (UTC)
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)
Proposal
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)
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)
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)
@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)
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)
@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)
Universal Code of Conduct News – Issue 1
Universal Code of Conduct News
Issue 1, June 2021
Read the full newsletter
Welcome to the first issue of Universal Code of Conduct News! This newsletter will help Wikimedians stay involved with the development of the new code, and will distribute relevant news, research, and upcoming events related to the UCoC.
Please note, this is the first issue of UCoC Newsletter which is delivered to all subscribers and projects as an announcement of the initiative. If you want the future issues delivered to your talk page, village pumps, or any specific pages you find appropriate, you need to subscribe here.
You can help us by translating the newsletter issues in your languages to spread the news and create awareness of the new conduct to keep our beloved community safe for all of us. Please add your name here if you want to be informed of the draft issue to translate beforehand. Your participation is valued and appreciated.
  • Affiliate consultations – Wikimedia affiliates of all sizes and types were invited to participate in the UCoC affiliate consultation throughout March and April 2021. (continue reading)
  • 2021 key consultations – The Wikimedia Foundation held enforcement key questions consultations in April and May 2021 to request input about UCoC enforcement from the broader Wikimedia community. (continue reading)
  • Roundtable discussions – The UCoC facilitation team hosted two 90-minute-long public roundtable discussions in May 2021 to discuss UCoC key enforcement questions. More conversations are scheduled. (continue reading)
  • Phase 2 drafting committee – The drafting committee for the phase 2 of the UCoC started their work on 12 May 2021. Read more about their work. (continue reading)
  • Diff blogs – The UCoC facilitators wrote several blog posts based on interesting findings and insights from each community during local project consultation that took place in the 1st quarter of 2021. (continue reading)

unsigned comment by SOyeyele (WMF) (talk) 22:37, 10 June 2021‎.
Index:Robert Carter- his life and work. 1807-1889 (IA robertcarterhis00coch).pdf
First run through is done, and it's transcluded. Needs validation. Thanks in advance for any help. Jarnsax (talk)
If I may... about the Monthly Challenge
Hi! I'm Ernest-Mtl, who started this kind of monthly challenge on the French-language Wikisource in 2019… Originally called Défi 5000' for 5000 proofread pages per month but later changed in October 2020 for Mission 7500 for 7500 proofread or validated pages… Before that, our community collaboration was simply called Défi du mois (Monthly challenge) but would barely meet the completion of a few books (about 1000 to 2000 pages per month).
Our experience showed a few things:
  • Naming the challenge with a number brought the people to participate a *LOT* more… from less than 2000 pages per month, calling it Défi 5000, brought us to an average of 6319 pages per month in 2019 and now, with the Mission 7500, we have an average of 9456 pages in 2021 so far…
  • Placing the actual results of the challenge on the main page from sensibly the same place you have yours actually to the upper right side column, just before new texts in a little container brought a lot more people because they don't have to scroll down the page.
  • People like to see actual results of what they participated in… that's why we started to advertise how many books were publish with our challenge. For example, they can see in almost real time how many works were completed in the current month, for each month and for the whole year. Seeing the challenge permited to publish in 2019 305 books out of 589 on our complete wikisource project brought them to continue their implication.
  • In the beginning, every month I was doing a post on the scriptorium to show the evolution of the challenge. Nowadays, it's not necessary anymore.
  • We try to represent as much as possible all the country of publication every month (mainly France, Canada (Québec), Belgium, Switzerland) ; we try to have a variety of works as well : novels, poetry, theatre, science, novella or short-stories, etc…
It was rough to start but brought vigorous implication in the challenge. I hope the English-speaking community will make your challenge sky-rocketed! :)
--Ernest-Mtl (talk) 14:12, 11 August 2021 (UTC)
@Ernest-Mtl: thanks for the message! Some things I'm hoping to add to our MC:
  • Tags in {{New texts}} for MC works
  • Live progress bars for indexes (so it won't need a bot to keep them up-to-date) - the backend is nearly ready
  • A way to record finished books would be good. Currently, validated books are the bottom of the page, but there's no global list of MC-completed works.
  • I haven't done a Scriptorium post this month because I rushed the MC changeover
  • I avoid naming after a number because I wasn't sure what we could achieve. 2000 seems a decent target for now — we hit that the first two months, missed by hair last month). We do have limited participation (myself included), possibly due to summer and also from lack of awareness or desire to work on shared works (?)
Thank you very much for the other notes, I will bear them in mind. I plan to revisit some of the implementation soon, when I have a bit of time and once some back-end facilities are ready.
And of course a big "thank you" for the idea and frWS implementation that we could "be inspired by" (or shamelessly rip off). The massive success of the frWS Défi is what made me so keen to give it a go here. ♥ from enWS :-) Inductiveload​—​talk​/​contribs 10:13, 12 August 2021 (UTC)
@Inductiveload: Well, nothing is a rip off in a community project… We're all working with the same goal… sharing interests and bringing people together working toward a shared goal… lol PS: I've seen your system is a lot more automated than ours… We are still doing the counting by hand (almost) using the bookworm bot reports… I'm kinda jealous! hahahaha --Ernest-Mtl (talk) 14:59, 28 August 2021 (UTC)
excellent. we are keeping up with French in proofreading, but not validation. so let the competition begin. Slowking4Farmbrough's revenge 15:03, 12 August 2021 (UTC)
@Slowking4: That could be a cute thing to do… finding 5 books in English and their French translations… Then creating a friendly competition… hehe --Ernest-Mtl (talk) 14:59, 28 August 2021 (UTC)
@Inductiveload: Thank you for your wonderful note and I'm sorry that I wasn't around during the summer. Your Défi was indeed the inspiration when I proposed this to Inductiveload. It's been utterly amazing to explore frWS and see the treasure trove of scan-backed works. Thank you for all your work.
@Inductiveload: I think that we should try these three things.
  • Tagging MC texts in the New Text box. This might require a formal proposal because one particular, powerful member is against the idea.
  • Moving the Collaboration box to above the New Text box.
  • Instead of formally naming our challenge MC, we can provide a progress bar showing our progress towards the goal number_of_pages_completed [Progress Bar] 2000. Languageseeker (talk) 10:57, 20 September 2021 (UTC)
@Languageseeker::
  • There was a proposal for this in June, which got a bit of general support, but no further comments on the implementation proposed at Template:New texts/sandbox. Based on the very strong opposition leading to instant reversion of the download links for new items after proposal and implementation, that's not enough to convince me to move forward. I'd support a new proposal, though.
  • Moving the Collaboration box to above the New Text box. This will definitely need a separate discussion.
  • Instead of formally naming... porque no los dos? I have a little more work to do on the background logic for the stats in light of the new Lua lib for that, however. Inductiveload​—​talk​/​contribs 11:19, 20 September 2021 (UTC)
Inductiveload​—​talk​/​contribs 11:19, 20 September 2021 (UTC)
While we're on the subject: the Monthly Challenge has just completely validated all three volumes of Sense and Sensibility, finally completing the progress on a page that has existing since 2004! Thank you everyone involved! Inductiveload​—​talk​/​contribs 19:34, 12 August 2021 (UTC)
It's a shame though, that the work still contained scores of errors because (I'm guessing) the text was matched-and-split to a scan of a different edition with different punctuation and spelling conventions. Validation can't be relied on as a sign of quality. BethNaught (talk) 07:57, 20 September 2021 (UTC)
@BethNaught: This is a real shame. Hopefully, this is the result of an older match-and-split that does not happen anymore. Thank you for revalidating this work. Languageseeker (talk) 10:57, 20 September 2021 (UTC)
The proofread and validation should pick up that we are in a different version and correct. Something askew there. — billinghurst sDrewth 12:10, 20 September 2021 (UTC)
new page notice
The blurb when creating a new Page is currently:
"This page does not exist yet; you can create it by typing in the box below and publishing the page. If you are new to Wikisource, please see Help:Adding texts. If you are here by mistake, just click your browser's back button. If no text layer is automatically made available, click the OCR button [obsolete] on the toolbar to try to generate one. To open and close the header and footer fields, toggle
. Also see Proofreading instructions. [links, etc]"
There is a very small audience for these instructions, most of which is out of date and unneeded by proofreaders. I recall their introduction as a reaction to a test or other by a 'new user', not fulfilling an actual need.
"This transcription page has not been created. For assistance see Help:Adding texts."
To the point, more helpful, and returns screen territory to users who see this more than once. CYGNIS INSIGNIS 13:00, 12 August 2021 (UTC)
yes. the instruction creep gets ignored, so less is more. but also some UX with veterans and newbies would be helpful.--Slowking4Farmbrough's revenge 14:51, 12 August 2021 (UTC)
Yes, yes, it is really really annoying to see the same blurbishnessblup over and over. And over. Toggle this info or make it curt and direct. Shenme (talk) 20:53, 18 August 2021 (UTC)
 Comment can we have suggestions to improve or pointers the change that should be made rather than "I don't like it", "this is old", etc. Some of the pages for text are
MediaWiki talk:newarticletext using file:Button ocr.png <= all new articles get some text
So pointers to the image in use would be great. Some of us don't see it either for blocking or with older toolbars.
Also noting that we have some paired text in special:preferences at MediaWiki:Proofreadpage-preferences-showheaders-label​. — billinghurstsDrewth 02:13, 26 August 2021 (UTC)
Two supports and a comment from the creator of the former text. Does anyone have a tweak to the replacement text—proposed above—before it is implemented? Cygnis insignis (talk) 16:59, 9 September 2021 (UTC)
Request for comment notification
Here is a link to a RFC on Meta concerning all Wikimedia projects. unsigned comment by Lionel Scheepmans (talk) .
{{greek}} vs. {{polytonic}} vs. lang=el vs. lang=grc
So having had two instances lately where using
{{greek}}        (monotonic ≈ modern Greek)
vs.
{{polytonic}}   (polytonic = ancient Greek)
actually mattered, I've been sensitized to these. Then when I thought "hey, shouldn't I be adding a
{{lang|el|...}}
around these" I went looking.
{{polytonic}} correctly sets lang="grc" for its enclosed text. This is the tag for "Ancient Greek".
{{greek}} also sets lang="grc". Not the tag for modern Greek lang="el". This is wrong and likely a leftover from before {{polytonic}} existed.
Or else we need a third template for Modern Greek, but then we'd need to find all the wrong uses, though there are many uses (3450?) and many wrong confused anyway.
How much of a mess to use lang="el" in {{greek}}. How much of a mess to continue making a mess with wrong usages? Shenme (talk) 04:26, 24 August 2021 (UTC)
And then there's Hebrew, completely different! {{hebrew}} says use a font that looks more ancient, but says/does nothing about language tag. {{lang-he}} will set language tag to lang="he". So to match the work I'd have to do
{{lang-he|
{{hebrew|ד}}
}}
to get ד‎ ? (it does work upon inspecting generated HTML) Bleh! Shenme (talk) 06:02, 24 August 2021 (UTC)
@Shenme:: so for Greek, I would imagine (code for "making it up") that nearly all Greek on WS is Ancient (grc). Only a handful of works are likely to be in Modern Greek (el), perhaps some dictionaries and phrasebooks, maybe "modernified" Ancient Greek (if there is such a thing), or maybe some untranslated quotation from a modern Greek author (monotonic Greek was only mandated in the 80s, so it's very new in WS terms).
For example the Catholic Encyclopedia is using polytonic Greek (you can tell because there are some breathings like "ὕ", e.g. here), so we can probably just bot them to {{polytonic}} on a work-by-work basis.
{{Greek}} denotes monotonic Ancient Greek, according to its documentation. Is that even a valid combination?
If not, we should probably move all uses of it to {{polytonic}} (but keep an eye open for modern Greek), and then redirect both {{grc}} and {{Greek}} to {{polytonic}} (because WS is overwhelmingly using polytonic Ancient Greek). Then, use {{el}} → {{Modern Greek}} to handle the rarer case. Inductiveload​—​talk​/​contribs 07:53, 24 August 2021 (UTC)
If you're going to collapse Greek and Polytonic templates to a single one, then please be sensible and redirect Polytonic to Greek. It makes absolutely no sense the other way. User sees Greek text to enter, they use Greek template to mark it. Nice and simple and no need to mess around with the arcana of monotonic vs. polytonic. Regardless of what is decided, I will continue to use the greek template in any and all works that have Greek text to be entered [and will continue to teach others to do the same]. Beeswaxcandle (talk) 08:55, 24 August 2021 (UTC)
Right, but the point is that as it stands, {{Greek}} is not suitable for general use for polytonic Greek, because font support isn't universal (which is why ULS provides a font for it). So using it for anything that's actually polytonic Greek is wrong. On the other hand {{grc}} is a redirect to {{polytonic}}! AFAICT, nearly all Greek at Wikisource is Ancient Greek. It's is not your fault that {{Greek}} doesn't do the right thing in most WS use cases, but it might need fixing.
Assuming the only valid options are "grc + polytonic" and "el + monotonic/no ULS", it doesn't technically matter which one redirects to the other since {{Greek}} and {{Polytonic}} would be synonyms. But if it does turn out to be the case, then, yes, it makes sense for {{Greek}} to be the "main" template as that's more consistent with other templates and it's clearly the one a user would reach for when seeing Greek text. But I will need input from someone with a better education in classical linguistics than me about whether it's ever valid to have a "grc" lang code, but not to use the polytonic font support in ULS (i.e. the current status quo of {{Greek}}).
In the meantime, {{el}} → {{Modern Greek}} have been created for use in things that are unambiguously modern, monotonic Greek. This sets the correct HTML lang code (el), so it's also better for accessibility/i18n/etc. We'll also need to carefully check if there is any modern Greek chucked into {{Greek}} and change it accordingly. Inductiveload​—​talk​/​contribs 11:16, 24 August 2021 (UTC)
Going from w:Monotonic Greek, modern Greek is only officially monotonic since 1982, and there's still sources writing it in polytonic Greek script. Modern Greek from 95 years ago is likely to be polytonic. OTOH, exact copies of pre-2nd century AD Greek works are likely to be missing accents and breathing marks, and we may have as much of that as modern monotonic Greek.--Prosfilaes (talk) 11:35, 24 August 2021 (UTC)
Stuff written in Hebrew script is not necessarily in Hebrew. Yiddish was written in Hebrew, and there's Jewish variants of local languages in many places of the Jewish diaspora, so Hebrew script might be any number of languages. Script in general can not be conflated with language.--Prosfilaes (talk) 10:06, 24 August 2021 (UTC)
What's the goal here? Do we really need these templates in 2021? When I look at Template:Greek, I see three lines with minor font differences, and no reason not to just go with the top line. Is there a significant audience that needs these templates to see Greek, Polytonic or otherwise, correctly? Systems from the last decade should all come with Unicode fonts that cover at least Polytonic Greek. mw:Compatibility#Browsers says MediaWiki doesn't support any browsers before 2013, and I don't think anyone running systems after that should need these templates.--Prosfilaes (talk) 11:22, 24 August 2021 (UTC)
I have no idea: I guess that's a question for the ULS team, since (I hope) they have a handle on which fonts are needed and which are not. I'd quite like to see the back of polytonic if there is no supported system without polytonic Greek support (not sure that's always a browser thing), because the provided font itself is pretty ugly.
However, a template is still needed because, webfont or not, the text should still have lang="grc" applied (and modern Greek should have el).
Indeed, enWP has deprecated their polytonic template in favour of {{lang|grc}}. Inductiveload​—​talk​/​contribs 11:39, 24 August 2021 (UTC)
After looking into this some more, it's clear that the {{polytonic}} template is redundant. Using the grc lang code is what is required to trigger ULS into serving a suitable font if needed.
So, now {{polytonic}} and {{grc}} are redirects to {{Greek}}, which uses the standard core template {{lang}} to apply the HTML lang attribute.
If users really want the old polytonic font fallback list (which always looked horrible to me, since it would end up at FreeSerif), they can add the following to their CSS (according to what font they want, and what they have installed):
[lang=grc] { font-family: Gentium, "Linux Libertine", "Palatino Linotype";}
If enough users wish for a way to set this to some kind of "serify" font, we can make that a Gadget, which will apply evenly to all grc text, not just polytonic, which, in the age of Unicode, doesn't need special font support in 99% of cases. Inductiveload​—​talk​/​contribs 11:48, 26 August 2021 (UTC)
Also, ULS does actually already allow one to set GentiumPlus as the font for grc text, but the way to do that is not well-exposed and needs a bit of a rigamarole: see phab:T289777 for the method. That task is also asking for a better way to set this though the ULS UI. Inductiveload​—​talk​/​contribs 13:34, 26 August 2021 (UTC)
I completely disagree with the move to redirect Polytonic to Greek. The whole point of the Polytonic template was to render Ancient Greek (Polytonic) text correctly. I've edited thousands of pages in the 1911 Encyclopædia Britannica to use {{tl:Polytonic}} in place of {{tl:Greek}}. 'Polytonic' displays the Ancient Greek text very close to the printed version. There was a discussion a few years ago in the Polytonic page about which fonts to include (someone had added fonts which did not render Ancient Greek correctly, those fonts were subsequently removed.) Why not revert the 'Polytonic' change, rename it 'Greek' and create a redirect from 'Polytonic' to 'Greek'? The vast majority of texts in Wikisource date prior to 1982 when monotonic orthography was introduced in Greece, so Polytonic fonts should be the default for Greek text.
If we want to use Polytonic fonts, why stop us from doing so by changing the template? DivermanAU (talk) 23:11, 26 August 2021 (UTC)
I've done similar work - not as much as DivermanAU - and followed the advice on the EB1911 project page style manual: use {{Polytonic}} "not to produce the characters, but because it renders in a more authentic font that shows the diacritics better." I assumed that was written by someone who understood the rendering choices, so unless someone proves that claim wrong I prefer the status quo. DavidBrooks (talk) 03:34, 27 August 2021 (UTC)
The thing here is that there is no such thing as a "polytonic font". Pretty much all "major" fonts that users would have as the browser default font have full support of the code points (which may not have been true in 2005), so then it's just down to styling. As a rule, Wikisource does not specify fonts to users (if we did, we'd set serif fonts almost everywhere, and we do not), as fonts are a user choice via their user-agent (usually a browser, ereader, etc). The principle of user-agent choice is the reason mw:Extension:UniversalLanguageSelector exists in the first place, and is at least partly related to accessibility.
At least on my system, {{polytonic}} is actually rather unattractive, because I don't have those "nice" fonts like "SBL BibLit, SBL Greek", which I assume are there because someone had them installed locally, so it ends up at "FreeSerifCode2000", which, yes, looks a bit more like the original fonts only because it's a serif font, but also stands out unattractively when the rest of the page is as default. In the general case, there's no way to pre-empt what fonts users have installed, or want to use. So, RE 'Polytonic' displays the Ancient Greek text very close to the printed version. this depends very much on the fonts the user has locally. If you have "SBL Biblit", it might look amazing for you, but that's not a font Wikisource serves itself (they're also not freely licensed, so WS probably can't serve them), so most people will not have it.
If we did want to force "better" fonts for users for Greek, it should really be done based on the standard (as in, web standards) lang codes (grc and/or el), rather than on "directly-applied" case-by-case basis (i.e. by specifying polytonic vs Greek). There are a few ways to achieve that:
  • Get phab:T289777 done, or implement some other way for users to dynamically change their per-language ULS font choices (which is what ULS is for)
  • Continue to use Template:Greek/fonts.css
  • Indexes set their own styles on [lang=grc] elements.
  • Users set their own overrides at their commons.css on [lang=grc] elements on a per-user basis (ultra-flexible, but not very user-friendly)
Also, it's now possible to set the entire display of content to a serif font from the Display Options menu, so if you're after "as printed" display, that will get you closer than forcing fonts for a subset of instances of a certain language. Inductiveload​—​talk​/​contribs 09:15, 27 August 2021 (UTC)
The recent change to the 'Greek' template has meant that the display has also changed from serif-style to non-serif style ('Polytonic' used to make sure that other devices, like Chrome-books, displayed a serif style font). Until recently, most computers using the 'Greek' template showed the serif font, but now they don't. Can we please allow 'Polytonic' and 'Greek' templates to show serif fonts as before. DivermanAU (talk) 23:39, 27 August 2021 (UTC)
This is a good example of what I'm saying about you can't make assumptions about what users see: for me, and I imagine nearly all other Linux users who likely have DejaVu fonts, {{Greek}} has always been sans serif (DejaVu Sans). Polytonic used (the ugly, IMO, Code2000).
The right way to deal with this is probably to lean on ULS, because that's exactly what it is for (and it can also serve up a nice font to use: Gentium). However, since knowing how fast things move, phab:T289777 will linger for a very long time, so we'll go back to a manual fallback list for now. But we really need to sort this out at some point, as forcing a font choice on the user is, IMO, poor form.
I have also promoted DejaVu fonts above FreeSerif, because they are much more consistent with surrounding text if you're on a system that has DejVu fonts, and promoted DejaVu Serif above the Sans (same order now as FreeSerif/FreeSans). I'm not quite sure why the ultimate fallback is sans-serif, not serif, or why the last several fonts are sans, but the "top" ones are serifs. But at least now I think they'll at least be similar for most users. And mono and polytonic will now be consistent - as long as the language is Ancient Greek, the font will match.
I'll keep looking for a way to do this properly without having to pre-empt the user-agent. Inductiveload​—​talk​/​contribs 00:45, 28 August 2021 (UTC)
Thanks for making those recent changes — the 'Polytonic' and 'Greek' template display on Windows 10 PCs now shows as serif font again. However, on a ChromeBook and a MacBook Pro, using 'Polytonic' still displays as sans-serif, whereas prior to 'Polytonic' being redirected to 'Greek', the display was a serif font. For what it's worth, the 'Polytonic fonts' template (as previously used by 'Polytonic' apparently ) has these fonts: 'SBL BibLit', 'SBL Greek', Athena, 'Foulis Greek', 'Gentium Plus', Gentium, 'Palatino Linotype', 'Arial Unicode MS', 'Lucida Sans Unicode', 'Lucida Grande', Code2000. DivermanAU (talk) 05:52, 28 August 2021 (UTC)
Template:PD-nonUK
I've been confused by this template for a long time and it's been bothering me, and it has occurred to me now that it's because of the template's vagueness and lack of specificity.
It currently says "This work is in the public domain outside the United Kingdom because the author has been deceased at least 100 years. However, owing to the subsistence of certain long-standing restrictions on publication and distribution, the work is NOT necessarily copyright or restriction free in the United Kingdom." What certain long-standing restrictions are these? Which UK laws apply here specifically? And does this only apply to certain old works in the United Kingdom, all old works originally published in the UK, or all old works regardless of country of origin? As someone completely unfamiliar with UK copyright law, I have no idea what someone ought to be worried about if they're in the UK.
Some past discussion on this matter: Wikisource:Possible_copyright_violations/Archives/2006/04#Book_of_Common_Prayer and Template talk:PD-nonUK#This perpetual copyright will eventually end
While it's been talked about before in these places, I think the wording of this template still needs to be more specific so our readers don't have to dig around our community chatter to find out why this template exists. Pinging User:Jusjih. PseudoSkull (talk) 13:36, 25 August 2021 (UTC)
There isn't a single route to this template. The uses I know of:
  • Peter and Wendy: the play (not the book, which came later) was granted perpetual copyright in the UK (because just allocating funds for a children's hospital would be too easy): details here, but the law is a specific section of the CPDA 1988.
  • KJV and Book of Common Prayer are another, totally separate, weird thing where permission to print the works is restricted by royal prerogative via letters patent, rather than copyright. The CPDA 1988 has a (non-specific) carve-out under para (1)(b) here (and I don't know if the actual letters patent are published anywhere, but if they were, we can have them too since, y'know, pre-1925).
Tl;dr there's not a single law that applies here, though both these cases are covered partly under the CPDA, which makes sense because that provides pretty much all relevant law in the UK. Inductiveload​—​talk​/​contribs 14:15, 25 August 2021 (UTC)
I started the template only due to others talking about the British perpetual copyright. I am unfamiliar with it, so correct the template as needed.--Jusjih (talk) 18:04, 13 September 2021 (UTC)
Should no The and The be disambiguated?
There is Orange Grove (1866) by Sarah E. Wall, but there's also a book called The Orange Grove (1829) by Mary Martha Sherwood. Should they be disambiguated at a main Orange Grove page? This would put the wall text at Orange Grove (Wall) and the Sherwood text at The Orange Grove (Sherwood). @Billinghurst: if you think this is compelling, can you please make the more from Orange Grove -> Orange Grove (Wall)? PseudoSkull (talk) 18:32, 26 August 2021 (UTC)
I suppose it should be moved because "The Orange Grove" by Sherwood could just be referred to as "Orange Grove" in some sources. PseudoSkull (talk) 18:33, 26 August 2021 (UTC)
**If** we are to disambiguate, then we would go to "Orange Grove"; when they have been like that we have not forced a disambig, nor have we been concerned if someone does. It just means that we cannot have hatnotes until we do. Your call on what you would like done. — billinghurst sDrewth 08:39, 28 August 2021 (UTC)
@Billinghurst: After some thought, I would like the move to be carried out. Could you please initiate that process as I cannot? PseudoSkull (talk) 17:43, 9 September 2021 (UTC)
Will do. — billinghurst sDrewth 23:25, 9 September 2021 (UTC)
"It sometimes seems wrong to omit a, some say the, definite article." [adapted from unattributed] CYGNIS INSIGNIS 12:39, 28 August 2021 (UTC)
Definitely would agree on produced works that we don't omit "A"/"An"/"The". The ability to group on disambiguation pages, and have redirects gets us around this issue, especially where the names of works are regularly referred to without these articles, and maintaining multiple disambiguation pages for each was leading to holes, confusion and related issues. I would also say that if we are doing a {{versions}} page that we would do that **with** the article not without as we do for disambiguation. — billinghurst sDrewth 23:25, 9 September 2021 (UTC)
@Cygnis insignis: Wrong as it may be, many times I've seen book titles referred to in this way in works I've proofread, which in my mind makes it make sense for there to be redirects from articleless titles. Perhaps the writer had an incorrect memory that the external work title did not begin with "The", or perhaps they had some idea that omitting it was okay. PseudoSkull (talk) 12:05, 15 September 2021 (UTC)
@PseudoSkull: it's all good in context, and we might see: '… the Orange Grove' as a reference to either work, but I'm guessing it is always The Tiger / Raven. Definitely following the context, by reading, than predisambiguation, by rule, is reasonable. (I didn't look deeply at teh examples, one is a red link) … actually, unbracket, one is a redlink :/ Cygnis insignis (talk) 12:24, 15 September 2021 (UTC)
and citation for authoress-ship please? Cygnis insignis (talk) 12:29, 15 September 2021 (UTC)
Public domain book?
Battle-Retrospect And Other Poems (1923, Yale Series of Younger Poets: New Haven, Yale University Press) by American author Amos Niven Wilder (1895-1993). Wanting to be 100% sure this is in the public domain before I upload. Thanks, Londonjackbooks (talk) 19:12, 27 August 2021 (UTC)
@Londonjackbooks: Published in the US over 95 years ago. Not many things in the copyright world are simple, but this is about as good as we get! I say: go for it!
I see the IA doesn't have a copy of the 1923 edition, but Hathi does. Let me know if you'd like that imported. Inductiveload​—​talk​/​contribs 19:21, 27 August 2021 (UTC)
@Inductiveload: Ah, I didn't check Hathi... I am rusty... But copyright seems to have been renewed in 1950 by Amos Wilder and "Reprinted with permission from the edition of 1923"... "First AMS edition published 1971" (as per IA 1971 copy, which I just borrowed to peek at). MY copy is the original 1923 edition. Does the renewal make the original not in the public domain? I do not know how this works. If you feel strongly that it is public domain, I would love for you to transport Hathi's copy here :) Thanks Londonjackbooks (talk) 19:29, 27 August 2021 (UTC)
@Londonjackbooks: Anything that was published before 1926 is in the public domain in the United States. Note that later editions of a work may still be in copyright, however. Renewals expire at latest 95 years after publication in the US, meaning that since it's 2021, anything published 1925 or before is public domain. PseudoSkull (talk) 20:08, 27 August 2021 (UTC)
@Londonjackbooks: Index:Battle-retrospect, and other poems - Wilder - 1923.djvu
(edit conflict) Anything published over 95 year ago (so, in 2021, before 1926, but not in 1926) is always fair game in the US (= at enWS). Which in this case is fortunate as Wilder died in 1993, so pma + 70 as 2063.
If this had been a non-US work, it would still be acceptable here, but the file couldn't be hosted at Commons until it was PD in the country of origin.
And there are cases of the reverse where a work PD in the country of origin is not PD in the US, due to URAA restoration. This extends the copyright term to 95 years after publication, so 1926 is still the magic number.
A later edition doesn't refresh the copyright on the original, but it can attract new copyright on new material. Note that from 1926–1963, even this new material had to be renewed (the renewal will detail what it covers). There is no way a 1971 edition could pull a 1923 edition out of the US public domain. Inductiveload​—​talk​/​contribs 20:23, 27 August 2021 (UTC)
Ah, thank you both for all of that... and for the upload! I have been waiting several years to transcribe this book :) Londonjackbooks (talk) 20:30, 27 August 2021 (UTC)
had it not been renewed, it would have been public domain in 1950; the renewal would have expired in 1978, had not Copyright Act of 1976 and Sunny Bono intervened; and it was public domain in 2019. [3] but depends on what you mean by "100% sure", there are no guarantees. --Slowking4Farmbrough's revenge 20:52, 27 August 2021 (UTC)
@​Londonjackbooks​:​https://catalog.hathitrust.org/Record/001194952 = https://lccn.loc.gov/23007703 - The registration is here (it's A703230, and Yale University Press was the copyright proprietor, with a date of 12 April 1923. It was renewal was R61872, on 4 May 1950. The US copyright expired on Public Domain Day 2019. (1 Jan 1924 + 95 years) Just to nail it down. :) Jarnsax (talk) 22:47, 27 August 2021 (UTC)
Excellent, Thank you :) Londonjackbooks (talk) 23:43, 27 August 2021 (UTC)
Horsepower glyph
Does anyone recognise the glyph for horsepower, in the upper image caption on Page:Incandescent electric lighting- A practical description of the Edison system.djvu/139?
It looks like half an upper-case "H" joined to an upper-case "P".
How can I type it? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:08, 27 August 2021 (UTC)
@Pigsonthewing: I think it's "㏋" (U+33CB). Inductiveload​—​talk​/​contribs 21:16, 27 August 2021 (UTC)
https://codepoints.net/U+33CB?lang=en agrees with you (that it's not just some other random symbol, but indeed horsepower) Jarnsax (talk) 22:04, 27 August 2021 (UTC)
@Pigsonthewing: &#x33CB; (what you see, not the markup) Jarnsax (talk) 22:07, 27 August 2021 (UTC)
Thanks, both. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:09, 28 August 2021 (UTC)
Community input needed: copyright of Philosophical Writings
At WS:CV#Philosophical Writings: Translators modern unpublished translation, or possible gifted translation there is an open copyright discussion for which broader community input is needed.
The work in question is a translation of an old text, and there are some incidental indications that the text was posted by the translator and that they may have intended to gift it to the web in some fashion. However, there was no explicit license tagging and there is no OTRS ticked for it, so it is impossible to know for sure that the translator 1) really intended a license that is compatible with Wikisource (e.g. without non-commercial and no derivative works limitations), and 2) actually understood the consequences of such a license. The suspected translator died in 2015 so it can now no longer be verified.
The discussion has been open since 2019 and there is no clear consensus either way among the participants (4 total).
In order to properly close this discussion we need more input from a broader swathe of the community. It requires no special familiarity with copyright or other arcana: just a willingness to read through the discussion and decide whether you, personally, are willing to accept what little evidence we do have as sufficient, or whether you would need more or stronger evidence (for example an OTRS confirmation).
There is no right or wrong answer (or clear policy) to this question; just your personal standard of evidence for unclear cases such as this.
Please post your comments in the linked thread (not here); and prefix your comment with either
{{vd}}
("vote delete") or
{{vk}}
("vote keep") if either of these is the ultimate outcome you think best. You can also comment without actually voting, as such, but a clear vote using the templates makes it easier for the closing admin.
PS. a similar issue obtains for the following discussion (WS:CV#Index:Civil Rights Movement EL Text.pdf) too. While the underlying issue is different, and possibly more complicated, it most importantly needs more input from the community. If you are inclined, reading through the discussion and posting your own conclusions would be very helpful! Xover (talk) 10:37, 28 August 2021 (UTC)
Bilingual and Side by side templates fail to produce anchors to page numbers
If a work is transcluded using the templates {{Bilingual}} or {{Side by side}}, the page numbers do not work as anchors, although I remember that some (long?) time ago they did. For example The Bartered Bride (1908)/Act first#8 does not go to page 8. It might be connected with the fact that some time ago the visual appearance of the page numbers of pages transluded using these templates changed for some reason and their background got sort of purple hue (which also does not look very nice). Is it possible to fix at least the anchoring? --Jan Kameníček (talk) 20:37, 28 August 2021 (UTC)
Not sure if this is helpful, but I transcribed Byron's Francesca of Rimini (I linked to a specific page number in the previous link to see if it worked), but did not use any of those templates. This was some time ago, so I don't recall the technical details about transclusion... Londonjackbooks (talk) 21:32, 28 August 2021 (UTC)
This solution looks interesting, although a disadvantage is that only every second page number is displayed. The two templates are good to display text side by side and provide all the page numbers at the same time. It used to work well, but something got wrong. --Jan Kameníček (talk) 23:51, 28 August 2021 (UTC)
@​Jan.Kamenicek​:​Yes, you are correct. Yet if you anchor to a page number that isn't visible, it will still take you to the correct target position on the page. ... I am curious... With the Bilingual and Side by Side templates, the page numbers render differently in the Main than normal... more vibrant and boldly colored than in typical transclusions. Graphicaly different, almost like an image, if that makes sense. I wonder, if that effect is removed, whether it would change anything...? I do not know how these things work technically... Londonjackbooks (talk) 00:42, 29 August 2021 (UTC)
@Londonjackbooks: Yes, you are right, the page numbers are rendered boldly colored, but I remember they used to render the same as it is usual. As for targetting the page numbers which are not visible in your system of columns: that is a good point. I will probably change the way of transcription in the works I am interested in as you have suggested if the problem is not solved, but generally it will not solve much, because there are many other works using the templates too. --Jan Kameníček (talk) 00:56, 29 August 2021 (UTC)
Hmm. At a quick peek (and before coffee, caveat emptor), has never produced page numbers, and , which just wraps for its core functionality, just calls for its page number display. Nowhere in these templates is there code that would give you a linkable page number, nor has there ever been so far as I can tell. And speaking from a purely technical perspective, this is one of several reasons why these templates (all three of them) should not be used.​Londonjackbooks' method avoids all or almost all their problems (again, from a technical perspective), and while it's slightly less user-friendly (ymmv) and uses a display table for the effect, these are, I think, fixable issues. It has the crucial virtue of actually using the ProofreadPage extension for its transclusions, so it gets all the features and properties that are designed for that. My recommendation for now would be to follow their example. Xover (talk) 07:40, 29 August 2021 (UTC)
Tech News: 2021-35
Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
Recent changes
Some musical score syntax no longer works and may needed to be updated, you can check Category:Pages with score rendering errors on your wiki for a list of pages with errors.
Problems
Musical scores were unable to render lyrics in some languages because of missing fonts. This has been fixed now. If your language would prefer a different font, please file a request in Phabricator. [4]
Changes later this week
  • The parameters for how you obtain tokens in the MediaWiki API were changed in 2014. The old way will no longer work from 1 September. Scripts, bots and tools that use the parameters from before the 2014 change need to be updated. You can read more about this.
  • The new version of MediaWiki will be on test wikis and MediaWiki.org from 31 August. It will be on non-Wikipedia wikis and some Wikipedias from 1 September. It will be on all wikis from 2 September (calendar).
Future changes
  • You will be able to read but not edit Commons for a few minutes on 6 September. This will happen around 05:00 UTC. This is for database maintenance.
  • All wikis will be read-only for a few minutes in the week of 13 September. More information will be published in Tech News later. It will also be posted on individual wikis in the coming weeks. [5]
Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.
16:01, 30 August 2021 (UTC)
Timeline of the public domain's future over the next handful of decades
I've created a timeline of approximately everything that will enter the public domain in the United States between 2019 and 2073. Take a look if it interests you or would be useful to you: User:PseudoSkull/Public domain
I know I left a few complicated bits out, but I didn't want to fill up my chart too heftily, so this gives a general overview of what the public domain will look like over the course of the Mickey Mouse Protection Act's lifetime. PseudoSkull (talk) 19:56, 30 August 2021 (UTC)
I'm not sure what the unpublished column is about. Isn't that just life+70?--Prosfilaes (talk) 20:00, 30 August 2021 (UTC)
Not if it's anonymous, pseudonymous, or a work made for hire. PseudoSkull (talk) 20:04, 30 August 2021 (UTC)
Redundant templates?
Do we need {{Filename}}, {{Image extracted}} and {{Image extracted/row}} for anything? --Jan Kameníček (talk) 10:24, 2 September 2021 (UTC)
Will anybody object if I delete them? --Jan Kameníček (talk) 13:24, 5 September 2021 (UTC)
Deleted. --Jan Kameníček (talk) 08:34, 8 September 2021 (UTC)
English, Scottish etc. vs British vs United Kingdom authors
It seems there is a big mess among the categories mentioned in the heading.
The category English authors includes a notice that it contains authors who lived when England was a nation for itself. I guess it means that only authors from the times of the Kingdom of England should come here. Besides the fact that the contributors are forced to search by themselves when exactly it was, it is also not very systematic, because parallel category Scottish authors does not contain any limitation to include only authors from the times of the Kingdom of Scotland, or Welsh authors only from the Principality of Wales. It is also the reason why some (many?) contributors add modern authors from England to this category.
The category British authors does not contain any notice who belongs there, but I guess it should be authors from the times of the Kingdom of Great Britain, otherwise it would not make much sense to keep it separate from the United Kingdom authors. Again, contributors seem to be confused by them and seem to distribute authors between them randomly or to both of them for sure.
We could try to save the system e.g. by changing names of the categories so that they showed better that they apply only to some historical periods. The names could be Kingdom of England authors, Kingdom of Scotland authors, Principality of Wales authors, Kingdom of Great Britain authors. However, this solution has many disadvantages. I am afraid that many contributors would be disapointed that modern Scottish authors would fall under United Kingdom authors, similarly as modern English authors do. It is even more complicated for Ireland. If we wanted to keep the system distinguishing members of historical independent countries from the times when the countries are/were parts of the UK, for Ireland we would have to found e.g. Irish authors (till 1801) and the Republic of Ireland authors. I am not sure if it is not too complicated.
An easier solution would be to abandon the attempts to keep authors of historical countries of the British Isles separate and to remove this notice from the category English authors. English, Scottish etc. authors would be simply authors from these countries regardless whether independent or part of the UK. The category United Kingdom authors would contain only authors who the contributors were not able to distinguish more precisely. British authors would be redirected to the United Kingdom authors.
Or, we can make a compromise: English authors would contain no limitations as for era and Kingdom of England authors would be its subcategory. The same for Scottish authors and others. British authors would be renamed for Kingdom of Great Britain authors and subcategorized to the United Kingdom authors.
I personally would prefer the last solution, but the previous ones are imo also better than the current confusing situation. --Jan Kameníček (talk) 14:29, 5 September 2021 (UTC)
Nested footnotes with nested poems
Pages 56 and 61 of The Philosophy of Beards have nested footnotes. To complicate matters the footnotes include <poem> markup, but are referenced from within other poems.
On the former, I have used a "user annotation" to note this. Is there a better solution? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:41, 5 September 2021 (UTC)
@​Pigsonthewing​:​Sir_Thomas_Browne's_works,_volume_3_(1835)/Hydriotaphia#cite_ref-102​. If something like that doesn't behave, try eliminating the pome tag. Cygnis insignis (talk) 13:15, 7 September 2021 (UTC)
Tech News: 2021-36
Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
Recent changes
The wikis that have Growth features deployed have been part of A/B testing since deployment, in which some newcomers did not receive the new features. Now, all of the newcomers on 21 of the smallest of those wikis will be receiving the features. [6]
Changes later this week
There is no new MediaWiki version this week.
Future changes
  • In 2017, the provided jQuery library was upgraded from version 1 to 3, with a compatibility layer. The migration will soon finish, to make the site load faster for everyone. If you maintain a gadget or user script, check if you have any JQMIGRATE errors and fix them, or they will break. [7][8]
  • Last year, the Portuguese Wikipedia community embarked on an experiment to make log-in compulsory for editing.  The impact report of this trial is ready. Moving forward, the Anti-Harassment Tools team is looking for projects that are willing to experiment with restricting IP editing on their wiki for a short-term experiment. Learn more.
Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.
15:20, 6 September 2021 (UTC)
Comment
Do we wish to volunteer to participate in the user trial for mandating login? Do we get sufficient value in IP editing IP edits from recent changes, and that includes 52 reverts (as time of typing). — billinghurst sDrewth 05:21, 7 September 2021 (UTC)
 Comment something that might not be that obvious as a benefit to requiring login as that IPs are not able to proofread a page in the Page namespace (which is why IPs seem to make so many red pages: that's all they can do). It's not made clear to IPs that there even is a proofreading mechanism from their point-of-view: phab:F34635385. Requiring login may therefore make editors making edits like Special:Diff/11670182 more able to proofread will all the tools. Inductiveload​—​talk​/​contribs 06:54, 7 September 2021 (UTC)
i see someone from Toronto, and Auckland being productive. are you sure you want to escalate? would not a bot be better? or an ip welcome message? otoh, it works for the pt admins, (well on the way to wikinews) --Slowking4Farmbrough's revenge 01:43, 8 September 2021 (UTC)
 Comment I've been reviewing Recent Changes here for a few weeks and I just don't see the cloud of tundra mosquitos as seen at en.wikipedia. It's so bad over there in despair I wrote:
Is there yet a general realization that Wikipedia is a proud shining obelisk inscribed with much knowledge in all the scripts of the world, but made of chalk and drenched in a corrosive continual acid rain?
At one time I argued that rather than anything or nothing, it should be changed to allow IPs to make _one_ edit a day, with the cheerful "want to contribute more - register!" This on the "first hit is free" theory - if their test of "you can edit" works, and they *really* want to contribute, they will register.
But as much as I hate IP edits in general I just don't see the need happening here. Perhaps vandals can't boast and point to Wikisource pages without someone saying "thought you didn't like books - how do you know about Wikisource?" Shenme (talk) 02:27, 10 September 2021 (UTC)
if you force people to register, then fewer will edit, and those that do will forget their password, and recreate a new account for every session. the barrier to entry of account creation and captcha are underrated. you may well abandon "anyone can edit" but there will be consequences. --Slowking4Farmbrough's revenge 22:04, 12 September 2021 (UTC)
 Comment I see no need to participate in this trial. There are some IPs who contribute usefully and conversely some logged in users who don't <shrug>. The only advantage that I can see is to prevent experienced wikisourcerors from editing while accidentally logged out. Beeswaxcandle (talk) 03:41, 13 September 2021 (UTC)
header, AuxTOC, and mbox
It was not my intention to hack {{Dotted TOC page listing}} but I did with {{Dotted TOC page listing|textbackground=inherit}} which, I really thought would grab the background color of {{AuxTOC}}. Which I was worried might change color depending on which skin is being used to view it in.
This failed, and I could see the reason that "transparent" is not allowed as a color and also, saw more about how it (the dotted) template works. So, the hack pulled in a transparent from AuxTOC and not the color.
After looking for the class being used for mbox (on media wiki) and AuxTOC (here), I read the AuxTOC docs; my priorities being a little backwards as I discovered. And, the AuxTOC uses the header "class", which is not so much a class as it is a "style setting" (which, I dearly hope I got wrong by not reading far enough down in the source), and it is safe to set the background color as this has been set locally.
So, my questions are:
  1. How come inherit failed?
  2. I am wrong about the header style (true or false) and (if true) the name of the class is?
  3. True or false, I don't have to worry about the color changing depending upon the skin choices of the viewer.
--RaboKarbakian (talk) 18:57, 6 September 2021 (UTC)
From memory the dotted template series have a hard coding of white so that the dots are visible when that layers appears from behind the textlayer. For use AuxTOC with the dotted series use
class​=​"subheadertemplate"
as that has the colour set within it. As the dotted template series is complex and never fully functional, I always say question whether its use is needed. — billinghurst sDrewth 00:58, 7 September 2021 (UTC)
i stay away from the dotted template, and use table code instead. more trouble than it is worth, even if it replicates typography of tables of contents. someone with serious css skills would be required to start over. --Slowking4Farmbrough's revenge 01:35, 8 September 2021 (UTC)
 Comment Ditto I second Slowking4. — Ineuw (talk) 02:02, 8 September 2021 (UTC)
The header class did not work either. The only thing the template will inherit is the one thing that breaks it.--RaboKarbakian (talk) 03:08, 8 September 2021 (UTC)
 Comment @RaboKarbakian: then I think that AuxTOC has the ability to force background-color => #E6F2E6 I do it so occasionally among lots of others edis so, I can forget what I do. — billinghurst sDrewth 10:33, 8 September 2021 (UTC)
The 2022 Community Wishlist Survey will happen in January
Hello everyone,
We hope all of you are as well and safe as possible during these trying times! We wanted to share some news about a change to the Community Wishlist Survey 2022. We would like to hear your opinions as well.
Summary:
We will be running the Community Wishlist Survey 2022 in January 2022. We need more time to work on the 2021 wishes. We also need time to prepare some changes to the Wishlist 2022. In the meantime, you can use a dedicated sandbox to leave early ideas for the 2022 wishes.
Proposing and wish-fulfillment will happen during the same year
In the past, the Community Tech team has run the Community Wishlist Survey for the following year in November of the prior year. For example, we ran the Wishlist for 2021 in November 2020. That worked well a few years ago. At that time, we used to start working on the Wishlist soon after the results of the voting were published.
However, in 2021, there was a delay between the voting and the time when we could start working on the new wishes. Until July 2021, we were working on wishes from the Wishlist for 2020.
We hope having the Wishlist 2022 in January 2022 will be more intuitive. This will also give us time to fulfill more wishes from the 2021 Wishlist.
Encouraging wider participation from historically excluded communities
We are thinking how to make the Wishlist easier to participate in. We want to support more translations, and encourage under-resourced communities to be more active. We would like to have some time to make these changes.
A new space to talk to us about priorities and wishes not granted yet
We will have gone 365 days without a Wishlist. We encourage you to approach us. We hope to hear from you in the talk page, but we also hope to see you at our bi-monthly Talk to Us meetings! These will be hosted at two different times friendly to time zones around the globe.
We will begin our first meeting September 15th at 23:00 UTC. More details about the agenda and format coming soon!
Brainstorm and draft proposals before the proposal phase
If you have early ideas for wishes, you can use the new Community Wishlist Survey sandbox. This way, you will not forget about these before January 2022. You will be able to come back and refine your ideas. Remember, edits in the sandbox don't count as wishes!
Feedback
  • What should we do to improve the Wishlist pages?
  • How would you like to use our new sandbox?
  • What, if any, risks do you foresee in our decision to change the date of the Wishlist 2022?
  • What will help more people participate in the Wishlist 2022?
Answer on the talk page (in any language you prefer) or at our Talk to Us meetings.
SGrabarczuk (WMF) (talk) 00:23, 7 September 2021 (UTC)
Wikisource:Upload-shared and our requirements for allocation
I have created this page that documents the recently created group that the community request. I have put some light placeholder text about its allocation, and welcome comments about how forceful we need to be with what are the provisions we wish to put in place. I would think that we would allow administrators to allocate to their bots if they can demonstrate and document their cases. When we created this we didn't see that we would generally provide this right to normal users, are people still feeling that is the situation and that anyone wishing to have that right assigned should put forward a request for rights to the whole or solely to an administrator.
Personally, I would prefer to see something to the community. — billinghurst sDrewth 01:28, 7 September 2021 (UTC)
I think it could just be self-assigned by administrators and requested for a non-admin's bot via WS:AN.
The scope for mis-use is limited, and mistakes or abuse can be trivially be rectified with Special:Nuke or Special:MassDelete and a list of that bot's contributions. There's no need for a lot of process, since a "do we trust you" process is already done as part of the admin nomination and bot flag grant. Inductiveload​—​talk​/​contribs 06:08, 7 September 2021 (UTC)
Copyright status of the original Garfield comics
I wanted to let you guys know that I started a discussion at Commons:Village pump/Copyright about the copyright status of the original Garfield cartoons (then called Jon), which were syndicated in the Pendleton Times from 1976 to 1977. It turns out they may very well be in the public domain, and if they are, it is of interest to Wikisource because we could host transcriptions of them. PseudoSkull (talk) 17:07, 7 September 2021 (UTC)
Just asking some questions about the {{FI}} template css
When replying, a yes or no will do.
  1. The {{​FreedImg/styles.css​}} specifies two font-sizes for a caption, 94% and 83%, can both be set to 83% or 85%, please?
  2. Can the caption line appear on top of the image as well? I am asking because I have ~500 images with captions on top of the image and it would eliminate the use of additional templates. — Ineuw (talk) 19:02, 7 September 2021 (UTC)
@Ineuw: #1: No, because that will change the size of every caption using this template. Which I opine should never have set a default size but now we're 10930 usages deep in the mud, so that's a bit of a problem to change. The 83% is only for the "image missing" notice.
What you can do is set
.wst-freedimg-caption { font-size: 83%; }
in the styles.css subpage of the index for a work-specific override. Then you will not need to set it on every template.
#2: Yes: you can use the (new) top_caption parameter. Inductiveload​—​talk​/​contribs 08:36, 8 September 2021 (UTC)
@Inductiveload: Much thanks for the explanation. — Ineuw (talk) 09:25, 9 September 2021 (UTC)
@Ineuw: FYI, the CSS should go in the /styles.css subpage of the Index page, so it will also be applied in the mainspace on transclusion. More details at H:Page styles. Inductiveload​—​talk​/​contribs 06:36, 10 September 2021 (UTC)
Thanks again. Understood.— Ineuw (talk) 05:16, 11 September 2021 (UTC)
Results for the 2021 Wikimedia Foundation Board of Trustees election
Read in other languages
Thank you to everyone who participated in the 2021 Board election. The Elections Committee has reviewed the votes of the 2021 Wikimedia Foundation Board of Trustees election, organized to select four new trustees. A record 6,873 people from across 214 projects cast their valid votes. The following four candidates received the most support:
  1. Rosie Stephenson-Goodknight
  2. Victoria Doronina
  3. Dariusz Jemielniak
  4. Lorenzo Losa
While these candidates have been ranked through the community vote, they are not yet appointed to the Board of Trustees. They still need to pass a successful background check and meet the qualifications outlined in the Bylaws. The Board has set a tentative date to appoint new trustees at the end of this month.
Read the full announcement here. Xeno (WMF) (talk) 01:56, 9 September 2021 (UTC)
Call for Candidates for the Movement Charter Drafting Committee ending 14 September 2021
Movement Strategy announces the Call for Candidates for the Movement Charter Drafting Committee. The Call opens August 2, 2021 and closes September 14, 2021.
The Committee is expected to represent diversity in the Movement. Diversity includes gender, language, geography, and experience. This comprises participation in projects, affiliates, and the Wikimedia Foundation.
English fluency is not required to become a member. If needed, translation and interpretation support is provided. Members will receive an allowance to offset participation costs. It is US$100 every two months.
We are looking for people who have some of the following skills:
  • Know how to write collaboratively. (demonstrated experience is a plus)
  • Are ready to find compromises.
  • Focus on inclusion and diversity.
  • Have knowledge of community consultations.
  • Have intercultural communication experience.
  • Have governance or organization experience in non-profits or communities.
  • Have experience negotiating with different parties.
The Committee is expected to start with 15 people. If there are 20 or more candidates, a mixed election and selection process will happen. If there are 19 or fewer candidates, then the process of selection without election takes place.
Will you help move Wikimedia forward in this important role? Submit your candidacy here. Please contact strategy2030
wikimedia.org with questions.
This message may have been sent previously - please note that the deadline for candidate submissions was extended and candidacies are still being accepted until 14 September 2021. Xeno (WMF) 17:16, 10 September 2021 (UTC)
Copyright-relevant properties for Wikidata - comments sought
I have opened two property proposals at Wikidata for recording of copyright data that is currently not covered by their data models.
In theory, these properties would allow automation of quite some boilerplate here at Wikisource. For example a template of the format
{{PD/US|1941}}
could be generated for Mrs. Dalloway.
I invite anyone with an interest in Wikidata modelling of Wikisource-adjacent data to comment on those proposals (and/or suggest alternatives, improvements, existing ways to models the information, etc). Inductiveload​—​talk​/​contribs 21:58, 10 September 2021 (UTC)
Server switch
Read this message in another languagePlease help translate to your language
The Wikimedia Foundation tests the switch between its first and secondary data centers. This will make sure that Wikipedia and the other Wikimedia wikis can stay online even after a disaster. To make sure everything is working, the Wikimedia Technology department needs to do a planned test. This test will show if they can reliably switch from one data centre to the other. It requires many teams to prepare for the test and to be available to fix any unexpected problems.
They will switch all traffic back to the primary data center on Tuesday, 14 September 2021.
Unfortunately, because of some limitations in MediaWiki, all editing must stop while the switch is made. We apologize for this disruption, and we are working to minimize it in the future.
You will be able to read, but not edit, all wikis for a short period of time.
  • You will not be able to edit for up to an hour on Tuesday, 14 September 2021. The test will start at 14:00 UTC (07:00 PDT, 10:00 EDT, 15:00 WEST/BST, 16:00 CEST, 19:30 IST, 23:00 JST, and in New Zealand at 02:00 NZST on Wednesday, 15 September).
  • If you try to edit or save during these times, you will see an error message. We hope that no edits will be lost during these minutes, but we can't guarantee it. If you see the error message, then please wait until everything is back to normal. Then you should be able to save your edit. But, we recommend that you make a copy of your changes first, just in case.
Other effects:
  • Background jobs will be slower and some may be dropped. Red links might not be updated as quickly as normal. If you create an article that is already linked somewhere else, the link will stay red longer than usual. Some long-running scripts will have to be stopped.
  • We expect the code deployments to happen as any other week. However, some case-by-case code freezes could punctually happen if the operation require them afterwards.
This project may be postponed if necessary. You can read the schedule at wikitech.wikimedia.org​. Any changes will be announced in the schedule. There will be more notifications about this. A banner will be displayed on all wikis 30 minutes before this operation happens. Please share this information with your community.
SGrabarczuk (WMF) (talk) 00:46, 11 September 2021 (UTC)
Talk to the Community Tech
Read this message in another languagePlease help translate to your language
Hello!
As we have recently announced, we, the team working on the Community Wishlist Survey, would like to invite you to an online meeting with us. It will take place on September 15th, 23:00 UTC on Zoom, and will last an hour. Click here to join.
Agenda
Format
The meeting will not be recorded or streamed. Notes without attribution will be taken and published on Meta-Wiki. The presentation (first three points in the agenda) will be given in English.
We can answer questions asked in English, French, Polish, and Spanish. If you would like to ask questions in advance, add them on the Community Wishlist Survey talk page or send to sgrabarczuk@wikimedia.org.
Natalia Rodriguez (the Community Tech manager) will be hosting this meeting.
Invitation link
See you! SGrabarczuk (WMF) (talk) 03:04, 11 September 2021 (UTC)
Sacred-Texts.com (an online library of religious texts)
While I frequent Wikisource as a reader I don't edit here, so I am quite curious if there are any efforts to reach out to entire websites to import them. While researching religion in South Vietnam I recently found a website called Sacred-Texts.com, they seem to know a lot about US copyright and try to make sure that as much as possible on their website is in the public domain. This website seems like "a perfect match" for the English-language Wikisource, is it already being used as a source? Is it useful or do the actual texts need to be available and not just online transcriptions? -- DonTrung (徵國單)  (討論 🤙🏻) (方孔錢 ☯) 12:50, 12 September 2021 (UTC)
 DonTrung (徵國單) : Generally speaking, importation of text from other sites (such as Project Gutenberg and Sacred Texts) is heavily discouraged now-a-days, especially if there exist scans of the works in question. To answer your question, it is used as a source in some places, although I can’t point to any at the moment. If you would like to edit, I could try to point to a scan of a work on Sacred Texts; although from experience I can say that works from there are rarer. TE(æ)A,ea. (talk) 14:40, 12 September 2021 (UTC)
@Donald Trung: yes, please try to find a scan before working on these projects. I have no objection to usage of the websites as a replacement for preliminary OCR, but they should be proofread in the Index and Page namespaces. PseudoSkull (talk) 16:12, 12 September 2021 (UTC)
I once tried to use it as a source for something in the Sacred Books of the East, but there were enough discrepancies and formatting issues (generally sacred-texts.com doesn't preserve all the formatting) to make it not especially practical (but also not impractical). Perhaps with a more "intelligent" conversion script you could do better, but at least for works with good page scans, I judged it about that same amount of effort to just do it from decent OCR. If the only source was poor quality images and didn't OCR, it would probably be better. Inductiveload​—​talk​/​contribs 16:48, 12 September 2021 (UTC)
Problem with poem extension in mobile view
Wikilover407 has pointed out a weird problem with the poem extension. If a poem spans across page breaks, then a gap appears at the place of a page break in the mobile view, no matter if there is an end of a stanza or if it is in the middle of the stanza. However, it looks OK in the desktop view. See e. g. One Hundred Poems of Kabir/IV, (screenshot of the mobile view). I have checked it with other poems too and encountered the same problem there. --Jan Kameníček (talk) 06:26, 13 September 2021 (UTC)
Known problem, which is why most of us have stopped using the poem tags for poetry, and instead use block templates with explicit linebreaks <br />. Beeswaxcandle (talk) 07:04, 13 September 2021 (UTC)
I've done very little with poems so maybe this is a dumb question but: Shouldn't the </poem> tag on the first page have been put in the footer, and then the opening <poem> tag on the second page been put in the header? That way the transcluded form doesn't include either of them? — Dcsohl (talk)
(contribs) 12:46, 13 September 2021 (UTC)
@Dcsohl: It's a good question, but this doesn't work for <poem>, because it's not a template that inserts markup, it's a parser tag that begins a new processing "mode" within the server software. This must all happen on a single page, so you can't "distribute" the tags between multiple pages. Also you cannot interleave the tags like <noinclude><poem></noinclude>...</poem>​.
{{ppoem}} is an experimental attempt to do better than <poem> (and the <br/> hack), both of which produce pretty awful markup. It's getting close to a point at which I think it think it's suitable for general use, at least in simpler cases. Inductiveload​—​talk​/​contribs 12:59, 13 September 2021 (UTC)
Poor Robin's True Character of a Schold
@Inductiveload: This is labeled as being 1678, but it's clearly not. Look at real books from 1678. To be concrete, it doesn't use the long-s, and it uses very weird fonts for that time, and it doesn't use italics properly for the era. After glancing through those books, I found one that actually shows the original: [9]. It doesn't look complete, though. At the very least, we should mark it and the files it uses as being from a Victorian (?) era reprint, and it's clearly been normalized to the traditions of a more modern era with modern illustrations; our copy starts "A RANK SCOLD is a Devil of the feminine gender; a serpent, perpetually hissing, and spitting of venom;" compared to "A Rank SCOLD is a Devil of the Feminine gender; a Serpent, perpetually hissing, and spitting of Venom;" in the original.--Prosfilaes (talk) 07:18, 13 September 2021 (UTC)
@Prosfilaes: hmm, true enough. I'm not sure how to mark it up without a more concrete bibliographic record though. A note in the header field? Inductiveload​—​talk​/​contribs 07:37, 13 September 2021 (UTC)
@Inductiveload: I've found the book our version comes from, "The Old Book Collector's Miscellany" (1872) (later published as "A Collection of Readable Reprints of Literary Rarities" in 1876), edited by Charles Hindley.
-- ei (talk) 18:06, 22 September 2021 (UTC)
Tech News: 2021-37
Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
Recent changes
Problems
All wikis will be read-only for a few minutes on 14 September. This is planned at 14:00 UTC. [11]
Changes later this week
  • The new version of MediaWiki will be on test wikis and MediaWiki.org from 14 September. It will be on non-Wikipedia wikis and some Wikipedias from 15 September. It will be on all wikis from 16 September (calendar).
  • Starting this week, Wikipedia in Italian will receive weekly software updates on Wednesdays. It used to receive the updates on Thursdays. Due to this change, bugs will be noticed and fixed sooner. [12]
  • You can add language links in the sidebar in the new Vector skin again. You do this by connecting the page to a Wikidata item. The new Vector skin has moved the language links but the new language selector cannot add language links yet. [13]
  • The syntax highlight tool marks up code with different colours. It now can highlight 23 new code languages. Additionally, golang can now be used as an alias for the Go programming language, and a special output mode has been added to show a program's output. [14][15]
Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.
15:35, 13 September 2021 (UTC)
Early modern and Modern author?
Hi. How is it that Author:Robert Henry Thouless can be both a Early modern and Modern author at the same time? Mpaa (talk) 22:24, 14 September 2021 (UTC)
Why not? If you have defined time periods for "early modern" and "modern", then somebody is going to cross that time period. In this case, it's automatic categorization based on the fact he was alive before 1900 and after 1900. A bit crude, but it's unerring; as long as Wikidata has birth and death years correctly, it will put them in those categories based on those years, something you can't say if you want to base it on publication dates, and even then, you'll still have "early modern" and "modern" on the same author unless we're getting completely subjective.--Prosfilaes (talk) 23:01, 14 September 2021 (UTC)
I was expecting more an either/or way, but it makes sense. Then the wording in Category:Authors by era needs rephrasing: "This category and its subcategories groups authors according to the era they were born in (see the table below). Where their lives occur in two eras, the one they wrote most of their works in is used."
Thanks for the explanation.Mpaa (talk) 18:07, 15 September 2021 (UTC)
FYI: Preloading derived header templates for serials and compilation works
A reminder that where you are working on a serial or a larger compiled work, that we are comfortable in setting up a derived header template for the work. Apart from just making life easier, it is in fact broadly quite useful to do so when working with some tools, for example Petscan, and for bulk loading data into Wikidata. If you need assistance in creating a derived header, then feel welcome to give me a ping. There are examples linked from the base template.
Further, with the mediawiki setup there is the means to have a preload functionality to have the template load into the subpages of the work so one can just complete the data. This bit does need to be undertaken by administrators due to it relationship to the Mediawiki namespace.
Happy to answer any questions here, or ping me from the talk page of the template of interest. — billinghurst sDrewth 00:23, 15 September 2021 (UTC)
What is the best way to deal with a text that is serialized in a periodical? It seems that the header should contain two previous/next entries. The first being the previous/next of the stories in that issue. The second being the previous/next part of the text. For example, for "A Scandal in Bohemia", the next story in The Strand is "The Bundle of Letters", but the next story in the Adventures of Sherlock Holmes is "The Red-Headed League" How should this be managed? Languageseeker (talk) 01:27, 15 September 2021 (UTC)
Languageseeker: See {{series}}, used e.g.here. TE(æ)A,ea. (talk) 01:33, 15 September 2021 (UTC)
The next story in The Adventures of Sherlock Holmes is a bad example. The Adventures of Sherlock Holmes is a collection, not a work serialized in a magazine, and there's no need to link the stories published in the Strand in the order of that collection.--Prosfilaes (talk) 02:19, 15 September 2021 (UTC)
@TE(æ)A,ea.: Thank you!
@Prosfilaes: Hmm, I'm not too sure about that. The Strand magazine had them listed as part of a work with a distinct order Page:The Strand Magazine (Volume 2).djvu/663. It seems to me as if they were meant to be a whole. Languageseeker (talk) 04:35, 15 September 2021 (UTC)
Okay, I guess they did.--Prosfilaes (talk) 04:40, 15 September 2021 (UTC)
Entering a new work
I have an autobiography for a Frank Tweedy hand typed by him in 1924 that I have transcribed in a Word file to upload to Wikisource for use as a source in a Wikipedia biography on Tweedy I have co-authored. I cannot for the life of me figure out how to do this. I have spent hours trying to go through Help and I have gotten no further toward uploading this autobiography. Am I missing something? Noel Andrew Sherry (talk) 00:50, 15 September 2021 (UTC)
@Noel Andrew Sherry: Ah, very interesting that you have that. The Wikipedia article Sherry is referring to for context, for anyone else reading: Frank Tweedy. A few minutes of poking around and I could not find an original scan, but I did find what appears to be your transcription of the work at File:Life of Frank Tweedy.pdf. Very nice work.
A few things to note:
  • I think 1924 above is a typo because your transcription says he wrote the autobiography in 1926, so different rules apply than normal. I believe that this work is unpublished, but I could be wrong (you probably know more about this Mr. Tweedy than I do). Normally that would not be acceptable here, but since Tweedy died over 70 years ago (in 1937), and according to your transcription it was signed by him, the work is actually in the public domain, meaning it is free of copyright restrictions in the United States. And if it was published, there was no copyright notice, so even if that's the case it would be in the public domain as well. Worst case, if it was published and there was a copyright notice that you did not place in the transcription, then I see no evidence of renewal. So, while it was quite generous for you to get permission from someone of Tweedy's estate and while it was quite generous that that person allowed you to transcribe it under a CC license, their permission or accreditation is not explicitly legally required for reuse, so a CC license was not necessary. So, the license tag should be either Template:PD-US-unpublished or Template:PD-US-no-notice​. Your own current PDF file containing the transcription may (possibly) be eligible for copyright under a CC license depending on the level of originality you provided in your PDF. (Not to say you shouldn't credit them, but the PD license is meant to show the precise legal situation of the work.)
  • So, since the work is out of copyright according to evidence available to me, something we recommend is that you scan the original autobiography (if a scan does not exist online; I haven't found one after some digging), and upload an original scan of the autobiography to Wikimedia Commons (see Help:Digitising texts and images for Wikisource for recommended methods). Then we recommend that you proofread the work based on the scan provided (see Help:Proofread to learn about the process). A summary is that you first create an index page, and proofread the pages within them page by page. Then when work is done, you transclude the transcription. I understand proofreading here is a little bit of a process and may take some getting used to, but feel free to ask any questions you want about it as well. The reason we recommend the scan backing is to prove that what is transcribed here appeared in the original on the precise pages they are found.
  • If it is not possible for you to retrieve the document from the grand niece again and therefore scanning is impossible, entering the work as-is on a page like Autobiography of Frank Tweedy may be acceptable. However, I do not recommend this unless there is no other solution.
Thanks for offering this rare content. Hope you enjoy your time here! PseudoSkull (talk) 12:38, 15 September 2021 (UTC)
Hello PseudoSkull, Wow this is thorough, helpful, thankyou. I am new to Wikisource and Wikimedia, but have written 4 articles now for Wikipedia, one co-authored on Frank Tweedy, then three botanical articles on species Frank Tweedy collected as an amateur but accomplished botanist. Will process this in a few days. Thanks for the help as I get started here. Noel Andrew Sherry (talk) 13:11, 15 September 2021 (UTC)
@Noel Andrew Sherry PseudoSkull has given a very good précis of how to get started here. Assuming the copyright situation is fine:
Generally, we prefer scan-backed works (i.e. with a scan of the original work). If you can, the first thing to do is upload a PDF of the scanned original document. If you need help assembling a set of images into a document, let me know (type {{ping|inductiveload}} in any comment to alert me, or drop a note on User talk:Inductiveload and we'll sort something out.
Then, say you uploaded the scanned file to File:Life of Frank Tweedy (original).pdf, you would create Index:Life of Frank Tweedy (original).pdf and that will allow you to enter the transcription next to each page. Again, I can help you set this up. Finally, once the text is entered, you would Transclude the proofread pages to Autobiography of Frank Tweedy.
Welcome to Wikisource, and I truly hope you stick around even once this project of yours is complete! Inductiveload​—​talk​/​contribs 13:22, 15 September 2021 (UTC)
@Noel Andrew Sherry: By the way, another page you may find useful, since you are used to editing Wikipedia, is Wikisource:For Wikipedians. Good luck! PseudoSkull (talk) 13:35, 15 September 2021 (UTC)
I was wondering if Word could export to pdf yet.--RaboKarbakian (talk) 14:31, 15 September 2021 (UTC)
ProofreadPage Lua library will be available from today
After the deployment of Mediawiki 1.37-wmf.23later today, a Lua library will be included in the Proofread Page extension used by Wikisource. The primary use of this library is to allow templates and modules to access proofreading statistics of indexes and individual pages.
There is an API reference here: mw:Extension:Proofread Page/Lua reference, and you can also see an example of a template here at enWS that uses the API at {{index progress bar}} (it provides a "live" progress bar of a given index). Note that this page will show a Lua error until the deployment actually happens later on.
I'd like to thank @User:Tpt and @DannyS712 for their huge patience and help in getting this from a very mediocre implementation to one far better and more powerful than I originally dreamed possible.
As always, let me know if I can be of assistance if you'd like help using this library! Inductiveload​—​talk​/​contribs 14:59, 15 September 2021 (UTC)
Oh wow, this is an amazing development. Really looking forwards to seeing it in action. A huge thanks to everyone who worked on this and made it possible. Languageseeker (talk) 15:11, 15 September 2021 (UTC)
Update: This has just been deployed (a little late because the release train was blocked on something unrelated):
{{index progress bar|Index:Galileo Galilei and the Roman Curia (IA cu31924012301754).pdf}}
Inductiveload​—​talk​/​contribs 13:36, 16 September 2021 (UTC)
Great job! Mpaa (talk) 17:27, 16 September 2021 (UTC)
Center block
On Template:Center block the description This template centers a block of text, much like {{block center}}. is unhelpful. Much like in what way? What is different? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:46, 15 September 2021 (UTC)
@Pigsonthewing: 'block center' preceded 'center block' in principle, the latter was thought a better name (agreeable, I think) and the former was redirected to the it. Then it became a fork, the text was changed to what you quoted after that; I haven't dared to look whether previous usage of either template was honoured. Not helpful, as an answer or, perhaps, a new template, but so it goes. Cygnis insignis (talk) 16:55, 17 September 2021 (UTC)
Camera Work
Hi, Just in case someone here might be interested, I am uploading to Commons all the 49 volumes of Camera Work, the quarterly photographic journal of Alfred Stieglitz. These are high quality scans. I am mostly interested by the images, but maybe someone would like to transcribe the text here. Regards, Yann (talk) 22:33, 17 September 2021 (UTC)
That's a really pretty work. If I had more wall space, I'd be down to the print shop this lunchtime! Inductiveload​—​talk​/​contribs 11:01, 20 September 2021 (UTC)
@Yann: Please continue to upload the volumes and I will make a page for them. Languageseeker (talk) 11:18, 20 September 2021 (UTC)
It will take some days to have the complete collection. Already 24 (+ 1 supplement) uploaded. Regards, Yann (talk) 12:56, 21 September 2021 (UTC)
@Yann: I've started work on transcribing the first issue. Also of note are the high quality scans of Camera Notes (1900–1) from the Camera Club of New York available from Rijksmuseum Amsterdam. - ei (talk) 11:31, 23 September 2021 (UTC)
Tech News: 2021-38
Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
Recent changes
  • Growth features are now deployed to almost all Wikipedias. For the majority of small Wikipedias, the features are only available for experienced users, to test the features and configure them. Features will be available for newcomers starting on 20 September 2021.
  • MediaWiki had a feature that would highlight local links to short articles in a different style. Each user could pick the size at which "stubs" would be highlighted. This feature was very bad for performance, and following a consultation, has been removed. [16]
  • A technical change was made to the MonoBook skin to allow for easier maintenance and upkeep. This has resulted in some minor changes to HTML that make MonoBook's HTML consistent with other skins. Efforts have been made to minimize the impact on editors, but please ping Jon (WMF) on wiki or in phabricator if any problems are reported.
Problems
There was a problem with search last week. Many search requests did not work for 2 hours because of an accidental restart of the search servers. [17]
Changes later this week
  • The new version of MediaWiki will be on test wikis and MediaWiki.org from 21 September. It will be on non-Wikipedia wikis and some Wikipedias from 22 September. It will be on all wikis from 23 September (calendar).
  • The meta=proofreadpage API has changed. The piprop parameter has been renamed to prpiprop. API users should update their code to avoid unrecognized parameter warnings. Pywikibot users should upgrade to 6.6.0. [18]
Future changes
  • The Reply tool will be deployed to the remaining wikis in the coming weeks. It is currently part of "Discussion tools" in Beta features at most wikis. You will be able to turn it off in Editing Preferences. [19]
  • The previously announced change to how you obtain tokens from the API has been delayed to September 21 because of an incompatibility with Pywikibot. Bot operators using Pywikibot can follow T291202 for progress on a fix, and should plan to upgrade to 6.6.1 when it is released.
Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.
18:32, 20 September 2021 (UTC)
Spam account "created automatically" and so I don't see it in "Recent changes"?
So I spot a bit of spamming and revert. Then look for more. Then realize that even though the account was recent I can't see it in the "Recent changes" logs.
Sandeepkushwaha65 account was created 05:35, 21 September 2021, almost immediately following by the edit summary spam at 05:37. I reverted at 06:27. I could see the spamming, but I couldn't see the account creation just two minutes before?
I compared with another new account and noticed a difference
05:30, 21 September 2021 User account Altonsnike talk contribs was created
vs.
05:35, 21 September 2021 User account Sandeepkushwaha65 talk contribs was created automatically
What is "created automatically"? How is that done? Is this a hole, where we can't know a spamming account has been created? Shenme (talk) 06:51, 21 September 2021 (UTC)
The account was automatically created at enWS on login, because the account is SUL'ed from bh.wikipedia. See Special:CentralAuth/Sandeepkushwaha65​. I'm not sure such account creations are visible in the RC view, but you can see them at Special:Log. Inductiveload​—​talk​/​contribs 07:39, 21 September 2021 (UTC)
Links to LCCN subjects in the Authority Control
I have noticed that the link to the Hussite Wars subject, as provided in the Authority Control box at the bottom of Portal:Hussite Wars, does not work. The link is taken from Wikidata. Surprisingly, if the link is clicked directly in Wikidata, it works well. For some reason the link from WD goes to https://id.loc.gov/authorities/subjects/sh85015311.html​, while the link from our portal, although taken from WD, goes to https://id.loc.gov/authorities/names/sh85015311.html . How can it be fixed? --Jan Kameníček (talk) 09:33, 21 September 2021 (UTC)
@Jan.Kamenicek: It looks like https://id.loc.gov will transparently redirect to the correct subpath for either /name or /subjects, so Special:Diff/11705158 should do the trick. Inductiveload​—​talk​/​contribs 10:11, 21 September 2021 (UTC)
Great! Thanks. --Jan Kameníček (talk) 10:57, 21 September 2021 (UTC)
Movement Charter Drafting Committee - Community Elections to take place October 11 - 24
Dear fellow Wikimedians,
This is an update from the Movement Charter process. We have closed the call for candidates on September 14 for the Drafting Committee and now have a pool of candidates with diverse backgrounds to choose from. As the number of candidates is quite large and thus informing yourself about them might be a bit more complicated, we want to try something different this time: an “Election Compass", more about it in this page.
The 15 member committee will be selected with a 3-step process:
  • Election process for project communities to elect 7 members of the committee.
  • Selection process for affiliates to select 6 members of the committee.
  • Wikimedia Foundation process to appoint 2 members of the committee.
Communities elect 7 members
This announcement is related to the community elections, which will take place in a time period of 2 weeks from October 11 to October 24. We look forward to a wide participation across the communities to create the committee to curate the writing of the Movement Charter. The Election Results will be published on November 1.
Affiliates select 6 members
Parallel to the election process, all affiliates asked to contribute as well: All affiliates were divided into eight geographic and one ‘thematic’ region (check the list), and each region chooses one person who will act as a selector for that region. These 9 selectors will come together to select 6 of the committee (from the same pool of candidates). The selection results will be published on November 1.
Wikimedia Foundation appoints 2 members
Finally, the Wikimedia Foundation will appoint two members to the committee by November 1.
All three processes will be concluded by November 1, 2021, so that the Movement Charter Drafting Committee can start working by then.
For the full context of the Movement Charter, its role, as well the process for its creation, please have a look at Meta. You can also contact us at any time on Telegram or via email (wikimedia2030@wikimedia.org).
Best regards, --Civvi (WMF) (talk) 10:27, 23 September 2021 (UTC)
Drop initial + long second line in poetry formatting
Hi all, I'm proofreading some poetry and came across a strange issue on this page -- Page:The Atlantic Monthly, Volume 19.djvu/27. I'll reproduce it here:
L
orem ipsum dolor sit amet,
consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.
Ut enim ad minim veniam,
quis nostrud exercitation
Basically, when inside a Template:Center block block with automatic width, usage of Template:Dropinitial along with "<br />" at the end of the somewhat long second line on the page is causing that line to break early, causing a line wrap one word before it should be, and that new "third" line ending immediately after that word. This happens using both "center block" and "block center."
I seem to have identified what is going on. This seems to be happening because "block center" calculates the maximum width of a line within the block before shifting this second line, which then causes that line to overflow when it is later rendered. The only way I have found that gets around this apparent error is to manually set the width of the center block to something that will be large enough to fit the entire second line, though this is perhaps not ideal. Any thoughts? Or is this just one of those cases where the best thing is to do the hacky thing? -- Mathmitch7 (talk) 20:12, 23 September 2021 (UTC)
@Mathmitch7: as far as I am aware (and I would dearly love to be corrected) this is an artifact of the CSS box model and how the widths are laid out. I tried for a very long time to avoid it with {{ppoem}} and failed. Setting a manual width is all that I could figure out. Sorry! Inductiveload​—​talk​/​contribs 09:42, 24 September 2021 (UTC)
I generally deal with this by adding an appropriately-long {{gap}} at the end of the first line.
L
orem ipsum dolor sit amet,
consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.
Ut enim ad minim veniam,
quis nostrud exercitation
Unfortunately it causes its own issues when the page is narrow and the first line wraps anyway, but it's the best I've found (and I prefer it to manual widths) —Beleg Tâl (talk) 13:08, 24 September 2021 (UTC)
{{Ditto}} is another possible hack:
L
orem ipsum dolor sit amet,

consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.
Ut enim ad minim veniam,
quis nostrud exercitation
The advantage is that you just copy the longest line into the template and do not have to figure our how long the gap should be. But it’s still just a hack, it would be better if some systematic solution could be found. --Jan Kameníček (talk) 13:27, 24 September 2021 (UTC)
FYI, both those approaches will almost certainly cause export issues: e.g. phab:F34652540 (in Koreader). Setting a manual width on {{center block}} will be OK because there's a (very deliberate) CSS rule of max-width:100% there.
Also, the gap method doesn't work for me, because in the font my browser is using (DejaVu Sans), 32em is too short.
As a general rule-of-thumb, any use of {{gap}} to "fake" alignment will probably not export correctly, because it guarantees something will go wrong as soon as there is a line break. Inductiveload​—​talk​/​contribs 14:14, 24 September 2021 (UTC)
Why is the extant means unmentionable?
UST so you haz to ask Us how we subverted it! "proofreading is easy, we just try to make it difficult" (to keep people you would avoid busy)
unsigned comment by Cygnis insignis (talk) 15:50:22.
@Cygnis insignis: I am not quite sure what that is supposed to achieve, because without the left-hand cell, a 100%-width table is just the same as no table at all, and if you wanted to hardcode a left margin to "fake" text near the middle on a certain width of screen (which is, I hope self-evidently, a dreadful idea in terms of responsive design), you would not use a dummy table cell full of junk to do so. You would apply a margin-left.
If if you use a flexible-width table, it's the same. Indeed, {{center block}} usually uses display:table;, so there's literally no difference when it comes to layout in the CSS engine:
This is a table
L
orem ipsum dolor sit amet,
consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.
Ut enim ad minim veniam,
quis nostrud exercitation
Also do bear in mind that the width attribute is deprecated by the web standards bodies, so rather than width=100%, the correct markup is style="width:100%;". Inductiveload​—​talk​/​contribs 16:29, 24 September 2021 (UTC)
"I am not quite sure what that is supposed to achieve …" sorry cousin, stopped reading after that, but I'm not saying it is not pertinent [as it were]. Cygnis insignis (talk) 16:38, 24 September 2021 (UTC)
Last edited on 25 September 2021, at 03:07
Wikisource
Content is available under CC BY-SA 3.0 unless otherwise noted.
Privacy policy
Terms of Use
Desktop
 Home Random Log in  Settings  Donate  About Wikisource  Disclaimers
LanguageWatchEdit