Wikisource:Scriptorium

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

Proposals

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

Changing the typefaces in Template:Cursive/styles.css

One-liner

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

Details of the issue

Current typeface choices

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

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

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

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

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

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

CSS broswer defaults are not good enough

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

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

Proposal

Considering—

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

I hereby propose that we:

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

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

Discussion

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

I am aware of that. The reason I proposed a calligraphic font instead of handwriting font is that there are no good "foolproof" handwriting font widely available.

Instead, is there for us to load fonts site-wide, so that we can choose from the various good options on Google Fonts or other open source fonts? I am unfortunately not tech-savvy enough to do it myself. ⸺ googoo0202 (he/him) (talk, contrib) 03:56, 20 October 2025 (UTC)

And there is a separate issue, that being the template is used in a large variety of "handwritten" text, from nicely handwritten—nearly calligraphic text, to signatures, to crudely jotted notes. I don't see a good middle-ground, handwritten font between all these. Hence my proposal of a completely different font. At least it is the default fallback of Mac systems, which is some firm ground around all the mud. ⸺ googoo0202 (he/him) (talk, contrib) 04:01, 20 October 2025 (UTC)

Something must be done, this is something, therefore this must be done? Sorry, that's a bit rude. I take your point that it would be good to have more cross-platform consistency and pick a reasonable default, and I probably agree with you. That said, I'm not sure why the fact that it's hard to choose a good default means we should choose a completely different font that suits none of our use cases for "handwritten" text. —CalendulaAsteraceae (talk • contribs) 20:23, 14 November 2025 (UTC)

Yah I get why you would say that. But it's not a random something. Rather, it's taking the Apply default and finding a way to apply it to Windows (sorry Linux). Yes it is Apple-centric, but given the alternative is Comic Sans MS, I don't think doing the opposite is anything better.

I tried surveying the usage of {{cursive}} a while back (as mentioned above), what I get from my totally unbiased absolutely cherry-picked bias-prone monkey-brain random clicking, I see no consistency in how it is used. To me, there are no hope of fantasising about one single good computer font that can capture all these use cases, thus the compromise. ⸺ googoo0202 (he/him) (talk, contrib) 06:33, 17 November 2025 (UTC)

I have some sympathy here, we heavily focus on printed texts and to the extent we would like to reproduce some of the effect of titles on etched plates like copper plate or title pages it makes sense to use a copper plate / chancery style typeface purely for those effects. While for actual manuscript we should probably have something that conveys both visual effect and semantic meaning, that these wasn't printed, Keeping in mind that handwritten = cursive is declining, so contemporary handwritten works aren't likely to actually be cursive with linked letters and general readability of cursive is declining... MarkLSteadman (talk) 07:15, 17 November 2025 (UTC)

It is very true that contemporary handwritten works aren't likely to actually be cursive. Using {{cursive}} for it is not great, I would rather build another template (if I get to know how to do it) for non-cursive handwritten, or generic handwritten text, using Segeo Script or other modern handwritten fonts. But that is besides the point I guess. ⸺ googoo0202 (he/him) (talk, contrib) 04:39, 18 November 2025 (UTC)

Bot approval requests

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

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:Online Safety Act 2023 (Category 1, Category 2A and Category 2B Threshold Conditions) Regulations 2025.pdf

Please move to Index:The Online Safety Act 2023 (Category 1, Category 2A and Category 2B Threshold Conditions) Regulations 2025 (UKSI 2025-226 kp).pdf to match commons. ToxicPea (talk) 00:49, 12 November 2025 (UTC)

St. Louis Globe Democrat and all subpages

They should be at St. Louis Globe-Democrat instead. Nighfidelity (talk) 16:23, 19 November 2025 (UTC)

Index:MU KPB 018 Comus by John Miltow - Illustrated by Arthur Rackham.pdf

This should be moved to Index:MU KPB 018 Comus by John Milton - Illustrated by Arthur Rackham.pdf ToxicPea (talk) 00:22, 30 November 2025 (UTC)

Index:Dissolution and Calling of Parliament Act 2022.pdf

Please move to Index:Dissolution and Calling of Parliament Act 2022 (UKPGA 2022-11 qp).pdf to match commons. ToxicPea (talk) 18:19, 7 December 2025 (UTC)

Other discussions

Index:Joplin Tornado - May 22nd, 2011.pdf

This index, and the related main documents are now blank because the file at Commons has been deleted.

Can this be sorted out ? Or should everything on wikisource be deleted ? -- Beardo (talk) 18:31, 26 October 2025 (UTC)

• Or should Wikisource host the document? On many occasions we have ruled differently on copyrights. --RAN (talk) 19:58, 26 October 2025 (UTC)

It looks like the deletion was due to an included photograph that is now being hosted on English Wikipedia as a non-free image. The text should be able to restored to Commons with the image redacted or maybe everything could be hosted here. —Tcr25 (talk) 20:27, 26 October 2025 (UTC)

If there are US copyright issues with the image, then the image can't be hosted here. "Non-free" image would mean that it violates our copyright restrictions. --EncycloPetey (talk) 20:38, 26 October 2025 (UTC)

we could adopt a exemption policy allowing fair use images included in public domain documents. but it is not the consensus yet. english wikipedia could host the document. --Slowking4 ‽ digitaleffie's ghost 02:02, 30 October 2025 (UTC)

Per Help:Licensing compatibility - "Fair use is explicitly prohibited on Wikisource, since Wikisource's license allows use or distribution in circumstances where fair use is invalid (such as commercial exploitation)."

Does someone want to arrange for a redacted copy, or shall we delete the stuff here ? -- Beardo (talk) 17:31, 1 November 2025 (UTC)

• It has to be someone with access to deleted Commons file, I can't find it online. Is the plan to redact and upload here or reupload at Commons? --RAN (talk) 18:44, 1 November 2025 (UTC)

  It seems that the original source is available at - https://web.archive.org/web/20170127072437/http://www.weather.gov/sgf/news_events_2011may22 I assume that a redacted version can be uploaded to Commons. -- Beardo (talk) 18:08, 4 November 2025 (UTC)

  As nobody seems interested in restoring the document, I will propose for deletion. -- Beardo (talk) 03:07, 12 November 2025 (UTC)

Are emails of federal employees necessarily public domain?

Letter from Terry Henry to CCR, regarding suicides, (2006-06-10) and Letter from Terry Henry to Barbara, regarding suicide, (2006 mid June) are two emails from a DOJ employee. I'm not too sure if they should be here, but I want to get more info before nominating it for deletion. Nighfidelity (talk) 21:31, 12 November 2025 (UTC)

I would like them to be in a larger context, as part of the file listed as source, even if that file has to have large copyright chunks removed. As for these files, any emails written by a federal employee as part of their job is public domain.--Prosfilaes (talk) 00:29, 13 November 2025 (UTC)

The url shown now gives a 404 page not found error. -- Beardo (talk) 01:27, 13 November 2025 (UTC)

The url was archived on wayback so the file is still available. ToxicPea (talk) 01:21, 18 November 2025 (UTC)

• Yes, the e-mail are part of the employee’s U.S. government job duties, and are thus “work[s] of the United States Government” which are not copyrightable. The PDF itself is a privately-prepared report, to which the e-mail were attached as appendices. TE(æ)A,ea. (talk) 17:26, 13 November 2025 (UTC)

How do I form a link to another language Wikisource article

https://de.wikisource.org/wiki/Jeanette_Schwerin_%E2%80%A0 the article is Jeanette Schwerin † Can someone format the link for me here. RAN (talk) 04:52, 17 November 2025 (UTC)

do you mean like this? de:Jeanette Schwerin † the code is [[:de:Jeanette Schwerin †]] ⸺ googoo0202 (he/him) (talk, contrib) 06:44, 17 November 2025 (UTC)

• Thanks! I was missing the leading colon (:) --RAN (talk) 16:51, 17 November 2025 (UTC)

Tech News: 2025-47

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 Reader Experience team is experimenting with reading lists on mobile web, allowing logged-in readers with no edits to save private lists of articles for later. The experiment is running on Arabic, Chinese, French, Indonesian, and Vietnamese Wikipedias since the week of 10 November, and will begin on English Wikipedia the week of 17 November.
• Users who can’t receive their email verification code during login can now get help by submitting a form on a new special page. This update is part of the Account Security initiative. If your account has an email address, please make sure you still have access to it. When logging in from a new device or location without 2FA, you may be asked to enter a 6-digit code sent by email to finish logging in. Learn more.
• One new wiki has been created: a Wikisource in Minangkabau (s:min:) [1]
• View all 23 community-submitted tasks that were resolved last week.

Updates for technical contributors

• As part of the Parser Unification project, the Content Transform Team rolled out Parsoid as the default parser to many low-traffic Wikipedias and is preparing the next step to high traffic ones. This message is an invitation for you to opt-in to Parsoid, as described in the Extension:ParserMigration documentation, and identify any issues you might encounter with your own workflow using bots, gadgets, or user scripts. Please, let us know through the "Report Visual Bug" link in the Tools sidebar or create a phab ticket and tag the Content Transform Team in Phabricator.
• Unsupported Tools: Several issues with Video2Commons have been fixed, including filename-related upload failures, black-video imports, and retry handling. AV1 support has also been added. Ongoing work focuses on backend stability, ffmpeg errors, subtitle imports, metadata handling, and playlist uploads. To track specific tasks, check the Phabricator board.
• Detailed code updates later this week: MediaWiki

Meetings and events

• Save the date for the next Wikimedia Hackathon happening in Milan, Italy from May 1–3, 2026. Registration will open in January 2026. Scholarship applications are currently open, and will close on November 28, 2025. If you have any questions, please email hackathon@wikimedia.org.

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

MediaWiki message delivery 17:26, 17 November 2025 (UTC)

Comics

Hi!

I see we have "some" comics that are in the Public Domain, but not that much. Also, there is not a separate Wikisource Wikiproject for Public Domain Comics. I think I would like to do something about both of those things, but also I am a perpetual Wikipedia & Sister Projects newbie. Any good advice I could get?

Best wishes -- Kaworu1992 (talk) 01:06, 18 November 2025 (UTC)

@Kaworu1992 here is my personal advice for you. Wikisource has a steep learning curve, and comics are difficult even for experienced editors. If you are a newbie, I strongly recommend that you start with something simpler. One thing you could do easily as a newbie though, is finding scans of comic books and uploading them to Wikimedia Commons. —Beleg Tâl (talk) 13:05, 18 November 2025 (UTC)

• @Kaworu1992: Have we transcribed a comic yet, I would love to see an example. It seems like it would be very difficult to come up with a standard format, other than single panel comic. --RAN (talk) 04:36, 23 November 2025 (UTC)

  The few we have are in Category:Comics, but they were done nearly 20 years ago and mostly as image galleries, which is more in line with Commons style content. --EncycloPetey (talk) 05:25, 23 November 2025 (UTC)

• Yes, essentially galleries of the pages. Very odd. Our format doesn't really fit them. I could see breaking them down to individual panels and having the speech balloons transcribed as text, but that would be so much work, for little improvement. --RAN (talk) 04:46, 24 November 2025 (UTC)

  An alternate method would be to put the content of the speech bubbles in the alt-text field of each image. However, that would be incomplete for accessibility purposes as image descriptions would also be needed. The work required to prepare tactile versions of even simple picture books for vision impaired children is huge with upwards of hours per page. Some of the complexities in comics would be much worse to reproduce. Beeswaxcandle (talk) 06:59, 24 November 2025 (UTC)

My personal theory is we should use the Film templates below the comic image to reproduce the dialogue ({{ft/d}}) / in-scene text ({{ft/i}}) / descriptive text ({{ft/s}}). Comics are very similar to films in terms of narrative structure, so this should be possible and should get around most of the stylistic/technical complications we often reference. I've been meaning to make a demo of this for some amount of years, but you know how it is: Haven't Gotten Around To It™. I just don't think trying to whiten comic bubbles, and use {{Overfloat image}} to put HTML text inside the bubbles, etc. would be a good way to do this. Even if we assumed we somehow made {{Overfloat image}} work consistently across devices and browsers for such complicated use cases ("hell is paved with good intentions, but mostly with compatibility issues"), the amount of time and effort it would take to reproduce comics in this manner, with such little added value, is I think just not worth it. The primary reason to put comics here in my mind, as opposed to just leaving them at Commons, is to make the text of the comics searchable. There are external sites I've seen before that include comic transcriptions below the comic image itself, so I think this theory would be worth experimenting with at Wikisource at the very least. SnowyCinema (talk) 11:34, 24 November 2025 (UTC)

On this subject, I have noticed that there are a few Indexes that have been created with .jpgs taken from comics published online, and with the Pages then just transcribing the text. I am not sure what the user who created them was intending, but I wonder whether they could be progressed by combining the original images with the transcribed text. -- Beardo (talk) 05:12, 25 November 2025 (UTC)

Importing modern works

Do we have a tool for importing modern, freely licensed, works?

For example, Walled Culture by Glynn Moody is published as CC0, and is available in PDF, epub or mobi formats.

We have Index:Walled Culture.pdf, created in 2023 and with no pages started, but it seems we could cut out a lot of the grunt-work through automation. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:58, 20 November 2025 (UTC)

It's not clear what part of the process you suggest automating. In the past, we have tried importing text and parsing the text into Pages for later proofreading, or using bots to create pages from OCR of the the PDF. Neither of those processes has led to satisfactory results, and we end up with texts not proofread by any human that sit for years or decades in that unproofread state. --EncycloPetey (talk) 13:40, 24 November 2025 (UTC)

I'm not suggesting using OCR or (necessarily) PDFs.

The text is in epub and mobi formats, from which it can presumably be extracted, complete with structured markup. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:02, 24 November 2025 (UTC)

Extracted to appear in what format? And with what method for checking accuracy if it's not going to be set in the Page namespace? --EncycloPetey (talk) 16:25, 24 November 2025 (UTC)

We seem to be at cross purposes.

Where did I say it would not go in the Page namespace? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:45, 24 November 2025 (UTC)

Then I have no idea what it is you are proposing to automate. Each question I've asked has received a negative response with no articulation or elaboration of what process you do envision. --EncycloPetey (talk) 19:17, 24 November 2025 (UTC)

It's a modern work released in epub form. You can check accuracy against the epub if that is a published format. There's no reason to work from pictures of printed pages if it was originally published as electronic text.--Prosfilaes (talk)

You could use pandoc -f epub -t mediwiki; it would keep the text right and hopefully not lose major formatting. There's nothing that's going to take an arbitrary epub and make it formatted properly, but that might be a good start.--Prosfilaes (talk) 04:50, 25 November 2025 (UTC)

Reminder: Help us decide the name of the new Abstract Wikipedia project

Hello. Reminder: Please help to choose name for the new Abstract Wikipedia wiki project. The finalist vote starts today. The finalists for the name are: Abstract Wikipedia, Multilingual Wikipedia, Wikiabstracts, Wikigenerator, Proto-Wiki. If you would like to participate, then please learn more and vote now at meta-wiki. Thank you!

-- User:Sannita (WMF) (talk) 14:22, 20 November 2025 (UTC)

File remame

I had these files renamed for clarity. Could someone please update the accompanying indexes and pages?

• File:The Mégha Dúta or Cloud Messenger.djvu → File:The Mégha Dúta or Cloud Messenger, H. H. Wilson, ed. 1.djvu
• File:The Mégha Dúta or Cloud Messenger (Second Edition).djvu → File:The Mégha Dúta or Cloud Messenger, H. H. Wilson, ed. 2.djvu

Eievie (talk) 00:54, 22 November 2025 (UTC)

There is no Index associated with that first file move. --EncycloPetey (talk) 03:02, 22 November 2025 (UTC)

 Comment It's generally better to say "1st ed." in a filename. In the above rename, the name is likely to be read as "H. H. Wilson, ed[itor, volume] 1". --EncycloPetey (talk) 03:06, 22 November 2025 (UTC)

Or, even better yet, the date? Here 1st ed in 1814, 2nd in 1843, that's a quite clear disambiguator. — Alien  3
3 3 12:34, 22 November 2025 (UTC)

Tech News: 2025-48

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

• Last week, the Wikimedia Search Team recreated the "DWIM" (Do What I Mean) gadget functionality server-side, for Russian and Hebrew Wikipedias. This feature adds cross-keyboard suggestions to the standard search-box suggestions. For example, searching for cxfcnmt on Russian Wikipedia will now add suggestions for счастье ("happiness") that the user probably intended. They plan to enable this feature for other Russian and Hebrew wikis this week. [2]
• Later this week, users of the "Improved Syntax Highlighting" beta feature will have syntax highlighting available in DiscussionTools. This requires that the "Enable editing tools in source mode" preference be set. [3]
• Campaign events extension – the set of tools for coordinating events and other on-wiki collaborations has now been deployed to all Wikimedia wikis. A new feature known as Collaborative contribution to help organizers and participants see the impact of activities has also been added. Join the upcoming learning session to see the new feature in action and share your feedback.
• View all 24 community-submitted tasks that were resolved last week. For example, the bug which stopped CodeReviewBot from working, has now been fixed. [4]

Updates for technical contributors

• Users of Wikimedia API can join a usability study to help validate the new design of Wikimedia REST API sandboxes. Interested participants should fill the recruitment survey. [5]
• The MediaWiki Interfaces team is deprecating XSLT stylesheets within the Action API. Support for format=xml&xlst={stylesheet} will be removed from Wikimedia projects by the end of November, 2025. In addition, it will soon be disabled by default in MediaWiki release versions: v1.43 (LTS), v1.44, and v1.45. Support for XSLT stylesheets will be fully removed from MediaWiki v1.46 (expected to release between April and May 2026). [6]
• The WDQS legacy endpoint (query-legacy-full.wikidata.org) will be decommissioned at the end of December 2025, and finally closed down on 7th January 2026. After this date, users should expect requests to query.wikidata.org that require the full graph to fail or return invalid results if they are not rewritten to use SPARQL federation. The team encourages users to ensure that tools and workflows use the supported WDQS endpoints (https://query.wikidata.org/ - Main graph or https://query-scholarly.wikidata.org/ - Scholarly graph). For support with migrating use cases, please review the Data Access and Request a Query pages for details and assistance on alternative access methods.
• 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 15:56, 24 November 2025 (UTC)

Are the Trump plans PD Edict?

Do Trump 28-point Ukraine–Russia plan (20 November 2025 version) and Trump 28-point Ukraine–Russia plan (23 November 2025 version) qualify under template:PD-EdictGov? These are stated by generally reliable sources to be what are implied to be word-for-word copies of specific versions of the original document, so they are various versions of a US government legal-type document. On en.Wikipedia, @Diannaa: removed the links to these two wikisource documents, stating in the edit summary that these are links to copyright violations, i.e. effectively suggesting that these are not PD.

Are they PD or not PD? Boud (talk) 00:36, 25 November 2025 (UTC)

• I would not trust English Wikipedia editors as to competence, especially on copyright issues (although in that respect I am more familiar with Wikimedia Commons). Neither of these are “edicts” as they are general or generic policy statements. The November 20 plan, which is a U.S. government work, is in the public domain for that reason; the November 23 plan is apparently a European government work, and so is likely copyrighted. TE(æ)A,ea. (talk) 21:15, 25 November 2025 (UTC)
  • The 20 Nov version as a US government work at least bypasses the question of whether they are edicts (by "question" I mean that I'm unfamiliar with the interpretation of what counts as an edict; I'm not saying that you're wrong).
    For the 23 Nov version, my understanding is that it's a derived version of the 20 Nov version, and I had thought that it was issued with US considered to be a co-author, i.e. it still is a US government document in that sense. However, that's not in the Reuters source, and currently I don't see any sources stating that the 23 Nov derived version is still a US government document (they're not interested in the copyright aspect), although they agree that it's a derived document, "By Sunday, a revision had emerged. It took the US plan as its basis and made steady amends, with several notable differences. "
    The Reuters source itself similarly says "... drafted by Europe's E3 powers of Britain, France and Germany, takes the U.S. plan as its basis but then goes through it point by point with suggested changes and deletions". Independently of whether it still qualifies as a US government document, the modified PD document probably takes on the additional copyright of the extra authors. Help:Official texts has no guide for France. Help:Official texts#Germany has "is in the public domain according to German copyright law [if] it is part of a statute, ordinance, official decree or judgment (official work) issued by a German federal or state authority or court" - which doesn't mention draft documents. Help:Official texts#United_Kingdom says "Since 2010, almost all information owned by the UK Crown is offered for use and re-use under the Open Government Licence by authority of The Controller of His Majesty's Stationery Office.".
    Is a modified US gov document still a US gov document (for the 23 Nov version)?
    Does {{OGL3}} apply for the 23 Nov version, since the UK Crown effectively "owns" a copy of the document? Boud (talk) 13:07, 26 November 2025 (UTC)
    • The 23 Nov version does not seem to qualify for any of the exceptions to OGL3 in UK. "Government policy is that public sector information should be licensed for use and re-use free of charge under the Open Government Licence (OGL) with only a few exceptions..." So OGL3 seems likely to apply. Boud (talk) 13:18, 26 November 2025 (UTC)

oh, they are PD. English admins are frequently wrong but never in doubt. and they don't play nice with sister projects. but a problem is, can't find a text source for the document, unlike Report On The Investigation Into Russian Interference In The 2016 Presidential Election. that would be an improvement. but this executive isn't known for text openness. --Slowking4 ‽ digitaleffie's ghost 23:36, 8 December 2025 (UTC)

How can one access a database dump of the Multilingual Wikisource?

Hi all! I am currently doing an exercise in machine translation of underrepresented languages, for which I need a large multilingual corpus of public-domain texts, programmatically accessible. I know that I can download a database dump for any individual-language Wikisource at https://dumps.wikimedia.org, e.g. an `enwikisource` or a `ruwikisource`. However, for the Multilingual part of Wikisource (the one with the code `www` at https://meta.wikimedia.org/wiki/Wikisource), there is no `wwwwikiource` or `mulwikisource` dump to download. Does such dump exist? If yes, where one can access it? If not, who could I ask to create it? Cointegrated (talk) 13:30, 27 November 2025 (UTC)

@Cointegrated: the database name for mulwikisource is (for historical reasons I think) sourceswiki. — Alien  3
3 3 21:53, 27 November 2025 (UTC)

Thanks a lot!!! I would have never guessed it on my own. Cointegrated (talk) 21:58, 27 November 2025 (UTC)

Creating a "Chefoo Convention" page

Hello.

I'm a guy interested in Chinese history, and while I was searching for treaties between the Qing Dynasty and the Western world, I found that there is no entry on the Chefoo Convention in Wikisource English.

I was unable to find a digital version of the text (encoded in ASCII so we can copy and paste the text directly), but I was able to find the original source of the English version of the treaty: https://babel.hathitrust.org/cgi/pt?id=hvd.32044088698881&seq=12

I'm not familiar with uploading texts to English Wikisource, my specialty is in Chinese texts. Would you all please help me with this endeavor? Thank you all very much! Blahhmosh (talk) 06:23, 29 November 2025 (UTC)

@Blahhmosh : this document being also available in Google Books, it is now converted in DjVu and loaded in Commons: File:Agreement Between the Ministers Plenipotentiary(…)signed at Chefoo (1876).djvu. • M-le-mot-dit (talk) 09:29, 29 November 2025 (UTC)

@Blahhmosh : The Index is ready here. • M-le-mot-dit (talk) 23:04, 29 November 2025 (UTC)

Unpaired tags in transclusions to mainspace.

Hi.

Can someone PLEASE fix these - https://en.wikisource.org/wiki/Special:LintErrors/stripped-tag? I'd been able to clear this out earlier in the year, and it seems to have built up again.

Nearly all the entries, are down to tags being unbalanaced on transclusion. , despite the pages concerned being balanced when header, content, footer are considered together..

So far in my attempts to delint I've found these can be caused by:

• the approriate /s version of a template has been omitted, or used in a header for a single page only, whereas the /e version, is in the main text.
• A page ends with a list item, but the next page starts with a non-list-item, such as a {{center}}ed heading. (These can be solve by placing {{nop}} on a single line at the end of the list.

Annoyingly Special:LintErrors doesn't provide any kind of information as to the Exact Page: where it found the Stripped tag, meaning entire runs of pages have to be checked which is not a satisfactory workflow.

ShakespeareFan00 (talk) 09:34, 29 November 2025 (UTC)

Crediting user translations

As far as I know, current practice has been to not specifically credit the translator in the header in user translations, which can be justified by concerns on self-publicity and on user translations not belonging to any specific author (especially given we don't allow a second user translation of the same work). Simply, am I wrong? I'd like to gather input to try and establish the community's position on this. — Alien  3
3 3 09:29, 30 November 2025 (UTC)

I will add that the context of this request for best practices is Wikisource:Proposed_deletions#Undelete_Fables_and_Parables, where a professional translator, who is sharing is work here (under free licence) asks to be credited (I see no reason not do so, given that this is done for many works in categories I checked - see examples there). Piotrus (talk) 11:57, 30 November 2025 (UTC)

Several of the translations you noted were published translation; that is, published somewhere and afterwards added to Wikisource. Published works that we then host are a different sort of work than user-created translations that are first published here. Previously published works are hosted here to look exactly as they were published, and would not be altered in any way. User-created translations can be edited and updated by anyone here, including the change of words. I see only two Author pages among the items you listed where the translation originated on Wikisource, and in such cases it is often a result of no one else stepping in to bring formatting to current norms. --EncycloPetey (talk) 13:56, 30 November 2025 (UTC)

You are correct about our current practice. User translations are communal projects, and editors who contribute to them are credited on the page history page (like practically all community-authored pages on Wikimedia projects.) —Beleg Tâl (talk) 19:44, 30 November 2025 (UTC)

Note we allow only a single user translation for any given work. It isn't meant to be frozen, credited to a single editor blocking out all future development. And crediting to an author is problematic if the work does change (e.g. a subsequent editor introduces an error or different interpretation than the original work). MarkLSteadman (talk) 20:24, 30 November 2025 (UTC)

@Nihil novi Were the translations in questions published somewhere before being added to Wikisource? (Realistically releasing them as an ebook, for example, even self-published, would count too - correrct me if I am wrong, folks). Piotrus (talk) 01:04, 1 December 2025 (UTC)

We don't host self-published works. If these poems have been independently published, then we can host them as such; otherwise unfortunately our only option is to host them as a communal project (or not to host them at all). —Beleg Âlt ^BT (talk) 14:37, 1 December 2025 (UTC)

Need help for Kannada lemmas

Hello, A year ago I started learning the Dravidian/South Indian language named Kannada with a teacher from north (!) Karnataka. Since we couldn't find standard textbooks from the Indian Ministry of Education, we tried to create our own. I tried using the Wikipedia Kannada lemmas but it turns out there is much outdated information there. The reason for this is that much of Kannada glossaries seem to be based on the famous Kittel dictionary, which is already two centuries old. E.g., acc. to my teacher, 'jirale' means not 'cockroach' but 'centipede'. Etc etc. Currently I'm paying him to go through the list and populate a Google Sheet with correct words. We're already have about 1000 words. I plan to release the list to Wikimedia (wiktionary?) and also to add pronunciations for the words. For the benefit of Kannada culture, I am paying out of pocket. If Kannadigas wish to help us with the list and get paid for it, please contact me. Vasil stanev1982 (talk) 16:08, 1 December 2025 (UTC)

Tech News: 2025-49

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 Wikipedia Year in Review 2025 will be available on December 2 for users of iOS and Android Wikipedia apps, featuring new personalized insights, updated reading highlights, and refreshed designs. Learn more on the review's project page.
• The Growth team is working on improving the text and presentation of the Verification Email sent to new users to make them more welcoming, useful and informative. Some new text have been drafted for A/B testing and you can help by translating them. See Phabricator.
• Add a link will now be deployed at Japanese, Urdu and Chinese Wikipedias on December 2. Add a link is based on a prediction model that suggests links to be added to articles. While this feature has already been available on most Wikipedias, the prediction model could not support certain languages. A new model has now been developed to handle these languages, and it will be gradually rolled out to other Wikipedias over time. If you would like to know more, please contact Trizek (WMF).
• View all 34 community-submitted tasks that were resolved last week. For example, the issue where search boxes on some Commons pages showed no results due to switch from SpecialSearch to MediaSearch, has now been fixed. [7]
• Two new wikis have been created:
  • a Wikipedia in Toki Pona (w:tok:) [8]
  • a Wikiquote in Nigerian Pidgin (q:pcm:) [9]

Updates for technical contributors

• Detailed code updates later this week: MediaWiki

In depth

• The Wikimedia Foundation is in the early stages of exploring approaches to Article guidance. The initiative aims to identify interventions that could help new editors easily understand and apply existing Wikipedia practices and policies when creating an article. The project is in the exploration and early experimental design phase. All community members are encouraged to learn more about the project, and share their thoughts on the talk page.

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

MediaWiki message delivery 18:57, 1 December 2025 (UTC)

The European Concert in the Eastern Question/Chapter 2

I've been trying hard to try and match the up the opening and closing tags on this, but it's managed to defeat me, Can someone please roll this and the Pages all the way back to the last STABLE version, and actually FIX the lints, instead of the back end and linter managing to confuse me continually?

It would of course be very nice if the linter actually told me WHERE the Lint arose from.. But in checking back and forth by manually expanding out the transclusion ranges, it's just made the situation worse :(

This needs to be rebuilt from a clean version at this point.

I am distinctly discouraged from continuing to care, if it's going to take an entire day to fix what should be a VERY SIMPLE opening or closing tag to add. ShakespeareFan00 (talk) 21:08, 2 December 2025 (UTC)

ws-export seems to be broken

Tracked in PhabricatorTask T411747

Trying to download any works from Wikisource either gives me the error: "This web service cannot be reached. Please contact a maintainer of this project." or it gets to the Anubis screen, says "Speed: 0kH/s", and eventually fails with "invalid response" after waiting on a reply from the server. I'm using a regular web browser (Firefox) so it shouldn't have any trouble with Anubis. Anyone else having this problem? Nosferattus (talk) 06:14, 3 December 2025 (UTC)

I have not been able to download for a couple of weeks. At first, I had wondered if it was just a problem with my connection. Is anybody able to download ? -- Beardo (talk) 14:09, 3 December 2025 (UTC)

@Samwilson: Is ws-export something that you can help with? It seems to be broken. Most often, I just get the "This web service cannot be reached." error. Nosferattus (talk) 04:40, 4 December 2025 (UTC)

@Nosferattus, @Beardo: I've opened task T411747 and got the site back online for now. The issue is not resolved though. Sam Wilson 05:24, 4 December 2025 (UTC)

Wiggly rule

Does someone know if we have this wiggly rule separating the headlines: File:DeB. Randolph Keim's Despatch (New York Herald excerpt Sep 18, 1863).jpg RAN (talk) 17:24, 5 December 2025 (UTC)

Use the wave parameter of {{Custom rule}}. Beeswaxcandle (talk) 17:27, 5 December 2025 (UTC)

• Thanks! --RAN (talk) 21:48, 5 December 2025 (UTC)

Tech News: 2025-50

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

• Anybody who wishes to secure their user account can now use two-factor authentication (2FA). This is available to all registered users of all Wikimedia projects. This is part of the Account Security initiative. Later, 2FA will be required for all users who can take security- or privacy-sensitive actions.

Updates for editors

• Following last week's deployments, the Add a link feature, which allows editors to add suggested links during editing, will be available to an additional 33 Wikipedias starting on 9 December. This expansion is possible thanks to the new prediction model that now supports all languages, including those that were previously not covered. While the feature has been available on most Wikipedias for some time, this rollout brings us closer to using the improved model everywhere. If you have any questions or would like more details please contact Trizek (WMF).
• Last week, the Search Platform team added transliterated as-you-type search suggestions to Georgian wikis. If there are only a few regular search suggestions, then queries in Latin or Cyrillic script are now rewritten into Georgian script to look for more matches. For example, searching for either bedniereba or бедниереба will now suggest the existing article about ბედნიერება ("happiness"). You can recommend other languages where transliterated suggestions would be useful on Phabricator for future development.
• Later this week, a controlled experiment will begin for editors on the 100 largest Wikipedias who are editing a section in the mobile web visual editor. 50% of these editors will notice a new "Edit full page" button that will enable them to expand their editing session to the whole page. This feature is intended to make it easier for people on mobile web to edit any article section, regardless of which section-edit icon they tapped to begin. The experiment will last ~4 weeks. You can find more details about the project.
• Later this week, the Reader Growth team will launch a mobile web experiment to expand all article sections by default (currently they are collapsed by default) and pin the section header the user is currently reading to the top of the page. The experiment will affect 10% of users on Arabic, Chinese, French, Indonesian, and Vietnamese Wikipedias. [10]
• The Wikipedia Year in Review 2025, a feature in the Wikipedia mobile apps (iOS and Android) that provides users with a personalised summary of their engagement with Wikipedia over the year, is now available on the iOS and Android apps. This edition includes expanded personalised insights, improved reading highlights, new donor messaging, and updated designs. Open the app to view your Year in Review and explore your reading journey from 2025.
• A recent software bug caused edits made with VisualEditor to make unintended changes to wikitext, including removing whitespace and replacing spaces with underscores in wikilinks inside citations. This was partially fixed last week, and further fixes are in progress. Editors who used VisualEditor between November 28 and December 2 should review their edits for unexpected modifications. [11]
• View all 23 community-submitted tasks that were resolved last week. For example, the incorrect handling of URLs copied from the address bar of Microsoft Edge users, has been resolved. [12]

Updates for technical contributors

• Starting this week, users of the "Improved Syntax Highlighting" beta feature will have CodeMirror as the editor for Lua, JavaScript, CSS, JSON and Vue content models, instead of CodeEditor. With this, the linters will be upgraded. This is part of a larger effort to eventually replace CodeEditor and provide a consistent code editing experience. [13]
• Developers are encouraged to take the 2025 Developer Satisfaction Survey, which remains open until 5 January 2026. If you build software for the Wikimedia ecosystem and would like to share your experiences or feedback, your participation is greatly appreciated. [14]
• There is no new MediaWiki version this week.

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

MediaWiki message delivery 17:45, 8 December 2025 (UTC)

Inconsistent/misleading dates in Index:The Girl From the Marsh Croft-1916.djvu

The current PotM is a book published in 1916. It consists of a series of short stories (might be chapters, I haven't read it). It seems to have a problem, presumably linked to data in Wikidata, in that each short story has a date of 1910 in the header, which is clearly not consistent with the publication date of the book.

Also, I thought that for multi-chapter/section works, the publication date should only appear on the main space transclusion. Chrisguise (talk) 06:42, 9 December 2025 (UTC)

@Chrisguise: I fixed all of these instances, since you're absolutely right that these are incorrect uses of the Wikidata items. For subwork version items, within collections, the date should match the collection's date. The hierarchy: subwork version is part of collection version (not collection work). The original Swedish short story collection seems to have been from 1908, with the first English translation being from 1910 (according to Wikipedia), but this particular version/translation of the collection is from 1916, so all the subwork versions from it inherit that specific year. SnowyCinema (talk) 07:06, 9 December 2025 (UTC)

Confusion often occurs when the printing date and copyright date are different. What determines the date of an edition? Is in the initial print date? The copyright date? The date of the print run? And the answer to those questions might be different for different works / translations.

In the case of Loeb Classics, for example, the date on the title page is the date of the print run, even when the edition is identical in content and series volume number to earlier impressions. I have one such volume where the colophon indicates the initial print date, seven dates of reprints, the date the text was first emended, then two dates the emended text was reprinted. Most people would consider that list to consist of only two editions: the original text and the emended text. But there are nine additional impression dates. Wikidata has the means to recognize the two differing editions, but no setup for tracking the reprints without either making them independent editions or consolidating them with the editions they are part of. --EncycloPetey (talk) 08:56, 9 December 2025 (UTC)