I just tried to prod along phab:T166138.

Couple of other fonts we could do with are a sans and serif "Outline" font, because clever though {{font outline}} is, it doesn't look great. E.g. the second line of this page for sans. But I can't immediately see good SIL-licensed candidates. Any ideas? priority: lowest.

Also for reference, phab:T270743 tracks the ability to export used ULS fonts. Inductiveloadtalk/contribs 11:49, 31 December 2020 (UTC)

Yale Shakespeare 2021Edit

The three titles entering public domain in 2021 are listed at Wikisource:Requested texts/1925. If you do not have the time to check the scans page-by-page, then I am quite willing to take the trouble to do so becfore you generate the files, if that would help.

I do not know when the two linked titles (Henry VIII and Love's Labour's Lost) will be available for download, but would appreciate it if, once they are available, you could generate a DjVu from each. --EncycloPetey (talk) 00:09, 1 January 2021 (UTC)

@EncycloPetey: LLL and H8 are done. I checked them, and they looked fine, but you have a better eye for these than me. Pericles I've failed to find any scans of. --Xover (talk) 21:39, 1 January 2021 (UTC)
I have found a Google scan [1] but I haven't checked it's quality. --EncycloPetey (talk) 01:53, 2 January 2021 (UTC)
Note that It should be uploaded to "File:Pericles (Yale) 1925.djvu" without the full title. Using the full titles for the Yale Shakespeare series is needlessly cumbersome, or we'd have had "File:The most excellent and lamentable tragedy of Romeo and Juliet.djvu" --EncycloPetey (talk) 02:04, 2 January 2021 (UTC)

Proper Poem tagEdit

Just a note as you don't appear to be watching that bug or component: I've hacked up a proof of concept for phab:T8419 (semantic poem support). Inductiveloadtalk/contribs 15:47, 1 January 2021 (UTC)

@Inductiveload: Thanks. Not that I've thought this through, but… I'm sceptical of using the wikimarkup indentation syntax. I see the reasoning, but it's designed for a different purpose (which has landed us in trouble before). And I suspect we'll rapidly want more control ("this is a hanging indent line", "this is a centered line", etc.; CSS classes essentially). The wikimarkup table syntax with {{ts}} is one possible model for it. Explicit stanza and line extension tags another possibility. But in any case, thanks for kicking this; and thanks for the headsup! --Xover (talk) 19:13, 1 January 2021 (UTC)
Hmm, yeah, I can see why you might want some better handling. The existing tag (and the new tag) are cheating a bit with just splitting the wikimarkup lines on newlines, which can be a bit suboptimal:
line 1<ref>reference line 1
this will be a new line</ref>
The thing that attracts me most about a "bodge mark 2" like the ppoem tag, rather than a full-blown table-style syntax is that it would be a drop-in replacement in 99% of cases. Conceivably, you could also think of a syntax like this to apply styling to the lines:
line 1
|style="text-align:center;"|line 2 (centered)
A "poem table" syntax like this might work and be more robust since it doesn't use line breaks to break up lines and stanzas, but you'd have to be more careful in applying it to existing pages and it's not so easy to proofread as every line needs markup:
| line 1
| line 2
| line 3
| line 4
Inductiveloadtalk/contribs 20:20, 1 January 2021 (UTC)

Eumenides requestEdit

Could you also generate a DjVu from (external scan) and upload locally to File:Eumenides (Murray 1925).djvu? You can compare against File:Choëphoroe (Murray 1923).djvu for much of the markup. I have checked the scan, and there seem to be no problems. I just ask that you use straight quotes and apostrophes, rather than smart quotes and curly apostrophes, if you can manage that. The other two volumes in the set have text layers with straight quotes, and it will go faster if I do not have to check them as I go.

There is no rush. I will finish his Agamemnon volume before starting on the Eumenides. --EncycloPetey (talk) 03:28, 2 January 2021 (UTC)

@EncycloPetey: Now up at Index:Eumenides (Murray 1925).djvu. Since this edition used curly quotes that's what the OCR is going to pick up. I do have some hooks where I could manipulate the text in the conversion, but I'm not immediately comfortable doing that since it wouldn't match the edition. But since curly quotes can be unambiguously converted to straight I'm thinking we can find some half-decent client-side way to fix them. I'll get back to you on that score… --Xover (talk) 12:53, 2 January 2021 (UTC)
Thanks. --EncycloPetey (talk) 15:46, 2 January 2021 (UTC)

template HeaderEdit

Hello. I have noticed that the TOC at The Czechoslovak Review/Volume 1 which is wrapped in the float right template has recently appeared above the header, although it was not causing any problems some time ago. Is it possible that the reason is this change in the {{Header}}? --Jan Kameníček (talk) 11:20, 3 January 2021 (UTC)

Solved :-) I just moved it below the header and now it is OK :-) --Jan Kameníček (talk) 12:06, 3 January 2021 (UTC)
@Jan.Kamenicek: :-) --Xover (talk) 12:08, 3 January 2021 (UTC)

#switch for Template:PD/US ?Edit

Hi. I am on the run, can you please look at Template:PD/US and see if we can easily migrate it to #switch:. All the #ifexpr: are going to be expensive. — billinghurst sDrewth 05:04, 6 January 2021 (UTC)

@Billinghurst: That won't work here because #switch can only compare equality and the logic in the existing #ifexpr is evaluating relative size (greater than, less than, etc.). I can take a look at moving that logic into a Lua module though, to see if the same logic expressed there will be easier to read and maintain. It should definitely be less expensive computationally since we can do variable assignment and relative comparisons natively, but it might not necessarily be more readable and maintainable for people used to template syntax. --Xover (talk) 08:11, 6 January 2021 (UTC)
Thanks, thought it was the case, though didn't have the time to get my brain into that space. It is not native thinking for me. — billinghurst sDrewth 23:49, 6 January 2021 (UTC)


Index/Page clean up required. — billinghurst sDrewth 11:47, 11 January 2021 (UTC)

Done. Thanks. --Xover (talk) 11:55, 11 January 2021 (UTC)

GLAM presentationEdit

Hi, [kind of continuing the conversation we sort of started a few months back about sorting a process for GLAM contributors… ] I've just arranged with @Giantflightlessbirds: to go down to their part of the country (Westland) in a month's time and give a seminar on Wikisource to the library staff and volunteers. Covering how it can be used to rescue and make available collections of PD texts. One of the local historical societies has acquired some journals of early settlers of their region, and there is a collection of local publications that aren't available anywhere else. My thinking is that I'll post the seminar somewhere on here after I've delivered it so that others can use it—or parts of it—when they have similar opportunities (pandemics permitting). GFB will also use the content to reach out to GLAM colleagues across the country and see if we can increase the NZ content beyond my own contributions. Cheers, Beeswaxcandle (talk) 07:43, 14 January 2021 (UTC)

Migration templatesEdit

Do we have a template for "this version is a dodge-ass PG version. We also have a scan, we should use that one day"? Or should we make a versions page with the PG and scan version (as redlink + {{small scan link}})? The latter involves quite a bit of page shuffling if you want to place the versions page at the base name. Inductiveloadtalk/contribs 13:20, 19 January 2021 (UTC)

@Inductiveload: No. And we have people who are not yet persuaded that scan-less dodgy Gutenberg texts are anything but a legitimate edition on par with real editions. So the options are a) to complete a new scan-backed edition and then speedy the dodgy text as redundant (which the policy allows) and hope nobody notices so that we have to have that discussion again, or b) to complete a new scan-backed edition and transclude it over the dodgy text and hope nobody notices and makes a fuss so that we have to have that discussion again. I'm opting for option b as the, hopefully, least controversial approach (besides, I like preserving edit history when it doesn't cost anything).
But whatever we do, we should definitely not preserve the Gutenberg texts once we have a proper edition. They're grandfathered in, and there's a legitimate argument that they're better than nothing (I disagree, but it is a valid argument), but once we have at least one proper scan-backed edition they definitely need to go.
However, I think we could create a "this text is not scan-backed / Proofread [and should be replaced with one that is]. Here's a (scan|index) to work from." without stepping on too many toes. --Xover (talk) 13:39, 19 January 2021 (UTC)
A wild pair of secret templates appear! {{Project Gutenberg}} and {{Second-hand}} have existed since 2012. Inductiveloadtalk/contribs 14:18, 19 January 2021 (UTC)
@Inductiveload: Ah, yes, but these are talk page templates (nobody checks the talk page). --Xover (talk) 16:42, 19 January 2021 (UTC)
Maybe we should move them to the main pages? After all, that's where the other ones go. Inductiveloadtalk/contribs 16:43, 19 January 2021 (UTC)
@Inductiveload: I'd be leery of doing that en masse, but adding namespace detect and subtly nudging new uses towards mainspace sounds manageable. Maybe. --Xover (talk) 16:47, 19 January 2021 (UTC)
I think all you'd have to do is switch tmbox for ambox in the namespace detector. Inductiveloadtalk/contribs 16:48, 19 January 2021 (UTC)
Also, what do we do with the {{textinfo}}s from transitioned pages? unsigned comment by Inductiveload (talk) 18:35, 19 January 2021‎ (UTC).
@Inductiveload: tmboxambox: ayup. {{textinfo}} should go once it no longer reflects reality. If the talk page is otherwise empty we can just nuke it entirely. --Xover (talk) 20:03, 19 January 2021 (UTC)

Fix to Template:Categories by dateEdit

My brain is busy doing other stuff, could you please look at this template, as it is not marking BCE in the top runner for 1st C BCE per Category:10s BCE works and others

It is also categorising incorrectly into Category:1st century works whereas it should be in Category:1st century BCE works‎, guessing something about the year parameter being empty and the BCE being outside of the determining criteria.

Also guessing that all "(works|deaths|births) by ..." templates have same issue and this will fix them all. Thanks if you can. — billinghurst sDrewth 10:19, 26 January 2021 (UTC)

@Billinghurst: I'll take a look. Could you point me at one specific page that is incorrectly categorised by the template, and—just to make sure my dumb brain doesn't get me lost on the way—list the incorrect category it is currently in and the correct category it should be in instead? Looking at the cats you already gave, the only obvious problem I saw was Category:10s BCE works which was being categorised into Category:1st century works when it should have been in Category:1st century BCE works. But that one was due to a missing era parameter in the template invocation, so that doesn't tell me much about the bug in the template itself. --Xover (talk) 10:42, 26 January 2021 (UTC)
It was the runner in the category, and you fixed both. Sorry am stuck in fixing some of the NLS works that I have tripped upon when fixing something else, upon something else, while doing something else. <sigh> the depths of issues at times. Thanks. — billinghurst sDrewth 11:16, 26 January 2021 (UTC)

Another toyEdit

Handy script for editing without going into edit mode:

// maintain script has no purpose on edit or special
if ((mw.config.get("wgCanonicalNamespace") !== "Special") && ["edit", "submit"].indexOf(mw.config.get("wgAction") === -1) {
  mw.loader.using(['ext.gadget.utils-difference', 'mediawiki.util', 'mediawiki.api',
      'oojs-ui-core', 'oojs-ui-windows', 'oojs-ui-widgets']).done(function() {

Let me know if you can think of useful things to preload into it if you find it useful. I will eventually make it possible to plug in your own tools. Inductiveloadtalk/contribs 00:05, 28 January 2021 (UTC)

@Inductiveload: Just started playing with it, and skimming the source I'm excited because it looks like an epically useful tool!
But ran into first issue fast: the regex replace inserts "\n" instead of a literal newline when you put "\n" in the replacement pattern. And you can't put a literal newline character in that text field (OOUI won't even let you paste them in). I tried looking for the culprit code but, to be honest, OOUI code makes me want to tear my hair out. Are you perhaps double-escaping the replacement string as well as the regex? --Xover (talk) 15:51, 26 February 2021 (UTC)
I think OOUI did that for me, I've unescaped it now. Try it again :-).
Something I am still missing: a good way to choose the tool. The button select thing is a bit shonky, but the dropdown/combo widget in OOUI is rubbish and doesn't really work for this application. Any ideas? I can roll my own à la User:Inductiveload/quick_access.js but that's like, totally effort, man. Inductiveloadtalk/contribs 16:03, 26 February 2021 (UTC)
@Inductiveload: Now the first "\n" gets turned into a literal newline, but the subsequent ones are inserted as strings. :)
(e/c) Hmm. Come to think about it, both regex and replacement pattern should probably be multiline text fields. A lot of our use cases are going to be a moderately large chunk of wikimarkup being transformed, with a relatively small number of regex bits thrown in to handle variations and capture data.
Oh, and it needs a way to save prefab transforms ala. TemplateScript's regex feature. I started playing with this because I have 74 pages where I need to replace a deprecated template with two newlines: too few to fire up AWB or Pywikibot, but too many to edit completely manually. Doing it once manually and then re-applying the memoized version for the rest is a convenient compromise for this situation.
Hmm #2. I have some stuff I might always want available, akin to the template insertion tools, but which are too specific to merit adding to the script for al users. But then there's also stuff like this current task, running through a category and cleaning up something until the cat is empty. I'll reuse the transformation 5 or 50 or 500 times, but then I probably won't ever need it again. These ad hoc transforms could quite well live in WebStorage (size-limited, aged out by the web browser eventually, not shared across browsers) until I hit the little x to delete it. The more permanent stuff needs another solution (function hooks from user .js probably). --Xover (talk) 16:11, 26 February 2021 (UTC)
Oh, hmm, you're special-casing \n? I would've thought generally un-escaping the escaped string passed from OOUI would be better. But that maybe has oodles of worms in it I guess. But /g seems to be what's missing, yeah. --Xover (talk) 16:15, 26 February 2021 (UTC)
OK, try that. Damn replace(), grumble grumble.
Agreed about storage. In the mean time, User:Inductiveload/pwb is my preferred way to do semi-one-off PWB runs. Saves a lot of command lines faffing when you can run it from a file. I'd definitely do it for 74 replacements! Probably the config should be YAML or something but the brutal simplicity of the text file appeals too! Inductiveloadtalk/contribs 16:24, 26 February 2021 (UTC)
@Inductiveload: Now it works, except the resultant edit summary is now broken. Compare before and after. --Xover (talk) 16:45, 26 February 2021 (UTC)
@Inductiveload: Hmm. Could the help strings go on the TextInputWidget instead of the FieldLayout in that dialog, so they go after the text field instead of in front of it? And the info widget thingy takes focus when you tab, so it's a bit annoying to tab from search to replace with a detour through the info thing. Maybe an explicit tab index or something? --Xover (talk) 16:58, 26 February 2021 (UTC)
Get out of my head :-p It's on the list. I think I've fixed the newline thing now Inductiveloadtalk/contribs 17:00, 26 February 2021 (UTC)

@Inductiveload: Hmm. /s and /m? Maybe best as toggles in the dialog along with /i to reduce confusion and limit damage potential? --Xover (talk) 21:57, 26 February 2021 (UTC)

At least you get a diff before you nuke something :-p. My kingdom for an issue tracker. Inductiveloadtalk/contribs 22:00, 26 February 2021 (UTC)
@Inductiveload: cf. your comment elsewhere. You can ask for a project on Phab. Both for the whole project (enWS), for your various tools, and you can tag things as personal (I think User-Inductiveload exists by default even, but I haven't checked; and not sure you can have kanban boards and such without a full project). Sam can probably help you get set up if you need it. --Xover (talk) 22:04, 26 February 2021 (UTC)
I've requested a personal project. I think an enWS project would be a good idea too, since we have scads of things that get forgotten and left to rot. Inductiveloadtalk/contribs 22:25, 26 February 2021 (UTC)
So User-Inductiveload is a Thing now. I've subscribed you to two issues related to this script (help affordances and regex flags). Feel free to unsubscribe (and/or tell me not to do that again) or subscribe to other stuff if you want a Phab ping when I pass mental wind on those issues, or when they're done. Inductiveloadtalk/contribs 10:20, 1 March 2021 (UTC)
Thanks! I'm generally unconcerned with "noise" and appreciate being kept informed, so feel free to throw me on the CC whenever you think I might be remotely interested (or, obviously, if there's some kind of contribution I can make). The flip side is of course that when cycles get tight I actively ignore stuff so I hope nobody gets offended if I'm non-responsive, and reminders when more cycles are again available is appreciated. --Xover (talk) 10:58, 1 March 2021 (UTC)

"Invisible" maintenance textEdit

Hi. Magnus has created a template for me that enables me to do some main subject finds and additions User:Magnus Manske/topicmatcher test, the issue is that I need to poke it into the works to function, which I can manage, though it leaves a visible message, and one which I don't wish to impose on the punters. Can we create an invisible class (#mw-hidden-template ?) that where a maintenance user can activate its visibility through tweaking the class in their common.css? While here, what would be the means to force a template's text to the outside of the header/footer templates, if that was what I chose to do. Thanks. — billinghurst sDrewth 11:50, 9 February 2021 (UTC)

FWIW I have temporarily stuck MM's template inside template:Compendium of Irish Biography for the means of testing and design. — billinghurst sDrewth 11:53, 9 February 2021 (UTC)
@Billinghurst: Hmm. Making it invisible by default with possibility of override from user css should be doable, but I'll have to dig a bit to see how best to do it. Moving the displayed text outside the other output from the same template is a bit trickier, so there we'll need JS (or possibly global CSS), but depending on the details of what's wanted we can probably find some way to do it. --Xover (talk) 12:03, 9 February 2021 (UTC)
I thought that we had a class to do it. Don't fuss the placement too much, that is the least of the issues, and housekeeping only, as I was just thinking search engines that ignore invisible. — billinghurst sDrewth 12:06, 9 February 2021 (UTC)
@Billinghurst: {{topicmatcher}}. It wraps the link in a span with the id #topicmatcher, and imports a TemplateStyles stylesheet that sets that id to display:none (so it's hidden by default). You can override it in user css using #topicmatcher {display: inline !important;} (don't forget the !important, it's needed to override the templatestyles here). --Xover (talk) 13:42, 9 February 2021 (UTC)
Thanks for all the work, all seems to be working well, I have done some adaptation for the cats and stuff, and some annotations about use. — billinghurst sDrewth 00:22, 10 February 2021 (UTC)

Using a template is good in that it doesn't need any fancy JS or CSS to show, but it does inject it into the page area. Would it make more sense to have it shunted to the .mw-indicators area by JS? Perhaps adding a class like .wd-tool-template or similar so that further tools can be added and get the same treatment (while keeping the ID for granular targeting if a user only wants one)? Then it can just be:

$(function() {

Inductiveloadtalk/contribs 14:24, 9 February 2021 (UTC)

@Inductiveload: What I really wanted to do was implement the whole thing as a gadget instead of a template so that only those that want it get it. But I couldn't find any sane way to access WD from JS, so this was more of a quick hack solution. I think right now Billinghurst is the only one that wants the topicmatcher link, so having it in every page (in the relevant works) for every user is a bit overkill. --Xover (talk) 14:35, 9 February 2021 (UTC)
Hmm, I've have a look-see - Wikidata is my next target for User:Inductiveload/maintain.js and User:Inductiveload/popups reloaded.js anyway. Inductiveloadtalk/contribs 14:57, 9 February 2021 (UTC)
Here's a first draft: User:Inductiveload/topic_matcher.js. Seems to work OK, though my rubbish SPARQL skills seem to indictate there are actually not a lot of examples:
SELECT ?item ?label WHERE {
  ?item wdt:P1433 wd:Q19020593.
  MINUS { ?item wdt:P921 [] } .
  SERVICE wikibase:label {
    bd:serviceParam wikibase:language "en".
    ?item rdfs:label ?label.

Go to query page

An auto-item creator based on the page base name would be a natural next step. Inductiveloadtalk/contribs 16:02, 9 February 2021 (UTC)
For most of the works that I am doing we know basepagename and its Q, subpagename, authorname and its Q, volume (if exists) and page number on the view, then we are most of the way there. The label for is always subpagename, and the description is usually generic for biographical articles of a work. There are some variations, eg. different contributors, thought that will be on the page where known, or stating unknown author. Depending on whether we are doing biographical or some other topic, we can get title and subtitle, for example Andrews, George (Q105143209).

Also noting that WEF framework has an IMPORT DATA function, so even if we can arrange the underlying data per page so that can inhale something would be fantastic, as I usually then manage the data in article across to biographical article. Noting that I have found no documentation for WEF's import data, and author has not been responsive to my naïve questions. — billinghurst sDrewth 00:43, 10 February 2021 (UTC)

Re your query, running it in on IrishBio is the fail, as much of that work predates WD, and I usually work item by item so we don't have incompleteness. I chose that work as it had the derived template. The Dictionary of Australasian Biography, 1892 (Q19084840) is a better work to run your query, though as a work it needs to be migrated to its template, just on my TO DO list as I work on other priorities.

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

billinghurst sDrewth 00:50, 10 February 2021 (UTC)

I think QuickStatements is probably the more usual way to import ad-hoc bulk data to Wikidata, and it's explicitly easy to post data into. If there was a tool to generate data batches, that's what I would target. Inductiveloadtalk/contribs 01:03, 10 February 2021 (UTC)
*But* that is only functional if you want to create a batch. I am more looking to a functional and integrated addition of the data, linking to WD, data extraction to the subject item, and a link at WP. I also do them as I create them per transclusion. — billinghurst sDrewth 01:45, 10 February 2021 (UTC)

Capitalization templatesEdit

Hi Xover. Thanks for the detailed edit summary here. I am a bit confused though — the guidelines at Help:Templates#Text Case make no mention of the principles you described; in fact, it seems to suggest the contrary:

While it is OK to omit the use of the upper case, lower case, and capitalize templates altogether, where they are used they should only be inserted where the choice of case in the work is a formatting decision (ex. special formatting in a work's title), rather than as required for spelling or grammar (ex. in an acronym).

The edits I made were precisely where capitalization was used in the source for styling/formatting, rather than because it was semantically meaningful. And the language used in that passage ("it is OK...") hints that omission of the templates is accepted, but not necessarily preferred.

Am I missing some community discussion or additional help page where the position you describe is explained in more detail? Cheers, Waldyrious (talk) 19:57, 10 February 2021 (UTC)

@Waldyrious: That page is a help page for the various formatting templates available. It's trying to tell you that while these templates exist, their mere existence should not be read as any requirement, or even suggestion, to use them. But if they are used, they should only ever be used when text case is a stylistic matter. As for dos and don'ts we (to my great personal annoyance) tend not to document stuff like that in any structured form because the community is generally averse to anything that smacks of "bureaucracy". --Xover (talk) 21:24, 10 February 2021 (UTC)
I don't know why we bother putting {{uc}}, {{lc}} and {{capitalize}} up there in pride of place. They're almost entirely useless (or worse) in 99.9% of actual content-space use and are mostly actually useful in templates for technical chicanery to do with string matching. {{sc}} and {{asc}} are nearly always the correct choice. Inductiveloadtalk/contribs 23:10, 10 February 2021 (UTC)
@Waldyrious: That is a help page in our Help: namespace that talks about our common templates, the place for style and guidance information is WS:Style guide; our policy stuff is housed in the Wikisource: namespace.

@Inductiveload: Part of the reason that templates exist is they are there is to stop the use of {{lc:xxx}} and {{uc:xxx}} which was a particular problem; and to allow a copy and paste of the text without getting all the case. If you think that the order is wrong, or less relevant, then change it. — billinghurst sDrewth 03:45, 11 February 2021 (UTC)

@Billinghurst: Hmm, I'm intrigued by what you mean with "and to allow a copy and paste of the text without getting all the case" — the main reason I thought it made sense to use these templates in content-space was precisely so that copying the transcribed text wouldn't bring non-semantic casing along (e.g. the all-caps first word after a dropped initial). Am I interpreting this incorrectly? --Waldyrious (talk) 18:25, 12 February 2021 (UTC)
Furthermore, Wikisource:Style_guide#Formatting says (emphasis mine):
Formatting should be flexible and not interfere with access to the document, knowing that we are trying to reproduce works for modern readership, not provide facsimiles of the time and place. See also Help:Adding texts, Help:Beginner's guide to typography, and Help:Editing.
...which (1) to my eyes seems to suggest that stuff like preserving original capitalization is not an explicit goal (am I reading this incorrectly?), and (2) links to Help pages as further guidance, so it's not clear that one's not supposed to follow what they describe. Am I missing some strategy that would allow me to follow the existing documentation without inadvertently stepping over lines? --Waldyrious (talk) 12:04, 13 February 2021 (UTC)
Thanks for the replies, guys. Xover, I can see your reasoning, and I agree that it's quite a sorry matter that these guidelines are not explicitly documented. I've have several edits reverted (including in the Help namespace, where my goal was to provide others the additional help I wished I had had myself!), because I didn't know the unspoken local rules, and although I'm an an experienced editor in other Wikimedia projects, it's always an unpleasant experience. I can totally see newcomers will less thick skin being entirely turned off after trying to contribute constructively, only to have their edits reverted. Let me be clear — I am not complaining about your reversion, which I can understand; but the documentation would be really helpful. I still recall that comprehensive guidelines documentation was the main reason I was able to get by smoothly when I started out as an editor in English Wikipedia. Anyway, If you once again find yourself advocating for more explicit documentation of guidelines, I'd be happy to add my voice to that effort. --Waldyrious (talk) 18:25, 12 February 2021 (UTC)
@Waldyrious: You hit it square: for anyone who haven't been involved in the long slow organic development of the current practice it feels arbitrary and impenetrable, and for those who have it's nearly as frustrating because all these newcomers keep arguing on points you "know" are settled. There are good arguments on the other side of the coin too, of course, but for my part I think we've skewed too far towards one extreme of the scale.
In any case, glad to hear we've not discouraged you; and do please feel free to hit me up here if you need help with anything or something else seemingly doesn't make sense. --Xover (talk) 19:00, 12 February 2021 (UTC)
Thanks — will do! --Waldyrious (talk) 11:52, 13 February 2021 (UTC)

Lang's Fairy BooksEdit

First of all, thank you for putting them together or back together.

Second, wikisource used to have a link at Andrew Lang's Fairy Books which (iirc) I accomplished via a subpage from the main and then "transcluded" that to the main.

Maybe the data link was gone when you removed it.

I would like to do that same thing for other items, like biological species, stars, planets, representations of mathematical formulas, etc. -- items that don't require a whole portal but are lost to the rest of wikidom by being available only at the broader subject (portal) to which they belong.

Was there a wd link to the fairy book subpage?

Will you not collapse things in the future if they have a wd-id?--RaboKarbakian (talk) 14:49, 13 February 2021 (UTC)

@RaboKarbakian: I see now that I have somehow managed to miss this message. My apologies: I thought for certain that we had discussed this, but it appears I only imagined that to be the case.
As mentioned in response to your more recent message, the Wikidata link above (and the interwikis) should work now. The wikidata linkage for this concept is a bit awkward since it is for the series as a whole (as is the topic of the Wikipedia article), but we do not usually deal with that level to any significant degree. However in this case a Portal: ought to be a pretty good fit, so I've created that now.
As a general rule of thumb, subpages on Wikisource shouldn't be linked to Wikidata like that, except in mainspace when the subpage is for a work in its own right (e.g. it is an edition of a fairy tale in a collection of fairy tales). Subpages of portals and author pages are like pages in Index: and Page:; they're internal workspaces not interwiki targets.
But what makes you say "don't require a whole portal"? biological species, stars, planets, representations of mathematical formulas all certainly seems to be subjects wide enough to merit portals. If we don't yet have enough works on a particular subject to merit creating the portal, then that's also a good indication that we don't need the interwiki link yet either. --Xover (talk) 20:19, 4 March 2021 (UTC)

Category:Wikipedia message box parameter needs fixingEdit

Not certain that this worked. The black magic in the template is not something I have dug into. Apart from anything else that it says WP. — billinghurst sDrewth 14:48, 16 February 2021 (UTC)

@Billinghurst: Thanks. It didn't. That's partly why I'm doing a spin through these now and making them more consistent. --Xover (talk) 15:04, 16 February 2021 (UTC)

I need your response pleaseEdit

At Wikisource:Copyright_discussions#Remarks_by_President_Biden_in_a_CNN_Town_Hall_with_Anderson_Cooper_deleted it seems like you've made a claim that really requires some substantiation and clarification. As an admin, I would hope that you see the value in having a clear understanding of the copyright status of works on this project. In case you didn't get the ping message somehow, I'm requesting on your talk page that you answer my questions at the original post. Thanks. —Justin (koavf)TCM 16:36, 21 February 2021 (UTC)

@Koavf: It's on my list. --Xover (talk) 17:43, 21 February 2021 (UTC)
Thumbs up emoji. —Justin (koavf)TCM 17:48, 21 February 2021 (UTC)

Ppoem is getting thereEdit

I think Template:Ppoem is looking fairly ship-shape. The "magic" syntax is still up in the air, but I think it hits most of the poetry pain points, and, significantly, does not require any MW devs to deign to review changes to the extension. Inductiveloadtalk/contribs 18:05, 26 February 2021 (UTC)

@Inductiveload: Awesome! I'll try to take a proper look in the not too distant…
Immediate reservation: this approach makes making the canonical usage model be {{ppoem/s}} … {{ppoem/e}} impossible. I'm beginning to lean towards making this the standard model for all block based or functionally block based templates for sanity, consistency, and ease of explanation. For any non-trivial stretch of text, having arbitrary strings in a positional parameter is inviting an endless litany of papercuts of the "you need to escape this character in that non-intuitive way". In an actual extension like mw:E:Poem you can get the best of both worlds (start and end tag based for the user, but full control of everything in between), but for a template-based approach the limitations are going to be a serious crimp in its style.
Then again, given its potential obvious advantages over the alternatives, I'm maybe not too worried about letting this be the exception that proves the rule. :-) --Xover (talk) 18:20, 26 February 2021 (UTC)
At the least this can be a test bed for the extension model (e.g. syntax and so on). As long as the data model is the same, we can bot it out later as long as we are happy with it. Anything that requires a dev to sign off will take, I would estimate, about 5 years to get through to deployment, and I'm not even really sure I'm joking.
Luckily for us, tables and equals signs and pipes are not very common in 15-19th century poetry. :-D Inductiveloadtalk/contribs 18:25, 26 February 2021 (UTC)

Erm... Usages removed on a template?Edit

I see plenty..? ShakespeareFan00 (talk) 21:01, 26 February 2021 (UTC)

@ShakespeareFan00: You're right. Darn it! Thanks for the heads up! --Xover (talk) 21:09, 26 February 2021 (UTC)
And in replacing it needs the unit -

ShakespeareFan00 (talk) 21:39, 26 February 2021 (UTC)

Indent 0Edit

The indent-zero on Page:Fairy_Tales_for_Worker's_Children.djvu/5 was kind of deliberate, because although it's redundant in the default "no-indent, gap for paragraphs" presentation on-wiki, it is not when exported to an e-reader which applies "conventional" print-style "indented, no-gap" paragraphs. The alternative is a classed span, perhaps, {{no indent}}, to make it clearer? Inductiveloadtalk/contribs 08:14, 1 March 2021 (UTC)

@Inductiveload: E_INSUFICCIENT_CAFFEINATION: Could I get the "with a teaspoon" version? --Xover (talk) 08:30, 1 March 2021 (UTC)
Is there even such a thing as sufficient caffeination on a Monday?
TL;DR I'd like it to look like Page:Fairy_Tales_for_Worker's_Children.djvu/5 on an e-reader which applies a platform-defined "default book-ish CSS", as opposed to also indenting the "Dear Little Comrades:" the same as the following paragraphs. The following is from an e-reader (well, an emulator, but same outcome):
This is a fairly common idiom in print, e.g. the salutations on Page:Parliamentary Papers - 1857 Sess. 2 - Volume 43.pdf/29.
To pick a gnat on a nit, there's also a weeny bit of leading there,
Actually....the most semantically correct solution is probably to define a template {{salutation}}, with a default of 0 indent and the ability to add leading when needed (since that's the exception, rather than the rule), which makes the intent clear. Inductiveloadtalk/contribs 09:20, 1 March 2021 (UTC)
@Inductiveload: Enlightenment dawns…
Ah. That was not a case that had occurred to me. Hmm.
Ok. We're talking about manually compensating for a known quirk in a class of user agents. The quirk is triggered because we do not explicitly style our practice in terms of indenting paragraph start and thus leave it up to a user agent's default stylesheet. Arguably the user agents in question have picked a dumb default, but as a general rule we do not have any significant influence on their defaults and so must try to compensate for them where necessary.
As you say, the semantically correct solution is to explicitly mark this as what it is: a salutation. However, there are two issues with that: first that {{indent|…|0}} is used for things other than salutations (but to achieve the same effect, I now realise), and second, but more importantly, that it would be way too detailed semantics compared to our general practice. We can and should drift towards more semantic markup (more semantic templates, not particularly at the generated-HTML level), but where we are today that level of detail would be significantly incongrous.
Which brings us full circle to your initial idea. We need a way to mark up that "in this specific instance it is important that the indentation is thus" rather than leave it up to the user agent's style sheet. I'm thinking that the semantics we want to express there is closer to {{never indent}}—other paras can be indented or not, since we leave it up to the user agent—but that {{no indent}} may be more intuitive.
So… My initial thought is to create {{no indent}} with a redirect at {{never indent}} and at {{ni}}, document both No … and Never … variants as synonyms in the usage section, and encourage use of {{ni}} in practice as a paralell to {{ti}} and {{hi}}. I'm thinking it should just be a wrapper around {{ti}} with the first param forced to 0 for simplicity and maintainability. But perhaps the leading issue is important enough to merit a more complete solution?
PS. In my work on replacing {{indent}} I'm finding a lot of cases where it is being used to achieve a side-effect, e.g. to force a line break or similar (which is why I'm not ready to bot-convert these yet). To avoid ending up with too massive backlogs I think it's probably a good idea to do deep dives on our various templates from time to time to catch side-effect uses and try to make specific templates for those purposes. Any template that by design or usage does too many things is going to be a real pain to modify once it's been left to amass usages too long. I have hopes for the ~6k uses of {{indent}} (but am worried about its /s, /c, and /e variants), but there are others with truly ridiculous transclusion counts and widely irregular usage patterns. --Xover (talk) 10:51, 1 March 2021 (UTC)
I'm not sure it's fair to call it a a known quirk in a class of user agents. If the document doesn't specify a text-indent on a paragraph, it's up to the UA to do what it wants. Part of the reason we do not generally force indents is to allow UAs to make the (valid) choice on their own to indent paragraphs how they see fit.
However, there are cases, as here, where the line is specifically not indented. The UA can't know about that unless we tell it. For example: the first line of Page:Parliamentary Papers_-_1857_Sess._2_-_Volume_43.pdf/27 is indented (i.e. should have the "default" indentation rule), so we cannot expect a UA to be "smart" and apply a nth-of-type or whatever (also the spamming of <p> by MediaWiki means applying a p:nth-of-type(n) will probably end in tears).
Indents being the honourable exceptions, the Wikisource method of "direct" formatting is actually pretty poor semantically-speaking, because it militates against UAs being able to make formatting choices on their own, as well as making the content void of meaning. For example {{c|{{larger|Chapter 1}}}} should akchually be <h2>Chapter 1</h2> in concert with work-level CSS that sets the font-size, weight, leading and text-align as needed. We're inching towards such a possibility, since CSS is now possible in the Index namespace (though only admins can actually turn a page into CSS for now: phab:T271710)
And this is why, IMO, a {{salutation}} might be a better call, in this case specifically, than a {{no indent}}, because it says what it is (probably via class="salutation", not how it looks (though it can provide a default, either by calling {{ti}} or its own TemplateStyles). Obviously, if the text in question is not a "salutation" and still needs a zeroed indent for some reason, then {{n(o,ever) indent}} or {{ti|0|...}} should be used. Inductiveloadtalk/contribs 11:16, 1 March 2021 (UTC)
@Inductiveload: "Quirk" in the sense "something peculiar to that class of user agent", not as in "quirks mode". And my point was that {{salutation}} is way too detailed a level for normal people to relate to semantics. Look at the semantics represented in HTML: it's headings and sections and paragraphs. The most fine-grained concept we can sustain (factoring in our volunteers) is probably the chapter title: once you're down to smaller components you cannot expect contributors to relate to them as semantic concepts except in very controlled subsets. For example, it might make sense to have a suite of templates designed to help with proofreading collections of correspondence. These may have sufficiently consistent formatting across letters, and be a sufficiently narrow context, that a {{salutation}} would work well. But this would be very near to the EB1911-specific templates: it just doesn't work as a general solution.
PS. There's no need to sell me on the concept of semantic markup. I'm a veteran of that war and have the scars to prove it. --Xover (talk) 18:47, 1 March 2021 (UTC)
@Xover: perhaps, but historically we are missing the critical part of the semantic structural/stylistic split, but if we can get per-work CSS to work (phab:T276067), we might be a good step closer, even if only for certain subdomains. Because then you don't need "n works" × "t types" templates, you just need the CSS for the work and a template that applies relevant class or tags (so "t" templates + "n" CSS sheets, note the plus). For example, {{EB1911 fine print}} would simply need to be {{fine print}}, and the actual meaning of that (in terms of formatting) is provided by an EB1911 style sheet. Ditto for {{ch}} - you just use {{ch}} and the CSS does the thing automatically, based on the work's CSS - center, larger, leading, whatever. Easier than {{c|{{larger|Foo}}}}{{dhr}}{{rule}}{{dhr}}. Pie in the sky, perhaps, but it could be a powerful tool for a radically simpler Wikicode experience. Inductiveloadtalk/contribs 18:58, 1 March 2021 (UTC)
@Inductiveload: On those points we are in perfect agreement, and I think those examples should be priorities. But I don't think {{salutation}} has that wide applicability, and hence the cost—benefit doesn't add up on that one. Note that in your examples more limited and specific templates become more general and reusable, while {{saluation}} is a dramatic narrowing of scope compared to {{indentation}}. It's an indentation template that can only be used for one tiny little part of edited collections of correspondence.
PS. It's also worth noting that the {{dhr}}{{rule}}{{dhr}} bit is not a natural fit for a stylesheet (you can fake parts of such constructs in CSS, but not all) so we'll still need to have a balance between templates and stylesheets even if we get proper per-work CSS support. --Xover (talk) 19:12, 1 March 2021 (UTC)
Well, the {{ch}} might have a rule=yes parameter, which emits an <hr class="chapter_rule"> that the CSS hits, since that is indeed a structural element. Sure, it's not going to cure all ills. I'm not selling snake oil, but I do have some rather nice slow-worm tincture? Then, {{ni}} and call it a day on this one? But then how do you capture the leading (if, indeed, one does bother): nest two templates, {{sbs}} or let {{ni}} adjust leading? I'd really rather not use {{dhr}} if I can avoid because dumping pure-stylistic divs in feels odd. None fill me with joy. Having templates that wrap CSS so thinly does rather beg the question of why we bother if we're basically writing a homebrew creole for, essentially, <p style="text-indent:0; padding-bottom: 1em;"> Inductiveloadtalk/contribs 19:28, 1 March 2021 (UTC)
@Inductiveload: I'm more comfortable with a leading parameter and attendant code on {{ni}} than {{salutation}}. But I'm still not sure it's actually needed versus our other ways to do it. Can you give me a ferinstance?
I am still not convinced that {{sbs}} makes sense, which is why I'm still treating it as a semi-private experiment. It was born to address two itches: poem formatting (mainly the pre-wrap), and inconsistent and unintuitive formatting templates ({{text-indent}} takes the length in the first slot and requires a unit, {{indent}} takes it in the last slot and requires a unitless number; we have multiple templates for margins with different params; pairs of templates that are often used together have different models for how to do start+end, some use /s some /begin some {{template start}} etc.). A lightweight CSS wrapper made the latter problem much better, but it is, as you say, also a bit of a creole; and as currently conceived it is only internally consistent and predictable, but inconsistent with all our other templates (using spaces to separate params for one thing; fixable, but then I'd need to make it a Lua module…). Which was partly why I'm looking at {{indent}} to see if it is feasible to instead standardise our normal templates more. The poem bits of {{sbs}} never worked as well as I'd hoped (mainly because of MW's p-wrapping), and if {{ppoem}} (which I haven't had a chance to look at yet) solves some problems without major new annoyances it's possible the value proposition for {{sbs}} evaporates.
I really wish we could do {{ppoem}} in a /s+/e model without insane hacks because the inherent limitations of the 1= model means it can never be entirely without caveats. But on the other hand, if we get to a point where that's our only divergent template I can live quite happily with that exception. --Xover (talk) 20:41, 1 March 2021 (UTC)


@Inductiveload: Actually digging into it I can't find that there's any actual leading qua leading in play. But there is the issue of p-wrapping rearing its head. {{indent}} does <div>\n…\n</div> while {{text-indent}} uses <div></div>. For a single-line argument such as on Page:Fairy Tales for Worker's Children.djvu/5, that means the former gets wrapped in <p></p> but the latter doesn't. And p tags get a top margin both in user agent default stylesheets and in MW's stylesheets; in my case a margin of 7px.

But if that margin hasn't collapsed into the adjacent one, I'm unable to identify it with my Mk. 1 Eyeball™. Is this the leading you were referring to or am I missing even more here?

And annoyingly enough this means {{ti}} is going to be behaving wildly inconsistently depending on whether you have a single line or multiple lines, and whether or not there is a newline at the start and end of the template parameter. I wonder how many existing pages are actually relying on this side-effect of the implementation… --Xover (talk) 14:20, 2 March 2021 (UTC)

The "leading" thing is about the first line of Page:Fairy_Tales_for_Worker's_Children.djvu/5 being just a touch further from the next line than most para-breaks in that page. It's an super minor thing, but the point is that any template flexible enough to arbitrarily set text-indent and leading will probably end up being a {{ts}}-style mess that's basically just CSS in a home-made dress and has zero semantic content.
On reflection, you quite are right that {{salutation}} is not a good way forward. However, directly formatting it with inline CSS (with or without a translation layer like {{ti}} or {{sbs}}) doesn't sit well. What I think we actually want is to be able slap a per-work class on in (say .ftfwc_salutation) and target that with CSS from the work's own CSS sheet. The infrastructure for which is not quite ready for prime time (but is actually closer than one might think: phab:T271710). I'm not 100% sure what would be the ideal API to editors would be here, but it might look something like {{block class|ftfwc_salutation|...(or /s}}, though I am not quite sure just yet.
Perhaps the issue with {{ti}} is that it there aren't newlines inside the div tag? I know that can upset the parser in bizarre ways, and I fixed {{EB1911 fine print}} recently for that exact reason. Inductiveloadtalk/contribs 14:51, 2 March 2021 (UTC)
In the scan?!? Oh ffs… I was looking for differences between the old and the new template, so I didn't even glance at the scan. D'oh-so-very-oh!
Yes, the difference is the newlines, and without them p-wrapping will kick in seemingly-randomly and inconsistently. And since p elements have margins that div elements don't, the two templates behave differently in seemingly random ways.
I think you're on the right track with the per-work CSS, but I think {{block class}} is the opposite extreme from {{salutation}} (and suffers much the same problems {{sbs}} does in that regard). I think there's a golden middle in between them somewhere, and I think something like {{chapter title}}—that applies a standard class="enws-perwork-chaptertitle" which is styled in the per-work stylesheet—is a good rule of thumb place to start. Hmm. But, in fact, it might be worthwhile to try to design a small core set of templates (cf. elsewhere) on paper first, to take advantage of per-work CSS, to see if we've hit the right level of abstraction. --Xover (talk) 15:37, 2 March 2021 (UTC)
@Inductiveload: Oh the irony!. (also forgot to ping above ^).
What was the context that prompted this change? --Xover (talk) 15:55, 2 March 2021 (UTC)
Well that's embarrassing. Umm, I feel like it was something to do with this:


*<div style="text-indent:4em">{{lorem ipsum}}</div>
*<div style="text-indent:4em">
{{lorem ipsum}}
  • Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

Re I think {{block class}} is the opposite extreme from {{salutation}} I see what you mean: it depends a lot on how {{salutation}} is implemented (direct CSS or class + TS CSS). I think I didn't quite have my brain in gear when I suggested that. I think it can rest for now - your idea of starting with chapter heading is far better one.
Re per-work CSS, we (as in you, me and other admins) can do it right now, but we really need that PHP variable setting (phab:T271710) in order to progress past a PoC. Inductiveloadtalk/contribs 16:21, 2 March 2021 (UTC)
@Inductiveload: I think we need more than the mere technical ability to store a stylesheet there in order to make it feasible as the way we do styling. Setting it in the Index: page for one thing, and having PRP auto-load that stylesheet, TemplateStyles-style, from <pages … /> for another. Sans that it'll be too fiddly for all but the most "fiddly" of contributors. We'll also have to think a bit about how to handle default styles for these things. Demanding full CSS-fu from contributors is a bit of a big ask. --Xover (talk) 17:12, 2 March 2021 (UTC)


I think this fixes the continuations:- {{Text-indent/c/styles.css}}

And it means you only need one /s or /c call on a page with a regular text indentation. :) ShakespeareFan00 (talk) 15:08, 1 March 2021 (UTC)

@ShakespeareFan00: Hmm. Regular paragraphs should not be indented, so I'm not sure most uses of {{indent/s}} are actually valid. There are some reasonable exceptions (like, as I recall, the headwords in EB1911) but these should all be a single paragraph, in which case {{ti|…}} and {{ti/s}}{{ti/e}} should be equivalent. But whenever these appear in the header and footer the likelihood is high that they just shouldn't be there to begin with. --Xover (talk) 19:22, 1 March 2021 (UTC)

a little spookedEdit

I was going through the history of a community page at the commons, my project, that I initiated, etc. In that history, were some comments with my name that were clearly wrong that I would have never made that were not what I was doing.

I am okay with other users being more than one person, although, saddened by that. But RaboKarbakian should be just me. If I ever have a group project with a single user name (which I cannot imagine), it would be a different user name and they/it would have their own history.

That history and the blanked talk page and schizophrenia (multiple personalities) of that blanked page user has me spooked and mostly sad.

Sorry to bother you.--RaboKarbakian (talk) 18:03, 3 March 2021 (UTC)

@RaboKarbakian: Up until about 2015, each Wikimedia project had separate user accounts. When a common login system was implemented the various accounts were consolidated. As I recall there were at least two others who had used "Xover" on other projects, but at that point they were no longer active so their accounts were renamed so that I could be Xover on all the projects. It is possible that the entries you saw were an effect of this process. --Xover (talk) 18:19, 3 March 2021 (UTC)
About a month ago. Two at the most.
Here is some good news. Wikisource has made it to w:en:Jupiter before wikivoyage. Not so "lucky" with the moon. Maybe you could reconsider the fairy books edit so source can be there also?--RaboKarbakian (talk) 18:38, 3 March 2021 (UTC)
@RaboKarbakian: I'm sorry to say I followed neither of those allusions. Explanations for a bear of very little brain? --Xover (talk) 18:42, 3 March 2021 (UTC) so no wikidata link to just the fairy books and no mention of them on other wikis. That was February 6, less than a short month ago.
If you look at the side bar of w:en:Jupiter, you will see a link to wikisource that will take you to a list of just the articles about Jupiter here. When the "enabled, rule-following know-it-alls" here (I am frustrated today because the same thing just happened to Gentlemen Prefer Blondes, so no working with other wiki there either) delete something that is at wikidata, wikisource becomes isolated and, imo, boring and full of sad rulesy people.
So, the fact that Wikivoyage made it to "the moon" before Wikisource is a sad and pathetic truth. When I ask that you restore the fairy books to the inclusion I created, I am asking that wikisource not be sad and pathetic. If not, maybe something can be put in the welcome script about a love of pasts with no future, as even a 3 years from now PD film can not be envisioned.--RaboKarbakian (talk) 15:02, 4 March 2021 (UTC)
@RaboKarbakian: Check your interwikis again now. --Xover (talk) 20:01, 4 March 2021 (UTC)
First, an apology. My mornings often start with a typo. I don't know how to fix that. Usually it is at the commons. Yesterday, I was reacting wrongly to a speedy that I requested. A good thing tho is that I chose to torment you, the previously not quite innocent.
The portal is nice, my first thought was overkill but my first thoughts are usually wrong. Those books, while edited to be "nicer" than the originals, have stories that are particularly brutal by modern parent standards. I found it interesting that Lang chose to leave out the part about Gulliver peeing on the Queens palace to put out the fire. Eras of political correctness....
So, to summarize, I am sorry. I thank you. And, isn't life interesting? not just now, but through the ages....--RaboKarbakian (talk) 14:36, 5 March 2021 (UTC)

Wikilinking revision - first draftEdit

Hi, a first draft for initial consideration before we go to the wider group is at User:Beeswaxcandle/Sandbox4. Let me know what you think. I'll tag a couple of others here for convenience. @Inductiveload, @Billinghurst, @Prosody: Beeswaxcandle (talk) 08:53, 4 March 2021 (UTC)

@Beeswaxcandle: I have made some comments "semi-inline". Feel free to move them elsewhere if you don't like them there. Inductiveloadtalk/contribs 09:48, 4 March 2021 (UTC)
@Inductiveload: I think banning plain links and links that take the reader to Wikidata is good. The flip side is permitting it when we have a suitable template. I'm thinking "show page preview + sister links if only WD; link to Wikipedia if an article exists; make sure the user only ends up on Wikidata if they specifically indicate they want to go there". All details subject to discussion and amendment of course, but the basic principle that Wikidata is not a suitable direct destination for a link in our works is sound I think. --Xover (talk) 10:05, 4 March 2021 (UTC)
@Xover: sure, I'm in agreement that WD is a very undesirable destination to dump a reader. Even if we have nothing better (or if any UI sugar is opt-in), we could make it so the link is disabled-by-default/un-coloured/whatever if WD is the only available result. But I think that's something we should explore before making a hard ban policy, as removing it from policy will be a whole "thing" that will drag on forever. If we, say, mandate WD links must use some template for now, botting out later is easy if we do decide that we don't want it at all. Inductiveloadtalk/contribs 10:25, 4 March 2021 (UTC)
@Inductiveload: Ok, I think we're in agreement on everything except possibly the specific shade of lilac on the storage facility for these two-wheeled pedal-powered conveyances. --Xover (talk) 11:47, 4 March 2021 (UTC)
We could have some CSS functionality hooked up to a gadget that allows those desperate to have WD links display, and standard text for those who don't and that would be the default. — billinghurst sDrewth 12:46, 4 March 2021 (UTC)
Yeah, that sounds like a good first-cut implementation and then we can get fancy later (anybody know if the enwp preview cards are a reusable feature or enwp specific?). BTW, @Samwilson: you've previously dug around in the vicinity of this issue. Thoughts would be very welcome. --Xover (talk) 14:04, 4 March 2021 (UTC)
{{wdl}} already exists (thansk SamWilson!), which does the WS/WP/Commons/WD fallback (though it uses Reasonator rather than WD diretly, which is a nice touch). I added some TemplateStyles CSS to hide (un-visited) non-WS-links. It's got a class module-wikidata-link on it already, so hitting it with custom CSS and JS is easy too. Inductiveloadtalk/contribs 14:08, 4 March 2021 (UTC)
@Beeswaxcandle: You're my new favourite person in the whole wide world! I've a few minor nitpicks but if this is adopted as is I'll be ecstatically happy. I'll try to read it in depth (including Inductiveload's comments) and comment in detail as soon as I have some moments in peace. --Xover (talk) 09:51, 4 March 2021 (UTC)

@Beeswaxcandle, @Inductiveload, @Billinghurst, @Prosody, @Samwilson: Ok, in between IRLs insistent nagging I finally found the time to sit down properly with this. I have made a modified version (diff) that was originally intended to just restructure headings and such, but which kinda got away from me. In addition to the restructuring the modified version also contains running changes of my own devise, and my attempts to incorporate all the comments so far. Major changes include (hope I remember them all):

  • Removed the paragraph on Wikilivres/Bibliowiki. It's been dead, kinda back, dead permanently, resurrected as a zombie, actively deprecated here in a discussion, and then kinda sorta maybe someone still wants to keep it on life support even though its heart has topped beating. Which is to say I don't think we should regulate that specifically in this policy. Whenever we want to actually address the issue once and for all (which is a big discussion on its own), we can regulate that in a separate policy page, or, at worst, have a vote on including a separate section on it here. But for right now I want to kick that can down the road a ways.
  • Added linking to Wikidata through {{wdl}}.
  • Removed prohibition on links to Commons, with a mind to linking to a category there. The idea was maybe valid for some extremely rare and narrow circumstances. I regret the change now and we should reverse that before this proposal goes before the community. I'm clearly an idiot. Or maybe some auto-links through {{wdl}} are ok. It's late, don't ask me such difficult questions.
  • Dropped completely the "links are annotations" concept. Now it only talks about links and what's permitted, but then says that some links that aren't permitted here may be permitted in annotations under the annotation policy. I think this makes the text a million times clearer and should stave off the confusion on display at WS:S currently. To me this is a main crux and I will argue the point until you all throw your hands up in frustration. You've been warned! :)
  • Changed all the "guidelines" to just plain parts of the policy. Non-normative guidelines go on a Help: page and we treat all this stuff as policy anyway. I think this provides far better clarity.
  • Removed inline references to translations and added a separate section that says everything that applies to mainspace applies equally to translations. It makes the main part of the text easier to read.
  • Added a separate section on born-digital texts with my best approximation of the special rules for such works. Parts of it may be controversial (I don't know: we haven't discussed these a lot).
  • Added some non-normative footnotes and a Notes section, with some text to explain the footnotes' status as "non-normative, but you can't just ignore them."
  • Lots of smaller changes that I forget, but which may or may not be for the better, depending on your perspective.

I aspire not to perfection, but I thought the result looked pretty good; and I imagined it neatly addressed all the existing comments. That being said I reverted the changes because I didn't want to be too pushy. :) But take a look and see if we can use those changes. I want to have a solid draft that can hopefully pass a community vote without significant changes, so I explicitly don't want to be too hasty in developing this draft, but it would also be nice to get it before the community before other discussions that this draft would solve devolve too far into the weeds. --Xover (talk) 20:55, 7 March 2021 (UTC)

@Inductiveload, @Billinghurst, @Prosody, @Samwilson: Have done a further rewrite, including a lot of Xover's suggested recension. I've left Inductiveload's inline comments and Billinghurst's comments in at present, so that we can check that we have covered all the concerns from those. I've also left a couple of paragraphs that I want to strike, but Xover wanted to keep with some rewriting. Could we aim for doing the RFC/promulgation by the end of the weekend? Once we've got this one moving, I want to move onto a couple of the others where we're currently lacking in our codification of our conventions (e.g. Author Names). I freely confess that I'm avoiding Annotations. Beeswaxcandle (talk) 08:54, 10 March 2021 (UTC)


So all the cruftiest {{header}} template logic is now crufty module logic. I'll try to tidy it up more now it's all there, but one step closer to those sunlit uplands.

Btw, lilac is a terrible choice, and the correct color is clearly lavender.   Inductiveloadtalk/contribs 20:13, 4 March 2021 (UTC)

@Inductiveload: Hallelujah! Cruft may be cruft, but debuggable and decruftable cruft is miles better than the status quo ante. --Xover (talk) 04:39, 5 March 2021 (UTC)

Specially labelled separate copies of worksEdit

You wrote to only use wikilinks in "specially labelled separate copies of works", can you direct me to a properly formatted example, it would be much easier to see what you are referring to, rather than you describing what it should look like. Thanks! --RAN (talk) 18:17, 6 March 2021 (UTC)

@RAN: Sorry, no. I'm not actually aware that we have any good representative annotations here. The best I can offer is a link to Category:Wikisource annotations (which doesn't actually answer your question). Personally I think we should just forbid them altogether for now because I don't think they work as they are currently conceived. The concept is used to allow for things like parallels texts, modern spelling editions (think Shakespeare and Chaucer), and similar that could be really great; but we've never had proper support to make creating such texts palatable for contributors. In any case, wikilinks are kind of on the minor end of the scale, and the annotations policy can't quite make up its mind whether it's about these or completely original editions. Treating links to Wikipedia as on par with something like a completely new translation of Aristotle with original critical commentary and explanatory footnotes is… well, not a particularly good fit at least. I think we're going to have to revisit that policy eventually to make it clearer and fit better with practice, and to adapt it better to fit what people want to do (on the one hand) and what our tooling actually makes practical (on the other). Not that it'll be much comfort, but I think your recent frustrations in this area has at the very least brought these problems to the forefront again, and as such may eventually help engender change. Not necessarily the change you would like to see (it might be, but I make no predictions of any outcome), but at least to make the policy clearer and more consistent, both internally and with other policies. --Xover (talk) 18:45, 6 March 2021 (UTC)


Despite what Nickw25 believes, the site administrators on PGDP want nothing to do with Wikisource. Even before Inductiveload downloaded the files, they told me and my friend to pound frozen sand. She was a community member. We merely asked to see one archived project and the response was very negative. They want to be left alone. However, they have no assertion of copyright or any other form of license on their texts. I have other thoughts on them that I prefer to keep private. Suffice it to say, that we should not contact them again. Languageseeker (talk) 16:06, 8 March 2021 (UTC)

@Languageseeker: As mentioned, it looks like there are some pretty significant philosophical differences standing in the way just now. But hopefully a trickle of communication can, eventually, lead to better mutual understanding and some common ground on which trust can be built. --Xover (talk) 17:02, 8 March 2021 (UTC)
{re|Xover}} I actually think that it's the fact that we're so close that scares them the most. Behind everything, I think they're afraid that we might lure away volunteers. The were extremely clear that they only produce for PG and will not share the files with anyone. This upset some forum members. When asked about the licensing of the files produced by the volunteers, they did not provide an answer. Instead, they asked to be left completely alone and I think that we should honor that wish until the leadership changes. Languageseeker (talk) 01:34, 9 March 2021 (UTC)

Voting procedureEdit

Hello. I am thinking about suggesting a rule codifying voting procedures when some new policy is suggested. I thought of making it similar to the procedure in English Wiktionary which seems very clear and effective to me. However, before I do so, I would really like to hear your opinion as you have a lot of experience with vote closing. What do you think about it? --Jan Kameníček (talk) 18:36, 14 March 2021 (UTC)

@Jan.Kamenicek: I'm not sure I'm prepared to make any positive recommendations (i.e. "Do it like this...") without thinking it over a bit. I'm happy to help out (I think codifying such things is inherently good), but I have to warn you that based on our discussion at the RFC I suspect we have fundamental disagreements on some small but crucial points.
The Wiktionary policy seems a good one in general outline, but it also seems a little rigid and mechanistic (for example, it prescribes a simple numeric formula for deciding the outcome; compare w:WP:CON). I would be surprised if the community here favoured such a hyper-structured approach. I think guidance that suggests that rough outline as a "best practice" wouldn't be a bad thing, and I think we could beneficially adopt several bits of it to codify our decision-making. But I don't think adopting it as is would be a good idea.
Personally, the most important bits are that we have a policy that describes how decisions are made; the minimum and maximum timeframes for decision processes; and who makes the final call, on what basis, and in what manner. Having done a lot of closing discussions I often wish I had clearer policy to lean on, and I constantly worry whether I'm overstepping. I've done a lot of work on enWP, and while they definitely have their own problems (that we should bend over backwards to avoid copying), the comprehensiveness of their core policies is enviable. I think we could beneficially adopt a lot of our non-Wikisource-specific policy from there, and model the rest on theirs even when it doesn't fit to be adopted directly (I would particularly like to see a clear delineation of behavioural expectations, because right now I think we accept contributors gunning people down in the middle of 5th Avenue with no corrective reaction).
In any case, I think our current policy set is so loose that I'm happy with all efforts to tighten it up. One can swing too far in the opposite direction, of course, but codifying how decisions are made seems a fairly fundamental one to me. --Xover (talk) 19:11, 14 March 2021 (UTC)
Thanks for your answer, I will think everything over. --Jan Kameníček (talk) 19:20, 14 March 2021 (UTC)

Women of the WestEdit

Hi @Xover:, I noticed that BD2412 has published a number of pages in the Women of the West series that appear to be unproofread OCR. Peteforsyth has a match-and-split queued with well formatted text for these pages. I know that a match-and-split will fail if there is any existing text. Is there anyway to delete the unproofread OCR so that Peteforsyth's work does not get lost? Languageseeker (talk) 06:00, 16 March 2021 (UTC)

I appreciate this note, but I'm not too worried about it. I took a calculated risk, queueing up a M&S for a proofread-of-the-month listed on the front page, and if somebody else got to it before Phe-bot does, it's OK with's only about 20 pages worth of material at most. I do think it would be good do find a way to bolster the bot though, and increase its ability to reliably process pages on behalf of more than one user at a time...wish I knew what it would take to do that. Thanks for noticing this Languageseeker (talkcontribs). -Pete (talk) 06:29, 16 March 2021 (UTC)

@Languageseeker, @Peteforsyth, @BD2412: I'm not really sure what needs doing here, since a cursory look suggests both the current Page: pages and the text at Women of the West/Washington are just minimally corrected OCR. But I'm sure that between the three of you you can figure out the best course of action. :) Feel free to continue the conversation here if you like, and just let me know if there's anything I can do to help. --Xover (talk) 07:04, 16 March 2021 (UTC)

Pages seem to be getting proofread almost as fast as they are being made. I don't see a problem. BD2412 T 19:36, 16 March 2021 (UTC)

Pericles (Yale)Edit

User:Languageseeker has extracted File:The Yale Shakespeare - Pericles Prince of Tyre.pdf from Google. Could you please convert the file to a DjVu, generate a new text layer, and upload the completed file to Commons as File:Pericles (1925) Yale.djvu? --EncycloPetey (talk) 23:16, 16 March 2021 (UTC)

@EncycloPetey: I'm having trouble extracting scan images of anything approaching usable quality from this file (which means both manual proofreading and OCR will be painful). I'll keep trying but no guarantees. @Inductiveload: Maybe your toolchain will do better on this file? --Xover (talk) 12:02, 17 March 2021 (UTC)
@EncycloPetey: there you go. Can I leave tarting up the metadata to you?
@Xover: something was very wrong with that PDF, but running it though ghostscript first helped (gs -o generated.pdf -sDEVICE=pdfwrite -dPDFSETTINGS=/prepress input.pdf), then ImageMagick to covert to PNG rather than pdfimages. Inductiveloadtalk/contribs 18:45, 17 March 2021 (UTC)
@Inductiveload: Thanks. And that's a very neat trick I'll have to remember for next time! --Xover (talk) 20:26, 17 March 2021 (UTC)


Is this of any use in relation to:-

Page:A_Treatise_on_Electricity_and_Magnetism_-_Volume_1.djvu/22 ?

'model' CDiP. is essentially what you set up.

BTW I wrote that table class stylesheet to try and make TOCstyle type formatting saner to implement on TOC with standardised layouts. ShakespeareFan00 (talk) 09:17, 20 March 2021 (UTC)

@ShakespeareFan00: Possibly. But after banging my head against the problem for a bit I've landed on the conclusion that none of the toc-specific solutions (most glaringly {{dtpl}} and friends, but it applies to greater and lesser degrees to all of them) merit their existence, and most should be killed with fire. I've not looked at {{tc}} in detail, so that's not a comment aimed at that effort, but I'm sceptical this is a problem amenable to technological solutions at this level. Between the vagaries of MediaWiki's table syntax, HTML's table model, and the quirkiness of the works we reproduce, I am now militantly sticking to direct control with a table and just {{ts}} for convenience. The odd thing is that our auxiliary tables of contents could conceivably benefit from some fancy technical solution and pretty formatting, but there we're rigidly sticking to the austerity of {{AuxTOC}} as if were mandated by the great librarian in the sky. --Xover (talk) 17:49, 20 March 2021 (UTC)
Well with
{{table class import|Template:Table_class/toc.css}}
|I|Item 1||1
|II|Item 2||3
|III|Item 3||5

You write the ToC like any normal table, and you shouldn't need to call TS as much. ShakespeareFan00 (talk) 17:58, 20 March 2021 (UTC)

Index:Etsu Inagaki Sugimoto - A Daughter of The Samurai (1925).pdfEdit

The other one is complete, because I did the pagelist for it. ShakespeareFan00 (talk) 17:28, 20 March 2021 (UTC)

@ShakespeareFan00: Thanks. Old one speedied. --Xover (talk) 17:38, 20 March 2021 (UTC)

Christmas is cancelled! FffffuuuuuEdit


This has been your regular outbreak of sadness and frustration. Thank you for your attention. Inductiveloadtalk/contribs 20:43, 24 March 2021 (UTC)

Class namesEdit

So for the "core" classes, we have two options:

  • Poem-specific, like ws-poem-italic
    • Pro: this will therefore not collide with an any other /.*italic/ if someone defines that in some other stylesheet
    • Con: duplication of common CSS
  • Defer to a site-wide "core" set of common styles: ws-italic, ws-bold, ws-smaller, ... placed somewhere like Template:Common styles.css and pulled in by {{ppoem}}. (the ws- is deliberate to avoid colliding with skin or core MW classes, and to make it easier to search for, I have also used __ as a prefix)
    • Pro: avoids duplication in style content
    • Pro: a standardised set of classes that don't only apply to ppoem might reduce cognitive loads
    • Con: this style sheet will probably undergo {{ts}}ification and end up huge, unless someone stands next to 24/7 it with a baseball bat wrapped in barbed wire
    • Con: the classes will end up shotgunned into thousands of pages - will that make it overly hard to maintain? If the rules are simple enough (like font-weight: bold; how much maintenance might be needed? Inductiveloadtalk/contribs 09:38, 26 March 2021 (UTC)
I have thoughts. They're not very coherent, but there's lots of them. You may regret asking… :)
I don't want to encourage end-user use of any CSS class directly (in fact I want to very very emphatically prevent it). <div class="prose"> can't be tracked, can't be sensibly adjusted, can't… Ugh! If we don't let end users use classes directly, where to store the associated style rules (or even whether they are CSS at all!) becomes a technical consideration. In principle, specifying |class=foo could make the template spit out an XML processing instruction, that an extension transformed into an event sent to a Gadget, that triggered an embedded Flash player that displayed the… etc.
And provided end users don't get their grubby little hands on raw CSS classes… I think we can postpone and noodle a bit on optimum strategies. I think there are some style rules that could beneficially be loaded via Common.css, because their ubiquity outweighs everyone having to load it. I think that set is probably smaller than what I think of as "core styles", because I see that defined in terms of "what tools do most contributors need" rather than "how large a proportion of pages is it used on".
For a lot of the obvious candidates I don't really consider duplication a critical issue. Anything where the class is simply a proxy for a single style property (bold, italic, etc.) is not going to change, and the set is probably not going to expand very often, so keeping them in sync is not going to be an issue in practice. Users are still going to end up with loading those styles multiple times, but this is going to be a tiny fraction of the overall overhead of what gets pulled on every single page load (the recent optimisations have been to the manifest and what gets pulled in the first HTTP exchange; the total pulled is still humongous). It is also something that is easy to optimise later.
Which is why I've been thinking that we can have a middling set of pre-defined classes embedded in ppoem. The end user interface is a simple class name, whose semantics are controlled by ppoem (context may possibly affect exactly how we define these classes), but the underlying CSS makes it unique. That means if we do define global styles ppoem will still use its local styles, until we choose to lean on the globals, at which point it's simple to just drop the selector prefix.
I'm not necessarily certain the above will hold together if picked at, and even so I'm not married to the approach. But it's my thinking so far.
PS. I've taken it for granted that if my meddling with this class stuff in ppoem is inconvenient you'll tell me to bugger off. Do please do that if it gets in the way in any way at all! --Xover (talk) 10:17, 26 March 2021 (UTC)


FYI, my plan (which I haven't thought through to a state I can implement it just yet, doing it in vivo is going to slightly tricky), is to move the margins to the outer span and multiply them by 3 (or something else if parameter 2 is set). This should make things a bit less wierd in terms of sizes and shouldn't need Lua hacks going forward.

Re the named positional parameters, this was a side effect of mwparserfromhell removing parameter 2 from an image dropcap. Inductiveloadtalk/contribs 21:18, 26 March 2021 (UTC)

@Inductiveload: Since both font size and the margins are given in raw CSS units you'll need to parse them before you can math on them (since CSS calc() requires the denominator to be a unitless number). I'm also seeing weird abuses like this and this. Going by the tracking cats I'm also beginning to question whether we should even support tweaking the margins:
A significant portion of -right, -bottom, and -left are either not really needed (i.e. this should be {{img float}}; and there are a lot of these cases) or are abusing the param for something other than dropcaps (cf. above). margin-top seems to be used a lot for alignment, and may be possible to obsolete (or it may be a legitimate knob to let users to tweak, but possibly not in raw CSS units). Font family hasn't existed in the code for over a decade and it had all of two uses (that I've removed; the tracking cat is still there just in case the category update job hasn't finished yet). z-index has one use, which should be replaced by {{img float}}, and then dropped. I have no idea what text-indent would be used for on a dropcap, and neither apparently has anyone else. Etc.
In any case, it's entirely possible we could clean out the bad uses of margin-* and be left with a manageable number of use cases to handle, and no other params. --Xover (talk) 22:37, 26 March 2021 (UTC)
@Xover: for the vast majority, font-size is either default (3em) or 2em, (or 200%). And that'll be easy enough as a one-off in Python (or Perl, whatever, I don't judge). I ran into the fake sidenotes too, but I have not had a chance to think about how best to handle them. I agree that clearing out the edge cases and abuses first would probably make whatever comes next more tractable. Since there are only a few hundred cases of margins (assuming the cats aren't lying), it could be not too miserable. Inductiveloadtalk/contribs 22:44, 26 March 2021 (UTC)
Also I made {{USStatSeal}} one day but clearly never got around to actually putting it in. Inductiveloadtalk/contribs 23:01, 26 March 2021 (UTC)
@Inductiveload: First cut: {{inset}}. Thoughts welcome. --Xover (talk) 22:03, 27 March 2021 (UTC)
Looks sensible at first glance. Some interesting responses here too: But that's for a special case where it's one line down from the start (but you want to copy-paste in the right order). Literally just set it up at diff. Inductiveloadtalk/contribs 22:08, 27 March 2021 (UTC)
@Inductiveload: Hmm. I'm not sure I care about that case. Such notes, in my experience, are placed not precisely but in "rough correspondence" with the text they relate to. We are never going to be able to place or order these with precision in general, so your test case there just stands out because the imprecision is visually obvious when close to the beginning of the text. If shape-outside gives us better control in general then we should use that in preference to margins, but otherwise I think trying to solve these special cases is going to be a bad tradeoff with complication. --Xover (talk) 08:20, 28 March 2021 (UTC)
I mean, I will not be heartbroken if we continue as we are (plunk the note in the middle of the text so it happens to pop up a few lines down, depending on container width). But it seems to me that this particular kind of note is actually more of a "paragraph heading" than a side note and the fact that it has a single line above it is no accident (unlike {{USStatSeal}}, which varies in placement). So, I think ideally, it should come at the start of the paragraph, if possible.
Re shape-outline: that works in concert with margins - it basically allows you to "unreserve" some of the margin's blank space and allow the surrounding text into it. Inductiveloadtalk/contribs 12:36, 28 March 2021 (UTC)

Query: will the proposed change work just as well for poetry and drama formats as for prose? There are currently drop initial issues where the drop initial extends into the next person's line of dialogue creating format headaches that require a kludge to solve. There are also situations where the drop initial is not the first character on the line, but has a few letters before it. --EncycloPetey (talk) 22:17, 27 March 2021 (UTC)

@EncycloPetey: Links to pages demonstrating such issues welcome! The change Inductiveload alludes to above (moving the margins to the outer span) is likely, if it works, to cut down a bit on general weird behaviour with {{di}}. But dropcaps and other formatting that requires CSS floats is always going to be fraught with unexpected behaviour. --Xover (talk) 08:12, 28 March 2021 (UTC)
I'll see what I can find.
  • @EncycloPetey: Thanks, those are excellent test cases. Sadly I don't think moving the margins in the template will do much to make those cases easier to handle. We'll be stuck in a world of workarounds until the CSS standards for real dropcaps are finished and browsers support them. --Xover (talk) 20:42, 28 March 2021 (UTC)
    As long as the changes don't add additional problems, I can still kludge around the problems. --EncycloPetey (talk) 20:44, 28 March 2021 (UTC)
  • Hey. I notice you are changing some of these templates, but only at one of the pages of a work with many other drop initials; are you planning to do the rest. I would have done whatever it took to get it rendering cleanly, so updates are welcome, but I was never fussed about matching the font size and other concerns (just that it appears as drop initial). CYGNIS INSIGNIS 02:32, 28 March 2021 (UTC)
    @Cygnis insignis: That depends on the page (and work). The ones I did yesterday were ones using a particular parameter (margin-bottom) in a way that was either not needed or which breaks stuff (negative margins in particular). Did my changes break something? --Xover (talk) 08:12, 28 March 2021 (UTC)
    Not broken, just different to the other pages, eg More English Fairy Tales Use a larger dropcap to match the scan rather than a margin to fake it. Note that the work is "More" tales, one of a set that I attempted to make consistent. CYGNIS INSIGNIS 09:05, 28 March 2021 (UTC)
    @Cygnis insignis: Thanks for the headsup. I'll take a look. --Xover (talk) 09:59, 28 March 2021 (UTC)
    @Cygnis insignis: Ok, I've gone through the other uses of dropcaps in the two works and made them consistent. Thanks again for the headsup! --Xover (talk) 21:26, 28 March 2021 (UTC)

Top marginsEdit

@Inductiveload: Check my reasoning here?

In going through the uses of di with top margin, it looks like a lot of them are to align the dropcap (usually an image) with the top of the associated line of text. Since this is usually a lower-case letter, for obvious reasons, this is the x-height of the font. The dropcap fails to align by default because it is pressed up against the edge of the containing box, but the text line is significantly higher than the x-height. So to obviate the need for setting this, we would need to set a default top margin equal to the distance from the edge of the container's content area to the shoulder of the lower-case letters in the current font and size.

By my reckoning that should be the line height (1.6em), less the font size (0.875em), divided by two (since line height is distributed evenly above the caps line and below the base line). In CSS terms, that should be margin-top: calc((1.6em - 0.875em) / 2);. And because di always sets it's own font size on the inner span, this margin has to be set on the outermost of di's many (many) spans.

This leaves the difference between the font size and the x-height to account for. Google suggests the typical ratio is about .5, so maybe something like margin-top: calc((1.6em - (0.875em / 2)) / 2);? Well, or for readability, margin-top: calc((1.6em - (0.875em * 0.5)) * 0.5);. At the likely range of font sizes, the difference between .2 and .8 (say) is minor, so that it is an approximation shouldn't be a big deal.

Hmm. Or maybe we could use root ems to avoid interference from set font sizes, and attach it to the innermost span (until all of them are moved)? My head hurts. --Xover (talk) 17:29, 28 March 2021 (UTC)

I think it's more common for a DI to align with the top of a capital, not the x-height (because a DI is very often followed by at least one capital letter, and most often a whole capital rest-of-word). This seems to work pretty well for the text DIs (at least up to ~4em, after which it starts to get obviously out of line on the low side), whereas image DIs are a little on the high side for some reason (hence those 0.1em, actually 0.3em according to the surrounding em size).
Images will always be vulnerable to alignments because it depends how tightly they are cropped. Inductiveloadtalk/contribs 12:24, 29 March 2021 (UTC)
@Inductiveload: Images and text behave differently because images by default have no margin or padding, but text has a pseudo-margin in the form of the line-height and variable rendered glyph physical size within the font size. But good point about the (small-)capitals—I must have been led astray by a non-representative subset of test cases—so perhaps it's the cap height we need to aim for. And images and text dropcaps clearly need to be treated differently in this regard since they behave differently. Maybe it would be worth having a separate "drop cap image" template? --Xover (talk) 12:35, 29 March 2021 (UTC)
Part of the reason I have moved all (but one) instance of the image DIs to using a parameter is so we are able do this in one template by detecting the use of image (as well as being able to track and deal with images more sanely that having them dumped on the template in raw wikitext).
Furthermore, margins set on the images are likely more correct as px, not em, since that's what the image is sized as - it independent of the surrounding text size. This is in strict reversal to preferring em when there's text in the DI. Inductiveloadtalk/contribs 13:00, 29 March 2021 (UTC)
@Inductiveload: But for this we don't care about the size of the image; we're trying to offset its top edge by an amount that is determined by the font size and line height (i.e. a unit that is relative to the font size). What would normally be handled by simple vertical alignment, which doesn't work here because we've taken the image out of the normal flow. --Xover (talk) 13:11, 29 March 2021 (UTC)
True, as long as the image has negligible empty borders. Inductiveloadtalk/contribs 13:21, 29 March 2021 (UTC)
@Inductiveload: Well, yes, but there are always going to be situations where custom tweaking is needed and we can't automatically determine it. I'm talking about finding a default top margin that obviates the need for customization (the 3=0.1em that is being added reflexively) in the majority of cases. --Xover (talk) 13:38, 29 March 2021 (UTC)
@Inductiveload: Ok, judging by Template:Dropinitial/testcases#Currently_using_top_margin, by using the calculated top margin on the outer span we can hit alignment with upper-case text with almost perfect accuracy for image-based dropcaps. Images with white gutters, or with extensive flourishes where the letter is placed weirdly, will still need manual adjustment. Lower-case or smallcaps subsequent text will be off by calc(cap-height - x-height) pixels, but could conceivably be simplified with a |lc=y param that applies the modified formula and thus avoid semi-random raw CSS length values in a positional parameter.
For text dropcaps the situation isn't quite as rosy. Since the offset here is an effect of the line-height to rendered glyph size ratio, and there's no way to get either value without weird JS hacks, we cannot actually calculate this accurately. Caveat that there's something happening there that I'm not quite understanding (have browsers implemented molten leading while I wasn't looking?), so there may be a way to do it that I just haven't found yet. But we can get pretty close for a constrained (typical) range of font sizes by applying a constant fudge factor (1.4). By dividing the font size of the inner span with the fudge factor you get something approximating line-height == rendered glyph size for most common font sizes for the dropcap. Combined with the same dynamic margin-top as for images we get "close enough" alignment with subsequent text for non-edge cases.
In other words, this may actually be worth pursuing; definitely for images, and probably for non-image dropcaps too (though they need more testing).
PS. feel free to nuke my changes to the sandbox etc. there if you want to dig into dropinitial. I'm just experimenting and checking feasibility so it's decidedly lower priority stuff. --Xover (talk) 08:08, 30 March 2021 (UTC)

Kick of MS botEdit

Do I remember correctly that you can kick Phebot? I think I may have killed it by accidentally sending it a request with a missing parameter rather than my local server due to stale JS :-/. Which might explain why it occasionally falls over if it can be KO'd with bad input. Inductiveloadtalk/contribs 17:05, 29 March 2021 (UTC)

@Inductiveload: Kicked. There was a trace from a raiseed ValueError in the logs, so somewhere down in the stack it clearly detects the error, it just doesn't recover (apparently). The architecture is complicated and I'm far from fluent in Python so anything bigger is out of reach, but, yes, I have shell access to phetools and can perform minor surgeries. --Xover (talk) 17:48, 29 March 2021 (UTC)

A present as a reward for your Phab brain dumpsEdit

function installOcrAutoClicker() {

  $( '#wpTextbox1' ).on( 'wikiEditor-toolbar-doneInitialSections', function () {

    var target = 'wsOcr1';

    var onMutation = function ( mutations ) {

      for ( var i = 0; i < mutations.length; i++ ) {
        var newNode = mutations[i].addedNodes[0];

        if ( newNode.attributes.rel.nodeValue === target ) {
          console.log("OCR button loaded: Imma click it, lol");
          $( newNode ).click();

    var observer = new MutationObserver( onMutation );

    observer.observe( $( '#wikiEditor-ui-toolbar .group-insert' )[ 0 ], {
      subtree: false,
      childList: true,

  } );

// check wgTitle/namespace as needed
$( installOcrAutoClicker );

Inductiveloadtalk/contribs 12:51, 1 April 2021 (UTC)

@Inductiveload: That's positively perverse. I love it! :) --Xover (talk) 13:16, 1 April 2021 (UTC)

Can I get an edit summary removed?Edit

I typoed.

ShakespeareFan00 (talk) 19:36, 1 April 2021 (UTC)

@ShakespeareFan00: I've hidden the edit summary from general view for your peace of mind, but all admins can still access it if they want to. I also think you're worrying way too much here: it was an innocent typo that nobody would take offence at (or even notice). --Xover (talk) 19:42, 1 April 2021 (UTC)

Index pagelists...Edit

As you can tell I am looking over some Index pages with a view to semi-standardizing the numbering on some of them. Can you review the ones I've done and comment as to the feasibility of continuing with that approach?.

As I cleared a good proportion of the relevant category a few years ago, a lot of the contentious "page-numbering" issues will be down to my efforts.

I am having to work fairly slowly, because in "standardizing" the numbering I am also trying to check for cross-referencing to specifc page number tags on transcluded pages. ShakespeareFan00 (talk) 19:47, 1 April 2021 (UTC)

@ShakespeareFan00: I looked at the latest 5-6 in your contribs and they looked fine. Not sure where the "F" thing came from, but that was pretty much the only issue. Oh, and please don't refer to other contributors in the edit summary in that way: you can refer to a "discussion elsewhere", but you generally don't want to personalise issues (I can expand on the reasoning for this if you like).
In general, if a page is part of the numbering sequence of the book it is never going to be wrong to label it with just that number. It is things like plates or protective pages that are outside the numbering sequence that need special labels. But there are lots of other contributors besides you that add things like "Title" etc. (I do it myself quite often) for various reasons (and we all irritate those who do not like that approach; I think you just became singled out on that score since you did so many Indexes in bulk).
That being said, I'm not sure going back over these indexes is worth the effort. If it lets you do cross-referencing or other quality control while doing it, sure; but changing the pagelist just to apply a different style of labelling is wasted effort that would better be spent elsewhere. If the goal is to avoid conflict and controversy I would rather recommend changing your approach going forward. For all you know, changing these existing indexes could annoy someone as much as the current style annoys others. Don't fret about it too much, is what I'm saying. :) --Xover (talk) 20:10, 1 April 2021 (UTC)
The other reason for slowly reviewing these these is that i,ii,iii etc is more logicial numbering if you want to cross reference into say a specifc page of the front matter, which would otherwise potentially have different pages with the same numbering. I've adopoted this approach on more recent efforts. Can you consider start an RFC on the page numbering issue to resolve :
  • How otherwise un-numbered front (or rear matter) is to be numbered in pagelists in the absence of a logical sequence presented in the work itself?
  • If "Title" ,"Half-Title" and "Inter-title" (i.e section title) pages should be labelled directly, if they would already be part of a numbered sequence?
Thanks.ShakespeareFan00 (talk) 08:06, 2 April 2021 (UTC)
For example Index:Chaucer - Complete works (Skeat Volume 6).djvu looks cleaner than Index:Chaucer - Complete works (Skeat Volume 7).djvu
If the title page needed a specfic link, an explict {{Anchor}} could be added on the page itself? ShakespeareFan00 (talk) 08:24, 2 April 2021 (UTC)
@ShakespeareFan00: I think it's stretching it to say that Vol. 6 looks cleaner than Vol. 7 to any measurable degree. It's not the labelling of the title page that's a problem, it's when you start pulling this toward the extreme other end of the scale. For example if the front matter does have a page numbering but you still add "Half-title", "Frontispiece", "Dedication", "Copyright", "Contents", "Colophon", "Illustrations", "Introduction", "Dedicatory poem", and so on. If the only thing you label outside the existing page sequence is the title page I don't really think anyone will complain.
But irrespective of this, you really shouldn't rely on these page labels for linking in the general case. They can and do change, for example when someone rejigs the Index:. Any link from another work etc. that should be stable should link to a target provided by {{anchor}} or {{anchor+}}. It's a bit different for ordinary (non-front matter) pages where the page numbers by nature are more stable, but even there I would generally recommend using an explicit anchor as a target.
I think an RFC is the wrong end to start. We could use clearer guidance on this, but that's an issue for discussion first. I also don't think this is a particularly pressing issue. The recent conflict over your approach is an anomaly, and most of the time contributors use their own good judgement and it ends up just fine. Unless I'm missing a lot of simmering frustration on this issue, I don't think this is a significant problem. --Xover (talk) 08:48, 2 April 2021 (UTC)
@Xover: One final clarification - Index:History_of_the_Anti_corn_law_league_-_Volume_2.pdf Here the issue is that "Title" would otherwise be (i) in the run of pages. I don't consider this significant enough to worry about, but wanted a definite ruling, so I didn't have to change things again when someone else complains. I am happy to change these en-masse if felt appropriate. ShakespeareFan00 (talk) 08:48, 3 April 2021 (UTC)
@ShakespeareFan00: I don't think mass-changing these is needed, nor advisable. You won't get a "definitive ruling" on this, given the current state of our guidance on this stuff. But if, for new uploads or works needing pagelist cleanup for other reasons, you use the in-book numbering sequence (in this case, "i") you definitely won't be doing anything wrong. I'm pretty sure not even those strongly opposed to named pages will really object to labelling the title page as "Title", and that's definitely within scope of each contributor's preference, but if you're worried about pushback it may be marginally safer to go for "i". That being said, I have, and will continue to, label the title page as "Title" absent an actual RFC or similar. Depending on my mood, the phase of the moon, and the quirks of the work in question, I may also use a named label for other pages and not be overly concerned about it. I have over time drifted more towards just using the existing number scheme, but I really don't feel this is something to be exceedingly rigid about. --Xover (talk) 17:22, 3 April 2021 (UTC)

Bye for a whileEdit

When I get an 'angry' response for performing what I thought was a good faith action, it's time to stop contributing for a while.

So can you semi protect my User page and User talk page ?

I will reconsider if I continue contributing when I am not as upset.

ShakespeareFan00 (talk) 11:48, 5 April 2021 (UTC)

@ShakespeareFan00:   Done And if you are feeling upset then taking a break is probably a good idea, for your own sake.
But I think you're overreacting to what may have been a somewhat brusque response, but is otherwise not particularly unexpected (I don't know what brought it on, but I can guess). While we are a collaborative project, that doesn't mean we have to have multiple people on one work most of the time. We have near infinite tasks that need doing, so there's plenty for everyone to do without stepping on each others' toes. And when works require collaboration it is usually a good idea to discuss and divide the tasks beforehand. It is also a fact that, regardless of whether you think it merited or not, you know that the contributor in question is frustrated with you. In those circumstances it would be wise to try to avoid wading in on a work where they are already working. As I said, there's tasks enough for everyone. --Xover (talk) 12:02, 5 April 2021 (UTC)

redact templatesEdit

Would it be possible for us to have just one redaction template? Multiples is just confusing and seems superfluous for the one act. — billinghurst sDrewth 02:04, 6 April 2021 (UTC) (noticed through unconnected pages)

@Billinghurst: Yeah, that's the plan. They were just too complicated to modify in place, so the plan is to make {{redact3}} in a (hopefully) technically sound way, migrate all uses of {{redact}} and {{redact2}} to that, rename / redirect and then end up with just the one template. Or, if I run into insurmountable problems, we'll nuke {{redact3}}: having two of them is bad enough, so I definitely don't want to add a third. --Xover (talk) 06:12, 6 April 2021 (UTC)

Moved index has left orphaned pages behindEdit

Hi, when you moved Index:The female Quixote, or, The adventures of Arabella (Second Edition V2).pdf to Index:Arabella (Second Edition - Volume 2).pdf you left all the pages in the Page: namespace unlinked. What are your plans for those ca. 270 pages? Beeswaxcandle (talk) 07:51, 9 April 2021 (UTC)

@Beeswaxcandle: Urp. That was sloppy of me. I'll fix it as soon as I can. Thanks for the headsup! --Xover (talk) 10:56, 9 April 2021 (UTC)
@Beeswaxcandle: Fixed. Thanks again. --Xover (talk) 15:45, 9 April 2021 (UTC)

Wrapping in poemsEdit

Maybe I've too worried about the wrapping in {{ppoem}}: the same actually happens in <poem>, for the same reason:

A WIND harp in a garden all year round,
Was fingered by the winds, and each one found
Within its silver strings an answering sound.

Perhaps the same solution (a manual width setting) might be the most expedient thing to do here, and if we can think of an automagical way to do this later, it'll be easy to seek and destroy manual widths. The max-width:100% on the outer ws-poem div means it will still autoshrink on smaller pages:

It's still not quite ideal, because in the case of an image dropinitial, the DI size is in PX and the rest of the line is in em. But might get us most of the way? Inductiveloadtalk/contribs 13:48, 12 April 2021 (UTC)

@Inductiveload: I wouldn't say "worried too much": it's a tradeoff between different ways it can subtly break, so calling it for one over the other means weighing a lot of different factors. The forced right padding throws centering off in a non-obvious way, that is hard to notice and hard to account for. For me that fails because it is really hard for most users to both notice and to understand even with an explanation. Having di break wrapping is a fairly direct cause—effect relationship (even if the underlying connection is mysterious for most) and the breakage is immediately adjacent to what causes it. So for me the balance tips to the opposite tradeoff; but it's a close enough thing that'd be hesitant to even argue too strongly for it.
But, yeah, the problem is definitely with di and not ppoem. I'm pretty much landed on this staying broken until we get real CSS drop caps, and that in the mean time we shouldn't accept too many tradeoffs trying to compensate for it. Which is, of course, another argument that we should just live with the wrapping issue in ppoem.
But if we do try to work around it with a fixed width, let's make sure it's a separate param like di-fix or whatever. There can be a million reasons people feel the need to specify a width (some good, most bad), so if it's just width it'll be a real pain to go back over and fixing them later. --Xover (talk) 18:13, 12 April 2021 (UTC)
So, say we had di-fix. How would it go? Allow users to specify the contents of a calc() expression so they can do 100px + 20em, where 100px is the image and 20em is the remainder of the line? That's the most "correct" statement of the maximum width, but I feel like that's adding too much complexity (since a non-image case is just some number of em). Maybe just settle for em only (perhaps enforced by adding "em" in the template) and on displays where 1em != 16px, it'll just have to wrap a bit early until we can defer to some sensible CSS once the committees stop faffing with emojis and focus on the important things like dropcaps and dot-leaders? Inductiveloadtalk/contribs 18:35, 12 April 2021 (UTC)
@Inductiveload: I think I'm for not over-complicating it for this case. At this point there are so many variables that even the fanciest algorithm won't get us anywhere near "just working" most of the time. When people are faffing about with extra widths to make things not wrap, the approach is trial and error until it looks ok. Most letter boxes aren't going to be 1em anyway so even without the indeterminate width it's mostly trial and error in practice. --Xover (talk) 18:55, 12 April 2021 (UTC)
OK, don't make any sudden movements, but I think I might actually have fixed it with just a margin-left:-4em; on the outer span of the drop initial, which means we don;t need the hack << syntax at all:
{{dropinitial|B|image=Examination and confession-b24926760-025.jpg|imgsize=80px}}EHOLD these acts and scan them well
behold their pervers way:
These left the lord, these did his truth
which shold have ben their stay.

{{dropinitial|B}}EHOLD these acts and scan them well
behold their pervers way:
These left the lord, these did his truth
which shold have ben their stay.
 EHOLD these acts and scan them well
behold their pervers way:
These left the lord, these did his truth
which shold have ben their stay.

BEHOLD these acts and scan them well
behold their pervers way:
These left the lord, these did his truth
which shold have ben their stay.

Cautious optimism.jp2 Inductiveloadtalk/contribs 02:58, 13 April 2021 (UTC)
@Inductiveload: That sounds entirely too good to be true, so I am going to refuse to believe it until I get a chance to test the hell out of it! :) --Xover (talk) 06:11, 14 April 2021 (UTC)
@Inductiveload: Wraps: 1, 2, 3, 4. And I'm trying to think of a sensible way to do the chorus on Page:War, the Liberator (1918).djvu/136. --Xover (talk) 17:05, 14 April 2021 (UTC)
So for the wrapping, it looks like the first line "wins" in the "how big is this box" stakes. A hack that does seems to work "OK" is adding a margin-right: Xem to the first line only, which bumps the box outwards (and still maintains overall centered-in-page-ness). Perhaps that's an acceptable di-fix escape hatch?
RE the chorus, how about a stanza class and some index page CSS and a stanza style that sets a margin on the lines, and italic on .italic_heading_chorus .ws-poem-line:first-child? Inductiveloadtalk/contribs 17:15, 14 April 2021 (UTC)
@Inductiveload:Wrap: that might be it. Maybe call it "extra-space" in that case, but…
Chorus: I mean I'm trying to think of a good general solution to that kind of thing, and whether it'd fit in with the facilities of ppoem. IndexCSS for a single song in the work seems way overengineered. --Xover (talk) 17:55, 14 April 2021 (UTC)
There's also nothing stopping you having, say, Index:Foo.djvu/italic_chorus.css (or Template:ppoem/styles/italic_first_line_chorus.css if you think it has wider scope for re-use, I guess). You will just have to do the templatestyles tag manually on the pages that need it. Inductiveloadtalk/contribs 18:05, 14 April 2021 (UTC)

Review Activity of BillinghurstEdit

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)

@Languageseeker: Take a hike. I am in conversation and don't take to this sort of tittle tattle approach. Fair dinkum. — billinghurst sDrewth 05:01, 18 April 2021 (UTC)
@Languageseeker: Reviewed. Now what exactly was it you wanted myself and Inductiveload to do about a disagreement between two long-term members of the community? --Xover (talk) 07:47, 18 April 2021 (UTC)

regex for complex cleanupEdit

I cannot get my brain around getting a couple of cleanup regexes for a page like Page:Encyclopædia Britannica, Ninth Edition, v. 5.djvu/440. To remove the excessive 9link when there is a mix of piped and unpiped template usage. Cannot do an "all but not" ([^\|]+?) or ([^}]+?) as they are so template intense you run into the next template. Can you think of a way through? Thanks. — billinghurst sDrewth 04:43, 18 April 2021 (UTC)

@Billinghurst: What's the end result you're after? Do you want to remove all 9link templates, or only those with a piped link? Or, I guess, some other subset? In any case, so long as none of the 9link invocations contain nested template calls inside their parameters we should be able to construct a regex that does the job. --Xover (talk) 07:07, 18 April 2021 (UTC)
kill both, grossly overlinked for things that are q.v. referenced, nor need links. Oh, I suppose I could two stage it; kill the bit before the pipe first, and then rm the template, leaving the original text. — billinghurst sDrewth 07:39, 18 April 2021 (UTC)
@Billinghurst: Making it a two-step process is often going to be easier and will avoid overly complex regexes. But I did a quick test and I think this'll work: {{9link\|(?:[^|}]+?\|)?([^}]+?)}}. The (?: is a "non-capturing" parenthesis so that \1 or $1 won't be polluted with something you just wanted to group rather than capture. That whole paren is targeting anything that isn't either a } (single-argument form of the template) or a | (multi-argument form) followed by a |. It needs the } to avoid matching into the next template. That bit is also optional so that the same regex can match both forms of the template. But in the multi-argument form this bit gobbles up the linking part of it, so that the last bit can just concentrate on matching the text we want to preserve. --Xover (talk) 08:05, 18 April 2021 (UTC)

Index:Love's Labour's Lost (1925) Yale.djvuEdit

I've done the front matter and Appendices, if you'd like to massage their usefulness with links, as you do. --EncycloPetey (talk) 19:34, 21 April 2021 (UTC)

@EncycloPetey: Awesome. I'll try to get to it as soon as I can (but probably won't be until this weekend some time since IRL is being… recalitrant… just now). --Xover (talk) 07:22, 22 April 2021 (UTC)

{{***}} in PpoemEdit

FYI, this now seems to be working (be gentle with it):

Once upon a midnight dreary, while I pondered, weak and weary,
Over many a quaint and curious volume of forgotten lore,
"While I nodded, nearly napping, suddenly there came a tapping,
As of some one gently rapping, rapping at my chamber door.
Once upon a midnight dreary, while I pondered, weak and weary,
Over many a quaint and curious volume of forgotten lore,
"While I nodded, nearly napping, suddenly there came a tapping,
As of some one gently rapping, rapping at my chamber door.

Also new: copy pasting stanza breaks now (rightly) includes a double line break.

{{Rule}} still needs thought: an HR in a SPAN is a sin. Inductiveloadtalk/contribs 08:09, 29 April 2021 (UTC)

@Inductiveload: FSVO. Putting a br after a display:block leads to a blank line after the ***. Maybe magic syntax to suppress the br? Or more generally, maybe magic syntax for "special line", combined with a "ppoem" param in the cooperating template, where the embedded template takes responsibility for outputting a complete and compatible ws-poem-line? Xover (talk) 08:40, 29 April 2021 (UTC)
Ppoem's BRs are now position:absolute so they are not actually used in the in-poem layout (but they still copy paste to give line/stanza breaks in plain text).
<span style="display:block;">This is display:block; (BR after the line as normal</span> 
Line 2
This is display:block; (BR after the line as normal)
Look ma! No gap.

Copy paste output still includes the BR:

This is display:block;
Look ma! No gap.
Having a ppoem mode for some templates may well be needed, but it seems {{***}} can get away without it.
Also because templates in ppoem expands first, each line of the output is processed separately, which could be a big problem), and a magic syntax for "exiting" the line environment is probably going to be needed if we want to allow HRs and other DIVvy things (or we make lines DIVs too).
It seems that an extension tag might really work better here, since I think the tag sees unexpanded templates templates in the content, but {{ppoem}} sees the full, expanded content, so we don't need to worry about making sure that templates expand to a single line. Inductiveloadtalk/contribs 08:59, 29 April 2021 (UTC)
@Inductiveload: Look ma! No gap. Only in Firefox. :) Xover (talk) 11:39, 29 April 2021 (UTC)
Oh good, now we're into browser shenanigans, srsly? Is this the 90s? Inductiveloadtalk/contribs 11:50, 29 April 2021 (UTC)
Hmm. But you might be able to achieve the same effect with display:none on the br. Not sure how different UAs handle the copy&paste case with display:none though, so that would need testing. Xover (talk) 11:52, 29 April 2021 (UTC)
That doesn't work in Firefox for Copy/paste. What might work (in Chromium) is br { content: ' '; }, but I'm pretty sure that's not supposed to work (content doesn't apply to self-closing tag, and should be applied only to pseudo-elements). Hmmmm Inductiveloadtalk/contribs 12:16, 29 April 2021 (UTC)
Or...just wrap the BR in a span and hit that with the CSS and it works without dodgy browser hacks. Inductiveloadtalk/contribs 13:03, 29 April 2021 (UTC)
Oh good. `cause I was gonna say… :) Xover (talk) 13:47, 29 April 2021 (UTC)

Ill assume that adaptation is not affecting pre-existing applications of this template. Without closely following this conversation, has the point been raised that an aster character * is usually intended to be toward the top of a line (that is, requiring a fudge of surrounding line heights to 'correct')? CYGNIS INSIGNIS 13:41, 29 April 2021 (UTC)

@Cygnis insignis: Yeah, the changes discussed above should not affect other uses of {{ ***}}. The slight imbalance within the line box is not, I don't think, possible to reliably compensate for automatically. It depends on the specific font and font size etc. so it will always require manual futzing, unless one of the upcoming CSS specifications give us much more control over individual glyphs and character boxes than I've seen. Xover (talk) 13:54, 29 April 2021 (UTC)
An asterisk is above the text mid-line: this this*. If you wanted a vertically centred one, you can use &lowast;: ∗ (or various other Unicode glyphs and also images). I imagine a good argument can be made for making that the default char for {{***}}, but that's a whole other thang. Inductiveloadtalk/contribs 14:26, 29 April 2021 (UTC)

The New EuropeEdit

Hello. May I ask for help with the journal The New Europe, vol. 2? There are several copies available at HathiTrust, but each of them has some flaws. It seems to me that the best one is the Michigan University copy, but it lacks 16 pages of the supplement to the issue of Jan 18, 1917. The pages of this supplement can be found e.g. in the California University copy. May I ask you to extract them from that copy and add them to the first one, preferably to the end of the issue? Besides that, the Michigan copy contains also four pages of Supplement to the issue of Feb 1, 1917, but these pages are inserted between the pages no. 80 and 81, while I believe they belong to the end of the issue. Could they be moved, too? --Jan Kameníček (talk) 17:56, 1 May 2021 (UTC)

@Jan.Kamenicek: These are locked behind Hathi's copyright wall so I can't access them. Sorry. I checked IA but they don't seem to have this work. Xover (talk) 18:20, 1 May 2021 (UTC)
I had downloaded both files using H. Download Helper, and I even managed to merge them together using an online merging tool, but I did not manage to shuffle the pages. The merged file is available in my GDrive. --Jan Kameníček (talk) 09:00, 2 May 2021 (UTC)
@Jan.Kamenicek: Oh, I'm a dummy. Of course you had access to them, or you wouldn't know their contents like that! :)
If you have the original files from Hathi, those are going to be best to work with. Tools that manipulate PDFs often do a very very poor job, reducing quality while simultaneously bloating file size. For example, the PDF in your GDrive seems suspiciously large (111MB) for a mostly black and white scan. I should be able to extract the pages and shuffle them around to make a new DjVu, but starting from the original Hathi files will have less potential for weird breakage. Xover (talk) 09:11, 2 May 2021 (UTC)
Page 31 after multiple format conversions.
@Jan.Kamenicek: I've made a DjVu (without shuffling the pages) and uploaded it temporarily to File:TheNewEuropeV2.djvu so you can see the quality. The cover page at DjVu index 31 is particularly telling, but a similar sort of degradation will affect the pages the OCR worked on too. In any case, take a look and let me know how you want to proceed. Xover (talk) 11:01, 2 May 2021 (UTC)
I see, you are right, the degradation is very big. Meanwhile I have uploaded the original versions to GDrive: The Michigan file and the California file. --Jan Kameníček (talk) 11:59, 2 May 2021 (UTC)
@Jan.Kamenicek: Ok, a new version is up at File:TheNewEuropeV2.djvu for inspection. This one has the pages corrected for the two supplements. I placed them after the back covers of the two relevant issues, since the issue text runs on into the cover and inserting them before would break up the flow. But I can move them if you would prefer a different solution.
But I notice that the Jan. 25 issue had a fold-out map that neither of these scans have included. You may want to check if there are other scans that have it properly so we can include it in the DjVu before uploading a final version. Xover (talk) 17:22, 2 May 2021 (UTC)
Great, thanks very much! As for the map, I searched for it in all four available copies found in HathiTrust, but unfortunately it was not scanned properly in any of them :-( --Jan Kameníček (talk) 17:38, 2 May 2021 (UTC)

The Blue Fairy and the return to scansEdit

I was trying to explain to @Billinghurst: how you attatched The Blue Fairy to its scan on another wiki. I was recommending that this be done to all the short stories scattered about and attributed to a journal. Attatch to the scan and move into the journal main.

He is not understanding me, I blame my wordiness and billinghurst not knowing you can do this great thing. Can you cause understanding here where it is not?--RaboKarbakian (talk) 13:45, 3 May 2021 (UTC)

@RaboKarbakian, @Billinghurst: I don't really recall doing anything special for The Blue Fairy Book (in fact, I don't think I've even edited The Blue Fairy Book (Q60321429), and on a quick peek I think maybe it's conflating the work and the edition). I did set up Portal:Andrew Lang's Fairy Books for the series and linked that to the Wikidata item for the series (which exists because English Wikipedia happens to have an article on it). What's the specific context here? Xover (talk) 14:25, 3 May 2021 (UTC)
It wasn't attached to the scan! And now it is! It is beautiful, btw! I will clean up the Fairy Book links at wikidata (nice pointer), I just have the 50s and 60s of Scribners to clean up, first.
There is so much crap here, in the Main. Wikisource needs your abilities, in my opinion.--RaboKarbakian (talk) 14:40, 3 May 2021 (UTC)

@RaboKarbakian, @Xover: At WD I was dealing with WD issues. I would not be discussing WS process there.

The discussion is that subpages of transcluded works should be itemised as editions, not literary works. WS works produce EDITIONS. How we produce editions is not dependent on whether there is a scan or not, it solely relates to the source of the work. If it comes from a source, it is an edition. Please focus. If I point you to d:Wikidata:Books for how you changed something that I created there, then I need you to be looking at what it says, not tell me that Xover is overwriting versions from a scan. Okay? — billinghurst sDrewth 03:26, 4 May 2021 (UTC)

@Billinghurst: Maybe this way of yours contributes to the reason that the two don't work so well together. What happens here, the changing of version pages into redirects undermines what you want there, by putting the version as the source link in the work. I thought the same could happen here, by moving the articles (which are attributed to the journal) into the journal (Journal/Volume #/Number #) space. And attaching them to the scan, which was a thing here a few months ago. A good thing, in my opinion.
Regardless of what happens in this case, changing version pages here, at source, into redirects gets reflected at wikidata. All of that liter. w/poem, edition stuff I did there disappeared, leaving the version here ([[Some Book/A Poem]] as the link on the liter. work there.--RaboKarbakian (talk) 12:50, 4 May 2021 (UTC)
@RaboKarbakian: You are still not listening, and you don't know about what you are talking. I am not talking about any actions here. At WD' I was talking about the specific edits that you undertook at WD. I specifically was on talk page of the item d:Talk:Q81846368. I created the item [2] and you then proceeded to change it in ways that are just plain wrong. You changed FROM version to other things; you dissembled things. I tried to talk to you at WD, and you brought it here. You still prattle on about moves and you have not addressed the issues that I have raised directly with you about the wikiprojects and its guidance.

Also When we move things here, it works perfectly well updating wikilinks at WD, and it changes no other data on the page. ZIP! Plus We don't change "version pages" into redirects, that is not what is happening. — billinghurst sDrewth 13:19, 4 May 2021 (UTC)

Xover, I am sorry that you have to suffer through this. — billinghurst sDrewth 13:19, 4 May 2021 (UTC)

@Billinghurst: No worries. So long as I'm not required to actually comprehend anything, a few extra notifications worry me not at all. :) Xover (talk) 15:41, 4 May 2021 (UTC)