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

WMF Board reform

Wikisource editors may be interested in the m:2025 WMF Board reform petition. Clovermoss (talk) 03:57, 11 October 2025 (UTC)

Proposals

Deleting author pages with populate

I can't find any page that clearly lists our requirements for Author pages. I'm going to suggest a new one, despite that. Instead of just tagging a page with Populate, we delete them. That simplifies some discussions, like Author:Herod Antipas and Author:Marcus Antonius, who may or may not have extant writings. Others, like Author:Anne do have a Works About section, but are they really authors if no one can identify even one work they wrote? That should go to a portal page. There's a number that should be improved: Author:S. E. Birrell should actually list known works, since they were created for Punch/Volume 148/Index to link to.

Since we decided that an author without English works available for transcription should be deleted, I'd point out that many of these may be in that list, e.g. Author:Isaac Commelin, an obscure Dutch author whose EN Wikipedia page lists no English titles.

I am not suggesting that we suddenly delete every author in Category:Authors with no works, but it could be an easy clean up project, and I'd say actually listing a work available in English is a low but useful bar for an author page.--Prosfilaes (talk) 22:09, 10 August 2025 (UTC)

I think as long as there is at least one scan hosted here or on c: that we can include with {{ssl}}, then it's worth keeping because that serves the basic function of a library by at least pointing someone to a work that can be read. And when it comes to non-English authors, a page should really only be created if someone is willing to put forth the effort to provide a local translation. If someone really wants to introduce to the world a freely-licensed English translation of something by Isaac Commelin, then that's lovely. Otherwise, I agree that this is a sensible proposal. —Justin (koavf)❤T☮C☺M☯ 22:15, 10 August 2025 (UTC)

All I'm asking is that someone list a work, even without scan. As for translations, we had a long discussion on Wikisource:Proposed_deletions/Archives/2025#Author:Ivan_Rakovskyi.--Prosfilaes (talk) 00:40, 11 August 2025 (UTC)

Even in the case of author pages that perhaps have no English works, someone might at some point translate one of their non-English works (we have sections for that here even). And even if that never happens they might be a written about, etc. As such I expect a much better solution would be to convert author pages that perhaps should not be author pages to portal pages. We already have tons of portal pages for people. Unless an author pages is really entirely erroneous, I do not see the need to have it deleted. Just move it from Author to Portal. Here are a few recent examples: Portal:James Joseph Norton I and Portal:Leif Jensen. I do not think it would be very hard to move and convert an author page to such a format (mostly just {{author}} to {{person}}). —Uzume (talk) 07:59, 20 August 2025 (UTC)

See the long discussion I linked. I argued for keeping an author page that had scan-backed transcriptions on other Wikisources that could be used for a translation, and the consensus went against me. The status quo on this Wikisource is that we delete author pages without any English works. If you want to change that status quo, that's a discussion for a different proposal.--Prosfilaes (talk) 21:54, 20 August 2025 (UTC)

@Prosfilaes: I am not particularly interested in arguing for such a thing as they can just be converted to portal pages. —Uzume (talk) 15:29, 21 August 2025 (UTC)

I'm open to this idea, but would like to hear additional opinions before supporting it strongly. --EncycloPetey (talk) 22:23, 10 August 2025 (UTC)

The general principle (that is, going through that list and either populating or deleting) seems good to me. And {{populate}} has indeed been applied much too widely for sudden deletion. 3k pages is quite a backlog, though, especially considering that proper author research is time-consuming; so I wouldn't call that an easy clean up project. As we've seen in various discussions, answering the question "are there English texts by this author in PD?" is hard. So that's a general support from me but we'd need to discuss further the details of organisation (e.g. among others: how deletion is requested: individually with {{sdelete|G5}}? individually on WS:PD? in a single round trip at WS:PD?). — Alien  3
3 3 22:44, 10 August 2025 (UTC)

Part of my goal is that we don't necessarily need to ask "are there English texts by this author in PD?". It's good that we do, but the creator of the page should do it.Prosfilaes (talk) 00:40, 11 August 2025 (UTC)

I was expecting to have objections to that, but come to think of it, I don't really. I just can't think of a case of author page with no indications of contribution to works in scope, that it would actually benefit us to keep. So I agree. — Alien  3
3 3 13:44, 11 August 2025 (UTC)

I do have an objection to this. This is especially problematic for works with many authors. I often have to spend considerable time fleshing out author stub pages while also developing such a work and them go back and list each authors contribution later. The sort of requirement this proposal is vying for makes such things considerably harder so I am very much against that. now in addition to developing enough details to get a good author page made I also have to fill out some stub of an accredited work before I even have the work more developed. A good example of this is Index:From servitude to service; (IA fromservitudetos00ogde).pdf which I have been working on and as a result I stubbed out all the authors so I could link to them. But this proposal means I have to immediate backlink to such before I am done so I cannot link to their actual contributions but some precursor until I complete their contributions. That is why I think this proposal very much sucks and I cannot go along with it. Sure I understand a want to clean up the many outstanding stubbed out author pages, many of which might be highly questionable but please do not make the lives of the cleanup crew easier by making everyone else's considerably harder. —Uzume (talk) 06:48, 20 August 2025 (UTC)

@Uzume: If I understand it right, this is just a temporary problem until the work and the author page are finished. In such a case it can be solved by adding {{Under construction}} to the author page, thus gaining time to finishing it later. --Jan Kameníček (talk) 08:59, 20 August 2025 (UTC)

@Jan.Kamenicek: I am not sure what you are talking about temporary? Are you implying there should be time limits on how long we let people work on things? I have books here I am working on that I started many years ago. Should I not work on them any longer? Should they be deleted because I did not completely them in a timely manner? The very same can be said for author pages. Why should people be required to populate works on them if they works are not completed, etc? I really do not see the need to oust stubbed author pages. Are they temporary? Sure they are—but with an arbitrary amount of time so I am not sure that qualifies for everyone's definition of temporary. —Uzume (talk) 09:34, 20 August 2025 (UTC)

Well, "years" is definitely a long time enough to have the work at least listed in the author's page. It is not necessary to link it to the work whose transcription has not been finished, but it should definitely be listed at least. I was not thinking about a specific time limit before, supposing that we are talking about a few weeks/months at most, but if we talk about years, then some time limit might probably be set (the motivation not being to get rid of the author page but to push the contributors to list the works). --Jan Kameníček (talk) 09:51, 20 August 2025 (UTC)

@Jan.Kamenicek: As an example, I am still working on The Bondman (albeit slowly) despite starting that in 2022. My point it why have time limits on developing author pages if there are no such things for other types of page development? Or perhaps you meant that this proposal should be temporary—as in the proposed speedy deletion criteria should only be available for a year during some major cleanup effort? I am definitely against any long term deletion criteria that limits author page development at whatever pace people wish to develop them at, including incredibly slowly. I am undecided about a temporary criteria that is say only available during a one year project cleanup window type of thing. —Uzume (talk) 17:28, 20 August 2025 (UTC)

I do not get the point. Adding a work to the author page takes very little time, uncomparable with transcription of an extensive work. Besides, incomplete works not fulfilling some basic requirements are frequently deleted too. Listing works to author pages is the most basic requirement, in fact that is why author pages have been introduced to WS at all. --Jan Kameníček (talk) 19:48, 20 August 2025 (UTC)

@Jan.Kamenicek: If it takes so little time, please go clear the backlog quickly. Thank you, —Uzume (talk) 16:56, 21 August 2025 (UTC)

Although I believe you understood my point, I will explain it in detail anyway: creating an author page is easy and fast. Finishing thousands of half-baked pages to get rid of long-time backlog is tiring and lengthy. That is exactly why contributors should create author pages in good shape immediately and not leave it to others later. --Jan Kameníček (talk) 18:48, 21 August 2025 (UTC)

@Jan.Kamenicek: I do not consider "creating an author page is easy and fast" to be true. Typically it involves linking to a Wikidata item which has to be found and/or created and requires an edit on Wikidata to add the sitelink. The Wikidata item should probably contain a minimum of certain things like a name and dates of birth and death and a few basic authority control items. All of those require research if they are incomplete or not already in Wikidata. Then the WS author page can be created and linked to such. Often this coincides with creating at least a category on Commons and tagging some of the author's work into such category. I usually also try to create a Commons Creator page (P1472) via their c:Template:Creator. I do not consider all that work trivial, especially when fleshing out a large number of authors from works like magazine or journal volumes so I find it useful to stub out the authors using {{populate}} so they can be found and linked to locally later when working on such works here. I do find it trivial for people who read such an author stub to either click on the Commons category link provided by the {{plain sister}} in the {{author}} header or the Special:WhatLinksHere link provided by {{populate}} from author page in order to find WMF local copies of the author's work either on Commons or directly linked here. —Uzume (talk) 12:57, 24 August 2025 (UTC)

Don't you do those things anyway, even when creating empty author pages? So if you do it, just list at least one work and that's it, easy. I really do not understand why you have so many problems with making the author page useful and why you insist that others should do it instead of you, thus creating still larger and larger backlog. -- Jan Kameníček (talk) 13:10, 24 August 2025 (UTC)

@Jan.Kamenicek: It places the extra burden to either require one to do that at page creation time when one is concerned about getting all the other items correct or returning to each created page within a short time frame to add such after getting all the pages created. If you think it is a good thing to discourage editors from doing such work, please vote for this proposal. I would rather encourage people to do this type of tricky work by voting against it. —Uzume (talk) 13:15, 24 August 2025 (UTC)

Surprised again that you consider adding very basic content to be "burden". Editors need to be encouraged to create author pages with useful content, and so I am going to vote for the proposal. Jan Kameníček (talk) 13:30, 24 August 2025 (UTC)

@Jan.Kamenicek: I can get behind the encouragement. I cannot get behind the requirement that discourages partial development so I am going to vote against this proposal. —Uzume (talk) 13:43, 24 August 2025 (UTC)

Partial development is listing just a few instead of all elligible works, which is common and encouraged. Empty pages are simply undeveloped and do not belong here. -- Jan Kameníček (talk) 13:49, 24 August 2025 (UTC)

@Jan.Kamenicek: You are entitled to your opinion but I believe there is work in gathering information about an author in order to create a viable author page and to that end consider author pages listing no works as partial development. —Uzume (talk) 14:49, 25 August 2025 (UTC)

@Jan.Kamenicek: FYI: Creating new author pages with {{under construction}} to tell people I am looking for and/or creating translations for English works for an author for an arbitrary period of time/the next several years seems like a much worse solution. Currently that template places such author pages into no category so one would have to use Special:WhatLinksHere/Template:Under construction just to find them. I am actually, okay with that as I prefer Special:WhatLinksHere but I imagine many others would not. —Uzume (talk) 18:19, 20 August 2025 (UTC)

Agree that listing the works, including those whose transcription/translation has only started, is a better solution. --Jan Kameníček (talk) 19:48, 20 August 2025 (UTC)

@Jan.Kamenicek: Yes, that is an obvious answer. It is always better to dump a complete work in a single go too but that seems unreasonable to require such and does not really lend itself to the collaborative environment of a wiki does it? —Uzume (talk) 17:00, 21 August 2025 (UTC)

If you want to have the collaborative environment of a wiki, you don't hide the work. The author page is frequently the way that editors find what works are in progress for an author. Having to click What links here is an unrealistic expectation when it should just be on the page.--Prosfilaes (talk) 00:01, 22 August 2025 (UTC)

@Prosfilaes: I agree such things should eventually end up on the author page but I also believe it is unrealistic to require such of the people developing the author stub pages to begin with. FYI: The 'What links here' link is even provided by {{populate}}. Creating author pages often requires a non-trivial amount of work on Wikidata and Commons. Multiply that when one is creating many author pages for magazine and journal volumes. Placing the extra burden to flesh out at least one item on their author pages at the time of creation will only discourage people from doing such work. —Uzume (talk) 13:11, 24 August 2025 (UTC)

Creating author pages requires no work on other projects. I don't even know what you're referring to on Commons, but many of the new author pages without works also have no Wikidata. I don't put that much work into Wikidata; I add some basic information and ISFDB, but don't go into details.--Prosfilaes (talk) 20:19, 24 August 2025 (UTC)

@Prosfilaes: Well I do put lots of work into Wikidata and have even started a number of projects to improve Wikidata from a EN-WS author pages standpoint. This is in part why I have been working on improving Module:Authority control, e.g., I have a project to dereference all the artificially created WorldCat Identities links here in order to push in WorldCat Entities ID (P10832) in replacement. In many cases this additionally links to works in WorldCat by the author via these identifiers allowing a connection from EN-WS author pages and their works listed in WorldCat. The project also often requires the entry of missing Library of Congress authority ID (P244) values. This benefits EN-WS (e.g., those working to clear the Category:Authors with no works backlog can use those links to help find works by the author that can be listed on their author page) and Wikidata. —Uzume (talk) 15:04, 25 August 2025 (UTC)

Thanks for mentioning Punch vol 148 - I thought I'd already populated the author pages but apparently not! I'll work on that and get it done before the end of August. Qq1122qq (talk) 06:41, 15 August 2025 (UTC)

 Comment—at Wikisource:Proposed deletions#Author:Rafael Grossi there is talk of adding a new CSD criteria for author pages with no indicated works in scope, which may interest participants of this discussion. — Alien  3
3 3 14:42, 18 August 2025 (UTC)

 Neutral, leaning toward  Oppose. It seems to me that the correct action should be to add a list of works, and to only delete the page if that proves impossible. I would, however, be open to more limited proposals, such as (for example) deleting author pages with no works and no incoming links —Beleg Tâl (talk) 19:27, 18 August 2025 (UTC)

FWIW, I've started combing through Category:Authors with no works (so far just Am - Az) and adding a work wherever I can, whether because I see they are an author for the Encyclopædia Brittanica, or they are linked as an author from an Index, or where a Wikipedia article identifies some of their works. The goal here is not to delete a bunch of pages, but to set a minimum theshhold for the creation of new Author pages, and promote a clean-up of those Author pages currently devoid of any listed works. We have nearly 3K pages currently tagged with a template that need to be checked, but those are only the pages that have been tagged. There are likely countless more such pages. A speedy deletion criterion will speed up the process, meaning we don't have to discuss every single Author page that lacks any listed works. "Incoming links" is insufficient cause. I am finding such links where the person was mentioned in a book, but that person has apparently written nothing. --EncycloPetey (talk) 19:54, 18 August 2025 (UTC)

I think this kind of work is great but I also have to agree with Beleg Tâl and oppose this proposal. —Uzume (talk) 06:51, 20 August 2025 (UTC)

I understand where you're coming from; I just think that "no listed works provided by uploader" is too generic a criterion for WS:CSD. I think I could support it if we added a caveat similar to criterion A3 "Works without authorship information, where a reasonable attempt has been made to discover this information and contact the user who added the text" (emphasis mine). —Beleg Âlt ^BT (talk) 16:29, 20 August 2025 (UTC)

I might be able to back a policy like that as well. I do not think {{populate}} by itself is strong enough for a useful CSD policy (if we go that far why not just delete the {{populate}} template itself and redirect it to the {{sdelete}} one). —Uzume (talk) 16:53, 21 August 2025 (UTC)

That's pretty much the plan; when the backlog is cleared, populate will be replaced by sdelete, probably not a simple redirect, but the equivalent.--Prosfilaes (talk) 00:18, 22 August 2025 (UTC)

@Prosfilaes: I figured that was the basis of your proposal and exactly what I am against. —Uzume (talk) 13:19, 24 August 2025 (UTC)

@Beleg Tâl: If this proposal comes to fruition, I will likely just start creating author stub pages with blank "Works" sections and tag them with something like {{general-stub}} instead of {{populate}}. I do not see the real difference is sifting through Category:Authors with no works vs. Category:Stubs (or something more specific). Of course this currently yields {{incomplete}} so perhaps the right category will end up as Category:Other pages tagged as incomplete (it seems there are already a few author pages there). Perhaps we can create a more specific {{author-stub}} template for this. author:John Jeffries is an interesting example. —Uzume (talk) 07:31, 20 August 2025 (UTC)

If this proposal comes to fruition, any author stub pages you create with blank Works sections will be speedy deleted under the new proposed criterion. —Beleg Âlt ^BT (talk) 16:18, 20 August 2025 (UTC)

@Beleg Tâl: Exactly and that is why I oppose it. I will probably be forced to add credits for things very obscure and hard to verify; like things not currently available online but references to such are. As an example, this proposal forces me to spend valuable time either trying to find an English translation or arbitrary starting (but not necessarily completing) a Wikisource original translation for some work of Lazar Komarčić, the Serbian "Father of Science Fiction" compared to the likes of Jules Gabriel Verne and H. G. Wells, just to keep his author page around because the vast majority of his work has not been translated to English. —Uzume (talk) 18:03, 20 August 2025 (UTC)

To be fair, if you're going to spend valuable time creating an Author page for Lazar Komarčić, then you should be looking for works by this author. (Also why the heck is this page in Portal space???) —Beleg Âlt ^BT (talk) 20:03, 20 August 2025 (UTC)

... I moved it to Author space where it belongs. Also I added a list of works, which I copy-pasted from enWP. None of those works are currently on enWS, but that's beyond the scope of this thread. —Beleg Âlt ^BT (talk) 20:07, 20 August 2025 (UTC)

... also I see that there are no incoming links to that page except from discussion threads, which means there isn't really any need for that page to exist. If there are no texts on enWS that are by him, nor any about him, nor any that even mention him; then it's okay for there to not be an Author page for him on enWS either. We can always create Author pages later when works get added. —Beleg Âlt ^BT (talk) 20:15, 20 August 2025 (UTC)

I can not find any evidence that Author:Lazar Komarčić has ever been translated and he doesn't have a Serbian Wikisource page I can find. So he's not really good for an Author page here for the near future.--Prosfilaes (talk) 21:54, 20 August 2025 (UTC)

Currently my understanding of the proposal is no works listed, while I understand the proposal is that works with only non-English listed would go to WS:PD where we can discuss works with the intent to translate, e.g. if they have transcribed works on another WS, whether the translation is abandoned, etc. MarkLSteadman (talk) 00:43, 21 August 2025 (UTC)

I agree with this. I would be ok with speedy deleting an empty Author page with no works listed at all; but a populated Author page with no known free English translations should definitely go through WS:PD —Beleg Âlt ^BT (talk) 13:33, 21 August 2025 (UTC)

@Beleg Tâl: That is an interesting development. As far as I know there are no known English translations of his works. My understanding was that author pages had to have English works listed on them. That is why I converted his page to a portal so it could be converted back when an English translation is found or created, etc. That said, I do not plan to argue against this development so long as a page for him can be maintained here. I do not think a "father of science fiction" where all his contributions are in the public domain should not be represented here in some fashion. —Uzume (talk) 15:44, 21 August 2025 (UTC)

Portal space is for people who have no authored works at all. If the person has written works, then the page either goes in Author space, or it does not belong on enWS at all. In the case of Komarčić, the current proposal means that the page may be deleted; but moving to Portal space is not an option here. —Beleg Âlt ^BT (talk) 15:49, 21 August 2025 (UTC)

• No, this is wrong; at least according to how {{populate}} is used (where if there aren’t any works, the Author: gets deleted), then non-English works don’t count. In such a case, such as politicians with biographies about them (in English) but no translations available, Portal: is appropriate. TE(æ)A,ea. (talk) 15:54, 21 August 2025 (UTC)

  Hmm, I don't remember any discussion in which the community agreed to use Portal space for people who have authored works. WS:Portal guidelines says Portal space is for "People who have not authored any works themselves". I haven't found any other relevant discussions (yet). —Beleg Âlt ^BT (talk) 16:00, 21 August 2025 (UTC)

• I think that it would be a good idea to encourage (if not require) new author pages to have works, but I think that it is inappropriate as a speedy deletion criterion; the goal should be improvement, not deletion. This definitely should not happen now, although perhaps one big discussion should be created for all authors where the people going through the needs-to-be-populated categories can’t find any works. I think that its use as a speedy deletion criterion is especially poor because this is a situation where the contributions of numerous editors could help find a solution. TE(æ)A,ea. (talk) 21:44, 18 August 2025 (UTC)

  The question being, improvement by whom? contributions of which numerous editors? We don't have many editors. Who is going to make that detailed bibliographic research on 3000 authors?

  Also, on the CSD, for author pages with no works listed. If/When anyone ever later feels like recreating an actual author page with links, they're absolutely free to; but in what matter does it help us to keep those empty author pages meanwhile? Being empty, they bring nothing. — Alien  3
  3 3 22:05, 18 August 2025 (UTC)

  • Alien: I would respond by asking why removing these pages would bring anything—many author pages list works without having any actually present here, and these are just one step away from that. Making the present of {{populate}} instant grounds for deletion short-circuits what should be happening: author-by-author bibliographic research. There shouldn’t be an easy way out of dealing with that. TE(æ)A,ea. (talk) 02:05, 19 August 2025 (UTC)

  • But why should we be doing author-by-author bibliographic research? WS:WWI says "Wikisource ... exists to archive the free artistic and intellectual works created throughout history, and to present these publications in a faithful wiki version so that anyone may contribute added value to the collection". It says nothing about creating a bibliography. I don't think this is one step away from listing works without having any actually present here; I think it's one step from an author page that lists works without even an external scan link. I think the latter is a little too far for me to want to delete; a page with just a work can become a page with an external scan link, which can become a scan and index that people can work on. An author page without a work listed doesn't justify its existence, that there is in fact a work we can host here with that author, and it just adds an effectively blank page to the site.--Prosfilaes (talk) 05:22, 20 August 2025 (UTC)

    @Prosfilaes: There may be nothing about creating bibliographies, but the point of such is to help find the works. We could delete the entire Author namespace too but I hardly think that makes sense. I agree with the assertion that such a namespace is not the point of Wikisource but by the same token is useful to develop it and as such it should not be required to have them at some level of completion (i.e., require to list at least one work) or be automatically considered for deletion. Sure there is a large backlog but that is not grounds to flush everything. I am sure there are such pages that should be removed—perhaps even a great many of them but I disagree that just because something is messy we should disallow it. —Uzume (talk) 07:04, 20 August 2025 (UTC)

    Messiness is not the issue. The present concern is lack of content. --EncycloPetey (talk) 15:28, 20 August 2025 (UTC)

    @EncycloPetey: Why is a lack of content a concern? If you want to work on it, no one is stopping you. Why do you want to stop others by limiting their ability to work on things at their own pace? This goes to the very premise of the concept of stub pages. This proposal basically is saying an author stub must be of a certain size or it gets axed. That is just foolishness as I see it. Just because people develop things in a different way than you might is no reason to force them to your standards. —Uzume (talk) 17:37, 20 August 2025 (UTC)

    Every Wiki project has minimum content standards. Wikipedia requires a sentence about the topic; there are no pages that consist solely of an infobox and a footer template. Wikidata requires links to projects or an ID from a database. We are now saying the same thing should be true for Author pages on Wikisource: there should be a work listed on the page, not just a header. --EncycloPetey (talk) 18:57, 20 August 2025 (UTC)

    I just want to add, that "stub pages" aren't really a thing here on English Wikisource. We generally prefer to leave a page uncreated until such a time as there is content to add to it. —Beleg Âlt ^BT (talk) 20:19, 20 August 2025 (UTC)

    @Beleg Tâl: Are you suggesting Index "stub" pages that have no Page pages should be deleted and/or remain uncreated? I was not aware that was a speed deletion criteria. —Uzume (talk) 16:11, 21 August 2025 (UTC)

    Those are not considered "stub" pages, they are considered "works in progress". —Beleg Âlt ^BT (talk) 16:12, 21 August 2025 (UTC)

    @Beleg Tâl: What is the difference from a "stub" and something in progress? Every Wikipedia article stub is basically a work in progress. I do not see the relevance in differentiating them. As I see it a stub is just something that is small and in need of further development. If that is not a sign for "in progress", I do not know what is. —Uzume (talk) 16:40, 21 August 2025 (UTC)

    My understanding of "stub" articles on enWP, is that they are essentially placeholders—pages where an article should be, but where no one has actually written one yet. An author page with no content is no more useful than a red link; on enWS we prefer to leave the link red rather than create a page with no content. —Beleg Âlt ^BT (talk) 16:50, 21 August 2025 (UTC)

    @Beleg Tâl: Isn't a placeholder basically something in progress (unless one plans to never have it developed and then it would probably be better as a redirect placeholder)? I am confused by this artificial delineation of definitions. Maybe I am missing something. I disagree. Author pages here usually require one to link to a Wikidata item. These things take work. However, and existing author page can be useful for linking to. Deleting lots of empty or or near empty author pages will likely result in those pages being recreated later which will likely result in new Wikidata items proliferating either duplicate items or causing those now unlinked items to be deleted at Wikidata losing collected information about the authors like authority control and birth and deaths, etc. So if an editor is working on a work with many authors (e.g., magazine volumes), they have to either spend considerable time generating authors, or leaving linking to the author pages for some future work. Without a body of existing author pages, editors will be encouraged to do the latter which will in turn make finding the works harder. —Uzume (talk) 17:32, 21 August 2025 (UTC)

    My experience is that people who create empty Author pages do not create Wikidata items. A Wikidata item should only exist when there is sufficient cause for such an item to exist. If a Wikidata item for an author contains links to Commons, to other wikis, or to database items, then that items would exist whether or not we have an Author page. If the only impetus for a Wikidata item is an empty Author page here on en.WS, then there clearly is insufficient cause. The requirement to list at least one work provides the justification in cases like these by demonstrating the individual is worth having a page and WD item. This is a low bar, and I am baffled by the resistance to listing one work, even if it is not yet hosted here. --EncycloPetey (talk) 18:15, 21 August 2025 (UTC)

    @EncycloPetey: That is not entirely true. Wikidata items require either notability or sitelinks to WMF sites. Many of the authors here are not particularly notable and as such their Wikidata items are subject to deletion if they lose their sitelinks to author pages here. I am not against listing any works but I am against requiring such from people who are doing the Wikidata and Commons work for stubbing out local author pages. I am sorry about "your experience" with regard to so called "empty" author pages but that is not how I work and I know this proposal will definitely discourage my work in creating such author page stubs and I can only assume some other people are in the same situation as I am or would be if they tried their hand at such. As such I am against discouraging such work and thus I am against this proposal. —Uzume (talk) 13:30, 24 August 2025 (UTC)

    You are misinformed. Please read d:Wikidata:Notability, which lists Wikidata's notability criteria. One of the criteria is a wiki sitelink. This is not separate from notability; it is the first criterion that may satisfy notability. --EncycloPetey (talk) 14:37, 24 August 2025 (UTC)

    Indeed. WD is full of authors or other items not linked to any WMF project, one of zillions examples: d:Q75733078. --Jan Kameníček (talk) 14:55, 24 August 2025 (UTC)

    @EncycloPetey: Regardless, the deletion of a large number of author pages here will endanger Wikidata author items so such deletions should be done carefully and not blindly en masse if they just happen to have {{populate}} and no works listed. When the information to substantiate a better author page with representative works is later found, the Wikidata for that author may not longer exist creating substantial work in the future. —Uzume (talk) 15:10, 25 August 2025 (UTC)

    If they are author pages, with works, then they won't be deleted. The goal is to weed out non-authors and set minimum standards as we go forward. I am baffled that you argue so vehemently against setting minimum standards for Author pages. --EncycloPetey (talk) 16:14, 25 August 2025 (UTC)

    "My experience is that people who create empty Author pages do not create Wikidata items"—this is true, but it needs to be added that there are some editors (including me) who make a point of creating Wikidata items for Author pages that lack them. So in the end, all the affected Author pages do in fact have WD items that would need to be cleaned up as part of this effort. —Beleg Âlt ^BT (talk) 13:52, 25 August 2025 (UTC)

    @Beleg Tâl: I agree. I always link any author pages I create to an Wikidata item often resulting in either improving the Wikidata item or creating new ones as needed. @EncycloPetey: Is it really necessary to punish those doing good work because of those not doing such? —Uzume (talk) 15:15, 25 August 2025 (UTC)

    If you see helping the readership as a punishment, you may want to rethink your perspective. --EncycloPetey (talk) 16:11, 25 August 2025 (UTC)

    The point of such is to help find the works. Pages without works don't do that. As a user, I'm frustrated every time I find there's a Wikisource page in another language and click through to find merely a list of works. I would be even more frustrated to find just a name. Yes, pages in reader facing namespaces should have some level of completion. Also, as an administrator, I consider this akin to the rule that Wikipedia pages without a claim of notability can be speedily deleted. If an editor wants to create a page in a reader facing namespace, they should list a work to make at least a prima faciae claim that the person is suitable for a page in the author namespace.--Prosfilaes (talk) 21:54, 20 August 2025 (UTC)

    @Prosfilaes: I think prima faciae claims can be represented by the Special:WhatLinksHere and Commons category links already present on author pages with {{populate}}. —Uzume (talk) 16:15, 21 August 2025 (UTC)

  @Alien333: They do bring something as they can be linked to when creating pages in Index, Page and main spaces. It can be a considerable work to create author pages as they should normally be linked to existing Wikidata items and those items should have good means of identifying the author (e.g., birth and death dates, etc.). If we force a bunch of author pages to be deleted because they contain no listed English works and later someone creates a work that references a pile of authors, that editor either has to not link to the authors, create redlinks to the authors, or spend considerable time trying to find Wikidata items and create author pages for them all. That is particularly distracting from transcribing the content from a scan and thus severely limits that kind of contribution and/or creating good author references for finding such content later. This sort of policy will likely result in the proliferation of many Wikidata duplicates for such authors with partial data, etc. —Uzume (talk) 16:27, 21 August 2025 (UTC)

  There is precedent for grandfathering, e.g. newly created works from Project Gutenberg are now candidates for speedy deletion as beyond scope but previously created works before that decision are not. If we want to make it a requirement (which is what making it a CSD means) going forward what does that mean if every time we have to ask for consensus and then allow an ever-growing lists of exceptions because we have had a discussion that didn't reach consensus? MarkLSteadman (talk) 22:53, 18 August 2025 (UTC)

  We could also agree to delay implementation of the new criterion to a specific date (e.g. 15 Dec 2025) to give time for population of bare Author pages with lists. That way anyone wishing to preserve work done has time to take action. There's nothing that necessitates immediate implementation if we agree on the new CSD. I would rather do that than grandfather in 3000 pages with no works. --EncycloPetey (talk) 23:18, 18 August 2025 (UTC)

  • EncycloPetey: I think that a full-scale grandfathering would be fine so long as we had people actively working on reducing the backlog—or rather, that we should have people actively working on it, and when it’s mostly empty of false positives, the requirement can be implemented. TE(æ)A,ea. (talk) 02:05, 19 August 2025 (UTC)

    If I understand correctly, your proposal is to add works to all the pages of people who actually wrote something, then grandfather all the Author pages that no one can locate works for? --EncycloPetey (talk) 15:30, 20 August 2025 (UTC)

    Grandfather until we sort out "False Positives" which I assume are people who actually wrote things in English but are not currently listed. MarkLSteadman (talk) 00:34, 21 August 2025 (UTC)

    • EncycloPetey: More or less so, but grandfathered from the speedy deletion, not from regular deletion. After going through a few dozen of them already, I don’t think that there’s nearly so much work involved as I thought; many authors have works on Wikisource already, which are just not listed on their Author: pages. So far, I’ve gone through a score of contributors to Punch, and later I hope someone can batch all contributors to encyclopedias. While EB is listed in the author header notes field, there are many contributors to the Imperial Dictionary of Universal Biography (which is not listed). Another exception to the grandfathering: people who spoke a language other than English as their native language, and who are thus not likely to have published anything in the English language (translations aside). There are many foreign politicians where, if any surviving works even do exist, (if they were authors at all,) they are not in English. TE(æ)A,ea. (talk) 15:51, 21 August 2025 (UTC)

      I found the same thing. There are pages where someone added works but did not remove the populate template. --EncycloPetey (talk) 16:05, 21 August 2025 (UTC)

The whole point of thing like {{populate}} is to allow people to develop author pages without having to develop their works all in one go. It makes it so someone can then work on things in Category:Authors with no works. I think this is a good thing. If some of them have little real valuable content available, sure, that could be grounds for getting the author page deleted but I do not think it makes sense to require people to list some work on a author's page or have it automatically considered for deletion. It should be considered for development and if it cannot be so then it can be tagged and considered for deletion like everything else that perhaps does not belong here. So I am very much against automatically vilifying author pages with {{populate}} and vote against this proposal. —Uzume (talk) 06:35, 20 August 2025 (UTC)

The backlog is really huge, so I do support this proposal. I understand the Uzume's concern, but this can be solved by adding {{under construction}}, as I have mentioned above, and it should be only a temporary solution. Another possibility might be speedying only pages of authors who do not have any works elligible to be hosted here listed and are not linked as authors of any work transcribed or being transcribed in Wikisource at the same time. Author pages linked from author/coauthor/translator/editor... parameters in headers of transcribed works or from index pages might be excluded from the speedy deletion criteria even if the contributor has not listed the work to the author page yet. --Jan Kameníček (talk) 09:15, 20 August 2025 (UTC)

@Jan.Kamenicek: You are entitled to your opinion but I am against it. I definitely agree it would be good to work on the huge backlog but I do not agree that towards that end we should blow up everything there just to clear the logjam. If there really are erroneous author pages they of course can be tagged for deletion just like anything else. And if it seems such pages are highly unlikely to have any real works attributed to them in English anytime soon, I think it makes more sense to convert them to portal pages. Otherwise, either develop the pages as per usual or leave them alone if you are unwilling to commit time towards them. Obviously we cannot all commit every waking second to every project here. So we all work on what interests us and interests can and do change over time. One never knows who they might end up collaborating with but that is power of a wiki. —Uzume (talk) 09:43, 20 August 2025 (UTC)

Are you suggesting conversion of empty author pages into empty portals? -- Jan Kameníček (talk) 09:57, 20 August 2025 (UTC)

@Jan.Kamenicek: Many of these so called "empty" author pages have "Work about" sections that would definitely be applicable for conversion to portals, however, even those that are entirely empty could be developed later. So yes, in fact I am. I really do not see the appeal to forcing people to "hurry up and develop" material. It will only push away "would be" and existing editors. —Uzume (talk) 17:31, 20 August 2025 (UTC)

I see. I have no problem with converting author pages containing just "works about" into portals. BTW, I really do not understand that dramatic tone about "forcing" people to develop material. We are talking about very simple author pages and about a very simple requirement. Developing this usually takes a few minutes, in some more complicated cases a little more, but the time is never too long and I cannot imagine why it should push anybody away. --Jan Kameníček (talk) 19:41, 20 August 2025 (UTC)

I would  Oppose moving author pages to Portal space, unless the individual actually never wrote any works. —Beleg Âlt ^BT (talk) 20:21, 20 August 2025 (UTC)

I in general would prefer that Portals be a level up if they are merely containing entries simple works about them (e.g. for every Egyptian Pharaoh have a single Portal listing links to short biographical articles about the Pharoahs rather than creating a separate Portal for each one). "New portals should only be created if there are enough works to be indexed." Help:Portals#Other_considerations but that is a separate discussion... MarkLSteadman (talk) 21:29, 20 August 2025 (UTC)

I would say the same for all the "author" pages we have for Late Roman popes. We can create redirects in Portal space to a single page for all the popes, and collect any articles there. If a pope on the list does warrant an Author page, then we can include a link to that pope's Author page in the appropriate section. --EncycloPetey (talk) 22:26, 20 August 2025 (UTC)

Or if they are notable enough to have enough works written about them to merit a Portal in their own right. (e.g. even if we don't have any works by Tutankhamun it might still merit a portal to collect all the things written about him). But in general, I think we should avoid having a stub article about Person X on WP therefore we should have an entry on WS just because we found a two line work about Person X in some article. But we can have that conversation about Portals after we sort out the discussion about Authors. MarkLSteadman (talk) 00:33, 21 August 2025 (UTC)

@Jan.Kamenicek: I am not sure where you are reading any dramatic tones from. Policies by their very nature force people to do things. Are you implying all the policies here are overly dramatic? I am confused. —Uzume (talk) 17:12, 21 August 2025 (UTC)

Actually, I think we push away a lot of people who want something more structured and organized. Going to an author page on a Wikisource and seeing that it doesn't actually have content is quite annoying. Works in progress are at least in progress. A list of works is just bare. I can't imagine clicking through an author link to another Wikisource and finding... nothing. Literally why does this exist? The finding of such stubs would not inspire me to start work on a wiki.--Prosfilaes (talk) 00:14, 22 August 2025 (UTC)

@Prosfilaes: I believe editors working on the transcribing the works probably find it even more annoying to have to create a bunch of author pages while doing their work. If I am transcribing a bunch of articles from magazine or journal volumes, I have the choice of finding rare authors (whose pages might be stubs), spending a bunch of time of creating such authors detracting from transcription work, or just not linking to authors that I cannot easily find here locally. The fact that a stubbed author page exists invites those who see it to add to it and flesh it out and that is how it should be, IMO. —Uzume (talk) 13:39, 24 August 2025 (UTC)

It doesn't take that long to create an author page, especially for a rare author. Go to Author:Name As Listed and add the work, a PD tag and authority control.--Prosfilaes (talk) 20:36, 24 August 2025 (UTC)

@Prosfilaes: I always link author pages to a Wikidata item in order to populate birth and death dates and authority control, etc. As such, it often takes substantial work to create the pages. Maybe there are lots of author pages being created without linking to Wikidata but I am not one of the people doing such. Even if there are many such creations, just how many editors are creating these pages vs. those creating ones linked to Wikidata? I cannot be sure but I imagine even is there are many such creations they are done by just a small group of editors. Please do not punish me (and anyone else who does the same) because others do not do such things. This is akin to punishing the many for the misdeeds of a few. —Uzume (talk) 15:24, 25 August 2025 (UTC)

I agree which is why I am opposed to a transcribed work / scan requirement. However, I think it is reasonable to ask to list a work when creating authors so that at least it is clear who it is. Having John Doe, journalist, fl. 1880s might actually be a variety of different people. Having John Doe, wrote Article X in Magazine Y. at least makes clear which John Doe it was intended to be created for.

That said, people are minimizing the work to create an author page. Tracking down the full name (for Author:Name) and date year (for PD tag) can be a lot of work, even tracking down authority control information for rare authors might not be easy, as they are listed under alternative names (e. g. instead of Jane Doe, Mrs. John Doe author of different work X). MarkLSteadman (talk) 15:57, 25 August 2025 (UTC)

 Support Just want to say I support the proposal, it is reasonable to ask people to identify what work is being references when wikilinking from another page while if generically referencing a person link to WP or WD as appropriate if someone really does need a wikilink for understanding. MarkLSteadman (talk) 00:51, 21 August 2025 (UTC)

 Comment I think that this proposal needs an exemption for authors with hosted works about them, even if no English editions of their works have been identified. —Beleg Âlt ^BT (talk) 15:51, 21 August 2025 (UTC)

This, among other reasons, is why I think this proposal is flawed and thus not appropriate. The idea is good but making this a policy would likely not be a good idea as I see it. It is comments like Wikisource:Proposed deletions#c-MarkLSteadman-20250818150100-Jan.Kamenicek-20250818125400 that really underscore this issue. —Uzume (talk) 16:34, 21 August 2025 (UTC)

Arbitrary break

This discussion has gotten unwieldy, so I'm going to cram an arbitrary break here.

@Uzume: There is something I am not understanding about your position here. Can we go back to basics and explain why adding a single title to an Author: page on creation is so problematic to you? I either don't understand the context in which you are working or the category of authors you are referrring to since what it sounds like you are objecting to appears entirely trivial to me.

Keep in mind that both Wikidata entries and links to Commons are entirely optional (very much desireable, but optional), as are license tags and authority control, on first creation of an Author: page. Neither are concerns about what the Wikidata community may or may not do based on the presence or absence of sitelinks relevant in this context.

Pretty much the only things that in practice would be absolutely required on first creation of an Author: page under this proposal is a reasonably full name, vital years, and the title of a single English-language work by or about that person that is reasonably believed to exist and be compatibly licensed. i.e. a minimal assertion that the person is eligible for an Author: page on English Wikisource, much like English Wikipedia requires an assertion of notability.

Requiring such a minimal assertion of eligibility appears to me to be a very low bar, especially when considered relative to the assertion that "this person exists" that is inherent in the creation of a page in the Author: namespace. On that basis this would seem to be a very reasonable proposal.

But when you are apparently so strongly opposed to what appears to me to be a trivial requirement there is obviously something I am failing to understand. Not about your arguments (those are, in isolation, entirely comprehensible), but about the foundations for them. What am I missing? --Xover (talk) 09:56, 21 September 2025 (UTC)

Closing

Having gone through the discussion I can see a majority of people agree with implementing the criterion: I counted 7 approving opinions, 2 opinions partly approving and partly opposing with some suggestions of modifications that did not get wider support, and 1 opposing opinion.

Thus, I am closing the discussion with the result that the new criterion was approved. --Jan Kameníček (talk) 18:50, 17 October 2025 (UTC)

Don't forget to update WS:D, WS:CSD, and MediaWiki:Deletereason-dropdown accordingly! —Beleg Tâl (talk) 18:57, 17 October 2025 (UTC)

Done --Jan Kameníček (talk) 19:38, 17 October 2025 (UTC)

We should also draft a section for Help:Author pages, and make sure the top-of-pages notes are current. --EncycloPetey (talk) 19:25, 17 October 2025 (UTC)

I added a note on that to the help page. Feel free to check the wording. --Jan Kameníček (talk) 19:44, 17 October 2025 (UTC)

I made this adjustment because I do not believe that having no titles in English is the same as having no English works available to host. It is not unusual for the first draft of a Classical Author page to list the works by their Latin or Latinized titles, even when the works have many published English translations. Some of our Translation versions pages with have a Latinized non-English title, even when multiple English translations are listed, and even for modern Languages. If someone has gone to the trouble to list works on the pages, then the page is not empty, and a little checking should be done. --EncycloPetey (talk) 21:17, 17 October 2025 (UTC)

The way it is currently written, the policy says that English-original works need to be "listed" on the Author page, but translations of non-English works only need to exist—is it possible to reword this to remove the discrepancy? Also why are published translations released under non-PD but otherwise compatible licenses excluded? —Beleg Tâl (talk) 00:06, 18 October 2025 (UTC)

The discussion was closed without the exception for the translations, and such a provision as EncycloPetey added was not properly discussed. While I understand the motivation of this modification (the list of works is not "empty"; unlike completely empty lists the contributor made some effort to add the works, so we could also make some effort to check for English translations before we delete it...) it needs to be approved in the discussion first, and so I have reverted the modification for now. --Jan Kameníček (talk) 09:49, 18 October 2025 (UTC)

The discussion is also being interpreted as written, so that pages with listed works are summarily being deleted, but the discussed criterion was no listed works. If the criterion is to be "no works listed what look like they are in English, even when works are listed", then I change my vote to  Oppose because that's not what was discussed. We discussed a speedy deletion for pages with no works listed, i.e. those that had the populate-template because of no listed works by the Author. --EncycloPetey (talk) 14:49, 18 October 2025 (UTC)

Proposal: Modify the new WS:CSD criterion regarding non-English works

The new criterion at WS:CSD currently reads: "Author pages with no published English-language works by the author listed". However, there are many Author pages with published non-English works listed, that would be deleted under this criterion. These pages are not "empty", and they are not relevant to the cleanup of Category:Authors with no works for which the criterion was initially proposed.

The deletion of Author pages where no known English translations exist, is a separate deletion rationale than the deletion of Author pages that do not list any works. If non-English authors are to be speedied, I believe they should at least be listed under a separate criterion in WS:CSD.

As such, I propose that the new criterion be reworded as follows: "Author pages with no published works by the author listed". —Beleg Tâl (talk) 12:04, 18 October 2025 (UTC)

@Jan.Kamenicek @EncycloPetey courtesy ping —Beleg Tâl (talk) 12:05, 18 October 2025 (UTC)

I am OK with such wording. Just to make sure we all understand it the same: this wording means that empty Author pages without any list of works get deleted, but if there is a list of published non-English works, it cannot be a subject of speedy deletion, but instead some search whether published translations of these works exist is required. The Author page can still be nominated at the Proposed deletions and if no published translations of these non-English works are found, it gets deleted anyway. --Jan Kameníček (talk) 15:57, 18 October 2025 (UTC)

I am not in favor of throwing the burden on to the proposer for deletion to demonstrated they did the required search. We don't have the requirement in other contexts, e.g. if no source or no license it isn't on the proposer for deletion to do a thorough search and say, "I couldn't find a source". Searching for translations is not necessarily trivial as they might appear in a bunch of names, periodicals, etc. It's fine to require going through individual proposed deletion however as a way to allow curing and search by interested parties and to work through the backlog here systematically. MarkLSteadman (talk) 16:29, 18 October 2025 (UTC)

E.g. someone puts up a 1920s Ethiopian poet listing only titles in Ethiopian, I shouldn't have to prove that I exhausted proven the non-existence of a PD / free-licensed translation to nominate it for deletion. MarkLSteadman (talk) 16:33, 18 October 2025 (UTC)

Agree. It should be enough to nominate it for deletion and give the community a chance to find and list some translation. It nothing is listed in a reasonable time, it will get deleted. --Jan Kameníček (talk) 18:13, 18 October 2025 (UTC)

We do host some works that are transcriptions of letters, manuscripts, and other forms of unpublished documents for notable historical figures and historical documents. We also explicitly permit theses that have undergone review by committee, even if unpublished. I therefore would add the phrase "...nor any listed works permitted under WS:WWI. --EncycloPetey (talk) 19:37, 18 October 2025 (UTC)

Or just simplify, "Author pages with no hostable works listed" —Beleg Tâl (talk) 02:09, 19 October 2025 (UTC)

That returns us to the previous issue of having to evaluate the list prior to performing a speedy deletion, and permitting speedy deletion of Authors that do have listed works. A speedy deletion should not require that level of evaluation. --EncycloPetey (talk) 02:53, 19 October 2025 (UTC)

I note that prior to mass-removing non-English language works that have long been listed on an Author page, one should probably check whether the appropriate foreign-language Wikisource is listing these works already, and, when in doubt, make sure to at least move the listing to the relevant Author Talk page so that the suitability of intweriki-transfering it can be explored. I have now done this for Archibald Pitcairne, where a number of Latin works were listed and were recently removed. (I've started a discussion to this end on Latin Wikisource at la:Vicifons:Scriptorium#Quaestio de Archibaldi Pitcarnii scriptoris operum recensione). Can we agree on this as standard policy going forward, so that information about extant works that may be appropriate for Wikisource as a whole is not inadvertently lost? --~2025-27371-40 (talk) 21:01, 19 October 2025 (UTC)

Well, if you wish to move it somewhere, you can move it directly to the appropriate language Wikisource. However, this discussion is about something different — we’re trying to find the best wording to reflect the result of the previous vote, so let's rather stay on topic. --Jan Kameníček (talk) 21:09, 19 October 2025 (UTC)

Since this discussion may or may not itself result in mass-removal of extant information about foreign-language works from English Wikisource, it's not obviously offtopic. Addressing your reply, I believe it would be inappropriate to expect en-WS users to "move [content] to the appropriate language Wikisource" as a matter of standard procedure, since interwiki transfers can be challenging for many reasons - e.g. they must be consistent with practices and policies on the destination Wikisource. Posting the content on the Author talk page, pending exploration of a suitable interwiki transfer, may then be a suitable compromise approach. --~2025-27371-40 (talk) 22:14, 19 October 2025 (UTC)

Changing the typefaces in Template:Cursive/styles.css

One-liner

The typefaces we currently have in {{cursive}} are hard to read. I propose we use a type of cursive typeface called Chancery for a very readable text, yet still distinct from {{serif}} and ''italic''.

Details of the issue

Current typeface choices

The {{cursive}} template was created with the Petit Formal Script before the cursive fallback.

Subsequently, people (including myself) has added more open source typefaces or those shipped with Windows or Mac systems. It now has these typefaces, in this order:

• Petit Formal Script
• two names for Pinyon Script Font
• Feltpen (I don't think this is open source)
• Dynalight
• Segoe Script (ships with Windows)
• Snell Roundhand (ships with Mac)
• and finally the cursive fallback

These can be broadly categorised into what I would call "modern handwriting" (Feltpen and Segoe Script) and "historical cursive" (the other ones). Both of them are not ideal.

The "historical" ones tend to have a problem with the x-height relative to the em box, where the x-height is relatively small. Not to mention the consistancy in the letterform (however good it may be in penmanship) tends to mush the letters together when viewed on screens.

The "modern" ones are not bad in terms of readability, but they are usually very stylistic and can sometimes be too attention-grabbing so that it hinders the reading experience.

CSS broswer defaults are not good enough

CSS's general font family (like serif and sans-serif) relies on the user's broswer and OS to choose an appriopriate font to render. However the cursive generic font family isn't very consistant across broswers and systems.

With a Windows 11 machine and a MacOS 15 machine for me to use, I tested for broswer defaults of the CSS cursive rendering on Firefox, Chrome, Safari (Mac only), and Edge (Windows only). For all test cases, all Windows cases render it as Comic Sans MS, and all Apple cases render it as Apple Chancery.

Proposal

Considering—

1. The first named typeface added to the template (ie, Petit Formal Script) is a "historical" cursive, not a "modern" one
2. Wikisource lives on the internet and it entails that the primary medium will be screens instead of prints
3. Consistency across platform is important (at least partial consistency)
4. It does not rely on the user to download any fonts to work (I'm unsure about this one)

I hereby propose that we:

1. Remove all the current named fonts in the template, and
2. Add Apple Chancery (ships with MacOS since 1993) and Gabriola (ships with Windows since Windows 7, 2009) before the cursive fallback

⸺ googoo0202 (he/him) (talk, contrib) 10:45, 17 October 2025 (UTC)

Apple Chancery is not a cursive font; it is a calligraphic font. Gabriola is a typographical font meant to look like light brushwork; it is not a cursive font either. The cursive template is meant to mimic cursive handwriting, not look like formal calligraphy. --EncycloPetey (talk) 19:29, 17 October 2025 (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

User:350bot — User:Fish bowl

Purpose

For migrating usages of Template:Sinogram (Template talk:Sinogram) to take advantage of the newly-finalized w:CJK Unified Ideographs Extension J, where possible; (much of the transcription work listed above has contributed directly to inclusion in Unicode). I have already done similar work at zh:Special:Contributions/350bot.

Scope

See above.

Programming language or tools

Python.

Degree of human interaction involved

Semi-automated: I will manually review every edit.

(See also: Special:WhatLinksHere/User:350bot)

Fish bowl (talk) 03:08, 19 September 2025 (UTC)

We have fewer than 300 pages in total with this template, and it is not clear what code you will be using or whether it is compatible with the regional and archaic forms used on pages here. --EncycloPetey (talk) 03:30, 19 September 2025 (UTC)

It will be a mind-numbingly simple find-and-replace—{{sinogram|description=⿰耒公|comment=not in Unicode, mentioned in http://appsrv.cse.cuhk.edu.hk/~irg/irg/irg30/IRGN1467ChinaLibCharIDS.pdf (p.42 at the bottom)}}</nowiki> → 𲹤 (see https://zi.tools/zi/𲹤 for display of this character; I'm sure that 0.00% of Westerners are rushing to install cutting-edge Chinese fonts for this) and {{sinogram|⿴行古}} → 𳀚 (https://zi.tools/zi/𳀚), and using Python is simply so that I can throw a database of these new characters at it for automated matching instead of hunting them down from the Unicode documents. "whether [my code] is compatible with the regional and archaic forms used on pages here" makes no sense; Unicode is Unicode. If it is somehow preferable for me to run this on my own account as in 2020 when I last requested feedback on a bot task proposal, please simply say so. Fish bowl (talk) 06:36, 19 September 2025 (UTC)

The replacement examples you've given do not display correctly for me. But the original content does.

As you say, Westerners are not likely to be installing the latest Chinese fonts, so a process that relies on the latest fonts, and will result in a change the will not display for Westerners may not be the best choice for a Wikisource project aimed at a Western readership. That is, since we have a Western readership, we cannot expect our readers to be using the most recent updates for Chinese. Changes that make the text less usable are not in the best interest if our readers.

I also think you did not understand my question about regional and archaic forms. The books that we host are mostly from 1930 or earlier, and therefore are using archaic forms of Chinese. We also have dictionaries for regional Chinese that use the sinogram template. Your response does not address these issues, possibly because you did not understand my question, but it also suggests you have not looked at the kinds of usages we have. --EncycloPetey (talk) 15:00, 19 September 2025 (UTC)

The display issue is simply a matter of font coverage. The characters in Extension J are fully standardized Unicode code points; whether or not an individual reader's system has a font that supports them is not something we can control. Many scripts don't render on many systems; this is a result of cost-effectiveness on the part of operating system maintainers, and lack of interest on the part of readers. Keeping stopgap kludges is not in the "best interest" of anyone. Where those characters now exist in Unicode, replacing the template with the actual character is the correct long-term solution.

In addition, most of these books are emphatically not within the interest of a clueless Westerner; I only inserted this statement for anyone who doubts that these characters are in Unicode. Can you see the text at wiktionary:Category:Old Uyghur lemmas? If you can, or if you can't, has it affected your understanding of extinct Turkic languages? If I told you that your system font is displaying w:Burushaski text wrong, could you identify how? I trust that anyone interested in these books is likely the type of person who is well-aware of the need to install fonts to catch up with developments in Unicode CJK.

Finally, I think you are also failing to notice that these are scan-backed works, and if a user cannot navigate to the scan to verify the original text, that is a problem that falls within the purview of those responsible for Wikisource's UI design.

As for "[code compatible with] regional and archaic forms": I believe that a deeper misunderstanding is occurring that is outside of the scope of this ticket. Chinese Wikisource handles works from the Ming dynasty (and earlier!) with ease. Are you aware of this?

Fish bowl (talk) 22:17, 19 September 2025 (UTC)

I am aware that Wikisource projects include some documents that are hundreds of years old, including works that cannot be transcribed with Unicode. That is why I have asked you to address certain issues, but you have dismissed rather than addressing. You are the person asking for a bot flag, so it is your responsibility to demonstrate that you understand what you intend to do, and that a bot is the correct tool for the job. This you have not done, so I am inclined to reject the request. --EncycloPetey (talk) 22:36, 19 September 2025 (UTC)

I am explaining that these issues are either non-existent or out-of-scope, but you appear to be dismissing my explanations. Fish bowl (talk) 22:45, 19 September 2025 (UTC)

@Fish bowl: You are "explaining" that the issues raised by EP are "either non-existent or out-of-scope"; otherwise known as "dismissing their concerns". I believe EP was looking for signs that you understood the concerns they raised, in which case dismissing them is non-productive. Tautologies like "Unicode is Unicode" may demonstrate a belief in the universal applicability of Unicode, but do not demonstrate familiarity with English Wikisource and the issues affecting this project. Absent clear signs that you understand the concerns, I have no confidence in your ability to address them (whether by bot or by hand). Xover (talk) 06:21, 20 September 2025 (UTC)

If I agree that there is an issue, and explain why, I believe that can be considered addressing a concern.

If I disagree that there is an issue, and explain why, I believe that can be considered addressing a concern.

I welcome either you or EncycloPetey to create a fresh, clear list of points for me to address.

As it seems to be a large point, I will respond that books that we host are mostly from 1930 or earlier, and therefore are using archaic forms of Chinese is an extremely, extremely, baffling statement. w:Ming typefaces have been stable for centuries, and solidified further by the w:Kangxi Dictionary, w:clerical script (circa Qin dynasty) is extremely legible to modern readers of Chinese, and vagaries like w:Simplified Chinese and w:Xin Zixing only form in after the 1950s. It is only when we reach w:seal script, w:oracle bone script, etc. that Unicode has considered re-encoding a new set of characters (and the traditional approach has often been to simply translate these forms to Ming/Kai!). All of the books in question are printed in a very clear Ming (or equally clear w:Kaishu) style appropriate for a printed text, and have contributed directly to inclusion in Unicode.

To be clear, making this bot request was for my own convenience (using Python is simply so that I can throw a database of these new characters at it for automated matching instead of hunting them down from the Unicode documents) and out of courtesy for the community. I could have done the same work in JavaScript with reduced efficiency and with no one noticing. "much of the transcription work listed above has contributed directly to inclusion in Unicode" was supposed to be a subtle sign of appreciation for this place. I beg you to not wear it out. Fish bowl (talk) 06:51, 20 September 2025 (UTC)

I don't see any problem with this. It's certainly worthwhile to replace approximations of characters with the actual character.--Prosfilaes (talk) 23:48, 19 September 2025 (UTC)

Yeah, but is it worthwhile to replace a good approximation of the intended glyph with a � or 􏿮 on most readers' systems?

New Unicode versions and new fonts are like new web standards, new browsers, and new operating systems: you need to assess adoption and compatibility before choosing to rely on the features they enable. CJK Unified Ideographs Extension J was added in Unicode 17.0, which was released on 9. September 2025 (11 days ago). That's way to soon for a website with a general and worldwide audience. Xover (talk) 06:51, 20 September 2025 (UTC)

Would you like me to assist in writing a webfont gadget or anything (for the benefit of fewer than 300 pages in total)? We can use the data at w:ja:GlyphWiki: https://en.glyphwiki.org/wiki/GlyphWiki:AdvancedApplication#i5.

Anyway, no one complains when new emoji are released. Fish bowl (talk) 06:54, 20 September 2025 (UTC)

For one thing, I dislike when someone says we're jumping the gun in updating the system, then it doesn't get updated for a long time, sometimes ever, especially when the change is fundamentally about correctness. People who can interpret the intended glyph are the most likely to have up-to-date fonts, or be able to interpret the replacement glyph of 𲹤. A webfont gadget would be useful, for a wide variety of scripts that may never get installed by the default install on an operating system.--Prosfilaes (talk) 00:55, 22 September 2025 (UTC)

I lack the technical knowledge to judge whether this bot will be a burden or a benefit. But in terms of a WS editor that has a general interest in East Asian text (or books with East Asian characters in them), I appreciate the existence of this proposed bot. ⸺ googoo0202 (he/him) (talk, contrib) 11:18, 17 October 2025 (UTC)

Repairs (and moves)

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

See also Wikisource:Scan lab

Index:Marking of Retail Goods Regulations 2025.pdf

This should be moved to Index:The Marking of Retail Goods Regulations 2025 (UKSI 2025-790 kp).pdf to match commons.

• Done --Jan Kameníček (talk) 17:43, 17 October 2025 (UTC)

Index:Englishhistorica36londuoft.djvu

Duplicate with Index:The English Historical Review Volume 36.djvu - Identical edition? Decide on ONE scan please. ShakespeareFan00 (talk)

I am not sure whether it is of any use to move the "not proofread" pages containing just raw OCR. I suggest moving only the proofread pages of the index. --Jan Kameníček (talk) 17:45, 17 October 2025 (UTC)

Boumediene v. Bush

This seems to be the court of appeals decision instead of the supreme court decision. I suggest that the link be redlinked and the page be moved to Boumediene v. Bush (476 F.3d 981 D.C. Cir. 2007). ToxicPea (talk) 21:48, 22 September 2025 (UTC)

• Normally it would only have one qualifier, I prefer the reporter citation (Boumediene v. Bush (476 F.3d 981)) personally. TE(æ)A,ea. (talk) 03:26, 23 September 2025 (UTC)

Select songs (1)

Please move this to Select Songs ("This is no my ain Lassie") for a meaningful disambiguator (see Select Songs). TE(æ)A,ea. (talk) 23:11, 14 October 2025 (UTC)

• Done --Jan Kameníček (talk) 17:56, 17 October 2025 (UTC)

Other discussions

Page title

Should we move 9/11 Commission Report to The 9/11 Commission Report given that it seems to be the actual title of the work? ToxicPea (talk) 03:00, 3 September 2025 (UTC)

 Support Xover (talk) 12:35, 4 September 2025 (UTC)

 Support —Tcr25 (talk) 12:38, 4 September 2025 (UTC)

 Support ⸺ googoo0202 (he/him) (talk, contrib) 12:12, 8 September 2025 (UTC)

Another related request. The subpages for the Notes page are of the form 9/11 Commission Report/Notes/Part 1 but the parts are called chapters in this work and they are located at 9/11 Commission Report/Chapter 1. Should the notes be moved to The 9/11 Commission Report/Notes/Chapter 1? ToxicPea (talk) 03:45, 1 October 2025 (UTC)

Hardware specific visual bug involving {{rule}}

I've noticed a visual bug involving {{rule}}. When there is more than one {{rule}} on a page, the top {{rule}} seems to be thicker than the others even when they are all the same height, but only on mainspace and the editing preview. When there are multiples {{rule}}s of different heights the top most {{rule}} of each height appears thicker than it really is. On Wikisource:Sandbox I put down 4 {{rule}}s of the same height and the bottom most {{rule}} appears thicker unless I'm in the editing preview in which case the top most {{rule}} is thicker. I put down 6 {{rule}}s in Page:Sandbox.djvu/92 and the 4th {{rule}} is thicker unless I'm in the editing preview in which case the 1st and 5th {{rule}} are thicker. This only happens when I'm using a chromebook. When I'm using a macbook everything is fine. ToxicPea (talk) 02:54, 4 September 2025 (UTC)

@ToxicPea: If it is hardware-specific the most likely cause is, essentially, different rounding of numbers. For example, the chromebook display may have some kind of multiplier on the size of a pixel. If so, you may be able to affect the rendering by setting different line widths (default is 1px). You can also test with raw <hr /> to see if that makes a difference. Xover (talk) 12:44, 4 September 2025 (UTC)

Using <hr /> doesn't seem to help at all. I'm thinking that this might be an issue with either HTML itself or how mediawiki uses HTML and how that interacts with the chromebook screen. ToxicPea (talk) 19:03, 4 September 2025 (UTC)

I tried the same thing on an online HTML compiler and there was no problem. My guess would be that the problem is on mediawiki's end. ToxicPea (talk) 19:07, 4 September 2025 (UTC)

 This section is considered resolved, for the purposes of archiving. If you disagree, replace this template with your comment. ToxicPea (talk) 03:46, 1 October 2025 (UTC)

stuff from the SCP wiki

I'm not sure if pages from the SCP wiki fits under "free" or not or if it break others Wikisource rules Skeletons are the axiom (talk) 13:47, 11 September 2025 (UTC)

I am afraid that works published on a wiki based web fall under what Wikisource considers to be "self-published" and thus out of our scope. Not speaking of the fact that we are quite cautious about digital-born materials generally. --Jan Kameníček (talk) 14:01, 11 September 2025 (UTC)

ok understood! Skeletons are the axiom (talk) 16:46, 11 September 2025 (UTC)

 This section is considered resolved, for the purposes of archiving. If you disagree, replace this template with your comment. ToxicPea (talk) 03:48, 1 October 2025 (UTC)

Super Long Work Title

Pinging @廣九直通車 and @Penguin1737 as this relates to UK Law . The UK Government recently published a statutory instrument titled "The Kent and Medway National Health Service and Social Care Partnership Trust (Establishment) and the West Kent National Health Service and Social Care Trust and the East Kent National Health Service and Social Care Partnership Trust (Dissolution) (Amendment) Order 2025". The title of this order is 270 characters long which is too long to be a title on Wikisource. The Wikidata link is at The Kent and Medway National Health Service ... Order 2025 (Q136326937) and the file is at File:UKSI 2025-1022 kp.pdf. If I want to add this work to Wikisource, what should the title of the mainspace page be? ToxicPea (talk) 19:23, 18 September 2025 (UTC)

Can’t seem to find any external standard on this situation; OSCOLA doesn’t recommend any shortening standard when shortening SI titles. I think something that’s clear and distinct would work, perhaps: The Kent and Medway National Health Service and Social Care Partnership Trust (Establishment) (Amendment) Order 2025. First section of the title + the amendment designation, to distinguish from The Kent and Medway National Health Service and Social Care Partnership Trust (Establishment) Order 2006 which it amends. And then we just put the full title at the top of the header notes. Penguin1737 (talk) 02:39, 20 September 2025 (UTC)

I've added an index at Index:The Kent and Medway National Health Service and Social Care Partnership Trust (UKSI 2025-1022 kp).pdf ToxicPea (talk) 03:01, 20 September 2025 (UTC)

@ToxicPea: Referring to w:WP:TITLELENGTH (after all, we all use the same underlying MediaWiki system), maybe that file could be named as "Statutory Instrument 2025 No. 1022"? This should be similar to how certain American Acts of Congress are named with the format of "Public Law XX-XXX".廣九直通車 (talk) 08:13, 20 September 2025 (UTC)

For the files on Commons, if we dropped the name entirely we would just keep it to the current standard format we have going there, as ToxicPea did on original upload (UKSI 2025-1022 kp.pdf). Although it doesn't matter much for Commons as the full title can go in the description and be discoverable.

The name here doesn't matter too much, I venture that this is not going to be a frequently cited/amended SI, we just need to remember what we picked when creating lists like the 2025 UKSI portal. While I think it would be useful to have a universal shortening system, as far as I can find, the title length byte limit only affects this order and the aforementioned 2006 order. They're the only legislation with short titles over 256 characters.

My proposal for the mainspace name is The Kent and Medway National Health Service and Social Care Partnership Trust (Establishment) (Amendment) Order 2025. And for the 2006 order, The Kent and Medway National Health Service and Social Care Partnership Trust (Establishment) Order 2006. Penguin1737 (talk) 23:22, 21 September 2025 (UTC)

Added The Kent and Medway National Health Service and Social Care Partnership Trust (Establishment) (Amendment) Order 2025 with the proposed title at least for now. ToxicPea (talk) 01:17, 8 October 2025 (UTC)

There is a recent discussion (now archived) about this on international treaties. Not sure if that helps. ⸺ googoo0202 (he/him) (talk, contrib) 09:49, 21 September 2025 (UTC)

That doesn't really help because that treaty had a commonly used short name. The instrument does not have a shorter name than this. ToxicPea (talk) 12:05, 21 September 2025 (UTC)

Administrator confirmation

I've been off-Wiki for a few weeks and realised that I missed putting up the Confirmation discussion for Xover at WS:ADMINS on 1 September. It is now there awaiting input over the next ten days. Beeswaxcandle (talk) 04:06, 20 September 2025 (UTC)

I missed that as well. Apologies. BD2412 T 04:15, 20 September 2025 (UTC)

Your tardiness couldn't have been better timed: had it been posted the 1st I wouldn't have been around to answer any questions. :) Xover (talk) 05:58, 20 September 2025 (UTC)

Right bracket

Can anyone work out how to insert the right bracket in this document: Brooklyn Eagle/1868/The Daughter of a Resident of Farmingdale Dies Under Suspicious Circumstances. I have seen it formatted in other legal docs, but can no longer find an example. RAN (talk) 03:10, 21 September 2025 (UTC)

@RAN: The usual pragmatic approach is to lay it out with a table and put the {{brace2}} template in a table column beside the text. I've done that as a quick demonstration.

PS. When you don't have a real scan to work from the image of the text should not be included inline like this (it's not present in the original, obviously, so it's an annotation). Link the image from the talk page or the |notes= field of the {{header}} template instead. And the correct way to transcribe things like this is to upload a scan of the entire issue of the newspaper—with all copyrighted parts redacted—and then proofread it from that. We have grandfathered in some texts with the approach you're using but we would prefer to not add more of them because all it does is increase the backlog that will have to be dealt with eventually. Xover (talk) 09:02, 21 September 2025 (UTC)

Tech News: 2025-39

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

Weekly highlight

• On September 24th at 15:00 UTC, all Wikimedia sites users will experience a brief read-only period due to a scheduled datacenter server switchover. The Wikimedia Foundation's Site Reliability Engineering (SRE) team will redirect all traffic from one primary server to its backup. You can listen to the switchover using the "Listen to Wikipedia" tool, where you will hear edits stop for a few minutes during the read-only phase, then resume. This twice-yearly datacenter server switchover ensures reliability by testing the backup datacenter, so that our sites can stay online even if the primary datacenter fails. You can read more about the process on the Diff blog.

Updates for editors

• Editors of 60 more Wiktionaries will soon be able to call functions from Wikifunctions and integrate them into their pages. A function takes one or more inputs and transforms them into a desired output, like adding numbers, converting miles to meters, calculating elapsed time, or declining a word into a case. They will join the other 65 Wiktionary language editions, which already have access to embedded Wikifunctions calls. Later this year, plans are in place to expand to more Wiktionaries and the Incubator.
• A new parser function has been added: {{#contentmodel}}. Template editors and admins can use it to get the localized or canonical name of the content model of a specific page. The function makes it easier to create and edit system messages, such as MediaWiki:editinginterface, even when you switch types of pages, like wiki, JavaScript, CSS or JSON page. [1]
• Adding or editing a DISPLAYTITLE for an article using VisualEditor will no longer be broken. Editors who use VisualEditor mode to modify the {{DISPLAYTITLE}} would no longer have the literal text "DISPLAYTITLE" or its localized variant added to their articles. A list of pages that may have been affected and might need cleanup is documented in this ticket.
• Beta users of the Wikipedia Android app can now try the redesigned Activity tab, which replaces the Edits tab. The new tab offers personalized insights into reading, editing, and donation activity, while simplifying navigation and making app use more engaging.
• View all 12 community-submitted tasks that were resolved last week.

Updates for technical contributors

• Detailed code updates later this week: MediaWiki

In depth

• Wikifunctions users can now import many essential facts involving geo-coordinates, quantities and time values from Wikidata. This is made possible by the creation of Wikifunctions types for these values, which makes them available for use by functions in Wikifunctions. Learn more about how this works in this video and Wikifunctions' August 1 newsletter (for quantities) and August 22 newsletter (for geo-coordinates).

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

MediaWiki message delivery 22:55, 22 September 2025 (UTC)

I'd like an image-snatching AI

What I have in mind is an AI that can be pointed to a page like this one, isolate out the part of the page that is in fact the illustration, create a .jpg of that isolated content, upload it to Commons with reference to authorship details in this work, and drop a link to the image file on the page where it belongs. Is that too much to ask? BD2412 T 03:58, 23 September 2025 (UTC)

• Someone did something similar to the Internet Archive, it cropped out the image and loaded the text just before and just after the image. I would love to see it done to all the public domain newspapers at Newspapers.com or the LOC Chronicling America or Fulton History. Commons:Category:Files from Internet Archive Book Images Flickr stream. You can contact the creator, see: here. --RAN (talk) 00:27, 24 September 2025 (UTC)
  • Fascinating! I will try that route next week. BD2412 T 04:24, 27 September 2025 (UTC)

Template:line-height2/s

When the templates {{line-height2/s}} and {{line-height2/e}} are not inserted on separate lines but in the beginning/end of the first/last line of the wrapped text, it causes problems with displaying paragraphs, see also the disussion here. I suspect there can be (many) more problems like that, so I would like to ask whether it is possible to find out all the cases of the wrong usage and correct them, or even better to fix the templates so that it did not matter whether they are on separate lines or not. -- Jan Kameníček (talk) 12:17, 23 September 2025 (UTC)

As far as I know (from using other template pairs), all /s /e pairs need to be on separate lines. Certainly the "fine block", "block center", and "hanging indent" pairs need to be. Thus, I suspect that it's a "feature" of paired templates. Beeswaxcandle (talk) 20:14, 23 September 2025 (UTC)

This is a problem with p-wrapping/MediaWiki's parser, where if it sees a <div> it doesn't add a <p> tag on that line, but then goes back to adding <p> tags on subsequent lines. —CalendulaAsteraceae (talk • contribs) 05:21, 24 September 2025 (UTC)

wikiproject requirements

would the Pentagon Papers be too small for a wikiproject? ltbdl (talk) 14:23, 25 September 2025 (UTC)

Not too small. Beeswaxcandle (talk) 19:16, 25 September 2025 (UTC)

Fairy Tales and Folk-Lore of New Zealand and the South Seas/The Great Swing

The subpage links to Fairy Tales and Folk-Lore of New Zealand and the South Seas/The Giant Warrior. I created that subpage but the link is still red. Clicking on it takes me to the "Wikisource does not have a text with this exact name" page and clicking on the create page button takes me to a permission error page which says that the title contains invalid characters. ToxicPea (talk) 02:11, 27 September 2025 (UTC)

I can follow that link to that page. Have you tried logging out and back in? --EncycloPetey (talk) 02:14, 27 September 2025 (UTC)

I just tried that and it didn't help. ToxicPea (talk) 02:20, 27 September 2025 (UTC)

If it helps the url that the link takes me to is https://en.wikisource.org/wiki/Fairy_Tales_and_Folk-Lore_of_New_Zealand_and_the_South_Seas/The_Giant_Warrior%E2%81%A0. I'm not sure what the extra characters mean but I don't think there supposed to be there. ToxicPea (talk) 02:21, 27 September 2025 (UTC)

There were similar problems last year, one of which still occurs - Index talk:Fairytales•Tregear•1891.pdf#Issues transcluding sections -- Beardo (talk) 02:46, 27 September 2025 (UTC)

There was a stray non-printing character at the end of the text in the link. I've removed it and the link is now okay. Beeswaxcandle (talk) 03:08, 27 September 2025 (UTC)

Thank you. ToxicPea (talk) 03:14, 27 September 2025 (UTC)

How do you do that ? Fairy Tales and Folk-Lore of New Zealand and the South Seas/The Spirit of the Cave seems to have the same problem. -- Beardo (talk) 03:31, 27 September 2025 (UTC)

I think what happened is that somehow there were invisible non-printable characters hidden in the link which were breaking it. I just retyped the link and that fixed it. ToxicPea (talk) 03:39, 27 September 2025 (UTC)

Well done. I thought that I had tried that, but couldn't get it to work. -- Beardo (talk) 13:01, 27 September 2025 (UTC)

 This section is considered resolved, for the purposes of archiving. If you disagree, replace this template with your comment. ToxicPea (talk) 03:15, 27 September 2025 (UTC)

Some bugs in auto-header

I just noticed that the auto-header in The Testament of Solomon is displaying information incorrectly. Most importantly, the header states "translated from English"—it was actually translated from Greek, and I cannot find where it is pulling the language from anyway (it is not specified on the Index page nor on Wikidata). Secondly, the header states that the author is "Anonymous, and Solomon" when it should say it is by "Anonymous (attr. Solomon)" as per the Index page. —Beleg Tâl (talk) 01:33, 28 September 2025 (UTC)

@Alien333: Looks like your link-parsing code is too powerful. Could you figure out a fix?

@Beleg Tâl, I'll add a special case to Module:Header so that it won't say "translated from English" if English is provided as the language. (This is happening because the work is using PRP to generate the header, and the index correctly says that the work's original language is English.) —CalendulaAsteraceae (talk • contribs) 22:34, 29 September 2025 (UTC)

Thank you!—If you're making special cases for Module:Header, would it be worth also checking for other hostable languages (Old English, Scots, etc)? —Beleg Tâl (talk) 02:07, 30 September 2025 (UTC)

Hmm, I think actually the thing we want to do is stop passing the language field from the index to the header via PRP. Consider the following cases:

• Wikisource translation of Beowulf from Old English. The index should set the language to ang, and the language passed to {{header}} should be ang.
• Transcription of an existing Modern English translation of Beowulf. The index should set the language to en, and the language passed to {{header}} should be ang.
• Wikisource Scots translation of Winnie-the-Pooh. The index should set the language to en, and the language passed to {{header}} should be en.
• Transcription of a recently-rediscovered Scots translation of Winnie-the-Pooh. The index should set the language to sco, and the language passed to {{header}} should be en.

Any hostable language could be a valid source language for a translation. The problem is that works in mainspace with the translator parameter will have the target language, not the source language, listed as the original language on the index page. —CalendulaAsteraceae (talk • contribs) 06:30, 30 September 2025 (UTC)

I've edited MediaWiki:Proofreadpage index data config.json to make it not use the language parameter in the header. —CalendulaAsteraceae (talk • contribs) 00:49, 2 October 2025 (UTC)

Tech News: 2025-40

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

Weekly highlight

• A major software upgrade has been made to Phabricator. The update introduces performance improvements, a refreshed search interface, enhancements to Maniphest task search, updates to user profile pages and project workboards, new Herald automation features, as well as general text input, mobile experience improvements and more. [2]

Updates for editors

• The Community Tech team will release the new Community Wishlist extension on October 1, that will improve the way wishes will be submitted. The new extension will allow users to add tags to their wishes to better categorise them, and (in a future iteration) to filter them by status, tags and focus areas. It will also be possible to support individual wishes again, as requested by the community in many instances. The old system will be retired. There will be a brief period of downtime while the extension is deployed and wishes are migrated to the new system. You can read more about this in the latest update or you can consult the current documentation on MediaWiki.
• As announced on Diff blog, the production trial of the hCaptcha service for bot detection has begun. The trial is currently using hCaptcha to protect account creation on Chinese, Persian, Portuguese, Indonesian, Japanese, and Turkish Wikipedias, where it will replace our existing CAPTCHA (FancyCaptcha). The goal with the trial is to better block bots while also improving usability and accessibility for users who encounter CAPTCHA challenges.
• The CampaignEvents extension has been deployed to Wikimedia Commons. The extension makes it easier to organize and participate in collaborative activities, like edit-a-thons and WikiProjects, on the wikis. On Commons, anyone who is a registered user can use it as an event participant. To use it as an organizer, someone needs to have the event organizer right.
• Sub-referencing, a new feature to re-use references with different details has been released to German Wikipedia. You can test the feature on testwiki or on betawiki as well. Please share your thoughts on using templates in sub-references or volunteer to become a pilot wiki.
• On wikis using the Mentorship system, communities can now opt experienced editors out of Mentorship through Special:CommunityConfiguration/Mentorship. Within this setting, communities may define thresholds, based on edit count and account age, to decide when an editor is considered experienced enough to no longer receive Mentorship. [3]
• The Editing Team and the Machine Learning Team are working on a new check for newcomers: Tone check. Using a prediction model, this check will encourage editors to improve the tone of their edits, using artificial intelligence. We invite volunteers to review the first version of the Tone language model for the following languages: Arabic, Czech, German, Hebrew, Indonesian, Dutch, Polish, Russian, Turkish, Chinese, Farsi, Italian, Norwegian, Romanian and Latvian. Users from these wikis interested in reviewing this model are invited to sign up at MediaWiki.org. The deadline to sign up is on October 3, which will be the start date of the test.
• The rollout of multiblocks had the side effect that non-active block logs may have been shown on Special:Contributions and on blocked users' user and user_talk pages. This issue will be fully resolved in a few days. As part of the fix, messages prefixed with sp-contributions-blocked-notice will be removed and replaced with those prefixed with blocked-notice-logextract in a few weeks. Please help translate the new messages and update any local overrides if needed.
• There was a bug with links added using visual editor if they included characters such as [ ] | after the fragment identifier (#). They were not encoded properly creating an incorrect link. This has been fixed. [4]
• One new wiki has been created: a Wikiquote in Malay (q:ms:) [5]
• View all 21 community-submitted tasks that were resolved last week. For example, the User Info Card now displays currently active global lock/blocks. [6]

Updates for technical contributors

• Later this week, editors using Lua modules will be able to use the mw.title.newBatch function to look up the existence of up to 25 pages at once, in a way that only increases the expensive function count once.
• A new Unsupported Tools Working Group has been formed as part of ongoing efforts to collectively determine technical work priorities, similar to the Product & Technology Advisory Council (PTAC). The working group will help prioritize and review requests for support of unmaintained extensions, gadgets, bots, and tools. For the first cycle, the group will be prioritizing an unsupported Wikimedia Commons tool.
• Detailed code updates later this week: MediaWiki

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

MediaWiki message delivery 20:52, 29 September 2025 (UTC)

Upcoming Dark Mode user interface rollout for anonymous Wikimedia sites users

Hello Wikimedians,

Apologies if this message is not in your language. Please help translate to your language.

The Reader Experience team will launch the Dark mode feature for anonymous users on all Wikimedia sites, including yours, on October 29, 2025.

Dark mode is an option that allows users to view pages in light-coloured text, and icons on a dark background. Once it is available for anonymous users, they can enable it when using various devices. More information on ways to enable it can be found on this page. Given many pages are still not compatible with dark mode this will be an opt-in feature and not automatically apply to pages.

Dark mode requires modifications to content pages and templates, and since our initial launch in July 2024, we have been working with communities and helping them prepare for dark mode. Before the rollout, it is essential that template authors and technical contributors test dark mode and read this page to learn how to make pages Dark mode-ready and address any compatibility issues found in templates.

We will fix most color compatibility issues only on the most-viewed pages on projects with over 5 million monthly page views. Technical contributors with an account should opt into dark mode currently using preferences or settings and test pages and seek help before the release to ensure everything complies before the enablement.

If you have any questions or need help, please contact the Reader Experience team for support.

Thank you!

UOzurumba (WMF) 02:08, 30 September 2025 (UTC)

Periodicals and Template:Incomplete

I'm seeing a good number of periodical base pages that use {{Incomplete}}, such as The Atlantic Monthly. I'm assuming the use is inappropriate in this case? Periodicals (and newspapers) are almost always going to be incomplete, almost inherently so, and are very unlikely to ever be complete. SnowyCinema (talk) 12:44, 1 October 2025 (UTC)

• I agree. As someone who occasionally looks through Category:Incomplete texts without a source, these periodicals are not usefully placed in that category. Perhaps in some cases (such as a periodical with a short term of publication) it would be appropriate, but not in this case. TE(æ)A,ea. (talk) 03:06, 3 October 2025 (UTC)

  Agree. --Jan Kameníček (talk) 17:59, 3 October 2025 (UTC)

  Would it be useful to have a different template for periodicals ? -- Beardo (talk) 19:02, 3 October 2025 (UTC)

In this case (on the page for a periodical title as a whole), I agree, unless the periodical is defunct, and so has a set number of things to add. But the template {{expand list}} exists, and was originally intended for just such uses; it is appropriate for individual volumes or issues where the table of contents has not been completed. --EncycloPetey (talk) 20:31, 3 October 2025 (UTC)

Disambiguating "The Singers' Companion"

These two works currently have ambiguous titles, so I'd like to disambiguate them:

• The Singers' Companion
• The Singers' companion, a choice selection of fashionable songs

The problem is, I don't see anything I can reasonably disambiguate on. They both have identical titles, identical subtitles, both published anonymously in the same city in the same decade. I have some ideas (including potentially leaving them with their ambiguous titles); but I want to ask the community: does anyone have a better idea for how to disambiguate these works in a manner consistent with our general practice? —Beleg Âlt ^BT (talk) 13:56, 1 October 2025 (UTC)

PS my ideas are:

• Leave them ambiguous at their current location
• Disambiguate based on their NLS call number
• Disambiguate with arbitrary index (1) and (2)

—Beleg Âlt ^BT (talk) 14:22, 1 October 2025 (UTC)

• BT: When I disambiguated “Four Songs” and some other titles, I used the following pattern: first, date; second, location; third, date and location. These three were only if any of those (in that order) were unique among all titles. If there was still ambiguity, I opted for Name of Pamphlet ("Name of First Song"), which is a meaningful distinction without reference to a particular library. In this case, I would move The Singers' Companion to The Singers' Companion ("Alice Gray"), and The Singers' companion, a choice selection of fashionable songs to The Singers' Companion ("A lassie lives by yonder burn"). TE(æ)A,ea. (talk) 01:11, 2 October 2025 (UTC)

  I like this solution! I'm gonna keep this in mind if I find myself in a similar situation.

  —SpikeShroom (talk • contribs) 17:58, 2 October 2025 (UTC)

URGENT: pages tag broken

Something has broken the pages tag. Works with multiple calls to the pages tag now display only the content from the first call. This has broken nearly every work on Wikisource. --EncycloPetey (talk) 19:02, 1 October 2025 (UTC)

I have just confirmed this issue is affecting es.WS as well. --EncycloPetey (talk) 19:07, 1 October 2025 (UTC)

Examples of affected pages here, including both newly added works and older works:

• A Short Survey of Czech Literature
• In Darkest London
• Tommy Thumb's Pretty Song Book
• Hamlet (1917) Yale
• Conference Reports of The Church of Jesus Christ of Latter-day Saints/Fiftieth Annual
• Fairy Tales and Folk-Lore of New Zealand and the South Seas

--EncycloPetey (talk) 20:10, 1 October 2025 (UTC)

This probably requires a ticket at phab:, but could be a local thing with interface admins. —Justin (koavf)❤T☮C☺M☯ 20:43, 1 October 2025 (UTC)

@EncycloPetey: I don't know what happened, but this appears to be fixed now, checking the works you mentioned. See any more problems I'm not? SnowyCinema (talk) 21:27, 1 October 2025 (UTC)

The message I got said: "They think it might be a result of the code-updates for phab:T278481 and they are now in the process of rolling-back that latest patch." And I just got an update that the rollback has been done. The above pages (and others I mentioned in the bug report) all seem to display correctly now. --EncycloPetey (talk) 21:31, 1 October 2025 (UTC)

I reported it, and got a speedy response that the engineers thought they knew the cause. --EncycloPetey (talk) 21:29, 1 October 2025 (UTC)

 This section is considered resolved, for the purposes of archiving. If you disagree, replace this template with your comment. --EncycloPetey (talk) 23:23, 14 October 2025 (UTC)

{{Redact}} length broken

The length field of the {{redact}} template seems to be broken. All instances of redacted text are displaying as the same size. ToxicPea (talk) 00:05, 2 October 2025 (UTC)

Confirmed. The culprit seems to be Special:Diff/15241923 by @CalendulaAsteraceae, which seems to have removed the em unit in the code among various cleanups. I'm not sure what changes were intended by diff is so I'll leave it for them to fix. Arcorann (talk) 04:01, 9 October 2025 (UTC)

Should be fixed now. —CalendulaAsteraceae (talk • contribs) 04:43, 9 October 2025 (UTC)

And while we're here, did the default width change? The documentation says 8em but the current code is emitting 4.25em. Arcorann (talk) 04:08, 9 October 2025 (UTC)

I think for some reason the length of redact length with custom length was being shortened and that default width was you what would have gotten when you put 8 into the length field. I've noticed that every instance of redacted text I've looked at since the fix is much longer now. ToxicPea (talk) 14:40, 13 October 2025 (UTC)

Encyclopædia Britannica—Reducing Link Clutter in Transclusion

I've been working on the EB9. In the transclusion of most articles, there seem to be some redundant links that clutter the header area. Take the article "Aalborg" for example. At the top of the page, there is a link to a "versions" page, which links to the EB11 article. In the header, there is a link to the Wikipedia article, followed by another link to the EB11 article, and then a link to the EB9 disclaimer. Then, on the right side of the header, under "sister projects," there is another link to the Wikipedia article, plus links to Wikivoyage and Wikidata.

My solution would be to remove the links from the "other-projects" parameter in the transclusion template {{EB9}}. It seems unnecessary to manually add these links since we have other systems to handle them. I would also suggest using disambiguation pages instead of "versions" pages; I don't see a reason to exclusively link to other Encyclopædia Britannica editions and omit the possibility of adding other works with the same title to the page.

Please let me know if this sounds like a good solution, or if there are any other considerations that should be made.

—SpikeShroom (talk • contribs) 17:47, 2 October 2025 (UTC)

• I agree that other_projects is inappropriate; after all, that’s what a disambiguation page is for. Similarly, I don’t think that a versions page is appropriate given that these articles are often complete re-writes; a disambiguation page (with the encyclopædia articles and other works) seems to be the best approach. Theoretically, we should have a disambiguation page for every encyclopædia article (at least, every one which shows up in at least two different works), but that would involve a lot of work. TE(æ)A,ea. (talk) 17:51, 2 October 2025 (UTC)

  My opinion is that dictionary, short encyclopedia entries, other reference works, etc. are fine not being disambiguated. I am not sure we need to list twenty "Aalborg, city in Denmark" every time it appears in a dictionary. Similarly I don't think we need to reproduce on an author page thousands of such entries. If people are interested in comparing across reference works they can find them easy enough. MarkLSteadman (talk) 23:11, 12 October 2025 (UTC)

Tech News: 2025-41

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

Weekly highlight

• Paste Check is a new Edit Check feature to help avoid and fight copyright violations. When editors paste text into an article, Paste Check prompts them to confirm the origin and licensing of the content. Starting Wednesday, 8 October, 22 wikis will test Paste Check. Paste Check will help new volunteers understand and follow the policies and guidelines necessary to make constructive contributions to Wikipedia projects.

Updates for editors

• Mobile devices will receive mobile articles directly on the standard domain (like en.wikipedia.org), instead of via a redirect to an "m" domain (like en.m.wikipedia.org). This change improves performance. This week it will be enabled on Wikipedias. The existing mobile URLs and the "Desktop view" opt-out remain available. Learn more. [7]
• New date filters, creationdate: and lasteditdate:, are now available in the wiki search engine. This allows users to filter search results by a page's first or last revision date. The filters support comparison operators (e.g. >2024) and relative dates (e.g. today-1d), making it easier to find recently updated content or pages within specific age ranges. [8]
• Wikifunctions now supports rich text in embedded calls across the 150 wikis where it's enabled. To showcase this, the team created a Latin declination table that Wiktionary editors can use to automatically generate noun forms, producing clear, formatted results — see an example output. If you need any help or have any feedback, please contact the Wikifunctions Team. [9]
• An edit link will now appear inside the categories box on article pages for logged in users, which will directly launch the VisualEditor category dialog. [10]
• View all 34 community-submitted tasks that were resolved last week. For example, there was a problem downloading pdf files last week and that has been resolved. [11]

Updates for technical contributors

• The field rev_sha1 in the revision database table is being removed in favor of content_sha1 in the content database table. See the announcement for more information.
• The Reader Experience team will roll out Dark Mode user interface on all Wikimedia sites on October 29, 2025. All anonymous users of Wikimedia sites will have the option to activate a color scheme that features light-colored text on a dark background. This is designed to provide a more comfortable reading experience, especially in low-light situations. Template authors and technical contributors are encouraged to learn how to make pages ready for Dark mode and address any compatibility issues found in templates in their wiki before the enablement. Please contact the Web team for questions or any support on this talk page before the enablement. [12]
• Starting on Monday, October 6, API endpoints under the rest.php path will be rerouted through a new internal API Gateway. Individual wikis will be updated based on the standard release groups, with total traffic increased over time. This change is expected to be non-breaking and non-disruptive. If any issues are observed, please file a Phabricator ticket to the Service Ops team board. [13]
• Detailed code updates later this week: MediaWiki

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

MediaWiki message delivery 17:23, 6 October 2025 (UTC)

Portal naming help

I would like to create a portal for books that instruct the reader about the care of skin, hair, cosmetics, etc. I need some help picking out what's the proper name for this concept.

• Personal grooming
• Personal beauty
• Beauty culture
• Beauty guide

Eievie (talk) 20:53, 8 October 2025 (UTC)

I think "Personal grooming" makes the most sense to me, especially if you're focusing on health as much as on fashion/beauty. —Beleg Tâl (talk) 21:16, 8 October 2025 (UTC)

I think that health quickly gets into a medical area better covered by Portal:Dermatology. Eievie (talk) 21:29, 8 October 2025 (UTC)

When trying to choose a Portal name, I will look at subject headings in the Library of Congress catalog; at article titles on Wikipedia in the same subject area; and at Category labels on Commons and Wikipedia. Each other those labels was carefully chosen, and subject to discussion. --EncycloPetey (talk) 22:26, 8 October 2025 (UTC)

LOC has https://www.loc.gov/search/?fa=subject:beauty,+personal. I can't find any Commons or Wikipedia categories for the broad concept at all. (Which I know sounds unlikely, but I can't. Maybe I was just searching all dud ideas.) Eievie (talk) 00:57, 9 October 2025 (UTC)

commons:Category:Grooming seems about right to me, even though its linked Wikidata item is grooming behavior (Q999981) which appears to be about something completely different for some reason —Beleg Tâl (talk) 01:53, 9 October 2025 (UTC)

Shaving your face, birds preening each other, and a person brushing their horse are—if you zoom really far out—all variations of the same idea. But I'd like to narrow the scope of this portal to just human grooming XD Eievie (talk) 02:06, 9 October 2025 (UTC)

Perhaps: "Personal grooming"? --EncycloPetey (talk) 23:24, 14 October 2025 (UTC)

Have your say: vote for the 2025 Board of Trustees

Hello all,

The voting period for the 2025 Board of Trustees election is now open. Candidates are running for two (2) seats on the Board.

To check your voter eligibility, please visit the voter eligibility page.

Learn more about them by reading their application statements and watch their candidacy videos.

When you are ready, go to the SecurePoll voting page to vote.

The vote is open from October 8 at 00:00 UTC to October 22 at 23:59 UTC.

Best regards,

Abhishek Suryawanshi
Chair, Elections Committee

MediaWiki message delivery (talk) 04:49, 9 October 2025 (UTC)

Author:Clotilde de Surville

As explained on the Wikipedia article for this "author", no such person ever existed, and the only work ascribed to her is now considered a forgery. Should this therefore be moved to the Portal: namespace, since it is not an actual author, but a pseudonym for an unknown forgerer? --EncycloPetey (talk) 20:17, 10 October 2025 (UTC)

We have many semi-historical figures in Author space, who are (or have been) attributed authorship of works. Category:Biblical figures has many such individuals. Category:Anonymous authors and Category:Pseudonyms also contain many pseudonymous unknown authors, all of which are in Author space. I personally do not consider this to be sufficient reason not to have an Author page for them. —Beleg Tâl (talk) 20:26, 10 October 2025 (UTC)

How many of those are authors of works considered to be forgeries? Right now, we have an Author page indicating the individual is a 15th century woman (with dates in the header), but we have historical research indicating (1) no such person ever existed, and (2) the work attributed to her is a 19th-century forgery. The Biblical figures in question are for works accepted by some religious traditions, and are not 19th-sentury forgeries. The categories you've listed do contain some examples of Portal namespace "authors", so those listings are equivocal on the issue. --EncycloPetey (talk) 20:33, 10 October 2025 (UTC)

The categories I listed do contain some pages in Portal space, but as far as I can see those are either non-authors or collaborations; I don't see any examples of individual attributed authors in Portal space. And yes, many of those works are forgeries, including some works accepted by some religious tradition; The Testament of Solomon is one such work that I worked on recently. —Beleg Tâl (talk) 21:26, 10 October 2025 (UTC)

That being said, I personally would consider making the page Author:Clotilde de Surville about the pseudonymous forger (fl. 1803) themselves, rather than on the fictitious 16th-century persona. —Beleg Tâl (talk) 21:27, 10 October 2025 (UTC)

see also Author:Pseudo-Dionysius the Areopagite, and w:Lee Israel. and there are other famous examples. note the controversy and move on. --Slowking4 ‽ digitaleffie's ghost 01:59, 12 October 2025 (UTC)

Agree about leaving in author space. I think trying to separate "forgeries" from "heteronyms" / "alter egos" and other pseudonyms into different namespaces will just cause fruit for future arguments, e.g. is w:Émile Ajar a forgery to win the Prix Goncourt a second time, the heteronyms of w:Fernando Pessoa (e.g.w:Alberto Caeiro), etc. MarkLSteadman (talk) 04:18, 12 October 2025 (UTC)

This seems like the most logical way to handle it (with some exploitation about the persona vs. forger in the notes field), and avoids the sorts of arguments MarkLSteadman mentions.—Tcr25 (talk) 11:18, 13 October 2025 (UTC)

Should that still be left with the fake dates, though ? -- Beardo (talk) 13:22, 13 October 2025 (UTC)

No, with the fl. date as Beleg Tâl suggest for the "author", but noting that the persona was supposed be from the 16th century seems helpful for context. —Tcr25 (talk) 17:27, 13 October 2025 (UTC)

Just wanted to also add that it might be necessary to have separate WD items for the forger and for the fictitious persona, but that shouldn't be a problem. —Beleg Tâl (talk) 03:16, 14 October 2025 (UTC)

Portal for events

I'm interested in making a portal about several things mentioned in the Oct. 24, 1929 of the The New York Times. How would I go about and do that? Nighfidelity (talk) 21:57, 12 October 2025 (UTC)

That seems like a rather vague sort of Portal. Normally we just host copies of newspapers in the Mainspace and have a table of contents. What would a Portal add? --EncycloPetey (talk) 22:58, 12 October 2025 (UTC)

I'm interested in making a portal of the Great Depression, as we don't have a portal for that. Nighfidelity (talk) 00:19, 13 October 2025 (UTC)

@Nighfidelity: That'd be great! Works made during the Depression documenting itself, and about it retroactively, do exist here. We also have Portal:Years. Just throwing that out there. Though we don't have one for 1929. And the public-domain status of all 1930 works is only 2.5 months away roughly! SnowyCinema (talk) 00:38, 13 October 2025 (UTC)

Tech News: 2025-42

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

Weekly highlight

• Last week, improvements to account security and two-factor authentication (2FA) features were enabled across all wikis. These changes include user interface improvements for Special:AccountSecurity, the support of multiple 2FA methods via authenticator apps and portable security keys (previously users could only enable one method), and a new Recovery Codes module which facilitates fewer account lockouts due to lost two-factor apps and devices. As part of the Account Security project, work is continuing through the rest of 2025 on further user experience improvements, and support for passkeys as an alternate second factor.

Updates for editors

• Another part of the Account security project is making 2FA generally available to all users. Along with editors with advanced privileges, such as administrators and bureaucrats, 40% of editors now have access to 2FA. You can check if you have access at Special:AccountSecurity. Instructions for activation are on the linked page. The plan is to continue increasing availability if it is determined that the user support capabilities are able to support global usage. [14]
• This week, users at wikis where talk page Usability Improvements are already available by default (everywhere except the 12 wikis listed in T379264) will gain the ability to Thank a comment directly from the talk page it appears on. Before this change, Thanking could only be done by visiting the revision history of the talk page. You can learn more about this change. [15]
• Users who have not verified their email address will soon be receiving monthly Notification reminders to do so. This is because users who have verified their email can more easily recover their account. These reminders will not be sent if the user is inactive or removes the unverified email from their account. [16][17]
• View all 21 community-submitted tasks that were resolved last week. For example, a fix was made for an occasional error with saving translated paragraphs in the Content Translation tool, and the related error messages are now easier to see. [18]

Updates for technical contributors

• The Unsupported Tools Working Group has chosen Video2Commons as the first tool for its pilot cycle. The group will explore ways to improve and sustain the tool over the coming months. Learn more on Meta.
• Detailed code updates later this week: MediaWiki

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

MediaWiki message delivery 18:59, 13 October 2025 (UTC)

Book title of The Harveian orations

I have created some remarkable orations by eminent people of The Royal College of Physicians. I need some clarification about the title of these works. Some are like this: The Harveian Oration 1870; while others have: The Harveian oration delivered at the Royal College of Physicians June 26, 1869 and The Passing of Morbid Anatomy. Which one is to be followed for a uniform way. Rajasekhar1961 (talk) 11:42, 14 October 2025 (UTC)

What aspect are you trying to make uniform? If the publications all have different titles, we don't force them to be uniform. You might instead start collecting them at a Portal:Harveian Orations. --EncycloPetey (talk) 22:36, 14 October 2025 (UTC)

Looking for New York City pages to proofread

Hi guys, it's me again for another year of WikiConference North America editing challenge (see conversation from last year). This year, we already identified Index:Lamb - History of the city of New York - Volume 1.djvu to transcribe. But I need more than 12 pages to proofread/validate. Can someone point me to another New York City-related publication that needs proofreading/validating? OhanaUnited^{Talk page} 21:27, 14 October 2025 (UTC)

Additional possibilities:

• A Description of the New York Central Park (1869) (external scan)
• Souvenir of New York (1889) [photo-book] (external scan)
• The Statue of Liberty, indelible photographs (1890) (external scan)
• How to Know New York City (1895) [guidebook] (external scan)
• Handbook of the New York Public Library (1921) (external scan)

--EncycloPetey (talk) 22:32, 14 October 2025 (UTC)

 Comment @OhanaUnited: Please add stuff to Portal:New York City if you find them for this. The city portals need appreciation. Thanks! SnowyCinema (talk) 22:33, 14 October 2025 (UTC)

Thank you both. I'm going to use Index:Lamb - History of the city of New York - Volume 2.djvu and Index:Lamb - History of the city of New York - Volume 3.djvu to maintain consistency. OhanaUnited^{Talk page} 03:34, 15 October 2025 (UTC)

• See: Portal:New York City Shouldn't we be using the sentence case, it currently reads as grammatically odd: "most populous city in the United States, located at the southern tip of New York State on one of the world's largest natural harbors" but shouldn't it read like a sentence: "New York City is the most populous city in the United States, located at the southern tip of New York State on one of the world's largest natural harbors."? End with a period and start with a majuscule and contain the actual subject. Both humans and computers prefer a full sentence to get the context correct. --RAN (talk) 17:30, 17 October 2025 (UTC)

  The phrase "sentence case" refers to a pattern of capitalization where only the first word and proper nouns are capitalized; it does not mean that the result is an actual sentence. For example, Harry Potter and the chamber of secrets is in sentence case, but is not a sentence. --EncycloPetey (talk) 17:36, 17 October 2025 (UTC)

• Using a sentence case when a title case is called for is interesting for a book on Wizards, but it looks odd used for a reference website. I think we should use a full sentence and include the subject in the sentence. Both humans and computers prefer a full sentence to get the context correct. --RAN (talk) 17:54, 17 October 2025 (UTC)

  Ummm... I think you still misunderstand what title case and sentence case refer to. I don't understand what you are saying about title case. This is title case: Title Case is Capitalizing All Words Except for Short Words Like Articles, Prepositions, and Conjunctions. How is title case "called for" in the Portal description we're discussing? Using sentence case on the existing description would simply capitalize "Most", and doing so would not make it a sentence. Putting something into sentence case is merely a pattern of capitalization, and has nothing to do with the grammar of making something into a sentence. Sentence case is also the preferred form of titles in the Library of Congress database, so it is not odd at all for a reference website. --EncycloPetey (talk) 19:19, 17 October 2025 (UTC)