Wikisource:Scriptorium/Archives/2024-01

New Hathitrust Works

It hasn't been opened yet, but this list is the 1928 books in English being freed at HathiTrust. Prosfilaes (talk) 01:51, 1 January 2024 (UTC)

The Lost World (1925 film)

Happy new year!

The film The Lost World has been ruined as the webm file is deleted in Commons. Is it possible for a bot to move the index Index:TheLostWorldSilent.webm and all related pages to fix the film transcription? M-le-mot-dit (talk) 09:40, 1 January 2024 (UTC)

Done

Mpaa (talk) 18:21, 1 January 2024 (UTC)

Thanks Mpaa. M-le-mot-dit (talk) 19:02, 1 January 2024 (UTC)

Article mislocated in userspace, possibly of a user needing help

While answering a question over at the Wikipedia Reference Desk, I noticed that our copy of the 1977 Soviet constitution has a link at the top to the same constitution after the 1988 amendments. The 1988 version is located at User:Glide08/Sandbox/Constitution of the Soviet Union (1977, Fully amended), which is in userspace. I am reluctant to simply move the page into mainspace because there does not appear to be a clear source (but I'm not sure exactly what the Wikisource policies are). User:Glide08 might need some mentoring about how to contribute constructively, but as this is my first post here, I am not sure of the procedures myself. M.R.Forrester (talk) 16:45, 1 January 2024 (UTC)

I out it in userspace because it was incomplete. It's not sourcebacked anyway so you can safely delete it. 2.53.185.71 17:02, 1 January 2024 (UTC)

Showing a file as an older revision of it

In trying to fix an ongoing issue with certain film transcriptions being out of sync, because a newer version of the film was uploaded at Commons, I thought of a possible fix—to have the video point to an older version of the same file. Is that possible? For example, at The Wizard of Oz (1925 film), the revision of the video that that transcription relies on is the one from 22 May 2016. PseudoSkull (talk) 12:22, 2 January 2024 (UTC)

Sounds similar to when you upload a new version of a scan and the pages are offset from the old one. I'd probably treat it the same way, and see if someone at Wikisource:Bot requests can update all the links —Beleg Tâl (talk) 21:04, 2 January 2024 (UTC)

@Beleg Tâl: Oh, I could do things like that myself, but to clarify on the situation, that's unfortunately not the straightforward solution this time. Most of the desynced films, such as with The Wizard of Oz (1925), re so out of sync that it's impossible to merge them without some human input—in other words, we'd have to retranscribe the films from scratch. And it's a pain to do it that way (and there are other issues with the video file The Wizard of Oz, such as the fact that it is considerably shorter and includes extra content but misses some content from the earlier revision, etc., so even the video itself will presumably need to be edited to include all the film's known content...somehow). So, I'm trying to think of a solution that we can use for now, while those future retranscriptions haven't been done yet.

The issue is that readers or editors who try to verify the content in the existing version of the film will find that the timestamps are completely off. And this wouldn't happen if we just made it display the earlier revision (for now). So I wanted to see if there's a way we can use the [[File: syntax to somehow do this. Or maybe there's some Lua code or MediaWiki logic markup that can do it? PseudoSkull (talk) 21:17, 2 January 2024 (UTC)

 Comment For a complete list (of all the cases I know of), see Category:Film transcriptions with out-of-sync timestamps. PseudoSkull (talk) 21:22, 2 January 2024 (UTC)

@PseudoSkull: In general the answer is no, and that would in any case not be a sustainable solution. But this type of problem is why we have c:COM:OVERWRITE. Xover (talk) 08:19, 3 January 2024 (UTC)

Do you use Wikidata in Wikimedia sibling projects? Tell us about your experiences

Note: Apologies for cross-posting and sending in English.

Hello, the Wikidata for Wikimedia Projects team at Wikimedia Deutschland would like to hear about your experiences using Wikidata in the sibling projects. If you are interested in sharing your opinion and insights, please consider signing up for an interview with us in this Registration form.
Currently, we are only able to conduct interviews in English.

The front page of the form has more details about what the conversation will be like, including how we would compensate you for your time.

For more information, visit our project issue page where you can also share your experiences in written form, without an interview.
We look forward to speaking with you, Danny Benjafield (WMDE) (talk) 08:53, 5 January 2024 (UTC)

Template:Interwiki-info

The template {{Interwiki-info}} is supposed to add extra text to interwiki links, but I do not see any text added in pages where it is used. Do I miss anything or does it not work as intended? -- Jan Kameníček (talk) 15:53, 5 January 2024 (UTC)

Tech News: 2024-02

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

Recent changes

• mediawiki2latex is a tool that converts wiki content into the formats of LaTeX, PDF, ODT, and EPUB. The code now runs many times faster due to recent improvements. There is also an optional Docker container you can install on your local machine.
• The way that Random pages are selected has been updated. This will slowly reduce the problem of some pages having a lower chance of appearing. [1]

Changes later this week

• The new version of MediaWiki will be on test wikis and MediaWiki.org from 9 January. It will be on non-Wikipedia wikis and some Wikipedias from 10 January. It will be on all wikis from 11 January (calendar). [2][3]

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

MediaWiki message delivery 01:19, 9 January 2024 (UTC)

Template:Index progress bar error message

Tracked in PhabricatorTask T354820

Recently, an error message is being displayed on all pages using {{Index progress bar}}. The error message is as follows: Lua error in ProofreadPage.lua at line 84: attempt to index upvalue 'qualityStats' (a number value). -- Bodhisattwa (talk) 04:46, 11 January 2024 (UTC)

@Bodhisattwa: Thanks for letting us know (and to Sam for the quick patch)! Xover (talk) 05:42, 11 January 2024 (UTC)

Lua error still on the Main Page

Anyone have an idea when the Lua error in ProofreadPage.lua at line 84: attempt to index upvalue 'qualityStats' (a number value). will be fixed and no longer display on the Main Page? Despite the previous thread and claimed patch,it's still displaying on the Main Page as of right now. --EncycloPetey (talk) 19:27, 13 January 2024 (UTC)

If I'm understanding the release process here (I very well may not) it looks like the bugfix for this is part of MediaWiki 1.42.0-wmf.14, set to be deployed starting 16 Jan 2024. The previous release (1.42.0-wmf.13) began installations on 9 Jan and this problem appeared on 11 Jan. That might suggest this will be fixed around Thursday, 18 Jan. Brad606 (talk) 19:56, 13 January 2024 (UTC)

@EncycloPetey: I'm on it. Just so everyone is aware, the problem seems to be that a variable named "qualityStats" coming in from the ProofreadPage API, that is expected to be a table value, but is coming in as a numbered value. I'm messing around to see if there's something we can do temporarily to keep the error from coming up. PseudoSkull (talk) 20:02, 13 January 2024 (UTC)

The release process is on a weekly cycle. Wikis are divided into three groups—group 0, 1, and 2—that are upgraded on Tuesday, Wednesday, and Thursday of the relevant week. Group 0 is mediawiki.org and test wikis. Group 1 is all non-Wikipedia sites (including Commons), plus a few "canary in the coal mine" smaller Wikipedias. And Group 2 is all the Wikipedias. This happens pretty much every week, with the exception of the obvious big holidays (Christmas etc.). So if you see big honkin' error messages, or the site goes down, towards the latter half of a Wednesday you can pretty much bet that a whole bunch of SREs are having their pagers go off right then. They can fix problems by deploying code outside this cycle (and pretty much every week they do deploy various emergency fixes after the normal deployment train), but doing that is resource intensive and has some risk associated with it so where possible they prefer to wait for the following week's normal release train. Xover (talk) 10:27, 14 January 2024 (UTC)

@EncycloPetey: So, after lots of examination, I was able to "fix" it. It's not a real fix though—all it does is take the error off of the Main Page if one ends up popping up. So, now, instead of showing bright red text when the {{Index progress bar}} or the like is called, it shows nothing.

I understand if some other coders here may not agree with this change, since this may keep us from detecting errors easily in the future. But, I thought it would be good as a temporary workaround, so feel free to revert at any point if you think it's inappropriate. But, it was the best I could do, since the problem really is underlying in the ProofreadPage extension, which is not in my hands.

Because of the concern about error detection in future cases, it would probably be a good idea to revert back to the revision before I started working on it in any case once the bigger issue with ProofreadPage is resolved.

And those of you more experienced with the MediaWiki Lua environment may chuckle at the fact that I didn't know this, but I couldn't even get the value that was coming in for "qualityStats" to debug it with. Even using "index:" at all was causing the red error to show immediately, so there was nothing I could figure out to get the actual value of qualityStats. So, I have no idea what the meat of the issue is. PseudoSkull (talk) 20:45, 13 January 2024 (UTC)

The error is triggered in ProofreadPage.lua when the underlying PHP module returns an incorrect data structure (an array instead of an array of arrays), so there's nothing we can do to avoid it or catch it short of wrapping it in pcall() as you've done here. In future it would be better to just disable the relevant template on the main page (since it's the only page we really care about in this case), which I should have done last week but I assumed they'd backport the fix and push it out of cycle. In any case, the fix will roll out here on Wednesday sometime during US business hours, so by Thursday we should be back to normal. Xover (talk) 10:13, 14 January 2024 (UTC)

Missing page

Hi! Is there any way to add a missing page to an index page? The index is based on a PDF file and some of it's pages have been proofread by the users. Yousef (talk) 20:22, 14 January 2024 (UTC)

It's not just a question of the Index, you have to fix the PDF as well. This is what the Scan Lab is for. You can request help with this process. --EncycloPetey (talk) 21:18, 14 January 2024 (UTC)

Tech News: 2024-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.

Recent changes

• Pages that use the JSON contentmodel will now use tabs instead of spaces for auto-indentation. This will significantly reduce the page size. [4]
• Gadgets and personal user scripts may now use JavaScript syntax introduced in ES6 (also known as "ES2015") and ES7 ("ES2016"). MediaWiki validates the source code to protect other site functionality from syntax errors, and to ensure scripts are valid in all supported browsers. Previously, Gadgets could use the requiresES6 option. This option is no longer needed and will be removed in the future. [5]
• Bot passwords and owner-only OAuth consumers can now be restricted to allow editing only specific pages. [6]
• You can now thank edits made by bots. [7]
• An update on the status of the Community Wishlist Survey for 2024 has been published. Please read and give your feedback.

Changes later this week

• The new version of MediaWiki will be on test wikis and MediaWiki.org from 16 January. It will be on non-Wikipedia wikis and some Wikipedias from 17 January. It will be on all wikis from 18 January (calendar). [8][9]
• Starting on January 17, it will not be possible to login to Wikimedia wikis from some specific old versions of the Chrome browser (versions 51–66, released between 2016 and 2018). Additionally, users of iOS 12, or Safari on Mac OS 10.14, may need to login to each wiki separately. [10]
• The jquery.cookie module was deprecated and replaced with the mediawiki.cookie module last year. A script has now been run to replace any remaining uses, and this week the temporary alias will be removed. [11]

Future changes

• Wikimedia Deutschland is working to make reusing references easier. They are looking for people who are interested in participating in individual video calls for user research in January and February.

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

MediaWiki message delivery 00:12, 16 January 2024 (UTC)

Recto-verso header not working

{{rvh}} is not displaying the verso recto title. RaboKarbakian (talk) 20:46, 15 January 2024 (UTC)

It's working on the pages where I see it used. --EncycloPetey (talk) 21:26, 15 January 2024 (UTC)

EncycloPetey: Hmm. I thought it would work when I got rid of some "|", but I guess my use of it is still wrong. See Page:The_Floral_Fortune-teller.djvu/32 --RaboKarbakian (talk) 12:23, 16 January 2024 (UTC)

Okay, no formating the page number and I had the recto and verso backwards. So, fixed. And, EncycloPetey, knowing it was my problem was a very big help! Thank you.--RaboKarbakian (talk) 12:51, 16 January 2024 (UTC)

Please unlock Author: Sukavich Rangsitpol

The page was lock and also discussion page Education for All Thai People (talk) 12:01, 17 January 2024 (UTC)

Under what rationale? The Author page was protected because of a repeated and persistent pattern of copyright violations. --EncycloPetey (talk) 16:21, 17 January 2024 (UTC)

@EncycloPetey, @Xover: I've finally blocked the user. The edits seemed disruptive, and their comments barely had any rationale to them or made any sense. They were often so badly formatted, too, that they looked like vandalism from a distance. And the end goal of it all was to, in line with the similar behavior some previous sockpuppets of the user, promote some biased viewpoint on our site, or reinstate copyrighted material previously deleted. It's clear to me they're not here to build a repository of free texts, and they were getting annoying. PseudoSkull (talk) 20:59, 17 January 2024 (UTC)

Refresh Special:DoubleRedirects?

I'm creating a bunch of double redirects, and I'd like to take care of them, but Special:DoubleRedirects isn't updating fast enough. Does anyone know if there is a way to force it to update? —Beleg Tâl (talk) 16:45, 17 January 2024 (UTC)

These Special: pages just update on a periodic cycle (as I recall, weekly), so you can't force update them without access to the server. —Justin (koavf)❤T☮C☺M☯ 17:05, 17 January 2024 (UTC)

It is normally every three days, it seems. There's a bot that clears the problems later that day. -- Beardo (talk) 19:45, 17 January 2024 (UTC)

ppoem and Help:Poetry

My understanding of Template:ppoem is that it's basically an improved version of the poem extension. Despite this, Help:Poetry doesn't mention it at all (I had to see it being recommended elsewhere on the wiki to know about it); should we update the page to focus on the ppoem template? Arcorann (talk) 10:13, 8 January 2024 (UTC)

I would first want to know that it's been checked out by additional code-savvy admins. The poetry tag is pretty poor to begin with, so "improved version of the poem extension" is a low bar. --EncycloPetey (talk) 16:43, 8 January 2024 (UTC)

Well at least one admin thinks it's fine, since it's on Help:Page breaks. Arcorann (talk) 07:36, 18 January 2024 (UTC)

Inductiveload made it and I've been both testing and using it extensively. In my experience it can deal with 99% of the actual poetry I run across easily and elegantly, and works well with all the sub-templates (small-caps first word etc.) needed. Abuses of poem tags for things that are not actually poetry is not a good use for ppoem, and advanced / complicated poem formatting may still require other solutions (e.g. I haven't tested it with things like The Yale Shakespeare yet; it might work but I haven't tested). So, for whatever it's worth, I heartily and strongly recommend that everyone use {{ppoem}} by default for poetry, and only switch to something else if they have to. I'm also happy to try to help if any of you advanced users of poetry stuff wants to start testing it out.

It's biggest drawback (IMO) is that it requires a different mental model than everything else on the site. Each invocation of {{ppoem}} is complete unto itself on a given page, and if the content spans multiple pages you tell each instance of {{ppoem}} to adjust its behaviour using |end=stanza and |start=stanza (or continue or follow). This in contrast to most of our page spanning templates where we rely on selective transclusion using the header and footer fields. Having something behave differently is confusing for users; but on the other hand the model works very well and is a lot clearer and easier to understand in itself (modulo being different). I think this is a very worthwhile tradeoff. Xover (talk) 09:47, 18 January 2024 (UTC)

Invitation to join January Wikisource Community Meeting

Hello fellow Wikisource enthusiasts!

We are the hosting this month’s Wikisource Community meeting on 27 January 2024, 3 PM UTC (check your local time).

As we gear up for our upcoming Wikisource Community meeting, we are excited to share some additional information with you.

The meetings will now be held on the last Saturday of each month. We understand the importance of accommodating different time zones, so to better cater to our global community, we've decided to alternate meeting times. The meeting will take place at 3 pm UTC this month, and next month it will be scheduled for 7 am UTC on the last Saturday. This rotation will continue, allowing for a balanced representation of different time zones.

As always, the meeting agenda will be divided into two halves. The first half of the meeting will focus on non-technical updates, including discussions about events, conferences, proofread-a-thons, and collaborations. The second half will delve into technical updates and conversations, addressing major challenges faced by Wikisource communities, similar to our previous Community meetings.

If you are interested in joining the meeting, kindly leave a message on klawal-ctr@wikimedia.org and we will add you to the calendar invite.

Meanwhile, feel free to check out the page on Meta-wiki and suggest any other topics for the agenda.

Regards

KLawal-WMF, Sam Wilson (WMF), and Satdeep Gill (WMF)

Sent using MediaWiki message delivery (talk) 10:54, 18 January 2024 (UTC)

Informing you about the Mental Health Resource Center and inviting any comments you may have

Hello all! I work in the Community Resilience and Sustainability team of the Wikimedia Foundation. The Mental Health Resource Center is a group of pages on Meta-wiki aimed at supporting the mental wellbeing of users in our community.

The Mental Health Resource Center launched in August 2023. The goal is to review the comments and suggestions to improve the Mental Health Resource Center each quarter. As there have not been many comments yet, I’d like to invite you to provide comments and resource suggestions as you are able to do so on the Mental Health Resource Center talk page. The hope is this resource expands over time to cover more languages and cultures. Thank you! Best, JKoerner (WMF) (talk) 21:42, 18 January 2024 (UTC)

Tag for acceptable use of initials in author page

I put together a quick concept for tagging author pages that use initials but don't need further action. This will help ensure we don't waste time trying to research names of people that don't need to be researched. You can see an example at Author talk:Harry S. Truman. Let me know what you all think. —Beleg Tâl (talk) 01:22, 19 January 2024 (UTC)

Great job! But, I wonder if it's time to use some Lua code in our Author header template that will automatically mark author pages with {{initials}} unless explicitly stated otherwise. Here's some pseudocode for what that would look like:

-- assumes the inclusion of an optional "initials_accepted" parameter in {{author}}
-- this parameter would be to limit the template on pages where it has been deemed acceptable to use the initials
if parameters["initials_accepted"] then
   return ""
end
   
-- Checks if an author title starts with an initial, or has an initial in it. If so, puts the template on the page.
if r"^[A-Z]\." in author_title or r" [A-Z]\." in author_title then
   return "{{initials}}"
end

(We also should consider making use of {{authority control}} an automatic thing on every author page, if it's not a subpage in the Author space or a redirect. This should be an easy implementation.) PseudoSkull (talk) 01:46, 19 January 2024 (UTC)

I'm hesitant to build this into the header directly. For one, this tag often goes on the Talk page, which is unaffected by the Author template. I especially think that tags for acceptable initials should go on the Talk page. That said, it's a good idea and worth further discussion. Maybe it should be its own discussion? —Beleg Tâl (talk) 14:46, 19 January 2024 (UTC)

Do we have a lot of those cases? There's S. up above, and I can think of an X. an E. and an M. But is it really common enough to merit a separate tag vs. just dropping a manual note on the relevant author talk page? Xover (talk) 05:27, 19 January 2024 (UTC)

I just had a minor edit conflict over Author:Joseph B. Sindelar because I mistakenly flagged it with {{initials}} for a second time despite it having been already noted as a correct use of initials. So I do think that it is worth using the template. You'll note that it isn't really a separate tag; it's just a mechanism for adding a manual note inside the {{initials}} template that also automatically recategorizes it for ease of maintenance. —Beleg Tâl (talk) 14:40, 19 January 2024 (UTC)

PseudoSkull -> SnowyCinema

I was "PseudoSkull", but not anymore. If you must know why, it's because I thought it suited me better. Just so everyone is aware, in case of any confusion. SnowyCinema (talk) 10:14, 19 January 2024 (UTC)

Vote on the Charter for the Universal Code of Conduct Coordinating Committee

You can find this message translated into additional languages on Meta-wiki. Please help translate to your language

Hello all,

I am reaching out to you today to announce that the voting period for the Universal Code of Conduct Coordinating Committee (U4C) Charter is now open. Community members may cast their vote and provide comments about the charter via SecurePoll now through 2 February 2024. Those of you who voiced your opinions during the development of the UCoC Enforcement Guidelines will find this process familiar.

The current version of the U4C Charter is on Meta-wiki with translations available.

Read the charter, go vote and share this note with others in your community. I can confidently say the U4C Building Committee looks forward to your participation.

On behalf of the UCoC Project team,

RamzyM (WMF) 18:09, 19 January 2024 (UTC)

CropTool

Does anyone know why this has stopped working? It was doing fine a couple of days ago but now it tries to load, then returns "504 The CropTool backend is currently having problems." Chrisguise (talk) 17:42, 22 January 2024 (UTC)

Tech News: 2024-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.

Problems

• A bug in UploadWizard prevented linking to the userpage of the uploader when uploading. It has now been fixed. [12]

Changes later this week

• The new version of MediaWiki will be on test wikis and MediaWiki.org from 23 January. It will be on non-Wikipedia wikis and some Wikipedias from 24 January. It will be on all wikis from 25 January (calendar). [13][14]

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

MediaWiki message delivery 01:03, 23 January 2024 (UTC)

RfC close

I'm not entirely familiar with Wikisource's policies on when closing a discussion is appropriate, but this RfC should almost certainly be closed by an experienced editor, since the last actual comment was in 2015 (there have been a few minor formatting edits since then). Thanks, Cremastra (talk) 14:22, 21 January 2024 (UTC)

Can we just get rid of RfC, period? No one ever uses it or takes it seriously, and all the discussions there have been sitting there forever. We have the Scriptorium, which seems fine and is used more. For proponents of RfC who will undoubtedly take issue with this suggestion, I challenge you with this question: If RfC is so handy, why is it ignored? Do we need to create more incentive not to ignore it? If not, it's practically a distraction. SnowyCinema (talk) 14:27, 21 January 2024 (UTC)

Although, I'd like to suggest we make a new WS:Scriptorium/Proposals subpage, because the Proposals section on this page is also barely ever used (and hard to find amongst all the other clutter). But we don't need an RfC, that was a carbon-copy of Wikipedia and Meta's systems that aren't necessary in a small project like ours, and this is exactly why. SnowyCinema (talk) 14:37, 21 January 2024 (UTC)

• I think (1) all currently extant requests for comment should be formally closed, (2) all of those requests for comment should be archived, (3) the current requests for comments page should be marked as historical, (4) a note is added to the process header on that page about the “proposals” section, (5) the “proposals” section here is moved to SnowyCinema’s Wikisource:Scriptorium/Proposals page, (6) the “proposals” section here is removed, and (7) a note is added at this page’s process header about the new “proposals” sub-page. When I have sought to create proposals in the past, I have always used the “proposals” section on this page, but I think that it would be better as a general matter to have most discussions on this page be archived automatically, while discussions about proposals should be archived manually (after a formal closure to the discussion). Thus, I agree that it is appropriate to split the “proposals” section off from this page. TE(æ)A,ea. (talk) 21:50, 21 January 2024 (UTC)

  This sounds like a good plan. Cremastra (talk) 21:02, 23 January 2024 (UTC)

Hover text on page status radio buttons

Hello, I am a long-time Wikipedia editor but new to Wikisource. I also do not have full color vision. I think it would be helpful if the "page status" radio buttons on the edit page would have hovertext explaining what they represent, both for unfamiliar users and those without color vision. Please feel free to point me to a proper location for discussion, if here isn't the right place. Thank you.-Ich (talk) 12:21, 23 January 2024 (UTC)

@Ich: The lacking accessibility of these radio controls is a known issue, that's just taking a long time to get fixed. Sorry.

To the degree it helps their layout is somewhat logical once you understand the page status system. On most pages there will be four radio buttons in the order "No text", "Not Proofread", "Problematic", and "Proofread". On pages that are already in the "Proofread" state, there will be a fifth radio for "Validated". When a page is initially created it will either be empty ("No text") or not fully proofread yet ("Not Proofread", or a rough draft). In the next step you either mark it as "Problematic" due to a missing image, mathematical formula, illegible text, etc.; or you finish it up as fully "Proofread". Already proofread pages might be returned to the previous states if a problem is discovered, or they can be progressed to "Validated" if this is a second person checking it. Xover (talk) 15:12, 23 January 2024 (UTC)

@Ich: Actually, you know what… This inaccessibility is just too dumb to let stand. I've hacked up a local workaround so that now you should at least get a tooltip with the associated text (provided your web browser displays title attributes). Still no real help for those using a non-visual user agent (JAWS etc.), but it's hopefully better than nothing. Xover (talk) 15:54, 23 January 2024 (UTC)

Way cool! Thanks for your fast response. I would assume proofreading must be done by people using browsers that support images, even if not color.-Ich (talk) 16:54, 23 January 2024 (UTC)

Broken links at Special:BookSources

When searching some ISBN using Special:BookSources, there are 7 varions links offered, out of which 3 do not work. These are: Internet Book Database, Internet Book List, and OttoBib.com. Can they be removed from the search? -- Jan Kameníček (talk) 00:17, 27 January 2024 (UTC)

Done with Special:Diff/13823186 Vahurzpu (talk) 03:32, 28 January 2024 (UTC)

PD-self

Is the template {{PD-self}} appropriate for the Translation namespace? Is {{PD-release}} favorable? The template's statement of "I hereby ...", in the first person, seems to go against Wikimedia stances on neutrality. Is an exception made for the Translation namespace?

I'm gonna let those who are interested in "Translation" material sort out this detail. SnowyCinema (talk) 16:40, 23 January 2024 (UTC)

For translations, we need both a template for the original and for the translation. For the translation, I would use {{GFDL/CC-BY-SA-3.0}} as directly fitting with requirements. I would not use {{PD-self}} for anything except a work that I had published somewhere else, then released here. --EncycloPetey (talk) 16:56, 23 January 2024 (UTC)

In the Translations namespace, {{Translation license}} automatically populates the license for the translation as {{GFDL/CC-BY-SA-3.0}}. In my opinion, using any other license is unwise, since future editors won't realize they need to change the license to match their own contributions. —Beleg Tâl (talk) 18:21, 29 January 2024 (UTC)

Actually I just realized, it should be {{GFDL/CC-BY-SA-4.0}}—I've updated the template accordingly :) —Beleg Tâl (talk) 18:26, 29 January 2024 (UTC)

But the example on {{Translation license}} uses {{PD-self}}. --EncycloPetey (talk) 18:31, 29 January 2024 (UTC)

Duplicates Index.

Index:Medicine and the church.djvu and Index:Medicine and the church; being a series of studies on the relationship between the practice of medicine and the church's ministry to the sick (IA medicinechurchbe00rhodiala).pdf appear to be the same edition? Not sure how we handle this. ShakespeareFan00 (talk) 20:05, 24 January 2024 (UTC)

And Index:Seven of the most popular songs (2).pdf and Index:Seven of the most popular songs (3).pdf seem to be different scans of the same edition. I guess one of the duplicates should be redirected/deleted? Or is some kind of merge possible? Cremastra (talk) 02:00, 25 January 2024 (UTC)

Speedied as redundant and file nominated for deletion at Commons. Mpaa (talk) 22:23, 25 January 2024 (UTC)

• For Medicine and the Church, the first one should be kept; the second index was one of Languageseeker’s mass-uploads. For the two chapbooks, those were a part of the NLS Scottish chapbooks project from a while ago; we got all of the marked duplicates, but some weren’t marked (like these). TE(æ)A,ea. (talk) 02:29, 25 January 2024 (UTC)

  File:Medicine and the church.djvu is at Commons, File:Medicine and the church; being a series of studies on the relationship between the practice of medicine and the church's ministry to the sick (IA medicinechurchbe00rhodiala).pdf is local and says 'do not move to Commons'. This should be sorted out. Both are Languageseeker’s mass-uploads. Mpaa (talk) 22:15, 25 January 2024 (UTC)

  Delete both and start again with KNOWN version then. ShakespeareFan00 (talk) 23:46, 25 January 2024 (UTC)

Personally, I think you can use {{speedy}} for duplicate indices. —Beleg Tâl (talk) 18:32, 29 January 2024 (UTC)

There are now three deletion discussions going on for Medicine and the Church. This one, one at WS:PD, and one on Commons. This is basically forum shopping. Please close two of the discussions and centre all discussion in a single place. Nominating a file for deletion at Commons prior to a decision here is poor practice and adds further complexities. In this case there are hundreds of page links to the files as they have both had a match&split done. The automatic deletion the file on Commons 7 days after nomination is going to cause a bigger mess here than we already have. Please start to think about the consequences of your actions before you take them—which is something I've been saying to you for 11 years now. Beeswaxcandle (talk) 17:52, 26 January 2024 (UTC)

I've withdrawn the other two deletion requests. Can someone now please make a decision about which SINGLE file to maintain ( I favour the DJVU.) and localise that SINGLE file? ShakespeareFan00 (talk) 18:00, 26 January 2024 (UTC)

The edition can't be hosted at Commons (due to a small portion that's not out of UK copyright). That was the basis of the Commons DR (now withdrawn). We have bothe a PDF and DJVU version. As I said above it may be just be more strghtforward to delete both and start again with a KNOWN local upload. ShakespeareFan00 (talk) 18:08, 26 January 2024 (UTC)

Was either work transcluded yet? ShakespeareFan00 (talk) 18:12, 26 January 2024 (UTC)

I will also mention that I had previously mentioned the PDF amongst other 'localisation' requests-

Wikisource:Scriptorium/Archives/2021-06#Scan_Localisation_requests_.... It was moved in response to investigations in 2021,

ShakespeareFan00 (talk) 18:41, 26 January 2024 (UTC)

It seems the same contributor that was working on it in March 2021 and in October 2021. It was 'localised' in June 2021, Then in October of 2021 the djvu copy was uploaded on Commons, and was worked on by the same contributor as in March @Languageseeker:

@Beeswaxcandle: These aren't just the same edition, there are both from the same IA location, One is PDF and one DJVU. Because the file was localised with a different filename and format, Commons would not have detected that it was in fact a duplicate, when the djvu was uploaded to Commons at a later date I can't find any main-space transclusion references for either the PDF or DJVU versions, on a quick check.

You stated in the withdrawn request at ws:PD that the djvu version should be the one retained. I agree with that position, assuming that the scans are complete. It would need someone with admin rights to transfer it from Commons though.

ShakespeareFan00 (talk) 18:41, 26 January 2024 (UTC)

Please ignore the struck out portion, I seem to having a lot of confusion. I'm now too confused to continue, can someone please sit down and carefully summarise the upload dates for each version?

ShakespeareFan00 (talk) 18:51, 26 January 2024 (UTC)

• ShakespeareFan00: DJVU uploaded (on Commons) in October 2021; PDF uploaded (locally) in March 2021. The indexes were created at the same time as the upload. So, the PDF has priority in terms of age. However, I prefer the DJVU (in terms of file quality). So, you should get that file localized, and the mark the PDF (and index) as duplicates of the DJVU. TE(æ)A,ea. (talk) 00:15, 27 January 2024 (UTC)

Fonts

Do we have a comprehensive list of what fonts are available at Wikisource? RAN (talk) 19:09, 26 January 2024 (UTC)

Available as templates, you mean? Technically, we're limited to anything CSS can provide. Our cursive and blackletter fonts are both quite complex amalgamations of custom CSS styles, for example. SnowyCinema (talk) 19:17, 26 January 2024 (UTC)

Do you mean a list of available typefaces installed as webfonts for use with ULS? I am not sure there is a 'default' list other than those used for ULS. ShakespeareFan00 (talk) 19:33, 26 January 2024 (UTC)

Can someone with more knowledge than me start: Wikisource:Typography ? It can be modeled on Wikipedia:Wikipedia:Typography. RAN (talk) 23:00, 26 January 2024 (UTC)

That Wikipedia page is an essay, and notes that its contents are highly controversial. Are you proposing to import an essay on a controversial issue here? Keep in mind also that Wikipedia is creating original content, which is not what we are doing here. For our purposes, we have Help:Fonts. --EncycloPetey (talk) 23:17, 26 January 2024 (UTC)

I believe this page lists all webfonts currently available to use via {{ULS}}. —Beleg Tâl (talk) 18:15, 29 January 2024 (UTC)

Tech News: 2024-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.

Recent changes

• Starting Monday January 29, all talk pages messages' timestamps will become a link. This link is a permanent link to the comment. It allows users to find the comment they are looking for, even if this comment was moved elsewhere. This will affect all wikis except for the English Wikipedia. You can read more about this change on Diff or on Mediawiki.org. [15]
• There are some improvements to the CAPTCHA to make it harder for spam bots and scripts to bypass it. If you have feedback on this change, please comment on the task. Staff are monitoring metrics related to the CAPTCHA, as well as secondary metrics such as account creations and edit counts.

Changes later this week

• The new version of MediaWiki will be on test wikis and MediaWiki.org from 30 January. It will be on non-Wikipedia wikis and some Wikipedias from 31 January. It will be on all wikis from 1 February (calendar). [16][17]
• On February 1, a link will be added to the "Tools" menu to download a QR code that links to the page you are viewing. There will also be a new Special:QrCode page to create QR codes for any Wikimedia URL. This addresses the #19 most-voted wish from the 2023 Community Wishlist Survey. [18]
• Gadgets which only work in some skins have sometimes used the targets option to limit where you can use them. This will stop working this week. You should use the skins option instead. [19]

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

MediaWiki message delivery 19:31, 29 January 2024 (UTC)

Fialure of hi-res image load script -

I was using a script of Inductiveload's to get hi-quality scan images, but it seems to have stopped working here:- Page:A Critical Dictionary of English Literature - Volume 1 (1871).pdf/803

Perhaps someone can look at the script and work out why? ShakespeareFan00 (talk) 22:33, 30 January 2024 (UTC)

The relevant script is documented here - https://en.wikisource.org/wiki/User:Inductiveload/jump_to_file#Loading_high-res_images ShakespeareFan00 (talk) 22:39, 30 January 2024 (UTC)

Last days to vote on the Charter for the Universal Code of Conduct Coordinating Committee

You can find this message translated into additional languages on Meta-wiki. Please help translate to your language

Hello all,

I am reaching out to you today to remind you that the voting period for the Universal Code of Conduct Coordinating Committee (U4C) charter will close on 2 February 2024. Community members may cast their vote and provide comments about the charter via SecurePoll. Those of you who voiced your opinions during the development of the UCoC Enforcement Guidelines will find this process familiar.

The current version of the U4C charter is on Meta-wiki with translations available.

Read the charter, go vote and share this note with others in your community. I can confidently say the U4C Building Committee looks forward to your participation.

On behalf of the UCoC Project team,

RamzyM (WMF) 17:00, 31 January 2024 (UTC)

PD works with non-PD scans

I'm considering working on a transcription of The Richest Man in Babylon (1926, so PD-US), but the scans that I've seen online so far seem to come from later editions (or are reconstructed from transcripts of unknown provenance). Is there a policy on what to do in this situation? Arcorann (talk) 10:43, 2 January 2024 (UTC)

@Arcorann: You'll have to search and find a valid scan of an edition that is in the public domain in the US. If you are set on this work, you can try asking on WS:Scan Lab or to User:TE(æ)A,ea here. Ciridae (talk) 11:39, 2 January 2024 (UTC)

@Arcorann: Yes, the scans available online are all far from preferable to a scan closer to the original. As far as policy goes, it is possible (but very messy) to take out the non-free elements, but in a digital edition from the 2010s it's very difficult to discern what is an original element and what isn't if you have nothing to compare it to. So I wouldn't recommend this method. Try to get a scan from the year 1926, and pinging @TE(æ)A,ea.: PseudoSkull (talk) 11:54, 2 January 2024 (UTC)

• Arcorann: You can find the original text here. I’ll see if I can get a copy of the original to scan, but the handling office is closed until mid-January, so you’ll have to wait for at least that long. TE(æ)A,ea. (talk) 15:36, 2 January 2024 (UTC)

  Thanks. I have a few other things to work on in the meantime so I don't mind waiting. Arcorann (talk) 07:39, 3 January 2024 (UTC)

  • Arcorann: For whatever reason, I can’t find any bibliographical details about the 1926 publication. However, soon after that a collection of three of Clason’s “Babylon” works was published, and the copyright for the collection was not renewed, so it is also in the public domain. See here: File:The Richest Man In Babylon (1930).pdf. I have also scanned the images from this copy in high quality; once you’re ready to proofread this work, I can upload them temporarily to let another user with knowledge of image-modification work produce color-corrected and adjusted images. TE(æ)A,ea. (talk) 21:51, 2 February 2024 (UTC)

    Thanks. Based on your response I've looked into it myself and found that the 1926 dating is likely wrong; according to another source, the short stories that make up the book version began in 1926, with the compilations coming out as Gold Ahead (9 chapters) in 1937 and The Richest Man in Babylon (11 chapters + foreword/afterword) in 1955. I have no idea where Wikipedia got its dates from but I'll have to flag it. At any rate, since we only have three of the eleven chapters in this version it's short enough that proofreading should be straightforward (~40 pages of text). Arcorann (talk) 10:43, 4 February 2024 (UTC)

Duplicates: Index:The Lord's prayer in five hundred languages, comprising the leading languages and their principal dialects throughout the world, with the places where spoken (IA lordsprayerinfiv00rost).pdf] and Index:The Lord's Prayer in Five Hundred Languages (Full).djvu?

PDF seems to be higher quality scans?ShakespeareFan00 (talk) 00:33, 29 January 2024 (UTC)

You mean this - Index:The Lord's prayer in five hundred languages, comprising the leading languages and their principal dialects throughout the world, with the places where spoken (IA lordsprayerinfiv00rost).pdf. -- Beardo (talk) 01:36, 29 January 2024 (UTC)

Yes, I might have made a typo? :( ShakespeareFan00 (talk) 05:59, 29 January 2024 (UTC)

The .pdf has a colour cover, whilst the .djvu has a later note from another company which took over the publishing. Do we want to preserve that note ? -- Beardo (talk) 17:12, 4 February 2024 (UTC)

Updates to Template:RunningHeader

Hey, everyone! @Xover and I have been working on migrating {{RunningHeader}} to Lua. Since this is such a widely-used template, we wanted to make sure the community was given a heads-up about these changes. We're doing our best not to break anything, but if we do, people should know who to contact. The current plan for migration (with testing after every step) is:

1. Change Template:RunningHeader/styles.css to Template:RunningHeader/styles/sandbox.css.
2. Make {{RunningHeader}} use Module:Running header (like {{RunningHeader/sandbox}} but using the main style sheet instead of the sandbox style sheet). Functionality changes: removes the unused style parameter, supports more than four cells in a header.
3. Check/fix pages in Category:Running headers with more than four entries.
4. Make sure Category:Running headers applying manual styles is still empty, then remove the code applying it from the module.
5. Update wst-running-header to wst-rh in index CSS and other pages.
6. Remove the wst-running-header class from the module.
7. Remove the old styles from the style sheet.
8. Check/fix pages in Category:Empty running headers and Category:Running headers with undefined entries.
9. Go through pages in Category:Running headers with one entry and Category:Running headers with two entries, converting to the standard three-cell invocation of {{rh}}. This will enable the next step.
10. Remove the code that enforces a three-cell minimum and adds Category:Running headers with one entry, Category:Running headers with two entries, and Category:Running headers with more than four entries. This will mean that if you only use two parameters in a running header, they will be left- and right-aligned, and if you only use one parameter, it will be centered.

    Edit: better to keep the tracking categories, I think.

11. Make all the other templates using {{rh/core}} use {{rh}}.
12. Migrate uses of the rh/n templates to {{rh}}.
13. Delete unused templates and tracking categories.

We'll keep this thread updated throughout the process. If you have questions/comments about the code or these planned updates, want to add to Template:RunningHeader/testcases, or notice any problems, please get in touch! —CalendulaAsteraceae (talk • contribs) 09:32, 3 January 2024 (UTC)

CalendulaAsteraceae: For 10, the two-entry running header should be left- and center-aligned, like current practice. TE(æ)A,ea. (talk) 14:13, 3 January 2024 (UTC)

I had forgotten to mention it (thank you, Jan Kameníček), but I also don’t think that any templates should be converted to Lua—and that includes templates which have already been converted. TE(æ)A,ea. (talk) 17:50, 3 January 2024 (UTC)

@TE(æ)A,ea.: Two questions which I hope will elucidate our respective philosophies (feel free to propose alternatives if you don't think these questions are useful):

• Do you think we should use Lua for anything?
• How would you prefer to implement the templates currently supported by Module:PD-US-notice?

—CalendulaAsteraceae (talk • contribs) 00:12, 4 January 2024 (UTC)

CalendulaAsteraceae: (1) No templates which are not for entirely internal use should utilize Lua. All templates displayed on public-facing pages—that is, templates which editors would add to Page:, Index:, Author:, (Main:), &c.—should use MediaWiki-enhanced HTML and CSS alone. Templates for entirely internal purposes, templates which are the basis of bot work, and templates and code for personal use may all use Lua; but no editor should need a knowledge of Lua (quite an esoteric language) to be able to understand a template in general use. (2) I don’t know why all of the license templates (or many of them, at least) were migrated to Lua modules, but it was an unnecessary action, and the templates which were in use beforehand were (a) usable and (b) did not rely on Lua. The old system, of all license templates being a modification of a base license template, was not only easy to understand but also a logical division. The opaque and entirely Lua-dependent system now in practice makes license templates a complete mystery to anyone trying to understand a license template or create a new template for some purpose. As other editors have mentioned, where large portions of work on Wikisource are dependent on a single editor or a small group of editors (whether in the maintenance of a specific, highly-used bot, or in the creation and maintenance of Lua code in place of MediaWiki templates), the overall, long-term functionality of Wikisource as a Wiki system is heavily weakened. TE(æ)A,ea. (talk) 04:00, 4 January 2024 (UTC)

The license templates are a bad example to extrapolate from. They looked easy when all you ever saw was a single license template at a time, but when you look at the sum of them you'd find a ton of logic spread out in different templates and often repeated in different templates. The current Lua implementation faithfully reproduces all the quirks of the templates, and as such it is almost equally complicated as the templates were. But the Lua implementation can and will be improved, unlike the myriad old templates. The biggest challenge there isn't really technical: it's that some of the changes are going to require the community to adapt how they use them, and that's always a slow process even in the best case scenarios, as well as some risk of stuff breaking while the changes are made which is kinda "noisy" for so widely-used templates.

You are also somewhat turning the issue on its head: Lua is not in any reasonable sense an esoteric language, unlike MediaWiki templates which are entirely specific to MediaWiki. Case in point, I had never previously used Lua until I came across it here, but because it is a general programming language with many similarities to other programming languages I was able to pick up on it quickly. Anyone with some programming experience is going to be able to understand Lua and make simple changes fairly quickly. The same is most definitely not true of any non-trivial use of MediaWiki templates. By implementing something in Lua rather than MediaWiki template syntax you are increasing the pool of technical contributors that can help out. And perhaps more to the point, you are making it easier for those technical contributors to do so (i.e. you get more technical maintenance for the same amount of technical contributor time). And that's not even getting into the fact that a lot of things are literally not possible to do in raw template syntax. Xover (talk) 09:08, 4 January 2024 (UTC)

Xover: I don’t see how the Lua implementation of the licence templates is an improvement, just as I said in my previous comment; under the old system, you could look at an individual license template, look at the general template, understand the scheme, &c., all of course without knowing Lua. Another problem, as a general matter, is that these are changes are being undertaken, so far as I can tell, without (and possibly even against) general consensus—as if they were neutral, ministerial changes to a template’s wording or implementation, and not fundamental rewritings of large swaths of code (especially as these rewritings are in an esoteric language). On that note: while Lua may not be an esoteric language among the world of computer programmers (although I had certainly never heard of it), it is quite esoteric among Wikisourcerors, for whom computer programming is not a requirement. However, a basic knowledge of MediaWiki is a general requirement, and that knowledge can be easily expanded (and easily applied) by looking at templates &c. However, with the switch to Lua, this general base of knowledge is removed, and that is highly objectionable. As to “increasing the pool,” again, that claim only applies to all Internet users, not necessarily people on Wikisource; and on Wikisource, a switch to Lua makes everything with which the module is concerned a useless and unfixable “black box” of esoteric code not used anywhere else on Wikisource. TE(æ)A,ea. (talk) 14:40, 4 January 2024 (UTC)

 Comment Well, generally speaking, I am quite unhappy about more and more stuff getting dependent on a handful of techy people, fearing of times when they realize they are not able to maintain everything, while for others it will be out of their reach. --Jan Kameníček (talk) 16:53, 3 January 2024 (UTC)

I understand this as a general concern, but I have to say, I don't think the current code for {{rh}} is especially straightforward or easy for non-techy people to work on either. It's already doing a bunch of complicated logic with parser functions, which is by necessity more complicated and forces arbitrary constraints on the number of cells because wikitext doesn't have variables. —CalendulaAsteraceae (talk • contribs) 23:42, 3 January 2024 (UTC)

 Comment a) Picking up on Te(æ)A,ea.'s comment: when I come across running headers with an empty 3rd parameter I simplify back to two with the intention of left and centre. If I need left and right only, there will be an empty second parameter. b) Please verify that uses of the template in the body of pages continue to work; i.e. the template is not just being used for page headers, but also to ease page layout, for example in image captions. c) Please verify that scripts that produce automatic running headers from our individual js pages will continue to work. Beeswaxcandle (talk) 18:14, 3 January 2024 (UTC)

@Beeswaxcandle, I've added some uses of {{rh}} in the work body to Template:RunningHeader/testcases. I hope this covers all the cases you're concerned about, but please add more if not. I'm also happy to try out scripts that produce automatic running headers if you can tell me what they are/how I can use them. —CalendulaAsteraceae (talk • contribs) 23:27, 3 January 2024 (UTC)

Have a look in my common.js for the scripts that I'm using. The section starting "special formats for proofreading tools" and the following chunk of pathoschild.templatescripts Beeswaxcandle (talk) 20:38, 8 January 2024 (UTC)

Thank you! —CalendulaAsteraceae (talk • contribs) 20:40, 8 January 2024 (UTC)

@Beeswaxcandle: We're going to have come up with an alternative for the use cases for {{rh}} in the page body, not necessarily now but in the long term. The template is designed for running headers and needs to be able to make certain assumptions about the context it is being used in in order to function well. The biggest problem in making a replacement for use in the body is that the cases are so variable and ad hoc: what in the world would we call such a template, and what would its defining concept be? I've seen letter signatures, numbered equations, an alternative to tables, and a bunch of others.

The good news though is that if we can make the {{rh}} uses general (i.e. the two-argument vs. three-argument issue) we can probably also generalise and reuse a lot of the underlying code for making horizontally distributed constructs. So we could have special templates for letter signatures and numbered equations and so forth, without having to replicate the same code in all of them and try to keep that in sync, if that turned out to be the best solution. Xover (talk) 09:22, 4 January 2024 (UTC)

In terms of page body uses, I principally use {{rh}} when I need a left and right on the same line. Mostly image captions (e.g. Page:Moving Picture Girls at Oak Farm.djvu/6) where I want to constrain the width at the same time. The main alternative of a table in this context is unwieldy and the current version of {{rh}} behaves perfectly. I can't think of a letter signature where I have used {{rh}}; I would normally use {{right}} with an right margin indent. Beeswaxcandle (talk) 20:31, 8 January 2024 (UTC)

CalendulaAsteraceae:

in {{RunningHeader/sandbox}}, the case with 5 args does not work for me, I do not see 'right' arg, only the other 4.

OK, I think I got it, this is still the current one, right?. Anywhere we can compare current vs. new?

I already shared my perplexity about the 2-arg change. I understand the logic but changing a long-established interface will conflict with people' 'muscle memory'. I am ambivalent on this point.Mpaa (talk) 18:34, 3 January 2024 (UTC)

You can compare current vs. new at Template:RunningHeader/testcases. —CalendulaAsteraceae (talk • contribs) 23:29, 3 January 2024 (UTC)

Since several people have asked about #10: I think that after the 'muscle memory' transition period, it will actually be more intuitive for the number of cells to just be directly determined by how many parameters are put in. This is already how the template determines whether there are 3 or 4 cells—I'd like to extend this so it also works for more than 4 cells, and then so that it works for 1- and 2-cell headers. Why make those be special cases when it's the same underlying concept no matter how many cells there are?

To be clear, if you want to have cells be present but blank, it will still work to include the appropriate number of blank parameters, e.g. {{rh|left|center|}} or {{rh|left|center||}} —CalendulaAsteraceae (talk • contribs) 02:44, 4 January 2024 (UTC)

Just to have an idea, I made a very rough analysis. To convert from 2-cell headers to 3-cell headers is about 100k edits. Mpaa (talk) 12:24, 6 January 2024 (UTC)

Thank you for checking! I think @Xover will be able to get most of them with a bot once we have tracking categories. —CalendulaAsteraceae (talk • contribs) 04:58, 7 January 2024 (UTC)

No, sorry, it is not reliable, I took an xml dump with full history. Forget about it. Mpaa (talk) 22:28, 9 January 2024 (UTC)

@Xover: not sure if you have alerts on for this thread, pinging you in case you don't. Concerns brought up so far:

• @Jan.Kamenicek and @TE(æ)A,ea. are concerned about Lua use (step 2).
• @TE(æ)A,ea., @Beeswaxcandle and @Mpaa are concerned about making the number of cells in a header be determined by number of input parameters (step 10).
• @Beeswaxcandle is concerned about whether the template will still work in page bodies. It looks fine on Template:RunningHeader/testcases, but we'll keep an eye out.
• @Beeswaxcandle wants to make sure that individual scripts that insert running headers will still work.
  • Per this search,the following users have on-wiki scripts related to running headers. I'm looping them all in here so they can comment if desired.

  @Alex brollo, @Apsaltini, @Assassas77, @Beeswaxcandle, @Beleg Tâl, @BethNaught, @BewareofDoug, @Billinghurst, @Bodhisattwa, @Borneanape, @Cygnis insignis, @DefrostedKevin, @DeirdreAnne, @Dictioneer, @DivermanAU, @Genoskill, @Griceylipper, @Gumr51, @Inductiveload, @Ineuw, @Jfhutson, @Jiaozi17, @Jimregan, @Jpez, @Kaiserwilliam, @Kbseah, @Londonjackbooks, @Maximillion Pegasus, @Mike Peel, @Mpaa, @Ostrea, @Peteforsyth, @Phoenixsparks11, @Pslits, @Ryuch, @ShakespeareFan00, @Simpliexme, @Sp1nd01, @Spangineer, @Steven Crossin, @Takashihakase, @Truchas13109, @Xxagile

  • The only problem I expect to arise is that users may have scripts that currently insert one- or two-cell headers, which will no longer work the same way after step 10.

—CalendulaAsteraceae (talk • contribs) 20:53, 8 January 2024 (UTC)

@CalendulaAsteraceae: Most of these users are not currently active (so pinging them is pointless), and user scripts (and TemplateScripts patterns) must be updated some times to keep working (don't break them needlessly, but if necessary…). That old user scripts insert an old version of the template until they're updated is not a very bad failure mode either (most of these seem to insert an otherwise empty three-argument running header, so they won't even break).

More relevant is Help:Gadget-RunningHeader because Gadgets have a higher expectation of maintenance. It's also likely that some people are still running the precursor at User:Inductiveload/Running header.js. Neither of these are possible for non-admins to fix, and both could potentially (but not necessarily) break completely.

All of which is to say that I'd probably ignore any user script for any user that's currently inactive; check user scripts of active users to see if they actually will be affected by the changes (what to do depends on what you find); and make sure the one actual Gadget will keep working (by pestering an interface admin if needed). Xover (talk) 16:54, 11 January 2024 (UTC)

@Xover: Thank you, that's helpful advice. MediaWiki:Gadget-RunningHeader.js and User:Inductiveload/Running header.js look like they'll probably be fine, but I'm not that proficient in regex or JS so I could be wrong. Certainly I can enable the gadget, test things, and bug @Inductiveload if I run into problems.

User scripts (of active users) which will be affected because they insert an old version of the template:

• User:Beeswaxcandle/common.js
• User:Beleg Tâl/proofreading.js
• User:Billinghurst/common.js
• User:Ineuw/proofreading.js
• User:Jpez/common.js
• User:Kbseah/common.js
• User:Mpaa/common.js
• User:Mpaa/works.js
• User:Ostrea/proofreading.js
• User:Peteforsyth/Regexp toolbar.js
• User:ShakespeareFan00/JWB-settings.json

User scripts (of active users) which I don't understand well enough to tell if they'll be affected:

• User:Inductiveload/cleanup.js
• User:Londonjackbooks/common.js

—CalendulaAsteraceae (talk • contribs) 23:39, 12 January 2024 (UTC)

OK, it does look like Help:Gadget-RunningHeader will insert a two-cell running header if the previous (or one-before-previous, etc.) page had a two-cell running header. This seems like it's probably fine, since we're going to update all the existing pages which use two-cell headers before we change how two-cell headers behave: once the behavior has been changed, the only pages with two-cell running headers will be the pages that are supposed to have them. (The gadget doesn't do great with recto-verso swaps for two-cell headers, but this is already an issue for four-cell headers, and in any case won't affect the vast majority of headers, which are three-cell.) —CalendulaAsteraceae (talk • contribs) 00:27, 14 January 2024 (UTC)

There is a conceptual conflict between the testcases and the statement in #10 above. #10 says that two parameters will give left and right; but the examples in the testcases are giving left and centre. And similarly for one parameter (centre vs. left). If the testcases are the actual proposed end state, then there is no problem other than the wording of #10. Beeswaxcandle (talk) 20:50, 8 January 2024 (UTC)

@Beeswaxcandle: Thanks for asking about this! The testcases are not the proposed end state; they are the proposed intermediate state after steps 1 and 2. I've added {{RunningHeader/sandbox 2}} (using Module:Running header/sandbox and Template:RunningHeader/styles/sandbox 2.css) to Template:RunningHeader/testcases to show the proposed end state. —CalendulaAsteraceae (talk • contribs) 21:08, 8 January 2024 (UTC)

{{RunningHeader}} is now based on Module:Running header. I will be reviewing existing uses of the template for compatibility before making any further changes. —CalendulaAsteraceae (talk • contribs) 20:25, 6 February 2024 (UTC)

Works with no license tag

I put together a PetScan query for works that are missing license tags, and was shocked to discover that the number was well over 10,000 works with no license tag. I've been flagging a bunch with {{no license}}, but of course that barely scratches the surface. If anyone wants to help add license tags, or flag pages with missing tags for later review, I think that would be a valuable contribution to this site. —Beleg Tâl (talk) 20:13, 31 January 2024 (UTC)

• For some of us, running the query repeatedly is time-consuming, so having the works tagged makes them much easier to find. Perhaps you could tag all of the oldest ones? Such as all those created before 2010, at least as a start. --EncycloPetey (talk) 20:52, 31 January 2024 (UTC)

  That's a good idea. There are a few hundred before 2010, but I'll get started at least. —Beleg Tâl (talk) 21:09, 31 January 2024 (UTC)

  Ok, I figured out how to get the list from PetScan into AutoWikiBrowser, so I think I can programatically flag the rest of them from here :) —Beleg Tâl (talk) 14:46, 3 February 2024 (UTC)

Speaking of {{no license}}—I think its wording is a bit misleading, as many works do contain license information somewhere (the most common being simply a date prior to 1929!), so I think we should reword it to be more accurate. Does anyone object to this? —Beleg Tâl (talk) 20:16, 31 January 2024 (UTC)

• What revised text do you suggest? --EncycloPetey (talk) 20:49, 31 January 2024 (UTC)

  Something like this maybe:

  This page does not have a license tag.

  All works are required to be tagged with a template that identifies their license status according to Wikisource's copyright policy. You can help by adding a license tag to this work. For more information, see Help:Copyright tags.

  The most important changes to be made are 1) that the page has no license tag (even though it might have "license information"), and 2) that the appropriate action is to add a license tag (rather than to nominate for deletion) —Beleg Tâl (talk) 21:01, 31 January 2024 (UTC)

I agree with this change. I'd also suggest that the red exclamation mark and the placement at the top are overkill, if the primary intended audience is human wiki editors, as opposed to readers. It seems a bit much for a reader to see such a visually strong banner for an item that may have no copyright concerns whatsoever, but just needs a 2 minute review by an experienced wiki editor. I'd suggest a convention of placing the banner at the bottom (which I believe also accomplishes the most important goal, of putting the page into a relevant category) and changing its color and visual style to be slightly less alarming. -Pete (talk) 02:36, 2 February 2024 (UTC)

I've hunted a little for an overview of template iconography, and I've come up short. But possible alternatives would be the orange exclamation mark used on {{No source}} or the broom used on {{cleaning}}. -Pete (talk) 00:20, 3 February 2024 (UTC)

I feel that the red exclamation is warranted. If the work has no license info at all, which is one reason for the tag, then the page is indeed in danger of deletion. --EncycloPetey (talk) 01:24, 3 February 2024 (UTC)

I agree. A lack of license tag is a major issue, and a big bold red exclamation mark right at the top is a very appropriate warning to the reader that the text they are reading is not in compliance with our license requirements and requires further action. —Beleg Tâl (talk) 02:27, 3 February 2024 (UTC)

I have difficulty following the logic. It seems to me, each of the 10,000 pages this applies to have two things in common: (1) one person made the implicit determination that the page does meet Wikisource's criteria, and put at least a few minutes of effort into it; (2) a different person, who may have put seconds or less of consideration into it, has asserted that the page might not meet Wikisource's criteria, because any assertion of its copyright status is inadequately expressed. Is there any scenario in which a reader is well served by an alarming banner, which appears to make a strong assertion? Have they received information that is significant? reliable? -Pete (talk) 05:30, 3 February 2024 (UTC)

I don't follow the logic you use to assert point (1). The lack of a license does not mean that someone concluded the work meets WS:WWI --EncycloPetey (talk) 07:30, 3 February 2024 (UTC)

My logic is very simple: This is a large number of pages that we are labeling without much consideration; we don't know much about the individual page. A red exclamation point at the top of the page is out of step with the fact that very little human consideration has gone into the placing of the banner. You can disregard the part about the judgment of the original uploader, it's merely context, not significant to my point.

Several pages in my watchlist were tagged this way last night. Every one of them was from the 19th century; all but one of them was clearly published in the 19th century, and the remaining one was PD due to death date of author. All of them were scan-backed, which means that in addition to whatever scrutiny there may or may not be at Wikisource, the file at Commons has not been identified as having a copyright problem.

Personally, when I visit a site that makes a strong claim that something is under copyright when it is clearly not, I find myself irritated with the site operators. I feel poorly served by their metadata and inclined to disregard what they have to say. I appreciate sites whose comments about copyright appear to accurately reflect the amount of effort and research they put into making the determination. I would rather Wikisource is more like that. -Pete (talk) 20:37, 3 February 2024 (UTC)

I don't believe in relying on negative evidence. A lack of identified problems at Commons should not lead us to assume that everything is fine. Works should have a clear statement of their copyright status, as checked by someone who has investigated the facts. The tag being added is a cleanup tag, letting folks know that this requirement has not been met, despite that fact that Policy requires it: "It is the responsibility of the contributor to assert compatibility with Wikisource's license. A template should be used on the source material page to indicate the license that the source material is posted under (see Help:Copyright tags)." If the template isn't there, then the contribution is in violation of one of the most important policies here on Wikisource. I cannot ascribe to the lackadaisical approach to core policy expressed in your comments. --EncycloPetey (talk) 21:53, 3 February 2024 (UTC)

I never claimed that presence on Commons was a guarantee, nor can I see how you would assign such a silly notion to me. Also not a guarantee: a tag on Wikisource. -Pete (talk) 00:35, 7 February 2024 (UTC)

Are users well-served? Yes, because they can expect to have clear license information and one of the best ways to get there is having uniformity rather than trying to craft a bunch of exceptions that make maintenance difficult. I understand that tagging a work from 1800 or author who died in 1750 as {{PD-old}} or a bunch of court cases and legislation as {{PD-GovEdict}} seems annoying and repetitive but if we want people doing maintenance activities it is far easier to find works which are missing tags rather than asking people to repetitively crawl through 1000s of "missing tags but that's okay" works to find the problematic ones. I think there is consensus that we shouldn't be removing license tags from such works. MarkLSteadman (talk) 06:31, 7 February 2024 (UTC)

I don't know if this sub-thread is cursed or what, it's weird to see multiple people I know to be intelligent and well meaning assign such bizarre opinions to me. Like, if you're going to respond to me, maybe start by reading my words? -Pete (talk) 07:32, 7 February 2024 (UTC)

• The template should not be mass-added at all, especially if the person mass-adding the template (Beleg Tâl) can easily determine what the license tag for any given item is. TE(æ)A,ea. (talk) 15:46, 3 February 2024 (UTC)

  That doesn't make any sense at all. It's a maintenance tag, and there is no reason not to place it on all the pages it applies to. Not mass-adding it is a ridiculous amount of manual work for no reason. —Beleg Tâl (talk) 16:02, 3 February 2024 (UTC)

  • Beleg Tâl: Especially since you know about it, please stop doing it. The problem is mass-adding the tag everywhere, all at once. It’s completely pointless to add the tag and then remove it, when the license could have just been added in the first place. There is clearly not consensus in this discussion for you to use a bot to mass-add the template. Please stop doing it. TE(æ)A,ea. (talk) 16:05, 3 February 2024 (UTC)

    Ok fine, it's stopped. Sorry @EncycloPetey: I guess you're gonna have to go off the PetScan query after all and look at each one manually because some people don't like maintenance tags for some stupid reason. —Beleg Tâl (talk) 16:07, 3 February 2024 (UTC)

    Because apparently being able to identify 10000 pages that require a license tag, must mean I am able to identify what tag all 10000 pages require all at once, because I am omniscient and magical or something idk —Beleg Tâl (talk) 16:09, 3 February 2024 (UTC)

    Honestly, when everyone objects to bringing works up to even the very basic standard of acceptableness then why do I even bother —Beleg Tâl (talk) 16:11, 3 February 2024 (UTC)

    My understanding is that the main page of works in the Main NS are expected to provide a. A header, b. sourcing information and c. a license. and that any work missing any of those should generally expect to be tagged with {{no header}}, {{no source}} or {{no license}} respectively. MarkLSteadman (talk) 00:06, 4 February 2024 (UTC)

    Yes! This is exactly the way it is supposed to be! —Beleg Tâl (talk) 16:55, 4 February 2024 (UTC)

    • Beleg Tâl: Your above comments are about as good as an answer as you’ll get. TE(æ)A,ea. (talk) 16:13, 3 February 2024 (UTC)

      I see no consensus against mass-adding the tag to these pages here. I see one objection that should be explored, during which process mass action should be paused, but without prejudice to resuming once done. Xover (talk) 17:06, 3 February 2024 (UTC)

Is it possible to do this in stages? 1. Deal with the scan-backed works first. To have uploaded a file to Commons, there has to be a valid licence. Translate those across and autopopulate. 2. Then deal with non-scan-backed works with a claimed date prior to 1929. These should be able to be dealt with relative ease as they are very likely to be PD. 3. Finally look at everything else, which is the stuff that will require research. That way we can focus on the works with real problems. Beeswaxcandle (talk) 17:24, 3 February 2024 (UTC)

My experience is that a scan on commons with a license tag there is no guarantee it's correct. There is one person on Commons, specifically, who I know has been mass importing scans from IA, and simply putting a Commons-compatible license without actually checking that the license is correct or that the work is legally hostable on Commons. I've had to nominate more than one of those uploads for deletion. --EncycloPetey (talk) 17:45, 3 February 2024 (UTC)

Even with bad licensing it is typically far, far easier to resolve licensing for a work backed by scans since then at least we have a known edition to start from or to check if something is suspicious. Even if the work is anonymous and lacks a date, there is at least a clear title to start from... Given that we do have, typically, linked author information it might even be possible to identify the majority of bad commons info where the author death date information is incorrect. MarkLSteadman (talk) 23:08, 3 February 2024 (UTC)

@Beleg Tâl: Thank you for taking the initiative on this! I've been meaning to do the same for pages lacking license and pages lacking scans, since those are the two major groups of pages that are going to require coordinated community effort to bring up to basic modern standards. I think it's entirely possible to get both those backlogs down to effectively zero, and it would put us in a much better place for the future. Xover (talk) 08:03, 4 February 2024 (UTC)

I would suggest that some of the disagreement evident in this discussion derives from two different roles the banner can play: Is it (a) a maintenance tag or (b) meant to convey information to the reader? If it is intended to play both roles, it will be more complex (not necessarily impossible, but complex) to get it right. I'd urge some discussion around what we expect this banner to do. (Personally, it's been a good wake-up call to me; I had never read the part of the copyright policy that states it is a contributor's responsibility to add the tag. It's sensible, and I'm happy to adjust my bad habits; but making louder banners is not really helpful to that process. I think simply pointing out this portion of the policy to good faith editors who fail to comply would go a long way. I've been active here for 15+ years, and this is the first that provision of that policy crossed my radar; and a great many of the examples I see (among the 10,000 pages Beleg Tal identifies) do not comply either, so it was not incredibly obvious.) -Pete (talk) 20:43, 3 February 2024 (UTC)

The key question I have is: What are people going to do to help rectify the situation? The tagging has helped me to locate and begin rectifying the lack of required license templates. I've set myself an unofficial goal of adding a license to at least five such works each day, for the forseeable future. If I can manage just five per day, then I'll have fixed the issue for over 1500 works in a year's time. And, for me, having these works tagged for cleanup is a huge help. --EncycloPetey (talk) 22:00, 3 February 2024 (UTC)

And if six more do the same, the 10,000 will be covered in that year. -- Beardo (talk) 23:45, 3 February 2024 (UTC)

Maintenance tags are a call to action to anyone visiting the page, identifying a deficiency that needs to be rectified. The most common way readers become contributors on Wikipedia is seeing such a deficiency and correcting it (be it a typo or incorrect information or missing information or ...). In this particular case it also serves to warn potential re-users that the copyright status (and thus liability for re-use) of the text in question has not been properly assessed. I don't like lots of screaming maint. tags in pages either, but the way to avoid that is to work to actually fix the problems they're pointing out rather than pretending the problem isn't there. And what we're discussing here is an actually addressable problem, unlike, say, the many vague maint. tags used on enWP that just stay there forever (Someone once thought that this article had too few references somewhere. It was in 2006 and none of that text is present in the article now, but I'm sure this template is still relevant somehow.)

We used to have a "Maintenance of the Month" (to mirror the "Proofread of the Month") for large maintenance tasks like this that cannot be automated. We should maybe try to explore different ways we can get the community as a whole more involved in maintenance. Not necessarily by resurrecting the "Maintenance of the Month"; but perhaps we could use site notices and similar to direct attention to any current large task like this. Not all backlogs are going to be suited for divide and conquer, but as has been noted a lot of these texts are going to be fairly obvious provided some coherent sourcing information is present. With some instructions to help people along (Anything older than $CUTOFF is probably {{PD-US}}. Just make sure it's not a later translation that might still be in copyright. If there's no scan and no source tag it with {{no source}}. If you're uncertain ask for help using new-copyright-expert-needed-param-in-the-template. If it looks like a copyvio bring it to WS:CV for community discussion. If it looks incomplete tag it with {{incomplete}}. And so forth.), it should be eminently doable in a reasonable amount of time.

But all that starts with actually having the pages tagged so they can be identified and worked on. Xover (talk) 08:00, 4 February 2024 (UTC)

I agree with the main point here. Just want to add that it has the property also that I would imagine {{PD-old}} and {{PD-US}} would cover most of their needs and those that it doesn't (e.g. translations, non-renwals, edicts, etc.) should really have a tag, it may be worthwhile to think about adding information about those two to the default page creation screen. (e.g. "This page should include a {{header}} template." --> "This page should include a {{header}} template, and for base page, license information via a copyright tag such as {{PD-old}} or {{PD-US"}} MarkLSteadman (talk) 06:50, 7 February 2024 (UTC)

The discussions above seem incoherent to me. Several users seem to focus on several points that I think are not controversial, i.e. there is no disagreement, to the detriment an ability to have a straightforward, values-based discussion of the one area that I feel is most in need of attention and input from users with a diversity of perspectives. I don't have much time to devote to this, unless I start to see a shift where there is genuine interest in my perspective, rather than inaccurate objections based on things I never said. I think this chart, which I invite others to fill in if they like, highlights a problem in the discussion. (I'm not pointing a finger at anyone here, I am certainly among those who could have been clearer in my own prior communication.)

	1 Knows policy requires © tag	2 Endorses © requirement	3 Useful to categorize pages without © tag via template	4 Important to address backlog	5 Useful to give readers provisional info/advice where © tag not yet present
Pete F	YES	YES	YES	YES	*

I'm not aware of anyone who disagrees on points 1-4, so any discussion of it seems like a distraction from important discussion.

On point #5, I believe ANY library's communication in the editorial voice should be minimal, dispassionate in tone, and accurate. I think our current practices fail in all three of those areas. I think this is something that could be adjusted (and here's the important part) without significant compromise to any of the goals others have alluded to...to inform readers that there might be accuracy issues in the explicit copyright claims or even in the presence of the page a website with our copyright policy, to offer readers an opportunity to become editors, to provide infrastructure that supports and encourages editors to resolve a backlog.

Hopefully that clarifies things a bit. Separately, I'll acknowledge that I have added many pages to Wikisource over the years without a copyright tag. (I don't like to call them "licenses" since on Wikisource so many of them refer to the public domain, which is an assertion or explanation, not a license.) When this issue came up a week or two ago, I read the copyright policy more closely and recognized my error, and began fixing the issue. In total quantity, I have not added more than EncycloPetey has, but a high percentage of edits I've made to my site since then have been fixing such errors. While I can't commit to logging into the site every day, much less making five edits, I certainly appreciate the spirit of EncycloPetey's wish to address the backlog, and I intend to keep doing my part. -Pete (talk) 21:27, 7 February 2024 (UTC)

@Peteforsyth: You were indeed misunderstood above. Classic case of miscommunication when the discussion gets hectic, I'd say. But note that you're partially incorrect: there was one contributor who objected to the tagging, and I think that contributed to the misunderstanding. Your argument is also fairly subtle: the current template does conflict with your #5 above, so when you argue against that you are implicitly also arguing against adding the template (and the reader needs to infer that you are also arguing for changing the template to resolve your objection). Which all is a long way to say that I think it was a good idea to take a step back and formulate your position more explicitly and in more detail.

However, I do still disagree with your #5 because it removes the call to action and the open and fair information to our reusers. If we don't have our collective… stuff… together, we should be open and honest about that, and the unsightly maintenance tags should be addressed by actually assessing the copyright status and adding appropriate licensing information. I could maybe see an argument for a "silent" tag for new texts if it was automatically added by bot immediately after the page is created, because the first-line response to that is patrollers engaging with the contributor to remind them to add a license (i.e. it's a backlog on a much shorter timescale). But for a backlog like this we need to both communicate to the open-ended group of reusers and the broad group of existing community members. It is also very much (we must assume) a temporary situation: we've now identified a large chunk of texts that should have had license tagging but don't, but which are also very likely most of them ok and fairly easily determined to be so. That's an eminently addressable issue well suited for a concerted community drive to eliminate the backlog. And having some good common projects is a bonus for community collaboration and cohesion to boot. In other words, while I would obviously prefer not to have such a backlog in the first, I don't think tackling it head-on is a bad thing at all. Xover (talk) 08:55, 8 February 2024 (UTC)

Thanks for your effort to engage with what I'm saying here Xover. A few points:

• Your assertion that I'm incorrect boils down to a conflation between "Stop applying this template by unvetted automated process" (which reads to me like a pretty normal step in the BRD sequence), and "no template should be used to assist this administrative task." This strikes me as reflecting a very dim view of TE(æ)A,ea.'s intelligence and/or intentions.
• My first point in this discussion concerned the design of the template. It was in response to a point by Beleg Tâl about the design of the template. If that's too subtle for people to follow, I'm not sure what I can do. (I'm not trying to further a grievance here, I'm open to suggestions, but I'd request such feedback be on my user talk or by email. added 21:14, 8 February 2024 (UTC))
• If other people misunderstood my points, it's nice to hear you understand that. But in order to continue a productive discussion, it would help if that were acknowledged by the users themselves. I also make mistakes in discussion, and when they're pointed out to me, I do my best to acknowledge my error. I find that it helps with bringing the discussion back to something generative.
• I agree with most, perhaps all, of your component points above. But I disagree with what seems to be an inference that they support the notion that this banner applied in this way is specifically justified. Again, I support the idea of taking action. My only concern is that this banner applied in this way introduces new problems. This is a wiki, and it's in our power to improve banners. That's all I'm suggesting here. -Pete (talk) 18:41, 8 February 2024 (UTC)

I've made more specific observations at Template talk:No license#Improving this template. Again, I hope these can be taken as straightforward, generative suggestions, not dissent about basic shared principles that I strongly agree with. I'm un-watchlisting Scriptorium for a bit, but I'm happy to discuss further there or on user talk. -Pete (talk) 21:14, 8 February 2024 (UTC)

Sub-pages

At some point, I was told that individual stories within a magazine should not have a licence tag - that was for the magazine as a whole. However, I see a number of Weird Tales stories have been tagged as "no license". Which is correct ? -- Beardo (talk) 05:30, 5 February 2024 (UTC)

This case is not quite that simple. If all the stories/articles/whatever in a periodical are first published in that issue, then only the main page for the volume needs a licence. If, however, it is a collection of re-prints (or a mixture), then individual stories may need a licence that matches the original publication. Some of the Weird Tales issues post 1928 are mostly PD, but some of the stories aren't. Beeswaxcandle (talk) 05:50, 5 February 2024 (UTC)

It is not necessary if all the stories are by the same author, which is rare. I usually add licence tags to every individual text in magazines, as the deathyear parameter in {{PD-US|deathyear}} differs for every individual author. Besides, some stories can be translated, requiring to use {{translation license}}, where the "original" parameter usually differs for every story too. News magazines also often contain unsigned texts, requiring {{PD-anon-US}} tag. --Jan Kameníček (talk) 17:39, 5 February 2024 (UTC)

I'd also point out that we have a lot of works that are published in a magazine or other publication, but which are currently located on their own page rather than being subpages of the publication they are a part of. I excluded subpages from my original PetScan search (or tried to at least), but I think I did add {{no license}} tags to some Weird Tales stories that were not subpages of Weird Tales. I think that anything at top level needs to have a license tag, but it would be better to move these tales to subpages. —Beleg Tâl (talk) 02:03, 9 February 2024 (UTC)

Poems of John G. Whittier, Owen, Donne, Wesley, Keats

Noting that many (hundreds?) of these appear to be individual poems by John Greenleaf Whittier, who died in 1892. Seems like it might be fairly straightforward for somebody with slightly greater automation skills than myself to change add {{PD-old}} to every poem linked from that page, and remove {{no license}} if it's present. (Possibly also worth adding {{no source}}, but would need to confirm whether that applies to all or merely many of the linked poems.) -Pete (talk) 20:22, 14 February 2024 (UTC)

Same thing for poems by Wilfred Owen whose death date also justifies {{pd-old}}. These ones should not be indiscriminately tagged {{no source}}, as some of them are properly scan-backed to an anthology. (those ones may all be sub-pages, and if so they need not have their own {{PD-old}} tag.) Addressing these two sets of pages would take a big chunk out of the backlog and make it easier to focus on pages that require human review. -Pete (talk) 20:47, 14 February 2024 (UTC)

It would also be a very good thing is someone took on the task of finding published collections of these authors' poetry so that we can begin backing them with scans. Same for the poetry of John Donne. I'm finding that a significant fraction of works without a source or license is a poem by one of these three authors. --EncycloPetey (talk) 23:52, 14 February 2024 (UTC)

I think I could handle this with AWB. The copyright thing, not the source thing, the source thing is a different kind of problem, with that I don't think there's a way to lop off a bunch of a backlog with a semi-automated process. I'll mess with AWB and try a small number, and post back here for feedback before forging ahead with the full set. I'll add Donne to the list too, thanks for that. -Pete (talk) 07:41, 15 February 2024 (UTC)

Looks like somebody might have already taken on Whittier. I ran through a few of Charles Wesley's poems, such as this: Come, Let Us Join Our Friends Above Any feedback before I continue? (I don't see how to make the edit summary more specific. Tried a couple things but I'm not seeing a place to manually add text to the summary.) -Pete (talk) 17:57, 15 February 2024 (UTC)

I'm planning to resume this afternoon. Not seeing any feedback here or on my specific edits, but I think it's OK because I've taken a conservative approach. I'm not touching the "no source" issue with these edits, and even though the edit summaries could be more specific, I think they're clear enough for the purpose.

Also adding John Keats to the list. -Pete (talk) 18:21, 16 February 2024 (UTC)

With that Wesley, there is a scanned version at https://upload.wikimedia.org/wikipedia/commons/thumb/5/52/A_Collection_of_Hymns_%28Wesley%29.djvu/page672-1882px-A_Collection_of_Hymns_%28Wesley%29.djvu.jpg - I suspect that many of his others are likely to be there. -- Beardo (talk) 23:15, 16 February 2024 (UTC)

When the section header says "Poems of John G. Whittier", but the topic of the thread wanders from Whittier to Owen to Keaths to Wesley, and possibly more buried in the above conversation,, people paying attention to the thread header, or looking in the archive, will not spot the relevant information. If you're going to talk about something other than the topic in the thread header, please start a new thread. --EncycloPetey (talk) 23:43, 16 February 2024 (UTC)

Fair point. In an ideal world I think the same could be said for the expansion of scope from "no license" to "no source", considering we're in a subhead of the "works with no license" thread. I'm sure we could all do better. At the moment what's being done by me and you seems reasonably straightforward, so I'm not inclined to take up people's time with a new thread, but I don't mind if you do so.

Just as a progress update, I just ran the AWB on the full collection of Wesley poems linked on his author page. -Pete (talk) 00:26, 17 February 2024 (UTC)

I have set up Index:Complete Poetical Works of John Greenleaf Whittier (1895).djvu. --EncycloPetey (talk) 23:43, 16 February 2024 (UTC)

Done The individual poems referred to above have had {{no license}} templates replaced with {{PD-old}}. This has reduced the backlog of category:Works with no license template by several hundred pages. -Pete (talk) 05:10, 19 February 2024 (UTC)

• Addendum per EncycloPetey's point about the growing list of relevant poets. I don't think this is a discussion we need to pursue in depth on Scriptorium, but I did start a list here for further instances of broad classes that can be fixed programmatically: Category talk:Works with no license template#Clearing the backlog -Pete (talk) 17:22, 24 February 2024 (UTC)

Subscribe to the This Month in Education newsletter - learn from others and share your stories

Dear community members,

Greetings from the EWOC Newsletter team and the education team at Wikimedia Foundation. We are very excited to share that we on tenth years of Education Newsletter (This Month in Education) invite you to join us by subscribing to the newsletter on your talk page or by sharing your activities in the upcoming newsletters. The Wikimedia Education newsletter is a monthly newsletter that collects articles written by community members using Wikimedia projects in education around the world, and it is published by the EWOC Newsletter team in collaboration with the Education team. These stories can bring you new ideas to try, valuable insights about the success and challenges of our community members in running education programs in their context.

If your affiliate/language project is developing its own education initiatives, please remember to take advantage of this newsletter to publish your stories with the wider movement that shares your passion for education. You can submit newsletter articles in your own language or submit bilingual articles for the education newsletter. For the month of January the deadline to submit articles is on the 20th January. We look forward to reading your stories.

Older versions of this newsletter can be found in the complete archive.

More information about the newsletter can be found at Education/Newsletter/About.

For more information, please contact spatnaikwikimedia.org.

---

About This Month in Education · Subscribe/Unsubscribe · Global message delivery · For the team: ZI Jony ^(Talk), Sunday 8:32, 21 April 2024 (UTC)

Reusing references: Can we look over your shoulder?

Apologies for writing in English.

The Technical Wishes team at Wikimedia Deutschland is planning to make reusing references easier. For our research, we are looking for wiki contributors willing to show us how they are interacting with references.

• The format will be a 1-hour video call, where you would share your screen. More information here.
• Interviews can be conducted in English, German or Dutch.
• Compensation is available.
• Sessions will be held in January and February.
• Sign up here if you are interested.
• Please note that we probably won’t be able to have sessions with everyone who is interested. Our UX researcher will try to create a good balance of wiki contributors, e.g. in terms of wiki experience, tech experience, editing preferences, gender, disability and more. If you’re a fit, she will reach out to you to schedule an appointment.

We’re looking forward to seeing you, Thereza Mengs (WMDE) 09:53, January 10, 2024