Wikisource:Scriptorium

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

Announcements

1000 pages processed in the Monthly Challenge

The first-ever Monthly Challenge, after a fairly sedate start, passed 1000 processed (marked no text, proofread or validated) pages yesterday, and has sustained over 100 processed pages for 2 days straight. Very, very approximately, This represents 10% of pages at enWS processed in the last 2 weeks.

In the spirit of friendly competition, there were more pages processed the day before yesterday than Mission 7500, the French equivalent challenge (which recently has been racking up ~12000 page a month) did yesterday. We're still to reach a milestone of 200 pages in a day, at which point the stats table gets a shiny green row.

There is nothing different about proofreading in the Monthly Challenge, and everyone is free to dive in. Nominations for future months are always open, but if you really want your favoured book to feature, you will need to help make a space for it! Inductiveload—talk/contribs 01:05, 13 May 2021 (UTC)

Announcing w:Template:Cite Q does Wikisource connections

It has been a long time in the waiting, however, this Wikidata-populated template cite Q now will automatically link to English Wikisource if you populate Wikidata appropriately.

Example: enWS—Abbott, Leonard Dalton <=> WD—Abbott, Leonard Dalton (Q106554722) <=> enWP—w:Leonard Abbott
Usage: {{cite Q|Q106554722}}

Thanks to Pigsonthewing and Mike Peel for their coding and time to get this implemented at enWP.

We need to find a good place to notate this for local usage. One place we should be adding it is to Wikisource:for Wikipedians though there should be other places locally. — billinghurst sDrewth 13:48, 18 May 2021 (UTC)

Over 3000 pages processed in the first-ever Monthly Challenge

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:

• The Picture of Dorian Gray
• The French Revolution (Volume 1) (Centenary Edition)
• The Time Machine and Fantastic Stories are proofread from Index:The Works of H G Wells Volume 1.pdf.
• Works of Jules Verne (Volume 5).

And the following validated:

• Index:Austen - Sense and Sensibility, vol. I, 1811.djvu
• Index:Orley Farm (Serial Volume 1).pdf (also completely proofread)

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

• Mrs. Dalloway by Virginia Woolf
• The Mysterious Island, Part 2 by Jules Verne
• When We Were Very Young by Author:A. A. Milne
• The First Folio is re-targeted to just The Tempest (the first play in the book)
• And many more! Over 13000 pages of fun for all the family!

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!). Inductiveload—talk/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)

Proposals

New Request for Comment on Wikilinking Policy is open

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

@Beeswaxcandle: I think 2 weeks / 72 hours is a little bit too aggressive, even for a presumed uncontroversial policy proposal like this. I understand the reasoning, but I just don't think the community is able to move that fast. For example, we have several long-time contributors that are currently in a phase where they check in only every couple of weeks. And I know for my own part that the local Covid status could easily make me too busy to check in here for weeks on end. We could still have an accelerated timeline (just not quite as accelerated as 2/72) if we notify of the proposal in an site notice and maybe even a talk page message to any established contributor that has been active in the last three months (or similar).

PS. And let me repeat my previous private kudos in public: you took my ongoing whining about the old policy and turned it into a concrete proposal for a new policy. Great work, for which I am extremely grateful! --Xover (talk) 09:25, 14 March 2021 (UTC)

Moral disclaimers for certain works

There are certain works that have a core message or consistently incorporate certain themes that most people would find offensive and morally reprehensible. I'm thinking specifically about works that were made for the purpose of promoting white supremacy. Some notable examples of these are: Thomas Dixon's The Clansmen and The Leopard's Spots; D.W. Griffith's films The Birth of a Nation (1915) and Intolerance (1916); Henry Ford's The International Jew (1920); Adolf Hitler's works; etc.

I think works such as these definitely need to be transcribed here, so that they can be viewed for historical purposes (as in, to understand what their arguments were and why they were made), and a transcription could for example make it easier for a user of our content to produce a rebuttal to said work. But the issue is that works like these are so bigoted in tone that their messages are simply indefensible, cruel, and morally reprehensible. I imagine many people who read our transcriptions of those works may get the idea that Wikisource's community, or the users who took the time and effort to work on the transcription, actually support the bigoted messages of these works, despite what Wikisource's project pages say about the project being NPOV.

So I propose that we create a disclaimer template, that we can put in the "Notes" section of the front matter page's header template. The template should say something to the effect of:

This text consistently promotes ideas that are particularly hateful or bigoted in nature. Please remember that Wikisource's community and its contributors do not necessarily endorse any opinions or ideas presented in any of its works, including this one. Works are presented as-is with no censorship involved, as transcription is done with a neutral point of view in mind, without bias for or against any particular ideology.

By the way, I think the disclaimer should only be included in works that have a consistently disreputable tone that may easily cause offense. I don't think that works such as Bobbie, General Manager or The Achievements of Luther Trant which casually dropped the n-word in a few times, but don't bring up racial issues much at all, should be given the template. However, a book focusing primarily on racial issues, taking a white supremacist stance, would qualify. PseudoSkull (talk) 19:12, 8 April 2021 (UTC)

I very much appreciate the underlying issue, but I'd be inclined not to do this. While it would have benefit for the most extreme and uncontroversial cases, such as those you list, there would be a tremendous number of works in a "grey area" where editors disagree, and/or where we lack the resources to even detect or evaluate subtle but reprehensible views.

Perhaps an alternative would be to put some careful work into a thorough essay along the lines you suggest, and link to it from somewhere prominent on the Wikisource main page. Rather than trying to attach it to every reprehensible work, simply express our position clearly in one central place.

I always think it's worthwhile to think about the precedent of traditional libraries. Would you expect to find your local library had inserted a position statement into its copy of Mein Kampf? It seems unlikely, though I could certainly see them having a general brochure available at the front desk explaining why they carry such works. -Pete (talk) 19:32, 8 April 2021 (UTC)

@PseudoSkull: Just to tie my comment a little more closely to your proposal, and focus on how things would play out in practice: How would you imagine things going if somebody strongly disagreed with you, and felt that Bobbie, General Manager was indeed reprehensible? (I have no familiarity with this particular work, just following your example.) How would we come to a decision? Would the process tend to deplete the time or emotional energy of various volunteers? Would the end result, regardless of what it is, bring much benefit to the reader? -Pete (talk) 20:12, 8 April 2021 (UTC)

Some editors have had similar discussions regarding the practice of using project disclaimers on works such as encyclopedias. I'm pretty sure no consensus was ever reached, and thus no action ever taken. In my personal opinion, a general disclaimer that covers all Wikisource works, perhaps placed prominently on the Main Page and in the footer, should suffice for both purposes. —Beleg Tâl (talk) 20:11, 10 April 2021 (UTC)

@PseudoSkull: I am not adverse to such a template being added to the corresponding talk page, and the use of "edition = yes" in the header to put the pointer. I have a preference to keep commentary out of main namespace, and keeping it as clean as possible. — billinghurst sDrewth 13:04, 9 May 2021 (UTC)

@Billinghurst: I'm fine with having the disclaimer on the work's talk page, especially since that's where readers will probably go to (inappropriately for talk pages btw) complain about the work itself. Here's a talk page that already had this issue, and had to be autoconfirm-protected, for example. PseudoSkull (talk) 18:10, 6 June 2021 (UTC)

 Comment Noting that in the footer of every page that we produced there is a link to Wikisource:General disclaimer. The text there should be reviewed and suggestions made. — billinghurst sDrewth 00:48, 9 May 2021 (UTC)

 Support making a template to tag sensitive works. How will it be coded?--Jusjih (talk) 01:21, 8 June 2021 (UTC)

Proposal: Amending autoconfirmed position at English Wikisource

I am proposing that autoconfirmed at English Wikisource be amended from 4 days and zero edits to 4 days and 10 edits

Current settings are wiki default

'wgAutoConfirmAge' => [
	'default' => 4 * 3600 * 24, ... // 4 days to pass isNewbie()
 ... 
'wgAutoConfirmCount' => [
	'default' => 0,
 ...

Other wikis that have modified time have moved that to 7, though I don't think that a time change is necessary. Other wikis that have changed their edit count have a range of 5, 10, 15, 20, 50.

I am proposing this change as at this time to give better protection to the wiki for edits on pages that have autoconfirmed settings, either through direct soft protection, or where that protection is wrapped into the title blacklists (local or global). At this point of time there are vandals exploiting this issue, and the zero edits becomes virtually ineffective.

To have a change this community needs to reach a consensus and submit a phabricator ticket to have site settings amended. — billinghurst sDrewth 08:18, 28 May 2021 (UTC)

 Support, should certainly not be zero. Edit: 10 seems fine, my support applies to anything up to and including 25. 50 seems a little on the high side. Inductiveload—talk/contribs 09:13, 28 May 2021 (UTC)

 Support, 10-20 seems like the right range to me. — Dcsohl (talk) 15:12, 28 May 2021 (UTC)

 Support, I would prefer something in the middle of the range mentioned above. Beeswaxcandle (talk) 19:47, 28 May 2021 (UTC)

 Support Tommy J. (talk) 23:50, 28 May 2021 (UTC)

 Support as proposed.

Anything in the ranges 4–7 days and 10–50 edits is fine by me. 4/10 as proposed is a good place to start, although I would personally be inclined towards 7/50 and scaling down if it turned out to be too strict. But bottom line is that I trust the proposer's judgement on this. Xover (talk) 12:30, 29 May 2021 (UTC)

 Comment if 10 is not the correct number, then suggest a number that the community can consider. Any codejunkie implementing will want to see a number to set. — billinghurst sDrewth 01:42, 29 May 2021 (UTC)

Suggesting that we can close as a consensus of the community exists for proposal, and submit a phabricator ticket that asks for a wgAutoConfirmCount = 10 — billinghurst sDrewth 14:25, 3 June 2021 (UTC)

Proposal: allow bots the reupload-shared right

This will allow bots to be used to import files from Commons using the mw:Manual:Pywikibot/imagetransfer.py 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. Inductiveload—talk/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). Inductiveload—talk/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. Inductiveload—talk/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 group

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. Inductiveload—talk/contribs 22:39, 4 June 2021 (UTC)

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

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!). Inductiveload—talk/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. Inductiveload—talk/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. Inductiveload—talk/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)

Bot approval requests

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

Repairs (and moves)

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

The Wonderful Visit

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 discussions

Policy on substantially empty works

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

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

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

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

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

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

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

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

• I believe that, if there is no scan as an Index: page, the main-namespace page should not exist unless it is being actively completed or is already mostly completed. A few pages (of the volume itself) is not very helpful, and is entirely useless if their is no scan given. TE(æ)A,ea. (talk) 15:59, 3 July 2020 (UTC).

• I think such preparatory information would ideally be on more centralized WikiProject pages (for the broad subject), both for clarity and to assist in keeping different efforts consistent -- but that it certainly should be retained as visible to non-admins. I think that the red vs blue link issue is minor (but not totally negligible) and outweighed by the disadvantages of hiding the history of previous efforts. I strongly encourage redirecting such pages to appropriate WikiProject pages (after copying over the details there). JesseW (talk) 18:11, 3 July 2020 (UTC)

• @JesseW: I agree that history shouldn't be deleted, but I think we should approach this in terms of what we want to see from these works, rather than what to do with the handful of examples at PD. There are hundreds of periodicals we could have but don't, and this applies to those as well. If we can come to a conclusion about what is and isn't wanted, we can make all the deletion requested works conform to that easily enough. Inductiveload—talk/contribs 20:55, 3 July 2020 (UTC)

• I think these pages are necessary to list index pages and external scans of multi-volume works (such as encyclopaedias and periodicals) especially if they are wholly or partly anonymous or have many authors or are simply large. I think it makes no difference whether such pages are in the mainspace, the portal space or the project space (except that it is harder to find pages outside the mainspace). The point is that these works often have so many volumes (often dozens or hundreds) that they must have their own page, and cannot be merged into a larger portal or wikiproject. If the community starts insisting on index pages, what will happen is the rapid upload of a large number of scans for the periodicals that already have their own page. Likewise if the community insists on transclusion. I also think it is reasonable to have a contents page in the mainspace, as it allows transclusion of articles. Most importantly, new restrictions should not immediately apply to existing pages that were created before the introduction of the restrictions. This is necessary to prevent a bottleneck. James500 (talk) 23:55, 3 July 2020 (UTC)

move the works to a maintenance category, and i will work them; delete them and i will not: i find your sword of Damocles demotivating. Slowking4 ⚔ Rama'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. Slowking4 ⚔ Rama's revenge 00:15, 6 July 2020 (UTC)

The entire point of moving this here, and not staying at WS:PD is to decouple from the emotions that get stirred up in a deletion discussion. Let's keep deletion out of this. If we come up with some idea of what we do and don't want, then we can go back to WS:PD and decide what to do. I imagine that all that will be needed will be a fairly limited amount of housework to bring those works up to some standard that we can decide on here, and all the collective works there will be easy keeps. Hopefully with some kind of consensus that we can point at to outline a minimum viable product for such works going forward. There are hundreds and thousands of dictionaries, encyclopedias, periodicals and newspapers that we could/will, quite reasonably, have only snippets of. How do we want to present them? What, exactly, is the minimum threshold? Let's head of all those future deletion proposals off at the pass, because deletion proposals often cause friction. Inductiveload—talk/contribs 00:47, 6 July 2020 (UTC)

and yet deletion is the default method to "motivate" quality improvement. i reject your assertion that "emotions get stirred in a deletion discussion", rather, anger is a valid response to a repeated broken process being kicked down on the volunteers. it is unclear that a minimum threshold is necessary, rather a functional quality improvement process is. until we have one, you should expect to see this periodic stirring of emotions, as the non-leaders act out. Slowking4 ⚔ Rama's revenge 11:53, 9 July 2020 (UTC)

@Slowking4: Thank you for presenting this opinion, and I'm sorry if I have not made myself clear. We do need to figure out how to avoid a de-facto process of using WS:PD as an ill-tempered ad-hoc venue for "forcing" improvements on people who have somehow managed to generate works that are so in need of improvement that another user has nominated them for deletion. Please also consider looking at #Re-purpose_WikiProject_OCR_to_WikiProject_Scans for an idea to have a "functional quality improvement process" to which such works could be referred upon discovery rather than kicking them straight to WS:PD. If you have other ideas or you have previously suggested something similar to address these frustrations, you could detail them there. Personally, I think we should always prefer improvement over deletion. Exactly what the remediation is (refer to a putative WP:Scans, WS:Scriptorium/Help, directly WS:PD as now, or something else) is not what this thread is for. This thread is for discussing, what, if anything, should be the tipping point for deeming a page "lacking" and doing something about, whatever "something" is. I don't think I can be much clearer that this is not about deletion. If we also have a better venue for improvements, then that's even better.

For example, my personal feeling and !vote on A Critical Dictionary of English Literature is "keep and improve", despite it lacking scans or even links to scans, having only one article and no other content, not even a title page: in short, failing almost every criterion suggested so far in this thread. The only thing it does have is have is good text quality of the one entry. I personally do not think this work should be deleted, but I do think it should be improved in specific ways. The first half of that sentence is not the focus of this discussion, the second half is. Inductiveload—talk/contribs 14:18, 9 July 2020 (UTC)

deletion threat has been an habitual method of communicating by admins since the beginning of the project. and text dumps have been habitual following in the guttenberg example. culture change and process change would be required to change those behaviors. we could may it easier to start scan backed works, but the wishlist was not supported. Slowking4 ⚔ Rama's revenge 21:00, 14 July 2020 (UTC)

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

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

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

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

@JesseW: It's not clear to me in your above whether when you use the term "index" you refer to a ProofreadPage-managed page in the Index: namespace, or a general wikipage in the main namespace on which an index-like structure (and/or a ToC, or similar) is manually created. Could you clarify? --Xover (talk) 05:14, 6 July 2020 (UTC)

I meant the namespace. Clarified now. JesseW (talk) 05:17, 6 July 2020 (UTC)

• Hoo-boy. Y'all sure know how to pick the difficult issues…
  My general stance is that: 1) scans and Index: (and Page:) namespace pages have no particular completion criteria to meet to merit inclusion, and can stay in whatever state indefinitely (there may be other reasons to get rid of them, but not this); and 2) the default for mainspace is that only scan-backed complete and finished works that meet a minimum standard for quality should exist there.
  That general stance must be nuanced in two main ways: 1) there must be some kind of grandfather clause for pre-existing pages; and 2) there must exist exceptions for certain kinds of works that meet certain criteria. I won't touch on the grandfather clause here much, except to say I'm generally in favour of making it minimal, maybe something like "No active effort to get rid of older works, but if they're brought to PD for other reasons they're fair game". The design of a grandfather clause for this is a whole separate discussion, and an intelligent one requires analysis of existing pages that would be affected by it. It is always preferable to migrate pages to a modern standard, so a grandfather clause is by definition a second choice option.
  Now, to the meat of the matter: the exceptions…
  We have a clear policy to start from: no excerpts. Works should either be complete as published, or they should not be in mainspace. But quite apart from the historical practices that modify this (which are somewhat subjective and inconsistent, so I'll ignore them for now), there are some fairly obvious cases that suggest a need for more nuance than a simple bright-line rule alone provides. The major ones that come to mind are: 1) massive never-completed projects like EB1911 or the New York Times (EB because it's big; NYT because new PD issues are added every year); 2) compilations or collections of stand-alone works with plausible claim to independent notability.
  For encyclopedias and encyclopedia-like things, we have to accept some subsets due to sheer scale of work. But when that is the grounds for exception, there needs to be some minimum level of completion. I'm not sure I can come up with a specific number of pages/entries or percentage, but it needs to be more than just a single entry (and, obviously, only complete entries). For this kind of exception to apply, I think it needs to be a requirement that the framing structure for it is complete: that is, the mainspace page should give a complete overview of the relevant work even if most of it is redlinks. That includes title pages and other prolegomena when relevant. For a periodical like the NYT, that means complete lists of issues with dates and other such relevant information (e,g. name changes etc.). For preference, these kinds of things should be in Portal: namespace or on a WikiProject page until actually complete, but that will not always be practical (EB1911 and NYT are examples of this). Mainspace or Portal:-space should never contain external links (i.e. to scans) or links to Index: or Page: space (except the implied link of transclusion and the "Source" tab in the MW UI provided by ProofreadPage).
  For exception claimed under independent notability there are a couple of distinct variants.
  Newspaper or magazine articles need to have a certain level of substance in addition to a specific identifiable byline (possibly anonymous or pseudonymous, and possibly identified after the fact by some other source, such as the Letters of Junius) in order to qualify. It is not enough to ipso facto be a newspaper article, a magazine article, a poem, or an encyclopedia entry. On the one hand we have things like dictionaries and thesauri, where an entry could be as little as two words. Or a one-sentence notice without byline in a newspaper. Or two rhymed lines (technically a poem) within a 1000-page scholarly monograph.
  To merit this exception it should be reasonable to argue that the "work" in question should exist as a stand-alone mainspace page (not that we generally want that; but as a test for this exception, it should be reasonable to make such an argument). This would clearly apply to moderately long entries in the EB1911 written by a known author that has their own Wikipedia article. It would apply to short stories or novella-length serialisations in literary magazines by authors that have later become famous (or "are still …"). It would apply to various longer-form journalistic material from identifiable journalists (again, rule of thumb is notable enough for enWP article), including things in magazines that have similar properties. For most periodicals the most relevant atomic (indivisable) part is the issue not the entry or article, but with some commonsense exceptions.
  It would, generally, not apply to things that are works by a single author, like a scholarly monograph that just happens to be arranged in "entries" rather than chapters. It would not apply to things that are essentially lists or tables of data. It would not apply to short entries in something encyclopedia-like or entries that are not by an identifiable author. The OED for example, iirc, is a collective work where entries are by multiple not individually identifiable authors (and each entry is mostly very short too); only the overall editor is usually cited.
  For works claiming this exception too the framing structure should be complete, even if most of it are redlinks. The same general rules about Portal:/WikiProject and no external or Index:-space links apply. An exception would be for periodicals where new issues enter the public domain every year; and we should generally avoid including even redlinks for the non-PD issues here (but may allow them in a WikiProject page). For non-periodical works in multiple volumes where some volumes were published after the PD cutoff, including listings for the non-PD volumes (but not links to scans; those are a copyvio issue) is ok.
  Poems, short stories, and novellas are a special class of works here. A lot of these were first published in a magazine (possibly serialized), and a lot of them exist as multiple editions in substantially the same form. Some exist in multiple versions. These should all primarily exist the same way as chapters as part of their various containing works; but there are some cases where we might want to have, for example, a series of connected pages of the poems of Emily Dickinson. I am significantly ambivalent about this practice, as it amounts to making our own "edition" or "collection" of her poems (in violation of several of our other policies), but I acknowledge that it is an established practice and it is something that has definite value to our readers. It may be that it is actually a practice that should be governed by its own dedicated policy rather be attempted to be handled within these other general policies.
  For the sake of example; applying this to the works Inductiveload listed at the start of this thread would shake out something like this:
  • Auction Prices of Books—This work appears to have no sensible subdivisions and is in any case by a single author. I see no obvious reason to grant this work an exception, except under sheer volume of work and even there I would want to see both a substantial proportion completed and some kind of ongoing effort towards completion (no particular time frame, but definitely not infinite and definitely not as an effectively abandoned project). In a deletion discussion I would very likely vote to delete the mainspace pages here (but, as nearly always, to keep the Index: and Page: namespace artifacts). I don't see this as a reasonable candidate for a Portal:, nor really a good fit for a WikiProject (though I probably wouldn't object to a WikiProject if someone really wanted one).
  • Central Law Journal/Volume 1—A single volume is too little, so I would want to see a complete structure for the entire Central Law Journal, with level of detail for each volume similar to the one existing volume. Each article in the journal can be individually considered for a stand-alone work exception; but for the collection I would want to see at minimum a full issue finished to justify having the mainspace structure, and preferably multiple issues (in a deletion discussion I might insist on multiple issues). Index: and Page:-space artefacts can, of course, stay. A Portal: might make sense for selections from the journal, of articles that meet the standalone work exception. A WikiProject to coordinate work and track links to scans etc. might be a decent fit here, if someone wanted that. As it currently stands I would probably vote delete for the mainspace artefacts (with option to move whatever content has reuse value to a non-mainspace page for preservation; and undeleting if someone wants to work on something is a low bar).
  • A Critical Dictionary of English Literature—The top level mainspace page has near-zero value, existing only to link to the single transcribed entry. For a credible claim to exception to exist it would need to be a complete framework for the work as a whole, and significantly more than a single entry must be complete. I would probably also want to see ongoing work, unless a substantial percentage of the entries were complete. The single finished entry is eligible to claim a standalone work exception, but I think it probably would not meet my bar for that (I might be wrong; and the rest of the community might judge it differently). In a deletion discussion I would probably vote to delete all the mainspace artifacts here (as always keeping Index:/Page: stuff) but with a definite possibility that I might be persuaded on the one completed entry (an absolute requirement for convincing me would be to scan-back it: as a separate issue, my tolerance for grandfathering of non-scan-backed works is small, and effectively zero for new/non-grandfathered works).
  • Bradshaw's Monthly Railway Guide—Would need a full framework and a number of individual issues finished to merit a mainspace page. I see no credible subdivisions for a standalone work exception, but might be persuaded otherwise if, say, one of the train tables was used as a (reliable primary) source in a Wikipedia article (implying some sort of notability beyond just being raw data). In a deletion discussion I would probably vote to delete all mainspace artifacts here. If anyone made the argument, I would entertain the notion that there is value in treating train tables like poems, and hosting a series of train tables like we do Dickinson's poems; but that would require a substantial number of them completed.
  For everything above my stance is nuanced by a willingness to accept temporary exceptions for things that are actively being worked: active being operative, but with no particular deadline to complete the work. We have differing amounts of time available, and some works are so labour-intensive or tedious to do, that my person threshold for "active" is a pretty low bar to clear. If it's months and years between every time you dip in and do a bit I might start to get antsy, but days or weeks probably won't faze me. And that the projected time to completion is very long at that pace is not particularly a problem so long as it is not infinite. Within those parameters I would always tend to err on the side of letting contributors just get on with it in peace, regardless of any of the policy-like rules sketched above.
  I also want to emphasise that I think this is a very difficult issue to deal with. There are a lot of competing concerns, and a lot of grey areas that will likely take individual discussions to resolve. My balance point on this issue is partly formed by a broader concern about our overall quality (we have waay too many works of plain sub-par quality, and too many not up to modern standards) and a hope that by preventing the creation of these kinds of works (rather than deleting them after creation) we will be able to retain the good and desirable exceptions without dragging down quality, and without the traumatic and stressful events that deletions and proposed deletion discussions are.
  And for that very reason I am grateful this issue was brought up here for discussion, and I hope we can end up with some clear guidance, possibly in the form of a policy page, going forward. And in any case, since it will create de facto policy, this is a discussion that needs to stay open for a good long while (there are several community members that have not yet commented whose opinion I would wish to hear before closing this), and depending on how well we manage to structure the consensus, may also require a formal vote (up in the #Proposals section). --Xover (talk) 09:03, 6 July 2020 (UTC)
•  Oppose. It is becoming clear that a policy on incomplete works in the mainspace is going to place enormous pressure on individual editors. I think it would be more effective to start a wikiproject devoted to scan-backing works that lack scans and so on. James500 (talk) 12:14, 6 July 2020 (UTC)
  • @James500: FYI, this thread was made in order to provide an exception to the current policy of "no excerpts". A literal reading of the policy as it stands has a plausible chance of coming down delete on the mainspace pages over at WS:PD. This thread is a chance to come up with a better way to support such partial collective works. That we have several substantially incomplete and abandoned collective works lolling around in mainspace is actually the result of laxity in respect to stated policy (not to say I think it's a bad thing). The deletion proposals, whatever you may think of them, are actually not in contradiction to policy. That said, as always, there is scope to adjust policy. Which is what this is.
  • Now, in terms of a WikiProject to scan back works, I think that is a good idea. See #Re-purpose_WikiProject_OCR_to_WikiProject_Scans above, which proposed to reboot Wikiproject OCR as a scan-backing Wikiproject. Inductiveload—talk/contribs 14:40, 6 July 2020 (UTC)
    • The policy says "When an entire work is available as a djvu file on commons and an Index page is created here, works are considered in process not excerpts." A literal reading of that policy is that no scan-backed work is an excerpt (it is expected to be completed eventually). Further the policy refers to "Random or selected sections of a larger work". A literal reading of that expression is that it does not include lists of scans, or auxilliary content tables, as they are not "sections" (they are not part of the work), and that not every incomplete portion of a work is either "random or selected" (which would not include starting from the beginning and getting as far as you can, with intent to finish later). I could probably argue that an encyclopedia article or periodical article is a complete work. James500 (talk) 15:16, 6 July 2020 (UTC)
• Nice wall of text, Xover (and I say that with great respect!) -- it generally makes sense and sounds good to me. As another hopefully illustrative example, take The Works of Voltaire, which I've been digging thru lately. I think this would very much satisfy your criteria as a large work, with sufficient scaffolding to justify the mainspace pages that exist for it. I would love to hear others thoughts on that. JesseW (talk) 16:07, 6 July 2020 (UTC)

  @JesseW: Yeah, apologies for the length. Brevity is just not my strong suit.

  The Works of Voltaire probably qualifies on sheer scale of work, yes. I don't think the current wikipage at The Works of Voltaire is quite it though: as it currently stands it is more WikiProject than something that should sit in mainspace (its contents are for Wikisource contributors, to organise our effort, not our readers, who want to read finished transcriptions). It also mixes a work page with a versions page in a confusing way. So I would probably say… Move the current page to Wikisource:WikiProject Voltaire; create a new The Works of Voltaire as a pure versions page, linking to…; The Works of Voltaire (1906), that is set up as a work page with the cover and title (and other relevant front matter) of the first volume, and an AuxTOC (and possibly also the {{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. Inductiveload—talk/contribs 17:35, 6 July 2020 (UTC)

• @Xover: I am in agreement with the majority of what you say. Particularly, I think a framework around any collective work (be it a single-volume biographical dictionary or a 400-issue literary review spanning 80 years) is the critical prerequisite, plus at least some scans, the more the merrier. Where I think I differ:
  • I am inclined to be a bit more relaxed in terms of how much of a work we need. As long as a single article exists, it's not "trivial" (e.g. only a short advert or some incidental text like a "note to correspondents", as opposed to an actual article), it's well-formatted and scan-backed, and a complete framework exists, including front matter and a TOC, such that's it is easy for anyone to slot in new pieces, I'd be fairly happy. Lots of periodicals have all sort of tricky bits like tables of stocks or weather tables and writing into policy that those must be proofread in order to get the "real" articles into mainspace would be a chilling effect, in my opinion. If you allowed an exception, it would be verbose and tricky to capture the spirit without saying "unless, like, it's totally, like, hard, man".
  • I am not dead against scan links in the mainspace at the top level, when such a top-level page exists. See my comments on Voltaire above. I am against them where they could sensibly be on an Author page and they are the only mainspace content.
  • I am ambivalent on the presence of, e.g., disjointed train timetables. It's not my thing to have a smattering of random timetables, but as long as they're individually presented nicely, it's not too offensive to my sensibilities. I might question the sanity of someone who loves doing tables that much, but whatever floats the boats! Also, I think that this might circle back to "good for export" - a mark which certainly would require completed issues or volumes. If you want to get that box ticked, you have to do it all.
  • Re the "notability" aspect of individual articles, I'm not really bothered by that, as I don't think we'll see a flood of total dross because few people really want to take the time to transcribe 1867 articles about cats in a tree from the Nowhere, Arizona Daily Reporter, and, actually I think some of the "dross" can be quite interesting in a slice-of-life kind of a way (always assuming well-formed and scan-backed). And the real dross is usually so bad (no scans, raw OCR, etc) that it can be dealt with outside of this topic. I think part of the value of WS is the tiny, weird and wonderful, not just in blockbusters like War and Peace and Pultizers. I think I might like to see more of our articles strung together thematically via Portals, but that's another day's issue. Inductiveload—talk/contribs 17:35, 6 July 2020 (UTC)
    • @Inductiveload: We appear to be mostly in agreement. But… instead of me dropping another wall of text on the remaining points of disagreement, maybe that means we're in a position to try to hash out a draft guidance / policy type page with the rough framework? Then we could go at the remaining issues point by point. Because I think I'm in with a decent chance to persuade you to my point of view on at least some of them, but this thread is fast getting unwieldy (mostly my fault). It would also probably be easier for the community to relate to now, and much easier to lean on in the future. --Xover (talk) 18:31, 6 July 2020 (UTC)
      • @Xover: If there are no more comments forthcoming after a couple of days, I think that makes sense. I don't want to railroad it: considering we have at least one !vote for "do nothing", I'd like to see if there are any other substantially different opinions floating about. Inductiveload—talk/contribs 17:41, 7 July 2020 (UTC)

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

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

Apologies, I see I had missed the point.

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

I'm really bad with walls of text, so I have only read a tiny portion of the above discussion. But I want to mention a couple of things that I think are worth considering in this discussion.

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

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

Proposal

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

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

The example given in Wikisource:Periodical guidelines might be improved, PSM is and was an exercise that has gone its own way (no offense to @Ineuw:, this is a site under development and that is only one example).CYGNIS INSIGNIS 13:05, 17 April 2021 (UTC)

@Cygnis insignis: You would be wrong to think that I am offended. Remember that when I started, I knew everything. By now, so much of that knowledge is lost that I am happy to listen. Would you elaborate please? — Ineuw (talk) 19:50, 17 April 2021 (UTC)

---

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

Translations and Reprints from the Original Sources of European History

Today I happened to come across the work Translations and Reprints from the Original Sources of European History, published by the University of Pennsylvania's History department from about 1897-1907. As far as I can tell, archive.org has full or nearly full coverage of the series, which has several volumes. I was originally looking for a PD English Translation of "fr:Qu’est-ce que le tiers état ?" by Author:Emmanuel Joseph Sieyès which is available in full on the French Wikisource but not yet validated, and I happened across this series, where excerpts of that text appear in the 6th volume. I guess my question is, would this source be something that others would be interested in having all volumes up on commons and a central page here with a table of contents? It seems quite wide-reaching and may help us expand English-language coverage of minor texts from European authors. I'm just curious if this is a work people think would be useful. Mathmitch7 (talk) 14:40, 29 April 2021 (UTC)

@Mathmitch7: I generally think it's a very good thing to set up this kind of collective work "on spec", because the set-up is quite a lot of faffing about for many users, but dipping in to proofread an article or two is easy once that groundwork is laid. But make sure it's well linked from authors pages and perhaps Portals so it can be found. If it can't be found, no-one will come, even if you build it.

In theory, if you don't proofread any articles, it can't have a mainspace page, however. C.f. Wikisource:Scriptorium/Archives/2021-02#No-content_mainspace_pages for a long but fizzled discussion to try to determine best practices for that. Inductiveload—talk/contribs 14:56, 29 April 2021 (UTC)

I would be interested in doing some of that, though probably very little overall, however, I have a preference and see no harm in having sections of the volumes with red-linked parent titles that follow this sister's convention of series/vol/sect, eg, I care for about 10% or less of The Emu, linking the 'parent titles' from The Emu/volume 3/Extinct Tasmanian Emu would be, as someone here said, "guaranteed to engender disappointment". CYGNIS INSIGNIS 15:29, 29 April 2021 (UTC)

@Mathmitch7: That looks like an amazing find. I’m sure some of those translations are still probably the only ones ever made. I took a quick look and there appears to be a new series as well. Languageseeker (talk) 19:22, 29 April 2021 (UTC)

Alright, so I've now uploaded one scan of each volume available on the internet archive of this series, you can find them at commons:Category:Translations and Reprints from the Original Sources of European History (UPenn series). I'll try to get them up to wikisource soonish, but I have some other things I have to do today. I'll note that the "new series" mentioned (which I also uploaded) are more monographs than big edited volumes, but I think they will still be helpful. Also, I was unable to find a version of Volume 5 readily available -- there's a version on archive.org but as it's a reprint from the 1971 it's not fully available for download, so that's something to look for in the future. Mathmitch7 (talk) 13:29, 10 May 2021 (UTC)

Tech News: 2021-19

Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.

Changes later this week

• The new version of MediaWiki will be on test wikis and MediaWiki.org from 11 May. It will be on non-Wikipedia wikis and some Wikipedias from 12 May. It will be on all wikis from 13 May (calendar).

Future changes

• You can see what participants plan to work on at the online Wikimedia hackathon 22–23 May.

Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.

15:10, 10 May 2021 (UTC)

Lower case naming of book by myself

Index:Some feudal coats of arms.djvu - I think I should have used caps when creating this and I don't know how to fix it. It's because I saw it in lowercase in the WorldCat books catalog, but also the name is sooooo long. I think it should just be Some Feudal Coats of Arms. Can someone fix it. I'm sorry. --The Eloquent Peasant (talk) 21:43, 10 May 2021 (UTC)

@The Eloquent Peasant: the name of the file (and therefore the index page) isn't really important as long as its not actively misleading. Just update the link to mainspace to be Some Feudal Coats of Arms. No need up be sorry :) Inductiveload—talk/contribs 22:00, 10 May 2021 (UTC)

Thank you! --The Eloquent Peasant (talk) 23:08, 10 May 2021 (UTC)

@The Eloquent Peasant: and the thing is that the standards used by cataloguers change so both are right at different times. So for us both forms are right, just ensure that you create redirects between the forms. In the end, as Inductiveload said, as long as it can be found as an accurate title, then no issues. We rile about the use of all capitals as that is just butt ugly. — billinghurst sDrewth 00:04, 11 May 2021 (UTC)

I have 1 GF. My husband says shouldn't come around 'cause she's butt ugly - ... but I like her and besides, while he's not lying, it's mean to say she is. She's a great person oh except she likes to drink too much. So for that reason, I keep her at bay and also because she lives 4540.9 miles away. All caps is crazy for a book name and all this makes me realize I should have more than just 1 GF. :) Thank you. :) --The Eloquent Peasant (talk) 00:10, 11 May 2021 (UTC)

I have .png and .jpg images for the book and have uploaded both (38 files) as .jpgs and as .png files but now I don't know which one would end up being used in the book here on Wikisource. I cropped and reuploaded one .jpg but the book has tons of images. Which is preferable here, .jpg or .png? See here: [[c:Category:Some feudal coats of arms (Book) The .pngs are a little big. Thank you. --The Eloquent Peasant (talk) 01:57, 11 May 2021 (UTC)

@The Eloquent Peasant: If you are talking page illustrations, we are file type agnostic and more interested in the output. Probably the best guidance of which is better in which situation is c:Commons:File types, and as while their primary use is the transcluded work here, their re-use anywhere should be more in your thinking. — billinghurst sDrewth 02:27, 11 May 2021 (UTC)

@Billinghurst: ok. --The Eloquent Peasant (talk) 02:29, 11 May 2021 (UTC)

@The Eloquent Peasant: in this case, since the images come from a source that is already compressed with a JPEG-like compression scheme (the IA usually uses JP2, but the idea is similar) there is not a lot of value in PNG. This is because PNG expends a lot of file size on slavishly recording all the pseudo-random noise produced by the JP2 compression, which is pretty much incompressible under the PNG format.

However, if you were to extract the images and clean then up so that they are black-on-white diagrams and the image noise is removed, then PNG would be a good choice. This is because the sharp edges between colours (i.e. black and white) represents "high-frequency" image data, which produces substantial image noise when compressed lossily as JPG. For example, below is the image noise (coloured red) that is introduced when a diagram is saved as a JPG:

Also, since the colors are limited in a greyscale, you may find that a greyscale PNG of a cleaned diagram is roughly comparable to a JPG anyway (YMMV, there are too many variables to make a global statement here).

tl;dr rule of thumb: JPG for photos and things that are already JPGs, PNG for "clean" diagrams. Inductiveload—talk/contribs 07:18, 11 May 2021 (UTC)

@Inductiveload: TY. I'll try to upload vivid, clean files and name all the files so it's easy to know what page they belong to (for eventual use in WS). I found a better scan of this book where the pages don't look yellow. --The Eloquent Peasant (talk) 15:03, 11 May 2021 (UTC)

@The Eloquent Peasant: note that often the yellowish files are actually a better starting point for your own extraction of the image than the black/while ones. The black/white ones are generally automatically processed fairly brutally to remove the paper colour and then recompressed heavily and this often produces a fairly rough image that might look cleaner from a distance, but on closer inspection will be found to have lost a lot of detail. H:EXTRACT has some details (but still needs a lot of expansion). Inductiveload—talk/contribs 15:58, 12 May 2021 (UTC)

@Inductiveload:That's exactly what I just surmised! I'm starting with the yellow .pdf pages and from there will clean up the files. The .jpgs that were extracted sometimes have entire sections of the image missing. I appreciate the guidance. I'll end up with .pngs and a smaller pixels size and blackish and whitish images that may not be perfect, but good enough! :) --The Eloquent Peasant (talk) 16:10, 12 May 2021 (UTC)

@The Eloquent Peasant: Just checking that you are aware that you can get the best quality individual file images easily from IA. If you look at something like https://archive.org/download/macliseportraitg00macl_0 click and open the VIEW CONTENTS and each page in the work is available right there for download. Usually far better than any manipulated PDF. — billinghurst sDrewth 02:24, 13 May 2021 (UTC)

@Billinghurst: I did spend quite a bit of time at that place and I searched through the different files. I downloaded what I thought would have the images, .jp2 for example but couldn't open. I did try there, but had no luck - not sure why. --The Eloquent Peasant (talk) 02:28, 13 May 2021 (UTC)

I downloaded GIMP for handling JP2000 images, and Inductiveload has some importable filters in his subpages. Though I will note that I am pretty rubbish in graphics tools, beyond the absolute basics. — billinghurst sDrewth 02:30, 13 May 2021 (UTC)

I do have the files in .png format and it's easy to work with them. The difficulty will be on pages with 12-17 images since each will have to be cropped, saved and uploaded. the worst part about is that the book doesn't give them good captions like "Fig. #" so I'll have to name them like Pg 27 img 1, Pg 27 img 2 etc. In total its about 2000 images or so the author states. So, I have pretty good organization skills but I'll soon be a little bogged down with real life. I almost downloaded GIMP. -The Eloquent Peasant (talk) 03:09, 13 May 2021 (UTC)

@The Eloquent Peasant: I finally wrote up a guide to how I use GIMP to do this: Help:Image extraction/With GIMP. Your images are much cleaner that the example, but the process is the same.

Also, the GIMP script Billinghurst refers is User:Inductiveload/Remove-background-colour.scm, which I think will work well for these images: they have nice even, light paper colours and dark ink. If the script works, it's a one-click solution. It doesn't always work, though. Inductiveload—talk/contribs 03:26, 13 May 2021 (UTC)

Okay. I'll download and try GIMP and (the importable filter). If it works for me, "Some feudal coats of arms" project may be in better shape sooner rather than later. --The Eloquent Peasant (talk) 12:18, 13 May 2021 (UTC)

@Inductiveload: Just an FYI, I like how this one turned out. (Rather than try learn that program we talked about (which reminds me of Pulp Fiction), I've decided to just use my Photoshop)... In Photo Shop, The "Artistic" / "Poster Edge" filter worked well on the last one I tried. What do you think? I like it because it's sharp, compared to the other ones I did. I'm not an expert on images, and I hate to practice on the little guys but, in essence, that's just what I'm doing. --The Eloquent Peasant (talk) 20:22, 14 May 2021 (UTC)

But also, the filter that works on one image, will not work as well on another., yet they should look consistent from one page to the next.... I think the best use of my time is get the images to look pretty good, upload them and map them to the pages... and it's a collaborative work so someone might improve the images in the future. Have a nice weekend! --The Eloquent Peasant (talk) 20:51, 14 May 2021 (UTC)

@Billinghurst: Thank you again. What you do here is really amazing! Anyway this "Some coats of arms" Project is too difficult for me but I'll cleanup, and upload images to Commons and create shell pages in WS. The text review by the Optical Character Recognition software doesn't work on that book at all. Thanks again and take care! --The Eloquent Peasant (talk) 21:27, 14 May 2021 (UTC)

Title for a Copyright Office letter

I have at User:BD2412/Affirmance of Refusal for Registration (Prancer DNA Sequence) an untitled letter from the Copyright Office to a copyright applicant. The letter indicates who it is from and to, and has a correspondence ID, but I'm not sure how to title it for the move to mainspace. Wikisource:Style guide appears to offer no guidance on this. BD2412 T 04:33, 11 May 2021 (UTC)

Not sure either, I don't know enough about patents and their form of letters. Does it have a common usage name? I think that there should some indication of the target to of the letter, and something to indicate the source, or a date. As this presumably sits in a series of letters, I think some consideration to how such letters look in a series, for the work itself, and also how the authority acts, as we are setting some indicators for future works. Consider some redirects too if part of a series. — billinghurst sDrewth 00:17, 12 May 2021 (UTC)

I suppose if it were in a citation the title would be Copyright Office letter from Robert J. Kasunic to Howard Simon affirming refusal to register the "Prancer DNA Sequence" (February 11, 2014). BD2412 T 15:30, 12 May 2021 (UTC)

That may be a tad long. If we have multiples of these in the series; or had others from the Office to another, how& what is suitably unique and distinguishing? — billinghurst sDrewth 01:36, 13 May 2021 (UTC)

I suppose Copyright Office letter affirming refusal to register the "Prancer DNA Sequence" would be sufficiently unique and identifying. I don't have any other documents in this area, but this one is of particular interest in modern times, given that the determination that copyright does not extend to DNA sequences means that you can't copyright the mRNA vaccine sequence. BD2412 T 07:22, 14 May 2021 (UTC)

Wikidata integration

Please see d:Wikidata talk:WikiProject Source MetaData#Wikisource integration project, requesting assistance for documentation + implementation. It reminded me of our recent discussion at Wikisource:Scriptorium#Google often unable to find works at Wikisource. Whatamidoing (WMF) (talk) 15:34, 11 May 2021 (UTC)

Introducing {{Annotate QID}}

For some time I have been noting the Wikidata IDs of people mentioned in works I'm transcribing, who have no author, portal or Wikipedia link, using HTML comments, thus: John Moss <!-- Q27478536 -->

I mentioned on Twitter today that I wanted a template for this, so that the terms are more clearly and semantically tagged, and User:Mfchris84 kindly implemented the idea. I have imported it as Template:Annotate QID (shortcut: {{aqid}}), used thus: {{aqid|Q27478536|John Moss}}.

The name John Moss in this sentence is an example of its use.

It is therefore now possible to write a Wikidata query to interrogate a work on Wikisource, and produce (or process) a list of people or things mentioned in it. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:47, 11 May 2021 (UTC)

There's also {{wdl}} which will link to, in order of preference, the first found of: an author/portal, a Wikipedia page, a Commons category and finally to Wikidata (via Reasonator) for a given Q-ID. Inductiveload—talk/contribs 19:31, 11 May 2021 (UTC)

 Question For both of these usages we need to explore how they work in linking policy, and annotation policy, and improve our guidance accordingly. What is the ultimate outcome? How does it improve our site? Where do we expect it used? How much do we expect it used? Both within a work, and withina page? What are our limitations in its usage? Once per page? per chapter per work? When do we annotate vs when or link? [We have a lot of non-fiction works] Also how do both work in the export realm? — billinghurst sDrewth 00:22, 12 May 2021 (UTC)

Wikisource:Requests for comment/Wikilinking policy mentioned it. Where does that stand? @Beeswaxcandle:?

WRT to export, they're "just" links, so they export as links. From an ebook, there is no difference between link to Wikisource and a link to Wikipedia or Wikidata other than the URL - both would prompt the user "do you want to visit this location". Depending on the reader that might or might not work (for a start, it needs network access which not all readers have).

Another issue is that nearly all reader devices have no concept of "hover", so using the title attribute for anything is going to be functionally invisible in the end result. This problem also affects {{SIC}}, {{tooltip}} and friends. Inductiveload—talk/contribs 15:45, 12 May 2021 (UTC)

@Inductiveload: The new version of the policy should be ready for release next week. Still juggling the various thoughts and coming to a conclusion. Beeswaxcandle (talk) 07:48, 13 May 2021 (UTC)

Not concerned about tooltips generated. SIC as it is, is just meant to be an indicator to the reader who may edit there and then. It is meant to be non-vital information, so never been an issue to not export. — billinghurst sDrewth 01:41, 13 May 2021 (UTC)

Should any template like "Annotate QID" have "tooltip" as an underlying component if we are using it to annotate? Even if we have to fiddle with tootip itself. — billinghurst sDrewth 01:43, 13 May 2021 (UTC)

"by nationality" categories

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

Here is what we have

• Category:Authors by nationality
• Category:Diplomats by nationality
• Category:Biographies of people by nationality
• Category:Poets by nationality
• Category:Philosophers by nationality
• Category:Scientists by nationality by field
• Category:People by occupation by nationality
• Category:Explorers by nationality
• Category:Politicians by nationality
• Category:Scientists by nationality
• Category:Soldiers by nationality
• Category:Songwriters by nationality
• Category:Civil servants by nationality

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)

Use of notes= for annotations

Is there community concensus for this edit? I always thought notes= is the right place for annotations. Hesperian 04:38, 12 May 2021 (UTC)

That does indeed look like an appropriate use of the notes field to me. Xover (talk) 04:48, 12 May 2021 (UTC)

Always has, always will be. How else have we ever added {{wikipediaref}} statements in situ. I have reversed their edit. — billinghurst sDrewth 09:59, 12 May 2021 (UTC)

Removed the "proposals" hatnote from Wikisource:Annotations

The document has been long in place and been pointed to and treated as de facto policy for an extended period, and not been targeted to be removed. So I have removed {{proposal}} which allows it to be a clear guiding document. If there is any dissent, then please revert that edit, and tell us what is clearly problematic with the document and how it should be otherwise actioned. Thanks. — billinghurst sDrewth 10:04, 12 May 2021 (UTC)

Thanks a lot, billinghurst, you have asked if I have an other point of view to add to this discussion. Well, my point of view is: Wikisource:Annotations is exactly what I would have liked to write myself!

I am translating it now into French in order to complete it with French wikisorcerers' additions, if any, to the French Wikisource corresponding page, and will tell you of the result.

Many thanks and many regards here,

--Zyephyrus (talk) 19:58, 14 May 2021 (UTC)

Then I am confused Zyephyrus. If you think that it is okay, why shouldn't we remove the proposal tag, and accept it as our current official guidance? — billinghurst sDrewth 00:54, 16 May 2021 (UTC)

FYI: Wikisource-bot has stopped archiving

A note to those who watch for archiving around the place. The bot stopped working April 30th, and I am seeking assistance to get the script investigated and the issue resolved. Bear with us. — billinghurst sDrewth 06:08, 13 May 2021 (UTC)

resolved — billinghurst sDrewth 11:03, 13 May 2021 (UTC)

RfC: Nomenclature for categorisation of person portal pages

Back to the people categorisation nomenclature ...

Background

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

• Wikisource:Scriptorium/Archives/2020-05#Time to talk nomenclature of author classification by occupation
• Wikisource:Scriptorium/Archives/2020-09#Nomenclature of occupations

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)

Woman in Art

This book is listed with a year of 1900. I knew this to be incorrect, as I have observed numerous later (pre 1926) dates being mentioned in the text while proofing it. Now on page 175 I see the date 1927 mentioned. Is this work now a copyright violation, and if so does it need to be withdrawn from the site? If so can the work I have already done be archived until it becomes out of copyright? Thanks Sp1nd01 (talk) 21:46, 13 May 2021 (UTC)

@Sp1nd01: there's no date, publisher or location mentioned (WorldCat agrees). This copy was signed by the author in 1930, so that puts it c. 1927–1930. And since Armstrong was American and presumably this is an American book (also considering the WorldCat holdings are all in the US), and there's no copyright notices, I think it would be covered by {{PD-US-no-notice}}. Inductiveload—talk/contribs 21:57, 13 May 2021 (UTC)

Great, thank you for checking it out! I'll continue working on it unless told otherwise. Sp1nd01 (talk) 22:15, 13 May 2021 (UTC)

yeah, the place to raise copyright is on commons, licensed as PD US no notice [1] - there are no easy formulas about copyright. berne might think so, but CC is blowing a hole in it. Slowking4 亞 Farmbrough's revenge 00:51, 19 May 2021 (UTC)

Template:author link and shortcut => substitution

I am asking that we reconsider how we use Template:Author link and its shortcut {{al}}. The template makes disambiguation (automatic / semi-automatic / tools) more difficult so I would like for us to consider either making it a requirement to substitute it or we have a process to go through and substitute it by bot. — billinghurst sDrewth 01:04, 14 May 2021 (UTC)

I've never been quite sure what itch this template scratches. Simply a typing aid? Inductiveload—talk/contribs 08:25, 18 May 2021 (UTC)

Yeah. You could of course hang lots of extra stuff onto it ({{wdl}}-like or microformats etc.), but so far as I know it serves no other purpose than convenience. On the flip side, it does generate a WhatLinksHere-listed wikilink, so I'm not sure I buy that it significantly complicates automated tools. It will generally be easier to deal with than plain wikilinks because it has more limited allowable syntax. Xover (talk) 08:35, 18 May 2021 (UTC)

Well, w:Wikipedia:Tools/Navigation popups doesn't work on it, it doesn't handle the template. Most of the existing disambiguation tools/scripts seem to be looking for square brackets. In AWB it adds more complexity to all disambiguation code as you never know whether it is one or two parameters, so never know whether to code for a pipe or curly bracket, and with possible long lines the regex can run for ages for the next of the type. If it was limited to author or portal namespace it wouldn't be as problematic but page ns is a nightmare. So I would much prefer that if we need WDL type, that we wrap them, not embed the code. — billinghurst sDrewth 15:57, 18 May 2021 (UTC)

@Inductiveload: I am guessing that it is lack of toolbar button, the convenience of "al" in combination of not knowing of the "w:Help:pipe trick". For me having a toolbar button for [[author:+|]], and wrapping [[author:Charles Dickens|]] outputs [[author:Charles Dickens|Charles Dickens]] makes it easier for me than any typing of curly brackets, letters and pipes. — billinghurst sDrewth 16:06, 18 May 2021 (UTC)

Old English texts: potential for a project?

I've been looking at the English literature portal and it looks like there could be a project to input pre-1926 editions of Old English works on Wikisource. There ought to be a Portal for OE literature which can list all the texts already uploaded; then, the aim of the project would be to input at least one edition for each text. Lists of texts of the OE corpora can be found in the respective poetry and prose category templates on Wikipedia. A lot of these are available in HathiTrust, but there is no one readable (as opposed to purely searchable) corpus of Old English works

The Category 'Old English works' is also a hodge-podge of editorial anthologies, translations into 'revived' Old English (which don't seem to be indicated as such as to distinguish them from real historical documents) and unsourced, contextless poems. So another aim of the project would be to reorder the portal along the lines of the Wikipedia template (i.e. organised on a thematic, historical or Manuscript basis).

Thoughts? —unsigned comment by Rho9998 (talk) .

@Rho9998: Wikisource:WikiProjects are able to be started by anyone; they are coordinating hubs for people of like interests. Help:Portal will guide you on portals, and they are generally aligned with a subject, so no issue from my PoV. For us categories are generally less populated than elsewhere, so we tend to not drill down too far until truly required—lots of near empty categories aren't useful. I would rather see 1 category of 40 items, than 20 categories of 2 items. Also noting that Category:Bright's Anglo-Saxon Reader additions is not usual for us, we tend to only categorise the root page in such a circumstance. A WikiProject is a great space to discuss and coordinate categorisation for such a subject. — billinghurst sDrewth 06:45, 17 May 2021 (UTC)

@Rho9998: I think an Old English Wikiproject is a great idea. The Old English section of Portal:English language certainly needs expanding, and if it expands over, say, 10 items, or gets thematic or other divisions, Portal:Old English should probably be created (containing both literature and language unless those need further splitting, which I think is unlikely for now). It's certainly odd that we have Portal:Old Norse literature but nothing at Portal:Old English!

I have no domain knowledge of Old (or Middle) English, so I can't do much other than provide moral and technical support, so you'll have to do the subject legwork (or find someone who does know their thorn from their wynn to help!)

If you choose a fairly "easy" text (one that doesn't need too much esoteric formatting or detailed domain knowledge of Old English, and is fairly short), it could also be a candidate for the Wikisource:Monthly Challenge.

If you would like a text or two from Hathi, let me know. If you want a lot of texts from Hathi, that's OK too, but I'd like some information from you in that case. Inductiveload—talk/contribs 09:07, 17 May 2021 (UTC)

@Billinghurst: @Inductiveload: I've made a draft of Portal:Old English on my user page; there's more texts in Category:Old English works than there are in Portal:English literature, so I think that it meets the criteria. As regards monthly challenge, I'm sure most of the texts will be easy enough to copy if anyone knows some way of shortcutting ash (æ), thorn (þ) and eth (ð) in the editor. Most editions put wynn (ƿ) as 'w' anyway, so no problem there. If I were inputting I'd also not copy the macrons as (1) this is difficult to input and (2) they were not used in the Anglo-Saxon era anyways. Personally, I wouldn't see a problem omitting the macrons consistently (and perhaps accompanying this with a note at the start of the Wikisource version), but then I'm not fully versed in copying best practices. I also have access to Hathi, but I'm not familiar with adding the scans and also even if the book is in the public domain, I'm sure Hathi still reserve copyright on the scan itself, except for those texts accessible without login? Finally you're right to say I'd need the involvement of others who know a bit about OE literature, regardless of whether non-specialists can also participate in the project, to discuss decisions like omitting the macrons. Rho9998 (talk) 12:13, 17 May 2021 (UTC)

@Rho9998: The draft looks pretty good in general. I'd just put it in place and it can tweaked in situ.

This is the kick up the backside I need to add an Old/Middle English section to the Wikieditor toolbar (some of the characters are in the Latin section, but they're all mixed up). I'll get back to you about that, but in the meantime if you can make me a list of all the characters you might need and drop it on my talk page, that would be great.

Re macrons: in general we'll be proofreading from a scan of something. If that uses macrons, so do we. If if does not, we do not.

Re Hathi copyright: even if the claim copyright, they don't actually have copyright. At least in the US where w:sweat of the brow doesn't hold, and that is what matters at English Wikisource. Commons concurs on that, so there's no problem uploading Hathi documents to there, as long as they are out of copyright in the country of origin and the US. If only in the US, they come here until they can be moved to Commons.

If you can find the same scan on the Internet Archive, that's usually better because it's much much easier to import scans from there anyway. Inductiveload—talk/contribs 12:24, 17 May 2021 (UTC)

Tolstoy (Wiener)...

We seem to have 2 incomplete sets:-

• Template:The complete works of Count Tolstoy volumes (As PDF)
• Template:Works of Tolstoy (Wiener) (As DJVU)

Can someone make a decision and upload one complete set in a consistent format? Thanks :) ShakespeareFan00 (talk) 10:01, 17 May 2021 (UTC)

I tried to make a complete set of PDFs, but Beeswaxcandle deleted the duplicate PDFs. Languageseeker (talk) 20:06, 17 May 2021 (UTC)

Are they complete between the two sets? If so, then sort the templates so there is one that points to both sets. The pdf versions that I deleted were the more recent upload. And minimal or no work had been done on them, while there had been some work on the DjVu versions. Beeswaxcandle (talk) 05:50, 18 May 2021 (UTC)

FYI, I have moved v2 to the PDF (was marked for speedy). The DJVU was missing pages, so the scan would have needed fixing anyway. Inductiveload—talk/contribs 08:24, 18 May 2021 (UTC)

Volume 12 is identical between the PDF and DJVU, I checked the pagelist , so can be migrated. I will check the remaining DJVU later. ShakespeareFan00 (talk) 09:29, 18 May 2021 (UTC)

Volume 17 is not identical. The difference seems to be some pages at the front. I've not found a content difference as suchShakespeareFan00 (talk) 09:38, 18 May 2021 (UTC)

Tech News: 2021-20

Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.

Recent changes

• There is a new toolbar in the Reply tool. It works in the wikitext source mode. You can enable it in your preferences. [2] [3] [4]
• Wikimedia mailing lists are being moved to Mailman 3. This is a newer version. For the character encoding to work it will change from UTF-8 to utf8mb3. [5][6]
• An earlier issue of Tech News said that the citoid API would handle dates with a month but no days in a new way. This has been reverted for now. There needs to be more discussion of how it affects different wikis first. [7]

Changes later this week

• MediaWiki:Pageimages-blacklist will be renamed MediaWiki:Pageimages-denylist. The list can be copied to the new name. It will happen on 19 May for some wikis and 20 May for some wikis. Most wikis don't use it. It lists images that should never be used as thumbnails for articles. [8]
• The new version of MediaWiki will be on test wikis and MediaWiki.org from 18 May. It will be on non-Wikipedia wikis and some Wikipedias from 19 May. It will be on all wikis from 20 May (calendar).

Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.

13:49, 17 May 2021 (UTC)

Overheard

About a month ago, I was in a meeting with some other WMF folks, and one said:

"Wikisource editors, to me, are heroes."

Unfortunately, I forgot to write down who said it, so I can't give proper credit, but I did want to let you know that your work is appreciated. Whatamidoing (WMF) (talk) 22:54, 17 May 2021 (UTC)

Migrating The Warden to The Warden (Trollope) for disambiguation

There exists another work of the same name: The Warden (Coleman), a poem which can be found at the page Songs and Sonnets (Coleman)/The Warden. @Billinghurst, @Inductiveload: Could one of you mass-migrate the chapters so this could be disambiguated? Thanks. PseudoSkull (talk) 17:02, 18 May 2021 (UTC)

moved chose a variation of the name, and disambiguation page is at Warden. — billinghurst sDrewth 04:02, 19 May 2021 (UTC)

Move The Sanctuary to Sanctuary

Most of the works listed at The Sanctuary actually have the title "Sanctuary" except one of them. Could the disambiguation page be moved by an admin to Sanctuary for better titling? PseudoSkull (talk) 17:03, 18 May 2021 (UTC)

Done per request, though I'm not an admin. Seemed uncontroversial. -- Mathmitch7 (talk) 18:31, 18 May 2021 (UTC)

Yes, that is our preferred location anyway. Do note that you can use intro to suggest variations of title that are there. — billinghurst sDrewth 04:03, 19 May 2021 (UTC)

Interaction ban with billinghurst

Frankly, I've had enough of billinghurst. billinghurst is removing content that I've created and is generally behaving like a rude and threatening administrator. So I am asking for an interaction ban with billinghurst. If billinghurst has a problem with my edits, I politely request that billinghurst request another administrator to step in and review them. Languageseeker (talk) 12:33, 19 May 2021 (UTC)

Well how about you edit according to the style, rather than thinking that everything is subservient to your project. Template:New texts has a format and direction, and you are expected to use it, not create your own style without consulting with the community. Author pages have a style, and not to be made into an holy mess solely for the benefit of your project. If you wish to change the style, start a conversation with the community. I am doing nothing but putting things back to the determined styles. — billinghurst sDrewth 12:39, 19 May 2021 (UTC)

my - that did not take long. this is a pretty friendly project (see accolade above) and billinghurst is a pretty friendly admin. (i have a "rude and threatening" list and he is near the bottom i have seen far worse rudeness by far higher functionaries, and far worse abusive conduct.) trying to follow community norms is a happier practice. you might not like how the other admins treat you. Slowking4 亞 Farmbrough's revenge 15:28, 19 May 2021 (UTC)

I don't think the comments that billinghurst left on my talk page, namely You are leaving spots of crap all over the place and Don't play games with me, would be considered friendly. Languageseeker (talk) 16:50, 19 May 2021 (UTC)

You are leaving spots of crap all over the place. Everywhere I look I find your edits that look like bird crap under a tree that someone needs to go and clean away. Your quality control is rubbish. You talk a great game, and then come up hugely short on the action. Here is this moments examples

• Hamlet, Second Quarto (Folger Shelfmark: STC 22276)
• Hamlet, Second Quarto (Huntington Shelfmark: 69305)
• Hamlet, Second Quarto Variant (British Library Shelfmark: C.34.k.2)
• Hamlet, Third Quarto (Bodleian Shelfmark: Arch. G e.13)
• Hamlet, Third Quarto (British Library Shelfmark: C.34.k.4)
• Hamlet, Third Quarto (British Library Shelfmark: C.71.b.2)
• Hamlet, Third Quarto (Edinburgh Shelfmark: JA 3734)
• Hamlet, Third Quarto (Folger Shelfmark: STC 22277) Copy 2
• Hamlet, Third Quarto (Folger Shelfmark: STC 22277) Copy 3
• Hamlet, Third Quarto (Huntington Shelfmark: 69306)
• Hamlet, Third Quarto (Huntington Shelfmark: 69307)

... Some of this was done a month ago, and I will be able to unearth more pretty easily.

So I cannot talk to you about this, I am not allowed to clean it up, and I have to talk to another admin about it. You have to be kidding! So I have a better plan: lift your game. Edit according to our styles, do not leave crap, do your quality control. Stop treating this place like a door mat.

With regard to my pugilism. I have tried being nice with you, and I have tried being collegiate, it doesn't work. You reverted my clean up on template:new texts with the temerity to say "There is no community consensus for this change. Please discuss it at the Scriptorium first." when it was your additions that were outside the norm, and which you had had zero discussion, and the instruction on the page is pretty clear on what is in scope on the page. So you will get "don't play games with me" if you try and play games with me.

I am big on consensus, and I abide by the consensus whether I agree with it or not. I edit to our consensus as comes through our guides or as discussed here. I fix up people's bird droppings without much complaint. I discuss on their talk page, I don't make big hullaballoos, and parade people in front of the community for their mistakes. However, when some people like to think their individual style trumps the community's and when they are asked politely to review their edits, and I get the passive aggressive metaphorical middle finger, I will not take that one. — billinghurst sDrewth 01:57, 20 May 2021 (UTC)

you have not tangled with admins. they tend to drag you to a drama board, where they talk about you as a problem user, with a block, and a demanded apology. they are vindictive, and bear false witness. but yrmv. Slowking4 亞 Farmbrough's revenge 23:45, 19 May 2021 (UTC)

Looking at the contributions highlighted by billinghurst, I don't see any "false witness" being borne here. The criticism of the editor's contributions is spot-on. Big blocks of unformatted text for what should be indicated in the format of a play. BD2412 T 02:11, 20 May 2021 (UTC)

glad you agree. it is important to contrast the situation here where it is a dispute about quality of work and community norms, and elsewhere, where there are false claims of legal threat, false claims of personal attack, false claims of non-notability, and false clams of plagiarism. Slowking4 亞 Farmbrough's revenge 13:39, 22 May 2021 (UTC)

"Hamlet, Second Quarto (Folger Shelfmark: STC 22276)"? "Hamlet, Third Quarto (Bodleian Shelfmark: Arch. G e.13)"? "Hamlet, Third Quarto (Folger Shelfmark: STC 22277) Copy 3"? Holy cow! I've seen some horrid examples of titling before on Wikisource but this probably takes the cake out of all of them. First of all, nowhere in the titling conventions does it ever mention these weird library ID things you put in there, and for good reason. Look at it: I don't want to have to know some weird code language to find what I'm looking for on a wiki where titles are supposed to be relatively simple enough to be coherent to the general public...

As far as the content goes: I think Billinghurst's complaints are totally reasonable and I'm not even sure what you're trying to accomplish with these. Looks to me like they're some way of treating the mainspace like a draft space maybe, which is not what the mainspace is for on any wiki including this one. The mainspace is for finished pages, not incomplete and unformatted works. We have enough of those already as it is, and we certainly don't need more, that are copied several times over with different titles for each instance.

I'm only addressing what was presented to me in this discussion, but as I'm sure as people have been implying that there's been a deeper problematic past, I  Oppose the interaction ban and support any efforts to delete the clutter listed above. Why slow down the process of getting rid of, or fixing, bad content by implementing an interaction ban with a certain admin who was dealing with it a lot, when we could just not do that and have a better time? If it were me in his position I would be speedying these pages right now as blatant violations of consensus. PseudoSkull (talk) 05:22, 20 May 2021 (UTC)

Thank you for drawing my attention to this list. I have speedy deleted them all because they are text dumps from a site that states "creative commons - non-commercial". We don't accept works under the NC variant here. If there are other such dumps on any of the other 38 plays, please tag them for Speedy Deletion (G6). Beeswaxcandle (talk) 09:17, 20 May 2021 (UTC)

The Hamlet texts came about because Billinghurst decided that ext and small scan links did not belong on the Hamlet page and removed all non-transcluded links from the Hamlet page. This triggered an edit war with EncycloPetey. Billinghurst informed me then that I could not post an ssl unless I already had a text in ns. Since the text was the proofread text of a PD source, I think that sweat-of-the-brow still appears. However, if you believe that a text from the sixteenth century is in copyright, then I will not challenge that decision. Languageseeker (talk) 12:09, 20 May 2021 (UTC)

So it is all my fault that you pasted rubbish text into pages. Right. I stood over you and twisted your arm, and held your cat hostage. I can see me there, standing over you. "Contribute the Hamlets, or the pussycat gets it." For goodness sake, what is wrong with this picture? — billinghurst sDrewth 13:43, 20 May 2021 (UTC)

I'm intentionally not commenting on the behavioral issues here, but assuming that the deleted pages above were in fact transcripts of scans of really old quartos of Shakespeare plays, without any modern annotations, they're in the public domain regardless of what the license says. See c:Commons:When to use the PD-scan tag for how they deal with it; I can't find any Wikisource policy in favor of respecting copyfraud claims. Vahurzpu (talk) 19:09, 20 May 2021 (UTC)

<sigh> I did not state that these were copyright nor do I support any copyfraud claims. An example of the original of the pasted text-dump is here. All the content of the page was pasted here including the preliminary guff, the annotations of the annotations, page headers, &c. &c. In that state, the page here was useless and contained material that we cannot host. Ergo, it was deleted. The reason for using G6 is simply that that is the best option when there is modern material on a page. Beeswaxcandle (talk) 20:20, 20 May 2021 (UTC)

• A word of caution for those responding. The account Slowking4 has stated they maintain an ordered list of admins, their grievances with process, a provocative tag in their signature, please also note this list https://en.wikisource.org/wiki/Special:CentralAuth/Slowking4 and reasons given for community actions at other big sister sites. CYGNIS INSIGNIS 03:00, 21 May 2021 (UTC)

  I thought it was metaphorical speech, and if it is, how about we just remove those bits for clarity. — billinghurst sDrewth 03:17, 21 May 2021 (UTC)

  there nothing provocative in knowing Rich Farmbrough, and viewing his treatment on english as an injustice. the mis-governance of that wiki is an open scandal, and outsiders are astonished. but let the fate of both of us be a warning to any who dare cross an admin anywhere. maybe you need a slowking warning template like "mad, bad, and dangerous to know" Slowking4 亞 Farmbrough's revenge 01:44, 22 May 2021 (UTC)

  When did you become aware of those bans? CYGNIS INSIGNIS 03:35, 21 May 2021 (UTC)

  Pinging @Billinghurst:, my question was smothered so notifying you I had a question. CYGNIS INSIGNIS 06:16, 21 May 2021 (UTC)

  @Cygnis insignis: Bans? I cannot say I have specific *knowledge* of any local bans external to this wiki with regard to any individual. Any other comment does not belong in this topicked conversation, though I am happy to answer on your or my talk page, or a pertinent conversation of the community. — billinghurst sDrewth 07:48, 21 May 2021 (UTC) And to add some openness ... my Special:CentralAuth/Billinghurst and xtools:ec/en.wikisource.org/Billinghurst — billinghurst sDrewth 08:18, 21 May 2021 (UTC)

  Billinghurst may have forgotten, but does have knowledge of a least one individual that have been banned elsewhere and welcomed here, although it was a long time ago it's sure I have not forgotten. Billinghurst or any user in good standing may request a diff here, but preferably offline to avoid further drama and 'not feeding of … ". CYGNIS INSIGNIS 11:08, 21 May 2021 (UTC)

  I said specific knowledge, and for me that would be about a formal ban motion of a community. And I am struggling to see the relevance of the point in this topic, and wondering where this fork is going, and how it is relevant. Not into playing gotcha. — billinghurst sDrewth 15:31, 21 May 2021 (UTC)

  the vindictiveness towards users that may be "banned" elsewhere: “C'est pire qu'un crime, c'est une faute”. [9] Slowking4 亞 Farmbrough's revenge 02:13, 22 May 2021 (UTC)

I understand that you might not find all of my contributions up to your standard and that I have made mistakes. However, you, billinghurst, are an administrator. That means that you have an immense amount of power on this site. The kind of speech that you use would not be acceptable by a regular user. Nor does it conform to standard of civility. You can mock the Hamlet case, but you decided, without community consensus, to remove all the external scan links, links to indexes, and red links on that page. Languageseeker (talk) 03:43, 21 May 2021 (UTC)

• The contributions of this user seems to be invoking bots or making edits that could be done by the same, generating the discussions they have stated they wish to engage in. They do not respond to any concern raised in those previous discussions, it seems they write more comments more than read and that is becoming increasingly looking like NOT HERE to improve our works. CYGNIS INSIGNIS 06:10, 21 May 2021 (UTC)

(outdent)  Comment You started this conversation, and I responded in what I am trying to do to bring your edits to a standard and to our style. So please stop trying to divert the conversation to it being my fault that I fix and highlight to the individual poor editing, or non-use of the style guide. [PLUS you do not get to re-prosecute the case, nor try to re-frame it when it is clear above that is not the situation.] And thank you for talking about Wikisource:Adminship, you will see that I am doing what it requires of administrators, and access to tools. I especially like this line Follows established Wikisource policy and guidelines. FWIW the only power that I have is the power of argument and experience, that does not come from the tools. — billinghurst sDrewth 08:09, 21 May 2021 (UTC)

I've been following this discussion from a distance, both here on the Scriptorium and (to a small degree) through some of the interactions that preceded it. My general sense is that both Billinghurst and Languageseeker have a great deal of knowledge and good will toward the purpose of Wikisource, but that each each has in some cases fallen short of expressing themselves with enough clarity, equanimity, or context to support the possibility of working together effectively. I agree with others in this thread that an interaction ban is not at all appropriate to this situation; and to the extent that this discussion was started with that narrow goal, it seems to me it'd be in everyone's interest to close this discussion ASAP, as it seems everybody is in agreement about that. Beyond that narrow decision, I think that if either Billinghurst or Languageseeker wants their interactions to get better, there are many things either one of them could do that would support that. I tend to agree that it's more incumbent on Billinghurst, who occupies an important position of trust, to do that; but also, he doesn't have an easy task. To both of you, I'd urge you to find ways to talk more clearly about your broader goals (my sense is that in both cases you have uncontroversial, good, and insightful goals motivating what you do here, if only others could see what they are) and be in less of a hurry to get specific outcomes. -Pete (talk) 19:14, 21 May 2021 (UTC)

Categories for CC-BY and CC-BY-SA

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

• For CC attribution, separate categories have been created, each version of license has its own category: Category:CC attribution 2.0, Category:CC attribution 3.0 etc.;
• For CC-BY-SA works, one combined category exists: Category:Creative Commons BY-SA, undivided for different versions (2.0, 3.0, etc.).

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)

RFC: External link styling nomenclature => some proposed changes

For quite a while we have utilised the following styles for link templates

• (work) lkpl (link plain) for shortened links (intrawork, interwork)
• (work) link (link) for full link with overt identification of the parent work

Inductiveload and I have found that there are some (old) templates that point externally, we renamed one to {{NYT ext link}} so that we could re-factor {{NYT link}}.

I am proposing that all our templates that are externally pointing utilise (site) ext link nomenclature. The exception to this is WMF wikis which have a separate functionality hopefully leveraging Wikidata, and Special:Interwiki. Not proposing to change {{ext scan link}}.

We need to do the separation to minimise confusing overlap, and happy to hear counter proposals. Unsure of the scope at this point, though think that is immaterial for the benefit. I am not asking anyone else to do the work, and would report back on what are the changes if the community agrees to progress. — billinghurst sDrewth 02:39, 21 May 2021 (UTC)

Fine by me, though I think it probably only have real value when the abbreviation (e.g. "NYT") could refer to an on-wiki title as well as an external site. For example, {{OCLC link}} doesn't seem to me to urgently need to become {{OCLC ext link}} (wrt the above, "OCLC lkpl" doesn't really make sense, so I don't see major scope for confusion). Though I wouldn't shed tears if it gain the "ext", so ¯\_(ツ)_/¯. Inductiveload—talk/contribs 23:50, 21 May 2021 (UTC)

I would prefer to see that one just disappear. OCLC linking is better through {{authority control}}. Seems that maybe a list brought here may be useful. I know that we have {{ADB link}} and it is thinks like that and certainly anything that is amibiguous. — billinghurst sDrewth 00:26, 22 May 2021 (UTC)

Category:External link templates holds those that we have categorised; list unaudited. — billinghurst sDrewth 01:06, 22 May 2021 (UTC)

oclc is better for work information, authority control better for author information. i would suggest restricting authority control to author page, and oclc to list of works, and work header. Slowking4 亞 Farmbrough's revenge 22:48, 22 May 2021 (UTC)

Who are the Election Volunteers in your community?

Do you want to be an Election Volunteer?

Would you like to get more people taking part in the Wikimedia Foundation’s Board of Trustees election?

The Wikimedia Foundation Board of Trustees announced the plan for the 2021 Board elections. That plan includes outreach and communication support for the Board elections. The Board election facilitators will:

• Inform communities of the trustee selection process
• Invite communities to engage in voting
• Encourage people representing emerging Wikimedia communities to run as candidates

Voter turnout in prior elections was about 10% globally. It was better in communities with volunteer election support. Some of those communities reached over 20% voter turnout. We know we can get more voters to help assess and promote the best candidates, but to do that, we need your help.

We are looking for volunteers to serve as Election Volunteers. Election Volunteers should have a good understanding of their communities. The facilitation team sees Election Volunteers as doing the following:

• Promote the election in their communities’ channels
• Organize discussions about the election in their communities
• Translate messages for their communities

Who are the Election Volunteers to connect your community with this movement effort? Is it you? Or someone you know? Check out more details about Election Volunteers and add your name next to the community you will support in this table or get in contact with a facilitator. We aim to have at least one Election Volunteer for Wiki Projects in the top 30 for eligible voters. Even better if there are two or more sharing the work.

Best, JKoerner (WMF) (talk) 18:04, 21 May 2021 (UTC)

Scan Localisation Requests...

For those that don't necessarily follow WS:CV,

I had noted some scans that should be localised.

The expertise of other contributors in reviewing these items, so that a contributor or admin with appropriate tools can localise the works concerned.

The reason is that whilst the works are potentially PD-US (based on publication dates), there are not necessarily PD in their original country of publication, given any lifetime the author given ( or absence of that information.).

Once moved the discussions at WS:CV can be closed rapidly :) ShakespeareFan00 (talk) 14:09, 22 May 2021 (UTC)

WS:CV is for works that are copyright violations at enWS, not Commons, so I am not certain that listing works that need to be shifted at that place is appropriate. Maybe a subsection here, or maybe a section at WS:AN though it doesn't actually require admin permissions.

As commentary, shifting works locally from Commons is a bit of an UGH task at this time. pywikibot's script imagetransfer.py fails, in that it is won't ignore the existence of the file at Commons and won't force. Magnus's script at c:MediaWiki:ExCommons.js use to work though me fails in the oauth components and I cannot get MM's attention to resolve the issue. — billinghurst sDrewth 02:20, 23 May 2021 (UTC)

Second parameter of {{wikt}}

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 words

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? Inductiveload—talk/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/survey

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:

foo
bar

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: https://phabricator.wikimedia.org/file/upload. Inductiveload—talk/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)

Tech News: 2021-21

Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.

Recent changes

• The Wikimedia movement has been using IRC on a network called Freenode. There have been changes around who is in control of the network. The Wikimedia IRC Group Contacts have decided to move to the new Libera Chat network instead. This is not a formal decision for the movement to move all channels but most Wikimedia IRC channels will probably leave Freenode. There is a migration guide and ongoing Wikimedia discussions about this.

Changes later this week

• The new version of MediaWiki will be on test wikis and MediaWiki.org from 25 May. It will be on non-Wikipedia wikis and some Wikipedias from 26 May. It will be on all wikis from 27 May (calendar).

Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.

17:07, 24 May 2021 (UTC)

Broken renewal links

Do records in https://exhibits.stanford.edu/copyrightrenewals 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. https://exhibits.stanford.edu/copyrightrenewals/catalog/R107985 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: https://archive.org/details/catalogofcopyrig372libr/page/182/mode/1up?view=theater. 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. Inductiveload—talk/contribs 08:59, 28 May 2021 (UTC)

Tech News: 2021-22

Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.

Problems

• There was an issue on the Vector skin with the text size of categories and notices under the page title. It was fixed last Monday. [10]

Changes later this week

• There is no new MediaWiki version this week.

Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.

17:05, 31 May 2021 (UTC)

Dissapointed...

I'm wondering if I should continue doing things here at all right now:- https://en.wikisource.org/wiki/Special:Contributions/ShakespeareFan00

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. [11] i would suggest finding someone with some serious CSS skills (as mentioned by billinghurst some time ago [12] ) until we get a wishlist , or summer of code, it will be very frustrating, best to put on hold and spare the emotional energy. Slowking4 亞 Farmbrough'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 Page

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. Inductiveload—talk/contribs 11:28, 1 June 2021 (UTC)

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

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)

Mass rollback request

Can someone just rollback every single edit I made after https://en.wikisource.org/w/index.php?title=Page:Chronological_Table_and_Index_of_the_Statutes.djvu/25&oldid=11369066

Somehow in trying to update something, it just broke here Chronological Table and Index of the Statutes/Chronological Table/Edw4

As I no longer have time, patience or expertise to track down precisely what wentwrong, The simplest answer is just to have the whole effort rollbacked en-masse, despite it for the most part actually working.

If someone has the time to find the typing error, (with no documentation, comments etc.) because that almost certainly what's caused it to be broken, you are welcome to, but I have had it with trying to actually contribute until I can actually rely on being able to do things without continually creating headaches for myself or other contributors to resolve.

I'd like to however thank other contributors here for their support, on past efforts however. ShakespeareFan00 (talk) 18:42, 5 June 2021 (UTC)

Reverting is easy. Do you need help trying to figure out this table? —Justin (koavf)❤T☮C☺M☯ 18:48, 5 June 2021 (UTC)

Yes. I'd like to know is why the Transclude wasn't working properly, It is almost certainly a typo on my part, somewhere. ShakespeareFan00 (talk) 19:05, 5 June 2021 (UTC)

Also Chronological Table and Index of the Statutes/Chronological Table/Cha2. It would be nice to know WHY. ShakespeareFan00 (talk) 19:29, 5 June 2021 (UTC)

What seems to be going on in Page: namespace as well is various interactions of blank characters (like spaces and line-feeds), with various parts of the header and sectionalisation. I've in the past asked for what the precise handling is to be DOCUMENTED, but no one has done so yet :( Sigh ) ShakespeareFan00 (talk) 19:37, 5 June 2021 (UTC)

I found the issues.. I'd not been setting up the transcludes correctly. No need to rollback now as I am getting it working very nicely :) ShakespeareFan00 (talk) 20:42, 5 June 2021 (UTC)

Chronological Table and Index of the Statutes/Chronological Table/23Geo2 - What went wrong here? ShakespeareFan00 (talk) 22:37, 5 June 2021 (UTC)

Note to self : Check that you've paired tags properly... ShakespeareFan00 (talk) 10:37, 6 June 2021 (UTC)

 This section is considered resolved, for the purposes of archiving. If you disagree, replace this template with your comment. — billinghurst sDrewth 07:33, 9 June 2021 (UTC)

Plato volumes

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)

Should poor quality of an image be preserved in works?

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)

Tech News: 2021-23

Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.

Changes later this week

• The new version of MediaWiki will be on test wikis and MediaWiki.org from 8 June. It will be on non-Wikipedia wikis and some Wikipedias from 9 June. It will be on all wikis from 10 June (calendar).

Future changes

• The Wikimedia movement uses Phabricator for technical tasks. This is where we collect technical suggestions, bugs and what developers are working on. The company behind Phabricator will stop working on it. This will not change anything for the Wikimedia movement now. It could lead to changes in the future. [13][14][15]
• Searching on Wikipedia will find more results in some languages. This is mainly true for when those who search do not use the correct diacritics because they are not seen as necessary in that language. For example searching for Bedusz doesn't find Będusz on German Wikipedia. The character ę isn't used in German so many would write e instead. This will work better in the future in some languages. [16]
• The CSRF token parameters in the action API were changed in 2014. The old parameters from before 2014 will stop working soon. This can affect bots, gadgets and user scripts that still use the old parameters. [17][18]

Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.

20:02, 7 June 2021 (UTC)