Wikisource:Scriptorium

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

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)

Add {{Text removed}} and {{Image removed}} to Wikisource:Annotations#What_are_not_annotations?

These two templates are 13 years old and currently used on 516 and 507 pages respectively to indicate text or images were removed from a page to make it license complaint but could be considered unacceptable annotations: "Annotations change the informational content of a work on Wikisource from its original source" which these certainly do. While arguable a scan quality indicator like {{missing table}} as indicating missing content, it isn't a perfect fit as they are different in nature. I therefore suggest that we codify this practice into policy as exemptable from trigerring the Annotations policy requirements such as declaration, clean texts, etc. to relect their use. MarkLSteadman (talk) 06:51, 5 September 2025 (UTC)

 Support No reason not to. Making it explicitly a policy helps cleans up the very underdeveloped policy and/or guidelines here on WS. ⸺ googoo0202 (he/him) (talk, contrib) 12:11, 8 September 2025 (UTC)

 Support per nom —Beleg Âlt ^BT (talk) 19:22, 8 September 2025 (UTC)

 Support per nom. --EncycloPetey (talk) 19:26, 8 September 2025 (UTC)

 Support - makes sense. -- Beardo (talk) 00:10, 9 September 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)

Repairs (and moves)

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

See also Wikisource:Scan lab

The Doctrine and Covenants

Can this be moved to The Doctrine and Covenants (unsourced) for a versions page (that would mention that version and The Doctrine and Covenants (1922 RLDS))? TE(æ)A,ea. (talk) 13:02, 5 September 2025 (UTC)

Done It may take some time for the system to process the header updates, but every page I checked should default to the correct basepage after it updates. --EncycloPetey (talk) 23:59, 13 September 2025 (UTC)

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.

Index:Englishhistorica36londuoft.djvu=

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

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)

Other discussions

Temporary accounts will be rolled out soon

Hello, we are the Wikimedia Foundation Product Safety and Integrity team. We would like to announce that we plan to enable temporary accounts for this wiki in the week of September 8 or 15.

Temporary accounts are successfully live on 30 wikis, including many large ones like German, Japanese, and French. The change they bring is especially relevant to logged-out editors, who this feature is designed to protect. But it is also relevant to community members like mentors, patrollers, and admins – anyone who reverts edits, blocks users, or otherwise interacts with logged-out editors as part of keeping the wikis safe and accurate.

Why we are building temporary accounts

Our wikis should be safer to edit by default for logged-out editors. Temporary accounts allow people to continue editing the wikis without creating an account, while avoiding publicly tying their edits to their IP address. We believe this is in the best interest of our logged-out editors, who make valuable contributions to the wikis and who may later create accounts and grow our community of editors, admins, and other roles. Even though the wikis do warn logged-out editors that their IP address will be associated with their edit, many people may not understand what an IP address is, or that it could be used to connect them to other information about them in ways they might not expect.

Additionally, our moderation software and tools rely too heavily on network origin (IP addresses) to identify users and patterns of activity, especially as IP addresses themselves are becoming less stable as identifiers. Temporary accounts allow for more precise interactions with logged-out editors, including more precise blocks, and can help limit how often we unintentionally end up blocking good-faith users who use the same IP addresses as bad-faith users.

How temporary accounts work

Any time a logged-out user publishes an edit on this wiki, a cookie will be set in this user's browser, and a temporary account tied with this cookie will be automatically created. This account's name will follow the pattern: ~2025-12345-67 (a tilde, current year, a number). On pages like Recent Changes or page history, this name will be displayed. The cookie will expire 90 days after its creation. As long as it exists, all edits made from this device will be attributed to this temporary account. It will be the same account even if the IP address changes, unless the user clears their cookies or uses a different device or web browser. A record of the IP address used at the time of each edit will be stored for 90 days after the edit. However, only some logged-in users will be able to see it.

What does this mean for different groups of users?

For logged-out editors

• This increases privacy: currently, if you do not use a registered account to edit, then everybody can see the IP address for the edits you made, even after 90 days. That will no longer be possible on this wiki.
• If you use a temporary account to edit from different locations in the last 90 days (for example at home and at a coffee shop), the edit history and the IP addresses for all those locations will now be recorded together, for the same temporary account. Users who meet the relevant requirements will be able to view this data. If this creates any personal security concerns for you, please contact talktohumanrights at wikimedia.org for advice.

For community members interacting with logged-out editors

• A temporary account is uniquely linked to a device. In comparison, an IP address can be shared with different devices and people (for example, different people at school or at work might have the same IP address).
• Compared to the current situation, it will be safer to assume that a temporary user's talk page belongs to only one person, and messages left there will be read by them. As you can see in the screenshot, temporary account users will receive notifications. It will also be possible to thank them for their edits, ping them in discussions, and invite them to get more involved in the community.

For users who use IP address data to moderate and maintain the wiki

• For patrollers who track persistent abusers, investigate violations of policies, etc.: Users who meet the requirements will be able to reveal temporary users' IP addresses and all contributions made by temporary accounts from a specific IP address or range (Special:IPContributions). They will also have access to useful information about the IP addresses thanks to the IP Info feature. Many other pieces of software have been built or adjusted to work with temporary accounts, including AbuseFilter, global blocks, Global User Contributions, and more. (For information for volunteer developers on how to update the code of your tools – see the last part of the message.)
• For admins blocking logged-out editors:
  • It will be possible to block many abusers by just blocking their temporary accounts. A blocked person won't be able to create new temporary accounts quickly if the admin selects the autoblock option.
  • It will still be possible to block an IP address or IP range.
• Temporary accounts will not be retroactively applied to contributions made before the deployment. On Special:Contributions, you will be able to see existing IP user contributions, but not new contributions made by temporary accounts on that IP address. Instead, you should use Special:IPContributions for this.

Our requests for you, and next steps

• If you know of any tools, bots, gadgets etc. using data about IP addresses or being available for logged-out users, you may want to test if they work on testwiki or test2wiki. If you are a volunteer developer, read our documentation for developers, and in particular, the section on how your code might need to be updated.
• If you want to test the temporary account experience, for example just to check what it feels like, go to testwiki or test2wiki and edit without logging in.
• Tell us if you know of any difficulties that need to be addressed. We will try to help, and if we are not able, we will consider the available options.
• Look at our previous message about requirements for users without extended rights who may need access to IP addresses.

To learn more about the project, check out our FAQ – you will find many useful answers there. You may also look at the updates (we have just posted one) and subscribe to our new newsletter. If you'd like to talk to me (Szymon) off-wiki, you will find me on Discord and Telegram. Thank you! NKohli (WMF), SGrabarczuk (WMF) (talk) 23:52, 28 August 2025 (UTC)

Did anybody try this out with ProofreadPage? In the Page: namespace ProofreadPage saves the username in the page and then limits certain actions (changing proofreading level) based on that username (the same user cannot mark a page as Proofread and as Validated; that has to be done by two separate users). Non-logged in users for this reason cannot use this ProofreadPage feature. But users with temporary accounts are logged in (as the temporary user account) and so may circumvent this restriction (even inadvertently). CC @SGrabarczuk (WMF). I believe there's a Phab for this down in the deps for the main task somewhere, but I can't recall the number ottomh. Xover (talk) 13:46, 1 September 2025 (UTC)

Hey @Xover, thanks a lot for this comment! I will immediately let the team know.

The only Phab task about temp accounts and ProofreadPage I could dig out is this: T326940. Let's see if we need to create a sub-task... SGrabarczuk (WMF) (talk) 14:13, 1 September 2025 (UTC)

Hi @Xover I looked for an open task but couldn't find any besides the one Szymon found above. Also noting that we are now deployed on all wikisources except English and Swedish (pending LiquidThreads migration) and so far haven't heard about any issues. -- NKohli (WMF) (talk) 10:34, 3 September 2025 (UTC)

@NKohli (WMF): If this is an issue it will take the communities some time to discover it, so lack of feedback is not necessarily indicative.

However, from the discussion in T326940 it is possible (I'm having trouble parsing the information in that discussion with entire confidence) that this is not an issue at all. Iff I understood it correctly, the ability to change proofreading status of ProofreadPage-managed pages in the Page: namespace is gated not on logged-in or not, but on the pagequality permission that is only assigned to the specific group users; and, again iff I understood correctly, temporary accounts can never be a member of that group. If so this is not an actual issue.

@Sohom Datta: Can you answer this authoritatively (fsvo) based on your testing in that Phab? Xover (talk) 11:59, 4 September 2025 (UTC)

@Xover, going through the conversation and re-testing, the APIs that ProofreadPage uses return the correct information and store it in the Page: namespace. ProofreadPage gates by the presence or absence of the pagequality userright and when $wgGroupPermissions['*']['pagequality'] = true; is set temporary accounts are allowed to edit page quality, whereas if the values are set as $wgGroupPermissions['user']['pagequality'] = true; then the UI does not allow the pagequality to be set. I would say this minimally works as I would expect. Sohom (talk) 14:30, 8 September 2025 (UTC)

cc @SGrabarczuk (WMF) and @NKohli (WMF) as well! Sohom (talk) 14:31, 8 September 2025 (UTC)

@Sohom Datta: Thank you! Xover (talk) 15:11, 8 September 2025 (UTC)

Wikisource:Requests for comment

there's 5 "open" rfcs from years ago, can these be closed? ltbdl (talk) 06:07, 1 September 2025 (UTC)

The process in its entirety is {{historical}} by now. I've tagged it as such. — Alien  3
3 3 06:48, 1 September 2025 (UTC)

on this topic, are we not doing RFCs at all now? everything should be done here in ws:scriptorium ? ⸺ googoo0202 (he/him) (talk, contrib) 12:14, 8 September 2025 (UTC)

The RFC page had 19 edits in its entire twelve-year history. This has been the de facto discussion page for most everything for many years now, aside from deletion and copyvio discussions, plus a few other specifics. --EncycloPetey (talk) 18:26, 8 September 2025 (UTC)

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)

Template:PD-NigeriaGov

We have a lot of active contributors currently working to add texts that were published by the Nigerian government, but we have on {{PD-NigeriaGov}} as we do for other countries like Norway's {{PD-NorwayGov}}. Examples include:

• 100 Facts About Nigeria (start transcription)
• A March of Progress - Collected Speeches of His Excellency Lt. General Olusegun Obasanjo (transcription project)
• Ibos in a United Nigeria (transcription project)

Could someone with sufficient knowledge of copyright law please look into phrasing a suitable template for use on the Nigerian works? --EncycloPetey (talk) 20:12, 3 September 2025 (UTC)

I am not an expert on Nigerian law, but I think that c:Commons:Copyright_rules_by_territory/Nigeria is a sensible place to start and at least consistent with the kinds of works likely to be uploaded at c:. —Justin (koavf)❤T☮C☺M☯ 21:00, 3 September 2025 (UTC)

• Which says: “Notice there is no exception for government works – quite the opposite, they are very broadly covered.” Because of URAA restoration and Nigeria’s 70-year term for government works, they are all copyrighted in the United States for 95 years after publication (unless it’s covered by the edicts-of-government doctrine). TE(æ)A,ea. (talk) 21:04, 3 September 2025 (UTC)

  There are sections of the Nigerian Copyright act that speaks to the exclusion of

  Section 3(b)

  (b) official texts of a legislative or administrative nature as well as any

  official translations, except their compilations; and

  Section 20(1)(i)

  (i) any use made of a work by or under the direction or control of the

  Government or by such public libraries, non-commercial documentation

  centres and scientific or other institutions as may be prescribed, where the

  use is in the public interest, provided that —

  (i) no revenue is derived, and

  (ii) the use does not substantially affect the potential market or value

  of the work ; Ifedohlapo (talk) 21:49, 3 September 2025 (UTC)

  The above was quoted from the Nigerian Copyright Act 2022, and i noticed that information in the duration section on this page https://commons.wikimedia.org/wiki/Commons:Copyright_rules_by_territory/Nigeria

  was cited from the 2004 Copyright Act Ifedohlapo (talk) 21:52, 3 September 2025 (UTC)

  Are the three works cited above even eligible for inclusion on Wikisource. I feel like they might be copyvio. ToxicPea (talk) 22:00, 3 September 2025 (UTC)

  Why do you say so? Ifedohlapo (talk) 22:04, 3 September 2025 (UTC)

  Because they don't appear to be a work of a legislative or administrative nature and are therefore eligible for copyright. ToxicPea (talk) 22:11, 3 September 2025 (UTC)

  and what about the second section quoted which falls under the 'part II-Exceptions to Copyright' section of the Act? Ifedohlapo (talk) 22:17, 3 September 2025 (UTC)

  Section 20.1 states

  20.—(1) The rights conferred in respect of a work under sections 9-13 of this Act, do not include the right to control any of the acts specified in those sections by way of fair dealing for purposes such as —
  
  

  and 20.1.i states

  (i) any use made of a work by or under the direction or control of the Government or by such public libraries, non-commercial documentation centres and scientific or other institutions as may be prescribed, where the use is in the public interest, provided that —

  (i) no revenue is derived, and

  (ii) the use does not substantially affect the potential market or value of the work ;
  
  

  The way I interpret that is that a copyright holder cannot legally prevent said parties from using their work in the public interest subject to the subsections 20.1.i.i and 20.1.i.ii. That doesn't put a government work into the public domain. This section appears to be about exemptions to copyright protection for copyrighted works, sort of like fair use in the United States, not about exemptions to copyright itself. ToxicPea (talk) 22:23, 3 September 2025 (UTC)

  I would consult a copyright lawyer on this, but the way i interpret this section is that works published under the direction or control of the government are not be protected by any copyright under certain conditions, especially if they are used in the public interest and the other conditions added in (i) and (ii) Ifedohlapo (talk) 22:36, 3 September 2025 (UTC)

  Right, and the Wikimedia general rules stipulate that restrictions like non-commercial are not acceptable. One must be able to sell machines that have Wikisource offline or expensive physical copies of Wikisource works, for example.--Prosfilaes (talk) 23:07, 3 September 2025 (UTC)

  I've started a discussion at Wikisource:Copyright discussions#Nigerian Works regarding the copyright of the works above. ToxicPea (talk) 23:12, 3 September 2025 (UTC)

  Okay then, thanks.

  I feel the information on

  https://commons.wikimedia.org/wiki/Commons:Copyright_rules_by_territory/Nigeria should also be looked into

  The new Copyright Act of 2022, has repealed the Copyright Act of 2004, so some of the information there should be updated. Ifedohlapo (talk) 05:17, 4 September 2025 (UTC)

  I've noticed that there's also no {{PD-Nigeria}} for non government works whose copyright has expired in Nigeria. We should probably both a {{PD-Nigeria}} and a {{PD-NigeriaGov}} as two separate templates. ToxicPea (talk) 23:23, 3 September 2025 (UTC)

  Do we need a template for PD-Nigeria ? We don't have those for every country. -- Beardo (talk) 01:16, 4 September 2025 (UTC)

  We have those for quite a few countries and I doubt it hurt to have it. ToxicPea (talk) 01:21, 4 September 2025 (UTC)

  I think it's also encouraging for people adding works from a particular country, to see a template specific to that country. And we've had a group of interested contributors arrive in the past month. --EncycloPetey (talk) 02:58, 4 September 2025 (UTC)

  I am not sure whether we really need PD-Nigeria template for non-governmental works, as the US copyright of these is covered by the PD-US tag. But the PD-NigeriaGov template seems really needed. @Ifedohlapo: Do you think you could prepare a draft of the text of this licence tag that would cover what has been discussed above? It can be suggested e. g. at Template talk:PD-NigeriaGov. --Jan Kameníček (talk) 13:54, 14 September 2025 (UTC)

  I have prepared a draft for the licence tag. You can check it out here Template talk:PD-NigeriaGov

  Ifedohlapo (talk) 16:17, 15 September 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)

Erroneous image based indexes

The index Index:"Red"·Fed·Memoirs-Hickey-1925.pdf is in the category Category:Image based indexes even though it doesn't appear to be an image based index. There are also other indexes like this. I feel like this is unintentional. ToxicPea (talk) 23:44, 4 September 2025 (UTC)

Looks like it was because the Cover Image field had an image file instead of a page number. I updated it for this Index, but I agree that this is unexpected behaviour. —Beleg Tâl (talk) 00:15, 5 September 2025 (UTC)

Does this look better? Categorizes by source type, adds separate tracking category for non-image-based indexes using a full image specification. Module:Proofreadpage index template/sandbox; Module:Proofreadpage index template/config/sandbox#L-184--L-202. —CalendulaAsteraceae (talk • contribs) 23:09, 8 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:51, 1 October 2025 (UTC)

Strange "w T " errors

Does anyone have any insight as to why we have hundreds of instances of errors like the three fixed here, where words starting with a "w" have a spaced "T" inserted before the next letter? They do not reflect anything in the text scanned. BD2412 T 04:07, 6 September 2025 (UTC)

The contributor that created the page you reference, mass-created about a quarter of a million wikipages in the Page: namespace with essentially raw OCR text. But as they always got very offended when I referred to it as "raw OCR" I imagine they had some kind of script to fix scannos involved as well. In other words, if the pages in which you find these artefacts were all created by the same contributor the answer to your question is most likely "a quirk of the OCR or scannos script they used". Xover (talk) 07:06, 6 September 2025 (UTC)

Hmm, no, they're just overrepresented because they created by far the most garbage pages. This appears in pages bot-created by others tagged as just uploading the hidden text layer from the file. It then seems most likely that all this text was generated by the same OCR engine, and that the w T is a quirk of that specific engine (Tesseract has quite a few quirks of that nature). Xover (talk) 07:19, 6 September 2025 (UTC)

• It looks to me like the serif ascender of the w on the right-most side, which is separated in this book, is interpreted as a short or small T, because the diagonal line on the right of the w is very thin and wears out—that’s my guess, anyway. (It’s really clear if you open up the image and zoom in all the way.) TE(æ)A,ea. (talk) 13:55, 6 September 2025 (UTC)

Referencing template request

Is there a template or set of templates I can use to create a reference that links to a note that is transcluded on a separate page. ToxicPea (talk) 02:24, 7 September 2025 (UTC)

@ToxicPea: I believe {{authority reference}} is what you're looking for, but it's hard to tell without knowing what text you have it mind for. Xover (talk) 06:16, 7 September 2025 (UTC)

I want to use this for Index:The 9-11 Commission Report (Official Government Edition).djvu although I've seen other texts that could benefit from this such as Introductory Material to the Final Report of the Select Committee to Investigate the January 6th Attack on the United States Capitol. Here the notes for each chapter are collected at the end and because they are so long it doesn't make sense to transclude them on the same page as the main chapter text. The notes will almost certainly be transcluded on a different subpage. I want to have a pair of references that can link between these subpages. ToxicPea (talk) 13:13, 7 September 2025 (UTC)

Hmm. Ok, so we're dealing with voluminous endnotes, grouped by chapter. So we will have subpages like /Chapter 1 and /Chapter 2, accompanied by pages for /Notes to chapter 1 and /Notes to chapter 2. Note numbering is unique only per chapter, and the precise note number is important in order to be able to refer to a specific footnote from the report. So we want to be able to insert references in /Chapter 1 where we specify the footnote number, and that links directly to the note with that number on the notes page for that chapter. Does that sound about right?

I think we might be able to do that by extending {{ref}} to support specifying a different wikipage in addition to the note number. You would have to use it something like {{ref|Notes to chapter 1|42}} to get it to work, which is maybe a bit tedious and noisy in the wikitext source. Xover (talk) 14:59, 7 September 2025 (UTC)

That sounds perfectly fine to me. ToxicPea (talk) 15:18, 7 September 2025 (UTC)

Are the comments on Help:Footnotes and endnotes#Endnotes relevant ? -- Beardo (talk) 16:42, 7 September 2025 (UTC)

Problems with a couple of indexes

There seem to be problems with Index:Completepoetical1848sout.djvu, Index:System of Logic.djvu, Index:The Mythology of the Aryan Nations.djvu and Index:The complete poetical works and letters of John Keats, 1899.djvu - all they show is "#invoke:Proofreadpage index template". The related Files look fine. Any ideas ? -- Beardo (talk) 17:02, 7 September 2025 (UTC)

@Beardo it's related to the TOC.If a remove some lines at the end of "Table of Contents" field, the index is successfully displayed. Is there a size limit? • M-le-mot-dit (talk) 17:25, 7 September 2025 (UTC)

Thank you. How strange. This seems to be a recent problem, as the Pages have just appeared in the orphaned pages list - so something must have changed in the last three days. -- Beardo (talk) 19:51, 7 September 2025 (UTC)

I'm not actually sure why it's failing, since the debug info doesn't show it exceeding any of the usual limits (memory size, execution time, etc.).

However, on a general note: please, for all that is good and holy, please stop using those templates that try to fake dot leaders. Reproducing dot leaders is entirely unnecessary, and since dot leaders are not supported in web standards all of them use various ugly hacks that rarely work very well. And in this particular case those four pages of toc, using those templates, expand to 708kB of wikitext which in turn is turned into 1.2MB of HTML. That's 1.2MB for everyone visiting the page to download just for the toc. I'l spare you the uglyness of all of that HTML output just because I don't want to inflict it on everyone reading the Scriptorium, but it's about 3000 lines of this:

<table class="ws-summary wst-dtpl">

<tbody><tr>
<td><div style="position:relative; width:100%;"><div style="max-width:80%; text-align:left; text-indent:-2em; margin-left:2em;"><div class="toc-line-entry-text wst-dtpl-background" style="display:inline; position:relative; text-align:left; padding:0.0em 0.5em 0.0em 0.0em; z-index:2;"><span class="wst-gap &#95;_gap" style="display:inline-block; inline-size:2em"></span>Mohammed; a Fragment</div></div><div class="ws-noexport wst-dtpl-background" style="position:absolute; left:0px; bottom:0px; width:2em; height:1.00em; z-index:1;"></div><div class="ws-noexport" style="position:absolute; right:0px; bottom:0px; width:100%; overflow:hidden; white-space:nowrap; text-align:right; z-index:0;"><div style="display:inline; float:right;">.&#160;&#160;&#160;.&#160;&#160;&#160;.&#160;&#160;&#160;.&#160;&#160;&#160;.&#160;&#160;&#160;.&#160;&#160;&#160;.&#160;&#160;&#160;.&#160;&#160;&#160;.&#160;&#160;&#160;.&#160;&#160;&#160;.&#160;&#160;&#160;.&#160;&#160;&#160;.&#160;&#160;&#160;.&#160;&#160;&#160;.&#160;&#160;&#160;.&#160;&#160;&#160;.&#160;&#160;&#160;.&#160;&#160;&#160;.&#160;&#160;&#160;.&#160;&#160;&#160;.&#160;&#160;&#160;.&#160;&#160;&#160;.&#160;&#160;&#160;.&#160;&#160;&#160;.&#160;&#160;&#160;.&#160;&#160;&#160;.&#160;&#160;&#160;.&#160;&#160;&#160;.&#160;&#160;&#160;.&#160;&#160;&#160;.&#160;&#160;&#160;.&#160;&#160;&#160;.&#160;&#160;&#160;.&#160;&#160;&#160;.&#160;&#160;&#160;.&#160;&#160;&#160;.&#160;&#160;&#160;.&#160;&#160;&#160;.&#160;&#160;&#160;.&#160;&#160;&#160;.&#160;&#160;&#160;.&#160;&#160;&#160;.&#160;&#160;&#160;.&#160;&#160;&#160;.&#160;&#160;&#160;.&#160;&#160;&#160;.&#160;&#160;&#160;.&#160;&#160;&#160;.&#160;&#160;&#160;.&#160;&#160;&#160;.&#160;&#160;&#160;.&#160;&#160;&#160;.&#160;&#160;&#160;.&#160;&#160;&#160;.&#160;&#160;&#160;.&#160;&#160;&#160;.&#160;&#160;&#160;.&#160;&#160;&#160;.&#160;&#160;&#160;.&#160;&#160;&#160;.&#160;&#160;&#160;.&#160;&#160;&#160;.&#160;&#160;&#160;.&#160;&#160;&#160;.&#160;&#160;&#160;.&#160;&#160;&#160;.&#160;&#160;&#160;.&#160;&#160;&#160;.&#160;&#160;&#160;.&#160;&#160;&#160;.&#160;&#160;&#160;.&#160;&#160;&#160;.&#160;&#160;&#160;.&#160;&#160;&#160;.</div></div></div>
</td>
<td style="text-align:right; vertical-align:bottom; padding:0.0em 0.0em 0.0em 0.5em; width:2.0em;">839
</td></tr></tbody></table>

If I could get one wish granted by a genie it would be for the community to ban {{dtpl}}. If I could have two it would be to also ban all templates trying to fake dot leaders. With my third I'd ask for world peace.

The size of this is almost certainly why it's failing, logically speaking, but it's doing so in interesting new ways that's hiding the root cause. I'm guessing because ProofreadPage is in the mix here, and not just vanilla MediaWiki. --Xover (talk) 20:31, 7 September 2025 (UTC)

Yeah, what's going on here is probably that we're hitting one of the usual limits but because the module is being called from ProofreadPage instead of directly by MediaWiki, and ProofreadPage isn't catching and propogating the error, we don't see any of the normal indicators of what the problem is. That's going to make it a bit harder to debug (and to catch any other indexes affected). Xover (talk) 10:08, 8 September 2025 (UTC)

As mentioned, something seems to have changed recently, as the pages from those four indexes appeared as orphaned with the latest report. If the error causes the pages to appear as orphaned, does that mean that there might not be other indexes affected ? (Or we'll see when the report runs again.) -- Beardo (talk) 00:09, 9 September 2025 (UTC)

Those four were sorted by @CalendulaAsteraceae, I believe. Two more have now popped up - Index:A life of William Shakespeare (IA lifeofwilliamsha02lees).pdf and Index:Withgodbookofpra00las.djvu. I think that the orphaned pages only shows an issue where there are pages not transcluded - so there could be other indexes with this problem which are fully transcluded? -- Beardo (talk) 20:37, 13 September 2025 (UTC)

Seems likely. I'm not sure of a better way to find them than going through all the page-namespace pages which use one of the dot leader templates and checking their indexes.

Probably the thing that changed is that one of the recent edits to Module:Proofreadpage index template by me and @Alien333 made the index display a little more expensive, which doesn't matter for most pages but pushed some indexes with expensive TOCs over the edge. —CalendulaAsteraceae (talk • contribs) 03:37, 14 September 2025 (UTC)

Is this rule aligned properly?

See: Jersey_Journal/1930/Chamber_Backing_Eddie_Schneider_For_Globe_Flight where the rule is misaligned. Is it just for me in Chrome, or do others see it? If I remove the images to the right, they align properly. This started about a week ago. RAN (talk) 20:13, 7 September 2025 (UTC)

• It didn’t work for me either (in IE/Edge), so I wrapped it all in a block center. TE(æ)A,ea. (talk) 20:37, 7 September 2025 (UTC)

  FWIW, that edit fixes the problem for me, which error did appear in Firefox in the pre-edit version of the page. --EncycloPetey (talk) 21:03, 7 September 2025 (UTC)

• What changed over the past week to create the error? Thanks for the {{bc}} tip, but we have to figure out what changed recently, to fix the hundreds of others. Switch between layout1 and layout2 and you can see it is only in one layout. --RAN (talk) 22:40, 7 September 2025 (UTC)
• It looks like it has been fixed, thank you to whoever worked out what was changed, and fixed it. --RAN (talk) 19:02, 10 September 2025 (UTC)

Tech News: 2025-37

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

Weekly highlight

• The Editing team is working on a new check: Paste check. This check informs newcomers who paste text into Wikipedia that the content might not be accepted. This check is an effort to increase the likelihood that the new content people are adding to Wikipedia is aligned with the Movement's commitment to offering information under a free content license. This check will soon be tested at a few wikis. If your community is interested in this test, please tell us in this task, or contact the team.

Updates for editors

• Later this week, users of the "Improved Syntax Highlighting" beta feature will be able to use a linting tool to see errors or other potential problems in wikitext in real time. See the help page for more information. [1]
• When browsing a wiki (like en.wikipedia.org), the software responds in one of two ways: a desktop page, or a redirect to a mobile version on an "m" domain (like en.m.wikipedia.org). Over the next three weeks, MediaWiki will start displaying the mobile version to mobile devices directly on the standard domain, without this redirect. This change does not affect existing m-dot URLs, or the "Desktop view" opt-out. Learn more. [2]
• When an edit changes the categories of a page, the changes to the category membership counts are now happening asynchronously. This improves the speed of saving edits, especially when moving many pages to or from the same category, and reduces the risk of site outages, but it means that the counts can show outdated information for a few minutes. [3]
• Edits on Wikidata to qualifiers (properties and values) and references (properties and values) in a Wikidata item statement will now not add entries to the RecentChanges or Watchlist pages on all other Wikis. This is a temporary change to improve performance while other solutions are created. Wikidata's own pages remain unchanged. Learn more. [4][5]
• Japanese-language wikis have had a major upgrade to the way that search works. The new search should generally give more accurate and more relevant search results. [6]
• View all 31 community-submitted tasks that were resolved last week.

Updates for technical contributors

• 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 01:14, 9 September 2025 (UTC)

Template:Cursive

The text displayed using this template is near microscopic for me now, and while this is exacerbated by a recent style change, that's not the only factor.

This font size is greatly reduced so that it's unreadable.

Is there a way to force the text to appear at standard size instead of so reduced? --EncycloPetey (talk) 03:16, 9 September 2025 (UTC)

Where are you having a problem with it? On my phone, it's got the same line height, even if the x-height is a bit smaller. It's all about the system fonts, I think.--Prosfilaes (talk) 06:59, 9 September 2025 (UTC)

I'm having the problem everywhere, including in the example above. On my screen, the lowercase "d" is only as tall as the lowercase "s" that follows it. --EncycloPetey (talk) 14:42, 9 September 2025 (UTC)

• What browser are you using, EncycloPetey? In IE/Edge it works fine—the text actually looks slightly larger than the surrounding text (although it’s just about the same). TE(æ)A,ea. (talk) 14:56, 9 September 2025 (UTC)

  Firefox, on a Mac. --EncycloPetey (talk) 14:57, 9 September 2025 (UTC)

  I expect OS matters more than browser. I'm on Windows, and {{cursive}} uses SegoeScript for me regardless of what browser I'm using. I don't know what fonts would be used on a Mac though unfortunately.

  @EncycloPetey as a workaround, you could try adding something like .wst-cursive {font-size: 200%;} to your common.css page. —Beleg Âlt ^BT (talk) 15:16, 9 September 2025 (UTC)

  That does help as a work-around, but it won't solve the problem for other editors. --EncycloPetey (talk) 16:04, 9 September 2025 (UTC)

  On my laptop with Windows, the cursive looks similar or just slightly smaller. On both an iPhone and an Android phone, the cursive is smaller - with the smaller letters about half the size, though the "d" is almost as tall. -- Beardo (talk) 17:57, 9 September 2025 (UTC)

  On Linux, it looks like the two fonts are nominally the same size, but it looks quite a bit smaller. Script fonts just tend to have a smaller x-height, and I really hate to meddle with something like this, especially as TE(æ)A,ea said it looks larger on their system.--Prosfilaes (talk) 20:20, 9 September 2025 (UTC)

  I suspect some of the script fonts are smaller than others, so depending which fonts you have installed on your system the cursive text may appear larger or smaller —Beleg Âlt ^BT (talk) 20:31, 9 September 2025 (UTC)

  The font size is also super small on my end. I'm using macOS Sequoia Version 15.6.1 and the font appears to be Snell Roundhand. I also tried on a chromebook running ChromeOS Version 139.0.7258.164 and the font on there is the same size as the rest of the text around it and appears to be Comic Sans for some reason. ToxicPea (talk) 21:11, 9 September 2025 (UTC)

  Comic Sans is often the default for the script font family on many computers/OSes/browsers. —Justin (koavf)❤T☮C☺M☯ 21:26, 9 September 2025 (UTC)

  If Snell Roundhand renders too small for a given font size, then I expect the thing to do would be to remove it from Template:Cursive/styles.css —Beleg Âlt ^BT (talk) 13:07, 10 September 2025 (UTC)

You can tinker with font-size-adjust to create a ratio of lower-case letters along with the x-height of the font. I've never done it before and I don't see the issue on my computer, so I don't think I can help much directly. —Justin (koavf)❤T☮C☺M☯ 20:28, 9 September 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)

Senator Paul on Impeachment of President Trump

I just came across this work, and was shocked to find its contents censored by consensus. I was going to add the content back myself, but felt it best to ask to overturn the (absurd) consensus beforehand. TE(æ)A,ea. (talk) 01:48, 13 September 2025 (UTC)

Why absurd? Wikisource was being used to help compromise the privacy of an individual and potentially endanger his life. It shouldn't be its own page at all; we should have the appropriate volume of the Congressional Report with this speech transcribed from that, transcluded onto the appropriate subpage.

At this point in time, there's no point in preserving the redactions. But they were an entirely reasonable action at the time.--Prosfilaes (talk) 02:40, 13 September 2025 (UTC)

• While it isn’t really brought up, we do have a neutral-point-of-view policy (WS:NPOV), and these redactions were clearly political in nature. “A neutral point of view on Wikisource means faithfully reproducing and crediting the original texts, without … reproducing only certain parts of the text.” I can’t really think of a clearer violation of this policy on Wikisource, honestly speaking. And we have many speeches from the Record which are presented without being buried in the many-subpage-deep structure that it creates. TE(æ)A,ea. (talk) 04:13, 13 September 2025 (UTC)

• They weren't political in nature; as I said, the goal of the transcription was to compromise the privacy of an individual and endanger his life; it's not political to be opposed to that. We could have deleted the whole work, instead. We shouldn't have speeches from the Record being ripped out of their context, and it would reduce or eliminate the need to make artificial titles like this.--Prosfilaes (talk) 05:34, 13 September 2025 (UTC)

Pages created by IP-users

On Danish Wikisource it turned out that there were a few pages created by ip-users and never edited by users logges in. So I made User:MGA73/Sandbox to see if the same was the case on English Wikisource. I did a few random checks and it seems to me that the pages are legit. But if anyone would like to check feel free to have a look. MGA73 (talk) 15:21, 15 September 2025 (UTC)

I note that Codex Atlanticus has ancient Italian with English translation and no information about the source of either. -- Beardo (talk) 23:42, 16 September 2025 (UTC)

Tech News: 2025-38

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

Updates for editors

• References lists that are made using the <references/> tag will now automatically display with columns in Vector 2022 when readers are using its 'standard' settings for text-size and page-width. [7]
• Starting in the week of October 6, on small wikis and medium wikis that have the CampaignEvents extension enabled, all autoconfirmed users will be able to use Event Registration as an organizer. No changes will be made for large wikis unless requested in Phabricator. This change is being made to make it easier for more people to use Event Registration, especially on wikis that are less likely to have policies related to the Event Organizer right. Learn more.
• Users that search using regular expressions (regex) can now use additional features including:
  • for the intitle: keyword: metacharacters for start-of-line (^) and end-of-line ($) anchors [8]
  • for both intitle: and insource: keywords: shorthand character classes for digits (\d), whitespace (\s), and word characters (\w); and escape codes for line feed (\r), newline (\n), tab (\t), and unicode (e.g. \uHHHH). [9]
• When you search for text that looks like an IP, the system will now show search results. It used to take you to the contributions for that IP instead of showing search results. [10]
• All wikis will be read-only for a few minutes on September 24. This is planned at 15:00 UTC. This is for the datacenter server switchover backup tests which happen twice a year. You can read more about the background and details of this process on the Diff blog.
• View all 24 community-submitted tasks that were resolved last week. For example, a bug was fixed that affected users who used the page-tabs to switch from wikitext editing of a section into the visualeditor. [11]

Updates for technical contributors

• The MediaWiki Interfaces team is redesigning the Wikimedia REST API Sandbox with Codex. If you have feedback on improvements for the API documentation or what makes developer experiences smooth (or frustrating), you’re invited to join an upcoming discovery interview, or leave feedback onwiki. Learn more.
• Edits to Wikidata aliases (an alternative name for an item or a property) will now be shown in RecentChanges and Watchlist entries on other wikis less often, reducing unnecessary notifications. This will reduce the overall quantity of 'noisy' entries. Wikidata's own pages remain unchanged. Learn more. [12]
• The new Unicode 17.0 version has been released. The datasets on Commons for the Module:Unicode data have been updated. Wikipedias that do not use the Commons datasets should either update their own data or switch to the Commons datasets.
• Users of the Wikimedia Enterprise Structured Contents endpoints can now access Parsed Tables. The new Parsed Tables feature extracts and represents Wikipedia tables in structured JSON. This improves machine accessibility as part of the Structured Contents initiative. Structured Contents output is freely available through the On-demand API, or through Wikimedia Cloud Services.
• A dataset of English Wikipedia biographical information from Wikimedia Enterprise has been published on Kaggle, for evaluation and research. This provides structured data from more than 1.5 million biographies, including birth and death dates, education, affiliations, careers, awards, and more (from a June 2024 snapshot).
• Detailed code updates later this week: MediaWiki

Meetings and events

• Scholarship applications for Wikimania 2026 in Paris, France, are open until October 31.

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

MediaWiki message delivery 17:06, 15 September 2025 (UTC)

A Phonetical Study of the Eskimo Language by William Thalbitzer

Index:A Phonetical Study of the Eskimo Language by William Thalbitzer.pdf shows "Error: No such file". There are about 30 pages that were linked to it. I suspect the original file was on Commons and has been deleted. Subsequently the book has been uploaded at - File:A Phonetical Study of the Eskimo Language (Thalbitzer, 1904).pdf - I don't know if that is the same edition.

Should the existing index and pages be moved over to the new name ? Or deleted and start afresh ? -- Beardo (talk) 23:47, 16 September 2025 (UTC)

From this, Page:A Phonetical Study of the Eskimo Language by William Thalbitzer.pdf/6, it looks like the deleted one was likely a reprint or facsimile edition. There may be some pages that are effectively the same, for example Page:A Phonetical Study of the Eskimo Language by William Thalbitzer.pdf/8, so moving the pages over may save a little work, but the pages are likely to be out of synch with the Wikisource-hosted version of the file. —Tcr25 (talk) 00:17, 17 September 2025 (UTC)

• It was deleted per this discussion, which mentioned that it was a facsimile reprint. Since this is an original (I think), we should to this file rather than getting the file undeleted and locally re-uploaded. TE(æ)A,ea. (talk) 02:57, 17 September 2025 (UTC)

  Thanks. I will mark this index for deletion. -- Beardo (talk) 03:12, 17 September 2025 (UTC)

Server switch - Your wiki will be read-only for a short time soon

Read this message in another language • Please help translate to your language

The Wikimedia Foundation will switch the traffic between its data centers. This will make sure that Wikipedia and the other Wikimedia wikis can stay online even after a disaster.

All traffic will switch on 24 September. The switch will start at 15:00 UTC.

Unfortunately, because of some limitations in MediaWiki, all editing must stop while the switch is made. We apologize for this disruption, and we are working to minimize it in the future.

A banner will be displayed on all wikis 30 minutes before this operation happens. This banner will remain visible until the end of the operation. You can contribute to the translation or proofreading of this banner text.

You will be able to read, but not edit, all wikis for a short period of time.

• You will not be able to edit for up to an hour on Wednesday 24 September 2025.
• If you try to edit or save during these times, you will see an error message. We hope that no edits will be lost during these minutes, but we can't guarantee it. If you see the error message, then please wait until everything is back to normal. Then you should be able to save your edit. But, we recommend that you make a copy of your changes first, just in case.

Other effects:

• Background jobs will be slower and some may be dropped. Red links might not be updated as quickly as normal. If you create an article that is already linked somewhere else, the link will stay red longer than usual. Some long-running scripts will have to be stopped.
• We expect the code deployments to happen as any other week. However, some case-by-case code freezes could punctually happen if the operation require them afterwards.
• GitLab will be unavailable for about 90 minutes.

This project may be postponed if necessary. You can read the schedule at wikitech.wikimedia.org. Any changes will be announced in the schedule.

Please share this information with your community.

Trizek (WMF) (Discussion) 15:41, 18 September 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)

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. [13]
• 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. [14]

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. [15]
• 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. [16]
• One new wiki has been created: a Wikiquote in Malay (q:ms:) [17]
• View all 21 community-submitted tasks that were resolved last week. For example, the User Info Card now displays currently active global lock/blocks. [18]

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)

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)

{{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)

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)