Wikisource:Scriptorium

From Wikisource
(Redirected from Wikisource:S OLD)
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 424 active users here.

Announcements[edit]

Proposals[edit]

Bot approval requests[edit]

SodiumBot[edit]

I'd like to request temporary bot permissions for User:SodiumBot so that the bot can takeover the task of updating statistics templates on en.wikisource that was until recently done by Phe-bot (in the event that Phebot becomes operational, I will shutoff this task, since it wouldn't make sense to have two bots updating statistics). A example of the kind of edits SodiumBot would perform would look something like this. Sohom (talk) 05:53, 17 March 2024 (UTC)[reply]

 Support, and thank you so much for taking over this task! Xover (talk) 09:08, 17 March 2024 (UTC)[reply]
 Support --Jan Kameníček (talk) 09:44, 17 March 2024 (UTC)[reply]

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.


About This Month in Education · Subscribe/Unsubscribe · Global message delivery · For the team: ZI Jony (Talk), Tuesday 6:33, 19 March 2024 (UTC)

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)

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]

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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
@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]

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]

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

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]

@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]
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]
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]

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]

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

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]

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

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]

@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]
@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]
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]

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]

 SupportBeleg Tâl (talk) 16:56, 4 February 2024 (UTC)[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]

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]

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

Awesome! —Beleg Âlt BT (talk) 19:39, 22 February 2024 (UTC)[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]

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]
I would love to see this bug fixed! In the meantime, however, the folks at Wikisource:Scan lab are very helpful in fixing the broken OCR generated by IA-Upload. —Beleg Âlt BT (talk) 14:22, 26 February 2024 (UTC)[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]

@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]
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]

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]

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]

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]

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]

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]

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]
Thanks for catching this! I've updated Module:Author to remove the inappropriate categories. —CalendulaAsteraceae (talkcontribs) 23:19, 18 February 2024 (UTC)[reply]

Tech News: 2024-08[edit]

MediaWiki message delivery 15:36, 19 February 2024 (UTC)[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]

Nevermind. This information turns out to be obsolete. Updated information will follow shortly. --Xover (talk) 14:30, 20 February 2024 (UTC)[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]

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]

Possibly extracted from this facsimile? [6] MarkLSteadman (talk) 01:38, 20 February 2024 (UTC)[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]

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]

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]
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]
  • 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]
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]
What about Wikisource links on Wikidata? In particular, if we have only one edition for a work (so no versions page), and we link the work to the edition page, does the work entry just not get a Wikisource link? Arcorann (talk) 09:31, 28 February 2024 (UTC)[reply]
Arcorann: Link the Main page (transcluded work) to the "work" and there is a property P1957 "Wikisource index page URL" that goes with the scan edition.--RaboKarbakian (talk) 16:18, 28 February 2024 (UTC)[reply]
So to confirm, both the work page and edition page on Wikidata have the same link, with the link on the work page on Wikidata being changed when a versions page is made? Arcorann (talk) 00:56, 11 March 2024 (UTC)[reply]
No. The edition of a work (housed at Wikisource) goes on the data item for that edition, with information and links for that edition. The "work" data item is the generic information such as original date of writing, original language, and links to the work data records at VIAF and the Library of Congress as well as for other databases. Any information that is specific to a particular publication should go on a data item for that particular edition/publication. This includes the first edition of a work, which should also have a data item for it. This mirrors the format used internationally for major library databases: one data item for the generic information, separate data items for each edition of that work that has been published. It must be done that way so that we can record all data specific to the edition such as publisher, publication date, location of scans, and holdings of that edition in libraries. The edition data item gets crosslinked to the work data item using P747 (has edition or translation) from the work and P629 (edition or translation of) from the edition. What RaboKarbakian has told you is the nonstandard maverick approach he uses, and not the recommendations followed by everyone else.
Periodicals are sometimes handled differently, because they do not have multiple editions, though some periodicals now have print editions and electronic editions of articles, but what I've described is true for most editions of other kinds of things. --EncycloPetey (talk) 01:31, 11 March 2024 (UTC)[reply]
OK, we all agree that the edition page on WD and the work page on WS should be linked. If a versions page exists on WS then it should be linked to the work page on WD; that much is clear. What I'm still confused about is what (if anything) should be linked to the work page on WD if no versions page exists on WS. Arcorann (talk) 08:10, 12 March 2024 (UTC)[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]

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

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]

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]

Nice! You're right it really should be default feature. Jpez (talk) 06:02, 29 February 2024 (UTC)[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]

@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]
i find timeless skin can get full width on screen by zooming in. yrmv. --Slowking4digitaleffie's ghost 01:18, 25 February 2024 (UTC)[reply]
Welcome to endless art of managing one's proofreading page. — ineuw (talk) 01:59, 25 February 2024 (UTC)[reply]
such is the open source paradise. i tend to stay away from custom css and java tools, as they are prone to break, interact poorly, and are hard to trouble shoot. i expect tools to break as there is little tool management and support. unsupported skins will eventually break also, but timeless is quite an improvement over flat sidebar gadget, and the skin that does flat sidebar. the wiki software changes are wikipedia focused with many unintended consequences on other projects. the configuration labor is a barrier to entry, making it harder to onboard newbies. --Slowking4digitaleffie's ghost 15:12, 26 February 2024 (UTC)[reply]

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]

There are too many sidenote templates on this website, so I've decided to add yet another :D

It is my hope and belief, that someday English Wikisource will have a standard general-purpose approach to sidenotes. At that time, this template should be replaced with the adopted standard template.

In the meantime, you can use this template as a placeholder to indicate a sidenote that should be standardized once a standard has been created. The actual formatting of the sidenotes in the meantime may vary. (Currently it uses {{right sidenote}}.) —Beleg Âlt BT (talk) 14:17, 26 February 2024 (UTC)[reply]

I was originally going to call this template Template:Generic sidenote, but I decided to give it a name that clearly indicated that it shouldn't be treated as an alternative permanent approach to sidenotes —Beleg Âlt BT (talk) 14:18, 26 February 2024 (UTC)[reply]

Tech News: 2024-09[edit]

MediaWiki message delivery 19:23, 26 February 2024 (UTC)[reply]

Sister projects:[edit]

When did Sister_projects start importing all the main_subject= from Wikidata? RAN (talk) 20:25, 27 February 2024 (UTC)[reply]

At approximately 12:31 (UTC) on 12 April 2021. Xover (talk) 21:13, 27 February 2024 (UTC)[reply]
  • I see by deprecating the main_subject at Wikidata I can suppress their appearance here. If there is a news article about a person getting married, I don't think we need to link to the Wikipedia article on wedding, just the person. --RAN (talk) 22:56, 27 February 2024 (UTC)[reply]

Lua error in Monthly Challenge March 2024[edit]

There is a Lua error in the Monthly Challenge for March 2024. The following text is displayed on that page: Lua error in Module:Monthly_Challenge_listing at line 122: attempt to index local 't' (a nil value). DraftSaturn15 (talk) 03:51, 1 March 2024 (UTC)[reply]

@CalendulaAsteraceae, @Xover: SnowyCinema (talk) 03:55, 1 March 2024 (UTC)[reply]
@DraftSaturn15, @SnowyCinema, @Xover, @CalendulaAsteraceae. Sorry all, a curly brace in the wrong place did me in (in Module:MonthlyChallenge/data). Nothing to worry about. TeysaKarlov (talk) 05:06, 1 March 2024 (UTC)[reply]
Thanks for fixing that! I took the opportunity to clean up the module a bit. —CalendulaAsteraceae (talkcontribs) 05:31, 1 March 2024 (UTC)[reply]
There's now a Lua error in previous months ("Lua error in Module:Monthly_Challenge_listing at line 514: assign to undeclared variable 'lines'.") Arcorann (talk) 02:20, 8 March 2024 (UTC)[reply]
Good catch! Fixed. —CalendulaAsteraceae (talkcontribs) 03:29, 8 March 2024 (UTC)[reply]

About annotations[edit]

Does it count as an annotation to add as a footnote/tooltip the meaning of a rare archaic foreign word? I know that according to WS:ANN, this would count as a translation, and so require to create a separate new version of the text for a single word. I am thinking of "kahulla", present here. According to the WP language reference desk people (discussion there), it referred, in Tongan, to a kind of fruit and flower garland. I get the point of trying to present truly original texts. I just feel like it would be useful to the reader to know what that is, for such obscure words that had to be looked for in the travels of Captain Cook, from languages with less than 200 000 speakers. A tooltip is, I think, quite clearly not part of the text, and so would not be too problematic regarding the "cleanness" of the text. Would that be fine? — Alien333 (what I did and why I did it wrong) 18:40, 2 March 2024 (UTC)[reply]

Creating the Wiktionary page for the word and then linking to it would be the best approach. @EncycloPetey: would be the best person to advise on how to do this over there. Beeswaxcandle (talk) 18:47, 2 March 2024 (UTC)[reply]
Adding Tongan words is outside my skill. You'd need someone familiar with that language to help. In particular, you'd need a documented example of the nominative form to serve as a main entry. --EncycloPetey (talk) 19:25, 2 March 2024 (UTC)[reply]
Why should the language change something? Tongan already has a few hundred entries on Wiktionary (a randomly picked noun), I could just use the same format. Though, since I have only seen that word in english sources, it might have accents, like a lot of other Tongan words. Cook and the other explorers (and everyone else, who learned by them) might not have understood the correct spelling of the word. Alien333 (what I did and why I did it wrong) 19:42, 2 March 2024 (UTC)[reply]
Update: I found mention on wikt of the Churchward english-tongan dictionnary (1959, a century later, but it is the best I was able to find), which is available for borrow on IA (tongandictionary0000chur), and does not contain "kahulla" but "kahoa", which is said to mean necklace or garland, and is also listed as such on wikt:necklace. I think that indeed cook had gotten it wrong (or mabe the word just changed over time, I don't know). I think I am going to create kahoa on wikt, and then link to that. What do you think? Alien333 (what I did and why I did it wrong) 19:58, 2 March 2024 (UTC)[reply]
This is starting to get complicated. In An Account of the Natives of the Tonga islands, from 1820, necklace is translated as "cáhooa". Moreover, it looks like Tonga did originally not have a writing system, and that it was the explorers/colonizers that invented one. I think I'll just link to the modern spelling. Alien333 (what I did and why I did it wrong) 13:19, 3 March 2024 (UTC)[reply]
It was the early missionaries to the Pacific who devised the various writing systems used in the Polynesian, Melansian, and Micronesian languages. They weren't consistent initially and it was only when the Bible books were translated and printed that the orthography for each language settled down. It didn't help when there were (and are) different dialects and the written version only covered one of them. Beeswaxcandle (talk) 04:44, 4 March 2024 (UTC)[reply]

Do you do something with signed books?[edit]

When the scanned copy of the book includes a handwritten signature, or a dedication, had anyone of you do something special with it? Like a little template, or a Category? Ignacio Rodríguez (talk) 18:41, 2 March 2024 (UTC)[reply]

Clean, name, and upload the image separately to Mediawiki commons, then insert it it wherever you need it. Post on my talk page if you need help. — ineuw (talk) 03:20, 4 March 2024 (UTC)[reply]

Seeking to be enlightened about US copyright laws and the rest of the World[edit]

I am completely lost in the fine print of the international copyright laws. In reference to the 1920s' publication of the "Twelve Chairs" by the two Soviet/Russian satirists, Ilf and Petrov, are still copyrighted in the USA, but I am in Canada, and I think that they are in the public domain. I have no idea how to pursue the universal status of these books. — ineuw (talk) 03:14, 4 March 2024 (UTC)[reply]

commons:Commons:Copyright rules by territory is a good place to start. —CalendulaAsteraceae (talkcontribs) 03:57, 4 March 2024 (UTC)[reply]
When was the English translation published , do you know ? --Beardo (talk) 04:38, 4 March 2024 (UTC)[reply]
@Ineuw: Copyright law is pretty arcane to begin with. International copyright and how it interacts with various Wikimedia policies is more or less dark magic.
You need to know whether the work was originally written in Russian and later translated to English, or whether it was originally written in English. If there's translation involved there are two copyrights to figure out, if originally in English there's just one.
Then you need to know where the work was first published and when, and if first publication was not in the US you need to know whether the US publication happened within 30 days of the non-US publication.
For uploading scans to Commons you need to make sure a work is public domain in the US and in the country it was first published. For hosting a work on Wikisource it needs to be public domain in, at a minimum, the US. Canadian copyright is relevant only if first publication happened in Canada, or if you are in Canada you, like all contributors, must take into account your local jurisdiction's rules. Xover (talk) 06:33, 4 March 2024 (UTC)[reply]
Thanks. Your note reminded me that I have been through this process before. This is a dead issue. This book was published first in Russian in 1928, and the latest English version was re-published in 2020. — ineuw (talk) 11:27, 4 March 2024 (UTC)[reply]
But when was the earliest English version published ? -- Beardo (talk) 16:44, 4 March 2024 (UTC)[reply]
there is a 1961 vintage edition [11] but it was renewed in 1989 [12] --Slowking4digitaleffie's ghost 23:58, 4 March 2024 (UTC)[reply]
@Beardo:I read it in English before Mel Brooks' film. That is how I knew that the film is faithful to the book. Whether it was 1961 edition or earlier, I will find try to find out later this week, since the book still exists.P.S: I am old. — ineuw (talk) 03:00, 5 March 2024 (UTC)[reply]
@Ineuw - I note that the were English-language films based on it (though with fewer chairs) in 1936 and 1945 - so I wonder if there was an English language version before those. -- Beardo (talk) 03:31, 5 March 2024 (UTC)[reply]
i'm seeing a 1928 1st russian edition,[13] and there is a 1953 russian Checkhov edition [14], but mainly Richardson translations. [15] --Slowking4digitaleffie's ghost 15:41, 5 March 2024 (UTC)[reply]
Thanks for the info, but none of this qualifies the book to be in the public domain and available for uploading to the commons, unless it depends on the publication date. The English translation which I read is still in existence and well preserved, including the sequel! I expect to receive a photo of the title and the colophon pages. — ineuw (talk) 03:16, 6 March 2024 (UTC)[reply]
US copyright term for this is very likely to be one calculated based on date of first publication plus 95 years. Anything published anywhere in the world more than 95 years ago (currently 1928) is in the public domain in the US, even if they are still in copyright in other jurisdictions. In other jurisdictions a work is most likely covered by a copyright term calculated from the death of the author, often 70 years (but can also be other durations, it varies from country to country). Works that are public domain in the US but still in copyright in other countries can be uploaded to English Wikisource, but might be incompatible with Commons' licensing policy (that depends on details of first publication, when, in what country, was it simultaneously published in the US, etc.). Xover (talk) 15:27, 6 March 2024 (UTC)[reply]

┌─────────────────────────────────┘
The English language copy of "The Twelve Chairs" in my possession is a John B. C. Richardson translation, published by Vantage Books in 1961. Definitely not in Public Domain. — ineuw (talk) 10:08, 15 March 2024 (UTC)[reply]

Political petitions and declarations[edit]

Tagged as having no license are these two petitions to the Amir of Bahrain:

and these six declarations of the EZLN (w:Zapatista Army of National Liberation) :

Is there any reason why the originals could be PD ? Also, with the EZLN decarations, I don't see any indication of who translated them. -- Beardo (talk) 03:58, 4 March 2024 (UTC)[reply]

There is no indication that I see that the Voice of Bahrain makes their works freely licensed or that they are anything more notable than any other self-published source: https://vob.org/en/?page_id=1240Justin (koavf)TCM 04:19, 4 March 2024 (UTC)[reply]
https://archive.org/details/zapatistasdocume00memb/page/48 claims to be an anti-copyright translation. MarkLSteadman (talk) 00:37, 5 March 2024 (UTC)[reply]

{{dropinitial}}, {{initial}} and {{ppoem}}[edit]

Whilst the 'drop initial' template in its various forms works OK within 'ppoem' (i.e. images, floating qm's, etc.), I cannot get it to work with the text-indent option. It leaves the dropped initial at the LHS and then indents the following text (see Page:The Yellow Book - 03.djvu/183 for example).

The 'initial' template doesn't work properly within 'ppoem' either - it places the additional text over the dropped initial. Chrisguise (talk) 09:34, 4 March 2024 (UTC)[reply]

There are many issues with {{ppoem}}. I tend to avoid it because there's always a new issue causing a problem. --EncycloPetey (talk) 19:40, 4 March 2024 (UTC)[reply]
I have tried something, if it is not what you need, feel free to revert it. --Jan Kameníček (talk) 18:15, 5 March 2024 (UTC)[reply]
@Jan.Kamenicek @EncycloPetey Thanks, it seems to have done the job, but I have no idea why. What you've done doesn't seem to be a documented part of the template. Chrisguise (talk) 08:50, 7 March 2024 (UTC)[reply]
@Chrisguise: It is documented (although not explained in much detail) in Template:Dropinitial#Margin examples for images, but it works for all dropped initials. --Jan Kameníček (talk) 10:10, 7 March 2024 (UTC)[reply]

Gadget importing information from Commons into Index page[edit]

When uploading books into Commons, I have recently changed from using the author name in the author field to using {{creator|wididata=QXXXX}}, as this seems to be preferred because it provides more information/links on the Commons page. However, using this form appears to upset the gadget that imports the information into the WS Index page, in that it wraps the author name in '[[author:' twice. Chrisguise (talk) 09:46, 4 March 2024 (UTC)[reply]

Tech News: 2024-10[edit]

MediaWiki message delivery 19:47, 4 March 2024 (UTC)[reply]

Report of the U4C Charter ratification and U4C Call for Candidates now available[edit]

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

Hello all,

I am writing to you today with two important pieces of information. First, the report of the comments from the Universal Code of Conduct Coordinating Committee (U4C) Charter ratification is now available. Secondly, the call for candidates for the U4C is open now through April 1, 2024.

The Universal Code of Conduct Coordinating Committee (U4C) is a global group dedicated to providing an equitable and consistent implementation of the UCoC. Community members are invited to submit their applications for the U4C. For more information and the responsibilities of the U4C, please review the U4C Charter.

Per the charter, there are 16 seats on the U4C: eight community-at-large seats and eight regional seats to ensure the U4C represents the diversity of the movement.

Read more and submit your application on Meta-wiki.

On behalf of the UCoC project team,

RamzyM (WMF) 16:25, 5 March 2024 (UTC)[reply]

Wikimedia Canada survey[edit]

Hi! Wikimedia Canada invites contributors living in Canada to take part in our 2024 Community Survey. The survey takes approximately five minutes to complete and closes on March 31, 2024. It is available in both French and English. To learn more, please visit the survey project page on Meta. Chelsea Chiovelli (WMCA) (talk) 00:18, 7 March 2024 (UTC)[reply]

Many apparent typesetting errors in source document[edit]

Hi, while validating Silas Marner in The Works of George Eliot (Cabinet Edition)/Volume 23), I have encountered numerous "typos" in the source text. They mostly seem to be a typesetting problem, not spelling errors, sometimes 1 or 2 per page. I have been marking them with the SIC template, thus far.

But, yesterday I encountered one page with MANY such errors: Page:The works of George Eliot (Volume 23).djvu/135, where many lowercase o's are printed as lowercase c.

I don't know much about 19th century printing, but assume the source text would have been printed with movable type. So it seems really unlikely that the typesetter would have repeatedly made the mistake of setting "c" characters instead of "o", and I'm at a loss to guess how the page was printed in this fashion.

I tentatively decided to not markup this page with the SIC template, as I think they would be a distraction to the reader.

And I'm tempted to go back and simply fix most of the existing SIC's (i.e. remove the template, leaving just the corrected word), as they all seem to be instances of the same printing problem in the source text.

Is this an acceptable solution? Harris7 (talk) 12:17, 8 March 2024 (UTC)[reply]

@Harris7: Very strange. Maybe the typesetter had poor vision or lost all his lowercase o's. I agree that it would be distracting to highlight all of these errors since there are so many. I would reserve the SICs for clear spelling mistakes rather than these awkward character substitutions. Nosferattus (talk) 15:00, 8 March 2024 (UTC)[reply]
@Harris7: Looks like a DJVU error to me; cf https://ia801309.us.archive.org/BookReader/BookReaderImages.php?id=cu31924008065751&itemPath=%2F21%2Fitems%2Fcu31924008065751&server=ia801309.us.archive.org&page=n134.jpgCalendulaAsteraceae (talkcontribs) 19:46, 8 March 2024 (UTC)[reply]
@CalendulaAsteraceae: I'm confused. I thought that I was looking at photographic images of physical (ink on paper) pages from a book. Are you saying DJVU processes (and alters) them somehow, resulting in the page images I see in the Wikisource edit screen? Why would it change all these characters from o to c? Harris7 (talk) 19:56, 8 March 2024 (UTC)[reply]
Oops. Sorry for my ignorance. Now that I've read about how DjVu compresses images of text, I see it is possible for it to save a single glyph of an "o" (for example) from the image, then use it everywhere it thinks there is an "o"; but in this case, its scanning for "exact" matches to the glyph is apparently not perfect, and it ends up replacing many c's with o's. And the Wikipedia article mentions a case like the one I have reported above.
So - I tend to agree with your assessment @CalendulaAsteraceae... Harris7 (talk) 21:09, 8 March 2024 (UTC)[reply]
@Harris7: I uploaded a fixed version. Old thumbnails may be cached for a while, but a hard purge should clear it. In any case, these were definitely compression artefacts and should not be tagged in the transcription. Xover (talk) 18:02, 9 March 2024 (UTC)[reply]
@Xover: Excellent, it looks great! Problem resolved, thanks! Harris7 (talk) 22:24, 9 March 2024 (UTC)[reply]
To my eye these look like a type-founding problem and they are "o" with a small piece missing. Some of the "c" on the same page are distinct enough to be a different piece of type. So, I wouldn't mark any of these. It is also possible that the type compositor for the page was illiterate (many were) and just picked up a round letter to match. As a side note, I have a distinct preference for the {{sic}} template over {{SIC}} as I find the latter to be intrusive when I'm reading. Beeswaxcandle (talk) 20:03, 8 March 2024 (UTC)[reply]

Many pages of Florida legislation governing specific state roads are linked here. As far as I can tell none is sourced.

I'm confident there's no copyright issue. And if the labor already put into these pages -- which was clearly extensive -- had resulted in something that makes the sourcing clear to the reader (either via talk page templates or scan-backing), I would have no concerns. Any law passed by a government body, no matter how local or how granular, fits within the scope of Wikisource.

But as it stands, I'm interested in perspectives on what should be done with these pages. Is there somebody who intends to do the work needed to link them up with source documents? If not, should they stay in Wikisource's corpus indefinitely? -Pete (talk) 21:14, 8 March 2024 (UTC)[reply]

Clarifying re: copyright: Of course the copyright status is important, and it's important to put proper tags on the pages. I'm confident these are public domain either via the general {{PD-GovEdict}} or due to specific state law; clarifying which is more applicable would be useful, and could facilitate tagging these articles. But I am first interested in whether there is consensus that they should remain in Wikisource's main space. -Pete (talk) 21:19, 8 March 2024 (UTC)[reply]

Mother Jones[edit]

What would be the main Author page and what the redirect for w:Mother_Jones (and would we need the G.? All links in wp do not have it)? Thanks Mpaa (talk) 17:53, 9 March 2024 (UTC)[reply]

Per established practice the author page would be Author:Mary G. Harris Jones with a redirect to it from Author:Mother Jones. Hopefully we can figure out what the "G." stands for (not the mother's maiden name, she was a Cotter; unless the G. is a mispaleographed C. in the baptismal record), in which case the page would be at the expanded name with a redirect at Author:Mary G. Harris Jones. Xover (talk) 19:05, 9 March 2024 (UTC)[reply]

What is this template good for? Do we need it? -- Jan Kameníček (talk) 09:35, 10 March 2024 (UTC)[reply]

It's used by 33 pages, mainly for linguistics works that used these symbols. It looks like it does more or less nothing, apart from changing the font. I think we could just change these 33 pages and remove it. Alien333 (what I did and why I did it wrong) 10:20, 10 March 2024 (UTC)[reply]
The fact it changes the font is the main reason why I am asking, as it is imo quite undesirable when the font is different from the font of the surrounding text. --Jan Kameníček (talk) 10:22, 10 March 2024 (UTC)[reply]
IPA is supposed to look different from the surrounding text. It's deliberately printed to look different in most books to make it distinguishable from the rest of the text. We really do need a template that stabilizes IPA presentation. I say this from years of experience with the issue at Wiktionary. Without the stabilization of selecting an IPA-appropriate font, we run high risk of having the wrong characters, and thus the wrong sounds, presented to the reader.
It also potentially serves a function similr to our language wrapping templates, alerting assisted text-to-speech readers that the enclosed text is not the standard language. However, I do not know whether that functionality is in place for this particular template. In theory, it should be. --EncycloPetey (talk) 10:55, 10 March 2024 (UTC)[reply]
Well, if the original book used different typeface for IPA characters, then it would be OK, but whenever I saw it, the font looked the same as the font of the surrounding text, for example here (first line of the new chapter). It does not look good when the font is changed. However, this could be solved by adjusting the template to change the font only when needed, e. g. by an additional parameter. As for the risk of using wrong characters, I am not sure how the template fixes it. If I use a wrong character, does the template correct me somehow? Besides we have the set of correct IPA characters in the Special characters above the editing box.) --Jan Kameníček (talk) 11:10, 10 March 2024 (UTC)[reply]
Hm, now I have realized that the example I linked above is actually not IPA, but it can still serve to illustrate the point. --Jan Kameníček (talk) 11:26, 10 March 2024 (UTC)[reply]

The Wikipedia page has an entire section on this: w:International Phonetic Alphabet#Typefaces. Wikipedia's w:Template:IPA also includes a link to w:Help:IPA#Rendering issues. Fish bowl (talk) 00:24, 11 March 2024 (UTC)[reply]

Tech News: 2024-11[edit]

MediaWiki message delivery 23:04, 11 March 2024 (UTC)[reply]

Wikimedia Foundation Board of Trustees 2024 Selection[edit]

You can find this message translated into additional languages on Meta-wiki.

Dear all,

This year, the term of 4 (four) Community- and Affiliate-selected Trustees on the Wikimedia Foundation Board of Trustees will come to an end [1]. The Board invites the whole movement to participate in this year’s selection process and vote to fill those seats.

The Elections Committee will oversee this process with support from Foundation staff [2]. The Board Governance Committee created a Board Selection Working Group from Trustees who cannot be candidates in the 2024 community- and affiliate-selected trustee selection process composed of Dariusz Jemielniak, Nataliia Tymkiv, Esra'a Al Shafei, Kathy Collins, and Shani Evenstein Sigalov [3]. The group is tasked with providing Board oversight for the 2024 trustee selection process, and for keeping the Board informed. More details on the roles of the Elections Committee, Board, and staff are here [4].

Here are the key planned dates:

  • May 2024: Call for candidates and call for questions
  • June 2024: Affiliates vote to shortlist 12 candidates (no shortlisting if 15 or less candidates apply) [5]
  • June-August 2024: Campaign period
  • End of August / beginning of September 2024: Two-week community voting period
  • October–November 2024: Background check of selected candidates
  • Board's Meeting in December 2024: New trustees seated

Learn more about the 2024 selection process - including the detailed timeline, the candidacy process, the campaign rules, and the voter eligibility criteria - on this Meta-wiki page, and make your plan.

Election Volunteers

Another way to be involved with the 2024 selection process is to be an Election Volunteer. Election Volunteers are a bridge between the Elections Committee and their respective community. They help ensure their community is represented and mobilize them to vote. Learn more about the program and how to join on this Meta-wiki page.

Best regards,

Dariusz Jemielniak (Governance Committee Chair, Board Selection Working Group)

[1] https://meta.wikimedia.org/wiki/Special:MyLanguage/Wikimedia_Foundation_elections/2021/Results#Elected

[2] https://foundation.wikimedia.org/wiki/Committee:Elections_Committee_Charter

[3] https://foundation.wikimedia.org/wiki/Minutes:2023-08-15#Governance_Committee

[4] https://meta.wikimedia.org/wiki/Wikimedia_Foundation_elections_committee/Roles

[5] Even though the ideal number is 12 candidates for 4 open seats, the shortlisting process will be triggered if there are more than 15 candidates because the 1-3 candidates that are removed might feel ostracized and it would be a lot of work for affiliates to carry out the shortlisting process to only eliminate 1-3 candidates from the candidate list.

MPossoupe_(WMF)19:57, 12 March 2024 (UTC)[reply]

Match And Split not running[edit]

Match and Split isn't running - is this due to the changes to bot requirements, or is it a temporary outage? —Beleg Âlt BT (talk) 13:35, 13 March 2024 (UTC)[reply]

@Xover Is this the grid migration ? Sohom (talk) 13:58, 13 March 2024 (UTC)[reply]
It,s the Grid Engine Apocalypse, yes. It won’t be back up again until someone ports it to the Toolforge Jobs Framework. This applies to all phetools. Xover (talk) 18:16, 13 March 2024 (UTC)[reply]
Lovely.
Time to crack down on people who upload without scans? :D —Beleg Âlt BT (talk) 18:22, 13 March 2024 (UTC)[reply]
Past time IMO. But, you know… Xover (talk) 06:29, 14 March 2024 (UTC)[reply]
Would it be okay for User:SodiumBot (my bot) to take over some of the operations of User:Phe-bot (particularly the onwiki statistics update function for now) ? Sohom (talk) 14:55, 14 March 2024 (UTC)[reply]
Permanent (automated / unattended) bot tasks need community approval at WS:S, but I can't imagine anyone would object to you taking over that task temporarily while phe-bot is down. Our bot policy and attendant policies are also a decade plus out of date so the bot policy must be seen as advisory rather than absolute. I say we figure out all the technical stuff first and when we arrive at a new status quo we can deal with the formalities. Xover (talk) 20:11, 14 March 2024 (UTC)[reply]
Hear hear @Xover! It's hard to imagine a working solution being met with objection. Working alternatives are important in a world where servers go down, users get pulled away for various reasons, etc. -Pete (talk) 17:53, 16 March 2024 (UTC)[reply]
Please put a Bot approval request in that section near the top of this page. As a part of the request I suggest that six months would be the best period to cover the temporary outage of Phe-bot and we can re-assess the ongoing need at that point. Beeswaxcandle (talk) 22:19, 16 March 2024 (UTC)[reply]

Switching to the Vector 2022 skin[edit]

Hi everyone. We are the Wikimedia Foundation Web team. As you may have read in our previous messages across wikis or here in June 2022, we have been getting closer to switching every wiki to the Vector 2022 skin as the new default. In our previous conversations with Wikisource communities, we had identified an issue with the Index namespace that prevented switching the skin on. This issue is now resolved.

We are now ready to continue and will be deploying on English Wikisource on Wednesday April 3, 2024.

To learn more about the new skin and what improvements it introduces when compared to the legacy 2010 Vector skin, please see our documentation. If you have any issues with the skin after the deployment, if you spot any gadgets not working, or notice any bugs – please contact us! We are also open to joining events like the Wikisource Community meetings and talking to you directly. Thank you, OVasileva (WMF) and SGrabarczuk (WMF) (talk) 15:47, 14 March 2024 (UTC)[reply]

@Candalua: it looks like Vector 2022 breaks mul:MediaWiki:TranscludedIn.js; are you able to update that tool? —Beleg Âlt BT (talk) 18:59, 14 March 2024 (UTC)[reply]
Vector 2022 breaks lots of stuff (in everything from trivial ways to completely broken). I encourage everyone to try switching to Vector 2022 in your preferences NOW and report anything that breaks here. Especially if any of our community-wide Gadgets are affected, but there are also some widely used user scripts that it would be good to know about sooner rather than later if they are going to break on April 3. Xover (talk) 20:15, 14 March 2024 (UTC)[reply]
Oh, and Transcludedin.js isn't really "fixable" per se, since Vector 2022 explicitly doesn't support adding menus. We'll have to try to reverse engineer what MoreMenu and Popups does to find something that kinda sorta works (we have two widely used user scripts that run into the same problem). Because that's a good use of volunteer resources over the WMF actually adding support for basic facilities for Gadgets that have been requested for two decades or so... Xover (talk) 20:24, 14 March 2024 (UTC)[reply]
An illustration of the problem with User:Inductiveload/jump to file (presumably one of the aforementioned user scripts):
with Vector 2010
with Vector 2022
Also broken: the Tools menu interacts poorly with the file history table.
CalendulaAsteraceae (talkcontribs) 04:01, 15 March 2024 (UTC)[reply]
Jump to file has been broken in other ways as well. I think I remeber looking into it and the web backend is providing some incorrect information :( Sohom (talk) 12:29, 15 March 2024 (UTC)[reply]
@OVasileva (WMF), @SGrabarczuk (WMF): This skin does not seem to be suitable for Wikisource at all. Compare e. g. the work with proofread extension in both skins. In the new one both the editing window and the window with the scan are so small that I am unable to do any proofreading work effectively. I can choose only between struggling with reading tiny letters or enlarging the scan so much that only a part of the page fits into the window. And this enlarging is possible only in the editing mode anyway, it is not possible in the reading mode. I would really like to ask this skin not to be deployed in Wikisource. --Jan Kameníček (talk) 09:51, 16 March 2024 (UTC)[reply]
Why? As Jan Kameníček said, the skin is unsuitable here (and everywhere else, but that's a different matter). Why is the WMF so keen to force Vector2022 on everyone when so many problems have been found with it? English Wikipedia alone has complained about it enough for ten wikis. It is far too narrow for actual proofreading, and you have failed to provide any good reasoning as to why this poorly-designed skin should be forced onto our IP editors. The WMF already has a bad track record of communicating and collaborating with the communities, and Vector2022 has so far only made it worse. Why do you insist on rolling this out as the new default? @OVasileva (WMF), @SGrabarczuk (WMF): At the minimum, you need to allow IP editors and readers to use the good Vector skin if they want to. Cremastra (talk) 22:41, 16 March 2024 (UTC)[reply]

Global ban proposal for Slowking4[edit]

Hello. This is to notify the community that there is an ongoing global ban proposal for User:Slowking4 who has been active on this wiki. You are invited to participate at m:Requests for comment/Global ban for Slowking4 (2). Thank you. Seawolf35 (talk) 19:43, 14 March 2024 (UTC)[reply]

Your wiki will be in read-only soon[edit]

Trizek (WMF), 00:00, 15 March 2024 (UTC)[reply]

Hi wikisource![edit]

Hello Wikisource editors! Y'all might know me from English Wikipedia and Wikidata where I've been more active. To be fair I might be becoming the kind of editor who edits all the wikis indiscriminately (I've been also considering joining Wikivoyage and/or Wikifunctions)

After having lurked here for awhile, I've found myself (somewhat accidentally) validating Index:Works of merit, in every department of literature.pdf (forcing myself to get familiar with Help:Tables and Help:Page breaks on the fly). I also intend to work on Index:Taming of the Shrew (1921) Yale.djvu as my first real transcription project.

Hopefully y'all will give me a warm welcome. Duckmather (talk) 04:38, 15 March 2024 (UTC); amended 16:55, 15 March 2024 (UTC)[reply]

@Duckmather: Yes, welcome to the project! We are a wiki that has always been quite lacking in contributors, compared to the ocean of texts we need transcribed, so we're certainly glad you stopped by! I left you our welcome template a while back, and the links there will help you understand how we do things here etc. Feel free to let us know if you need some help, by using WS:Scriptorium/Help if it's ever needed. I hope you enjoy your time here! SnowyCinema (talk) 06:37, 15 March 2024 (UTC)[reply]
@Duckmather: Also note that Index:Taming of the Shrew (1921) Yale.djvu is a part of the Yale Shakespeare series, and as such there is a specific consistent style established for the whole series. The Yale Shakespeare is also quite technically challenging to format correctly, so it may not be the best starter project. Xover (talk) 07:01, 15 March 2024 (UTC)[reply]
@Xover: Yeah, I'm aware (I've looked at the source code of Page:Midsummer Night's Dream (1918) Yale.djvu/13 and such). I've been thinking about simplifying the style using the <poem> syntax, plus a special div-based version of {{pline}} for line numbers (as opposed to the current style of using {{dent/s}} and {{dent/e}}, plus a shit-ton of
's for the newlines). Duckmather (talk) 16:54, 15 March 2024 (UTC)[reply]
@Duckmather: That's why I warned you this text is part of a series, and you need to conform with the established conventions for it. Xover (talk) 16:58, 15 March 2024 (UTC)[reply]
@Xover: Is there documentation more thorough than this? I've been poking around for established conventions and that's all I found, maybe I missed something? -Pete (talk) 15:25, 16 March 2024 (UTC)[reply]
No, sorry, that's what there is. You'll need to look at the other volumes in the series for reference. As I said, not a good text for beginners, and not very well suited to dip in and out of even for experienced contributors. Xover (talk) 19:42, 16 March 2024 (UTC)[reply]
Hi @Duckmather! I've seen you around at RfD (at least I used to). Cremastra (talk) 13:55, 15 March 2024 (UTC)[reply]

Making MoreMenu and Without text Gadgets default[edit]

In #New Gadget: MoreMenu and #New beta Gadget: Automatically empty Without text pages, I announced the availability of these two new Gadgets. Since then there has been relatively little feedback, but what feedback there has been has been positive. I therefore intend to make both default at some point in the relatively near future.

I encourage you to post feedback in this thread (positive, negative, neutral, or apathetic; all feedback is valuable). Especially if you are sceptical I encourage you to actively test both Gadgets and then express your concerns here. Xover (talk) 13:19, 15 March 2024 (UTC)[reply]

 Support Sounds good to me. —CalendulaAsteraceae (talkcontribs) 14:51, 15 March 2024 (UTC)[reply]

Easier import[edit]

It seems most book and newspaper scanning projects don't offer proofreading, so it's tempting to copy works to Wikisource for that purpose. But it is a lot of trouble downloading the right format (e.g. Internet Archive's zip archive of JP2 files), then creating the proper format (e.g. PDF or Djvu with OCR text), uploading it to Commons, and creating an Index page, before you can even start. Are there any examples where this has been automated or simplified? Back in 2010, I copied entire years (1836, 1837; 300 djvu files per year, one for each day) of the Swedish official gazette from the national library to Commons and started proofreading in Swedish Wikisource. I thought that was a pioneer effort that would soon be automated, but it is just as complicated today as it was fourteen years ago. LA2 (talk) 18:10, 15 March 2024 (UTC)[reply]

@LA2: Try https://ia-upload.toolforge.org/ Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:00, 15 March 2024 (UTC)[reply]
So that uploads PDF/Djvu files from IA to Commons. But doesn't create a Wikisource Index page? And there are no similar bots for taking files from other sources? Here's an 1884 issue of a Swedish newspaper. I'd like to proofread that, but I need to download 8 JP2 images, convert them into a PDF, upload that to Commons, and create an Index page on Swedish Wikisource. How do I get someone (the WMF) to develop (and then maintain) a bot to do that? It should not be a unique bot for this source, but a bot framework where I can easily add new sites, from where to download stuff, and what metadata to add. --LA2 (talk) 20:34, 16 March 2024 (UTC)[reply]
yeah, i wished for an text upload wizard, but it did not get taken. such is the technical support - tools keep breaking and being sunset. but a task flow from scan to IA to wikisource limps along. we have all the work we can do with printed books. newspapers and periodicals are a sideshow. --Slowking4digitaleffie's ghost 22:47, 16 March 2024 (UTC)[reply]

Header broken on all mainspace pages (urgent)[edit]

"bad argument #1 to 'fetchLanguageName' (string expected, got nil)." is appearing on every page across the site that invokes Template:Header. I've been trying to figure out what's causing the error to appear now to implement a temporary fix, but have been unsuccessful. @Xover, @CalendulaAsteraceae: any ideas? SnowyCinema (talk) 07:20, 17 March 2024 (UTC)[reply]

@SnowyCinema: I'm looking into it. Xover (talk) 07:25, 17 March 2024 (UTC)[reply]
Ok, pretty sure I see the problem. Working on a fix now. Xover (talk) 07:40, 17 March 2024 (UTC)[reply]
@Xover, @CalendulaAsteraceae: It appears to be fixed now per @Uzume:'s suggestion here. Hopefully this change will apply every nook and cranny. What do you think Xover? SnowyCinema (talk) 07:50, 17 March 2024 (UTC)[reply]
It should indeed be fixed now. I'm watching the tracking category slowly tick down (around a 100k now), but it's going to take a while for all of them to clear. For any page where you're still seeing it, a regular purge should clear it. Xover (talk) 08:09, 17 March 2024 (UTC)[reply]
That is caused by includes/Engines/LuaCommon/LanguageLibrary.php#132 which checks the arguments and requires first one to be a string type. I suggested a workaround in the sandbox. —Uzume (talk) 07:53, 17 March 2024 (UTC)[reply]

Tech News: 2024-12[edit]

MediaWiki message delivery 17:39, 18 March 2024 (UTC)[reply]