User talk:Inductiveload

From Wikisource
Jump to navigation Jump to search

Inductiveload User Area
Main User Page Talk Page Gallery Contributions

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

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

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

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

Wikisource user page Commons user page Wikibooks user page Wikipedia user page

VPN access to enWS

I'm going to be moving to a country that regularly blocks Wikipedia and the entire Wiki world. I would like to keep on contributing to enWS, but I've noticed that it doesn't allow you to edit when I'm on a VPN. Is there anyway to enable editing when on a VPN? Pinging @Xover as well. Languageseeker (talk) 04:48, 18 October 2022 (UTC)Reply[reply]

@Languageseeker: Depends on the mechanism that's preventing you from editing. There are some hard network level blocks for some VPN and VPN-like services, and these cannot be circumvented. But the most common variant is a simple block of the IPs added by admins whenever various forms of undesirable behaviour is detected. These blocks are circumventable by simply giving your account the "IP block exempt" flag, which lets an account edit through the block so long as they are logged in. We don't really have a defined process for this, but any admin can add it, so just put a request for it on WS:AN (for transparency purposes) and we'll figure it out. You'll need to request the same on each project you want to participate on (e.g. see c:COM:IPBE and wikt:Wiktionary:IP block exemption), and there is an additional global level where global IP blocks may be placed (see meta:WM:IPBE). Xover (talk) 06:28, 18 October 2022 (UTC)Reply[reply]
@Xover Many thanks for the detailed answer. Languageseeker (talk) 01:32, 19 October 2022 (UTC)Reply[reply]

TableStyles in Index: pages

When you were messing with Module:Proofreadpage index template, did you ever try adding a TemplateStyles stylesheet to it to replace the inline style attributes? Since MediaWiki:Proofreadpage index template is somewhat "special", I'm a little concerned this will break in spectacular ways and am hesitant to just try it out. I think I can treat it as just any other template, modulo the actual #tag:pagelist itself, but given the hacky ways PRP has historically stored things, my paranoia is in full bloom.

PS. Prompted by needing to make a small change to it, and getting offended by all the remaining cruft, I'm toying with the idea of finishing migrating it to Lua, moving formatting into a TemplateStyles stylesheet, and then writing a Gadget to allow inline editing of individual index fields (via the API). If you've thoughts, cautions, ideas, etc.… Xover (talk) 15:11, 18 October 2022 (UTC)Reply[reply]

@Xover:, I'm afraid I do not recall at all, so...maybe? Definitely would be a good idea. Inline editing would be pretty sweet.
BTW, User:Inductiveload/maintain actually does some fields already through a wizard-ish kind of UI. However, it hasn't yet learned to edit Index pages specifically via the API's JSON content-format, it just regexes the Wikitext. Inductiveloadtalk/contribs 16:21, 18 October 2022 (UTC)Reply[reply]
Oh, wow, it hadn't even occurred to me to hit the "Maintain" link on an Index: page. D'oh! Well, now I know where I can crib some code. :)
I was thinking just regexing the wikicode, but I'll take a look at what the API offers. I was more thinking in terms of not needing to reload the page for each field so it feels snappy. Xover (talk) 19:12, 18 October 2022 (UTC)Reply[reply]
@Xover FYI, the JSON-aware index field API is actually broken by upstream changes (see phab:T321446). Inductiveloadtalk/contribs 15:36, 29 October 2022 (UTC)Reply[reply]
Umherirrender suggests As replacement it seems prop=revision with the contentformat is usable., but I haven't got around to digging yet. Xover (talk) 15:52, 29 October 2022 (UTC)Reply[reply]
I couldn't find a prop=revision for the action=parse, so assuming that that means a query action like, then rvcontentformat is apparently deprecated. Inductiveloadtalk/contribs 16:18, 29 October 2022 (UTC)Reply[reply]
Hmm. So it seems the thinking is that a JSON representation should live in a derived MCR slot (that can be requested explicitly) instead of getting transformed on request when the API is hit. Optimising for latency instead of disk space, maybe? Xover (talk) 16:30, 29 October 2022 (UTC)Reply[reply]
That would make more sense (hence phab:T291293), but will that ever happen? I am not hopeful. Inductiveloadtalk/contribs 16:37, 29 October 2022 (UTC)Reply[reply]
Grmbl. @Tpt, @Samwilson, @Sohom data: Have any of you by any chance looked into making Proofread Page use a MCR slot for storing proofreading status (cf. T291293 and T48724)? And if so, can you comment on the feasibility of replacing the now-broken Index Data API (T321446) with a derived slot (cf. T277203)? Context is that T206253 nerfed contentformat with action=parse, and rvcontentformat with action=query is deprecated (still works, but will go away eventually). Unless someone picks up the MCR work it seems unlikely this is fixable. Xover (talk) 17:00, 29 October 2022 (UTC)Reply[reply]
Yes, MRC is doable. The thing that is blocking me to implement it is to know what to do with the header and footer fields. Should we keep them as special areas or just drop special support for them? Tpt (talk) 09:37, 1 November 2022 (UTC)Reply[reply]
@Tpt: Having dedicated noinclude fields is necessary for quite a lot of cross-page formatting, so dropping them would necessitate a lot of ugly and confusing literal <noinclude>…</noinclude> tags in the page body. In addition, I think the community is quite attached to reproducing running headers and footers on each page. Even community members with an exceedingly pragmatic view of the header/footer ("Don't put too much effort into them, they won't be transcluded so don't really matter") religiously reproduce them in their own texts. In other words, I think it is important that we preserve this functionality.
Whether that means keeping the existing serialization, switching to wikitext-embedded-in-json, move the header and footer to separate MCR slots, or some other clever thing I have no idea. It's going to require special handling for diffs etc. whichever way we go so I don't think the exact serialisation and persistence method matters much outside its own concerns. Xover (talk) 06:50, 2 November 2022 (UTC)Reply[reply]

MC Bot down

It looks as if the MC bot is down again. Can you take a look when you have a moment? Languageseeker (talk) 20:08, 26 October 2022 (UTC)Reply[reply]

My tmux session was gone, so maybe the toolforge server was restarted or something and there was a transient outage. I can see some stats got missed I have refreshed the data and it should update soon. Thanks for the report. Inductiveloadtalk/contribs 22:59, 27 October 2022 (UTC)Reply[reply]

Css field still needed?

Given Index: styles are here, do we still need the Css field (and its tracking category) in the index/index data config? Xover (talk) 15:23, 29 October 2022 (UTC)Reply[reply]

@Xover no, I do not think we need it any more now that the category is cleared out. Inductiveloadtalk/contribs 15:29, 29 October 2022 (UTC)Reply[reply]
Thanks. I'm doing some tidying there so I'll probably nuke it entirely when I get to that point. Xover (talk) 15:33, 29 October 2022 (UTC)Reply[reply]

PRP css

In the PRP css there is the statement

.prp-page-image-openseadragon-horizontal {
    height: 33vh;

and it gives me a huge whitespace between the top of the tabs and the header/image panel (in monobook). What is its purpose? I have been ignoring it for ages as it is ugly though manageable on my monitors on PC, however, when on a laptop alone it is butt ugly. I can turn it off, though it does need to be addressed IMNSHO. [Noting that I reckon that I am way off any standard js/css display for enWS] — billinghurst sDrewth 02:05, 13 November 2022 (UTC)Reply[reply]

@Billinghurst: I am unable to reproduce this in Safari, Firefox, or Chrome. Does it still do this if you open the page when logged out and add &useskin=monobook to the URL? I see nothing obvious that should cause problems in User:Billinghurst/common.js or User:Billinghurst/common.css, but you might want to test after removing the #prp-page-image-openseadragon-vertical {height: 100%;} (this should no longer be needed) and .ext-wikisource-ExtractTextWidget { display: none; } as the most likely to interact some way with this (if you haven't tried that already).
The CSS you quote above should only have an effect when the PRP editor is in horizontal mode. It's for the container for the image when the editing layout is horizontal, and sets its height to "33 viewport height units" (essentially just 33% of the visible browser window height). When the editing layout is vertical the scripts dynamically add the class ".prp-layout-is-vertical" on that container, and the associate style then sets display: none; which hides it entirely regardless of its configured size. From what you describe it sounds like something is preventing this display:none from having an effect, but there are any number of things that could potentially cause that.
If you want to go delving into the Web Inspector in your browser you might try seeing if you have the class .prp-layout-is-vertical set on any element, and whether that element is the div with .prp-page-image-openseadragon-horizontal set. It might also be worthwhile to check the computed properties for that div to see what its height is set to (and from where) and what its display is set to (and from where). Some of the possible causes of this would leave an error message in the JavaScript Console, so any error messages there might also be relevant. Xover (talk) 09:46, 13 November 2022 (UTC)Reply[reply]
The changes to my common.css don't make a difference. Interestingly when I do it in a private window (so logged out) I see the thick white band appear (things rendered down, and then disappear with everything rendering back up, and that is with vector or monobook. Logged in, through web developer tools, when I pick the element (highlight) the whitespace shows as
<div class="prp-page-image-openseadragon-horizontal" id="prp-page-image-openseadragon-horizontal"></div>
when I do the same logged out, it doesn't show. So I may have to outwait the cache somewhat. <shrug> — billinghurst sDrewth 10:38, 13 November 2022 (UTC)Reply[reply]
Hmm. Just to double-check: you are using the so-called "vertical" layout, with the scan image to the right of the text box, and not the "horizontal" that has the image above the text box? Because in that case the javascript delivered as part of PRP should have set prp-layout-is-vertical in the @class for that div. There are no error messages in the JavaScript console? What web browser is it?
Provided you are using "vertical" layout, and don't need to switch, you could maybe work around it using .prp-page-image-openseadragon-horizontal {display:none;} in your Common.css, but that's kinda icky and prone to break with future changes. It would be good to be able to pinpoint exactly why it's breaking and fix it properly.
PS. What you see when logged out sounds like roughly correct behaviour. On page load you should be getting a div with just .prp-page-image-openseadragon-horizontal set, and with a stylesheet that sets it to 33vh. Once the javascript has loaded (they load asynchronously) it should detect that you're in vertical layout (which is default for logged-out users) and add the .prp-layout-is-vertical class which changes the style to display:none. If the computer or network is sluggish (or heavily loaded or...) this could look like a big empty block appearing and then getting hidden. I don't see that happening on my computer, but that's probably because it happens fast enough that it gets lost in all the other site chrome and dynamic menus and stuff. It's likely that this would be more visible in a lightweight skin like monobook than in Vector. Xover (talk) 12:52, 13 November 2022 (UTC)Reply[reply]

the subpage format used with header=1

With something like Emily of New Moon the header=1 format is ugh, as it inserts a year parameter on all the subpages, and that then bumps down the author field extending AND adding the publisher detail further extending the header. I believe that header=1 works need a simpler (separate?) subpage structure. — billinghurst sDrewth 23:29, 23 November 2022 (UTC)Reply[reply]

PRP just calls a template with pre-filled params when header=1 is present. Once we have that all backed by a Lua module it should, I hope, be fairly straightforward to detect that we're on a subpage and adjust the output accordingly. The tough part would be defining what the logic should be, because we have so many quixotic edge-cases (and a lot of historic uses that hardcodes specific formatting inside template fields to achieve some specific effect). But without actually looking into it in detail I think it's probably doable. Xover (talk) 20:15, 24 November 2022 (UTC)Reply[reply]
Hmm. But the author-on-a-new-line thing is actually due to feeding PRP's author info to the |override_author= field in {{header}}. For some reason that always puts it on a new line (I have no idea why). Xover (talk) 20:45, 24 November 2022 (UTC)Reply[reply]