Hello! There will be a Wikimedia Café meetup on Saturday, 11 April 2026 at 14:00 UTC (timestamp conversion tool), focusing on the the 2026-2027 Wikimedia Foundation Annual Plan. The featured guests will be Kelsi Stine-Rowe (senior manager, Movement Communications, Wikimedia Foundation), and Sam Walton (senior product manager, Moderator Tools, Wikimedia Foundation). In addition to this Café session, several additional meetings regarding the Annual Plan are listed on the Collaboration page, and you may participate on the talk page. This Café meetup will be approximately two hours long. Attendees may choose to attend only for a part. Please see the Café page for more information, including how to register.

↠Pine (✉) 05:32, 29 March 2026 (UTC)Reply

Wikisource:Translations has a policy for user translations created after July 2013 that says:

A scan supported original language work must be present on the appropriate language wiki, where the original language version is complete at least as far as the English translation. An inter-wiki link to the original language work must be present on the English translation.

So, the criteria in this context, stated simply, is:

• Inter-wiki link to the original (usually)
• Must be scan-backed at the original-language Wikisource.

I propose making a criterion for speedy deletion on this merit (which would presumably become CSD§G10):

CSD§G10 - User translation not compliant with policy, see WS:T

Rationale: There are so, so, so many works from after July 2013 that are already eligible for deletion for not fitting these criteria. They should all be cleaned up, as part of systematic maintenance on the Translation namespace, which quite frankly it needs a lot of. But as it stands now, these translations can only be sent to WS:PD one at a time, which is inefficient given that there are hundreds of post-July 2013 user translations at least that fail the criteria. An editor who wanted to clean this up at scale would just be spamming WS:PD with entries containing the same nomination rationale of "User translation from after July 2013 without scan-backed version at the original-language Wikisource." And as one particular trooper already knows, WS:PD has been getting filled to the brim lately as it is.

So, given that the justification for the deletion of these user translations is going to be the exact same every time, and given that consensus and the reading of current policy seem to be pretty straightforward on deletions of user translations of this nature, I think making this a criterion for speedy deletion will enhance our ability to clean up a substantial portion of our Translation: backlog. It will also allow us to quality-control our user translations more thoroughly in the future. SnowyCinema (talk) 17:21, 26 March 2026 (UTC)Reply

Yes, it would require a change in policy. At this point, these user translations will all have to be deleted anyway. This discussion is really more about doing this without creating enormous WS:PD backlog. SnowyCinema (talk) 00:13, 27 March 2026 (UTC)Reply

 Support per nom —Beleg Tâl (talk) 17:32, 26 March 2026 (UTC)Reply

 Comment Minor quibble affecting the way the proposal is worded, but not the text of the proposed new CSD criterion itself. The WS:T policy requires that the scan-backed copy "must be present on the appropriate language wiki", not on the original language wiki. There are at least two instances where this distinction matters. (1) No original language wiki exists, so the original would instead be at the multilingual wiki. (2) The text of the original was published as part of an academic work in a different language. This is not unusual for academic antiquarian works, particularly where an older source document finds its first (or only) publication in a journal of a different language. I can think particularly of medieval Galician and Asturian poetry published in a Spanish book, or medieval Occitan poetry in a French book. In those cases, the book is more likely going to exist at the national language Wikisource rather than the subnational language one, even if the subnational Wikisource exists. And the wording of our policy as written permits this, whereas the stricter reinterpretation stated above does not. --EncycloPetey (talk) 17:55, 26 March 2026 (UTC)Reply

I accept that nuance, and stand corrected on that specific point, but the substantial reading of my proposal stands. SnowyCinema (talk) 18:01, 26 March 2026 (UTC)Reply

There are some criteria for speedy deletion that allow for a small window of time to fix a problem. For example: "Works without authorship information, where a reasonable attempt has been made to discover this information and contact the user who added the text." I have no issue with the proposed CSD being one of them. SnowyCinema (talk) 00:09, 27 March 2026 (UTC)Reply

(But if a user translation has been sitting around for months or more, I think just deleting it in that case is sufficient.) SnowyCinema (talk) 00:10, 27 March 2026 (UTC)Reply

 Support per nom. I have also no problem with the adjustment suggested above. --Jan Kameníček (talk) 20:44, 26 March 2026 (UTC)Reply

Support but only for works that have not been touched in a while (say three months). Recent stuff should be put at PD for discussion and a chance to be done properly. — Alien  3
3 3 15:11, 27 March 2026 (UTC)Reply

Considering the extent of disagreements about modalities etc (as evidenced by below discussion), and how translations are most often quite complex issues, as it stands this ought to go to PD. This would be an Oppose until we can agree notably on "scan-backed" and "complete".

For the record, my opinion is: "scan-backed" just means based on a scan (image of the physical work). "complete" means, well, I'd say proofread but that's an indistinct bar, but at least, not a copydump/ocrdump (ie someone has at least actually worked on making this a transcription). — Alien  3
3 3 22:14, 3 April 2026 (UTC)Reply

I will just comment that several times works were nominated that have been moved and were actually grandfather / or have scan-backed versions that weren't linked / complete vs. proofread, etc.. I would prefer that we update our documentation to be clear about what exactly is required and emphasize that the expectation for admins to actually check the history before deleting. MarkLSteadman (talk) 16:34, 27 March 2026 (UTC)Reply

Specifically: what is "scan-backed" and "complete"? We have nominated and deleted works with scans that were not proofread for example. For CSD it would be good to make it a clear policy statement rather than relying on PD to allow a chance to discuss and agree or disagree. MarkLSteadman (talk) 16:39, 27 March 2026 (UTC)Reply

I think the translation policy in question is clear enough to make a CSD out of it. A work must be scan-backed and proofread at a different Wikisource at least as far as our English user translation goes. And "as far as" means that every page must be Proofread or higher at the other language Wikisource, up to where we've translated it. If 5 pages were proofread and 10 were not proofread, we can only proofread the 5 that were proofread, and not the 10 others that are not proofread.

But I will say I do agree that, in general, our policy and guideline pages including this one are fairly poorly written and could stand for a lot of grammatical and contextual revision. The standard could be elaborated as I've done here on that page to make it more clear, but I think the simpler version we have now is still sufficient to deduce what's required. SnowyCinema (talk) 16:58, 27 March 2026 (UTC)Reply

 Comment I've interpreted "as far as" to refer to the amount of content in the English translation, rather than the quality of the pages involved. For example, if the scan-backed copy has transcribed only the first 50 verses of a 100 verse poem, then the English translation can only include those 50 verses, and no further, until the remaining verses are transcribed at the other language Wikisource. Asking that the pages be marked as "proofread" isn't as meaningful. We've had pages marked "proofread" here that were riddled with errors, and have had IPs thoroughly proofread pages without marking them as such. --EncycloPetey (talk) 18:06, 2 April 2026 (UTC)Reply

That may be true, but at least in theory, a page marked as Proofread should be done and a page marked as Not proofread should be not done. I think it's not really about quality as much as it's about what our system classifies as done or not. SnowyCinema (talk) 18:45, 2 April 2026 (UTC)Reply

Yet complete is not the same as proofread, and our policy specifies "complete at least as far as the English translation". It says nothing about the page status. --EncycloPetey (talk) 18:55, 2 April 2026 (UTC)Reply

"Complete" means proofread or higher. But if the word "complete" is up for interpretation, then we should probably be debating what to do about that wording specifically. But Jan.Kamenicek seems to agree with my interpretation of the policy, and there has been at least one deletion before on this merit at WS:PD. SnowyCinema (talk) 21:12, 2 April 2026 (UTC)Reply

On Greek Wikisource, it is not unusual for scan-backed works to have originated copy-pasted from the Perseus classical works repository, which has a very high accuracy rate and specified sources. I've proofread scan pages that originated from Perseus and found 98-99% accuracy. Our threshold bar is scan-backed and "complete", not "page status proofread". If we opt for the latter, then simply marking pages "proofread" is sufficient for translation, regardless of actual quality. And if "complete" means proofread, then a missing image or table; missing text from an adjacent work; or unformatted footnote making a page "problematic" becomes a bar to translation, and that's just silly. --EncycloPetey (talk) 23:31, 2 April 2026 (UTC)Reply

That certain Wikisources may be misusing the ProofreadPage software is not grounds for abandoning trust in that system entirely. What those Wikisources should be doing is marking pages as Proofread when they're done, and keeping pages at Not proofread or Problematic when they're not done. If they're doing that incorrectly, then that's a fault of their own. But the system is designed so that you can distinguish between pages that are done and not done. Yes, there are going to always be edge cases that are not caught for various reasons, where for example a page is "proofread" with terrible formatting or marked as Proofread even if not actually proofread, or things like that. But the system has certain rules. If they break those rules then that's an edge case, not something to be considered the norm. SnowyCinema (talk) 00:00, 3 April 2026 (UTC)Reply

I disagree with declaring something an "edge case" in the absence of data, and summarize that exactly one person has equated "complete" with "proofread", with a possible second person per claim. --EncycloPetey (talk) 00:45, 3 April 2026 (UTC)Reply

To clarify what I was saying, this is what the software was designed for. The rule is: you don't mark something as proofread unless it's ready to be transcluded. Meaning done. Complete. And I was saying that when a software is designed a specific way, there are always, in any situation, going to be a handful of cases of misuse lying around. Deployment of software at scale with thousands of users always produces this inevitability. You can similarly say that there are certainly unattested words lying around at Wiktionary, certainly articles that blatantly don't pass the notability requirements at Wikipedia (as much as I dislike those requirements), and certainly works under copyright at Wikisource—all at any given moment. You simply cannot absolutely prevent this on any platform. So the fact that there are misuses of software or users who don't properly follow policies doesn't mean that the point of the software is suddenly moot—it just means that a statistical inevitability with everything is still the case. This would be like saying that because there are works in copyright on Wikisource at any given moment because patrolling hasn't found them yet, that we don't have any copyright policies. SnowyCinema (talk) 04:27, 3 April 2026 (UTC)Reply

 Oppose based on discussion. I concur with those who say that WS:PD is the appropriate place to deal with these translations. --EncycloPetey (talk) 02:12, 3 April 2026 (UTC)Reply

These works are all against policy anyway. Really this discussion was a suggestion on how we could ease up what would otherwise be a very painful process. To have to send each individual item that blatantly doesn't meet policy to PD one by one will be something I'm sure that most people will have a lot of negative feelings about, but it would be necessary if there's no way to get them deleted in bulk quickly. We can't keep works that don't align with our policies, so we are obligated to delete them no matter the method used. SnowyCinema (talk) 04:27, 3 April 2026 (UTC)Reply

Not disagreeing with you, but I think it's perhaps worth remembering that WS:PD is also primarily used for works that are against policy. Also: if there are a number of works that all need to be addressed by WS:PD, we can use a single post for them; we don't need to do them one by one. —Beleg Tâl (talk) 23:20, 3 April 2026 (UTC)Reply

We are never obligated to delete. Repair, correction, and change are also possible outcomes. --EncycloPetey (talk) 23:25, 3 April 2026 (UTC)Reply

 Oppose Much as it pains me to add to the workload of the poor schmucks trying to keep WS:PD moving and admins trying to clean up the sins of the past, I think for translations we have collectively failed to meaningfully enforce the policy for too many years to now make them speedyable. It would have to be limited to new translations added (i.e. 2026–), or a once-off massive purge of the pre-2026 backlog followed by stricter enforcement. On bad days I despair and think the only realistic option is nuking the lot of the mess and starting over, but while there is a large proportion of unverifiable and unsalvagble crap there there are also nuggets of gold, unique translations not found elsewhere, and many many volunteer hours in there.

I think we need to enforce the current policy, for new additions, for a good long while before we should make it speedyable. And in the meanwhile try to do a bit more aggressive cleanup of Translation: (batch noms at WS:PD of 5–10 translations with similar problems, spaced out in time so these don't drown the page). Perhaps as an alternative to deletion we could userify more pages (move them to subpages of the user page of the user that created them), but tag them with some suitable tracking categories (if nothing else so that they can be identified later) and defang any templates that need it (e.g. {{translation header}} should probably either be removed or get special logic to display a User:-specific format).

But that being said, in any discussion at WS:PD for a non-policy compliant user translation you can feel free to adduce a {{vd}} from me unless I chime in with a different !vote. I may also change my mind on the speediability of these if the cleanup gets too bogged down by packrats at WS:PD. Genuine efforts to salvage nominated texts (i.e. putting in the work) is good; !voting {{keep}} for non-policy compliant texts solely because one disagrees with the policy is just obstructionism (it borders on being bad faith behaviour, in effect if not in intent). We can disagree on what the policy should be and still work within its constraints (I don't agree with every policy we have on the books).

Or put another way: I don't disagree that almost all the non-policy compliant user translations should be deleted, but I think this is currently a bad fit for the speedy deletion mechanism specifically. Xover (talk) 09:47, 4 April 2026 (UTC)Reply

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

See also Wikisource:Scan lab

It and its subpages should be moved to Sarawak Gazette/1907/01/04. Nighfidelity (talk) 15:15, 20 March 2026 (UTC)Reply

@Nighfidelity: Done Now at Sarawak Gazette/1907/1/4 with a redirect to the new location at the old page name. Xover (talk) 10:27, 4 April 2026 (UTC)Reply

Should be moved to After the Storm (Arthur). Nighfidelity (talk) 04:38, 4 April 2026 (UTC)Reply

@Alien333: When you moved After the Storm to After the Storm (Arthur) you forgot to include subpages. After the Storm is now a dab page with all the chapters as subpages. My suggested procedure for fixing would be:

1. Move After the Storm to After the Storm (disambiguation) without redirect
2. Move After the Storm (Arthur) to After the Storm without redirect
3. Move After the Storm to After the Storm (Arthur) with subpages but without redirects
4. Move After the Storm (disambiguation) to After the Storm without redirect

Alternately, since there're only 28 of them, this might be better done manually and taking the opportunity to rename the chapters' page names to use arabic numerals instead of roman. I may circle back and do this at some point if you don't have the time for it, but I'm not able to just now. Xover (talk) 10:38, 4 April 2026 (UTC)Reply

Thanks for the ping. That was before I had the "move subpages" checkbox and I probably didn't notice them existing.

Y Fixed now. — Alien  3
3 3 13:50, 4 April 2026 (UTC)Reply

Should be moved to Index:The life and most surprising adventures of Robinson Crusoe (IA lifemostsurprisi00def).pdf as the file got moved a while ago. Nighfidelity (talk) 13:22, 7 April 2026 (UTC)Reply

Should be moved to just The American Review as it's a periodical which doesn't need a subtitle. Nighfidelity (talk) 20:21, 9 April 2026 (UTC)Reply

 Comment No, it shouldn't. There are also other journals with that title. --EncycloPetey (talk) 20:25, 9 April 2026 (UTC)Reply

What about The American Review (1844)? Nighfidelity (talk) 20:28, 9 April 2026 (UTC)Reply

No, that implies it was only published in the year 1844, and it was not. In fact, none of the issues bear that date. --EncycloPetey (talk) 20:31, 9 April 2026 (UTC)Reply

The title used by the Library of Congress is "The American review a Whig journal of politics, literature, art, and science"[1], though they note that the subtitle varies. --EncycloPetey (talk) 20:34, 9 April 2026 (UTC)Reply

Should be moved to The Philanderer (Shaw) to disambiguate against Irish Poems/The Philanderer Nighfidelity (talk) 16:08, 23 April 2026 (UTC)Reply

Done. I have started the disambiguation page but leave you to complete. -- Beardo (talk) 19:14, 23 April 2026 (UTC)Reply

Thanks! Nighfidelity (talk) 19:16, 23 April 2026 (UTC)Reply

Needs to be moved to Index:Explanatory Notes - Commonwealth Parliamentary Association and International Committee of the Red Cross (Status) Act 2025 (UKPGA 2025-2 kp).pdf after file on commons is moved. ToxicPea (talk) 18:18, 23 April 2026 (UTC)Reply

Currently, Category:Early modern authors defines the early modern period as 1631–1899. This is out of line with standard definitions of the early modern period, which the Wikipedia article says "is variably considered to have ended at the 18th or 19th century (1700–1800)". It is defined in Module:Era, taken from Module:Date, which added this feature in 12 January 2017, but the logic behind it, including the year 1899, seems to be much older, as seen in this discussion from 2007. Would anyone object to changing this to reflect a more typical definition of early modern? --Yodin^T 14:38, 3 March 2026 (UTC)Reply

I would. Modern and early modern is pretty ambiguous, and many of our readers may not be thinking in terms of the definitions you give. Given that even when suggesting changing it, you leave an ambiguity of a century, that implies that the lines aren't going to be clear even to those who do think along those lines.

Our current system is bad, I think, and I don't think tinkering with it is going to do any good. It's

Category:Ancient authors: 700BCE–600, which says it follows the prehistoric period; in actuality, we include authors like Author:Hammurabi (c. 1810 BCE – c. 1750 BCE) in it. It has 755 authors in it.

Category:Medieval authors: 601–1420. Lumping the dark ages in with the High Middle Ages is interesting, but sure. 888 authors.

Category:Renaissance authors: 1420-1630. Note that it includes the start of the Early Modern Period as given by Wikipedia, which is 1500, and I don't know why 1420 or 1630 was chosen. It's 210 years and 1,608 authors.

Category:Early modern authors: 1631-1899, or 268 years. 35,571 authors.

Category:Modern authors: 1900- , or currently 126 years. Moving Early Modern back to 1800 makes it a mere 168 years, and modern 226 years, and 1700 makes modern 326 years. I'd say that the more recent an era is, the more the narrow the focus should be. Modern has 24,341 authors in it.

If we want to change it, I think we should just go with centuries, at least since 1500. The line between Early Modern and Modern isn't clear, but the line between 20th century and 19th century is much clearer. Move Medieval to 601-1500, and make 1501-1600, 1601-1700, 1701-1800, 1801-1900 and 1901-2000, and 2001- century categories. Or even 1901-1950, 1951-2000 "early" and "late" 20th century categories. In any case, Modern Authors does not need to be any bigger than what it is.--Prosfilaes (talk) 05:59, 4 March 2026 (UTC)Reply

I would support switching to centuries instead of the current approach. It does seem to have been a very arbitrary set of choices, made in the early days of Wikisource. --Yodin^T 10:52, 4 March 2026 (UTC)Reply

Most of our current system is modeled on the LoC cataloguing system, though the choices of date and grouping for authors in the above set of date categories is not. The LoC categorizes modern authors by century, so we should probably do so as well. Looking at their categorization of European literature, there is a period from 1500-1700 grouping for most western European countries, though of course this period does not necessarily have meaning in Asian countries. Switching to centuries can work for authors from the Renaissance forward, but will not work well for Ancient and Medieval authors. Additionally, I suggest we would need to establish clear choices for authors whose birth and death years are across century boundaries. For example, an author born in 1790 is unlikely to be an 18th-century author, since few authors publish works by the age of 10. --EncycloPetey (talk) 12:43, 4 March 2026 (UTC)Reply

Certainly, I was not proposing moving the earlier categories to centuries, though we'd need a clean century end-line; we could either move Renaissance to 1600 or 1700, and drop it all together and run medieval to 1500.

We do have authors that published that young, like Author:Daisy Ashford, all of whose important work was written in the 19th century. On the flip side, Author:Laura Ingalls Wilder was 65 when she was first published and Author:Anna Sewell was 57. Short of keeping track of first publication, I figure it's probably best to continue to include all authors alive in the 19th century in that category (now Early Modern, then 19th century) without worrying about whether they were really authors.--Prosfilaes (talk) 10:21, 5 March 2026 (UTC)Reply

 Comment Can we not just get rid of the entire thing? What utility do these categories even have? People all across the board disagree about what counts as "ancient" or "modern". I'd say on a hunch that it seems far more useful to sort by actual decade, century, millennium, etc. than with this framing. We also could sort by things that are much more unambiguously agreed to be "eras", like the Gilded Age or the Great Depression for example (but of course, there's still debate even within those). SnowyCinema (talk) 21:39, 4 March 2026 (UTC)Reply

For example, if you asked someone in 1920 whether they thought 1895 was part of what they'd consider the "modern era" compared to, say, 1810, I think they'd be in unanimous agreement that it was, because they had living understanding of what came before and after. Wouldn't we think so, as regular readers of their texts? So the framing of "modernity starts at 1900, pre-modernity ends at 1899" seems problematic just for that reason alone. SnowyCinema (talk) 21:41, 4 March 2026 (UTC)Reply

And we can make all kinds of arguments about when "modernity" started, that are all arbitrary, and it really depends on what you philosophically consider "modern". Some people would genuinely consider pre-Internet life to be not modern. So that would put the start of modernity around the early 90s at best. What about cars being the starting point, or nuclear weapons being the starting point, or the countercultural revolutions of both China and the West being the starting point? Industrialization being the starting point? It's all up in the air and it depends on your interpretation, and also where you're starting from. Why is it our job to define "modern" in any sense? SnowyCinema (talk) 21:44, 4 March 2026 (UTC)Reply

 Comment Sorting ancient and medieval authors by decade, or even by century, would make finding them nearly impossible; they would be too sparsely distributed. I'm also unsure how we would sort Authors by decade. Using "eras" like the Gilded Age would apply only to literature in some languages in certain limited parts of the world; it would not be a universally applicable designation like centuries. --EncycloPetey (talk) 22:41, 4 March 2026 (UTC)Reply

For one, they are useful as base-level categories for our Author pages. If someone is looking for an author, and isn't sure what English form of their name we're using, they can often spot it by using categories. I do this regularly at other-language Wikisources when I desire to know which classical authors they have and which they do not. --EncycloPetey (talk) 22:43, 4 March 2026 (UTC)Reply

For modern specifically it seems problematic on so many levels. The 1899–1900 year cutoff seems bizarre given the continuity between the 1900s (decade) and the 1890s. The scientific progress narrative, the early automobiles, the early film evolution, the fashion, the gender roles, the political climate, the average writing style, the education system, the racial norms, everything. All of that was essentially a continuum between the two decades, not a cutoff. I don't know enough about the ancient world to comment too much on it, but the 1899–1900 cutoff is a specific point that I think a lot of writers from our typical early 20th century time period would have fervently disagreed with. Would they not have called 1895 "modern", in the historiographical sense, in 1930? The categories would be arguably more defensible if "early modern" at least included pre-industrialized or barely-industrialized life and stopped somewhere around the time industrialization started, like about the time that Karl Marx was alive and writing about it (to critique it from the perspective we all know). This is a problem with the categories that I've had for a while but haven't gotten around to writing it out as a concern. SnowyCinema (talk) 07:52, 5 March 2026 (UTC)Reply

Re: "the continuity between the 1900s (decade) and the 1890s", where does this continuity exist? Is that statement equally applicable in Spain, Greece, Japan, and Persia? Any boundary will be unsatisfactory somewhere, but dividing by century is the way that the Library of Congress is doing it. Matching their system makes the two inter-compatible. --EncycloPetey (talk) 20:51, 5 March 2026 (UTC)Reply

Any cut won't make sense for someone. Peter Charanis talks about people on Greek Islands in 1912 describing themselves as "Romans." It's meant to be useful, to help find authors. Also being English WS it's useful having a Eurocentric view as that is where most of the authors are. MarkLSteadman (talk) 22:16, 20 March 2026 (UTC)Reply

There seems to be a strong consensus in favour of replacing the existing system with century-based categories, from 1500 on. Would the next step be to create a proposal to see if there's enough support to update the templates? --Yodin^T 17:42, 10 March 2026 (UTC)Reply

Here's a concrete proposal.

Remove categories Category:Renaissance authors, Category:Early modern authors, Category:Modern authors.

Adjust Category:Medieval authors to end at 1500. (Adds roughly 300 authors to Medieval authors.)

Create Categories 16th century authors, 17th century authors, 18th century authors, 19th century authors, Early 20th century authors (to cover 1901-1950), Late 20th century authors (to cover 1951-2000), 21st century authors.

(The Early and Late 20th century authors will be one of the more controversial parts of the proposal. But at 24,000 authors in Modern Authors, splitting it will help make it more reasonable, and this does match a Dewey Decimal System split. It's also a non-moving split that provides a rough separation between modern PD-Gov / CC licensed authors and older PD-US, PD-70 and PD-no renewal authors.)

Fix the description of Category:Ancient authors to make the start date unbounded, which is the current behavior.

All splits will include any authors we know to have lived in that era, which is basically the current strategy.--Prosfilaes (talk) 21:17, 20 March 2026 (UTC)Reply

The 1950 split has an evenness to it. A 1945 split would make a bit more logical sense as Pre-WWII and Post-WWII. MarkLSteadman (talk) 22:22, 20 March 2026 (UTC)Reply

But that's not pre-WWII; pre-WWII is 1939 or 1941. In my personal library, I have a tag "Elizabethan (II) literature" for works published between 1952-2022. I think being even is more neutral here.--Prosfilaes (talk) 02:29, 21 March 2026 (UTC)Reply

WWII depends on who you talk to. e.g. the Chinese... But more broadly the shift from a European Empire-dominated world to a US-dominated world brought upon by the war. Anyways. this proposal has my support, two broad categories for roughly the era pre-printing and then centuries for afterwards. MarkLSteadman (talk) 23:48, 22 March 2026 (UTC)Reply

I would support this. I don't think there's a perfect approach to this, and I think the later centuries are going to be almost unusable to readers and editors regardless of whether or not they're split into two (or even ten, by decades), but it is much better than the current system, and for that reason I think it should be implemented, and can always be improved later on. Another approach could be to include only authors who have associated Wikidata works items that are from the given century, or floruit dates there, which would lead to many fewer authors in the categories, but that's probably not a bad thing. --Yodin^T 17:36, 22 March 2026 (UTC)Reply

 Support, this seems reasonable to me, and is essentially what I argued in the last thread about these categories except with a specific proposal. (Great work!) But can we extend this to works as well, e.g. Category:Early modern works etc. will presumably have to be reworked similarly? SnowyCinema (talk) 19:30, 22 March 2026 (UTC)Reply

 Comment Is there some reason not to have a 20th-century authors category? The two halves of the century could be subcategories, with authors placed into those rather than the parent one, but I can't support the proposal if there is no category at all for the 20th century as a whole. --EncycloPetey (talk) 01:02, 23 March 2026 (UTC)Reply

I don't see a problem with an author being in multiple year-based categories, and from at least 1900 onwards (possibly even as far back as 1500) having per-decade categories would seem more practical. Each decade category would then be a subcategory of the century category, and each author would be in all the categories for decades in which they lived (or possibly flourished, if anyone sees the need for the distinction). And if we go that route we could have broad(er) paralell categories for eras like Early modern as a secondary finding aid (not as the primary categorization) either on each author directly, or as a paralell parent for the per-decade categories. For example because some people care about Elizabethan authors, some for Jacobean authors, and some for Elizajacobean authors (I definitely don't have any specific author in mind for these examples. Nope. Not at all. Completely arbitrarily picked.) A full 20th century category would fit in nicely with that scheme, and solve other cut-off problems too as a nice bonus. Xover (talk) 19:58, 4 April 2026 (UTC)Reply

 Support redefining.--TunnelESON (talk) 17:50, 2 April 2026 (UTC)Reply

 Support per above. For what it's worth (as this is English Wikisource and not Dutch), this centuries-based categorization (including the 20th century split) generally neatly aligns with how the history curriculum takes shape here (to 3000 BC, 3000 BC-500 AD, 500-1000 and 1000-1500 [Low and High Middle Ages, respectively], 1500-1600, etc.; each with a name characteristic of that timespan). Regarding the 20th century split: the first half of the 20th century is known as "Time of world wars" (what seems to be a false memory of mine attached "and crises" to it - it'd be apt but alas), the second, lasting to this day, as "Time of television and computer". Thought it might be useful to bring this outsider perspective here, even though I know full well this won't and cannot apply anywhere universally. DarkShadowTNT (talk) 00:48, 8 April 2026 (UTC)Reply

News articles are aggregated by the source, and there are Portals for topics. Is there any way I click on a link, and see all the news articles from that day, or that month? RAN (talk) 00:42, 10 March 2026 (UTC)Reply

Hmm. No. But that's a very interesting point. Wikisource doesn't have the greatest findability and navigation in general, and for periodicals this would be one obvious view some people will be interested in. For example because the date is when something especially interesting happened and you want to see how different periodicals covered it. Xover (talk) 20:07, 4 April 2026 (UTC)Reply

Does anyone understand what this page is for? It showed as having no pages linking to it. -- Beardo (talk) 16:55, 14 March 2026 (UTC)Reply

Pinging @ShakespeareFan00, @Billinghurst, @Inductiveload as Billinghurst and Inductiveload have edits on the page; and ShakespeareFan00 duplicated the content to the page's styles.css. -- Mathmitch7 (talk) 17:01, 14 March 2026 (UTC)Reply

@Beardo (CC: @Mathmitch7) It's (now) redundant to Index:Os Lusíadas (Camões, tr. Burton, 1880), Volume 1.djvu/styles.css. SF00 changed Page:Os Lusíadas (Camões, tr. Burton, 1880), Volume 1.djvu/25 from using the old {{page styles}} template with that stylesheet to using Index:Os Lusíadas (Camões, tr. Burton, 1880), Volume 1.djvu/styles.css (which is loaded automatically by the Proofread Page extension) and just forgot to ask to have the old style page deleted. I've deleted it now. Xover (talk) 20:21, 4 April 2026 (UTC)Reply

Thanks. I suspected it was something like that. -- Beardo (talk) 20:24, 4 April 2026 (UTC)Reply

I added the 50-year statement to the module (pulled from part of c:Template:PD-Thailand which for some reason we didn't have in any of our templates) because it was relevant to a particular work I needed to justify the license for, lest it would not be justifiable without it, and then discovered that the entire template, uniquely, requires you to specify only one subsection of a specific part of the legal code. Is it absolutely necessary that we require the specific code and categorize each one? All license templates I've ever seen here or on Commons only require the template to be essentially a catch-all. Can there not at least be an option not to use the codes? Or can we make a separate template for the 50-year principle? SnowyCinema (talk) 19:48, 17 March 2026 (UTC)Reply

@SnowyCinema: I don't remember the details, but this was one specific contributor that had a bee in their bonnet about a specific issue with the Thai copyright regime and felt that the template had to explicitly have the rationale that the law requires. It was tied to a couple of specific WS:CV discussions and seemed like it was maybe spillover from discussions at thWS. I didn't much like it at the time it was changed, but it never reached the top of my todo list to follow up on it. I think it likely that the parameters in question aren't needed (much less should be required), but we'd need to dig into the rationale for it to determine with certainty whether they're needed (it could be a literal requirement of the law for all I know, even though that would be quite surprising). Xover (talk) 20:36, 4 April 2026 (UTC)Reply

Leaves of Grass (1860) is formatted very weirdly. Instead of using code templates to produce a hanging indent, the line breaks from the original book are preserved, and the later part of the line is manually indented. This is counter to Help:Formatting conventions#Line breaks so I'm working on fixing it.

It would be helpful to me if I could mark which pages I'd done and which I have yet to do. However, if I were to un-validate the pages, I would be locked out of re-validating them. Could someone else un-validate them please? Eievie (talk) 03:54, 22 March 2026 (UTC)Reply

That's not what the page status tracker is for. If you need to keep personal track of your progress you can make a note on something in your perosnal User space, or in a file on your computer, or in a physical notebook. Page status is not meant for tracking a single person's progress. --EncycloPetey (talk) 17:27, 23 March 2026 (UTC)Reply

Insofar as it's being framed as a personal favor, I get that. However, if a page claims to be validated but nonetheless breaks basic formatting conventions, would it be fair to say that claim of being validated is inaccurate? Eievie (talk) 17:36, 23 March 2026 (UTC)Reply

What "basic formatting conventions" are you referring to? I don't see anything in your request that qualifies by Help:Page status or Wikisource:Style guide in what you've described. The quote you've pulled refers to prose text, and not to poetry. We have no style guide for replicating poetry, in part because poetry formatting is more advanced and more nuanced than can be described at a basic level. As far as I can tell the page "is ready for display to the casual reader—even if it has little errors in it". --EncycloPetey (talk) 16:45, 28 March 2026 (UTC)Reply

Hello all,

Could others please weigh in on whether adding hanging indents which are not in the source material is acceptable under Wikisource's current style guide.

My interpretation is that to distinguish one paragraph from the next a single empty line is best, as it maintains consistency of the presentation of works across Wikisource. Indentation of the first line is strongly discouraged, extreme cases aside, and that other (non first line) indentation can be replicated if present in the source material (so long as there is still an empty line between paragraphs).

@Tosca-the-engineer, hopefully not misconstruing their opinions, feels that adding hanging indents (for plays) improves readability on narrow screens, and would be acceptable under the style guide (whether present in the source material or not), as the aim is not to imitate the printed pages, but only to create a digital transcription.

Please see the initial discussion here: Wikisource:Community collaboration/Monthly Challenge/Nominations in the "Morton - My First Fit of the Gout" section (I don't know why I can't seem to link to the section directly). Discussion then continued here: User talk:Tosca-the-engineer#The Importance of Being Earnest, regarding the reversion of Index:The Importance of Being Earnest - French's edition.djvu/styles.css.

Thanks, TeysaKarlov (talk) 20:23, 25 March 2026 (UTC)Reply

I concur that applying a style completely different from the original is inappropriate. --EncycloPetey (talk) 16:47, 28 March 2026 (UTC)Reply

Indeed, styling should not be added that was not in the source. — Alien  3
3 3 17:49, 28 March 2026 (UTC)Reply

@Alien333, @EncycloPetey Thanks for the responses, and confirming my suspicions. Regards, TeysaKarlov (talk) 19:22, 28 March 2026 (UTC)Reply

The transclusion on the principal page is also highly unorthodox. --EncycloPetey (talk) 17:07, 30 March 2026 (UTC)Reply

@EncycloPetey I wanted to change the main page transclusion too, but thought it would be provocative while the indent style discussion was ongoing. @Tosca-the-engineer What was the motivation behind the placement of the ToC inside the flexwrap, rather than transcluding in a 'page order' sort of sense? Regards, TeysaKarlov (talk) 19:36, 30 March 2026 (UTC)Reply

the section on "Secretary McNamara's Prepared Testimony, 20 February 1968" in Index:Pentagon-Papers-Part IV. C. 2. b.djvu is clearly an extract from some text, but i can't find it. what text is it from? ltbdl (talk) 05:26, 27 March 2026 (UTC)Reply

wait, no, found it: Gulf of Tonkin, the 1964 Incidents: Hearings Before the United States Senate Committee on Foreign Relations, Ninetieth Congress, Second Session, on Feb. 20, 1968 ltbdl (talk) 05:32, 27 March 2026 (UTC)Reply

made an index from a different scan: Index:Gulf of Tonkin, the 1964 Incidents - Hearings Before the United States Senate Committee on Foreign Relations, Ninetieth Congress, Second Session, on Feb. 20, 1968.pdf

just waiting for the file to un-break itself. ltbdl (talk) 05:49, 27 March 2026 (UTC)Reply

@Ltbdl I purged the file on Commons then Wikisource. The index looks okay to me now. Regards, TeysaKarlov (talk) 07:43, 27 March 2026 (UTC)Reply

Are they in the public domain under {{PD-USGov}}? Nighfidelity (talk) 17:03, 27 March 2026 (UTC)Reply

I haven't looked at all of it, but it looks like page 24 says of its photos, "Source: DOJ OIG photographs and DOJ OIG schematic drawing depicting the MCC New York SHU," which would almost certainly be under PD-USGov. On another page, p. 35, it says the diagram is also from the DOJ OIG, but the photograph is from "Office of the Chief Medical Examiner, City of New York (OCME)", which well may be under the City's copyright. Would love to see somebody else's perspective though. -- Mathmitch7 (talk) 17:16, 27 March 2026 (UTC)Reply

• I agree with Mathmitch7. The DOJ OIG photographs and schematics are fine, but the OCME photographs aren’t. (I’d like to imagine that they’re below the threshold of originality per Burrow-Giles, but whatever.) If it’s agreed that they’re copyrighted, I can redact the file. TE(æ)A,ea. (talk) 20:46, 27 March 2026 (UTC)Reply

Page: images are being cropped again. The last bug report got marked as resolved, despite the continued problems. TE(æ)A,ea. (talk) 16:00, 28 March 2026 (UTC)Reply

I too am seeing regular squashing of images, and have to reload every new page once or twice in order to get the scan page to display in the correct proportions and thereby be readable for proofreading. I'm also having the edit window come up far too small every time I edit a Page. The software is not remembering the size set for the main edit window from one page to the next, so every time I go to the next page in the book, I have to resize the edit window (again), then reload the page (once or twice) to get the scan page to display correctly. If the image came up in correct proportions and the edit window could remember the previous edit size, that would greatly speed up the process of editing and reduce a lot of frustration and wasted time. --EncycloPetey (talk) 16:49, 28 March 2026 (UTC)Reply

• For me, the problem’s worse; the image loads with only the top-left part taking up the entire image window, and if I zoom out, no more is shown. I reloaded dozens of times, but without fixing anything, making it actually impossible to proofread. Your other issue, with the pages automatically resizing in a bad way, happens to me for every work if I ever, even once, accidentally, resize an image; this has been going on for months now. TE(æ)A,ea. (talk) 17:24, 28 March 2026 (UTC)Reply

  That does indeed sound worse than what I'm experiencing. I did include the image at right, though, because it demonstrates that the edit window is not generated to match the image, nor is the image being aligned to the edit window. In this case, it was not only vertically compressed, but the top half is not in view, even though there is ample space below the image to permit display. Whatever process is being used to create the window is unsuccessful and is not taking the most basic needs of editors into consideration. --EncycloPetey (talk) 18:34, 28 March 2026 (UTC)Reply

• Here’s what my page looks like. I can resize it so that it takes up the right amount of the screen, but it’s still cut off. In addition, if I go to another page, that page will, in addition to being cropped, be offset in a different amount. TE(æ)A,ea. (talk) 18:53, 28 March 2026 (UTC)Reply

A fix was introduced yesterday, in response to task T421372. Maybe it solved this problem? Seudo (talk) 16:02, 1 April 2026 (UTC)Reply

• Seudo: No, it did not. I still have the image cropping issue. It cuts off the right-most quarter or so of the page. It is also inconsistent; it was not happening earlier this week, but has just started again now. As another user mentioned, clearing the file cache seems to (at least temporarily) fix this problem; but that is not a viable long-term solution. TE(æ)A,ea. (talk) 20:02, 1 April 2026 (UTC)Reply

  I checked on Page:The Religions of Japan (4th ed. 1912).djvu/220 (mentioned in the screenshot above) and have no cropping problem, whatever the zoom level. On the other hand, a developer said in the Phabricator task that the patch will be deployed next week. So maybe it will be solved in a few days... Seudo (talk) 10:13, 2 April 2026 (UTC)Reply

  • It’s very inconsistent, which makes it hard to track down. It seems to happen if the image ever “hiccoughs”—after being blank for a little bit, the full image will load for a very short time, then it’ll be blank for a very short time, and finally the cropped image will load. (It also seems to be more common if you’ve ever re-sized a page; by re-sizing a page, it permanently messes up the orientation and sizing all other pages in the index. Is there a bug report for that?) The purging-file trick is also inconsistent; last time, it worked for forty pages, but this time it only worked for one page. If it’s being deployed next week, I’ll wait until then to check it again. Will it only work prospectively, for indexes that haven’t already been messed up? TE(æ)A,ea. (talk) 13:37, 2 April 2026 (UTC)Reply

MediaWiki message delivery 19:25, 30 March 2026 (UTC)Reply

It throws some error about thumbnails, even though no thumbnail is being created. (I was trying to load this image.) How incompetent are the people running the codebase? If they stopped changing things we wouldn’t keep having these problems. TE(æ)A,ea. (talk) 00:55, 31 March 2026 (UTC)Reply

The current title uses "The", which is not part of the work’s formal name. "Jerilderie Letter" is the common, widely used name of the document. Removing the definite article aligns with Wikisource's naming conventions for works and matches standard references in secondary sources. - Rollercoasterrider25 (talk) 02:15, 31 March 2026 (UTC)Reply

So you have copied the text to the version without "The" and turned the original into a redirect? That's not how to do this sort of thing. That loses the history.

Please can you give some links to these secondary sources that you mention. (I see that the wikipedia is at w:Jerilderie Letter, whilst wikidata has pages for both versions). -- Beardo (talk) 03:30, 2 April 2026 (UTC)Reply

@Beardo: Apologies, I should have waited for a response. It is referred to widely in scholarship and elsewhere simply as the Jerilderie Letter, not "The" Jerilderie Letter. See for example this National Museum of Australia article, or this article published by the University of Melbourne. - Rollercoasterrider25 (talk) 12:11, 2 April 2026 (UTC)Reply

And it seems that the original source did not include "The". Now moved. -- Beardo (talk) 01:23, 4 April 2026 (UTC)Reply

Hello everyone,

This is a notice regarding an ongoing data migration on Wikidata that may affect your election-related templates and Lua modules (such as Module:Itemgroup/list).

The Change:
Currently, many templates pull electoral maps from Wikidata using the property P1846, combined with the qualifier P180: Q19571328.

We are migrating this data (across roughly 4,000 items) to a newly created, dedicated property: P14226.

What You Need To Do:
To ensure your templates and infoboxes do not break or lose their maps, please update your local code to fetch data from P14226 instead of the old P1846 + P180 structure. A list of pages was generated using Wikimedia Global Search.

Deadline:
We are temporarily retaining the old data on P1846 to allow for a smooth transition. However, to complete the data cleanup on Wikidata, the old P1846 statements will be removed after May 1, 2026. Please update your modules and templates before this date to prevent any disruption to your wiki's election articles.

Let us know if you have any questions or need assistance with the query logic. Thank you for your help! ZI Jony using MediaWiki message delivery (talk) 17:11, 3 April 2026 (UTC)Reply

@ZI Jony: this has nothing to do with us and you have very probably used a faulty search query with false positives. The two pages listed for us have nothing to do with the issue in question, and are (I think not coincidentally) the two which turn up when searching template: "insource" which leads me to think you did not properly use insource:. — Alien  3
3 3 21:19, 3 April 2026 (UTC)Reply

@Alien333, thanks for pointing our, the message did send as usage of that property or templates, message I send to Project:VP for general notification. However, there are several others options that in the way I mentioned in the message. Thanks! ZI Jony ^(SWMT) 02:55, 4 April 2026 (UTC)Reply

For all my 'creations' and 'edits' I have 'watch this page' ticked, so I receive notifications if they are changed. Recently, I have been getting a lot of notifications from what appear to be different new users (red link) who 'validate' one random page only from a work. Is this just a coincidental cluster or is something else happening? Chrisguise (talk) 10:29, 5 April 2026 (UTC)Reply

There were a few days this week (31st, 1st and 2nd) when I noticed a lot of unmatched italics or bolds from new users (several with nothing on their talk page), which seems related. I was wondering what was happening, too. -- Beardo (talk) 16:51, 5 April 2026 (UTC)Reply

should a request on meta: SRCU be made? ltbdl (talk) 17:24, 5 April 2026 (UTC)Reply

I suspect some kind of editathon or something. — Alien  3
3 3 17:32, 5 April 2026 (UTC)Reply

Based on comments on User talk:Ilaria.pellegrini-migliarini, this is for a university course. There have been too many of them for me to keep up with welcoming them and commenting on errors. I've picked up a few that are doing good work, the others are only going to hang around long enough to get credit. I doubt the Educator involved has given sufficient direction on what to do and I've made quite a few reversions where templates are broken or the style guide ignored. Beeswaxcandle (talk) 01:57, 6 April 2026 (UTC)Reply

I've also spotted pages where all of the formatting and templates were stripped from a Proofread page; or where random quotes, tags, and non-English templates were inserted into a page. --EncycloPetey (talk) 17:13, 6 April 2026 (UTC)Reply

Likewise. Chrisguise (talk) 17:58, 6 April 2026 (UTC)Reply

We seem to have another wave of brand new editors today. --EncycloPetey (talk) 18:41, 17 April 2026 (UTC)Reply

I've been seeing a lot of Cyrillic look-alike characters getting added to transcriptions lately,[3][4][5] presumably by people using OCR and not noticing them. These characters are basically identical to their Latin counterparts and very difficult to detect unless you are using tools that fix them automatically. I'm wondering if it would be possible to create an AbuseFilter that automatically detects Cyrillic characters and warns the editor when they try to save the page, so that they can double-check. Nosferattus (talk) 00:07, 6 April 2026 (UTC)Reply

@Nosferattus: Could you give us a list of specific letters? Both the ones you've seen used, and surrounding likely candidates from the Cyrillic code block?

Creating an AbuseFilter that warns about the presence of these shouldn't be too difficult, and if needed we can weed out existing instances with a bot. Xover (talk) 07:15, 6 April 2026 (UTC)Reply

Cyrillic look-alike characters

Cyrillic	Unicode	Latin
А	U+0410	A
В	U+0412	B
С	U+0421	C
Е	U+0415	E
Н	U+041D	H
І	U+0406	I
Ј	U+0408	J
К	U+041A	K
М	U+041C	M
О	U+041E	O
Р	U+0420	P
Ѕ	U+0405	S
Т	U+0422	T
У	U+0423	Y / y
Х	U+0425	X
а	U+0430	a
е	U+0435	e
о	U+043E	o
р	U+0440	p
с	U+0441	c
у	U+0443	y
х	U+0445	x
і	U+0456	i
ј	U+0458	j
ѕ	U+0455	s
Ӏ	U+04C0	I / l
ӏ	U+04CF	i / l

A couple of these, like У and ӏ are debatable. Nosferattus (talk) 14:55, 6 April 2026 (UTC)Reply

I think it would be more useful to have a tool that highlights characters in the Cyrillic range of values, one that could be set detect Greek values. The problem is that I see some Greek characters in OCR texts, and this happens because there is also Greek text in the scan page as well, whether in line or as a quote or part of a math formula. But some Greek capitals look like English capitals, and spotting them isn't possible, so it would be nice to have a tool that highlighted the Greek, so that visual inspection can permit their removal from sections where they don't belong, yet ignoring them where they do belong. --EncycloPetey (talk) 16:19, 6 April 2026 (UTC)Reply

I agree, but setting up an AbuseFilter is definitely a lot easier than building a charset detection tool. Luckily, most of our source texts don't have actual Cyrillic in them so I think it would have a low false positive rate, but yeah, Greek would be more tricky. Nosferattus (talk) 21:24, 6 April 2026 (UTC)Reply

But such a detection tool, implemented well, would be useful to Wikipedia as well as to Wikisource. It might therefore be something the developers would be willing to create. --EncycloPetey (talk) 22:00, 6 April 2026 (UTC)Reply

It would certainly be a frustrating false positive rate, as many books with Cyrillic are going to have it on nearly every page.--Prosfilaes (talk) 06:28, 7 April 2026 (UTC)Reply

Hmm. From a (very superficial) search it doesn't appear we have a lot of texts legitimately using Cyrillic characters. Dictionary of Spoken Russian was about the only one I found. And for sporadic texts with lots of Cyrillic we could have the warning message contain instructions for how to request a per-work exception, and then manually exempt them in the filter.

I did find quite a lot of hits for Cyrillic characters, distributed between: 1) the problematic replacements that triggered this discussion (surprisingly many of them), 2) interwikis to Wikisourcen using the Cyrillic alphabet, 3) provenance data ("first published in Russian journal title), and 4) citations to sources in languages using the Cyrillic alphabet. The substitutions should obviously be fixed. The interwikis point out a problem with our use of Wikidata and would be resolved by fixing that. The provenance data probably belongs in Wikidata, but requires some careful thought. And the citations may be sporadic enough that we could live with having to click through a warning when adding those.

So I think we definitely still could set up an abusefilter to catch these, and it might help avoid amassing more of the first three categories, but it would cause some side-effects that we need to consider before pulling the trigger on something like that. Xover (talk) 13:04, 7 April 2026 (UTC)Reply

And we do seem to have cases like A Soliloquy on the Soul (1)/А Soliloquy On the Soul, now at A Soliloquy on the Soul (1)/A Soliloquy On the Soul (good luck spotting the difference without tool support), that was linked from its parent and sibling (both fixed now). That redirect isn't needed but I'm leaving it in place for now for demonstration purposes. Xover (talk) 13:25, 7 April 2026 (UTC)Reply

Ugh. Or this. Xover (talk) 13:40, 7 April 2026 (UTC)Reply

Interwikis often cannot be sorted by using Wikidata, because doing so can knocks out all interwiki connections, under many conditions, even when the data is entered correctly into Wikidata. For example, Agamemnon (Aeschylus) has interwiki links only to Arabic and French, even though many Wikisource projects have translations, including Greek Wikisource. --EncycloPetey (talk) 17:00, 7 April 2026 (UTC)Reply

I think that must be a bug, because they did add functionality for interwiki links to follow has edition or translation (P747) a few years ago —Beleg Tâl (talk) 17:03, 7 April 2026 (UTC)Reply

@EncycloPetey: Do you have a link to the Greek Wikisource page for that work? There is no link to it on Wikidata, so it not showing up as an interwiki here is no surprise. And since this is at the work level it's a straightforward 1:1 exercise (i.e. the exact same thing all the Wikipedias do) so I'd be very surprised if MediaWiki was broken for that use case. Walking up from the edition or translation level to the work level is a bit more iffy so that's where I'd expect MW to be broken, if it is broken (I've never had cause to look into this). Xover (talk) 17:16, 7 April 2026 (UTC)Reply

It is on Wikidata, under the editions and translations. --EncycloPetey (talk) 17:18, 7 April 2026 (UTC)Reply

The interwikis are supposed to connect the editions when there is no work page, because that's how most copies are done at Wikisources. See Beleg Tâl's comment above. --EncycloPetey (talk) 17:19, 7 April 2026 (UTC)Reply

Oh, you expect it to walk down the hierarchy to generate an interwiki to an edition from the work level item? How would that even work when editions and translations are a flat soup of all the myriad variants? That would—just for the sake of example—end up interwiking the Brown translation to the Morshead translation. I was thinking that for a text at the edition level we expect it to walk up to the work level and interwiki the work-level pages on the other Wikisourcen (i.e. their equivalents of versions pages, on the assumption that if they have a work level page they probably have at least one edition level page too). Xover (talk) 17:46, 7 April 2026 (UTC)Reply

I personally would expect it to go both ways. Not sure how I'd expect it to deal with multiple editions in the same Wikisource, but it wouldn't interwiki from enWS to enWS regardless. —Beleg Tâl (talk) 17:51, 7 April 2026 (UTC)Reply

I don't know the technicalities, but I know that Norwegian Wikisource developed code to do just that, and it was working here for a time too. --EncycloPetey (talk) 17:54, 7 April 2026 (UTC)Reply

No, you can't assume that a work-level page means there is an edition on the same site. There are Wikisources that accumulate lists of editions of works, none of which are actually hosted, because they lack editors, so having the links to scans is about the best they can manage. --EncycloPetey (talk) 17:56, 7 April 2026 (UTC)Reply

Honestly, I think both would be really useful - a tool for distinguishing Latin, Greek, and Cyrillic characters would be useful for experienced editors who need to use all three; and an abusefilter would be useful for catching new users who don't care and just paste in whatever their OCR tool generates. —Beleg Tâl (talk) 16:48, 7 April 2026 (UTC)Reply

... maybe the abusefilter could be limited to users without autopatrol? Is that even possible? just spitballing ideas —Beleg Tâl (talk) 16:49, 7 April 2026 (UTC)Reply

Without checking I would assume so. But I'm not entirely sure even experienced users are immune to this problem: you really can't tell by eye that you have a Cyrillic letter in there without some tool support like what EP suggested, or a big honking warning from the AbuseFilter on save. Xover (talk) 17:09, 7 April 2026 (UTC)Reply

What I mean is, tool support like EP suggested would fix the issue for experienced users, but would be ignored by new users, so if both solutions were to be in use then the AbuseFilter could be limited to new users who would otherwise ignore the tool support. —Beleg Tâl (talk) 17:23, 7 April 2026 (UTC)Reply

That's true, but currently there is no tool support, so it seems like it would make sense to move ahead with an AbuseFilter that works for everyone. Even as a (somewhat) experienced Wikisource editor, I would appreciate having such an AbuseFilter to catch these cases, as it's easy to miss them when proofreading. The AbuseFilter should definitely whitelist any sources that prominently use Cyrillic and I also think it should be limited to the Page namespace, so that we aren't triggering it from provenance data or interwiki links. Nosferattus (talk) 23:51, 7 April 2026 (UTC)Reply

In Ukrainian Wikisource we have a gadget https://uk.wikisource.org/wiki/MediaWiki:Gadget-presenceLatinLetter.js to highlight Latin letters in text it is quite useful for this task. Although it doesn't work in the editing mode, only when reading the page Bicolino34 (talk) 08:12, 8 April 2026 (UTC)Reply

MediaWiki message delivery 16:19, 6 April 2026 (UTC)Reply

@EncycloPetey / @Beleg Tâl:

Continuing on from #Look-alike Cyrillic characters above, and thinking out loud a bit…

enWS has Aeschylus (Smyth 1926) v2/Agamemnon that transcludes the English pages of File:Aeschylus (Smyth 1926) v2.djvu, and elWS has el:Αγαμέμνων that transcludes the Greek pages from the same scan. enWS also has a versions page at Agamemnon (Aeschylus) that is the work level above Aeschylus (Smyth 1926) v2's edition level.

Aeschylus (Smyth 1926) v2/Agamemnon is linked to the Wikidata item Agamemnon (Q138026394) (a version, edition or translation (Q3331189)), and Agamemnon (Aeschylus) is linked to the Wikidata item Agamemnon (Q3320792) (a dramatic work (Q116476516)).

el:Αγαμέμνων is linked to the Wikidata item Agamemnon (Q138026370) (a version, edition or translation (Q3331189)). elWS does not have a wikipage for the work level (our versions page).

Despite being the same edition by the same editor / translator (literally transcluded from the same scan), the enWS and elWS texts have separate Wikidata items.

Agamemnon (Q3320792) (the work level item) has sitelinks to arWS, frWS, and enWS.

Agamemnon (Q138026394) (enWS edition level) has sitelinks only to enWS.

Agamemnon (Q138026370) (elWS edition level) has sitelinks only to elWS.

Aeschylus (Smyth 1926) v2/Agamemnon has interwiki links to arWS and frWS.

Agamemnon (Aeschylus) has interwiki links to arWS and frWS.

el:Αγαμέμνων has interwiki links to arWS, frWS, and enWS (but the enWS one is manually added at elWS).

So…

Aeschylus (Smyth 1926) v2/Agamemnon and [[s:el:Αγαμέμνων|] should probably be linked to the same Wikidata item (with sitelinks to both enWS and elWS). But our splitting a single multilingual edition into two single-language texts makes that a little awkward (not necessarily wrong, but awkward). That would, I expect, obviate the need for the manual interwiki at [[s:el:Αγαμέμνων|], and should give Aeschylus (Smyth 1926) v2/Agamemnon an automatic interwiki to elWS.

Since both Aeschylus (Smyth 1926) v2/Agamemnon and el:Αγαμέμνων has interwikis to arWS and frWS this means MediaWiki is walking up from the edition (Agamemnon (Q138026394) and Agamemnon (Q138026370)) to the work level item (Agamemnon (Q3320792)) and grabbing its sitelinks as interwikis.

I haven't checked frWS and arWS's rexts and what interwikis/sitelinks/etc. they have because my brane hurts enough as it is.

Anyways… What we're not getting here is automatic interwikis (from any level) to the itWS, plWS, deWS, etc. editions listed on Agamemnon (Q3320792) (e.g. it:Agamennone, an Italian translation by Ettore Romagnoli (Q32862)). This is to me completely logical and expected behaviour, but appears to be where MediaWiki is failing to meet others' expectations (cf. the above thread). I don't think this is "fixable": by walking down from the work to the edition you would 1) interwiki a completely different edition / translation, and 2) how would you decide which one of multiple editions to link to (e.g. which of the several editions on enWS would the text at elWS get an interwiki to?). We could maybe build a local gadget that gives you a complete "other versions of this text" map built by walking Wikidata up and down, but I don't think the interwiki system can accomodate this globally.

But this also rather strongly suggests that we either need to create "versions page" (wikipages corresponding to the work level) for all our texts, or come up with something else clever. Otherwise the (different) editions at itWS, plWS, and deWS will forever stay hidden from the interwiki network. Something else clever might be the hypotethical Gadget, or possibly a built-in equivalent to {{other versions}} on steroids in the Wikisource extension. Something whose semantics are explicitly "everything, even if they're different editions" (vs. the interwikis that really can't mix and match).

I haven't had call to go spelunking in this topic before so this is just a braindump of my first foray. Comments, corrections, thoughts, etc. would be very welcome! Xover (talk) 20:20, 7 April 2026 (UTC)Reply

Misc unsorted thoughts:

• Ideally, I would expect Agamemnon (Aeschylus), as well as the top-level page for each hosted translation, to pull the following language wikilinks from wikidata:
  • ar, fr (listed in the Wikidata item directly)
  • it, de, el (wikidata items listed exactly once under "has edition or translation", but not directly in the main item)
  • possibly pl (which is listed twice under "has edition or translation"), in which case I'd expect it to link to one of the two Polish editions arbitrarily
• I don't really expect this ideal expectation to be implemented, and it won't actually bother me if it isn't tbh
• I do think that a relatively elegant solution would be to have Wikidata link to redirects in place of versions or translations pages, if only one version/translation exists. Unfortunately Wikidata discourages using redirects in wikilinks.
• We can't make a solution that depends on other Wikisources changing the way they structure their content or integrate with Wikidata, of course.
• Manually adding interwikilinks is still a valid solution, regardless of the behaviour of Wikidata or MediaWiki.

—Beleg Tâl (talk) 20:37, 7 April 2026 (UTC)Reply

Two points:

• The separate Wikidata items for the Smyth Agamenon / Αγαμέμνων should not be surprising because they are not the same edition. One is an edited original while the other is a translation. Just as two poems in the same volume will have different Wikidata items, so an English translation of a play and the original Greek of a play, even in the same volume, will have separate data items. Both are linked via published in, which identifies that they are in the same volume. There is no way that two works in different languages can be "the same edition" or should have the same data item. One is an edition of the original in its original language and the other is a translation into a modern language. Only the containing volume Aeschylus, with an English translation, Vol. II (Q137809722) is the "same edition", not the contents.
• Greek Wikisource does have two editions og the play, the Smyth edition in classical Greek, and el:Αγαμέμνων (μετάφραση Γρυπάρη), which is a modernized Greek edition pulled from Gutenberg. Greek Wikisource believes in having a clean "main" version of the text, without disambiguation, and any secondary copies disambiguated from the main one.

--EncycloPetey (talk) 21:36, 7 April 2026 (UTC)Reply

• This is obviously a big question. I personally am in favor of having several "versions" pages to disambiguate editions, but:
• If a work only has one (available) edition in English, I feel like that "editions" info could exist on the same the same page as the individual edition. Ideally, there's a way to link a page to both its work-level wikidata item and its edition-level wikidata item. Maybe a gadget or lua module to "walk up and down" like you say would be necessary? Otherwise, maybe a template that allows us to indicate both WD items.
• I think that ideally Wikidata's "work"-level item should link only to versions/editions pages on each language's WS, editions should be tagged on WD with the "has editions" property, and each edition should get its own page. If a work on Wikisource is a direct representation of a given edition, it should be directly linked to that edition-level item. Otherwise, it should get its own WD item listed separately. I think about them as: Wikisource pages that represent the work in the abstract link to the work, vs. Wikisource pages that represent an edition of a work in particular link to the edition.
• I also think that multilingual wikisource (that is, what's currently the "main" wikisource site without a subdomain) could be a good place to collect all Wikisource editions and translations of a given work in one place, across languages. (Some of us would like to see this eventually move to the mul. subdomain, but that's another conversation.) A gadget/lua module/tool to walk up and down WD items would be a welcome addition to make something like that viable.
• If ultimately we need other Wikisources to change their behavior, that's definitely something we can ask about and discuss with leadership from other WSes.

-- Mathmitch7 (talk) 00:02, 8 April 2026 (UTC)Reply

Since I tend to work on books with terrible built in OCR, I press the 'Transcribe text' button on almost every page I proofread. This morning I've started to get the following error message:

Image URL must begin with one of the following domain names and end with a valid file extension: upload.wikimedia.org and upload.wikimedia.beta.wmflabs.org

This happens no matter which transcription option I choose. Just for me, or is this a wider problem? Qq1122qq (talk) 10:07, 8 April 2026 (UTC)Reply

Just a note to say that, whether as a result of this comment, or just random good luck (did something get turned off and on again?), transcribing is now working again as normal for me. Qq1122qq (talk) 13:03, 8 April 2026 (UTC)Reply

I suspect that something got switched off accidentally and then switched back on. -- Beardo (talk) 13:48, 8 April 2026 (UTC)Reply

I'm seeing a big increase in the usage of this obscure template across multiple namespaces. The history and documentation are meagre. Should this be considered a core template, and where should it be deployed? Should it replace wiki-markup for italics, and where? Author only? Portals? Versions pages? in the Page namespace? --EncycloPetey (talk) 17:48, 8 April 2026 (UTC)Reply

I think that {{cite}} (i.e. <cite>) is the same situation as {{heading}} (i.e. <h1> etc.)—it is "more correct" from a semantic perspective, but might not play as nice with MediaWiki's formatting. So long as it doesn't mess with the fidelity of the transcription, I don't have any issue with it. —Beleg Tâl (talk) 18:27, 8 April 2026 (UTC)Reply

A bit of an announcement: Due to an intensive operation in the earlier part of this year, I have managed to clean out every single unlicensed work from Wikisource (as in mainspace, non-subpage, non-disambig pages without licenses) from the backlog a few weeks ago. So, everything on the site should have a license now, and our project should now be substantially legally safer.

For context, there were nearly 8,000 works without licenses before I started (around 6 months ago)...which was an absolute disaster. I can't believe it was actually at a number like that.

• (Okay, there's one item there now, but it was added after this major cleanup operation was done and will probably be deleted at WS:CV in a few days.)

Special thanks go to Beleg Tâl for helping out with much of the technical side of this, Jan.Kamenicek for doing a lot of the CV discussion closures, and Alien333 for doing so much at WS:PD (which is where a few of these had to go). Also thanks to several users who've given substantial debate and input in the WS:CV threads that have been created in this, as they've helped me understand copyright law a lot better and provided some great intellectual challenges.

One thing I'm interested in seeing after all of this is if the WS:CV backlog in the rest of 2026, and subsequent years, is significantly lower than previous years because of this. I am also thinking about doing other projects to clean up the backlog soon, like scan-backing constitution pages en masse for example. SnowyCinema (talk) 00:19, 10 April 2026 (UTC)Reply

Thanks very much for all the work done!!! --Jan Kameníček (talk) 10:55, 10 April 2026 (UTC)Reply

What an incredible job, thank you for all your hard work! —Beleg Tâl (talk) 13:54, 10 April 2026 (UTC)Reply

Hi, FYI Seudo from the French WS has created a small Python program to edit WS with the help of Chat-GPT. It is quite impressive. The code is here and the discussion is here (in French, but you can use a translator). Best, Yann (talk) 11:49, 10 April 2026 (UTC)Reply

Can you give us a quick preview? Is the goal to make a better OCR transcription? —Justin (koavf)❤T☮C☺M☯ 12:01, 10 April 2026 (UTC)Reply

Seudo shows some examples: simple proofreading, proofreading and complex formatting. Yann (talk) 13:35, 10 April 2026 (UTC)Reply

Using AI for providing not just OCR but also formatting on top of it, or helping to automate repetitive tasks both under human supervision is one thing. Creating a full agent that say uploads from IA, proofreads and then transcludes the pages into mainspace fully automated is another. MarkLSteadman (talk) 12:51, 10 April 2026 (UTC)Reply

Apparently, Chat-GPT is able to add formatting in addition to a good proofreading, and the process can be automated. So it does in a few seconds what a human would do in one hundred times more time. Yann (talk) 13:35, 10 April 2026 (UTC)Reply

Yeah exactly, among other things it can build out relatively complex tables in wikitext or convert mathematical formulae into latex. MarkLSteadman (talk) 13:43, 10 April 2026 (UTC)Reply

Another use case might be converting musical scores into lilypond. Another thing is it can help build out styles.css files for those less familiar with CSS. The point is that it broadens beyond just reducing the number of scanos in an OCR. MarkLSteadman (talk) 13:44, 10 April 2026 (UTC)Reply

How well does it handle cases with archaic spelling? with poetic formatting? with French or German words embedded in the text? --EncycloPetey (talk) 13:53, 10 April 2026 (UTC)Reply

None of those are necessarily intractable. It should be able with the proper instruction take stanzas and convert them into {{ppoem}} and follow instructions on keeping particular spelling idiosyncracies. They are also inherently multilingual. It's important to realize that they can be quite customized to our needs, we can tell them quite detailed how we want poems formatted or how to handle unusual spellings / other languages etc. MarkLSteadman (talk) 14:55, 10 April 2026 (UTC)Reply

It sounds as though those things are as yet untested, then. I'm not in favor of untested methods. Nor would I be keen to have to teach the model about every archaic spelling, or how to distinguish archaic spellings from poetic spellings, from dialectical spellings, or recognizing misspellings. It looks like it is perhaps an adequate tool for doing the work of OCR, and seems to be able to cope with pages with bends in them, but with insufficient testing, I wouldn't rate it beyond the same as an OCR tool. --EncycloPetey (talk) 19:20, 10 April 2026 (UTC)Reply

You want to give me a page and I can see what it can do? Or would you prefer for people to do all the testing and development in private? MarkLSteadman (talk) 23:03, 10 April 2026 (UTC)Reply

You're missing the point. It's not a question of doing a single page "right". It's the question of whether it can reliably do the job, over and over, even when the choices change from one work to another. Some works have to-day and to-morrow consistently hyphenated, but others have them unhyphenated. Some works have dialectical conventions where spaces and apostrophes appear in nonstandard places, but others do not. Some works have French loanwords spelled with diacriticals that no longer appear over those words, such as régime and rôle, and in other works those do not appear. It's going to take a lot of testing training, across multiple works with different standards. But it must be trained not only to follow certain standards, but to adjust those standards to fit the specific text. That's not something that can be demonstrated by doing one page. That requires a large number of tests under multiple conditions. "Here, it managed one page" doesn't convince me. --EncycloPetey (talk) 00:00, 11 April 2026 (UTC)Reply

Okay, so the answer will be what I said, people will develop these in private, come back in say a year, after they said I have been using this for 6 months with 10,000 edits and I am quite happy about it. But even then to answer your question, I don't do old texts or mixed language texts that frequently, I do less poetry. I know you proofread a lot more poetry. If I come back and say here it helped proofread 100 mathematical books / tables over thousands of edits that won't answer the questions you raised, does it handle poetry? MarkLSteadman (talk) 12:57, 11 April 2026 (UTC)Reply

I would take more care around "hundred times more" ("existential" for three pages and code the editor in question did not even write?). OCR is already pretty high quality, and despite all one can say, AI still is not reliable to do something deterministically. Checking everything is right is already a consequent part of proofreading, and trading less time spent transcribing for more time checking unreliable (and unreliable in nondeterministic ways) output is not necessarily a plus.

I would also raise an objection to recommending volunteers to funnel money into this. — Alien  3
3 3 14:03, 10 April 2026 (UTC)Reply

The point is that it isn't standard OCR but better, it can do some of the most time consuming tasks such as converting tables into properly organized style sheets and wikitext, scores to lilypond, or formulas to latex. I haven't seen anyone here claim that they can convert a score into lilipond with our current ocr tools. And many of these things can be a pain to work with, e.g. figuring out why your hand coded latex doesn't compile at all. MarkLSteadman (talk) 15:07, 10 April 2026 (UTC)Reply

I agree. My problem with AI is unreliability, and, more specificly, unpredictable unreliability. Whenever I use AI for OCR (NOT on Wikipedia, do not worry), I manually proofreead the results with the fine-toothed comb (and keep finding errors here and there). So I'm totally against giving it free reign. -- Wesha (talk) 17:44, 10 April 2026 (UTC)Reply

Like any tool, a final validation by a human is needed, but AI can probably do the proofreading alone. It would reduce manual work considerably. Now, the existential and commercial questions remain, but I think this is a debate worth having. I also proofread books because it is interesting and fun. So introducing a tool should not make it boring. Yann (talk) 09:16, 11 April 2026 (UTC)Reply

I've tried AI for formatting, and it has problems. Look at this diff. It does an amazing job of adding formatting, but it also added italics not in the example I fed to it, just because they were what it should have looked like, not what the page looked like. It also took excessively long titles and truncated them with ..., again not as it was done, but as it arguably should be done.

That was probably a net win, but it also introduced some real problems. I can see an tool that can produce good math OCR opening up a lot of texts to being worked on. But so far it looks way too likely to make unneeded changes to be used any way but carefully controlled.--Prosfilaes (talk) 23:37, 10 April 2026 (UTC)Reply

• I was wondering what was up with the Greek text on that page! When I went over it, I made it again from scratch, because it was wrong in very weird ways—unlike being copied from the Internet or from a mostly-accurate Greek-script OCR. Now I know. So, it seems like it’s mostly accurate, but wrong in seemingly random and hard-to-predict ways. I probably wouldn’t use it unless I would be going over the result comprehensively anyway, like when making a really large table. TE(æ)A,ea. (talk) 19:03, 11 April 2026 (UTC)Reply

  Two things: 1. It may be possible to have the AI use a tool to do source text matching with say Perseus or gr Wikisource for longer citations and surface that instead (e.g. by parsing the citation to find the work --> finding the referenced work). 2. Some of this might be addressable based on the exact script design (e.g. controlling the temperature which might cause some of these errors, or having a reviewer agent to check the transcription precisely for divergences or even highlight areas of concern). E.g. we could have a gadget that just highlights text it thinks might need double checking (which might be helpful for say, Greek text, where it could leverage it's knowledge of grammar to find typos that might be obvious to someone familiar with the language but not someone just transcribing it letter by letter). MarkLSteadman (talk) 04:08, 14 April 2026 (UTC)Reply

Our policy is that we require two pairs of human eyes to proofread and validate. We can't prove that a bot tool of some kind wasn't one or both of those pairs of eyes and we ask the operators for honesty. Although I'm unlikely to be using an AI tool to create tables and scores—I actually enjoy doing those—if there are tools that assist a Wikisourcerer to do the bits they don't enjoy and the user is fully checking output before submitting as proofread, then I don't have a problem with the concept. However, I would have a problem if an AI tool was being used to validate a page—the worst would be one AI agent proofreading and another validating without a detailed human review. (Having been told recently by an AI agent that I am two different people and having it hallucinate on the projects I've actually been involved with here, I don't have a lot of trust of AI right now.) Beeswaxcandle (talk) 19:54, 11 April 2026 (UTC)Reply

I agree 100%. I think it would be great to use AI tools to find and fix errors or set-up formatting, but only humans should be officially proofreading or officially validating. If you're clicking those buttons, it means you have used human eyes and human brains to review the text. Personally, I think it would most useful to have AI tools like this review texts that have already been validated and flag all the overlooked errors for a human to review and fix. Nosferattus (talk) 04:02, 13 April 2026 (UTC)Reply

I think in the long-term I would be OK with having an AI validate pages that are already proofread, since we have such a backlog for validation. But certainly, validate with an asterisk—clarifying that it was AI-validated and in no way guaranteed.

Despite my own immense misgivings about AI, I do occasionally use Gemini to help with some tricky proofreading questions. But the way I use it is to engage it as a simulated "colleague" to help with paleography, interpreting a work's intended meaning, and as a time-saver versus doing that research by myself.

A great example I can think of is usefully transcribing the word "slot" on Page:Report of Senate Select Committee on the Invasion of Harper's Ferry.pdf/105. The word makes absolutely no sense in its context, and so I was wondering if the scan was bad, or if there was a mechanical difficulty in the physical printing, or if another edition of the text had corrected it, or what. Ultimately, after a lot of back-and-forth with Gemini, I determined what I think is the most likely scenario, that the word was supposed to be "lost," but that it was laid out wrong on the printing press. But that was after a lot of engagement about possible historical meanings of the word "slot" (it can mean 'to slay or kill,' but that would be weird in context!), and estimating the relative likelihood of the intended word being "shot", "slot", "slain", or "lost"; and also determining if the error occurred at the hand-transcription at the hearing itself, setting the printing press, printing the sheet, storing the book, scanning the book, me reading the scan, or some complex combination. All that to end up writing {{SIC|slot|lost}} on a page that few people will ever read.

Now granted, that's a kind of high-level interpretation (and ultimately, annotation) that I'm comfortable doing all by myself. But whereas I have to fully immerse myself into a historical context to be able to evaluate these sorts of things, an AI chatbot can get me up to speed on that stuff while still firmly staying in an advisory role. In short, it's a tool. I don't even trust AI stuff to adequately act as a literal OCR engine -- I'm very very far from treating one as a trusted wikisource editor. -- Mathmitch7 (talk) 22:49, 13 April 2026 (UTC)Reply

I don't see much point in having AI validate pages. Validation is really an extra, and should mean that someone has carefully gone over the final page. That pages aren't validated is fine.

I don't know what you mean by "AI stuff". In the most general sense of AI, anything that can do OCR is AI. In the modern neural network meaning, most modern OCR is AI, including the normal mode of Tesseract, the OCR that we usually use.--Prosfilaes (talk) 00:53, 14 April 2026 (UTC)Reply

I think it might make sense to help identify things that people might have missed.An example would be helping to find things like modern vs. modem, 0 vs. O, Is vs. 1s etc. by building up good lists of such errors since it would have both the context and the scan to compare to. Another thing, is it could provide far more pointed guidance around lint errors, think of adding an "AI review" button next to "show preview" at it will give a short list of things to check. MarkLSteadman (talk) 04:15, 14 April 2026 (UTC)Reply

E.g.

1. You used block template {{c}} inside a span template {{larger}}: suggestion instead of {{larger}} use {{larger block}}.

2. You have fostered content: suggestion add {{nopt}} to the table

3. On row 5 of the table you have Is: likely 1s because it is referring to one shilling as a price given the row above and below say 6d

MarkLSteadman (talk) 04:21, 14 April 2026 (UTC)Reply

I wonder if anybody has actually tried my tool, or did you use other AI techniques?

Since running a Python command-line tool is not for everybody, I produced an executable with a graphical interface (not published yet, but I could publish it on Github if it is useful). Making a graphical interface, which used to take a week of professional programmer's work, can be done today in a few hours with AI programming tools...

For real-world examples, I ran the tool on 24 pages with complex formatting, sections and template calls, such as here (see the wikicode). The prompt I used is there and you can see, even if you can't read French, that's it's not very long and could be written by any Wikisource user.

However this is mostly useful when you need special formatting and/or you have complex OCR needs (AI works great on ancient Greek). For standard, 19-century novels, this would probably be a waste of time and AI tokens. Seudo (talk) 07:52, 16 April 2026 (UTC)Reply

While AI is a better tool than OCR for English text transcription and formatting, it can introduce errors in table formatting and non-English text. For my case in Index:Dictionary of the Foochow Dialect.pdf, it can forget to introduce the whole column, switching data first with the second row, or switching data between the first with the last row, or totally forget to introduce a row every 30 to 50 transcriptions. Cerevisae (talk) 02:28, 22 April 2026 (UTC)Reply

I also noticed that AI sometimes "forgets" an entire paragraph in the text, with no apparent reason. A solution might be to ask a second AI to check that the main AI has transcribed everything... The second AI may use a less intelligent (and less expensive) model than the first one. Seudo (talk) 08:04, 23 April 2026 (UTC)Reply

I have used Chat-GPT to format this page. Yann (talk) 08:40, 23 April 2026 (UTC)Reply

Worlds of IF (February 1958) overall, and specifically, Isaac Asimov's story, Feeling of Power. -- Wesha (talk) 17:47, 10 April 2026 (UTC)Reply

Per https://onlinebooks.library.upenn.edu/webbin/cinfo/if1952, the Asimov was the one story renewed from that issue. -- Beardo (talk) 18:49, 10 April 2026 (UTC)Reply

(And you asked about that story previously !) -- Beardo (talk) 19:01, 10 April 2026 (UTC)Reply

Sorry if I have. Must have slipped my mind. Thank you! -- Wesha (talk) 21:54, 10 April 2026 (UTC)Reply

MediaWiki message delivery 15:19, 13 April 2026 (UTC)Reply

I don't know who to contact, so I'm writing here. The clock on the Tatar segment's main page isn't working correctly. For example, the time on the UTС is currently 15:20, but the main page is stuck at 5:40. Please help or tell me who to contact. Winogadique (talk) 15:21, 13 April 2026 (UTC)Reply

I don't know what you mean. Can you please provide a link? —Justin (koavf)❤T☮C☺M☯ 15:42, 13 April 2026 (UTC)Reply

This is mul:Main Page/Татарча. These editors have chosen to use some {{CURRENTTIME}}-kind stuff to display the current time; but all pages are cached so stuff isn't reparsed every second. Putting the date there was an awkward choice but not much to do. — Alien  3
3 3 17:30, 13 April 2026 (UTC)Reply

I'm an admin at mul.ws and I could port mw:MediaWiki:Gadget-UTCLiveClock.js to have a constantly-updating clock. Do we need that? —Justin (koavf)❤T☮C☺M☯ 17:42, 13 April 2026 (UTC)Reply

That's just a gadget; it would be JS running in the user interface, not like a clock inside the page content. I'm dubious about the use of an in-clock page anyhow. — Alien  3
3 3 19:39, 13 April 2026 (UTC)Reply

I think that using {{currenttime}} for this purpose is a mistake, in any case, and should just be removed from that page. mw:Help:Magic_words#Date_and_time says "Due to MediaWiki and browser caching, these variables frequently show when the page was cached rather than the current time," making it inadequate for this purpose. As to Justin's question, I don't see a pressing need for a sitewide clock gadget, especially because we're a library, not a source for up-to-the-minute news. -- Mathmitch7 (talk) 22:22, 13 April 2026 (UTC)Reply

Done https://wikisource.org/w/index.php?title=Template%3A%D0%91%D0%B0%D1%88%D0%B1%D0%B8%D1%82%2F%D0%91%D0%B0%D1%88%D0%BB%D1%8B%D0%BA&diff=1334617&oldid=320069 —Justin (koavf)❤T☮C☺M☯ 22:41, 13 April 2026 (UTC)Reply

This user's contributions were to add several poems and articles from Savant, a publisher that had a magazine with English language editions and 2 global editions written in the language of the circulation region. Peculiarly, there doesn't seem to be proof that the publisher ever existed, nor could I find any evidence that the apparent authors were either alive or dead. Nighfidelity (talk) 19:35, 13 April 2026 (UTC)Reply

see my comment/investigation/rant on the deletion discussion for savant's wikipedia page. ltbdl (talk) 01:57, 14 April 2026 (UTC)Reply

I am planning to use User:CerevisaeBot to add preliminary AI-formatted transcriptions from pages 734 to 1741 on Index:Dictionary of the Foochow Dialect.pdf. All the changes will be implemented using a Python script. The texts will be reviewed before the script is activated to implement the changes. Will review implemented changes for every 10 to 30 pages of transcriptions. The Bot will be deactivated after all the preliminary transcriptions are completed. Cerevisae (talk) 00:39, 14 April 2026 (UTC)Reply

At New York Daily News/1928/03/09/Freeport Legion Lists War Heroes can the wikidata link to one of the people mentioned in the article be restored? I know some people do not like them, but this has been debated multiple times. RAN (talk) 18:05, 15 April 2026 (UTC)Reply

Has something been changed yet again? Editing that used to run smoothly now requires multiple tweaks every time I proofread a page.

I've been proofreading A Daughter of the Seine all this month. As of yesterday, everything functioned well, and earlier this morning too. But as of a short time ago, whenever I edit via the Proofreading edit window, whether to proofread a new page or to verify an existing page, the scan page is briefly visible then vanishes. I can get it back by clicking in the scan window, at which point it is too large to display in the window and I have to resize it. I'm having to go through this process every single time I open the proofreading window.

Nor is the problem limited to that scan. I have checked several more scans, both PDF and DjVu, and this issue is happening for every scan I check.

Are other people experiencing this issue? Did something happen in the past few hours to create this problem? --EncycloPetey (talk) 18:51, 15 April 2026 (UTC)Reply

Not happening on my side. What I'm seeing is the page loads with the image, then disappears briefly, but then comes back and stays there. Are you seeing any errors in your browser console? Might be related to settings or smth. — Alien  3
3 3 20:28, 15 April 2026 (UTC)Reply

@EncycloPetey @Alien333 When I click edit, the page image also vanishes for me. Occasionally it reappears by itself almost immediately, more often scrolling in and out on the page image fixes it, or if not that, then clicking back on my browser, then clicking edit on the page again. Regards, TeysaKarlov (talk) 21:32, 15 April 2026 (UTC)Reply

Yes, and if I'm previewing the page, every time in or out of the preview I have to make those adjustments again. It is no longer remembering settings for pages, and the constant need to tweak the image every time in order to simply see the scan has drastically slowed my progress. --EncycloPetey (talk) 21:38, 15 April 2026 (UTC)Reply

I've the same issue. Resize, zoom in, zoom out bring the image. In the console there is the following error, apparently when the image disappear:

Error creating texture in WebGL. undefined openseadragon.js:28820

setIssue @ openseadragon.js:28820

internalCacheCreate @ openseadragon.js:26192

prepareInternalCacheSync @ openseadragon.js:31342

etc. The French Wikisource has also the same issue. • M-le-mot-dit (talk) 21:55, 15 April 2026 (UTC)Reply

If I had changed anything at my end, that might make sense, but I haven't. No, I have no errors in my browser for anything, and I have changed no settings anywhere. It started a few hours ago and is persistent since then. --EncycloPetey (talk) 21:45, 15 April 2026 (UTC)Reply

Well, I wasn't having additional issues, but now I am. If I edit and then save a new page, the result displays only the user-created content; the scan image disappears entirely once I save the edit, and I can't get it back unless I go to some other Index, then return. Files are disappearing from the Index as well. My browser is now saying "Failed to initialize OpenSeadragon; no image found", whatever that means. This is problematic enough that I'm going to switch to working elsewhere while this gets resolved. --EncycloPetey (talk) 21:51, 15 April 2026 (UTC)Reply

• I am having the same problems as EncycloPetey. When I try to edit a page, the image appears for a fraction of a second, then disappears. If I change the position of the image, it works. I can do this by clicking on where the image should be, to zoom in, and then resizing it to the normal size; or, if the index also has the related problem of incorrectly resizing every page, I just need to click the resize page button. However, once I reload the page (for example, by clicking on “Show preview”), the image once again doesn’t load. (2) A related issue which I have been facing is that, sometimes, I am unable to call the OCR tool when I open a page, which throws the “Error from the OCR tool” message. (3) I mention that because, now, it does this for every page. Presumably this is owing to some new, stupid change to the backend code. TE(æ)A,ea. (talk) 00:23, 16 April 2026 (UTC)Reply

Oh well, happening to me too now. Have opened task on phabricator: phab:T423548. — Alien  3
3 3 05:59, 16 April 2026 (UTC)Reply

Thanks for that. The problem has worsened for me today. It is no longer loading any image in the Proofread scan window. I get an error and no access to the scan. If I want to proofread, I'll have to have one tab open to the proofread edit window and a separate tab open to the scan source at IA. There's no way for me to proofread within the Proofread page editing. --EncycloPetey (talk) 17:17, 16 April 2026 (UTC)Reply

Well, that's not working now either. With no page image, I can't use OCR, and the file is no longer feeding it's text layer. So I would either have to generate OCR off site or type it all manually. This issue seems to vary individually by scan. The issue is affecting some PDFs but not all. --EncycloPetey (talk) 17:22, 16 April 2026 (UTC)Reply

I noticed this some yesterday, but today it's gotten worse (same issues EncycloPetey describes). —Tcr25 (talk) 15:28, 17 April 2026 (UTC)Reply

I did not experience this issue when EncycloPetey mentioned it first, but today I have been experiencing it too. --Jan Kameníček (talk) 19:52, 17 April 2026 (UTC)Reply

I am seeing this as well, where I need to change the zoom. I do notice the following CORS error in the console: "WebGL warning: tex(Sub)Image[23]D: Cross-origin elements require CORS." which might explain this as something is up with the cross-site protection (the web browser blocking one site (here "upload.wikimedia.org" from commons) rendering in another ("en.wikisource.org"). This is with Firefox Browser. When using Chrome I see the error in seadragon setIssue mentioned above. I also see the issue in safari. Note it persists even after disabling enhanced tracking protection as well. MarkLSteadman (talk) 00:54, 18 April 2026 (UTC)Reply

@Samwilson I saw that there was some recent work with seadragon in the ProofreadPage extension repo, just a heads up that we have been seeing issues with the initial rendering of the images in various browsers. MarkLSteadman (talk) 01:06, 18 April 2026 (UTC)Reply

@MarkLSteadman: I've been looking into it. Sorry about breaking things! :( I've replied on phab:T423548. Sam Wilson 01:32, 19 April 2026 (UTC)Reply

This is now fixed for me. Thanks! MarkLSteadman (talk) 23:51, 22 April 2026 (UTC)Reply

We had the same problem, since a couple of days. When will this be corrected? It's very nasty. --Dick Bos (talk) 06:32, 21 April 2026 (UTC)Reply

Should be fixed tomorrow morning UTC. — Alien  3
3 3 09:40, 21 April 2026 (UTC)Reply

Fixed! Thanks.................--Dick Bos (talk) 06:38, 23 April 2026 (UTC)Reply

Hi, Is there a place for advertising validated texts? I can't find one. I think it would encourage people to validate more texts, if the result is proeminently displayed somewhere (e.g. on the main page on French WS: fr:Wikisource:Accueil). Yann (talk) 20:06, 16 April 2026 (UTC)Reply

We advertise Proofread texts. Validated texts of note can be nominated as possible Featured Texts, but that does not always succeed because validation sometimes leaves many errors in the text. We have a former Featured text currently under review because it is full of transcription errors. The situation on French Wikisource may be better, but we often have new editors contribute to validation without understanding what that actually means. How does French Wikisource manage this issue? --EncycloPetey (talk) 21:19, 16 April 2026 (UTC)Reply

There is no particuler process. AFAIK, new users mostly want to proofread new texts. Yann (talk) 19:25, 17 April 2026 (UTC)Reply

@Yann: At least twice,[16][17] it has been proposed to put a validated texts search box on the Main Page. Both Kaldari and Xover created working mock-ups for it (e.g. [18]). But it seems to have been forgotten about despite apparent support. I would definitely support having such a feature on the Main Page and it's kind of ridiculous that we don't have any way for visitors to discover our validated texts. Nosferattus (talk) 20:40, 17 April 2026 (UTC)Reply

Reading through the old discussions, it seems the only problem was that many of our validated texts weren't actually in Category:Validated texts at the time. Back then we only had ~2500 texts in the category, but now there are 4,350, which seems like a decent number. Kaldari, Xover: Is this something we could move forward with? Nosferattus (talk) 21:11, 17 April 2026 (UTC)Reply

Per Portal:Proofreading milestones, still missing much. (Maybe a situation like this.) — Alien  3
3 3 21:26, 17 April 2026 (UTC)Reply

It looks like a lot of the validated indexes in Category:Index Validated are transcriptions of single images rather than texts per se, for example Index:"GIVE^ United War Work Campaign." - NARA - 512697.tif and Index:! Explosive objects in War in Ukraine, 2022 (01).jpg. This seems to explain some of the discrepancy. Nosferattus (talk) 16:01, 19 April 2026 (UTC)Reply

Apparently there was a discussion back in 2014[19] to establish which types of Wikisource content were considered notable enough to have their own Wikidata items. Most issues were conclusively resolved in that discussion, but the status of book chapters was not, nor has it ever been clarified in the 12 years since. So some Wikisource books have Wikidata items for all their chapters and some don't. To settle this matter one way or the other, I created a discussion on Wikidata: Wikidata:Project chat#Creating Wikidata items for every chapter of a book. If you are interested in this topic, please join the discussion there (not here). Thanks! Nosferattus (talk) 22:03, 17 April 2026 (UTC)Reply

What exactly is the difference between {{inline-right}} and {{Right inline}}? ToxicPea (talk) 13:58, 18 April 2026 (UTC)Reply

The latter one actually works, but the former does not? --EncycloPetey (talk) 14:17, 18 April 2026 (UTC)Reply

well, title. ltbdl (talk) 15:56, 18 April 2026 (UTC)Reply

Are you joking? Nosferattus (talk) 16:07, 18 April 2026 (UTC)Reply

no. it's documentary evidence, although it's weird documentary evidence. ltbdl (talk) 16:09, 18 April 2026 (UTC)Reply

I'd say this would not be eligible per Wikisource:Proposed deletions/Archives/2026#EFTA00005586. ToxicPea (talk) 16:16, 18 April 2026 (UTC)Reply

You can add it to mul:. —Justin (koavf)❤T☮C☺M☯ 18:50, 18 April 2026 (UTC)Reply

Wouldn't mul: have the same problem with scope? ToxicPea (talk) 00:22, 19 April 2026 (UTC)Reply

mul: allows for non-textual content as long as it's tagged under the mul:Category:Zxx (No linguistic content). Unlike most subdomains, we basically don't have an official scope policy, afaik. -- Mathmitch7 (talk) 16:57, 19 April 2026 (UTC)Reply

This would be a legit historical document. Of course you couldn't just publish anything, but since this is in principle in scope as an educational and historical document, there's no issue with the linguistic content as such. —Justin (koavf)❤T☮C☺M☯ 23:59, 19 April 2026 (UTC)Reply

Did something happen to prevent pageview data collection during the past two days? I've checked several unrelated pages here, in several namespaces, as well as several pages from two other Wikisource languages. In all cases, there are no views recorded from the past two days, even for pages that are normally high traffic. --EncycloPetey (talk) 17:59, 19 April 2026 (UTC)Reply

Third day without pageview data. Is the data not there, inaccessible, or has our statistics code stopped working?. --EncycloPetey (talk) 18:56, 20 April 2026 (UTC)Reply

The Star Science Fiction Stories anthology series, specifically the short story It's a Good Life, in the second volume. Nighfidelity (talk) 21:12, 19 April 2026 (UTC)Reply

I see that no. 4, 5 and 6 were renewed - here - but I don't see the others. -- Beardo (talk) 22:05, 19 April 2026 (UTC)Reply

MediaWiki message delivery 15:00, 20 April 2026 (UTC)Reply

Hi, Why does the template {{asc}} stopped working here, while {{sc}} works as expected? Thanks, Yann (talk) 17:52, 20 April 2026 (UTC)Reply

TemplateStyles does not work inside a wikilink. There are instances of {{sc}} on that page that are not inside wikilinks, so its TemplateStyles page has been loaded; but all instances of {{asc}} are inside wikilinks so its TemplateStyles page has not been loaded. The workaroun I usually use, is to place <templatestyles src="All small caps/styles.css /> manually somewhere else on the page. —Beleg Tâl (talk) 18:01, 20 April 2026 (UTC)Reply

Alternatively, if you put that asc outside the wikilink (and not include the author), I think that would work, no ? -- Beardo (talk) 18:05, 20 April 2026 (UTC)Reply

Yes, assuming that the whole wikilink should be all small caps, then that works too :) —Beleg Tâl (talk) 18:06, 20 April 2026 (UTC)Reply

Yes, that works. Yann (talk) 18:20, 20 April 2026 (UTC)Reply

Actually, it is more complicated than that:

[[The Collected Works of Mahatma Gandhi/Volume 1/Preface to this Volume|{{asc|Preface to this Volume}}]] works (4th line);

But [[The Collected Works of Mahatma Gandhi/Volume 1/General Preface|{{asc|General Preface}}]] doesn't work. (3rd line). Yann (talk) 18:27, 20 April 2026 (UTC)Reply

Another alternative is to make the Contents a table, and set all-small-caps for the one column using the Style sheet. --EncycloPetey (talk) 18:23, 20 April 2026 (UTC)Reply

IMO the easiest would to change {{asc}} so that it works like {{sc}}. Yann (talk) 18:32, 20 April 2026 (UTC)Reply

The method I'm suggesting would require neither template at all, nor the multiple TOC templates. --EncycloPetey (talk) 18:53, 20 April 2026 (UTC)Reply

I am open to suggestion, but I have seen many alignment issues with tables. And now that the page is formatted with templates, it is a big work. ;o) Yann (talk) 19:50, 20 April 2026 (UTC)Reply

There is an easy solution: moving {{TOC begin|asc=yes}} to the header. It also makes the code cleaner. Yann (talk) 22:32, 21 April 2026 (UTC)Reply

One day, one day, we'll have templatestyles in links. Perhaps we'll even be alive to see it... — Alien  3
3 3 10:17, 21 April 2026 (UTC)Reply

Hi, I would like to have a second opinion about formatting of this work. Since formatting should be consistent for the whole work, better to do it right from the start.

1. How to name sections when there are several similarly named sections in the same volume, e.g. Page:The Collected Works of Mahatma Gandhi, vol. 1.djvu/34?

2. Should sections about the same subject be merged, e.g. Page:The Collected Works of Mahatma Gandhi, vol. 1.djvu/33, "Indian Vegetarians" 1 to 6? If not, how do we name them?

Yann (talk) 20:53, 20 April 2026 (UTC)Reply

The sections are all numbered in the Contents, precisely so that works with similar titles can be distinguished. It would make more sense to use that numbering system as labels for the subpages. Then each item will have a unique label, and nothing needs to be merged. --EncycloPetey (talk) 22:13, 20 April 2026 (UTC)Reply

@EncycloPetey: Hi, Do you mean naming The Collected Works of Mahatma Gandhi/Volume 1/A Confession as The Collected Works of Mahatma Gandhi/Volume 1/1? Yann (talk) 06:48, 21 April 2026 (UTC)Reply

If there is no suitable word to describe the items, then yes. Though something like /Item 1 rather than just /1 would be preferable. --EncycloPetey (talk) 14:46, 21 April 2026 (UTC)Reply

@EncycloPetey: All sections have meaningful titles, so I would keep them. But numbering can be added, e.g. "meaningful title (1)", "meaningful title (2)". Any issue with that? Yann (talk) 20:00, 21 April 2026 (UTC)Reply

That becomes complicated when dealing with a multi-volume work with many repeated titles. Wikisource:Style Guide recommends numbering over individual titles when the parts are numbered. --EncycloPetey (talk) 20:09, 21 April 2026 (UTC)Reply

OK, but the titles include the volume number. Also it could be argued that each section is a work of its own right. They are not chapters in a novels. They appear successively only because they are published in chronological order. Naming them by their title would greatly improve the possibility to search for them. Actually, I think using "meaningful title (date)" to avoid any confusion. Yann (talk) 20:34, 21 April 2026 (UTC)Reply

That won't work because some works have the same title and the same date. --EncycloPetey (talk) 20:54, 21 April 2026 (UTC)Reply

Hi, Should the dates in the ToC by formatted as (3-2-1929) or as (3–2–1929)? Thanks, Yann (talk) 08:42, 22 April 2026 (UTC)Reply

See, for example, 22d Intelligence Squadron, where the author value in Index space is "Air Force Historical Research Agency" but in Mainspace is "Air Force Historical Research Agency". Since author field is usually a wikilink in Index space already if a wikilink is appropriate, the autoheader probably shouldn't be also trying to convert it to a wikilink, especially if it results in situations like this one. —Beleg Tâl (talk) 23:40, 20 April 2026 (UTC)Reply

I thought that the author field in Index space has to be manually made into a link - it isn't automatic. -- Beardo (talk) 03:43, 21 April 2026 (UTC)Reply

Y Fixed. Special:Diff/15895518. Essentially, some time ago we changed code to properly pass on author names to {{header}} instead of links and the *-nolink params; but that made output the same for stuff left purposefully unlinked in indexspace and stuff linking to an author page. I've added an additional nolink for attribution params that don't contain any links. — Alien  3
3 3 10:13, 21 April 2026 (UTC)Reply

Thank you! —Beleg Tâl (talk) 13:28, 21 April 2026 (UTC)Reply

Moheen (talk) 20:37, 21 April 2026 (UTC)Reply

Hello! I am an admin at the Finnish Wikisource. We do not have a namespace for Author pages but we just dump them among everything else in the mainspace, and I see that the German project does the same. Could you tell me, in a few words, the benefits of having a separate namespace for authors? And if by happenstance here should be some users who also work in the German Wikisource, how do you cope without having one? Pxos (talk) 15:50, 22 April 2026 (UTC)Reply

It's not a huge difference, but it makes the mainspace only for works, and I frequently review changes among authors by filtering to just that namespace.--Prosfilaes (talk) 23:31, 22 April 2026 (UTC)Reply

I think we have a bunch of templates that do different behavior based on the namespace, e.g. the license templates. So say {{PD-old}} will say "This work was published before ..." in Main but "Some or all works by this author were published before ..." in Author. Maintenance categories and searching might also be easier, that said this is more a question of scale and activity. The Portal / Author / Work separation does cause issues and confusion, so YMMV. MarkLSteadman (talk) 00:10, 23 April 2026 (UTC)Reply

Take, for example, when one sees at "recent changes", a page with a human name (for example, Augustus Lowell). The reader will not know whether it is the name of a book or the name of an author until he or she clicks on the page. Having separate namespaces makes things much easier. Sije (talk) 20:27, 23 April 2026 (UTC)Reply

Namespaces create a tangible, computer-readable separation between different kinds of content. The content in works and in author pages is of a different nature, therefore having a separation is natural. I'd especially highlight the part about templates and so on. — Alien  3
3 3 20:48, 23 April 2026 (UTC)Reply

Having texts and authors in separate namespaces also means never having to disambiguate the two kinds of content in the same namespace. So, for example, biographies about people do not have to be disambiguated from the people they are about. A disambiguation page in our mainspace only has to disambiguate works with the same title, not different categories of data. --EncycloPetey (talk) 21:40, 23 April 2026 (UTC)Reply

I see that the latest update has drastically changed the look of module editing, with some of the useful features removed, notably the vertical column lines. In placxe of vertical alignment bars down the page, I must count individual uses of tabs and spaces. Is there an option somewhere to reactivate the vertical lines? --EncycloPetey (talk) 19:35, 22 April 2026 (UTC)Reply

If you press alt+shift+,, and tick the "highlight whitespace" button, it shows all the tabs and spaces.

I'd appreciate if you could take some time to detail issues you have with CodeMirror (the code editor which just replaced the old one), so I can forward that to the devs working on it. — Alien  3
3 3 19:58, 22 April 2026 (UTC)Reply

I know how to show all the tabs and spaces, but that's a visual mess that's hard to parse and looks more like noise than information. That's why I asked if there was a way to get the vertical lines back. As I said, counting individual space splotches and tab arrows everywhere is not useful. It is visual noise. The clean vertical lines we used to have representing the location of every 5 spaces / tab was much cleaner and easier to use.

Note also that your keystroke instructions will not work on my Mac and are not at all intuitive. Further, tf I activate all the visual cues while editing a Module, then all that nonsense follows me to the next Proofread edit window, and I have to go looking for how to turn it off. Previously, we had clean vertical lines, line numbers, and colors that showed up only what editing in Module namespace. Now I must activate and deactivate every time I switch between editing namespaces. --EncycloPetey (talk) 20:05, 22 April 2026 (UTC)Reply

Re the indent lines: for info, that's phab:T412883.

Re wikitext/non-wikitext keeping settings: that's phab:T418352, being worked on right now. (It got a fair lot of people annoyed.) — Alien  3
3 3 20:17, 22 April 2026 (UTC)Reply

That's not to imply that all the changes are bad. In fact, I am very happy to see that we can now easily activate line numbers while editing in any namespace, which makes it much easier to locate issues while editing. --EncycloPetey (talk) 20:09, 22 April 2026 (UTC)Reply

Is this the conversion from OpenGL to Canvas to fix the issues raised above about image rendering? MarkLSteadman (talk) 23:51, 22 April 2026 (UTC)Reply

Er, no.

That change solely concerned the image you see at the right in proofreadpage when editing. OpenGL and the Canvas API are two JS APIs that let code modify the html <canvas. element.

The change in question here is the move between two MediaWiki extensions that provide syntax highlighting and the like: mw:CodeEditor (based on the external library Ace), which up to now was the editor we got for module pages, and now is not used anymore; and mw:CodeMirror (based on the external library of the same name), which provided the syntax highlighting etc for wikitext pages for a long time (the "syntax" button if you use the 2010 toolbar), was recently greatly upgraded to now also cover modules and other code pages, and a few days ago replaced CodeEditor for module pages. — Alien  3
3 3 08:34, 23 April 2026 (UTC)Reply

@DraftSaturn15@Penguin1737 What are you using to redact pdfs? I've tried to redact two pdfs and somehow managed to delete the OCR. ToxicPea (talk) 02:01, 23 April 2026 (UTC)Reply

I use https://smallpdf.com/redact-pdf to redact pdfs. —DraftSaturn15 (talk) 04:03, 23 April 2026 (UTC)Reply

I use https://tools.pdf24.org/en/ for redacting. It also has other tools for adding OCR layers and cropping out images. Penguin1737 (talk) 00:29, 24 April 2026 (UTC)Reply