Wikisource:Scriptorium

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

Proposals

Proposal to change {{SIC}} display

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)

 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)

 Support Thank you for writing this up! —CalendulaAsteraceae (talk • contribs) 21:17, 27 March 2024 (UTC)

 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)

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)

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)

 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)

 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)

You'll find that both our personal preferences tint our views on what the intended Wikisource audience is! If I get you properly, your assumption is that it tends towards the archivist/scholar type, who'll come to Wikisource to find preserved documents that couldn't be found on other websites (except on wiki commons). My own assumption is that, while we do get researchers and scientists who'd rather read our completely-rewritten-as-close-as-possible-to-the-original texts than the actual original texts (which are on wiki commons), the main audience of Wikisource is the actual general audience, novel readers and the like. A poll on audience wishes would be interesting, but in its absence a cursory look at wikimedia statistics imply that the actual situation leans towards my point of view.

Now none of us imply (yes, not even me) that "everyone" wants to see typos corrected or not corrected, as indeed if there was a consensus there would be no discussion. But what is the SIC use which would accommodate the most people?

Old SIC accommodates Wikisource editors who want the text displayed to have the original printing typos (which isn't the same as wanting to have an accurate text, as no editor transcribes accurately every typography quirk of the original text), and the archivist/scholar who is glad that they can read the original typo right away instead of having to move their mouse over the text to check it (assuming researchers don't study texts by downloading ebooks of them and reading them on their phone, which would remove the tooltip). It inconveniences all those who want to read a text without printing typos, which I will assume is an important part (again, not "everyone") of the general audience. New SIC would inconvenience these two previous categories (which are very important categories, as one of them is the actual decision-maker on template changes), and accommodate most ebook-readers, as well as archivist/scholars who don't mind about printing typos or about hovering over indicated corrected text to see what the original typo was. As to which audience we should accommodate, that's a website policy that I can have no influence on! even if it seems to me that one audience clearly outnumbers the other.

Furthermore new SIC would have no influence on copy/pasted text used by scholars who want to use the actual original text in their thesis, as original-typos would still be clearly marked for a scholar to notice and add back at leisure, and no serious researcher would use Wikisource text without carefully reading it first to remove new, editor-added typos.

I'll only frankly disagree on your opinion that expanding the scope of SIC could lead to more misuse. The scope of SIC has been expanded in other versions of Wikisource with no unwelcome result, so I can safely affirm this is a baseless fear.

As to the WS Export, it's only a low priority issue, as it only shows on PDF. I'd argue underlining without tooltip is still more useful than no underlining at all, as it somehow indicates that the editor was aware there was a problem with the word. Ostrea (talk) 10:37, 28 March 2024 (UTC)

 Comment I have stated before that perhaps we should have an approach where we dynamically load a list of "errata" in the text elsewhere perhaps generated in the headers by detected SIC templates, and perhaps something like this would deprecate the need for a tooltip at all, and the correct text would therefore be displayed instead of the typo. My biggest issue with tooltips is that they don't work well on exports or mobile views, and are designed for desktop views (pretty much the only view to Wikisource around the time the template was originally created). But I do think that recognizing where typos and other inconsistencies exist is extremely important, since they can aid in discussions about publication or revision history of certain works, about historical typographical or linguistic tendencies, etc.

Just so everyone is aware, there are literally examples of literary errors that became famous or iconic throughout history. One example I can think of offhand is the "all your base are belong to us" fad of the early 2000s which has its own Wikipedia article (although I know this wouldn't be nearly old enough to be PD). But there are many older examples. I recall there are several examples of newspaper editors accidentally leaving random curse words in the articles because they were bored sitting at the typewriter and forgot to remove them, things like this. While I mistakenly thought there was an entire Wikipedia article listing famous historical typos, (but like, why isn't there???), you can find loads of articles online about these and they're fun to read about. Anyways, they're historically important, ok? Just trust me on that. SnowyCinema (talk) 10:16, 28 March 2024 (UTC)

The list of errata is indeed a solution present on the french Wikisource, which I find very convenient! It's however a more important change than just reversing the SIC template, which is why this proposal is more modest in scope, and aims to at least gather what is the general opinion on "displaying typo" vs "displaying corrected text". I don't think list of errata could be agreed on without at first agreeing on the "displaying corrected text" philosophy...

Probably one the most most famous misprinted works is the Wicked Bible, which sadly isn't apparently yet on Wikisource. When such a typo is a matter of fame, I'm sure there could be found grounds to leave it untouched! Ostrea (talk) 10:48, 28 March 2024 (UTC)

 Comment - I'm not going to vote yet, since there are some issues in the comments I'm making here that complicate things.

• I'd consider the possibility of creating a new template instead, which I would prefer (not least because the name "SIC" implies that what is displayed is as given in the original).
• Related to this is unexpected uses of {{SIC}}. In particular, it's been used by some contributors to show when hyphenation is inconsistent in the tooltip. Obviously if we want to change the behaviour of {{SIC}} this would need to be removed (replaced by {{tooltip}}?) first; again, this would not be necessary with a new template.
• I note that on some pages of the EB1911 transcription we already have typos being amended in the text, with a tooltip showing the original text. IIRC this is done manually (by using a span, without a template).
• I also note that in the course of migrating some works to scans I've been in the situation of having to introduce typos such as errors in punctuation. While I don't really mind this, it does seem a bit weird to actively make the work worse for the end user. The tooltip not being readable on export does seem to be an important factor here, by the way (and is something that was brought to my attention recently).
• Finally, {{SIC}} is mentioned in Wikisource:Annotations as a non-annotation. This may need to be revised if the template is changed.

Arcorann (talk) 11:26, 28 March 2024 (UTC)

Point 1 and 2 could imo be addressed by adapting the SIC documentation to clarify its goal, point 5 will also eventually be done when the change takes. A name change of new SIC could be done if there's a strong demand for it, but I don't see it as so explicit that it would confuse users in its purpose. I wonder if point 3 is following current Wikisource policy... Concerning point 4, old SIC making the work worse for the readers except for those interested in seeing all the original typos is precisely why I'm for the SIC change Ostrea (talk) 10:43, 29 March 2024 (UTC)

It really shouldn't be unexpected that textual inconsistencies (hyphenation, italicization, use of accents) are marked as SIC in many texts. They are typographical errors in most cases, especially if being done in the context of the same story, nonfiction book, or novel. What other sites like Gutenberg will often do in these situations is just correct the error, i.e. make all hyphenations the same throughout the text. If a user had the right software tools, they could actually figure out that there was inconsistent hyphenation in any given text (which is something I can do with my software). Sometimes, these inconsistencies literally happen on the same page as each other, so they can be more obvious in some contexts. It's a specific distinct classification of textual error that appears in almost every work I've ever seen, thus deserving of its own separate template.

It can also have implications for Wikisource proofreading as well. Sometimes, inconsistent hyphenation is actually our fault, since most hyphenations at the end of page lines are mid-word so they don't need to be preserved—but it's impossible for OCR softwares and the like to determine when this end-line hyphenation is supposed to be preserved or not, so it ends up with a scanno on our part. We end up with situations where "houseparty" comes out of "house-\nparty" very commonly, for example. So the template, like SIC, is also used to distinguish possible proofreading errors from actual hyphenation errors on the part of the original author, to save the time of later editors trying to improve our transcription's accuracy. SnowyCinema (talk) 12:06, 31 March 2024 (UTC)

•  Support As the proposer said, this would increase text readibility, etc. I understand the desire to preserve the original text as much as possible, but blatant misspellings (as opposed to archaic spellings) aren't helpful to anyone. Cremastra (talk) 12:24, 28 March 2024 (UTC)
• Weak  Support. Addendum: Sorry, as it stands, I  Oppose making the change to the current template but I'd support a second template that uses this functionality...
• I do agree that, for all practical purposes, what most readers care about is a working text, and I do like that this change doesn't completely remove the SIC template (as I'm sure some editors here would suggest since they hate the tooltips). But, if we're going to go about this change it shouldn't be the finale for another 15 years. We need to be constantly reworking this SIC template situation, and improving on it with new features. Eventually, I do want the tooltip to go away (à la Beeswaxcandle), but I have no idea what I'd put in its place yet. For now though, a couple points:
  • This template should carry a parameter, an option to display the typo text, for those proofreaders who want to show the original typo rather than the corrected one. We need to be considering in this discussion that different types of works may necessitate correction more than others. Think of who the audience of that work is going to be. A.) For example, are we working with the US copyright catalogs? In that case, Ostrea's SIC would be more useful because a reader is looking for the listings and not concerned about where typos are. And displaying the typo text can actually be argued to be more harmful, especially when we're talking about writing code that's supposed to parse these entries. B.) But for silent films, novels, short stories, poems? These follow a clear narrative top-down structure, and therefore old SIC makes more sense, because researchers of fiction might actually be interested in where the typos appear. This especially makes sense for works that are known to contain a lot of typos, such as certain works by foreign writers (per Jan), or works that were poorly produced for other reasons. But, this is a fine line, and isn't easy to make a rule about: it's probably best to leave it up to individual editors to make a decision.
  • And this actually makes me wonder if we just need a third SIC template for Ostrea's suggestion, rather than to change the SIC template that's already there...
  • PS: A general philosophical sentiment: I will say that, while the general reader of our text is not any "vaguely supposed scholar figure", our WMF sites are generally written and constructed assuming they'll be useful for scholarly research and I think that this is a good thing. This is why Wiktionary isn't an Urban Dictionary clone, and why Wikipedia doesn't use street slang so that their audience of billions can better understand the articles. God forbid our sites become as outright awful for our society's intellectual fervor as today's social media platforms. The WMF sites are some of the only platforms that genuinely keep me sane in this world, giving me real information with evidence and keeping my attention span strong and not weak. I'm not saying this specific proposal is conducive to this so don't get the wrong idea, but I'm saying that the general sentiment of "we should be serving people, not scholars" can lead to bad places if followed in an absolute sense. I do want WS to get more page views, but I want it to better society by encouraging people to read more, not to further the very real and demonstrable trend of attention spans in the general population getting lower and lower specifically because of apps like Snapchat, Tiktok, and Instagram... Just a general sentiment, not related to the proposal itself really, but more to an incidental sentiment.
• Overall, I think there are benefits to your suggestion, but 1. this needs to be an ongoing endeavor and not left as it is, and 2. the very sloppy ideas and notions I just typed out are things I'd like to be considered before this template change is made. SnowyCinema (talk) 13:03, 31 March 2024 (UTC)

  Arcorann mentioned a 2 templates solution earlier (SIC would stay the same and display the typo, a new template would display the corrected text), and I'm getting more and more convinced that it could become a good compromise. Choosing whether or not to use it could then be a style decision the original (or most prominent) editor of a text chooses around the start of the editing work, just like it's done with choosing whether to use long s or not, or curvy or straight quotes. The new template could be done with or without tooltip, but would always have to make it easy to find where the typos are (for instance by showing a list of the typos on the side like >here<, by clicking on "Coquilles (1)" under "Options d'affichage"). As we have no consensus on a global change of SIC, I think if a change is done it's going to be through a solution similar to this. Ostrea (talk) 08:13, 2 April 2024 (UTC)

Strongly  Oppose—hosting editions as published is a fundamental part of the Wikisource ethos and is what differentiates us from other online libraries such as Project Gutenberg. —Beleg Âlt ^BT (talk) 13:44, 2 April 2024 (UTC)

Furthermore, I see that the example text is correcting "longue word" to "long word", which brings to mind the large number of instances where editors have used {{SIC}} to modernize outdated spellings rather than to only correct typos (or otherwise assume that an unusual spelling must be a typo), and that in itself is enough for me to strongly oppose the replacement of original text with corrected text by default across the board for all current uses of {{SIC}}. I would be much more inclined to consider supporting this if it were a new template for texts moving forward, and did not affect existing uses of {{SIC}}. —Beleg Âlt ^BT (talk) 13:46, 2 April 2024 (UTC)

@Beleg Âlt, @Beleg Tâl: What about certain technical works such as copyright catalogs? The copyright catalogs for example have very direct technical use cases, and showing the corrected text instead of the original would make more sense for those. This reigns true for a lot of other works that are catalogs or lists. Would you be opposed to a second template to be used for these other works? SnowyCinema (talk) 15:04, 2 April 2024 (UTC)

I can see why one might want catalogues and lists to be corrected, but as I said before the point of Wikisource is to host them as published. Reference material that is not from a source publication is even explicitly excluded per policy, and I think correcting the published material goes against that (though a separate version of the catalogue with the corrections included could be created as per WS:ANN) —Beleg Âlt ^BT (talk) 15:10, 2 April 2024 (UTC)

@Beleg Âlt, @Beleg Tâl: Is that really the point, though? I think (as Ostrea said) the first and foremost point is to host an array of free source texts, with the added suffix of "and we should stay as true as possible to the original, as a nice touch". There are times in which keeping a bit of the text as originally published would be absurdly complicated and therefore function worse, such as at Fidelia#ToC with the misplaced part in the TOC, and that was a point where a compromise had to be made in order to preserve readability/logical structure. We can't always stay true to the original published text, lest we'd find ourselves in a tough position in many situations. It's why we aren't required to replicate dots in TOCs, and the like, as well. I would be willing to agree with the opposition on the issue of typos in fictional works such as novels, stories, films, etc., where the typos are more likely to have literary value. But the closer and closer you get into nonfiction toward the realm of catalogs and listings, that point gets harder to defend as such. While researchers would probably find value in film typos, no one would find value in an accidental comma in a catalog entry that was meant to be formulaically entered... You and many others seem to be coming at this from the approach of "the philosophy of Wikisource says this", and the philosophy is certainly relevant, but practical considerations (who our audience is, why we lack an audience, what would look better to readers, etc.) should be taken into account, rather than only caring about precedent. SnowyCinema (talk) 15:34, 2 April 2024 (UTC)

I think that this whole proposal and discussion seems to boil down to the philosophy of Wikisource. I strongly disagree with Ostrea's suggestion that being true to the original is only "a nice touch"—noting that our policy is "to present these publications in a faithful wiki version". Our recent adoption of WS:ANN as policy further underscores the importance of clean, faithful transcriptions to this project. We have consistently insisted that corrigenda be presented without modifying the text itself (as demonstrated by {{SIC}}, {{AuxTOC}}, {{User annotation}}, separation of user annotations into separate editions, etc). This suggestion, to actually modify the text, goes against all of this. —Beleg Âlt ^BT (talk) 16:17, 2 April 2024 (UTC) —Beleg Âlt ^BT (talk) 16:17, 2 April 2024 (UTC)

I do believe that being true to the original text is essential! But should we really be more faithful to the printer's errors than to the writer's intent? It seems to me that the current situation of preserving misprints in text isn't due to a matter of faithfulness (as neither the printer nor the writer would like faithfulness to go that far), but to the belief that not touching anything about the text (which is still modified in many small ways on Wikisource anyway) is preserving it. Even masterwork paintings get restored!

Wikisource philosophy talks aside, I think like you that new template will be the eventual solution. Ostrea (talk) 20:33, 2 April 2024 (UTC)

@Beleg Âlt, @Beleg Tâl: Yes, and the language you're using speaks to the unfortunate cultural tendency here to put policies, philosophies, and precedents above a practical and self-improving approach. We indeed have quite strong sentiments among our prolific members about certain notions like this one, and this has influenced our policy. But I'd like to add that while the precedent is strong, we've never, ever, ever performed any kind of a survey, statistical study, or the like on exactly how our audiences feel about the presentation of our site. I mean, we don't even know who our audience is, or at least we have very poor ways of demonstrating that definitively.

Let's talk about reality of these "precedents" for a second: our precedents, policies, and the like clearly haven't helped us. We're still living in a world where Wikisource is a barely relevant platform. The majority of our pages (many of which are quite notable works) can barely get 1 page view a month, while even the most obscure Wikipedia articles have at least a few hundred a month. For decades we've relied on the opinions of a tiny community, consisting mostly of long-time prolific editors with specific reminiscences or sentiments or concepts of purity, with very little actual concern for the reader base, or even the less active editor base. The more successful online communities than us take the opinions of the masses seriously, which we certainly don't do.

I'm not saying this should be the only consideration (we should be fostering an intellectual environment, not just designing us for clicking and swiping, yadayada), but we shouldn't just completely dismiss it in favor of long-time editor precedent either. The few active users who are laying oppose votes in this very discussion are about 50% of the "voter" population that solely maintain these very precedents, so I am skeptical that it's very democratic at all. SnowyCinema (talk) 17:35, 2 April 2024 (UTC)

 Comment I just want to add: if {{SIC}} were modified in such a way that (a) preserved the text as published, (b) was clearly a Wikisource addition rather than part of the original publication, but also (c) made the correction clearer and more accessible to address the issues Ostrea suggested—I would consider this non-controversial and would support it wholeheartedly. —Beleg Âlt ^BT (talk) 19:54, 2 April 2024 (UTC)

 Oppose—as it would modify existing texts. See for example: Page:Jane Eyre.djvu/107, Page:Pierre and Jean - Clara Bell - 1902.djvu/306.--M-le-mot-dit (talk) 14:59, 2 April 2024 (UTC)

This is such an inappropriate use of {{SIC}} 🙈 lol —Beleg Âlt ^BT (talk) 16:17, 2 April 2024 (UTC)

@Beleg Âlt: Regarding these pages, I agree. Some are validated for years. I've seen also cases where italics were not correctly placed: such as {{SIC|''toolpit''|tooltip}}; the new system would remove italics. M-le-mot-dit (talk) 18:16, 2 April 2024 (UTC)

 Oppose We're already fighting inappropriate uses of {{SIC}} where non-typos are being modernized because of rare spellings and archaic usages. Flipping the use of the template would bring those editorial changes to the front. Additional arguments about differences between editions have been made above; sometimes the typos are the reason for hosting (or avoiding) a particular edition. Hiding those published typos is a disservice both to readers and to the Wikisource editors who have worked hard to prepare the editions. I'm not convinced by arguments based on Spanish Wikisource, since that project moves slower than a glacier in producing new content. --EncycloPetey (talk) 17:08, 2 April 2024 (UTC)

I see you omitted to mention French Wikisource. I know why! Ostrea (talk) 20:36, 2 April 2024 (UTC)

No, you don't. --EncycloPetey (talk) 22:33, 2 April 2024 (UTC)

 Support (but with a new template, which appears to be what the proposal's settled into) I agree with Ostrea that having a readable text is more important than typos. I've seen cases where the u's and n's were consistently scrambled, at a rate of approximately one error per page. For such quite certain errors, not caused by the writer's bad english and not intentional, keeping it in the tooltip would cause no harm. I think the majority of our readers want to read the text and are not especially interested in the typos (though that is not sure and a poll about it, if it can be done, would be a good idea), and those that are specifically interested in this edition of this text and all its printing errors probably care enough to hover over the word. It would be better if that new template would display differently from {{SIC}} to make it clear that is is not the original text. — Alien333 (what I did & why I did it wrong) 15:04, 3 April 2024 (UTC)

Template:Welcome image change

Apparently this is a thing that happened. The image for the welcome got changed from someone going through books (which is what we do) to some random woman (who is apparently an author, not that the portrait makes it at all clear). I support the change. Other interested editors: Xover, SnowyCinema. TE(æ)A,ea. (talk) 03:24, 9 April 2024 (UTC)

•  Oppose The portrait of an actual English author (George Eliot) is preferable over an imaginary random guy from a painting. The portrait of G. Eliot is more welcoming and inclusive, and is also far less busy visually. More welcoming because the subject is facing the viewer, not facing the other way, ignoring the viewer. --EncycloPetey (talk) 03:57, 9 April 2024 (UTC)

Right, but as I noted in the other discussion, (and as TEA's comment further proves), the image is not universally recognizable. You're assuming that every editor will come from the same background. A book is a universally recognizable symbol, whereas this individual is certainly not. SnowyCinema (talk) 04:25, 9 April 2024 (UTC)

No author will be universally recognizable;that's a bar we cannot reach. And neither is the fictional man from an obscure painting going to be recognizable. Yes, books are widely recognized, but the older image is not that of a book, but of a person standing on a ladder with his back to the viewer. Is that a welcoming image? That image doesn't say "Welcome to Wikisource", but says: "I'm busy so don't bother me." That may be an accurate representation of Wikisource, but it is not a welcoming image. --EncycloPetey (talk) 19:22, 9 April 2024 (UTC)

•  Support I've always felt weird about this change for a lot of reasons, though I wasn't aware of it being a result of a discussion until now, and apparently I wasn't the only one.

• A portrait of George Eliot is not universally recognizable, and people from many different backgrounds will not resonate with the image. At most, she is symbolic of a specific literary movement in Western history...barely relevant at that time outside of Europe...and therefore to many she just represents a random individual on a portrait.
• Also, we are a neutral platform and shouldn't appear that we favor certain authors over others. We can say certain authors are notable, that's fine—but for our welcome template? I know some will claim they didn't choose the image because of some personal preference or bias for the author herself as has been argued, but whether or not that's true, this is favoritism in practice, inherently, even if unintended. Why not choose Blake, Tennyson, Wells, Fitzgerald, Wollstonecraft, Chesterton, Doyle, ... the list goes on? This just creates an argument about who to choose, and that's counterproductive and unnecessary, even if we're just going to count popular women writers in this... So, individual people should be out of the question.

I think the previous image was better than what we had after; it was creative, unique, obscure, unexpected, gives a certain nostalgic appeal that also relates to what we're doing in the modern sense, and was certainly not "too visually busy" whatsoever. I don't think anyone will care that much that the person in the portrait is not facing the viewer. It is a slight downside, sure, but the benefits and relevance more importantly of the image far outweigh this extremely slight and almost unnoticable con in my opinion. SnowyCinema (talk) 04:25, 9 April 2024 (UTC)

•  Oppose but only because I want to make a case for the effectiveness of the G. Eliot painting specifically. When I was welcomed in last fall by the aesthetically pleasing G. Eliot painting, it inspired me to discover her Author portal, and thus begin learning how WS is organized. It was puzzling and inviting. I suppose I did wonder "why her?" over all other possibilities, but I confess I simply enjoyed the non-sequitur enigma of it; it felt like an unexpectedly welcoming artistic and aesthetic flourish (which defied my expectactions and contributed my warming up to WS in a hurry). I also was assuming this photo rotates regularly; so I suppose in that sense I "support" changing it, but I'd hope it could continue to be welcoming, intriguing, and aesthetically pleasing. Not sure I'm even entitled to a vote here, but I thought I might have a relatively different perspective as a new Wikisourcer. Brad606 (talk) 05:02, 9 April 2024 (UTC)

@Brad606: Yes, you are certainly entitled to vote here with your edit count and your time since registration, and I have loads of respect for this direct user feedback and the unique perspectives. I really wish we had more of this kind of thing in our votes and discussions (more often than we should, we rely on the opinions of the hyper-experienced, rather than the end users who the technology affects the most). I think if the image were rotated, using specific authors might make more sense, since it doesn't suggest partiality, so you raise a valid point about that for sure. This is something that (as far as I know) is technically possible, actually, and if George Eliot were one of a diverse collection of 365 author portraits rotated every day of the year, that would be an interesting (and more neutral) way of doing this. SnowyCinema (talk) 05:14, 9 April 2024 (UTC)

Indeed, for this issue in particular, input from a newer (well, relative to some of us dinosaurs; 3+ years is not all that new) contributor is very valuable.

Whether it makes sense to rotate the image I don't immediately have an opinion on, but if we were to opt for that we needn't make a whole catalog of 365 images and auto-rotate (which is hard to do sensibly in MediaWiki). It would be enough to simply say that "this image rotates periodically" and then let people propose changes here. Simple and low-tech, and easy to relate to and maintain. Xover (talk) 06:10, 9 April 2024 (UTC)

• I'm not sure what "support" and "oppose" would be relative to here (support the change that has already happened? oppose that change? support changing from what's currently there to something else, possibly the previous image? oppose changing it further and stick with what currently there?), but I am in favour of returning to the Spitzweig image we had for fifteen years. It's funny and quirky, and more importantly it represents well and directly Wikisource as a project and what we do here. A generic portrait of an author says nothing about this project, except maybe "look how sophisticated we are that we know immediately who this generic-looking person is". Having a specific author leads to endless discussions of this author vs. that author, and kinda begs for a caption for the image in {{welcome}} that explains who the person is and why they are relevant to welcoming new users. --Xover (talk) 06:31, 9 April 2024 (UTC)
•  Oppose, as in opposing the change back to the original picture. The "random woman" in question being a pillar of english literature, I don't think there's an argument for her to be replaced by an actual random man, and George Eliot being unknown by major contributors is all the more reason to actually keep her there. Mind that this isn't a picture to represent the entirety of Wikisource, but to be presented to all new contributors, and new young users could be more enticed to stay and to take the website seriously if welcomed by a young writer than by the quintessence of stuffy old archivist. However it's true that the change done was quite one sided and that the original image has its merits, so I support a rotation in pictures, although not a daily one Ostrea (talk) 09:55, 9 April 2024 (UTC)

It seems to me like English literature had quite a lot of "pillars" (including some of the other authors I've mentioned), and I think these pillars would only interest a certain subset of our contributor base, even if more or less the majority. As I pointed out, users from certain cultural backgrounds, age groups, educational and class backgrounds, hobby/interest areas, etc., may not find her immediately recognizable, personally relevant, or even know her by name. From my own personal experience, even in America, let alone countries completely outside the "global West", she wouldn't be recognizable to most adults... And in the Philippines, you can absolutely forget it.

So, I do agree with Xover's point that the portrait has a certain aura of elitism on our part, an issue I forgot to mention in my vote. It isn't wrong of anyone not to know who this author is, as there are plenty other interest areas in Wikisource's league that are unrelated to 19th century English literature and poetry. For example, maybe somebody comes here out of interest in the history of the Boy Scouts...or engineering manuals...or film history...or the New York Times...or school yearbooks...or a plethora of others.

Well, anyway, the "actual random man" isn't the crux of my argument, as it's not just the man but what he's doing that leans me to favor it. This is something that the Eliot portrait lacks—there's nothing about that image, except the expectation to recognize her as an individual, that makes it relevant (tangentially) to what we do here. SnowyCinema (talk) 12:53, 9 April 2024 (UTC)

• • Ostrea: I know who George Eliot is, I just wouldn’t know off-hand (nor, I think, would most readers) that that portrait is of George Eliot. In addition, George Eliot is by no means the most prominent author we have on Wikisource, and is in general not a good representation. The man is fictional, but that is the benefit; he is an abstraction of the process involved at Wikisource. When representing Wikisource, you can see one tiny facet (with the Eliot portrait), if you can even recognize it, or an abstraction of the basic concept. One is clearly more valuable. TE(æ)A,ea. (talk) 20:32, 9 April 2024 (UTC)
• comment The current picture of George Eliot has been in place for 2½ years (Sept 2021). Prior to that we had the Carl Spitzberg image for 11 years (Oct 2010). There was no painting image used in the versions prior to then. Both images were chosen by User:Cygnis insignis as part of updating the template. I am not aware of any discussion that led to either change. Personally, my preference is for the humour expressed in the Carl Spitzberg image. Beeswaxcandle (talk) 10:16, 9 April 2024 (UTC)
• I'd prefer the old image too. Being french (you don't have to look as far as the Philippines), I'd never even heard of the name of G. Eliot before coming here. I was very puzzled it took me a while to discover that she was an author and not just some picture of a random woman. The Spitzberg one is more clearly related to Wikisource (and funnier). (note: Only been here for a few months, if I shouldn't vote in things like this please tell me so) — Alien333 (what I did & why I did it wrong) 19:56, 9 April 2024 (UTC)

  @Alien333: You very definitely should, and we very much appreciate new users engaging themselves with the running of the project. If there's anywhere we have "experienced users only" stuff an experienced user (natch) will take care of it. Essentially it's a matter of a few kinds of votes where votes by users who are not "established" count less or not at all (and that's for the vote counters to deal with). I can't recall any time that rule actually came into play. We also have a few technical things that are better performed by experienced users or admins, but that's purely for practical reasons (easy to make mistakes that are a pain to clean up, or requires admin tools to do right). But in general I wouldn't worry about that: there's no place or aspect of the project where relative newcomers are inherently not welcome, and in most things it's a "with open arms" type situation. Xover (talk) 06:22, 10 April 2024 (UTC)

Assuming the desired proposal is to change back to the previous image (this should have been stated explicitly),  Support as per Cremastra etc. Arcorann (talk) 05:19, 12 April 2024 (UTC)

 Support Logging in makes talk pages active and otherwise increases availability. I am usually busy doing something when I am logged in. Then, me the hipster, wants to be done with gender talks. G. Eliot and the people who are available here have one thing in common. We and she had to declare a gender before authoring any opinion or request. We have an extra choice. I can choose to be in a very specifically defined new gender, one which I don't feel qualified to speak for, much less be a member of. And that is the default choice. My experience with the works of G. Eliot was like the bash manual for reading (aka sleep inducing). I couldn't do it. Reading a lot of the crap that is here is work also, so, people logged in for editing or reading are probably busy here. When you can easily be honest with that image of the old fashioned guy putting a book on the shelf and avoid a whole bunch of the politics of personal definitions. Dear George Eliot: Glad to know you, don't let the door hit you on the way out. Hopefully, with you gone, we can walk down the path of "NON DISCLOSED because it REALLY DOESN'T MATTER" universe, where every person on the internet is a 14 year old boy. Tread lightly.--RaboKarbakian (talk) 10:28, 10 April 2024 (UTC)

As mandatory gender selection goes, it claims to be there for software to run. I become very suspicious when a "person" knows which gender I have opted for. I don't know how to sift through your preferences to learn anything about you. Is there a user gender template any where?--RaboKarbakian (talk) 09:22, 12 April 2024 (UTC)

@RaboKarbakian: You can't set a gender in MediaWiki, but in your preferences you can, if you like, specify what pronoun the software should use when it needs to refer to you in the third person. The default is the gender-neutral singular they (the setting predates the recent proliferation of pronouns and politicisation of they as a pronoun), and you have to actively choose to have it use she or he. What a given user has set this preference to is made available through a parser function (essentially a "built-in template"). So for example you could type {{GENDER:Xover|he|she|they}} to get "they" and {{GENDER:RaboKarbakian|he|she|they}} to get "he".

Also please note that gender here is a very nebulous concept as the software knows nothing about who you are in real life, and cannot tell what your biological, social, cultural, or legal gender is (I think there's even an ethnic conception of gender). It only knows that a particular user has chosen for the software to use either he, she, or they in certain interface messages where non-gendered language is impossible or too awkward. Nobody knows whether what you specify there is true, in whatever sense is relevant, or not. Xover (talk) 13:53, 12 April 2024 (UTC)

Xover: the point being that software can access that information but people cannot, at least not without software like at minimum, a template. Which would explain a lot about Petey's "Rabo is a maverick" rant. Petey taught me at wikidata. So I had a software rant from him. For example. I have seen gender (also) used in a "he is typing" sort of way also, in the wiki gui, where it was supposed to be.--RaboKarbakian (talk) 16:24, 13 April 2024 (UTC)

•  Support: while I don't classify George Eliot as "some random woman", the original painting better reflects what goes on here. If you don't immediately recognize the current picture as depicting George Eliot, it's somewhat confusing, whereas the original painting is immediately understandable (as SnowyCinema said above, "a book is a universally recognizable symbol, whereas this individual is certainly not.) Cremastra (talk) 22:15, 10 April 2024 (UTC)

Bot approval requests

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

SodiumBot

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)

 Support, and thank you so much for taking over this task! Xover (talk) 09:08, 17 March 2024 (UTC)

 Support --Jan Kameníček (talk) 09:44, 17 March 2024 (UTC)

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)

 This section is considered resolved, for the purposes of archiving. If you disagree, replace this template with your comment. --Xover (talk) 13:12, 13 April 2024 (UTC)

Repairs (and moves)

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

See also Wikisource:Scan lab

The Yellow Book Volume 8 - page moves

I have repaired the file for this work by adding in two missing pages (132 & 133). As no placeholders had been inserted, please move all transcribed pages, from Page:The Yellow Book - 08.djvu/152 onward, on by two (i.e. to Page:The Yellow Book - 08.djvu/154, etc.)

Contrary to the statement on the index page, page 134 is not missing. Also, the 'missing' p. 347 and 348 appears to be the result of a page numbering error, since there is nothing in the table of contents that would appear on these pages if they were present, nor is there anything in other scans of this volume.

I have also taken the opportunity to remove the last page, which was a colour grading card. Thanks, Chrisguise (talk) 13:59, 28 March 2024 (UTC)

@Chrisguise done. Index page to be cleaned, pagelist to be updated, etc. Mpaa (talk) 22:00, 12 April 2024 (UTC)

@Chrisguise something strange in the scan? see Page:The Yellow Book - 08.djvu/252 and Page:The Yellow Book - 08.djvu/391. They were proofread but the scan has empty pages. Mpaa (talk) 22:04, 12 April 2024 (UTC)

Thanks. I'd spotted the issue with 252 but not got as far a 391. 47 also has the same issue. There should be text on these pages. I'm looking to fix the scan but it shouldn't involve any more moves. Chrisguise (talk) 04:35, 13 April 2024 (UTC)

I've updated the index page and everything in terms of page alignment is (hopefully) fixed. Thanks again. Chrisguise (talk) 07:18, 13 April 2024 (UTC)

With a Difference

This originally was an article in The Atlantic Monthly/Volume 109/Number 650. If allowed, it could be moved to The Atlantic Monthly/Volume 109/Number 650/With a Difference thus retaining the contributor chain, And then, so it can become scan backed, starting with Page:The Atlantic Monthly Volume 109.djvu/128 of the scan: paste, review and rinse -- then display with <pages>.

If all of this is "okay" I can do any or all parts. There might need to be approval or perhaps there are preordained procedures which would make this unusual in that it might easier to ask permission for than it would be to apologize for.--RaboKarbakian (talk) 14:21, 3 April 2024 (UTC)

Now I am authoring an apology.--RaboKarbakian (talk) 16:03, 7 April 2024 (UTC)

So, I am sorry. I moved the page to Page:The Atlantic Monthly Volume 109.djvu/128 thinking I could just move the page from one empty page to another and back it up to before its move and then edit out the parts that are not on that page of the scan.

Instead, I get a "failed to blahblah sea dragon" because, apparently, the page is lacking something that brings up the page editing tools and scan view and such.--RaboKarbakian (talk) 16:11, 7 April 2024 (UTC)

@RaboKarbakian: You can't move pages from mainspace to Page: (or Index:) namespaces; they're completely different content models. To move text between mainspace and Page: you'll have to cut&paste manually (since Match&Split is broken indefinitely). In any case, I've undone your move so you should be back to the status quo. Xover (talk) 18:59, 7 April 2024 (UTC)

@Xover Could you add a little more info about "broken indefinitely"? I'd like to update Help:Match and split to reflect this. -Pete (talk) 19:12, 7 April 2024 (UTC)

@Peteforsyth: All the functionality of phe-tools was disabled due to the Grid Engine shutdown (they moved Toolforge to Kubernetes). Getting it running again requires porting it to a completely new environment, and it's an old inherited code base that's poorly documented and with some very tight couplings to the old environment. I still intent to try getting it running again, but that's going to require quite a bit of sustained time and attention; which is exactly what I have trouble finding these days. Soda has kindly taken on some of the stats tasks, but the rest are offline until some unspecified and unpredictable point in the future (which might be "never", but hopefully not). Xover (talk) 19:25, 7 April 2024 (UTC)

@Xover Thank you. I made a big note at the top of the page here; perhaps there is more appropriate formatting, of course no objection if you want to adjust. -Pete (talk) 04:27, 12 April 2024 (UTC)

I moved the page to The Atlantic Monthly/Volume 109/Number 650/With a Difference (leave the redirect up); feel free to copy-paste the text into the Page namespace and transclude when you're done. Arcorann (talk) 13:13, 8 April 2024 (UTC)

Sorry. What is the dirt on soda? --RaboKarbakian (talk) 19:43, 7 April 2024 (UTC)

I know of soda as a beverage or a baking ingredient, any other definition eludes me. -Pete (talk) 04:28, 12 April 2024 (UTC)

@Peteforsyth: "Soda" refers to Sohom Datta, who operates SodiumBot (the bot that now updates the on-wiki stats). He's also done a lot of technical work on the plumbing for Wikisource (Proofread Page, Edit in Sequence, etc.). All `round awesome person. Xover (talk) 13:47, 13 April 2024 (UTC)

@Xover: Thanks for the explanation, and thank you Soda for all the work! Pinging @RaboKarbakian. -Pete (talk) 18:17, 13 April 2024 (UTC)

To the Lighthouse - page moves

Although this work is marked as 'Done' (fully validated and transcluded) it is actually missing two pages (172 and 173). To allow placeholders to be inserted, could you please carry out the following moves:-

• The index page name = Index:To The Lighthouse.pdf
• The page offset = 2
• The pages to move = 174-318
• The reason = Insert missing pages

Thanks —unsigned comment by Chrisguise (talk) 12:01, 13 April 2024 (UTC)‎.

Note that this will also require updating all the transclusions for these pages. Xover (talk) 10:56, 13 April 2024 (UTC)

@Chrisguise: Page:-namespace pages have been shifted. Xover (talk) 13:11, 13 April 2024 (UTC)

Other discussions

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

Dear community members,

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

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

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

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

For more information, please contact spatnaikwikimedia.org.

---

About This Month in Education · Subscribe/Unsubscribe · Global message delivery · For the team: ZI Jony ^(Talk), Tuesday 16:59, 16 April 2024 (UTC)

Reusing references: Can we look over your shoulder?

Apologies for writing in English.

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

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

We’re looking forward to seeing you, Thereza Mengs (WMDE)

Template:Beleg Tâl's sidenotes

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)

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)

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

As it happens, in this case there is no pain or frustration. I created a formatting-agnostic template because we didn't have one and we needed one; and I made it a placeholder template because we don't have community consensus (yet) on what a formatting-agnostic sidenotes template should look like and how it should work.

You do make a good point, however. Perhaps it would be better if, instead of a placeholder template that should be replaced when consensus is reached, I were to make it a permanent template that should be modified and updated with whatever behaviour is decided upon? Alternatively, I could just rename it, to at least remove the username as an issue. What do you think of this?

As for compiling the issues and use cases of the various existing sidenotes templates—that has already been done in much detail elsewhere (primarily by @ShakespeareFan00), and I do not think that this thread is the place for rehashing that whole discussion. I merely intended to inform the community of the template I created so that works containing sidenotes could still be proofread in the meantime. —Beleg Âlt ^BT (talk) 17:42, 28 March 2024 (UTC)

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

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)

commons:Commons:Copyright rules by territory is a good place to start. —CalendulaAsteraceae (talk • contribs) 03:57, 4 March 2024 (UTC)

When was the English translation published , do you know ? --Beardo (talk) 04:38, 4 March 2024 (UTC)

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

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)

But when was the earliest English version published ? -- Beardo (talk) 16:44, 4 March 2024 (UTC)

there is a 1961 vintage edition [1] but it was renewed in 1989 [2] --Slowking4 ‽ digitaleffie's ghost 23:58, 4 March 2024 (UTC)

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

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

i'm seeing a 1928 1st russian edition,[3] and there is a 1953 russian Checkhov edition [4], but mainly Richardson translations. [5] --Slowking4 ‽ digitaleffie's ghost 15:41, 5 March 2024 (UTC)

• According to the 2011 translation’s introduction, the first English translation is from 1930 under the title Diamonds to Sit On. Ineuw: I have ordered a copy through ILL, hopefully it will arrive soon. TE(æ)A,ea. (talk) 17:08, 5 March 2024 (UTC)

  Aha. There is a copy of a 1947 printing which says first published in England 1930 - https://archive.org/details/in.ernet.dli.2015.77089/page/n3/mode/2up -- Beardo (talk) 17:22, 5 March 2024 (UTC)

  https://search.worldcat.org/title/213519073 translator Elizabeth Hill, https://en.wikipedia.org/wiki/Elizabeth_Hill_(linguist) ? --Slowking4 ‽ digitaleffie's ghost 00:35, 6 March 2024 (UTC)

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)

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)

┌─────────────────────────────────┘
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)

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

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)

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

Switching to the Vector 2022 skin

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)

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

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)

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)

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 (talk • contribs) 04:01, 15 March 2024 (UTC)

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)

@CalendulaAsteraceae: The above brokenness in Jump to File should be fixed now. Xover (talk) 17:04, 29 March 2024 (UTC)

@Beleg Âlt (CC Beleg Tâl): It turns out I lie. Not only does Vector 2022 (now) explicitly support menus like this(ish), but Jon even stepped in and fixed s:mul:MediaWiki:TranscludedIn.js for us (Thank you Jon!). Xover (talk) 17:02, 29 March 2024 (UTC)

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

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

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)

i would make timeless the default skin on wikisource. --Slowking4 ‽ digitaleffie's ghost 00:58, 21 March 2024 (UTC)

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)

yes, it is an improvement over flat sidebar gadget. the menus remain a problem. --Slowking4 ‽ digitaleffie's ghost 22:52, 25 March 2024 (UTC)

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)

Different line height in Vector 2022?

It seems the line height in Vector 2022 is different for some reason which makes problems with text withing pictures, such as here. --Jan Kameníček (talk) 18:57, 30 March 2024 (UTC)

@Jan.Kamenicek: It's not the line-height (that's identical), it's that in their great wisdom they decided that paragraphs were not sufficiently distinguishable from a mere line break within a paragraph on Wikipedia (of course), and so they "fixed" it by fiddling with the styling such that paragraphs in Vector 2022 now get both a top "margin" and bottom "padding". In Vector 2010 paragraphs just had a .5em top and bottom margin, and since adjacent margins collapse in CSS that meant paragraphs were always .5em (~7px) apart. If you insert two blank lines you get an extra empty paragraph, and so you get exactly 1em (14px) between the visible paragraphs. In Vector 2022 they've deliberately used padding instead of margin to defeat this collapsing, so that adjacent paragraphs get 1em between them. Paragraphs separated by two blank lines will now get 1.5em (21px) between them. Or put another way, they want to make it so that text separated by a single blank line looks like what we expect text separated by two blank lines to look. Text separated by two blank lines is now going to look fairly comical.

Mostly this is just jarring design-wise (we'll get used to it), but for any context were we depend on some kind of predictable height of the content (like your example) we're now going to have trouble. Vector 2010 and Vector 2022 now behaves completely differently, and Vector 2022 in a way that is hard to override in a predictable fashion. Templates have limited capability to differentiate between skins, so I am uncertain to what degree we can smooth out the differences there. This behaviour was added to Vector 2022 quite recently so I've asked them to please stop poking their nose down into on-wiki content at this level of detail. If I can persuade them to revert this change that would be for the best. If not, I'm not sure how we're going to deal with it. Xover (talk) 22:13, 30 March 2024 (UTC)

This also means that editors who leave in the end of line breaks throughout paragraphs when proofreading need to stop doing so. Those of us who use any other skin won't see a problem, but it will make it look weird for anyone on the default. Beeswaxcandle (talk) 22:49, 30 March 2024 (UTC)

I don't think that's going to be a problem. What they're doing in the skin is styling HTML p tags in ways that are going to be annoying to work around, but where p tags get added in the first place is a function of the parser and not of the skin. Hard line breaks inside a block of text have mostly worked because they do not cause the parser to insert a p tag there. So since the parser is not changing, neither should the behaviour for hard line breaks inside paragraphs. Xover (talk) 09:43, 31 March 2024 (UTC)

A quick update. It seems like this change has caused several problems across projects and they are consequently going to reevaluate. It's likely they will not simply revert the change, but they may change the way they do it such that we don't get this problem or there is a cleaner way to work around it. Xover (talk) 09:35, 5 April 2024 (UTC)

Btw, in order to figure out some workable approach to this, if we're stuck with it, I'm going to need plenty of examples of places where it breaks. Things like the text overflowing in Jan's {{overfloat image}} example above. A lot of cases are going to be the kind of "pixel perfect" layout that you can't in general do on the web, but we'll need to look for ways that at least it won't be any more broken than it already was. Xover (talk) 11:03, 31 March 2024 (UTC)

Making MoreMenu and Without text Gadgets default

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)

•  Support Seems reasonable. Cremastra (talk) 13:56, 15 March 2024 (UTC)

 Support Sounds good to me. —CalendulaAsteraceae (talk • contribs) 14:51, 15 March 2024 (UTC)

•  Support They can't hurt anyone, and I feel like emptying without text pages should have been done long ago. Alien333 (what I did and why I did it wrong) 16:42, 16 March 2024 (UTC)
•  Support --Jan Kameníček (talk) 09:45, 17 March 2024 (UTC)
•  Support per those above, particularly Alien333's wise words. BD2412 T 03:26, 21 March 2024 (UTC)
•  Support without text, ambivalent about Moremenu Chrisguise (talk) 10:24, 26 March 2024 (UTC)

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)

It's taken me a bit to realise what happened when an unexpected poorly named tab suddenly appeared and the keyboard shortcuts associated with delete, move, and protect all stopped working. I've turned off MoreMenu in my Preferences because I don't use a mouse if I can avoid it. The "poorly named" comment comes because there were two tabs labeled "page". How are less-experienced users to know which one does what? Beeswaxcandle (talk) 21:15, 29 March 2024 (UTC)

@Beeswaxcandle: The non-optimal naming stems from Wikisource's choice to use "Page" as the main tab, which then clashes with the commands and links in the menu that are related to the current page. On Wikipedia that tab is called "Article", on Wikibooks it's "Book", on Commons it's "Gallery" etc. I'm not sure there's a good solution to this (the non-optimal tab naming has been mentioned as confusing in other contexts too, for similar reasons).

The missing accesskeys however are clearly a bug. I've reported it upstream so hopefully that can be fixed fairly quickly. Xover (talk) 11:59, 30 March 2024 (UTC)

Easier import

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)

@LA2: Try https://ia-upload.toolforge.org/ Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:00, 15 March 2024 (UTC)

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)

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. --Slowking4 ‽ digitaleffie's ghost 22:47, 16 March 2024 (UTC)

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

Header broken on all mainspace pages (urgent)

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

@SnowyCinema: I'm looking into it. Xover (talk) 07:25, 17 March 2024 (UTC)

Ok, pretty sure I see the problem. Working on a fix now. Xover (talk) 07:40, 17 March 2024 (UTC)

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

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)

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)

Tech News: 2024-12

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

Recent changes

• The notice "Language links are at the top of the page" that appears in the Vector 2022 skin main menu has been removed now that users have learned the new location of the Language switcher. [6]
• IP info feature displays data from Spur, an IP addresses database. Previously, the only data source for this feature was MaxMind. Now, IP info is more useful for patrollers. [7]
• The Toolforge Grid Engine services have been shut down after the final migration process from Grid Engine to Kubernetes. [8][9][10]
• Communities can now customize the default reasons for undeleting a page by creating MediaWiki:Undelete-comment-dropdown. [11]

Problems

• RevisionSlider is an interface to interactively browse a page's history. Users in right-to-left languages reported RevisionSlider reacting wrong to mouse clicks. This should be fixed now. [12]

Changes later this week

• The new version of MediaWiki will be on test wikis and MediaWiki.org from 19 March. It will be on non-Wikipedia wikis and some Wikipedias from 20 March. It will be on all wikis from 21 March (calendar). [13][14]
• All wikis will be read-only for a few minutes on March 20. This is planned at 14:00 UTC. [15][16]

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

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

Bug report

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

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

Disambiguating encyclopedia articles from works

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)

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)

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

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)

See Preface (Johnson). Xover (talk) 16:16, 21 March 2024 (UTC)

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

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)

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)

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)

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

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)

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)

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)

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

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)

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)

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)

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

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)

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)

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)

Invitation to join March Wikisource Community Meeting

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

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

@Xover Thank you for pointing that out, will include a standard signature in future announcements. KLawal-WMF (talk) 19:15, 28 March 2024 (UTC)

Tech News: 2024-13

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

Recent changes

• An update was made on March 18th 2024 to how various projects load site, user JavaScript and CSS in Vector 2022 skin. A checklist is provided for site admins to follow.

Changes later this week

• The new version of MediaWiki will be on test wikis and MediaWiki.org from 26 March. It will be on non-Wikipedia wikis and some Wikipedias from 27 March. It will be on all wikis from 28 March (calendar). [17][18]

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

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

{{Header}} template and misleading publication dates

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)

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

@CalendulaAsteraceae: What is your opinion? SnowyCinema (talk) 11:10, 26 March 2024 (UTC)

@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 (talk • contribs) 19:57, 26 March 2024 (UTC)

Would doing so affect Versions headers? --EncycloPetey (talk) 22:06, 26 March 2024 (UTC)

Versions headers shouldn't link to version/edition/translation items, so it shouldn't be an issue (once I fix the dozen or so pages that are incorrectly linked) —Beleg Âlt ^BT (talk) 20:15, 28 March 2024 (UTC)

That's why I ask. If dates are only pulled from versions pages, does that mean the date of first publication (on the data item for the work) will vanish from version pages? --EncycloPetey (talk) 15:36, 29 March 2024 (UTC)

Depends how the code is written; it shouldn't. —CalendulaAsteraceae (talk • contribs) 16:03, 29 March 2024 (UTC)

Simplify Scriptorium page structure

[I thought we'd discussed this before, but I'm failing to find it in the archives just now. I think I recall that people were generally positive, but that we didn't have a good plan for alternative solutions for Announcements and Proposals. So reopening the issue to see if we can at least make a little progress.]

I'd really like to simplify the page structure of this page to avoid having subsections. It makes a lot of things much more complex, and don't work all that well on mobile (or in the Vector 2022 skin, but that's… a different issue). It is also confusing for newbies, and the important stuff (announcements, proposals) tends to get lost. So…

What would we have to do as an alternative for the current sections?

• Announcements
• Proposals
• Bot approval requests
• Repairs (and moves)
• Other discussions

Other discussions would, obviously, just become the one section present on this page (with no actual separate heading, of course).

Bot approval requests could probably either move to WS:BR, with instructions to also post a notice here; or it could be just a normal thread here on the Scriptorium. We average far less than one bot approval request per year, and while looking through the archives for something else I saw several that just languished with no comment. Depending somewhat on the outcome for other sections, I think just making bot approval requests normal threads here is the most practical and pragmatic way to handle them.

Repairs (and moves) doesn't really seem to warrant a separate section on the Scriptorium, and in any case tend to be overlooked in their own section up above. I think most such requests should go to WS:S/H, requests specifically about scans should go to WS:LAB, and anything needing +sysop should go to WS:AN. So we could replace the whole section with instructions about where to go instead up in the header.

Announcements are, I don't think, very useful as a separate section here because they tend to get lost. I think probably we could make announcements just normal threads here, maybe with "Announcement: " tacked on as a prefix to the thread title. We could have instructions to add {{do not archive until}} so that announcements where that's relevant stay on the page more than 30 days. There may be other things we could do to enhance their visibility while keeping them as a normal thread.

Proposals too are, I think, better handled as normal threads here, combined with use for separate pages for things that are RFC-y (and with a notice here). We should also use watchlist notices (cf. the recent one about Vector 2022 users needing to update their scripts) for important ones (especially policy proposals), and possibly also create a template where current proposals are listed (the template could be permanent at the top of this page and WS:S/H, and we could encourage users to transclude it on their own user page to keep up with proposals). I think that would actually improve visibility of proposals.

I'm sure I've forgotten about something, and I'm sure people will have different views on what the best way to handle stuff is; but that's a snapshot of my current thinking.

PS. This thread isn't in itself a proposal, as such, but the discussion that precedes a potential future proposal. If there is significant support, or general apathy in the absence of active opposition, I'll make a concrete proposal up in #Proposals that would, then, presumably, be the last such under the status quo. Xover (talk) 10:44, 28 March 2024 (UTC)

This sounds like a good idea to me! —CalendulaAsteraceae (talk • contribs) 15:15, 1 April 2024 (UTC)

Just a note that this is the kind of change that needs positive agreement. If there isn't significant participation, and absence of strong opposition, no change can be made. I was hoping to get a sense of where the community stood in this thread, before proceeding to a specific proposal. If nobody thinks this is an issue or doesn't think it's worth the time-investment, then making an actual proposal would just be wasting everyone's time. Some yay, nay, or meh would be helpful, is what I'm saying. :) Xover (talk) 09:32, 5 April 2024 (UTC)

Just wondering, how did this end? Because we still have #Announcements up there, which has not been used for a while, but apparently also WS:Scriptorium/Announcements, which is at least used for some newletters. — Alien333 (what I did & why I did it wrong) 10:56, 12 April 2024 (UTC)

@Alien333: If it bugs (almost) nobody but me enough to comment here then there's obviously no support for making any change and the status quo prevails (and there's no point making a proposal under those circumstances). I'm guessing the reason nobody's commenting here is that they're mostly fine with how things are, and thus not motivated to think through the sketch of an alternative above. The current structure has worked well for a long time so changes to it has the presumption against it. Xover (talk) 12:25, 12 April 2024 (UTC)

@Xover Perhaps this post became lost in the otherwise difficult to navigate Scriptorium? At any rate, I am not a great fan of the current layout, but equally wonder whether everything may become harder to find if things changed (for the most part, if I want to find the scan lab, I google it, as who knows where the link on Wikisource resides). If the Scriptorium did change, a clear table of contents at the start of this page, linking to the bot request, scan lab etc. subpages, would be much appreciated. TeysaKarlov (talk) 21:33, 12 April 2024 (UTC)

I've thought for some time that the community pages here really need some sort of navbox. It'd certainly make it easier to get around. Arcorann (talk) 13:48, 13 April 2024 (UTC)

Yeah, that's partly what I have in mind. I'd like to split things into more separate pages, with one thing (main section) per page, and then have a navbox type thing on each page. I also think we can make a template that's displayed prominently in strategic places that lists all currently open proposals. Something like w:Template:Centralized discussion. Xover (talk) 13:53, 13 April 2024 (UTC)

The irony for me is—indeed!—this discussion got lost and I didn’t see it until just now despite my best efforts to follow this page. As a new WS contributor, it’s been hard for me to get invested in this page despite it being on my watchlist (where multiple edits are easily lost track of because of the default way it collapses multiple edits into just one, which I don’t fully understand).

I’m not smart or experienced enough to propose specific restructuring solution(s), but wanted to say I support any effort by admins and other experienced folks to improve our community interaction. Compared to other “risky” proposals that would affect content in the main namespace, it seems relatively lower risk to talk about improving this discussion namespace. Just a lot of inertia and potential loss aversion at play probably, which is understandable as a human cognitive bias. Brad606 (talk) 14:59, 13 April 2024 (UTC)

@Brad606: Yeah, the default watchlist is a bit confusing in this sense. I recommend going to both the Watchlist section of your Preferences to turn on "Expand watchlist to show all changes, not just the most recent", and to go to the Recent Changes section to turn off "Group changes by page in recent changes and watchlist". Why in two different tabs of the Preferences? I have no idea. ¯\_(ツ)_/¯ Xover (talk) 18:30, 13 April 2024 (UTC)

@Xover: Yes, indeed, part of the reason this discussion has been unseen is because of the mountain of obscured discussions already in the Scriptorium from other cases.

Specifically for proposals, I think this deserves its own separate page. Note that Wiktionary has wikt:Wiktionary:Votes, a process which works quite well. Official votes (on policy, etc.), aka proposals, are done in a very structured format:

• Draft it out, based on and reference previous discussion.
• Set a time when the vote begins. Have it sit there as it would be when it starts more or less, but don't allow people to actually vote until the date and time of it starting. This serves a useful purpose: People can comment on the vote's talk page, etc., if the proposal has lack of clarity or has other inherent issues.
• Most importantly to me, set a clear time when the vote ends. Most of our discussions here (being one of the problems with both the Scriptorium and our desert known as RFC) do not have clear end dates, or clear definitions or enactments of resolution. So they just sit around more or less as thought experiments, going back to the huge "community practice vs. policy" dichotomy we have as well.

So, I think our proposals should function somewhat like this. They should at least be structured so that action is ensured to be taken if consensus allows. Wiktionary also transcludes a list of all current votes on everyone's watchlist, as well as in many other places, so that the wider community is aware... Some ideas for a page title: Wikisource:Votes, Wikisource:Proposals, or (and I like it a lot less) Wikisource:Scriptorium/Proposals.

I'm interested to know what your thoughts on this proposal structure are. I'd move to get the other sections mentioned to subpages as well (and repairs could maybe be merged with WS:Scan lab), though I have less to comment about them. SnowyCinema (talk) 00:13, 14 April 2024 (UTC)

Should we mark the RfC process historical?

There was an earlier discussion that suggested this, but that has since been archived. There are several huge "open" RfCs, but none of them have had much recent participation or any participation at all – one has had no edits since it was proposed in 2021, and overall the process seems abandoned, with the Scriptorium being used for most discussions. I think the {{historical}} template should be added to the main RfC page and any open RfCs should be closed (as "no consensus" in at least one case, due to 0 participation). Clearly, the process is not attracting the input it needs (Wikisource:Requests for comment has achieved a grand total of 243 pageviews so far this month, compared to this page's 6,036 [19]). Cremastra (talk) 15:09, 29 March 2024 (UTC)

I think it needs updating and revitalization, but there's no need to abandon it entirely. One thing that makes it so moribund is that we mostly get by just fine on established practice, and our policy framework covers most obvious areas. So while not ideal, neither is it particularly urgent to fix it. Xover (talk) 16:59, 29 March 2024 (UTC)

Best practices for title pages and other front matter

I was preparing the title page for The Diothas (here) when it occurred to me that I couldn't find much guidance about front matter (the page Help:Front matter says nothing about style). I did notice that most proofread title pages decrease the vertical space compared to the page, but is there a guideline for this? Arcorann (talk) 10:13, 30 March 2024 (UTC)

@Arcorann: No, no good guidance. Title pages (and similar parts of the front matter) are a bit special. The rule of thumb is to reproduce the original layout as closely as possible without going insane with hyper-detailed formatting, and without causing it to overflow a single page when exported to ePub. How detailed a reproduction is useful will also vary from text to text: if the title page has clearly received a lot of love from the publisher then putting more effort into reproducing it is good, but if it is very simple then a reasonable representation is good enough. It's fairly subjective and up to each contributor's judgement.

Personally I always put quite a bit of effort into the title pages etc. of my projects, because I think it's important (not least in order to look good in ePub form), but nobody is likely to rag on you for a reasonable level of laziness here. We can never perfectly reproduce them anyway, so just exactly where the line is drawn will of necessity be a subjective call. Xover (talk) 12:08, 30 March 2024 (UTC)

Follow-up question: what's the best way to check how the title page looks when exported to ePub? Is there a way apart from just exporting it? Arcorann (talk) 12:23, 3 April 2024 (UTC)

@Arcorann: No, sorry. I've often thought we should have a Gadget to preview this to catch obvious problems with pagination, page width, etc. but as of now the best option is to just export it. Xover (talk) 15:40, 3 April 2024 (UTC)

Table of Contents: Index:A Lady's Life in the Rocky Mountains (1879).djvu

Table of Contents: Index:A Lady's Life in the Rocky Mountains (1879).djvu I'm validating this. There's a typo I don't know how to correct. Please see IX on the table of contents. At the bottom, it says the page numbers are 143-146. But I think it should say 143-166, since the next section starts at 167. Also Section 1, Section VI, , Section X, and Section XV are the only ones that say "Pages" in front of the numbers. Please advise when I can continue validating the pages. Thank you. Maile66 (talk) 15:54, 31 March 2024 (UTC)

@Maile66: The actual table of contents starts here. The index page's table of contents is just a transclusion of the normal table of contents pages in the Page namespace. To find them, just Edit the page to see the index's source code, and you'll find in this case:

{{Page:A Lady's Life in the Rocky Mountains (1879).djvu/17}}
{{Page:A Lady's Life in the Rocky Mountains (1879).djvu/18}}
{{Page:A Lady's Life in the Rocky Mountains (1879).djvu/19}}
{{Page:A Lady's Life in the Rocky Mountains (1879).djvu/20}}

And just copy and paste. SnowyCinema (talk) 16:03, 31 March 2024 (UTC)

Thank you, but since I am doing the validating on this, someone else needs to make these corrections because it tells me the changes need to be proofread. Maile66 (talk) 18:42, 31 March 2024 (UTC)

@Maile66: 1.) You don't have to wait for other people to proofread the pages; if you want you can just go ahead and proofread them, since the validation is something that anyone can do. 2.) Which pages haven't been proofread? The table of contents pages are all validated, and all the pages except advertisements at Index:A Lady's Life in the Rocky Mountains (1879).djvu are at least proofread. Are you certain we're talking about the same transcription project? SnowyCinema (talk) 23:32, 31 March 2024 (UTC)

Right now I'm validating pages 2-166 ... and I'm happy occupying myself with that. Maile66 (talk) 23:41, 31 March 2024 (UTC)

@SnowyCinema: Ahhhh .... thank you for your instruction and guidance. I fixed the page number. Maile66 (talk) 20:39, 1 April 2024 (UTC)

@SnowyCinema: Well, oops! Looks like I have a lot to learn. Maile66 (talk) 20:52, 1 April 2024 (UTC)

Tech News: 2024-14

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

Recent changes

• Users of the reading accessibility beta feature will notice that the default line height for the standard and large text options has changed. [20]

Changes later this week

• The new version of MediaWiki will be on test wikis and MediaWiki.org from 2 April. It will be on non-Wikipedia wikis and some Wikipedias from 3 April. It will be on all wikis from 4 April (calendar). [21][22]

Future changes

• The Wikimedia Foundation has an annual plan. The annual plan decides what the Wikimedia Foundation will work on. You can now read the draft key results for the Product and Technology department. They are suggestions for what results the Foundation wants from big technical changes from July 2024 to June 2025. You can comment on the talk page.

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

MediaWiki message delivery 03:36, 2 April 2024 (UTC)

Global ban for Slowking4

It looks like we are in danger of losing one of our most prolific editors: meta:Requests for comment/Global ban for Slowking4 (2). If you have any opinion on this, speak now or forever hold your peace. (I realize this is mentioned further up the page, but wanted to bump the issue in case folks didn't notice it.) Nosferattus (talk) 22:42, 2 April 2024 (UTC)

This was posted above under the heading #Global ban proposal for Slowking4. --EncycloPetey (talk) 23:23, 2 April 2024 (UTC)

But we needed to make doubly sure the WS community was aware this was going on, since that "discussion" (more of a notification really) was buried. Thanks Nosferattus! SnowyCinema (talk) 00:27, 3 April 2024 (UTC)

you're very kind, however, it is unclear to me, that any amount of reason matters. only go there if you have a strong stomach. the drama caucus (one of your admins among them) will continue to put the stewards to the test, until they get the result they want. lest you think that the neglect of the WMF is bad, just consider the active hostility of a solipsistic clique of functionaries. i got my compliment from "notorious RSG", so the name calling is amusing. Wikimania was becoming tiresome, one of you should go, and help out Vigneron, and there is the wikisource conference to plan for. "all who wander are not lost". --Slowking4 ‽ digitaleffie's ghost 02:31, 5 April 2024 (UTC)

All small caps

Is the {{all small caps}} template supposed to work in non-Latin scripts like Greek? They are sometimes working here:

Οιδιπουσ

The Greek line previewed correctly, showed correctly when I posted the comment initially, but then did not work when I emended my comment. Because the behavior is variable, sometimes working and sometimes not, I can't tell whether this is the asc-template, the polytonic-template, an interaction between the two, or something else entirely.

They do not seem to be working in those scripts in the Page namespace. --EncycloPetey (talk) 18:12, 3 April 2024 (UTC)

I winder if this is related to the issue I posted at WS:S/H#font-feature-setting:'hist', and some OpenType features are not working? —Beleg Âlt ^BT (talk) 18:51, 3 April 2024 (UTC)

Just for testing:

• Default font: Οιδιπουσ
• Junicode: Οιδιπουσ
• GentiumPlus: Οιδιπουσ

For me the first two work, and the last one does not; which suggests that it's just the GentiumPlus font that {{polytonic}} uses that might be the problem —Beleg Âlt ^BT (talk) 18:53, 3 April 2024 (UTC)

Document in Jamaican patois

Is Yuunivorshal Deklarieshan a Yuuman Raits within the scope of English wikisource ? -- Beardo (talk) 04:27, 7 April 2024 (UTC)

Hmm. I'd say it's a clear no. Jamaican creole is not generally mutually intelligible with Standard English (although as a primarily spoken language, and as a creole, the degree is pretty fluid from person to person and situation to situation). This is just one such case for which we have mulWS. Xover (talk) 07:10, 7 April 2024 (UTC)

 Keep at enWS as a closely-related language to English. We should keep JC works if we're going to host works in Old English, which is at least as unintelligible, if not more so, than the Jamaican Creole provided. SnowyCinema (talk) 14:27, 7 April 2024 (UTC)

It's not primarily a question of mutual intelligibility (although that is certainly also a factor). Old English is a direct precursor of English, and there is a direct lineal relationship linguistically speaking. Jamaican creole is a hodgepodge of languages, where there happens to be a large dash of English in the mix, but it is inherently a mix of languages that do not fit neatly into one specific language family. mulWS is for precisely such cases where you cannot slot a text neatly into one language. Xover (talk) 15:48, 7 April 2024 (UTC)

> where there happens to be a large dash of English in the mix

The major lexifier of Jamaican Creole is English[23].

> but it is inherently a mix of languages that do not fit neatly into one specific language family

Its language family is English-based creole. Here is its classification on Glottolog.

I just wanted to point that out. I didn't know that mulWS existed when I uploaded it, so if that's a better place, then great, I can put it there or an admin can move it. Or if here is fine, that's great too. I'll wait for you all to decide, since I'm brand new to this project and don't know how things work here.--Vuccala (talk) 23:54, 7 April 2024 (UTC)

 Delete This is in Jamaican Creole (a stable language resulting from a mix of languages), not a patois (nonstandard speech within a language). Clause McKay published poetry in the Jamaican patois, but the document under consideration is in Jamaican Creole. Further, this document is a translation of a document that was originally written in English. Since the document is a translation, and is not in English (or Scots), it falls outside our coverage and should be housed at the Multilingual Wikisource. --EncycloPetey (talk) 15:06, 7 April 2024 (UTC)

Question (from me, the uploader): is there a more suitable Wikimedia project I could have uploaded this to? There is no Jamaican Creole Wikisource, and we're using this document over at Wiktionary for demonstrating attestations of Jamaican Creole vocabulary using this template: Template:RQ:Yuunivorshal_Deklarieshan_a_Yuuman_Raits. --Vuccala (talk) 23:29, 7 April 2024 (UTC)

See the above discussion. There is a multilingual Wikisource that houses all languages that do not have a dedicated Wikisource project for the language. --EncycloPetey (talk) 01:00, 8 April 2024 (UTC)

Is there a way to move something from here to there ? Or does it need to be input separately there ? -- Beardo (talk) 01:20, 8 April 2024 (UTC)

I am an admin and can import. —Justin (koavf)❤T☮C☺M☯ 07:10, 8 April 2024 (UTC)

@Beardo:: s:mul:Yuunivorshal_Deklarieshan_a_Yuuman_Raits. —Justin (koavf)❤T☮C☺M☯ 07:11, 8 April 2024 (UTC)

@Vuccala: s:mul:Yuunivorshal_Deklarieshan_a_Yuuman_Raits. —Justin (koavf)❤T☮C☺M☯ 07:35, 8 April 2024 (UTC)

@Koavf: Thank you! I've updated the link in the Wiktionary template to point there instead. You guys can now delete it from English Wikisource. --Vuccala (talk) 10:59, 8 April 2024 (UTC)

Transcription speculation

Just a fun little exercise—I was wondering what projects you guys would be working on if more modern works were in the public domain today. So, I started this editable user subpage, User:SnowyCinema/Speculative transcriptions; the idea is to list your favorite copyrighted works that you might be working on if they were not under copyright. Anything is on the table—video games, TV shows, or books like is our general focus now, etc. I'm curious to see what your answers are. Feel free to add items to the list if you can think of anything. SnowyCinema (talk) 15:35, 7 April 2024 (UTC)

Random line break

Hello. I have recently started a project of Tarka the Otter and some pages seem to have a random line break towards the end for no apparent reason (like page 14). Did I do anything wrong? I can't figure out what is wrong. HendrikWBK (talk) 01:42, 8 April 2024 (UTC)

You did not join the separate lines to make a continuous paragraph, and that line break is a consequence. --EncycloPetey (talk) 01:58, 8 April 2024 (UTC)

It seems that only the last line is affected. In the rest of the page, if I leave two new line spaces, a new paragraph is formed, while one leaves the subsequent line in the same paragraph. I don't understand what you mean, I believe I did kept lines from the same paragraph immediately next to each other. HendrikWBK (talk) 02:06, 8 April 2024 (UTC)

️@HendrikWBK The software parses the text in unpredictable ways if you don't remove the newline character at the end of every line, and the consequence is that random line breaks appear for no apparent reason. Ignacio Rodríguez (talk) 06:21, 8 April 2024 (UTC)

See Wikisource:Scriptorium/Help#Proofreading_Paragraph_Problem Mpaa (talk) 06:59, 8 April 2024 (UTC)

Tech News: 2024-15

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

Recent changes

• Web browsers can use tools called extensions. There is now a Chrome extension called Citation Needed which you can use to see if an online statement is supported by a Wikipedia article. This is a small experiment to see if Wikipedia can be used this way. Because it is a small experiment, it can only be used in Chrome in English.
• A new Edit Recovery feature has been added to all wikis, available as a user preference. Once you enable it, your in-progress edits will be stored in your web browser, and if you accidentally close an editing window or your browser or computer crashes, you will be prompted to recover the unpublished text. Please leave any feedback on the project talk page. This was the #8 wish in the 2023 Community Wishlist Survey.
• Initial results of Edit check experiments have been published. Edit Check is now deployed as a default feature at the wikis that tested it. Let us know if you want your wiki to be part of the next deployment of Edit check. [24][25]
• Readers using the Minerva skin on mobile will notice there has been an improvement in the line height across all typography settings. [26]

Changes later this week

• The new version of MediaWiki will be on test wikis and MediaWiki.org from 9 April. It will be on non-Wikipedia wikis and some Wikipedias from 10 April. It will be on all wikis from 11 April (calendar). [27][28]
• New accounts and logged-out users will get the visual editor as their default editor on mobile. This deployment is made at all wikis except for the English Wikipedia. [29]

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

MediaWiki message delivery 23:37, 8 April 2024 (UTC)

Avoid concurrent confirmation for our `crats

Courtesy ping: BD2412, @Beeswaxcandle.

It just occurred to me that we currently have Confirmation discussions for both of our `crats going on concurrently (because we elected both of them at the same time). Now, granted, neither one of them is likely to be involved in any controversy, but it is in principle unfortunate to have them both be up for confirmation at the same time. I therefore propose that we artificially postpone the next confirmation for one of them by 6 months so that their future confirmations will be at different times of the year, and so they can more easily switch out who handles closing confirmations without getting into situations where they can be accused of being influenced by an ongoing confirmation for themselves. It's not something that's likely to happen, but since it's easy to avoid entirely…

It doesn't matter which one of them we move in the cycle, but just so there's a concrete proposal I suggest we delay BD2412's next confirmation by an additional 6 months (for the very well-thought-out reason that they happen to be listed first on WS:A currently :)). Xover (talk) 06:55, 9 April 2024 (UTC)

No objection to the plan, but we could also just add a few more 'crats. BD2412 T 15:55, 9 April 2024 (UTC)

Actually for the period of time when Hesperian was also a 'crat, all three of us were being confirmed in the same month. I should also point out that any established wikisourceror can close a confirmation discussion and I used to close Hesperian's so that he didn't have to do his own one. Beeswaxcandle (talk) 05:28, 10 April 2024 (UTC)

Not restricted access discussions; those have to be closed by the `crats. But, yeah, as mentioned, this isn't exactly a big issue. I just noticed it now and figured there was an easy way to avoid the problem altogether, so why not. Xover (talk) 06:12, 10 April 2024 (UTC)

There is also this discussion, where it was suggested that if the outcome was "bleeding obvious", then it would not be a problem for a 'crat to close a discussion in which they were a participant. I suppose this might be considered to apply to a 'crat closing their own clearly uncontested reconfirmation, though this feels a bit wrong. For this month, I have no problem with the two 'crats involved each closing the discussion for the other, though this also potentially could create an appearance of a tit-for-tat. BD2412 T 15:31, 11 April 2024 (UTC)

Index:United States Statutes at Large Volume 44 Part 2.djvu

Raw OCR dump. Should be removed (along with other Raw dumps) unless someone is prepared to provide alternate scans that are ACTUALLY READABLE as opposed to bordeline illegible on numerous pages. I've been trying to remove lints by attempting to proofread pages that where showing up in a list of mismatched Italics. Raw OCR Dumps diminish my enthusiasm for continuing, and there should be concerted effort to clean out the gibberish generated from them. ShakespeareFan00 (talk) 09:25, 12 April 2024 (UTC)

the scan is fine, with the improved OCR. awaiting for the volunteers to proofread. if you remove it, then the volunteers cannot do the work. (i would be more motivated if there were a consensus to ditch the side notes, which are more trouble than theye are worth). --Slowking4 ‽ digitaleffie's ghost 13:16, 14 April 2024 (UTC)

Primary sources concerning Wyatt Earp

This page contains a number of short newspaper articles all on a related topic. It's been proposed to separate the page, which seems like clearly the right thing to do if the page is going to stay on Wikisource, if somebody is going to take the trouble to find scans, etc.; but this is a labor-intensive task that seems unlikely to happen in the near future. In the meantime, even though it contains actual source material, I would suggest that moving this page to the Portal: space might be the best way to tidy things up. -Pete (talk) 17:35, 12 April 2024 (UTC)

Tech News: 2024-16

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

Problems

• Between 2 April and 8 April, on wikis using Flagged Revisions, the "Reverted" tag was not applied to undone edits. In addition, page moves, protections and imports were not autoreviewed. This problem is now fixed. [30][31]

Changes later this week

• The new version of MediaWiki will be on test wikis and MediaWiki.org from 16 April. It will be on non-Wikipedia wikis and some Wikipedias from 17 April. It will be on all wikis from 18 April (calendar). [32][33]
• Default category sort keys will now affect categories added by templates placed in footnotes. Previously footnotes used the page title as the default sort key even if a different default sort key was specified (category-specific sort keys already worked). [34]
• A new variable page_last_edit_age will be added to abuse filters. It tells how many seconds ago the last edit to a page was made. [35]

Future changes

• Volunteer developers are kindly asked to update the code of their tools and features to handle temporary accounts. Learn more.
• Four database fields will be removed from database replicas (including Quarry). This affects only the abuse_filter and abuse_filter_history tables. Some queries might need to be updated. [36]

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

MediaWiki message delivery 23:29, 15 April 2024 (UTC)