User talk:Inductiveload/Archives/2021

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

The Great Gatsby questions

I am proofreading and validating pages from The Great Gatsby scanned file (the images). Should the punctuation and spelling be altered, based off the scanned images? Windywendi (talk) 00:33, 2 January 2021 (UTC)

@Windywendi: yes, the spelling and punctuation should match the scan. This includes reproducing typographical errors, which you can mark with {{SIC}} if you want. Inductiveloadtalk/contribs 00:46, 2 January 2021 (UTC)


I downloaded this skin called DarkVector: User:PseudoSkull/vector.css. It's pretty cool and I implemented it to help me not get bad eyesight in 20 years of proofreading every day for Wikisource. It mostly works, but there are a few things it leaves the same, such as "User page" and "Discussion", "Read", "Edit", "History" etc. Also, the search bar is still white.

Any chance you could poke at the CSS for me and possibly fix these minor issues? Please and thank you! PseudoSkull (talk) 07:44, 2 January 2021 (UTC)


If you verify here (per usual process) that it was indeed you who joined the Discord server just now, I can make you an admin. PseudoSkull (talk) 21:26, 7 January 2021 (UTC)

Yep, that was me. Inductiveloadtalk/contribs 10:13, 8 January 2021 (UTC)

Cleanup user css/js

Could you nuke User:Alexlur/common.css to get it off the broken redirects list? Dangling redirect created when renaming a user, that isn't active on enWS. --Xover (talk) 14:54, 8 January 2021 (UTC)

Kaboom,   Done Inductiveloadtalk/contribs 14:59, 8 January 2021 (UTC)

Suggest watchlist message re tag marking

Getting lots of hits on your markup filter. Would you please consider doing a Watchlist message to alert people so they are able to modify their editing behaviour, rather than just progress with edits unchanged. Noting that I got a throttle message from the system due to that filter. Thanks. — billinghurst sDrewth 12:40, 10 January 2021 (UTC)

Yes, I will write some proper documentation for this. I have also moved Mediawiki:Tag-deprecated markup and Mediawiki:Tag-deprecated markup-description in response to the changed tag name.
I'm not sure what you mean by a throttle message? There are only a few dozen hits per day on the tag. Inductiveloadtalk/contribs 15:05, 10 January 2021 (UTC)
Abusefilter is telling me through Notifications said Abuse filter 41 you recently edited was throttled. so presumably too many edits were being checked and it was sucking resources (noting that I didn't check its stats at the time, probably should have). This is partly why I put some of the new top parts to lessen what it checks, and maybe I should exclude bots too. — billinghurst sDrewth 21:49, 10 January 2021 (UTC)
Weird, I have never seen such a message. When does that message show itself?
Ideally, this wouldn't need a filter at all and we could just use Special:LintErrors, but phab:T173944 isn't done yet (plus at least in RC we can see where such markup is being actively added). Inductiveloadtalk/contribs 23:25, 10 January 2021 (UTC)
First time that I have seen it, probably due my being trained (beaten!) WAY BACK to write tighter eliminating components at the beginning of a filter. To note that I have now excluded bots from the filter, and hazarding a guess that it will have been a bot editing somewhere that will have been the trigger; noting though there is no exact time nor greater precision on where the issue occurred. Apologies for not consulting about the term change from "bad" to "deprecated", just could see the confusion starting, and it is my experience that complaints will continue with connotative usage. Whitelist and blacklists will be renamed due to negative connotations of the colour.

May wish to note anecdotal feedback in User talk:廣九直通車#Template:Center about other WSes, let alone other wikis. — billinghurst sDrewth 01:44, 11 January 2021 (UTC)

We should probably look at our introductory help pages like Wikisource:For Wikipedians and the like to talk about html tags being deprecated and to utilise css styles, preferably through existing templates. — billinghurst sDrewth 02:13, 11 January 2021 (UTC)

Philosophical Transactions/Volume 50

Hi. I have noticed that you have been working with the template {{TOC begin}} recently. At the same time the TOC at Philosophical Transactions/Volume 50 got jumbled for some reason. Is it possible that it has been caused by the changes in the template? --Jan Kameníček (talk) 22:22, 10 January 2021 (UTC)

@Jan.Kamenicek: Looks like this is because the last two pages of the TOC don't use table markup, and there was no {{TOC end}} after the table-like portion at the end of Page:Philosophical Transactions - Volume 050, part 1.djvu/17 (well, there was, but it was in the footer). I don't think this would have been related to whitespace between the templates. Inductiveloadtalk/contribs 23:19, 10 January 2021 (UTC)
Ah, I see. The TOC was originally designed in a different way, but then somebody started redesigning it using this template, but left it in the half of the way. (I personally prefer the previous version anyway). --Jan Kameníček (talk) 23:22, 10 January 2021 (UTC)
And thanks for finding the problem! --Jan Kameníček (talk) 23:23, 10 January 2021 (UTC)

Ready for export?

Hi. I have noticed that you sometimes check works whether they are ready for export. May I ask you to have a look at R. U. R. (Rossum's Universal Robots)? It is not necessary, only if you have time… Thanks very much. --Jan Kameníček (talk) 11:14, 12 January 2021 (UTC)

@Jan.Kamenicek: Sure! So a quick check produces a few (small) issues:
  • Put page breaks after images to prevent the following content starting halfway down the page. I know we had trouble before where there were widows before a title, but for an image, this is unlikely, and it's more likely you'll drag half of a title on the previous page. For example: Special:Diff/10831082
    • I think the smaller images in Acts I and II are OK as they are, since the size works well with surrounding text.
  • The {{block center}} should not be specified in px. On an e-reader, the display might be over 1000 pixels across (mine is 1072), but the font size is very large in term of pixels (a visually impaired user may have a screen only 10 or 15em across!), so you restrict things unnecessarily. Better is to specify the layout in terms of em. Browsers usually (unless the user configures it differently, e.g. for accessibility) generally have an em size around 16px, so your 420px here is about 28em. Which looks about the same in the browser, but looks better on the ereader (the e-reader screen is <30em, so it is effectively 100%).



  • The body of the text renders very well, and the sections all seem to be present. Inductiveloadtalk/contribs 12:02, 12 January 2021 (UTC)
Thanks very much, I will try to keep this advice in my mind for other works too. I can see that you have corrected the issues mentioned above, or is there anything left? --Jan Kameníček (talk) 14:29, 12 January 2021 (UTC)
Yes, I think it's pretty much sorted now. I'll let you add the category! :-) Inductiveloadtalk/contribs 15:14, 12 January 2021 (UTC)

Right aligned captions...

This worked, but I'd feel happier with a templated solution moving forward, so that if the HTML/CSS required ever changed I don't have to change a vast number of Page: s . ShakespeareFan00 (talk) 15:43, 21 January 2021 (UTC)

@ShakespeareFan00: OK so there were some nasty left-overs from the previous {{FI}} implementation. Now it should be fine to use divs in there. The problem was it was trying to put a <div> (the {{center}}) in a <p>, and that's not cool. Now the caption is just a div. Not sure what that supposed to be a workaround for, but it looks long fixed (and the markup is way simpler now anyway). Inductiveloadtalk/contribs 16:42, 21 January 2021 (UTC)


I'm curious what the reasoning is for this change: [1] --EncycloPetey (talk) 00:24, 22 January 2021 (UTC)

@EncycloPetey: I was reviewing it for export. Firstly, align="center" is obsolete HTML and is currently (due to a bug, as it turns out) exporting incorrectly (but this needs to be fixed "eventually" anyway), and while I was there I changed it over to some templates which apply CSS that was previously omitted. For example, the cells were not correctly vertically aligned for small screens (should be left two columns top, right column bottom), and the last column can wrap (sometimes even in-between the 1 and 3 of 135!) if you don't set white-space:nowrap;.
Furthermore, using constructs such as {{gap}} at the end of a cell line to attempt to force a padding is also misguided, as it will not work when the line wraps (and the longest line always wraps first). The better thing to do is set a size—using text relative units like "em", never "px"—that cap the width at a certain point that gives a suitable gap (in this case, 25em looks "OK" to me, perhaps it may feel it a little wide?) and allow the built-in {{TOC begin}} style to apply a default max-width:100% to prevent overspill on narrow screens, while still allowing to close the gap and not waste space if needed (remembering that a mobile or vision-impaired device may only have 10–15em of width in total).
The dots are just arrant frippery of course, but since I've fixed (most of?) the templates to not export the dots, they aren't causing the exporting havoc that they used to (though the markup is still "not ideal", it's not actively harmful anymore). If you're against them, s/2out/2/g will sort it out for you. Inductiveloadtalk/contribs 00:51, 22 January 2021 (UTC)
Thanks for the explanation. I may ask more questions later, since I hope (when I may have time in a few months) to go back through a lot of my older contributions, and Featured Texts, to ensure they are fully formatted for downloads. --EncycloPetey (talk) 19:21, 23 January 2021 (UTC)
I've written some guidance at Help:Preparing for export with some dos, don'ts and known issues. It's not yet complete (notably for TOCs), because I've been trying to address some of the issues at source rather than advising workarounds (for example, dotted TOCs are much less of an issue than they used to be). Please let me know if 1) I break anything somehow, or 2) Help:Preparing for export is too vague on something or 3) you would like an opinion on something (there's also {{export to check}} you can use to ask for a once-over). Inductiveloadtalk/contribs 20:38, 23 January 2021 (UTC)

Context is King

T272704's task description needs a few "when exporting" and similar phrases sprinkled into it. The people working on ws-export will infer the context, but everyone else will be left scratching their heads. :) --Xover (talk) 12:53, 22 January 2021 (UTC)


BTW, while I remember: WS:S#Update to NopInserter Gadget. Current version at User:Xover/Gadget-NopInserter.js with some very minor additional changes. There's probably a couple more bells and whistles that could be added if anybody cared, but just fixing the bug is the main thing. --Xover (talk) 12:55, 29 January 2021 (UTC)

  Done I made the change, should take effect once the gadget caches cycle. Inductiveloadtalk/contribs 13:39, 29 January 2021 (UTC)


Hi, I found British White Paper of Palestine 1939 which isn't linked to a source. There is File:1939 White Paper cmd 6019.djvu. Is this one you could fix please? DuncanHill (talk) 18:52, 29 January 2021 (UTC)

@DuncanHill: I created Index:1939 White Paper cmd 6019.djvu. The text is actually slightly different (numbers and references). Inductiveloadtalk/contribs 20:24, 29 January 2021 (UTC)
Also, see User:Inductiveload/Sandbox/PP, which is something of a work-in-progress. It doesn't reach up to the 1930s, but there may be something there of interest to you. The best resource listed is, which has tons of Google Books links. You can easily import them from Google to the Internet Archive with and from there, let me know and I can more easily upload the volumes to Wikisource (more easily than directly from Google). Inductiveloadtalk/contribs 21:29, 29 January 2021 (UTC)

a plainlist question

What is the proper format for the first line of this page?— Ineuw (talk) 22:04, 28 January 2021 (UTC)

I think you can just add <noinclude>*</noinclude> to the first line to fake a new list item. You don't get the "mid" indent, but I suppose it might be possible to fix in CSS with {{plainlist/m}} if it's critical {{plainlist/m}} can be used instead of {{plainlist/s}} to suppress the hanging indent on the first page (it won't make any difference in mainspace). Also note that apparently leaving blank line splits the list up into 'n' lists of a single item each. @PseudoSkull: has been doing something similar recently, BTW. Inductiveloadtalk/contribs 22:11, 28 January 2021 (UTC)
{{plainlist/m}} doesn't work, but don't fret it. I usually move the dangling paragraph end to the previous page, but here I am facing with "dangling" paragraphs 2-3 pages long. I don't think that merging them in one page is the right think to do.
I also tried all the other hanging indent templates but use tables mostly because all have this problem. — Ineuw (talk) 03:39, 29 January 2021 (UTC)
It does work, but the first line still needs to be a list item in the Page namespace to receive the CSS. Use <noinclude>*</noinclude> to do that. Inductiveloadtalk/contribs 13:38, 29 January 2021 (UTC)
Many thanks. Everything is working well. I checked the results in the main namespace. There is one exception to {{plainlist/m}}. It cannot be used for a paragraph which is joined by {{hws}} & {{hwe}}. This breaks the paragraph in the main namespace, so I use {{plainlist/s}}. Also, I do not enclose the list item (*). It does not affect the main namespace display.— Ineuw (talk) 13:54, 29 January 2021 (UTC)
You shouldn't need {{hws}} and {{hwe}} anymore. Even with it, it seems to work: History_of_Woman_Suffrage/Volume_5/Index#pageindex_804. Inductiveloadtalk/contribs 13:57, 29 January 2021 (UTC)
Thanks again. I tested hyphenations as well without the template, and it works. I noticed that when using {{plainlist/m}}, it no longer indents the page namespace but it displays correctly in the main namespace.— Ineuw (talk) 18:42, 31 January 2021 (UTC)
@Ineuw: abracadabra! My bad - I left a sandbox stylesheet in the template so it worked fine...until I stomped in the sandbox. Inductiveloadtalk/contribs 19:20, 31 January 2021 (UTC)
Thanks again.— Ineuw (talk) 00:33, 1 February 2021 (UTC)

Template that isn't printready

I will leave Template:Blife-Plate page with you, as I tidy other aspects of the work. It has some lovely images and it would be a waste to not have that one set for viewing. — billinghurst sDrewth 21:31, 1 February 2021 (UTC)

@Billinghust: I'll see what I can do. It'll need a bit of care to strike a balance between nice images in export, filesize and so on. Inductiveloadtalk/contribs 09:20, 10 February 2021 (UTC)
And why do you think that I put it in front of someone competent, and not had a go at it myself. I have to go back and look at a whole lot of stuff I have done over so many years. Think that there is some clear POTM stuff that we did in the early-mid 2010s where we looked at works with image and we set them all with 500/600px widths. <shrug> — billinghurst sDrewth 22:33, 10 February 2021 (UTC)
500/600px can be OK, but they might poke out of a Layout 2. There is CSS wrangling with max-width:100%; done to avoid really bad things happening on export (and in the mobile view). Things are very slowly beginning to work by default. :-) Inductiveloadtalk/contribs 22:40, 10 February 2021 (UTC)

adding enWS page link to the query


SELECT ?item ?label WHERE {
  ?item wdt:P1433 wd:Q19084840.
  MINUS { ?item wdt:P921 [] } .
  SERVICE wikibase:label {
    bd:serviceParam wikibase:language "en".
    ?item rdfs:label ?label.

Go to query page

could you add something to provide the interwiki enWS link, so we can just click open the page? Thanks. — billinghurst sDrewth 01:48, 10 February 2021 (UTC)

@Billinghurst: Here you go:
SELECT ?item ?label ?article ?page_titleWS WHERE {
  ?item wdt:P1433 wd:Q19084840.
  MINUS { ?item wdt:P921 _:b7. }
    ?article schema:about ?item;
      schema:isPartOf <>;
      schema:name ?page_titleWS.
  SERVICE wikibase:label {
    bd:serviceParam wikibase:language "en".
    ?item rdfs:label ?label.

Go to query page

  Inductiveloadtalk/contribs 09:13, 10 February 2021 (UTC)


!important should be reserved for user stylesheets. Do we really need (need) it in site styles? It makes it effectively impossible for a user to override, both in on-wiki user styles and in UA styles. --Xover (talk) 14:09, 10 February 2021 (UTC)

@Xover: I thought we did, but the same effect can be achieved with being more specific by adding .minerva__tab-container. Inductiveloadtalk/contribs 14:41, 10 February 2021 (UTC)

Headers and footnotes

Thanks for the welcome message. I have two early questions. The first is a simple one, on the page headers. The book that I have started transcribing has a header text that alternates format between the odd and even-numbered pages, so

The Voyage of Italy.  Part I.


Part I.  The Voyage of Italy.

Can I use the first form throughout, or should I alternate them as the original does?

Second, much more interesting, is on footnotes. I've read the guidance, but I'm not sure if the footnotes are only to duplicate footnote texts that are already in the source text, or whether they can include new explanatory notes by the transcriber. In researching some of the words/ places/ persons mentioned, I would be able to add a footnote to give the current name, or a clarification, or to note the correct spelling to an old form or an original typo. Eg: the text mentions "goistre" (for "goitre") and a "Monsieur Esselin" (actually fr:Louis Hesselin, intendant des plaisirs du roi, 1600-1662). By adding the correct/ modern text in the footnote, at least makes the text searchable. Is this something that can be done? Scarabocchio (talk) 15:05, 11 February 2021 (UTC)

@Scarabocchio: re the running headers, we do put them the right way around. There is a gadget to help you: Help:Gadget-RunningHeader, or there are template that auto-flip the side based on the page number. In either case, you need to take care of the section name change. @PseudoSkull: has a bot for this, perhaps they can help (then you can just leave them out and bot them in later - honestly, doing it manually is a bit of a waste of human life IMO).
Re the footnotes: these are considered WS:Annotations, and generally speaking, we don't put them in. However, it is allowed to link to authors and works at Wikisource, so the names are easy, and a very small number of links to Wiktionary for really odd words (like "goistre") are also fine, but often the word isn't at Wiktionary. Again, PseudoSkull can help you there, he's a Wikitionary person too. We do have {{User annotation}} which you use to mark your own, more detailed, annotations in footnotes. I don't find the concept objectionable at all (it's decent value-add to me), but it would be worth asking for clarification on the WS:Scriptorium, since that's probably not a universal opinion. Inductiveloadtalk/contribs 15:29, 11 February 2021 (UTC)
@InductiveLoad: Many thanks. On the running header, the text requires a three part header: <pageno>+"Voyage of Italy"+"Part I", or the alternate "Part I"+"Voyage of Italy"+<pageno>. The examples at Help:Gadget-RunningHeader show it working with a two-part header. Can it work with three parts?
The guidance in WS:Annotations implies that an original, unannotated version should exist before any annotations are added. I'll carry on transcribing just the base text for a while, keeping my own annotations separate, to confirm that I am going to carry on working here. Scarabocchio (talk) 16:22, 11 February 2021 (UTC)
@Scarabocchio: it should work with three parts as well (let me know if it doesn't, that's a bug). Inductiveloadtalk/contribs 18:55, 11 February 2021 (UTC)

DIV span swaps...

I got this down to under a page, but the remaining reported swaps require someone with more expertise to resolve.

Once these are resolved, quite a few of the remaining "DIV span swaps" in main-space are down to the REF wrapping issue which is a known issue.

I am also reverting some of my changes in respect of Index:Beowulf_(Wyatt).djvu made previously to allow someone with more expertise to come up with a stable long term solution, because the current {{lang block}} doesn't format consistently for this work. ShakespeareFan00 (talk) 10:21, 12 February 2021 (UTC)



You might also need to check for the situation of {{lsp||Text to use default spaci|ng}} in the template logic.

See User:ShakespeareFan00/foo/testcases and the template code called, for potential ideas on how to handle this very robustly.

Generally the required output for cases of @@absent@@ and @@empty@@ will be the same in many instances, though. ShakespeareFan00 (talk) 22:14, 13 February 2021 (UTC)

@ShakespeareFan00: Does it not work?


* {{lsp||Text to use default spaci|ng}}
* {{lsp|1=|2=Text to use default spaci|3=ng}}
* {{lsp|0.15em|Text to use default spaci|ng}}
  • Text to use default spacing
  • Text to use default spacing
  • Text to use default spacing
Looks the same to me. Parameter 1 doesn't care about param 3 being present or not? Smart logic to allow {{lsp|Text to use default spaci|ng}} and notice that parameter 1 is not a valid CSS size is technically possible, but probably more confusing that just allowing a blank parameter.
My plan is to work to remove the custom spacing from {{sp}} and short-cut that to be {{lsp||{{{1}}}|{{{2|}}}}}, so it can be used for the default case and get the "un-spaced tail" capability. Inductiveloadtalk/contribs 22:21, 13 February 2021 (UTC)
For me test case1 in your examples looked slightly different, I am thinking that may be a cache issue. ShakespeareFan00 (talk) 22:31, 13 February 2021 (UTC)
Aside, There's not an easy mechanism to trap for px vs em based values is there? I seem to recall you stating elsewhere that px values in templates were deprecated in favour of em based ones which scale better for mobile devices. ShakespeareFan00 (talk) 22:31, 13 February 2021 (UTC)
@ShakespeareFan00: There's {{CSS unit}} which you can use with a #switch or #ifeq to catch naughty px values. {{AuxTOC}} currently catches them and adds Category:Pages_using_pixel_widths. 287 sinners right now.
Do you remember the name of the enWP tool that can search through all template parameters? Inductiveloadtalk/contribs 22:35, 13 February 2021 (UTC)
I don't. Sorry. ShakespeareFan00 (talk) 23:04, 13 February 2021 (UTC)
In case you wanted to focus your bot on something specific - was all the Page: namespace instances. As many of these will be transcluded, clearing these first should reduce the main list a bit? ShakespeareFan00 (talk) 10:19, 14 February 2021 (UTC)

Right-aligned header

Hi. Is it necessary to right-align the header? Imo it does not look nice. --Jan Kameníček (talk) 15:16, 17 February 2021 (UTC)

@Jan.Kamenicek: It was already right-aligned in the Site CSS (look for .gen_header_forelink). The only place it was not right aligned was on mobile (which didn't matter much because previously it was crushed into 20% width, which is very narrow on a mobile screen). Inductiveloadtalk/contribs 15:34, 17 February 2021 (UTC)
Maybe it is cause by something different, but up to now the headers of author pages were centered, while today the names of authors and their dates appear much more to the right, see e. g. František Lützow or any other author page. --Jan Kameníček (talk) 16:01, 17 February 2021 (UTC)
@Jan.Kamenicek: oh, I see. That actually was a different thing, not the alignment. I've gone back to hardcoding the widths on wide screens to 20:60:20, and only do "free width" on small screens after wrapping. Thanks for the heads up :-) Inductiveloadtalk/contribs 16:11, 17 February 2021 (UTC)

Footer (slightly) borked

I'm seeing the footer missing the back/forward arrows, and its sizing is a hair off (too wide on the right). It probably needs adjusting after your changes to the markup of the {{header}}. Doesn't look like it's broken enough that most people will notice, so you can probably just stash it on the todo until your header modifications are stable.

PS. I'm giddy to see the header getting cleaned up! --Xover (talk) 17:08, 17 February 2021 (UTC)

@Xover: I've added the arrows back in, they're no longer in the #headerprevious/next element so they weren't being picked up.
I don't think the width has been affected by what I did. The header uses a fixed 20:40:20 width ratio (it always did, the new changes should only kick in on small screens). The footer uses a float method, much like {{rh}}, which means that the central "cell" might well not be centred if the two sides aren't the same width.
I might try a flexbox approach for the footer too at some point.
Glad you like it so far. Module:Header is slowly accreting functions and I don't think it's exploding anywhere. Inductiveloadtalk/contribs 17:24, 17 February 2021 (UTC)
Given the arcane mess it was, the changes have been remarkably unexplody, yes. Very nicely done! --Xover (talk) 17:27, 17 February 2021 (UTC)
Hmm. Looking closer I see the various horizontal boxes all have "ragged" right edges. Probably worth looking into. Eventually. --Xover (talk) 18:41, 17 February 2021 (UTC)
@Xover: Which ones? Is it a new thing? Inductiveloadtalk/contribs 18:44, 17 February 2021 (UTC)
Not sure. Never noticed before, but I'm inclined to think that's just because I haven't really looked that close until the recent changes. I may be being fooled by the sister project links in the notes field (I'll have to throw up some grid lines to be sure). The footer is off by half an em or something relative to the categories box. And eyeballing it on one page the header looked like it was also off by a similar amount, but now you ask I'm no longer sure. --Xover (talk) 19:11, 17 February 2021 (UTC)
Hmm, I have noticed that before, but never investigated. Looks like a stray 100% width in Mediawiki:Gadget-Site.css for .footertemplate. I think this'll fix it.
The header looks in-line to me, but the plain sister is inset a bit within the notes field (because the plain sister has 0.5ex of margin on all sides). The shortcuts box doesn't, so I think just removing the right-side margin will line things up better. Inductiveloadtalk/contribs 19:21, 17 February 2021 (UTC)
Yeah, that did the trick. --Xover (talk) 20:31, 17 February 2021 (UTC)

Missing controls in index_preview

Hi. Added mw.loader.load('//');. I see the thumbnail of a single page but the said controls do not show anywhere in the frame.— Ineuw (talk) 02:40, 19 February 2021 (UTC)

This is the display. What could I be doing wrong? — Ineuw (talk) 05:38, 19 February 2021 (UTC)

@Ineuw: For the moment, the controls only appear when the page does not already exist. Adding them requires some more UI logic to ask the user if they're sure and if they want to replace/append to existing content. Inductiveloadtalk/contribs 09:44, 19 February 2021 (UTC)
Got it, Thanks.— Ineuw (talk) 16:23, 19 February 2021 (UTC)
I hope you don't mind my testing the script and uploading screenshots. I clicked twice on the same page, with a different control. Could not escape from my error and the tab froze, but not the browser (Firefox). — Ineuw (talk) 17:02, 19 February 2021 (UTC)
Weird, that works for for me. I'll keep an eye out. Inductiveloadtalk/contribs 17:41, 19 February 2021 (UTC)
Perhaps there is something in my User:Ineuw/vector.js that interferes with the script? — Ineuw (talk) 19:23, 19 February 2021 (UTC)

Template:Header/main block‎

I see you were re-working the header templates..

I have a request..

It relates to - Folk-Lore/Volume 2/Legends of the Lincolnshire Cars, Part 1 header.

Here the section tag is used for the Issue and for the Article name. This works, but leads to a long section name if the line-feed is removed to resolve a lint error.

What would be better is to have an Issue, article title separation, but that might need a new {{periodical contribution header}} to pre-process? ShakespeareFan00 (talk) 12:10, 19 February 2021 (UTC)

Hold on for the moment and we'll come back to it when the logic is all in the module, otherwise it's just hacks on top of hacks. Inductiveloadtalk/contribs 12:12, 19 February 2021 (UTC)

Kitchen sinks…

cf. this comment. If we have to nerf taint checking in {{header}} because {{versions}} does something funky, my immediate thought is that we need to split the code further to keep the funkyness from complicating the code for {{header}}. Does it look like there's potential for separating presentation from parameter handling from metadata from structure, or some other sensible ontology? I mean, even if we keep all the special-casing and such it'll be better by the mere fact of being in Lua, but it'd be nice excise these warts when we have the opportunity. :)

PS. Module:Arguments. --Xover (talk) 13:44, 19 February 2021 (UTC)

@Xover: my thinking is to port {{header}}'s logic to Lua essentially as-is first (maybe with minor tweaks), then worry about tidying up once I have it as code that can be reasoned about.
Since {{versions}} calls {{header}} and manually inserts formatting like {{Font-weight-normal|Versions of}}<br />''{{{title|{{PAGENAME}}}}}'' into the header field, there's not much we can do right now other than just exclude them. Once the header module is looking tidier, we might consider another parameter to allow {{versions}} to do this in a saner way. We might consider that {{versions}} shouldn't call {{header}} itself, but everything calls {{header/base}}, a separate invocation of Module:Header or something else. Exactly how it shakes out is a task after moving the logic from the "title cell" of the header, which is my primary goal right now (so we can fix junk like double spacing and missing commas).
Re separation of structure, that's what {{header/main block}} is aiming for (rather than cramming it all into Module:Header and so it can be harmonised with other headers).
Module:Arguments looks handy, I'll check it out.
And thanks for fixing that talk page, no idea what happened there :-/ Inductiveloadtalk/contribs 14:05, 19 February 2021 (UTC)
Yeah, getting into a state that is amenable to… well, anything, really… is the critical thing (you have no idea how grateful I am that I don't have to touch that mess!). The comment just tripped a red flag for me so I wanted to give you a poke while you have your hands deep in its guts.
enWP have developed quite a bit of Module infrastructure that makes Lua a lot less primitive to work with. Arguments, Yesno, No globals, and utilities for working with categories, etc. And a lot of the modules (unlike the templates) are not too tied to enwp-specific logic. They're not really built to be easy to fork and keep in sync, but a surprisingly large portion can be used as-is. --Xover (talk) 14:20, 19 February 2021 (UTC)

Making hidden layouts visible...

Check out what I added to my common.css, That with your highlihter styles, is starting to look powerful..

What would be nice is a way to add some javascript to 'toggle' this on or off.

Known issues -

  • Currently I have no easy mechanism for limiting it to 'Content' pages, Talk pages look very weird when viewed with the current ruleset.
  • I should really set a rule for DL usage on talk page, as that usage is so widespread as to be de-facto usage.
  • No detection for tables currently.
  • Symbol set used probably needs to look more like something LibreOffice uses to show non-printing characters.

ShakespeareFan00 (talk) 17:55, 21 February 2021 (UTC)

  • JS toggling is easy, just add/remove a class to mw-parser-output and target that with CSS. You can even have multiple toggles.
  • Content pages are easy, because they have even namespace numbers. Load the CSS from the JS to be able to do if (ns % 2 === 0) { loadCSS(); }
Inductiveloadtalk/contribs 18:33, 21 February 2021 (UTC)
I have not written JS code before. Do you have examples? ShakespeareFan00 (talk) 19:54, 21 February 2021 (UTC)
ON second thoughts, I am probably too inexperienced to even understand them at present. ShakespeareFan00 (talk) 20:03, 21 February 2021 (UTC)

Septuagint (Brenton 1879)

For the project Septuagint (Brenton 1879), is it OK to leave it in its present form, which is a little easier to navigate, and to import data from elsewhere?

Doing things from the original book means the Bible data is organized by page and it requires the data to be re-transcribed. Bobdole2021 (talk) 20:09, 24 February 2021 (UTC)

@Bobdole2021: it really should be transcribed against the original so it can be proofread side by side with the book. However, "continuation" table rows is a bit of an issue that I haven't thought of a tidy solution for, and you will need that. There are work-arounds, but they are rather messy.
In general, we are trying to reduce the amount of non-scan backed works wherever possible. They don't need to be retranscribed, just have the existing content moved to the Page namespace.
It would still be organised and presented in the mainspace as it is now. Inductiveloadtalk/contribs 21:43, 24 February 2021 (UTC)

OK that's fine. I'll both setup things up in the mainspace from existing data, and work on figuring out how to put it into page-by-page setup so I can double-check with the original. Sounds good. Bobdole2021 (talk) 22:43, 24 February 2021 (UTC)

Quantum categories

Just now, while the file is deleted at Commons (undel request opened), Index:Login USENIX Newsletter feb1983.djvu shows that it is in Category:Pages with missing files. Naturally enough. However, looking at the category page the index doesn't actually show up there. I'm flummoxed. You got any ideas?

The only things I can think of are either PRP is doing something non-standard, or MW has a configuration that excludes certain namespaces from showing up in a category. But neither one seems obviously plausible in light of the fact the the category does show on the Index: page. --Xover (talk) 10:38, 24 February 2021 (UTC)

@Xover: whoops forgot to save this. Looks like it was a caching issue and a hard purge did the trick. Inductiveloadtalk/contribs 19:30, 25 February 2021 (UTC)
No, what you're seeing is presumably because the file was undeleted at Commons. I purged both the Index: and the Category: and still the category was listed on the Index: page but the page was not listed in the Category:. I guess I'll have to set up some test pages and see if it's reproducible. --Xover (talk) 21:49, 25 February 2021 (UTC)
I did a hard purge (with the purge gadget) yesterday and it seemed to work. I was on my phone and forgot to finish the message to tell you because I got distracted by real life annoyingly happening. I often see categories not filling, generally it resolves in the end, but I've never timed it. Inductiveloadtalk/contribs 22:33, 25 February 2021 (UTC)
If one set of purges didn't loosen it I kinda doubt the next ones did. But some indirect categories (transclusion, MW set cats, etc.) are updated on a periodic basis, either literally or figuratively by a cron job, so that is certainly one possibility. I'm just not quite buying it since the file was deleted last November and it still hadn't updated yesterday. It could be purge + time, of course, rather than just time, but that's not an effect I've noticed in MW before. Incidentally, the file was restored just over two hours after I posted here so that's a pretty narrow window. --Xover (talk) 23:32, 25 February 2021 (UTC)

charles albert buck is full of mistakes/lubek's third chess castle

The following discussion is closed:
End of discussion. Have an nice life, but do it elsewhere. :-)

dude, you are reverting correct info, year of birth is incorrect!

also he foretold the third chess rotation: correct year of birth 1868; third chess castle:

so, instead of vandalizing, where to post that info, on what chess talk page if not on his? unsigned comment by (talk) .

@ None of this is evidence of his date of birth. This is also not a place for original research, or promotion of a chess move. If you have an original, published, public domain document related to the "third chess rotation" (whatever that means), feel free to present it. Otherwise, there is no place at Wikisource for this material. If you continue to spam this stuff, you will continue to be blocked. Inductiveloadtalk/contribs 17:49, 25 February 2021 (UTC)
go on findagrave for proof,i gave it and was deleted SO IM NOT GIVING IT AGAIN, type his name and you will see im correct, give me link where i can present third chess castle! unsigned comment by (talk) .
That's a different Charles A. Buck. is ours. If you think it's the wrong one, you can explain why you think so. According to, it is the right one. If you information about "third chess castle" is not a public domain document, we can't have it here. If you write it up properly, perhaps Wikibooks, but you'll have to do better than the current spam. Sorry. Inductiveloadtalk/contribs 18:09, 25 February 2021 (UTC)

No, wikibooks does not care and lubek's third chess castle is played in some countries; also be careful of unsavory characters; they are reported on: wikipediasux /forum/viewtopic.php?f=10&t=1333&p=19413&sid=d276c4732d977b481e173f1a7b4258c6#p19413 (this circus is already live across www and you or anybody else across wmf wont be able to alter it) who will try to remove our conversation, if it does, dont allow others to play with your page, that will show your high level of low self-esteem: i will create a user account here and under my space i will write about the castle. What happened to public domain, it used to be up to january 1 1923, now it's 1926? MY STUFF IS NOT SPAM, BUT HIGHLY EDUCATIONAL MATERIAL AND THEN SOME... unsigned comment by (talk) .
Public domain in the US is set at 95 years ago. Thus it moves forward one year, every year. 2021 - 95 = 1926.
Please do not add your "educational material" here. This is not a chess strategy forum. If you contributions are not good faith efforts at transcribing public domain texts, then, given your history, they will continue to be blocked on sight. You had your chance for the benefit of the doubt, and the fact you have used three IPs for this conversation hardly fills me with confidence. Inductiveloadtalk/contribs 18:53, 25 February 2021 (UTC)
no, you never gave me nor do you give anybody benefit of the doubt like rest of wikipedoians, my castle statement is here anyway from long ago you wont find it and i dont need to post it again and it is across other wikis and it goes to show how ignorant and stupid you are when it comes to ip: there are dynamic and static IPs, DUH!!! can you post full story to:; also there is plenty of evidence his book was published on january 1: yet your pals erased that date, thus making wikisource articles inacurrate again, again and again:
If I'm so ignorant and stupid that I think dynamic IPs moving from Sydney to Canberra to Perth randomly is suspicious, then I must be far too stupid help you. Sorry. Good luck bringing your chess move to the world, but it's not going to happen at Wikisource. Inductiveloadtalk/contribs 19:22, 25 February 2021 (UTC)
and my ips are australian and they change and they could be out of australia as professionaly defined and you just sait it right how stupid you are and all wikipedoians:

Source tab missing in document

Hi Inductiveload, I've noticed that the source tab and the side page links that point to the source djvu pages is missing on the chapter pages for translation I've been working with (and which you so graciously helped me to get started with): Translation:Writings of Novalis The problem is with all the chapters, so I figure its in the Index Page Code or TOC. I'm wondering if I may have inadvertently disrupted the code in some way. Could you guide me on how to address this? Thanks you for your help! Wtfiv (talk) 06:22, 10 February 2021 (UTC)

@Wtfiv: Nice work! There is a bug in the ProofreadPage system that only shows the source tab in the main namespace: phab:T203102. It's been open since 2013 (yes, really), so I'll try to arrange a local stop-gap. Inductiveloadtalk/contribs 09:17, 10 February 2021 (UTC)
@Wtfiv: JS sticking plaster in place. Let me know if you still can't see it. Inductiveloadtalk/contribs 16:46, 10 February 2021 (UTC)
Thanks Inductiveload! The JS sticking plaster works! It gets the reader to the index page, which is invaluable for verifying the source. When researching the problem I saw the 2013 discussion and actually looked at the example it provided, and saw it was broken. I had some memory at some point in the process of having the access to the source tab, and your note agrees, 2013 was a long time ago! So I figured it was fixed. It particularly helps readers with questions get to the original/translated pages. Thanks for taking care of that!
I have one more tentative request, realizing this may be a bigger issue than sticking plaster can handle: Would it be able to get back the page links on the left that point to the individual djvu page? If not, I appreciate what you already have done! Wtfiv (talk) 03:14, 11 February 2021 (UTC)
@Inductiveload: I saw that you have indeed been able to apply more plaster and bring the pages back to translations as well! Thank you...(I wonder how much work that was)? I may be sounding like the Fisherman's Wife here (or maybe you are still thinking it through), but would it be possible to shift the text to the right a couple of em's so that the page numeration doesn't overlay on the text? Regardless, I am still grateful that you have been able to address a problem that has been hanging out there since 2013! And I am also appreciative of how responsive you've been regarding this issue. Also, I suspect I'm not the only one to feel this way, but it's nice to know you are there to support and guide us through the esoteria of this scriptorium. I like its solitude, but it's good to know there is someone out there to make sure the arcane works remain accessible! Wtfiv (talk) 19:45, 13 February 2021 (UTC)
Glad you like it here. I'm trying to kick things into shape a bit with the JS, I'm glad it's working. Getting the indent might or might not be easy, I'll give it a poke, but it might not be an overnight fix. Or maybe it will be!
Esoterica is certainly one way to put it. I'm trying to whip some docs into shape, but there's a long way to go yet!
Remember, I'll always happy to give a hand if I'm around, feel free to ask. And pointing out places documentation doesn't make sense is a great help to streamlining the on-boarding process, so feel free to drop notes if anything doesn't make sense, or it if doe, but it's unclear at first, or can't be found easily. Inductiveloadtalk/contribs 20:05, 13 February 2021 (UTC)
@Inductiveload: I just wanted to say that your adding the page/djvu links has already been helpful in terms of my work with the translation. More than once, I start seeing a systematic pattern that requires me to go back and change a recurring word's translation though the documentation, and the page number really helps me to get to it quickly rather than having to click through each page in the index. And, in the unlikely chance somebody wants to verify a translation, the page makes that available to them as well. So for me at least, your repair of most of the 2013 damage to the translation pages is really appreciated!
Also, I can definitely see the work in the help pages that have been done. If you've been doing a lot of the contributions to it, I again thank you! Because of its more complex nature, learning to navigate and edit Wikisource is definitely a steeper learning curve than some of the other Wikis. At some point, I may switch gears a bit and reflect on the kind of help that would have made things easier. (Though I think your friendly encouraging response to my initial query, the creation of the initial dvju's and providing some models to guide me by setting the up the TOC, and index pages was probably the greatest help.) Thinking about your offer on the help pages, I think an entire scriptorium discussion on how to decrease the slope of the initial learning curve may be useful though it'd be useful to get members at the relative beginner and intermediate states involved, as their memories of navigating are still recent.
One final observation while I've been working here. As I delve deeper into Wikisource, however, I'm starting to realize the service it can provide to the larger community is not as great as it could be. Its already a great repository for classic and historically relevant proofread texts, and it is one of the best tools on the web for accessing these texts in various formats that actually work properly (e.g., mobi). But on the whole, much of what is seems to offer still seems hidden from view. Outside of the Wikisource universe, the works seem hard to find, and there is not nearly as many links to these works in Wikipedia as there seems there should be. But that too may be something for a scriptorium conversation another day. As you can already tell, I am definitely enjoying the place. Wtfiv (talk) 19:06, 15 February 2021 (UTC)
I am really glad you're enjoying yourself!
One of the major, major issues we have is organisation and discoverability, since "bit pile o' pages" is our default state. Portals are always suggested, but they're rarely set up into a really nice state and they often "peter out" after a couple of levels. If you have a special interest, working on a portal can be a nice thing (any tying it up to authors, works, scouting for works to add, etc). For example, Portal:German literature is a fairly bland and disordered list, and a more "exhibition style" page with a curated section for the Big Authors, a section for "The Classics (TM)", by subject, era, school (Romantic, Reformation,....) etc., would probably be more engaging. And it's allowed to have some description in the Portals, it doesn't have to be just lists. For example, I tried to add some background to Portal:History of China (and then got sidetracked).
Work is slowly happening on categories, but IMO manually curating things will always be needed at least at the higher levels. Inductiveloadtalk/contribs 19:20, 15 February 2021 (UTC)
Exploring how to work out the portals may be a great way to go! I took a look at yours and it does give me ideas. Thanks! Wtfiv (talk) 04:59, 17 February 2021 (UTC)
@Wtfiv: btw, I think I just fixed the issue with the overlapping page numbers. As far as I know (which is not very far), Translation space and mainspace should work the same with transclusions now. Inductiveloadtalk/contribs 15:01, 1 March 2021 (UTC)
It looks great! And, it is downright inspiring- time to do some more work! Not only are the pages functional for editing and verification as per your last fix, but now it looks really nice for public viewing too. Thank you so much! Wtfiv (talk) 16:16, 1 March 2021 (UTC)


Mostly unused, I was thinking that something like this should be Module, which would potentially have no upper limit on the pairs that could be added.

I also made some changes recently to {{rbstagedir}}, mostyl converting it to a classed SPAN , instead of a call to {{float-right}}

I've also got {{poem special/s}} working , as well as {{stagescript/s}} and family.

I also note {{playscript}} which is table based. (which isn't necesarily ideal in a paged environment).

None of these are widely used outside of a few specfic works, and thus I am wondering if the efforts made already should be combined into a single Module, based on what you had already achieved with ppoem, to work around some defects in the POEM extension.

ShakespeareFan00 (talk) 11:02, 28 February 2021 (UTC) (Aside: Generally I've noted that in print poetry, (and this may be a consideration for export) that printed poetry ( and hymnals) tend to move the end of a stanza that won't fully fit on an output page to the next page. I'm not sure how this could be done in CSS though.)

Alignment of translation with original

Hello Inductiveload,

This question pertains to the text:

I've completed the transclusion from the original Italian text to English by populating the left-hand pages. I've started the proofreading process and want to ensure to tidy up any loose ends, e.g. tweak the translation if needed, correct the English, etc.

One bothersome aspect is to align the English translation as closely as possible with the Italian original. At the end of the page there is often the issue that the sentence structure of English and Italian may not align and so, there needs to be a decision what to include on the current page and what on the next page. Also, as in the Italian original, the last sentence on a page is often not finished and continues on the next page. Question, is it problematic for the completion of the translation product to its final phase if the sentences are split between the bottom of a page and the top of the next page? An example are pages 14 and 15, but the situation occurs on many consecutive pages.MvRwiki1944 (talk) 19:22, 25 January 2021 (UTC)

Your guidance will be appreciated.

@MvRwiki1944: good work! That's OK, it's just how translations are - you can't ensure the sentences split neatly across pages every time. As long as it's vaguely sensible, just choose whatever is easier (probably put the entire sentence/clause/etc on the page where most of it is in the original. Inductiveloadtalk/contribs 20:05, 25 January 2021 (UTC)
@Inductiveload:Proofreading completed. What to do next? Wait for the text to be validated?MvRwiki1944 (talk) 08:19, 11 February 2021 (UTC)
@MvRwiki1944: Wow, wonderful! The next step is to transclude it to mainspace and add it to {{new text}}s to strut its stuff. Validation will eventually happen when a suitably motivated Italian-English bilinguist comes along: it is no impediment to presenting the work in the mainspace. Inductiveloadtalk/contribs 07:26, 18 February 2021 (UTC)
@Inductiveload: In the transclusion to mainspace do we just manipulate the English translation or do we also include the Italian original text for the benefit of the validators? The latter in the form of the manuscript or a transclusion to modern orthography? And where do I find the workspace to start the transclusion process?MvRwiki1944 (talk) 20:48, 27 February 2021 (UTC)
@MvRwiki1944: We don't have to include the Italian. What we can do is to link both the enWS and itWS mainspace page from the same Wikidata item (d:Q3563423). Then a link to itWS will appear in the mainspace front page for enWS, and for enWS at itWS.
In theory, we can do parallel it/en text using inter-wiki transclusion, but normally you'd only do that after there's a "clean" English translation. In particular, parallel texts do not (currently) export well at all.
I suggest that you transclude at The Three Princes of Serendip (the title of the English Wikipedia article). You can mention the Italian title in the notes field of that page. Inductiveloadtalk/contribs 19:12, 28 February 2021 (UTC)
@Inductiveload: So, I've started the transclusiom with the Title page and the Contents (not in the original manuscript). How, do I move on to a new section, presumably with a fresh create without losing the first 2 pages? The next section is Imprimatur (pages 3-6).MvRwiki1944 (talk) 23:29, 28 February 2021 (UTC)
@MvRwiki1944: Whoops! Forgot this should have been in the Translation space! I moved it for you. I also created Translation:The Three Princes of Serendip/Imprimatur as a demo for transcluding the next set of pages.
Content that does not appear in the original generally does not go in the Page namespace, even if there is a handy blank page to put it in. Rather, we put it in the main (or translation!) space and use something like {{AuxTOC}} to mark it as "added value". Inductiveloadtalk/contribs 23:40, 28 February 2021 (UTC)
@Inductiveload: Thanks for your assistance. Now, how do I move back and forth between various subsections? I can get to each them based on previous notification, but I don't see how I can move back to the title page and Contens from Imprimatur.MvRwiki1944 (talk) 00:05, 1 March 2021 (UTC)
@MvRwiki1944: generally, there's a link to the next and previous sections in the relevant header fields and a link to the title page in the title field on each page. All three should use relative linking. Inductiveloadtalk/contribs 00:11, 1 March 2021 (UTC)
@Inductiveload: Thanks for your help. Finished the transclusion of the document to mainspace, moving from one section to the next, starting with your upload of the Imprimatur. To navigate backwards in the document via links doesn't seem to work since the backwards links aren't there. The document in mainspace needs major cleanup to move on to the next stage. In order to transclude by section I moved material from adjacent pages in the proofread source document, so as not to have to deal with splitting pages. Any recommendations for cleanup are appreciated.MvRwiki1944 (talk) 02:06, 1 March 2021 (UTC)
@MvRwiki1944: I've moved them to our standard naming of Rank N, but I left the display names in the header as you had them.
You should also not need to move text between pages in the normal case. You can do it with Labelled Section Transclusion. Inductiveloadtalk/contribs 08:16, 1 March 2021 (UTC)
@Inductiveload: I had moved all text to mainspace, but now all text after Prologue is gone in mainspace. Also, I still don't see functional backward links. How do I get back to the full text without having to recreate it?MvRwiki1944 (talk) 12:02, 1 March 2021 (UTC)
@MvRwiki1944: Look at the table of contents at Translation:The Three Princes of Serendip. It's all there. The backlinks should be formatted like [[../Foreword/]], otherwise they will not be links. Inductiveloadtalk/contribs 12:07, 1 March 2021 (UTC)
@Inductiveload: I can see the backlinks now. Next task is to clean up the text in mainspace, starting with the running-together of letters in the paragraphs, e.g. in Imprimatur the words 'consequence' and 'suffice'. Can this be edited out in mainspace, or do I need to go back to namespace?MvRwiki1944 (talk) 12:29, 1 March 2021 (UTC)
@MvRwiki1944: What do you mean by "running together"? The words look OK to me. The page numbers do overlap the text, but I'm currently working on that. Can you take a screenshot? Inductiveloadtalk/contribs 12:32, 1 March 2021 (UTC)
@Inductiveload Sent screenshot of Imprimatur, showing the words 'consequence' and 'suffice'. This running together of letters occurs all over the text. Sent email with PDF attachment to, in reply to your most recent email to me.MvRwiki1944 (talk) 12:54, 1 March 2021 (UTC)
@MvRwiki1944: I don't think you can reply to email "pings". Maybe just upload the screenshot to (or wherever) and post the link. Just the ID part of the URL will do if it sets off the spam filter. Inductiveloadtalk/contribs 13:07, 1 March 2021 (UTC)
@Inductiveload: Not familiar with (or whatever) and link to what? The PDF is a screenshot of Imprimatur as it appears on my computer.MvRwiki1944 (talk) 13:18, 1 March 2021 (UTC)
@MvRwiki1944: It's a website for posting images. I don't receive emails Or you can email me <removed>. Inductiveloadtalk/contribs 13:39, 1 March 2021 (UTC)
@MvRwiki1944: so you did mean a collision with the page numbers. Can you try it now? Inductiveloadtalk/contribs 13:55, 1 March 2021 (UTC)
@Inductiveload: Looks great now. Problem solved. Is the transclusion document equivalent to mainspace and is it the document from which the validators work by checking the namespace document they can access through clicking on the numbers in the left margin of the page. Has the text been reclassified as to be validated ? nd what should I do next? Also, what is the shortest pathway to the document on mainpage?(talk) 01:06, 2 March 2021 (UTC)MvRwiki1944 (talk) 17:03, 2 March 2021 (UTC)
@MvRwiki1944: It is now live on the front page. I updated the index page status to "to be validated" and created Author:Cristoforo Armeno. Inductiveloadtalk/contribs 17:34, 2 March 2021 (UTC)

Continued listitems...

Page:Russell_Bucklew_v._Anne_L._Precythe,_Director,_Missouri_Department_of_Corrections.pdf/42 has a continued list item.

I was currently using this:- Template:Plainlist/single.css via a template style to suppress the marker on a continued list item.. However, a very helpful user on the Wikimedia discord's Technical channel expressed concerns that this might not be an ideal way of doing this.

As you were involved in getting things to 'export' cleanly, I was wondering if you had any views? ShakespeareFan00 (talk) 10:01, 2 March 2021 (UTC)

Since I know you love writing docs

User:Xover/Template guidelines

Input (very very!) welcome. Feel free to edit directly. Won't be offended if you think any part of it is idiotic (but might of course push back on it since everything I write is obviously the work of genius), nor if you think it's a waste of time (see previous parenthetical).

I'm thinking it can become a guideline-guideline eventually, and something we actively work (long term) on migrating existing stuff to.

And it's meant to be a pretty technical guideline. Target audience is me, you, and anybody else with their fingers in the technical guts. So fair game to talk about p-wrapping, margin collapsing, semantic-ish templates, etc. But sufficiently readable to the community at large that they can look and see that it is good (nodding sagely is adviced). --Xover (talk) 10:46, 2 March 2021 (UTC)

Blanking as 'no text'

I noticed your contribution here. Can you clarify the reason for this? AnotherEditor144 t - c 12:18, 2 March 2021 (UTC)

@AnotherEditor144: As I mentioned in my edit summary, this is an ex libris sticker, and, since it is not part of the work in question, we do not reproduce it. We also don't reproduce barcode stickers, call number stickers, the card pocket in the back of some library books, library stamps, scribbling by the book owners/borrowers (unless that's a historically useful work in its own right, Fermat's famous marginalia comes to mind), or library or digitization watermarks or registration markers. Basically, if it's not part of the book when published, we don't usually reproduce it. Inductiveloadtalk/contribs 12:25, 2 March 2021 (UTC)
Thank you. I thought you might be interested in this.

Machinell translated

@Inductiveload: Hallo Inductiveload, we had discussion because of machine translation. You wrote to me that i have before inserted license template. I did that now but still it was not translated. I do not realize why it was not translated while uploading. Thanks from germany

--Riquix (talk) 06:26, 7 March 2021 (UTC)

@Riquix: Sorry, I don't follow. What's the problem here? The file at Commons has a license template. The problem before was that it did not have a license template. What translation were you expecting to happen? Inductiveloadtalk/contribs 09:26, 9 March 2021 (UTC)
@Inductiveload: If the experienced user has been made then all pages translated automatically. Now we have to put every single page with OCR button. Look at any one page here : --Riquix (talk) 10:19, 9 March 2021 (UTC)
Oh I see, this file does not have a text layer. It's also missing several pages. Digital Library of India really do produce some rubbish scans. I'll try to source a better scan from here, but it'll take some time to download and convert. Inductiveloadtalk/contribs 10:27, 9 March 2021 (UTC)
@Riquix: try this scan: Index:Essays On The Gita - Ghose - 1922.djvu. It's a different printing (it's the original 1922 Madras edition), but the content should be the same. All pages appear to be present, and I've put in a text layer for you. Inductiveloadtalk/contribs 11:34, 9 March 2021 (UTC)
Many thanks !--Riquix (talk) 07:11, 10 March 2021 (UTC)

Woa there, cowboy!

This needs some discussion first! --Xover (talk) 19:10, 10 March 2021 (UTC)

@Xover: There's zero visual difference (it still uses {{new texts/item}}) or any difference in functionality to how it used to be. Except that month-by-month archiving is now completely automatic. Inductiveloadtalk/contribs 19:24, 10 March 2021 (UTC)
You're sending end users into Lua code, and completely changing the workflow for new texts. There are technical differences, a completely new and alien syntax, and there's no guarantee those who interact with this workflow are capable or comfortable with the new version. This can't just drop in without warning. I actually also have some technical concerns on my own account, but those are a secondary point. --Xover (talk) 19:33, 10 March 2021 (UTC)
What technical issues did you have in mind? Inductiveloadtalk/contribs 19:37, 10 March 2021 (UTC)
Mainly that as a user-facing interface ("config file"), Lua datastructure syntax is fragile: forget a comma, or any one of a billion other obscure technical details, and you start throwing big red error messages and break the whole system (an error in one leaf breaks the whole tree). Compare the old version: each entry is an individual template, where a mistake is usually immediately obvious, and, crucially, cannot break other entries.
Just for contrast, when I've previously toyed with ways to improve that (admittedly rather baroque) process, it's been in the direction of a default-Gadget-provided JS UI to manage the list and possibly JSON storage for the actual data (i.e. explicitly not user-editable). Not as an actual proposed "better" way to do it (I've "toyed with the idea" not actually thought about it), but just to make clear my frame of reference and thinking related to this. --Xover (talk) 19:50, 10 March 2021 (UTC)
@Xover: I thought of that, but MW Lua editor will not let allow you save a syntactically invalid table. The worst you can do is screw up the data itself so badly that it can't even be loaded, which takes some doing (it is possible, e.g. by referencing a global). But nearly all practical ways to do that end up with the same result as now: {{new texts/item}} chokes on it. For example, the most likely syntactically-valid thing a user will do is forget quotes:
	 		title = George,
	 		author = Algernon,
	 		year = 1875
In which case it breaks "normally". You can't write title = George Chapman, that won't save, as will forgetting a comma. About the only thing I've managed to find that does actually cause a load failure and is allowed to actually be saved is forgetting a comma and quotes and not putting it in {} (and doesn't check it before saving):
I've also considered a tool like you say but I would bet half a bitcoin that it would become unmaintained, like PageNumbers.js or Match and Split, depending on whether its a local JS tool or Toolforge tool, the day that the inventor gets hit by a bus. Plus it'll be an even bigger PITA if dodgy data sneaks in if the tool doesn't also make it really obvious how to revert it.
Also, arguably, there's not much practical difference between one failed entry because the user missed { in the current system and they exploded the data table. The main page is still busted, probably with a red error in either case, and will be fixed or reverted ASAP by someone. If we were super-serious about avoiding that, we'd detect the error text (or blanking, or whatever) with a bot watching the page and have it insta-revert (or allow only edits to a canary page, and have it mirrored to the real page if it is suitably not on fire). But that applies right now too. Inductiveloadtalk/contribs 20:31, 10 March 2021 (UTC)
Oh, interesting. I didn't even consider that the editor might prevent this. Input validation FTW!
But I still think the syntax is more complicated and fragile from a user perspective. The template version is far from great, but we do sort of have to presuppose users to be minimally comfortable with templates to contribute. A complex data structure in Lua is a step too far IMO. Even without the breaks everything vs. breaks this entry issue, the myriad ways this can "not work" feels fragile and obtuse to the user, and especially since just hitting the "Preview" button won't actually work.
But to be clear: I'm not saying we can't go that way, no way no how not never. I'm saying it's a big enough change that we need to let the community decide if they're comfortable with that before implementing it. For my own part I'd much prefer to edit the Lua config to MW templates (did I mention I hate templates?), so it's no skin off my own back. Looking the same on the main page or ugly error message ditto aren't really main concerns for me: error messages are good so we discover and can fix issues, and the main page is way overdue for some tweaks. It's the user experience that concerns me. But it's entirely possible my concerns are overblown. --Xover (talk) 16:50, 14 March 2021 (UTC)


I knew I wasn't crazy! :)

But that's just the pagenum span. While you were digging around, you didn't happen to find code to suppress the transclusion of the actual page content. Cf. eg. this sandbox. If the page content is transcluded, it's arguable that the pagenum should be too, for consistency. There may be legitimate uses for pulling such pages in through PRP (vs. just normal MW transclusion like you'd do for the ToC on an Index:), but in my experience these always end up as exclude=pp. in the <pages … /> tag. --Xover (talk) 08:29, 16 March 2021 (UTC)

@Xover: I know what you mean, but I was more about fixing the issue in the code as written, since that was 1) easy, 2) fixes our issues where the W/T number merks the one you want and 3) won't really change on-wiki behaviour (I have no idea if people are using W/T pages for weird and nefarious purposes on other Wikisourcen). To do what you suggest would be to stuff all the transclusion code into the if statement:
                if ( $qualityLevel !== PageLevel::WITHOUT_TEXT ) {
                    $pagenum = $pageNumber->getRawPageNumber( $language );
                    $formattedNum = $pageNumber->getFormattedPageNumber( $language );
                    $out .= '<span>{{:MediaWiki:Proofreadpage_pagenum_template|page=' . $text .

                    if ( $from_page !== null && $page->equals( $from_page ) && $fromsection !== null ) {
                        $ts = '';
                        // Check if it is single page transclusion
                        if ( $to_page !== null && $page->equals( $to_page ) && $tosection !== null ) {
                            $ts = $tosection;
                        $out .= '{{#lst:' . $text . '|' . $fromsection . '|' . $ts . '}}';
                    } elseif ( $to_page !== null && $page->equals( $to_page ) && $tosection !== null ) {
                        $out .= '{{#lst:' . $text . '||' . $tosection . '}}';
                    } elseif ( $onlysection !== null ) {
                        $out .= '{{#lst:' . $text . '|' . $onlysection . '}}';
                    } else {
                        $out .= '{{:' . $text . '}}';
                    $out .= $placeholder;
Inductiveloadtalk/contribs 08:36, 16 March 2021 (UTC)
Yeah, that's why I wondered if there was existing code for it that was just broken like the pagenum stuff. A bug would presumably be easy to fix, but a change that affects on-wiki behaviour would at the very least require research, and worst case also community consultation (which I don't think any of the usual suspects have the capacity for these days). --Xover (talk) 08:51, 16 March 2021 (UTC)
AFAICT, there isn't broken code for it, it's "supposed" to be like that. But I would say that the logic of suppressing the page number and inter-page separator but not the content is flawed. It's just on wikis (all of them?) where those pages are usually completely empty, there's no visible difference, so no one has cared (or they have assumed it is intended and excluded them manually when needed.
I'll file an issue and patch (after a conflicting patch has gone in) and we'll see if anyone screams. If nothing else, there'll be a task+patch in the system for future reference. Inductiveloadtalk/contribs 08:56, 16 March 2021 (UTC)
Oh, that reminds me… We should have a cleaned up version of User:Xover/notext.js as a default gadget. I think maybe I saw you had something similar sitting somewhere? In any case, it should empty the text fields when "Without text" is chosen, and restore it when choosing something else (in case the user just misclicked). I'll get around to fixing it up eventually, but feel free to jump ahead if you want. --Xover (talk) 09:36, 16 March 2021 (UTC)
@Xover: I have the Index preview grid, developed for a driven-off contributor, which provides "set as empty" in the alt-click pop-up: User:Inductiveload/index_preview, but nothing like that in edit mode.
Messing with the textbox is frustrating with JS because it kills the undo buffer (at least it does for me in both Firefox and Chrome), so restoring the text after a JS intervention isn't trivial (this is incredibly annoying sometimes). So it'll need special handling other than just Ctrl-Z on the text-box. Inductiveloadtalk/contribs 10:09, 16 March 2021 (UTC)

Lua table length

Incidentally, since I saw a comment of yours somewhere… Lua table length can be counted with # iff its keys are monotonically increasing integers starting at 1. It's one of the quirks of Lua's design that makes absolutely no sense to anyone. --Xover (talk) 08:33, 18 March 2021 (UTC)

@Xover: that's what I thought, but the table that mw.loadData() provides has metamethods that mean #foo, annoyingly, does not work on them (cf. the last bullet here. My workaround was a simple counter loop, which is brutalist but effective. Inductiveloadtalk/contribs 09:21, 18 March 2021 (UTC)
Ah, yes, metamethods… How do I loathe thee? Let me count the ways… --Xover (talk) 09:33, 18 March 2021 (UTC)
Remember you can't use #metamethod_loathings :-D Inductiveloadtalk/contribs 09:34, 18 March 2021 (UTC)

Template:Kut-eng and Template:Kutenai

Found this situation when lint error hunting.. Given the large number of templates here I am wondering if what's needed is a module based engine where each pair is placed on it's own line? ShakespeareFan00 (talk) 10:21, 18 March 2021 (UTC)

This should probably be ruby:


<ruby style="ruby-position:under;">


Inductiveloadtalk/contribs 12:54, 18 March 2021 (UTC)

An em is not an em

cf. sandbox.

So it looks like &emsp; is not actually 1em wide, which makes trying to align other bits with :-indented lines inside {{ppoem}} rather a challenge. See example (the drop-initial makes everything complicated, and here it has to be manually shifted due to indented lines).

I would suggest mimicking {{gap}}'s approach to get a predictable width, but possibly using &emsp; instead of WORD JOINER inside the span (so the semantics match the context).

PS. I think possibly the drop-initial would have been easier here if I could have disabled the hanging indent on the first line, since both rely on text-indent/margin for their effect. Might be worth considering as magic ppoem-syntax at some point. --Xover (talk) 09:54, 20 March 2021 (UTC)

@Xover: Re emsp: that probably makes sense.
Re the dropinitials: these have been a "bit" of a pain. I think you actually generally want to keep the hanging indent even after a DI if possible, because you still need it to show the next line is a continuation of the first, not a new line (normally, printed matter still keeps the hanging indent for the first line). However, CSS seems awfully reluctant to allow that without prematurely wrapping the first line. Setting the first line's width to > 100% works but you need to know the extra to add, which you obviously do not know in general. Cogitation continues.
We might also want to consider a syntax to allow a ppoem-line to acquire a class (and, maybe, style), somewhat like tables do for cells. Probably not for common use, but would add flexibility. Inductiveloadtalk/contribs 11:32, 20 March 2021 (UTC)
Dropcaps are… yeah. Thanks to having to fake them with floated content we're always going to be in a world of pain there. I have wondered though, if we could fix the premature line wrapping by adding Yet Another fake span, z-indexed to the back and turned functionally invisible, but positioned such that it lets the browser calculate the actual width of the box. I think this behaviour might actually be a hole (not a bug, per se, but an unintended corner case) in the CSS box model. Possibly it's that white-space needs, in addition to normal and pre-wrap, a please don't ever wrap this line unless you really physically have to, and calculate its width accordingly. In any case, yeah, preferably preserve hanging indent, but I'd probably trade it for being able to achieve other things if forced to choose.
I've also loosely wondered if—since you're already parsing wikicode here—we could let templates like {{di}} to signal their presence to obviate the need for manually adding constructs like {{di|A}} << HOY!. Anything from stripcodes to HTML classes could conceivably work there, and could be emitted either always or by explicit request along the lines of {{di|A|mode=ppoem}}.
A class on lines is probably a good idea, but may want to wait for a clear need (per-work CSS may generate that) to avoid having too much syntax with too obscure use cases. Inline style is an emergency solution, so I'd urge a very clear need before implementing that. Could predefined styles cover 80% of the need reasonably? Is there an acceptable manual fallback for the remaining 20%? If so I would argue we could avoid inline styles altogether. --Xover (talk) 18:09, 20 March 2021 (UTC)
@Xover: Dropcaps are… yeah...yeah
since you're already parsing wikicode here I'm not really, though. I could inspect the content for something like {{(di|dropinitial)\| but that's a rather uncomfortable coupling between the templates. I'd almost rather go for a DI syntax within ppoem.
we could avoid inline styles altogether it's fairly likely that per-work CSS will permit this, as long as you can apply classes to lines.
Inductiveloadtalk/contribs 13:22, 21 March 2021 (UTC)
DI syntax: I wasn't really thinking about looking for the template invocation (regex parsers suck), although if anything would merit such a hack it'd be {{di}}. I was thinking more along the lines of making any template that needed it emit a control code (strip markers spring to mind, but I'm sure there are other ways that would work). But I haven't really looked at how you're doing the magic syntax here, so I don't know what'd be a non-yucky way to do it. The amount of magic syntax so far seems to sit pretty solidly in the Goldilocks zone (I'm amazed at the sheer number of pages I've been able to do with essentially only ppoem!), but adding too much more is, IMO, rapidly taking it into the "unwieldy monster" end of the scale. --Xover (talk) 15:02, 21 March 2021 (UTC)
@Xover: glad to hear about the magic syntax. I'm also cautious about taking it too far into "black magic" territory (also I don't want to end up badly re-writing a LALR parser or something as a module to parse a mini-language and/or ending up with {{TOCstyle}}).
Because this is a template, it only sees incoming {{di}}'s as, literal "{{di|...}}" and the module spits the Wikicode out, verbatim, as it comes. They expand later in the parser, not in the module. In theory, you could capture them and expand in the module with frame.expandTemplate but that would be a very last resort, IMO. Inductiveloadtalk/contribs 16:47, 21 March 2021 (UTC)

Crossing pages is the cross we bear

Any thoughts on handling lines that cross pages inside a ppoem run?

The case is actually a play where everything is spoken in verse, but stage directions show up as a long unwrapped "line" that can span across page boundaries. I can only come up with moving text between pages (which pains my obsessive streak) or splitting it out of the ppoem block (which has the same alignment problems old poem has). I could also abuse hws/hwe I suppose, but for about a short paragraph's worth of text that feels… icky.

Any clever solutions I haven't thought of? I don't think this can be fully solved without a new start/end model and making ppoem an extension (either part of or at least tightly integrated with PRP), can it? --Xover (talk) 11:12, 21 March 2021 (UTC)

Oh, and the example is at Page:War, the Liberator (1918).djvu/92 and /93. I ended up moving the text to the latter page. But I don't have to like it! :) --Xover (talk) 12:42, 21 March 2021 (UTC)
@Xover: I think we can get away with just a new start/end "no-line-break" model and just omit the span-close and open on transclude. The pagenum span will occur half-way though the line, but that's fine, I think (or even preferable).
I'm open to extension-ification, but I'd rather get a template working and then upgrade, or we'll be here all decade. Inductiveloadtalk/contribs 13:26, 21 March 2021 (UTC)
Oh, you're right and I'm just being dumb; I wasn't thinking across namespaces at all. Yeah, that would presumably work (unless the parser steps in and p-wraps it into oblivion of course). And I'm in no hurry for extensionification either; I'm by no means certain the benefits (which may only be the ability to do a /s+/e model) will outweigh the costs. My playing with it so far suggests it works astonishingly well. I'll try to cobble together something resembling structured feedback when I'm done playing. --Xover (talk) 14:54, 21 March 2021 (UTC)
@Xover: This appears to be working now with start/end set to same-line. Open to suggestions if that is not a clear value. Inductiveloadtalk/contribs 12:26, 22 March 2021 (UTC)
The page joining indeed seems to work. In re the value, the keyword "continue" pops up in my head, but I'm not sure it makes any kind of sense. --Xover (talk) 18:06, 22 March 2021 (UTC)
@Xover: "Continue" was in my head too, but we need to make sure this and "follow" aren't too confusable. Unless follow is "no-stanza"/"same-stanza" or something? Inductiveloadtalk/contribs 18:16, 22 March 2021 (UTC)

Large initial

Hello. I have notice that you added the image parameter to the template {{dropinitial}}. Would it be possible to do the same with {{largeinitial}} too? I tried to add the image simply into the first parameter of the template, but for some reason it does not keep the baseline, see Page:Czechoslovakia's tribute to the memory of Woodrow Wilson.djvu/11. What do you think? --Jan Kameníček (talk) 22:11, 22 March 2021 (UTC)

@Jan.Kamenicek: I added the parameter and it seems to work OK. :-) Inductiveloadtalk/contribs 22:50, 22 March 2021 (UTC)
Absolutely perfect! Thanks very much. --Jan Kameníček (talk) 00:15, 23 March 2021 (UTC)

Finally caught a break...

...or something that broke, in any case. :)

See War, the Liberator, and Other Pieces/My Old Grenade (transcluded from pp. 128 and 129).

My immediate guess is that nesting ppoems will generally break in similar ways without special params to handle it. But it's possible this particular formatting would be better done with either an embedded {{center block}}, or possibly explicit magic syntax for the stanza (e.g. "the following stanza is a centered block within the overall width of the poem block").

But on the plus side, this is the first case that seems to break in about a hundred pages of ppoem use (variability low to medium, so not a real torture test; but fairly representative). --Xover (talk) 09:06, 23 March 2021 (UTC)

Hmm, this is probably a case for phab:T276681 (per-stanza classing), possibly with a built-in class for block-centred. Inductiveloadtalk/contribs 09:12, 23 March 2021 (UTC)
Yeah. The following poem also has what looks like a stanza block-aligned to the right that I predict similar problems will accrue to. --Xover (talk) 09:17, 23 March 2021 (UTC)

The latest edits broke btw.

A << B and the rest of the alphabet.

Just in case you hadn't already caught it yourself. :) --Xover (talk) 12:40, 23 March 2021 (UTC)

@Xover: sorry, I didn't mean to break it while I was faffing! Anyway, I have something like stanza styles working now (plus a tidier module with...tests!).
The margins are still causing a few issues with the block centre's exact alignment, but the general idea and syntax is there, at least. Inductiveloadtalk/contribs 13:49, 23 March 2021 (UTC)
Awesome! Page:War, the Liberator (1918).djvu/134 is probably a good in-the-wild example of the margins not quite lining up (well, either that or my eyes are going crosswise). No worries about the breakage: this is experimental use.
Oh, hmm. Why is the example above wrapping now? --Xover (talk) 14:24, 23 March 2021 (UTC)
@Xover: where is it wrapping? Bombers and Grenade are both unwrapped on my screen.
In general, DIs may well cause a spurious wrap specifically if the lines next to them are within 4em of the longest in the whole poem, or if the DI itself is bigger than 4em (cf. last example in the docs). Inductiveloadtalk/contribs 14:50, 23 March 2021 (UTC)
In this example…
A << B and the rest of the alphabet.

…the A is above the B on my end. --Xover (talk) 14:52, 23 March 2021 (UTC)
@Xover: Ah, that's because A is not floated left like a DI would be. The lines are display:block (for the moment) to allow them to have a hanging indent each (without being paragraphs) Inductiveloadtalk/contribs 15:00, 23 March 2021 (UTC)
Ah, yes. I see now. Thanks. --Xover (talk) 15:02, 23 March 2021 (UTC)
@Xover: btw, the :::: syntax now produces a {{gap}}-like fixed-width span of that many 'em', containing that many emsp's for copy-paste. Inductiveloadtalk/contribs 16:07, 23 March 2021 (UTC)
Oh, excellent! I just had occasion to test with a single em and it worked great. PS. Also ran across some possible pre-defined classes for poem (and possibly stanza) here. --Xover (talk) 19:14, 23 March 2021 (UTC)
@Xover: Hmm, how do you think this should work? Provide a handful of built-in class names via Template:Ppoem/styles.css (say one for text-align:center/right, smaller, and fine)? I think the only one that makes sense to be magic is text-align center/right, but then what's the syntax? Inductiveloadtalk/contribs 19:22, 23 March 2021 (UTC)
For this case I was thinking pre-defined classes in styles.css. I don't immediately see any need for magic syntax for this. Based on the use case I ran into I was thinking maybe the standard bunch of size classes, and left/center/right/justify, and a couple of line-height values to cover common cases. And I was thinking mostly in terms of stuff that could be cleanly implemented as classes (i.e. nothing like {{di}} here). But maybe I haven't thought it through enough? --Xover (talk) 19:37, 23 March 2021 (UTC)

The other initial has dropped!

OR rather, the quotation mark has escaped.” :) --Xover (talk) 15:13, 23 March 2021 (UTC)

ARGH! Inductiveloadtalk/contribs 15:14, 23 March 2021 (UTC)
This should be fixed now (the floated thing floats too). Inductiveloadtalk/contribs 09:38, 24 March 2021 (UTC)
Yeah, verified. Thanks! --Xover (talk) 10:51, 24 March 2021 (UTC)

Block based templates

Ppoem's docs probably needs a separate caution about block (div/p) based templates inside stanzas. And depending on how many of those crop up regularly in poems we may want to maintain a list of compatible alternatives. The one I ran into was {{

      • }} (which screams to be migrated to Lua in any case), but I've worked around it manually for now until I see how often it crops up. --Xover (talk) 07:16, 24 March 2021 (UTC)
@Xover: Hmm, so I think there are a few options here, in no particular order (and with minimal thought given so far), and can be mixed and matched:
  • Provide wholesale alternative templates e.g. {{*** inline}} (but we have enough templates)
  • Give {{***}} and friends an inline parameter (but we don't really want to add more gotchas to ppoem)
  • Convert {{***}} and friends to <span style="display:block;"> (semantically this might even not be the worst idea ever - are they really divs (division/section) anyway?)
Adding a magic syntax to ppoem to make a line a div isn't an option because stanzas are (rightfully) p's, so you can't have divs or other p's in there. Inductiveloadtalk/contribs 09:38, 24 March 2021 (UTC)
I'm not sold on the argument that much of anything is actually properly a p, but be that as it may…
I think implementation should be a bit mix and match, unless something points itself out as the One True Way. The key point there is to document the common gotchas, and anywhere we can reduce the need for docs (for reading them, not so much the writing of them) by making the relevant templates intuitive or "just work" the better.
I don't generally think converting div to span with display:block has much point (it's a distinction without difference in html5; we mostly only notice due to p-wrapping and other parser messes). Better would be a move away from 1= templates and towards /s+/e templates for blocks, to make clear what the model is. For users it would also be more intuitive (less cognitive load) even with more templates, because the inline and block versions would (if done right, and in most-but-not-all cases) would appear to be one template and how to call it given by the context.
And I'm generally on the wait and see train on this, until we see how many of these there are. The only reason I'm pointing a gun at {{
      • }} is that internally it uses {{loop}} to do its thing, and that one seriously needs to be killed with fire. Since it needs to be gutted anyway we might as well find some way to make it work well in ppoem too. --Xover (talk) 10:50, 24 March 2021 (UTC)
@Xover: I'm not sold on the argument that much of anything is actually properly a p How do you mean? Make stanzas a div? That would definitely work and allow block children. But a stanza certainly feels like a p (and as we all know, feels > reals), though since they have a class anyway it makes little practical difference.
I don't generally think converting div to span with display:block has much point indeed, it's almost sophistry, but, at least for {{***}} (and a few allied things), it's not really a div. In fact it's semantically possibly more like an HR element. Which might be possible with per-work CSS (it needs :after selectors and won't copy-paste), but won't be practical with templates.
some way to make it work well in ppoem too - some way to use span instead of div would be easy even as it is, but I haven't thought about it enough to say if that's a good idea.
wait and see train on this agreed. Inductiveloadtalk/contribs 11:16, 24 March 2021 (UTC)
p is a brainfart from a bunch of old farts back in the early nineties (yes, TimBL and DanC, I'm talking about you ;)), inherited by the work on GML back in… I actually don't remember when IBM started work on that, and can't be arsed to go look it up… but it was a model of what HTML would be used for that was very coloured by the fact that the web did not exist. It reflects the idea that HTML is primarily a way to mark up documents—and I mean double-spaced, typewritten, stacks of dead trees here—and needs to be able to express all the customary parts of such artefacts. It's from a conception of HTML as "a simpler SGML with active hyperlinks", rather than the foundation of the modern web (the majority of which much more resembles an application than a document). When div and span were introduced in HTML 4.01 (well, really in HTML 3.2+ iirc, but that's a different story) it reflected amassed experience that a paragraph tag is way too narrow and limiting for the kinds of things the web needs, and brings along too many assumptions from the stacks of dead trees. In that old conception of the web, p would actually be incorrect here, because a stanza should have its own tag. In the new conception of the web a stanza, like a paragraph (in most contexts), is just another kind of logical grouping of a page (i.e. a div) to which more specific semantics can be added with a microformat. On enWS the only real proper use for p would be marking up the paragraphs in the works we reproduce, but that would only make sense if we could control it directly (the parser's p-wrapping has way too many problems).
In any case… I can't think of a single use case here where p would be appropriate and where it wouldn't cause far more problems than it was worth. We inherit some default styling in both UAs and MW for div too, but overall it has far fewer problems. Not that, you know, it's a pet peeve or anything… :) --Xover (talk) 12:02, 24 March 2021 (UTC)
@Xover: Well it sounds like you know this in more detail than I do! Perhaps I've overestimated the usefulness of p based on how pervasive it is. So should we make stanza a div (it's a trivial thing to do)? None of the CSS should be affected, at least. Inductiveloadtalk/contribs 12:09, 24 March 2021 (UTC)
Bah. I'm mostly just curmudgeoning, and mostly due to T253072. If it's trivial I'd argue lamely in favour of switching, otherwise I'm just venting. The main reason for switching is that div inherits fewer pre-defined behaviours and styles, but on the other hand it works just fine with p so switching might necessitate explicitly specifying some of that stuff. --Xover (talk) 14:13, 24 March 2021 (UTC)

Ppoem, the Liberator

Ok, I've now finished War, the Liberator, and Other Pieces. I did half of it using {{sbs}} and then switched to {{ppoem}}. And finally I went back and converted the {{sbs}} uses to {{ppoem}}, swapped out {{em}} and {{gap}} with : and ::, and other features and fixes you added as I was working.

The experience so far is that, modulo the issues you address along the way, ppoem works great, is rock solid, is intuitive to use (modulo learning curve, caveat custom syntax and model), solved all the needed problems for this work, and despite the oddball and kinda fragile start/stop hinting there were essentially no problems on transclusion (which is more than I can say for any of the other ways we deal with page-crossing!). Converting sbs to ppoem was straightforward (which I think means they actually share far more in philosophy than is immediately obvious), and resulted in immediate improvements: simpler (and less) markup, far fewer visual glitches, and just overall better in all ways. Compared to all other ways to format poems (and similar constructs) ppoem is much better in every way.

The drawbacks and annoyances are the custom syntax that is very different from everything else we use, and can reuse very little existing acquired knowledge; keeping track of what kind of start and end model to use is a bit taxing, and will be moderately difficult for many contributors; and the need to have special syntax (<<) after a dropcap is not at all intuitive and so resists establishing muscle memory (I kept forgetting, even after I figured out why it was needed).

I think the first issue probably argues that we should be completely uncompromising in keeping the custom syntax small and internally consistent (no special-casing, no solving every need that pops up using new magic). The second will need some noodling, but can probably be alleviated somewhat by using good keywords that people intuitively understand, possibly encouraging putting |end= at the actual end of the template call, and maybe even some fancy GUI tool to manage that aspect (or possibly just something EasyLST-ish). The last issue we've discussed elsewhere so I won't go into it here, but it's sufficiently annoying that it's worth a couple more cycles coming up with possible DWIM solutions.

All in all I'd say ppoem as it stands is already a massive success, and but for the need for much more testing on real world data and some caution around the custom syntax / model, I'd say it could with great benefit have been pushed to the community already. I'm going to go back over some of my existing works that use {{sbs}} and convert them to see if there are any more gotchas to be found, and because I'm already convinced that ppoem means sbs can no longer justify its existence (pre-wrap/poem formatting was its raison d'être; ppoem does that far better, and even though sbs has other functions they probably don't justify its existence alone). --Xover (talk) 11:27, 24 March 2021 (UTC)

Thank you for the vote of confidence. Except for the CSS finagling and the DIs, I'm fairly happy with the outcome so far, too. :-)
I'm still thinking about the DI stuff. I think there might be better ways to handle it, but I haven't gotten it just yet. Ideally, the "<<" could just die one day.
Re the start end model, the only thing I can really think of other than your suggestions is "moar magic" with another magic syntax on the first/last lines like "=> same-line" at the start and "stanza-break =>" at the end, but I'm far from convinced that that's actually a reduction in cognitive load. At least parameters are familiar and explicit (and can be picked out by existing tools like mwparserfromhell).
Re completely uncompromising in keeping the custom syntax small and internally consistent absolutely, I do not want this to be {{ts}} 2.0. Inductiveloadtalk/contribs 11:39, 24 March 2021 (UTC)

On a completely unrelated note… Does the 4em right margin need to be on the stanza (vs. the lines)? It seems to be the main culprit in making centered stuff fail to align sensibly (by pushing all the contained lines too far left relative to centered stuff outside the ppoem). The left margin for the hanging indent that the right margin is, I think, compensating for is attached to the lines, so my immediate assumption would be that the right margin should be too. --Xover (talk) 18:50, 24 March 2021 (UTC)
@Xover: this is indeed part of what is messing with the alignment. The right margin is actually there to make sure that the lines, which are 100% wide (of the stanza) don't lose their right-hand 4em on a small screen. Although they are 100% wide, they're also 4em to the right, so they "stick out" of small containers.
And why the merry Felicity is there a width:100% there anyway, I hear you ask? That's because if you don't force the line to be as wide as the stanza, a drop initial will definitely wrap its line (whereas with 100%, it will only wrap if the line is within 4em of the longest in the whole poem).
I'm sure there's a better way somewhere, but this way is the best I could figure out with my fried brain. Inductiveloadtalk/contribs 19:01, 24 March 2021 (UTC)
Would width: calc(100% - 4em); do it? --Xover (talk) 20:31, 24 March 2021 (UTC)
No, because you actually want the 4em to stop the wrapping with (smaller) drop initials. But I am not sure the cure isn't actually worse than the ailment here. Inductiveloadtalk/contribs 21:16, 24 March 2021 (UTC)

Dropped initial

Hello. It seems that after your edits of the template {{Dropinitial}} the top margin parameter stopped working (I did not check the other margin parameters), see User:Jan.Kamenicek/Sandbox. Can you also have a look at it, please? --Jan Kameníček (talk) 11:00, 23 March 2021 (UTC)

@Jan.Kamenicek: Ugh, yes, dagnabbit! I didn't notice that at the time. I guess my eyes are so far out of calibration that I missed that 0.1em in the docs! Thanks for the report - I think this should fix it. Inductiveloadtalk/contribs 11:48, 23 March 2021 (UTC)
Great, now it looks to work as expected, thanks. --Jan Kameníček (talk) 13:06, 23 March 2021 (UTC)

The bot sets the alt parameter e. g. by alt&#61;G instead of the usual alt=G, see e. g. here. Is it intended? If so, is there any advantage? Imo it makes it less comprehensible. --Jan Kameníček (talk) 18:20, 25 March 2021 (UTC)

Darn, I thought I'd caught all those. That was a trip-up in mwparserfromhell because the alt parameter was being set in the {{di}} template, not in the image call. {{di}} doesn't have an alt parameter at all (it's simply parameter 1), so setting the alt parameter there did nothing at all. Inductiveloadtalk/contribs 18:35, 25 March 2021 (UTC)
I see, thanks for explanation. --Jan Kameníček (talk) 21:20, 25 March 2021 (UTC)

Table across two pages

Hello! I saw your Help:Page_breaks#Tables_across_page_breaks and need some help with my pages. I tried to do the poem which runs from Page:An Exposition of the Old and New Testament (1828) vol 3.djvu/28 into Page:An Exposition of the Old and New Testament (1828) vol 3.djvu/29 in the same format as I had done the one at Page:An Exposition of the Old and New Testament (1828) vol 3.djvu/21. I've tried to follow your instructions, but the eight lines of the poem (which are not two separate stanzas) do not line up at An Exposition of the Old and New Testament (1828)/Job. Can you help? : PeterR2 (talk) 10:20, 31 March 2021 (UTC)

@PeterR2: This should not use a table at all. The (current) easiest way to deal with this is to use {{block center/s}} and <poem>:
Page 1
{{block center/s}}
Line 3
Line 4
----------------------↑ Body/footer ↓<
{{block center/e}}
Page 2:
{{block center/s}}
----------------------↑ Header/body ↓<
Line 3
Line 4
{{block center/e}}
Using tables for poems is bad for all sorts of reasons. There is work underway to improve poems, but for now, something like the above works fine. See H:POEM for more information.Inductiveloadtalk/contribs 10:37, 31 March 2021 (UTC)
Thank you! I will try and copy this on the other poem earlier in the volume. I notice that page numbers don't usually cause a break in An Exposition of the Old and New Testament (1828)/Job - is there any way of having the whole eight lines run smoothly without a gap? : PeterR2 (talk) 10:42, 31 March 2021 (UTC)
@PeterR2: I don't see a gap between the halves of the page: What do you currently see? You might need to purge the page. Inductiveloadtalk/contribs 10:46, 31 March 2021 (UTC)
This in Vivaldi: - but yes it looks fine in Firefox and Chrome so don't worry! : PeterR2 (talk) 10:53, 31 March 2021 (UTC)
That's odd: I see this is Vivaldi: And since Vivaldi uses the same engine as Chrome, I wouldn't expect it to behave differently between the two. Are you sure you don't have some kind of customisation setting a margin somewhere? Inductiveloadtalk/contribs 11:04, 31 March 2021 (UTC)

Module:New texts/data

Is this going to be a manual process and reliant on you? If so, that doesn't seem sustainable nor reliable. I would have thought that we could be getting user:Wikisource-bot to do that more reliably. I would have also thought that we could be doing something setting something to be a json page via Special:ChangeContentModel somewhere . I could be dreaming though if we could have something that will scrape an archived line in "new texts" poke into a json file and then remove the line. If we set up the schema, I am happy to go back and convert all the previous years into json pages. The one thing that we will need to allow is updated for disambiguation and moves. — billinghurst sDrewth 00:17, 18 March 2021 (UTC)

While on that, I am guessing that module: ns is not the long term living habitat for the data. Plus if we are recording json data like this, I would love if we could allow to record WD item data number. I think that there is long term value, and we should be able to run queries and bots, and maybe help twittify stuff more readily. — billinghurst sDrewth 00:22, 18 March 2021 (UTC)
@Billinghurst: the idea was to transition entirely to the module, since {{#invoke:New texts|new_texts|limit=7}} provides exactly what you need. Then, there's no archiving needed at all, except for at the end of a year, when you just copy the whole durn thing to the year's archive page. Template:New texts/testcases provides a comparison.
I have (finally) figured out how to inhale JSON. So now the data lives at Template:New texts/data.json, and archived data would be at Template:New texts/data/2020.json etc.
Re The one thing that we will need to allow is updated for disambiguation and moves. this is the same as currently - update the link target (i.e. the title value).
Re Wikidata, it's certainly possible to link to WD. However, due to the number of items, you will not be able to use it to construct pages like Wikisource:Works/2021 if they have more that about 400 entries (and we're on track to break that limit), because that's the limit on how many WD items a single page can load. So we can't fall back entirely onto a list of only Q-numbers, awesome though that would be. With PWB, at least, it's trivial to get the Q-number for a page given the title value, so you can work backwards. Inductiveloadtalk/contribs 10:26, 18 March 2021 (UTC)
Ignorant question. Does the tabular json have any benefit for us mw:Help:Tabular Data as I see it is an available content type. I don't trust users to edit json files, though I wonder at there ability to edit a table. — billinghurst sDrewth 05:01, 13 April 2021 (UTC)
@Billinghurst: I can't get it to work here: do we have the Data namespace turned on? Tables would be useful for lots of stuff (e.g. volume data that Wikidata doesn't seem bothered about). Inductiveloadtalk/contribs 21:23, 13 April 2021 (UTC)
No idea. I was prodding people in irc #mediawiki though no one took the bait. I will prod some other avenues, though might be a "meh". — billinghurst sDrewth 23:09, 13 April 2021 (UTC)

In relation to you periodicals issue, there are a number of library cataloguers at Wikidata, it is just a matter of finding one for the help. I saw someone in the past couple of weeks but for the life of me cannot remember where. You may find someone through Wikidata:Status updates or you could try emailing someone like Ruth and asking for help, or being ask for someone as I am sure that they are a tight community. Let me prod someone on twitter to see if they can point someone to answer the question. — billinghurst sDrewth 23:31, 13 April 2021 (UTC) sDrewth 07:46, 14 April 2021 (UTC)
@Billinghurst: Well I'm suppose I am pleased that I'm not the only one who finds the ontology tricksy. Inductiveloadtalk/contribs 08:02, 14 April 2021 (UTC)
Found them, so pushing from that direction d:User_talk:UWashPrincipalCataloger#May_I_borrow_your_time?billinghurst sDrewth 23:50, 14 April 2021 (UTC)


January starts at 2., then February resets and starts at 3., March resets and starts at 4. Novel, though I am not sure that it is the objective. Can we get the count firstly start at 1 ,and then continue in the next month? Thanks. — billinghurst sDrewth 13:03, 2 April 2021 (UTC)

  Done Inductiveloadtalk/contribs 15:59, 2 April 2021 (UTC)

Problem with refilling Index Page

Just tried your awesome new Refill Index Page link and I got a bit of an oddity. It says [[Author:H. G. Wells|Author:H. G. Wells]]. Shouldn't it be [[Author:H. G. Wells|H. G. Wells]].

Also the Volume is coming out as [[/14|14]] leading to Index:The Works of H G Wells Volume 14.pdf/Volume 14. Shouldn't it be [[%series title%/14|14]]. This is probably a good way of thinking about title vs series title. %title% should produce [[%title%]], Volume %volume% while %series title% should produce [[%series title%/%volume%|%series title% (Volume %volume%)]]

Finally, the edit text says

"You are editing in the Index namespace, see Editing help and Index pages

This page includes a form for entering details about a work. There is a gadget to auto-populate fields from the File: at Commons:."

Shouldn't it say

"You are editing in the Index namespace, see Editing help and Index pages

This page includes a form for entering details about a work. There is a gadget to auto-populate fields from the File:%link to file at commons% at Commons:." Languageseeker (talk) 13:03, 4 April 2021 (UTC)

@Languageseeker: For me, it fills the author as [[Author:H. G. Wells|]], which comes out correct (it's called the Pipe trick).
As I have said already, you should set the title at the Commons page, not the series. The series does not import to the Index page and you have not set any title at all at Commons. So it imports nothing. We do not always place works in a series as subpages of the series, because "series" can be quite a nebulous concept and works within a "series" may well be full-on works in their own right (as opposed to volumes of a single work). For example, The Garden of Eden is part of the New-Church Popular Series but it is a top-level book in its own right.
I have modified the edit notice for Index pages (I actually have that turned off in my CSS to save space, so I haven't seen it for some time!) Inductiveloadtalk/contribs 13:32, 4 April 2021 (UTC)
Index:The_Works_of_H_G_Wells_Volume_14.pdf Looks better, but I'm still getting the problem with the Author. Also, right now, we have two different links for the transcluded text: ''[[The works of H. G. Wells]]'' and [[The works of H. G. Wells/Volume 14|Volume 14]]. Shouldn't we just keep the second?
Also, the links does not go to Commons directly. Could it go to Common directly? Languageseeker (talk) 14:00, 4 April 2021 (UTC)
@Languageseeker: OK, that was bizarre, the JS was being pre-processed with the Pipe trick. Should work now.
The link now goes directly to Commons.
We usually have a link to the top of the work (in this case, it would be a volume list of the 28 volumes) and a link directly to the volume transclusion. E.g. Index:EB1911_-_Volume_01.djvu. Inductiveloadtalk/contribs 14:34, 4 April 2021 (UTC)
Works beautifully. Thanks Languageseeker (talk) 14:45, 4 April 2021 (UTC)
  Done Languageseeker (talk) 15:30, 4 April 2021 (UTC)

Batch Import Periodical or External Scan Link

I've noticed that there are a lot of pages, such as The Atlantic Monthly where there are {{ext scan link}} suggesting that users might find it troublesome to manually import dozens of volumes even if they are able to find the links. Would it be possible to batch import them and set up the template for the volumes? Languageseeker (talk) 13:50, 4 April 2021 (UTC)

It's possible, but gathering all the requisite metadata and makes it a little more labour-intensive than you might think. At the least, you would need, for TAM, for each volume:
  • The date range: e.g. November 1857 – May 1858
  • Publication year (e.g. 1858)
  • IA or HT ID (ideally IA because then you don't need to mess with reconstructing a Hathi scan, which takes a long time)
  • City (probably always Boston?)
  • Publisher if known
  • The license (easy up to 1926)
  • The Commons category (e.g. commons:Category:The Atlantic Monthly, 1858)
None of it is hard, just a bit of a faff. I use a spreadsheet to generate commons files and Index pages. Then it's just a matter of battling the Commons uploader API which is having a bit of a sulk at the moment. Inductiveloadtalk/contribs 14:20, 4 April 2021 (UTC)
Perhaps, we can do something like {{ext scan link|url|desired name}} and pass that off to the IA upload tool? If the file appears on Common, then change to {{small scan link|desired name}}. Then we wouldn't have to worry about guessing the file name, creating the Index Page, or bad index pages. Then this tool would become a sort of auto-filler for the IA tool. It would also be useful in cases when the IA tool failed so that the uploads could be retried automatically. What do you think? Languageseeker (talk)
That would need support from the IA-Upload tool which is in various degrees of broken-down-itude at any given time. A way to prefill with a URL like "" would be handy, for sure, and I have wished for it before (but not hard enough to figure out how to install and hack on the tool....yet). Also with a little bit of care, you can do better than blindly upload from the IA using their terrible metadata, like, for example, putting the dates covered in the description. Inductiveloadtalk/contribs 14:41, 4 April 2021 (UTC)
It might be possible to just borrow code from the IA tool because lots of it wouldn't be needed. Basically, get the URL, build the link to the PDF, URl2Commons, import metadata. A new, simplier IA upload tool with no GUI and no user interaction. Languageseeker (talk) 14:53, 4 April 2021 (UTC)
@Languageseeker: It would be a nice trick, and probably not that hard. But it'll still suck up the IA's rubbish metadata and dump the files in a generic category, whereas I think you could ideally do a bit better than that. Not least, with a bit more care, you can create the Index page too, which you cannot do with Url2Commons.
It's on my list to enable a better batch upload system for Wikisource, but the list is long and the days are short. Inductiveloadtalk/contribs 14:58, 4 April 2021 (UTC)
I know that you're swamped and there is way too much to do. Would it be possible to set up a vote on feature requests? Maybe one month for proposals and then a ranked vote?
I know that metadata is not the greatest on IA, but it often requires manually editing. No tool will ever fix incorrect or absent metadata. However, trying to upload 95 volumes manually takes hours of just staring while tasks run in the background. It would take less time to batch upload and then fix metadata manually. Maybe, it would be possible to just borrow code from Fæbot? Languageseeker (talk) 15:06, 4 April 2021 (UTC)
IME, it's much quicker to set all the metadata in a big ugly spreadsheet and then upload it all in one go (staring at the terminal is strictly optional). Opening and editing 95 file pages and 95 index pages (or fiddling with a bot to make the changes retroactively) is not very exciting.
I plan to post my uploader script at some point (a point where it isn't full of API keys and imports of random modules from various places). "One day" it might morph into a full-on toolforge tool, but that needs UI and all sorts of bulletproofing.
Voting on feature requests is all very well, but you still need someone to do them. Comm Tech is already being nice to us with the exporter and OCR projects, and there are not many people "into" the JS/Tools side of things. Most of the tools have been rotting for years: half the existing gadgets don't work as promised. Inductiveloadtalk/contribs 15:20, 4 April 2021 (UTC)
Uhm. Uploading and adding an index for 95 volumes is one thing. What takes effort is verifying that all pages of all 95 volumes are present and legible. Just mirroring IA is something a bot can do at any time. --Xover (talk) 12:46, 5 April 2021 (UTC)
@Xover: indeed, which I why I'm not on a multi-thousand volume mass upload spree, because locating the good scans and filling in metadata is more work that actually pressing the button on a list of 95 IA IDs and using their awful metadata without even checking.
On the other hand, the IA (or HT) pagelists (e.g., or a local equivalent) help a lot because if you see this:
then you know that volume is very likely complete, because the numbering is continuous right to the end (actually, you normally know that earlier: as you see a non-BW-Google scan). So that helps a bit. Inductiveloadtalk/contribs 13:30, 5 April 2021 (UTC)
I’m not advocating on going on a uploading spree, but making uploading faster and easier is something that can benefit users. On one hand, IA and Hathi Trust have many duplicates that we don’t need. Also, nobody needs to proofread a reprint that has no illustrations, author input, or scholarly value. We’re a curated collection not donations in a box. Curation takes time. However, every user has a limited amount of time. Do we want to spend their time doing something that a bot can do or on something that a bot cannot? A bot can upload 95 volumes, but it cannot verify the completeness of a work. With such a bot, I can go to IA, find the best scan, set up the links on the Author page, press save, and the then do something else. In a day, the files will be there and I can proceed to set up the index pages. Languageseeker (talk) 14:55, 5 April 2021 (UTC)
BTW, I’ve seen plenty of incomplete non-Google scans especially from the LOC. Hathi Trust has a feedback button that we can use to report missing pages. Languageseeker (talk) 14:57, 5 April 2021 (UTC)

Media matters

cf. this. It occurs to me that we may well still have files referenced using the Media: prefix. I run into them now and again, so the odds someone stuffed one into {{di}} somewhere is at least non-zero. --Xover (talk) 12:41, 5 April 2021 (UTC)

  Done (but AFAICT none found so far), also for Image which indeed had a few. Inductiveloadtalk/contribs 07:41, 6 April 2021 (UTC)

{{FIS}} is broken

Hi. The {{FIS}} introduced paragraph breaks before and after the image. I used this template hundreds of time to offset images where the text is supposed to flow around without a break. — Ineuw (talk) 13:58, 5 April 2021 (UTC)

@Ineuw: A link to an affected page would be handy. Inductiveloadtalk/contribs 14:04, 5 April 2021 (UTC)
Apologies, Page:The_Rise_of_the_Russian_Jew.djvu/1.— Ineuw (talk) 14:07, 5 April 2021 (UTC)
The problem is {{fs85}} is a block element. FIS is a span, but if you put a div inside, it'll break the surrounding paragraph. Inductiveloadtalk/contribs 14:15, 5 April 2021 (UTC)
This is a very belated thank you. I didn't forget, it's just that I was embarrassed about the number of stupid problems requesting help for around that time. Thanks again for all your help.— Ineuw (talk) 01:47, 11 April 2021 (UTC)

Script Request... Recent Activity warning...


Would it be possible to have a script that adds as bar to the top of pages, that indicates a page has been edited recently, or that there is a 'frequency' of edits to related pages?

The thinking here is that as it can take some time to setup or edit certain pages (like Index pagelists), if you have other 'fast' editors, there is a high potential for edit conflicts, which for long-term contributors can become a frustration. A warning about recent activity can potentially avoid these.

I am not sure how plausible it is to have a mechanism during the loading of the Edit page, which warns about potential edit conflicts, before you even start editing a page though.. Not sure if the edit requests are tracked in an accessible way that would make somthing like a "X is already editing this page..." the way Discord has a "X is typing..." warning in near real-time..

ShakespeareFan00 (talk) 23:05, 5 April 2021 (UTC)


  mw.hook( 'active_page_alert.config' ).add( function ( apa ) {
    apa.cfg.userLimits = [
          user: 'SomeUser',
          timeLimit: 120
  } );

Bit a help with Template needed

Can you help me out with {{The_works_of_John_Ruskin}}. The volumes are 01, 02, etc. Languageseeker (talk) 23:10, 6 April 2021 (UTC)

For {{The collected works of Henrik Ibsen}}, volume 1 is a pdf.
@Languageseeker:   Done × 2. Inductiveloadtalk/contribs 23:14, 6 April 2021 (UTC)

Common Link to Small Scan Link

Is is possible to convert all {{Commons link}} to {{small scan link}}. This seems to be an ancient way to say that the file for proofreading exists on Common, but we now have Proofreader Page. Also, why do is there {{small scan link}} instead of {{scan link}}? Seems like extra typing for nothing. Languageseeker (talk) 00:46, 7 April 2021 (UTC)

@Languageseeker: {{Commons link}} link just means there is no Index page (yet), normally you skip that and go right to a scan link. Make an index page and you can change to a scan link. You can use {{ssl}}, or even User:inductiveload/save load actions if you want. Or AutoHotkey or similar. Inductiveloadtalk/contribs 00:51, 7 April 2021 (UTC)

Problem with Small Scan Link and multi volumes that do not start with 1

I'm having a problem with {{small scan link}} where if I don't set the first volume to 1 it throws Lua error: At least an Index page is required. For multi volume series, such as the Complete Works of John Ruskin at Author:John_Ruskin, there are cases where the first volume is not actually 1. Languageseeker (talk) 00:50, 7 April 2021 (UTC)

{{ssl}} contains the instructions for that case: use the nameN parameters. Inductiveloadtalk/contribs 00:52, 7 April 2021 (UTC)
What's the syntax for nameN? I don't see any examples on the template page. Languageseeker (talk) 01:02, 7 April 2021 (UTC)
@Languageseeker: (What have you tried?) Inductiveloadtalk/contribs 01:05, 7 April 2021 (UTC)
I tried {{small scan link|vol3=The_works_of_John_Ruskin_(IA_worksofjohnruski03rusk).pdf}} Languageseeker (talk) 01:06, 7 April 2021 (UTC)

Better Footnotes

I noticed that when transcribing footnotes, there is currently no way to preserve the original reference. Instead, Wikisource creates a new numbering scheme for footnotes that has no basis in the original text. See, Page:The_New_Monthly_Magazine_-_Volume_101.djvu/74. Is there anyway to create a template to override these? Perhaps something like this


For example,

To Godstowe's glade;{{footnote|<ref>See ''Reginald Dalton.'' Book iii. chap, v.</ref> and hallows all the scene<br />|*}}

which would transclude to

To Godstowe's glade* and hallows all the scene

Page 62, *: See Reginald Dalton. Book iii. chap, v.

Languageseeker (talk) 01:18, 7 April 2021 (UTC)

@Languageseeker: We don't try to reproduce the original footnote numbering exactly, see Help:Footnotes_and_endnotes. Inductiveloadtalk/contribs 01:40, 7 April 2021 (UTC)
Is there any particular reason why not? It seems like a fairly big change to alter the way that notes are referenced. Languageseeker (talk) 01:48, 7 April 2021 (UTC)
I don't know exactly, but it pre-dates me. I'm sure you could dig up discussions on the Scriptorium. Inductiveloadtalk/contribs 01:49, 7 April 2021 (UTC)
It seems like a fairly controversial topic that comes up fairly regularly. User:EncycloPetey and User:billinghurst are against it while other keeps on requesting it. Their main concern appears to be that it makes footnotes lose their distinctiveness when transcluded. However, can we not preserve them when transcluding by including the page number? With the community fairly divided on this, would it not be better to put this up for a vote? Languageseeker (talk) 02:06, 7 April 2021 (UTC)
Because we are converting from footnotes to endnotes, and works we do are typically footnotes that restart each page, many do not scale, and have seen endnotes with over a 100 count sources. PLUS we have a house-style and numbers would appear to be the consensus (and it pre-dates me too). Otherwise, I don't see that it is anything of particular concern a citation is a citation, and a house-style is a house-style. — billinghurst sDrewth 07:58, 7 April 2021 (UTC)
@Billinghurst: The issue is that it is hugely inaccurate and a fairly large modification of the source text. I can understand converting footnotes to endnotes, but renumbering footnotes makes them impossible to reference. If a book had Page 15, †, then it's incorrect to say that this is footnote 27. It seems that the consensus occurred many eons ago before Proofread Page existed and now we can easily format them correctly. Maybe it's time to revisit this if it's become technically possible and easy to do this. Languageseeker (talk) 12:47, 7 April 2021 (UTC)
If someone truly needs the number from the original source, they have access to the scan page by simply clicking on the page number in the margin. If the original source is using symbols, where the same symbol is used repeatedly for the first footnote on every page, then reproducing that will mean many, many footnotes all marked identically, which is useless in an electronic format. --EncycloPetey (talk) 13:06, 7 April 2021 (UTC)
(ec) The conversation doesn't particularly belong on a user talk page. But do tell me which of the 22 *, 13 †, 8 ‡ or the seven 22 1s, 13 2s, 8 3s you think should stay the same when they become endnotes? Tell me that you would like to see the split references remain split as they come from different pages. There is nothing wikt:inaccurate, let alone hugely inaccurate, so please stop the rhetorical flourishes; the refs are automatically generated and they accurately reflect the text and position of the reference that is in the work. Show me one _inaccuracy_ on a properly formatted and proofread page. — billinghurst sDrewth 13:08, 7 April 2021 (UTC)

IA Scan Link Template

It turns out that there's a {{Internet Archive small link}}. Could it be improved so that if the file exists on Common, it acts as a small scan link and if not, it redirects to IA?

For example,

{{Internet Archive small link|newvoyageroundwo01damp}}

would check if {{Internet Archive link|newvoyageroundwo01damp}} exists on Commons, if so and filetype is PDF or DJVU, it would act as {{ssl|A new voyage round the world. - Describing particularly, the isthmus of America, several coasts and islands in the West Indies, the Isles of Cape Verd, the passage by Terra del Fuego (IA newvoyageroundwo01damp).pdf}}

if not, then it would go to the current code

<span title="Copy of this work at the Internet Archive" style="font-size: 83%; white-space:nowrap;">([{{{1}}} IA])</span>

This should help users avoid having to try to upload the file through the IA tool only to find out that the file already exists because someone already uploaded it which is a colossal waste of time. Languageseeker (talk) 13:03, 7 April 2021 (UTC)

@Languageseeker: AFAIK there is no way to get the filename of a PDF or Djvu with a given IA ID in the info via Lua, and that means you can't do what you want. At best you could write a gadget to flag up "stale" Commons links in JS (e.g. make them red or whatever) and suggest a replacement. There are only 60 transclusions of {{Commons link}} (it's not a very common template), so I think this is not a very exciting prospect. If you're going to go around tagging with {{Commons link}}, you might as well use {{ssl}} and set up the index while you are at it. Lua is limited to mw:Extension:Scribunto/Lua_reference_manual. Inductiveloadtalk/contribs 13:22, 7 April 2021 (UTC)
Oh ok. So you can do File -> Get Metadata, but not Find Metadata -> get File? Languageseeker (talk) 13:39, 7 April 2021 (UTC)
Pretty much, yep. You can do it in JS (presumably aping however the IA-Upload tool detects matching IDs), but not, AFAIK, in Lua (remember that gets pre-rendered by the server on save - if it does a search as part of that, how will the server know when to re-render if, say, you upload a matching file?) Inductiveloadtalk/contribs 14:06, 7 April 2021 (UTC)

"We're all mad here."

Ok, so one issue we will have to solve once and for all with ppoem is separator / elision lines.

Starting somewhere completely different, I've fallen into what seems to be an endless rabbit hole where we're using {{loop}}, {{

      • }}, {{}}, {{separator}}, and probably a few more I've not had the misfortune to meet yet, plus manually spacing out asterii, dots, and middots with nonbreaking spaces.

So far I haven't really thought much about the solution; but I've concluded this is definitely a problem, and one that rises to "ppoem must deal well with" through the combination of this being difficult to solve inside ext:Poem and the relative high frequency of appearances of such lines in poems in general.

I'm currently mulling over ways to fix and merge (or replace) various subsets of the above templates for this purpose, but the though has also occurred to me that "it sure would be nice" to support it directly in ppoem. That way probably lies madness due to the number of knobs people can, and do, tweak with the existing templates, but I'm throwing it out there in case you see a potential for a clean solution where I can't. But however we approach it, I want to say the goal should be that once ppoem deploys generally there is One True Way™ to do such lines inside a ppoem, that is well documented, and all other ways should be avoided. --Xover (talk) 13:27, 7 April 2021 (UTC)

@Xover: I want to say flex box, but I'm unsure if that will export in any kind of sane way. Inductiveloadtalk/contribs 14:07, 7 April 2021 (UTC)

'New' math....

There seems to be a bot that updates formulae using MATH tags to resolve some issues, See

Could something like the bot there be implemented here ? ShakespeareFan00 (talk) 18:34, 7 April 2021 (UTC)

@ShakespeareFan00: I'd certainly hope that they'll provide the fixes as needed with their bot. Is there any indication we have any issues manifesting at enWS? Inductiveloadtalk/contribs 13:03, 10 April 2021 (UTC)
There may be a few affected pages. ShakespeareFan00 (talk) 13:12, 10 April 2021 (UTC)

The Complete Poems of Paul Laurence Dunbar

Thank you for your awesome work on The Complete Poems of Paul Laurence Dunbar. Languageseeker (talk) 00:32, 8 April 2021 (UTC)

Sword Blades and Poppy Seed in Author:Amy Lowell

Can you help clean this up so that it doesn't spam the PG category? Languageseeker (talk) 01:10, 8 April 2021 (UTC)

@Languageseeker:   Done Inductiveloadtalk/contribs 01:47, 8 April 2021 (UTC)
Thanks Languageseeker (talk) 03:05, 8 April 2021 (UTC)

Metadata not loading

I'm having a strange problem affecting The Works of Charles Dickens where the metadata is not loading from Commons. It's basically all the red links on this page. When I tried to add Index:Works of Charles Dickens, ed. Lang - Volume 28.djvu and then reload the index data, it still didn't work. Languageseeker (talk) 00:48, 9 April 2021 (UTC)

@Languageseeker: The Commons page doesn't use Commons:Template:Book, that's why. The metadata filler takes the information from the Book template - if it's missing, there's not much it can practically do. Inductiveloadtalk/contribs 00:53, 9 April 2021 (UTC)
Thanks. I fixed the metadata. Languageseeker (talk) 02:14, 9 April 2021 (UTC)
@Languageseeker: I don't think this really counts as "fixing" something. The metadata is now substantially worse. For a start, the title is wrong, there's no author and you've trashed the categorisation. That template wasn't used for no reason. The title of the work is The Works of Charles Dickens, the title of the volume is American Notes and Pictures from Italy. I think you need to be a bit more circumspect when storming into "fixing" "problems". In this case, filling in the Index page metadata manually would have likely been the easier way forward. Inductiveloadtalk/contribs 02:28, 9 April 2021 (UTC)
Better? Languageseeker (talk) 04:55, 9 April 2021 (UTC)
@Languageseeker: Marginally, but still not as good as it was. Why did this even need changing at all? Just so you could do a one-off import with a helper gadget at Wikisource? Now that's done, what's the point of leaving the page worse off than before you changed it? Inductiveloadtalk/contribs 06:49, 9 April 2021 (UTC)
I cleaned it up a bit more. My overall goal is to replace the needless non-standard template with a standard book template. It's not like the metadata was that great in the first place. Languageseeker (talk) 14:33, 9 April 2021 (UTC)
@Languageseeker: It was better than it is now, and it's not exactly hard to see where. The editor is still missing, you have mixed up the subtitle, the volume title and description, you have mixed up "location" and "city" and you have not replaced the category that the template added and removed the language tagging. Please either put it back how it was, or if you want to use the book template, make sure there is at least the same metadata there was before and in the right fields. Inductiveloadtalk/contribs 16:22, 9 April 2021 (UTC)
Um, the incorrect publisher on Vol 28 was not actually the result of my edit. I looked over your template on Commons Template:Works of Charles Dickens volume and I noticed some issues. The major one is that the documentation for the Book template states that Volume should be a number while you have a text field (Volume={{{volume}}}: {{{title}}}). So, I believe that it might require fixing. I’m also not sure why you made City={{{location|}}} instead of City={{{city|}}}. Seems a bit confusing and this is causing an issue when changing it to the book template. In my edit, I put “With Introduction, Notes and General Essay by Andrew Lang” into the Description field so that the subtitle could be the name of the work. I don’t see a volume title in Book. I’m happy to revert if you fix your template to follow Commons guidelines, make sure that it can work on importing, and apply it to all the volumes. Otherwise, it seems to me that reverting the changes would just return us to a broken
"Um", you have done the import already, so that's specious. Also there is zero exception that the Commons info needs to conform itself to whatever rudimentary heuristic the Wikisource helper script uses. If the script doesn't work, just deal with it and enter it manually. It only needs doing once anyway.
I don't know why city → location, but it's not that confusing if you just check the page before you save it. If you want to use Book, whatever, I have no issues with that, but breaking stuff to put pressure on to fix things you don't like is not constructive. Just compare what it was and what it is. There is still missing data. If you care so much about the volume title not having a dedicated field, you should raise the issue at commons:Template talk:Book (and get involved in fixing the issue, not just drive by with "um, this is not how I like it kthxbai") and not just abuse the description field (which is for "out of band" information like physical condition or whatever) and move on, leaving messed up stuff in your wake that someone else has to deal with. Thousands of books have a volume title there. If you want to go on a mission to add a volume title field and tidy them up, into more a more semantic field, fine, I'd even say that's a good idea. But until then, leave things strictly better than you found them, and I think we can all agree that how you intended to leave it is not better than how it was. Inductiveloadtalk/contribs 12:58, 10 April 2021 (UTC)
Let’s bury the hatchet on this one. I never meant to make things worse. I might have been a bit hasty and didn’t realize that was a custom template and not just a user error. I tried to fix this it, but it didn’t seem to work out. I respect you and what you do for this site too much to want to create bad blood or hurt feelings% Languageseeker (talk) 05:36, 12 April 2021 (UTC)
  (or socially-distanced equivalent). I have raised a query on commons:Template talk:Book about adding a volume title, because you are right in that forcing the volume number and title into one field is not ideal.
I sorry if I came over as sharp. I have no intrinsic desire to keep a work-specific template over Book, BTW, I just would like to make sure that there is strictly no less metadata. Ideally, of course, all the bibliographic info (as opposed to file specific) should be pulled from some structured data "somewhere" (Wikidata/Commons SDC/something else?) but I have no idea what that should be, and I don't have enough clones of myself to really dig into it right now, let alone embark on some mission to improve all the literal millions of books at Commons. Inductiveloadtalk/contribs 07:26, 12 April 2021 (UTC)

Help with Splitting Images and Creating DJVU

Can you help split the images in Paradise Lost 1674 and create a DJVU out of them? Languageseeker (talk) 02:14, 9 April 2021 (UTC)

If you could use ScanTailor or similar to prepare a set of split images, I'll run it through the DJVU/OCRifier. Inductiveloadtalk/contribs 02:36, 9 April 2021 (UTC)
I'm not very good with batch jobs. This guy uploaded 32 rare books without splitting the pages and it would be great to do them all [2], but I lack the technical skill. Languageseeker (talk) 05:25, 9 April 2021 (UTC)
@Languageseeker: It's not a batch job as such, ScanTailor is for processing scan images (e.g. splitting, etc). Give it a try before saying you can't do it.
I'll make 32 DjVus from 32 zips of images because I know that's quite hard and until I can get round to publishing the code and/or making a web-based tool others may not be able to do it easily. But doing 32 end-to-end extract/splits and making the DjVus and doing all the metadata for upload "on spec" is more than I have time for, sorry. Inductiveloadtalk/contribs 07:03, 9 April 2021 (UTC)
No worries at all. I appreciate you looking into it. Languageseeker (talk) 20:25, 9 April 2021 (UTC)

author template/module picked up a comma section <-> contributor ?

Maybe I am losing it, though I don't remember that we had a comma between the section name when we used contributor as shows at McClure's Magazine/Volume 9/Number 1/May. Would you be so kind to recheck, and if we didn't can we please head that way. Thanks. — billinghurst sDrewth 11:29, 10 April 2021 (UTC)

@Billinghurst:   Done . Inductiveloadtalk/contribs 12:23, 10 April 2021 (UTC)

A Little Help with a template

I'm trying to create {{IAu}} to simplify uploading to Commons from IA. It basically takes the three parameter that IA upload tool needs and constructs a url from them: {{IAu|Internet Archive ID|Common File Name|pdf or djvu}}. However, I'm running into an issue where

{{IAu|jesuitrelations169jesugoog|59|pdf}} works, but

{{IAu|cu31924092218191|The Jesuit relations and allied documents (Volume 27)|pdf}} doesn't.

Anyway you can take a look? Languageseeker (talk) 15:42, 12 April 2021 (UTC)

@Languageseeker: The problem is Parameter 2 has a space in it. This means the link is: [ Jesuit relations and allied documents (Volume 27)&format=pdf Upload ...], which turns into a link with the URL "" and the text "Jesuit relations and allied documents (Volume 27)&format=pdf Upload ...".
The solution is URL-encoding the URL parameters: like this. Inductiveloadtalk/contribs 15:56, 12 April 2021 (UTC)
Thanks! Languageseeker (talk) 02:29, 13 April 2021 (UTC)

with new per index css

I am guessing that with the new css setup, that we can stop doing per row align right like in Page:A catalogue of notable Middle Templars, with brief biographical notices.djvu/293 and do something with td:nth-child or per column. If we can, could you create something in Index:A catalogue of notable Middle Templars, with brief biographical notices.djvu/styles.css and I can take it from there. Guessing that we are creating classes. I know that we looked at it many many years ago however our css was too dated at that time. It will definitely make for simpler coding at a work level. Thanks if you can help. — billinghurst sDrewth 07:31, 14 April 2021 (UTC)

@Billinghurst: There you go! Mostly just a regex replace for things like {{ts|ar}} and making the letter headings into headers (using !). Inductiveloadtalk/contribs 07:43, 14 April 2021 (UTC)
If we can set the last or the right-most column what are your thoughts on a global class of align last column right? It is common enough to make global, and people set all the other formatting as needed around it through a work's css. — billinghurst sDrewth 11:11, 14 April 2021 (UTC)
So global table classes is something I have thought about for a very long time. {{table class}} (not my work) attempts to deal with some of the common cases. The issue is a multi-way balancing act between simplicity of expression, simplicity of markup, simplicity of implementation/maintenance and robustness.
I have some concerns with how {{tc}} is implemented, e.g. because classes like _bt are basically just an indirect way to say {{ts|bt}}. CSS shines where we can leverage selectors like descendants and :nth-child. For example __grid is something that cannot be done without very verbose inline styling.
There's also a risk of de-semanticising (ironic use of a non-word intended!) things as well as providing a wide surface for fragility. For example, the following would render the same:
{| class="somework_somedata"
|... index CSS provides the grid and margin:auto rules here, which apply to the "_somedata" type of tables.
{{table class/import}}
{| class="__grid __floatc"
However, the latter is a stylistic intent (basically used as a shorthand for hundreds of {{ts}} calls), while the former is a semantic statement of the form "this table is a somedata table" and the styling is a natural consequence of that, with the class identity→styling mapping performed by the index CSS on a work-local basis. Which is perhaps a slightly sophistic argument, and out-of-touch with how we currently do things (mostly out of technical necessity) but I think it's certainly one to bear in mind before we storm ahead and scatter-gun thousands of quasi-global classes into tables all over the place.
To take the Templars index as a more concrete example, the question is do we prefer having a complete semantic→styling mapping in the index CSS (as we do now, more or less) or write something like class="last-col-ar heading-larger-centered margin-auto" and compose the styling out of many pre-made blocks (and still if anything can't be an off-the-shelf class we'll need to use index CSS to fill in the gaps).
Inductiveloadtalk/contribs 16:48, 14 April 2021 (UTC)

"The World and it's People"

You uploaded Vol 12 recently, so I created {{World and its People}} In case other volumes got uploaded by other contributors.

I note about 12 volumes in the series? ShakespeareFan00 (talk) 10:16, 14 April 2021 (UTC)

@ShakespeareFan00: Lol, that was a random upload to test IA-Upload could duplicate a PDF! Inductiveloadtalk/contribs 16:51, 14 April 2021 (UTC)

Auto advancement. Of POTM

Just wondering how long it normally takes the POTM to advance once the current one is fully validated. Languageseeker (talk) 15:57, 15 April 2021 (UTC)

Until someone changes the current value to something greater than 1. And before you ask, I don't really think this should be automated, because even if the index is validated, it may not be transcluded properly. With great care you could make an attempt at using the index page info like {{index transcluded}}, but since I'm sure there'll be ways for that to fall over in hilariously unforeseen ways and go unnoticed, it's probably easier to just change current manually. Inductiveloadtalk/contribs 17:18, 15 April 2021 (UTC)
You know me too well. Seems my mind was confused. Hope good progress will be made on one of the greatest poetic works of the Harlem Renaissance. Languageseeker (talk) 19:28, 15 April 2021 (UTC)

Help Scrapping Books from BL

I was wondering if you knew of any easy way to scrape all 127 quartros off the BL. The link is [3]. Then it goes to{{id}}&page=1 Languageseeker (talk) 03:53, 17 April 2021 (UTC)

You can scrape the images via the URL like Only the last number needs to be changed. With a bit of experimentation, you may be able to figure out the maximum page count, or just iterate until you hit a 404. For determining the ham-1603-22275x-bli-c01 "slug" for each work, you can load the PageMax.aspx page and pick out out the #uiPageImage element.
As before, ScanTailor is the tool of choice for splitting and de-skewing the double-page photos. Inductiveloadtalk/contribs 11:16, 19 April 2021 (UTC)
Thanks for the advice, but that sounds a bit too technical for me. I don't know what slug is. I tried using scan tailor, but it produced a mess. I tried to automatically select the images and set uniform margins and produced a horribly degraded result. Languageseeker (talk) 20:14, 19 April 2021 (UTC)

Review Activity of Billinghurst

Can you please review the activity of Billinghurst on Hamlet (Shakespeare). Not only has he removed valuable external scan links, but he's also removed existing scan links. Languageseeker (talk) 03:00, 18 April 2021 (UTC)

Also, this comment he left on my talk page. User_talk:Languageseeker#You_are_all_over_the_place._Finish_your_works. Such conduct would be considered abusive when coming from a user let alone an administrator. Languageseeker (talk) 04:38, 18 April 2021 (UTC)

Beware the Jabberwookie!

The first line of the first stanza.

This line belongs to no stanza.
Neither does this.

But this gets a shiny new stanza.
So long as we don't tickle the Jabberwookie.
It is much worse than the Jabberwock,
since it will wrap you up in peas.

I don't think, offhand, that this is fixable. So workarounds that come to mind are either magic syntax or a fake hr specifically for ppoem that uses markup that will not anger the Jabberwookie. Having also looked (very slightly) at {{}} and {{

      • }} in ppoem lately, I'm inclined to think we may need a small suite of the most common stuff specifically for use in ppoem, as an alternative to magic syntax.

PS. It also just occurred to me, that if we're to look at the extension route, the natural place to start is going to be SyntaxHighlight rather than poem. --Xover (talk) 06:45, 19 April 2021 (UTC)

@Xover: making the stanza a div helped (a bit), but HR inside SPAN is not quite right. Perhaps we should have a magic syntax to drop a line right out of a stanza and start a new stanza after it? Inductiveloadtalk/contribs 09:43, 19 April 2021 (UTC)
When the rule is being used as a separator, sure; but here it conceptually is a line. I'm thinking what we need is a line span that just happens to display something that is visually indistinguishable from an actual horizontal rule.
The first line of the first stanza.
This is line three of the stanza.
“Hi there, I'm Stanza 1.4.”

Along those lines. All these types of rules might also need a smaller line-height to look balanced with the lines containing full-height characters. --Xover (talk) 10:03, 19 April 2021 (UTC)
@Xover: how about just {{bar}} then:
The first line of the first stanza.
Keep going...

Inductiveloadtalk/contribs 11:04, 19 April 2021 (UTC)
Yeah, that's what I'm doing but bar has… other issues.
Random thought: a special kind of line, a "separator line", that has a smaller line-height, but is most likely going to be populated by a specific template (like bar) rather than by magic syntax? Not at all sure it's worth the effort and complexity, but… --Xover (talk) 13:17, 19 April 2021 (UTC)
@Xover: hmm, fundamentally such a thing can be done with the line class, so it could be {sep} ———.... BTW, which page is "type specimen" for this? Inductiveloadtalk/contribs 13:20, 19 April 2021 (UTC)
this. And class would presumably do the job just fine. --Xover (talk) 13:49, 19 April 2021 (UTC)
And speaking of, what's your thought on the canonical way to tweak or disable the hanging indent? 4em is a bit aggressive for this use, and some bits should have none. --Xover (talk) 13:52, 19 April 2021 (UTC)
I guess we could do it as a class on the whole ppoem (and/or per stanzas. Since it's an effect on the line, the selector .ws-poem-no_indent .ws-poem-line would work in either case. The DI special-casing would need handling as well.
Sometimes I kinda envy the typesetters of yore who could just put a letter in the right place in the chase and pack it out with reglets. Inductiveloadtalk/contribs 14:03, 19 April 2021 (UTC)
Oh, I figured you had an idea of how that should be done. I'll try futzing with pre-defined classes and see how that feels. No indent is probably a shoe-in, but differently hanging indent quickly runs into the {{ts}} trap. {{hin}}, if it doesn't interact badly, may be it; otherwise the threat of magic syntax starts looming.
Yeah, traditional typesetting and layout have some definite advantages. And it's not helped particularly by us sitting squarely in the "sweet" spot where we get all the indeterminism and quirks without very much of the dynamism and flexibility. But ppoem raises the bar there, so there's certainly hope for the future. --Xover (talk) 15:04, 19 April 2021 (UTC)
@Xover: A built-in for no indent sounds like a good idea, and maybe 2em might make sense. After that, it probably makes sense for users wanting unconventional indents to supply their own classes, or Template:Ppoem/styles.css will look like a kitchen sink warehouse on stock-take day. Inductiveloadtalk/contribs 15:25, 19 April 2021 (UTC)

broken index page <= config

Index:The character and extent of air pollution in Leeds - (A lecture delivered before the Leeds Philosophical Society, on March 3rd, 1896.) By Julius B. Cohen (IA b21534160).pdf has a red link on the status, and you have a double category naming. — billinghurst sDrewth 12:48, 19 April 2021 (UTC)

@Billinghurst: it looks OK to me (, even with a purge? Maybe it was a transient thing while the template and module switched over control of the status? Inductiveloadtalk/contribs 13:15, 19 April 2021 (UTC)
No obvious breakage here either, for whatever that's worth. --Xover (talk) 13:18, 19 April 2021 (UTC)
But Index:The Cruise.pdf shows up with redlinked status and a borked category. --Xover (talk) 06:55, 20 April 2021 (UTC)
@Xover: looks OK to me? It could have been borked for a few minutes yesterday - cached? Inductiveloadtalk/contribs 07:21, 20 April 2021 (UTC)
It was edited by an IP in the interrim (very strange coincidence), which would have reparsed it. --Xover (talk) 08:09, 20 April 2021 (UTC)
IP was SFan not logged in. Beeswaxcandle (talk) 17:19, 20 April 2021 (UTC)

Transclusion status bot run

I'm seeing instances where there is a transclusion template with "yes" and the template is replaced with status marked, but other situations where there is a template that is not removed and the information is not transferred.

In particular, situations where there is a duplicate half-title page (or something similar) that is deliberately tagged and categorized as "not transcluded". Does the bot make a strict check that does not allow for these situations? --EncycloPetey (talk) 03:28, 21 April 2021 (UTC)

@EncycloPetey: Pages should not be affected - this is index templates only. The bot makes no decisions, just copies the status from {{index validated date}} or {{index transcluded}} to the Index page field. Can you link a page you think it has not removed a template? Inductiveloadtalk/contribs 03:48, 21 April 2021 (UTC)
Oh, I take it you mean Index:Shakespeare's Sonnets (1923) Yale.djvu? I didn't think there were any using "X" and also the templates, since that was a short lived "temporary" state. I'll run though and check that (small) batch. Duh, sorry, I've thought of that - any "duplicate" templates will be hoovered up as the two old templates get converted. For a short period, a very small number of pages (~10 I estimate, out of ~13k) may have more than one category. Inductiveloadtalk/contribs 03:50, 21 April 2021 (UTC)

That killed my Watchlist. #Killed not killed — billinghurst sDrewth 12:54, 21 April 2021 (UTC)

@Billinghurst: #sorrynotsorry, at least it has a bot flag :-D You want to do the honours and kill off the templates? Inductiveloadtalk/contribs 16:50, 21 April 2021 (UTC)
All respective pages have text updated to reflect dropdown field in Index: page. Templates removed. I will let you tell the community of your great progress. — billinghurst sDrewth 05:40, 22 April 2021 (UTC)

Could you review a proposal?

I’ve been working on a proposal to improve the tooltip system used on wiki source. My draft proposal is at user:Languageseeker/popup. I was wondering if you could review the feasibility/desirability/clarity of my proposal. Languageseeker (talk) 18:10, 21 April 2021 (UTC)

@Languageseeker: I understand where you are coming from. I don't really have the bandwidth to deal with this in detail, but your proposal probably needs to focus a bit more on how you plan to implement this rather than just what the problem is. Immediate technical queries I have with it as written:
  • "The new system would use css popups": What is a CSS popup? CSS has no innate concept of a popup, since that's structural data, not stylistic. Probably a fully-fledged system would use some kind of rich UI element like OOUI when possible (or maybe it can just be done with mw:Reference_Tooltips right now).
  • E-readers: not many solutions will work on e-readers since the baseline is a very (very) basic environment and you may not even have a touchscreen, let alone a mouse. Probably the best you can realistically hope for is on-the-fly conversion to footnotes by the exporter. Footnotes generally are supported OK (and use the right epub hinting). Inductiveloadtalk/contribs 20:28, 21 April 2021 (UTC)
I was thinking about using something like these two examples [4] [5]. So, it would use CSS to control the display of the popup and how the text is stylized. In this way, these options can be overwritten on a per-text basis. As for ereaders, it would require additional engineering to convert these popups which I don't plan on doing. Thoughts? Languageseeker (talk) 20:51, 21 April 2021 (UTC)
That's a very very rudimentary popup system. MediaWiki includes OOUI, so probably something along the lines of mw:Reference_Tooltips is more practical than a full-custom solution? Inductiveloadtalk/contribs 21:04, 21 April 2021 (UTC)

talk archives

To note that your talk archives are somewhat hidden. I have modified {{archives}} to have an automated year function which should assist you if interested. — billinghurst sDrewth 05:26, 22 April 2021 (UTC)

Whoops, quite right   Done . I wasn't sure how to integrate "Archive 1/2" with auto year, so I gave up and did the easy thing. Inductiveloadtalk/contribs 13:25, 22 April 2021 (UTC)

upgrades to the index form

The form for the index page prefills in information from the book template. When I move the information to wikidata, the form shows up empty.

So, a nice upgrade is to have it pull from wikidata if it exists.

Everything I know about pulling information from wikidata, I learned here, at the author template. It is so easy.

If I had a computer, I would make a citation tool that would make the publication listings at the author pages.

On a different matter, I have a question about a template at commons. The template gave me errors, but it seemed to work. I was wondering if you could look at it and tell me if it is rendering nicely for you as well. It is in use for volumes of things there commons:Category:Bentley's Miscellany, Vol. 1 for one.

Thanks.--RaboKarbakian (talk) 19:11, 22 April 2021 (UTC)

It can be done, but it'll be a little bit of work to get it done. There aren't many files like that currently, so for now it's not a high priority to me. I'll get to it one day, unless someone else does first.
I don't know what template issue you are referring to, but the page files there seem to at least not have errors. E.g. File:Bentley's Miscellany, Vol. 1-0279.jpg looks OK. Inductiveloadtalk/contribs 19:46, 22 April 2021 (UTC)
I was wondering about the volume navigation.
I was very unhappy about an exchange I had at the commons. You should read it carefully and have your own opinion or not of it commons:User_talk:Languageseeker#pdf,_djvu_and_jp2. It wasn't just my words there. I know how I would fix the bot, but I don't like software that does this.--RaboKarbakian (talk) 19:58, 22 April 2021 (UTC)
The navbar template appears functional? I'm not seeing any errors.
I don't know what about that conversion could make you "very unhappy". Regardless, the IA-Upload bot has been modified to only warn if the same identifier has been uploaded before (phab:T269518). I don't like software that does this - I don't know what you mean by that: If you don't like IA-Upload, don't use it? Inductiveloadtalk/contribs 20:27, 22 April 2021 (UTC)
In the exchange on that talk page, I read your welcome to me when you were "ready to export" texts here and something I said after that during the DP f2 days. These words were delivered back to me and way out of context in an automated sort of way. I don't like that kind of software. Liza is so late 90s....
I like IAUpload, enough to have learned some of its ways and foibles and I am both sad and happy it is being fixed. I kind of want to cuss or append everything that I say on a talk page with something about not liking chat mining now.--RaboKarbakian (talk) 21:40, 22 April 2021 (UTC)
I'm sorry, I genuinely have no idea what you are talking about, as far as I can tell LanguageSeeker was being helpful and I'm fairly sure they're not a chat bot. Inductiveloadtalk/contribs 22:02, 22 April 2021 (UTC)

Monthly Challenge Work

I would really like to get the Monthly Challenge running in May. Since, I'm not sure that the Bookworm Bot can get started by then, I've created an alternative page for the Project Wikisource:Community collaboration/Monthly Challenge (2021)/May 2021. There's a nomination project on WS:S#Call for Nomination of Texts that has enough texts already. There are two major tasks remaining. The first involves halving the New Text Box and creating a text box for the Monthly Challenge above it similar to the one on French Wikisource. This requires an Administrator. Can you do that? The second is writing the FAQ which I plan to get done over the next few days. I'll also create a discussion on the FAQ at WS:S once they're done. Languageseeker (talk) 13:18, 24 April 2021 (UTC)

Wanna take it for a spin?

Whenever you have a moment, could you take this for a spin to check that I haven't massively borked something before we replace MediaWiki:Gadget-ocr.js? Other thoughts and feedback welcome too, of course, should you feel inclined. Xover (talk) 15:11, 23 April 2021 (UTC)

@Xover: not flushed with time right now, but I'll try. First impression: not sure it's working for hOCR - I get the "hOCR complete" popup but nothing happens in the text box. I think $('#wpTextbox1').value should be $('#wpTextbox1').val() (or cut out jQuery and do document.getElementById("wpTextbox1").value = ...).
Also probably need to steal from be inspired by the Google OCR JS and add $( "a[rel='wsOcr1']" ).css("width", "45px"); around line 95 to fit the wider button icon. Unless the Wikieditor config hook has a CSS field I don't know about. Inductiveloadtalk/contribs 15:54, 23 April 2021 (UTC)
Fixed. --Xover (talk) 10:02, 24 April 2021 (UTC)


@Xover: As an aside since this is adding buttons, with the "2017" editor now 4 years overdue, do you have any idea what's going on there? Is there anything we should be doing to get ready for an eventual change-over? It doesn't seem to share the configuration hook with the 2010 editor. As usual, there's naff-all in the way of documentation for the new shiny. I don't personally use it and found it incredibly annoying when I tried it, but there's a few tagged edits around, so some people must like it (or they don't know they can turn it off!). Inductiveloadtalk/contribs 16:14, 23 April 2021 (UTC)

You mean the wikitext mode of the Visual Editor, I presume? There's actually been some movement on that just recently, triggered by CommTech's use of Parsoid for ws-export, in that the VE team has apparently now given this enough thought that they've concluded they need a Parsoid-native version of ProofreadPage to make this work. I think that opens the possibility that they'll give it some attention eventually. But the bad news is that I don't think our use case is even on their radar, so all the docs and exposed functionality assume you're a core MW dev employed by the WMF. It is definitely possible to hook into VE, both visual mode and wikitext mode, in all sorts of ways, but I've found jack-all that's usable for Gadget or user script developers. Which reminds me… no, on second thought, I'll have to dig up some links for that rant. Later. --Xover (talk) 16:41, 23 April 2021 (UTC)
PRP and Parsoid came up in phab:T274654#6946964 and resulted in phab:T278481.
The other links I wanted to dump were mw:ResourceLoader/ES6 and T237688, T178356, and T75714. The long and short of which is… MW and the WMF are now feeling the pain of not using ES6 so much that they're willing to drop Grade A support for IE11 and start requiring it for new core features, but have not as yet given any priority or allocated resources to developing the necessary validator for end-user accessible code (like gadgets) to be able to use ES6. This is kinda concerning since Krinkle, who as they mention in one of the comments is the most likely person to do the work, jokingly estimates it won't get done until 2030. I'm not sure how to approach that because, as they say, it isn't a trivial job, and it's hard to point at anything ES3 makes actually "impossible" or that ES6 suddenly makes possible; it's more the same kind of pain that leads the WMF itself to want to move the bar.
And speaking of the utter neglect of Gadget coders… Are you familiar with Vue at all? I've never really looked at it but from a quick peak it looks to exist for / appeal to 1) people who are caught up in the now-fashionable "let's all dump on jQuery" fad, 2) people who are religiously convinced React is the light and the truth, solves all problems, brings world peace, and is therefore the one true way, and 3) people with a genuine need to build full blown applications. What I am not seeing is a library of pre-made UI widgets ala jQuery UI—for which OOUI was already a hideously complex replacement—or anything else that would help us make robust, functional, consistent gadgets with modern and user friendly UI. Sigh. --Xover (talk) 11:42, 24 April 2021 (UTC)
Oh good, we're on the same page. The total neglect of Gadget coders is really quite frustrating. There are AFAIK, a grand total of zero documents explaining best practices for gadgets (specifically: configuration, deployment and code sharing), and you get short shrift in chat channels for asking. The OOUI help pages are deserts for answers (and still have the wrong IRC link on them, where you get an earful for being in the wrong channel). The OOUI "manual" is hilariously short on use cases. and I'm still short of a tab-completing selection box that actually reduces keystrokes for finding something (for User:Inductiveload/quick access.js, I had to roll my own).
I did ask for a way to at least ask ResourceLoader to load specific deps locally (phab:T278304) because otherwise you can't really test "JS libraries" without finding and disabling all other clients of the library. If the core site JS uses such a library, that's not very practical. "Test it on a local wiki" was the answer given. I'm working on a workaround but it's fugly (think web server which regexes JS on the fly ugly).
RE Vue, I have no idea WTH is happening, or if there's anything useable for Gadgeteers, if there ever will be, or even if that's planned. I am vaguely planning to use Vue for a future Toolforge thing just so I'm not totally blindsided when it comes along (but Vue + Bootstrap, since I have no earthly clue where WVUI is at, or even if one can use it for anything right now). I think the idea for Vue is that it's good an "incremental" use, so you can drop in a few Vue widgets without having to drink the whole cup of SPA koolaid. As you say, all one needs is a small library of widgets to play with. And at least it can't be much worse that OOUI in terms of verbose boilerplate needed, eh?
Anyway, if I get something working before you do, I'll let you know. Inductiveloadtalk/contribs 22:23, 26 April 2021 (UTC)

Wikidata requires paranoia

cf. Hans Andersen's Fairy Tales/The Top and Ball and probably a smattering of other pages, and this change. Code like this needs to be not only defensive but downright paranoid: you're dereferencing a complex datastructure that is directly end-user editable with zero input validation. Any and all levels in that datastructure may be missing or contain garbage. As I recall, the last time I ran into this issue I had to walk the tree level by level and do a nil check for every one. Xover (talk) 13:01, 24 April 2021 (UTC)

@Xover: I think (though I could well be wrong) that the datastructure isn't totally user-editable. In this case, a missing datavalue field (and a snaktype=somevalue field) means it's "unknown value"). Checking for the item datatype (wikibase-id, though if the calling code said "edition of", that's a given) and a present datavalue should be enough? (bedtime reading: Inductiveloadtalk/contribs 22:52, 26 April 2021 (UTC)
nil-checking datavalue is probably enough here, yeah (cf. below).
You're right that the whole structure isn't user-editable, but you can easily run into logical inconsistencies like a qualifier value for a property with unknown value. My main point is that in dealing with Wikidata we need to armorplate and program defensively as a rule, much more than with any other semi-structured data source. Pulling from MWs DB tables, for example, we can assume a certain level of consistency because it's enforced on input by the software in a high-level UI. Wikidata barely validates syntax, much less any kind of real consistency, and at the same time let end users change data in what is essentially the "database" layer. It's kinda scary. (remind me to rant about semantics and information modelling some day; some day you have lots and lots of free time…)
In any case, I dug up the previous instance I was thinking of: Armoring against bad data on Wikidata. It's been a while, but superficially it looks like a very similar type of issue, which probably means nil-checking the datavalue is the pattern to extract from this.
Oh, and that doc was useful. I've been looking for that kind of thing and have failed to find it. I think we need to start thinking about what we can do in terms of gadgets to make our WD integration better and more user friendly, without crossloading code from some dude's user space on a different language project… --Xover (talk) 08:58, 27 April 2021 (UTC)


Guessing, not presuming, that you have had a look at what frWS is now doing with their Index: page template. Either way, waving it under your eyes. — billinghurst sDrewth 08:30, 26 April 2021 (UTC)

@Billinghurst: I have coveted their WD barcodes and I will eventually acquire them for our own nefarious purposes. Inductiveloadtalk/contribs 22:07, 26 April 2021 (UTC)
We could probably persuade Tpt to give us a rundown of what the module does, how it fits into their larger architecture, and what the drivers were. I'm thinking the coding part of this stuff isn't so hard, it's more an issue of figuring out how it should work, what are the externally imposed limitations, etc. But then, the way WD is set up is fundamentally incompatible with the way my brain is wired, so maybe that's just me. :) --Xover (talk) 09:02, 27 April 2021 (UTC)
@Xover: I can probably figure most of it out, it's mostly a question of "what we actually want it to do" (other than bling-bling which is of course a noble aspiration). The biggest issue for me is that WD is actually not always as good as you would think/hope at the kind of bibliographic metadata we actually would want on an index page - particularly for things like volume (and that that's before we get to periodicals).
Furthermore, even if I could figure out representing sub-edition data (like volumes), there's another level to it: Index pages exist in a kind of unhappy no-man's-land between WD edition items and Commons SDC data - while the file represents the edition, the instantiation of that representation has its own properties (e.g. pagination, missing pages, scan quality, scan providence, etc etc) that can and do vary even within the same edition. This is, I think, the "Item" level of FRBR (Group 1). This is, I think, one of the primary disconnects between what WD promises it could be and what it actually is to Wikisource comes about. Inductiveloadtalk/contribs 09:19, 27 April 2021 (UTC)
Now I could be wrong, however, it still relies on data population at WD, and prior to the work being done here. We have struggled to get good WD compliance here at an work/article's creation, and I know that I generally do it just the once when I have transcluded. Prime issue for me is the push from Commons to WD has no easy semi-automated tool to either push or check data. Similarly the push from our Index pages to WD is not connected. — billinghurst sDrewth 11:37, 27 April 2021 (UTC)
Well, certainly without the data being present somewhere, it's all a disaster. However, we currently have no one place we can put all the data, or even a solid idea of how to split data between Commons, WD and WS index pages in the general case. Which has lead to "some people" (i.e. me) saying "sod it" and just not bothering too much. I try to get the file metadata for scans to be reasonable, but since I don't even know what best practices are, I leave it at that for files.
For "easy" works like a single volume novel, WD can hold pretty much all of it in the work/edition structure, and only things like the pagelist need to be done at the file (or Index) level. For things in the mainspace, it's also easier, as that that generally can traverse a edition or translation of (P629) statement and suck data out of the work-level item (where things like "topic" likely reside). The "item" level of the FRBR system kind of falls away at that point, because we kind of isolate that behind the Index/Page:Mainspace division.
It's possible there's a good way to do this for a general book (e.g. a volume of a set, or a periodical issue), but I haven't been able to work it out yet. And sadly, the periodical thing especially is probably where WD can most help us deal with the enormous amount of bibliographic data represented by the contents of a periodical.
I am working on a WS -> WD item creator (working title: Wikidata Creata :-D), but it's not done (or half done) yet because writing gadgets is such a huge PITA with the tools we are given. So I'm considering doing it all in a separate web-app on Toolforge. Inductiveloadtalk/contribs 11:52, 27 April 2021 (UTC)

the setting up of a journal

I checked the tables of contents. Ingoldsby goes to VOLUME 17! Honestly, I was just twiddling thumbs with Rackham. Bentley's is more like interrupting thumb twiddling by playing with a hangnail. I don't like my computer being hacked. It is (a simile is about to happen, different from string literal) like having people jump in your car and go with you, expressing opinions, making rules and interrupting -- just with their presence. When my computer didn't boot, (and when my home directory was being mounted via nfs or ntfs, they mounted it "Non Executable") it was like (simile) they decided to park my car in their garage and I don't even get to know where or who.

I am trying not to spin this one way or another. I am trying this for years! Closer to 5 years since the non-executable fiasco than 1. So, I was going to use my compromised computer and work on something that I like but don't have great cares for. Arthur Rackham. Very wonderful illustrator; his creepy is cute.

Apologies for the rant. My inkscape friend does perl. I do python. WS is lua?

I was going to start to set up Bentley's Miscellany here when I saw Wikisource:WikiProject Popular Science Monthly. I came here and ranted. They have an "engine". At data, I have separated scans & index pages from Main.

RL is calling, there is no wrong answer: journal? Yes or no.--RaboKarbakian (talk) 15:06, 27 April 2021 (UTC)

I'm sorry, I do not understand what you are saying. The first half makes no sense to me. The second half seems like you'd like to set up a periodical at WS for Bentley's?
The first step towards that is probably gathering a list of all the volumes and scans into Bentley's Miscellany. If you're going to use the Internet Archive SIM scans (which look like they are split into 3 each, TOC, content and index), that might make life a bit harder for you. I don't really have a good suggestion for a better option other than scraping the Hathi scans or checking over the Google scans at the IA (which look pretty poor). Inductiveloadtalk/contribs 15:31, 27 April 2021 (UTC)
Jumping into this conversation. I also had plans to create an page for Bentley's miscellany. In addition to the Princeton Scans, Toronto also has full color scans of some of the volumes. For the volumes on Haithi trust, is there anyway that you can batch download the Princeton Set and the Upload them to Commons without compression so that the images can easily be extracted? Languageseeker (talk) 18:31, 27 April 2021 (UTC)
The first rant here is about why I choose different things than what I really want to work on. If my words are being mined, then always including a displeasure about being hacked works for me.
I played with pulling in information from wikidata for about 20 mins, it has been a couple of years since I did this.... You can see what I got at Bentley's Miscellany. The upper portion is paste. The data calls (also edited paste) are under "pulled".
The scans are at commons commons:Category:Bentley's Miscellany. Best to change your preferences to "cats on top" there for easier navigation.--RaboKarbakian (talk) 19:13, 27 April 2021 (UTC)

Expanding use of preload to something on a per work basis

For some of our compilation works I would like to better utilise MediaWiki:Gadget-TemplatePreloader.js somehow for people working on these compilations.

A Biographical Dictionary of Modern Rationalists will be using the header adaptation Template:BDMR and it (now) has a /preload. I would like to have scope to put in this template rather than "header" utilising the path of the work. I would also like to see if we can look to do something similar with a range of other compilation works. I would hope that we wouldn't have to do it by editing the preloader.js itself but somehow leverage it by having a "by work" configuration file, json, something!

Nothing urgent urgent as I can do a templatescript that I can set up to do a replacement, but to make all these compilation works easier, better, uniform I see that it is our next evolution. If we can have it configurable outside of the javascript it gives great flexibility and ownership. Thanks for your consideration. — billinghurst sDrewth 02:54, 19 April 2021 (UTC)

@Billinghurst: hmm, yeah, so the idea is a (very) good one, but I'll need to think a bit about the implementation. JSON is probably a good call, as long as it actually loads as JSON when AJAX'd. I'll give it a poke at some point. Inductiveloadtalk/contribs 09:08, 19 April 2021 (UTC)
Less urgent, I remembered how I did the override ... Template:Editnotices/Group/A catalogue of notable Middle Templars, with brief biographical notices. Leaves a bit of a fat header, however, good enough for just a simple template and transclusion where the fat editnotice matters less. The (ugly) things that you forget when you haven't done them for years, and how sad is it when you are talking in terms of many years. :-/ — billinghurst sDrewth 12:45, 28 April 2021 (UTC)
Even betterer, I have set up some group documentation that can be applied at Template:Editnotices/Group/docbillinghurst sDrewth 13:04, 29 April 2021 (UTC)

9 years isn't even the record...

You may like to be aware of phab:T41510, both for yourself and if anyone else runs into it. There are workarounds through the API, asking a dev to clear it, etc. should that be needed. Xover (talk) 18:47, 29 April 2021 (UTC)

Dezoomify Question

I'm trying to use dezoominfy to get the images off The Jane Austen Manuscript website that are in the PD. However, I get the following error

ERROR: Could not open ImageProperties.xml (<urlopen error [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1123)>).


Are you familiar with the program or know how to fix this error? Languageseeker (talk) 20:29, 30 April 2021 (UTC)

@Languageseeker: It's been a long time since I used it. works, which suggests dezoomify-rs would work too? Inductiveloadtalk/contribs 22:55, 30 April 2021 (UTC)
Thanks. I tried -rs and it didn't work. I guess that I might have to do it image by image through the web interface. Languageseeker (talk) 02:57, 1 May 2021 (UTC)

Add link to source on Index Pages

One thing that I noticed on frWS that would be helpful here was links to the original source on the Index page. Perhaps, we could import the links from Commons with the other metadata? This makes it much easier to fetch the full resolution images from IA. Languageseeker (talk) 04:39, 2 May 2021 (UTC)

We could do this, but it's one more thing to keep in line. It's possible that some kind of Commons SDC or Wikidata (probably via Wikisource index page URL (P1957)) might be more sensible, and building out an Index page SDC/WD infrastructure might be more sensible. Though I am personally hazy on when to use SDC and when to use WD. There's also User:Inductiveload/jump to file which will link you directly to the source file or hi-res JPG at the IA (or Hathi, or some others), and also give you the option of loading a high-res image into the ProofreadPage pane for when the scan thumbnail is a bit rubbish (PDFs are especially bad at this). Inductiveloadtalk/contribs 23:08, 2 May 2021 (UTC)
I see. The user script is great. Would there be anyway to get it to upload the high-resolution image to Commons? I think that high-resolution images really come into play when trying to upload better quality images. Languageseeker (talk) 00:33, 3 May 2021 (UTC)
@Languageseeker: A WS-optimised uploader is on my middle-term list, but it won't (directly) be part of this script (though the script might direct you to a prefilled upload form). Uploading raw originals will be part of that.
In any case, the upstream original isn't that useful at WS in the general case, because it is usually needs non-trival processing to remove the paper colour and tidy up defects. It's nice to have the original at Commons, but it's not something we in general will present to readers. Inductiveloadtalk/contribs 18:59, 3 May 2021 (UTC)

Stats color for 100 to 200 range

There’s a highlight color for >100 and one for <200. Could you add one for between 100 and 200? Languageseeker (talk) 00:17, 3 May 2021 (UTC)

My thinking is that highlighting isn't highlighting if everything is highlighted. The idea is only to call out things that have special meaning: falling short of a "minimum" level (bad) or exceeding some "maximum expected" level (good). Obviously, we don't yet have a good handle on our expected levels so 100/200 are made-up thresholds.
On that note, if we start hitting 200 per day on a regular basis, we should bump the limits so that we 1) keep the hounds snapping at heels by raising the "lower" bar and 2) raise the upper bar so we have a meaningful "this day was exceptionally good" signal rather than allow the whole table to turn green. Inductiveloadtalk/contribs 19:05, 3 May 2021 (UTC)

Monthly Challenge - volume's image

Hello. Could you tell how to change on Monthly Challenge's page The French Revolution (Volume 1)'s cover from 5 to 9 (as index displays)? I can't figure out how to do it. Ratte (talk) 08:08, 4 May 2021 (UTC)

@Ratte: Sure: like this (at Module:Monthly Challenge/data/2021). It's slightly wierd, but it's the only way I can make it so that that MC grid can update automatically without needing a bot to run constantly to keep it up to date. I will be writing some central docs on how to work the MC infrastructure once I'm sure it does actually work (it's looking "OK" so far)! Inductiveloadtalk/contribs 08:31, 4 May 2021 (UTC)
Thank you! Ratte (talk) 08:42, 4 May 2021 (UTC)

Transclusion Question

Can you take a look at The Works of H. G. Wells (Atlantic Edition)/Volume 1/The Time Machine/Chapter 1 and see why Chapter 2 is being included? Languageseeker (talk) 19:47, 7 May 2021 (UTC)

@Languageseeker: sure - the problem was that tosection is inclusive. Thus you needed a TM1 section to use as the tosection parameter. Inductiveloadtalk/contribs 22:06, 7 May 2021 (UTC)

Monthly Challenge Sprint

Would you mind switching over the sprint to Science? Languageseeker (talk) 20:59, 9 May 2021 (UTC)

@Languageseeker: done. Inductiveloadtalk/contribs 21:04, 9 May 2021 (UTC)

Setup a nude class for Template:authority/link and Template:authority/lkpl

Hi. As is possible with I would like to get some css class(es) on these links so I can visually track the use of these links in works (per User:Billinghurst/common.css). And you know that extended css is not my strength so would you mind doing that? Thanks. — billinghurst sDrewth 01:57, 11 May 2021 (UTC)

@Billinghurst: They now have ws-authlink and ws-authlkpl classes respectively. I haven't done per-field classes like {{article link}} because it's quite a bit of faffing in template mode (vs module mode) and doesn't have an immediate use. At least now, you can do
.ws-authlink, .ws-authlkpl { color: green; }
or whatever other style tickles your fancy. Inductiveloadtalk/contribs 06:38, 11 May 2021 (UTC)
Thanks, I am hoping that it is useful for visual link check diagnostics. — billinghurst sDrewth 12:16, 11 May 2021 (UTC)

NIH, or...

Add a pinch of caution on this one. This may be just NIH, but there are several red flags here for me. For one, we're only just now hearing about this, when the project is essentially finished (cf. the grant proposal: it ends in May). The project was to involve lots of community consultation, with "the Wikisource community", but it looks like they've only talked to the Punjabi Wikisource (the home wiki for at least one of those involved). There are significant differences between the language projects that may make a single-project setup untenable for other language projects. And while better Wikidata integration is awesome, it needs very careful design and management: e.g., what happens when a arWP editor hops over to Wikidata and changes the fields that are used on our Index pages? Or changes it locally on arWP and some set of tools makes the change also happen on Wikidata. Or a bot does a new monster import of Worldcat, with zero verification of the data. Or… All the projects have different policies (as enWP found to their detriment) for things like verifiability, conduct, conflict resolution, etc. And different priorities, which is a perfect recipe for conflict. Technologically crufty as our current indexes are, we own that data and can make policies for them, and patrol changes to them. Once we outsource them we have zero control. And what happens once this grant is exhausted? "Wikidata integration isn't really supported; it's really buggy and nobody is likely to fix it any time soon."

So maybe a more succinct summary is: if you find good stuff there then we should certainly crib what we can, but on our terms and we can't just assume that because someone got a grant to make something it is necessarily good for us. And a lot of the coolest potential stuff for WD<->WS integration needs community buy-in and policy changes, not just technical plumbing. Bah, humbug! :) Xover (talk) 20:32, 11 May 2021 (UTC)

@Xover: I agree 100%. Mostly they were vague on exactly which Wikisourcen they were even talking about. I can turn grumpy and lawn-territorial later on, as needed ^_^. Besides, unless they have a global interface admin and/or GS on side and willing to egegiously abuse those rights, they'll need someone with the bits locally anyway.
As it is, eventually I'm long-term hoping for a frWS-kind of affair for Index page WD, perhaps with more twiddly bits, perhaps not. But until the Datazoids 1) figure out how we're supposed to record, in particular, per-volume data for multi-volume works, and 2) write that down somewhere incredibly clearly in words of one syllable for my dumb ass (or someone figures out what the Commons Structured Data is actually for and tells me that's what I should be using and then tells me how), I find myself suffering from a Vitamin Care deficiency. Inductiveloadtalk/contribs 20:42, 11 May 2021 (UTC)


Undertaking this should not be necessary for autopatrolled users, especially where it has been asked on their user talk page repeatedly. — billinghurst sDrewth 14:32, 11 May 2021 (UTC)

@Billinghurst: What's wrong with how it was before? Those four lines are not four paragraphs, they're a single "semantic" line with manual breaks, so <br/> is valid? Inductiveloadtalk/contribs 14:39, 11 May 2021 (UTC)
Aaagh, this one (sorry was going to bed). — billinghurst sDrewth 22:28, 11 May 2021 (UTC)
and fwiw when using the +er-blocks they do need to be separated by blank lines rather than closer with BR as the text is not suitably separated, it overlaps (in Firefox). — billinghurst sDrewth 22:33, 11 May 2021 (UTC)
@Billinghurst: Hmm, that's not ideal, indeed.
I don't see anything wrong with the -er-blocks in Firefox. If the line heights are wrong on some platform or something, we need to address that, as line wrapping doesn't only happen with manual BR tags. Does the lorem ipsum in the docs at {{xxxx-larger}} do it as well? Inductiveloadtalk/contribs 22:38, 11 May 2021 (UTC)
I have no idea whether it is platform specific or not, just saying that I am seeing it that way in my browser. With the (larger)+er block usage (usually above x-) it is typically a display set of text like title pages rather than standard body text as can happen with the (smaller)-er blocks we need that line spacing to contract like it does neatly. So in the display pages we can just throw formatting at it and have it display nicely. So if shoving blank lines or BR doesn't matter as the look is okay, so do it to suit the required display. [Changes now is going to impact a lot of pre-existing pages where it is display for display sake. — billinghurst sDrewth 22:49, 11 May 2021 (UTC)
Right, but it's not good if one user thinks something displays properly and another see it broken. For example, with BR, this is what I see: Which is (pedantically) more like the original, not that it really matters. I have used BR-in-largers on title pages before, so it's not good if it turns out they are coming out busticated for some.
Do you see any difference here between 1 and 2? Inductiveloadtalk/contribs 22:56, 11 May 2021 (UTC)
Oh yeah. phab:F34451074 and attached you there. — billinghurst sDrewth 02:38, 12 May 2021 (UTC)
@Billinghurst:, OK I have harmonised the larger-block templates to set the line height to the same as the smaller ones (1.4), which isn't needed for me, but apparently is for you, despite us both being Firefoxers. It should now be functional to have a line break in these templates (forced with BR or natural). Thanks for the screenshots, very helpful. Inductiveloadtalk/contribs 13:54, 12 May 2021 (UTC)

phab:F34451086 the original page series in screenshot. — billinghurst sDrewth 02:48, 12 May 2021 (UTC)

podcast user:Jon (WMF) Worth a listen to Between the Brackets — billinghurst sDrewth 04:48, 12 May 2021 (UTC)

Thank You

I saw the amazing work that you did on the MC-Cover Template and I wanted to send you a quick thank you. It looks wonderful. Languageseeker (talk) 18:31, 27 April 2021 (UTC)

@Languageseeker: ...and now the listing is automagic - all you have to do is keep it topped up with works, and it'll take care of putting them in the right sections (as long as we have under about 500 active—i.e. immune or < 3 months old—works, which I think won't be an issue!). Still no way to have a page counter without a bot or similar, but at least this avoids a daily need to check statuses and risk works stagnating in the wrong sections. Inductiveloadtalk/contribs 20:32, 27 April 2021 (UTC)
The page looks so beautiful. It’s more than I could have hoped for. Once we reach 500 books a month, we can make it the Weekly Challenge (hee-hee). Is there any way to see texts that have only a few pages to validate or are mostly proofread? I also want to use this as a means of finishing texts. Simply outstanding work. Languageseeker (talk) 00:43, 28 April 2021 (UTC)
@Languageseeker: Glad you like it!
Re Is there any way to see texts that have only a few pages to validate or are mostly proofread not really, this is what we need a bot or phab:T281195 for. Once the proofread percentage data is either sitting in a module (or directly available via some magic tag), we can work it into the tiles for a quick overview. Daily stats like frWS will almost certainly need a bot - I don't see that being built into the core any time soon (though it would be pretty nifty if it could).
I feel like the near-live stats are part of what drives the frWS project, without the feedback, people drift back to their own domains. Inductiveloadtalk/contribs 00:51, 28 April 2021 (UTC)
I think that stats are only part of what drives users to contribute to frWS. If you look at Distributed Proofreaders, users contribute even when they only see the number of books completed every month. In my opinion, most users simply don't know what to do when they arrive on the site. Right now, we basically tell users to pick a project any project. However, most volunteers just wanted to be given a specific task. They also want to contribute to something important. So, I hope that by putting attractive texts on the Monthly Challenge, the site will grow it's user base. That is why I'm selecting texts that have broad recognition or look cool. My other hope is that by creating scan-backed copies of important works, we will attract more users to our site. Our key benefit is that we can combine scan-backed proofreading with the generation of ebooks in a way that allows for future improvement of formatting by relying heavily on templates. That's the key selling point of this site.
I also hope that by creating a Monthly Challenge, it will become easier to reach out to GLAM institutions. Most GLAM institutions simply don't have the money to proofread texts. Scanning is cheaper, but they don't want to contribute scans if they'll just grow moldy in the backpages of WS. With the Monthly Challenge, we can tell GLAM institutions that if they provide us with the scans, then we'll feature them on the Monthly Challenge and get them proofread. Right now is a great time to reach out to GLAM institutions because the demise of flash has had a devastating impact on GLAM websites. Combined with the pandemic, most GLAM institutions are choosing to either take them down or leave them broken. enWS can reach out as a new home for these scans.
On a separate technical note, I've noticed that the box containing the PoTM vanishes if the site window gets to small. Maybe, it would make sense to make sure that the PoTM and Monthly Challenge box does not vanish on small displays? Also, would it be possible to create a way to easily monitor the talk pages of all the Indexes in the Monthly Challenge to see if a user asks a question there? Languageseeker (talk) 02:52, 30 April 2021 (UTC)
Re key selling point that's my view too.
Re monitoring all talk pages, this should probably be a script to add all MC index talk to your watchlist, and probably is not that hard. I'll look into it.
Re small screens, I think the reasoning is that the proofreading UI is so unwieldy on a mobile screen that there's not much point directing mobile users to working spaces anyway. I think we could at least advertise a bit, once we have some progress to advertise, but it'll need some thought to make it useful/interesting to mobile users. Inductiveloadtalk/contribs 22:52, 30 April 2021 (UTC)
For the small screens, I meant when you resize your desktop internet window, the PoTM box vanishes. On the frWS, it gets moved to the bottom in a long column, while on the enWS it simply vanishes. I can understand why it's ommited on mobile, but, on desktops, you can resize the window. Languageseeker (talk) 02:59, 1 May 2021 (UTC)
Oh yeah, good point. We actually can target the mobile front page differently. I'll take a look (at some point). Inductiveloadtalk/contribs 11:40, 1 May 2021 (UTC)

Take your time. I was also thinking that it might be good to add some stats to the front page template like the French do. It can go between the line about the number of works and the sprint listings. Column 1 Mission 2000

Column 2 Results of 2021 : May 2021 (Total Pages validated or proofread) (percentage of 2000) ((daily change) pages)

Thoughts? Languageseeker (talk) 12:47, 1 May 2021 (UTC)

This should be possible once we have a few stats to use. Year-to-date stats will obviously only make sense from next month, and total-to-date only from next January. The whole stats system still needs a bit more tweaking before it becomes a hands-off automatic thing (for a start, moving to a Toolforge backend).
On the front-end, feel free to mock it up at {{Collaboration/MC/sandbox}} using fake figures and I can use that as inspiration when I have a suitable stats-processing function to wire up to it. Inductiveloadtalk/contribs 14:25, 1 May 2021 (UTC)
  Done Languageseeker (talk) 15:30, 1 May 2021 (UTC)
@Inductiveload: Any updates on implementing this? Languageseeker (talk) 20:06, 13 May 2021 (UTC)
@Languageseeker: {{Monthly Challenge statistics}} is now a thing (it's currently showing the average-to-date of the month), but it will need more work to handle the monthly roll-overs for things like day-1 stats. I think we'll see a few things falling over on the 1st. Inductiveloadtalk/contribs 20:09, 13 May 2021 (UTC)
I would be interested in stats on click-throughs to the sub-pages of works that are expected to be read-through. Or clicks from wikipedias to their little source sisters. CYGNIS INSIGNIS 15:16, 1 May 2021 (UTC)
We can get pageview data for pages via {{annual readership}}, but figuring out how users get to our pages and how they traverse them would possibly start running into issues with data collection fairly quickly (at least, you'd have to be very careful the data is fully anonymous, and even then I'm not sure of the rules on WMF sites). Inductiveloadtalk/contribs 20:39, 1 May 2021 (UTC)

New WMF toy in testing

Special:Preferences#mw-prefsection-betafeatures, enable "Discussion tools". Beside being really convenient both for replies and new threads, it eliminates a whole lot of "woops, forgot to sign" issues. I mention this for no particular reason. At all. Just completely randomly. :) Xover (talk) 08:35, 5 May 2021 (UTC)

@Xover: Gosh, a useful feature in the Beta section! ^_^ Inductiveloadtalk/contribs 08:50, 5 May 2021 (UTC)
I know. Shocking, isn't it? :) Xover (talk) 09:24, 5 May 2021 (UTC)
Aurp. You may also want to go into the Appearance section and uncheck "Use Legacy Vector". Not due to its awesomeness, but to be aware of and be prepared for what's (apparently) coming. Lots of good ideas, some less good, and a at time really janky implementation. I'm suspecting a lot of the impedance comes from two main factors: the team's prioritising readers over contributors, and a basic assumption that all content on the wiki is user generated (true for almost all the other projects) and uniform across pages (also true for most other projects).
I have good experiences with some of the people involved (receptive to feedback etc.), but it's probably going to take some effort on our part to affect anything here. Xover (talk) 07:57, 14 May 2021 (UTC)
@Xover: hmm, yeah I've tried that before and it doesn't look great. However, "fixing" the centred column formatting, if we wanted to do so, is probably "only" a matter of futzing with CSS here and there, so it's "probably" OK. I guess it's a matter of how much the current state is WIP and how much is actually considered "done".
Then again, some limiting of content width is also probably not a totally insane idea, since a 120em page (1920/16 = 120) is pretty excessive in most cases. But almost certainly the Page: NS editor might need special casing.
Anyway, since from the timeline on the project page it looks like this is some time away for us, I'm not sure there's a whole lot to do here right now. If we are sulkily disinclined to make any real effort, we can also let some other Wiksourcen take the early-adopter hit and only opt in once they've ironed out the wrinkles. I suppose collecting a CSS "fixes" file as a CSS gadget (targeting .skin-vector:not(.skin-vector-legacy) or similar) might be helpful when petitioning the reskin project for mercy?
For example, this removes the most egregious mis-feature, IMO: the 9em margin-left on #content:
.skin-vector:not(.skin-vector-legacy) #content {
    margin-left: 0;
Inductiveloadtalk/contribs 12:30, 14 May 2021 (UTC)
A lot of stuff is effectively getting locked in now, so if we want to affect anything we need to start talking to them sooner rather than later. And that will require familiarity with the current state of it and their roadmap ahead, and, perhaps even harder, having some idea of what we want. It is also an opportunity to get things done if we have pain points in this area. Right now there is attention and assigned resources, which, well, you know how things usually go when that's not the case. Xover (talk) 12:44, 14 May 2021 (UTC)
@Xover: Probably would help if I checked User:Inductiveload/vector.css wasn't causing chaos with the new layout before I was too rude about it in public... >_< Inductiveloadtalk/contribs 13:48, 14 May 2021 (UTC)

on page numbers

You mentioned these recently and I wanted to blather on about them, I think they are a crucial addition to the site. I try to show by example, but don't remember where they are: this is what I would have shown, The year's at the spring, which I still think works; the other being an original (ie printed, analog) index conveniently linked by pages numbers (not hundreds of anchors). Hope this was of interest. CYGNIS INSIGNIS 21:38, 9 May 2021 (UTC)

@Cygnis insignis: are you meaning the toggles in the left toolbar in the "Display Options" section? — billinghurst sDrewth 01:59, 11 May 2021 (UTC)
@Cygnis insignis: thanks for the note. I do wonder about linking only page numbers because it seems counter-intuitive to me - it "feels" like they're going to take me to the Page NS, though I imagine a user unfamiliar with the site wouldn't have that feeling.
More importantly (to me): on export this means the TOC text is not clickable (and the user agent may not make it clear where the link is):
Furthermore, the hint to the export tooling of the name for the entry in the "EPUB TOC" (the one you get when you "view book structure", as opposed to the one in the "content", which replicates the original) is the link text, so using the page number makes it somewhat unclear what is going on:
Sorry to be such an export bore! Inductiveloadtalk/contribs 06:52, 11 May 2021 (UTC)
I hadn't given that much consideration, although I also think that is important I hadn't expected the problems you outline. I suppose there are many potential hazards. I'll go off and learn about what's going on with EPUB, etc, maybe pick this thread up again when I better understand the export side of things. Thanks for the info, and for the couple of times you helped solve a problem recently (kept forgetting to say "that worked a treat, cheers) Have a good one. CYGNIS INSIGNIS 07:23, 11 May 2021 (UTC)
Oh, in indexes. user:Phe did quite a string of those for me back in the year, eg. The Elizabethan People/Index. Do we need to do anything different with them for export? — billinghurst sDrewth 12:14, 11 May 2021 (UTC)
@Billinghurst: no, that works fine - the #XXX links work just fine in the EPUB (and they make sense to me as the clickables, since one index entry can have n pages). It's the TOC where the exporter is actually using the link text to construct its own idea of what the entries in the document's structure are called. Inductiveloadtalk/contribs 12:37, 11 May 2021 (UTC)
  • I'd forgotten about something, and having reread that just now I recognise it was inappropriate for me to post here. Cheers anyway for the replies. CYGNIS INSIGNIS 00:05, 15 May 2021 (UTC)

Page:The Works of H G Wells Volume 1.pdf/7

Okay, where's the Index:page ,the file information and what the actual scans got out of step? Because the Hi-res scans this is looking for bear no resemblance to the ones in the PDF/DJVU for the nominal page numbering? Suggestions are welcome because I don't like playing hunt the glitch. ShakespeareFan00 (talk) 23:49, 14 May 2021 (UTC)

@ShakespeareFan00: Mea Culpa, this is actually the UC copy not the UM copy. Sorry about that. The UC has the British printing and UM has the US printing. Updated as appropriate. Languageseeker (talk) 00:40, 15 May 2021 (UTC)
Also, the hi-res versions weren't available when I uploaded the volumes. I left a message for them and they seemed to fix them. If someone wants to replace the low-res version with a higher-res version, feel free. Languageseeker (talk) 00:43, 15 May 2021 (UTC)
Thanks... The script seems to be appending an additional 0 to the page numbering for some reason. Is something doing a string concatenations when it should be doing an addition? ShakespeareFan00 (talk) 07:23, 15 May 2021 (UTC)

Index date validated not working

I’ve validated these indexes but the index validated date is not working. Index:Asian Infrastructure Investment Bank Act 2015.pdf and Index:Poems (Edward Thomas, 1917).djvu. Both indexes are fully transcluded. Could you please have a look at this. My OS is Mac OS and my browser is Opera. I also tried viewing with Safari and its still the same. --kathleen wright5 (talk) 02:10, 15 May 2021 (UTC)

@Kathleen.wright5: You need to add the "month year", what is there as grey text is an example of the format. Inductiveload, we may need a "for example ..." prepend in the field. — billinghurst sDrewth 02:22, 15 May 2021 (UTC)

Dislike DHR

I dislike having DHR in works that I do, especially when I can just as well space them out with hard returns and not get code bloat and impact readability. So I am not sure why you are replacing them with {{padded page break}}. I especially see DHR used way more than necessary when we can just be adding clean clear space. Am I missing something? — billinghurst sDrewth 05:54, 17 May 2021 (UTC)

There are a couple of reasons I would put for why I think {{ppb}} is better (and why I'm not just randomly screwing about):
  • Multiple hard returns in the code actually result in "stacked" P tags that contain a single BR each in the output. This is 1) semantically wrong as there are no structural paragraphs there at all and 2) this relies on the rather inconsistent way MW throws out P tags, BR tags, and how the inter-paragraph margins stack up. For example:
3 blank lines:

4 blank lines:

This means that the actual gap you get doesn't scale linearly in number of lines, because every odd number of lines collapses one BR into the last P tag (or at least it does right now, but because P-wrapping is a mess, who knows if this behaviour is a safe long-term bet):
1 line:


2 lines:


3 lines:


4 lines:


5 lines:


  • Secondly, multiple blank lines in Wikitext are fragile not only because MW makes no hard guarantees about how it's going to handle them, but also because the editor intention behind them is not always clear. How important is it that there are 2 blank lines here? Does the editor mean they want exactly one P tag containing exactly one BR tag (for a 0.5em + (1.6 * 1em) total effective gap)? Or did they actually just mean they want "some" gap? Whereas {{ppb}} is explicit: This is a page break with padding around it. Actually, I think all visible page breaks should get padding and then we wouldn't need {{ppb}} at all, because you very rarely want two pages jammed right up against one another, IMO
    • For that matter, {{dhr}} has some small advantage as well, especially on title pages: there is (hackish) CSS in the epub export which limits the height of a DHR to 100%, because massive stacks of multiple P tags usually result in a random division, with some P's on one page and the rest on the next, depending on how many P's there are and how big the reader screen/font-size is. Furthermore, DHR is an explicit "this div makes blank space" structural element with a class that allows targetting of CSS (which is how the EPUB exporter does that). Bare P tags have no such intention marker.
  • Because the P tags and the page-break DIV (which is what actually causes a page break on export) are disconnected siblings, you end up with free-floating P tags on each side of the break on export. This is currently true of {{ppb}} too, but...
The implementation of {{ppb}} certainly is was lacking, an DHR-PB-DHR is the wrong solution for it (even if it is brutally functional). What needs to happen is {{page break}} should some parameter that allows to adjust this. This is on my "make exports moar bettar" list, but I haven't gotten to it yet well, I have now, wasn't as hard as I thought. Inductiveloadtalk/contribs 08:32, 17 May 2021 (UTC)
Also, similar to the (new) {{ppb}} without DHR escorts, {{section end rule}} provides a similar thing for a rule. By adding a dedicated class, default padding and width (and any other CSS) can be applied though index-level CSS, so you don't need the {{dhr}}{{rule}}{{dhr}} idiom (or anti-pattern, depending on how grumpy one feels), you just need {{ser}}.
The idea is similar: allow the user to express what they mean, as well as avoiding spraying out 3 separate HTML elements that might or might not even end up on the same page. Inductiveloadtalk/contribs 13:07, 17 May 2021 (UTC)
Hah! I hate terminating section rules too—unneeded book artefact like hyphens, etc. For me they fall between sections and should not be transcluded. :-) — billinghurst sDrewth 06:58, 18 May 2021 (UTC)
@Billinghurst: First, not all {{ser}}s have to be at the end of a transcluded page.
Second: remember, a single template which adds a class + per-index CSS can do this: .ns-0 .wst-section-end-rule { display: none; }. No dummy sections needed. Inductiveloadtalk/contribs 08:17, 18 May 2021 (UTC)
Sure, or just not get wedded down in thinking that the 19th book compositing needs to be 21st century computer presentation. The word is king. — billinghurst sDrewth 10:52, 18 May 2021 (UTC)
@Billinghurst: I don't follow. The point is this allows it to not be part of the presentation, without having to faff about carefully arranging sections or futzing with no-includes. Slap a {{ser}} down, add suitable CSS (once only) and it's done - no section-end rules in mainspace. Inductiveloadtalk/contribs 10:56, 18 May 2021 (UTC)

Characters required for Old English keyboard

Hi Inductiveload, thanks for offering to make this; it would be really great to enable quick proofreading of these texts by specialists and non- alike. So this would require the following characters:

1) all 26 characters from the Modern English alphabet

2) the following characters from the O.E. alphabet:

  • eth: Ð,ð
  • thorn: Þ,þ
  • wynn: Ƿ,ƿ

3) A,a E,e I,i O,o U,u and Y,y with macrons, as this is used editorially to distinguish long from short vowels

Thanks so much in advance. Rho9998 (talk) 12:38, 17 May 2021 (UTC)

@Rho9998: It should now be available in your Wikieditor "Special Character" palette: screenshot. I didn't add the 26 normal letters because they're all on a keyboard and it'll just add clutter I think.
Let me know if you think of any other characters to chuck in :-) Inductiveloadtalk/contribs 12:59, 17 May 2021 (UTC)
@Inductiveload: Nice one. Well done on including the Tironian note (⁊) and the shorthand for þæt (ꝥ) as I forgot to mention them. That reminds me that on the punctuation front there's also the interpunct (·) which was used in the original manuscripts (although most editors modernise the punctuation). And checking Wikibooks I'm told there's also g with macron to abbreviate the prefix ge-. This further reminds me that there's g and c with dots on the top (ċ,ġ) used by some editors to mark when they're soft. Sorry for forgetting these but I hope that should be all of them now.
If you're feeling so inclined, you could also add runes. These are used sometimes in O.E. but I'd imagine they'd be useful for other languages and could merit their own keyboard.
@Rho9998: OK, added. I put the runes into Old/Middle English, but they could also go to their own panel. ¯\_(ツ)_/¯ Inductiveloadtalk/contribs 13:42, 17 May 2021 (UTC)
@Inductiveload: So can Wikisource transliterate the special characters directly, or will I have to go through and add in every one? This is as far as I am with my first attempt: Index:Hargrove1902alfred'soldenglishversionofaugustine'ssoliloquies.djvu
@Rho9998: You mean, in terms of the OCR? It looks like the Google OCR tool recognises this as Old English (even though the IA OCR clear did not). Instructions: Help:Gadget-ocr.
and þæt ic mage geearnian þæt ic sī wurðe þæt dū më
for dĩnre mildheortnesse ālyse and gefrēolsige. Ic clypie to
þë, Drihten, Þū be æall geworhtest, þæt þe æalles ge-
weorðan ne mihte, në æac wunian ne mihte būtan þë.
If all OCR fails, your only options are to proofread by hand from first principles, or find a matching text to copy-paste from.
BTW, it might be clearer to name the file something like "King Alfred's Old English version of St. Augustine's Soliloquies - Hargrove - 1920.djvu"? I can move the file if you like? There's nothing technically wrong with it as it is, it's just a bit of an eyeful. Inductiveloadtalk/contribs 15:44, 17 May 2021 (UTC)
@Inductiveload: re the file name sorry about that I didn't know how to change. I think the OCR has read it as modern English because the first part is, or because I've put en as the language? I'll familiarise myself with how the OCR works. Thanks for the link.
@Rho9998: Ta-da: Index:King Alfred's Old English version of St. Augustine's Soliloquies - Hargrove - 1902.djvu.
R.e. the OCR, this is nothing to do with you. The OCR is "baked-in" to the OCR at the source (the Internet Archive). The Google OCR button sends an image to some Google cloud thing and it regenerates it from scratch. Whatever Google does seems to notice when it is fed Old English, whereas whatever the IA did failed to notice (or was set to English only). The "normal" black OCR button just returns whatever OCR is in the file if it can, so that's what you get.
The is a current technical project to make Wikisource OCR processes a bit better, but for now, the Google button is probably your best bet. Inductiveloadtalk/contribs 15:59, 17 May 2021 (UTC)
@Inductiveload: Yeah I see what you mean now; I didn't see the big black and then multicoloured OCR buttons: doh! I agree Google OCR comes out much better. Unfortunately it looks like its read a lot of the macrons as either diaereses or circumflexes. Would I be able to do a 'replace all' for the whole OCR-ed text? Thanks for the file name change. Rho9998 (talk) 16:07, 17 May 2021 (UTC)
@Rho9998: You can add the following Javascript (just copy-paste) to Special:MyPage/common.js. Then you should see a button marked "OE OCR fixes" in the sidebar on the left:
$.ajax('//', {
  dataType: 'script',
  cache: true
}).then(function() {
  // page NS
      // RunningHeader
        name: 'OE OCR fixes',
        position: 'replace',
        script: function(editor) {

          // replace most diacritics with macrons
          var replacements = [
            [ /[àáäâã]/g, 'ā' ],
            [ /[èéëêẽ]/g, 'ē' ],
            [ /[ìíïîĩ]/g, 'ī' ],
            [ /[ũúüûũ]/g, 'ū' ],
            [ /[òóöôõ]/g, 'ō' ],
            [ /[ỳýÿŷỹ]/g, 'ȳ' ],

          for ( var i = 0; i < replacements.length; ++i ) {
              .replace(replacements[ i ][ 0 ], replacements[ i ][ 1 ]);
    ], {
      category: 'main',
      forNamespaces: ["Page"]
} );
The code like /[ỳýÿŷỹ]/g is a w:regular expression (see also here), the one after that is what is is replaced with. Basically any char found that's inside the square brackets will be replaced with that one. The g means it will do it as many times as it can in the text. Run if after you use the Google OCR button.
You can add more replacements as you need, or come and ask me to make a regex to solve something (i'll need example input and output text, as well as any examples you can think of where the replacement should not be made).
Don't be shy about editing your own JS: you can't damage anything and if it stops working, you can just go back in the edit history to an old version :-). Inductiveloadtalk/contribs 16:26, 17 May 2021 (UTC)
@Inductiveload: That is amazing, thank you! I've also copied and pasted the code and then edited the duplicate so that there's the option of replacing all wynns (ƿ) with thorn (þ) for texts where wynn is changed to 'w' anyway - you can see why the OCR would get them confused. As this text has the Latin source in the footnotes I won't add one to replace 'p'-s with thorns as that would cause more problems than it solved! I've also added ash and its accented variants by copying and adapting one of your lines of code - and this does make me realise that sometimes there are macron ash-s so if you feel like adding it to the keyboard please do, though note it's not a major hurdle for the instant as most ash-macrons are automatically inserted by the fixes you wrote. Rho9998 (talk) 17:44, 17 May 2021 (UTC)
@Rho9998: glad it's working out for you! Ǣ is already there, next to Ā. I noticed it while testing the replacements. :-) Inductiveloadtalk/contribs 17:55, 17 May 2021 (UTC)

Fixing the Transclusion of Index:Works of Jules Verne - Parke - Vol 5.djvu

When this volume got transcluded, it seems that not enough care was taken. Can you move all the pages to Works of Jules Verne/Volume 5/. Also, for Works of Jules Verne/The Mysterious Island, the Chapters should be moved to Works of Jules Verne/Volume 5/The Mysterious Island/Dropped from the Clouds/ e.g. Works of Jules Verne/Volume 5/The Mysterious Island/Dropped from the Clouds/Chapter 1 Thanks. Languageseeker (talk) 20:12, 17 May 2021 (UTC)

We don't need the volumes in this situation, they are just physical artefacts and make navigation difficult. Having as WORKS / SUBWORKS is perfectly fine; remainder of the work is done that way, and we should continue that way. Moved the subpages of the second work (after effing it up the first time). It seems that we will need AuxTOC in various places to properly generate the download output. Not certain whether it should be at the root page, or in subpages like Works of Jules Verne/The Mysterious Island. — billinghurst sDrewth 08:02, 18 May 2021 (UTC)
Not certain whether it should be at the root page, or in subpages You can have both: add the root page and subpage to the category Category:Ready for export. Note: the TOCs on the subpages must be inside a container classed ws-summary. This can be {{AuxTOC}}, {{TOC begin}}, or, if you are wrapping things manually {{export TOC}} or {{hidden export TOC}}. Inductiveloadtalk/contribs 08:21, 18 May 2021 (UTC)
My comment was more about the structure of the entire work. Not enough of sampling to make a recommendation, so put out the reminder. — billinghurst sDrewth 10:48, 18 May 2021 (UTC)

General question, from are you able to select a line, and edit/create a tag via the button? I just get fatal errors, though my rights are such a combination who knows what they think they are doing. — billinghurst sDrewth 16:43, 18 May 2021 (UTC)

@Billinghurst: [af12dbf3-a0ff-4f91-bf0c-0a812f3bb62b] 2021-05-18 16:50:35: Fatal exception of type "Error" :-/ Inductiveloadtalk/contribs 16:51, 18 May 2021 (UTC)
Hmm. @1234qwer1234qwer4: as someone without advanced rights locally though good mw knowledge, can you please tell me what you can do with these tags. Thanks. — billinghurst sDrewth 01:24, 19 May 2021 (UTC)
Bug reported, bug fixed. All good, sorry to be a bother. — billinghurst sDrewth 03:10, 19 May 2021 (UTC)

author = unknown

In olden times we used to direct an author = Unknown ability in header. From my looking at the instructions for the template that is now not said. And it still seems to work with the display logic, however, we are getting the equivalent of links to Author:unknown. Not sure when that occurred, and the when isn't really important. Is it an easy fix in your code? If not, then I will run my bot through to convert these to | override_author = Anonymous and the corresponding categorisation. There are about 600.

We also had a case where someone was using the override and still having author = author so had a magic load of links pointing there, and the categorisation. Those I have fixed and mentioned to the contributor about how to handle. — billinghurst sDrewth 15:34, 19 May 2021 (UTC)

Meh! And Author:not mentioned from translator field — billinghurst sDrewth 15:38, 19 May 2021 (UTC)
@Billinghurst: author = unknown does work and categorises. E.g. An Index Expurgatorius. It could link to Portal:Anonymous texts if you want (the old header template did not do this, so I followed it).
For translator and editor, both fields also special-case "Unknown" in the same way (including suitable categories). Inductiveloadtalk/contribs 15:43, 19 May 2021 (UTC)
They are shadow author linking. I am seeing them categorised to category:Works with non-existent author pagesbillinghurst sDrewth 15:46, 19 May 2021 (UTC)
@Billinghurst: ...or are they? diff. So many corner cases in the headers! Inductiveloadtalk/contribs 15:54, 19 May 2021 (UTC)
I am not understanding the assertion. — billinghurst sDrewth 15:57, 19 May 2021 (UTC)
@Billinghurst: ...I fixed it. "unknown" in the author (or editor or translator) field no longer categorises to category:Works with non-existent author pages. Inductiveloadtalk/contribs 16:01, 19 May 2021 (UTC)
Thanks. And "not mentioned" in translator? — billinghurst sDrewth 16:25, 19 May 2021 (UTC)
Chalk up another tin of Campbells to the face. See, for example The Voyages and Adventures of Captain Hatteras. Inductiveloadtalk/contribs 16:41, 19 May 2021 (UTC)
Beaut, that should get rid of another swag. Got the category down by about 1500 today.

  Comment Some days it is one slightly opening a cupboard door and out come thousand cans of tomato soup on your head. Followed by wikispelunking special:whatLinksHere/author:author= author <deskthunk> — billinghurst sDrewth 16:31, 19 May 2021 (UTC)

Faaaaark Special:WhatLinksHere/Author:No contributor recorded, and I will bot these ... when my other run is finished, then I will get Wikisource-bot to touch all those pages in that category again for the fourth time today. At one a second it is either a fun bucket, or a bun ... — billinghurst sDrewth 16:50, 19 May 2021 (UTC)

on having and being a bad experience

10962243 That made me laugh, last February, because "Replay Gain" gives really good info for remastering and when dreaming/thinking sounds like a rant.

I was trying to find a way to make better conversion of color to monochrome before my computer broke, but there was no reliable way yet. Some conversions were great for some but not for others and I could not figure out the why yet. Like it could have been darker needs this not that, or more reds are better with that, not this. It surely was not as consistent as clipping in sound files.

Any rant would have been directed at myself. The decision making that follows the simple monochrome or color toggle was my personal boggle.

Then, the weird fact I learned a while back about the delivery of TV images when we used antenna. That both color and b&w were sent on the same wave. People are so clever! Such a thing is terrible though, for the digital realm, making downloads and files bigger -- but I really thought back then that the conversion was in the device! But, the filming or the processing of it, if you care about quality, is very different for the two.

More rant?--RaboKarbakian (talk) 15:42, 19 May 2021 (UTC)

So, not only are my headers gone but now templates are too. This diff:

--RaboKarbakian (talk) 15:45, 19 May 2021 (UTC)

Traffic Signs Manual/Chapter 1 (1982 revised 2004) template use fail b/w browsers

If I look at that page in Firefox (w10, 88.0.1) it is a fail, though looks okay in Chrome. I will leave to work out the css issues as it is beyond me. — billinghurst sDrewth 01:02, 23 May 2021 (UTC)

@Billinghurst: could you be a bit more specific about what is failing? It looks pretty OK to me. Inductiveloadtalk/contribs 12:04, 24 May 2021 (UTC)
Apologies, was juggling 5 tasks again, half messages. phabricator:F34466027 numbering top right. — billinghurst sDrewth 12:25, 24 May 2021 (UTC)
@Billinghurst: OK, can you have a quick check to see if it's working now? Feels like it might be the same as before with the line-height, this time on {{fs}}. Inductiveloadtalk/contribs 12:31, 24 May 2021 (UTC)
Yes, resolved. Though that we have an issue in the same browser that simply differs by underlying instrument is an issue, especially where one of those is a reasonable common operating system. — billinghurst sDrewth 12:37, 24 May 2021 (UTC)
Seems like Windows + Firefox is sensitive to line-height for larger fonts in a way no other renderer is. I'm not sure if that's a browser bug or undefined or what (@Xover: do you know?). But the "solution" is apparently to set line-height where needed. Annoyingly, there appears to be no way for a non-Windows Firefoxoid to know if this is happening. Even at [6], I can't see this on Windows 10 + FF 88, so it might just be you have something weird on your system? Inductiveloadtalk/contribs 12:45, 24 May 2021 (UTC)
Billinghurst is using monobook, and there the skin sets line-height as a length value (1.5em). Length values are inherited by the computed value of the parent's line height. So for a block with font-size 127% and line-height 1.5em, with a base font size of 10px, the child will inherit a line-height of  . If you then set font-size to 300% or 800% you'll have a glyph of size   and   inside a 19px line-height. When the line in question is forcibly broken you end up with two overlapping line boxes.
This is only an issue in monobook (Vector sets line-height as a unitless number so it inherits properly), and the kind of difference between monobook and Vector that was among the driving factors for developing the new skin (the visual bling-bling too, of course, but monobook is very outdated from a technical perspective too). Xover (talk) 14:40, 24 May 2021 (UTC)
OK, that explains why I couldn't see it on a browser test site - the default for un-logged-in is Vector. At least we don't have a horrible platform thing going on like I thought. Inductiveloadtalk/contribs 15:08, 24 May 2021 (UTC)

A little birdie…

…uploaded a new version of File:Birdcraft-1897.djvu back in March. Do you happen recall why and what the changes were? Xover (talk) 11:56, 24 May 2021 (UTC)

@Xover: I think it was a mis-aligned text layer (phab:T219376 perhaps?), so this was a rebuild from JP2. I always forget the chunkedUpload thing uploads the moment you choose the file, rather than allowing to add a comment and submit. Sorry! Inductiveloadtalk/contribs 12:02, 24 May 2021 (UTC)