Xover

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)

Special:Diff/14135949

Should have left an edit-summary!, The change here was because apparently border-spacing: <non-zero> does nothing unless border-collapse:separate is also set. The difference isn't structural, but you might want to check if the border spacing specified is actually being applied. This non-application of border-spacing<>0 might also be happpening in other templates. ShakespeareFan00 (talk) 09:35, 27 April 2024 (UTC)

The above was noted when looking into how to migrate away from deprecated table attributes, something that is progressing well. Although I can pause that effort if you have concerns.

ShakespeareFan00 (talk) 09:35, 27 April 2024 (UTC)

These are only used for layout tables, so the correct fix is generally to move away from the table rather than faffing with the detailed CSS. But, anyway, yes, please do always leave an edit summary that explains what you're doing and why you're doing it. Having to guess from the diff is unnecessarily hard. Xover (talk) 09:54, 27 April 2024 (UTC)

Erm. Hang on. You do know the default value for border-collapse is "separate", right? Xover (talk) 09:56, 27 April 2024 (UTC)

Okay , I clearly don't understand something then. ShakespeareFan00 (talk) 09:58, 27 April 2024 (UTC)

I've now reverted a lot my 'modernisation' efforts because I've lost confidence in the edits. Perhaps someone else like yourself can figure out how to modernise the releavant pages to ONE consistent format or class, so other contributors like me are not thrashing around trying to get things consistent? ShakespeareFan00 (talk) 11:28, 27 April 2024 (UTC)

I think the problem is that you're "thrashing around trying to get things consistent". In carpentry the rule to live by is "measure twice, cut once". I think that's probably a good rule of thumb for mass changes here too. And it's usually best to know that there is an actual tangible problem, that is well understood, before trying to implement a "fix". Xover (talk) 11:46, 27 April 2024 (UTC)

Page:EB1922_-_Volume_32.djvu/255

Am I hitting a CSS specficity issue? It's working on ALL the other cells. ShakespeareFan00 (talk) 14:56, 27 April 2024 (UTC)

Which cell? What is the effect you're trying to achieve? What is actually happening instead of what you wanted? Xover (talk) 14:59, 27 April 2024 (UTC)

I was not seeing a bottom border on a cell in the last row. I had another look at the layout and seemingly resolved it. ShakespeareFan00 (talk) 15:05, 27 April 2024 (UTC)

I was trying to replace "rules=cols" with a tablestyle. The table here should also have right aligned figures, but I wasn't sure at present how to implement that in a maintainable way.. ShakespeareFan00 (talk) 15:05, 27 April 2024 (UTC)

I don't have a ready-to-go design for that, but I would have started by trying to add text-align:right for :nth-child columns 2-, and then override the alignment for the header cells. Xover (talk) 15:09, 27 April 2024 (UTC)

The eventual goal is to chip away at - https://en.wikisource.org/w/index.php?title=Special:Search&limit=500&offset=1000&ns0=1&ns1=1&ns4=1&ns5=1&ns6=1&ns7=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&search=insource%3A%2F%28R%7Cr%29%28U%7Cu%29%28L%7Cl%29%28E%7Ce%29%28S%7Cs%29%5C%3D%5C%22cols%2F

So that deprecated table elements are eventually removed. If you have other classes to do it, feel free. ShakespeareFan00 (talk) 15:08, 27 April 2024 (UTC)

border= behaviour for TABLE..

Am I just being intensely dense? According to some information I have seen border should be 0 or 1. However, on English Wikisource im seeing border<>0 values. A quick check seems to suggest that border<>1 and border<>0 values means that 1px borders exist for the cells, BUT it is only the outer border to which the non 1 value is applied?

Can you please document somewhere what the EXACT conversions into CSS are before I change anything else the wrong way? Thanks. ShakespeareFan00 (talk) 15:53, 27 April 2024 (UTC)

It would also be appreciated if someone could check back on my recent conversions and make sure I am actually converting what I think I am converting. :( ShakespeareFan00 (talk) 16:35, 27 April 2024 (UTC)

border= takes an integer and is treated as a pixel value (the npx is implied). But since the attribute is old and deprecated its rendering is browser-specific and does not correspond directly to the CSS table model. Are you sure you're not over-complicating whatever problem it is you're working on? Xover (talk) 18:28, 27 April 2024 (UTC)

I'm not over complicating, It's about making the right conversions. The border=npx seems to only apply the large value to the outside border, not the indvidual cells. This is an important consideration when converting to use CSS because I need to know what value to set up in a selector for a td or th field? ShakespeareFan00 (talk) 18:32, 27 April 2024 (UTC)

Ok, let me simplify: you cannot convert 1:1 from border=1 to CSS. This is why border= is deprecated. Its behaviour is browser-dependant. In order to remove uses of it you will need to look at the relevant table and figure out what it should be, and then style it like that with CSS. Xover (talk) 18:44, 27 April 2024 (UTC)

That's what I figured as well. Hmm.. I'll try and approximate then. ShakespeareFan00 (talk) 18:47, 27 April 2024 (UTC)

Remaining rules=all usages..

https://en.wikisource.org/w/index.php?search=insource%3A%2Frules%5C%3D%5C%22all%2Fi&title=Special:Search&profile=advanced&fulltext=1&ns1=1&ns4=1&ns5=1&ns6=1&ns7=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

3 remaining uses.. Much appreciated if you could took a look at some point, as these are trickey to convert to something sane, by modern CSS standards:) ShakespeareFan00 (talk) 18:52, 30 April 2024 (UTC)

I don't think these are worth it to do anything about (well, except the translation). Xover (talk) 19:04, 30 April 2024 (UTC)

Template:Header, but in idwikisource

So basically, I'm updating the header templates on idwikisource, based on this wiki. There's a problem, and that is the header's position isn't on top. It's only happened in the main namespace, such as id:Undang-Undang Republik Indonesia Nomor 12 Tahun 1956 and id:Amerta: Berkala Arkeologi 3/Bab 1. Weird enough, it's fine on the template namespace itself (id:Templat:Header). How can I fix it? Thanks. Mnam23 (talk) 14:18, 1 May 2024 (UTC)

@Mnam23: My apologies. This came in while I was travelling, and when I got back there was a myriad little crisis that distracted me. I did see your message here when you posted, but I just plain forgot about. My apologies; that was lame of me!

Visiting the two pages you link to do not make it obvious to me what the problem you are describing is. Did you manage to resolve it on your own in the interim? If not then I'll need some more details to be able to make any useful suggestions.

In general though, the {{header}} template on enWS is automatically moved by a default (on for everyone) Gadget (see Help:Layout) that as a side-effect will move the header template to the top of the page if it was not already there. Xover (talk) 06:26, 11 May 2024 (UTC)

@Xover: I think this image would explain. (It has header, but the position isn't there). Mnam23 (talk) 12:07, 11 May 2024 (UTC)

@Mnam23: s:id:Perdjoangan Kita di Lapangan Perburuhan has a header as expected for me, as has s:id:User:Xover/sandbox. Judging by the screenshot you linked you are not seeing that on these pages. I recommend you try viewing these pages while logged out, and if the header shows up then it is almost certainly caused by one of your user scripts or styles. My suggestion would be to try emptying out s:id:Mnam23/vector.css (completely empty) to see if that fixes it. If so then it is something in that stylesheet that is causing the problem. The most likely culprit is one of the selectors that have a display: none; rule. Xover (talk) 16:44, 11 May 2024 (UTC)

@Xover: Nope. It's still happen to me. Check this image. Mnam23 (talk) 07:40, 24 May 2024 (UTC)

Unpaired P tags...

Example:- https://en.wikisource.org/w/index.php?title=Wikisource:Scriptorium/Archives/2017-01&action=edit&lintid=2541493

There has over the lifetime of English Wikisource been what I would term a "convenient misuse" of unpaired P tags as a line-break., or as in the above as a paragraph break in list item (apparently due to mediawiki limitations, The use of multiple colons to thread discussions, whilst not strictly a correct usage, is now endemic wiki usage, and customary practice.). In order to further reduce the amount of missing-tag LintErrrors, can you longer term look into developing a migration approach that is "appropriate" across all namespaces? Various approaches exist, such as replacing them with fully formed <P>...</P> across list/discussion items {{pbr}} {{pbri}}, or simply blank <P>...</P> constructions instead of a single <P>. This needs an administrator to implement in a calm manner, as most of the unpaired P tags are not in "content" namespaces. ShakespeareFan00 (talk) 10:24, 2 May 2024 (UTC)

(Aside: It would also be nice if the remaining High Priority Lint Errors were also resolved, The vast majority of the remaining ones being in User: space as far as I can tell, which I was strongly advised not to attempt 'amatuear' repairs on.)

ShakespeareFan00 (talk) 10:24, 2 May 2024 (UTC)

@Xover: Following on your comments elsewhere - https://en.wikisource.org/wiki/Special:LintErrors/missing-end-tag?wpNamespaceRestrictions=1%0D%0A4%0D%0A5%0D%0A6%0D%0A7%0D%0A9%0D%0A10%0D%0A11%0D%0A12%0D%0A13%0D%0A14%0D%0A15%0D%0A100%0D%0A101%0D%0A102%0D%0A103%0D%0A710%0D%0A711%0D%0A828%0D%0A829&titlecategorysearch=&exactmatch=&tag=div&template=all

Seems to be the bulk of non content namespace lints with any potential rendering impact. I'm not even going to suggest any fixes.. ShakespeareFan00 (talk) 13:41, 6 May 2024 (UTC)

Reminder to vote now to select members of the first U4C

You can find this message translated into additional languages on Meta-wiki. Please help translate to your language

Dear Wikimedian,

You are receiving this message because you previously participated in the UCoC process.

This is a reminder that the voting period for the Universal Code of Conduct Coordinating Committee (U4C) ends on May 9, 2024. Read the information on the voting page on Meta-wiki to learn more about voting and voter eligibility.

The Universal Code of Conduct Coordinating Committee (U4C) is a global group dedicated to providing an equitable and consistent implementation of the UCoC. Community members were invited to submit their applications for the U4C. For more information and the responsibilities of the U4C, please review the U4C Charter.

Please share this message with members of your community so they can participate as well.

On behalf of the UCoC project team,

RamzyM (WMF) 23:10, 2 May 2024 (UTC)

Pellucidar

The publication year is 1962, but the copyright year is 1915. The license is correctly PD-US with the death year of the author, but the revised templates interpret the publication year as the year for copyright, and I have no idea whether there is any way to correct the issue without revising template code. --EncycloPetey (talk) 05:19, 24 May 2024 (UTC)

@EncycloPetey: In the context of the license template, the year argument is the year of first publication because that's what affects the copyright. The year of subsequent editions only becomes relevant if there is copyrightable new matter, in which case the year argument should be the year of first publication for the last published of any copyrightable matter.

This is not a very intuitive usage, but I think with copyright law being what it is there is little alternative. Xover (talk) 05:53, 24 May 2024 (UTC)

That presents a problem if we have multiple editions. But in this case, it's an edition published by Ace Books. Claiming a publication year of 1915 would be nonsensical here because (a) 1915 was the year of first publication, when the story was serialized, in pulp magazines, and (b) Ace Books did not exist in 1915. We need a means to distinguish year of publication from year relevant for copyright. --EncycloPetey (talk) 06:03, 24 May 2024 (UTC)

Maybe just rephrase "because it was published before January 1, 1929" to specify that we're talking about the (latest) year of first publication? —CalendulaAsteraceae (talk • contribs) 04:58, 25 May 2024 (UTC)

@EncycloPetey: I am (as usual) being slow and failing to see the problem. Sorry. Why does using year of first publication create a problem when we have multiple editions? Why is it a problem that the license tag, way down at the bottom of the page, references the date that's relevant for copyright purposes (the {{header}} contains the date relevant for bibliographic purposes)?

Would simply changing the wording that is displayed for these cases to be specifically about first publication (along the lines Calendula suggests) resolve the issue? Xover (talk) 08:22, 25 May 2024 (UTC)

If we use the date of first publication, then all editions have the same date, even if the specific copy was issued decades or centuries later. This will create a lot of confusion for readers looking at versions pages, where all the dates are now the same for all the versions. It will also create a problem for disambiguating versions by maninspace name where the key difference is the date the edition was issued; resulting in editions with one date in the page title (for disambiguation) that is different from the date in the header. How many years of future explanations and minor edit warring would this lead to? --EncycloPetey (talk) 17:24, 25 May 2024 (UTC)

@EncycloPetey: If I've suggested that then I am most definitely confused. Sorry!

What I mean is that in the {{header}}, in the wikipage name, and on versions pages, we use the actual year of publication for the edition of the text we are reproducing. But in the licensing template—because it expresses copyright status and copyright cares about a) the abstract work more than the concrete edition, and b) the year of first publication—we use the year relevant for copyright, which is the year of first publication.

This obviously isn't ideal because you have to use different dates in the header and in the license template, but it is sort of necessary since they express different things (copyright vs. bibliographic domains, essentially).

Did that make more sense, or am I still confused? Xover (talk) 18:44, 25 May 2024 (UTC)

Understood, but in this case, the License template compared itself automagically with the header date, and decided there was an error. And the header documentation offers no explanation of what's going on. Now, I have since determined that PD-US has options for coding that will solve the issue, but other licensing templates, such as PD-old do not. Until the license and header templates are coordinated and co-documented, we're going to get errors generated by template magic. --EncycloPetey (talk) 19:18, 25 May 2024 (UTC)

Oh. Hmm, I think it's beginning to dawn on me. {{PD-US}} is probably not looking at what's been put in {{header}} but rather is pulling the year of publication from the attached Wikidata item when one isn't provided as an argument to the template. I'd need to check the code to be sure, but that seems a likely explanation. I wasn't aware it did that, hence my confusion.

That will, as you say, tend to cause some confusion. I am not entirely sure we can safely use publication dates from Wikidata for license templates, since at least most what is there today are bibliographic dates and not copyright dates. We'd either have to walk up the tree to the work level item to get the date there, or look for a Wikidata property that specifically is for copyright. But then we get into the different licensing policies between projects and other weirdness. Maybe it would be best to just not try to automatically get the date, making specifying one manually mandatory? It may be the data we need is reliably(ish) available at Wikidata, but I'd need to do some digging to be confident about that. @CalendulaAsteraceae: Have you done any research into that when you worked on {{PD-US}}? Xover (talk) 20:08, 25 May 2024 (UTC)

My recent experience is that a lot of our new copies are attached (incorrectly) to work data items instead of edition data items. And Wikidata currently does not distinguish publication date from print date from copyright date. --EncycloPetey (talk) 01:03, 26 May 2024 (UTC)

Indeed, {{PD-US}} is referring to Wikidata, not the header (and I'm not actually sure how it could refer to the header). The relevant code is in Module:License Wikidata.

Wikidata technically has a copyright property, but it's inconsistently applied, doesn't always include the reasoning/jurisdiction, and is IMO generally less useful than just getting the year. (I added an example at Last Poems in case you're curious.) Probably walking up the tree to the work level (if needed) is the way to go. —CalendulaAsteraceae (talk • contribs) 04:22, 26 May 2024 (UTC)

I added code to Module:License Wikidata to get the date from the parent work item if available. I think this should make the dates reliable enough for copyright purposes, given that we can override as needed. I will also say that I've found the automatic year determination and addition to Category:Possible copyright violations helpful for catching cases like The Crane is My Neighbour, which was inappropriately tagged as PD-US even though it was published in 1938. —CalendulaAsteraceae (talk • contribs) 04:45, 27 May 2024 (UTC)

@CalendulaAsteraceae: Awesome. Thanks!

@EncycloPetey: Could you have a look at various cases and see if the behaviour is now more in line with expectations? We'll need to watch this and see if further tweaks are needed. Xover (talk) 05:39, 27 May 2024 (UTC)

If it's pulling the date now from the work data item, then what happens for translations of classical Greek and Latin texts, where the relevant date is the modern date of publication and/or the date of death for the translator? --EncycloPetey (talk) 15:45, 27 May 2024 (UTC)

@EncycloPetey: I'll check. Could you point me to an example where the translator died less than 100 years ago? —CalendulaAsteraceae (talk • contribs) 02:24, 28 May 2024 (UTC)

Examples: The Antigone of Sophocles (1911); Trojan Women (Murray 1905); Sophocles' King Oedipus. --EncycloPetey (talk) 04:30, 28 May 2024 (UTC)

Hmm, interesting. Translations are somewhat unique in the context of copyright since translating something inherently creates a new copyright, unlike most new editions of an extant work. Wikidata's current model doesn't distinguish between a translation and any other form of edition, so we can't detect translations and apply special logic to those.

I am increasingly sceptical that we should be pulling years from Wikidata for the license templates. We want people to actively assess the copyright, not just slap something on there, and autofilling from Wikidata somewhat undermines that. When in addition most of our translations are going to get very incorrect years and we can't even detect that it's happening, I think we may be at a point when the problems outweigh the usefulness.

Or does anybody see any brilliant solutions to this that I'm missing?

What we could consider, is pulling the "copyright status" from Wikidata if not explicitly given. "Copyright status" is a derived property, so it means someone has at some point made some kind of assessment (unlike calculating it from a raw datum like a year). It is also specifically about copyright rather than the year of first publication (bibliographic) so we wouldn't be repurposing data from one domain to another.

Given the poor state of this data on Wikidata I'm not at all sure it'd be worth it, though. Xover (talk) 05:10, 28 May 2024 (UTC)

It would mean pulling multiple copyright status values and combining them to get the right template. And it would still require applying the correct death year based on the latest date from among the author, translator, illustrator, possibly editor, and possibly someone else, and any of those could have multiple persons listed. --EncycloPetey (talk) 14:04, 28 May 2024 (UTC)

No, I don't think it would work to grab all years and try to figure out the right one. If we went down that path it'd have to be trusting the copyright-specific properties already set at Wikidata and then just applying that license directly. See d:Q19092354, where there are two statements for copyright status (P6216). One that says in the jurisdiction United States of America (Q30) the status is public domain (Q19652) as determined by published more than 95 years ago (Q47246828). And one that says that in the jurisdiction countries with 80 years pma or shorter (Q61830521) the status is public domain (Q19652) as determined by 80 years or more after author(s) death (Q29940641).

I am not at all sure this would be a good idea, mind, but that's the approach I see having some chance at having any kind of reasonable accuracy. For items when nobody has set the copyright related properties we should probably just emit an error message asking the user to supply them. Xover (talk) 18:49, 30 May 2024 (UTC)

two djvu to redo?

I have two recent IAUpload creations whose OCR is off by at least one. And, I am having format envy because the fæbot pdfs are larger. At your earliest convenience could you look after File:The Wireless Operator with the U.S. Coast Guard.djvu and File:Jack Heaton, Wireless Operator (Collins, 1919).djvu?

Also, I am used to you being around more!!--RaboKarbakian (talk) 17:51, 7 June 2024 (UTC)

@RaboKarbakian: Both files regenerated and reuploaded. No need for format envy because the file size reduction comes from excessive downsampling and compression (i.e. it reduces quality).

Yeah, I used to have more free time for wiki stuff, but real life is sorta eating up my every spare second lately. Sorry. Xover (talk) 07:25, 9 June 2024 (UTC)

No sorries! Less than 2 days turn around, 3 times the size, and files that tersely and tactically point to the previously filed bug report. Thank you so much! And that real life treats you as well as you treat the wiki.--RaboKarbakian (talk) 10:12, 9 June 2024 (UTC)

OCR again. At you convenience{?}: File:Wireless Telegraphy and Telephony (1908, Massey and Underhill).djvu--RaboKarbakian (talk) 20:43, 21 June 2024 (UTC)

Hamlet

If you have the time, there is one page of Notes (p 155) and seven pages of Appendix (pp 177–183) that I cannot Validate, since I am the person who proofread them. If you can validate those eight pages, then all the end matter will be validated. --EncycloPetey (talk) 23:13, 7 June 2024 (UTC)

A beginner's questions about editing advice:

You reverted one of my formatting revisions last night, with the comment, "Whenever there is a newline involved (or even large amounts of text) you should prefer the block variants (/s + /e) of templates, and serif is (almost) never applied manually (dynamic layouts apply that)", which prompted a fair amount of headscratching, mainly about block variants, but also about typefaces, which is probably the easier subject to begin with.

Serif text

I have gone back and removed the serif template from everywhere that I had specified it in the contents of this book, save possibly the title page, since I foresee that this is likely to be an issue if I do not gain a fuller understanding of the subject first. As a preface, I note that 99% of source texts use exclusively Roman type, even though Gothic (sans-serif) has been widely used for over a century (at least, it appears as a secondary typeface in newspaper headlines from the early twentieth century, though usually not in the body of articles). In fact it's still preferred for nearly all books, magazines, newspapers, and a wide selection of other published items, probably because people prefer its appearance and how readable it is.

Even many online sources prefer Roman type. So it looks odd to render a book written entirely in Roman type—especially when it seems to have been the deliberate and artistic choice of the author and/or publisher, and would be expected in a work due to its age and/or genre—entirely in Gothic type. But the internet being what it is, and Wikisource relying primarily on Gothic type for convenience, nearly everything here does so anyway. Rather than trying to fight the tide, I had thought that perhaps using the serif template for chapter or section headings or poem titles, where the size of the text makes its typeface rather obvious, and accessibility is unlikely to be at issue (these days, even smartphones have a high-enough resolution to where font choice is unlikely to affect readability), would be acceptable, at the cost of nothing more than being perceived as a fussy editor who had not yet come round to the futility of the effort.

On a completely different topic, another editor, whose topic of interest seems to be primarily table of contents formatting, keeps trying to explain to me that things like maximum page width should not be set, because readers will be using different settings, rendering it officious to limit say, the table of contents to something approximating the width of the widest pages in the rest of the book. I can only assume that the same reasoning lies behind the advice not to use the serif template—that typefaces are determined by the reader's device, and nothing we can do as editors will ordinarily affect what they see. This is a shame, if the case, since I doubt more than one in a thousand readers even knows both that this is an option, and how to do it; but if so, then perhaps it is entirely futile to specify that any line of text should be in serif.

But then, would the template serve any useful purpose, if it will automatically be disregarded by reader preferences? If it's not normally disregarded, then isn't it fair to use it for large type, or titles where it's rather conspicuously used in the original text? And is there some archived community discussion I have yet to encounter that goes into the specifics in more detail than I have even considered?

Newlines and block variants

I'm familiar with wiki markup and simple template usage, but HTML/CSS coding and similar topics are a stretch for me. Usually I learn formatting through trial and error, and until recently I had little reason to worry about being reverted for any reason other than that another editor didn't like my changes. But "newline" is a term I don't know that I understand, despite it looking transparent. Do you mean "any time that text is broken into lines", or only when it's typed on separate lines, but not when broken using <br> tags (and, BTW, does it matter whether it's written <br> or <br/> or <br />)?

The text on the page you reverted is using the "fine block" template, which I find puzzling because it's not small text; some of it is small, but the largest part is obviously large text, and the "fine block" template seems to have a standard size that is smaller than the default, though its documentation says that size can be specified using "the appropriate inline template (<span>)", something that is not done on the page in question. So we are back to HTML, or something else like it, which wiki markup and templates have generally spared me having to learn, and I am a bit confused as to why the number of lines involved requires such complex formatting. Obviously I cannot use "(/s +/e)" with any of the font size templates other than "fine block", as they do not seem to have them.

The text on the dedication page gets around the different font sizes in the original, in part by using the "all small caps" template, the advantage of which over simply typing a line of smaller text in all caps eludes me (obviously the purpose in this instance is to vary the text size). But I am trying to figure out the best way to render text that varies in size and weight and alignment from line to line, so that I will not have to worry about messing up page coding, or being reverted due to having done it wrong. And if there is no way to do this using simple markup or templates alone, then is there some kind of tutorial that explains how to do it right? Trial and error are becoming quite laborious, and I am worried that it will all be for nought if someone goes through my attempts to replicate even the approximate appearance of text on pages with a fine-toothed comb. P Aculeius (talk) 13:10, 25 June 2024 (UTC)

@P Aculeius: That's a very well-considered set of questions that deserve a well-considered answer, which I sadly don't have the time for just now. I'll try to get back to it when real life is being less recalcitrant, but for right now it'll have to be the abbreviated version…

In general, typographic detail at the level you are discussing is an artefact of the printing shop, not the author, and our primary goal is to faithfully reproduce the author's intent. There are known cases when we know the author had a hand in this kind of decision, but that's very exceptional. In addition, we do not aim for diplomatic transcriptions: approximate representations are sufficient. And web technology being what it is it is impossible to achieve anything resembling the pixel-perfect control this level of detail implies, and attempting it generally just makes things worse. "Big" and "small" text perceptually depend on the web browser's font size, screen resolution, and browser viewport (window) size. And, finally, we have a gadget that dynamically applies styles based on various sources—you can set it per-page with {{default layout}}, and each user can override this, and turn use of serif fonts on and off, etc.—which does not work if you force serifs with {{serif}}.

All this should be much better documented in our help pages, but sadly we (as a community) are pretty bad at doing so. This stuff is the result of organic trial and error over ~20 years, so there's rarely One Tru Discussion™ that establishes all these various rules. Infuriating and frustrating for the newcomer (trust me, I've been there), but that's where we are.

On block templates… whenever you have non-trivial amounts of text (possibly including other templates and wikimarkup) you should strongly prefer /s+/e templates for the simple reason that they are much much more robust and less prone to mysterious failures in those cases. They also happen to be a lot more readable and easier to understand than a mess of inline templates, and especially when you start adding <br /> into the mix, but those are secondary to the main reason. The short version of why is that the /s+/e variants spit out the necessary start and end html tags independently of one another, but with the inline variants you get MediaWiki template argument parsing involved (sensitive to various non-obvious special characters, has magical rules for whitespace, etc.).

About <br />: it doesn't really matter whether you use <br>, <br/>, or <br />. Although some people care a lot about it there's no real technical reason to do so that's worth fighting about. We may at some point use a bot to normalize these to one variant or another, but generally you can use whichever you prefer. But the use cases where using <br /> is appropriate are somewhat rare. A few title pages and colophons are the main uses, but for everything else you should think carefully before resorting to <br />. I know the impulse, but it's triggered by the default skin's use of increased line-height (1.6x iirc) which makes such text blocs seem unbalanced. It's not, really, and the skin changes these values from time to time, so it's not something to sweat overly much. It's much more important (relatively speaking) to have clear and easily understandable code, and <br /> is the antithesis of that. In particular, inside {{ppoem}} <br /> is a bad idea.

Anyways… this was a bit hasty, so my apologies for that, but I hope it helped some all the same. Do feel free to ask if there's anything I can help with (I complain about being busy irl to excuse my tardiness in replying, not to suggest questions are not welcomed). Xover (talk) 14:00, 25 June 2024 (UTC)

Thank you, that's actually fairly clear and detailed. Especially now that I've spent some time reworking my markup on the affected book from the dedication page forward up to index page 40, and am (I hope) getting the hang of the fine block template, as well as how to fix text size in ppoem for the couplets that precede some of Adams' own verses. My only bothers there are that it looks like there should be more space between the couplets and the poems they precede, but I could just insert a blank line if need be; and I'm not sure there's an ideal weight for the text, as plain looks a bit weaker than the original and boldface looks too heavy. But those are minor quibbles.

As for the serif text, I note that the example I was pointed to when reading about page layouts actually does specify serif for titles. But it also uses a layout template which, although easy enough to understand, says in its documentation that it's now disfavoured (the template, not serif text), and that CSS styles are now preferred. I'm not sure I'm up to learning CSS now, and I'm wary of employing a layout template that's considered outdated. Subsequent chapters in the same book just use the serif template for the titles. So I think perhaps this is acceptable, even though users can toggle between Roman and Gothic views: it looks as though text contained in the serif template remains in serif even if the body text is toggled to sans-serif. But I can understand why this would not be desirable for body text; and it's easy enough to go back and change the titles at some future time, so for now I'll just leave them sans-serif along with the rest of the text.

I hope that my work on this book is improving and generally acceptable so far. Thank you again for your reply, and I look forward to anything you have to add to it in future. P Aculeius (talk) 20:56, 25 June 2024 (UTC)

Running headers (and footers)

I've only just realized that you're the one who created the index and most, if not all of the pages for In Other Words, and proofread them, and now I'm muddying up your work with fussy edits... your patience must be truly formidable!

Earlier pages all placed the title of the book or poem in the header using the {{rh}} running header template; later ones use the {{c}} center template. I've been replacing the latter with running header, but since there's only one thing to include—and it varies in terms of whether it's used and whether it consists of the book title or current poem—I was already wondering why running header was needed, before I realized that the person who just gave me a better understanding of how to use templates is the one who placed the ones I was replacing.

So is there any reason to use running header in this instance, or would it be better converted back to plain center? And if there's no advantage, then what distinguishes it from the running header template consistently used in the footer, which contains only a centered page number? At least that occurs on every page, though I don't know whether it should make a difference.

Meanwhile, based on our previous discussion, I've been using {{c/s}} and {{c/e}} constantly, in some cases replacing {{c|{{foo|bar}}}} that you had made... I really don't want to make a mess of things. Is it more a judgment call based on the complexity of nested templates than a question of one being superior to the other? Sorry to have so many questions... P Aculeius (talk) 00:47, 27 June 2024 (UTC)

Replacing the Illustrator template

Hello. I have noticed you replaced the deprecated {{Illustrator}} template for the built-in parameter "illustrator", which is great. However, when the parameter was used for a specific subpage only and not for other subpages of the work, such as here, then the parameter "section_illustrator" should be usually used. Do you think it could be possible (and not too difficult) to find all other cases to change the parameter? -- Jan Kameníček (talk) 15:46, 1 July 2024 (UTC)

@Jan.Kamenicek: I'm working on this, but it overlaps with a couple of other kinda knotty issues so it's taking some time. Xover (talk) 10:11, 12 July 2024 (UTC)

I'll follow up on this at WS:BR#Replace illustrator header parameter with section_illustrator in subpages of works. Xover (talk) 12:05, 21 July 2024 (UTC)

Portal:Federal_Government_of_the_United_States/Tab1

https://en.wikisource.org/w/index.php?title=Portal:Federal_Government_of_the_United_States/Tab1&action=edit&lintid=3236265

This was showing up as having fostered content , but in looking at it, the only thing I can think of is the <onlyinclude></onlyinclude> which should be ignored by the linter?

I think this is a false positive detection, along with the <section></section> tag issue on many of the other pages detected. ShakespeareFan00 (talk) 07:08, 5 July 2024 (UTC)

It's probably just a false positive, yes. That whole portal should also be redesigned (it's copied over from enWP and doesn't work for enWS) without these pseudo-tabs, so I'm disinclined to spend much time on fixing what's there now. Xover (talk) 10:25, 12 July 2024 (UTC)

Template:Information

I thought this had a box border around it? (It does on Commons). I'd been doing a lot of edits in preperation for "night mode" and wanted a second opinion as to those edits having caused the border to vanish. (I did check the underlying Styles and did not find anything that obviously that could have caused the border to vanish. ShakespeareFan00 (talk) 17:33, 6 July 2024 (UTC)

I just synced the template with Commons, so hopefully this problem should be obviated. —CalendulaAsteraceae (talk • contribs) 15:20, 7 July 2024 (UTC)

Thanks. I have on my todo to reimplement {{book}} and {{information}} from scratch because the Commons versions of these are a pain in the neck and use lots of Commons-specific stuff. Xover (talk) 10:18, 12 July 2024 (UTC)

PPoem

Page:A Jewish Interpretation of the Book of Genesis (Morgenstern, 1919, jewishinterpreta00morg).pdf/338

Is this a bug or am I asking the >>> feature to do too much. ShakespeareFan00 (talk) 19:16, 11 July 2024 (UTC)

@ShakespeareFan00: You're asking too much of default {{ppoem}}. >>> is initially for line numbers and such; so whenever you have longer text there will no longer be room within the right margin and things start looking wonky. You can make it work for these cases but it'll require fiddling with margins etc. in the per-work CSS. I've never been sufficiently hard up to have to do that (it's fiddly and a pain) so I don't have any existing examples to hand. Xover (talk) 10:23, 12 July 2024 (UTC)

Do we need a quotation version of ppoem? ShakespeareFan00 (talk) 18:31, 12 July 2024 (UTC)

Problems with automatic header

While we're on the subject, I may as well inform you of an actual bug in the automatic header (that I didn't bother with because I wasn't going to use the automatic header anymore, and don't have access to fix it myself anyway).

If the Index page has multiple illustrators (like Index:Lange - The Blue Fairy Book.djvu), the automatic header will display this as follows: illustrated by [[Author:H. J. Ford and G. P. Jacomb Hood|H. J. Ford and G. P. Jacomb Hood]]

If you're fixing bugs in the automatic header, this might be one to look into. —Beleg Tâl (talk) 15:46, 19 July 2024 (UTC)

Heh, yeah, that's the one I'm currently looking into which is why I might as well try to fix other stuff while I'm at it. :) Xover (talk) 15:56, 19 July 2024 (UTC)