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.


[ NEVER CLICK ON THIS!!!! ]

Page statistics change coming up.[edit]

Hello. I don't know if you are aware of phab:T95629 but some of the associated precursors to that task have already eliminated such things as Special:PopularPages. Personally I can live with that (if indeed that is the full extent of the implications) but perhaps this will also affect some counters you may be aware of (yet I am clearly not) that WikiSource or its management may depend upon? I hope ignorance ≡ bliss? (Consulting WikiPedia contacts won't help as apparently enWS in particular has had this functionality turned off for some years—thus their experience of this change is likely to be quite different to the sister projects.) AuFCL (talk) 05:28, 27 July 2015 (UTC)

Hey man & thanks. I saw some changes (then reversions) over on Wikipedia to MediaWiki:Histlegend but didn't know about the Phab. Task. I'll look into it when I get home. -- George Orwell III (talk) 13:25, 27 July 2015 (UTC)

Smallrefs line height[edit]

Is it my imagination, or has the line height for {{smallrefs}} diminished recently. Surely my eyesight isn't deteriorating. If you haven't seen it recently, I think that it needs a fraction more whitespace. — billinghurst sDrewth 13:35, 28 July 2015 (UTC)

There is no difference between 110% and 1.10 as a multiplier the last time I checked 7 months ago but I'll look into it when I get the chance. -- George Orwell III (talk) 20:56, 28 July 2015 (UTC)
Thanks. It may be the works, it may be my mind, it just looks tighter and a little harder to read. <shrug> — billinghurst sDrewth 10:10, 30 July 2015 (UTC)
@Billinghurst: just to be clear, we are talking about the text referenced after the primary content and not the numbered refs peppered throughout the content right? There's been a lot of movement on the cite/citiod front (primarily for Wikipedia's benefit) but since those various citations are just references at their heart, its possible a change there has "leaked" over to us here somehow. Anyway, I'm going through the gerrits and such right now in hopes of locating something.

And fwiw... I'm not exactly seeing any difference but I'm not all that sure I count as a "frequent" user of smallrefs of late either. Can you point to a specific example of the observed "narrowness" just so I have a baseline we both can keep referring back to if need be. TIA. -- George Orwell III (talk) 21:24, 30 July 2015 (UTC)

@Billinghurst:, Your eyes are not deceiving you, the line height is less than before. I noticed as well, and think that the change is recent, perhaps a couple of days old. Being line height addicted, must tell you that I had nothing to do with it. :-) — Ineuw talk 01:59, 1 August 2015 (UTC)

┌────────────────┘
I reverted the change to {{smallrefs}} from 7 months ago if that makes things any better. It re-introduces the problem of both font-size and line-height having lengths in percentages which causes "fractional" values in px during calculation however. Other than that 7 month old edit, I can't find anything more recent that could have cause that change in rendering locally; that's not to say something hasn't changed core or extension wise. -- George Orwell III (talk) 02:40, 1 August 2015 (UTC)

Please don't tell me there is still some imbecilic browser out there can't distinquish 110% from 1.1?

Oh well, at least it exercises the job queue. AuFCL (talk) 02:54, 1 August 2015 (UTC)

Nah, I don't think so. This more about the current 'default desktop-view' -to- 'baseline font-size settings' thing than anything else. Everything derived from that "14px" font-size are more likely to run into these issues; when in doubt, I just look at the page in Mobile View for guidance -- results always seem to multiply and divide "better" with a 16px baseline there. I wish more focus was put into unifying the Vector & Minerva skins already. -- George Orwell III (talk) 03:21, 1 August 2015 (UTC)
<shrug> If you want a page, then squish Page:Admiral Phillip.djvu/309 a little. — billinghurst sDrewth 11:53, 1 August 2015 (UTC)

┌────────────────┘
So restoring 110% didn't change anything? -- George Orwell III (talk) 19:43, 1 August 2015 (UTC)

OK I bumped the line height to 1.25 which calculates to a nice, even line-height of 14px ("normal" contents font-size). Better? -- George Orwell III (talk) 19:53, 1 August 2015 (UTC)
Not sure this helps but as far as my experimentation goes, mobile view inter-reference spacing appears to be dominated by the margin-bottom attribute (applied as 10px via .content ol li—specific to mobile view)rather than line-height. Does this get us anywhere? AuFCL (talk) 00:57, 2 August 2015 (UTC)
For me in desktop view that change with a little more whitespace does look better. — billinghurst sDrewth 01:10, 2 August 2015 (UTC)
Well I guess we'll leave it there unless of course someone disagrees with the change. -- George Orwell III (talk) 23:23, 4 August 2015 (UTC)

┌─────────┘
Feel free (both of you) to dismiss this as a complete side-issue but I am getting rather confused as regards future planned directions. If "Minerva" is truly official then why is it not offered as a Preferences skin choice? In a similar vein if "Vector" is an evolutionary dead-end are editors doing themselves a disservice in even remotely attempting to reproduce layouts per current display metrics? And finally whatever happened to "Winter"? AuFCL (talk) 05:12, 2 August 2015 (UTC)

Minerva is official - its just geared for mobile view right now; mobile mode would not be offered at the bottom of every desktop page if it wasn't. Whatever they call it or regardless of the interim steps they take to get there, the main and mobile views will merge if only in their final rendering as opposed to a single shared skin. Both avenues will have left and right margins depending on how wide your viewport is at the time; the 10 or 11em the Vector sidebar takes up will be freed up and a mirror width right margin will ultimately "center" all content. When its wide enough, the layout will look much like "Winter" proposes now and then begin to "collapse" margin-wise as that viewport shrinks incrementally down to the minimum mobile phone device standards of the day. The left sidebar will become some sort of flyout or lightbox when the viewport is less than some yet to be agreed upon standard width; the new right margin however is geared to hold Wikipedia style infoboxes, inter & intra wikilinks, language links and the like. If so, that right margin would be a "waste of space" for us without additional manipulation.

All that might change from one day to the next; fair warning. -- George Orwell III (talk) 23:23, 4 August 2015 (UTC)

Template:Greek trans documentation[edit]

Hi. What your change ([1]) mean? This breaks viewing of documentation. Skim (talk) 19:31, 28 July 2015 (UTC)

The original problem was that part of the template is being called from the User: namespace and put us over the template expand limit at the time. I just forgot to change it back. Sorry. -- George Orwell III (talk) 20:53, 28 July 2015 (UTC)
ok, thanks :-) Skim (talk) 09:53, 7 August 2015 (UTC)

Image correction[edit]

Hi! Coming to you after a long time. You might remember the deletion at Commons, some time ago, of the image at Author:Bankim Chandra Chattopadhyay, and subsequent undeletion. It is a heritage image and used by many sites, including Goodreads. I have finally located the original version at Page:The Literature of Bengal.djvu/244. But the quality of the image is very bad indeed. Same is the situation with other images in the work. Probably something to do with the original material used for printing the image on. Are these images redeemable? You have expertise in many technical matters, that's why I am asking. Regards, Hrishikes (talk) 08:10, 3 August 2015 (UTC)

I know it is a day later but the JPG now at position /244 looks great to me. Are you asking about the images embedded in the DJVU and presented as a thumbnail in the Page: namespace? -- George Orwell III (talk) 23:02, 4 August 2015 (UTC)
I am talking about the jpg. Does the skin on the face look like human skin? Hrishikes (talk) 00:29, 5 August 2015 (UTC)
Apologies for jumping in but the image does look a bit bad. Note p.136 and p.194 on the Internet Archives source pages which show better images. They are lithographs. Given all concerned (time, age, handling, humidity conditions, &c) the image is good enough. Do try to find a better source for that particular image though. Try HathiTrust. —Maury (talk) 01:02, 5 August 2015 (UTC)
Maury: The IA copy (the one here) is from the University of California. Three other copies are available (Michigan, California, New York) at Hathi Trust here. But they have US access only. Hrishikes (talk) 03:06, 5 August 2015 (UTC)
I don't mind getting it from Hathi Trust for you but what exactly do you want? Just one image or more? I live in the USA. "US only" isn't how I think information on Internet should be. —Maury (talk) 03:23, 5 August 2015 (UTC)
I need two things from Hathi Trust: (1) Images from this work; (2) Another work by the same author here. I shall be grateful if you can provide these. Hrishikes (talk) 04:35, 5 August 2015 (UTC)

┌───────────────────┘

Back to the point on "scanned" images. The first thing to keep in mind here is our goal is to reproduce original published works as faithfully as possible; not so much to enhance them beyond reason.

That said, its very rare to have high quality images in post-conversion djvu files. If IA was the source, I'd go look for the original PDF used for IA processing whenever possible to verify the images were "poor" to begin with rather than mangled in the conversion to DjVu. Frequently the archived .tiff or .jp2 file will have superior images to work with because they are next closest thing to the original source and created early on in IA's conversion process. Finally, alternative sources -- such as HathiTrust as Maury has offered -- are also worth investigating if the IA "options" do not pan out to be worth further pursuing. And I'm sure other well-established contributors have additional tips on how to optimize image selection/creation too; don't hesitate to call upon them -- If I may be as so bold to speak for them -- consider yourself among friends if you haven't realized that yet on your own already :) -- George Orwell III (talk) 22:34, 5 August 2015 (UTC)

A(sort-of)nother tag candidate?[edit]

Hello. Only if you have a moment to spare would you please be so kind as to have a cursory look at this sandbox demonstration (of {{math tag}}) and let me know if you consider this a hopeless waste of effort? I would have liked to have made a more natural complement to the {{span tag}}/{{table style}}/{{paragraph tag}} set but have embarrassingly discovered tags supported by extensions have different parsing priorities to what I formerly considered perhaps the "natural order."

I repeat: please do not expend effort on this unless you actually think it might be useful to yourself. I suspect I might be the only candidate user and if that really is true would vote for expunging the whole mess. AuFCL (talk) 09:59, 3 August 2015 (UTC)

It seems workable enough to me but I'm really not that familiar with reproducing formulas and such (never had much need for it transcription wise). But the first thing I'd check is to make sure nothing similar has taken hold or been in use for some time now on at least the major Wikipedias. If nothing like that exists then I wouldn't worry about you being the only one to utilize it at first here on WS; others will follow if they can pick up your application of it easy enough. -- George Orwell III (talk) 23:31, 4 August 2015 (UTC)
The sanity check is appreciated. As I see it there are two main driver cases, one driven by a relatively obscure situation which may not recur in situations other than the peculiar notation exemplified here. This monstrosity <math style="border:1px solid black;border-left:none;border-bottom:none;">\scriptstyle{q}</math><math>\scriptstyle{p}</math> (yielding the almost effete result "\scriptstyle{q}\scriptstyle{p}") may be represented as {{math|br|bt|script=\scriptstyle{ q } }}<math>\scriptstyle{p}</math> which perhaps may be only an improvement in my own fevered imagination?

The other case which I consider arises fairly frequently is when a self-contained formula fragment appears centered on a line of its own interspersed in the text flow which is traditionally handled by wrapping it in either {{center}} or its variants (e.g {{centre|<math>\frac{\pi}{2}.</math>}} resulting in

\frac{\pi}{2}.

Under the proposed notation {{math|dbl|mc|script=\frac{\pi}{2}. }} does the same thing viz \frac{\pi}{2}.

I shall leave this delicious and rather unplanned example where my proposal generates code which works better than the traditional case (Have you noticed mediawiki always screws up the paragraphs immediately following the presence of definition lists' <dl> tags? Which of course is the precise situation at this point in the discussion?) AuFCL (talk) 07:52, 5 August 2015 (UTC)

First suggestion: If the inline stylings for the math tag are going to be consistent yet somewhat repetitive, why not lessen the parser burden by defining those attributes as classes? Again, I couldn't tell you if there is such a common set of math related inline stylings in use to make class definitions themselves worthwhile.

The other thing about how certain elements interact with other elements like your paragraph a descendent or child of the defined list element also touches on the class definition thing. With CSS3 support nearly universal now browser-wise, we can build should be building more specific "chains" of selectors to define css classes for just such instances of recurring usage. Plus, we need to start vetting not only what already have css wise but anything newly added against mobile view sooner rather than later -- or we'll get stuck with what they decide to give us a la Wikipedia-specific. -- George Orwell III (talk) 22:51, 5 August 2015 (UTC)

I would support a template approach solely for the reason that it uses #tag which helps alleviate issues that we have with &ltpoem>, <ref> and other created hard <tag>s which generally don't integrate well. That said, we just need to be wary then of pipes and instructions for use of {{!}}. — billinghurst sDrewth 23:29, 5 August 2015 (UTC)
FYI... {{!}} was made a formal magic word not too long ago and don't believe it runs into the issues it did when it was applied as a template anymore (though I'm not 100% sure about that). -- George Orwell III (talk) 23:35, 5 August 2015 (UTC)
O.K. Two issues immediately arise: I am sure everybody has already realised the (unfortunate) coincidence that TeX (and thus <math>) syntax just happens to be compatible with wiki-markup template syntax—unfortunate in the sense that parser priority choices mean that the wiki-engine "steals" essential elements out of the TeX expression (things like "{{") before TeX even gets to "see" them. Thus more than ordinary care has to be taken to ensure party A isn't trying in vain to process content intended for party B &amp vv. Which nearly renders keyword {{!}} unusable in this particular setting—certainly not even much of an assistance{{!}}

Getting back to the outer point I completely buy into the "class" argument with the long-standing proviso that short of the famed mw:extension:CSS or equivalent support idea ever being seriously considered this approach opens up the elephant in the room sysop/user divide. Do you really need me to go 100% apolitical and expand, especially since this is old, old, old near-archaic territory?

All of the above aside I would like to propose something along the lines of adding a new class (somewhere in the chain of your choice) along the lines of

img.mathcentre {
	display:block;
	margin:0 auto 0 auto;
}
to be utilised in the context of e.g. <math class="mathcentre">{{!}}</math>. Vary the classname (obviously there will be a U.S.-centric preference for "mathcenter"?) but in any case I believe this variant will become immediately useful. AuFCL (talk) 01:02, 6 August 2015 (UTC)

AuFCL (talk) 01:02, 6 August 2015 (UTC)

I don't do math stuff, the works are of little interest to me. Re "class" stuff I leave to GO who knows more about it then I care to, and I go with the flow. I was more lending support to a standardised approach using tags and documenting so we have better/consistent interactions with our tags that matter to us. Easier to document and support, and allows users to transcribe not beat their heads on their desks asking why in the hell isn't it working. — billinghurst sDrewth 01:11, 6 August 2015 (UTC)
Do the top and bottom margins need to be "nullified"? what about just...
img.mathcentre, img.mathcenter {
	display: block;
	margin-right: auto;
	margin-left: auto;
}
... in hopes of letting any rare chances of box-ish layout of math tags inherit top or bottom margins instead. -- George Orwell III (talk) 01:21, 6 August 2015 (UTC)
Entirely acceptable. The nulling of top and bottom margins has perhaps become a bit of a blind spot with me as in most contexts I have been overly-conscious of not disrupting the overriding ruleset.

And re. Billinghurst: it appears I misunderstood your misunderstanding. Not sure if that really cancels out but at least I think we do not disagree on this issue? AuFCL (talk) 01:50, 6 August 2015 (UTC)

Yes check.svg Done . -- Can we start a separate "the elephant in the room sysop/user divide" (if need be) rather than tagging on to what seems like agreement all around on the other facets? -- George Orwell III (talk) 01:58, 6 August 2015 (UTC)
Re. primary issue: Genius. Trialled here Page:Elements of the Differential and Integral Calculus - Granville - Revised.djvu/53. Re. other matter I fully concur but fear issue might prove touchy. I await your guidance for, as you know I have had the experience of more than a few unexpected submerged rocks on this longitudinal matter. I really do not think we need to go there unnecessarily. AuFCL (talk) 02:06, 6 August 2015 (UTC)
I'm not sure what there is to visit but if its something nagging you, by all means lets crack it open. All I ask is we do that closer to the weekend when I should have more "time". -- George Orwell III (talk) 02:11, 6 August 2015 (UTC)
  1. I keep forgetting it is only mid-week to you.
  2. It really is not worth the fight, but just remember CSS alterations are trivial to sysops, but a big deal from the user side. (Sub-corollary: for every idiot user there is equally an idiot sysop who won't understand the background of a request they do not understand.)
  3. None of this stuff is in any way urgent.
Will that do for a precis? Now let it die. AuFCL (talk) 02:47, 6 August 2015 (UTC)

Gadget Updates[edit]

https://en.wikisource.org/w/index.php?title=MediaWiki:Gadget-enws-tweaks.css&curid=1483652&diff=5564643&oldid=5514261

Well whatever you changed it broke something for me, I can't know seemingly use the {{nop}} toolbar option or add the OCR button in the proofreading tools. Presumably this is a planned update? ShakespeareFan00 (talk) 08:30, 7 August 2015 (UTC)

Umm. Maybe this storm of JavaScript errors being logged by my (and presumably other) browser might be more relevant? I think you might agree there is a bit of a common theme going on—one that I hardly think is related to any CSS edits… AuFCL (talk) 09:02, 7 August 2015 (UTC)
"Gadget "pr_test_layout" was not loaded. Please migrate it to use ResourceLoader.  See <https://en.wikisource.org/wiki/Special:Gadgets>." load.php:156:624
"Gadget "altindex" was not loaded. Please migrate it to use ResourceLoader.  See <https://en.wikisource.org/wiki/Special:Gadgets>." load.php:156:624
"Gadget "userMessages" was not loaded. Please migrate it to use ResourceLoader.  See <https://en.wikisource.org/wiki/Special:Gadgets>." load.php:156:624
"Gadget "markblocked" was not loaded. Please migrate it to use ResourceLoader.  See <https://en.wikisource.org/wiki/Special:Gadgets>." load.php:156:624
"Gadget "NopInserter" was not loaded. Please migrate it to use ResourceLoader.  See <https://en.wikisource.org/wiki/Special:Gadgets>." load.php:156:624
Agreed, It seems a number of wikisource gadgets need migration as the error message states :( ShakespeareFan00 (talk) 09:33, 7 August 2015 (UTC)
https://www.mediawiki.org/wiki/ResourceLoader/Migration_guide_%28users%29#MediaWiki_1.26 - OK It's to do with the most recent mediawiki update. Nicce if they could have made this more obvious... ShakespeareFan00 (talk) 09:36, 7 August 2015 (UTC)
I have attempted to raise this at Wikisource:Administrators'_noticeboard#Special:Gadgets but currently nobody seems at home. Ineuw is complaining, so he is around... AuFCL (talk) 09:48, 7 August 2015 (UTC)
I have trimmed the duplicate entries from the console error log dump above, not noted in the heat of the moment.

Also I note some degree of recent experimentation concentrating upon the ocr.js entry in MediaWiki:Gadgets-definition. May I ask the motivation for the various change/reversion cycles? Because when a menu pathway is opened to access said Gadget (in my instance via the legacy toolbar) I believe the actual utility works fine, at least based upon my own dry-run trials. I must be missing an important point but as always will assist if I can. AuFCL (talk) 00:56, 9 August 2015 (UTC)

@AuFCL: second point first... please check WikiEditor again for the OCR button's presence (now found on the main toolbar) and the generation of the Proofreading tools bar. The problem all along has been the load order; one module fails to load because a dependency expected to exist by default or by the loading of another module hasn't taken place yet. This has always been the problem with the OCR button being generated separate (and thus "late") from all the other WikiEditor "buttons" and/or menus. I suspect everything will work now since I moved the button out of yet another separate "module", the proofreading tools advanced menu. Please verify.

I will look at what you've listed in the interim. -- George Orwell III (talk) 01:10, 9 August 2015 (UTC)

Now that is interesting (and I hope the result you had intended!) The OCR button is now missing from the legacy toolbar (no doubt because you moved it) and present at the top-level on the advanced toolbar. This makes me happy but will p*ss the bejesus out of Billinghurst. Not quite sure that is necessarily an improvement but it certainly will make for popcorn time if you choose to make a stand… AuFCL (talk) 01:23, 9 August 2015 (UTC)
@AuFCL: what about now re: classic vs. enhanced toolbars? And was there any change in the console list? I tidied the code for the first two but can't figure out why they are being reported if they (I assume) are not currently enabled in the first place. -- George Orwell III (talk) 02:14, 9 August 2015 (UTC)
Advanced. All functions seem O.K. (Zoom In/Out/Normal and OCR.) Console logging:
"Use of "wgNamespaceNumber" is deprecated. Use mw.config instead." load.php:156:624
"Use of "wgPageName" is deprecated. Use mw.config instead."
Legacy toolbar same.
Buttons are still being evaluated "late" compared with situation prior to 1.26wmf17 (I am not supposed to be noticing that but have a local script on my machine spots the order.) This last does not matter. AuFCL (talk) 02:26, 9 August 2015 (UTC)
Progress: looks like you've nailed the console logging with that mw.config.get change to NopInserter. AuFCL (talk) 02:59, 9 August 2015 (UTC)
Thanks again for all the help with this, @AuFCL: please check your console every so often & [re]list as needed. And I wonder if @Ineuw, Londonjackbooks: can verify your classic vs. enhanced toolbar & OCR button observations/findings. Is your desired toolbar working like before all this?

As for buttons loading "late" -- I can only guess its an unmovable reality in our case; primarily because the classic toolbar is part of the core while wikieditor is just a default enabled extension to the core unlike the Proofreading extension which is just WS specific (In short, I really haven't a clue). -- George Orwell III (talk) 03:00, 9 August 2015 (UTC)

All is currently functional under firefox (both toolbars...and the "Proofread tools" set is present. Console currently logging occasional repetitions of:
"Use of "sajax_init_object" is deprecated. Sajax is deprecated, use jQuery.ajax or mediawiki.api instead." load.php:156:624
"Use of "sajax_debug_mode" is deprecated. Sajax is deprecated, use jQuery.ajax or mediawiki.api instead." load.php:156:624
Those will probably be in MediaWiki:Dictionary.js, MediaWiki:Gadget-TemplatePreloader.js or MediaWiki:Gadget-massdelete.js per task T55120. I just don't know how to convert the deprecated sajax bits to jQuery.ajax is all -- will need external help with those. Plus the massdelete one might be moot if they ever get around to resolving task T108501 as per the Admin noticeboard consensus. -- George Orwell III (talk) 04:20, 9 August 2015 (UTC)
The "late" remarks stem from my usage of a firefox extension called Greasemonkey which is supposed to "sense" (I have no idea how) page load completion to ensure end-user javascript execution is delayed until it can act upon the page as finalised. This used to work fine prior to the latest wmf17 release but is now launching local activities before button "click" events have been populated. I repeat this is not a showstopper merely an indication perhaps of the new reality. AuFCL (talk) 03:38, 9 August 2015 (UTC)
Probably of no interest whatsoever to anybody except myself just noticed phab:T108323 has been raised to address GM scripting. I am proud to state I had already figured out and implemented at least one of the "fixes" discussed so far. AuFCL (talk) 18:24, 9 August 2015 (UTC)
This seems new in the console (at least I haven't noticed it before):
"Use of "skin" is deprecated. Use mw.config instead." load.php:156:624
Huh? That's a new one on me - probably just needs the addition of another mw.config.get(). Any clue to which "file" might hold that now deprecated bit? -- George Orwell III (talk) 04:20, 9 August 2015 (UTC)
I thought it might have been something perverse like looking at Notifications from "Mobile view" but just retried that without recurrence? Still looking... AuFCL (talk) 04:51, 9 August 2015 (UTC)
Dammit saving that last message just triggered it again. I wonder if it is the result of some javascript cleaning up as it dies? AuFCL (talk) 04:54, 9 August 2015 (UTC)
Please do not have a heart attack as a result of this but the error points to [2], specifically the line commencing trackCallbacks.add(handler);. (There is only one occurrence of this string in the code but as to what it indicates I cannot even guess.) AuFCL (talk) 05:07, 9 August 2015 (UTC)
@AuFCL: Well I just modified a bunch of .js files that had skin called in them so let's see if things are any better in a bit. -- George Orwell III (talk) 05:24, 9 August 2015 (UTC)
I saw that and haven't seen any more recurrence of the log entry for a while. (I guess you already know this but the sajax entries point to the exact same "trackCallbacks.add(handler);" line, so that seems to be the outstanding hint? And does not obviously seem to be preventing anything 'working' as far as I can tell.) AuFCL (talk) 05:30, 9 August 2015 (UTC)
I don't find anything broken even after that last batch of skin changes either even though I went with (mw.user.options.get( 'skin' ) instead of the "recommended" (mw.config.get( 'skin' ). I guess time will tell if there was any wisdom in that.

I can't do much with the compiled load.php since it's intricacies are beyond my skillset, but I suspected callbacks always played a role in the load order somehow so it might be relevant to the RL thing. -- George Orwell III (talk) 05:41, 9 August 2015 (UTC)

I totally agree regarding suspicions and (regrettably my own as well) limitations on ability to make any sense of that dense code, though the use of callbacks does support my disquiet that it is clean-up/teardown code which is "discovering" a problem long after the causal trigger. If the load order changes one of two things are certain: either the whole problem will suddenly go away, or things will seriously get much much worse. Are you a gambling gentleman? AuFCL (talk) 06:12, 9 August 2015 (UTC)
Agree; we've been lucky enough to fall on the "no problems seen" side of things more often than not but its just a matter of time before something major breaks. I'm just afraid things will be so far gone at that point that fixing it will not be simple matter; its more like a complete overhaul or a total abandonment will be the only solutions then.

Anyway, thanks again for all help and input. I'm looking to grab a bite, forget all this and get some rest but will definitely re-visit this tomorrow. -- George Orwell III (talk) 06:34, 9 August 2015 (UTC)

Kicking myself for making that gambling remark earlier and not advancing the view it will not be 50:50 odds. In fact if it wasn't for your efforts I know there would be a small mutiny by now so in case not already bleedin' obvious: THANKS! AuFCL (talk) 18:24, 9 August 2015 (UTC)

┌─────────────────────────────────┘
This is what I get now. It's still missing the 3rd set of tools which contain the text magnifier, the opening & closing of the headers and switching between over/under or side by side proofreading. — Ineuw talk 03:16, 9 August 2015 (UTC)

I know this is old advice. Purge local caches and see if this changes? AuFCL (talk) 03:38, 9 August 2015 (UTC)
Nah, I doubt its that - otherwise the OCR button wouldn't show being "moved out" to the other toolbar. <sigh> I swear it might be easier to just buy I-man a laptop that's up to date & has BIG screen just so he'll stop being the 'exception to the rule' at almost every turn. :) -- George Orwell III (talk) 04:20, 9 August 2015 (UTC)
Them Northerners can get nasty if'n you riles 'em enuff.] AuFCL (talk) 04:31, 9 August 2015 (UTC)

Log Events[edit]

Thought I'd better hive off a new section to try to concentrate things again. New javascript log error turned up today:

TypeError: div_pagenumbers.offset(...) is undefined index.php:288:10

—this time pointing into MediaWiki:PageNumbers.js. I believe I was creating Sheet metal drafting/Chapter 3 at the time so perhaps this is an example of the module loading order firing before the DOM build has completed? May just be a one-off. AuFCL (talk) 19:11, 9 August 2015 (UTC)

I got this to happen once more (but not subsequently, so it is delicate.) I believe the trigger is to create a brand-new main-space page containing a valid <pages> directive and Preview the result before initial saving. Subsequent Previews do not trigger the log; and neither do pre-existing pages such as Sandbox. Something to remember even if not worth following up at present? AuFCL (talk) 19:32, 9 August 2015 (UTC)

And another one:

ReferenceError: APIsharedImagePagePreviewHTML is not defined api.php:1:4

The linked page in this case looks like (definitely my impression) a JSON dump of the wikicode content of the current Page: being edited. Tentative trigger (can't currently reproduce at will) may be use of PageNumber link back from main-space transclusion result back to Page: space? AuFCL (talk) 19:50, 9 August 2015 (UTC) Got it! The trigger appears to be whenever {{FI}} is being invoked. Detail of the page referred to is e.g. [3]. I am unclear whether the error is at the WikiSource or the Commons end of the request, but clearly the link itself appears valid (why do we need Common's wikitext in any case beats me; surely we want the image blob and that is all?) AuFCL (talk) 21:16, 9 August 2015 (UTC)

The pagenumbers one seems "harmless"; I haven't a clue how to "fix it" either way. The second one is out of our hands -- there is nothing API specific being used in the FI template afaict. -- George Orwell III (talk) 21:29, 14 August 2015 (UTC)
Welcome back. I agree it is harmless and beyond our scope to fix anyway. Over the last few days I have been noticing a smallish variety of javascript log entries which appear to originate from API calls (all cross-wiki stuff; mainly to Commons) which carry a &callback= specification. I am beginning to suspect because this parameter holds the javascript function name to invoke when the rest of the data is gathered together this amounts to a warning that the versions of mediawiki on either end of the request/response don't match and some system monitor is going "that is nice, other system, you went to the effort of collecting all that data I asked for but I didn't want it anyway."

Once (if ever) all software versions resynchronise across the cluster (wonder if anybody has remembered HHVM or whatever it is called now?) I expect this stuff will magically go away. Either that or somebody will finally realise the internal network fabric is pushing around an unnecessarily large proportion of useless traffic—as if! AuFCL (talk) 21:57, 14 August 2015 (UTC)

Template:Illustrator[edit]

I am planning to go back and (start to) grab cases where we have works with illustrator and wrap them up in a template with some vcard components. If we ever agree to add them into the {{header}} template, then we have components set. Can you please check that I grabbed the bits and set them right. Thanks. — billinghurst sDrewth 05:36, 9 August 2015 (UTC)

I have no objections to what you have but do kind of consider the whole vcard/fn thing rather pointless now with the arrival of Wikidata in the mix. The problem is those kind of template parameters (such as illustrator, editor and the like) should be properly defined 'messages' in the main MediaWiki default message set. The way we run things now depends on sister projects or fellow language domains to design and implement their equivalent templates the same way we do and we both know that's just not the case. Add to that lack of ease in translation in some cases and all we've manage to accomplish is the continued reinforcement of a flawed approach to all this.

In my view, the current header template's parameters all need a revisit & review in regards to becoming proper MediaWiki (namespace 8) messages -- not to mention the further redesign of the basic layout of the template so it can be "flexible" enough to become an Wikipedia styled infobox in mobile view if need be (mark my words, that is what is being envisioned for the right hand margin in Mobile View depending upon the viewport available). That first step can also go along way in beginning to resolve the works vs. editions issues touched upon elsewhere (Wikisource-l among them where I see you yourself brought up that same "problem" recently). -- George Orwell III (talk) 06:02, 9 August 2015 (UTC)

Londonjackbook's toolbar buttons[edit]

May I have a quick sanity check please? As you know I've been thinking of load issues and it occurs to me the active code out of her (old) common.js:

/** Check that the required mode and modules are available. Then, customize */
if ( $.inArray( mw.config.get( 'wgAction' ), [ 'edit', 'submit' ] ) !== -1 ) {
	mw.loader.using( [ 'user.options', 'jquery.textSelection' ], function () {
		if ( mw.user.options.get( 'usebetatoolbar' ) == 1 ) {
			$.when(
				mw.loader.using( ['ext.wikiEditor.toolbar'] ),
				$.ready
			).then( customizeToolbar );
		}
	} );
}

—is checking for wikiEditor load completion, when in fact because Vector provides at least two icons she is expecting to appear this code ought to in fact be awaiting both Vector and wikiEditor to have finalised. (I don't even know how to check Vector states, so any hints appreciated!)

Waiting for the entire DOM population to complete as you are probably aware is unacceptably long (imaging for example a page containing a large image; most users won't tolerate waiting 30 seconds for the Preview to load—before button processing commences if we settle for this case—when they have already scrolled it off-screen to validate the text component.)

Any thoughts please? AuFCL (talk) 23:13, 14 August 2015 (UTC)

Sounds like you're coming to realize WikiEditor's inherent flaw(s) just like the developers are when it comes to WE building it's default button & menu sets and the need to modify that default locally after the fact. I see there was some movement addressing that this week so the status of things seem to be in flux at the moment.

Regardless, I can't seem to get the point across to the higher-ups that there really should be a way to "hook" into the "default" creation at the point after the containing framework, layout and edit fields(s) are generated but before any buttons are actually added to the default sections to allow local users to override/amend those options/menus with their own custom replacements. This nonsense where we have to let the entire extension finish building only to tear it down & rebuild it to some degree at the local level seems fraught with timing and loading pitfalls no matter how we try "organize" how & when the load order executes.

b:MediaWiki:Common.js, b:MediaWiki:Common.js/Toolbox.js might hold a better approach but I've only just begun to analyze it when you posted. -- George Orwell III (talk) 23:32, 14 August 2015 (UTC)

Well that is me all over, chasing the bandwagon. Just sign me up for the mandatory allocation of Kool-Aid come the day. Thanks for your time & effort. AuFCL (talk) 23:39, 14 August 2015 (UTC)
See? You say one bad thing about mediawiki and enWS, Meta, enWP fall over in shock… AuFCL (talk) 00:33, 15 August 2015 (UTC)

This may be a useful tool[edit]

This may be a useful tool for javascript coders unless, you already have this, or something similar. — Ineuw talk 03:02, 20 August 2015 (UTC)