User talk:George Orwell III

From Wikisource
Jump to: navigation, search

George Orwell III (talk page)

(Archives index, Last archive) Note: Please use informative section titles that give some indication of the message.


how to download from google books?[edit]

This book's upload, did you download it from Google? And if so, could you please post an image of the webpage? The reason for asking an image to see if I can access the same page from a Canadian IP. Have not been able to download any books directly from Google, and don't know why. Thanks. — Ineuw talk 23:15, 8 February 2016 (UTC)

@Ineuw: Have you tried toollabs:bub/ ? — billinghurst sDrewth 01:08, 9 February 2016 (UTC)
Thanks. Didn't know about this. Will try it later tonight. — Ineuw talk 03:03, 9 February 2016 (UTC)
@Ineuw: - What is so "wrong" this file that you can't collect your senses and go to the sources parameter of the book template for the link I used from Google Books? -- George Orwell III (talk) 00:09, 13 February 2016 (UTC)
Now now GOIII, you are jumping to conclusions, just like I do. Perhaps it's because we are related? After all, my mother and your mother are both mothers. :-) — Ineuw talk 00:50, 13 February 2016 (UTC)
By that reasoning so am I: mothers of sons of b…es? AuFCL (talk) 00:59, 13 February 2016 (UTC)

A different note on mediawiki:PageNumbers.js (& mea culpa)[edit]

You might cast your memory back to my influencing you to make this change? Well this proves there is a bug of minor consequence remaining—to which I currently have not the slightest inkling of a solution. In other words I realise now I mislead you at the time!

It appears if the very first item on a transcluded page happens to be a red-link itself, the page_span.parentNode.nextSibling logic as it stands homes in to the wrong DOM node with this result. I am undecided as to whether this issue is unique to the first page in the transclusion set; or perhaps the parser hierarchy has subtly changed since PageNumbers.js traversal logic was established. Either way, two heads aware of matter better than one?

This is far from being a priority matter; just a note you might find of interest. AuFCL (talk) 21:10, 10 February 2016 (UTC)

I am a bit lost - mostly because I do not "see" anything wrong (redlinked) at the example DNB page you linked. Can you elaborate? -- George Orwell III (talk) 00:17, 13 February 2016 (UTC)
Well this is whats yuz gets when yuz is slow on the scene observing transient conditions. When I wrote the note on the 10th February, the first content element on that page happened to be a red-link to Author:Francis Henry Salvin—an item which Billinghurst added on 11th February. Now looking at the page on (well my time anyway) 13th Feb. the condition has "gone away."

If you recall I stated it was not a high-priority issue so don't bother further except to note somewhere in the background the code isn't perfect (as if you did not already know that!) AuFCL (talk) 00:45, 13 February 2016 (UTC)

@AuFCL:, as always -- I appreciate your interest & collaboration in such matters and apologize for my unavoidable "slowness" of late as well. It's this lack of free time that has forced me to reassess my "approach" and focus more on coming up with a replacement to the current nonsense on rather than trying to prune and pray with every incremental fix on the current bits here. I'd welcome your participation there as well if agreeable. -- George Orwell III (talk) 23:39, 13 February 2016 (UTC)
Joking aside I am not holding said "slowness" as a mark against you. On the contrary thank you for the invitation and the expression of trust.

I have been (extremely casually) watching over there but to this point feel I am so far behind the eight-ball as to be unable to offer anything useful. Test2 is a good choice but no doubt suffers from a different set of eager "fixers"? (The last fully tongue-in-cheek: one person's prized sample fault for further analysis is another one's challenge to plaster over and obscure as quickly as possible. Sound familiar?) AuFCL (talk) 23:49, 13 February 2016 (UTC)

Not when it comes to the ProofRead Page extension and related - nobody has cared what I do with it so far. Only the PR extension is active by default there - all the "supporting" scripts and bits are up to local (User:) activation; plus any MediWiki: template can be moved as a redirect from the Template: namespace (if not already). -- George Orwell III (talk) 00:22, 14 February 2016 (UTC)
You cunning sod. I am all admiration but wait: isn't that just a back-handed way of creating a #REDIRECT out of MediaWiki:-space into Template:? Or is there some special loophole-for-testing going on over there? Remember (and this is not a hint or request) I am not a sysop there. AuFCL (talk) 00:33, 14 February 2016 (UTC)
Nothing special - it can be done anywhere including here except for the "rule" frowning upon no cross-namespace redirects in the first place (told you nobody says boo over there). I did it there on test2 for no other reason other than letting non-admins edit/revert stuff "normally" unavailable to them when normal residing in the MediaWiki namespace. Its also further evidence that the MediaWiki namespace is not meant for what amounts to a Template: to begin with. (e.g. the edit protection argument is moot). -- George Orwell III (talk) 01:11, 14 February 2016 (UTC)
I am proud to consider myself a technician rather than a politician in these matters. I am far more interested in the capabilities than the legalities at this point in the investigation. I cannot at this point in time recall where I read this but I believe the MediaWiki: name space is internally sub-classified three ways (umm. I think (java)scripting and CSS was one; $-substitution was another and the third might have been template-like? As you might tell my recollection is hazy. If I come across the reference again I'll shove it your way if you are interested.) [I think you politely side-stepped excreta bovinus, No?] AuFCL (talk) 01:48, 14 February 2016 (UTC)
I don't doubt that is stated somewhere as you say - all I'm saying is things like MediaWiki:Proofreadpage pagenum template are hacks or they'd be listed along with the rest of the PR message group but its not so it can't be thought of as legitimate usage of the MW namespace. Its just a manually made up template occupying the MW namespace for no good reason (other than to keep it "hidden" initially). -- George Orwell III (talk) 06:14, 14 February 2016 (UTC)
I am in total agreement on that point. I have not found the "mystery documentation" but in looking around note the third paragraph of meta:Help:System_message#Protection. Your ultimate let-out clause, should you ever want to use it, henceforth should be: "If an administrator wishes to allow general editing of a system message, a template call can be placed in the MediaWiki page, with the template containing the message itself." (Hey, it was in the official documentation, been there unchanged since a helpful IP editor introduced it in February, 2006. Wasn't me: U.S. based.) AuFCL (talk) 07:04, 14 February 2016 (UTC)

Re: MediaWiki:Gadget-Site.css—No.[edit]

Good effort and attempt appreciated but not useful. div#content alone lives betwixt these so the ">" just cripples what little good there already is. Besides, the PageNumbers.js cookie issue smashes this for a knock-out high-score anyway. AuFCL (talk) 02:24, 20 February 2016 (UTC)

5 changes, 2 changes, 1 change, 1 change, 3 changes: Not at all complaining about the results. May I giggle uncontrollably now? Sincere thanks! AuFCL (talk) 08:29, 21 February 2016 (UTC)
That's why DL has be tossed. I'm only concerned about the changes I made to PageNumbers.js re: jQuery $.cookie to mw.cookie. Doubt that any of it was "right" -- George Orwell III (talk) 08:48, 21 February 2016 (UTC)
Yes, I saw that. The dynamics of mw.cookie appear to be different in the sense that the cookie "name" handled changes, e.g. "layout" becomes "enwikisourcelayout". This means there is no hope of settings made under the old system transferring to the new but no great loss. I am slightly more concerned about the fact the old system attempting (and of course failing) to maintain independent settings for each individual article. This approach is "more honest" in the sense changing layout for one page changes for all.

I would not recommend pushing it any further; and you frankly caught me off-guard with the class name change for Page: space. Very cunning and I applaud the choice. Up to that point I had been leaning more toward either inhibiting PageNumbers.js executing against name space 114; or perhaps faking in a standard cookie "value" whenever dealing with Page:. All ultimately equivalent in effect.

One final note: I think we were experimenting on this in parallel but I have realised despite the choice of variable names and optimistic documentation $(selector).attr("style",value) does not at all act upon a standard CSS selector; it simply searches the DOM tree for nodes with the nominated id= or class= attribute values to act upon and absolutely nothing more complicated. Hierarchies and associated nodes are not acted upon, ever. AuFCL (talk) 10:10, 21 February 2016 (UTC)

You still miss the original point of lumping everything under the sun into PageNumbers.js, Common.js (and at first Base.js as well); Dynamic Layouts were never intended to be dynamic at all; that's the whole point of setting css via common.js -- everything is processed as if those setting were manually added inline rather than defined then called from any .css file. Those class names are "meaningless" in the traditional sense as proven by this latest fiasco under dynamic layouts (that's why the first span sits alone with only the class= set in the templates themselves; the other span was an attempt to override the faux inline values provided within common.js [fail]).

I remember now how this whole "cookie" thing never really worked because every third "visit" or so, the entire Display Options side menu would go "missing" in addition to only the Layout selections working -- you couldn't hide or toggle the embedded links at all. The only "fix" for insuring the consistent creation of the portlet option menu was to hard code it in along with the basic mw defaults and then hide it from all the other namespaces afterwards. You can probably see an extra "separator" line in the side menu when viewing your User: preferences (that's the hard code hack at work).

Again too much crap lumped into one .js to ever be fixable; imho we need to start from scratch (mobile mode will eventually force that regardless. -- George Orwell III (talk) 11:19, 21 February 2016 (UTC)

I presume you are referring to this little piece of craziness:
<div class="portal" role="navigation" id="p-do" aria-labelledby="p-do-label"><h3 dir="ltr" id="p-do-label" lang="en-GB"></h3><div class="body"><ul></ul></div></div>
—presumably that is what is left after something was created and partially .removed again? AuFCL (talk) 12:21, 21 February 2016 (UTC)
Pretty much. The issue was/is there is no reliable "trigger" to initiate the bits to create all that -- the best that I could come up with is to see if the presence of the "Source" tab is 'true' or see if the presence of the pr-quality status bar is 'true' and then build a Display Options menu portal to accommodate the settings 'built' by PageNumbers.js. But that too would somehow allow the Display Options menu container to go MIA more often than 'allowable' to the community-at-large. The only way to consistently generate the container to accommodate display options was to 'seed' MediaWiki:Sidebar with a skin triggered entry (dee-oh [do] for display options). The problem then became a "simple" matter of preventing the display of DO in other namespaces AND those instances of non-transcluded main-space content (admittedly an ugly hack but it works nevertheless). -- George Orwell III (talk) 13:23, 21 February 2016 (UTC)
Ah. So you're the one who sprayed all those mysterious tests for presence of table.pr_quality around every time #p-do is about to get the chop? I have come across articles constructed such that the top level did not have "Display Options" yet the sub-pages did and tracked it only as far as uncovering the lack of that element but not as far as its author.

See what I mean about becoming the single point of contact? Nuisance isn't it? AuFCL (talk) 21:57, 21 February 2016 (UTC)

Yeah I'm the one that stopped the flakey generation of the Display Options side-bar menu and the subsequent options appearing under it WHEN the pages index tag is exclusively used - what of it?. And I'm betting what you describe is a top level page "built" by the user mixing LST, the pages tag, the Page template and the page-break template to "create" that page. Using certain combinations as listed for transclusion does not reliably load the progress-bar nor the source bar at the same point &/or order as does using nothing but the pages index tag for transclusion. Can you find me an example of this regardless of my assumption(s)?

As far as being a 'single point of contact'; I'm not sure if I like what you're saying. Do think I intentionally strived to become that or that I would up seeming that way thanks to circumstances beyond my control? I pretty much welcomed you in particular twice to join the system admin level just for your need skillset and help on this frontier btw (stone meet glass house in short).

I checked back. Even simpler case: the top-level page consists purely of {{header}}+wikitext containing links to sub-pages containing the "real" <pages/> logic. Thus there is no trigger for Display Options to ever be presented or applied to the top-level. Otherwise close enough to your formula.

Regarding SPOC: Hey, do you think I liked telling you (as if I ever thought you did not know already)? It was intended as a kindly reminder to try not to get roped into that situation. If I truly believed you were guilty of such overweening ambition we would not be having this conversation at all. I started to respond to the sysop matter but realised the best answer is do not go there. You and I both know why it isn't going to happen. AuFCL (talk) 06:36, 24 February 2016 (UTC)

I sympathise with your overall point about killing this to make way for progress. Please (at least try) not to fall into the old trap of only one person (presumably this time yourself) holding all the threads with whatever the new conception turns out to be. This 'community' is somewhat prone to split into big- and little- endians who will fight to the death to support their ideas about the "correct" way of going about things long after the sole key individual who actually knows how things hang together has moved on. Neither grouping will have the remotest idea of how to patch up the inevitable bit-rot faults which crop up yet will be over-eager to stamp on any newcomers who pass by with their newfangled ideas. (This is one of the reasons I am cautious of your occasional Alex and Thomas side-swipes: all good fun maybe but there is a darker side too.) AuFCL (talk) 12:21, 21 February 2016 (UTC)
I'd be happy if I can just break PageNumbers.js up into gadgets per feature and not have self.layouts & junk residing in Commons.js anymore. ResourceLoader (e.g. Gadgets) can then be manipulated to load what is needed in a far better manner and order than what is taking place now. Replacing Dynamic Layouts with some sort of comparable responsive web design is unavoidable regardless; its just a matter of time. -- George Orwell III (talk) 13:23, 21 February 2016 (UTC)
I realise our perspectives on this (will) differ but I see "self.layouts & junk residing in Commons.js" as a somewhat desperate attempt to permit the end-user access to and influence upon "secret system stuff" configuration data (I'd have said gadget but in reality know PageNumbers predates current gadget usage.) As such I cannot entirely condemn the concept. You cannot blame the developer for not anticipating every perverse whim of the consumer base and there is not always a "tame sysop" available to implement every aesthetic change. This is getting close to the feed-with- vs teach-how-to- fish parable. AuFCL (talk) 21:57, 21 February 2016 (UTC)
Agree to disagree. -- George Orwell III (talk) 23:25, 23 February 2016 (UTC)
I did not really expect you would. In some respects you are more of an idealist than am I in this instance. Anyway I did not intend to provoke a fight; and even if I did I'd not be bothered using this kind of an issue in order to provoke the old bear. AuFCL (talk) 06:36, 24 February 2016 (UTC)

== A minor cosmetic issue ==

Hi. I refrained from bothering you for quite awhile (who keeps count?). Then, I came across a minor cosmetic issue and perhaps you can correct it. It's about the pagination controls which appear in either edit or read mode in the Page namespace. The 'page advance' control's left edge overlaps the right edge of the 'page backwards' control and this hides colored border display when using the Nopinserter.js. Could you please separate the controls by 4-5 pixels if possible? Thanks. — Ineuw talk 04:23, 21 March 2016 (UTC)

interesting snippet re abuse filters[edit]

FYI. For Special:AbuseFilter/16 it can show a hit on a main ns file for a new added link when there is no change to the main ns added_link directly. I note that I changed one of the transcluded Page: ns pages and fixed a broken link, and about half a day later, someone has updated the main ns page. That update has identified that the transcluded page has a new url at that time and it shows in 'examine' though does not show in the 'diff'. Thought that it was worth sharing. — billinghurst sDrewth 03:53, 3 April 2016 (UTC)


I have left a message on MediaWiki_talk:Gadget-Site.css#border-box_.2A_selector_needs_to_be_removed. Perhaps you can provide some insight into why the rules were added so we can fix them. Thanks, ESanders (WMF) (talk) 14:25, 20 April 2016 (UTC)

@ESanders (WMF): Judging by the amount of phabricator & gerrit work I've seen you involved with, you may already know one of the main the reasons (or will dawn upon you sooner rather than later I suspect) for overriding settings --> trying make an .svg (ooui-icon/ooui-indicator) "behave" like a font-glyph while also serving as containing element's "background image" is riddled with pitfalls as it is - never mind trying to deploy it under a pre-existing skin such as Vector after the fact.

If you wanted completely scalable/zoomible font-glyphs without the svg-to-faux-icon headaches, should have looked at developing/deploying something like FontAwesome to begin with [imho that is] -- George Orwell III (talk) 05:08, 21 April 2016 (UTC)

I'm not sure I understand the specific bug you were trying to fix, but font icons were proposed and considered, but rejected in favour in SVG; mostly because of bandwidth concerns. ESanders (WMF) (talk) 08:26, 21 April 2016 (UTC)


I am afraid that {{USStatChapHead}} has evolved far beyond my capability to comprehend, so I am hoping that you may be able to step in and fix whatever problem is currently causing the datenote parameter not to display anything when the page is rendered. Many thanks! Tarmstro99 15:30, 24 May 2016 (UTC)