CalendulaAsteraceae

Last Poems (Housman)

Looking at that work and its literary components, and each specific and having value, I don't think that we should be bound by the 1, 2, 3, 4, components when each has a specific name and each should have a specific item at WD. I reckon we can do better to make the pages have specific titles, and findable by search engines, rather than what the original contributor set up. — billinghurst sDrewth 22:48, 7 September 2023 (UTC)

@Billinghurst: How do you think we should handle the poems that have titles, distinct from the first line, like Last Poems (Housman)/1 ("The West")? —CalendulaAsteraceae (talk • contribs) 03:54, 8 September 2023 (UTC)

Personally I would have used their name for the section and subpage name, as that is how they are titled/known. Though how we align that on the ToC is an interesting question, and my first though was to utilise redirects so that the ToC is not needing to predict. When we pump them into WD, both fields are available. Though I also think that it is a reasonable question to pose to the community for a consensus. State the issue, put forward your proposal. — billinghurst sDrewth 04:05, 8 September 2023 (UTC)

@Billinghurst: Sorry, I'm having trouble parsing this for some reason. Under the policy you're proposing, should the first poem be at Last Poems (Housman)/The West, Last Poems (Housman)/Beyond the moor and mountain crest, or somewhere else? —CalendulaAsteraceae (talk • contribs) 04:27, 8 September 2023 (UTC)

"Last Poems (Housman)/The West" title to subpage; in your ToC, you may just leave it as is, then they become redirects <shrug>

WD; title (P1476), first line (P1922) re WD — billinghurst sDrewth 04:32, 8 September 2023 (UTC)

Makes sense, thank you! I might just go ahead and do that; it seems like a good approach and should be pretty straightforward to change later if anyone brings up concerns. —CalendulaAsteraceae (talk • contribs) 04:41, 8 September 2023 (UTC)

Works with physical attachments

Hi. Remember the work we transcribed in person, Firestone Tires and Tube Prices letter, May 4, 1927? I thought to make a category for this sort of thing, at Category:Works with physical attachments, in case the situation ever arose again. Did you ever find any other instances of this unique occurrence? PseudoSkull (talk) 22:34, 17 January 2024 (UTC)

A similar thing to consider would be Pop-up books, which I wouldn't consider physical attachments, but a different style of visual presentation. Although, I'm not sure how content from these books would best be represented here at WS. I know I had lots of these when I was younger. According to Wikipedia, Daily Express Children's Annual Number 1 "with pictures that spring up in model form", perhaps the beginning of the US history of children's pop-up books, will go into the public domain next year. PseudoSkull (talk) 22:40, 17 January 2024 (UTC)

I haven't found any other instances of this occurrence yet, but I'll keep an eye out!

For pop-up books… I'm not sure. Video would be neat if possible. —CalendulaAsteraceae (talk • contribs) 23:27, 17 January 2024 (UTC)

Silent animated films

Hi, Callie. So, I think our presentation with live-action films is pretty good, but unfortunately, our transcriptions don't seem to lend themselves well to silent cartoons... These cartoons don't tend to have a whole lot of intertitles if any—instead, they use onomatopoeic, usually one-word, capitalized dialogues, much like some of the quieter comics do. For example: "Zoom", "Bang", "Clang", "Boom", "Zowie", "Ouch", "G-r-r-r", etc. And what will happen is that there have to be entire lines of our transcription, entire pages, devoted to these lines of minor importance, and it just doesn't look very good in the final product. They take up like half the transcription or more usually.

They do have structural importance to the plot, so I do kind of want them to be included somehow, but I feel like the appearance, and maybe even logic, has to be improved drastically to keep it from scaring our readers away. So I thought maybe you could give me some ideas to better the presentation and workflow with these?

One idea I had was to find some way to toggle on/off these types of lines (I can't think of what to call them!), unless you toggle them on. Sort of like how our Collapsible boxes work. But I'm not sure if this is possible?

I've been experimenting with cartoon-specific templates, such as {{Film multiplier}} (example that eliminates 58 potential pages), {{Cartoon dialogue}}, {{Film exclamation}} (example), etc. But I just don't think these templates are enough. Feel free to have your way with anything in Portal:Bobby Bumps, Portal:Oswald the Lucky Rabbit, or Portal:The Alice Comedies if you'd like. SnowyCinema (talk) 19:22, 25 January 2024 (UTC)

Ooh, this does look like an interesting challenge! {{Collapsible box}} and {{collapsible list}} achieve collapsibility by applying the mw-collapsible class to the outer div and letting MediaWiki do the rest—inserting a button with JavaScript attached. For this kind of application, what we want is one button to toggle all the dialogues/onomatopoeias/whatever, or maybe one button per type. Ideally, we'd also use the built in mw-collapsible functionality, because that would be way easier. I'll poke around and see what I can do! —CalendulaAsteraceae (talk • contribs) 04:02, 26 January 2024 (UTC)

Thank you. A few things: 1. I made Index:Sandbox.webm a long time ago to experiment with film technology, if you'd like that. 2. I know that on Wiktionary, there is a Visibility section, where you can toggle all of a certain template. For example, on wikt:hubris, the left bar will show "Show translations" and "Show quotations". Maybe we can have something similar to that? But I am worried about how the timestamps and ProofreadPage will feel about this, because for example {{Advertisements}} causes problems with the pagination wherever it's used... SnowyCinema (talk) 08:29, 26 January 2024 (UTC)

I've started work on {{transcript collapsible}}! It's still very much under development, but we'll get there. —CalendulaAsteraceae (talk • contribs) 05:39, 6 February 2024 (UTC)

Template:Blackface and related.

Obviously this template was needed, but I was wondering if you had considered that you might also want to consider a template to mark inappropriate depictions of other ethnic or religious groups (We already have {{moral disclaimer}}). I am not going to give specfic examples, but they unfortunately exist.

More generally you might also want to consider adding a template to the film set, that allows for 'classification' concerns to be added as metadata. Whilst original Motion picture content rating system film "classifications" might not be entirely accurate compared to current "classification" criteria, they can sometimes be a reasonable guide.

ShakespeareFan00 (talk) 07:59, 6 February 2024 (UTC)

{{Film}} was @SnowyCinema's idea and you should probably talk to him about the design stuff (I'm mostly improving the technical implementation), but I appreciate the suggestions! —CalendulaAsteraceae (talk • contribs) 17:46, 6 February 2024 (UTC)

(Probably you should give specific examples if you want to come up with disclaimers for them, though.) —CalendulaAsteraceae (talk • contribs) 05:33, 15 February 2024 (UTC)

Header automatic defaultsort

Thank you for doing this—maybe you remember, but I suggested that we do this several times now, and I'm glad it's finally being done! I just wanted to let you know that I disabled MediaWiki:Duplicate-defaultsort, which was causing all those "defaultsort appears multiple times" errors to pop up. The way this logic appeared to work is that if {{DEFAULTSORT}} appears in the page multiple times, it threw an error. I didn't think that this was going to be valid anymore per the new changes, since the way the new Header logic works, we will actually want the autodefaultsort to be overridden in some rare cases (such as if "A" refers to the letter A and not the indefinite article, or if "The" refers to a Vietnamese or Swedish word, etc. etc.).

So TLDR, you won't have to worry about those errors anymore now. SnowyCinema (talk) 23:18, 12 February 2024 (UTC)

Thank you! —CalendulaAsteraceae (talk • contribs) 23:59, 12 February 2024 (UTC)

The reason this change was backed out (multiple times) is that there's no clean way to do this in MediaWiki. If we're going to automate default sort keys we have to always set it through {{header}} (i.e. |sortkey=) and prohibit raw DEFAULTSORT: (and, obviously, migrate all existing raw sort keys to the new param) in mainspace (and Translation:, and Portal:, and anywhere else we activate default sort keys). Xover (talk) 07:32, 13 February 2024 (UTC)

There were on the order of 5000 pages in Category:Works with DefaultSort error before SnowyCinema disabled the error, which on one hand is kind of a lot, but on the other hand is less than 1% of the pages using {{header}}, and honestly, I think it's a pretty manageable number.

I've added a tracking category for works which have a defaultsort key applied through the header: Category:Headers applying DefaultSort key. (It's not going to be all works with a header, since the header only applies a defaultsort if it's specified manually or different from the page name.)

{{Author}} has applied a defaultsort for a while, and a quick look at the Internet Archive suggests that Category:Authors with DefaultSort error is usually empty, so I'm optimistic that we can extend automated sorting to more namespaces even if the underlying code situation is less than ideal.

@SnowyCinema, it does sound like it would be a good idea to re-enable MediaWiki:Duplicate-defaultsort, although maybe only after I've had a look through these pages. —CalendulaAsteraceae (talk • contribs) 22:46, 13 February 2024 (UTC)

I'm surprised the number is so low. Maybe that's because the defaultsort is set to use ", The", which is in contradiction with some that just take the "," part out altogether. But, maybe the majority of defaultsort keys are added to recently scan-backed works—the number of 5000 seems to coincide with that theory. Editors often add defaultsort keys behind me in my works in New texts if I forgot to add it myself. If this trend has been happening with nearly every new text over the past several years, this could be why the number is at 5000 instead of something in the hundreds of thousands.

Another solution could be to use a bot to systematically remove all Defaultsorts in the mainspace... But either way, I don't think that we should reinstate the error message, since there are legitimate cases where overriding the defaults could be necessary. And that error message will boldly show in red to any reader who accesses that content, which is an extremely bad look for our site. I think it gives readers the impression that our site is filled with bugs (since nearly every film entry I've come across was affected by this error, and our films while low in number do represent a significant amount of traffic to Wikisource). SnowyCinema (talk) 23:09, 13 February 2024 (UTC)

This might not be possible, but could we set the defaultsort error message to be hidden by default, but with a class that users could target to make it visible, like {{deprecated}}? —CalendulaAsteraceae (talk • contribs) 23:29, 13 February 2024 (UTC)

The message should be there and be visible. Having duplicate defaultsort is an error that should be visible (so contributors see it when they cause the problem) and tracked in a category (so systematic maintenance can handle the ones missed). If you're routinely seeing these errors (except in connection with the recent major code migration) then something is wrong elsewhere. Xover (talk) 16:00, 14 February 2024 (UTC)

There are ~150k uses of DEFAULTSORT in mainspace alone. That you only saw 5k in the category should certainly be analysed and understood (Are there only 5k where Lua and the manual sortkey are identical? Is it delay in populating the category? etc.), but in general all these have to be migrated to |defaultsort= so there's just one place to manage these (most contributors just copy approaches they see elsewhere, without necessarily understanding it). Xover (talk) 16:09, 14 February 2024 (UTC)

@Xover: If it's that big of an issue, that it must be shown as an error when it occurs, then we need to implement the "sortkey=" functionality ASAP and then completely delete all uses of "DEFAULTSORT" sitewide. But we should at least wait until this process is done before reinstating the message. Error messages popping up all over the site on many high-traffic pages and scaring our readers away won't do even for a short length of time. I've stated why this error is occurring (manual defaultsorts being different from the defaultsort provided by the header in the new code), which specifically happens in approximately 5,000 pages. It's not just that defaultsort is there at all, but that it overrides with a new value.

I'd offer to write the bot that removes the defaultsorts. It should be a fairly simple implementation, which I could do pretty much immediately on demand. SnowyCinema (talk) 23:48, 14 February 2024 (UTC)

@SnowyCinema: That would be really helpful! Since we don't want to remove the defaultsorts that are correctly different from the automatic defaultsort, could you have the first pass convert the manual defaultsorts to use the defaultsort parameter? Once you've done that, you could go remove the defaultsort parameter from the pages in Category:Headers with DefaultSort equal to page title, and reviewing the remaining pages in Category:Headers applying DefaultSort key would be less urgent since they would no longer have errors. —CalendulaAsteraceae (talk • contribs) 05:09, 15 February 2024 (UTC)

Yes. Is it ready to go? If so, I can start the process. Here's what I would do:

1. Delete all defaultsort keys that are the same as the automatic defaultsort.
2. Move the different ones to a defaultsort parameter in the header template.

I'm realizing that this may become more complicated, though, in pages that do the thing where the Header template is not called directly, but instead uses a special html tag (something similar to <pages>) to shorten transclusion content... So what should be done in those instances? (And what's the tag called again?) SnowyCinema (talk) 06:47, 15 February 2024 (UTC)

Yep, this is ready to go! If you're talking about works which set header="1" in the pages tag, I think it's OK to just ignore those for now and only edit the pages which call the header template directly. I guess if there are a lot of those pages we'll need to figure out a solution, but let's handle the easy stuff first. —CalendulaAsteraceae (talk • contribs) 21:06, 15 February 2024 (UTC)

@SnowyCinema: The pages extension tag accepts arbitrary parameters and feeds them (through some intermediary magic) to {{header}}. If you add sortkey="…" to its arguments it'll just work once I fiddle the mentioned magic to pass it on. Xover (talk) 17:41, 16 February 2024 (UTC)

Uhm, but, yeah, I meant to say: ignoring these for now is also ok. There aren't that many of them. Xover (talk) 17:53, 16 February 2024 (UTC)

And also, re this. I think sortkey is a better name for this param. "defaultsort" is MediaWiki-specific arcana that doesn't really roll off the tongue for anyone not deeply steeped in that dark art. "sortkey" is still geeky, but it's more understandable for normal humans. Xover (talk) 17:55, 16 February 2024 (UTC)

Legit; I rarely have strong opinions about parameter names. —CalendulaAsteraceae (talk • contribs) 17:57, 16 February 2024 (UTC)

@Xover, @CalendulaAsteraceae: Could one of you please give me a jumpstart? I want to know how I can get a list of pages that use the {{DEFAULTSORT}} magic word, across the mainspace. Is there a Wikidata query I should use for that? If so, I think I'll start the process sometime today. SnowyCinema (talk) 02:27, 17 February 2024 (UTC)

@SnowyCinema: Category:Headers applying DefaultSort key, Category:Headers with DefaultSort equal to page title, Template:Header and insource:/\{\{DEFAULTSORT:/, Template:Translation header and insource:/\{\{DEFAULTSORT:/ —CalendulaAsteraceae (talk • contribs) 06:32, 17 February 2024 (UTC)

@Xover: I was originally going to do this, but I'm struggling to find a time window that would work for 150K edits (even with the flood flag on). The computer account I use for Wikisource is different from the ones I use for other tasks, and I'm constantly having to switch between accounts. Would you be willing to do this bot task? If not, I'll try and work out a window for me. SnowyCinema (talk) 22:33, 18 February 2024 (UTC)

@Cinematic Snowfall: Sure, I can do it if you have the job itself ready to go (and all edge-cases figured out). Xover (talk) 06:12, 19 February 2024 (UTC)

Header glitch:-

Author:John McMahan It claims there's mismatched italics? Is it mis-reading the bold in the notes? ShakespeareFan00 (talk) 09:21, 13 February 2024 (UTC)

I don't know what tool you're using to get the mismatched italics claim, but the page does show up in Special:LintErrors iff it implements the description list with the MW colon shortcut. —CalendulaAsteraceae (talk • contribs) 18:52, 14 February 2024 (UTC)

Interestingly, Template:Author/testcases only shows up in Special:LintErrors if I invoke the template outside of {{test case nowiki}}. —CalendulaAsteraceae (talk • contribs) 20:58, 14 February 2024 (UTC)

 This section is considered resolved, for the purposes of archiving. If you disagree, replace this template with your comment. ShakespeareFan00 (talk) 18:43, 16 February 2024 (UTC)

Portal:Dick_Turpin

Typo in code, means it's calling a non-existent function? ShakespeareFan00 (talk) 21:16, 15 February 2024 (UTC)

See also Category:Pages_with_script_errors 21:17, 15 February 2024 (UTC) ShakespeareFan00 (talk) 21:17, 15 February 2024 (UTC)

Your header and author template changes seem to mean a call from Template:Person no longer works as before. ShakespeareFan00 (talk) 21:25, 15 February 2024 (UTC)

 This section is considered resolved, for the purposes of archiving. If you disagree, replace this template with your comment. 18:42, 16 February 2024 (UTC)

Template:Plain sister

I have noticed you have been working on Scribunto Lua migrations of several of the larger templates here. Once things settle down perhaps you can consider {{plain sister}} too. We have finally removed all significant dependencies on the deprecated Module:Wikidata and I would really like to remove the last vestiges of the deprecated Module:Wikibase (removing constructs like {{#invoke:Wikibase|id}}) too. Fully migrating {{plain sister}} should also allow one to avoid its template expansions in Module:Header structure. Thank you, —Uzume (talk) 06:44, 16 February 2024 (UTC)

@Uzume: Due to the change in the thread below, both Module:Wikidata and Module:Wikibase should now be without transclusions. We just need to let Author: namespace purge itself first. Xover (talk) 16:36, 16 February 2024 (UTC)

@Xover: Exactly my thoughts but thanks for the comment (and I believe it was 13875957 and not 13876025 quoted below but you did make them in fairly close temporal proximity). —Uzume (talk) 16:43, 16 February 2024 (UTC)

@Uzume: Author: has emptied out so now there are only self-transclusions and links left. Do you want to bring them to WS:PD or would you prefer I do it? Xover (talk) 07:37, 17 February 2024 (UTC)

@Xover: It does not matter much to me really (deleted is deleted, right?). That said I am surprised we do not have a speedy deletion policy covering unused templates and Scribunto modules (e.g., something akin to c:Commons:Criteria for speedy deletion "T2: Unused template"). I can think some several others that could use such, e.g., {{documentation/start box}}, {{documentation/start box2}}, {{documentation/end box}}, {{documentation/end box2}} (I think w:Template:Documentation used to use these a long time ago), etc. I am sure there are many others. —Uzume (talk) 00:34, 20 February 2024 (UTC)

@Xover: Incidentally, 4852729 is wrong and should be reverted ({{wbreponame}} is only coincidentally a valid interwiki prefix and "Special:Search" is guaranteed to exist, whereas their multilingual versions are not and should always match English here anyway). You can see a similar reversion at mul:870096 Thank you, —Uzume (talk) 03:43, 29 February 2024 (UTC)

Thanks. Fixed. Xover (talk) 06:13, 29 February 2024 (UTC)

Once things settle down I'll be happy to work on migrating {{plain sister}}. —CalendulaAsteraceae (talk • contribs) 18:18, 16 February 2024 (UTC)

@Uzume: I've got a draft up now at Module:Plain sister/sandbox. There are still a couple issues I'd like to sort out, but I've made a good amount of progress! —CalendulaAsteraceae (talk • contribs) 05:02, 28 February 2024 (UTC)

@CalendulaAsteraceae: That does look like good progress. Eventually I would like to be able to address things like Template talk:Plain sister#|edition= support (which is highly related to Template:Edition/doc#Deprecation). But for now, moving all of Template:Plain sister functionality into Module:Plain sister is a big step in the right direction. Thank you, —Uzume (talk) 01:44, 29 February 2024 (UTC)

I wouldn't worry about {{edition|title=}}. It's used only in one text, by one user, and is not actually needed there. I'd sooner spend cycles on renaming |edition= to something like |textinfo=, because nobody understands what the former actually does. Xover (talk) 07:52, 29 February 2024 (UTC)

@Xover: There are so few usages of {{edition}} because I converted all the others (that didn't use |title=). It would be nice if a new |textinfo= allowed for arbitrary text and not just yes so we could get rid of {{edition|title=}}. —Uzume (talk) 19:01, 29 February 2024 (UTC)

@Xover, @Uzume: I've finished implementing all {{plain sister}} functionality in Lua (and made Module:Header structure use the module directly). What do you think of Module:Plain_sister/sandbox#L-237? —CalendulaAsteraceae (talk • contribs) 03:46, 8 March 2024 (UTC)

@CalendulaAsteraceae: That is great news and the part you asked about looks good too (now we just need to document that at some place like Template:Plain sister/doc). I suppose I should now consider working on cleaning up Special:WhatLinksHere/Template:Edition (moving the transclusions to use the new |textinfotitle=) and eventually take {{edition}} to WS:PD after that. I suppose there is no real hurry though. Thank you, —Uzume (talk) 04:03, 8 March 2024 (UTC)

@Uzume: Just to be clear, I haven't implemented this in the live module yet, just the sandbox, but once I've implemented these changes in the live module, it would be great if you could take care of the cleanup! Just want to be sure this seems like a good implementation before I go ahead with it. —CalendulaAsteraceae (talk • contribs) 04:05, 8 March 2024 (UTC)

@Uzume: I've implemented this change now, and updated the documentation. Go ahead and update uses of {{edition}}! —CalendulaAsteraceae (talk • contribs) 04:54, 9 March 2024 (UTC)

Template:License

Can you rexamine the code here, on Executive Order on Organizing and Mobilizing the United States Government to Provide a Unified and Effective Response to Combat COVID-19 and to Provide United States Leadership on Global Health and Security Lua runs out of memory! on what should be a short document... ShakespeareFan00 (talk) 09:27, 16 February 2024 (UTC)

@ShakespeareFan00: This problem has been there since 2021, and only triggers on certain texts based on what's defined on its Wikidata item. In short it's a combination of MediaWiki's insanely inefficient Wikidata integration, and a wasteful implementation of the function that blew up. It's fixed now. Xover (talk) 15:44, 16 February 2024 (UTC)

Thanks ;)

 This section is considered resolved, for the purposes of archiving. If you disagree, replace this template with your comment. ShakespeareFan00 (talk) 15:47, 16 February 2024 (UTC)

The Romance of Tristan and Iseult

What made you consider Bédier to be the "author" of this work? Wyatt is not considered the author of Beowulf, and Tolkien is not considered the author of Sir Gawain and the Green Knight. --EncycloPetey (talk) 16:49, 22 February 2024 (UTC)

Response at Wikisource:Bot requests#Remove "by" from use of override_author in headers —CalendulaAsteraceae (talk • contribs) 22:42, 22 February 2024 (UTC)

Errors in Template:Header

I'm not going to pretend to understand whatever improvements you are making to Module:Header, but you should know that {{header}} has started producing the following error: Lua error in Module:Header at line 104: variable 'attr_data' is not declared. —Beleg Tâl (talk) 19:48, 23 February 2024 (UTC)

I see youre actively working on this template, but FYI a different error message is appearing here: "Lua error in Module:Header at line 104: attempt to index field '?' (a nil value)." Thanks, and good luck with your coding! Brad606 (talk) 19:55, 23 February 2024 (UTC)

Thank you both, and yikes that sure was an error. I'll have to see what I can do to add tests for it, since the function the error was coming from (check_non_existent_author_pages) is only run in mainspace and translation-space. —CalendulaAsteraceae (talk • contribs) 19:58, 23 February 2024 (UTC)

I've added a testing option to Module:Header to reduce the odds of this sort of error getting through in future. —CalendulaAsteraceae (talk • contribs) 20:27, 23 February 2024 (UTC)

A lyricist writes lyrics to accompany a song. A librettist writes the text to which an opera is composed. The process and terminology is significantly different and should not be conflated. Likewise, a setting of the Catholic Mass would not have "lyrics"; nor does Verdi's Requiem. Only songs have lyrics (etymologically from Greek lyric poetry, which were poems to be sung). Grander works cannot be described as having "lyrics"; to do so is inaccurate and looks uneducated. --EncycloPetey (talk) 22:16, 23 February 2024 (UTC)

You know, now that I've thought about it I actually agree with you that librettist is a distinct role from lyricist, but this is a terrible argument for that position. Sure, an opera isn't a song, but generally, a significant component of opera is words, usually verse, set to music; in what sense is the person who writes the words not a lyricist? (If the etymology of the word "lyric" is supposed to be persuasive, I'm afraid I don't see how.) It would have been more instructive if you'd given examples of works with distinct lyricists and book-writers, like Fiddler on the Roof (which unlike Verdi's Requiem is not sung-through). —CalendulaAsteraceae (talk • contribs) 03:54, 24 February 2024 (UTC)

(As long as we're sharing etymology facts, I do think it's interesting that "libretto" includes the sung lyrics as well as spoken text and stage directions, whereas its modern counterpart, the "book", typically excludes the sung lyrics—probably a result of musicals having more spoken text in them. When I have more time I should research what they call the book in Italian, and whether it includes the lyrics.) —CalendulaAsteraceae (talk • contribs) 05:31, 24 February 2024 (UTC)

Among the Greeks, lyrical poetry was one specific type of poetry, and was distinct from dramatic poetry, epic poetry, and other forms. To be lyrical poetry, it had to be constructed in a specific format for a limited set of purposes. Poets who wrote poetry for dramatic works (the Greek equivalent of opera) were not lyrical poets but dramatic poets. --EncycloPetey (talk) 14:54, 24 February 2024 (UTC)

Oh, did opera develop out of the Greek dramatic poetic tradition? I'd only gotten back as far as intermedi. I'm accumulating quite the reading list! —CalendulaAsteraceae (talk • contribs) 21:16, 24 February 2024 (UTC)

I think you're confusing yourself with ontology. "In the context of a work that is an opera, the term for the role is…" Outside that context (i.e. in the abstract) the terms overlap somewhat, but here we're always discussing which terms to use in the context of a particular text. Xover (talk) 08:51, 24 February 2024 (UTC)

Good point! —CalendulaAsteraceae (talk • contribs) 21:06, 24 February 2024 (UTC)

I'm also confused as to why a librettist isn't the author of the libretto, but is the author of "text" in the change to the Header? --EncycloPetey (talk) 14:54, 24 February 2024 (UTC)

Oh, that's just because I didn't want to have to worry about litigating the boundaries of librettist versus other kinds of text author—same logic as making "arranger" and "composer" just say "music by". That kind of detail is important in some contexts (and should probably be included in the notes if it's not mentioned in the work) but in the context of the header we need to strike a balance between specificity and avoiding unnecessary complexity. I'm not wedded to this particular division of concepts, but those were my considerations. —CalendulaAsteraceae (talk • contribs) 17:15, 24 February 2024 (UTC)

Although on second thought, implementing synonyms is going to be really annoying. Librettist it is! —CalendulaAsteraceae (talk • contribs) 20:51, 24 February 2024 (UTC)

Authority control

Hey! Is there a way that the Header could automatically insert an Authority control template on certain pages, such as Versions pages, any mainspace page that is not a subpage, Author pages that are not subpages and not disambigs, and Portals? That would be a huge improvement as well, so we don't have to add that manually either. SnowyCinema (talk) 03:15, 24 February 2024 (UTC)

That should be doable! Probably

• Finish migrating {{authority control}} to Lua
• Add logic to Module:Header structure that adds authority control if a boolean is set to true or the page meets certain conditions (namespace, not a subpage, etc.)
• Set the authority control boolean to true in Module:Disambiguation, {{versions}} and {{translations}}

—CalendulaAsteraceae (talk • contribs) 03:22, 24 February 2024 (UTC)

Erm. You do realise {{authority control}} goes at the bottom of the page and {{header}} goes at the top? Xover (talk) 08:45, 24 February 2024 (UTC)

…right. That would make things difficult. Maybe not, then! —CalendulaAsteraceae (talk • contribs) 21:17, 24 February 2024 (UTC)

New York Times index

I see the amazing work you are doing to harmonize all the NYT articles. Is the plan to eventually speedy delete all the italicized redirects from the index? It would clean up the index. Are we going to migrate lower case headlines from "Twain and yacht disappear" at sea to "Twain and Yacht Disappear at Sea" as part of the harmonization effort? RAN (talk) 13:26, 27 February 2024 (UTC)

I think the appropriate next steps are

• leave the redirects to avoid linkrot if external sources link there
• migrate lowercase headlines
• migrate articles from Portal:The New York Times and replace the table of articles with a prominent link to The New York Times; the portal can continue to index related works and so forth
• ensure all articles are in the appropriate year/month/day subpages
• ensure all issues with article subpages have a page which indexes the articles
• ensure all issues are linked on the base page
• replace the {{header periodical}} with a normal header (which means redirects won't be included in the index)

I don't have immediate plans to work on this, but I'll probably get around to it at some point—or you could, if you're interested! —CalendulaAsteraceae (talk • contribs) 19:15, 27 February 2024 (UTC)

@Richard Arthur Norton (1958- )

It looks like the work I've been doing on The New York Times over the last couple of months intersects with this. My proofreading focus on the NYT is to get some complete issues done of two important dates - the end of WW1, and the assassination of Lincoln. As part of this I was getting increasingly irritated at the rather poor presentation of the main user-facing NYT page, and have rearranged (and, hopefully, improved) it significantly. In particular, the scan links were just completely inappropriate for a 'user facing' page, particularly as almost none of them linked to actual scans.

I've tried to move every article I could find into a /year/month/day subpage, but haven't attempted to change the actual articles themselves (and have made minimal changes to the article titles). I did use header periodical to create an index for each year that has at least one article, and that can be improved over time for those years that have had more comprehensive work done to particular issues. It should now be possible for an interested reader to actually find the articles that have been proofread and transcribed. I'm sure I'll have made some mistakes on this as it was done completely manually, but it's better than it was before! Qq1122qq (talk) 09:08, 11 April 2024 (UTC)

Automated-index versus manual-indexing for example for Brooklyn Eagle

Are we going to have both, one at Portal:Brooklyn Eagle and one at Brooklyn Eagle. You switched Brooklyn Eagle to manual-indexing from the automated-index. Whenever I encounter a manual-index and automated-index, the article count if off because not everyone adds to the manual index. RAN (talk) 23:05, 27 February 2024 (UTC)

We don't need to create portals for every newspaper. Portal:The New York Times exists because it's mentioned in other works and is a very well-known paper.

While manual indexes are less complete, they're also better-organized and easier to use. FWIW, this PetScan should get you most of the Brooklyn Eagle pages that aren't linked from the main page. —CalendulaAsteraceae (talk • contribs) 23:37, 27 February 2024 (UTC)

Error in John Keats versions pages

Apologies for the trail of errors. I was pasting standard text, then using 'find and replace' to replace the title of the work, to create these, since most of the versions pages only have the same two works listed on them. At some point my 'find and replace' must have got corrupted, but I didn't notice since the impact wasn't visible. Thanks for fixing them. Chrisguise (talk) 13:52, 4 March 2024 (UTC)

You're welcome! I'm glad creating Category:Headers with numerical arguments did in fact turn up pages with issues. —CalendulaAsteraceae (talk • contribs) 18:53, 4 March 2024 (UTC)

Turns out there are more :) https://petscan.wmflabs.org/?psid=27161052 —CalendulaAsteraceae (talk • contribs) 05:22, 7 March 2024 (UTC)

Admin ready

Hi! You've been editing across our namespaces for over three years now, you know our community inside and out, and have been making quite substantial and impressive changes to some of our most important templates as well. I think you're not only ready for the bit, but have a clear need for it and can be trusted with it, and if you accept here I can start an admin vote for you. SnowyCinema (talk) 03:36, 8 March 2024 (UTC)

Thank you! I accept. —CalendulaAsteraceae (talk • contribs) 03:37, 8 March 2024 (UTC)

How to make changes

This is not a good change. There's no edit summary, the diff touches every single line, when I manually compare the revisions it looks like you've arbitrarily changed coding style to your preference with no functional change. I was this close to just reverting it (I'm grumpy before sufficient caffeination). Please undo that change, rethink whatever it is you were trying to do, and then reapply it with a good descriptive edit summary (what are you changing, and why are you doing it). Xover (talk) 06:06, 13 March 2024 (UTC)

Yeah, that's fair, sorry. I will pay more attention to version-control stuff (edit summaries, coherent changes per edit, branching) going forward. —CalendulaAsteraceae (talk • contribs) 20:12, 13 March 2024 (UTC)

Congratulations, you are now an administrator on English Wikisource

Having passed the requisite week of discussion with nothing but glowing endorsements, it is my pleasure to inform you that you are now an administrator. You will notice some shiny new buttons on the top of your page (or under the "More" dropdown, depending on your setup). Use them well. Your first annual confirmation will be in April 2025. Cheers! BD2412 T 17:57, 15 March 2024 (UTC)

An addition to WD version

If it were still a simple template, I might be trying to add an "if P2679" (author of forward) to it for a {{WD forward}}. So, I took a look at the module. Truly, it was easier to behold, without the {{{{{{{{|}}things}}}}}}}}}}}}}} }} in it, but I am hesitant to mess with it. I think just:

	version_info.forward = p.WDStatement({
		['item'] = item,
		['prop'] = 'P2679',
		['prefix'] = ', forward by ',
		['getLink'] = true
	})

And probably a request to another module somewhere.... So, eh, could you?--RaboKarbakian (talk) 11:52, 22 March 2024 (UTC)

current_title scope in Module:Header and /year

A user came onto IRC channel #wikipedia-en-help asking about this error message "Lua error in Module:Header/year at line 430: variable 'current_title' is not declared" for this page: Flowers of Evil (Shanks).

It looks to me like line 22 in Module:Header needs to come after line 24 where current_title gets declared. But I haven't tested it. Jmcgnh (talk) 06:01, 31 March 2024 (UTC)

I was just coming here to mention the same thing after I noticed it but looks like you ninja'd me BrandenJames (talk) 06:05, 31 March 2024 (UTC)

Module:Header

Your most recent edit broke headers across the entire project, so I reverted the change. --EncycloPetey (talk) 06:15, 31 March 2024 (UTC)

@EncycloPetey, @Jmcgnh, @BrandenJames: Well that's an interesting failure mode for Template:Header/testcases. Thanks for catching that; I'll try to figure out how that error got through testing. —CalendulaAsteraceae (talk • contribs) 19:45, 31 March 2024 (UTC)

Formatting changes on, for example, Page:A Shropshire lad (IA shropshirelad00hous).pdf/9

Hi, hope I'm not treading on any toes doing work on 'A Shropshire Lad' - I checked the edit dates and nothing seemed to have been done on it for a year or so.

I was wondering why you felt the need to change the formatting on this page? I've occasionally seen others do the same sort of thing but pretty much every title page I've done and/or seen has been typed as printed. From my perspective, whoever designed the book decided that the text on the title page would be in capitals, so what's the point / assumed benefit of doing it in lower/title case and then telling the system to show it as upper case? If nothing else, it presumably increases demand on storage and processing resources. Chrisguise (talk) 16:41, 1 April 2024 (UTC)

@Chrisguise: No worries about treading on toes, I just saw your edits because the page is on my watchlist and I have changed my mind about some formatting issues since last year :) The reason to set allcaps with CSS is accessibility—it works better for screen readers and for readers who want to change the capitalization style (and it really doesn't add that much processing demand). For a more detailed explanation: https://apastyle.apa.org/style-grammar-guidelines/paper-format/accessibility/typography —CalendulaAsteraceae (talk • contribs) 18:19, 1 April 2024 (UTC)

Request for Template:Vertical Header for tables on Wikisource

Hi, I want a vertical header template identical to w:Template:Vertical_header for tables (e.g. in this page) in Wikisource texts, but unfortunately, there are none currently available. Is it possible to create one for Wikisource, or re-use the one for Wikipedia? Thanks in advance. Sutradhar links (talk) 07:25, 4 April 2024 (UTC)

The problem is that web standards do not provide a clean way to have vertical headers in tables. All the ways to do it—including the one used by enWP's template—are a collection of hacks that kinda sorta gives that effect, but which interferes with other formatting, is prone to break in different contexts and when the environment changes (e.g. due to MediaWiki or skin updates), and don't work in various accessibility and export contexts (e.g. as an eBook). We have several other templates that try to fake something that the web standards don't actually support (drop-caps and hanging indents, for example) and experience shows that we just end up with a half-way solution that nobody is really happy with, and that is a real pain to maintain. Xover (talk) 09:56, 4 April 2024 (UTC)

Update: I was able to use Template:Vlr to achieve a somewhat satisfactory result (see the updated page referred above), though not identical to the ideal version. Anyway, thanks for your response. Sutradhar links (talk) 14:55, 4 April 2024 (UTC)

noexport in Header

Hi. Could you give me a quick rundown of the apparently noexport-related issue that made it necessary to handle TemplateStyles down in Lua instead of with the normal extension tag up in the template? Xover (talk) 09:36, 8 April 2024 (UTC)

The header template wrapped the header stylesheet in <div class="ws-noexport">...</div> for reasons that are not clear to me (but I didn't want to mess with it in case it was important). The reason that TemplateStyles is being handled in Lua is so that other modules like Module:Disambiguation can use the header template without having to separately remember that it has the stylesheet dependency. —CalendulaAsteraceae (talk • contribs) 15:48, 9 April 2024 (UTC)

Ok, so those are separate issues.

The ws-noexport class means the contents won't get included when exported to, say, ePub. The extra div was probably just because it was the easiest way to add the class to the old template code. All that's needed is that it's set on the outermost container in the output markup structure. But why are there two entry points, where one adds the class and one doesn't?

And, let's see… The header structure needs styling, so either all clients must remember to add the stylesheet or it needs to be handled in Lua? But why are the client stylesheets added in Lua from Module:Header structure? The natural place for these stylesheets is in the client templates. Managing client template-specific deps like {{Portal header/styles.css}} down in Module:Header structure would seem to be a layering violation. Xover (talk) 06:08, 11 April 2024 (UTC)

That's fair. I added the get_stylesheet and get_noexport_stylesheet functions to Module:Header structure since I was using the same code to add stylesheets in multiple client modules, but if you think it's better to do it another way, that seems fine to me. —CalendulaAsteraceae (talk • contribs) 17:13, 11 April 2024 (UTC)

Are there clients of Module:Header structure that should not get a ws-noexport class? There doesn't appear to be anyone calling p.get_stylesheet?

The idiomatic way to do it is to load the stylesheet with the parser tag from the client template. Mainly because that makes it visible to anyone looking for it without having to trace through three levels of code, but also because that makes for a clean separation of concerns. The lower level more generic module (Header structure) should ideally know nothing about and have no dependency on the higher level client templates or modules. That way, e.g., {{portal header}} is responsible for styling its own output. But it could just be that I'm missing something obvious?

I'm working on getting rid of some global CSS, some of which targets this cluster of templates, so I need to be sure I understand where the various bits of styling are coming from so I can safely push things to TemplateStyles. And the way it's set up now confused me (not that that's saying much). Xover (talk) 19:54, 11 April 2024 (UTC)

Makes sense, fewer layers to hunt through is a good thing. I've updated the client modules so they handle their own styling. —CalendulaAsteraceae (talk • contribs) 03:16, 12 April 2024 (UTC)

USStatSidenote and it's non standardness...

Can you get this to work in a more standard way in line with what {{right sidenote}} and {{LR sidenote}} are SUPPOSED to be used for?

Page:United_States_Statutes_at_Large_Volume_35_Part_1.djvu/184

Thanks. Other templates in the USStat "family" should ideally also be re-examined. ShakespeareFan00 (talk) 16:49, 10 April 2024 (UTC)

The overlap probably means that somewhere a "display:block; clear: {left|right}" might be needed. It's how I solved a problem with some UK statutes which encountered a related issues, if I recall. ShakespeareFan00 (talk) 08:39, 11 April 2024 (UTC)

God, that code's a mess. I'll take a look, and either fix the issue or get frustrated and give up; stay tuned! —CalendulaAsteraceae (talk • contribs) 17:18, 11 April 2024 (UTC)

If you can also overhaul other sidenotes templates so they don't have the overlap issue, and work with dynamic layouts even better. ShakespeareFan00 (talk) 17:20, 11 April 2024 (UTC)

Something broke - Page:Ruffhead_-_The_Statutes_at_Large_-_vol_3.djvu/299 The sidenotes here should be on the right-hand side.ShakespeareFan00 (talk) 19:23, 11 April 2024 (UTC)

I fixed this. ShakespeareFan00 (talk) 19:24, 11 April 2024 (UTC)

It would be worthwhile for eveyrthing to based on {{sidenote}} as that is what is compatible with the dynamic layouts material. ShakespeareFan00 (talk) 22:26, 11 April 2024 (UTC)

Found another one - https://en.wikisource.org/wiki/Special:ComparePages?page1=Template%3AUSStatSidenote2&rev1=12405159&page2=Template%3AUSStatSidenote&rev2=4658594&action=&unhide=

What does {{USStatSidenote2}} do that the original doesn't? There should only be ONE template?..ShakespeareFan00 (talk) 08:33, 12 April 2024 (UTC)

Agreed. I've made {{USStatSidenote2}} be based on {{USStatSidenote}}. Fully merging the templates would be a lot of work, but should at least be easier now. —CalendulaAsteraceae (talk • contribs) 20:35, 12 April 2024 (UTC)

Some of the other USStat templates add there own sidenotes.. Can those be examined for simplifcations as well so that there is ONE base sidenote, which can be tweaked, instead of about 10 of them? ( https://en.wikisource.org/wiki/Special:AllPages?from=USStat&to=&namespace=10 ) if it helps. ShakespeareFan00 (talk) 20:28, 12 April 2024 (UTC)

I think all the USStat templates are all using {{USStatSidenote}} now. —CalendulaAsteraceae (talk • contribs) 22:20, 12 April 2024 (UTC)

Somethings not quite right here:-

United_States_Statutes_at_Large/Volume_1/1st_Congress/1st_Session/Chapter_1

The date is WAY over to the right.

ShakespeareFan00 (talk) 22:26, 12 April 2024 (UTC)

Fixed by basing {{USStatSidenote}} on {{sidenote}}. —CalendulaAsteraceae (talk • contribs) 20:22, 14 April 2024 (UTC)

Template:Lang_block

Hi, can you consider adding open/close support to this or to Module:Lang, desired behaviour would be that it works like the similarly named options in ppoem, with some tweaks for the use case..

start	open	Opens in both page and on transclusion
end	close	closes in both page and on transclusion
end	block	close behaviour in Page: , closes a paragraph/block on transclusion but omits other closures
start	block	open behaviour in Page: , opens a paragraph/block break on transclusion but omits other closures
end	continues	close behaviour in Page: namespace, omit closing code on transclusion.
start	continues	open behaviour in Page: namespace, omit opening code on transclusion.

Prompted by the multi-lingual situation here -https://en.wikisource.org/wiki/Page:United_States_Statutes_at_Large_Volume_38_Part_2.djvu/602 (although portions here should eventually move to other Wikisource.)

Being able to have open/close params for lang would also enable over time the deperecation of {{lang block/s}}{{lang block/e}} and the need to resync 4 different templates, leading to simpler logic and more efficient markup I think.

You are welcome to take up the general issue more widely, on the Scriptorium as well as there are many other templates using an /s /e /m approach that might also benefit from an open/close approach as well ShakespeareFan00 (talk) 13:14, 14 April 2024 (UTC) ShakespeareFan00 (talk) 13:14, 14 April 2024 (UTC)

Outside R/L

These do not always work well with Dynamic layouts. If you can make them work with Dynamic layouts so much the better. See also {{MarginNote}}, {{margin block}}, {{numbered div}} etc.. If you've already started on a consolidation,there is sense in doing a whole scale overhaul of all of these.. :) ShakespeareFan00 (talk) 08:12, 15 April 2024 (UTC)

Page:Provisional_Collection_of_Taxes_Act_1968_(UKPGA_1968-2_qp).pdf/5 - Here Outside L/R might need a manual shift adjustment( The template doesn't take into account that the margin on a list/indetation might have been tweaked, hence one of the sidenotes that is a reference to another act isn't flush with the left/right hand side respectively. ShakespeareFan00 (talk) 08:32, 15 April 2024 (UTC)

Ideally Outside(L/R) etc , and left/right sidenote should all do the same thing! Outside L/R however have the ability due to being floated to have clear(left/right) setup (to avoid overlaps) as opposed to left/right sidenotes that are absolute positioned. This may need a MASSIVE (and possibly breaking change) overhaul.

(Aside: I will continue with rh migration when I have time.)

ShakespeareFan00 (talk) 08:32, 15 April 2024 (UTC)

A minor "linter"- https://petscan.wmflabs.org/?psid=28031835 This tracks Mostly mainspace pages where there is both an Outside L and Outside R. With the exception of the legislation in the query, other items should be made consistent in Mainspace(on transcusion0 bu using the RL or LR variants appropriately for the works concerned. ( Fixes required are an afternoon's effort at most.) ShakespeareFan00 (talk) 09:43, 15 April 2024 (UTC)