User talk:Xover

From Wikisource
Jump to navigation Jump to search


Big, bold red text about wikidata entities!!![edit]

The fables, all 6 or 7 hundred of them, have been indexed. So, (as suggested at the portal) I put them in the order of the index and I started to link them to wikidata via {{wdl}} because, they are a "bitch and her whelps" to find there so, one big finding and pasted on the portal and all is well, etc.

BUT!! I have big red letters within the 500 series. See Portal:Aesop's_Fables#Perry_501–584. Normally, I would just think to rethink it but this error has more entities behind it and is weird to have where it is, if it is indeed a software complaint of the usual kind.

So, 1) is that really a problem or just about that one data? 2) is it going to become a problem (if it isn't already)? 3) what can be done to collect these eh, whelps?

This is nothing like herding cats, btw....--RaboKarbakian (talk) 00:17, 21 March 2022 (UTC)Reply[reply]

@RaboKarbakian: I'm not sure why Perry 508, and only Perry 508, is throwing an error there. I see nothing obvious at The Trees Under the Protection of the Gods (Q105289012) to explain it, and if it was the total number of entities used on Portal:Aesop's Fables I would have expected lots more big bold red errors there. When I have the time I'll try to trace what {{wdl}} is doing with Q105289012 in more detail, just in case there's some weirdness that's not apparent at first glance, but so far I see no explanation for what's going on. Xover (talk) 06:11, 21 March 2022 (UTC)Reply[reply]
Xover:Not entirely unrelated, but close: Bevis and Butthead Ben and Jerry fix a scan. Much more like Ben and Jerry, I guess.--RaboKarbakian (talk) 00:10, 22 March 2022 (UTC)Reply[reply]

Xover I am sorry to bother you, but I am in need of some dialog, I think. The abuse of wdl was naive and accidental; I am not anxious to make the same mistake with {{nsl2}} (which worked very nicely for a simple %s/problem/hack/g). Through my mind have been running some different options. First, just using simple bracket links like I have been (in the 600s and 700s mostly). Second, continue with the nsl2 template. Others: a table where the QNNNNNN is shown and linked to with the row shared by the linked page name here. A Portal:Perry index where Portal:Perry index/001-099, &c. subpages exist. I am actually looking forward to some scripting, much more than wanting a specific format.... So, here is where you inject some guidance and direction, replace my naive with knowledge, or, tell me what to do and where to go if that suits.--RaboKarbakian (talk) 01:37, 8 April 2022 (UTC)Reply[reply]

Xover I had some observations about the behavior of that page and where the warning happens. Adding an edition or translation to any of the wdled items would make the warning move up, like from 420-something to 410-something. And that would happen without touching the page. That got me thinking that perhaps the or a module is grabbing "everything" and then picking from that what it wants. And that just using the base module and asking for just the links might fix that page. Maybe I am wrong, but it would explain that behavior. --RaboKarbakian (talk) 01:14, 13 April 2022 (UTC)Reply[reply]
@RaboKarbakian: On closer inspection it seems to be simply that the total number of wikidata for the entire page is tipping over a hard limit. But I still don't understand why only a single item is showing an error.
I think we're going to have to rethink the entire entire Aesop's portal for this. What are we trying to achieve with the {{wdl}} invocations there? Do we actually need to fetch data from Wikidata for most of those links? Are we just trying to document what the Q-number is for each of these? Would it make more sense to generate the entire portal from Wikidata by bot, that is, the page itself is just static wikicode and all the lookups happen offline? Xover (talk) 15:23, 24 May 2022 (UTC)Reply[reply]
Xover rethought for sure! I have been thinking about it. It shows on the link where it has reached it's limit. I watched it move as I added editions or versions to numbers lower than the "problem" number and the number would move up, meaning, occur at a lesser number.
So, my (unconfirmed) thoughts about the "why" are this: the (or a, since I am not sure which one and I myself have used more than one) module pulls in all of the properties from the data item and then delivers the requested properties. So, if the problem is at fable 14 and I add a version to fable 8, the overload moves to fable 13.
{{wdl}} is a great thing. It is wonderful for linking within articles. I just used it for Yerkes Observatory, for instance. Right now, it points to en.wiki but in a potentially very near future, it might point to a collection of articles here (it has a very famous "largest refractor telescope"). But terrible for a table like the Perry index. But, what would be good for the perry index would also be good for {{wdl}}....
If all that is needed are the links to this or other wiki, then a "simple" module might be made that gets just those inter-wiki links. This module could never be used to build a versions or translations page, for instance, like the other module(s), but would be easier on all systems because of the single purpose.
About the linked Perry index. Yes, it is a very good thing to have all of the fables with their links. I can expound more on this, but I already have somewhat. Not only is the list good, but it should be on every wiki that hosts fables (like el.s, es.s, nl.s, la.s, fr.s....) and on wiki with articles about fables (en.wiki, fr.wiki, el.wiki, etc) with the same cascading way with its links. I am certain that there are other lists of things like the fables that could stand the same thorough treatment to make it easier for the wikis to work together on.
Thanks for getting back to this.--RaboKarbakian (talk) 15:50, 24 May 2022 (UTC)Reply[reply]
@RaboKarbakian: Actually, I am a genius and everyone should bow down before me and worship my über leet coding skillz! :)
It turns out that while {{wdl}} doesn't fetch more than it needs from Wikidata, the underlying Lua library it uses does. By tweaking it to call the Wikidata access functions juuuust right, I think I've eliminated the current big red error message on this portal. We'll probably hit a similar limit at some point eventually, but this gives us some more breathing room.
So longer term we probably need a different approach for this portal in any case. Do we really need to lookup anything at all from Wikidata on that portal? Maybe the important bit is just having the Q-number alongside the link? Something like a custom template called as {{perry fable|503|Q7726564|The Cock and the Jewel}}, which just spits out a local link with the provided label (i.e. "Perry 503. The Cock and the Jewel") without ever touching Wikidata. We'd lose automatic linking to other projects when the local page doesn't exist, but performance would improve dramatically. Finding interwikis for each fable is best done from that particular fable's individual page, rather than the portal, in any case. Xover (talk) 16:56, 24 May 2022 (UTC)Reply[reply]
Lovely tweaks! This is a thank you and a warning. The warning being that I am going to put the page completely back onto wdls, so we will know what the limit is, or isn't if the index doesn't reach it. I have no problem with whatever decision is made about how the index is handled; it's just that when I was trying to find which fable I had, I was looking at en.wiki, fr.s the link that the perry number goes to -- anywhere I could find it. The same fable have different characters and, they are also reflective of changes in domestics, ie. what was a weasel in the 1600s is a cat now. Goats in Greece are sheep in England, etc. 2100 years of fables, if they were ever clear-cut, they aren't now. So, I will always vote for inter-wiki linking. I would have used it had it been available.
Thanks again! --RaboKarbakian (talk) 18:55, 24 May 2022 (UTC)Reply[reply]

Good news and bad news![edit]

Xover I have converted the portal to use only the template now. Bad news first

The bad: The limits of the new and improved {{wdl}} are (still) unknown.

The good: The index at Portal:Aesop's Fables is (still) rendering without warning and also, in seconds (where it used to take 10s of seconds!).

Such is the outcome of "our" very fine tweak....--RaboKarbakian (talk) 13:37, 25 May 2022 (UTC)Reply[reply]

@RaboKarbakian: That's awesome news! And do, please, take the credit for the improvement: it was your pointer in the direction of a too greedy Wikidata function that made me go looking for this (the mere technical change here was essentially trivial once the issue was spotted). Xover (talk) 16:33, 25 May 2022 (UTC)Reply[reply]
Xover Was bragging about the big {{wdl}} fix and a few more module improvements were wished for at WD templates.--RaboKarbakian (talk) 18:05, 29 August 2022 (UTC)Reply[reply]

broken wdlness[edit]

Xover: I am having {{wdl}} related problems. A person is removing the category for the book and making it into a shared category (which is very stupid, imo, because it will not ever be a "shared wikimedia category, the publication linking to an article -- commons is the only place for such a cat!!) As a result, links to categories that contain scans and other matter related to the book are not going to commons, but instead going to resonator. There has been instruction (where it was discussed) about which property needs which tweak, but I would rather the practice of making a "wikimedia category" for every commons category a thing of the past.

{{wdl}} is broken for abusive use of commons categories, and I am not big on fixing it to not be broken then. I consider this to be abusive, maybe I am wrong, but shared cats should be made when two or more cats are using it on wikimedia sites (plural) and not before -- well, I use that for when there is a "character"/"tale named after the character" cross over mess, to get the publications out of the mess....--RaboKarbakian (talk) 21:27, 29 September 2022 (UTC)Reply[reply]

Re: center tags and center template[edit]

See the examples below for differences:

ALICE’S ADVENTURES IN WONDERLAND


ALICE’S ADVENTURES IN WONDERLAND

ALICE’S ADVENTURES IN WONDERLAND

The three options are, from left to right: center template, center tag, and underline. The line in the original is not right below the text, but it is not as far away as the center template produces, so I use the center tag. So, yes, it is intentional. TE(æ)A,ea. (talk) 19:31, 3 July 2022 (UTC)Reply[reply]

@TE(æ)A,ea.: Hmm. Interesting. But why the block center around the already centered text? Xover (talk) 20:44, 3 July 2022 (UTC)Reply[reply]
Xover: The block is so that the rule matches the length of the text. TE(æ)A,ea. (talk) 21:02, 3 July 2022 (UTC)Reply[reply]
@TE(æ)A,ea.: Oooh, that's quite clever! But, ok, you're not actually using it for (block) centering, just to have a common container for the text and rule that gives them both a width. That makes a lot more sense. :-)
I dug into the reason for that huge vertical gap and, as suspected, it's p-wrapping that's biting us again (long-form/technical explanation available on request). Long story short, your {{c}} is getting wrapped in not just the <div> that the centering needs, but also a <p> that MediaWiki adds; and that <p> is styled by the skin to have a hard 7px bottom margin. And since the <p> is added outside of our control we can't easily suppress it or otherwise fix it "automagically". *sigh* But, knowing it's there we can semi-manually correct for it in these specific cases. I've added support for a nomargin=1 parameter to {{c}} that forces the bottom margin of contained <p> tags to zero. You can see the effect relative to the alternatives in this table:
{{c}} {{c|nomargin=1}} <center> {{u}}

ALICE’S ADVENTURES IN WONDERLAND


ALICE’S ADVENTURES IN WONDERLAND


ALICE’S ADVENTURES IN WONDERLAND

ALICE’S ADVENTURES IN WONDERLAND

Can you check that its rendering is indeed (close enough to) what you needed here? --Xover (talk) 07:57, 4 July 2022 (UTC)Reply[reply]
  • Xover: Sorry I missed you with this! Yes, nomargin=1 does the trick quite well. If you don’t mind, could you (1) replace all of the <center></center> usages in the work and (2) explain the p-wrapping problem? Thanks for solving this problem! TE(æ)A,ea. (talk) 00:36, 26 July 2022 (UTC)Reply[reply]
    @TE(æ)A,ea.: With how lame my own response time has been lately you should definitely not worry about missing stuff like this. Even more than usually I mean. :)
    Replace is done. Please do a spot check that it looks ok.
    p-wrapping is… Hmm. What we usually call the "parser" in MediaWiki, is really a whole bunch of different layers and components whose overall function is to take the wikimarkup you enter into the editing text box and transform it, ultimately, into the HTML that gets sent to the web browser for rendering as a "web page". One of the things that's done in one of the stages is to try to make sure the HTML that gets generated is well formed and won't confuse web browsers. This was first implement way way back in the early oughts, and with a rather narrow perspective. In particular, it had the base assumption that all page content must be contained within at least one block-level container (div, p, etc.) to be valid (this was before html5, and wasn't really true even then), and it had eyes primarily for Wikipedia, where a page consists of sequential paragraphs of text that should all conform to the house style, and having "automatic" paragraphs was a good thing.
    The result is that the parser uses a relatively dumb bit of code to go through the wikimarkup and wrap chunks that it thinks needs it in <p>…</p>. It's dumb in the sense that it has limited understanding of context, looking mostly on just one line, and gets easily confused. But every time we insert a blank line (technically, two consecutive newline characters) the parser will consider it a paragraph break and wrap things in p tags. Except when it doesn't. For example, if a paragraph of text begins on the same line as a <div> start tag, or ends on the same line as a </div> end tag, that paragraph will be considered to already be contained within a block-level element and not need p-wrapping.
    So the most obvious and common (for us) example of p-wrapping going wrong is templates like {{c}}. It works by taking the text its fed as an argument, and wrapping it in a <div>…</div> to which some appropriate styling is applied. For {{c|Chapter 1}} that works fine and reliably. But then you have a longer text you want to center so you enter something like {{c|First paragraph.\n\nSecond paragraph.\n\nThird paragraph.}} (\n\n stands in for two newlines, aka. a blank line, obviously). Now it all depends on how the template was written. The very most obvious way to write it is (omitting all actual formatting etc.): <div>{{{1}}</div>, which with the argument expanded becomes <div>First paragraph.\n\nSecond paragraph.\n\nThird paragraph.</div>. Woops. The first and last paragraphs are on the same line as a div tag so they are ignored, but the second paragraph isn't so it gets wrapped in p tags. Within a single template the three paragraphs now behave differently. So maybe you try working around it by manually inserting newlines before and after the first/last paragraph? Sorry bub, the parser strips leading and trailing whitespace in template arguments. So the only way to get consistent behaviour is to write the template like this: <div>\n{{{1}}\n</div>. That makes the parser treat all three paragraphs the same, wrapping all of them in a p tag. Great.
    Except, we created a gajillion templates before this issue was understood (and we're still creating more at an alarming clip), and putting those extra newlines in the template changes the output. Often it doesn't matter, but in cases like your Alice heading above you get an extra p tag that you didn't have before, and both the web browser's default stylesheet and MediaWiki's skins (e.g. Vector) have styling for paragraphs based on Wikipedia-like assumptions. The net result is that your Alice text gets wrapped in a p to which the browser applies a 7px top and bottom margin, and when you're fine tuning its distance to the following horizontal rule that really gets in the way.
    And we have a huge huge number of similar cases. They're hard to fix because our templates were slapped together by different people at different times with no real unified design behind them (some of those people had directly contradictory design approaches), and without any particular attention to this particular problem. And we have developed a habit of just using whatever template gives us the visual effect we're after, regardless of whether the particular template makes sense in that use or not. So whenever we try to fix things like this p-wrapping problem we need to go through an endless number of very very weird edge-cases to see if they break, and find some kind of strategy to replace the ones that do (nomargin for {{c}} being one such strategy). A "preventive measure" in that regard is trying to slowly move toward a more "designed" use pattern for templates; for example by using {{c/s}} and {{c/e}} and similar for blocks of content, so that we can have clean block or inline semantics for a given template (but making people use those is hard since our templates are inconsistent in this regard). Of course, since most of the community either doesn't care about technical minutia (very much understandable) or are actively offended when someone tries to tell them what they should and shouldn't do with their templates, that's a pretty slow and uphill struggle. I'm sure we'll get there one day though. :)
    In any case, despite its length the above is a very simplified explanation, but the gist is that sometimes MediaWiki adds extra p tags that can mess things up if we're not careful about how we design and use templates. --Xover (talk) 09:48, 26 July 2022 (UTC)Reply[reply]
    • Xover: Thanks for the explanation! Yeah, that “parser” seems really annoying. My lack of knowledge of Lua leads me to believe that modules could fix this problem, by treating every line (of text) in, for example, {{center}} the same way. But that seems like a lot of work, especially with the great number of templates, to fix a problem with MediaWiki. As for your quest for proper template usage, spread the message! I’m sure, one day, people will start using table formatting for tables of contents. I also had another instance, where I almost used the center tag over the template; but in that case they produced the same result, so it was a separate problem. (I was trying to add text at the end of a {{***}}, if you want to know.) The replace looks good; thank you for that, as well. TE(æ)A,ea. (talk) 17:03, 26 July 2022 (UTC)Reply[reply]
      @TE(æ)A,ea.: The output from a Lua module would still be processed by the parser, so that in itself wouldn't help. Xover (talk) 17:22, 26 July 2022 (UTC)Reply[reply]
      Xover: I was thinking that the module would wrap each new line of Lua-centered text in a div, so that the parser wouldn’t act on the second line (in your case above), just like it doesn’t act on the first and third lines. This (I think) would avoid the problem, but I don’t know either how Lua works or how it interacts with the parser, so I may be wrong. TE(æ)A,ea. (talk) 18:00, 26 July 2022 (UTC)Reply[reply]

MediaWiki:Gadget-PurgeTab.js[edit]

This no longer seems to generate a 'tab' for me. Did you or Mediawiki change something recently that affects how tabs and 'portlets' are added?

(@Inductiveload:'s Jump to file script seems to have stopped working as documented about the time the Purge tab also stopped working.)

ShakespeareFan00 (talk) 09:04, 18 August 2022 (UTC)Reply[reply]

@ShakespeareFan00: The Gadget hasn't changed, but the Desktop Improvements / Talk Pages Project dropped a release in this week's train (see the last few Tech News at the Scriptorium). That being said, I still have all the purge options as expected in the "More" dropdown menu next to the search field. What skin are you using? Does it matter whether you're logged in or not? Have you tried a different web browser? Xover (talk) 14:24, 18 August 2022 (UTC)Reply[reply]
Thanks... I solved the 'purge' option by toogling it on and off again in Prefrerences ( Yes I know classic meme/trope etc.)ShakespeareFan00 (talk) 15:36, 18 August 2022 (UTC)Reply[reply]

Please don't ... The Three Colonies of Australia[edit]

Please do not arbitrarily move works solely based on case. If that is what the author chose for using modern titling vs what was in use at another time/standard, we should be letting it stand. That has typically been the community's approach. We have always just said to add redirects. Doing that will just lead to bickering and other moves that are all essentially arbitrary and neither resolve the issue or create any benefit. Thanks. — billinghurst sDrewth 12:06, 24 August 2022 (UTC)Reply[reply]

@Billinghurst: In this particular instance the author actually used title-case for the work's title (there are self-references to it in the prose), and since I had to retransclude most of it and rejig subpages anyway I took the opportunity to correct the capitalisation too. There are redirects in place for the old capitalization so it should be essentially transparent. Xover (talk) 13:31, 24 August 2022 (UTC)Reply[reply]
We have not been slave to the title case, and that is covered in my above components about older and modern standard. There are numerous conversations about retaining the contributor's general approach and not overriding it without good reason, rather than our preference. If it is essentially transparent, it wasn't as it came up in a few places for me, and the move is essentially not required when we had redirects in place. — billinghurst sDrewth 10:56, 25 August 2022 (UTC)Reply[reply]
@Billinghurst: If something broke I'd appreciate a headsup so I know to check for that in the future. And as already mentioned, in this particular instance I was going to have to perform major surgery on the page structure in any case, and I saw no indication that the page name capitalisation had been chosen as a deliberate expression of the original contributor's preference so I took the liberty of tweaking the page name in the same mode and manner I made any number of other little tweaks that I felt would improve the text. Absent an actual complaint from (one of) the original contributor(s) that says they prefer the original page name I don't quite see why you're making such a (relatively) big deal out of it. Xover (talk) 13:59, 25 August 2022 (UTC)Reply[reply]

Grimm days for Rackham files[edit]

I have renamed all of the missing files and I would upload the (zip) file to my google drive but this browser is too old for gdrive. So, Tuesday morning (library is closed tomorrow), I can head to the library with the file and share the link here (or there at the djvu file). The replacement files can be put into a one off download for Tuesday, also, making download so much easier.

Also, I am not as good with zip as I am other archive files. So, if you wait until Tuesday, you have a choice between zip, gz, bz2, or xz. No guarantees for bzip or zip -- I just haven't made that many of those, for sure, I would not try anything fancy with them.

So, in summary: On Tuesday, should you agree, a two file download instead of legion, archived at your choice/whim, within reason.--RaboKarbakian (talk) 20:43, 4 September 2022 (UTC)Reply[reply]

Methods for interwiki transclusion?[edit]

I notice that you just recently added MediaWiki:Gadget-interwiki-transclusion.js. I've encountered a few different methods for interwiki tranclusion so far; is there anything that makes one better than another? For example, there already exists mw:Manual:$wgEnableScaryTranscluding, which seems like it would be the most preferred solution, yet there are evidently other options available. What makes the problem of interwiki transclusion so technically difficult that it has inspired such a proliferation of methods to address it? Shells-shells (talk) 07:21, 11 September 2022 (UTC)Reply[reply]

Well, in essence it is just simply not supported. Since the WMF have not implemnted support for it MediaWiki, all ways to do it are hacks that are trying to do something the platform they are operating in does not actually support. They thus all have lots of downsides and weaknesses, and as such alternate approaches tend to proliferate.
As for why it is so difficult… What happens to templates that are used on the remote wiki, but do not exist on the local wiki or has different content? What about categories? Should remote pages show up in searches? How do you reconcile different content policies? Do changes to remote pages show up in the watchlists of local users? What if the remote page is vandalised? How about if it is simply moved to a new name? What about interwiki transclusion of executable code, like a (javascript) Gadget?
None of the issues are unsolveable, but it's a relatively big problem and the need is very limited (Wikisource is the only project that really needs this). It is very unlikely that anyone will try to tackle this in any relevant timeframe. However, there is a great need (and an acknowledged need) for global Scribunto modules and templates, and possibly also Gadgets, and it is possible this will get tackled at some point And since a lot of the underlying plumbing will be the same, this may make it more likely that we get a proper solution to the kind of interwiki transclusion we need.
PS. I didn't write MediaWiki:Gadget-interwiki-transclusion.js, I just migrated it to a Gadget so we could get it out of MediaWiki:Common.js (and so people can turn it off). I plan to rewrite it eventually because the current code is pretty archaic, but that mostly for general code hygiene reasons. Xover (talk) 07:58, 11 September 2022 (UTC)Reply[reply]

Interwiki gadget[edit]

Is there any information on how to use the interwiki gadget? My reasons for using it are mundane. I want to use a single home page for the wikis I am active. Is this possible? — ineuw (talk) 00:36, 12 September 2022 (UTC)Reply[reply]

@Ineuw: You mean your user page (User:Ineuw)? No special magic needed for that: you just create a user page on meta (m:User:Ineuw) and it'll show up on all the projects where you don't have a user page. To show it on the projects where you do have an old user page, just delete the local page and the global one will show instead (most projects will let you ask for speedy deletion of your user page for this reason).
There're som gotchas with links and templates (the page is rendered on meta and the result is displayed on the other projects), but you should be able to figure that out with some trial and error (and feel free to ask for help if you get stuck). Xover (talk) 06:05, 12 September 2022 (UTC)Reply[reply]
Thumbs up, thank you. I wasn't sure if I was allowed to do this. — ineuw (talk) 02:25, 13 September 2022 (UTC)Reply[reply]

Speedy deletion[edit]

Well, yesterday I checked the list of translations and the one I marked is really pointless (since there are many other and better translations already out there), that's the reason this page (and the corresponding scan pages) should be deleted. D.H (talk) 06:03, 12 September 2022 (UTC)Reply[reply]

@D.H: Thanks for the clarification. Just wanted to check that it wasn't just you throwing your hands up in disgust at our inability to provide clear guidance in this area. :) Xover (talk) 08:43, 12 September 2022 (UTC)Reply[reply]

Re: List of Governors[edit]

I noticed this when I transcluded the page; would subst:-ing the templates get around this problem? If not, the next best option seems to be to split the list into two pages. (Also, the whole work needs a function auxTOC, which should get around this whole issue.) TE(æ)A,ea. (talk) 21:18, 12 September 2022 (UTC)Reply[reply]

@TE(æ)A,ea.: No, these templates just aren't subst'able.
BTW, keep in mind, the purpose of the dot leaders is to help guide the eye from the text on the left to the page number on the right, and primarily for short "chapter" titles (i.e. large distance). For this particular list, where the distance between the left and right column are inherently short, the dot leaders no longer serve any actual purpose. They do make the page look a little bit tidier, if a lot busier, but they no longer serve their original purpose. I, as always, recommend just getting rid of them. Xover (talk) 05:27, 13 September 2022 (UTC)Reply[reply]

Concerns about contributions from User:JoeSolo22[edit]

Checkmark This section is considered resolved, for the purposes of archiving. If you disagree, replace this template with your comment. ShakespeareFan00 (talk) 16:27, 28 September 2022 (UTC)Reply[reply]

Being: NIS 9, Spain, Armed Forces NIS 11, Sweden, Armed Forces NIS 13A, East Germany, Armed Forces

These are completely unsourced and given their nature may contain portions that would need to be redacted. ShakespeareFan00 (talk) 15:50, 28 September 2022 (UTC)Reply[reply]

Source is here: https://www.cia.gov/readingroom/collection/nis. MarkLSteadman (talk) 15:54, 28 September 2022 (UTC)Reply[reply]
Thanks.ShakespeareFan00 (talk) 15:58, 28 September 2022 (UTC)Reply[reply]
I left them a reminder about sourcing of other items they've contributed (User talk:JoeSolo22#Sources for material you have uploaded and transcribed. ShakespeareFan00 (talk) 16:13, 28 September 2022 (UTC)Reply[reply]
My bad. I'm extremely new to Wikisource and probably should have been attaching specific sources from the FOIA Reading Room.
Any still-classified information on those documents is still redacted or censored as per CIA declassification policies.
I'll attach sources ASAP, thanks for letting me know. JoeSolo22 (talk) 16:24, 28 September 2022 (UTC)Reply[reply]
@ShakespeareFan00, @MarkLSteadman, @JoeSolo22: Thanks all for being vigilant; and for sorting this out quickly. Much appreciated! Xover (talk) 18:06, 28 September 2022 (UTC)Reply[reply]

copyright discussions[edit]

I'm mostly not over here, but feel free to give me a cross-wiki ping on my talk page if you need someone who knows "how" to actually search the NUC, CCE, or VCC for you. I'm mainly doing biblio research on Wikidata these days, but absolutely don't mind taking a few minutes to look into something that's actually being discussed. Jarnsax (talk) 06:02, 30 September 2022 (UTC)Reply[reply]

@Jarnsax: That's mighty kind of you to offer. Thank you!
But since I'm greedy and tactless (and speaking to talk page stalkers as well :)), the major problem we have with WS:CV and WS:PD is often not researching actually determinable copyright status, but a very limited pool of people willing to participate and offer opinions on the undeterminable cases. We thus get mostly the same old regulars, and the occasional contributor fighting for "their" text, with by now more or less entrenched positions. Not to imply that there's anything wrong with having a particular bent on such issues (although the "preserve old junk at any cost" stance can be a little tiring when you're trying to clean up old sins), but with so few participants these positions do not obviously reflect the community as a whole and a lot of discussions become impossible to actually close. Thus, backlogs for miles (or, well, years, more aptly). So… Anyone willing to systematically look at every copyright discussion or proposed deletion to offer their opinion would be very helpful. And I know that's a very big ask, so I'm mostly mentioning it in the hopes that little by little I'll get a substantial number of people to do a little each and thus get those backlogs back on track and possible for normal people to follow without drowning (because right now those backlogs are hideous).
In any case… I saw elsewhere that you're a Wikidata person, which I don't think I'd really picked up on before. I'm interested in improving our use of and contribution to Wikidata for the bibliographic area, so if you see any issues or run across any opportunities there I'd love to hear about it. At the top of my wishlist is some sort of sane (JS) API I can use to build better tooling here. Books and person-as-author information models are fairly abstruse and hard to deal with without ubiquitous and user friendly visual tools, so I'd really like to make that as smooth and in-your-face as possible on the Wikisource side. We put such a lot of effort into bibliographic research here (not to mention all the copyright research) that it's a real shame we can't better push that back to Wikidata. Xover (talk) 04:34, 2 October 2022 (UTC)Reply[reply]
Yeah, how to actually get books working "correctly" on WikiData has quite the learning curve, and for a long time was somewhat pointless, since the tools to actually "use" it were lacking (Cite Q). There's also that actually getting you head around WD's version of the FRBR, and knowing enough about how library cataloging actually "works" to get your head around what it's telling you... a LoC LCCN can actually point at any level of the data model... for something like "Lonely Planet USA", it's at the work level, with 20 years of bi-annual editions cataloged under the same LCCN, but there are also things like collections of pamphlets bound together where each one is cataloged separately. Getting the basic identifiers pointing at the right level is not always obvious, and to actually "deconvolve" stuff you really need to get them at the right level. Merged datasets can really suck.
If you look at History of New York State, 1523–1927 (Q114083307) (which is a the work entity) and the edition and volumes, I've actually put some effort into doing that one as 'completely' as possible, with references for everything, and all the info needed to verify it's copyright status (hopefully) automagically.... which has included some tweaking of the various properties and such in WD, lol. It's a process.
FYI, I've uploaded the (de-watermarked) PDFs, and scans of the plates, for volumes 1-5 on Commons, and I'm working on volume 6. If you look at the Category over on Commons commons:Category:History of New York State, 1523–1927 (1927) and the ones for the volumes, all the data in the infobox (and the links to the volumes from the edition, and between the volumes) are being handled automatically, from WikiData... the pages just invoke c:Wikidata Infobox with no parameters.
If you look over on enwiki, at w:User:Jarnsax/citations, I have a 'catalog' of automatically generated citation templates... I'm overriding the author/editor names just because of enwiki policy, the "house style" is last, first, otherwise I'd get the "object stated as" that gives the name as stated on the title page. At w:Ulster County, New York you can see it actually used at an article, specifically in the "as elaborate as makes sense" citation style (by which I mean, the Sullivan cite is through a footnote, using the "simplified footnote" to insert a pagelink, and linking to a citation of the specific chapter about the county in the bibliography). While some of that linking is 'forced' now, because Cite Q isn't done yet, eventually these links should go to WS, and be automatically maintained.... I am not sure exactly how it will work, but for existing transcriptions the links can be 'forced' to WS.
An intended future feature for Cite Q, from what I read, is to 'automagically' update the 'title' interwiki links in citations (I'm faking this now, by adding commons as a "full work available at url" and setting it preferred... the same would work for WS for now, to transcriptions, but eventually a regular interwiki to here should take precedence and the full work entry can go away).
I'm actually 'working the crap' out of Sullivan over on enwiki right now (while digging out the plates from volume 6) to replace the many, many times it was cited via a "Holice Deb and Pam" transcription on a now dead webpage, as well adding the chapters as general references and "founding date" cites for counties, cities, and towns in New York. I hope this book can end up as an 'exemplar' for how to get this shit all flying in formation, down to pagelinks in wikipedia articles (hopefully) being automatically created down to the page number anchor in WS transcriptions... across dozens of articles. :)
And then, wash rinse and repeat a few thousand times. I do want to prioritize stuff that exists here, tho. Jarnsax (talk) 05:47, 2 October 2022 (UTC)Reply[reply]

Vaught’s Practical Character Reader Copyright[edit]

Search up Vaught’s Practical Character Reader on Wikisource. It’s date is 1902 Blahhmosh (talk) 05:04, 2 October 2022 (UTC)Reply[reply]

@Blahhmosh: I'm happy to help with the copyright question, but I'm not going to do your research for you. If it is on Wikisource somewhere it should be easy for you to link to it, rather than make me search for it. And I mentioned some factors that are essential to determine copyright status in my previous message. Xover (talk) 05:08, 2 October 2022 (UTC)Reply[reply]

Author died in 1903. The book was published in 1902. The place was in the US. Blahhmosh (talk) 05:32, 2 October 2022 (UTC)Reply[reply]

{{wdl}} and categories[edit]

You asked to be told about issues there... this came up after WD edits I made, which resulted in someone from here yelling at me about broken interwiki links. After some 'unproductive conversation', lol, eventually I figured out there is a bug in this template (actually, the module), which is widely used here. This will take a bit of explanation, and it's worth noting that I don't know Lua, so don't look at me to fix it.

{{wdl}}, which is used by {{header}}, attempts to fail down a list of possible interwikis when attempting to find a valid pagetitle to link to. One of the possibilities it considers is a Commons category.... it looks to see if one is directly linked to the WD entity. This is not a valid test... it is incomplete, and doesn't reflect the way that categories are normally linked to "articles", meaning pages in mainspace.

For categories, there should be an entity "instance of" Wikimedia category (Q4167836), that is where category interwiki links (and the "Commons category" property) live. This entity is linked to the main entity about the subject with wikidata:Property:P301 "category's main topic" and wikidata:Property:P910 "topic's main category". A similar mechanism exists for Wikimedia list article (Q13406463), and lists are linked to categories using wikidata:Property:P1753 and wikidata:Property:P1754

This way of modeling lists and categories about a subject is "ontologically correct", which WD likes. It's also essential to resolving cross- and intra-namespace conflicts, when the 'main entity' needs to be linked to a "article" and/or "list" in mainspace, and/or a category with the same pagetitle. The ability to directly link a Commons category to anything but a "Wikimedia category" was only added after much much much complaining from Commons people, and you shouldn't rely on things being linked that way, as the existence of a Gallery on Commons (collecting plates from a book, for example) will require the existence of a "Wikimedia category" entity to deconflict the pages.

{{wdl}} needs to, when looking for a pagetitle, follow "topic's main category" and look for a Commons category interwiki link there, as well. Otherwise completely valid and legitimate "cleanup" edits to WikiData, adding a category entity, will cause undetectable broken pages here. Supporting list articles (I can dig up the ids, there are "has list" and "has list of works" properties) would probably be a good idea as well, since a lot of "articles" (meaning only pages in mainspace, that are not redirects, part of Proofread Page, or something else odd) here, that are things like lists of editions, actually are IMO "list articles" and should be able to link to a matching "list article" on enwiki first, and then fail back to a "normal article" on the topic (and not break if there is only a list article for some odd reason, and so an enwiki interwiki link doesn't live on the main entity).

None of this "list article", stuff applies to Author pages or Portals, BTW.... they don't live in the main namespace, so are not "Wikimedia list articles", they are their own thing. Jarnsax (talk) 10:41, 2 October 2022 (UTC)Reply[reply]

@Jarnsax: Thanks. Questions…
What makes you say {{header}} uses {{wdl}}? It doesn't, so far as I know (I could be wrong).
Hmm. Are you saying that a edition level item should have a topic's main category (P910) pointing at an item that is a Wikimedia category (Q4167836) (or possibly Commons category (Q24574745)) and which in turn has an interwiki to commonswiki? What then is the role of Commons category (P373)?
Also, this may be problematic due to the performance issues with accessing Wikidata. Grabbing interwikis from a single item is reasonably performant; walking the dependency hierarchy for multiple items and grabbing random properties from them is slow, painful, and requires ooodles of boilerplate code (existence and sanity checks for every single level).
Then again, I am not certain linking to Commons even makes sense for what {{wdl}} is intended for. Essentially it is a way to link to English Wikipedia inside texts in a way that will flip back to Wikisource as soon as we create the relevant page. Commons categories, galleries, and other sister projects are borderline under the intent of the linking policy. Xover (talk) 12:14, 2 October 2022 (UTC)Reply[reply]
I got the impression header uses it from what things I was told my edits broke... I didn't 're-break' it to check (the person who complained had undone my edits over there) or read {{header}} until just now, and you are right, it does not depend on {{wdl}}. I actually understand lua well enough to see where the issue is in the module {{wdl}} uses.
It might be an edition item, it might be a work item, it might be volume items as well, it depends on what categories exist over on Commons, if there are multiple editions, and if they have page or plate scans... whatever level of detail of categorization is appropriate depending on what 'they have'.
There is a bot that automatically adds P373 to every entity, regardless of what it is an instance of, that has an interwiki to a Commons category, and also adds the interwiki to any entity that has P373. My impression is that it's to let other wikis pull either one, for simpler code on that end, but I could be wrong. Never bothered to go back and read the bot request.
Where I was told, finally, that the issue was {{wdl}} was on my talk page, after chasing the guy off my WD one, and I don't think there's an easy way to link to it... Portal:Aesop's Fables was the example given of it's use (though why, unsure, since I didn't edit those entities) that caused it to fail through to reasonator, and I see how it would cause that behavior if the link was on a "Wikimedia category".... but maybe it's just being misused. Jarnsax (talk) 13:27, 2 October 2022 (UTC)Reply[reply]

Jarnsax: Shouldn't you be making the shared category for d:Q114144281 and not bothering others to make it work with out a reason? The "stuff" I was working on has been tied up with this, so, please justify it with another category somewhere to share.

Also, don't worry about the bot, that property is not necessarily about shared categories. I use it to show what category the scan should be in, for instance. I "should be" or "am" in communication with the bot author already.--RaboKarbakian (talk) 17:10, 2 October 2022 (UTC)Reply[reply]

@RaboKarbakian Please don't start this again over here.... what I "should" be working on is whatever I "choose" to be working on. Right now, I'm not working on that, and have chosen to do other stuff to do first...actually, specifically to avoid breaking your shit.
I am not, as I have already told you, intending to be adding Wikimedia category entities to any books that might be, or might end up, over here. I'm not doing it, and actually started working on other stuff for a while, because you told me it broke stuff here. The specific complaint you showed up with was not due to any issue with the edits on Wikidata, despite you trying to start a revert war over "housekeeping" edits to WD that are completely valid and only unusual in that they are being linked to by this template.
That I'm "not doing it" does not mean someone else won't, or that I'm going to refrain, forever, from doing it correctly just because a template here is 'broken'. Now that Cite Q is working better, and people will hopefully start fleshing out the dataset of books, anyone not from here that looks at how WD normally does it, and does it like that, will break your pages. Any book with a Gallery on Commons will break your pages, because it will require a Wikimedia category entity to hold the Commons category link.
I'm actually under no obligation, over on WD, to try to hunt down if Wikisource is 'undetectably' linking to an entity, and going to spit out bad results when fed good data, by coming over here and searching the wiki... no other editor would have the slightest idea that you have an issue, and most would have taken you to AN after they told you to get off their page the first time and you ignored them, after you showed up out of nowhere complaining incoherently and calling them a stalker. Jarnsax (talk) 17:47, 2 October 2022 (UTC)Reply[reply]
@RaboKarbakian: Your frustration is leaking out as snide hostility. Take a few breaths, listen to some smooth jazz, have a cuppa… Then lets figure out how to fix stuff.
@Jarnsax: Please excuse RaboKarbakian. They are really invested in using Wikidata specifically for the interwiki linking functionality, and put enormous effort into it. As a consequence they tend to get a bit flustered when stuff breaks in seemingly mysterious ways.
The bottom line is that this is not a panacea. Wikidata is its own project, with its own goals, practices, and policies. That MediaWiki shows a interwiki link that goes where you want it to go does not ipso facto mean that what's been put into the Wikidata item is actually correct. And there is absolutely no guarantee that what Wikisource wants is even possible within the constraints of 1) what Wikidata is, and 2) what MediaWiki as a software platform is capable of. Jarnsax gave me some pointers in this thread that might lead to some way to make everyone happy (or they might not), or at the very least actually understand the problem so we can document the limitation and manage expectations. Xover (talk) 19:52, 2 October 2022 (UTC)Reply[reply]
Thank you for that, Xover. It's not that I have some mad attachment to the "Wikimedia category" thing, it's that stuff that uses WikiData should, logically, all work the same way, or at least be compatible with the most common way, instead of creating some undocumented special subset of items that only work "the less common way" and will be undetectably (from editing Wikidata) broken, since they are being used on pages here that are not "directly" linked to them. If not, it should be discussed and documented on Wikidata, here, and probably other places.
The categories on every language wikipedia use "Wikimedia category", they have to, otherwise they would have massive conflicts because of how many articles and categories share the same pagetitle, or translations of the same pagetitle on different language wikis. Ignoring it isn't a 'sustainable' answer, and it's not because of me. Look at something like Category:Earth (Q1458521), and imagine the inter-wiki conflict horror. People know it's done that way, and do... there is a very large population of people who are 'wikipedia people' that have been trained for the better part of a decade that it's how it's done, it's really only Commons people that put them directly on the 'main entity'.
Wikipedia, Wikispecies, Wikitravel, etc., people writing citations using Cite Q (which is designed to be 'international') to books transcribed here would randomly break your shit, and have no way to notice, and meta:WikiCite is very much a thing. That it's "an issue" is very much due to the widespread use of the template here, and it's only an issue for here AFAIK (the templates at Commons understand either way, because the people that wrote them know that directly linking categories is not normal, and someone on some random wiki might have a 'functional need' for the Wikimedia category entity). If the "fix" requires editing the pages here, instead of just the template or module, en masse, that looks like a really easy bot (or even AWB) task. I'm not trying to be a jerk, it's not like I haven't edited on and off here for a very long time, and I'm trying to get cites in articles on en that link to shit over here, and hopefully setup so that your incoming interwiki links from those cites that will just work automatically.
TBH, if I had not 'broken this' (Cite Q still isn't used much at all) then someone else would have, probably before long, and the response from someone who was not familiar with or didn't care about Wikisource, or didn't even speak English, would probably have been far less patient and productive than it taking me five minutes to see the problem once I was finally told what template to look at. It's only that I had specifically made a list of entities with hathi ids, knowing it was likely to have wikisource books that were cited on enwiki and could be linked through the template, that made me hit this so soon. Jarnsax (talk) 21:41, 2 October 2022 (UTC)Reply[reply]

Xover: Is there a reason you are using {{pbr}} on talk pages? You might consider to use the "legacy" experience for talk pages.--RaboKarbakian (talk) 17:10, 2 October 2022 (UTC)Reply[reply]

Habit, I guess, mostly? In traditional talk pages it is sometimes needed to avoid breaking stuff, so it's ingrained reflex for me even when using the nifty new reply tool. Does it cause problems on your end? Xover (talk) 19:54, 2 October 2022 (UTC)Reply[reply]

@Xover Regarding 'performance' when crawling dependency trees... one of the things I've been using "New York" to nail down as an example is tweaking properties and constraints to be able to make at least the basic info about versions and volumes able to be 'transitive' (a bad term for it) without triggering errors.... for instance, looking at History of New York State, 1523–1927 (Q114083307), the basic 'language date place and publisher' of the edition is stored as qualifiers to the "has edition" statement, and I'm not "expecting" you to trawl upward from the volumes to inherit stuff like author or copyright status from the edition or work, I'm explicitly stating it on each entity that it applies to. If we can get 'like that' (the 'documentation' doesn't go really go into that much detail yet) the way to 'do it', that should make it possible to do something like grab a meaningful list of editions from the work without having to crawl down to each one. We should also to be able to create usable a tree of "logical" divisions of the work (parts, chapters) if needed because of how stuff is transcluded here, to get linking to work, with them 'dependent from' the volume they are in. I just haven't tried it to see how well it works at that level of detail, since "New York" doesn't have stuff here to link to. Jarnsax (talk) 00:15, 3 October 2022 (UTC)Reply[reply]

@Jarnsax: Well, there's two things here.
One is that MediaWiki has a couple of hard limits on Wikidata access: total Lua runtime for a given page is 10 seconds, and then the code will get terminated, and the maximum number of Wikidata entities that can be accessed from a single page (I don't recall the number ottomh, but we hit it in lists). mw.wikibase.getEntity is ok-ish when accessing the current page's connected Wikidata item. But when you ask for a different Wikidata item by qid, performance goes into the toilet.
The other is the complexity of the code. mw.wikibase.getSiteLinks just gives us the interwikis straight up, but to do the same "manually" means fetching Commons category (P373) and category's main topic (P301); checking that they are both not nil and not the empty string; then fetching the item they refer to; and then asking for that item's interwikis. If we're going to walk the tree up to the work we're adding many more steps, and accessing percentage-wise a lot more Wikidata items. So a lot more boilerplate code, and reducing by a third the number of items we can have in a list before hitting limits.
That's not to say we can't, won't, or shouldn't do that of course. I'm just explaining why I'm not immediately jumping for joy at hearing of the ontologically correct approach.
In (SQL) databases, this kind of issue is often addressed using "views": virtual tables that combine columns from many tables into a coherent view for a specific use cases. Alternately, one builds an API in front of the data layer to abstract away the details one does not care about. I think in the area of bibliographic data we need to start thinking along those lines if we're to let Wikidata stay ontologically pure within their data model and let other projects do easy stuff (like getting interwikis, and author info) in an easy way. Hopefully that would give me a saner JavaScript API to use to make specialised GUIs for Wikisource-relevant Wikidata data. Xover (talk) 08:23, 4 October 2022 (UTC)Reply[reply]
@Jarnsax: But this is what that might look like. Does it look to you like I've understood how this is supposed to work to you? Xover (talk) 16:46, 4 October 2022 (UTC)Reply[reply]
Within my incredibly limited understanding of Lua, yes. Don't ask me to debug it, but from how I follow the 'logic' that should give you the right results. There is actually a bot that keeps interwikis and "commons category" statements in sync on specific entities, it will create one if the other doesn't exist, regardless of if it's a "Wikimedia category" or not, so if you are willing to rely on that, and allow possible temporary breakage until the bot catches up it'll reduce what you need to check for.
If you look at the data model for editions, I really don't think all the choices are the best.... an egregious example being that the data model says you don't have to set the author on an edition entity if it's the same as on the work, since if you don't set it breaks Cite Q when actually trying to cite.... well, essentially anything, since it doesn't crawl up or down either, at least not yet. You can probably take that into account, the authors of Cite Q might just say 'no' to implementing that the way the data model says now, that trying to 'inherit' stuff just isn't workable at scale for anyone.
It's also ignoring that an edition, even if it has the same author as the work, still "has" an author, so.... yeah, a little broken. I'm sure it will eventually get sorted, but I think part of that will revolve around Cite Q and the same software limits. It's easier to persuade people when you can point at reality and say "this is what actually works." I suspect that what I was calling "transitive" up there is going to have to be a thing, if people want to use WD to actually create lists.
It's rather the point of my working with this to figure out how to write entities that actually produce correct citations from the current code, even if it means saying the same thing on multiple items, and maybe doing what's just literally wrong in the 'documentation', and having those discussions... it's going to take real world experience with edge cases to figure out what actually works while still making sense, given how weird books can be.
One thing that almost certainly isn't going to change, though, is the whole "work/edition/exemplar" distinction, it's based on the FRBR, and pretty essential to 'deconvolving' things that other databases have conflated. Jarnsax (talk) 09:19, 5 October 2022 (UTC)Reply[reply]
@Xover Thinking about this, as far as 'optimization', and playing with it...
Using Portal:Aesop's Fables, comparing the existing code and the sandbox version in previews, the profiler doesn't show me any real difference other than a few 10's of kbs of Lua memory (and it tells me the entity limit is 400, FYI...I didn't know either) and the page runs in almost exactly the same time... which makes sense, since I think most of the items on that page have an interwiki, so the "extra stuff" never happens enough to matter much.
With the sandbox code, I don't see the "number" of loaded Wikibase entities "explode" (from 83 to 121) unless I actually remove the test for interwikis completely (and switching case 2 and 3 didn't really matter). This is on a page that invokes {{wdl}} 521 times, and the 80-90 number seems to be the ones that are falling through to reasonator with the existing code, and 40-ish times there is a 'category' entity to look at. The other several hundred are just finding "Commons category" instead of an interwiki, I guess.
These numbers seem to lie, unless it's "fetching" sitelinks/interwikis without actually "loading" the entity per the profiler, and being found that way doesn't count against the max # of entities loaded.
What this lead me to think is that the extra code is only going to really hurt performance at all for the specific invocations using an entity that does NOT have a valid interwiki (i.e., fails case 1), and only if there is actually a wikimedia category entity.... if you've already 'loaded the item' to look for P373, looking for P910 doesn't hurt unless you find (and need to load) it.
I'm also getting the impression, tbh, that it's going to take thousands of invocations of this on one page, or several hundred that don't find an interwiki via case 1, to break page rendering. The extra code doesn't make any difference unless case 1 falls though, also, so... I'm led to think that most pages that break this would have broken it anyhow. The module only loads once, and the template is so small that template expansion just doesn't matter, it's not like one of those tables where every line is an individual template, that recursively balloon.
I'm not saying you are wrong, and stuff won't break, but that Portal seems so far from having an issue that I can't figure out where the problem would happen. Is there a page that uses {{wdl}} some truly insane number of times you can point me at?
It seems telling that Portal is actually invoking {{wdl}}, and running the existing code, actually fetching sitelinks (or attempting to) 521 times.... loading more than 400 items would hit the limit, and it's apparently loading exactly one, and working fine.
I don't think (after really looking at and messing with it) that this will actually cause drama, other than on pages where the (the number of fails through to "Commons category") plus (the number of times it fails there and is "successful" at finding a second entity to load) is greater than 400, and even then "time" isn't going to be the failure point.
Is that really going to happen? Not trying to "dispute" that it can, it just seems to me like that would probably be an extreme edge case, unless there are some massive lists of stuff that is just on Commons...any case in which the existing code doesn't go to reasonator, it will make zero difference, and not go toward that limit of 400. If it did, the existing code wouldn't render on the Aesop's Fables portal (since it calls wdl way over 400 times). Jarnsax (talk) 04:13, 8 October 2022 (UTC)Reply[reply]
It seems like a page it would break would have to 'currently' have 400 or more links to Reasonator. Jarnsax (talk) 04:28, 8 October 2022 (UTC)Reply[reply]
@Jarnsax: I think your analysis here is correct, in the main, but I haven't had the spare cycles yet to dive into it (hence why it's still in the sandbox). The sandbox code doesn't load any extra items unless it first fails to find a regular interwiki, and then only when the main item actually has a property pointing at one of the two relevant category-type items. But what worries me is that once the commonswiki sitelinks are removed from the main item, all those {{wdl}} calls will pass the first gate; and if they are removed because they have been moved to a separate item pointed at by one of those two properties, then they will pass the second gate. At this point, every {{wdl}} call will have to fetch an extra item. And Portal:Aesop's Fables currently contains ~725 fables, it's just that not all of them are linked yet. At two entities fetched per template call, we'll fall over after less than a third of those.
In addition, the sandbox code currently doesn't walk the workeditioncopy tree, which, for some use cases, it probably ideally should. If it does that, pathological cases can end up fetching rather a lot of items from Wikidata and hitting the limit very soon.
That all being said, this is not a new problem, or one unique to categories. Hence the existence of ListeriaBot. I have on my todo list to figure out some way to handle things like the Æsop's portal, and whether a ListeriaBot-like approach can adequately serve our needs. It may not, simply because not all content or organizational elements of that portal are appropriate to represent on Wikidata. For example, the arbitrary bins (Perry 1–100) they are divided into, and the non-Perry classifications of the later listed fables that are onthology from the notoriously fuzzy humanities, not universally applied, and partly reflect local preference on Wikisource / the contributors involved.
I think we also need to seriously consider whether, given the current limitations of both Wikidata and and Mediawiki, we are simply going to have to forego Wikidata for this particular use case. We already, elsewhere, push the absolute limits of what Mediawiki is able to do in its current form, and fetching lots of Wikidata items on a single page is always going to be challenging in the current software architecture. In light of the indirection approach I now understand Wikidata prefers, in addition to our book-related use case (which means we need to deal with the workeditioncopy model), I am leaning towards concluding that this use case simply isn't possible currently.
PS. These numbers seem to lie, unless it's "fetching" sitelinks/interwikis without actually "loading" the entity per the profiler, and being found that way doesn't count against the max # of entities loaded. Yes, I have a sneaking suspicion sitelinks are somewhat magical in some way. I haven't found any docs that spell that out, but I've made similar observations in previous jousts with this problem. Xover (talk) 11:04, 8 October 2022 (UTC)Reply[reply]

Hathi and copyright[edit]

You had made a comment, when talking about the 'degree of confidence' in something, about Hathi not being 'determinative', and you're right. If it's post-1927, and they call it copyrighted, it means one of two things; they checked, and it is, or they didn't check. We have no way to tell the difference.... it just brings "maybe they checked" into question, and in the particular case the renewal might have been hard to find due to the "author" and the college name changing.

If you 'expect' it to be copyrighted, though (post-1927), and they say it isn't, you know they have actually done a copyright clearance on it.... see https://www.hathitrust.org/access_use#pd. Like they also say on that page, their "claim" that they cleared it doesn't absolve you from the responsibility of checking yourself, you should still look it up. They are "telling you" that they found evidence, and you need to find it. I've never found an instance of them being wrong, in such a case, though I'm sure they make mistakes.... like they say, you need to look it up. That's part of why I volunteered my services to do so, if needed.... the scans of the CCE are a pain in the ass if you are not familiar with them, way beyond what they would be as 'books', because of how they were issued indexes are often stuck in the middle. The VCC is far worse, while the NUC is easy. :)

The Stanford renewals, otoh, just "might" tell you where to look. They have made a point since the beginning out of telling people they are a "bad" source. Jarnsax (talk) 00:14, 4 October 2022 (UTC)Reply[reply]

At you can probably infer from wikidata:Wikidata:Property proposal/National Union Catalog ID, it's part of my "plan" to systematically look them up while going down my list of Haith IDs on Wikidata. Jarnsax (talk) 01:04, 4 October 2022 (UTC)Reply[reply]
Are y'all aware of the extraordinary work done at the Online Books Page tracking copyright for books and periodicals? You can often find a clear determination about, for instance, post-1927 renewals or the lack thereof on those pages. A little tricky to navigate, but there's a wealth of info there that can save you some searching. -Pete (talk) 05:14, 4 October 2022 (UTC)Reply[reply]
@Peteforsyth: No, I don't recall ever seeing any copyright-determination-relevant info on the (otherwise excellent) Online Books Page. Do you happen to have an example at hand?
Not that we can blindly rely on any external entity for our own determinations, of course, but reusing existing research into publication dates etc. is a definite time-saver. Xover (talk) 07:31, 4 October 2022 (UTC)Reply[reply]
I find it especially useful for periodicals. There's an overview page that lets you look up periodicals alphabetically, and also has a concise summary of some of the relevant law in the intro, and links to a couple other pages with further info. Here's an example with renewed issues and renewed contributions for the Oregonian: https://onlinebooks.library.upenn.edu/webbin/cinfo/oregonian -Pete (talk) 17:20, 4 October 2022 (UTC)Reply[reply]
@Peteforsyth: Oh wow. I had no idea that existed. Thank you! This is going to be very helpful. Xover (talk) 19:17, 4 October 2022 (UTC)Reply[reply]
@Jarnsax: HathTrust just gives me dumb year-based cutoffs; has some really crappy bibliographic data (and some very good data, lest I be misunderstood); and are not interested in corrections to either. In other words, I rely on them for pretty much nothing much more than as a slightly higher-quality version of the Internet Archive. The Stanford database is, for me, "good enough" for the straightforward cases: if you check with both title and author and don't find a renewal there, I'll accept that as sufficient searching to support a claim of {{PD-US-no renewal}} absent evidence to the contrary. Most of this stuff is "balance of probabilities" and risk assessment (to both ourselves and our reusers), especially when you get into cases where you need to know contract details between authors and publishers (or estates) to know who actually owns it and needed to make the renewal.
I think Commons (vs. us or HathiTrust) made a really smart call with c:COM:PRP and the US+country of origin policy. Those two in combination sets the bar (and expectations) to a level that will fend of most legal risk, and makes it possible to weed out all the really iffy cases without endless fights to save every little bit of content. It does get a few babies thrown out with the bathwater, but not too many; and, crucially, it makes keeping the vast majority of content much easier. Commons actually probably doesn't notice that that's the case due to sheer volume and variety of content (and chronic understaffing in every aspect of their management), but for our relatively narrow area of content it would have worked wonders. Oh well. US-only is another simplification that, in a lot of cases, makes things easier. But it does lend itself to rather interminably long discussions of the edge cases (as Pete can certainly attest to). Xover (talk) 07:50, 4 October 2022 (UTC)Reply[reply]
The main issue I see with Hathi's bibliographic data, tbh, is just the kind of standard thing, that a lot of old stuff is cataloged with data from the Library of Congress's electronic card catalog, and it has the same issue the Library of Congress does with cards that were only partly copied into the computer, as well as the card actually describing the edition the LoC has instead of the ones the various Hathi libraries have.
The Stanford database has gotten better to use over time, it used to often be really hard to find stuff if you didn't know the registration number, because searches would give you renewal claimants instead of authors. The error rate isn't 'that' bad, it's like with the other stuff, you usually find it right where you expect, if it exists. I've just seen enough instances where I was 'sure' it would have been renewed, just because the copyright would still have been valuable, and it was unfindable in Stanford until I knew the renewal number. It's been a while since I used them a lot, though.
I know that we can't do 'real' copyright clearances on stuff... it's impossible without a level of information that is far beyond anything realistic for us. We just should at least make good faith effort to look in the normal places, and I tend to be a bit OCD, lol. I actually did participate in a lot of copyright discussions over on Commons, when I was active there (years ago, now) on my old account. I agree with you about the rules, there's just also a huge amount of stuff where nobody really appears to have even tried to realistically check... 'old sins', like you called them, and there at least used to be a massive pushback to even looking in the direction of the URAA backlog, and canvassing of people from "local" wikipedias to, essentially, rant about that Commons has to care about the URAA at all if anyone tried to discuss even the most obvious cases in order to find a consensus about the 'level of evidence' for them.
I'm far less 'bothered' by a long discussion about something that is actually a debatable point (is this 'original enough'?), or something where it's not provable as a 'fact' and so opinion really matters (is this an edict?), than when people just go on and on about irrelevancies. We're supposed to be looking for and discussing evidence in order to achieve a consensus, and actually listening to what other people say, not 'litigating a position' to get the 'verdict' we want from the closing admin. Lawyers are obligated to make the best case they can for their client even if they know for a fact it's bullshit.
I also apologize for the length of the Stalin thing, whoever closes it. (sign) Jarnsax (talk) 07:11, 5 October 2022 (UTC)Reply[reply]
@Jarnsax: Closing admin is likely to be me, just because I seem to be the only one with the stubbornness and intestinal fortitude to wade through it all. But as I think I alluded to somewhere up above, the main challenge there is insufficient participation to neutrally assess consensus. We have some community members who regularly try to help out (for which I am eternally grateful, even when I vehemently disagree with their positions), but too few and, because they are a self-selected subset, tend towards entrenched positions. Having to dive into the details and being the closing admin is a rather uncomfortable position to be in, that engenders a lot of agonising over whether I have sufficiently juggled the hats correctly. Sheer volume and diversity of participation at both WS:CV and WS:PD would help immensely with that (which is why I am always recruiting when an opening presents itself).
Regarding bibliographic data I have despaired of any traditional catalogue, and especially any metacatalogue like Worldcat or, to a lesser degree, HathiTrust, achieving even the minimally acceptable level of quality. I think a "Worldcat" must be crowd-sourced and collaborative to have a hope of functioning. And my hope is that Wikidata can become the hub for that, but I despair at the lack of good tools and concerted effort for it. The community at Wikidata seems way way too fond of ingesting huge data sets and, to put it coarsely, ontological wankery, to get any traction on the bibliographic side. I so wish the Internet Archive would stop focussing all their effort on spamming links to their "properties" all over Wikimedia projects, take OpenLibrary out back and put a bullet in it, and then put their collaborative efforts with the WMF into developing the tools needed to let Wikidata kill Worldcat and VIAF. There's such a huge opportunity there, that's being wasted by focussing on selfish goals and competing for the same pool of volunteers.
And, yes, URAA seems to be as anathema at Commons as it always was. But then there's a certain set of our extended community that seem so focussed on the subjective desire to hoard "all the content" that both URAA and excluding fair use content appears like tyranny, villainy, and oppression. I think it may boil down to whether you view the projects as something we're doing for us, or something we're doing specifically to let others reuse it. Free Software (GPL) vs. Open Source (MIT/BSD), as approaches, is probably another side of that coin. I don't think those positions are reconcilable, and thus I think one side has to "win" in order to resolve it. My impression is that on Commons the anti-URAA side has really lost but are still fighting a guerrilla war that has been mostly extinguished elsewhere. And I think it would be better for everyone concerned if those last remnants were finally stamped out (the admins over there show clear signs of burnout). Xover (talk) 07:46, 5 October 2022 (UTC)Reply[reply]
I figured you would be the closer, I'm not canvassing or anything, I just rather feel sorry for whomever has to read it. I will fully admit I got frustrated with someone, and probably went a bit overboard in my explanation of just how completely off base what they were saying was, but... like I said there, w:not even wrong, the people at the USCO know more than us, so listening to them is a good idea. You might decide I became a bit of a jerk with my tone, though I suspect you will understand my annoyance.
Your comment about OpenLibrary literally made me laugh out loud, for several minutes, and I'm still chuckling. I agree wholeheartedly, it's almost impossible to try to edit (the UI is atrocious) and full of garbage data that bots added, such as entries for ISBNs for 'non-bibliographic items' associated with a book (think a store display stand that comes with enough copies to fill it, it has it's own ISBN for ordering) that are just examples of why you need a human brain in the loop, obvious is not obvious to a bot.
I fall very much on the "for others" side of the spectrum, otherwise there's really no point, it's just an endless exercise in navelgazing, with the occasional explosion of useless drama. If you are just creating your own little walled garden, that you "own", on a public wiki, eventually someone is going to show up and kick down the walls, and redecorate to make it better for other people, because that's just how wikis work. Jarnsax (talk) 09:20, 5 October 2022 (UTC)Reply[reply]
You might want to read/watch w:Talk:Edict of government#Georgia v. Public.Resource.Org Inc. and the public policy argument if you're at all vague about that. The conversation here made me look at that article, and it's not great. Hopefully it will get enough discussion that the article can become better, and it's kinda 'relevant' to copyright stuff here, at least for edicts. The vast majority of news articles and such talking about the case totally missed the point, because the context is so obscure. Jarnsax (talk) 04:10, 7 October 2022 (UTC)Reply[reply]
@Xover There is a poem from 1932 by w:Beatrice Ward, that was widely distributed on a broadside to advertise Perpetua... it was framed on the wall at a lot of 'dead-tree' printers. It's actually on a bronze plaque at the entrance to the US GPO... something about them elsewhere made me think of it.
I've always thought it expresses what the projects are "doing", what this whole thing is supposed to be about, a lot better than anything any of "us" have written.
It's File:This is a Printing Office.jpg.... and yes, Commons has the wrong copyright template (she published the poem in England), but meh, it's still PD. Jarnsax (talk) 00:33, 12 October 2022 (UTC)Reply[reply]
This is what the GPO says about it: "Warde’s benedictory words continue to ring true, because they express what we know to be the timeless importance of reproducing and transmitting the written word in our society. Setting down the written word for all to see—whether by applying ink to paper or locking it digitally via public key infrastructure—preserves it, authenticates it, and makes it official, the real thing. This act in turn makes it possible to replicate and disseminate the written word unchanged, providing a common foundation for literacy, education, commerce, the arts, and—perhaps most important of all—the conduct of government in a free society." Jarnsax (talk) 00:42, 12 October 2022 (UTC)Reply[reply]
@Jarnsax: Oooh! I'd never actually run across that before. That's pretty perfect for Wikisource, indeed.
But how do you figure it's PD? First published in the UK by an author that died in 1969 doesn't scream "PD" to me (rather it screams "URAA"). And what's the typographic copyright status of Perpetua? And the plaque isn't a two-dimensional mechanical reproduction so the limits of Bridgeman v. Corel need to be considered for the photo of the plaque. But at least the GPO logo is correctly licensed as {{PD-USGov}}. :) Xover (talk) 05:16, 12 October 2022 (UTC)Reply[reply]
@Xover I figured you would think it was really cool (I obviously do, lol), and it actually does fit here specifically really well. I'd just never thought about it in this context; it was just random historical trivia floating in my head, actually from reading a history of the GPO (that's where I grabbed the quote, which is absolutely PD, it's their history of themselves with lots of nice photos).
Typefaces themselves aren't copyrightable in the US, just as a rule. See w:Intellectual property protection of typefaces#United States. Not that it would ever really come up here.
I haven't tried to prove it's PD. I just happen to be really sure it is, because I know what it was. :) Her, and it, are actually 'famous' in printing, completely apart from this poem. See UC Press at 125 Years: This Is a Printing Office for a whole article about it and her... at the very bottom, it talks about the exact circumstances.
The typeface companies didn't really have any interest in copyrighting those broadsides, which were usually just random nonsense (the lorem ipsum of ads and title pages, for display type) chosen to show off the typeface. Nobody would ever bother to copy them. They would mail them to every printer on the planet, basically, as advertising. Perpetua was just supposed to somehow "embody democratic ideals"... it ended up on monuments and stuff, somewhat ironically in this case. Jarnsax (talk) 05:45, 12 October 2022 (UTC)Reply[reply]
It's not URAA... it was published in the UK, and we've had "bilateral relations" with them since the end of the 1800's.
w:Lanston Monotype was actually a US company (though they had a UK subsidiary, that she worked for) and sold the machines worldwide... I'm doubtful it wasn't also "published" here simultaneously, just by sending it to printers, and would have had to 'comply with the formalities', which like I said they likely didn't bother... they were ephemera and usually nonsense.
It's actually become a 'thing' for people setting up a new letterpress to print copies of it... if it's copyrighted, a lot of people have violated that copyright... including (I looked back to verify) the US Government in that 2016 history, since they printed the actual text in a PD work, and there's no 'by permission' statement or anything to warn people off.
I think it's ok. :) Jarnsax (talk) 06:46, 12 October 2022 (UTC)Reply[reply]
This is actually a catalog, and too old to have Perpetua or the poem, but it's the "kind of thing"... https://archive.org/details/monotypespecimen00lansrich/ that they didn't bother to copyright... it would have been 'new stuff' to go along with your catalog, the first page talks about updating "your loose-leaf book." Jarnsax (talk) 07:22, 12 October 2022 (UTC)Reply[reply]

Reprint copyrights (esp. TOCs)[edit]

Before I start a whole "thing" at WS:S, could you cast a wise thought over the idea of reprints? Specifically, some issues of The Criterion are PD-US since they go back to 1922 (i.e. publication over 95 years ago). However, the only copies obvious extant (save one solitary issue from volume 1) are a 1967 reprint. Obviously the preface is copyright if it's from then (presumably slightly before as TSE died in 1965, but in any case, it's not from the 20s). However, what about the TOCs, title pages and publisher's info? (see https://archive.org/details/criterion19221930002unse/page/n7/mode/2up).

Especially the TOCs give me pause. The original issues had an issue-by-issue TOC on the cover. It's not clear to me if they were then issued in volumes with complete TOCs as is common, or if the reprint added a volume-wise TOC as "new" content.

What do you think? Redact it all for safety? Do we have a guideline here? Inductiveloadtalk/contribs 16:59, 9 October 2022 (UTC)Reply[reply]

@Inductiveload: Quick reply without looking.
Only creative work is copyrightable. So a compilation of poems is creative, and copyrightable, in the selection included. Facts are not copyrightable (until you amass enough of them to hit database rights). A listing of article titles in alphabetical, chronological, or physical (observed) order is not copyrightable. Adding page numbers is not copyrightable. A toc with enough creativity in its ordering to be copyrightable would be useless. So… unless we're into stunning visual design or other graphical elements, I find it highly unlikely that anything described as a "table of contents" is copyrightable.
Publisher logos are copyrightable, though. The layout of a title page could conceivably be so, but I'm not sure I would care about that for most typical title pages (centered text of various sizes) absent obvious graphic design elements.And mere information (name of publisher etc.) is not copyrightable.
I'll try to take a closer look tomorrow, but I'd be very surprised if much more than the preface and publisher logo was an issue. Xover (talk) 18:45, 9 October 2022 (UTC)Reply[reply]
@Xover thanks! That was kind of my thought (roughly following w:Feist v. Rural) but I'd thought I'd check in. Luckily the actual article that was requested is in volume 4, and I did find that volume in the original form: Index:The Criterion - Volume 4.djvu. However, the others seem sulkily disinclined to reveal themselves in the OG form. There are only an handful of pre-1927 volumes, so redaction isn't really an issue if it comes to it, but synthesising a TOC is a bit of a faff if it's not actually required! Inductiveloadtalk/contribs 19:51, 9 October 2022 (UTC)Reply[reply]

Template:Interwiki redirect[edit]

Did you mean to leave a stray DIV tag in this? ShakespeareFan00 (talk) 17:35, 14 October 2022 (UTC)Reply[reply]

@ShakespeareFan00: No. Fixed. Thanks. Xover (talk) 17:37, 14 October 2022 (UTC)Reply[reply]

Template:Header broken[edit]

I heard that you were working on such templates, and thought you should know. See here. It seems to only effect court cases, so it may be some specific formatting. The header gets pushed to the bottom of the pages. It’s not the “Notes” line, either, see here. TE(æ)A,ea. (talk) 14:50, 15 October 2022 (UTC)Reply[reply]

@TE(æ)A,ea.: Ouch. Yes, that looks like something I broke. I'll start looking for the cause. Thanks for the headsup! Xover (talk) 14:53, 15 October 2022 (UTC)Reply[reply]
@TE(æ)A,ea.: I think I've reverted the change that caused this. Could you verify? Xover (talk) 15:19, 15 October 2022 (UTC)Reply[reply]

leftoutdent[edit]

I still have works to move to standard templates, like for Oxford Men and Their Colleges Yes check.svg Done and The Indian Biographical Dictionary (1915) and migrate so we have large numbers of pages in play here. I have just converted {{TIWW}} calling the css of {{Oxon}}. Maybe I need to point these all to a short biographical entry .css rather than having them tucked away as a subpage of one. — billinghurst sDrewth 00:33, 16 October 2022 (UTC)Reply[reply]

and works under special:prefixindex/The Catholic Encyclopedia and its makers/ Yes check.svg Done which is just a real parking lot at the minute. — billinghurst sDrewth 00:37, 16 October 2022 (UTC)Reply[reply]
and yes, the migrations of these compilation works has been so we can be more nimble and holistic; similarly why I converted my of the ... link and ... lkpl templates for these biographical works. — billinghurst sDrewth 00:41, 16 October 2022 (UTC)Reply[reply]
Probably need to project manage this somewhere and guessing somewhere in WS:Maintenance is a better space. — billinghurst sDrewth 00:54, 16 October 2022 (UTC)Reply[reply]
And I remember the article type, it was for birth marriage and deaths notices, primarily, as The Times used that style for a while. — billinghurst sDrewth 03:15, 16 October 2022 (UTC)Reply[reply]
And it is equally useful in book indices as seen at Economic Development in Denmark Before and During the World War/Index, so there will need to be some sort of replacement that can inherit and follow on. — billinghurst sDrewth 03:17, 16 October 2022 (UTC)Reply[reply]
Template:Men-at-the-Bar, Template:PDBP and Template:Men of Kent and Kentishmen now have their references removed, which should fix all existing templates — billinghurst sDrewth 03:48, 16 October 2022 (UTC)Reply[reply]
@Billinghurst: We could make a dummy template (e.g. {{biographical dictionaries style}}) that just attaches a /doc page (explaining it) and hosts a /styles.css that can be either included directly in other templates; or we could make the template itself non-dummy and spit out the TemplateStyles. Or, as mentioned, since this seems relatively widely used, we could add a "Layout 5" with these settings and then just use the dynamic layouts system for those pages. I do very little work in biographical dictionaries and such so I don't know what makes the most sense for them. Xover (talk) 07:17, 16 October 2022 (UTC)Reply[reply]

The First Men in the Moon[edit]

Don't forget to change all the links from Featured Texts, or the Versions page will get featured in January. --EncycloPetey (talk) 17:07, 16 October 2022 (UTC)Reply[reply]

Oh. *blush* D'oh! Thanks for keeping me from a rather spectacular embarrassment for new years! :) Xover (talk) 17:15, 16 October 2022 (UTC)Reply[reply]
There. I think I got all of them. Thanks again for the save! Xover (talk) 17:26, 16 October 2022 (UTC)Reply[reply]

Stripped tags.. (and other LintErrors)[edit]

https://en.wikisource.org/w/index.php?title=Special:LintErrors/stripped-tag&dir=prev&offset=1518208&exactmatch=1&namespace=104&titlecategorysearch=

I know you have some higher priority tasks on right now, but I'd reached a limit in respect of items I felt comfortable editing in relation to the remaining items here. Any chance you could take a look, and resolve these or make appropriate requests to other forums as needed?

Once these are resolved, most of the 'content' namespace Lint-Errors are 'Missing tags' which are simpler to resolve. Most of the mainspace one's I've handled so far seem to be unpaired italic syntax, typically italics stared on one line and ending on a subsequent one, (Aside: Is this something that can be fixed in a semi-automatic way, to avoid long term carpal tunnel, as it's quite repetitive? ) ShakespeareFan00 (talk) 18:37, 16 October 2022 (UTC)Reply[reply]

@ShakespeareFan00: There were just ~100 of them in that category? I fixed those, some very few of them bot-fixable (and actually left over from a previous incomplete cleanup of mine). But in the main the lint errors aren't easily susceptible to automatic fixes. Xover (talk) 20:33, 17 October 2022 (UTC)Reply[reply]
The reason there are so few of them, is that a while back I put in a very determined effort in an attempt to clear the backlog.
(In respect of 'content' namespaces.) If you wanted to proceed to fixing up LintErrors in other namespaces feel free, but I was "strongly advised" to focus on content ones.
The means the biggest backlog is now Missing tags (mostly unclosed/unpaired italics.) :) ShakespeareFan00 (talk) 22:40, 17 October 2022 (UTC)Reply[reply]
@ShakespeareFan00: Trust me, I have noticed your herculean effort at reducing this backlog. Very much appreciated! But I was surprised it was the last hundred or so you gave up on, rather than the multiple many thousand first. :)
In regards of other namespaces, so long as the lint errors do not cause actual current problems, fixing them up are going to remain a very low priority. That's both due to simply having to prioritize what we expend scarce volunteer resources on, but also because once you get into, say, User: pages or discussion archives you're probably going to need explicit community consensus for some things (not all fixes are going to be perfect replacements, "changing history" is potentially controversial, and editing within another user's user space should generally be avoided). Xover (talk) 05:52, 18 October 2022 (UTC)Reply[reply]
Well the last few were as I said ones I didn't feel comfortable editing. Typically I've ended up with a residue because :-
  1. I'm UK based, meaning that some works I didn't feel comfortable in editing because of copyright concerns (I.e it needed actual proofreading, as opposed to a semi automated technical repair.)
  2. I wasn't able to determine a logical place for the fix, or that the technical fix on a specific page, meant that an entire work needed to be re-examined (as you found).
  3. The work potentially contained translations, or character scripts my browser had issues in editing (such as RTL languages.)
  4. The work contained material of a 'sensitive' nature, and required a Wikisource expert to ensure appropriate reproduction, or transcription.
ShakespeareFan00 (talk) 07:43, 18 October 2022 (UTC)Reply[reply]

Index:Nostradamus (1961).djvu[edit]

2 missing pages? ShakespeareFan00 (talk) 16:23, 17 October 2022 (UTC)Reply[reply]

Page:Nostradamus_(1961).djvu/139[edit]

Would you mind sanity checking something, the AutoRefs part ofUser:Inductiveload/save_load_actions seems to have stopped functioning as documented. Did you change or remove something that it expects to see, when you updated parts of the Mediawiki namespace recently? ShakespeareFan00 (talk) 18:43, 17 October 2022 (UTC)Reply[reply]

@ShakespeareFan00: None of the changes I made recently should affect that, but one never knows of course. There have been recent changes to ProofreadPage and MediaWiki that could conceivably affect it though. I see you've gotten it to work by fiddling with Gadgets, so it probably wasn't anything related to those other factors. In any case, in order for me to look into it I'll need to be able to reproduce it, so you'll have to figure out which combination of Gadgets and user scripts it is that triggers the problem. Xover (talk) 20:43, 17 October 2022 (UTC)Reply[reply]
My best guess at present is that I had Match and Split tools enabled. ShakespeareFan00 (talk) 22:08, 17 October 2022 (UTC)Reply[reply]
@ShakespeareFan00: M&S tools are currently a bit buggy (they've bitrotted and haven't been updated yet), but they haven't had any changes recently, so I don't see why they would suddenly interfere with save/load actions. The only obvious candidate I can think of is the automatic header + footer script. But if you're running a lot of user scripts (like the regex toolkit, Pathoschild's templatescript, etc.) it could be any number of things. You'll need to reduce it down to a reproducible combination before we'll have a hope in heck of identifying the problem. Xover (talk) 05:57, 18 October 2022 (UTC)Reply[reply]

prose class for DIV's[edit]

<div class="prose">
...
</div>

Do we still need that construction in Mainspace given that increasingly works are using dynamic layouts, and {{pagenum}}? ShakespeareFan00 (talk) 11:06, 18 October 2022 (UTC)Reply[reply]

Usage of this in mainspace should be balanced up, so removal should be straightforward if you wanted to make a script for doing that. :)

ShakespeareFan00 (talk) 11:07, 18 October 2022 (UTC)Reply[reply]

Something broke the UI at proofread page.[edit]

See Glitch02.png.

But it seems currently to only manifest on pages that have table based markup? ShakespeareFan00 (talk) 08:39, 19 October 2022 (UTC)Reply[reply]

@ShakespeareFan00: Hmm. I think this maybe is a PRP change.
@Samwilson: See above screenshot of Page:The London Gazette 28314.pdf/106 (I just reproduced in latest Safari on macOS). I've seen, but not really registered, the same phenomenon on pages where the scan image is not the typical portrait rectangle. There's also a report at WS:S#New ProofreadPage dynamic (viewport) height in the Page namespace that may be related (may also be user error and local CSS issues). I haven't dug into it, but gut feeling is that this may be related to the new sizing / layout approach for PRP Page: editor. Xover (talk) 08:48, 19 October 2022 (UTC)Reply[reply]
@ShakespeareFan00, @Xover: That looks bad! Is it happening on other browsers? I'm not able to replicate. Is it the same with syntax highlighting on or off? Sam Wilson 08:53, 19 October 2022 (UTC)Reply[reply]
@Samwilson: I reproduce in Safari, Firefox, and Chrome (all recentish), and both logged in and logged out. I suspect screen size may be a factor. These are all on a laptop, so small vertical size (I normally have to scroll vertically a lot to navigate the editor). Xover (talk) 09:00, 19 October 2022 (UTC)Reply[reply]
I am using a Firefox Nightly build ( which is typically a few branches ahead of the main Firefox release.). Disabling/Enabling Syntax Highlighting does not change the botched UI rendering. I also disabled certain Gadgets and Scripts, to test for an interaction issue. The (IndexStyles) CSS for the Index is here : Index:The London Gazette 28314.pdf/styles.css but as that should be isolated from the UI, I am convinced it should not be affecting the UI. ShakespeareFan00 (talk) 09:09, 19 October 2022 (UTC)Reply[reply]
@Xover, @ShakespeareFan00: Is this the same bug as phab:T321344? And I'm now able to replicate it... it's weird, I was testing the other day with small screen sizes etc. but couldn't make it do it, but now it's right there. Feels like a recent change and I'd still be using cached CSS. Sam Wilson 03:10, 21 October 2022 (UTC)Reply[reply]
@Samwilson: Could be. But without really noticing noticing, I imagine I've seen this for much longer. Which is why I was connecting it with the change you made a while back that was supposed to peg the editor UI height to the image height (happened around the time of the OSD work I think). But, as mentioned, I've only vaguely noticed it, and usually when Commons was flaking out and not loading images, so there was a completely different issue that I was focussed on. The symptoms in the screenshot in T321344 certainly look like the same thing. Xover (talk) 06:09, 21 October 2022 (UTC)Reply[reply]

Script Errors - Extensive {{ts}} use may be the cause for some?[edit]

I am suspecting the issue with Lua script errors you are seeing are due to extensive use of {{ts}}, which is causing a Lua equivalent of the 'template transclusion size limit exceeded' warning/error? In respect of some of the pages the soloution is to convert the {{ts}} usage over to CSS classing defined in an Indexstyle. For Bradshaw, it may be necessary to split the work into the individual tables? ShakespeareFan00 (talk) 09:12, 19 October 2022 (UTC)Reply[reply]

@ShakespeareFan00: There are a few of those left, yes, but most of them are fixed. I'm not sure what to do about the remaining ones, because those I looked at were not good candidates for IndexStyles / CSS classes (too much variability). There are some rather extreme optimizations I can make in Lua, but they are a lot of work and have usability drawbacks, so I've not pulled the trigger yet.
However, my biggest concern right now is the use of TOC-row and friends (the dotted ones, in particular), because they bloat the output insanely. There's not much scope for further optimizing these, and little alternative so long as they insist on reproducing the darned dot leaders. I have no good ideas currently for how to approach these (oh, and these are what's currently filling the main. cats.). Xover (talk) 09:18, 19 October 2022 (UTC)Reply[reply]
Hmm.. There was a working draft (https://www.w3.org/TR/css-content-3/) for CSS to have leaders natively. So very long term the current code could be dispensed with entirely. I am personally not that attached to retaining dot leaders in TOC (but with retention of the option to reimplement them once CSS supports them in a cleaner way.), and in some more recent efforts of mine I've done the TOC as a simple table. ShakespeareFan00 (talk) 09:30, 19 October 2022 (UTC)Reply[reply]

Formatting pages using DIV in header/footer vs classing ...[edit]

Not the way I would have done this personally:- Page:Joseph Story, Commentaries on the Constitution of the United States (1st ed, 1833, vol I).djvu/522

I will fix the lint errors, but I'd like a second view on just stripping things like this out, or someone moving it to a proper ns104 class? ShakespeareFan00 (talk) 13:17, 19 October 2022 (UTC)Reply[reply]

@TE(æ)A,ea.: Was there a specific reason you used raw <div> … </div> instead of {{larger block/s}} and {{larger block/e}} there? Xover (talk) 14:10, 19 October 2022 (UTC)Reply[reply]

Index:She (1887) (shehistoryofadve1887hagg).djvu[edit]

Uploaded in good faith (because the PDF glitched out , but IA-upload decided to mis-align the text layer. Any chance of shifting it? I'll have a look and see how shifted it is. :( ShakespeareFan00 (talk) 15:28, 19 October 2022 (UTC)Reply[reply]

Page scan scan for pp. text for pp.
Page:She_(1887)_(shehistoryofadve1887hagg).djvu/16 1 4

ShakespeareFan00 (talk) 15:38, 19 October 2022 (UTC)Reply[reply]

@ShakespeareFan00: Is this still needed if WS:LAB#She is fulfilled? Xover (talk) 17:58, 19 October 2022 (UTC)Reply[reply]
The request there is related to why I uploaded a generated djvu.. Not sure why IA-upload misaligns the text layer though :( ShakespeareFan00 (talk) 18:16, 19 October 2022 (UTC)Reply[reply]
@ShakespeareFan00: If you look at the processed scan images (the _jp2.zip file), you'll see several misscanned pages (duplicate page images, where the duplicates are uncropped etc.). The IA tags these pages in its metadata, but doesn't remove them. When IA upload processes such files it adds OCR sequentially as if these were not present, and thus gets misaligned by an equal number of pages. In addition, there is a combination of bugs—DjVuLibre accepts invalid OCR input, and then chokes when trying to output that same data; combined with a similar accumulating-offset bug in MediaWiki-DeJaVu—that also shows up as offset text layer. In either case, the only fix is to regenerate the file from scans using tools that detect or avoid both bugs (which my tools do, hence why I tend to always regenerate DjVu files from source scans rather than try to repair them in place). Xover (talk) 19:12, 19 October 2022 (UTC)Reply[reply]

Obadiah Poundage Letter[edit]

Hi Xover. You left a source needed template on the Obadiah Poundage page. I don't usually edit WikiSource so I don't know how to set things up. Here is a source for the letter: [1]. There will be others if you do a Google search for "Obadiah Poundage Letter". If you could pop that onto the page in the appropriate format that would be very useful. Cheers! SilkTork (talk) 01:00, 20 October 2022 (UTC)Reply[reply]

@SilkTork: The problem is that, analogous to WP:V, we need an actual scan of the source in order to verify that the transcription is correct; and, analogous to WP:RS, we need that source to be something actually published by a publisher. The link you give is essentially "some dude on the Internet" for these purposes.
That being said, the {{no source}} tag is currently not really a pressing issue since we have about a gazillion old texts with the same problem. There's pretty much zero chance anyone will come along and delete it on that basis. On a really long time-scale it might end up there (community expectations for quality have been steadily increasing), but for the foreseeable future any actual action regarding it will be someone doing the work to find a scan and migrate it to that.
So… If you want to improve its quality / avoid the ugly maint tag / prevent it ever getting nuked by deletionist cleaner-uppers, the most effective effort would be tracking down a scan of the original publication in which it appeared. You can just stuff the link into the notes parameter of the {{header}} template. Extra credits for figuring out how to upload the scan in a suitable format (DjVu, or at a pinch PDF), creating an Index: page for it, migrating the text to Page:-namespace pages, and then transcluding those to Obadiah Poundage. But those bits require knowledge that's Wikisource-specific and even experienced Wikimedians usually need help figuring all that stuff out. The community is usually happy to help with all that—requests go on WS:S/H—if you want to go the extra mile. But the key is linking to a scan of the original publication (the London Chronicle for November 4, 1760, I take it). Xover (talk) 07:45, 20 October 2022 (UTC)Reply[reply]
@SilkTork It's in The London Chronicle, vol. 8, pp. 436–437. A scan is available here; I have added this link to the header notes. The text currently on Wikisource appears to omit large portions of the letter. Shells-shells (talk) 23:11, 21 October 2022 (UTC)Reply[reply]

Lint errors - Missing tags (ns0)[edit]

https://en.wikisource.org/wiki/Special:LintErrors/missing-end-tag?namespace=0&titlecategorysearch=&exactmatch=1

I estimate I'll run out of low hanging items I feel comfortable making repairs on in the next few days. Any chance you could give the residuals a glance? In some instance I haven't corrected because what i was seeing was an OCR dump, and it would be better to work from a scan for those works (and in many places I've added link to potential external scans to works I did corrections on)

I detailed my reasons for avoiding some pages previously. ShakespeareFan00 (talk) 19:46, 21 October 2022 (UTC)Reply[reply]

PDF links[edit]

While diff is definitely removing Fugly with a capital Fug (though TBH I did quite like seeing "this is a PDF" for links, that selector is a crime), you may still like what I have for adding "IA" and "Worldcat" icons to relevant links:

a.external[href^="https://archive.org"] {
    background: url("//upload.wikimedia.org/wikipedia/commons/thumb/1/13/Internet_Archive_7x8px.svg/7px-Internet_Archive_7x8px.svg.png") no-repeat right;
    padding-right: 10px;
}

a.external[href^="https://www.worldcat.org"],
a.external[href^="https://worldcat.org"]  {
    background: url("//upload.wikimedia.org/wikipedia/commons/thumb/7/76/Worldcat_logo_16px.png/12px-Worldcat_logo_16px.png") no-repeat right;
    padding-right: 14px;
}

phab:F35611359 for an idea of how that works out. Inductiveloadtalk/contribs 14:48, 22 October 2022 (UTC)Reply[reply]

Nifty. I wonder if there's a market for a Gadget to add those. Or possibly to teach {{esl}} about it. But I'm thinking this kind of thing is best as a hover action ala. Popups. Xover (talk) 16:10, 22 October 2022 (UTC)Reply[reply]
I actually do have a pretty shonky script for IA links which takes you to the IA-Upload tool: User:Inductiveload/IaUploadPopup. I was gently wimbling towards adding it to popups as it doesn't need to do much. More extensive IA metadata would be pretty cool, but CORS might mean a need to proxy some of the cross-domain IA API calls. Inductiveloadtalk/contribs 18:18, 22 October 2022 (UTC)Reply[reply]

Paired italics over newline..[edit]

I've found this works reasonably well with the replace fucntion added by Inductiveload's maintain.js script:-

Search string : \'\'((.)*)\n((.)*)\'\'
Replacement rule : ''$1 $3''

It's amazing how some tools become common place in a workflow that when you have to disable them you notice. :) ShakespeareFan00 (talk) 11:36, 23 October 2022 (UTC)Reply[reply]

@ShakespeareFan00: Yes, that regex should work reasonably well (modulo the false positives). PS. Those inner parenthesis are pointless; you can drop them and just use ''$1 $2'' for the replacement. \'\'(.*)\n(.*)\'\'. I'm also not sure you need to escape the single quotes there. I haven't tested in IL's tool, but in this particular context they shouldn't need to be escaped. ''(.*)\n(.*)'' Xover (talk) 11:42, 23 October 2022 (UTC)Reply[reply]

Wikisource:Administrators' noticeboard[edit]

@Xover: Hello, could you please review my page protection request on the admin noticeboard? Thanks, Matr1x-101 (talk) 21:12, 25 October 2022 (UTC)Reply[reply]

Small-caps template change may affect the page space[edit]

Hi Xover, I notice a recent change that when using small-caps on a page e.g. Page:EB1911 - Volume 24.djvu/575 (via the {{1911link}} template which uses small-caps i.e. the word "Impressment" or "see Navy") that the text no longer displays in small-caps. When transcluded though, the display is in small-caps. This may be related to your recent change to the {{Small-caps}} template. Until recently the text would always display in small-caps in the Page space. DivermanAU (talk) 05:34, 28 October 2022 (UTC)Reply[reply]

@DivermanAU: Not sure why it would display correctly when transcluded. But the lack of small-caps in Page: namespace was due to a bug in {{EB1911 footer initials}} that combined with a property of MediaWiki's style implementation to cause the small-caps styling to go missing. The problem would have occurred on any page where {{EB1911 footer initials}} was used before {{EB1911 article link}} (or any other use of {{sc}}), because MediaWiki deduplicates such style specifications (only the first use outputs the style specification, subsequent uses just refer back to the first) so when the first is broken the subsequent ones get no styling. The bug in {{EB1911 footer initials}} was that it put the formatting template (in this case {{sc}} inside the linking wikimarkup, where it is generally not permitted (inside link markup you should generally just have plain text; with some exceptions that do work). The fix was simply to wrap the entire link in {{sc}}. Xover (talk) 10:22, 28 October 2022 (UTC)Reply[reply]
Thanks for explanation and the fix! DivermanAU (talk) 19:42, 28 October 2022 (UTC)Reply[reply]

{{ref}} and {{note}}[edit]

Do these predate the Cite extension, and if so are these still needed, when most works can be converted to use ref tags anyway? ShakespeareFan00 (talk) 08:05, 2 November 2022 (UTC)Reply[reply]

@ShakespeareFan00: Well, the current implementation may predate Cite, but in general, no, they're just wrappers around the functionality like many others (including {{smallrefs}}). Whether they should still be used is a better question. While they can be converted to Cite, mostly, they have some different properties, such as being uncoupled from Cite's automatic generation of fragment identifiers. For certain situations this may be necessary or desirable (cf. the authority reference / endnote stuff, that challenges the model Cite depends on). That being said, I haven't really looked at these in detail so it may be I'm missing something and/or would have a more specific opinion if I did. Xover (talk) 09:04, 2 November 2022 (UTC)Reply[reply]
Ref / Note do effectively pre-date good <ref>/ here, not so muchc by time, but effective usability. Or maybe it is more accurate to say that the development of the mw:extension:Cite, and sustainable rollout of many extensions, was happening at similar time and at that time it was not suitable for our use. We do have a few realistic uses for it, though IMO they are few and far between. We should be using cite functionality where possible, and only use ref/note where we have a demonstrated good reason not to do so. — billinghurst sDrewth 21:46, 3 November 2022 (UTC)Reply[reply]
^---- This. Xover (talk) 07:07, 4 November 2022 (UTC)Reply[reply]

AF[edit]

Often you will find that added_lines is more effective that the new wikitext, as that is checking the + prepended lines rather than the whole presented page, especially where we are having troll behaviour. It usually gets fewer false positives. new_wikitext is most useful for where you are want to see the p+ve something in the produced page, or akin stop the removal of something on the page — billinghurst sDrewth 21:39, 3 November 2022 (UTC)Reply[reply]

Ah. Thank you! Xover (talk) 07:05, 4 November 2022 (UTC)Reply[reply]

Deprecated table attributes..[edit]

Namely bgcolor:- https://public.paws.wmcloud.org/User:ShakespeareFan00/bgcolor_ns0.txt

Any chance of doing an automated conversion along the same approach I had been doing manually? ShakespeareFan00 (talk) 14:45, 4 November 2022 (UTC)Reply[reply]

FI and FIS ignoring imgwidth=param...[edit]

There's something screwed up with {{FI}} and {{FIS}}

{{FIS|file=Fig 29A. A complete course in dressmaking, (Vol. 2).png|caption={{smaller|''Fig. 29A. In laying a pattern on the goods, place the largest pieces on first and then fit in the small pieces''}}|float=left|width=100%|imgwidth=500px}}

{{FI|file=Fig 29A. A complete course in dressmaking, (Vol. 2).png|caption={{smaller|''Fig. 29A. In laying a pattern on the goods, place the largest pieces on first and then fit in the small pieces''}}|imgwidth=500px}}

Fig 29A. A complete course in dressmaking, (Vol. 2).pngFig. 29A. In laying a pattern on the goods, place the largest pieces on first and then fit in the small pieces

Fig 29A. A complete course in dressmaking, (Vol. 2).png
Fig. 29A. In laying a pattern on the goods, place the largest pieces on first and then fit in the small pieces

In that it is expanding the image to fill the entire space, and seemingly ignoring the outright imgwidth I'm actually setting independently.

What should happen is that the container width is 100%, but the image is centered at the given img-width. with {{FI}} this reduced size image should be centred, with {{FIS}} it should be floated.

In my use case, Page:A complete course in dressmaking, (Vol. 2, Aprons and House Dresses) (IA completecoursein02cono).pdf/31 I actually need float=center, to do an FI style layout inline, which isn't currently supported other than by convoluted hacks. What float=center should be implented as is an inline way to center the image (text-align:center) possibly with the outer span being set to (display:block; width;100%) being 100% of the parent container (in the same way as I fake a blank DIV as a span in {{pbri}} ShakespeareFan00 (talk) 14:39, 5 November 2022 (UTC)Reply[reply]

Also in looking into this I found that the underlying module is making assumptions about the widths being % or px based.
CSS supports many many more units than that, and there was an effort by others here to try and move away from fixed px based layouts.
Would it be possible for you to look into updating the relevant Module so it can properly support a fuller range of CSS style units, and for {{FIS}} to have a a float=center like behaviour if it was given as a specfic template argument?
Thanks.
ShakespeareFan00 (talk) 16:44, 5 November 2022 (UTC)Reply[reply]
@ShakespeareFan00: Going by memory: imgwidth doesn't set the display width, but the size of the thumbnail to fetch from Commons. It's mainly intended for very large images so that you don't fetch ~24MB of image data and then scale it down to 200x200 pixels, not least because it makes ebook exports humongous. That's also why the unit is px: thumbnail size is always specified in pixels.
And we generally don't want to expose raw CSS in template arguments (reasoning on request), so even for display oriented parameters it is likely a hard-coded unit would be deliberate. This is orthogonal to the issue of avoid specifying things in pixels in order to make sizes adaptable. Xover (talk) 16:59, 5 November 2022 (UTC)Reply[reply]
Thank you.. So currently , em-based image container sizing isn't possible, because mediawiki doesn't work that way. (HTML needs an instrinsci size (width/height), but does allow the img element to be rescaled in a browser with CSS. Mediawiki doesn't currently have a way to permit that rescaled img behaviour)
Maybe the Module should give a gentle warning, about the issue...
Longer term it would be nice if there was a way to set em based imgwidth's for {{FIS}}, so that the kind of layouts that need centered captioned images in a run of text, can be implemented without the kind of convoluted coding some works like St Nicholas have at present.
What I think the user here was trying to do on the relevant page was set up the image region to be 25em wide (centered), within a container that spanned 100% of the parent (page) i.e trying to do an inline FI, without getting a break in the content.
I found this problem, due to the fact that I'd been using some custom CSS, to inline H3 headings at the start of certain paragraphs. Without tweaking {{FI}} to {{FIS}}, In places Mediawiki wasn't doing P wrapping in the right places, and hence the headings weren't being displayed correctly.
Can I ask you to dig a little deeper, as I think this should be strightforawd to solve, if not a little time-consuming.
ShakespeareFan00 (talk) 17:41, 5 November 2022 (UTC)Reply[reply]
@ShakespeareFan00 What are you trying to do??? At least can you add the page link please? — ineuw (talk) 19:56, 5 November 2022 (UTC) — ineuw (talk) 19:59, 5 November 2022 (UTC)Reply[reply]
As a frequent user of the FI/FIS template, I recreated your page in my sandbox, and repeated under it with my FI template layout of the same. The div width of "34em" is the read view width of my page namespace, and matches very closely the main namespace layouts 2 and 4. I don't understand what you need to float? to center? I understand that you are most interested in the magic of programming, but the end result of our work may be printed. Before you consider such complexity, print the file to see if these complex layouts don't affect it. This seems too complex for what is needed to be done. — ineuw (talk) 20:47, 5 November 2022 (UTC)Reply[reply]
@ShakespeareFan00, @Ineuw: I must be daft or something. What is it about that page that requires more than a plain image and a centred caption, or possibly a centred block? I see it uses FI, which is convenient shorthand for that, but otherwise unremarkable. What is the actual problem here? Xover (talk) 21:17, 5 November 2022 (UTC)Reply[reply]
  1. Using {{FI}} within a paragraph, causes the text following that FI to not be wrapped (as it's DIV based), which is breaking some other formatting this work uses (such as the subheadings). (I was generating subheadings using {{ph/c}} so that I could set one consistent style for them, to put this as in the original meant they are inlined.) {{FIS}} cannot be directly centered at present, so it's not possible to get an FI like (centered) behaviour inline currently.
  2. Neither Mediawiki image syntax or an HTML 5 img-tag accepts em based sizing anyway. I am thinking what the other contributor wanted here was an img that was 25em wide on the page. However to get an FI like centered behaviour, with FIS (including the caption functionality) the width has to be set-to 100% to fake a block like behavior with a SPAN. I'd originally put these images in using a specific template for the work, but other contributors decided to use FI/FIS. I also note that in places elswehere {{img float}} was used, meaning that the caption sizing is now inconsistent.
I'm going to withdraw from working on this until someone else is prepared to force ONE consistent approach, which was partly why I had setp up the CSS in IndexStyles that I had, only for other contributors to do their own thing.ShakespeareFan00 (talk) 00:00, 6 November 2022 (UTC)Reply[reply]
@ShakespeareFan00: I see no discussion among contributors on Index talk:A complete course in dressmaking, (Vol. 2, Aprons and House Dresses) (IA completecoursein02cono).pdf to outline the problem and agree on an approach. Why do you expect the approach to be consistent when no attempt at coordination has been made? If un-coordinated contributions create a problem then raise it on a suitable talk page and figure out a common approach. But be prepared for 1) explaining the problem you see so that others can understand it, and 2) the other contributors may not agree with your assessment of the severity of the problem or that any given solution is the best or necessary. You have an eye for spotting especially consistency problems, which not all contributors do, but not all consistency problems must be reconciled or at least not at any cost. Xover (talk) 05:57, 6 November 2022 (UTC)Reply[reply]
I have however, commented out the IndexStyles I set, until someone is prepared to demonstrate how it SHOULD be done.ShakespeareFan00 (talk) 00:06, 6 November 2022 (UTC)Reply[reply]
See Index:A_complete_course_in_dressmaking,_(Vol._2,_Aprons_and_House_Dresses)_(IA_completecoursein02cono).pdf/styles.cssShakespeareFan00 (talk) 00:25, 6 November 2022 (UTC)Reply[reply]
I'm also now annoyed:- Page:A_complete_course_in_dressmaking,_(Vol._1,_Introduction)_(IA_completecoursein01cono).pdf/116 I was attempting to set up ONE common style for the captioning, Why then does the one supplied to {{FI}} and the one given to a {{tl|img_float differ so radically? ShakespeareFan00 (talk) 00:57, 6 November 2022 (UTC)Reply[reply]
Enough, is enough. How do I have ONE consistent caption size? Thanks. ShakespeareFan00 (talk) 01:09, 6 November 2022 (UTC)Reply[reply]
{{FIS}} floats everywhere, provided you create a float-center snippet see the {{ts}} snippets "fll" and "flr" for float left and float right. I can help you better if you add page link to your page of concern and point out what you want/don't want. I never used the CSS feature of the index page because it didn't exist at the time I inserted many images, but George Orwell III and User:Inductiveload helped me with these issues in major ways. — ineuw (talk) 03:01, 6 November 2022 (UTC)Reply[reply]
PS: To continue, what do you mean by "consistent caption size"??? — ineuw (talk) 03:06, 6 November 2022 (UTC)Reply[reply]
@ShakespeareFan00: Have you tried .img-floatleft, .img-floatright {font-size: 94%}? Xover (talk) 06:15, 6 November 2022 (UTC)Reply[reply]
.img-floatleft, .img-floatright {font-size:83%; font-style:italic;} actually, but I'll try that on Volume 1. The aim of moving things to Index stlyes, so that I don't have to keep doing the back and forth taking in or taking out templates in cap/caption paramaters. It changes in ONE place, and ONE place only. ShakespeareFan00 (talk) 11:56, 6 November 2022 (UTC)Reply[reply]


I've had enough of going round in circles on this. Please can someone revert all my changes,and impose again with ONE style effectively imposed and DOCUMENTED. That why I can be sure I (and other contributors) are actually following something consistently. All I wanted was ONE 'image' and caption approach across the entire set of volumes. In my original proofreading I thought had actually set that up, but it seems unreasonable of me to think that other contributors would at least have the sense to ask why it was set up that way, if it wasn't directly documented.
I've already attempted to explain this twice, but having linked more than a few pages previously, perhaps I am not competent to continue because I seem to breaking more stuff than I'm actually fixing. That's why I'd like someone else to set ONE caption and image approach, using ONE template/style rule across the entire work ( and other volumes in this set of books on Dressmaking.)
  1. The text shown for the figures on A_Complete_Course_in_Dressmaking/Lesson_2/Simple_finishes_for_edges is not consistent, i.e different figures/image have different sizes for the cpations. This is also true of A_Complete_Course_in_Dressmaking/Lesson_2/Patterns. I'd had attempted to set up some CSS (currently disabled) to handle this, which I would like to use across the entire work.
  2. I had attempted in A_Complete_Course_in_Dressmaking/Lesson_1/Seams_and_their_uses to give an example to set up the {{imgfloat}} (which can be placed in the center) with a tclass (set on the caption span in img_float) so that it was consistent by applying a tclass to the caption of the (which can be centered). That approach did not work because in a number of other works {{img float}} havd DIV based captions, and I had not checked for that specfic use case.
(Aside: Mediawiki doesn't use em based sizing for image related stuff. I'd updated the documentation for {{FI}} and {{FIS}} to note that.)
However that means that it is not (currently) possible to use an em based imgwidth for {{FIS}}, which means that it gets ignored, or set internally to some nonsensical value, meaning that the width value gets used instead. As for an inline FIS which placed to mimic an FI (inline but in the center), will have it's width set to 100% (ie across the whole page), it is this value that is used to setup the size of image, leading to the overly expanded image.
At this point I am not sure how to continue, because of the various differing approaches used, this 2 volumes of this work which were nominally are a complete mess of conflicting approach. I'd rather not make this was by another attempt at fixing it. That's why I need someone else to look at the various attempted approaches, choose ONE approach ( such as {{tl|imgfloat) for example, setting up any relevant CSS as appropriate. I had tried to do this is in volume by standardizing on {{imgfloat}} in volume 1, but that didn't work because my approach in relation to how to class the caption made too many assumptions.
::@Xover:, Can you attempt to summarize from this discussion what you think the actual issues are? There's more than one thing interacting here, and I now have a headache. :( ShakespeareFan00 (talk) 08:31, 6 November 2022 (UTC)Reply[reply]
I've now in respect of Volume 1 reverted my attempts. It doesn't matter if it was the right approach or not, because it seems other contributors DO need to be DIRECTLY and EXLPICITLY told what approach to use, instead of the unreasonable expectation that they would pick up that a specfic contributor, had standardised things in a specfic way if they had encountered the same template's or approach, across many pages.(Aside:Other contributors have criticised me in the past for ignoring a standardisation 'they' had imposed on a work, even though there wasn't a style guide as such, stating that they reasonably expected me to have some common sense.) (Sigh) ShakespeareFan00 (talk) 08:52, 6 November 2022 (UTC)Reply[reply]
And after a lot of effort, I think I've got a standarisation (apart form volume 9 which someone had already completed.), I've setup the styles and page header/footers for the remaining volumes and conformed any pages already proofread. This is now hopefully fixed ( apart from Vol. 9), but I'd appreciate feedback if you find anything amiss.

Split column tables over many pages..[edit]

See Index:Algonquian Indian names of places in Northern Canada.djvu , The table in this have multiple columns across different pages.

This would be impossible to layout using mediawiki table syntax. Do we have a module that could render such tables, or is it a case of manually combining the data from 2 pages to a single one manually in Page ns? ShakespeareFan00 (talk) 00:22, 6 November 2022 (UTC)Reply[reply]

When you need a table spanning many pages, use a single table for each page. I edited two pages and transcluded them here to show you that separate tables are OK and they look continuous on the main page. (The table and FI/FIS guy). — ineuw (talk) 02:41, 6 November 2022 (UTC)Reply[reply]
@Ineuw: Just to check: you do realise this is a 6-column table that's just split vertically between recto and verso sheets, right? I ask because while the rendering here is a reasonable approximation, it is not displaying as a continuous table for me as I thought was your intent from your above comment. Xover (talk) 05:39, 6 November 2022 (UTC)Reply[reply]
ShakespeareFan00: If you want the table to be continuous (as in the original), you can use section-by-section transclusion, but that can get complicated (see here for an example of something similar). TE(æ)A,ea. (talk) 02:59, 6 November 2022 (UTC)Reply[reply]
@ShakespeareFan00: As you say, there's no actually good solution for this since either HTML table markup nor MediaWiki's wrapper for it actually supports this kind of thing. Both Ineuw and TE(æ)A,ea.'s solutions are reasonable approximations given imperfect tools. For myself, I think I would have just combined the two table halves on a single Page: page as a pragmatic compromise. The page-by-page fidelity in the Page: namespace is less important than getting a readable and coherent result to our readers. Xover (talk) 05:35, 6 November 2022 (UTC)Reply[reply]
@Xover I chose the wrong consecutive pages because the 2nd page has a paragraph spacing above the title. I will proofread two consecutive pages containing the same table later today. I have done this many times, and checked the results in the main namespace page. — ineuw (talk) 16:51, 6 November 2022 (UTC)Reply[reply]
Corrected the tables. Because of the odd and even tables, each set of two consecutive pages in the main namespace will look as in User:Ineuw/notes5.

I need to know how it's wanted to be be laid out in the main namespace? I can create two separate tables, one is the two columns appearing as a continuous page, and the other is a four column table? — ineuw (talk) 10:43, 7 November 2022 (UTC)Reply[reply]

The layout of this table is complicated by the recto/verso split.
In mainspace what is desirable is a table laid out as
{{(!}}
{{%!}}Indian Name.!!Meaning.!!Present Name.!!Lat.!!Long.!!Remarks.
{{%-}}1. Aithinetōs′ekwǎn Saka′higan{{!!}}Indian Elbow Lake{{!!}}1. Elbow Lake{{!!}}54° 50′{{!!}}100° 50′{{!!}}Ithenootosequan (David Thompson)
{{%-}}...
{{!)}}
Indian Name. Meaning. Present Name. Lat. Long. Remarks.
1. Aithinetōs′ekwǎn Saka′higan Indian Elbow Lake 1. Elbow Lake 54° 50′ 100° 50′ Ithenootosequan (David Thompson)
...
But that would need some kind of module/scripted support as HTML?mediawiki does not do it natively.

ShakespeareFan00 (talk) 11:07, 7 November 2022 (UTC)Reply[reply]

In case you are wondering {{%!}} {{%-}} were some shorthands for a starting a table-row without necessarily needing to worry about whitespace handling quirks in templates. (There are also a potential pattern to grep/match for, if a module is used to build an {{rvtable}} Module. Thanks.ShakespeareFan00 (talk) 11:07, 7 November 2022 (UTC)Reply[reply]
Thanks, this is an important addition and a reminder I must study {{%-}} further. I have come across this in the {{ts}} module listing the codes. But I may have another solution. — ineuw (talk) 23:01, 7 November 2022 (UTC)Reply[reply]
I completed the first eight alternate tables. On my 24" display it aligns accurately. see the results. I will start the rest tomorrow. Consistency was the key. However the text needs proofreading.
I also don't know what the etiquette is, but I think we should continue the discussion elsewhere unless, Xover doesn't mind? — ineuw (talk) 06:24, 9 November 2022 (UTC)Reply[reply]
@Ineuw, @ShakespeareFan00: I don't mind. Mi talk page es su talk page. :) Xover (talk) 08:48, 9 November 2022 (UTC)Reply[reply]

Img templates...[edit]

Okay deep breath everyone.

Xover, at some future date , would it be possible for someone to carefully review the various templates.modules Wikisource has for visual media handling (i.e images) in works, with a view to centralising the functionality into a single Module/Template? The goal would be to have one consistent way of doing it, that can be understood without needing to understand the quirks of each specific one as at present. ShakespeareFan00 (talk) 12:34, 6 November 2022 (UTC)Reply[reply]

@ShakespeareFan00 I clearly recall that this was done years ago, {{FIS}} was the necessary result of {{FI}}. The text surrounding FIS flows unbroken as you can see on this page and hundreds of other images, left or right. Please look at the template fields used. — ineuw (talk) 17:07, 6 November 2022 (UTC)Reply[reply]
So how do I set up an inline FI then? {{FIS}} has to be left or right. There isn't a mechanism for centering it currently. A now deleted template that existed, set this up in a somewhat hacky way by setting margins IIRC, which were substituted into FI/FIS as needed. I don't recall what it was called though.

ShakespeareFan00 (talk) 17:40, 6 November 2022 (UTC)Reply[reply]

Look at this page please. and you can change float=center — ineuw (talk) 17:47, 6 November 2022 (UTC)Reply[reply]
I also recall, a previous discussion- :: Wikisource:Scriptorium/Help/Archives/2019#Page:Tycho_brahe.djvu/111 from 2019. I seem to recall I eventually coded the suggested approach there into a subst template. ShakespeareFan00 (talk) 17:49, 6 November 2022 (UTC)Reply[reply]
I was using this: - https://en.wikisource.org/w/index.php?title=Index:A_complete_course_in_dressmaking,_(Vol._1,_Introduction)_(IA_completecoursein01cono).pdf/styles.css&oldid=12725584 on which i had been using on Volume 2 onward. ShakespeareFan00 (talk) 17:57, 6 November 2022 (UTC)Reply[reply]
I can't help that you are overthinking issues that have been resolved long ago.
Template Creation date history:
{{img float}} = 2010-08-13T11:56:40 by Inductiveload.
{{FreedImg}} = 2013-06-10T17:10:06‎ by Theornamentalist and completed by GOIII.
{{FreedImg/span}} = 2013-10-28T13:22:31‎ by Alex brollo and completed by GOIII. — ineuw (talk) 18:08, 6 November 2022 (UTC)Reply[reply]
I've now attempted to explain this all 3 times, and it's STILL NOT apparently getting through, with various other issues getting conflated. There's a deficit of understanding somewhere. It's completely pointless bashing my head against a 'wall' any further.

ShakespeareFan00 (talk) 18:29, 6 November 2022 (UTC)Reply[reply]

Apologies, I must be having a bad day. The deficit of understanding is on my part, by the way.ShakespeareFan00 (talk)

Index page template changes..[edit]

Hi.. Something changed recently which means I get a "An unexpected error was detected. Please report this error to phabricator.wikimedia.org with logs from the console." when I try to do a pagelist preview with the relevant Button in the UI.

Which logs do you need to further diagnose, and how would I obtain them? ShakespeareFan00 (talk) 19:50, 6 November 2022 (UTC)Reply[reply]

@ShakespeareFan00: On which page are you getting that error? ("all Index: pages" is one possible answer)
I'm guessing this is an error message from Soda's new visual pagelist editor, and if so it is probable that it is choking on some change I have made recently. If that's the case then it's something I need to fix and Phabricator won't be any help. Xover (talk) 20:55, 6 November 2022 (UTC)Reply[reply]
@ShakespeareFan00: I did some digging and found a workaround. It should work again now. Xover (talk) 06:52, 7 November 2022 (UTC)Reply[reply]

An Apology[edit]

I owe you an apology, I was trying to do something complicated, that required me to do a little bit more reading of the documentaion in depth. That is however no reason for me to react in the way I did elsewhere (now struck through). I hope that you can accept my views were out of frustration at my own lack of ability, and that I can continue contributing in a more positive manner. ShakespeareFan00 (talk) 20:04, 6 November 2022 (UTC)Reply[reply]

@ShakespeareFan00: Don't worry about it. We all get frustrated from time to time, and by not only noticing that that had happened but even apologising for it, you are way ahead of most people on this site (myself included). But do let me tack on an unsolicited piece of advice: when you start getting that frustrated it is usually better to drop whatever the issue is, step back for an hour or a day, and then come back to it when you've regained your equilibrium. Nothing here is important enough to subject oneself to frustration and aggravation. If you are able to pursue an intractable problem without excessive frustration then great, otherwise it's usually better to go find some activity that does not cause you such grief. Contributing here is supposed to be fun, remember? :) Xover (talk) 20:52, 6 November 2022 (UTC)Reply[reply]

Page:The_grammar_of_English_grammars.djvu/400[edit]

A Match and split that didn't quite work out. Any chance you could split this up whilst I take a time out? I'm not working at peak effectiveness at the moment. ShakespeareFan00 (talk) 20:57, 6 November 2022 (UTC)Reply[reply]

@ShakespeareFan00: It looks like you figured this one out? Xover (talk) 06:50, 7 November 2022 (UTC)Reply[reply]
Yep. Figured this out. This isn't just a move to pagenamespace, it's a Phe-Bot assisted M&S move to page namespace :)... (not that anyone will still get that meme). ShakespeareFan00 (talk) 11:00, 7 November 2022 (UTC)Reply[reply]

Index:Alexander and Dindimus (Skeat 1878).djvu[edit]

I've done a match and split in good faith. But I have concerns the page scans are a little poor in places. Do you know of any better scans? ShakespeareFan00 (talk) 19:13, 7 November 2022 (UTC)Reply[reply]

Also - Page:Alexander and Dindimus (Skeat 1878).djvu/45 Looks nice in all layouts except Layout 1, where it's was unreadable. I've gone back to the pre split version in ns0, until someone else can suggest a layout that's stable. (Sigh) :(

ShakespeareFan00 (talk) 20:13, 7 November 2022 (UTC)Reply[reply]

@ShakespeareFan00: Have you tried moving the {{sidenotes begin}} to the header? Xover (talk) 21:08, 7 November 2022 (UTC)Reply[reply]
Yes I've tried that. It's still looks unreadable in Layout 1. I can set a default layout 2 for this, but I still have concerns that there should be cleaner way to handle this. It displays fine in page ns.
https://en.wikisource.org/w/index.php?title=Alexander_and_Dindimus/Text&oldid=12729274 if you want to test.
It's a convoluted as it is, because of the split-language on the page issue. the pages tag doesn't have an includesection portion only an onlysection, which means I have to set up for 45 or so pages manually :( sigh... ShakespeareFan00 (talk) 21:25, 7 November 2022 (UTC)Reply[reply]
@ShakespeareFan00: Setting a default layout is exactly to be able to specify that this text needs this layout to function well. That it would also be nice to figure out what's going on with the sidenotes on that page in Layout 1 is a different matter. Xover (talk) 06:34, 8 November 2022 (UTC)Reply[reply]

Modularise {{img float}} and merge with FI/FIS etc?[edit]

The problem is here.. Page:A complete course in dressmaking, (Vol. 4, Blouses) (IA completecoursein04cono).pdf/16 It would be nice to have the same file=missing behaviour that you added to {{FI}}.

I'm using img float here rather than {{FIS}} because {{FIS}} has to in it's current implementation be either left or right. It doesn't have the img-center fakery that {{img float}} does, due to different coding.

Of course the other solution is for the relevant module supporting {{FIS}} to be updated to permit a float=center style behaviour. ShakespeareFan00 (talk) 20:18, 8 November 2022 (UTC)Reply[reply]

I just added "float:center;" as "flc" to the shortcuts. — ineuw (talk) 22:05, 9 November 2022 (UTC)Reply[reply]
Where was this added, sorry? float:center doesn't exist in CSS. That's why has the additional class to do it. ShakespeareFan00 (talk) 22:29, 9 November 2022 (UTC)Reply[reply]
My mistake, I will change it to "fln" "float:none;" is what you might be looking for. — ineuw (talk) 20:11, 10 November 2022 (UTC)Reply[reply]

Missing FS/FSI codes[edit]

@Xover Are we working with two separate code lists for 'ts'? What happened to the old 'ts' codes??? Your list contains only 42 codes and the old one had 142. You dropped codes which are used with 100's of my images. Is it the number of codes? or the layout style? I would like to include all codes in one table, organized alphabetically. — ineuw (talk) 20:23, 10 November 2022 (UTC)Reply[reply]

@Ineuw: What list are you referring to? Xover (talk) 21:01, 10 November 2022 (UTC)Reply[reply]
I think it's the list of short codes in {{ts}} (which was modularised), or it could be {{span tag}}, {{p}}, {{heading}} etc.
Was something in another template specfically referencing part of the old version of {{ts}}?
An example page is needed to help figure out WHAT isn't as expected. ShakespeareFan00 (talk) 21:20, 10 November 2022 (UTC)Reply[reply]
Also {{Table style/parse}} should probably be marked as deprecated as the current implementation of {{ts}} uses Module:Table style/data

instead. ShakespeareFan00 (talk) 21:27, 10 November 2022 (UTC)Reply[reply]

There are less separate codes listed in the module version because it aliases. - I've implemented 'fic' for freedimg-center. The code is tweaked a little bit from {{img-float}} - See the bottom of my user page- User:ShakespeareFan00 :) ShakespeareFan00 (talk) 21:58, 10 November 2022 (UTC)Reply[reply]
I don't care where the codes come from, and what form they are code formatted. There are many codes that are in use and do not exist on Xover's list. Perhaps you want convert them? In any case, you can't archive unless you re-create and redirect the codes. — ineuw (talk) 23:57, 10 November 2022 (UTC)Reply[reply]
Okay let's slow right down..
  • Firstly WHAT template are we ACTAULLY talking about?
  • Are you SURE you haven't got {{ts}} confused with one of the others, or with writing CSS styles directly inline?
  • What codes do you say are in use, but not present in the lists for the SPECFIC template you are actually using? ShakespeareFan00 (talk) 00:18, 11 November 2022 (UTC)Reply[reply]
As far as I can determine ALL the codes/alias in the original {{ts}} got migrated to the module version.ShakespeareFan00 (talk) 00:20, 11 November 2022 (UTC)Reply[reply]
I pasted my copy which was copied last may. User:Ineuw/notes7 — ineuw (talk) 02:29, 11 November 2022 (UTC)Reply[reply]
@Ineuw: Well, I certainly didn't change any codes in a list on your computer! :)
In other words, you need to take a couple of steps back and add explanations so the rest of us can follow you. When you refer to "Xover's list", where on-wiki can I find that? In what context (which wikipage) are you trying to use a code that no longer works? And how are you using that code? In the section heading here you refer to, I think, {{FreedImg}} and {{FreedImg/span}}; but in your message you refer to {{table style}}. If you are trying to use a code with one of these templates that is not working, you need to specify which template and which code. Xover (talk) 06:40, 11 November 2022 (UTC)Reply[reply]
I am referring to this list. In this list, there exist a float:left and float:right. The copy on my computer came from an earlier layout of that page. What I called "Xover's table" is the Module:Table style/data. This is my first encounter with a Module and I missed it. Are they related? how is a new code added to the module? — ineuw (talk) 08:27, 11 November 2022 (UTC)Reply[reply]
Some template code on Wikisource, was moved to being written in Lua (Module: namespace), because it was easy to make it easier to maintain, and to improve performance. Table style which is widely used was one of these templates.
The coding in the module is JSON like.
The coding for fll for example is as follows:
  ['fll'] = {
    style = 'float:left;',
    aliases = {'float left'}
  },
The first line is the short code, such as the al, ar, fll, flr etc...
The second line is the actual CSS. This can be of any length, but must be valid 'sanitised' CSS.
The third line is the aliases, that is the other codes that can be used for same styling.
My added implementation to float an image to the center is:-
  ['fic'] = {
    style ='display:table; margin:0 auto;text-align:center;max-width: 100%;height: auto',
    aliases = {}
  },
To add a code, you add the three line with the relevant parameters.
ShakespeareFan00 (talk) 09:25, 11 November 2022 (UTC)Reply[reply]
@ShakespeareFan00: Your "fic" code is outside the scope of {{ts}}. For one thing it makes no sense to set display:table on a table element (which is what {{ts}} is for). For another it is trying to do too many things, and a mechanism like {{ts}} should only be used for one or two style rules to be manageable.
I suspect you're adding this one in order to use {{ts}} outside a table, which is not a supported use case, a bad idea, and will need to be migrated at some point. I would strongly urge you to not use this approach to solve the problem you're trying to solve. We may not have a quick fix for that problem, but it's probably better to wait until we do than to hack up something like this just to patch over it. Xover (talk) 15:15, 11 November 2022 (UTC)Reply[reply]
@Ineuw: The list in Template:Table style/doc is generated automatically from the actual code in the module and should always (modulo caching) reflect the actual behaviour of {{ts}}. The codes supported in the module should reflect exactly the codes that were supported by the original template, barring a few codes that have been added subsequently. If any were lost during the conversion then that is simply a bug, and I am not aware that this is the case.
The instructions for adding new codes are in the docs at Module:Table style/data. But also please heed the caution there: the data is in actual Lua code (that is, it is programming language code) so please make sure you know what you are doing before modifying it, and consider requesting assistance if you are not certain you can do so safely.
I would also generally urge constraint in adding new codes. While it is often convenient, the {{ts}} approach to formatting things is not sustainable. It exists because we have no better way to handle table formatting, specifically, and not because this is actually a good way to do it. For things other than tables we usually do have have better ways to fill a given need, even if they have not been implemented yet, and (ab)using {{ts}} or one of the templates using a similar approach is a bad idea from a technical and long-term sustainability perspective.
And as I keep reminding ShakespeareFan00, some things are just simply not sufficiently well supported (in web standards, web browsers, or MediaWiki) that we should be relying on it, even if we can find some way to hack it together such that it seems to give the desired effect right now. Dot leaders, and to a lesser degree the TOC templates in general, are a prime example that has caused us no end of grief and will continue to do so for years and decades still. Not to mention things like {{center block}} and {{block center}} (which both do the same thing, but subtly differently, so that only massive manual labour can reconcile and merge the two); or {{brace}} and {{brace2}}; {{redact}} and {{redact2}}; or…
In any case… Speaking as someone who spends an inordinate amount of time trying to reconcile and clean up this mess, I urge restraint in making changes, or adding new templates, or using a template for a purpose different than the one for which it was designed just to solve some there-and-then problem without considering its wider implications and maintainability. We're not exactly spoilt for technical contributors so we have a strictly limited capacity for maintaining such things. Xover (talk) 15:05, 11 November 2022 (UTC)Reply[reply]
Thank you.
What I was trying to do is to have {{FIS}} center an image+caption (which it can't do currently). Currently FIS set's "display: inline-block." If it instead set "display:table;margin:0 auto" on the wrapper containter for the very specfic float=center use case however (which is essentially what {{img_float}} DOES in the same use case).
See Page:A complete course in dressmaking, (Vol. 4, Blouses) (IA completecoursein04cono).pdf/24 for an example of the type of image+caption inside a paragrpah run that I am talking about.
I agree with you that HTML/CSS doesn't necessarily provide a long-term fix for this yet.
ShakespeareFan00 (talk) 16:36, 11 November 2022 (UTC)Reply[reply]
@ShakespeareFan00: What I'm having trouble understanding is why this image needs to be inline? Xover (talk) 16:39, 11 November 2022 (UTC)Reply[reply]
Because, if it isn't and I put {{FI}} instead, it breaks the paragraph, which meant an intended approach I had for subheadings didn't work. I ended up abandoning the sub-headings approach entirely. The SPECFIC image can be relocated. However, I am disapointed that there seems to be a resistance to an easy fix, for something that would make FIS and img-float behave with similar functionality, which would be beneficial longer term .... (Sigh)ShakespeareFan00 (talk) 16:44, 11 November 2022 (UTC)Reply[reply]
@ShakespeareFan00: I am absolutely willing to listen and to be persuaded otherwise. But to me it currently looks like you're trying to use the inline version of FI as if it were the block version, instead of just using the block version directly. Shoehorning a block-oriented template into working as an inline-oriented template, and vice-versa, does not generally seem like a good idea. Xover (talk) 16:48, 11 November 2022 (UTC)Reply[reply]
I can understand your technical objections, and in respect of SPECFIC images in the linked SPECFIC work, most of the images can be relocated to not being within paragaph runs.
As I've explained before REPEATEDLY, {{FI}} uses a DIV, {{FIS}} uses a SPAN. There isn't a way to get an image that displays like {{FI}} does (i.e float=center) using {{FIS}} currently. {{FI}} cannot be used inline, because DIV in P is badly formed HTML. That's now 4 TIMES I've explained it, and it gets more and more tiresome every time. :(
Do I actually have to BREAK some (sandboxed) pages personally, trying to get a float=center behaviour, before someone else implements what should be a relatively straightforward (it isn't trival though) set of if statements in the relevant Module? (namely a test for a FIS vs FI usage, and args["float"]="center", and change the display type used on the outer containing span from being an inline-block to being 'display:table' if it's float=center. {{FI}} being DIV based already, is already in effect float=center.
ShakespeareFan00 (talk) 17:04, 11 November 2022 (UTC)Reply[reply]
Okay so I implemented a very dirty float=center here Module:FreedImg/sandbox line 183.
I'd appreciate someone writing some testcases for the intended new functionality.ShakespeareFan00 (talk) 17:26, 11 November 2022 (UTC)Reply[reply]

┌─────────────────────────────────┘
@Xover Thanks for you message. I have no intention to add anything to the module. As long as the codes work, it's fine.

@ShakespeareFan00 There is no need to explain the issue. Perhaps what you want to do is not possible. After all there is no such a thing as a floating center, as you pointed out to me. What you are trying to achieve that may not be possible. You mention the caption is not centered? Perhaps you can show an actual printed image comparison? in this work, there are hundreds of images in center floating between columns. AFAIK we cannot do this. — ineuw (talk) 20:30, 11 November 2022 (UTC)Reply[reply]

@ShakespeareFan00: My apologies. As mentioned IRL is being a bit recalcitrant just now so I am having trouble keeping up and am not able to spare a lot of brain-cycles for wiki-stuff. You have indeed explained several times, it's just that I haven't been able to understand it yet.
But… The point I am failing to get is why you need to use FIS as if it was a block-based template. None of the examples I've seen appear to require that. Page:A complete course in dressmaking, (Vol. 4, Blouses) (IA completecoursein04cono).pdf/23 for example, works perfectly fine with FI. Ditto for Page:A complete course in dressmaking, (Vol. 4, Blouses) (IA completecoursein04cono).pdf/24.
I perfectly well understand that block elements cannot be used inside inline elements, and that a div cannot appear inside a p element. But I don't see how this applies in any of the examples I've so far seen. And, in fact, that very issue makes FI and other block-based templates preferable to span-based ones: they can contain both, where the span-based ones can only contain other inline elements.
Is the need driven by something that is visually broken? Is it a lint error you're seeing? Is it breaking when used inside another template? When another template is used inside it?
I am truly sorry if I am being dense, but I just haven't been able to grasp what problem we are trying to solve. Xover (talk) 20:18, 11 November 2022 (UTC)Reply[reply]
See the code I added to the sandbox version of the Module. I also put some test cases..
What I wanted was a version of FIS that did float=center. The sandbox version of FIS now does that.
This wasn't about flowing text on either side (which is indeed NOT possible in simple HTML/CSS). It was always about an image centred in the page with blank space either side, without needing to worry about re-locating the image outside of where a paragraph was to cope with where mediawiki put P tags.
I'm too tired to go into any more depth on it right now.. but as nothing visually broke in terms of relocating images, that's the pragamatic way to move forward.
I'd still appreciate someone looking at the sandbox code. ShakespeareFan00 (talk) 22:10, 11 November 2022 (UTC)Reply[reply]
As an aside, The FI/FIS module probably should throw an error if a non-sensical float value is used.?
ShakespeareFan00 (talk) 22:13, 11 November 2022 (UTC)Reply[reply]
Errors: yes, most of our templates should ideally give visible errors when given detectably non-sensical input, but in the general case it'd be a lot of boilerplate code (harder to maintain and prone to both false positives and false negatives etc.) for relatively little practical benefit. It's possible we can find a somewhat sane way to do it for our Lua code long term (I have some ideas), but I don't think it'll percolate to the top of the priority list any time soon. Xover (talk) 23:18, 11 November 2022 (UTC)Reply[reply]

two scans[edit]

  1. The first is at Hathi. It is https://babel.hathitrust.org/cgi/pt?id=mdp.39015071565991 (The Road to Wellville). They included a 1904 version of this in boxes of Grape-Nuts and, I think it should be here. So, I am uncertain if you have access to Hathi or not. If you do have access and are willing to download/upload, then great. If either of those conditions are not met, I can take it to the Scan Lab.
  2. I downloaded a pdf from somewhere in Deutchland and uploaded it here and it is not acting like a pdf. The site has a download of tiff of the scan. Perhaps you could sent it through the Djvu machine? The book is goregeous, really. The files live at https://digital.staatsbibliothek-berlin.de/werkansicht?PPN=PPN780028635&PHYSID=PHYS_0007&DMDID= Same conditions, if both are not met, I can take it to scan lab. Oh, the broken pdf is at File:Grammar Japanese Ornament-PPN780028635.pdf

Further, I am not alone proofing these, if this is a matter. Also, I hope all is well with you.--RaboKarbakian (talk) 16:15, 19 November 2022 (UTC)Reply[reply]

@RaboKarbakian: File:A Grammar of Japanese Ornament and Design (1880).djvu (minimal checking, so caveat emptor).
I'm afraid I have no special HathiTrust access. If it's geolocked for you it'll be geolocked for me too. Xover (talk) 22:07, 19 November 2022 (UTC)Reply[reply]
Xover: Index:A Grammar of Japanese Ornament and Design (1880).djvu <--Looks great! Thank you! Hathitrust is not geolocked, but as a guest, I can only download certain things. I am considering downloading it page by page and getting rid of the watermarks. It could be done by tomorrow, but to upload, it would be Monday. I am thinking it will be worth that extra work for the watermarkless pages. Maybe I will be dropping by with a link to a pack of pages on Monday? Thanks again!--RaboKarbakian (talk) 00:43, 20 November 2022 (UTC)Reply[reply]
@RaboKarbakian: Feel free to drop such a link. I just can't promise how quickly I'll get to it.
HathiTrust geolocks individual scans based on whether they think it is in copyright etc. So to access these you can either access them from a US IP address, or you can be logged in through one of their member institutions. Xover (talk) 09:06, 20 November 2022 (UTC)Reply[reply]
Xover https://drive.google.com/file/d/1OivWjDBM9d24jgt8Td9SzK_FObp12tmb/view?usp=share_link Access at Hathi makes download easier.--RaboKarbakian (talk) 15:16, 20 November 2022 (UTC)Reply[reply]
@RaboKarbakian: File:The Road to Wellville (1926).djvu Xover (talk) 17:19, 20 November 2022 (UTC)Reply[reply]

replicating tracker into NIE[edit]

Hi. Recently you put a tracker into {{Appletons'}}. {{NIE}} probably has a similar need. Truth be known we probably have an amount of work to do here, and I almost think that we should be spinning in an intermediary template for biographical compendiums for those listed in herebillinghurst sDrewth 03:48, 20 November 2022 (UTC)Reply[reply]

@Billinghurst: I added a similar tracking cat for NIE: Category:NIE template with Wikipedia parameter (5,014).
Work on migrating {{header}} to Lua stopped a while back due to an issue with TemplateStyles, but I think we've got that one licked and can continue. Once that is done I think we can more easily add at least coarse tracking categories for these parameters (since all the bio templates end up calling {{header}}). If we need per-work categories we'll probably need them to pass the module a prefix to use (something like |catprefix = NIE), but it should be doable. Xover (talk) 09:24, 20 November 2022 (UTC)Reply[reply]
Thanks, it is a rough brain fart at this stage, though I was thinking that having a better track of templates that leverage header, and components of header would be useful. My brain harks back to the conversations when we went to the current look of header (c. 2009), and its components, and how we have developed it since. There are things that are a little quirky maintenance category around application of formatting. As you know I have a specific interest in the biographical compendiums which have specific constructions around volumes (some as a note, some as an active link), contributors, editions, etc., as such that I think that we should consider an intermediate template build (or similar) to make something like {{NIE}} more a shell to build, and stylistically able to be modified from the intermediate (though that may be your wish from the module), and here I am thinking of {{authority/link}} <=> {{CFB link}}. [My hope with "[[{{{title}}}/{{{1}}}|{{{1}}}]]," in [[{{{title}}}]] is that at some point when we get around to having a definitive style review it becomes easy to update. [ Wishes! :-) ] — billinghurst sDrewth 22:23, 20 November 2022 (UTC)Reply[reply]
@Billinghurst: I'm not sure I understand the requirements for the biographical compendiums well enough to be able to reason out the majority of their needs (so you'll need to spoonfeed me the details). But at least {{header}} is likely to become just an #invoke of the Lua module, which means per-work wrappers can just manipulate the parameters and then #invoke the same Lua function. Not sure what we'll do with {{process header}}, {{translation header}}, etc., but I'm hoping they can just be different entry points to the same function. If there are commonalities across the different per-work wrappers it's certainly possible to make helper functions for that (possibly just like {{process header}} etc.). We could also introduce an intermediary template and/or Lua module specifically for these, but my initial assumption (which may well be wrong) is that this would only make sense if they provided an alternate interface for per-work template builders. And with my limited understanding of this area I can't immediately see what that would look like. I'd be happy to look for ways we could reduce pain points, standardise features (like tracking cats), etc. though.
Could you perhaps give a couple of examples of things that are hard or tedious to do with per-work templates today? Tracking cats for |wikipedia= (and possibly the other sister project params) I'm guessing. What else? Xover (talk) 20:08, 24 November 2022 (UTC)Reply[reply]

header update thoughts[edit]

The author field in header and the override_author are on old solution concept that maybe too simple (old?) if we are moving to a module, especially when override_author was meant to capture multiple authors, then we at sometime suborned it for disambiguated author display. We probably have the scope with module to look to author, author1, ... authorn. We maybe can get to a better solution for recording and presentation. The display label for the author and the underlying link were done that way for good reasons, but while it can be a complicating factor to explain, it may have positive benefits in a range of spaces. ESPECIALLY where we have anonymous works, or things that are corporate authors so hanging off a portal page.

We probably then have similar scope for translators, section contributors, section translators stepping onwards. — billinghurst sDrewth 23:41, 23 November 2022 (UTC)Reply[reply]

@Billinghurst: Hmm. |author1=, |author2=, etc. paired with |author1-link=, |author2-link=, etc.? And the same for |translator1= / |translator1-link=, |contributor1= / |contributor1-link=, |editor1= / |editor1-link= and so forth? Yeah, I think we could do that in a fairly straightforward way. If so it would be good to (eventually) migrate all existing uses of |override_author= etc. so we could remove that code from the module. Probably bot'able for most cases, the exceptions being when people have gotten creative with what they put in that field.
Do we want to try for structured data like |author1-last= / |author1-first= for the benefit of web scrapers / metadata, or would that be taking it a step too far? Would probably be finicky given the wide variability of names and auto-linking authors, but for simple cases it might provide some benefit. How about supporting Wikidata QIDs? We'd then get whatever the name at Wikidata was, and be dependent on Wikidata site links for linking the Author: page, but it'd be a nice and tidy way to link our stuff to Wikidata in a machine readable way. We could also conceivably support just giving the QID for an edition item at Wikidata and fetch everything else from there, but I think that would probably require some better (visual, smart) tools for creating Wikidata items and adding bibliographic details to them (and I haven't found any sane API for that as yet; plus there's no real supported GUI library just now while we're waiting for Codex/Vue to get properly deployed).
I plan to have a go at {{header}} again at some point not too distant, so do feel free to drop thoughts here and I'll keep them in mind. Xover (talk) 19:10, 24 November 2022 (UTC)Reply[reply]

Wood Carvings in English Churches II/Chapter 4[edit]

Something went badly wrong on a match and split... Can you find the CLEAN version and delete the pages in the Index: that got created in error thanks?

It would be nice to have a way to 'undo' a bad match and split :( ShakespeareFan00 (talk) 23:23, 25 November 2022 (UTC)Reply[reply]

Resolved. As I said it would be NICE to have a way to 'undo' a bad one. ShakespeareFan00 (talk) 10:07, 26 November 2022 (UTC)Reply[reply]

Migrating stuff...[edit]

Check my contributions.. I'd been trying to migrate some pages away from using <HR /> directly. ( I've tried to replace usages in ns0, and some other non talk namespaces... (I'm not sure if I checked ns104 (Page:), but that's less of a priority as we can set up Indexstyles as needed on a per work basis.)

Next step is attempting to migrate uses of <SUP>...</SUP> , <SUB>...</SUB> and <U>...</U> in ns0.. and some other namespaces that are quick to do.

Any chance you could do a review of these efforts and migrate things in ns10 as needed? Thanks. ShakespeareFan00 (talk) 20:36, 26 November 2022 (UTC)Reply[reply]

Also, I recall having attempted to migrate some ---- rules over to {{rule}}. ShakespeareFan00 (talk) 12:02, 27 November 2022 (UTC)Reply[reply]
You may also find some of the queries here of interest - https://public.paws.wmcloud.org/User:ShakespeareFan00/linthints.ipynb

ShakespeareFan00 (talk) 14:48, 27 November 2022 (UTC)Reply[reply]