Wikisource:Scriptorium

From Wikisource
Jump to navigation Jump to search
←
Scriptorium
→

The Scriptorium is Wikisource's community discussion page. Feel free to ask questions or leave comments. You may join any current discussion or start a new one; please see Wikisource:Scriptorium/Help.

The Administrators' noticeboard can be used where appropriate. Some announcements and newsletters are subscribed to Announcements.

Project members can often be found in the #wikisource IRC channel webclient. For discussion related to the entire project (not just the English chapter), please discuss at the multilingual Wikisource. There are currently 407 active users here.


▼

Announcements[edit]

Proposals[edit]

Making WS:Annotations official policy[edit]

Please see the discussion on this subject below at #Wikisource:Annotations —Beleg Tâl (talk) 02:05, 9 February 2024 (UTC)Reply[reply]

Bot approval requests[edit]

Repairs (and moves)[edit]

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

See also Wikisource:Scan lab

Other discussions[edit]

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

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 spatnaik at wikimedia.org.

PD works with non-PD scans[edit]

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)Reply[reply]

@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)Reply[reply]
@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)Reply[reply]
  • 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)Reply[reply]
    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)Reply[reply]
    • 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)Reply[reply]
      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)Reply[reply]

Updates to Template:RunningHeader[edit]

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)Reply[reply]

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)Reply[reply]
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)Reply[reply]
@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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
 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)Reply[reply]
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)Reply[reply]
 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)Reply[reply]
@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)Reply[reply]
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)Reply[reply]
Thank you! —CalendulaAsteraceae (talk • contribs) 20:40, 8 January 2024 (UTC)Reply[reply]
@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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
You can compare current vs. new at Template:RunningHeader/testcases. —CalendulaAsteraceae (talk • contribs) 23:29, 3 January 2024 (UTC)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
@Xover: not sure if you have alerts on for this thread, pinging you in case you don't. Concerns brought up so far:
—CalendulaAsteraceae (talk • contribs) 20:53, 8 January 2024 (UTC)Reply[reply]
@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)Reply[reply]
@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 scripts (of active users) which I don't understand well enough to tell if they'll be affected:
—CalendulaAsteraceae (talk • contribs) 23:39, 12 January 2024 (UTC)Reply[reply]
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)Reply[reply]
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)Reply[reply]
@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)Reply[reply]
{{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)Reply[reply]

Reusing references: Can we look over your shoulder?[edit]

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)

PD-self[edit]

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)Reply[reply]

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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
But the example on {{Translation license}} uses {{PD-self}}. --EncycloPetey (talk) 18:31, 29 January 2024 (UTC)Reply[reply]

Duplicates Index.[edit]

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)Reply[reply]

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)Reply[reply]
Speedied as redundant and file nominated for deletion at Commons. Mpaa (talk) 22:23, 25 January 2024 (UTC)Reply[reply]
Personally, I think you can use {{speedy}} for duplicate indices. —Beleg Tâl (talk) 18:32, 29 January 2024 (UTC)Reply[reply]

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)Reply[reply]

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)Reply[reply]
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)Reply[reply]
Was either work transcluded yet? ShakespeareFan00 (talk) 18:12, 26 January 2024 (UTC)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]

  • 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)Reply[reply]

Fonts[edit]

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

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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
I believe this page lists all webfonts currently available to use via {{ULS}}. —Beleg Tâl (talk) 18:15, 29 January 2024 (UTC)Reply[reply]

Broken links at Special:BookSources[edit]

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)Reply[reply]

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

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?[edit]

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

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)Reply[reply]
Yes, I might have made a typo? :( ShakespeareFan00 (talk) 05:59, 29 January 2024 (UTC)Reply[reply]
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)Reply[reply]

Tech News: 2024-05[edit]

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. [1]
  • 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). [2][3]
  • 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. [4]
  • 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. [5]

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)Reply[reply]

Fialure of hi-res image load script -[edit]

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)Reply[reply]

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)Reply[reply]

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

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)Reply[reply]

Works with no license tag[edit]

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)Reply[reply]

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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
@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)Reply[reply]

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)Reply[reply]

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)Reply[reply]
And if six more do the same, the 10,000 will be covered in that year. -- Beardo (talk) 23:45, 3 February 2024 (UTC)Reply[reply]
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)Reply[reply]
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 {{tl|PD-US"). MarkLSteadman (talk) 06:50, 7 February 2024 (UTC)Reply[reply]

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)Reply[reply]

@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)Reply[reply]
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)Reply[reply]
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)Reply[reply]

Sub-pages[edit]

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)Reply[reply]

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)Reply[reply]
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)Reply[reply]
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)Reply[reply]

Poems of John G. Whittier, Owen, Donne, Wesley, Keats[edit]

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)Reply[reply]

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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
I have set up Index:Complete Poetical Works of John Greenleaf Whittier (1895).djvu. --EncycloPetey (talk) 23:43, 16 February 2024 (UTC)Reply[reply]

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)Reply[reply]

Automatically empty "Without text" pages:[edit]

I came across this gadget today and enabled it in my preferences. I've tried it on a number of blank pages but it doesn't seem to work. The examples I've tried only had text in the main box but it wasn't cleared before the page saved. Chrisguise (talk) 00:50, 3 February 2024 (UTC)Reply[reply]

@Chrisguise: There's something very weird going on with that Gadget, in that sometimes it completely fails to load for no obvious reason. Usually it loads if you then reload the page, but that kinda defeats the purpose of the Gadget. I'm looking into it, but I'm having trouble figuring out where to start looking. Xover (talk) 08:45, 7 February 2024 (UTC)Reply[reply]
@Chrisguise: I think I found the problem. It should work now. Please let me know how it works for you. Xover (talk) 11:26, 18 February 2024 (UTC)Reply[reply]
Hi. It seems to work in normal 'create' and 'edit' modes, clearing all content from the main body, header and footer. It doesn't seem to work when I tried it with the 'edit pages in sequence' gadget. Thanks. Chrisguise (talk) 17:29, 18 February 2024 (UTC)Reply[reply]

Wikisource:Annotations[edit]

I'd like to have a straw poll, to resolve the community's stance without discussion on whether or not WS:ANN should be considered official WS policy. This is merely a fact-finding poll, to determine whether or not the community supports this page as policy. This is not intended to be a discussion, as its associated Talk page already has more than enough of that. If largely supported, then I'll start some kind of official !vote; if opinion is divided or against, then at least we'll know, and discovering that is the sole purpose of this poll. --EncycloPetey (talk) 22:17, 3 February 2024 (UTC)Reply[reply]

 Support —Beleg Tâl (talk) 16:56, 4 February 2024 (UTC)Reply[reply]
I was under the impression that the policy was made official in 2021 as per this edit and the corresponding discussion. Was that not the case? Arcorann (talk) 10:03, 7 February 2024 (UTC)Reply[reply]

Making it policy[edit]

Rather than asking everyone to support a second time, since the support seems to be unanimous, I'm going to ask whether there are any objections serious enough to prevent this page from becoming policy. Keep in mind that it is possible to change policy, so if the objection can be corrected with a discussion afterwards, please consider that option as well. This page seems to be considered policy already, but I'll leave this open for at least a week before adding the official tags and such, in case there are serious objections. --EncycloPetey (talk) 19:36, 8 February 2024 (UTC)Reply[reply]

Proceeding now with the official action to mark it as policy, based on unanimous support. --EncycloPetey (talk) 19:17, 22 February 2024 (UTC)Reply[reply]

Awesome! —Beleg Âlt BT (talk) 19:39, 22 February 2024 (UTC)Reply[reply]

Moving essays between namespaces[edit]

After receiving a talk I would like to strongly oppose an unilateral move to userfy the essay for several reasons:

  1. The move lacked prior discussion.
  2. The move would discourage faithful improvement by others.
  3. Jimbo Wales, not me, originated the post against attacks on userpages, which should document wmf:Policy:Terms_of_Use#4._Refraining_from_Certain_Activities.
  4. Template:Blanked userspace page is further documented.

Hopefully this matter will be peacefully solved.--Jusjih (talk) 02:37, 4 February 2024 (UTC)Reply[reply]

@Jusjih: You think this issue is very important due to a personal bad experience with a Chinese project that permitted one such page aimed at you, but using user pages for attacks on other contributors is an absolute non-issue on enWS. To the degree it ever occurs (which I don't recall ever seeing) the admins will deal with it under existing policy (and the UCoC, which requires us to deal with such pages even if there was no local policy). Xover (talk) 07:37, 4 February 2024 (UTC)Reply[reply]
@Jusjih: I also do not see which problem present in Wikisource either currently or in the past you are trying to address and what is the point of having such an essay in the Wikisource namespace. I am very sorry if you were a subject of an attack somewhere else, in the past I experienced it too, so I know what it is like and you have all my sympathy, but I do not see how it could help when you import the essay to an unrelated project. Essays in the Wikisource namespace should address Wikisource issues only. According to Wikisource:Essays, Wikisource essays are general-interest essays while User essays are specific or minority-interest essays... The text you imported really does not seem to be connected with anything we generally feel as needed to be solved here, as far as I know there has never been such a problem since I started contributing here, and so it falls under the category of user essays (if needed here at all). --Jan Kameníček (talk) 10:07, 4 February 2024 (UTC)Reply[reply]
I don't see any issue with having this essay, or any other relevant essay that a contributor wishes to write, present in WS space. I have no problem moving this one back to WS space where it belongs.
Personally, it doesn't matter to me what space the essay is placed in. However, I think that a discussion should have been had before moving it, i.e. WS:S should have been consulted before moving from WS to User space, rather than before returning it from User space back to WS space. —Beleg Tâl (talk) 16:58, 4 February 2024 (UTC)Reply[reply]
@Beleg Tâl: with an edit in the essay in question gave me permission in private emails to move it into the user subpage. If anyone has any issues, please let the latest host of the essay to follow up. Hopefully it will please everyone peacefully. :-)--Jusjih (talk) 03:29, 14 February 2024 (UTC)Reply[reply]

Chappaquiddick[edit]

What is the copyright position of a speech like this ? -- Beardo (talk) 02:12, 5 February 2024 (UTC)Reply[reply]

@Beardo: Personally I would consider this speech to be primarily a political speech (it concerns the then-Senator's resignation and whether he should seek reelection, and addresses these questions to the voters), and as such is outside the scope of {{PD-USGov}}. This means normal copyright rules apply, and the issue of copyright status hinges on when it was first subject to general publication with the author's consent (note that the speech was just a performance, not a publication, so you'll need to look for, typically, a book form publication or a newspaper article bylined by Kennedy rather than reported by the newspaper's staff). If that publication was without copyright notice, or if whatever work it was did not have its copyright renewed, then it is {{PD-US-no notice}} or {{PD-US-no renewal}}, otherwise it's in pub. +95 copyright (or if unpublished in pma. 70 copyright). Xover (talk) 09:05, 7 February 2024 (UTC)Reply[reply]

Template:M-larger[edit]

What is this template for? --EncycloPetey (talk) 17:28, 5 February 2024 (UTC)Reply[reply]

I'm confused as to what's confusing: it makes text that is 110% the font size of the previous text. —Justin (koavf)❤T☮C☺M☯ 17:45, 5 February 2024 (UTC)Reply[reply]
Under the Usage heading, it merely says: "This template simplifies formatting text that is M-larger" without explaining what that means. --EncycloPetey (talk) 17:50, 5 February 2024 (UTC)Reply[reply]
Sure, but Template:M-larger#Font_size_definition_by_relative_differences_using_words. —Justin (koavf)❤T☮C☺M☯ 17:58, 5 February 2024 (UTC)Reply[reply]
Ah! Instead of explaining the usage in the Usage section, its explanation was placed much further down the page, buried in a table explaining multiple templates in relation to each other. --EncycloPetey (talk) 18:10, 5 February 2024 (UTC)Reply[reply]
Our current size classes are a deliberate standardisation of text sizes, and new sizes should not be added without a policy-level discussion. Arbitrary other sizes can be achieved—when there is some exceptional need to deviate—using {{font-size}} (alias {{fs}}). Xover (talk) 09:10, 7 February 2024 (UTC)Reply[reply]
It seems {{m-larger}} was added to this table in July. I had never heard of the template prior to seeing it used recently. Was there a discussion to add that template as standard? --EncycloPetey (talk) 19:43, 8 February 2024 (UTC)Reply[reply]

Tech News: 2024-06[edit]

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

  • The mobile site history pages now use the same HTML as the desktop history pages. If you hear of any problems relating to mobile history usage please point them to the phabricator task.
  • On most wikis, admins can now block users from making specific actions. These actions are: uploading files, creating new pages, moving (renaming) pages, and sending thanks. The goal of this feature is to allow admins to apply blocks that are adequate to the blocked users' activity. Learn more about "action blocks". [6][7]

Changes later this week

  • The new version of MediaWiki will be on test wikis and MediaWiki.org from 6 February. It will be on non-Wikipedia wikis and some Wikipedias from 7 February. It will be on all wikis from 8 February (calendar). [8][9]
  • Talk pages permalinks that included diacritics and non-Latin script were malfunctioning. This issue is fixed. [10]

Future changes

  • 24 Wikipedias with Reference Tooltips as a default gadget are encouraged to remove that default flag. This would make Reference Previews the new default for reference popups, leading to a more consistent experience across wikis. For 46 Wikipedias with less than 4 interface admins, the change is already scheduled for mid-February, unless there are concerns. The older Reference Tooltips gadget will still remain usable and will override this feature, if it is available on your wiki and you have enabled it in your settings. [11][12]

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

MediaWiki message delivery 19:22, 5 February 2024 (UTC)Reply[reply]

Rendering of 'blackletter' text[edit]

For awareness, while validating this page Page:The_Economist_1843-08-_Vol_1_Preliminary_Number_(IA_sim_economist_1843-08_1_preliminary-number).pdf/1 using Firefox, I thought there were typos in the line 'And Banker's Gazette', as both the 'A' and 'k' did not look right in blackletter. However, the text is correct. When viewing the same page in Edge, the blackletter text renders correctly. Chrisguise (talk) 08:10, 6 February 2024 (UTC)Reply[reply]

Chrisguise: Template:Blackletter#Modes mode 4 gets the s and the k. 'k?--RaboKarbakian (talk) 11:50, 6 February 2024 (UTC)Reply[reply]
Thanks for the fix. I've not previously had any problems with the default mode. Chrisguise (talk) 12:05, 6 February 2024 (UTC)Reply[reply]

Style sheet per book[edit]

One often puts energy into shaping each heading or image caption to look a bit like the printed typography. An idea that has struck me is that this could be done with a CSS style sheet per book. In this book, all chapter headings are written in ALL CAPS, section headings in small caps, and image captions in cursive. Then you could just run away with ==h2== and ===h3=== and <img> tags and all would be fine. Has anybody experimented with this? Would it work with transclusions under the ProofreadPage extension? LA2 (talk) 21:02, 6 February 2024 (UTC)Reply[reply]

@LA2: See Help:Page styles. But don't use MediaWiki default heading and image caption syntax for these. MediaWiki and the skin "owns" these and can change their styling at any time (in addition to heavily styling them in the current style sheets). Use our normal Wikisource-specific formatting templates and then override their styles using page styles. For chapter headings and subheadings I am working on {{h}} and {{sh}} as a simple and consistent way to handle most (think 80/20) such constructs. They add very simple default styling, but are designed to be enriched or overridden by Page styles. And I plan to make more such templates as I come across other good candidates for standardised handling (plates and image captions may be one such). They're currently undocumented while I test them out in my own proofreading projects to get experience with where they work well and where they need tweaks, but I'm happy to help if you want to try experimenting with them in your proofreading projects. Xover (talk) 09:20, 7 February 2024 (UTC)Reply[reply]
@Xover I think they cam be merged with {{Pseudoheading}} and relatives. Mpaa (talk) 20:40, 11 February 2024 (UTC)Reply[reply]
@Mpaa: Eventually, yes. Right now they're deliberately separate because we're exploring the same ideas from slightly different angles. Xover (talk) 06:05, 12 February 2024 (UTC)Reply[reply]

Copyright status check..[edit]

IS this PD-US-Gov - https://archive.org/details/coloruniversalla440kell/mode/1up It seems to contain reprints of earlier material from copyright journals. If it is PD-US-Gov ( as a NIST/NBS published) work can someone please put it on commons? (Or at the very least identify the portions that can be.) ShakespeareFan00 (talk) 10:19, 9 February 2024 (UTC)Reply[reply]

Yes, this is just a repackaging of two earlier works, which would presumably have copyright protections and it is not clear if/when/how/that they were put into the public domain. —Justin (koavf)❤T☮C☺M☯ 10:39, 9 February 2024 (UTC)Reply[reply]
Seems fine to me; it's a 1976 work published without copyright notice, with permission of the author (see introduction). For the two underlying works, "THE ISCC-NBS METHOD OF DESIGNATING COLORS AND A DICTIONARY OF COLOR NAMES, by Kenneth L. Kelly and Deane B. Judd, NBS Circular 553, Nov. 1, 1955" is an NBS Circular, and in this context NBS obviously means the National Bureau of Standards, the same federal government body that's publishing this book, and "A UNIVERSAL COLOR LANGUAGE, by Kenneth L. Kelly, Color Engineering 3, 16 (March- April 1965)" is solely authored by the author of the introduction, so it had his permission. https://tsapps.nist.gov/srmext/certificates/archives/2106.pdf is a copy of the original article with a copyright notice from Color Engineering's publisher. I believe it to be the work of a US government official in the course of their job, and thus not eligible for copyright, but that part could be a concern. The other work is clearly PD-USGov/PD-US-no notice, IMO, and is not a problem.--Prosfilaes (talk) 17:04, 9 February 2024 (UTC)Reply[reply]
Circular 533 is something to find :) - The only difference here is that the 1976 printing might have had eratta corrected? ShakespeareFan00 (talk) 17:14, 9 February 2024 (UTC)Reply[reply]
Other works on Colorimetry:
  • Ridgway, Robert, Color Standards and Color Nomenclature, Washington D.C (1912)
  • D.H. Hamly, The ridgway Color Standards with a Munsell Notation Key, J.Opt. Soc. America , 39, 592(1949)
  • Colors for Moldeld Urea Plastics, Commercial Standard CS147-47, U.S Department of Commerce, (1947)
  • Colors for Polysterene Plastics, Commercial Standard CS156-49, U.S Department of Commerce, (1949)
  • Federal Specifcation TT-C-595 , Colors : Ready Mixed Paints. Issued: 1951 (It became FS 595?)
  • Judd, D.B. The 1931 I.C.I Standard Observer and Coordinate System for Colorimetry, Journal of the Optical Society of America 23,359 (1933)
  • Judd, D.B and Kelly, K.L., Method of Designating Colors, Journal of Research, NBS 23,355 (1939) RP1239
  • Kelly, K.L., Central Notations for the Revised ISCC, NBS 61, 427 (1958); RP 2911
  • Kelly. K.L., Coordinated color identifications for Industry, NBS TN152 (Nov. 1962)
  • Kelly. K.L., and Judd, D.B. The ISCC-NBS Method of Designating Colors and a Dictionary of Color Names. NBS Circular 533. Nov 1. 1955
ShakespeareFan00 (talk) 18:51, 9 February 2024 (UTC)Reply[reply]
  • The original of “A Universal Color Language” can be found here on IA. Color Engineering is a privately published periodical, “© Kinelow Publishing Company, Inc., 1965.” There is no copyright notice on Kelly’s article, nor on any other article. Copyrights on issues of periodicals apply to the issue itself (for the proprietor of the periodical) and to the articles printed within (for the authors of the articles). It’s not clear whether Kelly held on to his copyright, or assigned it to Kinelow so as to have the article published. At the end of the article, there is a short description of Kelly’s professional career, highlighting his work with the National Bureau of Standards, in addition to three papers co-authored with Dr. Judd, “Method of Designating Colors,” “ISCC-NBS Method of Designating Colors and a Dictionary of Color Names,” and “Central Notations for the Revised ISCC-NBS Color-Name Blocks.” In addition, this description does not make any mention of private work (except work done collaboratively, in which he was the Federal part). As the original article was published in an issue of a periodical with a copyright notice, if the article was done separately from his work, than the copyright on that work would continue through the new (combined) publication, even though the modifications would be PD-US-no notice. On balance, though, I would say the article is PD-USGov, despite the non-government publication. TE(æ)A,ea. (talk) 19:28, 9 February 2024 (UTC)Reply[reply]

What does it take to have RELIABLE tools?[edit]

Index:NBS_Circular_553.djvu IA Upload- but the OCR is out by one. What does it take to have tools that can RELIABLY do what they claim to? ShakespeareFan00 (talk) 23:18, 9 February 2024 (UTC)Reply[reply]

What is more, this bug is really old, see task T194861 founded in 1918! I sometimes come across this problem too, so I ignore the original (shifted) OCR and simply overwrite it using our OCR tools. --Jan Kameníček (talk) 00:11, 10 February 2024 (UTC)Reply[reply]

longdash not transcluding properly[edit]

See A_Chambermaid's_Diary on p.7, where the longdash inside italics is not transcluding properly, neither does it it look correct in the Page namespace. --EncycloPetey (talk) 23:26, 11 February 2024 (UTC)Reply[reply]

Nevermind. I found the problem. --EncycloPetey (talk) 23:29, 11 February 2024 (UTC)Reply[reply]

Announcing the results of the UCoC Coordinating Committee Charter ratification vote[edit]

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

Dear all,

Thank you everyone for following the progress of the Universal Code of Conduct. I am writing to you today to announce the outcome of the ratification vote on the Universal Code of Conduct Coordinating Committee Charter. 1746 contributors voted in this ratification vote with 1249 voters supporting the Charter and 420 voters not. The ratification vote process allowed for voters to provide comments about the Charter.

A report of voting statistics and a summary of voter comments will be published on Meta-wiki in the coming weeks.

Please look forward to hearing about the next steps soon.

On behalf of the UCoC Project team,

RamzyM (WMF) 18:24, 12 February 2024 (UTC)Reply[reply]

Tech News: 2024-07[edit]

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

  • The WDQS Graph Split experiment is working and loaded onto 3 test servers. The team in charge is testing the split's impact and requires feedback from WDQS users through the UI or programmatically in different channels. [13][14][15] Users' feedback will validate the impact of various use cases and workflows around the Wikidata Query service. [16][17]

Problems

  • There was a bug that affected the appearance of visited links when using mobile device to access wiki sites. It made the links appear black; this issue is fixed.

Changes later this week

  • The new version of MediaWiki will be on test wikis and MediaWiki.org from 13 February. It will be on non-Wikipedia wikis and some Wikipedias from 14 February. It will be on all wikis from 15 February (calendar). [18][19]
  • As work continues on the grid engine deprecation,[20] tools on the grid engine will be stopped starting on February 14th, 2024. If you have tools actively migrating you can ask for an extension so they are not stopped. [21]

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

MediaWiki message delivery 05:48, 13 February 2024 (UTC)Reply[reply]

Combine the {{PD-US}} and the {{PD-US-no-renewal}} templates[edit]

There are still many, many authors who have both works that fit into the scope of the {{PD-US}} template and those fit into the scope of the {{PD-US-no-renewal}} template. These templates, when used both on the same page, occupy a plenty of space which both has an inelegant appearance and contains some redundant text. I suggest making the third template (for example, {{PD-US-expire-no-renewal}}) that combines the content of both templates and can be used on pages of such authors (like Lovecraft or Frank Owen) --Nonexyst d 14:35, 17 February 2024 (UTC)Reply[reply]

@Nonexyst: I definitely agree with the sentiment here, but I'd like to take it a step further and just take the public-domain reasons off of author pages altogether. In other words, perhaps we should just have a template that says something like "This author has works that are in the public domain." (in the usual more formal terms of course)
The part where tagging specific public-domain reasons is actually important is in the individual works themselves. Author pages exist effectively as directories for finding these works, and since we're starting to delve into territory where keeping up with the copyright statuses of all the works within these "directories" is complex and therefore repetitive and redundant, we should just remove that altogether.
This is just another bit of constant maintenance that we don't need. SnowyCinema (talk) 14:45, 17 February 2024 (UTC)Reply[reply]
Yeah, let's just drop hyper-specific templates like {{PD-US-no notice}} and {{PD-US-no renewal}} from Author: pages. Author's works are either generally in the public domain, some are in the public domain, some are compatibly licensed, or they are generally still in copyright. More nuance and detail is just noise there (an explanation can go on the talk page if needed; eg. like for Tolstoï and the translations, or the hyper-complicated situation for Lovecraft). Xover (talk) 17:43, 17 February 2024 (UTC)Reply[reply]

If we're going to make an author-specific licensing template, the name of the template should make it clear that the template is for use on Author pages, and no resemble the templates we use on works, in order to reduce the likelihood of confusion. --EncycloPetey (talk) 18:33, 17 February 2024 (UTC)Reply[reply]

I can see dropping some of the hyper-specific templates, but I don't think we should toss out all of the details. We should have separate templates for authors whose works are generally all in the PD (died 95 years ago), authors who have some works expired due to age, and US authors who may have some works not renewed or no notice. I think it's important to say whether works are generally in the public domain, or if there's more elaborate checking needed.--Prosfilaes (talk) 16:13, 19 February 2024 (UTC)Reply[reply]

Just want to say I'm pleased to see this discussion going. Previously I've felt that copyright banners on Author: pages were extraneous and sometimes misleading, but these kinds of refinements would make a big difference. Kudos all. -Pete (talk) 17:54, 24 February 2024 (UTC)Reply[reply]

It is not only author pages where both {{PD-US}} and {{PD-US-no-renewal}} may appear, it can happen with some periodical too, see e.g. The World (newspaper). Besides creating a combined template, we could also solve it in a way similar to {{Translation license}}. --Jan Kameníček (talk) 19:12, 24 February 2024 (UTC)Reply[reply]

Approximate birth and death categories[edit]

When there is just an approximate date of birth or death in Wikidata, the software tries to categorize the author into non-existing categories like category:C. 1390 births, see e. g. Author:Petr Chelčický. I am not sure whether such categories should be founded. Would it be possible to change it so that the authors are categorized directly into category:1390 births? -- Jan Kameníček (talk) 22:24, 18 February 2024 (UTC)Reply[reply]

Ah, only now I have noticed that the author is categorized into both categories. So is the approximate date category necessary? Would it be possible to remove such categorization, leaving only e. g. category:1390 births? --Jan Kameníček (talk) 22:27, 18 February 2024 (UTC)Reply[reply]
Thanks for catching this! I've updated Module:Author to remove the inappropriate categories. —CalendulaAsteraceae (talk • contribs) 23:19, 18 February 2024 (UTC)Reply[reply]

Tech News: 2024-08[edit]

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

  • If you have the "Email me when a page or a file on my watchlist is changed" option enabled, edits by bot accounts no longer trigger notification emails. Previously, only minor edits would not trigger the notification emails. [22]
  • There are changes to how user and site scripts load for Vector 2022 on specific wikis. The changes impacted the following Wikis: all projects with Vector legacy as the default skin, Wikivoyage, and Wikibooks. Other wikis will be affected over the course of the next three months. Gadgets are not impacted. If you have been affected or want to minimize the impact on your project, see this ticket. Please coordinate and take action proactively.
  • Newly auto-created accounts (the accounts you get when you visit a new wiki) now have the same local notification preferences as users who freshly register on that wiki. It is effected in four notification types listed in the task's description.
  • The maximum file size when using Upload Wizard is now 5 GiB. [23]

Changes later this week

  • The new version of MediaWiki will be on test wikis and MediaWiki.org from 20 February. It will be on non-Wikipedia wikis and some Wikipedias from 21 February. It will be on all wikis from 22 February (calendar). [24][25]
  • Selected tools on the grid engine have been stopped as we prepare to shut down the grid on March 14th, 2024. The tool's code and data have not been deleted. If you are a maintainer and you want your tool re-enabled reach out to the team. Only tools that have asked for extension are still running on the grid.
  • The CSS filter property can now be used in HTML style attributes in wikitext. [26]

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

MediaWiki message delivery 15:36, 19 February 2024 (UTC)Reply[reply]

Changes to loading user scripts in Vector and Vector 2022[edit]

Obsolete information for historical reference.

As announced in Tech News 2024-08 there are changes coming to how your vector.js / vector.css and vector-2022.js / vector-2022.css are loaded. Currently, if you are using the Vector 2022 skin, both the vector and vector-2022 variants are loaded. Starting at some point in the near future (date has not been set yet, but the original ambition was to get it done by the end of 2023 so we're on borrowed time) the Vector 2022 skin will only load the vector-2022 variants.

If you are using the Vector 2022 skin (not on by default, so you must have explicitly turned it on) you will need to migrate the code in your vector.js / vector.css to vector-2022.js / vector-2022.css. You should not do this until the change goes live or the same code will be loaded twice with unpredictable results (unpredictable, but it's very likely your scripts will break in some way).

Once some of the site-wide code affected by this change has been migrated it is likely we will ask for an expedited transition, in which case it will be announced here that it has happened. If that plan doesn't pan out you will have to keep watch for your old scripts to stop getting loaded and migrate then, but we may not be able to announce a specific date when it happens (it depends on upstream communication about the change). In either case it is likely that once the change has been implemented (for all sites, not just enWS) there will be a notice about it in a future Tech News.

If you are using any other skin but Vector 2022 (including original Vector aka. Vector 2010) you should not be affected by this and there is no action needed on your part.

If you have questions or need help migrating your vector.js / vector.css please feel free to post in this thread. --Xover (talk) 13:07, 20 February 2024 (UTC)Reply[reply]

Nevermind. This information turns out to be obsolete. Updated information will follow shortly. --Xover (talk) 14:30, 20 February 2024 (UTC)Reply[reply]

Second attempt: As announced (extremely subtly through the use of the past tense) in Tech News 2024-08, changes have already been made to how your vector.js / vector.css and vector-2022.js / vector-2022.css are loaded. Previously, if you were using the Vector 2022 skin, both the vector and vector-2022 variants were loaded. Starting at some point in the recent past (I don't have the exact date) the Vector 2022 skin will only load the vector-2022 variants.

If you are using the Vector 2022 skin (not on by default, so you must have explicitly turned it on) you will need to migrate the code in your vector.js / vector.css to vector-2022.js / vector-2022.css or they will not be loaded. There are significant changes to to the skin in Vector 2022 so there is no guarantee that your old scripts will work in the new skin without modifications.

If you are using any other skin but Vector 2022 (including original Vector aka. Vector 2010) you should not be affected by this and there is no action needed on your part.

If you have questions or need help migrating your vector.js / vector.css please feel free to post in this thread. --Xover (talk) 14:36, 20 February 2024 (UTC)Reply[reply]

Discourse Concerning the Natation of Bodies[edit]

This was just listed as "new". In researching the supporting scan, I discovered that the Commons file simply lists "Internet Archive" as the source, without any specifics. I cannot find the scan there. Can anyone else please locate the source of the scan at Commons? --EncycloPetey (talk) 20:28, 19 February 2024 (UTC)Reply[reply]

Possibly extracted from this facsimile? [27] MarkLSteadman (talk) 01:38, 20 February 2024 (UTC)Reply[reply]

Invitation to join February Wikisource Community Meeting[edit]

Hello fellow Wikisource enthusiasts!


We are the hosting this month’s Wikisource Community meeting on 24 February 2024, 7 AM UTC (check your local time).


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) 11:11, 20 February 2024 (UTC)Reply[reply]

Wikidata questions[edit]

There are a few points that don't seem to be covered in Wikisource:Wikidata:

  • Work and edition items: how does this work when there's only one version? What do we do with the links?
  • How do we handle periodicals and issues of periodicals?

(Also once these get resolved can we update the page?) Arcorann (talk) 09:58, 23 February 2024 (UTC)Reply[reply]

The work is more generic than editions. Works have different "outside information" than editions, which helps to keep the two separate. Works are instances of "literary work" or "work of science". Works might have a publisher, but be sure to only put the publisher of the first edition on it. Editions often have different publishers. A work should never have a property pointing at a scan or the gutenberg publication of the same or of an edition in the local library. Each of those would be an instance of "version, translation or edition". The edition gets the url to the wikisource index and the work gets the Main space link. It doesn't matter if there is only one edition. Editions link to the work via "edition of" and works link back to the edition via "Edition or translation of". Everything here that is in quotes has a property number at wikidata, but a few characters typed into the property area at wikidata will usually pull up the property you are looking for, if you are not a machine.
Magazines and journals are a mess of the same thing. Each freaking issue getting a work and at least one edition. Each issue reaching to its volume and each volume reaching to its first data, that states the beginning publication date, and the end date. Many of the journals have this information but it is under the "inception" property as is the wikipedia way. Adding publication date information makes those records useful for wikisource.
About adding this to the help. There are a million ways to say something but nothing works quite as well as experience. A very very helpful thing for me in figuring this out was to make the data and the {{Book}} template work on the scan, the scan being the edition that is used here. And then making the category at the commons and putting the link to that on the Work data. The book template has places for many things that should be found as edition properties at wikidata. The category needs the place of first publication, and the year [[Category:1928 books published in the United States]] and [[Category:Books published in Massachusetts]] or New York City or Boston. Those categories are about the licence, at least the year and country. The later, I guess, being interesting. Well, the {{Book}} template and getting everything installed at commons was very helpful to me in working through the wikidata that gets connected to it. It might help you also.--RaboKarbakian (talk) 15:12, 23 February 2024 (UTC)Reply[reply]
As Rabo points out, periodicals are a real morass of challenges from a data perspective, and Wikisource has to deal with many of the same issues. I'm not sure which are bothering you at the moment, but some that really bug me are:
  • What constitutes a distinct periodical? Are The Herald, The Weekly Herald, The Sunday Herald, The Herald Town & Country Monthly Insert, The Springfield Herald, and the Metro County Herald different names of the same publication, or five separate publications? How about the Times-Herald, formed after a merger? Other databases/authority controls such as the U.S. Library of Congress seem to err in the direction of making a separate data record for each title variant, but there are often important qualities of a publication that span many names (same publisher, same status as "only paper in town with unique social/political influence," etc.) that are harder to capture that way. The specifics of every publication's unique history are an important factor, and coming up with a general rule that is workable and accurate seems impossible. The Overland Monthly is a magazine that contends with these issues; I put several different name variants all on one Wikisource page, which I think is the least-bad approach and probably the most useful to a reader (but maybe not a data-oriented researcher), but still not very satisfying.
(oops, I left out the main point I was after: the audience and purpose of Wikidata might lead to different approaches for Wikidata vs. Wikisource vs. Wikipedia, but even that is an issue, because how do you link them? Especially with publications with numerous name changes, some innocuous and some substantive... -Pete (talk) 19:35, 23 February 2024 (UTC) )Reply[reply]
  • Our templates are largely designed with books in mind. There's no header template to capture an overall publication (such as year started/year ended, founder, predecessor, successor), and no header template for individual volumes or issues (month, day of month, etc.) "Year" as the only available template parameter in {{header}} does not fit well with periodicals
  • With some periodicals, especially newspapers, it's unclear the best framework for more granular pages. Below the top level, do we organize by year or volume number? Sometimes volumes span two years, other times there are two volumes per year, so it's a fundamental question. Below that, do you go with "/12 May 1902/" or "/1902/May/12" or something in between? Even with daily naming, what about a newspaper with separate morning and evening editions?
  • Copyright status is supposed to be asserted at the top level page, but this can result in weird collections of templates that are messy and not very informative without careful reading. See The Overland Monthly for an example of this too.
Some of this is addressable by developing more bespoke templates here. If you're interested in working with me on that, I'd suggest Wikisource talk:Periodical guidelines as a place to dig into what's needed and develop specs/proposals.
Also, if you haven't, I'd suggest consulting periodical-related WikiProjects on other projects, such as wikidata:Wikidata:WikiProject Periodicals and w:en:Wikipedia:WikiProject Newspapers. -Pete (talk) 19:21, 23 February 2024 (UTC)Reply[reply]
Arcorann this should be the best help for publications at wikidata: wikidata:Wikidata:WikiProject_Books They have not updated about oclc classify being superceded, but, these tables are really good.--RaboKarbakian (talk) 15:20, 24 February 2024 (UTC)Reply[reply]

British patents[edit]

There is a handful of patents which have been placed on pages of the form GB1893 15805 but with header title "Great Britain patent 15805". I think that these pages should be moved to something clearer, and I think that the mention of Great Britain is incorrect - British or UK. I suggest that the example link should go to "British patent no. 15805", or something like that, and the others moved similarly. Do people agree ? -- Beardo (talk) 02:25, 24 February 2024 (UTC)Reply[reply]

Note that GB is the official patent country code: https://www.uspto.gov/patents/apply/applying-online/country-codes-wipo-st3-table. And that is the id at espacent: https://worldwide.espacenet.com/patent/search?q=pn%3DGB189315805A MarkLSteadman (talk) 03:06, 24 February 2024 (UTC)Reply[reply]
Note that: https://worldwide.espacenet.com/patent/search?q=pn%3DGB189415805A is also 15805, https://worldwide.espacenet.com/patent/search?q=pn%3DGB189515805A is also 15805, https://worldwide.espacenet.com/patent/search?q=pn%3DGB2361408A is also GB 15805. You will probably need the date in the title at some point, e.g having a versions page once duplicates start appearing. Another option is the patent title "Improvements in or connected with Chest Expanding Braces or Straps." 03:21, 24 February 2024 (UTC) MarkLSteadman (talk) 03:21, 24 February 2024 (UTC)Reply[reply]
Thanks. That does seem to imply that the actual patent number includes the year at the start.
And whilst GB might be the reference, "Great Britain" is not correct. -- Beardo (talk) 06:02, 25 February 2024 (UTC)Reply[reply]

New Gadget: MoreMenu[edit]

There's a new Gadget available in your preferences: MoreMenu.

This should be familiar for enWP contributors where it's been available for years. The basic gist is that it adds a new dropdown menu next to the search field (in Vector) with useful links for pages (the "Page" menu) and, on user pages, about the user (the "User" menu). If you have particular rights you may see extra links specific to those user rights (e.g. admins get a few extra links that require administrator rights to see or use).

The Gadget is currently non-default so you need to explicitly turn it on to use it, but going by experience from other projects this is so useful that we'll probably want to turn it on by default once we're sure it doesn't cause any problems here. Xover (talk) 10:53, 24 February 2024 (UTC)Reply[reply]

New beta Gadget: Automatically empty Without text pages[edit]

There's a new Gadget available in the "Beta" section of your preferences: Automatically empty Without text pages.

This is a really simple little Gadget that watches the page status radio buttons in the Page: namespace and when you click the "Without text" one it empties out any stray automatic headers and footers as well as OCR text that may be in the page. It also saves away the text that was there so that if you click it by mistake you can just click any other pages status radio button to get the contents back.

The Gadget has been available for a while but was plagued by a "mystery bug" that made it fail to do anything most of the time. This problem should now be fixed (/me crosses fingers) and some wider testing would be useful. In my own experience this functionality is so useful that it's a no-brainer to make it default for all users, but it started life as my personal user script and hasn't had sufficient testing yet (feedback on this if you have an opinion would be welcome). Xover (talk) 11:02, 24 February 2024 (UTC)Reply[reply]

Size of edit window in Page: namespace..[edit]

I don't know what changed but the size of edit window in proofread page is now too small to be reasonably useable. Please change it back to the previous setting. Thanks. ShakespeareFan00 (talk) 22:08, 24 February 2024 (UTC)Reply[reply]

@ShakespeareFan00: If it helps, in my CSS file I figured out how to control the width of the #textbox1 of the proofread page. Specifying width doesn't work, but margins or padding does. — ineuw (talk) 23:35, 24 February 2024 (UTC)Reply[reply]
i find timeless skin can get full width on screen by zooming in. yrmv. --Slowking4 ‽ digitaleffie's ghost 01:18, 25 February 2024 (UTC)Reply[reply]
Welcome to endless art of managing one's proofreading page. — ineuw (talk) 01:59, 25 February 2024 (UTC)Reply[reply]

Index:Cumhadh do dh' iarla Earraghaidhail.pdf[edit]

One of the small books from the Scottish national archive - but this one is not in English. Can it be moved to the Gaelic part of wikisource ? -- Beardo (talk) 06:04, 25 February 2024 (UTC)Reply[reply]

Retrieved from "https://en.wikisource.org/w/index.php?title=Wikisource:Scriptorium&oldid=13917089"