Inductiveload User Area
Main User Page Talk Page Gallery Contributions

WELCOME to my user talk page. Feel free to leave me a message if there is a problem or you would like my help, or anything else.

I am also active on Commons. If you would like help with a file I uploaded or would like me to make a file for you, please ask at my user talk page there. If the request is Wikisource-centred, ask here.

Anything you write on this page will be archived, so please be polite and don't write anything you will regret later! My purpose here is to make interesting and useful documents open to the public. I am never trying to make trouble, and any problems can almost certainly be resolved quickly and easily if everyone stays calm.

Please sign your posts by typing four tildes (~~~~) after your post, and continue conversations where they start. This helps to keep discussions coherent for future readers! If I leave a message on your page, then please reply continue there. My replies to messages left on this page will be here.

Archives
Older dicussions from this page are stored in archives. Especially interesting or detailed topics are kept in sub-archives. Below is a list of all archives and sub-archives:
Wikisource user page Commons user page Wikibooks user page Wikipedia user page


T277451Edit

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 .
                        "|num=$pagenum|formatted=$formattedNum}}</span>";

                    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)

Module:New texts/dataEdit

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)

https://twitter.com/billinghurstwik/status/1382114885786497025billinghurst 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)

Lua table lengthEdit

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:KutenaiEdit

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:

Example

<ruby style="ruby-position:under;">
<rb>taʹx̣as</rb>
<rp>(</rp><rt>Then</rt><rp>)</rp>
</ruby>

taʹx̣as(Then)

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

An em is not an emEdit

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 bearEdit

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 initialEdit

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...Edit

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

Dropped initialEdit

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)

The other initial has dropped!Edit

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 templatesEdit

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 LiberatorEdit

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)

Table across two pagesEdit

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}}
<poem>
Line 3
Line 4
</poem>
----------------------↑ Body/footer ↓<
{{block center/e}}
Page 2:
{{block center/s}}
----------------------↑ Header/body ↓<
<poem>
Line 3
Line 4
</poem>
{{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: https://ibb.co/Hpxbp0F. What do you currently see? You might need to purge the page. Inductiveloadtalk/contribs 10:46, 31 March 2021 (UTC)
This in Vivaldi: https://ibb.co/wK3gt3Q - 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: https://ibb.co/PWQmc92. 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)

Wikisource:Works/2021Edit

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 PageEdit

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 LinkEdit

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 "https://ia-upload.toolforge.org?id=XXXX&filename=YYYY&ext=pdf" 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. https://pagelister.toolforge.org/, or a local equivalent) help a lot because if you see this:
<pagelist
1="Cover"
2to4="–"
5="Title"
6to9="–"
10=2
781to783="–"
784="Cover"
/>
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 mattersEdit

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 brokenEdit

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...Edit

Hi.

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.loader.load("//en.wikisource.org/w/index.php?title=User:Inductiveload/ActivePageAlert.js&action=raw&ctype=text/javascript");

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

Bit a help with Template neededEdit

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 LinkEdit

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 1Edit

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 FootnotesEdit

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

{{footnote|ref|character}}

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 TemplateEdit

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;">([https://archive.org/details/{{{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."Edit

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....Edit

There seems to be a bot that updates formulae using MATH tags to resolve some issues, See https://www.mediawiki.org/wiki/Extension:Math/Roadmap

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 DunbarEdit

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 LowellEdit

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 loadingEdit

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 DJVUEdit

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 [1], 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 ?Edit

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 templateEdit

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: [https://ia-upload.toolforge.org/commons/fill?iaId=cu31924092218191&commonsName=The Jesuit relations and allied documents (Volume 27)&format=pdf Upload ...], which turns into a link with the URL "https://ia-upload.toolforge.org/commons/fill?iaId=cu31924092218191&commonsName=The" 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 cssEdit

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)