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. 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 435 active users here.


Over 3000 pages processed in the first-ever Monthly ChallengeEdit

The May Monthly Challenge is now complete and the numbers are in: 3122 pages were processed (marked no text, proofread or validated), which is more than 50% over the tentative goal of 2000 and represents an average velocity of over 100 pages/day. The following works were fully proofread:

And the following validated:

As well as quite some progress on other volumes in the challenge. New works in June include:

Thank you to everyone taking part, and here's to 4000 pages in June (for you northern hemisphere people tempted by nice weather: ignore that horrid glowing yellow sphere in the sky. It'll give you cancer, stay in and read books on the Internet!). Inductiveloadtalk/contribs 15:53, 1 June 2021 (UTC)

This is a fantastic initiative, thanks to those who organised. Given WS can be overwhelming and difficult to find your way around at first, I think this has great potential to make contributing easier and more rewarding. Nickw25 (talk) 10:18, 5 June 2021 (UTC)

#wikisource IRC channel moved to Libera.chatEdit

  • The #wikisource IRC channel recently moved from Freenode to Libera.Chat.
  • Register an account on Libera.Chat and join us there!
  • More information at m:IRC/Migrating to Libera Chat
  • Links around the place were changed recently.

billinghurst sDrewth 01:53, 13 June 2021 (UTC)

@Billinghurst: or whoever. Is this channel logged and moderated? CYGNIS INSIGNIS 17:01, 14 June 2021 (UTC)
@Cygnis insignis: We haven't logged the channel at this stage. Moderated? No, as a WMF-grouped channel it can be as required. It has m:wm-bot sitting in it, and is simply a channel. Last couple of days it has been Inductiveload educating me in css conversions of my works as I simplify the direct code in my previous ToC and put that into Index:(workname).css, and get them better "ready for export". [Must admit it makes ToC so much easier to navigate and proofread in the Page: ns. Thanks Inductiveload. — billinghurst sDrewth 23:52, 14 June 2021 (UTC)

New tool: Wikisource Image UploaderEdit

The upload form.

There is a new tool available for more easily uploading images for use in Wikisource works. Imaginatively, it is named Wikisource Image Uploader. There is also a local gadget for linking directly to the tool with prefilled fields from the Page or Index namespaces. More documentation at Help:Gadget-ImageUploader.

If you notice any bugs or feature opportunities, please file an issue at Or just let me know directly :-)

If you can't think of something to use it for here is some inspiration: Category:Pages with missing images. Inductiveloadtalk/contribs 01:01, 22 June 2021 (UTC)


New Request for Comment on Wikilinking Policy is openEdit

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: allow bots the reupload-shared rightEdit

This will allow bots to be used to import files from Commons using the mw:Manual:Pywikibot/ script (which is currently broken, but I'm working on a fix).

Currently this right is disallowed except for admins.

@Xover: ping since you pointed me to this script. Inductiveloadtalk/contribs 21:29, 2 June 2021 (UTC)

  Support Languageseeker (talk) 21:39, 2 June 2021 (UTC)
  Support I'm slightly ambivalent. There was a reason why this permission was only assigned to +sysop when added, and we don't do a great job of managing bot permissions currently. On the other hand there is limited harm that can be done with it, and we do have some vetting of +bot. Not having it would also prevent InductiveBot (and other bots) from localising files from Commons or require it to have +sysop just for those tasks. So on balance I land on support. Xover (talk) 07:10, 3 June 2021 (UTC)
  • not support proposal in current form. Firstly the pywikibot script doesn't even work for admins, and if an admin has the right to go and do it, then it is a pretty simple task once one is logged into toolforge; you don't need to activate a bot right.

    To the proposal, we don't have that many requests, and we don't have any backlog, so what is the justification for such a significant change? I do not wish to have all bots with unlimited right to transfer files from Commons, and if we were to progress I would want to see controls over that ability. Remembering that what this is doing is also removing a file from Commons, and that should never be an unregulated right. — billinghurst sDrewth 11:45, 3 June 2021 (UTC)

  • I've fixed (well, pending) the script.
  • Also, the script only deletes the file if moving to Commons and if the user has delete at the source wiki. Since I'm not asking for the delete right, (and I don't even have it myself at Commons) this is doubly moot if running a non-sysop bot account and moving from Commons.
  • The justification is not having to perform batch imports actions as a sysop, but instead under a normal bot account. Since bots are have a process to gain their flag, it's not like just anyone can do this; that's the control over the ability. Fundamentally, if someone wants to upload the files here, they can still do so with a bot account by messing with the filename (and or touching the file hash), so bot users already have the ability to make a mess and don't because then you get a rude message on your talk page and/or a -bot.
  • There's nothing wrong per se with doing it as a sysop on Toolforge, it's just a bit overpowered, IMO, and a (small) faff when I have my bot OAuthed locally (though now I have two sets of tokens, so it's not so bad). Inductiveloadtalk/contribs 12:06, 3 June 2021 (UTC)
So you are saying that while it is called imagetransfer it is actually a replication, not a transferral. Okay, that is reassuring. With regard to the right, it would be better to have a group created and have the ability to have that right allocated, either to a bot, or to an individual. That gives a better control and overt permission to do an act, rather than as a hidden action (remember bots are generally hidden from RC). I would much rather have a light procedure in place where a 'crat (or maybe a sysop) grants the right to an account on public application, then it can be set to expire, and we don't have issues with bots just doing things. — billinghurst sDrewth 13:24, 3 June 2021 (UTC)
To be fairrrrrr the first line of the script doc is Script to copy images to Wikimedia Commons, or to another wiki.
A separate group makes sense too, but it would be best if it can be sysop-granted, I don't think it needs 'crat oversight (unless uploading these images is specifically harmful in a way I haven't realised?).
I mean, I can just upload them on my own account, but it means I have to bot-flag myself and then anything I do in the meantime is b. Or I spam RC with the images (in this case, >100). Neither of which is ideal, IMO. Unless we do say that image transfers shouldn't be done with a bot flag, and RC spam is OK in this case, just like local uploads, which is fine by me too, I don't really mind.
If "bots doing questionable things" is a issue, IMO we have bigger problems than just the possibility bot operators nefariously copying files from Commons. Inductiveloadtalk/contribs 13:49, 3 June 2021 (UTC)
Answer: Bots' actions are typically hidden from normal processes, so a modicum of caution/risk management and oversight is always best. I have seen bot access abused, and while I don't think that it will happen here, a light touch approval process is not a high hurdle. Plus this way, it can be given to those without bot rights however we so choose. — billinghurst sDrewth 14:47, 3 June 2021 (UTC)

Proposal 2: create separate groupEdit

Okay suggest that the proposal becomes: Creation of a group called "upload shared" with the sole right of reupload-shared that can be added and removed by administrators and bureaucrats. We can then work out our procedures for how that is applied. We can say now explicitly that administrators can apply it to their bots as an extension of their rights; further detail to be confirmed by consensus, if community supports. — billinghurst sDrewth 14:34, 3 June 2021 (UTC)

Annotation: Override files on the shared media repository locally (reupload-shared) which is required to move a file from Commons to enWS as normal rights will stop that happening due to the existence of the file at Commons. — billinghurst sDrewth 14:37, 3 June 2021 (UTC)
  Support fine by me. Inductiveloadtalk/contribs 22:39, 4 June 2021 (UTC)
  Comment Proposing to close this request as having the community consensus for creation of a user group "upload shared" with both the sole right and addition/removal capability as described. — billinghurst sDrewth 01:41, 14 June 2021 (UTC)
  requested at phab:T285130billinghurst sDrewth 08:22, 18 June 2021 (UTC)

Proposal: add a "project marker" to new works (e.g. PotM, MC, Wikiprojects) in {{new texts}}Edit

Despite a small drama a couple of weeks ago over this subject, I think it would be worth having a way to show some new works have come out of a community project, such as WS:POTM, Monthly Challenge, or any other Wikiproject that produces a proofread work. Specifically, it should link to the project in question to drive traffic to that project and allow the project participants to see their project's successes advertised.

Perhaps some fairly discrete inline tag that obviously not part of the work title: PotM (just an example, please don't bikeshed the exact formatting!). Inductiveloadtalk/contribs 10:16, 3 June 2021 (UTC)

@Inductiveload: Are you thinking of something that is logged within Wikidata through their d:Help:Badges as is the desired means to mark proofread and validated works? Or were you just wanting something local. Something that differentiates projects, or specific per project. Were you thinking something built into header templates? Root level, root level and subpages; or root talk page?

Further, what is your justification for driving people to projects for completed works? What do you think that it will achieve? Why do you see that project-produced works deserve that over single works?. I don't personally see that completed project works particularly need any special recognition post completion, well nothing more special than any other completed work. I would say feel welcome to develop something that sits on talk pages that allows works to be linked to projects, to be called up easily, otherwise there is nothing special about these works compared to any other work. Well nothing that warrants more recognition than something completed by a person or a couple of people outside of a project. At the moment our works are tagged with badges as delivered from WD records for Proofread/Validated, FT, and I would prefer to keep our header tagging to the badges, and to tag quality of works. — billinghurst sDrewth 11:31, 3 June 2021 (UTC)

@Billinghurst: Sorry, that wasn't clear, I mean in {{new texts}}, not on the mainspace pages or in the headers.
The idea is to show people that there are organized subprojects working on $whatever and that the projects are active (because otherwise they wouldn't be producing a new work) and available to join in. Inductiveloadtalk/contribs 11:42, 3 June 2021 (UTC)
@Inductiveload: I think that having some display options of what you are proposing in "new texts" sandbox would give the community an idea of the sort of thing, and the elegance that can be produced. It may also be opportune for us to think what else that template could easily and neatly do without overcrowding it, or making it ugly. — billinghurst sDrewth 11:59, 3 June 2021 (UTC)
Something (very roughly like Template:New texts/sandbox. Obviously exact styling is flexible, but it's a bit soon for nitpicking over that. Inductiveloadtalk/contribs 12:16, 3 June 2021 (UTC)
  Support I think this will help bring attention to community collaborations and reward users who participate in them. Languageseeker (talk) 03:34, 5 June 2021 (UTC)
  Support I think this helps promote the value of contributions to the collaborations and demonstrates to newcomers in particular that their contributions can quickly make it into a compiled product. One of the challenges with WS is that you can make contributions to an index that years later still isn't completed or transcluded. For some people, this extended time from contribution to realised product perhaps reduces engagement (I know it does for me). Nickw25 (talk) 10:19, 5 June 2021 (UTC)
  Comment On frwikisource, works in the New Texts section of the page produced by Mission 7500 are marked with: {{e|{{vert|Mission 7500}}}} which produces: Mission 7500 . I do not know how long this marker has been in place, but it has been there since at the very most, January 2019. CVValue (talk) 00:56, 21 June 2021 (UTC)

Bot approval requestsEdit

Repairs (and moves)Edit

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

The Wonderful VisitEdit

The Wonderful Visit should be moved to The Wonderful Visit (1895) to disambiguate from The Wonderful Visit (Atlantic Edition). Languageseeker (talk) 04:25, 9 June 2021 (UTC)

Other discussionsEdit

Policy on substantially empty worksEdit

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

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

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

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

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

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

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

  • 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. Inductiveloadtalk/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. Inductiveloadtalk/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. Inductiveloadtalk/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.)
    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. Inductiveloadtalk/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 {{Works of Voltaire}} volume navigation template). I don't know how tightly coupled the volumes of this edition are (does the first volume have a common ToC or index of works for all the volumes?), so some flexibility on format may be needed to make sense. But as a base rule of thumb it should start from a regular works page and deviate only as needed to accommodate this work (mainly the size is different).
    In any case… With a volume or two completed (they're only ~350 pages each) I'd be perfectly happy having something like that sitting around. With less then that I'd possibly be a bit more iffy, but it's hard to put any kind of hard limit on that. And with somebody actively working on it I'd be in no hurry whatsoever regardless of current level of completion.
    PS. I'm pretty sure a large proportion of the contents of these volumes are works that would qualify under "standalone works" that could exist independently in mainspace, regardless of what's done with the The Works of Voltaire page. Even his individual poems and essays can presumably make a credible claim here (because it's Voltaire; less famous authors would have a higher bar). Better as part of the edition, but also acceptable on their own. --Xover (talk) 16:56, 6 July 2020 (UTC)
  • @JesseW: I personally take no issue with this page's existence (actually I think it's a nice work and good way to allow an important author's works to be slotted in piece-by-piece. I have some general comments which overlap with this thread (written before Xover's reply, so pardon overlap):
    • First off, I differ with Xover in terms of the scan links: I think they're better than nothing, and I don't see much value in duplicating the volume list onto an auxiliary page just to add scan links. However, I can sympathise with the sentiment that our mainspace shouldn't direct users off-wiki (or at least off-WMF). But if we don't have the scans, and that's what the user wants, they're leaving anyway. Real answer: import moar scans!
    • No scan links are necessary where the volume exists in mainspace and is scan-backed (e.g. v3)
    • Ext scan links should only be used when there is no Index page or imported scan. Use {{small scan link}} or {{Commons link}} when possible (e.g. v2)
    • The first volume list could probably be in an AuxTOC to mark it out as WS-generated content.
    • The "Other editions" section belongs on an auxiliary namespace page (Talk, Portal or Wikisource). I suggest the Talk page is best in this case. Inductiveloadtalk/contribs 17:35, 6 July 2020 (UTC)
  • @Xover: I am in agreement with the majority of what you say. Particularly, I think a framework around any collective work (be it a single-volume biographical dictionary or a 400-issue literary review spanning 80 years) is the critical prerequisite, plus at least some scans, the more the merrier. Where I think I differ:
    • I am inclined to be a bit more relaxed in terms of how much of a work we need. As long as a single article exists, it's not "trivial" (e.g. only a short advert or some incidental text like a "note to correspondents", as opposed to an actual article), it's well-formatted and scan-backed, and a complete framework exists, including front matter and a TOC, such that's it is easy for anyone to slot in new pieces, I'd be fairly happy. Lots of periodicals have all sort of tricky bits like tables of stocks or weather tables and writing into policy that those must be proofread in order to get the "real" articles into mainspace would be a chilling effect, in my opinion. If you allowed an exception, it would be verbose and tricky to capture the spirit without saying "unless, like, it's totally, like, hard, man".
    • I am not dead against scan links in the mainspace at the top level, when such a top-level page exists. See my comments on Voltaire above. I am against them where they could sensibly be on an Author page and they are the only mainspace content.
    • I am ambivalent on the presence of, e.g., disjointed train timetables. It's not my thing to have a smattering of random timetables, but as long as they're individually presented nicely, it's not too offensive to my sensibilities. I might question the sanity of someone who loves doing tables that much, but whatever floats the boats! Also, I think that this might circle back to "good for export" - a mark which certainly would require completed issues or volumes. If you want to get that box ticked, you have to do it all.
    • Re the "notability" aspect of individual articles, I'm not really bothered by that, as I don't think we'll see a flood of total dross because few people really want to take the time to transcribe 1867 articles about cats in a tree from the Nowhere, Arizona Daily Reporter, and, actually I think some of the "dross" can be quite interesting in a slice-of-life kind of a way (always assuming well-formed and scan-backed). And the real dross is usually so bad (no scans, raw OCR, etc) that it can be dealt with outside of this topic. I think part of the value of WS is the tiny, weird and wonderful, not just in blockbusters like War and Peace and Pultizers. I think I might like to see more of our articles strung together thematically via Portals, but that's another day's issue. Inductiveloadtalk/contribs 17:35, 6 July 2020 (UTC)
      • @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. Inductiveloadtalk/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)


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

Since the proposal has now slipped off the main page (to here), with vague support for the first part (collective work inclusion criteria) and a fairly consistent opposition to the second (no-content pages), my plan is to transfer the first part, as guidelines rather than policy, to Wikisource:Periodical guidelines. As non-binding guidelines, they can then be worked on further in situ. Sound OK? Inductiveloadtalk/contribs 08:10, 16 April 2021 (UTC)
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)

"by nationality" categoriesEdit

Seeking feedback on how many author "by nationality" categories are necessary, and then the lower spread beneath those.

Here is what we have

I can see the value in some of these especially as all authors would normally be added to a category below "Authors by nationality", but all of these seems like duplication.

I will also preface the commentary that something like category:Scottish philosophers‎ and its kin are ambiguous in title as they are author: ns pages only, and if we keep them they either need to be policed or renamed to indicate author only. Taking biographical entries down that far is also seems somewhat exceeding requirements.

Anyway, asking what the community is trying to achieve with that categorisation, and where we want to go with it. Thanks. — billinghurst sDrewth 00:07, 12 May 2021 (UTC)

I think any literary occupation naming a form listed in the Lib of Congress catalog could be useful, e.g. Poets by nationality (from Poetry), Orators by nationality (from Orations), Dramatists by nationality (from Drama), Novelists by nationality (from Novels). But do we consider "nations" to be the modern entity or the one that existed at the time the author was alive? This will have implications in cross-linking categories with Commons and Wikipedia. --EncycloPetey (talk) 21:50, 9 June 2021 (UTC)

RfC: Nomenclature for categorisation of person portal pagesEdit

Back to the people categorisation nomenclature ...


Two previous nomenclature conversations about authors, and biographical works/entries

so authors pages are now "occupation as authors" and "biographies of occupation"

Top of the this part of the tree is {{:Category:Occupations]]

So where does the community wish for person portal pages to be categorised? To their own subcategory tree?, eg.

  • Category:Biologists
    • Category:Biologists as authors [Author ns:]
    • Category:Biographies of biologists [Main ns]
    • Category:(something about portals and biologists) [Portal: ns]

or is there a wish to combine them with an existing category? Not categorise? Or just leave them at the Biologists level? There are will never be a lot, though it maybe look a little unusual.

If it is its own category, what do you wish to have it called?

  • Portals of biologists
  • Biologists portals (grammatically incorrect or we can add grammar)
  • (your suggestions)

At this stage people portals are only generally only categorised to Category:People in portal namespace currently sitting in the 180s, and most through use of template:person (special:whatlinkshere/Template:Person) though not all. Still some transfers to do by anyone interested (petscan:19073593).

Thanks for your feedback. — billinghurst sDrewth 12:41, 13 May 2021 (UTC)

I did some transfers. Didn't encounter too many problems. Is it wanted to retain the old class hierarchy? I've kept them, but it is only possible to override the main class and the first subclass. See Portal:Francesca Cuzzoni. There is no support in {{person}} to override subclass2 (see Portal:Zacarias Moussaoui), or "parent" for that matter. It is possible to link a related portal with "portal" though.
I've also encountered one that should probably be merged? See Portal:Marcus Whitman. --Azertus (talk) 12:43, 25 May 2021 (UTC)
@Azertus: Thanks. I don't know enough to even start talking classes, out of my pay grade. With regard to Whitman, just merge the content and then replace the portal page with a substituted {{dated soft redirect}}. — billinghurst sDrewth 15:01, 25 May 2021 (UTC)

Categories for CC-BY and CC-BY-SAEdit

I noticed that licenses CC-BY (CC attribution) and CC-BY-SA are categorized in Category:Works by license differently:

Could someone explain — is there any specific reason for such distinction in categorizing of these types of licenses, or this difference has occured accidentally, without any intent? This information may be helpful for me, because I am intending to create category (or categories) for CC-BY on the multilingual Wikisource, currently it have category Creative Commons BY-SA, and I want to create similar category for CC-BY (CC attribution) as well.

Also, additional question: on the top of the Category:Creative Commons BY-SA there is a statement: "These works are released under a Creative Commons BY-SA license, including the Creative Commons Attribution-ShareAlike 2.0, Creative Commons Attribution-ShareAlike 2.5, and Creative Commons Attribution-ShareAlike 3.0 Unported licenses...", but license Creative Commons Attribution-ShareAlike 4.0 is not mentioned there; does it mean that CC-BY-SA 4.0 works are prohibited on the English Wikisource? --Nigmont (talk) 04:34, 20 May 2021 (UTC)

@Nigmont: I would think that it is an even simpler explanation, in that they have not been updated sincee 4.0 came out. We have and allow 4.0, see Template:CC-BY-SA 4.0. Feel free to update the text to be aligned with the reality. — billinghurst sDrewth 13:35, 20 May 2021 (UTC)
Alright, thanks! So I added an entry about CC-BY-SA 4.0 into the list of licenses of the category description. Meanwhile, the English Wikisource currently does not have a page describing CC-BY-SA 4.0 (which older CC-BY-SA licenses have, for example Creative Commons Attribution-ShareAlike 3.0 Unported), so I was forced to link to the Creative Commons page instead of linking to a Wikisource page. --Nigmont (talk) 03:10, 15 June 2021 (UTC)
In addition: why ever did I think that CC-BY-SA 4.0 might be prohibited on the En-WS: I had seen somewhere (maybe on the multilingual Wikisource, maybe on the Commons) that somebody said that only CC-BY-SA 3.0 was allowed (amongst CC-BY-SA licenses) on the Wikisource, and CC-BY-SA 4.0 is incompatible with 3.0 and so far it is prohibited, and a work licensed with CC-BY-SA 4.0 should be banned from the mul-WS. May be, that opinion ot that user had been inspired by absence of mentioning of CC-BY-SA 4.0 on the English Wikisource. :) So, such things as forgetting of mentioning of full sets of available licenses should not be taken too frivolous, because failing to do that may lead to dramatic conclusions. :) --Nigmont (talk) 03:29, 15 June 2021 (UTC)

Second parameter of {{wikt}}Edit

I'm working on a dictionary of foreign phrases, and I'm linking to Wiktionary whenever the page exists and has an entry in English or the language in question. I've found two phrases so far which vary slightly between the printed version and the Wiktionary page, so I tried to use the wt page as the first parameter in {{wikt}} and the alternate (printed) text as the second. The problem is that the template currently uses the second parameter to link to a language section instead of displaying alt text. I would argue that alt text is a more important feature for the template, but maybe it can be worked to have both. Can someone please help with this? Ultimateria (talk) 21:36, 22 May 2021 (UTC)

@Ultimateria: Please read Help:Wikilinks. It would not be usual for us to have pages with that many links externally to wiktionary. You don't need to use a template for a link you can simply use link syntax like [[wikt:target word|word]]. I would also argue that if you have a term of difference that under Wiktionary's approach that you are better to create the extra page, the variation, at Wiktionary. It is my understanding that they wish to capture such variations.

With such an approach I am also wondering whether it may be better aligned to using the Wikidata: lexeme componentry, rather than direct links to Wiktionary. @Jura1: would you care to add some informed comment? (not my speciality area) — billinghurst sDrewth 02:11, 23 May 2021 (UTC)

@Billinghurst: I promise I knew how to link, I just forgot! Thank you. I'd like to keep the links; this is a very concise dictionary and we can include much more information by linking to Wiktionary. I'm familiar with Wiktionary's redirect practice (which is extremely sparing), and I didn't explain that these two links are special cases, but one is a typographical variation we don't use, and the other is a rare variation of a phrase possibly made in error. Ultimateria (talk) 02:45, 23 May 2021 (UTC)
@Ultimateria:Sweet. One of the things that we have been considering/exploring recently is our management of interwiki links, especially in the modern day of wikidata, managing rotlink; annotating v. linking. Areas in which we are all learning, and trying balancing the impact. Never certain where to start an answer. — billinghurst sDrewth 04:13, 23 May 2021 (UTC)

Duplicate wordsEdit

I have posted a list of duplicate words I found on validated pages at User:Мишоко/Duplicate words. Much work to be done for those interested. Мишоко (talk) 16:37, 23 May 2021 (UTC)

@Мишоко: Interesting! Could I ask how you generated this list? Downloading text over the API or some sort of DB query? Inductiveloadtalk/contribs 13:09, 24 May 2021 (UTC)
I used the latest dump. "All pages, current versions only." 12GB uncompressed. Мишоко (talk) 15:35, 24 May 2021 (UTC)

It seems that people are applying different solutions to these problems. If the duplciation is in the source, and is an error, then I suggest at the the top (for example) should be marked up as at {{SIC|the the|the}} top. Some people have been tagging similar cases as "not done", and leaving the duplication in situ. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:29, 29 May 2021 (UTC)

Sure, if it is duplicated in the work it should be left in situ. Doing nothing with the work and marking as "not done" on the list is accurate; adding {{SIC}} is an optional means of handling it and is also accurate. To my way of seeing it, attending to the list as raised, marking its review is the matter for addressing the list.

If you wish to talk about the mandating of {{SIC}} for such situations, that is probably a different discussion. It was had when we introduced the template, and went from the invisible {{sic}} to the overt {{SIC}}; as well as the second parameter usage of the latter template.

If we are wanting to talk about whether we want to leave something in place for Мишоко's searches, we could also leave {{sic}} in place for the bot to note and skip. — billinghurst sDrewth 04:49, 30 May 2021 (UTC)

Browser rendering question/surveyEdit

I have run into an issue which might indicate a browser compatibility issue with our most common font size templates. Could people please check the following against this screenshot:


Specifically, please comment if:

  • you see the words "foo" and "bar" substantially closer together than in the screenshot, or
  • you see the same thing as in the screenshot and you run Windows and use any version of Firefox.

You can report working combinations of OS + browser too if you want. Please include both OS and browser versions. If you want to upload a screenshot for reference, you can do so at Phabricator: Inductiveloadtalk/contribs 13:07, 24 May 2021 (UTC)

If you have a screenshot you can typically just paste it and it creates the image. — billinghurst sDrewth 13:22, 24 May 2021 (UTC)
Seeing the same as the screenshot, using Firefox 89.0.1 (64 bit) on Windows 10 Einstein95 (talk) 08:17, 21 June 2021 (UTC)

Tech News: 2021-21Edit

17:07, 24 May 2021 (UTC)

Broken renewal linksEdit

Do records in get automatically removed after some time (or when the copyright/renewals expire)? Links to these records can be added to pages with the {{copyright renewal}} template, itself used by {{copyright-until}}. I've noticed that all those links on Author:Arthur Josephus Burks are broken, e.g. Of course I realise that once the copyright *and* the renewal have expired, there's no point in keeping them, except for historical purposes and verification.

I've downloaded the full data set for the Copyright Renewals Database and there is no trace of the IDs from the Burks page (e.g. R107985). @Fenrix1958: do you know more about this? All in all, I'm just curious... --Azertus (talk) 13:29, 26 May 2021 (UTC)

The problem here is that the renewal is actually for a periodical (Weird Tales), so it's listed in a different part of the copyright register: The Stanford database only includes books, so this link never worked, it's just added automatically by {{copyright renewal}}, which can't tell a book's R-number from a periodical's. Possibly {{copyright until}} needs a parameter to link directly to some other resource.
Other periodical renewal volumes are listed here. Inductiveloadtalk/contribs 08:59, 28 May 2021 (UTC)

Tech News: 2021-22Edit

17:05, 31 May 2021 (UTC)


I'm wondering if I should continue doing things here at all right now:-

When you've checked templates carefully SEVERAL times, and they still break it's time to go back to the LAST stable version obviously, which is what I've now had to do TWICE, despite checking everything VERY CAREFULLY, and STILL having thing explode in spectacular fashion.

I do not like wasting my time, and having Mediawika, the intircate nature of some templates and my apparent inexperience hamper my efforts i not conducive to continued contributions here.

Perhaps someone else can review the train-wreck of revisions of the templates concerned and figure out what ACTUALLY went wrong, but at present I am wondering why I should bother continuing to contribute, if I am not going to be able to rely on the kind of support that such efforts and expertise such efforts would seem to apparently need.

I would also strongly suggest given their widespread uses that the block of templates concerned are put under some kind of protection, so that a PROPER code review can take place rather than my completely incomeptent efforts. ShakespeareFan00 (talk) 19:41, 31 May 2021 (UTC)

i admire your attempts to make sidenotes work after being a mess for a decade. [2] i would suggest finding someone with some serious CSS skills (as mentioned by billinghurst some time ago [3] ) until we get a wishlist , or summer of code, it will be very frustrating, best to put on hold and spare the emotional energy. Slowking4Farmbrough's revenge 23:16, 31 May 2021 (UTC)
It happens. Sometimes you can spend hours working on something only to make it even more broken. It's not your fault, just a sign of the complexity of the issue. I've really valued your work here and would be greatly saddened to see you leave. Hang in there. Languageseeker (talk) 02:23, 1 June 2021 (UTC)
Strongly agree with the sentiments expressed, and have benefited from ShakespeareFan00's contributions elsewhere. Many have tried to make it work and watch it explode, previous experiments are useful when looking for a solution :) CYGNIS INSIGNIS 02:46, 1 June 2021 (UTC)

We need to set our criteria for what it is that we want. Left and right? How it works in each in display layout, and how we want it to work. How we expect it to work in mobile. How we expect to act when the sidenotes overlap. Until the criteria is determined nothing can happen. I still think that this is one for the wishlist. What you need to have is all the features and functional specificatiosns developed and ready to go. Leaving it all until there is a call-out is too late. @Whatamidoing (WMF): is there a product manager we could work with, or approach, to scope these needs so we have a good proposal ready to go at some point resources allow?

It should never stop you from proofreading the works now, as if the base templates are used, they become sandboxes for the developers. We need someone css clueful and timeful, who is separated from the works and will tell us how it will just have to be. And stamp their feet at us when we vary. Also recommend stop developing more templates to do this, keep it simple. The more complicating the factors that keep being introduced makes any translation to something CSS plug-in just makes it harder to migrate. — billinghurst sDrewth 04:04, 1 June 2021 (UTC)

@Billinghurst:. The plan was to update the sidenotes to use CSS classes for the defaults, which could be overridden by defining additional classes on a per work basis. Things like depth, size and alignment could then be set across an entire document (or CSS selector) instead of indvidually for each sidenote, which is the current approach. I was prior to my update attempts using an override approach (on the outer wrapper) here: Page:1751_A_collection_of_all_the_public_acts_of_Assembly,_of_the_province_of_North-Carolina_now_in_force_and_use.pdf/28 the relevant classes being Index:1751_A_collection_of_all_the_public_acts_of_Assembly,_of_the_province_of_North-Carolina_now_in_force_and_use.pdf/styles.css.
  1. The reason sidenotes end up overlapping, is that without the override, position:absolute fixes the vertical position. Given the limitations of HTML/CSS when the relevant templates were implemented this approach was entirely reasonable. The floated/clear approach clear:left/right clears the overlap, (and I will note that in mainspace, a floated approach is essential what {{OutsideL}} and {{outsideR}} implement.). As the floated/clear approach required fixed margins however, it's not a universal solution. (Especially for works that do not have them). The classes in the relevant index only apply in Page: namespace so far, because of the different layouts, I am not sure it could be made to work for {{left sidenote}} and {{right sidenote}} universally, given the very different dynamic layouts. I've moved my efforts into Sandbox versions, that way any typos shouldn't 'leak' and it gives someone else a chance to look at the code BEFORE it goes live. (Aside: Is there a reason why for layouts, the relevant styles are set directly from code in the Mediawiki namespace instead of the code choosing to apply a 'relevant' stylesheet, which could be defined independently.?
  2. It's currently tricky to handle the situation of a nil parameter passed (or not pasesd) from a higher template. I'm in the process of trying to sandbox in my userspace a possible approach to this.
    A construction |{{if:{{align}}|align={{{align|}}|...}} does not always reliably workas parameter passing logic to a lower level template from a higher level wrapper. One typical way of solving this to do just set a default anyway |align={{{align|value}}} being a typical usage. What I'd like to eventually do is something like <syntax highlight inline=yes lang="html">|align=@std</syntaxhighlight> as the paramater passing logic in the higher value template.
    That approach however make the lower level template a lot more complicated, as a switch function has to be used, to handle 'absent' ,'nil' and '@std' values that eventually reach it. I have however implemented @std like handling logic as a sub page of my userspace and would appreciate someone with more experience figuring out if it could be simplified. (see User:ShakespeareFan00/@std, User:ShakespeareFan00/@val and the testcases at the bottom of User:ShakespeareFan00/foo/testcases.ShakespeareFan00 (talk) 06:36, 1 June 2021 (UTC)
Stop. Take a step back. Get out of the operations. Until you have a picture of what it is that is wanted and needed (functional specifications) you are wasting breath telling about coding of templates, it is just code. You need a strategy before you have tactics. Until we have steady and complementary LAYOUTS, and a picture of what happens with sidenotes in each form of layout. What the form for mobile: do we keep them? do we stick them in front of paragraphs. Is it a case by case situation? So please provide no further detail of the guts of things. And yes of course it is a CSS class and style solution, as it is a CSS problem. — billinghurst sDrewth 07:18, 1 June 2021 (UTC)
What Billinghurst said. ⬆︎
The problem you're attacking is a big and complex one that interacts with just about every conceivable complicating factor: MediaWiki's capabilities, the active skin and its styling, the capabilities and limitations of templates, of ProofreadPage, the limitations of HTML and CSS, our community practices, the other technical bits and bobs on the project (like the dynamic layouts script), and even culture and community and other such human factors. You are not going to solve this "from the bottom up" by keeping banging your head against it: if it were solvable that way in practice, one of the geekier members of the community would very likely have done so already.
And because it is a big complex issue, the benefits of solving it have not yet been seen as sufficient to outweigh the effort involved. If you want to make any actual progress on this, starting from that end is where you can make headway. It may be almost as frustrating (just for different reasons), but it at least has a chance of eventually leading to a solution somewhere down the line.
And just for the record: I very much doubt that there is any perfect solution for this. The fundamental difference between a fixed paged media like a book and a dynamic non-paged media like the web means we are only ever going to be able to achieve approximations of various degrees of verisimilitude. Hyper-precise positioning of sidenotes relative to portions of the text, and without interfering with other page elements, is probably only going to be doable for something like 80% of cases; the remaining edge cases are going to have to suffer one tradeoff or another. Xover (talk) 08:06, 1 June 2021 (UTC)
Not that I actually care at this point, in the absence of someone providing an actual specification, but I took the attempted re-write into a sandbox, and after some careful rewriting I managed to get this Page:Sandbox.djvu/257, which addressed many of the objectives I was trying to achieve namely:
  1. Avoid generation of unnecessary inline styles, by moving the default values to an appropriate CSS class ( In respect of the outer 'layout' wrapper this classing of the defaults had already been implemented by another contributor.) and only generating inline styles for non-default values.
  2. Allow the 'default' settings to be updated by changing only the core template/stylesheet, as opposed to every template that might call the basic templates, and without needing to redundantly specify those defaults in other templates.
  3. Allow sidenote layout/formatting to be separately configurable via CSS selectors in Indexstyles or other TemplateStyles.
  4. Allow for specific classes of sidenote layout/formatting to be defined across a work without needing to specify values inline or without affecting a generic sidenote layout/format.
  5. Eliminate the Page/Main namespace distinction as this can be done with an appropriate namespace selector in CSS.
What I had not yet implemented (as there are other workarounds) was:-
  1. Allow sidenotes to act as link targets, by providing a way to set a sutiable anchor or ID for them. (This is so that the cl-act like anchoting on
Onoging issues:
  1. Overlapping sidenotes.
  2. Limitation of {{outside}} and {{outside2}} to 'default' "Layout 2" due to how they are currently implemented.
  3. Other sidenote like marginal templates such as {{Outside}}, {{margin note}} {{cl-act}}} etc...
But as no-one has stepped forward to write a specification, I am not holding my breath for these to be fixed any time soon. ShakespeareFan00 (talk) 08:53, 2 June 2021 (UTC)
@Billinghurst: I'm not sure which team would be best, but let's ping @SGrabarczuk (WMF) for now, since he's been working with New Vector and therefore appearance-related stuff, and I'll go poke a couple of PMs to see which team they think it ought to be. Whatamidoing (WMF) (talk) 23:55, 2 June 2021 (UTC)
Also, @ShakespeareFan00, which skin are you using? I think @Xover is correct about the possibility of skin-specific difficulties. Whatamidoing (WMF) (talk) 00:09, 3 June 2021 (UTC)
The issue is not necessarily related to Skins. ( I think I am using Vector) It's mostly related to
  • 'Dynamic layouts', a feature that's specific to English Wikisource (The current Dynamic Layouts are implemented in mainspace via Mediawiki:PageNumbers.js.)
  • the 'paged' nature of content that Wikisource uses the ProofreadPage extension for.
  • The lack of 'native' support for sidenotes in wiki markup/HTML/CSS.
  • The differences between old-style print and online content.
  • The (Pre|as)sumptions certain contributors myself included, have made about what's possible to do.
A very high-level requirement might read something like this : "Provide a mechanism to support side-noted content in a clear and unobscured manner, consistent with the intent of an original work, desirably reflecting stylistic choices made by the original authors, and allowing readers with differing devices to view them in a manner consistent and appropriate to the requirements of those devices or reader preference."
ShakespeareFan00 (talk) 13:02, 3 June 2021 (UTC)
Eek! I need to get back to AKJV where sidenotes are used *extensively*, and I'm hung-up with such problems as mentioned above - sidenotes overrunning each other.
Please ping me when y'all have proposals and possible code to try. Basically, sidenotes have to work for AKJV - sidenotes solutions have to work for AKJV - or we're just creating a different solution that can't be used in important works. Shenme (talk) 04:37, 9 June 2021 (UTC)

Error on Main PageEdit

Can someone help fixing the "Lua error" in Module:Monthly Challenge statistics? Many thanks for debugging a component of our main page.廣九直通車 (talk) 09:30, 1 June 2021 (UTC)

@廣九直通車. The "responsible parties" have been notified, and knowing them they'll probably fix it in short order (modulo IRL, timezones, etc.). :) Worst case I can try tracing my way through the code at some point over the next 24–48 hours (superficially it doesn't look like it'll be too too hard to fix, but…). Xover (talk) 11:04, 1 June 2021 (UTC)
I think I may have fixed this accidentally by prodding a cronjob before seeing this message. I will attempt to figure out what was actually exploding and hopefully it'll all go off on time next month. Inductiveloadtalk/contribs 11:28, 1 June 2021 (UTC)

Revert my edits on Index:Works of Thomas Carlyle - Volume 03.djvuEdit

Can an administrator revert my edits on Index:Works of Thomas Carlyle - Volume 03.djvu that I recently did. I tried updating the source file and then shifting the pages and I didn't work out.

Page:Works of Thomas Carlyle - Volume 03.djvu/13
Page:Works of Thomas Carlyle - Volume 03.djvu/11
Page:Works of Thomas Carlyle - Volume 03.djvu/10
Page:Works of Thomas Carlyle - Volume 03.djvu/20
Page:Works of Thomas Carlyle - Volume 03.djvu/21

Languageseeker (talk) 03:25, 2 June 2021 (UTC)

@Languageseeker: It's not clear to me what you want done, or what you need an admin for. You can undo your own edits on any page, and you can even undo most page moves (just so long as the automatically created redirect doesn't have any additional edit history). Is the issue that the source file has been updated and the Page: pages are no longer aligned with the scan? Xover (talk) 05:19, 2 June 2021 (UTC)
This got taken care of. Thanks. ! Languageseeker (talk) 20:24, 2 June 2021 (UTC)
If you want to see your page moves special:log/move/Languageseeker and they should have a "revert" link; they do for admins. It will create the redirect, and if you want that deleted then you will need to request those with {{sdelete}}. — billinghurst sDrewth 11:03, 3 June 2021 (UTC)

Plato volumesEdit

I was sifting through the philosophy section and saw that books of Plato's dialogues, at least the 5 volume Jowett translations (which are all empty indices, Index:The Dialogues of Plato v. 1.djvu and so on), have at least one redundant copy, being Index:02 Jowett Plato Facsimile Vol2.pdf, from which Euthyphro and Apology (Plato) is transcluded from into mainspace. Should the proofread and transcribed pages from the PDF moved to the more complete 5 vol DJVUs, and the mainspace pages be transcluded from the moved pages? Thanks, EggOfReason (talk) 00:59, 6 June 2021 (UTC)

I would check to see which scan is of the best quality and migrate content to that copy. --EncycloPetey (talk) 21:55, 9 June 2021 (UTC)

Should poor quality of an image be preserved in works?Edit

If there is a version of an image that is in color, but the original text contains a version of the image in black and white, should the black and white image be used over the colored one? Or should we be aiming for textual accuracy by showing the image that originally appeared there, in its original state?

A specific example: @Languageseeker: recently added a colored version of the frontispiece to Resurrection Rock (1920). I really appreciate that he found the original painting of this image and it is beautiful, and I think it should be on Wikimedia Commons for sure. But my only concern is that it does not appear in color in this version of Resurrection Rock.

Another example is The Bloom of Monticello, which contains facsimiles of paintings in lower quality than the originals. In that work, I kept the images as they originally appeared. PseudoSkull (talk) 01:48, 6 June 2021 (UTC)

Depends on the work In one work of recent origin (of a technical nature) I used color replacements because it was only the scan that was in monochrome.

ShakespeareFan00 (talk) 10:39, 6 June 2021 (UTC)

I think about what the author's intent would have been. Would the author have intended to have full-color, high quality reproductions and were limited by the technology or did they incorporate such images for artist reasons. As a reader, I would rather see a high-resolution color version and I think that most authors would have preferred the same. Languageseeker (talk) 12:16, 6 June 2021 (UTC)
@Languageseeker: We also keep typographical errors though (except in rare circumstances), which were not intentional on the author's/publisher's part. PseudoSkull (talk) 18:02, 6 June 2021 (UTC)
@PseudoSkull: I've struggled with the issue as well. I think both sides have valid arguments. For me, the major distinction is between technological limitations and errors. Black and White reproductions of paintings resulted from technological restrictions while typographical errors did not. I think it's important to note that in this case, the painting was commissioned specifically for Resurrection Rock. Languageseeker (talk) 13:54, 10 June 2021 (UTC)

It really depends on the purpose of the text. In a book about painting, I would use higher quality color images, if they are available. If the image is intended to show detail in a part of the painting, I might stick with the original. If the image is a minor feature of the text, again I might use the original. --EncycloPetey (talk) 21:58, 9 June 2021 (UTC)

Depend on what the author's intent and Wikimedia Commons may consider having both colored and black & white. Some scans are photocopied from colored to black and white and if so proven, then having colored images may render black & white redundant.--Jusjih (talk) 04:28, 11 June 2021 (UTC)

Tech News: 2021-23Edit

20:02, 7 June 2021 (UTC)

line spacing on Polytonic blockEdit

Could someone correct the line spacing on Template:Polytonic block? It produces a larger gap between the first and second line in a block than between subsequent lines, as shown below.

ὄλβου καὶ πλούτου δώσω περικαλλέα ῥάβδον,
χρυσείην, τριπέτηλον, ἀκήριον ἥ σε φυλάξει,
πάντας ἐπικραίνουσ᾽ οἴμους ἐπέων τε καὶ ἔργων
τῶν ἀγαθῶν, ὅσα φημὶ δαήμεναι ἐκ Διὸς ὀμφῆς.

Thanks. --EncycloPetey (talk) 17:29, 10 June 2021 (UTC)

@EncycloPetey: This is another fun manifestion of MediaWiki's rather trigger-happy approach to P-tags. Basically, if the template looks like this:
then the output looks like this:
  Line 1<br>
    Line 2<br>
Whereas if the template looks like this:
then the output looks like this:
    Line 1<br>
    Line 2<br>
The MediaWiki skin adds top/bottom margins of 0.5em to P-tags by default, so the former ends up placing that margin between Line 1 and 2.
I have changed the template to align with most other block templates like {{larger block}} which also add the newline after <div>. Inductiveloadtalk/contribs 19:20, 10 June 2021 (UTC)


Template Runningheader doesn't support anymore leading spaces in the parameters. {{Runningheader| left| center| right}} has for result:




and not




Is there a way to fix the template or the pages with this issue? --M-le-mot-dit (talk) 17:36, 10 June 2021 (UTC)

@M-le-mot-dit: Try &nbsp; Tommy J. (talk) 19:00, 10 June 2021 (UTC)
@M-le-mot-dit: In general, whitespace around parameters is pretty fragile (it's handled differently for positional vs named parameters, for a start). What are you trying to achieve? It's possible index CSS may be more appropriate if it's spacing-related. Inductiveloadtalk/contribs 19:11, 10 June 2021 (UTC)
In fact these spaces are not useful; it was just clearer to separate parameters in long expressions. I have now to fix hundreds of page in Index:All the Year Round - Series 2 - Volume 1.djvu and I wonder if a bot may help me. --M-le-mot-dit (talk) 09:22, 11 June 2021 (UTC)
@M-le-mot-dit: if something is sitting in the header, my thought would be to just leave it. Someone can fix it when they validate the pages and there is no point in wasting good time for something that does not affect the transclusion. — billinghurst sDrewth 11:20, 11 June 2021 (UTC)
@Billinghurst: thanks for your suggestion. I'll fix validated pages and let the proofread pages for the future validation. --M-le-mot-dit (talk) 13:02, 11 June 2021 (UTC)
@M-le-mot-dit: Oh, I see, sorry I misunderstood the issue. I have adjusted the template to avoid this by using explicit named params to strip the whitespace. Inductiveloadtalk/contribs 13:23, 11 June 2021 (UTC)
@Inductiveload:. Excellent! Thanks for this improvement, because I don't remember if I have done the same elsewhere. --M-le-mot-dit (talk) 13:28, 11 June 2021 (UTC)

I see what @M-le-mot-dit: was attempting, and why I think. Leading spaces can be used with named parameters

{{RunningHeader|left= LEFT |center= CENTRE |right= RIGHT }}




but not positional (unnamed) ones. Fixing this is a trivial matter for a bot cleanup, doing it manually is not trivial. CYGNIS INSIGNIS 11:54, 11 June 2021 (UTC)

It is a design feature of templates that named parameters work better in managing whitespace, and that positional parameters without the explicit parameter names (1=|2=|3=) just play differently. My point was that in headers in the page: ns we truly don't need to fuss. — billinghurst sDrewth 13:26, 11 June 2021 (UTC)

@M-le-mot-dit: There are some places where the running header has been used in the body rather than in the header or footer, and therefore will be presented in the transcribed work.

@Billinghurst: Is there a way to search for uses of this template in the transcluded text for repair, without having to search for uses that are not transcluded? --EncycloPetey (talk) 15:03, 11 June 2021 (UTC)

Inductiveload has fixed the issue in the template itself; you can see in my example in the top of this section that there is no more difference with or without leading space. So there is no problem even when RunningHeader is used in the body of a discussion. --M-le-mot-dit (talk) 18:03, 11 June 2021 (UTC)
@EncycloPetey: I see a template count of (transclusions: 1,230,437, links: 125) all up, and in Main ns (transclusions: 4,031, links: 0) [10] and we don't know whether they are using the template name or a redirect, so would have to do a what transcluded these to 4000 main ns pages. With regard to header/body/footer, remember they don't actually exist, they are javascript display artefacts of wikitext, so no, I don't think that it is worth chasing down for a handful of possible cases of <pre> text displays. This belongs to our proofreading and validation process. — billinghurst sDrewth 01:22, 12 June 2021 (UTC)

Universal Code of Conduct News – Issue 1Edit

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

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

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

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

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

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

Find-and-replace across a whole workEdit

Do we have a tool that can do find-and-replace operations across all the pages in a single work? I'm thinking of something analogous to VisualFileChange.js on Commons. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:44, 11 June 2021 (UTC)

No automated bots that users can set and forget. Generally I would do a search and bot it. We can just load the special:prefixindex set of pages and bot them. Not hard. More whether we can get a good regex with little false positives. If you want something done then WS:BR. With regard to the script why don't you just load it in your common.js and see if will work for you. — billinghurst sDrewth 13:33, 11 June 2021 (UTC)
visualfilechange can do it on commons. but it was designed as a deletion tool, so not included here. maybe loading the javascript will work here [11] --Slowking4Farmbrough's revenge 12:19, 16 June 2021 (UTC)

Request for eyeballs and editing => Wikisource:Do not move Index:, Page:, File: pagesEdit

Hi. I am preparing this document as a bit of an explanation essay and a bit of guidance. It is a rough draft and I would appreciate people adding to the document or adding annotations for components that need clarifying/modifying. Be as harsh/finicky as you like with it, it is formative and needs to be understandable to newer users. — billinghurst sDrewth 02:17, 14 June 2021 (UTC)

Suspected OCR errorsEdit

I've posted a list of suspected OCR errors on validated pages at User:Мишоко/Suspected OCR errors. Much work to be done for those interested. Мишоко (talk) 08:26, 14 June 2021 (UTC)

@Мишоко: Very good! Inductiveloadtalk/contribs 08:55, 14 June 2021 (UTC)

transclusions as single pageEdit

I just created the index Index:My Disillusionment In Russia.djvu as a single page. The practice here is to subpage sections, even to the most discrete part (eg. tertiary works, and at least dictionary). A concern might be the generation of page structure for export, I don't know enough about that. Comments? CYGNIS INSIGNIS 15:20, 14 June 2021 (UTC)

@Cygnis insignis: On-wiki: it's had to go right to a given chapter because there is no TOC.
WRT to export:
  • This means there will be no Chapters in the document TOC: [12]. In conjunction with the lack of in-text TOC, there is no way at all to find a chapter in the epub (or PDF). There is no fundamental reason we can't deal with this a task to add the ability to add an in-page TOC that points to sections on the current page to the epub TOC.
  • If you do do this, you should probably add a {{page break}}, otherwise the chapters all run together, whereas you probably want each chapter to be a new page (this is normal in pretty much all real books and also ebooks). Inductiveloadtalk/contribs 15:35, 14 June 2021 (UTC)

Tech News: 2021-24Edit

20:26, 14 June 2021 (UTC)

Transclusion ProblemEdit

In The Adventures of Huckleberry Finn (1884)/Chapter 4, the first word is cut off on the transclusion, but not on the page scan. (It says Well in Page ns, but not in the transclusion.) Can somebody please take a look. Languageseeker (talk) 02:39, 15 June 2021 (UTC)

It displays for me, same in both main and page: nss. — billinghurst sDrewth 11:53, 15 June 2021 (UTC)
Thanks for checking. It seems to work for every Layout, except Layout 2 (the default one). Which one are you using? Should I take a screenshot? Languageseeker (talk) 12:56, 15 June 2021 (UTC)
@Languageseeker: May be due to the negative indent. Try something like "height1=177px|width1=100%|height2=30px|width2=300px|height3=440px|width3=324px" and no indent. --M-le-mot-dit (talk) 15:13, 15 June 2021 (UTC)
The ELL is sitting up above the image in layout 2. People are just trying to be too clever. Keep it simple. There should be three images, not the one. The title, the image, and the W. Then you can use {{drop initial}}. We need something that works on computer monitors and phones, so trying to think that you can extract one image from a book and get image is just fooling oneself. KISS! — billinghurst sDrewth 16:31, 15 June 2021 (UTC)
{{overfloat image}} and {{flow under}} should be burnt at the stake, and if anyone wishes to hold to them while they are burning ... (well). They won't export nicely. — billinghurst sDrewth 16:37, 15 June 2021 (UTC)

OCR botEdit

Do I recall reading that someone has a bot that can populate pages with OCR text, and perhaps running headers, ready for proofing? Index:A Catalogue of the Birmingham Collection - 1918.pdf has over 1100 pages, and it would be good to get a help starting on them. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:58, 15 June 2021 (UTC)

@Pigsonthewing: Does the OCR not appear automatically once you edit the page? Inductiveloadtalk/contribs 18:22, 15 June 2021 (UTC)
Yes; that's not what I'm talking about Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:44, 15 June 2021 (UTC)
@Pigsonthewing: Also not what you asked, but are you aware that the running header and footer can be inserted automatically as you go? A 'bot' could do that and save the page, is that what you want? I don't consider that as useful as the other methods of proofreading. CYGNIS INSIGNIS 13:31, 16 June 2021 (UTC)
@Cygnis insignis: I suspect what he is asking about is 'automatically' using Help:Gadget-ocr to create the pages with it's improved OCR, instead of just saving the garbage that is typically embedded in the file. Jarnsax (talk) 17:32, 16 June 2021 (UTC)
@Pigsonthewing: I ran the OCR and fixed the running header on the first 50 pages or so for you. Definitely a work that will benefit from one person doing the majority of the actual transcription, for consistent table formatting. Feel free to poke at me for another batch.. far less tedious when you can do smaller batches somewhat automatically. Jarnsax (talk) 17:56, 16 June 2021 (UTC)
Having run 110 or so pages of this, while a bot to perform the task might be useful in some cases, this isn't one of them. Tessaract is obviously quite confused by the page layout, seeing it as 'multi-column' instead of 'dictionary' about half the time, and so the text for the running header isn't reliably placed. To get a 'reliable' OCR would probably require manually futzing with the PDF to define text fields... not even remotely worth it. Jarnsax (talk) 19:32, 16 June 2021 (UTC)
yeah, this work will require a lot of table code. given the text layer typical output, might want to paste in a spreadsheet, to move cells around, and then into bot will not help. --Slowking4Farmbrough's revenge 01:27, 18 June 2021 (UTC)

Letter suggesting membership of James Cook in The Royal SocietyEdit

The body of the letter has been transcribed, but the signatures and dates below it have not, and I'm having trouble reading them. If anyone who's familiar with 18th century handwriting wants to transcribe/proofread(/validate) about half a page of signatures, I'd really appreciate it. The page to proofread is Page:Cook letter.jpg. —CalendulaAsteraceae (discusscontribs) 02:52, 16 June 2021 (UTC)

Wikimania 2021: Individual Program SubmissionsEdit

Dear all,

Wikimania 2021 will be hosted virtually for the first time in the event's 15-year history. Since there is no in-person host, the event is being organized by a diverse group of Wikimedia volunteers that form the Core Organizing Team (COT) for Wikimania 2021.

Event Program - Individuals or a group of individuals can submit their session proposals to be a part of the program. There will be translation support for sessions provided in a number of languages. See more information here.

Below are some links to guide you through;

Please note that the deadline for submission is 18th June 2021.

Announcements- To keep up to date with the developments around Wikimania, the COT sends out weekly updates. You can view them in the Announcement section here.

Office Hour - If you are left with questions, the COT will be hosting some office hours (in multiple languages), in multiple time-zones, to answer any programming questions that you might have. Details can be found here.

Best regards,

MediaWiki message delivery (talk) 04:19, 16 June 2021 (UTC)

On behalf of Wikimania 2021 Core Organizing Team

Index:Robert Carter- his life and work. 1807-1889 (IA robertcarterhis00coch).pdfEdit

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

author categoriesEdit

Can I get a pointer to discussion of the categories in the Author ns that concluded the construct category:X as authors was a good idea? CYGNIS INSIGNIS 18:54, 17 June 2021 (UTC)

Check the archives for here over the last 18 months, the conversations were open for a long period. The basis was that we were getting a mix of authors and biographies in the categories, so they have been named overtly. — billinghurst sDrewth 11:58, 19 June 2021 (UTC)

Editor parameter in "header" and its use on subpagesEdit

Hi. I would like for us to consider that the editor in {{header}} have advice that it should typically only be used at the top level (or volume level) of a work, and not need to be added to every subpage of a work, eg. for article level. We need to be keeping the subpages cleaner and only have the information that is specifically pertinent to the subpage, not filled with secondary information that is available higher in the work. — billinghurst sDrewth 01:26, 18 June 2021 (UTC)

Mobile version => collapsed licences?Edit

I am wondering for our works and our author pages whether we should collapse the visible licences. — billinghurst sDrewth 04:31, 18 June 2021 (UTC)

Blackletter looking horrid (UnifrakturMaguntia)Edit

Anyone else currently finding blackletter difficult to read.

  • Hard to read Hard to read
  • Hard To Read Hard To Read

When I proofread works I have used it over the umpteen years and not had a problem. Looking at it today, this representation is awful. I have no idea where we look in the ULS system for the font history of UnifrakturMaguntia. — billinghurst sDrewth 11:51, 19 June 2021 (UTC)

we are at the mercy of a free font provider there are public domain fraktur fonts, but haven't found an accessible one. we need a special character set. german converts to latin, it is only english that continues to do mainly on title pages. (i thought the point was to make it hard to read) --Slowking4Farmbrough's revenge 14:43, 19 June 2021 (UTC)

Please provide input here or on Meta and during an upcoming Global Conversation on 26-27 June 2021 about the Movement Charter drafting committeeEdit

Hello, I'm one of the Movement Strategy and Governance facilitators working on community engagement for the Movement Charter initiative.

We're inviting input widely from users of many projects about the upcoming formation of the Movement Charter drafting committee. You can provide feedback here, at the central discussion on Meta, at other ongoing local conversations, and during a Global Conversation upcoming on 26 and 27 June 2021.

The Movement Charter drafting committee is expected to work as a diverse and skilled team of about 15 members for several months. They should receive regular support from experts, regular community reviews, and opportunities for training and an allowance to offset costs. When the draft is completed, the committee will oversee a wide community ratification process.

Further details and context about these questions is on Meta along with a recently-updated overview of the Movement Charter initiative. Feel free to ask questions, and add additional sub-sections as needed for other areas of interest about this topic.

If contributors are interested in participating in a call about these topics ahead of the Global Conversation on 26 and 27 June, please let me know. Xeno (WMF) (talk) 16:53, 19 June 2021 (UTC)

The three questions are:

  1. What composition should the committee have in terms of movement roles, gender, regions, affiliations and other diversity factors?
  2. What is the best process to select the committee members to form a competent and diverse team?
  3. How much dedication is it reasonable to expect from committee members, in terms of hours per week and months of work?

Tech News: 2021-25Edit

15:49, 21 June 2021 (UTC)

em-dash at page wrapEdit

How can we suppress a space at the start of a page, when the preceding page ended with a character such as an em-dash? for example, the start of page 26 on /Report renders as "Steam.— Should" when "Steam.—Should" is wanted. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:10, 21 June 2021 (UTC)

@Pigsonthewing: You need to use {{peh}} (page-end-hyphen) to do that. It's the same way you'd keep the hyphen in the word "over-eager" being split over a page break. See H:HYPHEN for more details. Inductiveloadtalk/contribs 18:37, 21 June 2021 (UTC)