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

Paragraph breaks with the fs90 and fs85 templates[edit]

  • To my HH, (Hungarian Homie), aka GO3.
  • Thanks for THIS LINK, & the font size and line height info provided below.
  • However, the purpose of my paragraph examples below was to demonstrate the lack of a paragraph break in the User namespace, as opposed to THIS PAGE in the Page namespace, where an empty row is sufficient to separate two paragraphs when using {{fs90/s}} — but not with the {{fs85/s}}. I am aware of the <p> but that's not what I was looking for.
  • I attribute these to changes in the font dimensions and the line height you indicate below, which differ from my earlier calculations.
 
  • By GO3. Baseline (i.e. post Vector Typography Refresh) is a 14px font-size with 22px line-height (plus top & bottom margins @ 7px each when Paragraph tag is in "play")
  • By GO3. {{fs85/s}} = [calculated] 11.93px font-size, 13.0px line-height

1. Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

2. Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

 
  • By GO3. {{fs90/s}} = [calculated] 12.6px font-size, 15.0px line-height

1. Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

2. Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

  • By GO3. ... and fyi {{Dhr}} = [calculated] 14.0px font-size, 15.0px line-height

Ineuw talk 19:49, 16 March 2015 (UTC)

I noticed your correcting my omission above, but that is not what I get on THIS PAGE. When you have the time and pleases you, please look at this. Thanks. — Ineuw talk 19:41, 20 March 2015 (UTC)

WikiEditor toolbar is loaded twice when editing - phab:T93384[edit]

Hi GoIII, I read your problem on phabricator. I had the same problem on Italian Wikiquote. I think I solved it (I don't know how, but it works!). I copied your common.js on my global.js and I fixed it - see diffs. It seems ok now! Check it out and let me know if you have problems again. -- Please, answer here or on my Meta talk page. Thanks. — FRacco (talk) 10:33, 30 March 2015 (UTC)

This is also happening to me when starting a new post - but so far, not in the Page namespace. I get two edit toolbars, one on top of the other. — Ineuw talk 19:31, 2 April 2015 (UTC)
They are still dickin' around with ways to try and support both the new "tracking" and generating a single toolbar (see https://gerrit.wikimedia.org/r/201004 for example) and can't seem to grasp the idea of deploying "fixes" for this asap. We'll just have to wait for the next scheduled update to see if that and one or two other patches manages to rectify this. Workarounds (like my previous and FRacco's above) would work but I just don't see the point of applying them when they are not fixes; just workarounds. Fwiw... it occurs less & less in the various namespaces as time passes & not in the Page: ns at all for me as well. -- George Orwell III (talk) 20:16, 2 April 2015 (UTC)

Your new menu scheme in Vector[edit]

@George Orwell III:. I think you should introduce it to the community. It's working fine and I really like it because it eliminates the clutter one constantly sees. FYI, a selected menu group does remain open when switching between namespaces which is good. — Ineuw talk 19:39, 2 April 2015 (UTC)

@Ineuw:: It shouldn't stay open even on a simple refresh - the cache mechanism is no longer in the gadget's .js. Part of the reasoning put forward by developers in removing collapsible menus from the original sidebar default in the first place was the fact the caching was frequently "over the top" by the time User:s added their own customizations/gadgets/etc. so I followed their lead for fear of the same "reprisals" for the Flat-List. No big deal - its just odd that you're seeing a pinned open menu stay open from one page or action to the next. Could it be something browser specific and I'm just not able to get that behavior under Win 8.1 / IE 11 or something? -- George Orwell III (talk) 20:33, 2 April 2015 (UTC)
As usual, thanks for reminding me about my browser collectionA Smiley.jpg Will try in a short while.— Ineuw talk 20:35, 2 April 2015 (UTC)
@George Orwell III: The selected tabs remain open in all browsers regardless in which namespace I switch to. It displays the open tab in context of the namespace and as I left it when exited. The moment I log in, I get my last menu settings of the namespace I was or even when I exit from the user namespace and when I log back and select the page namespace from my contributions I still get the menus as I left them. It's definitely not browser specific. Browsers I tested were - Firefox, IE 11, Comodo Dragon (Chromium) and Opera, all latest versions. Perhaps Wikisource stores them in cookies. I will test that too.
Deleted all the Wikisource cookies from Firefox (dozens of them) so I had to log in. Visited the My contributions list and the Navigation menu was open as I left it before cookies' deletion. I closed the Navigation panel and visited other namespaces, where everything remained closed except in the scriptorium the Languages tab is always open - cookies or no cookies. I hope it helps but what it's worth, I don't think that it's a problem it works well. I would still offer it because it's optional and you will find out soon enough if and when the s**t hits the proverbial fan. In the meanwhile I will keep on testing it - One test I forgot. "Does it stay closed?"@George Orwell III:Ineuw talk 02:06, 3 April 2015 (UTC)
@Ineuw:, the only thing I can think of that its the remnant of the previous Gadget, Collapsible Nav, which -- even if disabled in your prefs (which it should be if Sidebar Flat-list is enabled now) -- might still retain the previous menu state moving forward and that is what is getting in the mix there. If that is somehow the case, 30 uses (or 30 days?) and that cookie or those cookies should expire regardless. So 'enjoy it while you can' might be the case. If not - go with God; It seems like you just disproved this anyway. -- George Orwell III (talk) 02:09, 3 April 2015 (UTC)
And as far as any stubborn menus staying open like Languages - switch back to Collapsible nav for a sec and collapse all the menus manually before you switch back to flat-list - that might might work. -- George Orwell III (talk) 02:11, 3 April 2015 (UTC)
Hang-on... try setting you language to en instead of en-ca. I bet that's it. -- George Orwell III (talk) 02:17, 3 April 2015 (UTC)

┌─────────────────────────────────┘
Changed to en-English, closed the language menu in the Scriptorium and then, changed the preferences to en-Canadian and the menu remained closed. Also the en language wording should be corrected:

  1. en-English SHOULD READ en-yankee, en-gringo or at least en-US (default). Unless someone checks the list, it would appear to be English English (a minor but necessary change).
  2. In the Gadgets, please put the two related items below one another (it's not an alphabetic list).
  3. Your wording in the Gadgets is not clear, for example both menus collapse. Something like this:
    1. Vertical sidebar menus: Allow sidebar navigation portals to be collapsed (Vector only; Horizontal flat-list layout must not be enabled).
    2. Horizontal flat-list menus: Converts the sidebar navigation portals to a collapsible flat-list menus along the top (Vector only; vertical sidebar layout must not be enabled).

Sorry for butting in. :-) — Ineuw talk 02:56, 3 April 2015 (UTC)

Sorry for the late reply @Ineuw: Did as much Gadget "protocol" allows for per your recommended tweaks... but as far the language thing goes - that's all mediawiki controlled and part of the core software so there is little I can do about that. Plus the recommendation for some time now has been not to use the English subsets (ca, gb, etc.). As much as it is hard to fathom, the only reason they remain available options is the revolt that takes place every time the developers propose removing them in case you haven't witnessed one of those yet. -- George Orwell III (talk) 21:56, 6 April 2015 (UTC)
@George Orwell III: Don't worry about being late, I knew that you were out of the office. Whatever I wrote were only suggestions and the Gadget arrangement for the new menus format is fine. In am perfectly content with en English setting. Also looked up this link about the language codes I hope it's the right link.— Ineuw talk 04:35, 7 April 2015 (UTC)

page link in wrong place?[edit]

At The Lesson of the Master, The Marriages, The Pupil, Brooksmith, The Solution, Sir Edmund Orme (New York & London: Macmillan & Co., 1892)/The Pupil/Chapter 1, the "[124]" page link is in the completely wrong place. Any idea why, and how to fix it? Hesperian 12:43, 6 April 2015 (UTC)

Its position jibes with what I find in the Page: namespace. Are we sure this isn't something due to screen width or something? Even the "hover highlighting" starts and stops on the right word(s) between 123 & 124 here. -- George Orwell III (talk) 21:42, 6 April 2015 (UTC)
Works for me now too. It was wrong before! Hesperian 23:33, 6 April 2015 (UTC)
FYI @Hesperian: --- I did make a minor edit on whatever page 123 is (/137 ?) in the interim just to be sure - but either way I "saw it" correctly at first inspection. -- George Orwell III (talk) 23:38, 6 April 2015 (UTC)


Again at The Lesson of the Master, The Marriages, The Pupil, Brooksmith, The Solution, Sir Edmund Orme (New York & London: Macmillan & Co., 1892)/The Pupil/Chapter 5, with "[144]" completely out of place. Can you see it? I suppose it will disappear like the other one.... Hesperian 10:27, 11 April 2015 (UTC)

And now it's correct again! Hesperian 00:44, 12 April 2015 (UTC)
I would like to venture a theory. Please check how many options are displaying under "Display Options" next time you observe misbehaviour: does it contain three or five sub-elements? If five (being Layout, Page links displayed/hidden, Page links beside/within text, Page links displayed/hidden and Page links beside/within text) please log out, reload the misbehaving page and check again. Are there now only three sub-options (and incidentally is the display now correct?)
If the above behaviour applies may I suggest you log back in again, go to Preferences/Gadgets/Interface/Display Options and untick the selection (Yes I know that looks like you are turning the option off. I think the prompt text is misleading.) While you are there also ensure option Site is selected (Believe me you will not like the results of turning both options off…or perhaps that is what you do happen to have right now?) Anyway, I believe this will solve the problem at least until the next software change.
The technical details are tedious and I have only noted them down here on paper (will transcribe if anybody really needs them) but the quick summary appears to be a potential race condition between javascript loaded from bits.wikimedia.org and en.wikisource.org. First one to populate a structure called pagenumbers.collection wins the race and I'll bet it isn't always the version you necessarily want. AuFCL (talk) 06:01, 12 April 2015 (UTC)

Everybody is safe & welcomed on this talk page unless I say otherwise!!! Deleting from it in such a manner insults both myself & that principle. -- George Orwell III (talk) 23:13, 13 April 2015 (UTC)

Thank you for welcoming me, and my apologies if you felt insulted, there was no intent to insult. However you have in fact repeatedly failed to keep me safe on this page, so telling me I'm safe here is nothing but words. I won't be coming back here if your "principle" allows someone who has repeatedly and severely abused me to inject themselves into our conversations. Seeya. Hesperian 03:24, 14 April 2015 (UTC)
A quick review of this current page, my 2015 and my 2014 archives shows nothing to indicate your assertion is valid one. You two even managed to help each other back in June of 2014 in fact. So whatever it is that poisoned your relationship must have transpired elsewhere; places where I am merely a spectator at worst and a sysop at best; not the "owner" himself/herself.

I have come to value your participation across the spectrum of issues we may or may not be facing at any given moment to any given degree. I also value AuFCL's input and ideas in this same vein. I urge both of you to continue bashing my brains in here on my talk on whatever the issue might be at the moment - together amicably or apart in sections if need be but preferably never with angst, anger or animosity regardless. Fair warning however, I reserve the right to move or delete a discussion initiated here based on my best judgment [hopefully] with the principles given "in mind". -- George Orwell III (talk) 03:47, 14 April 2015 (UTC)

Browser display differences of the flat menu[edit]

Hi. I noticed a post but don't remember where, which mentions that the gear obscures the Language menu (when selected to display horizontally on top of the page). I knew about this, but waited to let you know because it wasn't all that important at the moment. Tested with "My" browser collection and it's partially obscured in Chrome/Chromium, Opera and Firefox, but not in IE 11, your favorite browser (which I think you should demote it to be your backup/test browser), Here is the requested image in Firefox. PS: since your work is focused on Wikisource, perhaps we should as the editors to list their preferred browser. — Ineuw talk 08:33, 8 April 2015 (UTC)

Wait, let me get this straight -- I manage to alter the reliable rendering of most of the 'skin' on-the-fly to render correctly in IE11 but I should "dump" it? Tsk... what am I -- European or something?

What about now? I think mistakenly margin-lefted when I probably should have padding-lefted in the original .css definitions. Again its not any particular browser at fault but another case of 'me' vs. the nutty wiki mark-up bunch. -- George Orwell III (talk) 11:41, 8 April 2015 (UTC)

It's still the same in FF and Chrome/Chromium, (says the former European). My point being that IE is not only on its out, but MS always did (or tried to) do things differently. I am offering to set up yet another browser survey to find out what is this community's favorite browser for editing. — Ineuw talk 14:51, 8 April 2015 (UTC)
Blah Blah Blah 'Browser love' is so 2004. Padding is padding; nothing special there & all current browsers should handle that with ease. If it didn't move its because of the stupid manner and/or the values this particular [wikified] css loads and nothing else. I tried one last thing that I could think of - after that; somebody who is affected by the overlap needs to give me the css needed to resolve it. Sorry. -- George Orwell III (talk) 15:09, 8 April 2015 (UTC)
#p-lang-label {
        display:inline-block;
}
"fixes" Firefox 37.0.1 for me. Might be worth chucking into the mix in MediaWiki:Gadget-FlatSidebar.css perhaps (if it works/does not screw up in any other browser)? AuFCL (talk) 20:29, 8 April 2015 (UTC)
So far, so good here too.

And I don't care what the other kangaroos might say, you're always of positive help to this project. Thanks again.

Looking forward I do hope that was the worst "problem" we see with this gadget - I can't see going back to "cluttered view" at this point. -- George Orwell III (talk) 22:07, 8 April 2015 (UTC)

You win again, works in all browsers. — Ineuw talk 23:12, 8 April 2015 (UTC)

┌───────────────────┘
Just in case this is not blindingly obvious I have written this here for your critical review (N.B. you may need a machete) before confusing everybody at Scriptorium. The following is very raw and certainly not ready for prime-time viewing. Back to the point:

Whilst by no means wonderful with regards friend Jpez "narrow screen overlap" issue might this be a hint as to a possible approach?

div#mw-navigation div#p-panel {
        position: relative;
        top: 0.33em;
        right: auto;
        float: left;
        margin-left: 9.00em;
        z-index: 100;
}
 
#p-personal {
    position: relative;
    float: right;
    top: 0.33em;
    z-index: 100;
}
 
#p-namespaces {
    margin-left: 1.5em;
    position: absolute;
    left: 10em;
    top: 15px;
}
 
#right-navigation {
    float: right;
    margin-top: 2.5em;
    position: relative;
    top: -45px;
}

Since both div#p-panel and div#p-personal live inside the container div#mw-head (already position:absolute) by overriding their individual existing position:absolutes back to position:relative and floating left and right respectively this solves the narrow-overlap case. The niggle remaining is of course div#p-personal ul has to carry padding-left:10em to cater for the case of really narrow screens potentially overlapping div#p-logo. The cost of not knowing how to address this is that the top two navigation toolbars will always be separated by at least 10em which I think I can live with.

#p-namespaces and #right-navigation are simply my ugly hacks at trying to recover the damage the above changes wreak on the bottom navigation toolbars. I am sure there is a better approach but today is getting too long for me to concentrate further for now. AuFCL (talk) 11:32, 9 April 2015 (UTC)

Just checking in b4 work takes over again. I should be free from it 2nite (~8hrs) -- George Orwell III (talk) 13:27, 10 April 2015 (UTC)
For what it's worth, everything is fine as far as I am concerned. unsigned comment by Ineuw (talk) .
No need to check in (you must earn enough to eat at least!) I want to make clear (to Ineuw) nothing I have suggested is currently implemented (so you won't see any changes at all; and in any case the issue I am trying to address concerns only what happens when the "screen estate" available is too narrow to accommodate the various navigation/edit toolbars) and (to GOIII) I am not trying to "force" a solution—indeed far from it—this latest proposal has some good features [if I say so myself] but also some major drawbacks and needs further thought/feedback/revision before considering it remotely acceptable. Forget it all (something has changed?) and the reason for this last discussion has gone away. It currently (maybe even not temporarily?) all works again without fiddling [with] the CSS. AuFCL (talk) 03:59, 11 April 2015 (UTC)
Forgive the lateness of my response - it was unavoidable until today...

The only explanation for this is the manner the Vector extension (fyi all the skins are pretty much stand alone modules at this point; much like any other extension just with a higher priority) is loaded then cached. I've noticed it has tendency not to fully "refresh" itself unless either a good amount of time passes or a major change in settings (like a core update) occurs). So its possible the full "override" of the default sidebar scheme does not take place soon after enabling the gadget but at somepoint a good time after that. Otherwise, I have no clue why things seem to be different in spite of the lack of any tangible "changes" being made in the interim. -- George Orwell III (talk) 23:22, 13 April 2015 (UTC)

┌─────────────┘
May I note your edit (however did you spot that connection?) and raise (I hope one final) niggle: enabling "Clock and Purge" still forces menu-lists to clash, but only by the width of the time-string. If it helps, I note the javascript modifies p-personal (I think) adding CSS for #utcdate. However I do not know why the width of this final list element is apparently not being taken into consideration. Is there a check (perhaps?) for #pt-logout being the last accounted-for list item? If there is I would like some hints as to where to look because this is about the point where I lose the thread. AuFCL (talk) 16:46, 6 May 2015 (UTC)

I can't take all the credit on that one. I received a suggestion via e-mail from somebody using the gadget on their own wiki about ...the lack of a Beta program... which let them "collide" properly with the Personal tool bar... no so called overlap that we have. I checked it out and she was right. Its still a "cheat" imho because -- as your clock issue indicates & to the best of my knowledge -- the width of the personal tools is not the trigger here; the left border of the right navigation area is.

My theory is that mediawiki (or Vector skin?) is using a @media rule (/*@media screen and (min-width:982px)*/) to cause a "trigger" rather than what we'd think it should be: @ the point of first overlap (e.g. shrink your display window to around 982 pixels wide; the left border of right navigation looks to me as 50% of the viewable area at that point - which also causes the "trigger"). So hiding the Beta menu shrinks the width of the personal toolbar to something less than 491px wide (50% of 982px = 491px) and gives the illusion that the left-border of the personal tool bar on the right and the gear icon's faux right-border on the left is the trigger point when its really the interaction between both the left & right navigation areas and the tabs they inconspicuously contain below that causes "something" (aka trigger point). AFAICT, the left & right navigation divs were designed primarily for Vector tab hosting and control - the personal menu thing and search bar came into their vicinity afterwards.

If the above is too much to digest at once as it is but have the urge to blow your mind further anyway, add h3#p-personal-label {display: block !important;} to your User .css. It "un-hides" an existing heading that -- if you go by the 'left-border/right-side touches right-border/left-side' logic -- will further help to confuse matters even more.

As for the UTC clock gadget - I don't use it. I use the "other" purge gadget that places the options in the existing drop down menu (where "move" is found) instead. I was in the minority some time ago when it came to separating the two features (completely different dependency modules/API in play in a nutshell) so I'd have to take a look at it again after all this time in order to give you an assessment proper (not anytime soon; sorry). Who knows -- maybe enough time has passed to re-visit the notion of reworking/consolidating 'clocks n' purges. -- George Orwell III (talk) 22:21, 6 May 2015 (UTC)

No. None of that really surprised me (though of course I thank you for bothering to read my blather in the first place.)

It looks to me like we two are at at least equivalent levels of understanding in this particular issue. In particular if either of us figure out the left-right trigger point you mention above please let us undertake to mention it to the other as my feeling is that will be a key moment for us both. Perhaps a dive into the Vector morass might be worth while: better take a deep breath!

Tried your mind-blowing reveal hack, only to realise I already knew about those dopey hidden-label ids (stylistically the damn things are everywhere; some script I have not yet isolated must enable/hide them as pseudo-drop-down-menu-titles. I am terrified this functionality might be buried within jQuery itself which frankly I find near impenetrable. Maybe the very fact #p-personal-label exists reveals our entire problem is rooted in a menu-hierarchy which is not being launched from its "designed base level"?) AuFCL (talk) 01:11, 7 May 2015 (UTC)

One further note: I should clarify I am in no way wedded to the UTC clock gadget. In an earlier discussion I think you mentioned a desire to correct issues "properly" as opposed to merely hiding all the deficiencies: a stance I hope we continue to share? My raising of the clock oddities was simply in hopes (now dashed) of provoking a "Aha: stuff can appear there!" moment. (Probably along similar lines to your LSD-like suggestion re. the #…-label stuff?) AuFCL (talk) 01:26, 7 May 2015 (UTC)
I'm a bit indifferent on the hiding point in this case (beta link) only because it's inclusion can be construed as redundant to the presence of the Preferences link -- save exactly the one additional click needed to get to one's Preferences / Beta tab. And, as it stands today, the Beta link is not flashing or changing colors every time a new Beta is added or updated -- even worse; removed -- so I'm not all impressed by arguments to "save it" at the moment. Of course I intend to find a solution other than the cop-out hiding it - if possible but you alluded to the greater issue impeding our progress - Vector itself!

Do you really want to dive in and "begin to see" just how deficient the Vector design really is & how deep the problems are? If yes: just add...

*:empty {
        background: lime;
        min-height: 0.1em;
        min-width: 0.1em;
        visibility: visible;
}
*:blank {
        background: blue;
        min-height: 0.5em;
        min-width: 0.5em;
        display: block;
        visibility: visible;
}
... to your local css file to reveal all the itty-bitty, teenie-weenie, work-arounds that "add-up" to throwing expected html behavior off at some point or another. Please note: deficiencies revealed that are "larger" than the ~tenths of an em forced by the above are already part of the document tree and do effect layout calculations more often than not!!! -- George Orwell III (talk) 02:03, 7 May 2015 (UTC)
Oh.. +fair warning: if you visit, edit and/or save page under the forced settings and mange to "freeze" yourself out from navigating and the like, just log out and leave me a note to disable the additions above. -- George Orwell III (talk) 02:03, 7 May 2015 (UTC)

Warning: The following below was written before your last couple of posts and represents a recovery from an edit conflict. Apologies—as ever—if I am raising a matter you have already addressed and I simply have not yet absorbed…
Let's try a different approach. Ignore UTCclock (I've turned it off for the duration of this test.) Set your display width to the smallest practical width which keeps div#p-panel from overlapping div#p-personal (only of course this is but a visual effect because of course they do: apparently by width of div#p-logo: is that significant, or merely a false observation?) Anyway: visual rules; no visible overlap but close as possible.

Now hover your cursor over either "Navigation" or "Tools", either of which menu titles contains content wider than their respective menu headings. Does the "Languages"+Gear heading now overlap the UserID entity under I.E. (as if certainly does in Firefox)? If so your li#pt-betafeatures is not the complete solution hoped for? If not then there is a difference in browser behaviour and perhaps that might spark a different line of investigation?

Repeating the above sequence whilst editing (as opposed to browsing) a page gives me an entirely different case: whilst edit-is-pending the two toolbars remain separated by blank space wide enough to accommodate hover-sensitive-expansion. What is going on here? AuFCL (talk) 02:17, 7 May 2015 (UTC)

┌─────────────────────────────────┘
Lime green (only needs purple and I shall feel twenty years younger. Might be just an au-corporate thing?) Thanks for the kind offer of recovery in case of severe borkage. Much appreciated! AuFCL (talk) 02:30, 7 May 2015 (UTC)
All my "best" testing to date points to the damn site logo in its current incarnation as the major roadblock to a final, well designed, universally accepted, trouble-free Gadget here. Now you and I can live without the logo just fine and 97% of these quirks would no longer be an issue for us BUT the lack of a site logo -- even due to a user selected gadget -- is frowned upon to put it mildly so we are forced to have something for a site logo as a rule (right now its the original logo -- using the same convoluted +160px, -160px positioning scheme tweaked to chop off the iceberg graphic and just display the word Wikisource that is embedded in the graphic; its not text.

Even before any changes or gadgets are applied, this graphic/logo is designed to be the top of the Vertical sidebar and has no real relation to its Horizontal head[ing] counter-part across the top other than overlapping the horizontal at the top-leftmost corner of the layout. Since the gadget's aim is to get rid of the sidebar and transferring its content to the flat-list, the current [re]use of the entire graphic is problematic if not pointless since only the text is to be displayed in the final rendering (see the Winter prototype of the "future" again - they achieve pretty much the same result as we do with hiding the original graphic + text .png file except they swap in or out the existing .png logo of graphic + text with a 2nd another .png of just text as needed.)

What I've come to envision after coming to point the finger of blame at our graphic-based log is...

  • find the damn font used in the current logo and substitute the graphic with our own 32px high by 160px wide simple text that resizes itself on the fly as need per user's setup; or
    • make a 32px high by 160px dynamic .svg of our own that will also predictably re-size itself as needed and use that as a substitute for the existing .png instead. This would retain a left most vertical sidebar "area" but only for the height of the .svg itself. Anything below that image's height would "float"? under it until it came up against the layout's left border.
  • Next, take either option of the above and...
    • make it the 1st of three horizontal cells from left to right (text-based-logo + flat-list + user-preferences) while keeping the faux padding that allows the flat-list to jump-down when things get crowded along the top; or
      • add it to the flat list as a faux first list-item of the flat-list menu itself and do away with the current absolute positioning all around. With the proper padding, the trigger should then execute well before the gear and the man are even close to each other - never mind overlapping each other. the 10 or 11ems directly under the current logo would -- in theory -- become available free space where the flat-list current does not "go".
Now I suck at graphic design so there is no chance I could make the dynamic .svg replacement -- forget about mirroring the current typeset font in plain old text -- so here we are looking for alternatives to the most straight forward & robust solution [apparently] to this issue instead. IDEAS? -- George Orwell III (talk) 03:30, 7 May 2015 (UTC)
Guilty as per last as well and agree with all alternatives you laid out above that. In short: stalemate! (On the other hand, my æsthetics are so poor as to make it extremely unlikely I shall be at odds with any solution eventually proposed.) AuFCL (talk) 03:46, 7 May 2015 (UTC)
Deep-6 the beta issue: long since identified as a (relative) non-event. Let's try to concentrate on a "correct" solution (in an imperfect world; no real sense in returning to LCD squalor?) AuFCL (talk) 05:26, 7 May 2015 (UTC)
Agreed. Found the font Linux Libertine in question and am beginning to play with the possibilities. A.) has to fit width-wise into the slot of the current .png (I believe is 160px or 10em) and B.) has to be at least? 32px? high (whatever it winds up to be must be divisible by 4[px] as long as baseline font-size is 16[px] --> means we can easily apply .25 .5 .75 em values and they will work nicely even if original calculated value(s) were in pixels). -- George Orwell III (talk) 05:37, 7 May 2015 (UTC)
I am still bogged down in jQuery-world without any useful progress worthy of report. Saw some of what I assume were the experiments to which you refer above at User:George Orwell III/Font‎‎ and have taken liberty of adding a suggestion. As ever, if this runs counter to your thinking please just delete my section. AuFCL (talk) 10:46, 8 May 2015 (UTC)
@AuFCL: That is good stuff - I didn't realize the dbl-V(W) was a glyph so I'll incorporate that into my further testing. At the same time, I ran down the original site-logo actually being called ( https://en.wikisource.org/w/static/images/project-logos/wikisource.png ) and it turns out it's dimensions in reality are 123w by 154h pixels but it's container element (div#p-logo) is the one "set" to 160w by 160w pixels (more exactly; 10em wide by 160px high in the .css). This means we need to account for two more considerations.

First, the actual width of our all-text replacement or new logo-image does not have to be exactly 160px(10em) wide as I/we thought initially. Our replacement can be any width up to 10em(160px) wide and, as long as it is centered somehow, div#p-logo should accept anything we substitute there with some minor .css adjustments at the most. The question of what the height of our replacement should be remains in flux. I believe it should be 2x the default line height (16px * 2 = 32px) but that too may not be the optimal height-length value in the end for our replacement, it's div container or both.

Second, I found the current use of em for width but px for height in the .css odd because any use of px typically inhibits any resizing (zooming is a different story however). I'm going to see what happens when I apply all em values for the ones currently in pixels as an aside that might be helpful in moving forward on the replacement front. -- George Orwell III (talk) 21:28, 9 May 2015 (UTC)

Fun Facts (Q&A?)[edit]

  • Did you know that whilst in Preferences, Sidebar Flat-list appears to be ineffective? (Is this by design or simply a good accident?)
  • Should Sidebar Flat-list BETA be enabled in conjunction with Sidebar Flat-list, or only if the latter is disabled. Perhaps the blurb should make this distinction clearer?
  • Want me to shut up about this sort of issue? AuFCL (talk) 05:47, 10 May 2015 (UTC)
  1. Most any addition/change to the current skin's defaults won't show in Special:Preferences - just try to enable the simple collapsible navigation menus gadget and you'll see they won't work on those Special:Preferences pages as well. I don't if that is by design or another happy mistake.
  2. separated but will be removing by Monday anyway. Pick one or the other; not both.
  3. For things like point 1: No. For things like point 2: Yes. (trying to work "under the radar" there)
George Orwell III (talk) 14:47, 10 May 2015 (UTC)

Regarding various macropods[edit]

Thank you for your kind words. This is probably largely a fault in myself but I have come to the sad conclusion there are people I like working with; those I do not, and finally those I would unrepentantly damn to the 33rd circle of Hell and then be disappointed there were no more levels below. Fortunately most of those who have evinced interest in your latest gadget fall into category One. AuFCL (talk) 06:47, 9 April 2015 (UTC)

Move bot?[edit]

Do you operate a bot to move pages in the main namespace? Anandamath is actually named Dawn over India (as it's a translation) and it would probably be best to use the former as the page to list the various translations. The title on all the pages would also need to be changed. Plus, if we could add the translator, that would be a bonus. If you don't have a bot, just let me know. Thanks, The Haz talk 04:36, 11 April 2015 (UTC)

Yes check.svg Sorted Bot not needed for a mainspace move. Admins have a tool that lets us move subpages with a mainpage as well as suppressing the redirects. Beeswaxcandle (talk) 07:28, 11 April 2015 (UTC)
Great to know, and thank you! The Haz talk 02:52, 12 April 2015 (UTC)

page numbers[edit]

I'm not sure if this is the same issue marked above. If it is, then don't worry about it. Basically, since I started using WS about a year ago, I noticed that on some works page numbers don't "highlight" the correct text, so clicking the page number to edit the highlighted text ends up taking you to the incorrect page. However, I had also noticed that it only happened on some works and I wasn't sure what to make of it so have ignored it since. Nonetheless, now that I see it again, I just wanted to point it out. The example I'm thinking of: Ancient Ballads and Legends of Hindustan/Our Casuarina Tree. What do you make of it? Does it have to do with the formatting used in the Page: namespace? Anyway, I know you have a lot on your plate (and this is not nearly up there in importance for me), so thanks, and definitely no rush. The Haz talk 04:00, 15 April 2015 (UTC)

Works as expected when logged out and when logged in with (what I consider to be, at least currently) "correct" Preference selections. Have you tried the Preferences test/changes described in (disputed) section #page link in wrong place? above (I consider the acid test for the failure case is when five menu items appear beneath "Display Options")? AuFCL (talk) 04:28, 15 April 2015 (UTC)
I finally realized the extra unintended availability of not-ready-for-deployment of the Gadgetized version of Dynamic Layouts and removed it from the list of Gadgets - belated thanks AuFCL - so we don't / shouldn't have to worry about that interfering with "normal" operations anymore.

And for future reference, I only manage to maintain mediawiki:PageNumbers.js at best; others with more scripting knowledge have pitched in over the years to try to make it reliable. Before some of you arrived here, for the first two or three years after "roll-out" only the toggle between the 3 or 4 defined layouts was functional. Even then, only Layouts 1 & 2, render reliably across all the major browsers.

Personally, I'm torn between finding a "better" way to adjust layouts on the fly or somehow refining the existing approach, but since I'm not the scripting guru needed for either, the most I can do is experiment. Any help on this front would benefit everyone in the long run btw. -- George Orwell III (talk) 22:07, 17 April 2015 (UTC)

Just tried them. No luck. I didn't have it enabled anyway, but I tried all combinations of the above. Three display options and it displays incorrectly while logged out or in. The Haz talk 04:56, 15 April 2015 (UTC)
Oh well. That's me out of ideas. (For reference works here under firefox.) Maybe suggest you detail browser for GOIII's benefit, but I'll drop out of this again. AuFCL (talk) 05:24, 15 April 2015 (UTC)
Sorry to infringe, but I have also faced a similar problem. Page numbers are not at all displayed at Researches on Irritability of Plants, although these are displayed in the subpages. Hrishikes (talk) 05:42, 15 April 2015 (UTC)
(For reference I was 58.166.112.186 edited the Index: page—omitted to log in.) I cannot fully explain why this behaves this way (perhaps pagenumber_id handling in mediawiki:PageNumbers.js—is that numeric only?) but removing the dot from "Adv." on the first page reference at Index:Researches on Irritability of Plants.djvu restores normal operation, for me at least. AuFCL (talk) 06:33, 15 April 2015 (UTC)
Yes, I have just removed the dot and now it's ok. Thanks a lot. Hrishikes (talk) 06:40, 15 April 2015 (UTC)
You're correct in that it works fine for me using Firefox or IE (would woulda thunk it?) but I normally use Chrome with Vector skin without any custom CSS (browser or WS). The Haz talk 20:41, 15 April 2015 (UTC)
I'm stuck with IE so I'm not seeing any oddities with the highlighting; Sorry. I don't know if it is possible when it comes to the highlight feature, but is there anyway to take a screen shot of what is happening? -- George Orwell III (talk) 22:07, 17 April 2015 (UTC)


symbols in {{page}}[edit]

I made my way over to Alice_in_Wonderland_(1903_film) today and noticed that the "page" numbers don't show as expected because of the colon in the time listing. Was this a change in the way they were handled? (I'm mostly just curious.) The Haz talk 02:22, 16 April 2015 (UTC)

This is merely a hint but could this (periods/colons in page ids decoding to "[undefined]") be a recurrence/mutation of the events discussed under MediaWiki_talk:Gadget-PageNumbers-core.js#Proper_page_number_decoding?

Also is it a concern/useful indicator that the Alice spans contain id fields as expected but no data-page-number values as implied should be expected by PageNumbers.js (incidentally: which one PageNumbers.js or Gadget-PageNumbers-core.js should be the current one executed? "Alice" appears to have Javascript events bound to PageNumbers.js whereas I would have expected the Gadget to be "more modern"?) AuFCL (talk) 05:26, 16 April 2015 (UTC)

Query: "Alice" directly uses {{page}} which is protected. Should this template be the point of population/filtering of data-page-number because right this moment it populates the span id field but does not even set data-page-number...? (Subsequent investigation: this seems not to help. Blind alley. Incidentally why do so many discussions end up with hints pointing to red links/moved pages or even one case of revdeled diffs? What is somebody trying to hide? Could it really be all that controversial or embarrassing? [Hope I am joking. I did not bother recording the references.]]) AuFCL (talk) 05:47, 16 April 2015 (UTC)
I'll have to take a closer look when I get the time but if memory serves me right, I doubt the two were ever designed to be compatible and only happenstance that the Page: and Index: namespaces recognized the video format(s) for faux transcription in the first place. One or two people ran with that without taking the deficiencies into consideration I believe.

Maybe one of the other projects like Wikibooks or Wikiversity have done better? -- George Orwell III (talk) 22:14, 17 April 2015 (UTC)

Makes sense. Also, I'm trying to figure out what the color-coded "legend" on that page refers to but it beats me. The Haz talk 23:42, 17 April 2015 (UTC)
@Hazmat2: I feel you are going to want to hit me for pointing this out but you did notice the "Key (info)" header points to Help:Film? As some of the examples quoted on that page indicate e.g. "[Eat me.]" ought to be coloured "[Eat me.]" in Page:Alice in Wonderland (1903) - yt.webm/5 (yet clearly is not) I might venture either @Einstein95: or @Theornamentalist: were still evolving a captioning style for moving images? (And yes, I am aware a response from Chris at least is not likely in the near future.) AuFCL (talk) 08:36, 18 April 2015 (UTC)
@AuFCL: Nah, I don't feel like hitting you, but I did see that. However, there was nothing on the page to suggest that it was ever coded to work, not even set up with CSS classes from what I saw. I just wanted to make sure it wasn't something that broke that would be a quick fix. The Haz talk 18:43, 18 April 2015 (UTC)
@AuFCL: Oh, I hadn't seen that help page when transcribing the text. I have since added the colour tags to the text for Alice in Wonderland. I apologize for not searching for a relevant help page in the first place. -Einstein95 (talk) 14:49, 29 April 2015 (UTC)

How to (globally) customise wikiEditor?[edit]

Regarding this discussion I am reasonably sure the traditional answer might have been to edit MediaWiki:Edittools but that approach has apparently been superseded. I am aware of the user-specific approach described at mw:Extension:WikiEditor/Toolbar_customization#Add_a_special_characters_page however where do the current initialisation tables live? Are we back to default software settings or are somehow drawing this cross-wiki (or worse yet have I simply over/under-thunk this matter?) AuFCL (talk) 00:21, 18 April 2015 (UTC)

'Too little, too late' may apply here. If you go through the Visual Editor Phabricator pages, you should be able to piece together the concerted push to implement VE here on WS. The first step took place about two weeks ago when the language character sets for both VE and WE were exported to a separate module under the premise they can be "shared" by both toolbars easier & more efficiently that way. It won't be long before the icons/buttons will also be of the oojs-type & shared by both editors too. This will be followed by VE offered as a Beta like it is now on Wikipedia. Finally the argument will be made to standardize VE here as well. I just don't have the free time to stress we pretty much don't care what becomes the standard as long as its customizable (i.e. not locked in & Wikipedia driven). -- George Orwell III (talk) 21:31, 18 April 2015 (UTC)
Thanks for a succinct answer.

I was perhaps 75% there and had uncovered a few VE tendrils but had shrugged them off as not relevant. Silly me!

(@Hrishikes: won't be best pleased, especially since my last comment on this matter had been tinged with a degree of gloom anyway.)

Good to see your input regarding customisations on task T91608. AuFCL (talk) 22:54, 18 April 2015 (UTC)

Sure and thank you (@AuFCL:) for picking up the slack until I got the chance to visit again.

Unless I'm mistaken - his issue is that the original character set for Bengal(?) in WikiEditor is/was incomplete right?. If so, he/we should open a new task requesting the entire set of characters, provided by "us", be added/amended to the current repository (-->I think is<--) specialcharacters.json -- which is currently found in the "core" IN HERE. This way, at least Hrshikes' issue is resolved in whatever the "standard" interface is now or will be in the future", shared or otherwise. -- George Orwell III (talk) 23:17, 18 April 2015 (UTC)

@George Orwell III, AuFCL: I have created a task here, but I don't know how to do it properly. Can you please look into it? Hrishikes (talk) 02:21, 19 April 2015 (UTC)
@Hrishikes: I took a stab at modifying it with the relevant groups & knowledgeable person(s) but it still might not have the routing, etc. it deserves so "we" should visit it at least once a day until at least the "viewership" has built up some. Eventually somebody who is more knowledgeable is typically drawn to the task that way & we'll go from there. @Ineuw: wasn't Hebrew screwed up or something recently as well? -- George Orwell III (talk) 02:48, 19 April 2015 (UTC)
Hi folks. I have subscribed also to show willing (and add to the viewership count) but have nothing particularly useful I can add at this moment. (In fact was that even a good idea as I seem to have a bad reputation for polarising loyalties?) AuFCL (talk) 03:16, 19 April 2015 (UTC)
I have added some subscribers, some are Bengalis (incl. steward & admin.) and others were involved in past tasks relating to Bengali font. Hrishikes (talk) 03:40, 19 April 2015 (UTC)
Just a quick heads-up folks (+@Hrishikes: Krenair has just updated task T96494 and tried to direct attention to Beeswaxcandle's edit of Gadget-charinsert-core which predates (at least) the addition of the ganda mark, and possibly also ্য.? Can one of the language experts please review and if necessary comment (on the phabricator page)? I have no objections to anybody wanting to make the update easier for themselves but if it is not complete then the exercise becomes a waste effort and use may well be made of the brief window of attention currently gained. AuFCL (talk) 21:29, 20 April 2015 (UTC)
Thanks GOIII for updating MediaWiki:Gadget-charinsert-core.js however (am I castigating a cripple equine here?) that is but half the fight bearing in mind this change explicitly lies outside the range of Krenair's link. I also fully support your comments on the task regarding the necessity of getting the language experts to fill in the details directly into the task specification (the very point I tried to convey above.)

At worst would re-expressing the diff as [1] perhaps be considered too sloppy? What about drawing up a non-graphic specification like &#2437;(অ) &#2438;(আ)…? AuFCL (talk) 23:46, 20 April 2015 (UTC)

Meh... this isn't Language central so please: let's move the rest of this to the actual open Task.

I copied the proposed set from the talk page to a .txt file, dragged it to the open edit window's textarea in Phab and submitted it once the automated "F" id assignment for the File appeared. I'm able to open it w/no problems but I'm not sure non-logged in users can (a good reason to get an account if not already). -- George Orwell III (talk) 00:02, 21 April 2015 (UTC)

GOIII / @AuFCL: Can you please add &zwnj; as mentioned in the talk page as well as the first item at http://www.fileformat.info/info/unicode/block/bengali/list.htm (the rest are already there)? Hrishikes (talk) 00:23, 21 April 2015 (UTC)
Look - why don't you create the set you want in a UTF-8 based .txt file on your desktop, then drag it to the Phab edit window to upload it. I'll delete the one I put up after I see yours. Follow?

Does anyone know if ZWNJ is supported in all wiki-supported browsers? -- George Orwell III (talk) 00:32, 21 April 2015 (UTC)

Thanks for adding anji (&#x0980;) in the task. As for zwnj compatibility, see the examples মিস্মি (without zwnj), মিস্‌মি (with zwnj direct entry) and মিস্‌মি (with code for zwnj). If you can visually appreciate that the first example looks different, then it is compatible in your system. I am really grateful for the help you have given. Hrishikes (talk) 02:07, 21 April 2015 (UTC)
The gadget should include everything now (zwnj is the last entry) but the bigger problem is making the revised set part of system default in the core's toolbars. Please follow that up under Task task T96494 or the current attention we happen to have there will dissolve quickly ... mark my words! -- George Orwell III (talk) 02:13, 21 April 2015 (UTC)

JSON[edit]

I have uploaded what I thought json format to the task. Can you please check? (I think the interest of others is already dwindling.) Hrishikes (talk) 07:49, 22 April 2015 (UTC)

@Hrishikes: There is an end-comma missing for the character right before the opening [ for the ZWS entry.

And whenever in doubt, use the online JSON verification tool - http://jsonlint.com/ -- George Orwell III (talk) 08:17, 22 April 2015 (UTC)

Ah yes, I found the error. Thanks for quick response. My computer connection seems to be out of order at present (I am doing this edit with my tab). As soon as possible, I shall correct the error. Hrishikes (talk) 08:36, 22 April 2015 (UTC)
Ashamed to admit I was unaware of the online tool. Most invaluable (and now bookmarked on all my machines.) I was previously relying upon a locally installed Perl-based demo which has 2KiB input buffer limitations—part of the reason I was ticked off specialcharacters.json is formatted as that one 10K+ line—it crashed anything I (previously) knew that could assist in verifying the thing! AuFCL (talk) 09:02, 26 April 2015 (UTC)

Low priority questions - just getting a bit curious.[edit]

Hi.

  • It seems to me that there has been some improvements to the font in the Page: namespace, both in reading and editing mode, it's a lot clearer and I like it. (It also could be that my eyesight is getting better with age). I assume that the font settings for the Page NS are embedded in the core program, because I couldn't find anything in the Common.js or the common.css. Is there a way I can see the font related settings? - I am looking at the web page inspector which lists ALL the fonts used or available, but how do I find the font-style, font-size, line-height setting?
  • I am also curious as to who controls the "Undo" memory size of the editing boxes? Is it the Wikimedia environment, is it the browser, or is it Windows? Can the number of "Undo" be increased.

Signed, Paprikás Gulyás. — Ineuw talk 07:41, 19 April 2015 (UTC)

(Showing my extreme ignorance: is that Poultry Goulash perhaps?) I am not sure if this is what you are looking for but under Firefox using Web Developer/Inspector/Fonts (right hand panel) reveals this edit session is using (for me) these fonts:
  • Georgia
  • Bitstream Vera Sans
  • Bitstream Vera Sans Bold
  • Bitstream Vera Sans Mono
  • DejaVu Sans
  • As you point out the font sizes and line-heights are not summarised there but in the "Computed" panel are revealed to be 14px and 21px respectively.

    I checked out a couple of random Page: pages (if that expression even makes sense) and for variation one used an additional font of "Bitstream Vera Sans Oblique" but dropped "DejaVu Sans" and "Bitstream Vera Sans Mono." Is any of this germane to your inquiry? AuFCL (talk) 09:55, 19 April 2015 (UTC)

  • <insert> "Poultry Goulash" is chicken for hungry Hungarians.—Maury (talk) 15:13, 19 April 2015 (UTC)
Thanks AuFCL. it's very much germane.
Important things first: It's sweet pepper Goulash, the pepper (paprika) being the Hungarian sweet pepper spice. see this link.
As for the fonts, check the default selected font & size in the browser Options\Contents\Advanced, as well as the settings in the WS Preferences\Edit. They affect the Wikisource page ns edit display. Mine is Arial for sans serif, and Courier New for monospace in the browser and 'Browser default' under user Preferences\Edit tab. This is what shows up in my Inspector right panel as well. This may mean that there is no font specified in the core, just the size.
Georgia is a font imbedded in Common.js for the main ns Display Layout 2 selection, which at 14 points is much smaller than Arial. — Ineuw talk 14:44, 19 April 2015 (UTC)

First, the only off-site "recent" change that I'm aware of isn't all that recent - Universal Language Settings' (ULS) font selector was reinstated on Wikisource awhile back (hover over the gear icon and open language settings to see the keyboard input and language selector features where Users can further refine the core settings.

Second, DOM explorer in IE 9, 10 or 11's F12 Developer Tools shows all the css settings, where they originate from, which get modified and/or superseded prior to final rendering in addition to many other on-the-fly capabilities to alter/test the current rendering plus the corresponding calculated values along with a graphical depiction of layout. Sorry - I know IE is beneath your tastes but I don't where else to get such exact info from (it literally made the flat-bar Gadget possible for me for example). -- George Orwell III (talk) 15:26, 19 April 2015 (UTC)

Much thanks GO3, very informative. Just noticed that the languages (gear) also contains font settings. . . . and some of what my eyes perceived, was correct. Wikipedia et al., did change the serif font of their websites (header, etc.) to "Linux Libertine" which is distinctively different from the previous font used. I found it by copying the code from the IE web developer, as I looked at it as well. The IE web developer looks very similar to Firefox' Web developer tools.
My criticism of IE is from a proofreader's viewpoint. I tried to proofread in IE, Chrome and Opera (being the fastest), but some of Firefox' extensions for proofreading are well thought out and sophisticated. In particular, It's All Text! and QuickWiki followed by Form History Control and Wired-Marker.— Ineuw talk 16:58, 19 April 2015 (UTC)

Djvu metadata[edit]

Hi. Any clue why https://commons.wikimedia.org/w/api.php?action=query&titles=File:EB1911_-_Volume_22.djvu&prop=imageinfo&iiprop=metadata&rawcontinue is not returning the text layer any longer? If I recall some previous discussions we had, this was supposed to return the djvu xml (structure + text). Actually, for some files, it still does (see https://commons.wikimedia.org/w/api.php?action=query&titles=File:Popular_Science_Monthly_Volume_20.djvu&prop=imageinfo&iiprop=metadata&rawcontinue). Bye— Mpaa (talk) 20:15, 19 April 2015 (UTC)

If I understand events correctly, there is some "major" change coming or already in progress(?) concerning the API (see T96595) so it might be that. The only difference between the two outputs that I can see is the one that has a null response also has a query-continue, image-info, iistart section with timestamp while the one that works does not -- do we need to close/end the 2010 query "[ii]start" or something? Yet THIS would seem to indicate it is not a factor.

Otherwise, I can only guess one version of the extension and it's dependent DjVuLibre revision was used in once instance and now either the extension files and/or the libre package has changed since then. I wish we could always be sure of running the latest DjVuLibre package but I never could get an answer where those files are actually hosted. Any clue? -- George Orwell III (talk) 22:08, 20 April 2015 (UTC)

CopyEdit does this --> https://gerrit.wikimedia.org/r/205328 <-- look related or what? -- George Orwell III (talk) 22:18, 20 April 2015 (UTC)
I do not think it is the query-continue, it is the same when I try to retrieve via bot (which handles it). Must be some other ongoing change as you say.— Mpaa (talk) 16:53, 21 April 2015 (UTC)
@Mpaa: just to note... neither output linked above reflects the current XML created for a multi-page .DjVu file when using DjVuToXML.exe locally. One strips the <PAGE value=... /> element out of the output entirely & the other somehow mashes up a plain text dump under the <PAGE value=... /> element instead of the expected character coordinate mapping generation for the embedded text. I'm guessing this is a result of poor decision making when developers are confronted with how or what to do with an embedded text layer when its "huge".

Isn't there some way to generate this XML and store it locally for each Index: under Page:SorceFile.djvu or Page:SourceFile.djvu/0000 instead? I'm thinking if that is possible, the text layer can always be pulled from that local repository instead always relying on Commons and / or the PR extension. Heck, it would make correcting the XML to some degree possible prior to Page: creation. I'm dreaming right? -- George Orwell III (talk) 21:57, 21 April 2015 (UTC)

The only way I can think about, is to do it downloading locally the djvu file, extracting the XML and upload it again. Or we might think to write a tool that does that on wmflabs, so we avoid the local download and let wmflabs network to deal with it. In some way this is a duplication of what phetools is doing (remember the link you gave me some time ago?). It is storing each page of a djvu file on wmflabs. You can see it following the link generated when you click on OCR here: MediaWiki:OCR.js, see this.--Mpaa (talk) 07:13, 22 April 2015 (UTC)
@Mpaa: riiiiight I remember all that 'jazz' now & it does seem to border on being almost the same as my desired result. Still, this issue begins with obtaining a "proper" result or output in the form of an XML file as per the .DTD included in the DjVuLibre package when DjVuToXML.exe is run on multi-paged .djvu source file. Creating that XML was dropped years ago from the DjVu "scheme" thanks to some bug that has long since been overtaken by new releases and/or upgrades all around. And its how we got stuck with this plain-text dump mentality early on and forced to work around that deficiency several times since.

My understanding (or vision?) is that only when that "proper" output actually results as expected in a "compliant" XML can move on to the issues of a.) how & where to store such XML-ish content per Index: or per source file; and b.) then how can we draw upon that stored XML repository for Proofreading purposes even text-layer improvement. To me, again, the first step doesn't seem all that hard to accomplish -- if we can use a DjVuLibre .exe to dump as we do now, why can't we use some other .exe from the same DjVuLibre package to generate that "optimal" .XML? -- George Orwell III (talk) 20:58, 22 April 2015 (UTC)

I guess it should be possible. Maybe we could involve @Phe: and see what he thinks. I guess it would not require a lot to exted his tools to add also the overall XML extraction and storage. In parallel I can continue my research ...— Mpaa (talk) 22:30, 22 April 2015 (UTC)

A question regarding Charinsert[edit]

There are now 20 sets including the 'User', in Charinsert. Would it be a difficult that each user defines their own Charinsert character set in their own Common.js beyond the basic sets? In other words would it be a complex problem if I were to copy the code into my common.js? I know that there are extensive discussions on Github, but it's too technical for me. — Ineuw talk 03:19, 22 April 2015 (UTC)

The community never chimed in on what the absolute minimum default sets should be for starters never mind the whining koala session that took place at the same time over duplicating not only the location of the old tool but the sets already existing in that old tool. The result was the over-blown & disorganized gadget we have now.

Originally, I wanted 1 or 2 default sets and let folks pick whatever else wanted on top of that via a sub-set of selections under the Gadget (if I got a hand on how to do that code wise that is). The other alternative was to make a help page/talk page that outlined how to add pre-compiled sets found in repository or a sub-page somewhere local to User:s common.js

If you're looking copy the gadget script to your local, User specific .js to eliminate/edit the current defaults - I don't know if that will work because of the dependencies, etc. afforded to scripts by the Gadget extension are not really mirrored when it comes to local User. js files (no harm in trying I suppose). You can add as many sets as you like however - as you probably already know.

If you wish to get this right, I'd totally support a proposal to revisit the current defaults and/or how to let users add sets on top of said defaults. I'd do it myself but I have whole machine gun clip of proposals to get to as it is in the near future and I don't want to risk appearing "overbearing" or whatever.

Finally, please note that WikiEditor and VisualEditor now share a single repository of character sets so it may come down to the CharInsert gadget using that instead one day soon. -- George Orwell III (talk) 03:42, 22 April 2015 (UTC)

Thanks for the info.— Ineuw talk 04:26, 22 April 2015 (UTC)
I cannot resist bringing your attention to this pair of links (pure time-wasters yet instructive to outsiders):
In short: real koalas don't whine (though I don't think that was the point you thought you were making.) AuFCL (talk) 07:30, 4 May 2015 (UTC)
Interesting but how about we let bygones be bygones? Thanks. -- George Orwell III (talk) 16:35, 4 May 2015 (UTC)
Oh noes! And to think I had mistakenly thought you were bright enough to realise the note was simply for you and your correspondents' amusement. No criticism of which you are not already aware was ever intended. The matter is now firmly closed. AuFCL (talk) 21:28, 4 May 2015 (UTC)

Spam whitelist[edit]

Proofreading Page:The_Fuck_Brief.pdf/4 triggers the spam filter for the tinyurl link. Could this page be added (and the link fixed as I inserted a space to save the progress)? -Einstein95 (talk) 16:48, 29 April 2015 (UTC)

Suggestion to improve the regex Search and Replace gadget[edit]

It's been so long since I bothered you, I had to think of something that may (or may not), be of interest to you and useful for proofreaders. From my perspective, the gadget for Regex Search & Replace has two major drawbacks. The easy one is that the gadget covers the text area completely. This, I am sure is possible to minimize and limit both areas to single line.

The second missing feature is, the ability to retain the parameters of both the search & replace until it's changed. I assume that this requires static space unique to the user that is always accessible to the gadget in any namespace. Please give it a thought. — Ineuw talk 19:19, 16 May 2015 (UTC)

That one is beyond my realm of abilities - I think you'd be better off asking Hesperian or Pathoschild. Sorry I-man. -- George Orwell III (talk) 21:20, 16 May 2015 (UTC)
Thanks for showing the way. — Ineuw talk 01:28, 17 May 2015 (UTC)
I thought that you might want to know that our regex S & R gadget is deprecated, and in its place there is the very neat Templatescript with all [my] requested features, simple instructions for its installation and use[s] included. The reason I mention this, that perhaps someone can add a link and a note by this gadget that it's deprecated and hope that the users will replace it with this current version.— Ineuw talk 22:49, 17 May 2015 (UTC)
P.S: My apologies, the link is already there by the gadget.— Ineuw talk 22:53, 17 May 2015 (UTC)
@Ineuw: well the link goes to the deprecated script which points to the improved script right off the bat. I just don't know enough about the old or the new script and how many folks use (or expect?) one or the other at this point in time to be comfortable enough to edit the current gadget entry. I know Pathoschild made an effort locally a few months ago to convert the known users of the old script to the new but that probably did not account for those users who did not happen to be "active" at the time nor saw the Scriptorium notice before it got archived.

What "we" need is accurate numbers on User: Gadget selections and (other than @Mpaa: magic?), that data is hard to come by. If we had it, we could notify those users still using the older script and update the current gadget blurb soon afterwards without worrying about leaving those Users who haven't logged into WS for some time 'stuck in the past'. -- George Orwell III (talk) 23:15, 19 May 2015 (UTC)

Thanks for the reply. I agree entirely with what you say, and I should get around to tell Pathoschild to better emphasize and direct new users to his current version, which works very well.— Ineuw talk 23:21, 19 May 2015 (UTC)