User talk:Xover/Archives/2024

Please do not post any new comments on this page. This is a discussion archive first created in 2024, although the comments contained were likely posted before and after this date. See current discussion or the archives index.

Antigone DjVu

Would you be able to create a DjVu file from this scan at Hathi? It's a 1911 US publication and US author (who died in 1939), and thus solidly in PD. I've been looking for more translations of Sophocles' plays, and would greatly appreciate any help you can provide. Using a name like "Antigone (Harry)" or "Antigone (1911)" would be sufficient to distinguish the file from other similar ones. --EncycloPetey (talk) 21:21, 2 January 2024 (UTC)

@EncycloPetey: File:The Antigone of Sophocles (1911).djvu Xover (talk) 08:59, 3 January 2024 (UTC)

Copyright violations discussion closure for Threats to the peaceful observance of the bicentennial

Why would this not be PD-US-no notice for the material as published within a PD-USGov work? The discussion only had two participants anyway, you and me, so I don’t think that it should be closed so quickly. By the way, thank you for work in closing up all of the discussions, that page was getting rather unwieldy. TE(æ)A,ea. (talk) 17:27, 6 January 2024 (UTC)

Well, the discussion had been open for well over a year so I'm not sure "so quickly" is the most apt description. :)

This was a call based on the fact that it is a case of private individuals giving prepared statements to a Congressional committee. That the committee is required to keep transcripts of such evidence, or that they choose to print those transcripts "for use of the committee", does not amount to general publication. Apologies for what I now see is a pretty lame closing statement on that. As you say, the page was starting to get out of hand so I guess I can plead haste. Xover (talk) 17:39, 6 January 2024 (UTC)

Völsunga Saga (1888)

Hi,

I have started to validate Index:Völsunga_Saga_(1888).djvu, but as a result am wondering how to deal with eventual transclusion. Right now there appears to be two approaches started. The first appears for the TOC and Title and Introduction. The second appears in the TOC for the rest of the chapters.

The Story of the Volsungs/Introduction

[[The Story of the Volsungs/Introduction]]

Völsunga Saga/Introduction

[[Völsunga Saga/Introduction]]

Since I am basically following your lead, it would be helpful if I could get a model that I could copy for the way you might like the header set up for the chapters of this work.

Thank you for any assistance,

PWidergren (talk) 12:35, 31 December 2023 (UTC)

@PWidergren: Thanks for your contributions. Much appreciated.

This text is one that was added many years ago without being scan-backed. I have used Match & Split to migrate it to the scan at Index:Völsunga Saga (1888).djvu and am now working to actually Proofread it against this scan. Since I am in any case going to need to put in a lot of work on it I am planning on taking the opportunity to correct the title used for the wikipage names to better match the printed title. As such I am going to move the existing pages at The Story of the Volsungs to Völsunga Saga, fix up the subpage names to modern standards and matching the new structure from the printed table of contents, and then update all the transclusions to use automatic headers. But I am planning to finish Proofreading the text first so I can discover any needs for adjustments first (for example, I just found that I needed to tweak the page structure to account for the major section division for the "Songs from the Elder Edda" part of the book).

All of which is to say that for now I would suggest you stick to just Validating the Proofread pages so that there won't be too many cooks in the kitchen to make a mess. Xover (talk) 13:18, 31 December 2023 (UTC)

Thank you for your response. Will do.

PWidergren (talk) 13:26, 31 December 2023 (UTC)

@PWidergren: May I direct your attention to this part of my previous message: … for now I would suggest you stick to just Validating the Proofread pages so that there won't be too many cooks in the kitchen to make a mess.? Xover (talk) 09:55, 10 January 2024 (UTC)

I guess I could just elect to abandon this project. I do not like doing that though.

Too bad that you are hard to work with. I have no idea when you would get around to doing the trancluding yourself.

But I stop work on this volunteer project at this point. Have a good day.

PWidergren (talk) 11:57, 10 January 2024 (UTC)

@PWidergren: I am sorry you find me hard to work. I really try not to be.

However, I think you'll generally find that on this project contributors prefer not to have others wade in and start making big changes in a project they're working on. It's not that they do not appreciate assistance or do not want to collaborate, but a lot of the work we do here is somewhat complex and needs consistency at various levels, both of which are harder to achieve if multiple people start doing parts independently (especially if done without coordinating well the division of labour). It's a matter of the old adage "too many cooks spoil the broth."

The reason I suggested that you focus on Validation (your efforts there being very much appreciated, by the way!) is that that's a very safe division of labour: it conflicts with nothing else, and I have never seen anyone complain about someone Validating pages in the projects they're working on. We also overall have far too few contributors interested in or capable of doing Validation, so our progress there is falling way behind.

Transcluding pages, however, goes to the core structure of a text, and best leads to wasted effort and at worst creates extra work. I am planning to redo the transclusions, move pages, etc. but I am waiting until I have finished Proofreading all the pages for the simple reason that during proofreading I am finding out what the content and structure of the work is and that will inform how I ultimately end up doing the transclusions, how I set up the header templates, and so forth.

In this case that also includes a reassessment of what the best mainspace wikipage name would be for this text, which was something I was planning to ask for your input on. In bibliographic terms (what appears on the title page) the title is "Völsunga Saga" (and hence I've used that in the file name and as the base page in the links in the table of contents), but in the half-title it refers to itself as "The Story of the Volsungs", and while Proofreading the bibliography I noticed that Magnússon himself refers to the 1870 edition as "The Story of the Volsungs and Niblungs". With three entirely different datums as input I was hoping someone with more familiarity with this field might know under what title or short title the work is usually referred to by others to help inform a final decision on what wikipage name to use. The wikipage, of course, need not be identical to the title of the work, but it is often convenient to not have it be more different than needed and at the very least to have it be recognisable as a variant of the title. In any case, since I have not yet settled on the final page structure, to now move pages around or creating a lot of subpages is actually going to create more work compared to waiting until those questions are settled. That was the main reason I suggested I would prefer it if you avoided doing that. Xover (talk) 13:52, 10 January 2024 (UTC)

Thank you for your lengthy response and I understand your concerns. I will finish validating the rest of the work after the transclusion is complete, so that it can be the way you would like it to be.

PWidergren (talk) 14:08, 10 January 2024 (UTC)

Ok, the book should now be fully transcluded. Modulo any errors that may crop up and need fixing, this completes the work I was planning to do on this. Xover (talk) 16:18, 12 January 2024 (UTC)

Page:Nicholas Gray Free Negro Bond.jpg

Currently this has the last remaining content div-span flip, but I'm not sure how to repair it, as it's adding a border to content, I'm not sure that can be done using a span in the same way. ShakespeareFan00 (talk) 09:11, 15 January 2024 (UTC)

Please undelete the introduction of Translation:Mishneh Torah

The introduction has been fully proofread at the Hebrew Wikisource. (Also, I would greatly appreciate if you (or EncycloPetey) can take a look at Page:משנה תורה דפוס ווארשא-ווילנא כרך ראשון 1.pdf/11 and see why it's aligned from right-to-left). Thanks in advance, Sije (talk) 18:26, 20 December 2023 (UTC)

@Sije: The right-to-left text was caused by setting the "Language" field in the Index: page to "he" (Hebrew). I have to admit I had no idea that would cause MediaWiki / Proofread Page to automatically set text-direction: rtl in the styles for Page: pages. I've changed it back to "en" (English) for now.

@EncycloPetey: I am thinking we can undelete all the pages of the existing translation and move them into Sije's user space temporarily while they are working on the translation. Do you agree? Xover (talk) 19:04, 20 December 2023 (UTC)

That should be fine. --EncycloPetey (talk) 19:07, 20 December 2023 (UTC)

@Sije: Apologies for the late response (there was a rather large technical outage yesterday that stole my attention). I have temporarily undeleted all the pages that used to be at Translation:Mishneh Torah and moved them to User:Sije/Mishneh Torah. You can find all of them in the list at Special:PrefixIndex/User:Sije/Mishneh Torah. Feel free to copy what you want for these, but keep in mind that the new translation should followed the published version (i.e. what's in the scan)—including layout, structure, headings, formatting, and so forth—rather than what's in the old translation (or any other divergence). While we don't try for pixel perfect reproductions, the texts we host should be recognizable as the edition from which it is transcribed. Common-sense adaptations are permitted and encouraged, but not so much innovation and novel presentation, if that makes sense?

Also, we don't want the old version sitting around indefinitely in your user space. So while there's no particular hurry (really: work at whatever pace suits you), please do let us know when you are finished with those pages (don't need them any more) or if you decide to give up on the project so that we can delete them again. Xover (talk) 13:08, 21 December 2023 (UTC)

OK, thanks. Sije (talk) 19:23, 21 December 2023 (UTC)

@Sije: Please don't move (or directly transclude) incomplete and "Not proofread" content into mainspace. We don't necessarily need to wait until the whole book is finished before we start putting things into mainspace, but right now all you have are 4 pages none of which are Proofread yet. Work on the translation in the Index:/Page: namespace wikipages until more substantial parts are done. If you need to preview how it looks when transcluded you can do so on your user sandbox (commonly User:Sije/sandbox but you can reuse User:Sije/Scrap or create another user subpage if you prefer).

Regarding the extant pages it is hard to advice meaningfully since I do not read Hebrew, but a few… think of them as "questions to check whether we're the right track", I guess.

First, in the subheading on Page:משנה תורה דפוס ווארשא-ווילנא כרך ראשון 1.pdf/2 I see the translation has "(Psalms 119:6)" which is not obviously present in the original. Is it there and I'm just not able to see it, or is this your own addition? In the latter case it would be considered an annotation, which we do not allow. There is at least one more such in the second paragraph that I can't find in the original text.

Second, there appears to be some kind of headings further down on the page in the original (centered text set off on its own line) that I can't see in the translated text. Have you omitted something here or is it just my lack of ability with Hebrew?

Finally, I see you've put some words in square brackets (a lot of "[it]"). Are these your way of marking a word that you have added but that is not present in the original? Perhaps because the language of the original is old-fashioned, or due to linguistic differences between Hebrew and English? If so then you should probably either omit these entirely, or just insert the word without the square brackets. A translation is never going to be word-for-word exact due to differences between languages, so some such necessary adjustments are within the purview of the translator. Whatever translation you feel best represents the original is fine, and no extra marking is necessary. Adding brackets though, would probably also be considered an annotation. Xover (talk) 20:07, 26 December 2023 (UTC)

1. The original contains many Biblical quotations without citing their sources (where in the Bible they are found). I thought that adding these sources would be considered a "common-sense adaptation". But if they're not allowed then I guess they'll have to be removed.
2. The headings further down on the page are 1. An introduction by Joseph Karo and 2. Karo's commentary to Maimonides' introduction. I think it should be OK for this Wikisource translation to contain the work of Maimonides only, without the lengthy commentaries by Karo and others found through out the scans. (If this is not OK, than I guess we might have to use scans of other editions, such as this 1566 edition (containing the first three "books" of Mishneh Torah) available at Google books.)
3. I will remove the brackets that are not present in the original. Thanks for your guidance, Sije (talk) 20:48, 26 December 2023 (UTC)

   @Sije: No, adding such citations would be an annotation in our parlance, and not permitted. In general, Wikisource transcribes and hosts texts as they were published by a reputable publisher. We don't add commentary, nor remove commentary that was present in that published edition. We don't attempt a pixel-perfect replication of formatting, but we do try to stick as close to it as is possible and reasonable. You'll want to pick an edition that you're mostly happy with as it is, but that you want to make available digitally and to translate.

   I recommend investing some time into finding a scan of good quality for an edition that you're happy with, as that will make the job much easier for you. Google Books can be quite hit and miss in that regard, so I recommend searching the Internet Archive and HathiTrust preferentially. I don't know what their coverage of Hebrew books is (both are US-based, with the bias towards English-language works that implies) but I have usually found them to have more scans and more editions available than Google Books, and both are better about copyright issues and permitting downloads than Google. Xover (talk) 08:01, 27 December 2023 (UTC)

   OK. I searched both Internet Archive and HathiTrust, and I think I'll stick with the current scan and try to translate Joseph Karo's introduction and commentaries, although that means that I have much more work to do than I thought. Sije (talk) 20:32, 27 December 2023 (UTC)

So far I have completed and proofread three pages, comprising the Introduction. Is there a minimum amount of proofread pages needed before they can be moved into mainspace? Sije (talk) 19:38, 19 January 2024 (UTC)

@Sije: My apologies, I missed this question. There's no particular limit, but just looking now, since November you've done three pages out of 381 and at that rate the work won't be complete until 2045 some time. We don't want incomplete texts sitting in our main presentation spaces indefinitely, which is why I'm waiting for enough of the work to be completed that what remains seems likely to be completed in a reasonable amount of time.

But you really shouldn't stress about transcluding to mainspace. In the Index: and Page: namespaces you can take all the time you need, and if you want to see how it looks when transcluded you can transclude to a sandbox in your User: space. Xover (talk) 06:43, 26 January 2024 (UTC)

Thanks for your response. I think I understand what you're saying that we don't want incomplete texts sitting in the mainspace. But I was thinking that since the "Introduction" is complete, at least the "Introduction" should be allowed to be moved to mainspace. Sincerely, Sije (talk) 20:21, 26 January 2024 (UTC)

Can u unlock this page

Special:MobileDiff/9813068 Education for All Thai People (talk) 00:28, 17 January 2024 (UTC)

@Education for All Thai People: Are you trying to reinstate an external scan link that was determined to be under copyright? This kind of reversion can't be done without community consensus anyway. You should try bringing that up at the Scriptorium or our copyright discussion page before doing this. Thanks. PseudoSkull (talk) 00:55, 17 January 2024 (UTC)

Special:Contributions/G(x) Education for All Thai People (talk) 05:14, 17 January 2024 (UTC)

@Education for All Thai People: Wikisource is not for promoting causes or a particular person. Xover (talk) 07:08, 17 January 2024 (UTC)

He is Thai education reformer who founded schools for 4.35 millions Thai children from poor families in remote areas.

Today his policies was reversed and Thai children had to ask for food on children day.

Then his speech and ideas was not deleted for copyright reasons but for advertising. Education for All Thai People (talk) 11:28, 17 January 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)

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)

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)

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)

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)

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

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)

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)