Wikisource:Scriptorium

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

Announcements

Wikimedia Education Program - National Education Policy Pilot Project at Fergusson College, Pune

The Open Knowledge Initiatives (OKI) at International Institute of Information Technology, Hyderabad is a strategic initiative with the aim to foster language diversity and promote equitable access to knowledge across the Indian subcontinent. Through community-led and multilingual efforts across Wikimedia projects like Wikipedia, Wikimedia Commons, Wikisource, Wikidata in research, partnerships, technology development, and outreach, the initiative seeks to strengthen and expand the open knowledge and technology ecosystem.
Under the Wikimedia Education Program - National Education Policy Pilot Project, OKI aims to develop a strategic framework for integrating open knowledge ecosystems into the Indian education landscape, directly responding to the mandates of the National Education Policy (NEP) 2020 and integrating the findings of the 2024 CIS-A2K study. OKI is facilitating and mentoring the community collaborations with different educational institutions to design the scalable process modules.
In collaboration with Fergusson College, Pune and Wikimedians, we have started Wikisource:Wikimedia Education Program - National Education Policy Pilot Project at Fergusson College, Pune. We kindly request for the community support in this endeavor.
Regards, Subodh (OKI) (talk) 12:50, 28 January 2026 (UTC)

Proposals

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

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

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

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

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

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

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

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

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

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

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

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

I'm not sure I understand you (genuinely). Do you want to avoid having to evaluate the list prior to speedy deletion, and also avoid permitting speedy deletion of Authors that have listed works? If so, I think the simplest wording would be "Authors with no works listed". —Beleg Tâl (talk) 14:33, 20 October 2025 (UTC)

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

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

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

Since this discussion is about the deletion of Author pages, and since talk pages of deleted pages are also speedied under WS:CSD M4 "Orphaned talk page", moving content to the talk page wouldn't help for any of the pages affected by this policy. It's a good idea though, for any Author pages for which this is a concern. —Beleg Tâl (talk) 14:40, 20 October 2025 (UTC)

So, we have three kinds of wording of the speedy deletion provision suggested:

1. Author pages with no published works by the author listed.
2. Author pages with no published works by the author listed nor any listed works permitted under WS:WWI.
3. Author pages with no hostable works listed.

My personal understanding of these points is:

No. 1 is clear. It allows to speedy delete only pages not listing anything published. Thus pages with lists of works published in foreign languages cannot be speedied, but they can be nominated for deletion at WS:PD to give community some time to list their English translations if such exist.

No. 2 further restricts the range of pages eligible for speedy deletion, excluding pages that list works which were not published but are permitted to be hosted (such as theses that have been reviewed and approved by a thesis committee at an accredited university, or scientific research—whether peer-reviewed or not—if the author meets Wikipedia’s notability guidelines).

I am not in favor of this, as it makes the speedy deletion process unnecessarily complicated. It would require the proposer to verify details such as whether the university in question is accredited, among other things. Moreover, I find the idea of hosting lists of unpublished scientific research that might one day be accepted here unconvincing, as is the need to analyze an author’s notability in such cases. In my view, author pages of this kind should only be created if we actually host their works.

No. 3 allows to speedy delete also pages with lists of foreign language works, which is not allowed under no. 1 or 2.

If anyone wishes, additional points can be added to the list. To avoid any misunderstanding, it might be better to hold a regular vote this time. To keep things fair, I suggest starting the vote, for example, once there have been no new comments here for five days. --Jan Kameníček (talk) 22:22, 30 October 2025 (UTC)

Number 3 is too broad, and would allow for speedy deletion of pages that are explicitly permitted by policy and by consensus, such as notable persons. It also requires research on the part of the person performing the deletion beyond what should be necessary for a speedy deletion. Is Seneca's Hercules Oetaeus hostable? Yes, but you can't tell that without researching it. Is "Komarekiella atlantica gen. et sp. nov. (Nostocaceae, Cyanobacteria)" hostable? The title is in Latin, but the article is in English. It might be hostable, but you wouldn't be able to tell from a list simply bearing the title, and it would require an investigation into its copyright status. Is Lucan's "Pharsalia" hostable? Yes; there are several public-domain English translations. Strindberg's Fordringsägare? Yes, with at least two English translations in public domain. Menander's Dyskolos? Maybe; it depends on the date of the translation, since a big discovery of a new papyrus was made in 1959, and translations based on that text won't be in public domain yet. None of this could be evaluated as part of a "speedy" deletion. It would require feedback from people doing research, or who are well acquainted enough already with the literature. --EncycloPetey (talk) 01:10, 31 October 2025 (UTC)

The onus would be on the author creator to provide a link to the translation. So you want to create a page for Strindberg, you have to provide an instance of a translation. It's like CS:6 for Author pages listing all copyrighted work. If someone creates a modern author page listing 10 copyrighted books, it isn't on the admin to do an exhaustive search to see if they authored a freely-licensed journal article somewhere. MarkLSteadman (talk) 15:14, 31 October 2025 (UTC)

"Published" is a little bit tricky, between common usage (e.g. a book was printed by a publishing house) and copyright office use (e.g. "If an author places copies of their new short story in a library book exchange box at the end of their driveway this constitutes publication of that short story.") and things like "limited publication" (e.g. sending a book to a publisher and it being rejected). So e.g. are works that have been "limited" published, "published" acording to criteria 1 (which would already cover the theses example)? MarkLSteadman (talk) 15:01, 31 October 2025 (UTC)

Indeed. I honestly don't like any of the three wordings listed above. I prefer my original suggestion: "Author pages with no works by the author listed". --EncycloPetey (talk) 17:29, 31 October 2025 (UTC)

I'm in favour of this wording tbh —Beleg Tâl (talk) 23:10, 1 November 2025 (UTC)

Unless we discuss copyright, we usually mean the first meaning of the term, as it is also used in WS:WWI, and in this sense it is also meant here. The wording EncycloPetey has suggested here can be added to the voting list. --Jan Kameníček (talk) 23:00, 1 November 2025 (UTC)

• Jan Kameníček, I think your consideration for No. 2 is too far-fetched. I think, in such a case, that it is reasonable and desirable, in case of uncertainty as to whether a work qualifies for speedy deletion, to bring it under normal deletion. I think it is good that grounds for speedy deletion are limited. In a deletion discussion, the onus should be on the creator to just retention; but in the case of a speedy deletion, where the creator does not always have the opportunity to respond, then the onus should be on the person seeking deletion. TE(æ)A,ea. (talk) 16:45, 31 October 2025 (UTC)

  My issue with #2 is that it is too arbitrary. Rewording the suggested criterion slightly, "Author pages where all listed works (if any) are both unpublished and also fail WS:WWI" seems like a strange line in the sand to draw, especially since it's tangenital to the original purpose of the criterion (i.e. empty author pages). Also, I suspect that the few Author pages that list only unpublished non-hostable works are niche enough that I'd prefer they go through WS:PD regardless. —Beleg Tâl (talk) 15:16, 4 November 2025 (UTC)

Voting

Let's start voting to conclude the issue finally. --Jan Kameníček (talk) 15:37, 29 November 2025 (UTC)

1. Author pages with no published works by the author listed.
2. Author pages with no published works by the author listed nor any listed works permitted under WS:WWI.
3. Author pages with no hostable works listed.
   •  Support --Jan Kameníček (talk) 15:38, 29 November 2025 (UTC)
   •  Support — Alien  3
     3 3 09:25, 30 November 2025 (UTC)
   •  Support And opposing the options with unpublished works not being permitted, since unpublished works of notable people would be reasons to include them as author pages in my view. SnowyCinema (talk) 19:27, 29 December 2025 (UTC)
   •  Support —Beleg Âlt ^BT (talk) 20:06, 29 December 2025 (UTC)
4. Author pages with no works by the author listed.
5. Author pages where all listed works (if any) are both unpublished and also fail WS:WWI.

While the policy itself was accepted with a solid number of votes, the poll on the precise wording has attracted only two votes so far, so I will wait a while longer before closing it. --Jan Kameníček (talk) 23:58, 21 December 2025 (UTC)

Given the number of voters, it seems that the exact wording of the adopted policy does not matter much to contributors. If no further votes are cast, I will close the discussion with the result “Author pages with no hostable works listed.” Let’s give it one more week. --Jan Kameníček (talk) 19:16, 29 December 2025 (UTC)

I am closing the discussion aimed at refining the wording of the policy on speedy deletion of empty author pages, adopting the following preferred wording: "Author pages with no hostable works listed." --Jan Kameníček (talk) 20:27, 5 January 2026 (UTC)

Proposal: Add option for Wikidata item in Index namespace

In some wikisources, basic data about a work in Index namespace comes from Wikidata, compare here. This new trend is implemented by inserting the option in MediaWiki:Proofreadpage index template and MediaWiki:Proofreadpage index data config.json. This makes the data centralised, and also readable by search engines that rely on Wikidata. I am proposing the addition here. This will be open to choice of individual editors, so that editors may fill up the Index page data as per current style or opt for importing from Wikidata. Hrishikes (talk) 13:58, 30 January 2026 (UTC)

 Comment Since a lot of editors here are linking scans and Index pages into data items for the work instead of the data item for the edition, I foresee a lot of mismatched information using this approach. On smaller Wikisources, this is less of an issue, but for a large project like en.WS, there will be a lot more potential for mismatched information. At the very least, we would need to agree on what values to use in certain locations: For example, Wikidata tracks editions and not always separate print runs, but here we will often make a distinction between impressions of the same edition issued in different years. --EncycloPetey (talk) 20:18, 30 January 2026 (UTC)

The edition versus print issue is a problem, but that has been sorted out by treating prints as editions. The item linked in my proposal is a reprint treated as edition in Wikidata. Every index requires a separate Wikidata item for this scheme to work, be it edition or print. Currently, index page data can be fetched from the Commons file; those who wish can do so. This Wikidata scheme will just create another option, to fetch data from Wikidata, like what is done in Author pages. Hrishikes (talk) 04:29, 31 January 2026 (UTC)

Bot approval requests

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

Repairs (and moves)

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

See also Wikisource:Scan lab

Index:The aborigines of Australia.djvu

Please finish migrating this to Index:The Aborigines of Australia (1988).djvu and fix the transclusion. It looks like the notice not to edit or proofread the 1888 scan was put there in 2011(!!!!), so this needs to be finished up. SnowyCinema (talk) 09:22, 6 January 2026 (UTC)

Index:Wratten Light Filters Ninth Edition.djvu

Sourcing provenance concern. On discord others suggested an alternate scan from Hathi - "https://babel.hathitrust.org/cgi/pt?id=uc1.31175002603820&seq=1"

I'm all for using better scans with more complete sourcing. ShakespeareFan00 (talk) 10:44, 15 January 2026 (UTC)

Index:File:When Peoples Meet.pdf

wrong title, should be Index:When Peoples Meet.pdf Duckmather (talk) 02:51, 26 January 2026 (UTC)

Moved. -- Beardo (talk) 05:26, 26 January 2026 (UTC)

 This section is considered resolved, for the purposes of archiving. If you disagree, replace this template with your comment. ToxicPea (talk) 01:00, 31 January 2026 (UTC)

Index:When knighthood was in flower bor, The love story of Charles Brandon and Mary Tudor, the king's sister, and happening in the reign of...Henry VIII; (IA cu31924022498913).pdf

Should be moved to Index:When knighthood was in flower or, The love story of Charles Brandon and Mary Tudor, the king's sister, and happening in the reign of...Henry VIII; (IA cu31924022498913).pdf (i.e. to change "bor" to "or"). However, I had already started proofreading it a long while ago, so this'll need an admin Duckmather (talk) 02:53, 26 January 2026 (UTC)

Index:Superseding Indictment, United States of America v. Robert Sylvester Kelly, also known as "R. Kelly".pdf

File:Superseding Indictment, United States of America v. Robert Sylvester Kelly, also known as "R. Kelly".pdf is a redirect file to File:Superseding Indictment, United States of America v. Robert Sylvester Kelly, also known as R. Kelly.pdf. So this index will have to be moved to Index:Superseding Indictment, United States of America v. Robert Sylvester Kelly, also known as R. Kelly.pdf. SnowyCinema (talk) 19:29, 26 January 2026 (UTC)

Index:The_Ten_Princes_-_Ryder_-_Dandin's_Dasha-Kumara-Charita.djvu

Hello, I tried to follow the instructions at Help:Beginner's guide to adding texts and (for uploading) Help:Internet_Archive#ia-upload, which resulted in commons:File:The_Ten_Princes_-_Ryder_-_Dandin's_Dasha-Kumara-Charita.djvu. Then I created Index:The ten princes ryder dandin 27s dasha kumar charita.djvu (clearly a mistake, needs to be deleted) and Index:The Ten Princes - Ryder - Dandin's Dasha-Kumara-Charita.djvu. There are a couple of (possibly related) problems:

• For some reason, the set of pages in the uploaded file here (on Wikisource / Wikimedia Commons) does not match the set of pages shown at the Internet Archive.

• In the page scans, the OCR-ed text is off by one page from the corresponding page.

Could someone help fix this mess? Not sure what I did wrong. Shreevatsa (talk) 07:07, 29 January 2026 (UTC)

@Shreevatsa: this problem sometimes occurs with scans from IA; for each invalid view the text if off by 1 page. The file should be fixed now. • M-le-mot-dit (talk) 09:46, 29 January 2026 (UTC)

Thank you. I see you uploaded a new version of the DJVU file. What was the fix? Shreevatsa (talk) 16:47, 29 January 2026 (UTC)

@Shreevatsa: DjVuLibre tools (djvm, djvused) allow some operations on DjVu files (delete a page, get or set hidden text). • M-le-mot-dit (talk) 19:12, 29 January 2026 (UTC)

Other discussions

Orphaned and ungrouped .jpeg files of music scores

As part of the discussion here about the composer Author:Charles-Marie Widor, I came across a large number of scans of individual pages imported to Wikisource from Commons with separate File namespace pages for each jpeg image, and from my admittedly small sample size, they all seem to be orphaned (unlinked) pages too. The files are well-named; each composition has a unique name, and they all have page numbers, e.g. File:Délivrance ! - chanson de route - paroles de A. Chuquet ; musique de Ch.-M. Widor - bpt6k3852287 (1 of 6).jpg, but making separate Index pages for each image seems silly. Is there a procedure for re-associating an image with its counterparts when it has already been uploaded/imported? —Tosca-the-engineer 21:20, 13 December 2025 (UTC)

Though the example that you link is not in English - so I assume should not be here. I wonder how many of the others are like that. -- Beardo (talk) 22:58, 13 December 2025 (UTC)

Most of the scores don't have lyrics—the example I linked to seems to have been a fundraiser for the war effort (it's from 1916). I was actually thinking of translating it myself. —Tosca-the-engineer 23:12, 13 December 2025 (UTC)

Remember that it will need to be scan-backed on French wikisource before you can do a translation here. -- Beardo (talk) 02:04, 14 December 2025 (UTC)

Maybe the best way to do it (on Commons probably?) is to create a Category for these images? Extremely not sure tho ⸺ googoo0202 (he/him) (talk, contrib) 09:53, 17 December 2025 (UTC)

The images are all categorised appropriately on Commons (grouped into subcats of c:Category:Compositions by Charles-Marie Widor), so I think the Commons categorisation is entirely separate from the Wikisource categorisation. There's approximately 7000 jpegs, so adding them to a category one at a time would be super inefficient, but maybe if I install Cat-a-lot as a user gadget… —Tosca-the-engineer 10:06, 18 December 2025 (UTC)

very sorry about the old scanning bad thinking. maybe you should consider grouping page pdfs into a combined multipage pdf using a publisher program and re-uploading a multipage scan in commons. more pre-work, but easier to set up an index page. --Slowking4 ‽ digitaleffie's ghost 01:16, 10 January 2026 (UTC)

1769 KJV Bible—New Index and Transclusion

Now that I've gotten help in fulfilling my Scan Lab request for a new 1769 KJV Bible Index, I've been thinking that [[Bible (King James)]] is too generic of a page for the transclusion of one single edition of the KJV. I know I've already done most of my transclusion work on that page, but . . . I'm dealing with that later. Anyway, I'd like some discussion on what the best naming scheme could be for individual Bible editions, since the standard doesn't seem to exist yet. The naming should ideally be accurate, descriptive, and future-proof. A title like The Holy Bible is accurate (like, that is the actual title, sans-subtitle), but neither descriptive nor future-proof.

My working idea thus far is "The Holy Bible (King James, 1769; Blayney)". This retains the accurate title, describes enough about the exact edition of the book (version, year; notable editor), and seems to be future-proof; I don't think this title will clash with any similar edition any time soon. If the inclusion of an editor is too odd, it could instead list the publisher, like "The Holy Bible (King James, 1769; Oxford)".

Which seems best? Any additional insight on the order of descriptions or which to include?

—SpikeShroom (talk • contribs) 01:12, 21 December 2025 (UTC)

• Were there multiple, different editions of the King James version of the Bible published in 1769? If not, I don’t see the need for further disambiguation. Similarly, I find it hard to imagine there would be many (if any) different editions of the same version published in the same year. In addition, I prefer Bible over The Holy Bible as the top-level title. TE(æ)A,ea. (talk) 01:23, 21 December 2025 (UTC)

  I do agree that I prefer Bible over The Holy Bible for generic pages for the sake of professionalism, but when it comes to the title of a specific edition, the scan does say The Holy Bible, so I don't see why it shouldn't be included. I'm sure there are Bibles out there just titled Bible or something, and I'd honor those just the same, based on what the scan shows.

  That being said, I'm inclined to agree that the last bit may be unnecessary. "The Holy Bible (King James, 1769)" seems to fit the bill. Or should the description be "(King James Version, 1769)"?

  —SpikeShroom (talk • contribs) 01:41, 21 December 2025 (UTC)

  Technically, it should really be called the "Authorised Version" (AV) rather than "King James Version" (KJV) as King James authorised it for use in the churches of England. However, KJV seems to be the vernacular title now for most editions outside of the UK. Beeswaxcandle (talk) 02:30, 22 December 2025 (UTC)

  Good point. I would use this fact to defer to the Wikipedia article, which primarily calls it the "King James Version," but includes "Authorised Version" and "Authorized Version" (British and American spellings) as redirects. Seems to be a good way to balance comprehensibility and variation.

  —SpikeShroom (talk • contribs) 20:25, 11 January 2026 (UTC)

Misplaced book on French WS

Hello all! We have on the French Wikisource a book that does not belong with us, as it is fully in English and the person who uploaded it long ago didn't embark on a translating project. We plan on deleting it per policy but wanted to give you a heads-up if anyone wants to transribe this delightful treatise Of the imagination, as a cause and as a cure of disorders of the body; exemplified by fictitious tractors, and epidemical convulsions. The corresponding file is on Commons but you may want to make use of the (admittedly few) already transcribed pages

Wikisourcely yours, Susuman77 (talk) 22:42, 29 December 2025 (UTC)

Hello! I think you can largely go on and delete it, as far as I can see. :) Cheers, — Alien  3
3 3 22:49, 29 December 2025 (UTC)

Noting for the record: the file on Commons is incomplete and missing about half the text anyway —Beleg Âlt ^BT (talk) 16:10, 30 December 2025 (UTC)

I may have found a complete scan in the National Library of Medicine digital collection. The pdf has 48 pages instead of 44, and the title page has different marks, but I just get a 502:Bad Gateway error when I try to download it, so I'm not sure. —Tosca-the-engineer 16:48, 11 January 2026 (UTC)

Double disambiguation pages

What is the community consensus regarding doubly-disambiguated disambiguation pages (i.e. disambiguation pages that are themselves disambiguated)? For example, Henry IV (Shakespeare) lists works by Shakespeare titled "Henry IV".

In my opinion, such pages are redundant; all works titled "Henry IV" by Shakespeare are already listed at both Henry IV and at Author:William Shakespeare (1564-1616). As such, Henry IV (Shakespeare) should redirect to one of those two locations (possibly with an anchor to the relevant section of the page).

We used to have a lot of double-disambiguation pages, but over the years they have all been merged into their parent pages. However, a few more have cropped up in the meantime. I've created a category for them here: Category:Double disambiguation pages. —Beleg Âlt ^BT (talk) 15:03, 30 December 2025 (UTC)

Probably shouldn't exist IMO, though I suspect a certain number of them should really be versions pages. — Alien  3
3 3 15:38, 30 December 2025 (UTC)

Of the pages we currently have, two are listings of editorials by a specific author, and this is improper use of a disambiguation page. Disambiguation should never be a list by the type of work. I agree that the other two seem superfluous --EncycloPetey (talk) 15:39, 30 December 2025 (UTC)

• These are useful, in certain situations, which is why I have created some of them in the past. Henry IV is a great example—needing to distinguish between the two plays of Henry IV is a far more likely use case than needing to distinguish between multiple different works which happen to have that title, two of which happen to be famous plays. The two lists of editorials are proper, because they are lists of works entitled “Editorial” by different authors. In addition, it would be unduly cumbersome to list several different short “editorials” together with all of the author’s other works, and it would be similarly cumbersome to have this list at “Editorial” or some other generic page. Thus, the middle ground, which avoids both of these cumbersomeness issues. TE(æ)A,ea. (talk) 02:44, 31 December 2025 (UTC)

  Would an anchored section not solve the issue just as easily, such as Henry IV#Shakespeare? (compare Sonnet#William Shakespeare) This removes the cumbersomeness without introducing redundancy, and also better follows our naming conventions for disambiguation pages (i.e. the title of the page is the title of the works being disambiguated). —Beleg Âlt ^BT (talk) 14:45, 31 December 2025 (UTC)

Having four entries doesn't seem a big issue one way or the other. Personally, I would like to see more examples to see whether they are useful or are becoming a problem and a hindrance. MarkLSteadman (talk) 02:53, 31 December 2025 (UTC)

There used to be a lot more. I don't think they are useful, but I don't think they are a problem or hindrance either. They're just redundant. —Beleg Âlt ^BT (talk) 14:38, 31 December 2025 (UTC)

I would say we should delete these, and move their contents to Henry IV. We want one disambiguation page per keyword as much as possible. SnowyCinema (talk) 04:18, 31 December 2025 (UTC)

The information is already also listed at Editorial and Henry IV and I don't think those pages are too cumbersome. I think it would be better to eliminate these pages as unnecessary - though to accept that such a page might be useful if the parent disambiguation page does become too cumbersome. -- Beardo (talk) 04:57, 31 December 2025 (UTC)

I think this specific one is useful. Where else should we link "Henry IV" from Page:Shakespearean Tragedy (1912).djvu/22 and similar? These cannot be linked to Henry IV. Anchor does not solve it, as the readers would be taken to a page full of other irrelevant works which makes it confusing for them. --Jan Kameníček (talk) 16:12, 31 December 2025 (UTC)

A different example. The version page Austria and Europe (The Bohemian Review, 1918) was created per Wikisource:Scriptorium/Archives/2024-08#Serialized works in periodicals (voting). As such it is also categorized in Category:Serialized works. Thus it cannot be included in Austria and Europe, as it 1) would be against the accepted policy and 2) could not be properly categorized. --Jan Kameníček (talk) 19:35, 31 December 2025 (UTC)

I don't understand—Austria and Europe (The Bohemian Review, 1918) is an edition, not a disambiguation page, and it is included among the editions listed at Austria and Europe —Beleg Tâl (talk) 01:06, 1 January 2026 (UTC)

True, sorry for the confusion. --Jan Kameníček (talk) 01:11, 1 January 2026 (UTC)

I personally don't have a problem with disambiguating something like Sonnet as it grows and if there starts to be large numbers of 100s of Sonnets by Poet X, moving them to there own subpage or breaking it up into subpages by author last initial or something. MarkLSteadman (talk) 20:53, 4 January 2026 (UTC)

User:333Bot and preventing tagging for deletion nominations

Noting here for general awareness (I've only now belatedly documented it at the bot's userpage, though it's been possible for a while): When you need for some reason or other to make the bot not tag a page listed for deletion, add <!--notag--> to the page in question (avoids having to revert again and again). — Alien  3
3 3 20:26, 1 January 2026 (UTC)

Is there a way to decrease the space between the author's name and his title?

Is there a way to decrease the space between the author's name and his title to more closely match the original? See: The Philadelphia Inquirer/1974/6 in Family on Trial in Trooper Battle. RAN (talk) 20:46, 1 January 2026 (UTC)

I tried something. As a general principle, don't use multiple {{c}}s consecutively. Then you can for instance use a {{br}} instead of a paragraph break. — Alien  3
3 3 20:59, 1 January 2026 (UTC)

• Thanks! Just what was needed. --RAN (talk) 22:31, 1 January 2026 (UTC)

Should I remove the "sic" where there is an error, or should the explanation be restored?

See: "Edward Schneider [sic]" at New York Daily News/1940/12/24/Cheated Death In Air Battles, Dies In Crash. Should we remove the "sic" pointing out an error, or should the explanation of the error be restored? Having an error pointed out and not explaining the error is confusing. Which is best practices? The person who removed it wrote: "the information is partly included in the header and author's page, and partly belongs to Wikipedia, not here". I am not sure that reading a Wikipedia biography will help people work out what the error is in the article. We shouldn't expect people to read a biography to figure out why a name or a date is incorrect in a newspaper article. I always assumed the "notes" section, was for … notes. RAN (talk) 21:00, 1 January 2026 (UTC)

Our text should reflect what the original said. If you want to point out an error, you can use {{SIC}} with the correct information. -- Beardo (talk) 21:05, 1 January 2026 (UTC)

• You are stating what I already know. The text already "reflects what the original said", I asked about the "notes=" portion of the header. I assumed it was for adding notes about the text. If it isn't for housing notes, perhaps change the name, or eliminate it. This isn't a matter of typed word versus presumed word, it is more complicated. --RAN (talk) 22:28, 1 January 2026 (UTC)

  Did the original text included [sic] ? -- Beardo (talk) 22:34, 1 January 2026 (UTC)

The documentation for the {{Header}} template states that the Notes field is for "notes to explain the work, to add context, or to impart concise information that adds value to the reader; for example, use of {{listen}}". Thus, it's not for explanations about misspellings in the text itself. Beeswaxcandle (talk) 18:19, 2 January 2026 (UTC)

• This is not a misspelling, it is an error of fact. My inquiry was about the removal of the note explaining an error of fact in the article. The note read: His legal name was "Eddie Schneider" but some sources incorrectly formalized it to "Edward Schneider". He wrote in Look Out, Lindbergh - Here I Come in 1931: "because people are always asking me, my name is really Eddie: I was christened that way. It isn't very dressy, but it serves the purpose." It certainly "add[ed] context [and] impart[ed] concise information that add[ed] value to the reader." Shouldn't it be "value for the reader" and not "value to the reader". The reader is not now more valuable, the text is now more valuable. I think it was removed for esthetic reasons, not because it did not add value for the reader. --RAN (talk) 12:32, 4 January 2026 (UTC)

The original text does not have any "[sic]" note included, so neither should our transcription. If you feel that the error should be pointed out, you can use the template {{SIC|Edward|Eddie}}. However, there is a little problem that it is also linked, which causes that the dots of the tooltip under the text are not displayed. This can be worked around with placing <templatestyles src="Template:Tooltip/styles.css" /> somewhere at the top of the text. --Jan Kameníček (talk) 21:30, 2 January 2026 (UTC)

• I temporarily restored the explanation of the error of fact in the notes section and also added it to the sic template. Which is less intrusive? I don't expect readers to research why the article used the wrong name, when a concise explanation can be included. We only need one version, the one in the sic template does not allow a link to his biography. I want to thank Jan Kameníček for the amazing formatting of the entry. --RAN (talk) 12:47, 4 January 2026 (UTC)

  I think the SIC template is enough, we usually do not use the notes in the header for explanation of such nuances. One of the reasons is that unlike Wikipedia our small community does not have enough volunteers who could keep checking accuracy and sources of such information. Instead, we provide links to Wikipedia articles in "sister projects" section of the headers, where anything can be explained in detail and where the community has well established fact checking processes. --Jan Kameníček (talk) 13:01, 4 January 2026 (UTC)

• We only need one, but the section is for "notes to explain the work, to add context, or to impart concise information that adds value to the reader", so maybe its time to rewrite the definition of notes=, or eliminate the notes= section. --RAN (talk) 14:10, 4 January 2026 (UTC)

  The notes section is for information adding context for the whole text, not individual bits of information contained in the text. It can bear publication information or details about the print history that can't be otherwise easily encoded in the header, such as indicating a volume is the 1927 printing of the 1922 edition. Or that the text is the US / UK edition of a book published in both countries. Or that a particular poem was previously published in another location, or that the following edition of that poem contains a proem added by the editor. So the notes section serves a very useful function for some publications. --EncycloPetey (talk) 14:27, 4 January 2026 (UTC)

 Comment I just want to add that a good place for this type of commentary would be the work's talk page —Beleg Tâl (talk) 19:33, 4 January 2026 (UTC)

Strange things in the Wikisource:Scriptorium/Help/Archives/2025

Something strange is happening at Wikisource:Scriptorium/Help/Archives/2025, where some archived topics seem to have disappeared. If you look at the previous revisions, you may find there e.g. the topic "Deceased Wikisource contributors page?". Then, some new topics were added by the Wikisource-bot, and the following revision does not contain that topic anymore. The strange thing is that the diff does not show any deletions from the page. Any explanation? -- Jan Kameníček (talk) 00:23, 3 January 2026 (UTC)

• Jan Kameníček: I have fixed it. Arcorann’s comment in the “footnotes, endnotes, and refs in general” section had <ref> without <nowiki>. The next </ref> happened to be in ShakespeareFan00’s comment in the just-now-archived “Page:A voyage to Abyssinia (Salt).djvu/359 &Page:A voyage to Abyssinia (Salt).djvu/360” section. By archiving this section, it closes the <ref>, which incidentally hides a hundred or so other sections. TE(æ)A,ea. (talk) 00:39, 3 January 2026 (UTC)

  Oh, that is funny :-) Thanks for finding the problem out and fixing it! --Jan Kameníček (talk) 00:52, 3 January 2026 (UTC)

Should Versions pages have license tags?

Should Versions pages have license tags, such as {{PD-US}}, or should that only be done in the actual transcribed versions they list? Example: The Stolen Body SnowyCinema (talk) 04:37, 4 January 2026 (UTC)

• They should not; license tags only make sense at the level of a published volume (as they are currently implemented, anyway). TE(æ)A,ea. (talk) 04:54, 4 January 2026 (UTC)

  Agree. Each listed volume may include additional material that would not fall under a license tag applied at the version page level, which would be confusing. This concern applies even more strongly to translation pages. --Jan Kameníček (talk) 13:44, 4 January 2026 (UTC)

They should, since they represent the intellectual work, and outside the US, it is the intellectual work that enters public domain based on the date of the author's death. Only in US law is the copyright date tied to date of publication and thus a specific edition. It also permits a shortcut with translations, allowing us in a central location to say that the original is in public domain, rather than restating that fact on each translation. --EncycloPetey (talk) 14:21, 4 January 2026 (UTC)

This can be confusing to readers, who may expect that the licence given at the version page applies to all the volumes listed there. But that often is not true, because the volumes besides the work itself may include illustrations by different authors, prefaces, introductions, notes, footnotes etc. The volumes can also have different editors. As a result each of the volume often falls under a different copyright license not only in the US, but outside the US too. For this reason it makes much more sense to give the copyright tags only with the actual transcribed versions. --Jan Kameníček (talk) 19:40, 4 January 2026 (UTC)

If someone if confused, then they're not reading the full tag on the versions page: "This work was published before January 1, 1931, and is in the public domain worldwide because the author died at least 100 years ago. Translations or editions published later may be copyrighted." Our license on the versions pages makes that point clear.

And those individual license tags on particular volumes pertain to the additional material in the specific copy, such as illustrations, front matter, notes, and the like, not to the base work. The license on such editions are not for the work, but for the additions to the specific copy. The purpose of tagging the versions page is to give the license for the underlying work. The license on one of our editions does not provide that information. --EncycloPetey (talk) 19:52, 4 January 2026 (UTC)

Well, e. g. {{PD-US}} template and others do not say anything about later editions as you quoted. There are many different license tags. In some cases the license tag that would be given at a version would not apply to any of the versions listed. And that can be confusing for some readers no matter how precise the message would be. If each version has its own copyright tag, having one more at the version page is imo quite redundant. --Jan Kameníček (talk) 20:17, 4 January 2026 (UTC)

If our license templates are inadequate, then we should improve them. Inadequacy of our templates is not a rationale for making general policy decisions. We can always improve the templates. --EncycloPetey (talk) 21:27, 4 January 2026 (UTC)

Agree that license templates can be improved. However, it would not change my main point: it is not much use to put there a license tag that may not apply to the listed items anyway. --Jan Kameníček (talk) 21:32, 4 January 2026 (UTC)

That doesn't help itself when the versions page itself lists versions that are copyrighted, especially if they are heavily revised versions of the same work as opposed to just new material, or have different publication dates. If the first edition is published 101 years ago and a much revised and a much expanded edition is published 5 years later, and that is the version transcribed, which publication date to stick in "This work"? This is common with say textbooks where later editions can have many new chapters, e.g. Mashall's Principles between its first edition in 1890 to the ninth in 1960. MarkLSteadman (talk) 20:19, 4 January 2026 (UTC)

E.g. isting "This work was published before January 1, 1931, and is in the public domain worldwide because the author died at least 100 years ago. Translations or editions published later may be copyrighted" on a page that only lists say the 20th (ed. died 1964) and the 24th (ed. died 1960) of Gray's Anatomy. Note the 43rd edition is coming out this year. MarkLSteadman (talk) 20:46, 4 January 2026 (UTC)

We shouldn't be listing editions that are copyrighted, since copyrighted items are beyond scope, without tagging them using a clear line tag or template. --EncycloPetey (talk) 21:24, 4 January 2026 (UTC)

• Non-U.S. copyright is irrelevant to enWS, and should not be a concern whatsoever. We have a generic disclaimer to that effect. Your claim about to what copyright adheres is also incorrect; in other countries, just as in the United States, it adheres to individual editions of works. The different is just when the copyright expires, not its existence. Even looking to other countries’ copyright laws, different editions of the same work may have different copyright terms, such as where later editions have different (and later-deceased) illustrators or editors. In addition, the license tag on a versions page has no meaning; after all, a versions page has no text of the work in question, just a list of different copies of that text. There is nothing to license, so a license tag is pointless. Now, translations pages are different from versions pages (which was the original topic). However, those are even more inappropriate; after all, we do not host the original-language version, and thus have nothing to license. As for your later statement, “The license on such editions are not for the work, but for the additions to the specific copy”, this is also incorrect. For any individual work, the license tag covers the copyright of the entirety of that work, which includes the residual copyright from an earlier edition and the new copyright of that edition. We cannot host a later, public-domain edition of a work if an earlier edition, the basis for that later edition, is still copyrighted. You also have previously stated that listing copyrighted editions is acceptable. TE(æ)A,ea. (talk) 01:14, 6 January 2026 (UTC)

"Only in US law is the copyright date tied to date of publication". This is false as even a basic look at https://cdn.nationalarchives.gov.uk/documents/information-management/crown-copyright-flowchart.pdf and https://cdn.nationalarchives.gov.uk/documents/information-management/non-crown-copyright-flowchart.pdf shows. MarkLSteadman (talk) 02:51, 6 January 2026 (UTC)

Yet all of our license templates state that "This work is in public domain ..." without any mention of editions. --EncycloPetey (talk) 18:35, 6 January 2026 (UTC)

This is caused by the fact that we sometimes use the expression "work" generally, meaning all its versions, and sometimes in a narrower sense, more or less synonymous to "edition". The text of the templates used under the editions speaks about "work" and "longest living autor of the work", but actually refers not only to the expired copyright of the author of the work, but also of the illustrator, editor, author of the preface/introduction/foreword, author of the notes..., all of which are connected with the specific edition only and not with the work in the general sense. And if the same author publishes a new version of the same "work", with some changes of the text, the new and different text of the template will still speak about "work" again, although it would in fact refer to the new edition only. --Jan Kameníček (talk) 19:29, 6 January 2026 (UTC)

Also an artifact of our history of having unsourced / second-source text. We see this where we replace unsourced / secondary-source "works" in place with proper defined "editions." Without proper edition information we don't things like the exact publication date of an edition / reprint so it tends to get blurred. MarkLSteadman (talk) 21:43, 6 January 2026 (UTC)

Given the point made several times in this discussion that the licensing is confusing, should be improve the template wording? --EncycloPetey (talk) 22:00, 6 January 2026 (UTC)

If so, it should probably be done in a new discussion. --Jan Kameníček (talk) 22:19, 6 January 2026 (UTC)

If that's the case, then I would say any decision in this discussion should be pended. Our license wording currently says ""work", but we're arguing that "work" pages should not have the license. The two issues are very thoroughly entwined. --EncycloPetey (talk) 22:42, 6 January 2026 (UTC)

I do not think so, if majority discussing contributors think that copyright templates should not be used on version pages, they simply should not. So unless the request for pending the decision is supported by more contributors, I do not think it is really necessary. I personally do not see the wording of the templates so problematic that it really needs any urgent adjustment, and at this moment it is not certain that such adjustments will take place at all. Or the adjustments might take a long time, but they are not an obstacle for stopping using the templates at version pages if the community decides so. --Jan Kameníček (talk) 23:04, 6 January 2026 (UTC)

From WS:WD, "Work items should hold information true to all editions, versions, manifestations, or implementations of the work." Very clearly copyright info does not belong on WD for work items if that is your question. This is clearly documented on that page. We could cleanup our terminology "Works on Wikidata are split into two data items: Work items: For the work in general. Edition items: For each specific version or edition." but also this has been true for ages...

MarkLSteadman (talk) 23:39, 6 January 2026 (UTC)

I'm not sure how that page is particularly relevant to the discussion here, as (a) it has no counterpart at Wikidata, and (b) it is neither a policy nor community-accepted guideline for Wikisource. Even if Wikisource adopted the page as a policy or guideline, the page concerns activity on Wikidata, and so it would carry no weight there, as Wikidata is a separate project from Wikisource. I personally agree with what it says there, but the context is what belongs on Wikidata, not what belongs on Wikisource.

I also note that, among the "invariant" things to be listed on the work data item are the title and author, but even those values can change from edition to edition, not only for textbooks, but also for translations, and for UK/US editions. --EncycloPetey (talk) 00:17, 7 January 2026 (UTC)

If it is not relevant to discussions about what we think nominate it for deletion or propose placing a disclaimer on it that it is not relevant to anything, e.g. some innocent editor following it and getting slapped for doing ti wrong because unconveyed reasons. My point is that it isn't just my coming out of thin area (just like a court might site books about topic X, saying it's not law, not relevant isn't the point). It provides evidence of what we think belongs on the page. MarkLSteadman (talk) 02:54, 7 January 2026 (UTC)

And we have a specific policy statement on resolving exactly this title question anyways on the versions page policy. I am happy to propose adding similar language for author or leaving blank (like anonymous works). Problem solved. Or are we going to start complaining that some untitled works don't have titles so we shouldn't have titles for pages? 03:01, 7 January 2026 (UTC) MarkLSteadman (talk) 03:01, 7 January 2026 (UTC)

My general point is that we've drifted into discussing something not relevant to the current thread using a page that applies only practice on another site. Note that we have no versions policy; Wikisource:Versions has never been made policy. -EncycloPetey (talk) 12:11, 7 January 2026 (UTC)

You've missed the context and jumped to deletion as an option. The section you've quoted opens with "Works on Wikidata are split into two data items..." so it's clear from context that the section is discussing practices on Wikidata, not on Wikisource. We don't delete pages simply because you've applied them out of context. If someone quoted a poem here out of context, that doesn't mean we ought to delete it. Instead, we should acknowledge that the quote was taken out of context, not jump to deletion.

And in this instance our page is at odds with recommendations on Wikidata itself. See d:Wikidata:Property proposal/copyright status. When the copyright status property on Wikidata was proposed and set up, it was explicitly applied to creative works, literary works, etc., and not to editions. The current type constraints listed for d:Property:P6216 reinforce that the property is intended for works and makes no mention of editions. --EncycloPetey (talk) 12:16, 7 January 2026 (UTC)

I don't really see that versions pages need licenses. The line for where editing a work gains copyright is unclear. US law requiring a copyright notice forced an editor to at least declare that there was new copyright, if they didn't have to be specific. An abridgment certainly would, and possibly, if the underlying source text was complex enough, forming a new distinct text with creative choices for inclusions and omissions. (The Frankenstein that underlies PG's edition apparently merges both editions, which would probably qualify.) As others have said, nonfiction books that have run through a number of editions get complex enough that one license doesn't really help. The Elements of Style has a 1935 edition by a new author, a 1956 edition by a new author (which I don't think is derivative of the 1935 edition), and John Woldemar Cowan wrote a 2006 revision of the 1918 original, released under the CC-BY-SA. They're versions of the same work, but come under different licenses.--Prosfilaes (talk) 00:40, 6 January 2026 (UTC)

Action to take

Based on the above discussion, I'm going to start this "action to take" thread on the assumption that no major new issues will be rasised, though acknowledging that the above discussion has been over only three days, and so new ideas might enter that discussion.

Assuming therefore that we intend to not have license tags on versions pages, and considering that user confusion was raised as an issue: Do we want to (a) simply remove all license templates from versions pages, and leave no information in its place; or (b) develop a new template for versions pages (not a license) that advises roughly what we've said above: that license information is placed on the pages of individual editions rather than the general page, since the text and images, authors and editors, can vary from edition to edition, affecting the copyright status. --EncycloPetey (talk) 12:32, 7 January 2026 (UTC)

Brace2 display issue

Page: namespace

Mainspace

I am getting different display of {{brace2}} apparently depending upon namespace. At right are images showing the same section of text as displayed in the Page namespace and Mainspace. In Mainspace, the brace is displayed at roughly half the height, even though it is the same content.

The locations are Page:George Bernard Shaw - The Apple Cart.pdf/81 in Page; and The Apple Cart/Act I#45 in Main. --EncycloPetey (talk) 14:16, 4 January 2026 (UTC)

@EncycloPetey: I remark that the problem occurs only with layouts 2 and 4, not 1 and 3. • M-le-mot-dit (talk) 15:22, 4 January 2026 (UTC)

But not consistently so. The same contextual syntax (and layout) is used on Page:Coriolanus (1924) Yale.djvu/12 and Coriolanus (1924) Yale/Text, but on those pages the display of the brace is consistent. --EncycloPetey (talk) 15:28, 4 January 2026 (UTC)

@EncycloPetey: In fact, the brace size depends on the width of the cell. That's why is seems to depend on the layout. You may see with layout 1 how the brace height changes with a narrower window. • M-le-mot-dit (talk) 16:03, 4 January 2026 (UTC)

That is quite unpleasant, and it must be some new bug, because I did not experience it in the past. Is there any way to work around it? --Jan Kameníček (talk) 20:00, 4 January 2026 (UTC)

@Jan.Kamenicek I do not believe this a new bug, as I have experienced it for a while (unless your definition of new was the past year or two at least). For whatever reason, layout or otherwise, if the cell containing the brace2 does not have sufficient width to display the full height brace, then the entire brace shrinks. As in @M-le-mot-dit's edit, one workaround is just to fix the cell width using {{ts|width:Xem}}. Regards, TeysaKarlov (talk) 22:22, 4 January 2026 (UTC)

Game books

Consider the Consequences!, whose transcription I have just completed, is a "game book" (a kind of "chose your own adventure"—in fact, reputedly the first ever).

I have put it into Category:Games, for now, but do we have one that is more precise? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:38, 4 January 2026 (UTC)

Thank you. I don't know the answer to your question, but I have also added it to Portal:Games. By the way, I think for your second link, you meant w:Consider the Consequences!. -- Beardo (talk) 01:16, 5 January 2026 (UTC)

We don't appear to have one that's more precise at the moment, but if we get more books of this type we can always create one later! —Beleg Âlt ^BT (talk) 14:35, 5 January 2026 (UTC)

rh and rvh

If a page has been created using the template rh, is there any advantage in changing it to use rvh ? -- Beardo (talk) 02:34, 5 January 2026 (UTC)

Not as far as I know. Just different ways of working. — Alien  3
3 3 11:48, 5 January 2026 (UTC)

The difference is that rvh is dynamically making a display decision based on the page number (in the scan?) so I would think that in a proofread page, we'd rather keep the rh if it already exists. We sometimes need to modify scans to insert or remove pages, and rvh in such a situation could lead to reversing the header format across all affected pages. --EncycloPetey (talk) 12:25, 7 January 2026 (UTC)

Mediawiki request

Could an administrator please import the MediaWiki:Cite link label group-lower-alpha from Mediawiki? This will allow us to create ref-tag references without numbers – specifically, <ref group="lower-alpha">Text</ref> would produce ^[a]. This would be helpful. Thanks, Cremastra (talk) 01:37, 7 January 2026 (UTC)

Per policy (Help:Footnotes and endnotes) our style here is to use numbered footnotes, regardless of what the style the original book used. This is why this label group hasn't been imported. Beeswaxcandle (talk) 09:12, 7 January 2026 (UTC)

I see, thank you.

How would you recommend transcribing footnotes as seen on this page, where there is one set of regular numbered footnotes with the number in-text and a second set of unnumbered reference footnotes without in-text anchors? I've transcribed the first as regular footnotes and the second as intext "[n #]" anchors but I feel there must be a better way to do it. Cremastra (talk) 17:46, 7 January 2026 (UTC)

i'm afraid admin minds are made up here. it stops work on the rare occasions there are two sets of footnotes, numeric and alpha. a shame, but there are worse practices. --Slowking4 ‽ digitaleffie's ghost 01:37, 10 January 2026 (UTC)

Template:Featured download

I don't think that this template should be included within mainspace pages outside of Main Page, like it has sometimes before. Here's a complete list of all 5 pages that use this template that way:

1. Some Mistakes of Moses
2. Love and Freindship and other early works
3. The Princess Pourquoi (collection)
4. A Puritan Bohemia
5. The story of saiva saints

It seems a bit redundant since the Download button at the top of every page is already there. SnowyCinema (talk) 08:12, 8 January 2026 (UTC)

I agree. I don't recall any of these five being a featured work (they're certainly not in the category), so using this template on them is misleading at best. Beeswaxcandle (talk) 07:32, 9 January 2026 (UTC)

Since a bit of time has passed, Done—removed these instances, as that template is really supposed to only be used on {{Featured text}}, for the Main Page, not on work front matters. SnowyCinema (talk) 00:17, 20 January 2026 (UTC)

Murder on the Links disambig

Murder on the Links is a version page, with:

• The Murder on the Links, published by Berkley Books in 1984.
• Murder on the Links (1985), published by Bantam Books in 1985.

Shouldn't The Murder on the Links be named The Murder on the Links (1984)? Or is there some other naming convention at play here? Eievie (talk) 06:59, 9 January 2026 (UTC)

Yes, it should be listed as that. SnowyCinema (talk) 07:03, 9 January 2026 (UTC)

It could be listed that way. Although if the 1984 edition is the only one published with "The" in the title, then the current disambiguation is sufficient. There is also the possibility of more than one 1984 edition, in which case adding "(1984)" is insufficient disambiguation. --EncycloPetey (talk) 13:21, 9 January 2026 (UTC)

The Wikipedia article uses "The" and shows a couple of early dust-jackets that both have "The". The page at agathachristie.com also shows a cover with "The". It looks to me as if the 1985 version might be the outlier. -- Beardo (talk) 17:06, 9 January 2026 (UTC)

Tech News: 2026-03

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

Weekly highlight

• The Wikimedia Foundation has shared some guiding questions for the July 2026–June 2027 Annual Plan on Meta and Diff. These focus on global trends, faster and healthier experimentation, better support for newcomers, strengthening editors and advanced users, improving collaboration across projects, and growing and retaining readership. Feedback and ideas are welcome on the talk page.

Updates for editors

• As part of the current work of Community Tech team on the Multiple watchlists project, the display of EditWatchlist will be updated as a first step towards multiple watchlists. Additionally, the pagination on Search will be updated too, as a part of the work on the Revamp pagination / page navigation wish. [1]
• The Global Watchlist is a MediaWiki extension that lets you see your watchlists from different wikis on the same page. It was recently updated to look more like the regular Watchlist, such as preparing it for temporary accounts in IP masking (including rerouting user links to contributions pages), making page titles bold, and opening links in edit summaries and tags in new browser tabs. [2][3][4][5]
• View all 28 community-submitted tasks that were resolved last week. For example, the issue where global blocks did not have the option to disable sending emails, has now been fixed, and will be available for use in the week of January 13. [6]

Updates for technical contributors

• The VisualEditor citation tool and Reference Previews now support "map" as a reference type. [7]
• Detailed code updates later this week: MediaWiki/MediaWiki

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

MediaWiki message delivery 19:33, 12 January 2026 (UTC)

Template:Copyvio/e and Module:Header

I recently made this edit to Module:Header in the hopes that this added logic would make {{Copyvio}} automatically close divs, if {{Copyvio/e}} or {{Cv/e}} is not already in the page. By the way, my changes work in terms of what shows up in the HTML DOM—if you inspect the page, you will see that {{copyvio}} templates, for example at Continuation of Comprehensive Mirror Aid to Governing (does not have {{cv/e}} yet) do in fact get closing divs.

However, even so, this Lua code does not stop Special:LintErrors from reporting a linting error for these pages. In missing-end-tag, you can still see Continuation of Comprehensive Mirror Aid to Governing listed, even though the Lua code is actually fixing this in the DOM.

So, is the problem that Special:LintErrors doesn't detect errors that are resolved through Lua modules? Pinging ShakespeareFan00, as I recently discussed this with him. SnowyCinema (talk) 23:15, 12 January 2026 (UTC)

Best practice question: source images on newspaper transcriptions

Question: Is it acceptable or discouraged to display a source image inline on a main-namespace text page when that image was the basis for the transcription?

Hello all, I’m very new to Wikisource and would appreciate community guidance on best practice. I understand that Wikisource generally emphasizes clean, readable text pages, and that scans are typically accessed via Index or File pages. At the same time, I have noticed that some main-namespace works do include source images inline for verification and historical context.

In my case, I have transcribed a public-domain newspaper article directly from a clipped image of the original front page. The text page in question is:

https://en.wikisource.org/wiki/Through_Southern_States_(Galveston,_Texas,_July_26,_1901)

The corresponding source image is hosted on Wikimedia Commons here:

https://commons.wikimedia.org/wiki/File:Harmony_News_August_8_1901_front_page.jpg

I would welcome any honest feedback after looking at the text page alongside its source image. Because this is a newspaper front page, where layout, headlines, and surrounding content are part of the historical source, I am trying to understand whether showing the clipped source image on the main text page is considered acceptable practice, assuming the image is not decorative and was the basis for the transcription.

My primary concern is reader clarity, as many readers may not intuitively know to look to a Talk or Index page to view the source image.

Thank you very much for your time and guidance. SueRostvold (talk) 15:38, 13 January 2026 (UTC)

Quoting from: WS:Image guidelines: Inappropriate images are those which are not part of the original document. Source of the work, including the scan, can be given at the talk page, or alternatively (and preferrably), it can be used for scanbacking the work per Help:Proofread. In fact, when we have the scan but the article is not scanbacked, {{No scan}} template should be put to the top of the page. But the scanned image of the newspaper page does not belong to the main namespace to illustrate the transcribed text of the article.

Let's imagine also the following situation: We can have an article which was originally illustrated with several images. We transcribe the article and add the images there too, and with them also the image of the scanned article that contains the same text and the same images too? I do not thing that would be a good practice, we should follow the current guideline: only images illustrating the original article (if there are such) should be present in the mainspace. --Jan Kameníček (talk) 20:54, 13 January 2026 (UTC)

Further to the above—using an Index page to link a scan to the work is the standard procedure for adding texts to Wikisource; all works added to Wikisource should be linked to an Index page wherever possible. As such, I have backed this work against Index:Harmony News August 8 1901 front page.jpg. —Beleg Âlt ^BT (talk) 21:07, 13 January 2026 (UTC)

By the way - isn't this better put as a subpage of Harmony News ? -- Beardo (talk) 02:44, 15 January 2026 (UTC)

I have no idea. But I am sure others do. :) SueRostvold (talk) 02:57, 15 January 2026 (UTC)

Thanks for making that index/source page for me. I appreciate it. SueRostvold (talk) 02:56, 15 January 2026 (UTC)

Navigation broken in Page namespace

I am no longer seeing Forward, Next, or Source tabs in the Page namespace. This is true not just here but in Greek and Spanish Wikisource as well. Am I the only person experiencing this issue, or is this affecting other users too? --EncycloPetey (talk) 19:30, 14 January 2026 (UTC)

@EncycloPetey Not just you. I have been having the same issues. Regards, TeysaKarlov (talk) 19:54, 14 January 2026 (UTC)

Are you using a skin? I see them with the default skin but not with others. MarkLSteadman (talk) 20:33, 14 January 2026 (UTC)

I am using Vector legacy. --EncycloPetey (talk) 20:40, 14 January 2026 (UTC)

I noted that this is an issue with the Monobook skin. The beta ProofreadPage feature retains the next and previous buttons. But same issue here. Mathmitch7 (talk) 20:51, 14 January 2026 (UTC)

I've posted a notice at the Mediawiki Village Pump. --EncycloPetey (talk) 19:48, 14 January 2026 (UTC)

I still see the previous and next arrows, the Image tab and the Index arrow on several pages that I have looked at. (I am using Chrome on a laptop, in case that makes a difference.) -- Beardo (talk) 20:14, 14 January 2026 (UTC)

I am using Firefox on a desktop. --EncycloPetey (talk) 20:41, 14 January 2026 (UTC)

• This was filed by Jdforrester-WMF as a "Unbreak Now!" bug on phabricator: T414630. Cheers! Mathmitch7 (talk) 20:56, 14 January 2026 (UTC)

  This is fixed as of 2026-01-14 22:35 (UTC). Premature deployment of an untested patch. Mathmitch7 (talk) 19:31, 15 January 2026 (UTC)

Thank You for Last Year – Join Wiki Loves Ramadan 2026

Dear Wikimedia communities,

We hope you are doing well, and we wish you a happy New Year.

Last year, we captured light. This year, we’ll capture legacy.

In 2025, communities around the world shared the glow of Ramadan nights and the warmth of collective iftars. In 2026, Wiki Loves Ramadan is expanding, bringing more stories, more cultures, and deeper global connections across Wikimedia projects.

We invite you to explore the Wiki Loves Ramadan 2026 Meta page to learn how you can participate and sign up your community.

📷 Photo campaign on Wikimedia Commons

If you have questions about the project, please refer to the FAQs:

• Meta-Wiki
• Wikimedia Commons

Early registration for updates is now open via the Event page

Stay connected and receive updates:

• Telegram channel
• Mailing list

We look forward to collaborating with you and your community.

The Wiki Loves Ramadan 2026 Organizing Team 19:45, 16 January 2026 (UTC)

Physique magazines

Hello, I'd like to ask for guidance regarding the suitability of certain historical US magazines for Wikisource. Magazines such as Physique Pictorial, Young Adonis, and Grecian Guild Pictorial were published in the United States in the 1950s–1960s and are considered to be in the public domain under PD-US-no notice. Scans of many issues are already available on Wikimedia Commons (e.g. File:Young Adonis.pdf, File:Physique Pictorial Vol 12 No 1.djvu).
Are the contents of such magazines acceptable for transcription on English Wikisource? Are there any specific policies or community guidelines on en.Wikisource regarding erotic/adult (18+) material? PolskiChłopak (talk) 21:05, 18 January 2026 (UTC)

@PolskiChłopak: Hi, and welcome to Wikisource. To answer your question, there is no rule against NSFW or 18+ material being hosted at Wikisource. We have for example pornographic films and erotica here already. The only concern would be copyright and the nature of publication, etc., which magazines like these should pass as you noted. SnowyCinema (talk) 21:07, 18 January 2026 (UTC)

Tech News: 2026-04

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

Updates for editors

• The tray shown on Special:Diff in mobile view has been redesigned. It is now collapsed by default, and incorporates a link to undo the edit being viewed, making it easier for mobile editors and reviewers to take action while keeping the interface uncluttered. [8]
• The Global Watchlist lets you view your watchlists from multiple wikis on one page. The extension continues to improve — it now automatically determines the text direction (ensuring correct display of sites with unusual domain names) and shows detailed descriptions for log actions. Later this week, a new permanent link for page creations and CSS classes for each entry element will be added. [9][10][11][12]
• View all 32 community-submitted tasks that were resolved last week. For example, the previously observed issue in Vector 2022, where anchor link targets were obscured by the sticky header, has now been addressed. [13]

Updates for technical contributors

• As mentioned in the October 2025 deprecation announcement, MediaWiki Interfaces team will begin sunsetting all transform endpoints containing a trailing slash from the MediaWiki REST API the week of January 26. Changes are expected to roll out to all wikis on or before January 30th. All API users currently calling them are encouraged to transition to the non-trailing slash versions. Both endpoint variations can be found, compared, and tested using the REST Sandbox. If you have questions or encounter any problems, please file a ticket in Phabricator to the #MW-Interfaces-Team board.
• Interactive reference documentation for the Wikimedia REST API has moved. Requests to API docs previously hosted through RESTBase (e.g.: https://en.wikipedia.org/api/rest_v1/) are now redirected to the REST Sandbox.
• The WMF Wikidata Platform team (WDP) has published its January 2026 newsletter. It includes updates on the legacy full-graph endpoint decommissioning, the User-Agent policy change, the monthly Blazegraph migration office hours, and efforts to reduce regressions caused by the legacy endpoint shutdown. As a reminder, you can subscribe to the WDP newsletter!
• Detailed code updates later this week: MediaWiki

Meetings and events

• The Wikimedia Hackathon Northwestern Europe 2026 will take place on 13-14 March 2026 in Arnhem, the Netherlands. Applications opened mid-December and will close soon or when capacity is reached. It's a two-day, technically oriented hackathon bringing together Wikimedians from the region. Hope to see you there!

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

MediaWiki message delivery 20:29, 19 January 2026 (UTC)

Annual review of the Universal Code of Conduct and Enforcement Guidelines

I am writing to you to let you know the annual review period for the Universal Code of Conduct and Enforcement Guidelines is open now. You can make suggestions for changes through 9 February 2026. This is the first step of several to be taken for the annual review. Read more information and find a conversation to join on the UCoC page on Meta.

The Universal Code of Conduct Coordinating Committee (U4C) is a global group dedicated to providing an equitable and consistent implementation of the UCoC. This annual review was planned and implemented by the U4C. For more information and the responsibilities of the U4C, you may review the U4C Charter.

Please share this information with other members in your community wherever else might be appropriate.

-- In cooperation with the U4C, Keegan (WMF) (talk)

21:02, 19 January 2026 (UTC)

Template:Engine usages

When do we want and not want {{Engine}} to be used? Are there any cases where it's definitely inappropriate? The template docs don't really say anything specifically, but I found one example of an Index page that uses it for only the page namespace, but not the actual transcluded work: Index:Darby O'Gill and the Good People by Herminie Templeton Kavanagh (1903).djvu. And all the work is anyway is a collection of short stories, average in page structure.

I also put {{Engine}} on a work I did called Southern Antiques (1931) years ago, but now that I think about it, it is a short nonfiction book with an average Introduction + numbered chapters structure, so I don't know that this was the right call. My understanding is that {{Engine}} is best for works like encyclopedias or dictionaries or copyright records, where there's loads of material within a multi-volume nonfiction work with logical topical separations.

(And the search engine doesn't actually seem to work that well, but we can get to that another day.) SnowyCinema (talk) 00:07, 20 January 2026 (UTC)

Where does the "Cast and Crew" section from

Hi, I want to transcribe a film in my home wikisource, and I'm using Blackmail (film) as an example. I couldn't find where the data of Cast and Crew section came from. I tried to copy to Sandbox [14], but it doesn't appear to have the Cast and Crew section. Anybody could shed a light on this? Thanks. Bennylin (talk) 06:05, 24 January 2026 (UTC)

@Bennylin: Hi, and thanks for taking interest in our film projects here. I looked and saw you're working on at the Indonesian Wikisource. The Cast and Crew section is generated by the template {{Cast and crew}} which is internal to {{Film}}. And the logic is in several Lua modules: Module:Cast and crew and Module:Film. Here's an example invocation: {{cast and crew|Q816038}} This can produce some code by itself. Hopefully that helps. If you need more help with it, I can try to take some time out this week or so to work on stuff over at idws with you. SnowyCinema (talk) 06:36, 24 January 2026 (UTC)

Thanks for the fast response. I will try it. Bennylin (talk) 07:21, 24 January 2026 (UTC)

It works now (id:Darah dan Doa (film)) even before I linked it to the Wikidata item. I wonder where it got its Wikidata ID from. Bennylin (talk) 06:19, 28 January 2026 (UTC)

Best choice for this editorial?

So I came across Chicago Press and Tribune/Editorial on Harper's Ferry and wanted to switch it to a scan-backed source (as well as transcribe the rest of that particular issue), so I transcribed Page 2 of Index:Chicago Press and Tribune 1859-10-20.pdf and transcluded it to Chicago Tribune/1859/October/20/Where the responsibility belongs. The question I have now is this -- what should I do with the old version? Should I just blank the page and redirect to the scan-backed version? Make an edition page and include links to both? Leave it how it is right now? Let me know what you think. Mathmitch7 (talk) 19:23, 24 January 2026 (UTC)

I would say to redirect the non-scan-backed copy to the scan-backed one, making sure that the edit history is preserved. CitationsFreak (talk) 13:42, 25 January 2026 (UTC)

Deleted per WS:Deletion policy#G4. @CitationsFreak: We do not keep such unnecessary redirects. Unlike Wikipedia, where contributors create their own texts—often building upon the work of others—we only transcribe texts, and therefore the page history is not as important here. --Jan Kameníček (talk) 14:07, 25 January 2026 (UTC)

Thanks! Helpful clarification of policy Mathmitch7 (talk) 15:40, 25 January 2026 (UTC)

Poems, by S. T. Coleridge. Second Edition, To Which Are Now Added Poems by Charles Lamb and Charles Lloyd

can this be transcribed? i believe the link has a scan

https://archive.org/details/bim_eighteenth-century_poems-by-s-t-coleridg_coleridge-samuel-taylor_1797 Skittythetranscat (talk) 10:55, 26 January 2026 (UTC)

The 1803 edition is currently being transcribed, but has not had many volunteers working on it. --EncycloPetey (talk) 15:08, 26 January 2026 (UTC)

When I searched for it nothing came up, how weird.

Thanks for linking! Skittythetranscat (talk) 10:35, 27 January 2026 (UTC)

It's listed and linked at Author:Samuel Taylor Coleridge. It's often worth checking the author's page in addition to making a general search. --EncycloPetey (talk) 14:56, 27 January 2026 (UTC)

Yes, it can. Do you need help with uploading the scan or creating the index page? -- Jan Kameníček (talk) 15:09, 26 January 2026 (UTC)

Once the 1803 edition is done I might look into it. Thanks for the offer. Skittythetranscat (talk) 10:35, 27 January 2026 (UTC)

Tech News: 2026-05

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

Updates for editors

• Wikimedia Foundation invites comments on proposed future of the Product and Technology Advisory Council until 28 February.
• All users with registered accounts can now use passkeys for two-factor authentication (2FA). Passkeys are a simple way to log in without using a second device. They verify the user's identity using a fingerprint, face scan, or a PIN code. To set up a passkey, first set up a regular 2FA method. Currently, to log in with a passkey, users must also use a password. Later this quarter, passwordless login will allow users to log in with a single click and a passkey. Users with advanced rights will also be required to have 2FA enabled. This is part of the Account Security project.
• Unregistered contributors on blocked IPs or blocked IP ranges can now interact on-wiki to appeal a block by creating a temporary account to appeal a block on the user talk page, unless the "prevent this user from editing their own talk page" is enabled. This solves the problem of logged-out users unable to use the default unblock process via user talk page. [15]
• View all 20 community-submitted tasks that were resolved last week. For example, the Two-Factor Authentication (2FA) methods description on the management page has been updated. It is now clearer and easier for users to understand and make use of. [16]

Updates for technical contributors

• A new AbuseFilter variable, account_type, has been added to provide a reliable way to determine the account type being created in the createaccount and autocreateaccount actions. As part of this change, the variable accountname has been renamed to account_name, and accountname is now deprecated. Edit filter managers should update any filters that use hardcoded account type checks or the deprecated variable. [17]
• Image thumbnails that are requested in non-standard sizes, and using non-standard methods such as direct requests to upload.wikimedia.org/… will stop working in the near future. This change is to prevent ongoing external abuse by web-scrapers and bots. Some users with custom CSS/JS, Interface Admins who can fix gadgets and local skins, and Tool-authors, will need to update their code to use standard thumbnail sizes. Details, search-links, and examples of how to fix them, are available in the task.
• Detailed code updates later this week: MediaWiki

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

MediaWiki message delivery 21:17, 26 January 2026 (UTC)

Double-click errors in Proofread Page

Last night I noticed odd behavior while editing in the Page namespace. The behavior is still occurring today. When I double-click a word, I now get the front half of a word selected instead of the entire word. It selects the word only up to the point where my cursor is positioned, instead of the entire word.

This behavior does not occur outside of the Proofreading in Page space, nor in other applications where I've tested for it. Although it does not occur 100% of the time, it is occurring frequently enough that I noticed it causing errors in proofreading, as I expect normal double-click behavior to select all of word, so that I can replace it, rather then retaining the end of the existing word.

Are other people experiencing this behavior in Page proofreading? --EncycloPetey (talk) 20:29, 28 January 2026 (UTC)

I believe that double-click-to-select is a browser-based function; have you experienced this in other browsers? I can confirm that I do NOT have this issue, and I am using Chrome on Windows. —Beleg Tâl (talk) 20:35, 28 January 2026 (UTC)

I am not experiencing it either. Tried Chrome, Firefox and Opera on Windows. --Jan Kameníček (talk) 20:45, 28 January 2026 (UTC)

If it is a browser-based function, then I would expect the same behavior in my browser regardless of the site / page. I considered this possibility and checked other sites, both in and out of Wikimedia. I am only experiencing the issue when editing in the Page namespace. --EncycloPetey (talk) 22:07, 28 January 2026 (UTC)

• That doesn’t change anything. I’ve had a long-running issue which only occurs in Page: and appears to an issue specific to me (not your issue, though); in other Web-sites, including other Wikimedia sites, there is no problem. For the record, I also don’t have your issue (I checked Chrome and Edge). TE(æ)A,ea. (talk) 00:43, 29 January 2026 (UTC)

Issues with editing window height in ProofreadPage

Tracked in PhabricatorTask T393231

Has anyone encountered that recently? I've been having issues with the editing layout being compressed to a very small height, making it kind of unusable. I can reproduce on another account, so I'm a bit surprised it'd affect only me. (For details, see my report at phab:T393231#11570707.) — Alien  3
3 3 21:22, 30 January 2026 (UTC)

Yes for past two days, I've been experiencing the second version you reported "the edit boxes overflowing onto the form buttons". No scroll bars on the edit window any more—instead the edit window expands to take in the entirety of the content, and the "form buttons" (Proofread status buttons, Publish buttons etc.) are floating in the middle of the edit box.

Edit: I've checked which feature was causing this extreme version of the problem in my case. It went away when I turned off "Improved Syntax Highlighting" in Beta Features. Pasicles (talk) 21:43, 30 January 2026 (UTC)

@Alien333: as a turnover you can use the grey handle above the Summary to expand the edit area. • M-le-mot-dit (talk) 22:19, 30 January 2026 (UTC)

My edit window suddenly reduced in height about the same time. I corrected the problem by dragging the edge of the editing window down, and it has stayed at the new height. I'm guessing that some sort of data was accidentally overwritten, or some change altered the default. The [OCR] button no longer appears at the top of my edit window; I have only the new drop-down OCR menu instead. And there in now an intrusive "Insert" drop-down menu at the top that was not there previously. The menu duplicates functions of the options below it, but also offers items that are completely useless in the Page namespace, like category and redirect insertion options, and the ability to sign my posts (in the Page namespace ??). This looks like Wikipedia-specific editing content misapplied to the Page namespace. --EncycloPetey (talk) 22:54, 30 January 2026 (UTC)

How do I start adding sources?

There are several primary source documents that I know are public domain (hundreds of years ago) that I'd like to add to Wikisource, but I am a bit confused; how do I start the new page? Is there a template? How does copyright apply to translations? VidanaliK (talk) 01:06, 31 January 2026 (UTC)

Have you read Help:Beginner's guide to adding texts? You should start by uploading a scan of the work to Commons, then create an Index here based on that scan.

Translations have there own separate copyright status. For a translation to be acceptable here, both the original and the translation need to be in public domain. -- Beardo (talk) 02:11, 31 January 2026 (UTC)