Wikisource:Scriptorium

From Wikisource
Jump to navigation Jump to search
Scriptorium

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

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

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

Announcements[edit]

Proposals[edit]

Proposal to change {{SIC}} display[edit]

This is a proposal to change what text the {{SIC}} template displays, i.e. making it show the corrected text rather than the original typo. An example of what the repurposed template could look like can be seen > here <, the final presentation, of course, not being definitive (current one thanks to @CalendulaAsteraceae: ). The most important change would be to put the typo in the tooltip and the corrected term on display, and the arguments for this change are the following:

  • SIC doesn't export well at all and the ebook result isn't any different from an overlooked typo, the exception being pdf showing the typo being underlined. The audience most happy with the current use of the template (indeed the only persons who can actually see the tooltip) seems to be editors who browse Wikisource solely on computer and who enjoy reading the typos from the original text. This is a fraction of the intended audience of Wikisource, and in my opinion the mindset is detrimental to increasing the website's reach: with the current use of SIC a reader wanting an ebook with no typos (which is most ebook readers) has no reason to use Wikisource over other book repositories like Gutenberg.
  • The proposed new usage of SIC would still clearly display that a typo has been fixed, and will display the typo as a tooltip, as completely correcting the text isn't the goal here. This is done to respect the original edition of the text, as it still shows how shoddy some books were published, and will be useful to book lovers who want to see how the text has been fixed between different editions. This information, however, will appeal only to a minority audience of Wikisource: this is why it's the typo that should be in the tooltip, not the displayed text.
  • The current use of SIC is awkward with missing typography, as a missing comma or quote mark mentioned by SIC will only show a tiny wave barely bigger than a dot, and is completely useless when the tooltip can't be accessed as it can't show what the deleted sign was. Truly the common practice among editors is to not use SIC at all for missing typography. The proposed new SIC would just display a sign.
  • Fixing typos instead of showing typos improve text readability. It had to be said.

I'll address some counter arguments which have been raised in previous debates on the subject:

  • "This is changing the text, Wikisource contributors shouldn't make editorial decisions, and the text has to be preserved as close as can be to the original" Preserving the text exactly as it was published actually isn't Wikisource's goal, it's Wikimedia Commons' goal, whose scans keep every single flaw of the text just like the real book. Wikisource editors change and make editorial decisions on every single text, whether it is omitting the 3em gap between period and new sentence start, ligatures like st, changing the dreaded ſ into s, displaying the pages in the right order despite faulty original arrangement, or not reproducing the occasional ink blots. Wikisource's goal is to preserve a text and to make it easily readable. The current use of SIC respects the first goal, but not the second one. The proposed new use of SIC would respect both goals.
  • "This will lead to entire texts being modernized to whatever the editor wants, and will make archaic orthograph disappear from Wikisource" As the current SIC template isn't used in that way, I think this would be an unreasonable development. Other Wikisource versions (Spanish and French versions for instance) already display the correction rather than the typo, some for years, and this hasn't led to any loss of accuracy in older texts, as indeed it's meant to be used only for obvious, occasional typos that the original printer would have corrected if aware of them.

I'll add that in case of a lack of consensus, a solution satisfying both those for the change and those against the change would be to implement some kind of switch which would allow to show globally either the corrected text or the original typos, as is done for some other templates. In that case I'd suggest to make it by default print ebooks with corrected text, as, and I want to stress this again, the current use of SIC for ebooks is worse than useless, it's detrimental to Wikisource. --Ostrea (talk) 20:06, 27 March 2024 (UTC)[reply]

 Support - Making SIC display the correct word by default to the reader seems like an obvious quality of life improvement. When an end user is reading the text, they want to read the word that's supposed to be there - they're not doing a scholarly analysis of variant spellings in different quartos, and if the text depended on an exact transcription of non-standard spellings then we wouldn't be using SIC anyway (e.g. I have a dream of putting Robert Record's The Whetstone of Witte from 1557 through the site - that definitely wouldn't be using SIC). Qq1122qq (talk) 21:01, 27 March 2024 (UTC)[reply]
 Support Thank you for writing this up! —CalendulaAsteraceae (talkcontribs) 21:17, 27 March 2024 (UTC)[reply]
 Oppose, strongly: 1) I agree with the counter arguments mentioned above.
2) We often host different editions of the same work. One of the aspects by which they may differ from each other may be e. g. a presence/absence of some typos, and it is desirable to show them by default.
3) The fact there is a typo may give the reader some information too, e. g. that the author was not good in English spelling. I have already proofread some works written by non-native writers which were full of spelling mistakes, and we should not be improving this.
4) The fact that the person who proofreads a work considers something to be a typo does not necessarily mean it is really a typo: it can be e. g. an unusual spelling, obsolete spelling or purposeful change of spelling. I have seen such cases of wrong usage of the template here. If the template shows the original text by default, it makes less harm than if it were the other way, because it is clear that the wrong tooltip is our addition to the text.
5) Ad "fixing typos ... improves text readability". If the original text was difficult to read because of frequent typos, we should keep this aspect in our transcription too. It is not our mission to "improve" original texts. Keeping the typos gives the transcription a tinge of the original text. --Jan Kameníček (talk) 23:50, 27 March 2024 (UTC)[reply]
A lot of your objections are about misuses of SIC, and are easily solved by not using SIC in works for which it's not suitable - if it's important that typos are recorded, then they should be.
This is a discussion about what the default behaviour of SIC should be when someone is reading the produced text. Qq1122qq (talk) 07:34, 28 March 2024 (UTC)[reply]
I completely agree with points 2 and 3! Point 2 would in fact be followed by the proposed new SIC, as it in fact shows where the corrected typos are, and the typo on the tooltip. Showing the typo by default would however only be useful to Wikisource users whose chief interest is to compare different editions rather than read a book, which, given that it's very unusual here for a book to have even 2 complete different editions, is only a fraction of its actual audience.
I hadn't considered point 3 when I wrote up the proposal, as I've had so far only seen SIC used in obvious printing errors. I don't think SIC, old or new, should be used in cases where the typo comes from the author rather than the printer, whether the author typo is intended or not.
Point 4 wouldn't be affected by the SIC change, as a new SIC still would show where the corrected typo is. It would indeed ask more (minimal) effort to check what the typo originally was by placing your mouse over the tooltip instead of being able to read it right away, but the harm in that exceptional and fixable case is vastly outmatched by the harm of normal intended use of current SIC, which is to show untooltiped typos in ebooks.
As for point 5, it is our mission to make older texts readable and accessible while preserving them; we're not preserving ink blots or misprinted punctuation either. New SIC still preserves typos and indicate them, it just doesn't make them the main focus, which is what old SIC is doing. Ostrea (talk) 08:36, 28 March 2024 (UTC)[reply]
 Oppose I loathe the template at the best of times, so tinkering with it is not going to improve it any—nor cause me to start using it. Some works here are unreadable because of the use of this template, with its underlining or (on my eReader) highlighting the text. Changing it to display the supposedly correct text is not going to take away the ugliness that is produced by tooltips. Its misuse for things like user translations of phrases from other languages will not be helped by displaying the alternate text. Deprecate it instead and remove all uses. The quiet template {{sic}} is by far the preferable option where it is felt that an egregious typo should be marked. Beeswaxcandle (talk) 06:45, 28 March 2024 (UTC)[reply]
 Oppose. As you can see just above, some people find even the current {{SIC}} to be way over the line into annotation territory. I am not personally that conservative (I think {{SIC}}, when used as intended, is fine), but I think showing the corrected text is a step too far. There have been some really egregious misuses of it as is and I am not keen on expanding the scope of its use.
One of the main differences between Wikisource and Gutenberg is our verifiability to a scan and that we preserve the original text as published, including being careful to distinguish which particular edition of a work our text represents. To say that "everyone" wants to see typos corrected is extrapolating personal preference too far: some proportion of our ebook readers will certainly prefer that, but our content is reused in all sorts of ways and for all sorts of reasons.
But if {{SIC}} doesn't currently export well that's an issue that can be addressed. I haven't run into that issue as yet, but from your description it sounds like the first thing we should do for the short term is to remove the underlining on export. WS Export doesn't have the facility to let the user express preference for things like this, so until it does it will be whatever is the default in {{SIC}} that gets exported but we can apply export-specific styles to it. We can possibly implement a way to switch between the two when viewed in a browser, but that seems a bit over-engineered for the actual need. Xover (talk) 08:35, 28 March 2024 (UTC)[reply]

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]
Bot flag granted for six months while work on updating Phebot is happening. If SodiumBot needs to take on other tasks, please seek community approval. If time period needs to be extended beyond the six months, please request on WS:AN as we approach 22 September, 2024. Thanks, Beeswaxcandle (talk) 17:22, 22 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), Thursday 9:39, 28 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)

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]

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]

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]
@Beleg Tâl: I feel your pain, but I think it is a very bad idea to put a username in any page name outside User: space, I think it's a very bad idea to make temporary placeholder templates, and I think it is a very bad idea to react to a proliferation on half-broken templates by adding yet another deliberately half-broken template.
I might suggest a more productive channel for that frustration is collecting a structured description of use cases along with problems with existing templates somewhere. It is conceivable that we'll be able to "solve" (fsvo) this eventually, but it will at very least require that the issue works its way up to the top of someone's list of annoyances, and for that a structured description of the use cases and problems will be essential. Xover (talk) 09:43, 27 March 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 [1] but it was renewed in 1989 [2] --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,[3] and there is a 1953 russian Checkhov edition [4], but mainly Richardson translations. [5] --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]

  • Ineuw: The book just came in. The title page says “HARPER & BROTHERS/PUBLISHERS/NEW YORK AND LONDON/MCMXXX.” The publication in New York makes it public domain in the United States and a United States work, meaning that it can be uploaded at Commons. Do you want to use the PLI copy, or would you like me to scan my copy? TE(æ)A,ea. (talk) 18:03, 21 March 2024 (UTC)[reply]
You are too kind. I don't know what PLI means. Also, is yours a hard copy? How would you scan it to share it? This is a subject about which I am ignorant, but I have no wish to burden you by imposing on your time. However, if you teach me to fish, . . . . . — ineuw (talk) 23:27, 21 March 2024 (UTC)[reply]
  • — ineuw: The copy Beardo identified (here) is from the Public Library of India (PLI). PLI is known for (1) a laissez-faire attitude to copyright law and (2) poor scans. For me, I just ordered the whole book (from ILL), so I could scan the entire book if you’d like. As for imposing, I’ve actually set up a system (here) for scan requests, so it’s no big deal. TE(æ)A,ea. (talk) 15:40, 22 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]
@Jan.Kamenicek: You can "Hide" both sidebars, to make them become dropdown menus, and recover the horizontal space. There is also a "constrain width" widget floating in the bottom right corner where you can toggle between full-width and constrained-width layout. Xover (talk) 09:09, 24 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]
i would make timeless the default skin on wikisource. --Slowking4digitaleffie's ghost 00:58, 21 March 2024 (UTC)[reply]
If you are using Vector2022 and click on a not-so-small gray button that says "hide", the sidebar will collapse and in fact you get even more width space to proofread. This is definitely an improvement in that sense. Ignacio Rodríguez (talk) 17:54, 21 March 2024 (UTC)[reply]
yes, it is an improvement over flat sidebar gadget. the menus remain a problem. --Slowking4digitaleffie's ghost 22:52, 25 March 2024 (UTC)[reply]
enWP complaining about something isn't really a useful yardstick. There's complaints if anything changes, and complaints if nothing changes. What would be useful is testing the new skin with all our local stuff on enWS and reporting concrete issues. Some of them may be with community-controlled things that we need to fix ourselves (see e.g. the broken user scripts and gadgets mentioned above), while others may be things we need to report upstream (in which case we need a good concrete description of the problem). Case in point, the Index: namespace has been exempted from Vector 2022's constrained-width layout because it didn't work well there and someone filed a good bug report about it. Xover (talk) 09:14, 24 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]
Per the above, I have now made both Gadgets default. They can be turned off again per-user in your Preferences. Xover (talk) 12:49, 27 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]
@LA2: That particular site offers a IIIF manifest, and there are IIIF downloader utilities out there that can make the download part a bit easier. But solving this in the general case is impossible because every site is different. Not that we can't build a tool to streamline this process as much as possible, and there's lots of potential for improving things for users, but it's a lot of work both to make and to maintain and it would still not be anywhere near painless. Xover (talk) 09:05, 24 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]

Bug report[edit]

I left three bug reports at MediaWiki talk:Gadget-Fill Index.js. Ignacio Rodríguez (talk) 04:00, 20 March 2024 (UTC)[reply]

@Ignacio Rodríguez: I've seen them, but not had time to look closely at them yet (and my backlog is pretty massive just now). Sorry. Xover (talk) 13:44, 23 March 2024 (UTC)[reply]

Disambiguating encyclopedia articles from works[edit]

I have always had a significant issue with our common practice of including encyclopedia articles, such as those from EB1911, Nutall, NSRW, etc., in disambiguation pages alongside other works. Some quite poignant examples exist at Jalna and Surakarta.

The crux of my argument is centered around the very concept of a disambiguation page itself. It's meant to disseminate confusion from works of the same title. And no one would ever confuse a novel with an unrelated encyclopedia article. Think about this in conversational form:

A: "Hey, have you ever heard of 'Jalna'?" B: "Oh, yeah, I loved reading that, that was a great novel!" A: "No, I was talking about the 1911 Britannica article about a town in India."

Like what? Who would ever say this as a response? That is what you're implying when you put something on a disambiguation page—that it's reasonable to think that someone might confuse a popular novel with an obscure encyclopedia article.

I admit that I don't know exactly how you would technically classify an encyclopedia article, in the bibliographic sense, and it has been noted that "a long encyclopedia article may even be regarded as an academic masterpiece". And this may be true—in fact, there are even (very rare!) instances where encyclopedia articles have been republished in some other form. But, we have to consider the context in which these articles exist—whereas something like an essay, a paper, a speech, or even an article in a periodical or newspaper, would be intended to be found on its own and regarded as its own individual property, an encyclopedia is specifically designed to be searched. In other words, you're never looking for the encyclopedia article for its own sake—you're looking for it because you want some specific information. You're using the broader work (Britannica) for the purpose of finding information about Jalna, and it never occurred to any reader that the article on it was even its own unique entity at all.

I wouldn't want to include "Jalna" the encyclopedia article on a disambiguation page, for the same reason that I wouldn't want to include every magazine issue editorial titled "Editorial" in a disambiguation page called Editorial—the editorial is intended to be searched from the issue, the same as the encyclopedia article is meant to be searched from the encyclopedia.

I do understand that in the case of Surakarta and many others, there is a counterargument some of you may make, in that encyclopedia articles have use in being disambiguated from each other. But in this case, really we need more extensive portals, and perhaps a separate searching technology specifically for our dictionaries and encyclopedic works, (I'm not kidding, this would be extremely useful and I'd love to see something like this), but it just doesn't seem like disambiguation pages are the place to be doing this.

Pinging @Beleg Tâl, @Neo-Jay: who I've talked with about this previously. SnowyCinema (talk) 14:14, 21 March 2024 (UTC)[reply]

As formulated, I disagree with this. But perhaps there is an underlying problem behind your reasoning for which one can find a solution that we agree on?
Encyclopedia entries are both practically and bibliographically stand-alone works (one can quibble about single-sentence entries and such, but one can't generally say that they are not in this context). And the purpose of disambiguation pages is to disambiguate among works with near identical titles. See Hamlet, in particular the original, vs. Lamb's bowdlerized version, Hazlitt's commentary, the three encyclopedia articles, and the encyclopedia article for the opera.
I've also sometimes been annoyed by the need for dab pages when there are only two works listed, and one of them seems very incidental or insignificant. But over time I've come to the conclusion that this stems from assigning too much significance to wikipage names (that's why enWP has big fights about a term's main topic: do most people mean the type pf small settlement or the play?). Having dabs is good, even if sometimes annoying for Wikisourcerers running into naming collisions.
The flip side is long dab pages like Poems. Some of these are inevitable (they're the corner-cases like Poems specifically, for which there's no good solution), but for others the straightforward solution is to add some structure to the page. So, for example, perhaps split different types of works to separate subsections, so that encyclopaedia articles are in their own section? Xover (talk) 15:33, 21 March 2024 (UTC)[reply]
@Xover: You say that "as formulated" you disagree with this, since you say that both practically and bibliographically they are stand-alone works, but could you elaborate on why and in what sense? I'd be interested to see the specific reasoning for this, and how it would refute that encyclopedias are functionally designed to be searched, with their articles existing more as "searches" than as individual works; while an essay or a poem are almost guaranteed to be published in multiple sources, to be clearly seen as standalone works in the sense that they are understood to be sought after in isolation? I am just saying it's misleading to treat encyclopedia articles as if they are sought after as the things themselves rather than the topics they represent. When I say the word "Elephant" in a sentence, how likely is it that I'm referring to the Wikipedia article on elephant if "Wikipedia" or "article" aren't in my sentence? SnowyCinema (talk) 15:48, 21 March 2024 (UTC)[reply]
Addendum: One could also say, in exactly the same way, that forewords of novels are works in their own right (since some form of those very forewords might one day be found in a periodical, who knows!). And in some technical, academic sense maybe they are, but would this justify a 500,000-item disambiguation page at Foreword? SnowyCinema (talk) 15:54, 21 March 2024 (UTC)[reply]
See Preface (Johnson). Xover (talk) 16:16, 21 March 2024 (UTC)[reply]
@Xover: Mmmh, this appears to be a rare edge case; it's a well-researched (and interesting!) versions page where the changes are noticeable, distinct, and span several different authors and publishers across eras. But to use this notable piece of Shakesperean literatary history that happens to manifest itself in the form of a preface, as a precedent for the rest of the millions of prefaces out there, is not a place I'd go with my lukewarm acceptance of it. And to be honest, I'm in the mindset that this belongs in another namespace or in some other structure, but I have no specific ideas and Versions makes sense within the confines of the little structure we have to work with. SnowyCinema (talk) 16:59, 21 March 2024 (UTC)[reply]
I very strongly agree with this position. Consider the page Poems mentioned above. In my opinion, it would be inappropriate and rather ridiculous to include on that page every encyclopedia and dictionary that happens to contain an article about "Poems". I would argue, as Billinghurst argued to me nearly a decade ago, that to be considered as a separate work for enWS purposes, the "component will have been separately published and outside of the bible" (replacing the bible with the encyclopedia in this case). —Beleg Tâl (talk) 16:58, 24 March 2024 (UTC)[reply]
The examples in that older discussion focus on poems and passages included within a larger work, and I agree somewhat that those are edge cases and might be worthy of such treatment. But encyclopedia articles for most major encyclopedias have their own authors and citation information from specific editions. That is, whereas The Walrus and the Carpenter will appear in the same chapter of its containing work, it does not have set pagination nor a separate author from the author of its containing work. Encyclopedia articles typically do have their own separate authorship, and are as much a work in their own right as a poem included in an anthology. Also, to be clear, it is not an article about Poems that would be listed for disambiguation, but an article titled "Poems". --EncycloPetey (talk) 00:32, 25 March 2024 (UTC)[reply]
Re articles in reference works being on their own they also frequently cross-reference each other, overlap with multiple different entries under the same header, have varying degrees of set clear pagination and are almost never independently reprinted. Multiple authorship also seems to be weird as a main deciding criterion to clue on IMO, e.g. when later editions add additional chapters to a book, now those original chapters have "own authors and citation information" and are now independent works but they weren't before?
Poems is a bit of an edge case as it goes into the Main / Portal linking issue as well and how Poems, Portal:Poetry and Category:Poems all interact but that is its own separate specific rabbit hole. Note that The Walrus and the Carpenter is frequently anthologized as a separate work on its own with its own chapter, set pagination etc. which causes issues as well if we then version those but not the original publication... MarkLSteadman (talk) 00:02, 27 March 2024 (UTC)[reply]

@SnowyCinema: I concur with your sentiment that every Foreword and Editorial should not be listed on disambiguation pages, but not for the reasons you've given. A Foreword is a description of the item, and not its title. We would not list every "Chapter I" on a disambiguation page, because that is a label, and not a title. Likewise, an Editorial is a kind of work, not the title of a work, and disambiguation pages should list works with a given title, without listing works described or categorized using a given label. Having worked on Wiktionary, the equivalent language is: labels are common nouns, but titles are proper nouns. And "foreword", "index", "editorial" are identifying labels, but not titles. --EncycloPetey (talk) 00:52, 25 March 2024 (UTC)[reply]

We have similar issues with things like Sonnet where they may be labeled by number as well by first line, and presumably Untitled or such some placeholder if we consider neither of those the actual title since not provided by the author. MarkLSteadman (talk) 01:59, 25 March 2024 (UTC)[reply]
Disambiguation pages are searching aids and title disseminators, so to include an encyclopedia article in them is functionally useless. The way those titles are referred to, as I said, is always "Jalna in the Encyclopedia Britannica" or the like. No one on earth has trouble telling the difference between a specific encyclopedia article about Moby Dick and Moby Dick itself. Whether or not they have different authors is beside the point, it's about the fact that encyclopedias are designed to be searched and not considered in their own right. Which is why, whether or not you want to say in some academic sense that they're "works" by some technical nitty-gritty classification, you can't say that they're standalone in any sense. The standalone work is the encyclopedia, is the dictionary. Any entries in them are just that, and they're meant to serve the purpose of the encyclopedia, not to be found on their own. SnowyCinema (talk) 06:58, 25 March 2024 (UTC)[reply]
You keep asserting that, but it's just not true as a general statement. Most encyclopaedia entries, sure, they're short blurbs that are mostly interchangeable, like dictionary entries, and primarily have value as a part of the larger work they are contained in. But the EB1911, and Grove, and a lot of others have entries that are long, well researched, with a distinct author, can have multiple editions, etc. In fact, in Grove (now owned and online at OUP) each entry gets its own DOI, and even has different DOIs for each edition of an entry. EB1911's entry authors are also often leading experts in their fields, and well-know and published outside EB1911 (see e.g. Sidney Lee, who is known today primarily as one of the leading Shakespearean scholars of his era). There's no practical difference between these an a short story in a short story collection, or a paper in a collection or festschrift. Xover (talk) 07:15, 26 March 2024 (UTC)[reply]
@Xover: The difference is that, and while Wikisource doesn't represent this often enough in practice, short stories and poems that appear in collections are almost guaranteed to have been published in multiple different sources, like periodicals, newspapers, or other collections, so they should categorically be considered as standalone works and categorically be assumed to exist in many versions. So the short story collections are effectively just collections of works, while an encyclopedia is more like a searchable database for information. I am aware that many encyclopedia articles are long and well-researched etc., but that's besides the point. I'm certain that many prized academics have also contributed a lot to Wikipedia's articles, but that doesn't make them standalone works in the same sense as a story. I'm sure some of the entries in these old encyclopedias were reproduced in other works, but even then oftentimes they become something fundamentally different later by reference. So, it's no longer EB1911's article on Moby Dick, it's now EB1922's update on Moby Dick, or EB1936's article on Moby Dick, you know? It's never just "Moby Dick: The Article". So these responses I'm getting don't address my primary concern, which is that while short stories are quite easy to categorically be considered in their own right and can be referred to explicitly by their titles without any adjacent context, the EB articles have to be referred to in the context of the encyclopedia or no one would ever understand what you were talking about. And that goes to the broader point as well: that no one would ever confuse Moby Dick the novel with an encyclopedia article about it, because it doesn't even make logical sense to lump the two together in this way as if they could be supposed to be the same. Also, no one has answered the hypothetical I gave before, which is if I used the word "Elephant" in a sentence, how likely is it that I'm referring to Wikipedia's article on the topic, if "Wikipedia" or "article" aren't in my sentence? SnowyCinema (talk) 08:35, 26 March 2024 (UTC)[reply]
No, but that's a contrived example. Cf. below, "William Shakespeare" could refer to one of any number of works that are substantially similar in subject-matter (biographical information about him and his works), but where some are in the form of encyclopedia articles, some are essays from collections, some are scholarly monographs, some may be fictionalized retellings of his life. It is quite common in the literature to see footnotes citing Lee (1904), Chambers (1930) with the full reference to a encyclopedia entry and a monograph (respectively) appearing in the bibliography. Depending on citation style used, these can appear as "Lee, Shakespeare" and "Chambers, Shakespeare" or any number of other variations. The point being that these do not treat encyclopedia articles and monographs differently. Your point is a valid one that applies to a lot of encyclopedia articles, but you cannot generalise it to "all encyclopedia articles".
You'll also note that nobody (serious) cites Wikipedia; they cite the article "William Shakespeare" on Wikipedia at a given date and time (or revision). "Wikipedia" as a work is somewhat meaningless; it's a tool for creating and a site for hosting the works it contains, which are the individual articles. Xover (talk) 09:04, 26 March 2024 (UTC)[reply]

I will just comment that I see three intersecting questions: 1. Workflow. For example, on WP if I want to find out about "Shakespeare, New Mexico" I can search Shakespeare --> Main topic (William Shakespeare) --> disamb page --> article, but on WS do we want to mirror the same flow to find information or do we expect a different workflow? 2. Bibliography of subpages. Which subpages are "works" and merit specific indexing and which works aren't? Is a Chapter in a Novel entitled Shakespeare independent? Is The Common Reader/Jane Austen a separate work because it is non-fiction now? Or only if it is by a separate author? Or republished and excerpted outside with sufficient notoriety etc.? 3. The actual construction of the redirects / links to those works from Main. For example does that link from Jane Austen, Jane Austen (1925), Jane Austen (Woolf) etc.? Do we have to create disambiguate pages at those points too? Do we merge "Shakespeare" and "Shakespere"? Do we consider encyclopedia articles by their titles like "Austen, Jane" / "Shakespeare, William" and disambiguate only under those names etc.? MarkLSteadman (talk) 01:52, 25 March 2024 (UTC)[reply]

I think only the second of those questions is really what is being addressed here. We don't have a workflow such that people would find "works about Shakespeare, NM" at Shakespeare, only "works titled 'Shakespeare'". As for whether to list similar titles together or separately, that is generally done on a case-by-case basis, which is why Sonnet and Sonnets are separate pages while A Sonnet is not. —Beleg Tâl (talk) 01:58, 26 March 2024 (UTC)[reply]
@MarkLSteadman: The Common Reader/Jane Austen, and the other essays in that collection, are stand-alone works, yes. In fact a number of them appeared stand-alone in The Times Literary Supplement before being collected there. Most fiction chapters (i.e. novels) will not fit this definition for the simple reason that each chapter does not stand alone, and the chapters are meant to be read in sequence (and are normally never published individually). But in collections of essays or short stories each individual piece is atomic. There are certainly edge cases out there, but the general rule is fairly clear.
All three of those redirects you list seem reasonable. But redirects are mainly about convenience or preserving links to an old title, and not so much about disambiguation.
Disambiguation pages are about distinguishing between works with an identical title, since we cannot let all works live on the same wikipage title otherwise, and as a finding aid to readers. Consider, for example, the Sherlock Holmes stories: most people will be looking for A Scandal in Bohemia with no idea that it was first published in The Strand Magazine in vol. 2, issue 7. What they need is A Scandal in Bohemia, a versions page, to tell them we have two versions of that text. Readers looking for "William Shakespeare" may be looking for any one of Sir Sidney Lee's encyclopedia article in the DNB, E. K. Chambers' seminal William Shakespeare: A Study of Facts and Problems, Park Honan's Shakespeare: A Life, or Stanley Well's Shakespeare: A Life in Drama, or any one of a whole host of other works whose primary title is a permutation of "William Shakespeare". The same goes for "Hamlet", which may be any version of the play, the Bowdlerized editions by the Lambs, Hazlitt's commentary on the play (an essay published in a fixup collection, designed to be read sequentially), several operatic versions inspired by the play (and some independent inventions), and a bunch of poems. The main unanswered question there is the precise definition of "identical", and that's an issue on which reasonable people may disagree. I favour a fairly permissive "…and substantially similar" type definition, but you can't really say someone that argues for seeing "William Shakespeare" and "Shakespeare, William" as distinct is "wrong". Xover (talk) 08:49, 26 March 2024 (UTC)[reply]
Right, but do we make a distinction between "Moby-Dick" (novel) and "Moby Dick" (article), The Tempest, Tempest, Tempest, The and Tempest, Marie, The Monk, Monk and Monk, James Henry, Kubla Khan and Kublai Khan, etc. The original example might make a distinction between Surakarta articles about the place and The Surakarta the novel, for example. I mention redirects as that is how these are implemented, given we are talking about works in a containing work, we only encounter clashes between the main work and the redirect to the encyclopedia articles. Which is why I started with the first point, these exist as aids for the reader. Personally, I favor more disambiguation, more linking, more discovery, probably more portals to provide structure etc. If we want to through more illustrations, great. But that is my personal opinion. MarkLSteadman (talk) 14:00, 26 March 2024 (UTC)[reply]
It isn't obvious that if you want Shakespeare: A Life search for "Shakespeare" and William Shakespeare: A Study of Facts and Problems search for "William Shakespeare," as a position is wrong. I.e. that someone searching for "William Shakespeare" might be taken literally and not see the Honan or Well work. I think it is wrong because we should favor discoverability and "wikiness" over exact searching like a catalog, but YMMV. MarkLSteadman (talk) 14:10, 26 March 2024 (UTC)[reply]
I am not seeing the harm, at all, in listing encyclopedia article titles on a disambiguation page. BD2412 T 19:56, 26 March 2024 (UTC)[reply]

Invitation to join March Wikisource Community Meeting[edit]

Hello fellow Wikisource enthusiasts!

We're excited to announce our upcoming Wikisource Community meeting, scheduled for 30 March 2024, 3 PM UTC (check your local time). As always, your participation is crucial to the success of our community discussions.

Similar to previous meetings, the agenda will be split into two segments. The first half will cover non-technical updates, such as events, conferences, proofread-a-thons, and collaborations. In the second half, we'll dive into technical updates and discussions, addressing key challenges faced by Wikisource communities.

New Feature: Event Registration!
Exciting news! We're switching to a new event registration feature for our meetings. You can now register for the event through our dedicated page on Meta-wiki. Simply follow the link below to secure your spot and engage with fellow Wikisource enthusiasts:

Event Registration Page

Agenda Suggestions:
Your input matters! Feel free to suggest any additional topics you'd like to see included in the agenda.

If you have any suggestions or would just prefer being added to the meeting the old way, simply drop a message on klawal-ctr@wikimedia.org.

Thank you for your continued dedication to Wikisource. We look forward to your active participation in our upcoming meeting.

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

unsigned comment by MediaWiki message delivery (talk) 18:56, 25 March 2024 (UTC).[reply]

@KLawal-WMF: Could you make sure these announcements contain a standard signature (see diff) so that Reply-Tool and Vector 2022's auto-toc features work? Xover (talk) 09:34, 27 March 2024 (UTC)[reply]

Tech News: 2024-13[edit]

MediaWiki message delivery 18:56, 25 March 2024 (UTC)[reply]

{{Header}} template and misleading publication dates[edit]

I have been doing work on various 'collected works' and noticed that misleading date information is appearing against individual works from these collections. Using 'The Complete Poetical Works of Percy Bysshe Shelley (ed. Hutchinson, 1914)' as an example:—

In the main page The Complete Poetical Works of Percy Bysshe Shelley (ed. Hutchinson, 1914), the year field is filled in '1914' and the title is displayed as 'The Complete Poetical Works of Percy Bysshe Shelley' (1914), as normal.

On the subpages for each individual poem, if there is no Wikidata link, the title of the overall work appears in the same way. The 'year' field is not used on these pages, so no date appears.

For subpages that do have a Wikidata link, the date of publication entered in Wikidata is displayed in the title. In most cases, this date is that of first publication (in the case of Shelley's collected works, given in a note at the head of each poem). Unfortunately, this date appears immediately after the title of the overall work (e.g. for 'Lines to a Critic', the main title appears as 'The Complete Poetical Works of Percy Bysshe Shelley (1823)'. This gives the impression that the 'collected works' was published in 1823, which is not the case.

I question the need for this date linkage to Wikidata, but if it is judged to be necessary then what is displayed should have some associated text to make it clear what the date is, and it should be placed either after the 'section' field (or better, in the 'notes' field), not the 'title' field. Chrisguise (talk) 10:56, 26 March 2024 (UTC)[reply]

@Chrisguise: For "Lines to a Critic" that's because the Wikidata item was handled wrong. It is being treated as if it's the work item, but it links to our version of the poem. This is a quite widespread issue on Wikisource and, in general, we need to correct all instances where this has happened. I do think we should prefer handling this in Wikidata over not doing that, but maybe we need to make it so that we only pull from it if it's marked as an instance of "version, edition, or translation". SnowyCinema (talk) 11:09, 26 March 2024 (UTC)[reply]
@CalendulaAsteraceae: What is your opinion? SnowyCinema (talk) 11:10, 26 March 2024 (UTC)[reply]
@SnowyCinema: I think that only pulling dates if the WD item is a version/edition/translation is the way to go. I can take a look at the code soon-ish. —CalendulaAsteraceae (talkcontribs) 19:57, 26 March 2024 (UTC)[reply]
Would doing so affect Versions headers? --EncycloPetey (talk) 22:06, 26 March 2024 (UTC)[reply]