User talk:Xover/Archives/2021

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

Yale Shakespeare 2021

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 tag

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:
<pp?oem>
line 1<ref>reference line 1
this will be a new line</ref>
</pp?oem>
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:
<ppoem>
line 1
|style="text-align:center;"|line 2 (centered)
</ppoem>
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:
<poem>
| line 1
| line 2
| line 3
|- 
| line 4
</poem>
Inductiveloadtalk/contribs 20:20, 1 January 2021 (UTC)

Eumenides request

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 Header

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 ?

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 presentation

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 templates

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)

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)

"Invisible" maintenance text

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() {
  $('.wd-tool-template').prependTo('.mw-indicators')
}

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 templates

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)

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 please

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 there

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?

https://en.wikisource.org/wiki/Special:WhatLinksHere/Template:Indent

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 - https://en.wikisource.org/w/index.php?title=Page%3AA_history_of_booksellers%2C_the_old_and_the_new.djvu%2F11&type=revision&diff=10963239&oldid=10341290

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

Another toy

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

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

Indent...

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)

Lang's Fairy Books

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)

Indent 0

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, but...eh.
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:

Example

*<div style="text-indent:4em">{{lorem ipsum}}</div>
*<div style="text-indent:4em">
{{lorem ipsum}}
</div>
  • 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)

a little spooked

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)
https://en.wikisource.org/w/index.php?title=Author:Andrew_Lang&oldid=10898638 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)

Header

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. smiley 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 works

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)

PGDP

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)

Wikilinking revision - first draft

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)

Voting procedure

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 West

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 me...it'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)

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}}
{|{{tc|__toc__CiDP}}
|-
|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)

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! Fffffuuuuu

Phab:T278379.

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

Class names

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)

Dropinitials

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: https://stackoverflow.com/questions/66825588/move-a-floated-box-down-one-line/66834662 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)


Top margins

@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 bot

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 dumps

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?

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

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 while

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 templates

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 behind

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 poems

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:
{{ppoem|1=
{{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.
}}
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.

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 Billinghurst

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

@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 cleanup

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)

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 Ppoem

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

{{ppoem|
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).
{{ppoem|1=
<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 Europe

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 scans

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)

text quality indicators

A note about those templates. I objected once to the substitution of those with the introduction of the color coded bar, which is somewhat useful though not better than what it was said to supersede. The template gave a color code and visual representation of what that meant, quite neatly I thought, and did not potentially misrepresent the state of completeness of the entire work ('cos, as you know, it only shows the quality of transcription on the parent page itself). I hope this is the seed of an idea for future developments, cheers for your other contributions to site improvements, I believe I'm benefiting from those in the Page and Index ns :) CYGNIS INSIGNIS 11:46, 9 May 2021 (UTC)

@Cygnis insignis: Thanks for the feedback. "Hmm." Your phrasing is ambiguous: did you once object but do not any longer, or was that a polite way to suggest you currently object? :)
The problem with those templates (well, one of the problems) is that they are not maintained. They were, to a degree, prior to Proofread Page, but these days I find fully validated works with TextQuality 0% and other obvious nonsense values. And even if there were a small cadre of users of the template that were religious about updating it, the project has grown far far too large for any manually updated indicator like that to be sustainable. I simply don't see any way {{TextQuality}} can work on the project today (outside of some very narrow exceptions, mostly to do with non-scan-backed works).
Improving the PRP-provided coloured bars is a different matter. There may be things we could do there. It may also be possible to do something roughly along the lines of the TextQuality indicators by different means. Possibly by leveraging Inductiveload's recent work on statistics for the "Monthly Challenge" thing and showing a whole-work progress indicator where the TextQuality icon is shown today using a Gadget. Xover (talk) 12:54, 9 May 2021 (UTC)
I know, it's a flaw, but where I am ambiguous it is often because it encompasses all of those interpretations :) A concern I had at the time was another example of an arcane element on the page, arcane in that it is 'sourcery', even a hover tip or link explaining what it was to non-regular users would have been improvement over the manually maintained predecessor, eg "pages included here are x quality". If I'm being obtuse in my reference to sourcery, it's because I'm hoping someone will ask me to elaborate on that! ;-) CYGNIS INSIGNIS 13:54, 9 May 2021 (UTC)
@Cygnis insignis: No worries. My personal flaw is a tendency to write lots and lots of words to make sure I get my reasoning across. If others can live with that I can certainly live with the odd bit of ambiguity.
I have also been known to perpetrate the odd rant, so if you've got one itching to get out you can feel free to offload it here. Xover (talk) 17:40, 9 May 2021 (UTC)

You have subscribed to the upload rant

OK well you asked :-) I was told in the Commons Discord (after much prior experimentation to rule out user error) to refer to this comment: https://i.ibb.co/2Y304fr/2021-04-13-192552-753x470-screenshot.png

I then asked why there was no mention of this is any documentation, like, anywhere, and was told to, quote, "be bold". Which is roughly the level of "FU, don't care, not our problem, fix yourself" I have come to expect from asking questions in most MW-related channels. So I did, and was challenged and reverted at Commons:COM:100MB. To date, the only sign that spending about 6 hours trying every possible permutation of upload methods is not only known, but almost expected and has no resources allocated to be fixed is a constellation of Phabricator issues with variously confused titles.

Basically:

  • The upload wizard works intermittently (and very....slowly)
  • URL upload works intermittently (ditto)
  • Pwikibot doesn't (didn't, see below) support async chunked uploads which seems to have become a serious problem recently (seems sync chunked uploaded used to be OK but now chokes something)
  • IA-Upload often dies with a 503/4 errors, which is, I hypothesise, the AddWiki framework having the same issue with not doing async chunked uploads.

Anyway, now that https://gerrit.wikimedia.org/r/c/pywikibot/core/+/679021 is merged (after being rebased with substantial time investment to learn how to hack PWB, and then get it though code review, by yours truly over four years after it was originally submitted by someone else), I have had no further issues with Pywikibot, and chunkedUpload.js-into-an-empty file page has worked for ad-hoc uploads too. Inductiveloadtalk/contribs 07:43, 11 May 2021 (UTC)

I went to upload this edition in response to a WS:PD discussion, and I see you beat me to it. Would I be stepping on your toes if I matched and split from Peter and Wendy (1911), or would you prefer I leave it with you? —Beleg Tâl (talk) 19:54, 13 May 2021 (UTC)

I'm planning to proofread that from scratch. Xover (talk) 20:45, 13 May 2021 (UTC)

wikidata two hop pull

I almost brought this problem here yesterday, but I think it cannot be solved or should not is more accurate.

I have a book that is a translation of a later edition. It is a translation of the first illustrated edition. The translation uees the same images even.

So, it would require two jumps to get the interwiki links, first to the edition and then to that other edition. Which might be the reason the Flatlanders have made this an issue -- it would be a reason even if the dimensionally disabled haven't encountered it yet.

It is about Popular Tales from the Norse (d:Q106730453), which is clearly a translation of exactly s:no:Norske Folke- og Huldre-Eventyr (d:Q19535315), which everyone knows to be the first illustrated version of d:Q2026385 which isnt linking to the orig. at no.source right now, but is where the inter-wikilinks are.

Unrelated, and just a rant. That Wegie put more tales in a second edition....

The question here is about getting interwiki links to Popular Tales from the Norse.--RaboKarbakian (talk) 12:44, 17 May 2021 (UTC)

@RaboKarbakian: I'll have a look when my brain feels up to tackling Wikidata. But one bit of information that may or may not help: a translation is just another kind of edition. In a strict ontological sense they are different entities, but for almost any bibliographic database translations are treated as just another edition. That this particular translation was based on a given edition of the original is not really reflected bibliographically; you'd need to record that elsewhere.
But, in any case, I'll try to take a look at some point and see if I can untangle why we're not getting interwiki links where they are desired. Xover (talk) 13:43, 17 May 2021 (UTC)
Yeah, with most books it is not an thing. But, Grimm at Open Library is just terrible, for example. The two tier system is seriously lacking. at OL it is W or M, for work and edition. To solve the Grimm problem there is to never point to the original, and have 100s of individual work & version pairs. A third tier would be helpful, for there, maybe a F for first, then by year or place or "year and place" see https://openlibrary.org/works/OL45361W/Kinder-_und_Hausmärchen which my device doesn't have the omph to find individuals within.
The W M, there starts to look like "funny at the inception" hackordug....-RaboKarbakian (talk) 14:05, 17 May 2021 (UTC)

This needs splitting up a per the ToC... I'll get to it in the next few days, but if you wanted to do it overnight whilst I take a rest, feel free. ShakespeareFan00 (talk) 19:01, 22 May 2021 (UTC)

Kind request for white list

Respected Admin,

I am the owner of my website FreakToFit. Few days before I was citing few articles for information in your wikipedia site as there was less information. But on one day itself I put so much citation that you thought I was trying to promote my content. But its not the truth. I have a fitness and health website which is fully knowledge base and doesn't contains any promotional material. When I was surfing through few of the articles on your panel I saw few lacks of information, thereby I started to putting the info and doing citation. But since it was over doing you have thought I have misusing the panel and thereby promotion.

But its not that sir. I have enclosed a screenshot of my website so that you can have a look. My request to you sir it will be extremely grateful if you please unblock my page freaktofit. Looking for a positive response Uttamwiki23 (talk) 11:50, 2 June 2021 (UTC)

Forum shopping, replied at User talk:Languageseeker#Kind request for white list. 𝟙𝟤𝟯𝟺𝐪𝑤𝒆𝓇𝟷𝟮𝟥𝟜𝓺𝔴𝕖𝖗𝟰 (𝗍𝗮𝘭𝙠) 11:55, 2 June 2021 (UTC)

Vaguely remember ...

... that I saw a recent comment about "p" and "pp" and why not just have a string, and I cannot remember where. The reason that I put them that way was two-fold. 1) Due to transclusions of templates that nest "header" as they will have one or two parameter and it mirrors that function though kept the naming short though obvious; then following 2) this allows a pull into WD with the harvest template bot, and gets around issues of whether we are using hyphen or ndash, and we can change as we need to do so. Nothing stops anyone using just "p", except it doesn't change the label. — billinghurst sDrewth 00:05, 11 June 2021 (UTC)

So...Vue is fun

https://ws-songbird.toolforge.org/ So much easier than gadgets!

That's even a WVUI button in the bottom left. Inductiveloadtalk/contribs 08:31, 24 June 2021 (UTC)

@Inductiveload: Neat! Grazing off the recent changes feed I presume? Is it just a WVUI testbed or do you have a specific goal in mind? (if it's patrolling qua patrolling I need to dig up some links) Xover (talk) 13:36, 25 June 2021 (UTC)
Oh, also, the settings dialog is borked on mobile if you're not aware. It gets mispositioned by the edits and suchlike. /me waves hands vaguely… Xover (talk) 13:37, 25 June 2021 (UTC)
Yes, it uses the RC event stream. It's more of a plaything for Vue/Vuex in general rather than WVUI, since they have a very limited widget selection (even checkboxes aren't released yet). Since it's mostly a toy, and it doesn't use BootstrapVue like https://ws-image-uploader.toolforge.org (which is actually a functional tool), it's not really "expected" to work all that well until WVUI invents dialogs or panels or similar.
It's mostly for fun, but it does make slightly different sounds for proofreads vs mainspace pages and page creations and edits on the Scriptorium and {{New texts}} get different sounds too. But it's not really designed for practical use as such. Though I'll probably improve incrementally as I learn Vue and as WVUI learns widgets. Like make it able to change sounds and store state etc, etc.
Also the sounds go weird after a few thousand pings, no idea what that's about: it's probably leaking something. ¯\_(ツ)_/¯ Inductiveloadtalk/contribs 13:54, 25 June 2021 (UTC)

Need help (two missing pages again)

Hello. There are two missing pages (159, 160) in Dickens vol. 16. Could you please add them from this file? Ratte (talk) 20:32, 14 June 2021 (UTC)

@Ratte: Sorry for the slow turnaround time. I should be able to look at it some time this weekend unless real life decides to be recalcitrant. Xover (talk) 13:32, 25 June 2021 (UTC)
@Ratte: Done Xover (talk) 20:34, 27 June 2021 (UTC)
Thank you! Ratte (talk) 16:52, 29 June 2021 (UTC)

Could you please add pp. 100 and 101 to this file? (It also needs the space at the end of the file-name removed, but I’ll request that move later.) TE(æ)A,ea. (talk) 20:42, 27 June 2021 (UTC)

@TE(æ)A,ea.: Done Xover (talk) 13:21, 28 June 2021 (UTC)
  • It turns out that pp. xxiv and xxv are also missing. They could be recovered from this scan, but should I just replace the current scan with that one, since they are evidently the current edition? TE(æ)A,ea. (talk) 14:56, 30 June 2021 (UTC)
    @TE(æ)A,ea.: I'm not familiar with the work, but if it's the same edition and otherwise complete the technical quality looks much better than the existing scan. In those circumstances I would definitely just upload over it (don't forget to update the file description page). Xover (talk) 17:46, 30 June 2021 (UTC)

<span><span>followed by</span></span>

Hi! I used a wikidata property call with a subst and got <span><span>followed by</span></span> (and for follows). I am thinking it was a fix for some other wiki that got pasted here when the Wikidata module was installed.

I was wondering if I could get permission to find and remove those spans, so, am I permitted to find and remove them? Perhaps they are for something here, but I doubt it.

I can link to things if you need it.--RaboKarbakian (talk) 16:19, 1 July 2021 (UTC)

@RaboKarbakian: Not all templates work with subst: (it often requires coding specifically for it). If you give me some links I'll take a look. Xover (talk) 16:28, 1 July 2021 (UTC)
The Allies' Fairy Book/Frost is where SF removed one. d:P155 and d:P156 are the properties. And the Module:Wikidata I think is the one that I used. It was a really, really simple call, not like Module:WikidataIB. The documentation at wikidata promised simplicity and it was, except the html was embarrassing.--RaboKarbakian (talk) 16:39, 1 July 2021 (UTC)
The subst is how I can tell what is being really rendered! I used both modules for User:RaboKarbakian/WD version, but not with P155 and P156.--RaboKarbakian (talk) 16:43, 1 July 2021 (UTC) (It wasn't a template, it was a simple call to the property....)
@RaboKarbakian: What was the subst: code you used? Xover (talk) 17:33, 1 July 2021 (UTC)
I just added a "published by" to The Allies' Fairy Book/Frost using P123. That is what I did with the follows and followed by properties, only this without the subst. Like I said, I used the module directly. There is a syntax for using it when the page is not installed as a wikidata item. Here: The Allies' Fairy Book/Frost follows The Tongue-cut Sparrow. --RaboKarbakian (talk) 17:43, 1 July 2021 (UTC)
@RaboKarbakian: If you want just the value you will have to call getRawValue, otherwise the module will attempt to format it for you (hence the spans). However, going by way of Wikidata directly in wikitext makes no sense: it's much easier to just copy and paste the text you need and the end result is exactly the same. Unsubsted Wikidata calls should not be used in normal wikitext. Pulling information from Wikidata should happen from inside a template in a controlled scenario, for example the way the {{author}} template does. Xover (talk) 17:49, 1 July 2021 (UTC)
That is not what the how to at wikidata said. I used subst because the information is static. If source ever makes a portal for Heinmann, then that will be linked where I put it. I think those spans are for another wiki and should not be included. But, let me know what you think, maybe, after some more familiarity with it. I used it and thought about it for a long while.--RaboKarbakian (talk) 17:57, 1 July 2021 (UTC)
@RaboKarbakian: Which howto and what did it say? Xover (talk) 18:32, 1 July 2021 (UTC)
It's like I am telling you how to be my boss! :) And really, I used it and thought about this for a while, so let's talk about basic module behavior. A module like Wikidata, when asked to get an item and provides the link (if it is linked) -- shouldn't that provide just an <a href="linkto">Wikidata property value</a>? If whatever template needs it, the spans should be included at that level, the template level, not from the module. It is sloppy html. Would you write html like that? I wouldn't and I don't think that the module should be either. I would be more than happy to check a number of these and find whatever bad html there is in there so that it can be gotten rid of before the module gets used too often. That you hadn't seen this before, makes me think that P155 and P156 are not being used here much, yet.
That how to wasn't exactly hidden at wikidata....--RaboKarbakian (talk) 19:05, 1 July 2021 (UTC)
@RaboKarbakian: It may not be hidden, but there are many howtos there so knowing which one you meant is kinda hard. And if a howto on Wikidata is giving instructions for what to do on Wikisource I'm interested in checking that it doesn't lead people astray.
Regarding modules to access Wikidata, the situation is not comparable to HTML. Templates and modules were not developed with an overarching architecture and separation of concerns in mind: they are an organic development happening at very different points of the technological development curve and trying to solve the same problem. For example, a lot of templates are now simple wrappers around a module that does all the heavy lifting: templates provide a slightly simpler invocation syntax and nothing else.
In addition, some modules are designed to be used in specific contexts where emitting pre-formatted results is the most appropriate interface. WikidataIB, for example, is designed to be used for implementing generic Wikidata-integrated infoboxes on English Wikipedia, where a goal is to let wrapping templates delegate all the Wikidata fields to the module and only contain code for the non-Wikidata functionality.
Wikisource doesn't develop its own Wikidata access modules (we don't have resources to sustain that) but import our modules from elsewhere. We explicitly do not want to make local changes to these modules because those changes have to be re-integrated every time we resync the module from the source wiki, and there is no good way to even detect that local changes have been made, leading to mysterious failures after each update.
So while, yes, in some design contexts it would be most natural for a module to return unformatted values, that is by no means universally true; and, no, we will not change the module's interface locally. If there's a particular Wikidata access module out there somewhere that works like you want we can consider importing it here (with the same caveats), but barring that you'll have to make do with the ones we have.
I have a todo for looking at options for Wikidata access, because Module:Wikidata is deprecated and I find Module:WikidataIB irksome in several ways, so I am by no means suggesting the status quo is perfect. But it is complicated and not an area to be waded into lightly. Xover (talk) 18:02, 2 July 2021 (UTC)


I just wrote a script that recursively gave a style suggestion:"leftt", and the table I was generating, the last four values on the original are wrong, a 1921 "off by .10 error", I guess. And got a "no" from you about my request, so the feeling here is more terse than usual. Warning, some unloading to follow. I do not want to allienate the local DJVU expert, so tough up a bit for the next bits....
So, a summary. But first, some background. I got more involved with my computer than the average due to the developer/enthusiast group I first encountered. A collaborative group who spoke confidentally of experiences and were open-minded about application. I miss them. I get a lot of authoritative mumbo-jumbo from first time viewers now, interspersed with escalation bot bs. You seem to be quite an expert at djvu, which is mysterious and mystical to me. It would be great and fine by me if you explained that. For example, I am really good at some things, but other things are (like I said) "magical and mystical" to me; it would be good to be not alone in that. (longing for home)
If you agree or disagree with my opinion that span span unspan unspan is crappy html is not the issue. What is the issue is that the module is pasted here from some other place and local changes to it will make repasting updates too complicated to consider. (Summary)
If I want to get the spans out of the module, I will need to make my appeal at en.wiki. Which is so weird, since we are in an environment sitting upon versioning software. But at this time, some software is moved from "mountain top" to "hill top" as the tunnels are all tied up with minutia? Summary
It is okay not to be great at everything, in fact, it is perhaps a reality. If there are questions about how to use wikidata, you can send them my way until a more experienced expert shows up. (longing for home)
I read the same warning at the wikidata module as you did. And I read more in other places. I think that warning is itself a deprecated opinion and came with the paste. IB is really good for some things and the data module for others, seriously, look at the source of my version template, both module have their purpose/use. There is a problem with one of my templates, a damn space!!! And I have forgotten how to mark an input as optional so the damn things need a second pipe whether it uses it or not. But perfectly formated versions with only two pastes is just freakin great! (confident speaking about experiences)
It should be okay to say that you don't know something, shouldn't it? Confidence about experiences and open-minded about application -- it's a nice and honest way to interact with others. Please re-read the kudos for being a djvu guru and forgive my tersity (longing for home)
So, two summary, a lot of longing for home, a kindly request to be real and one confident voice.--RaboKarbakian (talk) 00:05, 3 July 2021 (UTC)
@RaboKarbakian: I don't actually understand what it is you are criticising me for. Please be specific and concrete. You can also stop worrying about offending me: constructive criticism politely presented does not offend me (even if I should disagree with it).
Perhaps it would be relevant for you to know that I am a bit frustrated about both the state of available Wikidata modules (not to mention API access from JavaScript) and the limitations of MediaWiki for things related to code reuse and version control?
The current Wikidata access modules are too specialised for specific uses and make assumptions related to those uses. When those assumptions do not hold true the way the modules behave are often either unnecessarily hard to use or too inflexible. It doesn't help that they are unusually hard to understand by being too closely tied to Wikidata and its data model rather than general computing concepts and common API designs. I wish we had a better and more flexible general-purpose Wikidata access module, and I am actively looking for one we could use (on and off, it's not my highest priority by any means).
It is also quite frustrating, to me, that MediaWiki doesn't have better facilities for sharing modules between projects, and for maintaining local modifications and adaptions. The "version control" built in is very specifically designed for prose text in Wikipedia articles, and lacks nearly every single property that is desirable for a code control system. There is also far too little collaboration between the projects, and consequently there is too little affordance made for other project's needs to make local modifications without having to take on maintenance of the module entire.
In other words, I wish I could point you at better facilities for doing whatever it is you are trying to achieve—I certainly don't mean to be dismissive—but I'm afraid we're mostly limited by the cold hard realities of our platform here. If there is something specific you're having trouble with I would be happy to help, if I can, but then you'll have to articulate your need in a way I can understand. Xover (talk) 09:50, 4 July 2021 (UTC)

Lint errrors

Well, I'll stick to 'content' type pages for now..

If you wanted to resolve some of the other remaining lint-errors outside of these:-

A lot of the simpler cases I'd already dealt with, having to a large extent cleared out a fair proportion of the Main and Page namespace misnesting , over the last few months. ( I will note I also cleaned out some simpler cases over on Wikiversity and Wikispecies.) ShakespeareFan00 (talk) 11:12, 7 July 2021 (UTC)

@ShakespeareFan00: Thanks. I may try to deal with some of these eventually, but I also don't think most lint errors are very critical so it has pretty low priority. Xover (talk) 06:22, 8 July 2021 (UTC)

Bot flag active

Hi. Did you mean to still have your bot flag active? Its been on since 9 May 2021 and its only because I include bot changes in my watchlist that I was able to see some of your edits - you've participated in some discussions while still having the flag on, so some editors might have missed your comments. --DannyS712 (talk) 00:26, 8 July 2021 (UTC)

@DannyS712: Grmpl. No, I just forgot to turn it back off. Thanks for the headsup! That would have just gotten increasingly embarrassing as time went on. :) Xover (talk) 06:37, 8 July 2021 (UTC)
Maybe in the future have it automatically expire after some time (a week?) in case you forget? Just an idea. Thanks, --DannyS712 (talk) 06:38, 8 July 2021 (UTC)
@DannyS712: Yeah, the thing is, I normally don't do that because I only need it for a couple of minutes or an hour or so, so any timeout would leave it on too long. Certain sayings spring to mind. I've been meaning to write a user script that gives me a visual reminder that the flood flag is on, and maybe also toggle it without having to go to the Special: page. But, you know, when priorities and laziness conspire… I should probably just start setting it to expire like a normal person would. :) Xover (talk) 06:47, 8 July 2021 (UTC)
Happened again, you're still flagged from 11 July. If you want me to make a script that will give you a visual reminder, I can try - just let me know what that visual reminder should be and where on the screen to show it --DannyS712 (talk) 21:12, 15 July 2021 (UTC)
@DannyS712: Aaaargh! This is now officially embarrassing embarrassing. For my sins I have performed the following penance: User:Xover/seawall.js (critique always welcome, but caveat quick-personal-hack!) @Inductiveload: You may be interested in this. Once baked a bit it might be useful as a admin-only gadget too.
BTW, does MW / Vector actually have any "API" (area of the page) that would actually be intended for displaying this kind of indicator? The mw-indicator stuff seems to be for… other types of indicators. I think we're probably in "will always be a hack" territory, but if anybody happens to know of a "proper" way… Xover (talk) 07:31, 16 July 2021 (UTC)

Could you move/copy this to my user-space, please? TE(æ)A,ea. (talk) 14:53, 3 August 2021 (UTC)

@TE(æ)A,ea.: Done. User:TE(æ)A,ea./Transitory Provisions of the Constitution of Ireland. Xover (talk) 16:41, 3 August 2021 (UTC)

Hong Kong Case Law Files

I've seen your Hong Kong case law file uploads like File:HKSAR v. Xu Shengqi (CACC 463-2010).djvu from Hong Kong's Legal Reference System. I'd therefore like to ask how can one download the original DJVU (or PDF) file from the system, nice and neatly? After all, the print function on that website doesn't give such quality as those judgments uploaded by you. Many thanks.廣九直通車 (talk) 10:07, 1 August 2021 (UTC)

@廣九直通車: I believe I downloaded the Microsoft Word (.doc) version, printed that to PDF, extracted the page images, and used a custom script to generate a new DjVu file with an OCR text layer. If you need more of these just let me know and I can do the same. It's a bit fiddly so no guarantees on how quickly I can get them done. Xover (talk) 10:19, 1 August 2021 (UTC)
Many thanks! I've now managed to upload some legal documents from that website, thanks!廣九直通車 (talk) 03:52, 4 August 2021 (UTC)

More deletions

In some recent deletion discussions, some individual parts seemed to have been forgotten.

Per this discussion (A glossary of words used in the neighbourhood of Sheffield), please delete these pages:

Per this discussion (Introduction (Molesworth to Hobbes, X) and Homer's Iliads in English), please delete this page:

Per this discussion (Leaves of Grass (Gutenberg edition)), please delete these pages:

Per this discussion (Ponniyin Selvan), please delete these pages:

Per this discussion (Sartor Resartus (Project Gutenberg edition)), please delete these pages:

Per this discussion (The Early Christian Attitude to War), please delete these pages:

Per this discussion (Variants and Analogues of some of the Tales in the Supplemental Nights), please delete this page:

Per this discussion (Landmark Education suffers humiliating legal defeat in New Jersey Federal Court), please delete these pages:

Redirection pages are painful, it seems; thank you for your work in deleting most of the pages. TE(æ)A,ea. (talk) 20:09, 6 August 2021 (UTC)

@TE(æ)A,ea.: Wow, that's an impressive haul. Thank you!
The problem is that the mass delete tool doesn't show you any extant redirects; they only show up when you manually delete pages one by one. So for these we have to rely on various other methods to catch them. Thanks for the above list which saved us having to hunt them down! Xover (talk) 09:47, 7 August 2021 (UTC)

my ego vs. seeming to complain

That was a very nice note that you dropped on my talk page. I was letting my ego express itself yesterday. Sometimes that expression seems like a complaint though. I remember feeling dismayed more than eh, "complainatory". I complain (or did complain) when I felt harassed or asked to lower my skill level (which I discovered yesterday was not the site-wide requirement it had been presented as).

Not complaining about volunteers and the current skill set comes with the territory. The opposite of complaining would be gushing, I guess.

Gushes: There is no better place for a djvu jockey than here! Proofers should be fluffing your pillows and such. I took a look at the tools in debian and omg! My script for making a djvu file failed miserably (commons finally deleted it about 4 or 5 years ago) and making one is nothing compared to fixing one! Shuffling cards to be in the right order would be difficult, shuffling a 'certain type of deck' even more so. So, I am very glad you are here.

Inductiveload, seems to have started life at the wikis as an SVG artist. Putting style class manipulation skills to good use is a plus.

Sometimes I deeply regret not learning how to script for wiki, but a lot of people who know "a little of this and a little of that" should always benefit from those who know a lot about one thing (as well as a little of this and a little of that).

There is a fortune file that says "I am sorry for the length of this, but I did not have time to make it shorter". <--That!--RaboKarbakian (talk) 18:32, 7 August 2021 (UTC)

@RaboKarbakian: I live in eternal hope of identifying the actual source of that quote, but like many of its kind it is variously attributed. It is, however, a perfect summation of most of my contributions here: "I would have written shorter, but I didn't have the time." Xover (talk) 20:10, 7 August 2021 (UTC)

partial repairs?

I have two books, with still red links, that are off by one. The first parts are done(ish yellow not green). Can parts or even end parts of books have their text realigned? And, can you pdf-- wait, I just checked and the one is repaired.... The other is Index:The Construction of the Wonderful Canon of Logarithms.djvu--RaboKarbakian (talk) 22:10, 9 August 2021 (UTC)

@RaboKarbakian: Done And as a bonus you got about 3x the scan resolution which should improve ad hoc OCR if needed.
PDF files are mostly not possible to manipulate in this fashion, but in dire cases we can convert them to DjVu and migrate any existing Index: and Page: pages over to use the new file.
DjVu files can be manipulated in many ways, but often (as in this case) it is easier to just regenerate them from the source scans. The problem with offset OCR text is almost always due to a bug that's partially in MediaWiki's DjVu handling code and partly in the reference implementation of DjVu (DjVuLibre). What happens is that certain pathological pages end up generating malformed text data (often the frontispiece or other non-text content that OCR engines get confused by) which DjVuLibre accepts as input, but then fails to later extract from the same file. When this happens MediaWiki fails to detect the error, doesn't notice the missing page, and just assumes that the next page text that it gets belongs to the current page. The net result is that the text layer for, say, page 5 gets added to the scanned page at page index 4. And the effect compounds if there are more such malformed pages, so you can get page offsets of one, two, five, or more pages. My hacked up DjVu toolchain avoids this problem at the source by validating the text layer before inserting it in the DjVu file thereby never actually triggering this bug. Not perfect but it's caught all the cases I've dealt with so far.
The one big challenge with manipulating DjVu files is that when you insert or remove a page all the subsequent pages shift around accordingly. If we have meanwhile created those Page: pages they will now be out of sync with the underlying DjVu file. To fix it we have to move those Page: pages to the new location, and there are no tools to make that process easy. If there are a lot of pages that needs to be shifted by a fixed amount we can use a bot to do it somewhat sanely; but if there are multiple page offsets (some pages added, some removed, spread throughout the work) it becomes a huge pain and must be done manually. That's why we really really want Index: pages and pagelists to be checked thoroughly before starting proofreading.
But, in any case, so long as there actually is a decent scan available we can usually fix it one way or another. Inductiveload even created Wikisource:Scan Lab for just this purpose, so don't hesitate to ask when needed. Xover (talk) 07:30, 10 August 2021 (UTC)
"validating the text layer" would be the formal language that hides the actual magic! I guess I have previous experiences gumming up my works in a similar fashion; a "just deal with it" for old and now solved problems. Ever see an "animated jpeg"? I have. The jpeg plug-in in earlier versions of gimp-1.2 had such a problem that needed images to be flattened before saving (it was called saving back then). Truly, I flattened before saving and then flattened before exporting for the next ten years (or through gimp-2.6) even long after the jpeg plug-in became the supreme best jpeg maker ever (finding the original quality settings). Surely your hacked tools is a similar invention. There are three qualities I have noticed through out the years that people who have my sign sun all possess: wide feet (with the exception of one who has "narrow heels"), an extra striving for perfection (or nit pickers) and the strong tendency to error on the side of caution. Some of those other people have annoyed me to an extreme due to the differences in "caution". That second quality has caused me to avoid Inductiveloads projects (like the Scan Lab) as the mere mention of the name and I get a slurry of errors that software would probably not detect. That third quality has prevented me from seeking help for things like this ocr stuff. I would not have been able to fix the ocr, but on the other hand, finding solutions for other problems myself has been one of the delights of my lifetime, so some balance should be found. The first, the wide feet, the internet makes no requirement of shoes (\pats the internet).--RaboKarbakian (talk) 14:27, 10 August 2021 (UTC)

Members of Congress and copyright

I had mentioning the Murtha case, and said it 'wasn't really relevant' because of being about tort law. That's true, in the main....Murtha, while giving an interview to the press, as a ranking member of one of the Defense committees, defamed a number of Marines by calling them murderers, and it used a explicitly different definition of 'employee'.

What is relevant, though, is that the press interview, and everything he said in it, was part of his 'official duties' because, by saying they committed murder, he would make the Secretary of Defense look bad, and that would help him advance his political agenda. The leeway for what is 'legislative' seems to be, not that it gets tested a lot, very very broad...as long as it has arguably some connection to some law the critter is trying to get passed, some agenda they are pushing, or his 'job' as a sitting critter to interact with his constituents and at least pretend to listen to their concerns. Jarnsax (talk) 04:39, 11 August 2021 (UTC)

@Jarnsax: That accords with the practice we have established for dealing with works by congresscritters. But it all hinges on congresscritters falling within the scope of the {{PD-USGov}} exemption in 17 USC §105, as amended by 17 USC §101. If they are excluded, either by the definition of "employee or officer" or by the Emoluments Clause, from 17 USC §105 then we are left with only the edicts of government doctrine. And while Georgia v. Public.Resource.Org, Inc. significantly expanded the scope of what this covers, it is still a far more limited exemption than that provided by 17 USC §105 in that whatever the work in question is, it must be in some fashion informative upon a law to bear upon an edict of government rather than merely being within the scope of their duties as an "employee or officer of …".
In other words, I think we really need to settle whether 17 USC §105 applies to congressmen. Xover (talk) 06:20, 11 August 2021 (UTC)
I agree... I mean, I have certainly expressed opinions, lol, but I've tried to be clear between what I feel certain about (like, Members of Congress can't be Officers, no other way of reading it) and things where I think the case law is vague.... specific points that, as far as I have dug up, haven't been ajudicated.
It does seem that the scope of "legislative activity" has come up in terms of the Speech and Debate Clause, though. Similar enough that the reasoning in some of the relevant cases might apply... there is some discussion here [3]. I haven't actually looked up those cases yet, as I'm reading a CRS report on the same thing [4]. I'm hoping it might shed more light on where the line would fall...our problem, really, is we're not really looking for something that's stated in statute law, but instead for the common law hole that edicts fall through.
I will say, though, that I don't think PRO really 'expanded the scope', other than making it explicit.... like I said, people have been calling BS on Georgia for years. :) Jarnsax (talk) 07:00, 11 August 2021 (UTC)
@Jarnsax: Edicts of government determinations used to be based on whether the work in question carried some form of force of law. Georgia vs. PRO expanded this to also consider authorship as a factor. For US works the distinction was often academic due to {{PD-USGov}}, but for works from countries that do not have PD-USGov-like exemptions in their copyright legislation the difference is quite significant. Anything authored by the jurisdiction's competent legislative body is now at least eligible for consideration in light of the edicts of government doctrine in US copyright practice. And even in the US, everyone calling bullshit on Georgia does not mean we, here, can ignore it until case law overrules them.
Which is somewhat the point made at WS:PD somewhere: if the Compendium of Copyright Practices flat out states something that it requires interpreting the law to contradict, then we are not competent to do so and cannot ignore them even if they are wrong. In Georgia vs. PRO both the 11th Circuit and the Supreme Court gave us that interpretation, but for the application of 17 USC §105 to congresscritters we're currently walking very close to the line of legal innovation.
I'm starting to wonder whether this is an issue it would be worth bringing to c:COM:VP/C, since it affects them too and the community there is larger. If no conclusion is possible to obtain there we may have to punt it up to WMF Legal (it may just be general enough that they'd be willing to address it). Xover (talk) 07:57, 11 August 2021 (UTC)
My issue with using the term 'expanded' is most easily explained by quoting the PRO decision... "A century of cases have rooted the government edicts doctrine in the word “author,”..." That doesn't mean that I think it would have been appropriate for any of the WMF projects to just ignore their claims, though (don't get me started on Commons and the URAA) so it's fair to say it expanded the scope of acceptable content.
The House Judiciary Committee report on the 1976 Copyright Act is here [5], and discusses section 105 starting on page 58. The main thing I get from that is that "works for hire" and "works of the United States Government" are meant to be construed the same way.
Regarding the Compendium, I'd agree that we can't just say it's wrong, but I think it's easily misread. If legislators "cannot be the authors" of works they create in the course of their official duties, then the US Government could not (if 17USC105 didn't exist) become the owner of "works for hire" created by them, because there was never a copyright to be transferred. The language in 313.6(C)(1) talk about works 'created by' the President, Congress, etc... and then "or any other officer or employee".... the words "any other" imply the entire sentence is talking about officers and employees.
I do think taking this over to the Commons is probably a good idea, but at the same time... points at comment about URAA above. There is an established group over there who has (IMO) a history of ignoring WMF legal. Jarnsax (talk) 10:05, 11 August 2021 (UTC)

Eis et al. running here too

OK: the monoblock, itwikisource-inspired tool runs here too: see User:Alex brollo/common.js, User:Alex brollo/common.css and User:Alex brollo/PersonalTools.js. Obviously I've to test scripts a little bit deeper, but luckily critical points turned out to be few and simple to fix.

I realize that a wide doc would be absolutely needed... the scripts summarize years of painful tries and a very personal editing style, focused on editing speed of wikicode. --Alex brollo (talk) 12:54, 29 July 2021 (UTC)

@Alex brollo: Awesome! I'll be sure to take a look as soon as time allows. Xover (talk) 12:56, 29 July 2021 (UTC)
Years ago, I contributed at en.wikisource, how I can fastly find a list of simple abandonated transcriptions, just to test my script here? --Alex brollo (talk) 05:17, 15 August 2021 (UTC)
@Alex brollo: I'm not sure we have any list specifically of abandoned transcriptions (we have way too many of them), but we have the Monthly Challenge that lists works for community collaboration. You should be able to find something in there. There is also Category:Incomplete texts which lists those transcriptions that have been explicitly tagged as being incomplete using {{incomplete}}. Xover (talk) 07:59, 15 August 2021 (UTC)
Thanks, I'm going to test tools on Index:A daughter of the rich, by M. E. Waller.djvu. Obviously the script needs a little bit of debugging, and I can't fix issues but testing it while editing. The only clues to scripts edits are a memoRegex section into Index talk page and a new eis level1 into the edit comment. --Alex brollo (talk) 09:10, 15 August 2021 (UTC)

Template:Tracked

What exactly changed, because it no longer shows the link to the actuall ticket, just an Open, stalled etc line? ShakespeareFan00 (talk) 13:28, 5 August 2021 (UTC)

@ShakespeareFan00: I can't reproduce. Template:Tracked/testcases looks as expected to me. Where are you seeing it fail? Xover (talk) 17:08, 5 August 2021 (UTC)
@ShakespeareFan00: Hmm. But I am seeing the Toolforge tool that provides the API to Phabricator is currently down, so it's likely the difference in symptoms is due to browser differences. I'll follow up the Toolforge thing and see if we can get the right people to administer a kick where one is needed. Xover (talk) 17:12, 5 August 2021 (UTC)
Previously , the second Test cases would have shown the NUMBER of the ticket, with the Status being the second parameter. In the updated version the nominal Phabricator URL is seemingly being converted to a status indication.

ShakespeareFan00 (talk) 09:04, 6 August 2021 (UTC)

@ShakespeareFan00: This should be fixed now. Tracked tasks should now show up with either the task number (an exception, cf. later) or the task description, followed by the status. Note that the backend service giving the status data is flaky and sometimes returns errors when queried. When that happens the template will just show the task number (instead of the description) and no status. Xover (talk) 07:31, 13 August 2021 (UTC)

Aiaaira

FYI, my little ramble about Hague IV etc. was essentially just meant to summarize what I had learned while looking into the situation of who had actual legal authority... like my other comments over there, I'm just mostly trying to give more info to hopefully help you guys with closing stuff.

This actually got me off on a nice tangent of reading way too much about the legal situation when the USSR dissolved, and how it was legally built. Anyhow, I think zapping it is the right decision... what I have basically learned is that people were are technically 'citizens' of whichever SSR, as well as Soviet citizens, but borders changed repeatedly, people moved around, and the citizenship law for the SSRs was "intentionally kept vague" and was basically irrelevant.

The kind of details about the author's life that would be needed for a formal copyright clearance are probably, to us, unknowable. Jarnsax (talk) 20:24, 26 August 2021 (UTC)

@Jarnsax: Yeah, that was what I figured (if I thought you really disagreed I would have held it open to try to tease out a consensus). All contributions to the discussions at WS:CV and WS:PD are very much appreciated: copyright research, since it requires a bit of specialised knowledge and often a lot of effort, is especiially appreciated of course; but even just expressing an opinion on issues that are not clear cut helps tremendously. Even on WS:CV we have a lot of issues that boil down to what each participant's standard of evidence, risk tolerance, or general stance on issues without a bright-line regulation in our policy or US law is. On WS:PD most issues are decided based on the participants' individual opinions because we have little bright-line policy for non-copyright issues.
When there are few participants, and they represent opposite outcomes, the issues deadlock and never get resolved. Especially since I really don't like letting mere majority voting settle the outcome: if it's, e.g., 2 vs. 3 on the outcome and both sides feel strongly about the issue, that's effectively a deadlock. And having 3 people total participate is probably above average.
What I'm trying to say, in a roundabout way, is that I very much appreciate your participation in these processes, both in terms of just generally contributing to consensus-building and in terms of actual legal and bibliographic research. Thank you! Xover (talk) 06:17, 27 August 2021 (UTC)
It's nice to hear that the admin mainly closing them knows how a wiki is supposed to work. :) I try to make it as least fairly clear when I'm "reasoning" vs citing factual information or actual cases (you've probably notice I try to cite stuff).... people are of course free to disagree with my reasoning, and I still tend to think in terms of Commons copyright rules anyhow (the 'and at home' thing). Jarnsax (talk) 18:16, 27 August 2021 (UTC)
@Jarnsax: Yeah, it took me forever and a day to train the lump of lead I use for a brain to think in terms of US-only. It doesn't help that I actually agree that Commons' policy is the right balance on this and that enWS should adopt it. Oh, well. Anyways, thanks for the compliment: I try! And when I inevitably mess up please do let me know. I may be an ornery, cantankerous, grouch, but I try not to bite the heads off people with valid criticisms. Too much. Xover (talk) 18:40, 27 August 2021 (UTC)
Right, ours is 'simultaneous worldwide publication'. Jarnsax (talk) 18:45, 27 August 2021 (UTC)

table style: template to module transition left docs in the dust (they were already very dirty)

The docs for {{table style}} have seemingly always been out-of-date. Now even more so. I just tried to use {{ts|w5}} and got style="w5;" output. Similar for {{ts|w10}}. They used to work. Never saw "w0" before, nor the "two thirds" longhands. Oh, they were there! {{ts|sc}} was never documented, even though used in examples in the doc!

Should items documented in the current Template:Table_style/doc be checked against Module:Table_style/data and forced into /data if missing ?

In addition, should items found in Template:Table style/parse be checked against Module:Table_style/data and forced into /data if missing ?

Should items not present in Module:Table_style/data be dropped from Template:Table_style/doc ?

And of course the proposed "additional shorthand"s aren't present. Can we drop everything in the "additional shorthand" column?

And how (or should) we document the new aliases like "all small capitals" ? Oh, look, at one time they were called "natural language"!? Huh?

And then someone changed column "code inserted" to "natural language code"?? It's CSS! 'Tain't nothing natural about it!

Can you think of others that would be sensitive to documentation changes?

Arrgh! What are your wishes my master? Shenme (talk) 04:10, 30 August 2021 (UTC)

@Shenme: Things that were only in the doc page never worked, so I've not bothered with those. The codes in /parse worked with the new module, but additional codes were added after I copied them but before I migrated the template to the Lua module. I've resynced those so they should now work too. As for the documentation table, it is now generated automatically from the data in Module:Table style/data so it should now always be up to date (modulo caching etc.). Happy? :) Xover (talk) 08:34, 30 August 2021 (UTC)
Use table to generate doc... automatic synchronization... I can't fault that! Thanks.
I've updated Template:Table style/doc a little. Link CSS so people know to blame someone else for problems/quirks. Add a note that styling sometimes doesn't work, e.g. table rows.
Would it be okay for me to change the column title
:tag('th'):wikitext('Style')
to
:tag('th'):wikitext('Output CSS Style')
There are so many different mentions of 'shorthand's, 'shortcut's, 'aliases', 'style's, etc. that being very clear what the output actually *is* is important. Again, if they have problems, get them to blame CSS, not us! Shenme (talk) 20:22, 30 August 2021 (UTC)

@Shenme: Go right ahead. :) Xover (talk) 21:13, 30 August 2021 (UTC)

non-emoji entities

When I placed them there, I knew they would render into creepy candy colored things on my mobile device, but I did not know there was another option. (I have such sadness about the emoji-fication of the Unicode Consortium)

Where did you find those things?

What are those things?

Where can I get my own collection of those things?--RaboKarbakian (talk) 14:14, 30 July 2021 (UTC)

@RaboKarbakian: Welll, I'm on macOS which happens to have a pretty decent "Emoji and Symbols" helper that, despite the name, gives you access to most of Unicode. But you can usually google your way to this stuff: there's tons of web pages with Unicode tables, including Wikipedia. Xover (talk) 16:53, 30 July 2021 (UTC)
I used Gucharmap which is the gtk+ unicode do-hickie. Mine came from the "Unicode Dingbat" block. I don't have the emoji unicode data installed. How did I get emoji and you get what gucharmap was supposed to deliver? (the app is using Red Hat's Liberation font, btw).--RaboKarbakian (talk) 18:42, 30 July 2021 (UTC)
Also, emoji are unicode: see https://home.unicode.org/ --RaboKarbakian (talk) 18:50, 30 July 2021 (UTC)
Sorry, I am not done here. I was just fooling around with the fonts in my browser and with this page: https://www.unicode.org/charts/beta/nameslist/index.html. ("Miscellaneous symbols" is at the 2600 block) When I use Dejavu font, I get the textural glyphs, when I use Liberation, I get the emoji. Mozilla installed an emoji font set so I am assuming that if the font selected does not contain the character, Mozilla puts an emoji there. So, while I did not build this Gucharmap, I have built it before and know what goes into it. I am going to assume that I used unicode characters. Whatever you pasted there made a "diff" so it is not unicode (because that would have not shown a change). Since you got your app out of a box, I think I will never know. Unicode was a very respectable group of developers before this emoji thing. Maybe it is like that HGTG story about the planet with Group A, Group B, and Group C, where the Group B people picked the colors of things. Any day now, maybe they will be sent off....--RaboKarbakian (talk) 19:15, 30 July 2021 (UTC)
I seem to need to express myself in between researches. I just answered my own question. See ☘ vs 🍀. {{Unicode|&#x2618;}} vs {{Unicode|&#x1F340;}}. I will be happier not asking the question "Why did my gucharmap paste give me the new one and yours didn't?" but I will always kind of wonder of it.--RaboKarbakian (talk) 19:31, 30 July 2021 (UTC)
@Xover: can you point your browser at User:RaboKarbakian/Symbols and tell me if there is anything in the text column that looks like an emoji and if there are any text in the emoji column? 1) it all looks like text to me (the text column has been x-largered) and 2) there is no special emoji for zodiac so I am wondering if calling by the unicode name is what makes emoji appear in your browser). 20 years ago, it was javascript for IE or for Netscape. *shrugs*, *pats ascii* --RaboKarbakian (talk) 01:06, 2 August 2021 (UTC)
@RaboKarbakian: My apologies, I appear to have missed this question. In the tables on that page, the vine leaf ones in the first table appear unsupported here (haven't checked why); the "New Moon" up to "Sun with face" are Emoji-styled, as are "Aries" through "Pisces"; otherwise they appear as textual forms. Xover (talk) 17:54, 15 August 2021 (UTC)
@Xover: Both sides? meaning the left side is using the xml number and the right side is using the unicode number? I was expecting the xml to display as text and the unicode to display as emoji styled. There are not special unicode identities that point to something other than what the xml points to {like the shamrock). If both sides of my table display as emoji-like, then I have no idea what it was that you pasted or how to for certain access it. And the vines don't display here either. I put them there so that one day they might, and maybe they too will be familiar printers marks like the floral leaves are.--RaboKarbakian (talk) 19:24, 15 August 2021 (UTC)
@RaboKarbakian: It's ♈︎ (U+2648 ARIES + U+FE0E VARIATION SELECTOR-15) vs. ♈️ (U+2648 ARIES + U+FE0E VARIATION SELECTOR-16). VS-15 asks for a text presentation and VS-16 requests Emoji presentation. The astrological symbols are Emoji by default. This only works with Unicode code points that explicitly support variations. Xover (talk) 06:09, 16 August 2021 (UTC)
@Xover: My eyes don't exactly cross, but something in my brain does the same thing when I see unicodes. I blame hex, but that might be wrong. Anyway, I just wanted to drop this off, here: https://unicode.org/Public/emoji/11.0/emoji-variation-sequences.txt Along with that &#FE0E being the same as &#65038;. There is at least one browser, chrome on someones mobile device that does not draw them correctly. I am checking an ipad later.--RaboKarbakian (talk) 17:01, 4 September 2021 (UTC)

The Net of Faith

Hello. Although I still believe that pre-1978 theses without copyright notice are PD nowadays, I would also like to try to get more information from nonresistance.org about their publication of The Net of Faith and ask Tom Lock about it. Can you please help me to word the questions that we need to be answered? Thanks! --Jan Kameníček (talk) 15:05, 4 September 2021 (UTC)

@Jan.Kamenicek: Well, the high-falutin' legal discussion is really orthogonal here. The discussion is really about whether PD can be assumed in the absence of an assessment of evidence specific to the case under consideration. As I mentioned at WS:CV, even if the assumption must be that they are protected by copyright the circumstances for a given dissertation or thesis paper may, on examination, lead to the public domain through failure to comply with the formalities or other means. And there are definitely many plausible ways that could be the case if we can just find the evidence.
So… if we're going to do the leg work, the first step is finding out what nonresistance.org's source for the text is. Did they just grab it through inter-library loan and scan it or transcribe it? Was it submitted to them by the author? A third party? Were they given a "permission to use", and if so under what terms? Were they provided an actual license and if so what was that license?
My immediate guess would be that they found it in some uni. repo or library somewhere and just grabbed it. In that case their part in the chain of custody doesn't help us much, and we will have to track further back. Was the translated text actually a part of the thesis paper, or did the author just happen to translate it while working on that thesis? If it wasn't part of the thesis, what path did it take to end up at nonresistance.org? Was it published anywhere prior to going online there, and if so where and when and under whose authority? If it was part of the thesis paper, which educational institution was it submitted to and what were their instructions to students and policies for such papers? Did they archive physical copies, or microfilm? Were these distributed anywhere? Were they made available through inter-library loan, and if so under what restrictions in terms of who could get access and what they could do with them? Was it ever commercially sold, for example to other articles chives and libraries through the microfilm distributor? And, not least of all, does the original—wherever it was first published—contain a copyright notice? It is in my experience rare for this kind of text to do so, but it is absolutely not unheard of, not even in the relevant time period.
Judging by Worldcat, Molnar published commercially (well, depending on what you consider "commercial", but…) as late as 1980, so I hold it not at all unlikely that the translation in question was actually published commercially as well. If so it was definitely subject to "general publication" and the normal rules (notice etc.) apply. Xover (talk) 15:36, 4 September 2021 (UTC)

quickstatements

It requires autopatrol level which I don't have here. I have it at commons where I have compiled a list of properties.

I was thinking of something like a citation template that creates a data item for the scan, which I can do from the commons because, well, they like me there I guess and have given me more rights.

Then I was thinking, maybe @Xover: can make this here before I can make it there. And so I am here, with the link and also, with the collected properties.

Quickstatements howto: https://www.wikidata.org/wiki/Help:QuickStatements#Best_practices Recently compiled property list: commons:User:RaboKarbakian/WD create book although, it might get renamed to "create scan"....--RaboKarbakian (talk) 17:02, 16 September 2021 (UTC)

Months ago, you asked me for the link at wikidata. To refresh your memory. one of the modules here claims to be "less expensive" than using the regular wikidata module. I am quite certain that the word "expensive" is being used to describe how much the computer is being used. I piffed at that statement, and still do, but I am willing to be corrected if I am wrong. The software chain is user, intermediate module, wikidata module. Sending a simple "#statements" to one module, who sends it to the wikidata module is the same as sending a simple "#statements" to the wikidata module or "less taxing". I think that the "expensive" part comes from sorting and qualifier finding. So, on my templates, if it was a simple thing, I just used the simple. If it really was complicated, I invoked one of the intermediate modules. Here is the that link I thought you should find yourself: https://www.wikidata.org/wiki/Wikidata:How_to_use_data_on_Wikimedia_projects (cryptically named, as you can see) I don't mind if you take my logic apart. I would prefer to be actually correct instead of just sounding correct and thinking that I am.
Also, you can probably win my challenge without even trying or even writing anything because I have no experience with Wikibase. I will need something like that to be able to get the right author id, location id, etc. The structured data interface at the commons does it really well. Have you seen that?--RaboKarbakian (talk) 19:36, 16 September 2021 (UTC)
Eek! Javascript! This is AC/DC https://commons.wikimedia.org/wiki/MediaWiki:Gadget-ACDC.js . It is slick. It will gather all of the images in a category, or work with a list. It will find a property at wd, given enough to search with (copyright status shows up with "c o p" for instance, pub date with "p"). It also locates Q's when given to it. It makes structured data (for commons files) at commons, not uploading to wikidata though. Some mix of this and quickstatemnts. I am done with the links and bothering you.--RaboKarbakian (talk) 19:57, 16 September 2021 (UTC)
@RaboKarbakian: I'm not following you in the above. What exactly is it you are asking me to do?
If it's making a template or module that can directly create an item at Wikidata then that's not really doable (for all sorts of reasons). If it's user interface like the Structured Data for Commons here on enWS then that's going to be a pretty tall order, and is likely better solved by getting the WMF to add in-core support for it. If it's a utility javascript á la ACDC it's something we can look into, but since Wikidata doesn't really offer any sane JS API (that I've found) it's not a very inviting prospect (I've looked at existing scripts' code and it ain't pretty). Xover (talk) 06:43, 17 September 2021 (UTC)
My initial idea was for something like a citation template that would create the data entry. Templates here all get not put. Quickstatements does that, all that is needed is for the information to be correctly formated (for quickstatements, pipe using syntax, iirc) and then reformated to send via http to quickstatements. So, that will all work from here.
My idea faltered when I realized it needed to be able to locate and use the correct "other information" from wd, like author and place of publication. That is when I found that javascript for ACDC, which does all of that.
My question about what you wrote is "Is Sanity a quality that Javascript API is even able to possess?" I have translated Scheme to Python and Perl to Python but it was all for a base software that I understood. I pasted the ACDC javascript into a text editor, saw that it was all on one line, my vision blurred, I closed the editor before I began seeing dolphins or birds or "something" in the Magic Eye-like image that my text editor had turned into. Came here and wrote positive things, not mentioning the text editor experience. No nightmares, last night, as I thought maybe. That is all I know about ACDC, other than it searches wd for properties and items.
I built my idea here. Sorry for the mess. Quickstatements will create wd entries from here, via url commands. I thought that ACDC uses wikibase to search wd, but is that wrong?--RaboKarbakian (talk) 12:23, 17 September 2021 (UTC)
@RaboKarbakian: I'm not sure what ACDC uses.
Hmm. Ok, so you're looking for some way to get to a pre-filled QuickStatements batch from a wikipage? What sort of wikipage (Index:, File:, any random page, etc.)? And what information do you envision manually entering into that page or are assuming is already on that page, and what information do you envision being looked up before being fed to QuickStatements? And should the QuickStatements batch create a completely new item, and if so of what kind? Or should it add attributes to an existing item? Xover (talk) 14:27, 17 September 2021 (UTC)
@Xover:From when I still thought it could be a template commons:User:RaboKarbakian/WD create book. The properties for creating a wikidata item from the scan. If you interested in seeing the book template at work for the images used here, File:Midsummer-Nights Dream-Rackham-081.jpg is a good example I have handy. If not, avoid!! (I have been "GET" info at wd for that, this is the same only "PUT".)--RaboKarbakian (talk) 14:36, 17 September 2021 (UTC)
@RaboKarbakian: The book template doesn't create a Wikidata item, it pulls information from an already existing Wikidata item. And the Book template already exists, so I am assuming you are trying to achieve something different from what it does. Hence the questions in my previous message: I need to understand what it is you are trying to achieve before I can figure out how that might be achieved. Xover (talk) 15:16, 17 September 2021 (UTC)
@Xover: Others have suggested that there should be a way to glean the information (from a template was my idea) and put it at wikidata. The book template, it will add the scan (P996) to an existing wd item. Probably I should not have pasted an example of that. At commons, that template uses the art module, I cannot imagine working on that. But a different template say, something like the hypothetical {{WD create book scan}} that puts rather than gets.--RaboKarbakian (talk) 15:28, 17 September 2021 (UTC)
@RaboKarbakian: A template cannot itself modify Wikidata. What it can do, and which several different templates already do, is to construct a link to the external QuickStatements tool that will pre-fill the details of a batch when you click on it. If you want a template where you can fill in all the parameters listed on c:User:RaboKarbakian/WD create book and, on saving, get such a QuickStatements link, then that should be possible.
But unless I understand how and where you intend to use it, and what effects it should ultimately have at Wikidata, I am unable to comment on the specifics. Xover (talk) 07:53, 18 September 2021 (UTC)
@Xover: iaupload might be a good start.
I started remembering.... The book template at commons does search and create if no wikidata id has been given it. Seems like it did not "put" all of the information at wd when it created it though. Also, finding it once created was a challenge, but I am going to look for it this time in my contributions (which I hadn't before). That info was at quickstatements, but with url activation, maybe not so helpful. I'm gonna find one of those pesky pdfs and see what all of that is doing lately.--RaboKarbakian (talk) 14:52, 18 September 2021 (UTC)

No good deed... {{table style}}

Consulting {{Table style}} for the Nth time this week and just happened to notice...

When calling up the page to consult the documentation, there's a stray line at top

style=""

Dropping the documentation doesn't fix that. Dropping the module invocation

{{#invoke:table style|main}}

does make the stray text disappear.

I noticed that Module:Table style

function p._main(args)

has these lines which would run whether there are arguments or not:

local str = 'style="'
for ....
    ....
str = str .. '"'
return str

Perhaps instead the order something like:

local str = ''
for ....
    ....
if str is non-empty
  str = 'style="' .. str .. '"'
return str

or whatever the 'correct' lua would be. Shenme (talk) 00:32, 29 September 2021 (UTC)

@Shenme: Done. Xover (talk) 13:43, 29 September 2021 (UTC)

Unused files

I have created this file to scan-back Appeal of the Council of People's Commissars to the Moslems of Russia and the East; please trim the second page, please, and match-and-split. TE(æ)A,ea. (talk) 20:56, 5 October 2021 (UTC)

@TE(æ)A,ea.: File:Appeal of the Council of People's Commissars to the Moslems of Russia and the East.djvu, Index:Appeal of the Council of People's Commissars to the Moslems of Russia and the East.djvu.
As you can see, image (OCR) quality is really poor due to generational loss: scan/photo → PDF → JPEG → JPEG → DjVu. It's generally going to be better if we can work on the original files: scan/photo → DjVu. Xover (talk) 07:12, 6 October 2021 (UTC)
Awesome! If you have pictures of the TOC it might be useful to have those for reference in case someone wants to see about some particular document in the future (even if we just have the image in commons). MarkLSteadman (talk) 15:23, 6 October 2021 (UTC)
  • MarkLSteadman: I only took pictures of those three pages, and I have now returned the book, so that is not possible—sorry. There were several dozen documents in that volume alone, not counting the other two (I think) volumes, so that would have been helpful. TE(æ)A,ea. (talk) 17:08, 6 October 2021 (UTC)
No worries. Awesome that you were able to get it. MarkLSteadman (talk) 18:06, 6 October 2021 (UTC)

Version Page for Jane Austen.

I see that you removed the notes about other editions from Jane Austen. Would you mind creating version pages for Sense and Sensibility, Mansfield Park, and Pride and Prejudice? Right now the text of Pride and Prejudice are from the 1817 edition while the scan links on Jane Austen are from the 1811 edition. I'm also planning on adding the ssl to the other texts, but they will be mismatched as well. Languageseeker (talk) 12:29, 3 October 2021 (UTC)

@Languageseeker: So far as I can tell we only host one version of each of those texts. Am I missing something?
Also, what's listed on author pages are works, not editions. Works don't have publication dates, they have dates of first publication. That the text we current have is a 1817 edition is entirely compatible with the author page showing the work to have been first published in 1811. Xover (talk) 13:08, 3 October 2021 (UTC)
I think the question becomes where do we put the scan links for the other editions. Right now, the following is confusing because the Pride and Prejudice refers to the 1817 version, (1813) refers to the first publication date, and (transcription volumes: 1, 2, 3) refers to the unproofread scans of the 1813 edition. How do we clear up the confusion? Languageseeker (talk) 15:35, 3 October 2021 (UTC)
The answer is Author:Jane Austen. We probably do not need ESL for all the editions, though if you have SSL then you can list them there. Don't go creating hot links to editions of works where we don't have a scan. — billinghurst sDrewth 15:43, 3 October 2021 (UTC)
@Billinghurst: Is something like this acceptable? Languageseeker (talk) 15:45, 3 October 2021 (UTC)
@Languageseeker: Since we have Billinghurst's attention I'll generally defer to them on this issue, but… I'd say that if there is work actually planned (and not just amassing links) for additional editions of these works, then add the ssl entries as sub-items (***) under the work. Just not as mainspace links for the additional editions: those go on a versions page, and only when the additional editions have actually been proofread. --Xover (talk) 16:12, 3 October 2021 (UTC)
I'm not trying to amass links for the sake of having more links, but to try and define what needs to be proofread. All the major authors have hundreds of editions of there works, but only a few of them are either those that the author contributed to or have some independent merit. Also, I've noticed that adding scans actually increases the likelihood that a text will be proofread. Languageseeker (talk) 01:37, 7 October 2021 (UTC)

Ppoem pokes its head out of its burrow

...but will it see its shadow? I have removed the dire warnings of doom from {{ppoem}} (leaving in its place a note along the lines of "be gentle").

Do you think a general announcement is in order, or wait and see if/how the keen-eyed early adopters manage to make it explode and shower us all with tiny bits of shattered poetry for a while? Inductiveloadtalk/contribs 08:04, 8 October 2021 (UTC)

@Inductiveload: I'd say announce it, and let the announcement reflect that while the template itself is well-tested and stable the use of it is still experimental. We have a theory that it will be way way better than the alternatives, but only large-scale use by diverse contributors will tell us that for sure. Xover (talk) 06:04, 9 October 2021 (UTC)

multi-layered tiff

Just for your notes, GIMP 2.10 (maybe others also) handles them much in the same way it handles pdf.--RaboKarbakian (talk) 15:02, 9 October 2021 (UTC)

File for redaction

It is Hotaling v. Church. Please redact the following:

  • On p. 199 (/1), the key symbol below “AFFIRMED” and the paragraph at the bottom of the right column;
  • On p. 200 (/2), everything except for the running header;
  • On p. 201 (/3), the paragraphs above the rule in the left column; and
  • On p. 205 (/7), the key symbol in the right column and the two paragraphs at the bottom of the right column.

Thanks! TE(æ)A,ea. (talk) 14:18, 9 October 2021 (UTC)

@TE(æ)A,ea.: Done and deleted. DjVu at File:Hotaling et al. v. Church of Jesus Christ of Latter-Day Saints.djvu. But are you sure the redacted bits are a copyvio? What's the source / who is the author? If it's just the syllabus and written by the reporter we host about a gazillion of those already (nearly every USSC case has it) and it's covered by the same license as the order and dissent. Xover (talk) 15:09, 9 October 2021 (UTC)
  • This opinion, as you can see, was published in the Federal reporter, Third series, which was published by West (now a wholly-owned subsidiary of Thomson Reuters). The syllabi and headnotes were prepared by West staff, and are thus copyright West. This is the reason newer volumes of the Federal reporter and regional and state reporters cannot be hosted: the extraneous material was not produced by someone with the ability to interpret law (or whatever the PRO phrasing is), but by a private individual or agency. I’m thinking of getting some more of these copyright-related opinions; is there a portal for (U.S.?) copyright law where they could be listed? TE(æ)A,ea. (talk) 15:45, 9 October 2021 (UTC)
    Ah, I see. There's no portal for copyright opinions that I'm aware of. Might be useful to have, both in Portal: and in Wikisource:. I keep having to google for things like PRO, and often struggle to recall the right google keywords. Xover (talk) 16:09, 9 October 2021 (UTC)
  • Xover: I have two more cases for you to censor, please: the district and circuit court opinions in this case. For the first one, please remove the first page (which relates to the whole volume), and censor the following: the West Key logos (on pp. 1350 and 1361); the syllabus and headnotes to the case (from “background” on p. 1350 to just above the rule at the top of the second column on p. 1352); and the syllabus and headnote to the following case on p. 1361. For the second one, please remove the first two pages (once again, relating to the volume) and censor the following: the West Key logos (on pp. 1229 and 1255); the syllabus and headnotes to the case (from “background” on p. 1229 to just above the rule at the bottom of the first column on p. 1231); and the syllabus to the following case (on p. 1255). TE(æ)A,ea. (talk) 21:26, 12 October 2021 (UTC)

Your comment on Author talk:Miss Morrison has prompted me to create a tracking category for such pages. Observe: {{honorifics}} and Category:Authors with honorifics in title. —Beleg Tâl (talk) 14:14, 13 October 2021 (UTC)

another controversial scan, maybe

It is not here yet, but I ordered "The Night Before Christmas" from the library. All of the 1960 and later documentation I have seen claims 1931 but SF uncovered an advertisement on a jacket cover for it from 1916. See Page:A_Christmas_Carol_(1916,_Rackham).djvu/193.

Would that dust cover be enough proof that the 1933 version is a reprint?

I also think that a lot more of the 1930's works were reprints of earlier works, small printings (perhaps), scanty records, lost in a war that devastated London. He died in 1939.--RaboKarbakian (talk) 14:22, 18 October 2021 (UTC)

@RaboKarbakian: I don't think so, at least not at first blush. But it'd depend on the details of what evidence is available, and might come down to subjective risk-tolerance, so for a given case it might be worthwhile to open a WS:CV discussion. Xover (talk) 06:16, 22 October 2021 (UTC)

Error on Author pages

Hi, I’ve come across this error message Lua error in Module:Author at line 426: attempt to index field 'datavalue' (a nil value). on Author:Harriet Angelina Fortescue whch I created this afternoon and now Author:William Harrison (1534-1593) which you created, which makes me feel better that it’s not just me. I can’t see what’s wrong. Any ideas? Cheers, Zoeannl (talk) 04:16, 23 October 2021 (UTC)

User:Zoeannl Xover will have the information but I had this experience today also. When I installed the Author page at Wikidata, the error went away.--RaboKarbakian (talk) 04:35, 23 October 2021 (UTC)
That worked for Harriet. But doesn't explain William's error. Cheers, Zoeannl (talk) 07:02, 23 October 2021 (UTC)
@Zoeannl, @RaboKarbakian: Should be fixed now. It was that dear sweet, but regrettably naïve child, Inductiveload, that in attempting to add some categories automatically based on data from Wikidata, failed to account for the perverseness and general hostility of the world. It is very charming and becoming, but I fear the baseness of technology and its users will lead to their disillusion. :)
Author:Harriet Angelina Fortescue was not connected to Wikidata, so when the code tried to get information on nationality etc., it was handed undefined and nil values. Author:William Harrison (1534-1593) was connected to Wikidata, and the item had a "nationality" property, but its value was empty, which Wikibase handles by sending back a completely different data structure. There was also a third variant that involved a property being set, but set to an "unknown" value, which triggered the same problem.
The solution for all of them is to be a bitter, cynical, and paranoid old grump that trusts no one: in this case by treating anything returned by mw.wikibase as hostile until it's been through quarantine, disinfection, background checks, three independent immigration interviews, and has waited three weeks after getting its immunisations (and even then it's best to keep an eye on them: CONSTANT VIGILANCE!!!).
There were about a hundred author pages bit by this that MediaWiki picked up (it's slow; there could be more that weren't reported), and all of them was one of the three variants above. Xover (talk) 07:41, 23 October 2021 (UTC)
Sweet! I enjoyed, if did not fully understand, your explanation. Cheers, Zoeannl (talk) 07:55, 23 October 2021 (UTC)
Thank you for (re-)educating this sweet summer child. I'm becoming more grizzled and cynical by the day and it's not only because of the software Inductiveloadtalk/contribs 10:27, 23 October 2021 (UTC)
User:Zoeannl what Xover said and Inductiveload is figuring out is this: Computers are stupid. It takes a human person (preferably a human being) to determine all of the ifs, thens, buts, and whiles and tell the computer not only to watch for them, but what to do when it sees them. People are infinitely smarter than computers.--RaboKarbakian (talk) 14:28, 23 October 2021 (UTC)
(I feel obliged to note for the record that Inductiveload has absolutely no need of my teaching on the art of egg-sucking. I'm just teasing them because Wikidata accesses blowing up is an endemic problem no matter how defensively one writes the relevant code. Only full-blown paranoia has a reasonable chance of staving off most such snafus.) Xover (talk) 15:15, 23 October 2021 (UTC)

hin

See my User talk..

I am also saying I have no objections to four letter word comments being suppressed/oversighted as a matter of routine policy. ShakespeareFan00 (talk) 10:10, 24 October 2021 (UTC)

Wow..

I forgot I'd even written this a few months ago.

Can you review the code and add some standard features like being able to 'class' the content created by it using Indexstyles ? (This template is potentially useful to replace certain other templates, by setting up appropriate stylesheets. ) ShakespeareFan00 (talk) 08:04, 25 October 2021 (UTC)

Regarding Cygnis Insignis' nomination

Couldn't reply to your post on it's proper place because it was locked, so forgive me for replying here.

*:{{ping|Ineuw}} Nominating someone without asking them first is a bit presumptous. Doing so in this case, when the last nomination was controversial, was really poor form. There was no reason to assume it would be less controversial this time, and if CI didn't even want the nomination now then you've subjected them to a very public discussion of their merits to no purpose and possibly without them even being aware of it. Please take more care in future.

In my post of withdrawing the nomination, I forgot to add some pertinence but still feel chastised and deservedly so. The missing information is that Cygnis insignis and I exchanged emails on the topic months earlier, before my first rejected nomination. I looked at the comments then, but made a note of renominating him because at the time, the objections were based on comments of 10+ years ago relating to my disagreement with him. I did not follow recent events, in fact I very rarely follow the discussions because of being sidetracked from proofreading, and because of my tendency to jump into discussions I know very little or nothing about. I hope this adds the missing context.— Ineuw (talk) 18:57, 2 November 2021 (UTC)

@Ineuw: I understand. Everyone makes mistakes, and heaven knows I've made more than my share. I wouldn't have called you out in public on this except that this particular mistake put Cygnis in a very uncomfortable position. Had they sought the nomination themselves then dealing with any complaints and criticism from the community would have been par for the course, but the way this went down was not fair to them. Xover (talk) 22:08, 2 November 2021 (UTC)

This linked but seems prematurely transcluded, [I swear, it was the very next thing I was doing]. What are your intentions for this work? Cygnis insignis (talk) 14:12, 5 November 2021 (UTC)

@Cygnis insignis: With some caveat that I may be misrecalling, my involvement was due to a copyright discussion for Imperial Household Law (1889) and was limited to scan-backing it since I'd already had to track down the scan. I have no current plans to work on it, and if I ever do it'll be at some relatively distant point in the future. I definitely have no objection if someone else wants to work on it. Xover (talk) 14:24, 5 November 2021 (UTC)

apology

I accept your apology, thank you. I also think it appropriate not to archive this particular discussion, under the circumstances, or perhaps I should request somewhere that it be revdeleted. Cygnis insignis (talk) 17:42, 2 November 2021 (UTC)

@BD2412:, active on this, please note my request here. Whatever happens next, that discussion will be isolated, static, and one-sided. Cygnis insignis (talk) 17:46, 2 November 2021 (UTC)
I don't believe it is appropriate to delete such a discussion without a community deletion process. As unpleasant is its existence may be, it happened, and is now archived. BD2412 T 17:48, 2 November 2021 (UTC)
@Cygnis insignis: I sympathise, but I'm going to have to agree with BD here. The nom should never have happened when you had not accepted it, and was not even aware of it, but once it did it needs to be archived with the rest. To the degree it helps in any way, at least the archive will show clearly that that was what happened. You can request revdel for it, or simply removal from the archives, but I don't think any admin would do that absent a community consensus to do so (especially since this is an area usually left to the `crats); and getting community consensus would entail another very public discussion of it that I am assuming you would prefer to avoid. I'm sorry that I can provide no better advice or assistance than that. Xover (talk) 18:16, 2 November 2021 (UTC)
The crat's decision has effectively locked it, no crat is likely to overturn another's decision. And as suggested, there will be a lot of drama is getting a consensus to have it removed. Once again, I get the message. Cygnis insignis (talk) 18:50, 2 November 2021 (UTC)
Please initiate that discussion, with my consent and stating your opposition if you wish, you or @BD2412:. Cygnis insignis (talk) 12:37, 3 November 2021 (UTC)
@Cygnis insignis: I can certainly help you with this, but it is generally going to be better coming from you. In particular, the proposal needs to explain your reasons and arguments for the removal—and be specific as to whether you are looking to have it removed from the archives or actually revdelled—and while I can certainly construct some such there is no guarantee I'll be able to capture the aspects that matter to you or give them the most appropriate emphasis. Please let me know how you wish to proceed. Xover (talk) 16:03, 3 November 2021 (UTC)
@Cygnis insignis: Don't hang this on "the crat's decision". Crats were specifically asked to archive the discussion. There only "decision" to be made was whether it was appropriate to archive, or should have been left live. There is no basis in policy for making a discussion of this character disappear altogether, and I don't believe that any crat could or would have closed the matter differently. BD2412 T 16:51, 3 November 2021 (UTC)
Asked by Xover, who had arrived, threatened to block me again, then realised what was going on. Cygnis insignis (talk) 07:52, 4 November 2021 (UTC)
@Cygnis insignis: To the degree "threatened" is an apposite description for letting you know you were leaving me few other options, the "threat" was regarding your edit-warring and I reminded you of the warning again at WS:AN because you were edit-warring again. Had you simply posted to the thread with essentially "I did not know about this and I do not accept the nomination." we could have skipped that detour completely.
And while I in no way condone the behaviour that led you to get that warning, or that which made the community react the way they did to your nomination, I do think that situation was not fair to you. Whatever the merits of the criticisms, it was a public pillorying that you had not sought and was not aware of to defend yourself in.
Consequently I am willing to assist you in trying to ameliorate its consequences, to the degree you feel I have anything to contribute. But the best I can do on my own is to lay out the facts as I see them, and that may not be how you see them, so I may do more harm than good. If that is what you want then I can certainly do that; but I still believe it would be better for you to post the proposal yourself, and so I am asking for confirmation that you really want me to post such a proposal on your behalf. Xover (talk) 08:58, 4 November 2021 (UTC)
The 'public pillorying' is a condition I accept in doing what I want here—sharing things I'm reading and think interesting—,increasingly so as those who regard transcribed contributions of "dumb" and "dusty" old books as the product of drones to be subjected to processing. As you have ministered what ought to happen next thus far, how far have you got with the next part of this process. Cygnis insignis (talk) 12:21, 5 November 2021 (UTC)
@Cygnis insignis: Right now I'm waiting for a clear indication from you that you wish me to proceed (I may be a dim bulb here, but I want to be sure I've understood correctly before bringing this up). Once I am sure you want me to proceed, my plan is to post a message on WS:S explaining that a nomination was opened without your knowledge or consent, that you find the—necessarily one-sided—discussion burdensome, and therefore would like it removed from the archive. I'll post it as a discussion thread rather than in "Proposals", and I'll note that I am posting on your behalf and by your request. Xover (talk) 14:32, 5 November 2021 (UTC)

Bot user

You’re marked as a bot user now; is that correct? TE(æ)A,ea. (talk) 16:50, 11 November 2021 (UTC)

@TE(æ)A,ea.: Yeah, for once it's not just that I've forgotten to turn it off (this time it's also lazyness). :) I'm in the middle of a run of semi-automatic edits and just stopped/detoured midway to set up the scaffolding for a work discovered in the process. Xover (talk) 16:54, 11 November 2021 (UTC)

The King in Yellow

We don't yet have a scan-backed copy of The King in Yellow, a hugely influential collection of supernatural / sci-fi short stories. I located what may be a first edition and have checked it for completeness, but there is no DjVu. Could you please generate a DjVu file from this copy and upload it to Commons? It is a US publication from 1895 authored by R. W. Chambers (d. 1933), so there will be no copyright issues. I should have vacation time in a couple of weeks to work here, but I expect once it is started, there may be others eager to help with this book as well. It would have made a great PotM. --EncycloPetey (talk) 17:40, 11 November 2021 (UTC)

Addendum: There is a whole category on Commons for commons:Category:The King in Yellow. --EncycloPetey (talk) 17:49, 11 November 2021 (UTC)

@EncycloPetey: Will do. I should have it done tomorrow-ish. Xover (talk) 18:07, 11 November 2021 (UTC)
@EncycloPetey: I lied: you get it tonight. :) Index:The King in Yellow (1895).djvu. The pagelist is just a placeholder put in to do basic sanity checks on pagination, and there's something funky with the original numbering in the front matter (this may have had loose leafs rebound out of order), so you will probably want to redo it. Xover (talk) 20:29, 11 November 2021 (UTC)

@Xover: wondering what to do with wikisource links like in Urim and Thummim (Latter Day Saints) --> https://en.wikisource.org/wiki/The_Evening_and_the_Morning_Star#Jul_1833,_No_8, I went and removed them. Is that the correct way of doing? Thank you for your time. Lotje ツ (talk) 14:21, 6 December 2021 (UTC)

@Lotje: Yup. If a text is deleted here then links to it on other projects should generally be removed. It's just that we have no good way of knowing that those incoming links exist so we can't really fix those as part of the deletion itself. Also note that strictly speaking that's regulated by the policies on Wikipedia over which we have no influence, so in theory they could mandate some other way to handle it. But speaking as a Wikipedia expat on enWS I'm pretty sure nobody there would object. :) Xover (talk) 06:54, 7 December 2021 (UTC)
Thanks Xover! BTW, I like your pensive dandy..., makes me think of this File:1840s Victorian Dandy smiley Lotje ツ (talk) 12:13, 7 December 2021 (UTC)

File to fix

Not that you have any time, but the following PETscan query lists about 100 or so files tagged as needing to be fixed, but which don't necessarily give further reasons: https://petscan.wmflabs.org/?psid=20859266

It should ideally be empty, and it would be appreciated if you could consider trying to document why the files got categorised as needing repairs, at some point. ( Using the new paging tools, I was able to remove a few entries that were previously on this list.) ShakespeareFan00 (talk) 09:52, 22 December 2021 (UTC)