Xover

Template_talk:RunningHeader#Migrating this template to Lua

I took your suggestion of importing an upstream module for Module:Roman! Could you take a look at Module:Running header and Template:RunningHeader/testcases and let me know what you think? —CalendulaAsteraceae (talk • contribs) 21:37, 9 November 2023 (UTC)

@CalendulaAsteraceae: Heh. Would you believe just hours before you posted this I was looking at {{rh}} and thinking to myself "I should really convert this to Lua!" (before punting as my todo is already too long)?

Overall looks awesome! Some quick observations in no particular order:

• Module:Optional CSS attribute is using somewhat confusing terms. It says it's working on CSS, but what it's really doing is constructing HTML attributes, some of which contain CSS, but in Module:Running header you're using it to make a HTML class attribute (which has no inherent connection with CSS, except that it's often targeted by CSS selectors). I'd suggest rethinking this module and what it's supposed to be. Maybe the module is about making HTML attributes? Perhaps it would make sense to have specific named helper functions to make .class(), .style(), etc. attributes? And it could either inline or in a sibling module have functions for working with actual CSS properties and values. Not directly related to {{rh}} but it took me a good long while to figure out what the calling code there was actually doing.
• Module:Running header#L-13 and on is confusing. Why do we need n here? It used to be an IPC mechanism for communicating between {{RunningHeader}} and {{RunningHeader/core}}, but now we're merging the logic inside Module:Running header. Where would args.n even come from? Wy are you checking for the value 4 when the only actual special case is three cells? Also, the code seems to cap the number of cells at 4, but /core supports up to nine. I think this should either be an enforced cap at a specific number (with reasoning: why are we capping it) or infinity.
• Module:Running header#L-20 is concise and elegant; but I found it unexpectedly hard to parse. I think the code is more complicated than the actual task it is implementing, not helped by the alien introduced by make_attribute_string(). I think I would have gone for a less elegant but more straightforward approach here. Then again, maybe the existing code would be clearer if the concept of Module:Optional CSS attribute was more intuitive?
• Module:Running header#L-38: why are you trimming a string you are producing yourself?
• Module:Running header#L-49: k is traditionally the "key" for an associative array (hash). The usual mnemonic variable name for a for loop counter is i (iteration, index). Also, a step size of one is the default and does not need to be made explicit (and in Lua usually isn't; unlike C-derived languages, Perl, etc.).
• You might want to look at using mw.html to generate markup in a more fluent way. It may be an awkward fit here, and it might be overkill for the use, but it's worth looking at at least.
• Module:Running header#L-56: Note that in its typical perverse style, MediaWiki will look for wikitext even in pages with a different content model. The category string there is going to get picked up and count toward things like category links, sometimes error tracking categories, etc. I plan to eventually write a module to generalize and abstract tracking cat handling that avoids this, but in the mean time I generally recommend doing awkward stuff like style_cat = '[[' .. 'Category:' .. catname .. ']]'.
• Module:Running header#L-59: The newlines aren't needed. HTML doesn't care, and the parser will mess with them as it sees fit in any case. The HTML output here isn't meant to be human-readable, and will need to be fed through a pretty-printer to be so no matter what we do here.
• Why is Module:Running header centered a separate module when all it does is add an extra class and then call {{#invoke:running header|_running_header}}?

Not every comment is, obviously, something you should necessarily take as gospel, and assume an "IMO" at some suitable place in each sentence. These are "thoughts" more than "advice", and jotted down fairly quickly as I looked at it the first time. More when I have time. Xover (talk) 09:57, 11 November 2023 (UTC)

Hmm. The output seems to be missing "wst-running-header-cell" classes for the cells. For three-column headers these could also beneficially have "wst-running-header-{left|center|right}" classes. And the old output has a "wst-running-header-default" class when no custom class has been added.

Incidentally, due to this template's ubiquity, I think we could beneficially use just "wst-rh-" as a prefix. There are enough instances of it that the byte savings are going to be measurable, and it saves having to type out the whole thing every time (especially in complex selectors). Xover (talk) 12:36, 11 November 2023 (UTC)

Thank you, this feedback was helpful!

• You're right that Module:Optional CSS attribute is about making HTML attributes. I ended up deciding it was unnecessary to use it for Module:Running header, but I'll keep your feedback in mind for future.
• I've implemented your suggestions about style_cat, Module:Running header centered, and classes. CSS that will need to be updated: search for .wst-running-header in CSS files
• I've removed the newlines between cells.
• Re args.n, the main concern was that there are a lot of invocations of {{RunningHeader}} that assume that the template will have three cells even if only the first one or two parameters are used. I've redone this part of the code to (hopefully) handle this more fluidly.

Looking at Template:RunningHeader/testcases, it seems that the spacing for four-cell headers is different in the updated code. Do you have insight as to why this is? —CalendulaAsteraceae (talk • contribs) 00:09, 12 November 2023 (UTC)

@CalendulaAsteraceae: In /sandbox.css#L-9 you have

.wst-rh > div {
  flex: auto;
}

flex: auto; is a shorthand property that expands to flex: 1 1 auto;, which in turn is the same as:

.wst-rh > div {
  flex-grow: 1;
  flex-shrink: 1;
  flex-basis: auto;
}

In /styles meanwhile, there's no explicit selector for these; which means the effective rule is flex: initial; which expands to flex: 0 1 auto;, which in turn is the same as:

.wst-rh > div {
  flex-grow: 0;
  flex-shrink: 1;
  flex-basis: auto;
}

When flex-grow is any non-zero number, it is a ratio used for deciding how to distribute any remaining space between flex items in the same flex container. If all the flex items have the same flex-grow value they all get equal parts of the remaining space. But if flex-grow is zero it means the flex item cannot grow to fill available space in the flex container. The difference is something like this:

flex-grow-0

Cell 1

Cell 1

Cell 1

Cell 1

flex-grow-1

Cell 1

Cell 1

Cell 1

Cell 1

When the flex items cannot grow larger than their automatically calculated width (max-content() in this case), justify-content: space-between; comes into effect (as there now actually is any space to distribute between the flex items).

Left- or right-aligning the contents of the flex items that can grow won't line up with the same alignments for the flex items that can't grow for the simple reason that their reference point is different: the items that can grow align relative to an edge that is in the free space outside the items that can't grow. The only common reference points for these is the center line, so aligning the growing flex items to center will give the same effective alignment.

The exception is the two outermost flex items. Because we have justify-content: space-between; active, that free space is distributed only on the inside. The two outermost flex item edges do not get any extra space on their outside edge (they are flush with the flex container, modulo padding and margins etc.). These therefore do have a common reference between the non-growing flex items and the growing flex items, on the left edge for the first flex item and on the right for the last flex item. And when they have a common reference they can be aligned relative to that reference and end up in the same place. Which is why the leftmost and the rightmost cells in the old and new template output appear to be aligned correctly.

Without really digging into it my thought is that flex-grow: 1; is the correct mode, and that we should have text-align: center; for all the flex items except the :first-child and :last-child which should be left and right aligned respectively. --Xover (talk) 10:07, 12 November 2023 (UTC)

Thank you for explaining! Using flex-grow: 1; and having text-align: center; for all the flex items except the :first-child and :last-child sounds good to me (with the exception of four-cell headers having the second cell left-aligned and the third-cell right-aligned, since this is the current style).

Thoughts on next steps?

1. Find & address any remaining issues with the new code.
   • Solicit feedback from other users? (Where?)
2. Update {{RunningHeader}} and Template:RunningHeader/styles.css.
3. .wst-running-header → .wst-rh in relevant pages; run a bot on the template and index CSS pages?
4. Replace {{RunningHeader/core}}.
5. Replace the now-redundant sub-templates {{RunningHeader/1}} through {{RunningHeader/9}}. (Maybe keep {{RunningHeader/1}} and {{RunningHeader/2}} since otherwise you have to specify cell_count; depends how heavily they're used outside of other templates.)
6. Delete unused stylesheets that are now redundant to Template:RunningHeader/styles.css.
7. Announce changes:
   • {{RunningHeader}} is backed by Module:Running header instead of {{RunningHeader/core}}.
   • {{RunningHeader}} now supports an arbitrary number of cells. If you input fewer than 3 cells, it will default to a 3-cell header, but you can set cell_count = 1 or cell_count = 2 if you want fewer cells. (Possibly {{RunningHeader/1}} and {{RunningHeader/2}} will also be options.)
   • The class prefix has been changed from "wst-running-header" to "wst-rh".

—CalendulaAsteraceae (talk • contribs) 19:24, 12 November 2023 (UTC)

@CalendulaAsteraceae: I don't think it's accurate to say the second/third cells are left/right-aligned. They may have that style applied (I didn't check), but since the div that contains the text collapses to its contents there's no space there for text-align to take effect. What you're seeing is probably just the distribution of the cells. If we're going to generalize a rule I think it either has to be all but the :first/:last being centered; or it has to be the somewhat more involved "all cells left of the midpoint are left-aligned, all cells to the right of the midpoint are right-aligned, if there's an odd number of cells the middle one is centered, if there's an even number of cells none are centered". My initial take is that the latter is over-complicated and not necessary. I could be wrong, of course, but…

I think we need more testcases before proceeding. For example, the ones I just added told me that while /core supports up to 9 cells, {{rh}} itself only supports exactly 3 or 4. I hadn't actually twigged to that when looking at the code. It probably doesn't matter, but that's the sort of change of functionality that we need to be conscious of and test the implications of.

I am also not sure we need |cell_count=. I haven't checked, but I'm pretty sure you can detect the difference between a parameter being present-but-empty and a parameter being absent. If so, why is the |cell_count= not simply the number of cells provided as input?

For the classes, output both the old and new classes on deployment, then you can take your time migrating existing uses of the old class. Once there are no uses left we can stop outputting the old class. That gives us a clean migration with no disruption.

{{RunningHeader/core}} can be deleted once it's no longer in use. All the /n variants too. What's the need for keeping /1 and /2? I don't think anyone cares whether there are one, two, or three cells in the output header so long as the one or two cells they provide end up in the right position. In my spot-checks I've only found two users adding these, and I've queried them as to the reasoning. Xover (talk) 08:49, 13 November 2023 (UTC)

And cf. my query to SF00 on their talk: My working theory is that we can make {{rh|42}} do what rh/1 does and {{rh|42|Chapter 3}} do what rh/2 does, or at least be treated identically to {{rh| |42| }} and {{rh|42| |Chapter 3}}. Xover (talk) 08:57, 13 November 2023 (UTC)

I've added the old class to the module for now.

Re left/right-alignment, I was just talking about the stylesheet. I'm on board with simplifying that situation. Also, I expect this to make {{RunningHeader-centered}} redundant, although I'll need to review the existing uses. (Wikisource:Bot requests#One more Template:RunningHeader-centered request would help with that.)

Really the only reason to have |cell_count= is backwards compatibility. Since {{rh}} only supports exactly 3 or 4 cells, if you only fill in the first 1 or 2 cells, the contents will be slotted into a 3-cell header, with the corresponding alignment. I'm pretty sure I've done this myself. If we converted existing instances of {{rh|42}} → {{rh|42||}} and {{rh|42|Chapter 3}} → {{rh|42|Chapter 3|}}, we wouldn't need |cell_count= and could just determine how many cells to use based on the number of input cells. —CalendulaAsteraceae (talk • contribs) 05:57, 14 November 2023 (UTC)

I was right, we'll be able to merge {{rh-c}} and {{rh}} :) —CalendulaAsteraceae (talk • contribs) 23:52, 14 November 2023 (UTC)

Another design question: is the style parameter useful? —CalendulaAsteraceae (talk • contribs) 16:27, 16 November 2023 (UTC)

@CalendulaAsteraceae: Unless there's a use out in the wild that can't be better handled with Index CSS, then, no, all |style= parameters in all templates should go the way of the dodo. We should always discourage as much as is reasonably possible, raw CSS or other unbounded formatting in the content spaces. |style= is a safety-valve to make unusual and hard things possible, but we want as little as possible and preferably zero of them. Xover (talk) 16:40, 16 November 2023 (UTC)

As far as I can tell, no one's using it at all :) Category:Running headers applying manual styles —CalendulaAsteraceae (talk • contribs) 16:42, 16 November 2023 (UTC)

Then hurry up and remove it before anyone gets ideas… Xover (talk) 16:53, 16 November 2023 (UTC)

Done! —CalendulaAsteraceae (talk • contribs) 16:54, 16 November 2023 (UTC)

Speaking of not letting people get ideas—WS:PD#Template:RunningHeader-centered. —CalendulaAsteraceae (talk • contribs) 20:57, 16 November 2023 (UTC)

An update on the transition plan: while of course we should do our best to find and migrate all the invocations with fewer than three parameters before migrating, I've also added a tracking category to the module in case we miss some. (Relatedly, we should hold off on replacing {{rh/1}} and {{rh/2}} until we've emptied that category.) —CalendulaAsteraceae (talk • contribs) 23:21, 21 November 2023 (UTC)

My thoughts on a migration plan:

• Create tracking categories (after making sure they're the right ones).
• Make sure Category:Running headers applying manual styles is empty.
• Make {{rh}} use Module:Running header. The only functionality change will be the removal of the style parameter.
• Add the contents of Template:RunningHeader/styles/sandbox.css to Template:RunningHeader/styles.css (in addition to what's there now). This won't change functionality.
• Change wst-running-header to wst-rh in index CSS, preferably with a bot.
• Change wst-running-header to wst-rh in other pages.
• Remove the wst-running-header class from the module.
• Remove the wst-running-header styles from Template:RunningHeader/styles.css.
• Empty Category:Running headers with one entry and Category:Running headers with two entries.
• Check pages in Category:Empty running headers, Category:Running headers with undefined entries and Category:Running headers with more than four entries.
• Remove the code that enforces a three-cell minimum and adds Category:Running headers with one entry, Category:Running headers with two entries, and Category:Running headers with more than four entries.
• Migrate all the other templates using {{rh/core}} to use {{rh}}.
• Migrate uses of the rh/n templates to {{rh}}.
• Delete unused templates and tracking categories. (Keep Category:Running headers using explicit parameter names, Category:Running headers with undefined entries, and Category:Empty running headers.)

—CalendulaAsteraceae (talk • contribs) 15:49, 28 November 2023 (UTC)

Does this look like a good plan to you, and if so, what testing needs to happen before we start implementing it? —CalendulaAsteraceae (talk • contribs) 06:01, 14 December 2023 (UTC)

The plan looks good, except you need to give the community a heads up at WS:S before changes that might conceivably break something (because it might break a large number of pages), so they know it's coming and who to contact if they see something broken.

Testing is iffy because we can't rely on code coverage in /testcases, since the output is expected to change. I think systematic creation of synthetic test cases + a selection of real-world pathological cases on /testcases is a good idea. Not to catch issues beforehand so much as being able to quickly identify problems after the change. And, of course, random sampling of pages "in the wild" after changes. Xover (talk) 07:20, 14 December 2023 (UTC)

Heads-up at WS:S#Updates to Template:RunningHeader. I've done my best to fill out /testcases, and haven't found any real-world pathological cases yet but will keep an eye out. —CalendulaAsteraceae (talk • contribs) 09:36, 3 January 2024 (UTC)

I don't have a lot of experience with these kind of Big Change discussions. It seems like the conversation's mostly died down, but do we need to wait for anything before getting started by updating the styles page? In particular: more arguments about using Lua at all, more testing, or more time for people to see the discussion? I would add "more discussion about the two-cell header thing", but it would be pretty nice to have the template using Lua even if the code has some silly special-casing in it. —CalendulaAsteraceae (talk • contribs) 03:20, 18 January 2024 (UTC)

The issue of whether to use Lua at all is a digression: its motivations are valid (complexity, maintainability, sustainability, etc.), but arguing that technology should stop advancing is not a productive way to handle it. We can certainly have those discussions, but then as general discussions not as part of the conversation for this specific template.

I haven't been paying close attention to this discussion (sorry, IRL is eating all my mental capacity right now), but with that caveat in mind… I think the two-cell header thing is the remaining issue to address. I don't tend to use two-cell headers so I don't have a gut feeling about the best way to handle it. It would be nice to have the functionality be completely genericised, but the details and what's the most common use cases for it are the critical factors for whether it needs to be special-cased. Users' muscle memory can be retrained, but if doing so creates a bigger overhead (requiring a lot of works to create Index CSS to handle it, say) it may be a necessary optimisation for user convenience. I don't have an answer for that ottomh. Xover (talk) 07:38, 18 January 2024 (UTC)

No worries! The only thing users will need to do differently is switch to adding a third empty header cell for left-center headers, which is only one extra keystroke. Retraining muscle memory is a cost, but I don't think it's an insurmountable one, especially since most headers are inserted automatically using the Header field of the index or with user scripts. (We can update the former and nudge users to update the latter.) —CalendulaAsteraceae (talk • contribs) 18:20, 18 January 2024 (UTC)

Hi! Just wanted to check whether you're convinced about the two-cell headers. —CalendulaAsteraceae (talk • contribs) 23:17, 25 January 2024 (UTC)

@CalendulaAsteraceae: I am convinced that you've thought the issue through to a far greater extent than I have, and that therefore I have very little useful to contribute to the question? :) Xover (talk) 06:56, 26 January 2024 (UTC)

Great, works for me :) In that case, could you do step 1 of the transition plan and replace the contents of Template:RunningHeader/styles.css with Template:RunningHeader/styles/sandbox.css? —CalendulaAsteraceae (talk • contribs) 15:19, 26 January 2024 (UTC)

(To be clear, the reason I'm asking you to do this is that while I can edit {{RunningHeader}}, I cannot edit the style sheet.) —CalendulaAsteraceae (talk • contribs) 06:51, 5 February 2024 (UTC)

@CalendulaAsteraceae: Not any more. :-) Xover (talk) 19:28, 6 February 2024 (UTC)

Thank you! —CalendulaAsteraceae (talk • contribs) 19:37, 6 February 2024 (UTC)

One more thing, could you unlock Template:RunningHeader/core? —CalendulaAsteraceae (talk • contribs) 17:19, 12 February 2024 (UTC)

Van Druten DjVu

I have another DjVu request: The Return of the Soldier by John Van Druten (external scan). I am planning to focus on dramatic works all this year, but I will first finish a handful of works in progress, so no hurry on this particular request.

The scan will have to be uploaded locally, since the author is from the UK, and died in 1957 (so protected until 2028), and preferably name the scan File:The Return of the Soldier (Van Druten).djvu to distinguish it from the Rebecca West novel it is based on. --EncycloPetey (talk) 00:51, 22 January 2024 (UTC)

@EncycloPetey: It's apparently geolocked at Hathi so I can't get at it. Sorry. Xover (talk) 05:55, 22 January 2024 (UTC)

I have institutional access and could easily download + share the page images, if that would be helpful. —CalendulaAsteraceae (talk • contribs) 07:15, 27 January 2024 (UTC)

@CalendulaAsteraceae: That would be awesome! Xover (talk) 08:46, 27 January 2024 (UTC)

OK, I've got the images. I don't really want to upload 124 images with the WS upload interface, so what's a good way to share them? —CalendulaAsteraceae (talk • contribs) 06:57, 28 January 2024 (UTC)

@CalendulaAsteraceae: If you have iCloud Drive, Dropbox, Google Drive, or similar, putting a zip file there and sharing it (probably best to drop the link in email rather than on-wiki) would be ideal. Alternately, if the work is public domain in your jurisdiction, you could upload it to the Internet Archive. I'm sure there's also some website out there that'd let you share a zip, but I don't know of one off the top of my head. Downloading 124 loose images is even more tedious than uploading them, so I very much hope we can find a way to exchange it in a container format like zip. Xover (talk) 08:09, 28 January 2024 (UTC)

Great! I've sent you an email with a Google Drive link. —CalendulaAsteraceae (talk • contribs) 08:15, 28 January 2024 (UTC)

@EncycloPetey: Done, thanks to CalendulaAsteraceae. Xover (talk) 09:10, 28 January 2024 (UTC)

Thanks so much! --EncycloPetey (talk) 17:59, 28 January 2024 (UTC)

Linting -

https://public-paws.wmcloud.org/4407/idx.txt - This is a listing of a sizeable chunk of Index with lint-error containing pages. Most are not proofread. It would be appreciated if someone could come up with a project to try and get some of these lint-free. (In many cases the lint errors are a pair of italic tags with a line-feed between them! and easy to solve.) ShakespeareFan00 (talk) 00:34, 2 February 2024 (UTC)

Header updates

I've taken another stab at updating {{Header}}. Does Module:Header/sandbox look like it's making a reasonable amount of changes? —CalendulaAsteraceae (talk • contribs) 04:13, 9 February 2024 (UTC)

@CalendulaAsteraceae: I would have split that up into maybe 3-5 steps, but it looks within reasonable limits, yes. Xover (talk) 10:14, 9 February 2024 (UTC)

Great! Could I ask you to review my changes and merge them into the main template? —CalendulaAsteraceae (talk • contribs) 17:30, 9 February 2024 (UTC)

@CalendulaAsteraceae: That requires available brain cycles and sustained attention, so as things look now that could maybe happen around Easter. How about I drop the protection and you can have at it yourself? Xover (talk) 08:58, 10 February 2024 (UTC)

Sure, sounds great to me! —CalendulaAsteraceae (talk • contribs) 20:57, 10 February 2024 (UTC)

@CalendulaAsteraceae: Done. Module, template, and main stylesheet can now be edited by autopatrolled users. Please let me know if I missed anything; and when you're all done so I can jack the protection back up to +sysadmin. Xover (talk) 21:15, 10 February 2024 (UTC)

@Xover: Will do! —CalendulaAsteraceae (talk • contribs) 21:16, 10 February 2024 (UTC)

Could you also drop the protection for Module:Portal header, Template:Portal header, Module:Author and Template:Author? (I'll make sure to give you a full list of pages when I'm done). —CalendulaAsteraceae (talk • contribs) 00:15, 12 February 2024 (UTC)

@CalendulaAsteraceae: Done Xover (talk) 06:14, 12 February 2024 (UTC)

Another unprotection request: Template:Translation header. —CalendulaAsteraceae (talk • contribs) 21:06, 12 February 2024 (UTC)

@CalendulaAsteraceae: Done Xover (talk) 06:42, 13 February 2024 (UTC)

Running header ..

The problem arose with {{RunningHeader/1rv}} and {{RunningHeader/1}} Unless the verso/recto classes are apparently defined in a very specfic order and location , they get overwritten by the generic template. I appreciate why you don't want these in site wide template, but perhaps you can suggest how to PROPERLY "fix" specific Indexstyles which were migrated over to use the updated naming structure and do not apparently work unless the recto, verso behaviour is defined in the generic stylesheet.

Most of the content in the stylesheet for {{rh/1}} was redundant to the generic stylesheet in {{rh}} anyway. See https://en.wikisource.org/w/index.php?title=Template:RunningHeader/1/styles.css&action=history The specfic Indexstyles that were not working yet:

• Index:The Seven Pillars of Wisdom (1926).djvu/styles.css
• Index:The_Annals_of_Our_Time_-_Volume_1.djvu/styles.css

ShakespeareFan00 (talk) 09:15, 12 February 2024 (UTC)

See also ALL the Pages: linked from {{rh/1rv}} - https://en.wikisource.org/wiki/Special:WhatLinksHere?target=Template%3ARunningHeader%2F1rv&namespace=

The behaviour for that template seemingly changed because of changes in how {{running header}} and related work.

Perhaps you'd like to implement an appropiate fix, before I revert every single contribution I've made in response to another contributors request to "update" usages of {{rh}} and related, potentially creating far more chaos in the process? ShakespeareFan00 (talk) 09:22, 12 February 2024 (UTC)

In the specfic - Page:Hesiod, The Homeric Hymns, and Homerica.djvu/100 The recto-verso behaviour is apparently ignored. Perhaps you can sit down and figure out how to do this, without it being overrideen due to a higher priority CSS stlyle undoing what's defined on the very specfic template? Thanks. ShakespeareFan00 (talk) 09:37, 12 February 2024 (UTC)

Also https://en.wikisource.org/w/index.php?title=Index:Risk_of_performance_errors_due_to_sleep_loss,_circadian_desynchronization,_fatigue,_and_work_overload.pdf/styles.css&action=history , where I had to revert the update, to get it working again. ShakespeareFan00 (talk) 09:46, 12 February 2024 (UTC)

@ShakespeareFan00: What you describe sounds like the well-known issue with selector specificity in CSS. It's solvable, but requires some understanding of how selector specificity works and how it interacts with our hierarchy of templates. But making changes to these templates and their style sheets willy-nilly is not the way to go about it. In the first instance bring the issue up with CalendulaAsteraceae who is currently working in this area and let them figure out how it fits in with the other changes they're making. And there's no need to (and it's not a good idea to) start mass reverting stuff. There is no particular urgency, so cool heads, think things through, and find a good long-term solution is the order of the day. Xover (talk) 10:19, 12 February 2024 (UTC)

Noted. I'll ask him about the 2 very specfic templates concerned, as they seem to be the ones creating the issues.ShakespeareFan00 (talk) 13:25, 12 February 2024 (UTC)

I thought it was CSS selector specificity. I'm just not sure how to solve it currently. ShakespeareFan00 (talk) 14:11, 12 February 2024 (UTC)

Index:Brain Volume 31 Index.pdf/styles.css

This page was associated with an index page that you deleted - I assume that the styles page should be deleted too. -- Beardo (talk) 17:52, 12 February 2024 (UTC)

@Beardo: Indeed. Thanks for the heads-up. Xover (talk) 06:41, 13 February 2024 (UTC)

Module_talk:Author/testcases

I think the word here is, "Why?" . This isn't the first 'glitch' I've noted from all the header changes, including a very obvious typo, that a slower approach would have caught quite quickly ShakespeareFan00 (talk) 15:26, 15 February 2024 (UTC)

Our Poets DjVu

Would you please be kind enough to prepare a DjVu from (external scan)? There are enough irregularities in the listing that I do not trust IA's PDF, and this work is nominated for deletion, but it's contents cover many 19th/20th century poets from whom we have little or no sources about their work. --EncycloPetey (talk) 19:48, 17 February 2024 (UTC)

@EncycloPetey: Index:Our Poets of Today (1918).djvu. I did a quick pass on missing pages, page order, etc. and it looked good. Xover (talk) 11:20, 18 February 2024 (UTC)

Thanks! --EncycloPetey (talk) 19:29, 18 February 2024 (UTC)

Removal of 'by' from transclusions using override_author

Hi. I note you have been removing the manually-entered 'by' where 'override_author' is used, and am wondering why. I took up the practice, having seen it done elsewhere, as it makes the presentation consistent with pages which only use 'author', where the 'by' is automatically included. Regards, Chrisguise (talk) 00:15, 23 February 2024 (UTC)

@Chrisguise: The edit summary should have contained a link to the relevant discussion, but in any case the removal of the manual "by" is so that {{header}} can start automatically adding "by" without creating "by by". Xover (talk) 06:32, 23 February 2024 (UTC)

OK Chrisguise (talk) 07:37, 23 February 2024 (UTC)

Page:Tristimulus specification of the Munsell book of color from spectrophotometric measurements (IA jresv31n1p55).pdf/23

I get a 'too-small' to be usable edit space for this. The only possible thing I can think of something that changed in recently, because it wasn't doing this until toady.

I appreciate your efforts in trying to clean out cruft, but something broke here.

And before you ask I did try viewing/editing without being logged in and got the same behaviour.

Also I've not had the ability to resize it for an EXTENDED period.

I am suspecting some kind of obscure interaction, but if there isn't a soloution I am reconsidering if I want to contribute on a project that's actively "broken".

ShakespeareFan00 (talk) 22:34, 24 February 2024 (UTC)

@ShakespeareFan00: The lack of resizing is annoying, but they dropped the ability during a modernization of the code because they didn't find a clean way to implement it. The cramped editing interface for scans that are in landscape orientation is simply a bug. You can temporarily work around it with:

.prp-page-container {
	min-height: 80vh;
}
.prp-page-image-openseadragon-vertical {
	height: 100% !important;
}

This behaviour is a tradeoff: almost all scan pages are in portrait orientation and the current behaviour works very well with those (compared with the old code), but it fails pretty miserably with landscape pages and there's no obvious robust fix for it. Longer term I'm hoping we get a full-screen editing interface (for other reasons) that would also fix this problem in most cases. Xover (talk) 10:03, 25 February 2024 (UTC)

I asked someone that worked on Proofread page to consider integrating Inductiveload's Minipane style UI. It's not something that is a high priority though obviously. ShakespeareFan00 (talk) 09:45, 26 February 2024 (UTC)

Colors...

Hi.. How quickly could you come up with a Lua Module to generate colors based on a blend of RGB triplets by percentage? ShakespeareFan00 (talk) 00:24, 26 February 2024 (UTC) (I needed a way to generate HTML hex colors for Ridgway's 1912 book, based on his methodology.) ShakespeareFan00 (talk) 00:24, 26 February 2024 (UTC)

@ShakespeareFan00: If I understand the calculation and the usage context, probably not that long. If it's taking a triplet of percentage values (0–100%) in and spitting them out converted to a triplet of hexadecimal values in a 0–255 space, then that should be fairly easy. If you need fancier conversion or other special behaviour it might be trickier. Xover (talk) 06:23, 26 February 2024 (UTC)

Ridgway, uses a series of pure hues, (he gives wavelengths) , blended in a percentage to give a full spectrum of colors. Colors from that spectrum are then blended with various levels of whit or black (there is a table) in the book to give an initial series.

All the colors in the first series are then blended with various amounts of neutral grey ( I took this to mean a 50% grey (or N/5 level on Munsell's scale.)

Breaking this down the first function in the module would take the sRGB values for pure hues, and 'blend' them on the basis of percentages, returning an HTML style value for use in a style statement.

The second function would take the value of the first and blend it with white or black percentages, again returning an HTML color value for the blended tone or shade.

The third function would take an html hex value from the previous 2 functions and blend it with a specified percentage of neutral gray.

If it's possible to combine all these into one ultimate ridgway color generator, based on the tables provided in the book, even better.

BTW if writing a color module, I would strongly suggest making it flexiblbe enough that it could also do RGB->HSL and other color space conversions in the future.

Additional functions could be for conversion of xyY or XYZ specified colors to clamped sRGB. This transformation has a specific matrix for doing so, (albiet in respect of certain data it would need to be able to accomodate adjusting the putput for different illuminat conditions. (In some of the JOSA published MUnsell data for example it's using Illuminat C whereas sRGB is Illuminant D65.).

The reason I am wanting a module to do this (based on established methodology) is that I couldn't be sure the color plates in some works had not faded compared to original publication. ShakespeareFan00 (talk) 09:44, 26 February 2024 (UTC)

@ShakespeareFan00: What you're describing here is something completely different than converting one way to specify a color in a given color space to another. What you're describing here is about converting between colour spaces, and that's pretty advanced stuff (read: not something I'm going to tackle any time soon). The best I can offer is to suggest you take a look at w:Module:Color to see whether it does any of what you need. I'll also note that the values provided by the early pioneers in now-PD (i.e. old) books does not necessarily match seemingly similar values in what are the current standards a hundred years later. Figuring out this stuff requires domain-expertise in colour theory that at least I do not have. Xover (talk) 10:04, 26 February 2024 (UTC)

Module:Color doesn't convert xyY or XYZ (yet). But it does have a useufl mixer function that would be useful. Can we put it on the import list at some point? ShakespeareFan00 (talk) 14:08, 26 February 2024 (UTC)

Gadget transclusion-check question

Hello, Xover, I am from Ukrainian wikisource, we would like to use same approach as you utilized in transclusion-check gadget, thanks for creating it.

https://en.wikisource.org/wiki/MediaWiki:Gadget-transclusion-check.js

But while I was reviewing your code for a gadget, I noticed that line 185 has namespace ids of 0 and 114, though in eng wikisource you don't have this ids, see here: https://wikisource.org/wiki/Wikisource:Namespaces

Also, on page https://en.wikisource.org/wiki/MediaWiki:Gadgets-definition you have an attribute namespaces=106, as I understand it forces gadget to work only inside that namespace, witch makes my question about 0 and 114 even more open. Could you please take a look there? It looks like 0 and 114 are from some obsolete revision. We are curious, what ids should be used (should it be for Index or some others)? Thank you. Maxbgn (talk) 21:21, 26 February 2024 (UTC)

@Maxbgn: ns:106 on enWS is the Index: namespace. The Gadget is limited to only execute there because its purpose is to mark the page numbers in the pagelist on an Index:. When it runs it queries the MediaWiki API for information about those Page:-namespace wikipages, and among the information it requests is what other wikipages they are transcluded in. The namespace numbers you see in line 185 are for mainspace and the Translation: namespace. They're being used to filter the API response so that it only returns information about transclusions in those namespaces (and not in, for example, a sandbox in the User: namespace).

The link you give is for Multilingual Wikisource (aka. mul:Wikisource:Namespaces). English Wikisource's namespaces are at Help:Namespaces. It's easy to get us mixed up since mulWS also has a lot of project pages in English (and no other Wikimedia project has a separate Multilingual variant).

Incidentally, I am very to happy to see that my contributions can be of some use on other Wikisourcen. Please do not hesitate to reach out if there's anything I can help with. I'd also appreciate feedback about what you had to change or what made adopting it difficult, so that I can perhaps make that easier for the other Wikisourcen that want to use it. Xover (talk) 22:34, 26 February 2024 (UTC)

Thank you again for your response and gadget, we have successfully launched it in Ukrainian wikisource. Now this page Help:Gadget-transclusion-check is available in Ukrainian language also, where I translated your documentation and added some tech details, related to our wiki. I've also credited your original page in the end. Maxbgn (talk) 12:55, 28 February 2024 (UTC)

Policy reform proposals

I'm pretty tired of the vague and terribly written policies we have... Since I know you've voiced adamant concern as well, I wanted to bring it up with you. I want to know your opinion on how we should exactly start to make reforms. I can see a couple of issues.

1. The awful wording and lack of specificity of a lot of our existing policies, such as those at WS:WWI. Some of what's said here is said in a single sentence, with conditional platitudes, when really the exceptions should be extrapolated on. For example, we should elaborate on a consistent definition of "text" to use in our policies, because "text" has many different definitions. And "work", "text", and "edition" are often used interchangeably to one another in our discourse (which I admit to doing sometimes myself).
2. Our help pages, and other pages that aren't strictly policy, are often cited as if their policy, meaning that as I think you said something along the lines of before, the differences between our namespaces aren't quite clear and pronounced enough. Maybe we should consider merging some of our help pages into policy so that there are clearer expectations for users, and so we don't have to constantly forget whether something was a policy or just a bit of advice from the Help page. (And IMO, a lot of our help pages contain advices that really ought to be policy.)
3. Our community culture, being quite anarchical and individualistic in nature especially in terms of certain stylistic or structural preferences, encourages a laissez-faire approach to policy application. And while I do think this culture has some merits it also leads to people selectively caring about certain policies and not as much for others. I think we're all guilty of this to some degree to be honest... So how can we determine how far we want laissez-faire to go? It's not entirely clear... And here I am getting into disagreements still because of this very mentality being inconsistently applied.
4. I do believe that we should, at the end of the day, care far more about the integrity of the site than any of its policies, and should be able to override a policy on the fly if it means improving user experience in a meaningful way for example. So it might be beneficial to include something similar to Ignore all rules in our policy documentation.

These are just some casual brainstorms. I was wondering if you gave policy reform any thought recently, and I would be interested in collaborating with you on some proposals, and/or gathering together other collaborators on it. Maybe we can make a WikiProject out of it. SnowyCinema (talk) 01:24, 28 February 2024 (UTC)

Lurker butting in: I'm interested in improving this situation too, and would like to find a way that makes things better without being too jarring. Feel free to nudge me if you get something going. -Pete (talk) 07:09, 28 February 2024 (UTC)

Thanks Pete. Yeah, I agree with that: make things better without being too jarring. Xover (talk) 08:03, 3 March 2024 (UTC)

@SnowyCinema: Sorry for the tardy reply. IRL is kicking my behind lately so anything requiring sustained attention is challenging.

Yes, I agree with all your main points (but reserve the right to disagree on some particulars). We need to improve our policy game, and because we have a lot of years of relative neglect to compensate for, that's going to take time (marathon, not a sprint). And the biggest challenge is that the community is in general not that interested in policy work, and significant subsets view policies as inconveniences and with outright suspicion. No policy reform is going to be successful if we cannot engage the majority of the community in it, and in a way that they at least feel heard if they disagree with the majority opinion on some point. There is also a major major risk in that relative anarchy has reigned for decades, attracting contributors that may hold views of what the site should be that are diametrically opposed and on the extreme ends of whatever spectrum. The only way to satisfy both will be to make policy more general, not more specific, and being specific will have a high risk of driving one side of that issue away.

What I'm trying to say is this will need tact, diplomacy, respect for all viewpoints, and sustained effort over time. Xover (talk) 08:02, 3 March 2024 (UTC)

{{plainlist/m}} spanning pages?

Should spanning with this template also be abandoned as in I did with spanning tables? I am asking because there are an unknown number of pages are spanned before you made me aware of the issue. I am referring to these pages Page:History of Woman Suffrage Volume 4.djvu/1217 — ineuw (talk) 06:45, 1 March 2024 (UTC)

@Ineuw: I am not sure I understand the question, so I am going to try to answer with a little guessing and a little generalisation and then you can hopefully adjust my understanding so I can give a more specific answer.

I never use the dedicated "middle" templates like {{plainlist/m}}, because I have yet to run into a situation where that is actually needed. In all actual cases I have run across it is enough to use the "start" template (i.e. {{plainlist/s}}) in the header. That will sometimes give small divergences in formatting in the Page: namespace, but looks as intended in mainspace when transcluded. Having small formatting glitches in the Page: namespace is ok: it is our internal workbench namespace and what counts is how it looks when transcluded for presentation.

I also do not normally use {{plainlist}} for use cases like your typical book index. For one thing, HTML / wiki list markup across Page: pages is technically very finicky and challenging for the software, and hence for the humans using it. But for another your typical book index neither needs list markup nor is semantically best expressed that way. So my usual approach is to separate each line of the index with one blank line, and each letter group with two blank lines (if the book has extra spaces between the letter groups). If there are hanging indents and similar in play I use those formatting templates in the header/body/footer as required, because those are simple div tags and not list or table markup (lists and tables are html constructs that are very finicky). This will sometimes give a presentation that is not pixel-perfect, but I've yet to find a case where it doesn't give results that are good enough for the purpose. So for all the typical book indexes, which is what your example page looks like, I quite strongly recommend not using any list markup at all. Some blank lines, a {{nop}} here and there, and maybe {{hi/s}}/{{hi/e}} in the header/footer is all you need.

The only time I use {{plainlist}} or other list templates is for something that is very obviously a list in the source. The book's index is arguably a list, but not obviously one, if I can put it that way.

Hopefully that was of some kind of use. Xover (talk) 07:26, 1 March 2024 (UTC)

Thanks for the reply. My concern was in general. I know that tables spanning pages slow down the server. I imagine that this also apply to the plainlist template. I am just curious. — ineuw (talk) 09:35, 2 March 2024 (UTC)

They don't inherently slow down the server, but some of the templates we use for them do cause all sorts of performance problems. And tables and lists in the way they are technically defined (both in HTML and MediaWiki wikimarkup) make them very fragile and finicky when we break them up across pages. For short lists or tables (like a two or three page table of contents) we can usually make it work, but for a potentially multiple many page book's index it is most definitely better to avoid those constructs if at all possible. Xover (talk) 10:15, 2 March 2024 (UTC)

Initially, my concern was how a table broken into two consecutive pages appear in the main namespace, but they match seamlessly and appear continuous. I check the main namespace looking for errors. — ineuw (talk) 10:26, 2 March 2024 (UTC)

Using mw.language.fetchLanguageNames in Module:ISO 639

I've been considering making Module:ISO 639 get language names from mw.language.fetchLanguageNames where possible. Does that seem like a good idea to you, and does the implementation in Module:ISO 639/sandbox look like a reasonable way to do it? —CalendulaAsteraceae (talk • contribs) 02:54, 16 March 2024 (UTC)

@CalendulaAsteraceae: Why does Module:ISO 639/local contain north of 8k language mappings? How many of these are actually used here? How many are likely to ever be used? How many of these (micro)languages even have a written language? Remember that these all get loaded into the hard-limited memory for every invocation of the module, whether they are used or not. Why do we need language codes that MediaWiki doesn't support anyway? We can't get web font support for them, or other software features, so why jump through hoops to just recognize them only on enWS?

Why do we need separate data tables for "local" names and "override" names? Why not simply let local names override upstream names and solve both in one lookup table? That also makes the logic more explicit: right now an "override" is supposed to only override upstream names, but the implementation also overrides local names and local names override upstream names even though they're apparently not supposed to. Having only two sources would make this logic and the code clearer.

Why would you fetch all language names, copy them into a table in your heap, and then look up a single code in it; instead of just looking the code up directly with mw.language.fetchLanguageName(code, 'en')?

Why are you lazy-loading Module:Arguments only in p.ISO_639_name? You're loading 8k of config, so loading Module:Arguments doesn't even show up in the performance profile. And in general, this kind of thing is premature optimization absent a specific real case where it is needed. Just stuff module loads up top where they're expected and simplify the code further down.

You're using Module:Error to handle what is a completely normal and expected situation: a missing argument value. Module:Error throws a low-level exception and unconditionally puts the page into a platform-provided tracking category. Its useful role is to signal that something catastrophic and exceptional has happened and technical admins need to step in immediately. What you're actually dealing with there is a warning to the end user that they have failed to provide some input, and if they do not fix it they will probably not get the result they wanted. It's the difference between "FIRE!" and "Excuse me, sir, I'm sorry to bother you but…". For this use case use Module:Warning, with a tracking category the community can use to fix backlogs if needed, possibly supplemented with Module:If preview to give users an early heads-up before saving.

That all aside, the approach as such seems good, and a definite improvement over the current implementation. I don't have a lot of experience with the Scribunto Language library so I can't give you any specific advice on it, but in general terms it's always better to use upstream functionality wherever possible. Less work for us to maintain, and we can take advantage of upstream improvements, stuff that breaks can be fixed once for everyone that uses it, and so forth. Xover (talk) 09:07, 16 March 2024 (UTC)

Thank you! I've adjusted the code to load Module:Arguments at the top, only load the specific MW language name needed, and use Module:Warning instead of Module:Error.

The reason Module:ISO 639/local contains 8k+ language mappings is that I was getting tired of adding mappings ad-hoc when works showed up in Category:Index pages of works originally in an unknown language. The memory issue is why there are separate "local" and "override" names (I've now made the code only load the local names if needed). I could be argued into merging Module:ISO 639/local and Module:ISO 639/overrides and only loading the names that are actually in use, but my main goal was to reduce maintenance. —CalendulaAsteraceae (talk • contribs) 02:11, 17 March 2024 (UTC)

@SnowyCinema, CalendulaAsteraceae: Try Module:ISO 639/sandbox (specifically 13974731). —Uzume (talk) 07:46, 17 March 2024 (UTC)

Thanks, but that's just the same as hard-coding "en". mw.language.getContentLanguage() returns the wiki's content language, which is hard-coded in LocalSettings.php as English. Xover (talk) 08:05, 17 March 2024 (UTC)

@CalendulaAsteraceae: Module:ISO 639 currently has three entry-points: ISO_639_name() for templates, _ISO_639_name() for other modules, and language_name(). But the latter is not designed as an entry-point in that it does no sanity checking of its inputs. In other words, it is designed as a private function that relies on its calling context to take care of sanity checking and error handling. When Module:Header calls language_name() it bypasses all of the error checking from _ISO_639_name().

In terms of API design, you want to reduce the number of entry points as much as possible so that you reduce the number of places you have to check inputs and to simplify the code in non-entry-point code. You also want to make private functions explicitly private so that clients can see clearly what functions they should not call directly. In a Scribunto context that means making private functions local and not part of the export table (p, the table you return at the end of the module). You can go further and name them with a _ prefix too, but that's not particularly common in Scribunto modules for whatever reason (I sometimes do that anyway, but it's not idiomatic).

If you want to make utility functions available for specialized cases you need to be very explicit about the contract: it is the client's responsibility to ensure valid arguments are passed in. You'll also need to start using stuff like pcall() and try/catch to avoid the standard libraries blowing up. And in this scenario, it also effectively means we'll have to include all the client modules (i.e. Module:Header and all its clients) in the testing matrix any time we make a change.

In this particular case I don't see why Module:Header can't call us through _ISO_639_name() so we can reduce the API surface in Module:ISO 639 to just ISO_639_name() and _ISO_639_name() (and isolate the error checking in the latter). In addition, at a quick glance it looks like while Module:Header calls Module:ISO 639 unconditionally, it is only {{translation header}} that actually uses the name. So we get the overhead for every single page that uses {{header}}, {{process header}}, etc. even if we don't need it there; and errors like this blow up the whole site instead of just a subset of pages isolated to one namespace. Xover (talk) 08:42, 17 March 2024 (UTC)

Pointers for CSS use

I randomly saw that you've been doing some work on https://en.wikisource.org/wiki/Index:Works_of_Sir_John_Suckling.djvu moving the TOC formatting to a stylesheet. I wonder if you have any tips on how I could do something similar for the index to The Strand Magazine? I haven't done anything with CSS for a while, and it would be good to move the formatting away from lots of repetition of the ts template. See Index:The Strand Magazine (Volume 3).djvu for my 'current' (i.e. 12 months ago!) style. Qq1122qq (talk) 13:43, 1 April 2024 (UTC)

@Qq1122qq: There are some tips / tutorial stuff in Help:Page styles. And feel free to ask for help here. It turns out a large proportion of tables of contents are remarkably regular so the reuse potential is pretty good. Xover (talk) 14:05, 1 April 2024 (UTC)

Thank you for the pointer - that looks like a very useful page. Qq1122qq (talk) 14:26, 1 April 2024 (UTC)

@Qq1122qq: Oh, one thing that might be worth keeping in mind… For a multi-volume work it's possible to create redirects from the style pages for vol. 2+ to the style page for vol. 1 so that you get consistent formatting throughout. This sadly requires admin permissions to set up, but do feel free to grab me if you need that. Xover (talk) 16:48, 1 April 2024 (UTC)

A loose end

Hi Xover, I just re-read your comment here, more closely than I did the first time. It seems like my comments came off as hostile or uncooperative, and I can see in hindsight how they would give that impression. I just want to assure you that wasn't my intent. I appreciate the efforts you make to keep things going here. In your comment, you stated that "process stuff matters." My purpose in each of the comments of the discussion was to learn the correct process. With your close, I did finally get the answer I had been seeking, and I specifically appreciate you spelling it out. I didn't intend to cause frustration, and I could have been clearer in my questions and comments. Sorry if I added stress. Pete (talk) 13:18, 2 April 2024 (UTC)

@Peteforsyth: You linked [[Special:Diff|here]], and not a specific diff. SnowyCinema (talk) 13:23, 2 April 2024 (UTC)

@SnowyCinema: Ugh. Fixed now, thanks. -Pete (talk) 13:26, 2 April 2024 (UTC)

@Peteforsyth: If you felt you needed to come here and apologise for something then the most reasonable explanation is that I've expressed myself poorly, given the wrong impression, it's my bad, and I am the one who should apologise. There may be issues on which you and I disagree to such a degree that the tearing out of one's own hair may be an apposite analogy, but I have yet to see any instance where you had any actual cause to apologise for anything. As for the specific comment you linked… Assume I was trying to apologise for dropping the ball on closing the referenced copyright discussion (this one), explaining ways you could nudge things along in such situations (never hesitate to ping me: if I've dropped the ball I appreciate reminders so I can fix it), and why I was being kinda bureaucratic on the process stuff. None of it was intended to express any form of critique, frustration, or similar. Quite the contrary. Xover (talk) 14:01, 2 April 2024 (UTC)

Template Rationalisations

These were some temporary migrations - https://en.wikisource.org/w/index.php?title=Special:WhatLinksHere/Template:Table_class/import&limit=500 , Ultimately this template should be removed entirely, as should {{numbered div}} and related. ShakespeareFan00 (talk) 10:08, 3 April 2024 (UTC)

Thanks for letting me know. Yes, {{table class/import}} in its current form should probably not be used. It's possible some ideas from it can be reused for some other use cases though, it depends on what needs are discovered when the more straightforward cases are dealt with. I'll keep it in mind. Xover (talk) 10:11, 3 April 2024 (UTC)

I've been workiing on deprecating valign but I need to take a break. ShakespeareFan00 (talk) 20:31, 3 April 2024 (UTC)

Unclosed DIV's

Any chance of clearing up some of these?

https://en.wikisource.org/wiki/Special:LintErrors/missing-end-tag?wpNamespaceRestrictions=8&titlecategorysearch=&exactmatch=1&tag=all&template=all

https://en.wikisource.org/wiki/Special:LintErrors/missing-end-tag?wpNamespaceRestrictions=1%0D%0A4%0D%0A5%0D%0A6%0D%0A7%0D%0A0%0D%0A10%0D%0A11%0D%0A12%0D%0A13%0D%0A14%0D%0A15%0D%0A100%0D%0A101%0D%0A102%0D%0A103%0D%0A106%0D%0A107%0D%0A114%0D%0A115%0D%0A710%0D%0A711%0D%0A828%0D%0A829%0D%0A104%0D%0A105&titlecategorysearch=&exactmatch=1&tag=div&template=all

I lack the clout/bits to resolve these ( some of which it might not be possible to repair.) ShakespeareFan00 (talk) 10:42, 5 April 2024 (UTC)

Unclosed span

https://en.wikisource.org/w/index.php?title=Wikisource:Scriptorium/Archives/2020-12&action=edit&lintid=1610524

Typo? ShakespeareFan00 (talk) 10:51, 5 April 2024 (UTC)

Probably. I just threw a /span in there in any case. Xover (talk) 12:01, 5 April 2024 (UTC)

Style rationalisations?

https://en.wikisource.org/w/index.php?search=insource%3A%2Fheadertemplate%2F&title=Special:Search&profile=advanced&fulltext=1&ns0=1&ns1=1&ns2=1&ns3=1&ns4=1&ns5=1&ns6=1&ns7=1&ns8=1&ns9=1&ns10=1&ns11=1&ns12=1&ns13=1&ns14=1&ns15=1&ns100=1&ns101=1&ns102=1&ns103=1&ns104=1&ns105=1&ns106=1&ns107=1&ns114=1&ns115=1&ns710=1&ns711=1&ns828=1&ns829=1&searchToken=5szr1s6lvq2qxyqc6iupa06jh

I've cleared some of the backlog but wanted someone to review..}ShakespeareFan00 (talk) 17:45, 6 April 2024 (UTC)

@ShakespeareFan00: I appreciate your willingness to help, but you've got to stop diving in immediately. I am still working on this, the template isn't done yet, and it's still not certain that it's a workable solution. The effect of you jumping in now—even though that was obviously not your intent—is that my job becomes much more difficult. I get edit conflicts because you've changed pages while I was working on them, trying to get the template to support that use case. You've changed a lot of pages that I otherwise had in my todo list to check for whether the template could work for them, and now I have to find a different way to identify them. And since the reason I hadn't converted them yet was that I wasn't sure yet that it would work there, it means I have to go back and check the pages you edited too.

Please don't take this the wrong way: I very much appreciate all your efforts in general, and your willingness to help out with projects like this. But please don't just jump in to these projects like this. Stop to think about whether you helping out in a given case might end up being a "bull in a china shop" type situation. If you're not sure, it's never wrong to ask before you go wading in. One person working on something alone can keep track of things on their own; but the second you have two or more people involved it is necessary to coordinate.

So, please don't do anything else related to this just now (most especially do not start reverting any of your changes!). Once I am confident this template can be used reliably, if there is still more work to do, I will let you know and tell you what would be most helpful. Xover (talk) 19:07, 6 April 2024 (UTC)

I have other projects so I should not conflict with your efforts now you have asked me not to.

Is the intent to clean out relevant Site.CSS entirely? ShakespeareFan00 (talk) 19:19, 6 April 2024 (UTC)

@ShakespeareFan00: Not completely empty, no. But I want to pare down the number of default Gadgets (each one adds to the size of the startup manifest), and I want to reduce the size of each default Gadget as much as possible, because we pay the cost of these on every single page load. And as it happens this coincides well with the need to find better solutions for some things that are currently global CSS classes. Xover (talk) 19:23, 6 April 2024 (UTC)

Redirected Stylesheet...

A_Dictionary_of_Music_and_Musicians/Lord_of_the_Isles,_The

Did someone forget to change the content model back? ShakespeareFan00 (talk) 20:04, 6 April 2024 (UTC)

@ShakespeareFan00: No, just a race condition: the page was reparsed into cache in the middle of setting up the stylesheet redirects, and hadn't been updated after. A null edit or page purge should fix it. Xover (talk) 20:15, 6 April 2024 (UTC)

Delinting - A strategy..

I'm currently working to remove unmatched <I> in Page: namespace typically resulting from OCR. The objective is to eventually allow for automated conversion of <I>...</I> to '' ... '' or some equivalent {{italic}} template, where needed ShakespeareFan00 (talk) 10:34, 7 April 2024 (UTC) Would you be willing to consider semi-automated conversion of <U>...</U><B>...</B><I>...</I> and <HR>...</HR> tags in content namespaces, once the effort to contain the mismatched ones is completed? ShakespeareFan00 (talk) 10:34, 7 April 2024 (UTC)

I plan to look at those eventually, mainly due to raw HR being problematic. Whether we actually want to convert B and I is less certain. It depends on how and where they are used. These two are somewhat special and it is entirely possible that we may end up just letting them stay, or possibly make some guidelines for when it is appropriate to use them. Xover (talk) 10:38, 7 April 2024 (UTC)

For some simple unmatched examples of <I> in raw:-

• https://public-paws.wmcloud.org/4407/i_pair
• https://public-paws.wmcloud.org/4407/i_space

ShakespeareFan00 (talk) 12:27, 7 April 2024 (UTC)

More stylesheets

There is a lot of rant about my stylesheets becoming "unhooked" from the text I was working on before I was finished.

There is less but more intense rants about basic templates not working, meaning in this case, not displaying for me.

There is a way in my browser that I can see that I have never visited the stylesheet page, but I don't want it to "get fixed" because appearances are deceiving.

Now all of my scripting is doing the exact same thing. The debugging output file stops updating.

Sorry about the rant; but the problems are problems.

Having style problems when I log into worldcat also, but that should not be ranted about here, I suppose.

thoughts about stylesheet migration

The SFan table style guru needs to make canned styles of common combinations, like do-re-mi when they see it on the page. If the table styled page has a three note call that gets used in all of tables for one magazine style then put them together and call it {{ss:do-re-mi}} which then can be expanded and moved (backwards, as it is) into the Main as {{ss:doe-sun-myself}} only using css names not musical theater names, or a be predetermined style collection whose structure is to be considered and determined later.

Build backward. Get another issue of the Journal of Optical and release the tables from the styles used by moving them to the style sheets with the same notation. Get a three note band together for making tables. The Kinks only used two notes very often!! The multi-personalitied SFan is the King of tables here. That two key shorthand for style is very very appealing. Builders and typists. Let the typists build backwards, it is easy, they can do it. The builders show them how to do it and they reassemble backwards built parts into good order; assuring the typists that it will still be the same amount of fun to use.

This should be fun and right now is not fun for me. The not completing things because weird and wrong software problems are occurring is more not fun than discovering the weird and wrong software problems.

final rant

Leave atlantic monthly alone for me to finish. Please. None of that moving the pages around crap like got done at Rackhams ring volume two. Yes, I know I hacked around Billinghursts bf deleter in an audacious way, but I should have been allowed the second volume without that page switching crap. I have done my time with that stuff. No more NNNNNNNNNNNNNNNNNNcu at IA, also. Honestly, those magazines set up will be great to just drop in and do an article with. I was looking forward to meeting up with where it started. So, let me build the magazine backward and you all start to work on table styles to sheets.--RaboKarbakian (talk) 13:58, 7 April 2024 (UTC)

@RaboKarbakian: I have no idea what you're talking about, sorry. If I've stepped on one of your projects then I apologise. If you explain which and how I'd appreciate it.

The only changes I have made to Atlantic Monthly are replacing old auxiliary contents with something new, and only because the old approach is going to stop working. I have no plans to move any pages around. Xover (talk) 15:43, 7 April 2024 (UTC)

I'm no expert on tables or on stylesheets. In checking back I can only find some repairs to italics, (and possibly the addition of a basic TOC) in a single volume of The Atlantic Monthly, which I can't (at present) find changes I've made to stylesheets. Can you clarify which styles have become 'detached'? Can you also provide a list of what you had as 'projects' so that any current delinting efforts aren't duplicated. ShakespeareFan00 (talk) 16:40, 7 April 2024 (UTC)

ShakespeareFan00 all of the color stuff, with the exception of the patent: The Ridgeway book, the Munsell articles. The stylesheet here says it is unvisited by me. Then it quits working, changes don't happen to the text. It seems detatched from the page. Unhooked from each other or the stylesheet being edited by me is not the stylesheet that the page is using, all of a sudden. Page: and styles.css.

In volume 6, {{bc}} did not display. Another one also, I forget which. bc is like a base template here and very useful. No complaint, no red Lua errors, nothing, including text, centered or not. Then I broke the tables there, because I was frustrated. I did not think it would break it, I thought that it would fix it and maybe the style sheet also. And it didn't fix it. I had to settle down to think about it. So, now, I can fix it in like 30 seconds, but there is still that "what happened to the style sheet" part. Sorry.--RaboKarbakian (talk) 20:53, 7 April 2024 (UTC)

Template:AuxBox

I'd used this for Transcription or usernotes. It was forked due to the different use case. If you want to rationalise, I have no objections. ShakespeareFan00 (talk) 21:14, 7 April 2024 (UTC)

Bulk upload request

In the process of scan-backing "Fragment of a Greek Tragedy", I ended up extracting a lot of back issues of The Bromsgrovian from https://www.bromsgrove-schoolarchive.co.uk (file URLs like https://www.bromsgrove-schoolarchive.co.uk/Filename.ashx?tableName=ta_publications&columnName=filename&recordId=112 and they go in order). I don't plan to transcribe them, and I don't really feel like going through the 138 issues published between 1904 and 1928 to check author death years and determine suitability for Commons, but I would like to upload them somewhere so they're more accessible to anyone who does want to work on transcribing them.

If I email you the files, could you use a bot to upload them to Wikisource? The file names follow the pattern The Bromsgrovian, [date], New Series, Volume [volume], Number [number].pdf and if possible I'd like the summaries to be

{{Book
 |Author           =
 |Translator       =
 |Editor           =
 |Illustrator      =
 |Title            =The Bromsgrovian
 |Subtitle         =
 |Series title     =New Series
 |Volume           =Volume [volume], Number [number]
 |Edition          =
 |Publisher        =
 |Printer          =
 |Publication date =[date]
 |City             =Bromsgrove
 |Language         =en
 |Description      ={{en|1=Magazine of Bromsgrove School}}
 |Source           =https://www.bromsgrove-schoolarchive.co.uk
 |Permission       =
 |Image            =
 |Image page       =
 |Pageoverview     =
 |Wikisource       =
 |Homecat          =
 |Other_versions   =
 |ISBN             =
 |LCCN             =
 |OCLC             =
 |References       =
 |Linkback         =
 |Wikidata         =
}}
[[Category:The Bromsgrovian]]

—CalendulaAsteraceae (talk • contribs) 04:04, 12 April 2024 (UTC)

I… don't actually know. I've never done any bulk uploads like that, and thus haven't really looked at what ready-made plumbing there is. I can take a look at some point when I've spare cycles for it. How many uploads are we talking about total? Xover (talk) 12:28, 12 April 2024 (UTC)

138. More than I want to do by hand, but hopefully not too many if there is ready-made plumbing. —CalendulaAsteraceae (talk • contribs) 19:51, 12 April 2024 (UTC)

@CalendulaAsteraceae: Just to give you a status update on this... I've found ready-made plumbing to bulk upload the files, but only with identical file description pages. I've not yet found any sane way to individualize them either at upload or in a batch after the fact. I'll keep looking as time allows. Xover (talk) 08:52, 15 April 2024 (UTC)

@Xover: Thank you! If it looks like it would be too difficult to customize the file description pages, you could skip the volume and date (the data's in the filenames, so it wouldn't be too hard for later users to add that info). —CalendulaAsteraceae (talk • contribs) 15:32, 15 April 2024 (UTC)

It's late for me, so this might be a bad idea, but what about setting |Volume = {{subst:ROOTPAGENAME}} and |Publication date = {{subst:ROOTPAGENAME}} and then running a replacement script to change |Volume = The Bromsgrovian, [date], New Series, Volume [volume], Number [number].pdf to |Volume = Volume [volume], Number [number], and likewise |Publication date = The Bromsgrovian, [date], New Series, Volume [volume], Number [number].pdf to |Publication date = [date]? —CalendulaAsteraceae (talk • contribs) 04:45, 19 April 2024 (UTC)

@CalendulaAsteraceae: Ooooh! Now there's an excellent idea! I'll see if I can make that approach work and let you know. Xover (talk) 05:29, 19 April 2024 (UTC)

Chekhov DjVu

Could you please generate a DjVu file from this IA scan? It will allow me to start scan-backing our translations of his plays. --EncycloPetey (talk) 02:54, 19 April 2024 (UTC)

@EncycloPetey: Index:Plays (1916).djvu. Basic quality control, but nothing in-depth. Xover (talk) 06:42, 20 April 2024 (UTC)

Thanks! --EncycloPetey (talk) 15:33, 20 April 2024 (UTC)

Although IA gives the title as "Plays", the Library of Congress titles it "Plays by Anton Tchekhoff", so I am going with that title. --EncycloPetey (talk) 15:38, 20 April 2024 (UTC)

Not sure I agree with the LoC on that call, but whatever you prefer is fine by me. :) Xover (talk) 16:43, 20 April 2024 (UTC)

Withdrawals

Hey, I just wanted to thank you for your patience explaining best practices around withdrawing a proposal (or not). I feel like I've been taking up a lot of "space" on the boards the last few months, so when something gets resolved I prefer not to take up more of people's time/attention than necessary. But what you said makes sense, I think I've finally got it. In place of a "withdrawal" on the most recent one, I simply added a "keep" !vote. -Pete (talk) 16:27, 19 April 2024 (UTC)

Don't worry about "taking up space". That's rarely an issue at all, and in your case it certainly doesn't apply. If you knew quite how batty I drove the old-timers here when I first became active you definitely wouldn't be worried about stretching my patience. :) The sentiment is appreciated, but you're doing entirely fine. And your willingness to help out with all this maintenance puts you well ahead by any yardstick you care to apply. Xover (talk) 17:17, 19 April 2024 (UTC)