Wikisource:Administrators' noticeboard

From Wikisource
Jump to navigation Jump to search
Administrators' noticeboard

This is a discussion page for coordinating and discussing administrative tasks on Wikisource. Although its target audience is administrators, any user is welcome to leave a message or join the discussion here. This is also the place to report vandalism or request an administrator's help.

  • Please make your comments concise. Editors and administrators are less likely to pay attention to long diatribes.
  • This is not the place for general discussion. For that, see the community discussion page.
  • Administrators please use template {{closed}} to identify completed discussions that can be archived
Report abuse of editing privileges: Admin noticeboard | Open proxies
Wikisource snapshot

No. of pages = 3,713,260
No. of articles = 922,720
No. of files = 19,623
No. of edits = 12,080,141


No. of pages in Main = 539,327
No. of pages in Page: = 2,727,780
No. validated in Page: = 530,182
No. proofread in Page: = 923,095
No. not proofread in Page: = 1,039,640
No. problematic in Page: = 38,194
No. of validated works = 5,505
No. of proofread only works = 4,271
No. of pages in Main
with transclusions = 332,247
% transcluded pages in Main = 61.60
Σ pages in Main


No. of users = 3,021,024
No. of active users = 395
No. of group:autopatrolled = 479
No. in group:sysop = 23
No. in group:bureaucrat = 3
No. in group:bot = 16


Checkuser requests[edit]

  • Wikisource:checkuser policy
  • At this point of time, English Wikisource has no checkusers and requests need to be undertaken by stewards
    • it would be expected that requests on authentic users would be discussed on this wiki prior to progressing to stewards
    • requests by administrators for identification and blocking of IP ranges to manage spambots and longer term nuisance-only editing can be progressed directly to the stewards
    • requests for checkuser

Bureaucrat requests[edit]

Interface Admin for Xover[edit]

@BD2412, @Beeswaxcandle: Ok, I finally got tired of pestering Inductiveload for every little JS/CSS bit that needs doing, so I bit the bullet and enabled 2FA for my account (which the `crats are somehow supposed to check, but have no technical facility to actually do). I'd like Interface Admin rights added to take care of random needed changes to .js and .css in MediaWiki:-space (most immediately, fixing MediaWiki:Gadget-addsection-plus.js which got borked in the latest MW release). --Xover (talk) 19:24, 20 October 2021 (UTC)[reply]

@Xover: Granted for 1 month. Seek Community support for ongoing access to the right in that time and we'll can make it a longer period to bring into line with your annual reconfirmation. Beeswaxcandle (talk) 22:21, 20 October 2021 (UTC)[reply]
Thanks, and will do. Xover (talk) 07:21, 21 October 2021 (UTC)[reply]
Symbol support vote.svg Support knows where their towel is and will be nice to have some company in the CSS mines. Inductiveloadtalk/contribs 22:23, 20 October 2021 (UTC)[reply]
Symbol support vote.svg Support Great user and has my trust. Languageseeker (talk) 22:27, 20 October 2021 (UTC)[reply]
Symbol support vote.svg Support PseudoSkull (talk) 23:32, 20 October 2021 (UTC)[reply]
This is all very well, but the AN is not appropriate place to seek community support as not all members of the community are regularly here. Open a conversation at WS:ADMINS. Beeswaxcandle (talk) 01:25, 21 October 2021 (UTC)[reply]
At this point, I don't know that it makes sense to observe the formality of a separate discussion. I would not expect the outcome to vary. BD2412 T 02:21, 22 October 2021 (UTC)[reply]

Page (un)protection requests[edit]

Requesting page protection for {{left sidenote}} and {{right sidenote}}[edit]

Given what happened (see above) I am of the view that as highly visible and widely used templates, these along with their respective style-sheets should be protected from general editing, with someone appropriate identifying a STABLE version and then protecting that version. Thanks.ShakespeareFan00 (talk) 09:46, 2 June 2021 (UTC)[reply]

Other[edit]

Interface administrators[edit]

Hi. Please see https://www.mediawiki.org/wiki/Topic:Unisfu5m161hs4zl. I do not remember if this was already discussed and how it is going to be addressed. Comments and suggestions welcome. Pictogram voting comment.svg Comment As far as I am concerned I would trust any admin who feels skilled and confident enough to tackle such edits.— Mpaa (talk) 21:05, 29 October 2018 (UTC)[reply]

I can handle the technical aspects of it. However, it can take me a while to get around to tasks that take longer than a few minutes, so I don't want to create a false expectation of being able to handle time sensitive matters on my own. —Beleg Tâl (talk) 02:35, 30 October 2018 (UTC)[reply]


We should decide how to address the fact that EnWS has no m:interface administrators. I see basically the following options. Please add/amend as you feel appropriate.

Option A - Assign right on demand when needed

Option B - Assign right permanently to willing Admins, to be reviewed in the confirmation process

As I said above, I am for the simplest one.— Mpaa (talk) 21:28, 30 October 2018 (UTC)[reply]

Option C - Assign right permanently to selected Admins, after approval process, to be reviewed in the confirmation process

Option C sounds like you're being volunteered (based on the lack of the word 'willing'). ;) --Mukkakukaku (talk) 06:27, 31 October 2018 (UTC)[reply]

Option D - assign the rights to all the admins, who have already been vetted for community approval, and then whoever has the ability and desire can make use of it as they will and as needed. —Beleg Tâl (talk) 13:33, 31 October 2018 (UTC)[reply]

Option D would make the most sense for us. For anyone to get themselves to the point that we trust them with the admin tools just so that they can mess around in the interface, they would be playing a very long game. Beeswaxcandle (talk) 22:05, 2 November 2018 (UTC)[reply]
I agree with Beeswaxcandle, Option D, although I would also be fine with the right only going to admins who express an interest. BD2412 T 23:00, 2 November 2018 (UTC)[reply]
It is so rare I disagree with Beeswaxcandle but this must be one of those times. The whole point of this change is to prevent the ignorant from accidentally screwing up - insulting as the implications undoubtedly are! As such under the new regime trust is no longer enough; perhaps somebody ought to draw up some kind of eligibility examination…? 114.73.248.245 23:03, 2 November 2018 (UTC)[reply]
That hasn't been an issue for us yet, and accidental changes are easily reversed. If we had more users it would be more of a problem, but as it stands this kind of distinction is more cumbersome than helpful in my opinion. —Beleg Tâl (talk) 00:08, 3 November 2018 (UTC)[reply]
As much as I like the idea of making all existing admin interface admin, IA were separated from regular adminship specifically to reduce attack surface(from hackers), and it was pretty dangerous if the access fell into the wrong hand, I'd rather propose having existing admin request right from bureaucrat and could be granted at the bureaucrat's discretion, and should be automatically removed if no action after two month.Viztor (talk) 02:13, 10 August 2019 (UTC)[reply]
  • Pictogram voting comment.svg Comment we discussed it when the rights were split, and it was agreed that it could be assigned on a needs basis. That has been done at least once for me with the temporary assignation of the IA rights. — billinghurst sDrewth 05:58, 10 August 2019 (UTC)[reply]
    Note that WMF Legal requires 2FA to be enabled for users who are to be assigned this right, so bureaucrats will have to verify this before doing so. MediaWiki's 2FA implementation is also sufficiently finicky that one may not want to enable it without proper consideration. --Xover (talk) 08:21, 10 August 2019 (UTC)[reply]
    What's wrong with the 2FA implementation? I haven't had any issues with it at all. —Beleg Tâl (talk) 22:17, 10 August 2019 (UTC)[reply]
    Ah, sorry, I should have been more clear. I am going on hearsay, mostly from admins on enwp (a crotchety bunch if ever there was one), and my own assessment of the documentation at meta. The main complaints are that the implementation in general is a little bit primitive (as is to be expected since WMF rolled their own instead of federating with one of the big providers), and that there is no way to regain access to your account if something goes wrong with the 2FA stuff (if your phone is stolen etc.) unless you happen to know one of the developers personally. None of these are in themselves showstoppers, and many people are using it entirely without issue. The phrasing sufficiently finicky that one may not want to enable it without proper consideration was not intended to discourage use, but merely to suggest that it is worthwhile actually giving it a little thought before requesting it be turned on. --Xover (talk) 17:52, 11 August 2019 (UTC)[reply]
    Okay, gotcha. As it happens, Wikimedia 2FA does include emergency access codes for use when your phone is unavailable. —Beleg Tâl (talk) 19:56, 11 August 2019 (UTC)[reply]

Formal requirements related to 2FA[edit]

Picking up this again…

I finally got so annoyed by our inability to fix even simple stuff stuff that requires Interface Admin permissions that I hopped over to meta to figure out what the actual requirements are (versus the should stuff). As it turns out, the 2FA stuff is (surprise surprise) as half-baked as most such Papal bulls from the WMF: 2FA is required for intadmin, but there is no way for bureaucrats to actually check whether an account has that enabled. The result of this is that even on enwp (where they take this stuff really seriously) they do not actually try to verify that 2FA is enabled before they hand the permission out: they check that the user is in the right group so that they can turn on 2FA, remind the person in question of the requirement, but otherwise take it on faith (trust). There's a request in for the technical capability to verify 2FA (and I think Danny is even working on it), but it seems mostly everyone's waiting for 2FA to be enforced by the software.

Meanwhile, anyone with existing advanced permissions (i.e. +sysop) have the capability to enable 2FA, and anyone with a particular reason (e.g. that they need it to get Interface Administrator permission) can apply to be a "2FA Tester" and thus gain the ability to turn it on.

The net result is that our bureaucrats (ping Hesperian and Mpaa) can assign this permission so long as we somehow somewhere make at least a token effort to make sure those getting the bit have 2FA enabled. Whether that's an addition to, or footnote on, Wikisource:Adminship, or the bureaucrats asking/reminding the user when it comes up, or… whatever… I have no particular opinion on. Since the previous community discussions have been actively adverse to regulating this stuff in detail, and absent objections, I think "Whatever Hesperian and Mpaa agree on" is a reasonable enough summary of consensus.

I still think we should have an actual policy for Interface Administrators (or section on it in Wikisource:Adminship) and some facility for permanently assigning the permission (ala. +sysop; but intadmin tasks are not one-and-done like +sysop tasks, they often require iterative changes over time and need to fit into a overall architecture), but so long as there is no appetite for that, something that we can point to and say "That's how we handle the 2FA requirement" if the WMF should ever come asking. --Xover (talk) 07:37, 10 February 2020 (UTC)[reply]

Question Question Is there anything further that the community thinks we need to discuss? — billinghurst sDrewth 01:36, 1 October 2021 (UTC)[reply]

I just added Special:Diff/11740077 as a quickrestatement of meta:Interface administrators, which is already linked from the top of Wikisource:Interface administrators. Basically "you should be using 2FA". If there are more formal ways to check in future, then we can update the information. FWIW, I have it on, which is a little annoying when I accidentally fat-finger the logout button, but otherwise seems unproblematic. Inductiveloadtalk/contribs 07:46, 1 October 2021 (UTC)[reply]
Should? "Required" is my understanding. There was a heated phabricator ticket about the WMF moving to have the allocation undertaken by stewards following their checking for 2FA being in place, rather than local 'crats. The counter argument was that local crats snould be able to check status and apply the rights. The ticket is stalled as a rethink is seemingly in play. — billinghurst sDrewth 08:14, 1 October 2021 (UTC)[reply]
It's a paraphrase of what I wrote, but I changed the text there to "required" since it's not just an expectation. Inductiveloadtalk/contribs 10:08, 1 October 2021 (UTC)[reply]

Request move[edit]

Hello. Could you please move "Siamese Interim Administrative Charter Act, Buddhist Era 2475 (1932)" to "Translation:Act on Interim Charter for Public Administration of Siam, 2475 Buddhist Era" and change its namespace from "main" to "translation"? Thank you so much. --KhaoNiaoMaMuang (talk) 12:21, 11 December 2020 (UTC)[reply]

Yes check.svg Done The above has been moved. Wikidata item needs to be moved. --kathleen wright5 (talk) 21:10, 11 December 2020 (UTC)[reply]

@Kathleen.wright5: The WD items should be updated when you do the moves, or very quickly afterwards. — billinghurst sDrewth 01:29, 13 December 2020 (UTC)[reply]
If anyone is interested in working on this particular backlog, there are about 80+ works (mostly Thai legal documents) that need to be moved from Mainspace to Translation space. —Beleg Tâl (talk) 21:04, 12 December 2020 (UTC)[reply]
If someone can map out the required conversions from {{header}} to {{translation header}} then I can run through them. Just too busy to do all the thinking of the conversions. Would be wanting indications of which lines add/remove/change, to make the bot tasking easier. — billinghurst sDrewth 01:32, 13 December 2020 (UTC)[reply]
@Billinghurst: Most of them are obvious - title=<title>, author=<author>, etc. The interwiki link [[th:<pagetitle>]] gives you the values for language=th and original=<pagetitle>. If shortcut and/or year are omitted, they need to be added as blank parameters. Finally, any instance of override_translator = [[Wikisource:Translations|Wikisource]] needs to be removed. —Beleg Tâl (talk) 14:24, 14 December 2020 (UTC)[reply]

Need some sort of template for constitutions and other iterative works[edit]

It is my opinion that we need to template tag those government works that have histories of versions as well-meaning editors keep updating existing versions rather than adding completely new versions. And it would be fair to say that we somewhat bury the fact that our documents are static versions rather than dynamic. I think that we should develop an elegant template that we can apply to these types of iterative works that clearly says that the presented work is a static version, and clearly states which static version. Any takers? — billinghurst sDrewth 04:01, 19 January 2021 (UTC)[reply]

Restore deleted items so I can finish transcriptions[edit]

Please look at Portal:Susannah_Lattin, the red links were entries that were deleted before I could finish transcription or before I could migrate the text from Commons. Could they be restored so I can finish the project? --RAN (talk) 03:00, 27 February 2021 (UTC)[reply]

@Richard Arthur Norton (1958- ): It is imo possible to restore it, but I had a look e. g. at The Long Island Mystery which is just a so short extract of the text that I am not really sure why it would be useful. Can just the page be simply founded again, only this time with the full text? --Jan Kameníček (talk) 09:35, 27 February 2021 (UTC)[reply]
The full text already exists for all these entries, they were deleted as I was creating them. I have the corrected text or the raw OCR at Wikimedia Commons and at Familypedia, where they were in 2015 when their counterpart here was deleted. I won't be be able to match them up to their image and text at Commons until I see the full article titles and what text was already there. The person deleting them, should have just asked me if I had the text to complete them. I think it was part of a larger dispute over whether ordinary people can get a portal or a category to tie them together as a subject of a group of articles. If you restore them, I can finish what I started. --RAN (talk) 20:20, 27 February 2021 (UTC)[reply]
I have restored Brooklyn Eagle/1868/The Long Island Mystery. It's the one with content. Most of the others are a header only with a file link. The one from the New York Herald was never created. Beeswaxcandle (talk) 20:37, 27 February 2021 (UTC)[reply]
@Richard Arthur Norton (1958- ): Please don't create these unfinished in main namespace. If you want to undertake a progressive transcription like that, then create it in your user space in a sandbox. [This is not the first time this has been mentioned and you have a string of unfinished transcriptions sitting in Special:PrefixIndex/user:Richard_Arthur_Norton_(1958-_).] Of course the best practice when you have a scan of the text is to utilise the Index:/Page: namespace like everyone else is encouraged to do. — billinghurst sDrewth 22:29, 27 February 2021 (UTC)[reply]
And to your sniping assertion, I would point you to your user talk page where there is still the very specific and clear text about why they were deleted. And yes, it was part of your history of problematic editing at that time. — billinghurst sDrewth 22:37, 27 February 2021 (UTC)[reply]
When you refer to my comments as "sniping" it is another indicator there is a personal problem, hence the request for an interaction ban. --RAN (talk) 21:11, 2 March 2021 (UTC)[reply]
  • And as I said then, and is still true today. I have the transcriptions waiting to be cut and pasted, except you delete faster than I can finish the work. We also have categories for entries called Category:25% for entries that are 25% transcribed or less. We even have a Category:0%. If you asked me if I had the text, rather than delete things I am working on, everyone would be happier. --RAN (talk) 21:09, 2 March 2021 (UTC)[reply]

Pictogram voting comment.svg Comment To any admin restoring progressive transcriptions, I would ask that if you restore them to main namespace that they are then moved to user namespace for their completion. Easy for them to be moved back to main ns upon completion. — billinghurst sDrewth 22:42, 27 February 2021 (UTC)[reply]

Proposed interaction ban[edit]

  • Can I suggest an interaction ban between myself and Billinghurst. If my entries need patrolling, it should be done by someone else that has no past history between us. Billinghurst has a record of enforcing his personal preferences selectively on my entries. As I reported earlier he was imposing rules he wrote under THIS IS A DRAFT!!! as !Wikilaw and instead of acknowledging them as draft rules, his response was to remove the THIS IS A DRAFT!!! title. There are a half-dozen ways that newspaper entries are being formatted, and there seems to be no rush to harmonize them, but Billinghurst is in a rush to change my entries, remove all wikilinks, delete entries I am transcribing, and most recently moving a valid entry out of mainspace. He is enforcing subjective rules selectively against me. I get the feeling that there is some personal animus involved and I am being put through a punitive audit for challenging him on the naming of an author entry recently. --RAN (talk) 05:21, 2 March 2021 (UTC)[reply]
As I said on your user page. Please only add things that fit the criteria of Wikisource:What Wikisource includes. At this time you are the only one bringing in family letters that have no notability, or to people of no discernible notability. As you yourself said you have transcribed some things at Ancestry, and that seems the appropriate place for items of a general genealogical and family history nature. Plus the works were not deleted, they were moved to your user space. I also asked for your wikilinks to comply to Wikisource:Wikilinks. Every time that this has happened, I have explained to you how it is out of scope.

Complaining here that I am supposedly enforcing my point of view when you have not demonstrated that the works are in scope, or that the linking is not out of scope is problematic. Stop complaining about me and demonstrate that the works are notable for inclusion here, and that the wikilinks that you did comply with our guidance. — billinghurst sDrewth 05:42, 2 March 2021 (UTC)[reply]

This is the problem, you are rigorously enforcing fuzzy subjective policy as if it is strict objective !Wikilaw and focusing on my entries, which feels like harassment. The more I complain, the more you focus on my entries. There are lots of other people around who do not have the long history of animus that appears to be here. Fuzzy subjective rules are being weaponized against someone you have a beef with, and that is wrong. It has gotten to the point where I fear asking a question at the Village Pump because you may unilaterally decide to delete something, or move something that I asked about. No contributor should be put in that situation. Having access to admin tools lets you be the executioner, but you are also allowing yourself to be the judge and jury too. The community should be deciding what is notable, and not notable, not you based on your personal preferences. The !Wikilaw you cite for saying my entry is non-notable reads as follows: "Works created before 1926: Most written work (or transcript of original audio or visual content) published (or created but never published) prior to 1926 may be included in Wikisource, so long as it is verifiable." That seems pretty straightforward to me, so the only reason I can see for saying it is not eligible for Wikisource, is the personal beef between us, hence the proposed interaction ban. When you read that rule, all you see is the word "most", which lets you delete what you personally do not like. --RAN (talk) 14:08, 2 March 2021 (UTC)[reply]

Need an Index: ns page move stopper[edit]

We need to toughen our defences against Index: and Page: ns moves. My suggestion is an abuse filter that selectively prohibits, or at the bare minimum warns people that it is not advisable. Before I do anything, would like to hear people's thoughts. Recovering from moves of this type is an issue, especially as it happens pretty quietly.

We don't have good automated rights that AF can leverage at this point in time, though there are numbers of measures that we can apply to restrict or pass actions. — billinghurst sDrewth 05:02, 30 May 2021 (UTC)[reply]

Sounds like a good idea, but I'm not familiar enough with the goings-on to have a strong opinion how to do it. Can you describe the problem a little more specifically and/or one or two of the things you think should be done about it? Does this have to with IPs, new accounts, experienced users making poor decisions, intentional vandalism, ..? -Pete (talk) 16:13, 2 June 2021 (UTC)[reply]
We do have Special:AbuseFilter/36, which is exactly for this. Perhaps add a warning actions to it and see if that stops people. Be very clear why they are being warned: "Please be extremely careful when moving pages in the Index or Page namespace if you are not an administrator. Non-administrators cannot suppress redirects, which means you cannot move other pages to where the moved page used to be. Moved index pages that have any existing sub-pages need to have the orphaned redirects deleted. It's much easier to ask an admin to do this (at WS:AN) directly rather than asking them to tidy up after a move with redirects left behind." Inductiveloadtalk/contribs 23:08, 2 June 2021 (UTC)[reply]
Yeah, that looks good. And I think a warning is the right level for this, at least to start. We have a relative frequent occurrence of people that create a new index after goofing the file name of the first, so the opposite problem is also relevant (it just has smaller consequences). Xover (talk) 06:06, 3 June 2021 (UTC)[reply]
Ok, Special:AbuseFilter/36 will now warn the user with MediaWiki:Abusefilter-warning-Non-admin Index-Move, then allow the user to continue (but also tag the edit). Inductiveloadtalk/contribs 18:01, 4 August 2021 (UTC)[reply]

Mediawiki:Watchlist-announcements[edit]

As administrators we need to make better use of our general means of announcements to our community, especially where we have either a significant proposal or have made a significant change to policy and templates, and want to capture all our users, and spasmodic users. We have all been pretty rubbish at that general comms in the past while and I think that we should at least think about what we want to better broadcast. — billinghurst sDrewth 09:02, 4 July 2021 (UTC)[reply]

This is just the banner that shows up above the watchlist correct? I think that's reasonable. Is there anywhere else we should be remembering to post such content - mailing lists, social media, etc? —Beleg Tâl (talk) 01:47, 7 July 2021 (UTC)[reply]
Correct, and it is persistent. As it is watchlist, only logged in users, and they can dismiss it once read. Wikisource-L, Twitter: @wikisource_en are possibles for some things. My reason for the watchlist is that it is our editors, and it is persistent, so very targeted, and low noise threshold. — billinghurst sDrewth 03:46, 7 July 2021 (UTC)[reply]
Huh, I had utterly forgotten Wikisource-l existed! Twitter seems more like advertising/evangelism than operational notices (one fine day a New Texts bot can post there!). Inductiveloadtalk/contribs 06:34, 7 July 2021 (UTC)[reply]
Indeed. Please don't post RfC or policy discussion notices to Twitter! Xover (talk) 07:02, 7 July 2021 (UTC)[reply]
Amen! And especially since low participation is a much bigger problem in our policy/rfc type discussions than excessive numbers of comments or discussions. The better attended a given discussion is the stronger any resulting consensus will be, and, if we do it right, the better it will reflect the position of the community as a whole. Xover (talk) 06:46, 7 July 2021 (UTC)[reply]

move requests[edit]

I am posting at Wikisource:Scriptorium#Repairs_(and_moves), but no one seems to be monitoring it. CYGNIS INSIGNIS 04:09, 9 August 2021 (UTC)[reply]

Import help[edit]

Please import books listed at Wikisource:Requested_texts#Import_5_books_about_Malayalam_language. These books were written for English speakers to learn Malayalam words, and the definitions are all in English. Thank you. Vis M (talk) 00:15, 20 August 2021 (UTC)[reply]

This doesn't require an administrator. Probably better requested at Wikisource:Scriptorium/Help if you are looking at assistance in how to do these. — billinghurst sDrewth 00:26, 20 August 2021 (UTC)[reply]
I think only admins and importers can do interwiki-import while preserving page history. Special:Import gives permission error for me. Vis M (talk) 11:50, 20 August 2021 (UTC)[reply]
Apologies, I misunderstood the request as you were referencing requested texts.
If you have those works at mlWS, why would we import them here? Is mlWS planing on deleting it? We can simply link to the work where it is now, if the work is within scope at mlWS. FWIW no one has import rights to bring works from mlWS to enWS, and from memory our 'crats cannot allocate the right. I think that we need to step right back and work out what it is that is needing to be done, and what is the appropriate place for the work, as it may be be situated at mulWS if it is not to be hosted at mlWS. — billinghurst sDrewth 13:24, 20 August 2021 (UTC)[reply]
Those are books about Malayalam language written for English readers/audience. mlWS will not delete it, it is indeed with in its scope. I think enWS also can have it here as its target audience is English language readers. Vis M (talk) 01:55, 22 August 2021 (UTC)[reply]
Hi, adding my 2c here—from briefly skimming through the texts, a significant portion of the texts appears to be in Malayalam. The may be within the scope of enWS since it's written in English and uses Malayalam words with context. The other works are more dicey—a significant amount of text is in Malayalam, which might warrant it being hosted on mulWS as opposed to enWS. On the other hand, works such as Index:Tamil studies.djvu also have a significant amount of text in another language (Tamil, in this case) which I would've expected to have been hosted on mulWS instead.
Is there a formal guideline of sorts that gives an idea of how much non-English text in a work is alright for a work hosted on enWS? Off the top of my head I'd say texts which use non-English words and phrases sparingly could be hosted here, but I can't really think of anyplace this has actually been mentioned. WS:Language policy redirects to WS:Translations, which doesn't have any info regarding this. C. F. 23:38, 24 August 2021 (UTC)[reply]
@User:Clockery Works that are literally half non-English (as in a side by side translation), and works such as a English-(non-English) dictionary seem to be considered 'obviously' in scope by the community here, so the bar where things start being problematic is pretty low. I think if the work is 'usable' to an English language reader, it's probably fine here. That being said, it would probably be easier to maintain just one place, and use an interwiki link. Jarnsax (talk) 00:34, 25 August 2021 (UTC)[reply]
My understanding is that multi-lingual works were in the aegis of mulWS, and that typically works were hosted at one wiki. There are some works that are side-be-side, English/another language, and those have split and are respectively imported using the series explained at Template:Iwpage. It was why I mentioned mulWS, in my initial response. — billinghurst sDrewth 00:51, 25 August 2021 (UTC)[reply]
Pictogram voting comment.svg Comment One thing we probably want to eventually sort out is mainspace presentation and export of works using {{iwpage}}. Since the content is loaded by JS in the page namespace, it doesn't work on transclusion and it therefore won't work on export. Which is a big shame for things like Loeb Classical Library since that's kind of the whole point.
I don't have any immediate idea about how to deal with this (other than throwing up hands and doing it all at enWS!), but I have a sneaking suspicion we'll need at least some server support (either from MW, the export tool, or both). And we'll also likely need to figure out a One True Way to format side-by-side texts in a flexible, exportable and generally not-horrific way. Inductiveloadtalk/contribs 06:12, 25 August 2021 (UTC)[reply]

On the general subject, we need clearer rules on this, and those rules shouldn't dissociate us from stuff like the Loeb Classical Library, which is the modern collection of Latin & Ancient Greek works in English. There's a lot of translated material only available in bilingual editions, and that needs to be clearly accessible from here.--Prosfilaes (talk) 20:13, 25 August 2021 (UTC)[reply]

I'd like to hear from mulWS (@Zyephyrus, @Ankry, @VIGNERON: as some representatives) on the hosting of dual language works. We we can link to works easily, though it doesn't show up in our searches. I would also be happy to place {{interwiki redirect}}s at the titles (and we can work out WD later). I don't really want to duplicate works as 1) they are dynamic in our proofreading space, 2) they will typically have different templates, 3) duplication is unneeded. — billinghurst sDrewth 00:00, 26 August 2021 (UTC)[reply]
Here are some examples:
For instance, this book: Latin text and English indications, useful on both. Do we place it on mul.ws?--Zyephyrus (talk) 12:59, 28 August 2021 (UTC)[reply]
Or this one, Ancient Greek and French, might be on mul.ws and offer links to both fr.ws and el.ws.
I admired the work of VIGNERON on br.wikisource with the {{iwpage|fr}} template used to show the French text}}. All these bilingual or multilingual texts would be moved to mul.ws. Do you think this a good solution ? There would be one place and only one to keep these kinds of documents. Would it be convenient and appropriate for all of them? --Zyephyrus (talk) 21:37, 28 August 2021 (UTC)[reply]
I haven't really given this a lot of thought, so I may be way off base and end up completely changing my mind… But my immediate thought is that iff we're to delegate something to mulWS we should explicitly take it out of scope (as in not permitted by WS:WWI) for enWS. To say we permit something but it should mostly be done at mulWS seems unworkable; and having content here that is actually managed at mulWS is untenable (different policies, different practices, different culture; no visibility on watchlists, etc.).
I also generally agree with Prosfilaes' stance above, but reserve the right to modify that due to technical or practical realities.
I suspect that a really good solution to this would require software support so that a given Page:-namespace page can more easily exist at multiple projects at once. And I don't think that is likely to occur in any reasonable timeframe. Xover (talk) 08:11, 29 August 2021 (UTC)[reply]

Pictogram voting comment.svg Comment Links Template:iwpage/Special:WhatLinkshere/Template:iwpage (which is essentially the same at each wiki and s:br:Special:WhatLinkshere/Template:iwpagebillinghurst sDrewth 14:10, 29 August 2021 (UTC)[reply]

Spamming as a block reason[edit]

We don't actually mention spam/promoting external linking as a blocking reason at Wikisource:Blocking_policy. Should we? I am extremely unsympathetic to it (i.e. an indef block is completely reasonable in my mind, because they users are clearly not interested in productive contributions), but I also don't want to act against policy. Inductiveloadtalk/contribs 07:51, 21 September 2021 (UTC)[reply]

  • Support, it should be mentioned there so that the policy was in accordance with the practice. --Jan Kameníček (talk) 08:58, 21 September 2021 (UTC)[reply]
  • It depends on the type of spam. If it's bot-spam, then instant indefinite block. If the spam and the user name are linked, then it's a spam-only account and also gets indef'd. If it's an apparently real human who has linked their user page to something spam-ish, then I tend to remove the spam and use the {{spam}} template on their talk page and not block, at least initially. If it continues to be added, then a short block. The majority of what I've seen in the last few months comes into the earlier categories. Beeswaxcandle (talk) 09:55, 21 September 2021 (UTC)[reply]
  • I classify spam as vandalism. HARD SPAM block, includes machine-generated / bot spam which has zero place here and those accounts should be totally infinitely blocked. Real person-generated spam has a broader range, and as BWC says there can be a range of responses, from HARD SPAM blocks, and SOFT SPAM deletion and warnings, etc. If you can capture that into some words, then go for it. I don't block talk pages typically so they can always appeal a block, knowing that spambot-generated won't appeal, and is usually main or user: ns, though very occasionally user talk: ns. So if we mention we need wriggle room for the admin in use of the tool, and definitely allow real users to appeal on their user page (maybe mention {{unblock}}). — billinghurst sDrewth 08:49, 26 September 2021 (UTC)[reply]
  • I support having this as a reason to block. Having the basis in policy does not always need to result in its implementation, if another solution is available. BD2412 T 07:05, 27 September 2021 (UTC)[reply]
  • I agree with what others have said. Spam that requires a block is already covered under things like Vandalism and Bots, and the rare spam that isn't covered this way should be handled more gently. That being said, WS:BP also supports this perspective ("polite communication with the user should be the first action, and blocking a last resort"), and it would not hurt to clearly identify Spam in our policy, whether as part of our definition of Vandalism or as its own heading. —Beleg Tâl (talk) 13:59, 27 September 2021 (UTC)[reply]
    • Also, it seems to me that a change to an Official Policy should be discussed on the Scriptorium for maximum community input. Can we move the discussion there, or are we just confirming interest at this point? —Beleg Tâl (talk) 14:01, 27 September 2021 (UTC)[reply]
      I was guessing sounding; and to be followed by a set of words to WS:S. — billinghurst sDrewth 14:10, 27 September 2021 (UTC)[reply]
      Indeed, just wanted to check first. Formal proposal now open at WS:S#Blocking policy regarding spammers. Inductiveloadtalk/contribs 09:29, 28 September 2021 (UTC)[reply]

Category:External links on protected pages & Category:Templates used in Mediawiki namespace[edit]

We have a bit of a maintenance issue in that external links in protected templates and mediawiki: ns are being missed when we are updating links. To assist, I have created the above parent tracking category to label such pages. We obviously cannot use it on Mediawiki: pages, so will have to be content with putting it on the corresponding talk page. I am working through creating subcats for each WMF tool that I find as they are more likely need to be what is changed, and will do some checks. I will note that as some of these pages use conditional code or includeonly so may be a little tricky to find by searching. [Reminder to not unnecessarily hide things to just avoid visual errors in non-display namespaces or ugly display code.] I am hoping that this will also allow us to check these a little more easily as we have suffered some link rot. I think that we may also need to put some checking categories on these so we can at least check these yearly, though haven't got that far and welcome people's thoughts.

I have also identified that we have had some templates transcluded to the mediawiki: ns that have not been protected. Can I express that any such templates need to be fully protected. If you are using a template within another template, then all subsidiary templates also need to be protected. Noting that it often it can be safest to simply use html span and div code and embedded css.

On that note, if we are protecting templates, it is better practice to use separate {{documentation}} so the docs can readily updated without someone asking for editing of protected templates. This is not pointing fingers, as some of these are old static pages that don't readily get traffic, and reflect older generation practices.

I welcome any suggestions/feedback here, and any help perusing of the template: and mediawiki: namespaces for targets. — billinghurst sDrewth 08:39, 26 September 2021 (UTC)[reply]

Seems we already have Category:MediaWiki namespace templates, I will transition to that and update categories. — billinghurst sDrewth 10:07, 26 September 2021 (UTC)[reply]

Import request for {{Date}}[edit]

I'd appreciate it if {{Date}} could be re-imported from commons:Template:Date. That's where it came from initially, but the version at Commons has changed a lot (and works a lot better). Thanks! —CalendulaAsteraceae (talkcontribs) 06:51, 13 October 2021 (UTC)[reply]

@CalendulaAsteraceae: {{date}} and its underlying Module:Date are problematic due to naming conflicts between the Commons version and the enwp version. It's on my todo list to resolve this, but it's going to take quite a bit of research and migration of other templates/modules so I haven't found the time yet. Xover (talk) 08:13, 24 October 2021 (UTC)[reply]
@Xover: That makes sense; thank you! It's certainly not urgent. —CalendulaAsteraceae (talkcontribs) 08:30, 24 October 2021 (UTC)[reply]
@CalendulaAsteraceae: {{date}} has now been re-synced from Commons. Xover (talk) 18:08, 26 October 2021 (UTC)[reply]
@Xover: Thanks you so much! —CalendulaAsteraceae (talkcontribs) 02:54, 27 October 2021 (UTC)[reply]
Just to note, this mess was generating too many issues so I've started in on trying to resolve it. It's probably going to take some time to complete, and breakage is expected while it's going on. If you run into issues related to dates, possibly accompanied by big red Lua errors, please let me know. Xover (talk) 17:52, 26 October 2021 (UTC)[reply]
Ok, all the issues I've been able to identify have been fixed. Module:Date is now w:Module:Date, and Module:DateI18n is c:Module:DateI18n (these are both in line with what other projects do). The custom code that was in Module:Date has been split out to Module:Era and Module:Author has been migrated to use that instead.
I'm not aware of any linger breakage from this, but there's a lot of obscure interdependent code in this area so I can't guarantee there isn't something remaining. The most likely and visible place to keep an eye out is in automatically added date-based categories for authors, but anything date based could potentially have been affected. Please let me know if you run across something. Xover (talk) 18:44, 27 October 2021 (UTC)[reply]

Requesting import of commons:Template:Cc-by-sa-3.0-de[edit]

commons:Template:Cc-by-sa-3.0-de is used on File:Governance across borders.pdf and doesn't seem to be here. Thank you! —CalendulaAsteraceae (talkcontribs) 06:20, 24 October 2021 (UTC)[reply]

@CalendulaAsteraceae: We can't import Commons' license templates here directly for technical reasons (they have a whole jerry-rigged i18n/l10n setup for their templates). But do we really need a -de specific CC BY-SA? I thought the CC licenses were interchangeable? Xover (talk) 07:44, 24 October 2021 (UTC)[reply]
@Xover: That does seem to be the case; thanks for catching that. —CalendulaAsteraceae (talkcontribs) 08:33, 24 October 2021 (UTC)[reply]

South Carolina Exposition and Protest[edit]

Please lock this page—frequent IP-based vandalism. TE(æ)A,ea. (talk) 15:05, 5 November 2021 (UTC)[reply]

Eh. By request, I put a one-day autoconfirmed users only protection on it. I'm not sure it really needed even that.--Prosfilaes (talk) 20:59, 5 November 2021 (UTC)[reply]

Author:Joanne Kathleen Rowling[edit]

Administrator-protected page, thus this request. The pages shows a death date of “fl. 2021,” which is not appropriate in this case because she is still alive and known to be so. TE(æ)A,ea. (talk) 21:39, 9 November 2021 (UTC)[reply]

This is not something special about Rowling: it's because she has a Wikidata floruit (P1317) property set. (see d:Q34660#P1317). Any author with no death and a floruit date will come out like this. It's done in Module:Author#L-133. Based on WD's property description date when the person was known to be active or alive, when birth or death not documented, it sounds like this just should not be set. As is traditional at WD, I can't find clear info on about it (d:Wikidata:Project_chat/Archive/2020/06#floruit_(fl.), the last linked discussion on the Property talk page, is not very helpful). 22:20, 9 November 2021 (UTC) Inductiveloadtalk/contribs 22:20, 9 November 2021 (UTC)[reply]
Yes check.svg deprecated I am comfortable to deprecate that property on the item as it is not a regular addition to items. — billinghurst sDrewth 22:29, 9 November 2021 (UTC)[reply]

Move request[edit]

Could Index:United Nations Resolution No. 69-131 (International Day of Yoga).djvu and Page:United Nations Resolution No. 69-131 (International Day of Yoga).djvu/1 be moved to Index:United Nations Resolution No. 69-131 (International Day of Yoga).pdf and Page:United Nations Resolution No. 69-131 (International Day of Yoga).pdf/1 respectively? The DJVU file isn't showing up right on Wikisource, and this means transclusion using <pages /> doesn't work at United Nations Resolution No. 69-131 (International Day of Yoga). —CalendulaAsteraceae (talkcontribs) 23:28, 21 November 2021 (UTC)[reply]

Yes check.svg Done something is very wrong with that DjVu indeed! Inductiveloadtalk/contribs 23:38, 21 November 2021 (UTC)[reply]
Thank you! —CalendulaAsteraceae (talkcontribs) 00:09, 22 November 2021 (UTC)[reply]

Move request for Aunt Jo's Scrap-Bag[edit]

At the moment, the volumes for this work are at separate root pages:

  1. Aunt Jo's Scrap-Bag, Volume 1
  2. Aunt Jo's Scrap-Bag, Volume 2
  3. Aunt Jo's Scrap-Bag, Volume 3
  4. Aunt Jo's Scrap-Bag, Volume 4
  5. Aunt Jo's Scrap-Bag, Volume 5
  6. Aunt Jo's Scrap-Bag, Volume 6

I'd like these pages, and their many subpages, to be moved to subpages of Aunt Jo's Scrap-Bag (Aunt Jo's Scrap-Bag/Volume 1 etc.). Thanks! —CalendulaAsteraceae (talkcontribs) 06:16, 23 November 2021 (UTC)[reply]

@CalendulaAsteraceae Yes check.svg Done . Chalk up another one from User:Inductiveload/false root pages ^_^. Inductiveloadtalk/contribs 18:26, 3 December 2021 (UTC)[reply]
Thank you! —CalendulaAsteraceae (talkcontribs) 01:26, 4 December 2021 (UTC)[reply]

Pge/Index resynch request...[edit]

Affected Page's

The scans concerned were renamed at Commons, meaning these Page: s needed to be resynched with the renamed Index. ShakespeareFan00 (talk) 23:45, 2 December 2021 (UTC)[reply]


Also as whole Index:-



I think a more closer examination of Index/Uploads by the relevant contributor might be needed, to fully resync everything properly. ShakespeareFan00 (talk) 16:27, 3 December 2021 (UTC)[reply]

Doing... . But please in future express an index moves simply with all of the following:
  • old index
  • new index
  • list of pages ranges to move (e.g. 1-12, 637-639 is sufficient), or all pages (and ideally, note if there are no pages)
  • page offset (0 if the same page numbers).
If (and only if) you are requesting a shift within an existing index, the new index is omitted.
Not doing this wastes the time of the person doing the move and also make mistakes more likely as there is no built-in double-check. Inductiveloadtalk/contribs 16:36, 3 December 2021 (UTC)[reply]
Ok, I think they're all Yes check.svg Done . Inductiveloadtalk/contribs 17:22, 3 December 2021 (UTC)[reply]

Index move request for Index:Works_of_Plato_his_first_fifty-five_dialogues.pdf[edit]

Per the instructions for requesting an Index move.

Reason for move : Renamed at commons per (Commons file renaming criteria 4) - Harmonisation of naming for multi-volume set.

ShakespeareFan00 (talk) 09:11, 4 December 2021 (UTC)[reply]

(Aside: Would it be possible to have a query or database report which identifies Index: pages whose title is different from the filename used at Commons, or where the nominal File: page is a redirect?) ShakespeareFan00 (talk) 09:11, 4 December 2021 (UTC)[reply]

Yes check.svg Done Thank you for the clear instructions.
There might be a way to find such cases, I'll have a think. Inductiveloadtalk/contribs 10:41, 4 December 2021 (UTC)[reply]

Pages move request for Index:Hvd-hnjwfx-1638317588.pdf[edit]

Pursuant to the instructions for requesting an index move.

  • Move type: Pages only move. Index already re-titled?
  • Old name: Index:Hvd-hnjwfx-1638317588.pdf
  • New name: Phaedon (Dacier, 1833).pdf
  • Extant Pages:1-2, 218-223
  • Offset: 0

Reason for move : Retitled file. ShakespeareFan00 (talk) 19:07, 4 December 2021 (UTC)[reply]

Yes check.svg Done , sorry about that. Inductiveloadtalk/contribs 20:27, 4 December 2021 (UTC)[reply]

Move request: Author:John Curtis (entomologist) to Author:John Curtis[edit]

Requesting this here since I created Author:John Curtis and only then noticed that Author:John Curtis (entomologist) existed, so I can't make the move myself. —CalendulaAsteraceae (talkcontribs) 01:09, 12 December 2021 (UTC)[reply]

@CalendulaAsteraceae Yes check.svg Done . Inductiveloadtalk/contribs 19:08, 14 December 2021 (UTC)[reply]
Something very strange happened here - it looks like it followed its own redirect several times while deleting. I think it's sorted out now. Inductiveloadtalk/contribs 21:55, 14 December 2021 (UTC)[reply]

Possible to delete a string of pages?[edit]

Is it possible to delete pages 64 to 103 of this index? Index:Recollections of My Boyhood.djvu

Somehow the match & split got off by one page, so all of these matched the wrong text. If deleting this subset is not possible, maybe delete all pages, and I will redo the match? -Pete (talk) 19:01, 14 December 2021 (UTC)[reply]

@Peteforsyth I did you one better and just shifted the page range up by one. :-) Inductiveloadtalk/contribs 19:06, 14 December 2021 (UTC)[reply]
Fantastic, thank you! -Pete (talk) 21:17, 14 December 2021 (UTC)[reply]

Block Page move Request for Index: Oregon Historical Quarterly volume 21.djvu[edit]

Cannot create page — "Image abuser"?[edit]

Hello, I am trying to update the page I Am a Cat by adding its third chapter. When I try to submit the edit, however, I am told that the edit was automatically recognized as malicious, and therefore not saved. The only information I am given is: `Image abuser (import of global AF/219)`. I don't understand what this means, as my edit contains no image at all and I am simply trying to post a chapter of prose; nor do I (as far as I know) have a history of image abuse, whatever that might entail. Please let me know if there is anything that can be done. Edit: to add more detail, I am able to post the entire content I intended to upload if that would help in identifying the problem. Kiril kovachev (talk) 22:37, 17 December 2021 (UTC)[reply]

@Kiril kovachev This is a filter that was implemented (I think, I wasn't an admin then) in response to a LTA that had certain unique signatures in the text combined with accounts with under 5 edits (this is why you hit it). Since the LTA in question seems to have gone away, I have changed the filter to allow edits and just tag for review in case they come back. You should be able to make the edit now. Sorry for the inconvenience. Inductiveloadtalk/contribs 22:49, 17 December 2021 (UTC)[reply]
Thanks very much for your quick response! And indeed, I was able to edit without a problem. Thanks again for your help, and have a good day :) Kiril kovachev (talk) 22:55, 17 December 2021 (UTC)[reply]
@Kiril kovachev thank you for your contribution to Wikisource! :-) Inductiveloadtalk/contribs 22:56, 17 December 2021 (UTC)[reply]

Request to move a page with subpages[edit]

Could someone please move this page, along with its subpages?

Route across the Rocky Mountains with a Description of Oregon and California

to

Route across the Rocky Mountains with a Description of Oregon and California (Ye Galleon)

(or a better title if that's incorrect; maybe (1982) is a better way to disambiguate?)

I'd like to make a "versions" page at the current title. I didn't properly understand Wikisource's approach to different editions when I first set up these pages. -Pete (talk) 23:17, 17 December 2021 (UTC)[reply]

Yes check.svg Done (to Route across the Rocky Mountains with a Description of Oregon and California (1982)). I updated the TOC, but please check for other broken links, etc. Inductiveloadtalk/contribs 23:25, 17 December 2021 (UTC)[reply]

Abuse filter false positive[edit]

This is a private filter so I won't describe it in detail, but on my en.wp talk page I had a complaint from Andrzejbanas that the abuse filter had blocked them for reporting harassment of them. The log is here: Special:AbuseLog/145862.

Is this part of the filter still needed or could it be relaxed? BethNaught (talk) 10:18, 3 January 2022 (UTC)[reply]

@BethNaught (CC Andrzejbanas): This filter was triggering on a slightly too generic string that it is probable that innocent users would be caught by, as demonstrated by the current case. I've removed the relevant condition so this should now hopefully no longer happen, and my apologies that you got caught up in it. I have also applied indef semi-protection on your user and user talk page. Feel free to ask for its removal here if you should ever become active on enWS (or for whatever other reason). Xover (talk) 10:58, 3 January 2022 (UTC)[reply]
Haha. Totally fine, i was curious what I did that might have done that. Thanks for setting it up. Andrzejbanas (talk) 18:32, 3 January 2022 (UTC)[reply]

Edit request for protected page[edit]

I'd like to request an edit on Shaving Made Easy/Chapter 14, to transition it to transclude using the <pages /> tag rather than the {{page}} template. Since it's protected, I'm making the request here. The content I'd like the page to have is

{{header
 | title      = [[../]]
 | author     = 
 | translator = 
 | section    = Chapter XIV.
 | previous   = [[../Chapter 13|Chapter XIII.]]
 | next       = [[../Chapter 15|Chapter XV.]]
 | notes      = 
}}

<div class="pagetext" style="text-indent:1em;">
<pages index="Shaving Made Easy 1905.djvu" include=65 />
{{page break|label=}}
<pages index="Shaving Made Easy 1905.djvu" include=66 />
{{page break|label=}}
<pages index="Shaving Made Easy 1905.djvu" include=67 />
{{page break|label=}}
<pages index="Shaving Made Easy 1905.djvu" include=68 />
{{page break|label=}}
<pages index="Shaving Made Easy 1905.djvu" include=69 />
{{page break|label=}}
<pages index="Shaving Made Easy 1905.djvu" include=70 />
{{page break|label=}}
<pages index="Shaving Made Easy 1905.djvu" include=71 />
{{page break|label=}}
<pages index="Shaving Made Easy 1905.djvu" include=72 />
{{page break|label=}}
<pages index="Shaving Made Easy 1905.djvu" include=73 />
{{page break|label=}}
<pages index="Shaving Made Easy 1905.djvu" include=74 />
{{page break|label=}}
<pages index="Shaving Made Easy 1905.djvu" include=75 />
{{page break|label=}}
<pages index="Shaving Made Easy 1905.djvu" include=76 />
{{page break|label=}}
<pages index="Shaving Made Easy 1905.djvu" include=77 />
</div>

Thank you! —CalendulaAsteraceae (talkcontribs) 04:11, 17 January 2022 (UTC)[reply]

@CalendulaAsteraceae: Yes check.svg Done Xover (talk) 07:38, 17 January 2022 (UTC)[reply]
Thank you! —CalendulaAsteraceae (talkcontribs) 07:40, 17 January 2022 (UTC)[reply]

Edit request for MediaWiki filter[edit]

I've been going through pages with defaultsort conflicts, and it occurred to me that this would be easier if there were a category analogous to Category:Authors with DefaultSort error. So I'd like to request that Category:Works with DefaultSort error be created and added to MediaWiki:Duplicate-defaultsort. Thank you! —CalendulaAsteraceae (talkcontribs) 09:43, 17 January 2022 (UTC)[reply]

@CalendulaAsteraceae Yes check.svg Done . This is a good idea, because the current (anti-)pattern of explicit DEFAULTSORTs makes it impossible to do this automatically in the header template (i.e. strip of "A/The" if present). This cat gets us a small step closer to being able to strip most of them out as redundant. Inductiveloadtalk/contribs 10:12, 17 January 2022 (UTC)[reply]
@CalendulaAsteraceae also I have added the defaultsort parameter to {{header}}.
The task now is to transition all the manual defaultsorts to either that parameter, or, for most(?) of them, do it by stripping A/An/The in the Lua function. I'm not sure the best way to move forward, but one way would be:
  • Temporarily hide the warning text in MediaWiki:Duplicate-defaultsort in mainspace (leave it enabled in other namespaces), but leave the category
  • Enable the auto-sorting (i.e. stripping of A/An/The) in Lua
  • All the mainspace pages with conflicting sort keys will then drop into the category, but won't spew big red errors
  • The category can be processed (probably with some kind of script, since most of the conflicts are likely "Foo, A" vs "Foo" and easy to handle
  • Once the category is empty, strip the rest of the DEFAULTSORTs, since if they're not throwing errors they must be redundant.
  • Now the pages are transitioned to the parameter, reinstate the warning text
This is not the only way to do it: you could also
  • Migrate all explicit DEFAULTSORTS in mainspace to the defaultsort parameter, then enable auto-sorting and then go back over all pages and remove redundant keys, or
  • Migrate all explicit DEFAULTSORTS in mainspace to the defaultsort parameter, but just delete any which will become redundant, then enable auto-sort. This will have short period when some pages will sort by their "A/An/The".
Anyway, let me know if you need any more edits to facilitate whichever method you prefer! Inductiveloadtalk/contribs 10:53, 17 January 2022 (UTC)[reply]
@Simon Peter Hughes: You do a lot of work in this area. Do you have any input here?
@Inductiveload: Not sure whether it's relevant, but keep in mind that we have some bad habits involving not bothering with the full title in defaultsort so long as the string used will kinda sorta sort properly mostly. Also, the sortkey should include any article stripped at the end so that titles that differ only in the article will sort correctly among themselves. Also, we have a lot of garbage data in title fields that we probably don't want to throw unprocessed into the magic word. Hmm. And then there's the "Sort key" field in the Index: that could maybe be used for something here… Xover (talk) 12:49, 17 January 2022 (UTC)[reply]
@Xover putting the article at the end is indeed how Module:Auto sort does it, which is what I would suggest Module:header eventually could use. The current manual ones are done both with and without, e.g. A Dictionary of Music and Musicians, which is literally the first result for insource:DEFAULTSORT that begins with an article.
The least "exciting" way would be to continue to use the subpage name, rather than the title parameter, because that won't change too much. If we wanted to use the title parameter, or inhale from an index page (rather hard, since most header invocations do not know what the index is), that would be a next step.
The first steps will have to be removing the manual DEFAULTSORTs, since, because none of them have been set with noerror or noreplace, it's impossible to do anything at all until they are changed to template params (or bot through and add noerror/noreplace, which is yet another option for moving forward). There are 132k+ instances, so it's going to be pretty painful whatever happens (and that's why I have never bothered to address it myself). Inductiveloadtalk/contribs 13:08, 17 January 2022 (UTC)[reply]
@Inductiveload: Thank you! I don't particularly have a preference among the different ways of transitioning pages to use the defaultsort parameter. I do have an edit request, though—could you add | defaultsort = {{{defaultsort|{{SUBPAGENAME}}}}} to the header in {{A catalogue of notable Middle Templars, with brief biographical notices}}? Pages in that work had been putting manual DEFAULTSORTs on each page, and I removed that from the preload. —CalendulaAsteraceae (talkcontribs) 02:32, 18 January 2022 (UTC)[reply]
No, please don't do that. There is nothing wrong with individual defaultsort, and it was purposeful to not have it in the template. Having a hidden defaultsort can be problematic. — billinghurst sDrewth 11:00, 18 January 2022 (UTC)[reply]

Move request Wittgenstein[edit]

About 200 pages from Index:Wittengenstein - Tractatus Logico-Philosophicus, 1922.djvu need to be moved to Index:Wittgenstein - Tractatus Logico-Philosophicus, 1922.djvu. Greetings Bigbossfarin (talk) 14:16, 19 January 2022 (UTC)[reply]

Yes check.svg Done , and the transclusion at Tractatus Logico-Philosophicus also updated. Inductiveloadtalk/contribs 15:02, 19 January 2022 (UTC)[reply]

74.75.9.45[edit]

Please block this user—vandalism. TE(æ)A,ea. (talk) 21:02, 19 January 2022 (UTC)[reply]

Yes check.svg Done Inductiveloadtalk/contribs 21:12, 19 January 2022 (UTC)[reply]