User talk:George Orwell III/Archives/2015

Please do not post any new comments on this page. This is a discussion archive first created in 2015, although the comments contained were likely posted before and after this date. See current discussion or the archives index.

QnA

I appreciate the effort but this whole section probably warrants being exported into whatever the equivalent of a private(?) project page (tripping over terms here, umm) is. That is, rather than occupying your talk page.

So please don't treat this next part as a discussion; more as an opportunity to define terms I am too stupid to currently figure out (if you like: feel free to let the list build up to answerable chunks.) —AuFCL (talk) 01:18, 1 January 2015 (UTC)

• transparent vs #hidden vs #transparent: ?

  well... ummm. You see...

  At some point in the past -- under some broken version of Windows and/or IE -- I was able to make border-conflict-resolution work seamlessly using that approach. Obviously, the OS & browser environment today no longer supports my approach -- but something always compels me to try adding it anyway (force of habit basically but not very helpful).

  Lets agree to worry about borders, colors & other non-layout-for-rendering elements/attributes after we get to the point where the 'three goals' mentioned earlier are nearly a reality shall we? Besides, mobile-mode seems to override any and all border settings with its own, single default. -- George Orwell III (talk) 02:02, 1 January 2015 (UTC)

Not so much "busted" as this little bunny playing catch-up is probably concentrating too much on the details and still missing too much of the big picture-like thing hanging in the sky… AuFCL (talk) 02:14, 1 January 2015 (UTC)

Politely please leave it

I am wanting to play and fix it, and the edit conflicts are a PITA. — billinghurst sDrewth 07:44, 3 January 2015 (UTC)

Okay, I have finished with it with regards to look and look with a little squeeze. A big squeeze fouls it up so don't try reading it on a small screen phone, though the other way was an image, and that wouldn't squeeze at all.<shrug> — billinghurst sDrewth 12:44, 3 January 2015 (UTC)

Autobiography of a Yogi

How does wikipedia prove that a publication truly is in public domain. The original publisher renewed the copyrights and another person/organization just started publishing it in the middle of a lawsuit. But the lawsuit was about other items. It was NEVER settled in a court of law.Red Rose 13 (talk) 10:38, 3 January 2015 (UTC)

And how if wikipedia is going to continue saying it is in public domain, how can we correct the wording because in reality the copyrights were definitely renewed on time. Just click on the links and see for yourself.Red Rose 13 (talk) 10:41, 3 January 2015 (UTC)

You can harp all you like but anything published before the edition in question (1951? 1952? whatever the definition of the 3rd Edition may be and as it relates to the date of the author's death for protections both inside & outside of the U.S.) are clearly within the threshold of falling into the Public Domain for (worst case) lack of 2nd renewal (best case) natural expiration of the 2nd renewal term.

If 1946 was the year of the original publication of the first edition, let us +28 years for 1st renewal term (1946+28=1974) plus giving the claimant the benefit of any doubt another +28 years for a 2nd renewal term (1974+28=2002) and noting the key date of works renewed for a 2nd term before 1976 do not get automatic 96 year protection from the date of the author's death, all boils down to the 1st edition fell into the public domain at the end of 2002 regardless of any mention or action taken in court or not.

Any edition that required a renewal date for a 2nd term that falls after 1976 got an automatic 2nd renewal and/or extension to 96 years after author's death if applicable.

You know this is why we don't host that last Chapter (49?) - the first appearance of that content was in the third edition and as long that 3rd edition was published in 1949 or later - the second renewal term's deadline date falls under the 1976 Copyright Act instead of the 1909 Copyright Act & automatic this, that or the other is theoretically still in effect. -- George Orwell III (talk) 10:55, 3 January 2015 (UTC)

Sorry didn't think I was harping. Yes I see what you mean and thank you for your detailed explanation. How can we change the wording to reflect what you said? Right now it says -

"This work is in the public domain in the United States because it was legally published within the United States (or the United Nations Headquarters in New York subject to Section 7 of the United States Headquarters Agreement) before 1964, and copyright was not renewed. For Class A renewals records (books only) published between 1923 and 1963, check the Stanford Copyright Renewal Database and the Rutgers copyright renewal records. For other renewal records of publications between 1922 - 1950 see the Pennsylvania copyright records scans. For all records since 1978, search the U.S. Copyright Office records. The author died in 1952, so this work is also in the public domain in countries and areas where the copyright term is the author's life plus 60 years or less. This work may also be in the public domain in countries and areas with longer native copyright terms that apply the rule of the shorter term to foreign works.

Works published in 1946 would have had to renew their copyright in either 1973 or 1974, i.e. at least 27 years after it was first published / registered but not later than 31 December in the 28th year. As it was not renewed, it entered the public domain on 1 January 1975."

This wording does not really define this situation. It was renewed in 1974 as is proven by the link provided above when you do a search and the subsequent renewals as well. So it says it wasn't renewed but when a person clicks on the link and searches - there the renewal is. So the template is not accurate and does not apply here. Any suggestions? Red Rose 13 (talk) 11:50, 3 January 2015 (UTC)

Heeeeeeeey... Wait a second!!! Bit by bit, this entire affair is coming back to me. SRF was not entitled to renew any of the yogi's books, according to the rulings in Self_Realization_v._Ananda_Church, Part IV, #13 ruling the 1974 renewal was invalid. Only the other types of works published in periodicals needed further resolution in the subsequent 2002 case.

I'm not going to forget to double check myself the next time you try to undo what was already been vetted by taking advantage of long periods of silence in the hopes that someone will do what I just - leap to a favorable conclusion because the previous discussion on this matter was so long ago.

The license template is appropriate. I advise you not to remove or substitute it in any way moving forward from now. I do admire your persistence coupled with appears to be great patience however. -- George Orwell III (talk) 13:15, 3 January 2015 (UTC)

LOL You give me too much credit - "taking advantage of long periods of silence" I forgot the details too. I now remember that during that lawsuit this book was not a part of the ruling and wasn't even part of the court case. But true the copyright law at that time was different and that came up in the lawsuit if my memory serves me. The template wording does not actually respresent what happened. In reality the book was renewed by the deadlines. when someone reads the templates and clicks on the links (one is not working) and reader looks to see if it was renewed, it shows in fact it was. The template links contradict the wording in the template. Are you comfortable with this inaccurate contradiction and think it is ok to have on Wikisource? Red Rose 13 (talk) 18:09, 3 January 2015 (UTC)

That's right, the pertinent parts of copyright law in effect at the end of the original term differed from the law near the beginning of the renewal term and then was amended a couple of times afterwards - the premise behind the relevant part of the copyright law has changed little since 1909 if not longer. Thankfully, the U.S. courts are tasked with interpreting the law no matter which law was in effect and when.

The copyright disclaimers found across the various WikiFoundations are primarily there to show anyone who questions the veracity of our policies a clear and consistent history of trying to adhere to various copyright and/or trademark laws to the best of our ability considering its a publicly available forum run by primarily volunteers. Anybody using what Wiki____ has as justification for hosting a work would get laughed out of a real court. The nuances in this instance are odd to say the least but -- just as you have done -- if somebody finds a problem with it, the same thing is likely to happen by raising the issue with someone or in a forum. That is why I re-linked the court case on the talk page.

That said, I understand where you're coming from but opening the door to making a "custom" license banner that is going to be used for just one work is not worth the trouble because others will take that banner up and start to demand this be customized or that be customized; using this instance as the justification -- or use it as proof that favoritism does indeed exist on Wiki____.

If you still feel strongly about addressing this, please open a detailed discussion on the main community board Scriptorium so we build a consensus on what to do about it (if anything). -- George Orwell III (talk) 18:43, 3 January 2015 (UTC)

Wikt

wikt:Oz#Etymology 2 Australia Auztralia (strine) — billinghurst sDrewth 03:09, 4 January 2015 (UTC)

Oh brother! 😕

. . . like I was ever going to make that connection in my lifetime. This is the extent of my exposure to Aussies. -- George Orwell III (talk) 03:32, 4 January 2015 (UTC)

Peter Allen was called the Boy from Oz, and that was a Broadway musical, and other uses are around, so one never knows what an American knows ... or if they   anything. — billinghurst sDrewth 12:58, 8 January 2015 (UTC)

Keep digging. Sooner or later you'll realize you're in over your head. Question then becomes are you smart enough to stop when you now know better.

It was simple non-comprehension of non-essential gibberish at worst; plus this matter had nothing to do with you. Your rush to "protect" your country and cultural in this, while admirable, was totally unwarranted. What's worse is the apparent problem with show tunes and like. Never expected that. --George Orwell III (talk) 18:22, 8 January 2015 (UTC)

Can a table be used in the FIS template? (very low importance)

The lower image offset to the right, ON THIS PAGE was made up of two FIS templates, one over the other. Could I have done this in a single template using a table in the "file" section if I declared the template |file = " as |type = user? Because what I tried ON THIS PAGE really flopped — Ineuw talk 03:14, 7 January 2015 (UTC)

Hi. I just discovered your solutions in the sandbox and on the page itsef (4 solutions not 3), only because I was looking for an empty Sandbox page to paste something. I get no email notifications after an initial post and this has been a long term problem.

Thanks for your efforts and guidance. You answered my question perfectly. And yes, I used the left or right margins as a padding to keep the text away from the images. We had a discussion about this a long time ago, and at that time you suggested it. What other solutions are there for a floating image? Can I use padding-right or left? — Ineuw talk 02:37, 11 January 2015 (UTC)

@Ineuw: -- My dear friend, this is the end.

This is the end of everything you ever thought or practiced when it comes to floating and/or centering divs, center blocks or block centering. As I tried to explain in the next section, the undeniable future for these kind of layouts is Flex (or flex-box) and I am slowly building a knowledge bomb to drop on the community explaining why we must adopt it. I urge you to look the below over and build the Flex layout example in the collapsed box on your desktop.

That said, I'm not sure if you realized it yet, not much in the current Wikisource:Sandbox is based on tables but on the css3 display: values. So if you don't have my common.css tableFaux section copied to your css - you won't see the DIVS & SPANS behaving like TABLE TBODY TR & TDs. -- George Orwell III (talk) 03:04, 11 January 2015 (UTC)

Got it. I tested the code below and just copied your tableFaux section.— Ineuw talk 03:29, 11 January 2015 (UTC)

@Ineuw:: Your gut probably tells you that you don't want to revert Font-size and Line-height (which should have been ' 1.0 ' not ' normal ' originally) in TableFaux but trust me; calculating everything based on a 16px font-size & line-height first makes tweaking those kind of settings afterwards much cleaner & easier. -- George Orwell III (talk) 03:38, 11 January 2015 (UTC)

centering

• The Laboring Classes of England/A Voice from the Factories and its centering

Heyho. First you're overthere; now you're over here

... Not sure why {{block center}} plays up to give a different centering than {{center}}, and it may be due to the use of {{shift left}}, and I am too tired to thunk it. If you could have a poke and tell me what I should do to fix it, I would appreciate your guidance. Thanks. — billinghurst sDrewth 12:52, 8 January 2015 (UTC)

Bleech... I just got done pulling whatever remaining hair I had left over centering

I'll take a look at it; just not this very moment, OK? -- George Orwell III (talk) 13:42, 8 January 2015 (UTC)

Stanza XXXVII has a line that is pretty long; long enough to throw your title seemingly off-center, if that is what the issue is. Other than that, I do believe using shift-left plays a part as well—looking at the same stanza/line. Londonjackbooks (talk) 14:05, 8 January 2015 (UTC)

Me butting in too. A quick measurement suggests that the 'center' is midway between the non-shift-left left margin, and the right-most character of the longest line, which is in XXXVII as identified by Londonjackbooks above. That is, 'shift-left' does not impact the left margin for the purposes of calculating the centre. Which sounds right to me. Personally 'shift-left' should not be used here. I refuse to believe that the typographer who laid these pages out intended that the lines be unindented except for an outdented (i.e. negatively indented!) last line of each stanza; no, the intended layout was to indent all lines except the last of each stanza. What is called for here is the removal of 'shift-left', and the use of 'gap' to indent all other lines. That will bring the 'center' over a bit. Hesperian 02:17, 9 January 2015 (UTC)

┌───────────────────┘
Your logic is undeniable and you'd probably pull it off optically as well since we're dealing....

1. with a single column body of text, "apparently centered" based on the center line of the paper page,
2. with uniform line-starts on the left of the column body
   • except for the single last "outdented line" per stanza; and
3. with "jagged" line-ends on the right of the column body; that
   • apparently never wrap within that column body
     • again, except for the single last "outdented line" per stanza
       (forcing the question: if some of the lines outdented to the left are still wrapping under the left starts due to the margin length on the right - what was the point exactly)
4. the single last lines per stanza all seem to be "outdented" by the same [negative text-indent] length.

Boom! the steps to take are...

• center the column body based on the uniform left line start coordinate and the longest line of all the jagged ending lines on the right line end coordinate (neither being the last line per stanza in this case)
• apply uniform negative text-indent lengths to produce "outdents" for the last line per stanza.
• set overflow: to visible to same last lines insuring "outdent" to been "seen" regardless of skin or css settings

Centered (no hable 'float-center' anymore- comprende?) is key now that the crippled "dynamic layout" concept (at least in spirit) we've had for some time now is about die a swift and painful reality (yes here on WS too) and give way to the rise of Flex (part of the HTML5 and CSS3 specifications). <emphasis mine>

The CSS3 Flexible Box, (or flexbox), is a layout mode providing for the arrangement of elements on a page such that the elements behave predictably when the page layout must accommodate different screen sizes and different display devices. For many applications, the flexible box model provides an improvement over the block model in that it does not use floats, nor do the flex container's margins collapse with the margins of its contents.

I underlined behave predictably to stress how important it is going to be to know, among other static measuring points, your viewable center line and how it relates to your various favorite, formatting techniques or preferences across least 3 ranges (the typical mobile-, mid- and high-end pixel-per-inch stuff) of settings for @ media screen rules.

We simple cannot survive if we don't make the move to the Flex-box layout model at some point (the existence of mobile mode almost demands that we switch).

Billinghurst was introduced to some of the headaches of the current [block-based] model and the unpredictability of different view screens when I tried to find a middle ground, embedded page-links setting that would work for everyone. No such luck; he noticed the change the same day. Why? because my viewable area is not the same as his. That shouldn't matter It does when Dynamic Layouts controls the mw-content Div container rather than its own "article" sub-container Div that "should be" subservient to and aligned under the total header-width minus any aside content (side-notes for example) or navigation aids (our faux column of embedded page links; even the auto generated wiki ToC).

@Billinghurst, @Hesperian, @Londonjackbooks, @Ineuw:A picture is worth a thousand words.--

• copy the html content in the below hidden box and paste it to a fresh .txt file
• do not select "save" -- select "save as" instead. And still do not select "OK" or "Save".
• select where it says something along the lines of "save as file type" and switch the type from ".txt" to "all(*.*)
• if there's an obvious way to set encoding, select UTF-8
• NOW type in a file name ending in .htm
• Finally, save the file

Dynamic Layout's Doom

<!DOCTYPE html>
<html lang="en">
<head>
<title>The Holy Grail of Desktop to Mobile Layouts (Flex)</title>
<style type="text/css">

  body {
   font: 24px Helvetica;
   background: #999999;
  }

  #main {
   max-height: 800px;
   height: 100%;
   margin: 0px;
   padding: 0px;
   display: -webkit-flex;
   display:         flex;
   -webkit-flex-flow: row;
           flex-flow: row;
   }
 
  #main > article {
   margin: 4px;
   padding: 5px;
   min-height: 360px;
   border: 1px solid #cccc33;
   border-radius: 7pt;
   background: #dddd88;
   -webkit-flex: 3 1 60%;
           flex: 3 1 60%;
   -webkit-order: 2;
           order: 2;
   }
  
  #main > nav {
   margin: 4px;
   padding: 5px;
   border: 1px solid #8888bb;
   border-radius: 7pt;
   background: #ccccff;
   -webkit-flex: 1 6 20%;
           flex: 1 6 20%;
   -webkit-order: 1;
           order: 1;
   }
  
  #main > aside {
   margin: 4px;
   padding: 5px;
   border: 1px solid #8888bb;
   border-radius: 7pt;
   background: #ccccff;
   -webkit-flex: 1 6 20%;
           flex: 1 6 20%;
   -webkit-order: 3;
           order: 3;
   }
 
  header, footer {
   display: block;
   margin: 4px;
   padding: 5px;
   min-height: 75px;
   border: 1px solid #eebb55;
   border-radius: 7pt;
   background: #ffeebb;
   }
 
  /* Too narrow to support three columns */
  @media all and (max-width: 640px) {
  
   #main, #page {
    -webkit-flex-flow: column;
            flex-flow: column;
            flex-direction: column;
   }

   #main > article, #main > nav, #main > aside {
    /* Return them to document order */
    -webkit-order: 0;
            order: 0;
   }
  
   #main > article, #main > nav, #main > aside, header, footer {
    min-height: 50px;
    max-height: 50px;
   }
  }

</style>
</head>

<body>
 <header>header</header>
 <div id="main">
    <nav>nav</nav>
    <article>article</article>
    <aside>aside</aside>
 </div>
 <footer>footer</footer>
</body>

</html>

Open it with your browser @ full screen and slowly shrink the viewable window width while observing how the "panels" re-adjust themselves. Keep reducing your window width long as you need to before you realize you found the Holy Grail of desktop And mobile layouts [easily done] in one layout for both & WITHOUT ANY JAVASCRIPT!!. -- George Orwell III (talk) 06:01, 9 January 2015 (UTC)

... that noise is me hitting my head flattening the frown out of my forehead on my desk (should have moved the keyboard first I reckon). I should have known better than to have opened this . Around here I just want to transcribe and edit, and have some pleasure and not follow or get tied up in . My hope of simplicity is . I will leave this to those who enjoy this . Fix it up as you please I will go and work on these tasks . — billinghurst sDrewth 07:56, 9 January 2015 (UTC)

┌──────┘
I have no response to that other than if you don't like something you find here, on my account's dedicated talk page -- stop coming here. George Orwell III (talk) 08:21, 9 January 2015 (UTC)

Unintended result of moving the licence templates below the footer

Hi, I've just transcluded Ante-Nicene Christian Library/Recognitions of Clement: Book 2 and found that the {{Translation license}} template is now separated over the footer. Is there a way to join the template's parts back together below the footer? Cheers, Beeswaxcandle (talk) 18:26, 13 January 2015 (UTC)

Not quite yet - the license banners are all HTML table based as well (that one being 2x as bad). I did it for demo purposes only & will move it back asap.

Speaking of asap - why haven't you chimed in re: Scriptorium / Proposals? -- George Orwell III (talk) 20:09, 13 January 2015 (UTC)

Sandbox musings

All well and good but you can't put <div> inside a <span> or <p>.

The reason for the sandbox investigations by another contributor based on an apparent glitch I'd encountered was

https://en.wikisource.org/wiki/Page:The_origin_and_deeds_of_the_Goths_in_English_version.djvu/51 using the current sidenote style results in a messed up rendering. Using the div based approach (albiet per paragraph at the moment) gives an example here https://en.wikisource.org/wiki/Page:The_origin_and_deeds_of_the_Goths_in_English_version.djvu/62 where it doesn't.

I will also note that by using {{sn-note}} I was able to get the titles rendering on the left or right hand side appropriately, something that seemingly wasn't possible with the conventional sidenotes currently used.

Compare pages 2&3 here- https://en.wikisource.org/wiki/The_origin_and_deeds_of_the_Goths_in_English_version.

Strangely the 'missed' newline isn't an issue..

If you can figure out a way to get both pages rendering "nicely" without the need for DIV's feel free to let the rest of us know :) ShakespeareFan00 (talk) 00:26, 14 January 2015 (UTC)

• Wikisource rule 4,563: You're always wasting your time trying to get ANY of the existing sidenote schemes to work as long as 1.) the Page: namespace improperly processes & renders them; and 2.) the mainspace transclusion is under the spell of dynamic layouts.
• Pages 2 & 3 look ok under layout 1. Under layout 2 (the layout most tablet users prefer as their default) it looks ridiculous. The text column is almost as wide as the sidenote columns are.
• All well and good but you can't put <div> inside a <span> or <p>.

Why on earth would you want to? Plus it goes against the specification for HTML

-- George Orwell III (talk) 00:57, 14 January 2015 (UTC)

Current issue is now resolved. Out of interest what is the technical issues with Proofread page that's causing improper rendering? (which is the actual glitch as opposed to one reported.) ShakespeareFan00 (talk) 10:36, 14 January 2015 (UTC)

OCR button

Hi! The OCR button seems to have disappeared from my edit toolbar after your tweaking. How do I get this new gadget or whatever? I have no knowledge about such matters, so help required. Hrishikes (talk) 06:48, 14 January 2015 (UTC)

@Hrishikes:, Hmmm... that's odd. Is it enabled in your user preferences --> gadgets --> Editing tools for Page: namespace?

And which editing toolbar are you using; Classic or WikiEditor? And what OS & browser versions? -- George Orwell III (talk) 06:52, 14 January 2015 (UTC)

OCR button enabled. OS Windows 7 Prof, 32-bit. Browser Chrome 39.0.2171.99m. Not sure about Classic vs. WikiEd. Hrishikes (talk) 07:05, 14 January 2015 (UTC)

@Hrishikes:, Again, in your user preferences --> editing tab --> editor section, to determine which toolbar you are using...

___ Show edit toolbar ( this on next 2 off = classic toolbar )

_X_ Enable enhanced editing toolbar (the above & below should be off if this is on = WikiEditor)

___ Enable wizards for inserting links, tables as well as the search and replace function (not very developed, works only if Wikieditor is enabled but recommendation is Not to enable this [ever]).

Other than using Classic toolbar I can't understand why its not working. Can you log-out and try editing a Page: as an anonymous visitor and see if the same thing happens? -- George Orwell III (talk) 07:14, 14 January 2015 (UTC)

Checked; all 3 options enabled -- should I change it? I have tried logging out, still no OCR button. Actually, I have never tweaked with these preference options as far I remember; these are just as always was as default or some such. Hrishikes (talk) 07:23, 14 January 2015 (UTC)

@Hrishikes:, All 3 enabled? - that's not right. Try just the one with the _X_ above. Make sure you remember to hit save at the bottom of the page.

Afterwards, go back to the Page: namespace and open an edit session. Is the toolbar the same as you've had all along? -- George Orwell III (talk) 07:27, 14 January 2015 (UTC)

Thanks a lot. It has come back after doing the above. In the meantime (before changing of options), I had checked in bn WS, where the OCR button was appearing fine. Do I need to change my preferences there too? Hrishikes (talk) 07:32, 14 January 2015 (UTC) Addendum: I have not noticed any change from my previous toolbar after option changing. Hrishikes (talk) 07:36, 14 January 2015 (UTC)

@Hrishikes:, Right. Those "extra" enabled options you just turned off were interfering with the "default" settings (that's why it didn't make any sense to me at first).

Anyway, if "bn" is another language Wikisource (bn.WS) project, you "shouldn't" have to do anything or change anything but I can't be certain "they" are keeping up with the latest core changes (like we had a core upgrade earlier today that broke the character insert bar for example).

And at least now you know that a.) just because you didn't select an option in your preferences doesn't make it the correct choice nor guarantees its the default one; and b.) based on a.) playing with those User preference choices may solve your issue or issues. -- George Orwell III (talk) 07:39, 14 January 2015 (UTC)

Thanks a lot. bn means Bengali. Thanks again. Hrishikes (talk) 07:46, 14 January 2015 (UTC)

Need some validated index pages to be moved

Greetings O Great one.

I found a perfect replacement for THIS DAMAGED FILE where 4 text pages and an image + a blank page are missing (total of 6). Should I upload the new version over the old one? From the beginning until .djvu 502 everything matches perfectly. The missing pages in question would be .djvu (503, 504, 505, 506 text), (507 image), and (508 blank), .djvu 509 = page 491.

There is an additional twist to the story. The overall number of .djvu pages of the new volume is 541, and the old is 537 because there are only 2 advertisements at the end in the new, as opposed to 4 in the old (They are jpg files anyways).. So to do the math, 537+2+6 = 541. Please get back to me whenever you feel like it. — Ineuw talk 00:19, 20 January 2015 (UTC)

Short ans. - yes. If positions /1 thru /502 are the same in the new as in the old, I would directly upload the new over the old and fix any changes in the book, information and/or index: templates if need be. You then need to file a BOT request to move the existing pages after the current /502 position to (if I understand right) be bulk moved by an offset of +4. Afterwards, it shouldn't be all that hard to manually move/delete any extra advert. or non-text pages as the new pagination may demand.

I don't follow what you mean by .jpg files however -- either they are 4/6 indirect djvus all merged into a complete, single bundled DjVu or a complete single bundled DjVu file with the 6 missing pages already in place, no? -- George Orwell III (talk) 00:44, 20 January 2015 (UTC)

Thanks. I will upload and file a bot request. The offset insert is +6 pages. The comment about the ads at the end is that they are not text but are .jpg .png images so they are not lost. The math was with the wrong symbol and order 537+6-2 = 541.Sorry for the confusion due to my not checking the message before posting. — Ineuw talk 01:15, 20 January 2015 (UTC)

Bulk page Moves

Wikisource:Bot_requests#Bulk_page_moves_in_Index:Our_Sister_Republic_-_Mexico.djvu

I note you'd already moved the very end of this work.

I moved the "end" of this work because the lack 2 extra advert pages in the replacement DjVu would only confuse the BOT master and make his/her life more complicated than it should be (this should be an ulterior motive for any request asked from a fellow contributor) -- George Orwell III (talk) 10:39, 20 January 2015 (UTC)

I've moved the upper end of mis-aligned block, but as a normal user can't continue the moves, maybe as an admin you can? ShakespeareFan00 (talk) 10:20, 20 January 2015 (UTC)

Yeah - that's exactly what I wanted to do - stop working quietly here at home on real pressing issues and play move'em if you got'em for the next half hour instead. Sorry. Not going to help ya there pal.

YOU WILL have to learn to slow the f@ck down, stop & think things thru for a moment or two and THEN act (one way or the other - it doesn't matter) sooner or later -- why not start today? :) -- George Orwell III (talk) 10:39, 20 January 2015 (UTC)

I would have moved all the pages, but as explained Mediawiki doesn't let you move over an existing page. I had thought this through prior to commencing the moves, but wasn't seemingly aware of the limitation on moving over existing pages.

Obviously I'd rather not to do a copy-paste of the other pages, for reason to do with page-history. ShakespeareFan00 (talk) 10:47, 20 January 2015 (UTC)

Oh well. Hopefully somebody with both the access and the free time will come by and address one (Bot request) or the other (sdeletes) - hopefully both in tandem. Credit given for knowing better than to blank pages just to copy & paste over them however. -- George Orwell III (talk) 11:05, 20 January 2015 (UTC)

Given that I am now getting hassle over this, User_talk:ShakespeareFan00#Leave_my_work_alone an being accused of interfering, when prior to thier message I wasn't aware it had been claimed, (there not being an indication on the Index page), I'm giving very serious consideration to not contributing here, on the basis of competence. I've been asked there to clean-up the mess, which as I've explained isn't something I can do.

In addition if Wikisource IS moving to a model where tasks are "claimed" , the user concerned having expressed concerns about me proofreading on something they were also working on, it would be nice to know. I remain perfectly willing to do clean-up on over bold edits, but in this instance the limitation was within Mediawiki, and thusly out of my control, also how was I supposed to know the task had been claimed?

I think the only answer to that issue is some form of mentoring, because a series of events recently seem to suggest a comptency deficit. ShakespeareFan00 (talk) 17:13, 20 January 2015 (UTC)

My response to their message User_talk:Ineuw#Your_recent_message ShakespeareFan00 (talk) 17:13, 20 January 2015 (UTC)

Deprecating experiments and older templates

This is a courtesy note to explain that I'm in the process of deprecating some of my older templates based on what you said concerning tables.

I am marking these a minor edits as in most cases it's a simple replacement or subst. ShakespeareFan00 (talk) 11:50, 20 January 2015 (UTC)

That's fine by me @ShakespeareFan00:. Please do take the time to review an "alternative approach" that I added to your User:../Sandbox/tables page pointing to the CSS3 usage of column-count, column-width, column-rule, column-gap and column-span (among others) before you go too crazy deleting stuff. Applying those attributes will generate "table-like" columns as well but aren't as "specific" as the 'proof-of concept' approach is. Still, they might help you salvage something you've previously tinkered with. -- George Orwell III (talk) 12:03, 20 January 2015 (UTC)

┌──────┘
In going through my experiments I found this - {{Ld}} , The intent seems to be to have been a workaround for limitations of list markup, and may also be amenable to the "display:" classing approach you mentioned in respect of tables. Do you know anyone other than yourself that would be willing to review templates like this? ShakespeareFan00 (talk) 12:10, 20 January 2015 (UTC)

What work-around? You just templatized the LI element to possibly override whatever is set (or is set by default) in the parent OL or UL elements thru manual input? Why do you waste sooooo much time & effort on templatizing something that is easier (and far more consistent given the wiki-mark-up environment we operate under) to do with straight HTML in the first place?

Dump it. I'm guessing nobody knows about it but you --> nobody has used it but you = real no benefit gained for potential future editors by using it at all. -- George Orwell III (talk) 12:25, 20 January 2015 (UTC)

I've also deprecated {{Ollist}} by reformulating the one template that was still relying on it. I've not tagged it for deletion as unused because I'm about to start a disscusion on it.ShakespeareFan00 (talk) 14:48, 20 January 2015 (UTC)

Licences and author images overlay

Author:Thomas Birch there is a problem that the copyright tag overlays the image of the author. (Firefox, monobook, logged in) — billinghurst sDrewth 13:15, 14 January 2015 (UTC)

The problem exists with Firefox, but it's OK with Chrome and IE. In Firefox, the problem is not limited to this author. Problem also exists in Author:Bankim Chandra Chattopadhyay. It seems that, if the works list is short enough, and the image hangs lower than the works list, the copyright tag will overlay the image. Hrishikes (talk) 16:51, 14 January 2015 (UTC)

@Billinghurst, @Hrishikes:, What about now? So its only the author image that gets overdrawn when the listing is too short? -- George Orwell III (talk) 23:39, 14 January 2015 (UTC)

Appears corrected. Thanks. Hrishikes (talk) 12:03, 15 January 2015 (UTC)

Thanks, that is back to how it was previously. — billinghurst sDrewth 11:50, 16 January 2015 (UTC)

Please help Ko.Wikisource regarding using Proofreadpage index template

Hello, Sorry to bother you. I am from Ko.Wikisource. I am trying to use Proofreadpage index template there. But it doesn't work. Please see this page - ko:색인:殺人書秘話 박문 제1집, 1938.10, 12-13 (2 pages).pdf. How I can see this index page well? Please check this ko:미디어위키:Proofreadpage index template is correct or not comparing MediaWiki:Proofreadpage index template which is changed lastly by you. Thank you in advance.HappyMidnight (talk) 16:45, 14 January 2015 (UTC)

My Korean is VERY rusty but I think that the namespace like "Index" is missing??? — Ineuw talk 00:21, 20 January 2015 (UTC)

There is, 색인 for Index and 페이지 for Page. I know this because I have submitted the patch to localize them. — revi_msg 06:27, 20 January 2015 (UTC)

It probably not-so-much missing as mis-assigned and the paglist tag is therefore somehow affected & not working. The ko.WS uses the new default namespace numbering assignment for Index: , ns-252, while we are grandfathered-in with ns-106. I'm betting that nuance makes using our setup as a template for ko.WS problematic to put it mildly.

Also, I'd take a look at anything in the MediaWiki namespace labeled starting with the term proofreadpage and make sure you have the KO equivalent. -- George Orwell III (talk) 00:54, 20 January 2015 (UTC)

Local community wishs to change the variable's name used on Extension (already have modified the variables but not extensions' translation), as such it does not appears. I have reverted your test edit. — revi_msg 06:27, 20 January 2015 (UTC)

@George Orwell, Thank you all for your concern and work. Fortunately some admin of Ko.WS has attended to this issue and they are trying to fix it. Anyway, your help also will be needed to fix it. I think we'd better talk at Ko.Ws. HappyMidnight (talk) 04:04, 21 January 2015 (UTC)

headertemplate class

Still on The Lesson of the Master, The Marriages, The Pupil, Brooksmith, The Solution, Sir Edmund Orme (New York & London: Macmillan & Co., 1892)/The Lesson of the Master:

Whenever I need to introduce content that does not exist in the work proper, such as introducing a TOC to a work that has none, I always mark that content up as class "headertemplate", so that it looks like the header and footer — thus clearly indicating to the reader that it is Wikisource content not book content.

Previously "headertemplate" class could only be applied to a table, not to a div, so I have always wrapped such content in a table in order to apply the desired class. I confess to embarrassment in telling you this.

Previously "headertemplate" class caused tables to be 100% wide, as desired. Your recent changes have broken this, and it looks awful.

However, your recent changes have also rendered it possible to do what I would have preferred to do all along: to use a div instead of a table.

After much reflection, I have come to the conclusion that you are going to have to roll back everything you have done for the last fortnight so that my ridiculous and embarrassing table hack continues to work they way it did before.

... or I could just go back through all my works and improve them by replacing all those tables with divs. Sanity check: is it safe to do so now? Are things stable enough that I can change all these tables to divs, and not wake up tomorrow morning and discover they all need to be changed again? -- Hesperian 01:31, 30 January 2015 (UTC)

@Hesperian: What you might not be aware of is that nearly all the class definitions found in any given .css, including common.css, normally in operation under Desktop View for en.WS do not automatically transfer to Mobile Mode, so I've been rewriting everything with as much inline .css styling as possible -- freeing up the definition selectors in the various .css as I go -- with the ultimate intent to consolidate and reintegrate class driven styling afterwards to insure they are picked up by both Desktop View as well Mobile Mode.

If something stopped rendering properly here on Desktop view as a result of one of these break-outs-to-all-inline-styling and the deprecation of the corresponding .css class driven styling having taken place, that means the object in question would have never rendered properly (if it rendered at all) under Mobile Mode long before any of the changes made during the past week or two. I've restored the table.headertemplate class just so your works render as intended and as before I started messing with things (if there any other instances like this one that you know of - please let me know). You can move to using DIVs if you wish at this stage of operation 're-write' but keep in mind you should not rely on the current .css definitions for all your styling needs - apply inline styling instead. -- George Orwell III (talk) 02:08, 30 January 2015 (UTC)

I hope you realise I was joking when I demanded you put everything back. Thanks for fixing my styling issue; I will still move all my legacy tables over to divs, but I won't be in such a hurry now. What I want is for my boxes to look like whatever the header and footer boxes look like, so classes are better than inline styling in my case. Hesperian 02:53, 30 January 2015 (UTC)

--> Looks pretty abominable to me if left that way. -- George Orwell III (talk) 02:58, 30 January 2015 (UTC)

Ugh! ... replacing my table with <div class="headertemplate">, which worked only a couple of hours ago, no longer does. Hesperian 03:04, 30 January 2015 (UTC)

Hesperian, use <div class="subheadertemplate"> for things like your faux ToC from now on. It was never a "header" in the true sense to begin with - just something that mirrored the header template's styling to help differentiate it from original content with non-original content. -- George Orwell III (talk) 03:17, 30 January 2015 (UTC)

Jolly good, thank you; and thank you for taking this mess on in the first place. Hesperian 04:24, 30 January 2015 (UTC)

Class style doesn't render in mobile mode, though it still looks heaps better than the travesty it was before. Hesperian 04:27, 30 January 2015 (UTC)

@Hesperian: Didn't I just explain in the above that hardly any of the current Desktop View class .css definitions carry over to Mobile Mode and to add the equivalent inline styling whenever possible until a [re]consolidation of .css attributes and their values that work under both modes into a unified .css file can take place? -- George Orwell III (talk) 04:38, 30 January 2015 (UTC)

Yes. My bad. Sorry. Hesperian 05:21, 30 January 2015 (UTC)

deleted Talk pages

Thanks for all the Emerson Talk page deletions; I wasn't sure if the 'history' should stay or not, but now I know to tag them in the future. BTW, in a previous post (in a bug ticket) you referred to me as a 'he'; I am a she for the record :) but no biggie! Londonjackbooks (talk) 00:58, 1 February 2015 (UTC)

This (alongside "Life is Pain" image no less)?: Thank you for vindicating my double-take at the time. AuFCL (talk) 01:18, 1 February 2015 (UTC)

@AuFCL:: "Pain is weakness leaving the body." "No pain, no gain." Good philosophies—even when working with wikis! Londonjackbooks (talk) 01:44, 1 February 2015 (UTC)

Fixed. Sorry 'bout that LJB.

Not a problem! Londonjackbooks (talk) 01:44, 1 February 2015 (UTC)

File:Life-is-pain-hammer.gif

As for preserving histories - when you move a page and leave a redirect behind, the redirect's history all goes to the new target upon the move and only logs the fact the redirect was created because of a move. So don't worry about preserving histories - its preserved automatically in a move more often than not.

The only time you need to be careful is when you're moving over an existing page (not sure if you even can without being an admin) or when you are moving things around in order to open-up/create a disambiguation page. You don't want the history associated with the DAB but the target in short. -- George Orwell III (talk) 01:35, 1 February 2015 (UTC)

I will read over the above a few times to try to digest what you are saying. Thanks! Londonjackbooks (talk) 01:44, 1 February 2015 (UTC)

disambiguation question

Can you please tell me your thoughts on the creation of a page such as this? I am mainly referring to the practice of using "various authors". I think it is practical, but am open to a better idea... Thanks, Londonjackbooks (talk) 01:44, 1 February 2015 (UTC)

Boy I don't know <shrug>. My gut tells me that's one too many disambiguation (DAB) pages but they are indeed two different enough titles to warrant a distinction. I defer to Hesperian - he's always the one I look to for things like this; Best to ask him. -- George Orwell III (talk) 02:04, 1 February 2015 (UTC)

Asked. Thanks! Londonjackbooks (talk) 02:21, 1 February 2015 (UTC)

another question

First, thank you for your continued clean-up of titling, etc. I was wondering, however: I understand and agree somewhat with linking directly to the indexed source (like you did here)... But, what if in the future, someone decides to add Emerson's complete works to WS—creating more than one version of many poems. Should the link not then point to a general title (e.g., The Rhodora—unless the page specifically refers to a particular work/date) instead? In other words, if we left it linking to The Rhodora, said page could in the future become a versions page, which would be a desirable page to alight upon for general use as opposed to a "random" work. Am I explaining myself ok? Sorry if I'm not clear... Londonjackbooks (talk) 02:18, 1 February 2015 (UTC)

Yeah, I'm of the mindset we should link to what exists today; not to what we might have one day. I realize now that my perspective on this might not exactly be the majority view. Anyway, its your baby so I'll stick to fixing dbl redirects and such and leave those instances alone from now on. Sorry for any extra work I might have caused you. -- George Orwell III (talk) 02:29, 1 February 2015 (UTC)

No biggie! Thanks for all your input & work, Londonjackbooks (talk) 02:32, 1 February 2015 (UTC)

Thanks

Thanks for fixing my css and js files. I didn't realize I put the JS into my CSS file. (It still got read as javascript anyway.) Also, I appreciate the note about the OCR button. I was actually a bit annoyed that it had disappeared and didn't know it was moved to Gadgets. The Haz _talk 01:20, 11 February 2015 (UTC)

Adobe Flash and Wikisource? The end of wit.

Does the Adobe Flash have any role in Wikisource editing, as in rendering the DjVu page display in the Page: namespace? The reason I am asking is because after 10 minutes or so of editing, when scrolling the original, the page rendering stops for about 10-15 seconds after each touch of the scroll bar, and I am unable to produce much work.

I stopped all services which interconnect with the Firefox browser and removed all addons that I suspected of interfering. But, I do know that Adobe Flash is an unending pain in my considerably sized butt. I also worked without a browser cache which didn't slow me down, but didn't alleviate the problem.

As I am writing this, I thought of some other strategies to try for test and get back to you. In the meanwhile, if you can think of something else that's related to the rendering of the image (perhaps a setting in the Preferences, like the Image size limit which is currently set at 1024x768 and the Thumbnails size it 220px. All the image size limits refer to a 4:3 screen ratio, while LCD\LED monitors are mostly 16:9. Would this have any effect? Also, I have 1GB of video memory which should be sufficient for DjVu rendering.— Ineuw talk 19:56, 9 February 2015 (UTC)

Sorry I-man, nothing like Flash running anywhere on Wiki-ware as far as I know. I can empathize w/you re: Flash -- until MS went there "own" flash way , I resorted to [re]taking control over it's registry key in order to prevent its meddling myself. But its definitely not playing a role here.

I went 26 inch LED here at home no too long ago so its not hardware aspect ratio related. CSS3 does allow for setting "rules" based on viewport, etc. but -- as far as I know -- only 1 setting is in place for desktop view; their might be more "rules" set in Mobile mode but I doubt they would be set so drastic to cause what you're observing.

The only thing in User: prefs that have been reported lately to cause "trouble" are a.) anything enabled on the Beta page; b.) enabling Media Viewer; and c.) enabling Live Preview / setting preview before diffs.

Other than that, FF has been "adding/altering" all sorts of "settings" according to their users - check the Village Pump ~ Technical archives over on Wikipedia for the most extensive mentions of these "new" troublemakers.

Let me know how you make out & if you have the time; can you look into the OCR button behavior on your various set-ups? I just don't have the proper test-bed to test for everything which, at times, cause the root of a problem erroneously point to the WMF code rather a bad browser setting or conflicting User: pref -- George Orwell III (talk) 23:30, 9 February 2015 (UTC)

Will check out the OCR button. As for my problem - it can wait.

For whatever it's worth, my OCR button is missing (too?) these last few days. Ubuntu, Firefox -- can test on other OSs/browsers, but haven't yet. (And GOIII, no, I haven't forgotten our other business -- just taking a little longer than I meant to getting back to it.) -Pete (talk) 14:32, 10 February 2015 (UTC)

┌────────────────┘
Some Preliminary Questions:

• What skin do you currently have in place?.-- The "default" is vector but you've been around long enough to know switching from one skin to another does not necessarily guarantee all the old settings seamlessly switch over to the new state so I have to ask.
• Which editing toolbar do you use by default; Classic or WikiEditor?.-- In your user preference settings, editing tab....

1. Show edit toolbar <-- only this one of the three listed here should be selected for Classic
2. Enable enhanced editing toolbar <-- only this one of the three listed here should be selected for WikiEditor
3. Enable wizards for inserting links, tables as well as the search and replace function <-- never select this; for now, these features are not ready for "prime time"

• Is the OCR button gadget enabled in your User preferences as well?.--

George Orwell III (talk) 16:02, 10 February 2015 (UTC)

Well, I don't really know about those settings foibles, but I'll answer your questions as best I can. I have used Vector as long as I can remember. I believe I was active on Wikisource before Vector came out, so I would have had Monobook enabled up until switching to Vector. (I don't think I chose Vector myself, I think it was changed for me whenever the default switched.)

If you mean "WikEd" toolbar, no, I do not use that gadget on Wikisource.

I do not have the "enhanced" toolbar enabled.

I do have "enable wizards" selected. I did not ever turn that on on purpose, and don't recall seeing it before. Perhaps some default was changed recently..?

The OCR gadget was disabled in my preferences. However I did not turn this off myself. It was working a few days ago, and I have not visited my preferences screen since then. -Pete (talk) 16:19, 10 February 2015 (UTC)

Some defaults were affected by recent changes to the core wmf code (e.g. updates) and thus - what was once believed to be a "default" site-wide setting now conflicts with some other "setting" so you now need to manually enable/disable some things for the time being (maybe forever?). Otherwise; sit and wait for developers to restore your "hands-off" state (good luck with that)

And the toolbar thing is kind of important (its not a gadget btw but a series of check boxes on your editing tab). I'd make sure only one of the three options I listed is enabled at a time (otherwise "hello more conflicts"). -- George Orwell III (talk) 16:25, 10 February 2015 (UTC)

OK, thanks for the explanation. But I'm a bit confused about "Classic" vs. "WikiEditor" though -- where is that choice? I thought you were talking about WikEd, which...was...a gadget, but I don't see it in the preferences anymore. (Perhaps it was never available on Wikisource? I used to use it on Wikipedia, and some of my students found it useful.) -Pete (talk) 16:41, 10 February 2015 (UTC)

• @Peteforsyth: Which editing toolbar do you use by default; Classic or WikiEditor?.-- In your User preference settings, Editing tab, Editor section....

1. Show edit toolbar <-- only this one of the three listed here should be selected for Classic
2. Enable enhanced editing toolbar <-- only this one of the three listed here should be selected for WikiEditor
3. Enable wizards for inserting links, tables as well as the search and replace function <-- never select this; for now, these features are not ready for "prime time"

George Orwell III (talk) 16:44, 10 February 2015 (UTC)

And don't forget your changes might not go through right away thanks to caching variables by you or by the wiki servers -- George Orwell III (talk) 16:47, 10 February 2015 (UTC)

Aha, so those checkboxes determine which toolbar I'm using? That wasn't clear before -- I understood them to be checkboxes I was supposed to match to which toolbar I had selected somewhere else. I think I'm with you now, I will experiment with both. Thanks! -Pete (talk) 16:49, 10 February 2015 (UTC)

I tested both Firefox and Chromium in Linux and the results were that with the advanced toolbar OCR always shows up and works. With the legacy toolbar the icon was missing on the first edit in both browsers. Purging the page (I use the UTC clock purge) it shows up. Perhaps the editors with a problem should check their preferences that only one toolbar is selected. I will duplicate this post in the Scriptorium/Help as well.— Ineuw talk 17:37, 10 February 2015 (UTC)

@Ineuw: Thank You; I wish somebody would!!

Wet the bed for a mislabeled file... but nooooooooo... my fellow contributors might learn something - best not post about that. No sir-eee. Bunch of one way fart smellers all. -- George Orwell III (talk) 19:13, 10 February 2015 (UTC)

Reached end of the road

The DjVu display in editing mode is still not resolved. Aside from the fact that I tried everything that I could think of, which includes my hardware, drivers, video and mouse drivers, are updated and Firefox is a fresh install without any "addons", my question is: Has the extension which manages the djvu page display & magnification been changed or updated recently with the current version of the wiki software? The reason I am asking is because the moment I place the pointer to scroll or click on the djvu image, the lower half of the image disappears for a few seconds, so that I can't scroll the page, making proofreading impossible. I tried Chrome/Chromium but that is not really an option. Could you tell if something was change. Many thanks.— Ineuw talk 20:19, 13 February 2015 (UTC)

I'll look again later tonight when I get home but I don't believe anything along those lines have changed. The only difference css wise that I can think off is resize: vertical/horizontal/both is recognized by FF & Chrome, but not by IE or Opera -- that setting applies to WikiEditor in some places/instances. -- George Orwell III (talk) 20:28, 13 February 2015 (UTC)

I still can't find any core code related changes that would cause something like that but I'm not exactly done fact-finding either. In the interim, I went through both the vector and common .css & .js files of your's and started trimming stuff that I'm not familiar with followed by noting things that need your review. But before that -- has anything changed since my editing of your .css & .js files? -- George Orwell III (talk) 05:25, 14 February 2015 (UTC)

I noticed that you made changes because the Charinsert dropped below the textarea. I was proofreading using Firefox in Linux but there I have no access to some tools. Now I am back in Windows to test it, and will let you know.— Ineuw talk 05:35, 14 February 2015 (UTC)

The problem persists. It originates with the clicking sequence on the image to magnify or to stop the magnification. There is definitely something wrong there. In cases when an editor must single-click on the image to set focus for the mouse pointer (when pointing is not working) immediately this changes the scrolling to minimize or magnify the image. The idea of a single click is idiotic at best and shows that the programmer hasn't done any editing in a meaningful way to test the idea. Also, the second single click to fix the image doesn't work properly unless the toolbar magnifier is clicked. This forces the image to refocus which cancels out the usefulness of the magnifier. Why double click was changed to a single click is beyond me. The children were at play again? I am working in over/under mode and not side by side. This might be a reason why no one complained about the magnification. I must assume that it's not used very much.

One more thing. I couldn't replicate the problem in Firefox in Linux because the pages I was editing required rewriting which limited the need to scroll. I am also uploading an screen image of the problem and want to post a bug report.— Ineuw talk 06:27, 14 February 2015 (UTC)

The uploaded image File:Lost scan.jpg

Ah well I see you've modified the width of the textarea box -- so I have to ask if this also happens when you're not logged in (e.g. none of those modifications would be applied when not logged in).

I added the "old" disable wheelzoom string to your common.js under the Proofread Page extension section just see if anything changes.

Finally, I think the files dealing with that zoom/wheel aspect reside in this folder fwiw.

... and if you're going to use the modern skin (a fancy monobook based variant) you're better off using the old "Classic" toolbar scheme with the old approach to customizing buttons etc. WikiEditor is really only tested for use under Vector as far as I know. -- George Orwell III (talk) 06:43, 14 February 2015 (UTC)

┌────────────────┘
Thanks for telling me, although I never had any problems with the advanced toolbar, just getting used to it. The only major advantage of the modern skin is that with the logo gone, it brings up the sidebar tools. --ineuw (whatever the clock says)

Fwiw... I did the same axing of the logo space in Vector for you (in Vector.css). -- George Orwell III (talk) 07:28, 14 February 2015 (UTC)

Proofreading without logging in works fine. the page image didn't disappear. This is an advancement which narrows down the issue to the wiki software and not the browser.

As for the editing screen width. it was always 80 columns wide and 12 rows, I don't remember ever touching those settings. Also, switched back to Vector...... Thanks for your help. — Ineuw talk 07:34, 14 February 2015 (UTC)

When "we" customized the line-height, font-size for the primary textarea box, we "screwed" with the normal settings for that box. I showed you how to restore 1em = 16px font-size ratio scheme (font-size: 1rem; line-height: 1.0;) and that would have been one place to apply/try it first and then teak it your liking(s). -- George Orwell III (talk) 07:49, 14 February 2015 (UTC)

For awhile things worked well and I was about to post here success, but then it began again. So, I reset my preferences to the default but reselected my preferences one by one. One important mention: The default checks off both toolbars as well as the "Enable wizards for inserting links, tables as well as the search and replace function". If the display problem re-occurs, I will just reset the preferences it again to default, correct the edit related (toolbar) settings, but leave everything untouched, as well as remove the contents of the css. Don't waste your time on this, we'll figure it out sooner or later.Ineuw (talk) 01:07, 15 February 2015 (UTC)

There is little else I can do without actually installing FF itself -- the virtual FF under IE11's F12 Developer Tools does not replicate what you describe here btw. The most productive way to proceed here imho is to debug your session by monitoring/logging your "movements" via a console. Unfortunately, I'm not sure how to do that under anything but Windows & Internet Explorer at best (which I believe you said is not behaving the same as FF & defeats the point if so).

The reason I suggest this is because even the "default" wmf code is peppered with carve-outs/hooks/and similar set for specific browsers (&/or specific versions of) in specific situations that only the most nerdy of nerds might be familiar with at best. So unless you/we can narrow possible causes or conflicts down further to a specific script, extension, module, etc., we're really just spinning our wheels at this point. -- George Orwell III (talk) 05:45, 15 February 2015 (UTC)

Agreed. While you were out and having fun, I removed all css and javascript, reset the preferences to default, and only then it worked without any problems. The only drawback was the default font size which was too small, so I placed the font related code back into the css and it failed on the second try. Uploaded another image tonight which shows that side by side editing is also affected.

I will figure out how to record my activity with the code inspector and then get back to you. Ineuw (talk) 07:33, 15 February 2015 (UTC)

First off -- there is no such thing as font-size: 1.2rem or anything along that variation on a theme.

There is only one value and one value only currently defined to "reset the font-size to an unaltered <body> element's default value where 1em is understood to equal 16px" (∴ 1rem ). This means when you apply 1rem to an element anywhere in a document's structure or outline it supersedes any prior existing .css or inline styling's applied to or calculated for that element and resets it so { font-size = line-height = 16px = 1em } -- which is what ALL specifications use for a baseline btw. Once the "reset" takes, you can than make/modify font-size and line-height settings of your own css - wise afterwards (thus the modification must always be below the reset in your css file). This, however is not impervious to scripting/code that waits for such "resetting" to finish along the trail from the initial click "in" to the finished rendering and defeats the purpose by executing at that point.

Its this kind of timing-order / loading-order issue that my gut says is screwing you up somehow (just like how the wmf update before last caused a conflict between CharInsert & the OCR button because they where both set as universal, site-wide defaults at the time. Changed the OCR gadget to be a manual selection and both managed to live together again). -- George Orwell III (talk) 09:32, 15 February 2015 (UTC)

Thanks for the explanation of the 1rem. It's understood.

As for the 2nd part of your post, I understood the issue, and now I am searching for a way to log all browser activity. There is a log system but I don't think it logs all changes. Will post a request on the Mozilla developer network.Ineuw (talk) 18:45, 15 February 2015 (UTC)

My money says its going to be the Proofread Page extension behind this. IMHO, it was bordering on POS status by the time ThomasV "left" and there is not much Tpt or Phe or we can do about that fact as the extension stands today. My CharInsert bar frequently loads at the top of the WikiEditor container in the Page: namespace whether I set it to do that or not in my .js file for example (something to do with the manner of generation of the Proofread tools drop-down menu & buttons).

Looking forward to your findings regardless. -- George Orwell III (talk) 19:07, 15 February 2015 (UTC)

Managed to save a log containing performance data, showing the order and the time it took to retrieve the code. The output is JSON format and I don't think it of much use. Here is a snippet copied randomly from the middle of the output, but will keep at it.Ineuw (talk) 05:23, 16 February 2015 (UTC)

B405886384123277BE23F\",\"pdbAge\":1,\"pdbName\":\"d3d11.pdb\"},{\"start\":1879900160,\"end\":1880211456,\"offset\":0,\"name\":\"dxgi.pdb\",\"breakpadId\":\"4184519EBA8C4D3C90017DC3F4DFBAA11\",\"pdbSignature\":\"4184519EBA8C4D3C90017DC3F4DFBAA1\",\"pdbAge\":1,\"pdbName\":\"dxgi.pdb\"},{\"start\":1815740416,\"end\":1831723008,\"offset\":0,\"name\":\"nvwgf2um.pdb\",\"breakpadId\":\"EA7D23B191624A908D398A0214EF252C1\",\"pdbSignature\":\"EA7D23B191624A908D398A0214EF252C\",\"pdbAge\":1,\"pdbName\":\"nvwgf2um.pdb\"},{\"start\":1957298176,\"end\":1957392384,\"offset\":0,\"name\":\"bcrypt.pdb\",\"breakpadId\":\"E23FFEF26CCA4A75A0EF624509D12C172\",\"pdbSignature\":\"E23FFEF26CCA4A75A0EF624509D12C17\",\"pdbAge\":2,\"pdbName\":\"bcrypt.pdb\"},{\"start\":268435456,\"end\":269721600,\"offset\":0,\"name\":\"nvspcap.pdb\",\"breakpadId\":\"016E88551978401EB7A9F458370E02211\",\"pdbSignature\":\"016E88551978401EB7A9F458370E0221\",\"pdbAge\":1,\"pdbName\":\"nvspcap.pdb\"},{\"start\":1480392704,

File:EyePoke.gif

It seems the PR image bug is resolved (nope)

So far, the proofreading seems to work today. I noticed in yesterday's perusal of the wmf javascripts that the mouse action/movement plays an important role, and that it commands to stop mouse activity at a certain point of the loading process. I checked the device manager and noticed that MS did not properly install the drivers for the HID devices. The Logitech mouse & keyboard driver was missing and the mouse showed that it had two copies of the same driver. This led me uninstall, clean, and reinstall the drivers for both the keyboard and the mouse and it seems OK now after proofreading some pages, so I keep hoping that this was the problem.

No such luck - but the mouse and the keyboard work fine. Ineuw (talk) 19:11, 16 February 2015 (UTC)

Boy that sucks. I've used Logitech wireless keyboards & mice for over a decade now just because they seem to work seamlessly with 'Windose' & haven't really had the need to install their proprietary drivers for some time now (unless it came bundled with some additional feature or app). In short, I doubted drivers was the root of the problem even before I read the about the "return" of the issue.

Fwiw... another idea popped into my head since my last - try editing something over the "test-bed" for the PrP extension over on test2.wikipedia.org to see if the same behavior occurs over there too. NOTE: before you do any editing/testing there, you should go through your User: preferences settings on that project's site first to make sure the absolute minimums are being loaded when you log-in. In other words, they have extra stuff like Courses, Visual Editor (beta) and some others on Test2 that we don't have tabs/settings for here on en.WS [yet]; make sure anything like that is not enabled whenever possible. Some stuff you can't exactly disable but you can still 'retard' their functionality via settings to have a small an impact as possible. Good Luck & let me know. -- George Orwell III (talk) 20:16, 16 February 2015 (UTC)

Be that as it may, removed all Logitech drivers, nevertheless the problem persists - not with the first edit, but around the ~10th page. So, I dared to search Maniphest and lo and behold (I tend to be biblical in such matters), there are many mouse scrolling related issues reported, some are exactly like mine. This one is closed. Others relate specifically to Firefox. All I did was search for the word "mouse", which yielded This page. Shall I add a new bug report? Your opinion at your leisure.Ineuw (talk) 04:03, 17 February 2015 (UTC)

fwiw... the best [free] "tool" around for hardware and software status under Windows installs is SIV. I swear by it. When you get into mouse/monitor stuff; its usually a matter of hardware/GPU acceleration vs software acceleration. In this day and age, I doubt its behind this - nevertheless it is still the first advanced internet option even in IE 11 so better I mention it just in case.

As for opening a bug report - first; I'd wait until after tomorrow's 1.25wmf17 update has been rolled out to us to file a new report, and second; make sure you cross reference any other bug (open or closed) that seems to be related to your issue when you do file that report.

What happened when you edited on Test2? -- George Orwell III (talk) 04:23, 17 February 2015 (UTC)

The test2 editing was fine. Thanks for SIW. I had a very old copy but this is far more sophisticated. I will also wait for the new software release. Now, if I can only find the acceleration, that would be nice. In any case go to sleep. It's pretty cold here colder than where you are.Ineuw (talk) 07:24, 17 February 2015 (UTC)

Hi. Some additional info: On the Wikipedia test page it was difficult to ascertain the problem because the proofread document is in French. The topic was very interesting and great read, but I was slow to proofread, so it wasn't a good way to test it because the time lag between two pages also affects this problem. - The longer the time between proofreading two pages, the less of a chance for the mouse to freeze. This is a symptom I was aware of previously.

This being day two of the upgraded ProofreadPage extension (0d8cbb6), and it was much better, (you can tell by the number of pages I proofread), but the problem persists irregularly. I was able to proofread some 10 pages without any problems and then the screen froze again. I quit proofreading for awhile, and when returned the cycle repeated itself again. ~10 pages OK and then it froze as usual. BTW, yesterday, before starting to proofread, I disabled the hardware acceleration in FF but without it, the pointer movement is unstable, so I had to re-enabled it. As usual you were right about the problem is in the extension. Should I still file a bug report? Ineuw (talk) 19:05, 18 February 2015 (UTC)

Please consider the matter closed and I apologize for taking up so much of your time.Ineuw (talk) 05:07, 22 February 2015 (UTC)

@Ineuw:, How is it closed? You found the cause?... and stop apologizing - I'd rather help you cause I know you'll contribute (PSM Project) for months to come. -- George Orwell III (talk) 05:14, 22 February 2015 (UTC)

Months? I am looking at years. :-) I had to revert to the last version of Firefox (34.0.5) and now it works . . . for the time being. Ineuw (talk) 05:30, 22 February 2015 (UTC)

You don't seem to be alone - every so often a rash of FF reports go up on WP's Village Pump. Anyway glad you found it & on to the next clusterf*ck. -- George Orwell III (talk) 05:36, 22 February 2015 (UTC)

Pages tag for header

As I understand it, the <pages> tag can be used in place of a header, as it now has most of the functionality built into it that the header template has had.

However, during a recent replacement along these lines, the edit preview informed me that the page needed a {{header}} template and referred me to that template's documentation.

So, it the use of the tag in place of the template still in "beta", or is the warning message and documentation just out-of-date? --EncycloPetey (talk) 04:00, 19 February 2015 (UTC)

Can you point me to the specific example? -- George Orwell III (talk) 01:40, 21 February 2015 (UTC)

It happens on pretty much any page I edit in the Main namespace. E.g., open Green Mansions/Chapter 19 in an edit window to see the message. --EncycloPetey (talk) 05:11, 24 February 2015 (UTC)

I tried edit mode for the provided example and many other mainspace pages also using the header=1 approach without being able to reproduce what you are observing. Since you have no User: specific .js or .css file in place either, I can only speculate... its a gadgets conflict, a caching issue or something else specific to your particular settings &/or setup.

I know this gets "old" but I have to ask

• Have you made sure your browser caches are being refreshed as needed and are current at the moment?
• What happens if you try the same actions when you're logged-out as you've done when you were logged-in?

Otherwise, you might need to ask if this is happening to anyone else in Scriptorium just to eliminate these "just you" possible causes. -- George Orwell III (talk) 06:37, 24 February 2015 (UTC)

Yes, my browser caches are bring refreshed. I waited some time before bringing the matter to anyone's attention, so this has been going on for a while. Yes, the problem still occurs when I am logged out. --EncycloPetey (talk) 02:03, 25 February 2015 (UTC)

Hold on a sec... is THIS the "message" you're seeing? 'Cause if it is, it's always been there just not displayed so "high up" on the preview page until I "moved" the header, footer, license, authority control banner, etc. out of Dynamic Layouts.

I never supported this garbage version of Edit Notices since it was forced upon us with no way to "turn it off" until after the fact. Anyway, is that what you're talking about? -- George Orwell III (talk) 03:30, 25 February 2015 (UTC)

Yes, that's the message I'm seeing above every edit in the Main namespace. --EncycloPetey (talk) 14:39, 25 February 2015 (UTC)

But you never see THIS anywhere when editing an Author: page? -- George Orwell III (talk) 01:02, 26 February 2015 (UTC)

I do now, but didn't in the past. I edit Author pages so rarely these days that I hadn't paid attention to the author notice. --EncycloPetey (talk) 03:44, 26 February 2015 (UTC)

OK, then we are clear its not something as a result of any of my changes other than its position "shifting". In other words its not something I did but was also forced to live/deal with.

The only way to stop something like this is 1.) to speak up when such nonsense is 1st proposed (My POV was in the minority that time) to insure there is always an "easy" way to prevent its generation (if so desired); or 2.) to apply a workaround to deal with it after the fact. Unfortunately, both you and I are forced to use the latter solution at this point in the game. -- George Orwell III (talk) 06:47, 26 February 2015 (UTC)

Couldn't we at least have the text/links updated to reflect current practices? Or are we really required to use the {{header}} and are not to use the <header> tag. The warning message currently says this. --EncycloPetey (talk) 14:34, 26 February 2015 (UTC)

@EncycloPetey: using header=1 is the left-over dream of the original PR developer, ThomasV. The intent was never to make life "easier" for us but for other language WS projects to import/translate our works. I never use that method and always go with the full header personally. -- George Orwell III (talk) 19:19, 27 February 2015 (UTC)

Your old request on Phabricator is reactivated

I don't know if this is still relevant but you should check out Set $wgAllowImageTag to true on en.wikisource Ineuw (talk) 20:20, 23 February 2015 (UTC)

The Stone of the Sun and the First Chapter of Mexican History, written by Enrique Juan Palacios (1920), translated by Frederick Starr

On 23 February 2011, you deleted the page or pages under "The Stone of the Sun and the First Chapter of Mexican History, written by Enrique Juan Palacios (1920), translated by Frederick Starr". Apparently, you decided it contained "No meaningful content or history". I'm wondering what brought you to that conclusion: Did relevant scholars contend the document was a hoax? I'm curious as to why it went away, because it's still referenced in "Aztec calendar stone" at http://en.wikipedia.org/wiki/Aztec_calendar_stone and I was quite looking forward to reading it. If it was a hoax I am, of course, pleased you removed it! In the event I'd appreciate knowing something of your rationale for removing it, beyond "No meaningful content or history". I thank you for your effort and time. Best wishes to you.

MisterCat (talk) 00:28, 25 February 2015 (UTC)

Boy you're not going to like this -- it was exactly 44 bytes long; meaning the page was created but had little to no content in it whatsoever beyond that. Sorry. -- George Orwell III (talk) 01:26, 25 February 2015 (UTC)

Good grief! At least it had an impressive albeit irrelevant title. "No meaningful content" for sure. Grrr.... No wonder you gave it the axe! Thanks, George, for letting me know so quickly. MisterCat (talk) 02:24, 25 February 2015 (UTC)

@MisterCat: Guys. You might be interested to know that an earlier incarnation of this link from WikiPedia used to point to The Stone of the Sun and the First Chapter of the History of Mexico, which is still extant on WikiSource. Perhaps that is the article for which you seek?

• This edit introduced the link to enWS.
• And this one changed it to the reference George deleted above.

124.183.124.235 07:03, 25 February 2015 (UTC)

That's the document, all right. Thanks! Trouble is, I can't figure out how to download it so that its appearance is similar to how it looks on the Web pages. The resultant PDF (via the "Book Creator") is in an entirely different typeface and is bereft of the few graphics which are contained on the Web pages. Of course, there's no telling what else is missing. But at least I can come here to read it! -- MisterCat (talk) 19:49, 25 February 2015 (UTC)

New? "feature" heads-up

Yet another thing to make you cry:

• Mobile View
• Desktop View

of this monstrosity: Special:UserProfile/George_Orwell_III

Maybe you are already aware of it? AuFCL (talk) 23:01, 25 February 2015 (UTC)

Upon re-reading my note above and taking into account your propensities to interpret my commentary other than how I intended it be taken I should emphasise two points:

1. I consider Special:UserProfile to be the monstrosity, not the fact I used your name as the (insane, required) parameter for demonstration purposes. (Pray mw:Extension:SocialProfile is never installed. Say no more.)
2. I am merely drawing your attention to the existence of this thing. I have no suggestions/demands/expectations to "improve" it short of hoping it will go away just as "mysteriously" as it appeared.

AuFCL (talk) 07:56, 26 February 2015 (UTC)

Are you sticking around this time or not? My girlfriend wants to know so she has a rough outline on how to "play me" in the future. TIA. -- George Orwell III (talk) 08:13, 26 February 2015 (UTC)

Oh bloody hell, it begins. See above point regarding (mis)interpretation. There is no way is your asking for advice on behalf of your girlfriend (real or putative) is appropriate, comfortable or likely to result in any kind of positive outcome. Besides, I have neither ideas nor any incentive to undertake research on the matter.

Sticking around? Probably not.

I have since come across task T90632 which actually makes me look like a polite diplomat. Strap in and enjoy the ride. AuFCL (talk) 09:35, 26 February 2015 (UTC)

┌─────────────┘
You must forgive me. I'mn under the influence of flu medication (no pun intended) and quite loopy. My previous was not my best. More when I can. -- George Orwell III (talk) 20:40, 27 February 2015 (UTC)

Table that feels like it should be simpler than it is

Hi, I've just spent over an hour setting the table on Page:A Dictionary of Music and Musicians vol 2.djvu/578 only to discover that rotating the column headers didn't decrease the width or increase the height of the cells. Is it reasonable of me to assume that your CSS-3 explorations will solve this? If so, I'll just leave it as it is for the time being and move on to other pages until we're ready to go. (Also, if it will work, then this table might be a good use case.) Cheers, Beeswaxcandle (talk) 08:48, 26 February 2015 (UTC)

I'll look into over the course of the next few days but if memory serves me right, I don't believe "rotated text" is something that has been worked out just yet. Still, there might be new developments that I'm unaware of. I'll ping you back here either way. -- George Orwell III (talk) 20:36, 27 February 2015 (UTC)

Instruments.

Philharmonic, London.

Crystal Palace Saturday Concerts.

Conservatoire, Paris.

Gewandhaus, Leipzig.

Sinfonie Soirien, Berlin, 1880.

Philharmonie, Vienna.

Dresden Opera 1764, (Hasse).

Philharmonic Society, New York (Theod. Thomas).

Bayreuth, 1878.

Birmingham Festival, 1879.

Lower Rhine Festival, 1880.

Handel & Haydn Festival, Boston, 1880.

Handel Commem., Westminster Abbey, 1784.

Handel Festival, Crystal Palace, 1880.

Damn close but no way to invert the text to match the original (so far). I'll keep looking but the above is by far the "easiest" to grasp as well as to apply imho. -- George Orwell III (talk) 23:44, 27 February 2015 (UTC)

I'm only seeing vertical text in IE8, but not in FF (35). As you say, it's close and without the cross-browser issue I'd be tempted to go with it. Beeswaxcandle (talk) 01:17, 28 February 2015 (UTC)

@Beeswaxcandle:, I added -moz and -webkit to the first column selector; any difference in FF?

SEE ALSO An experimental implementation is available since Gecko 36. It is governed by the preference layout.css.vertical-text.enabled defaulting to false. -- George Orwell III (talk) 01:28, 28 February 2015 (UTC)

No difference. I'm not sure what to do with that preference, or indeed where it lives. But Gecko 36 is the current Developers' release (24 Feb), so I don't think it's available for me. Beeswaxcandle (talk) 02:24, 28 February 2015 (UTC)

Recent Revert

Just got a notification about a revert, but it didn't indicate the page, Was there a concern about something specific?ShakespeareFan00 (talk) 10:23, 28 February 2015 (UTC)

Not really. You put the reason for Proposed deletion as No file for Wikisource:Proposed_deletions#Index:United_States_Statutes_at_Large_Volume_50_Part_2.djvu when it really was some User: generated gibberish that warranted it's deletion. I just reverted your last addition/edit in order for the deletion log (only Admins can see) to show the gibberish first & at the top is all. Nothing to worry about & sorry I didn't close the Proposed deletion at the same time. -- George Orwell III (talk) 10:36, 28 February 2015 (UTC)

Add new mediawiki:blockedtext message by March 4-8

Hello there George Orwell III, can you add this block message please by march 4-8? Because the block message got deleted on 21 December 2013/December 21, 2013.

96.5.241.7 15:09, 2 March 2015 (UTC)

Get bent. Myself and others have told you before to take your suggestions and move on - this project's current approach [the default message] serves us well and there is no reason to change it. -- George Orwell III (talk) 21:07, 2 March 2015 (UTC)

Congressional Record standard formatting not working

What changed recently?

The Congressional Record standard formatting with the div/div style formatting isn't working lately.

Example at 2002 Wikipedia Press Release.

Any ideas on how to fix it?

-- Cirt (talk) 19:38, 10 March 2015 (UTC)

Any other examples that weren't copied & pasted from flawed press releases to begin with? -- George Orwell III (talk) 21:38, 10 March 2015 (UTC)

Well, prior to very recently, even if they did have formatting issues, as long as the first line of a paragraph was on a new paragraph line, (just press enter essentially at the new paragraph), the whole rest of the formatting looked great, but now, not. What changed? -- Cirt (talk) 21:48, 10 March 2015 (UTC)

Oh I see what you mean now & I think I've "fixed" it. Yes? -- George Orwell III (talk) 22:15, 10 March 2015 (UTC)

Hrm, I don't think so, as this version should still look totally fine, with the div formatting, but it doesn't. Any idea why not? -- Cirt (talk) 00:05, 11 March 2015 (UTC)

THAT specific example was flawed at the source (extra space before every line start) to begin with -- which is why I originally asked for another example that wasn't a 14 year old POS copy and paste.

Not for nothing -- and with all due respect -- are we really that lazy & dependent on wiki mark-up to do basic [re]formatting? It took me less than a minute to turn the line fragments & extra-spacing into proper paragraphs (which renders the current revision just fine under your just as ancient "prose" approach btw). -- George Orwell III (talk) 00:18, 11 March 2015 (UTC)

Hey man, I very much appreciate all your help, sorry if I've troubled you. Of course it's okay to do the formatting oneself, just was curious what prompted the code from looking different recently? -- Cirt (talk) 00:24, 11 March 2015 (UTC)

No worries & never a problem.... but that was a bad example to begin with is all. Sorry if it came-off otherwise.

Long story short: the recent "change" was an overlooked side-effect of me trying to switch Dynamic Layouts (MediaWiki:PageNumbers.js) to be a proper Gadget instead. Part of that script strips all existing classes before creating the 3 layered div "container" and instead of only executing on mainspace pages with content Transcluded in from the Page: namespace, it was stripping those common pre-proofreading extension classes on all pages regardless. (my bad 100%; sorry for the inconvenience -- it won't be the last time it happens I'm afraid). -- George Orwell III (talk) 00:41, 11 March 2015 (UTC)

Ah, okay, thank you. No worries, here, too. :) -- Cirt (talk) 00:45, 11 March 2015 (UTC)

Paragraph breaks with the fs90 and fs85 templates

• 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

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

@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 collection 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?

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

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?)

• 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

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 33^rd 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?

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)

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

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}}

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?

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

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.

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

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

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):

• Vocal Koala (warning: audio)
• Koala Vocal Folds

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

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

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)

File:Report on political entity campaign financial disclosures for 2007 Kosovo elections.pdf

Hello, I just wanted to notify you that a file you are connected with (either an edit to a page or the index) is nominated for deletion.

• Report on political entity campaign financial disclosures for 2007 Kosovo elections.pdf
• Deletion request entry

I did not start this request, but did want to notify you about it in case you have information to add. Thanks, The Haz _talk 17:22, 7 June 2015 (UTC)

Toolbar display error

Your opinion on - would be appreciated, as this display glitch seems to be a recent phenomena.ShakespeareFan00 (talk) 08:20, 8 June 2015 (UTC)

What about now? I think I isolated the problem & WikiEditor should no longer display like that - although if you're using the MonoBook skin you might have other display issues as per today's Tech News 2015-24 in Scriptorium. -- George Orwell III (talk) 17:02, 8 June 2015 (UTC)

Thank you :). We can flag this as resolved for now, although it might be worth flagging this iseeuse with the WikiEditor developers? ShakespeareFan00 (talk) 17:04, 8 June 2015 (UTC)

There really are no WikiEditor developers anymore - the focus for sometime now is the eventual roll-out & replacement of all existing toolbars by VisualEditor. It was a local thing anyway; I'll keep an eye out for similar pitfalls. Thanks for reporting it in any case. -- George Orwell III (talk) 17:14, 8 June 2015 (UTC)

Some beautiful fonts

My favorite is the 1st, the "San Francisco Text" — Ineuw talk 03:13, 20 June 2015 (UTC)

Thanks

Thanks for your help, can you tale a peek at the Scriptorium and see if you can help clarify two new questions.--Richard Arthur Norton (1958- ) (talk) 17:01, 24 June 2015 (UTC)

Serendipity: text-line-synchronised backgrounds?

Hi. I half recall you and Ineuw working on a project fairly recently to obtain synchronised background colour variations—Lofas Project, the various File:Lineheight* image set? (I hope this is not a false memory.)

Anyhow in looking for something quite unrelated in hopes of helping friend Ineuw I stumbled across [2] which I thought may be of interest; possibly even useful. AuFCL (talk) 10:57, 29 June 2015 (UTC)

Index:Mrs Beeton's Book of Household Management (Part 2).djvu

For some reason I can't at present determine, the forward and backward linkage for

Page:Mrs Beeton's Book of Household Management (Part 2).djvu/618 and Page:Mrs Beeton's Book of Household Management (Part 2).djvu/621

are still broken in that they link to (Part 1) not (Part 2), As I'm in effect the sole contributor on most of the transcription it seems it would just be quicker to mass delete the entirity of my efforts, and the index page, starting again with a KNOWN to be clean index page and pagelist. ShakespeareFan00 (talk) 11:06, 14 July 2015 (UTC)

The "problem" with the current approach was including Part 2's ToC on Part 1's Index: page. I removed that and now (I believe) all the page progression's are OK again. I don't know why that is case however - all I know it works.

IMHO, people waste far too much time fiddling with how the Index: page "looks" instead of insuring that it "works" -- accurately. NOBODY that I've ever spoken to outside of our little cabal of regulars ever gave a second look at the Index: page as long as the ToC pages within the Page: namespace were accurately done. Others obviously think that looks matter. -- George Orwell III (talk) 23:52, 14 July 2015 (UTC)

No progresss here, the pages listed above STILL mislink, even after a hard purge. As I said let's start with a KNOWN CLEAN version, where any possiblity of an underlying gltich has been removed.ShakespeareFan00 (talk) 08:59, 15 July 2015 (UTC)

Something is wrong at a lower level. And Commons is being "difficult" about uploading the non-split version of the Djvu file, as wellShakespeareFan00 (talk) 09:16, 15 July 2015 (UTC)

Now fixed, and I reinstated the ToC' as well, which so far haven't caused a reccurence of the gltich. I supsect what may have happened is "wrong cached version" and the server got confused. ShakespeareFan00 (talk) 09:29, 15 July 2015 (UTC)

And readding the ToC caused it to recur... I don't understand how that's possible and as I'm not prepared to spend any more frustrations on this, I just removed it entirely..ShakespeareFan00 (talk) 09:33, 15 July 2015 (UTC)

Page statistics change coming up.

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

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

Hi. What your change ([3]) 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

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?

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 dbl

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)

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

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 [4], 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

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. [5]. 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

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

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

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)

Not been seeing the bad images ...

I haven't seen the images added or where the cleanup may be, if I need to do some checking and some underlying blocking, then please let me know. — billinghurst sDrewth 16:37, 6 September 2015 (UTC)

@Billinghurst: some add'l background info.

In a nutshell, "new" images are not the problem when it comes to the restricted list -- some of the old restricted File: images were moved to new names on commons so the "old" names are (in effect) redirects. Subsequently, if you apply that redirect -- in spite the fact that name is listed on our restricted list -- you can render any blocked/restricted File:. Apparently, one can just create a redirect pointing to a restricted image and use that to render it.

I already went through our list and added the actual File: names the images in question are being hosted under but I'm sure its vulnerability elsewhere (as it still is on WP). -- George Orwell III (talk) 16:52, 6 September 2015 (UTC)

Silly stuff: table rendering

You will recall repeatedly referring me to this rendering specification? Well in trying to track something down today in code inspector I stumbled across this firefox internal url resource://gre-resources/html.css. I have no idea if that will work in Edge or whatever your choice is these days but if it works and you scroll forward to the line commencing "/* tables */" it starts to look really familiar (I'll quote a few lines only as a taste):

/* tables */

table {
  writing-mode: horizontal-tb !important; /* XXX remove when bug 1077521 is fixed */
  display: table;
  border-spacing: 2px;
  border-collapse: separate;
  /* XXXldb do we want this if we're border-collapse:collapse ? */
  box-sizing: border-box;
  text-indent: 0;
}

table[align="left"] {
  float: left;
}

Small-world syndrome? AuFCL (talk) 21:20, 13 September 2015 (UTC)

Thanks for this - wish I could see the whole thing somewhere (at your leisure -if at all). This does not seem contrary to the W3 spec nor 'defaults' found in IE/Edge but it does seem to reinforce the idea that 2 approaches are needed -- one for occasional complex tables (such as Billinghurst's linked example below) and another for the more typical repetitive ToC -type of "table" (again --> more list-item like than html table) renderings.

Will catch up with your latest over on ColTest talk page in a bit. -- George Orwell III (talk) 22:00, 17 September 2015 (UTC)

column width

Hi. Would you mind poking Page:The Slippery Slope.djvu/247 to get both first columns to be the same width on my ugly hack. Thanks if you can. — billinghurst sDrewth 12:43, 15 September 2015 (UTC)

I had a go with a blunt axe. Now GO_III may simplify the whole thing and embarrass us both? AuFCL (talk) 10:41, 16 September 2015 (UTC)

Well it looks right to me after AuFCL's edit. And I don't see any other way to achieve that result with marginally "less" formatting applied either. Good work AuFCL. -- George Orwell III (talk) 21:45, 17 September 2015 (UTC)

Sidebar Flat-list gadget

nice gadget. is there a plan, or interest in rolling this option out for other wikis? seems like an obvious hack to become more mobile friendly. Slowking4♡Farmbrough's revenge 23:31, 22 September 2015 (UTC)

Thanks for that - its nice to get feedback even now.

I mentioned it in Phabricator and a few other places when it reached the current stage but interest didn't seem to resonate with most folks back then. The main problem is the way Vector handles the site logo for all the other projects - our gadget uses custom dimensions to hold a string of font-glyphs to spell out Wikisource rather than a .png or .svg (otherwise the left hand tabs won't resize properly along with the recovered left margin from "eliminating" the sidebar). Other than making that modification in the current .js to spell out Wiki...., there is no reason it shouldn't work the same everywhere Vector is is the default skin. I'd be happy to help make it worth rolling out elsewhere if need be regardless. -- George Orwell III (talk) 20:17, 23 September 2015 (UTC)

Page:Ruffhead_-_The_Statutes_at_Large_-_vol_3.djvu/99

In the templates used here it's not possible currently to combine {{fqm}} and {{Dropinitial}}, It would be appreciated if someone experienced with doing complex layout efforts was able to look into this.

There is also the longer term issue of how to combine the various approaches taken in regard to sidenotes into "one" consistent, compliant scheme. (I'm using the cl-act series for this work because it's best solution to date.)ShakespeareFan00 (talk) 10:09, 25 September 2015 (UTC)

Does {{fqm|'}}{{di|W}} not work? You can try {{di|{{fqm|'}}W}}, but the quot mark is bulky... Consulting an expert may be best... Londonjackbooks (talk) 10:41, 25 September 2015 (UTC)

@Londonjackbooks: just noting the quote mark is "bulky" in your second suggestion because it it being 'sized' in the context of {{di}} (which defaults to 3× normal. Just try it in the—admittedly ridiculous on several levels—case of {{di|{{fqm|'}}W|1em}}.) All in all I lean toward your first suggestion (and just added a note to Template:Floating_quotation_mark/doc#Compatibility more or less to that effect.) AuFCL (talk) 01:56, 26 September 2015 (UTC)

Really? ..AuFCL/common.css

I am sure you are correct but that wasn't the particular damage to which I referred. I was testing, teasing you about your promise last week to make the proposed compass-point pos-n, pos-ne, pos-e, ... classes public last week upon whose presumed existence I coded the LUA sample (and did that not turn into a saga?) Now when the bloody thrice-damned (Sunday here no less!) thing finally runs I find the output is a joke because them thar classes, sort of, ain't. AuFCL (talk) 01:17, 27 September 2015 (UTC)

I know that's not what you meant but it was "wrong" regardless so I fixed it on the way to rectifying my omission from the other which is now in place. On the same note -- do you not have CodeEditor "features" available on most .css and .js pages? (enabled/disabled by toggling the <> button with WikiEditor in edit mode on those type of pages)

One of these CodeEditor "features" is the read out at the bottom next to the "stop", "yield" and "i"(nfo) symbols indicating the number and severity of "common" (stress common; does not always mean correct at the same time) script & stylesheet errors (if any) throughout the page.

If you have it (and it works) re-add the tab I removed and you should see the error "bang" appear at the left of that line. An explanation can be viewed in the message bar along the bottom of the window (or just hover your pointer on the line with the error). I'll stop here if this all first time news for you to allow you the chance to catch up.

I'll be catching up on your other posts in the interim. -- George Orwell III (talk) 01:31, 27 September 2015 (UTC)

Seriously CodeEditor defaulted to "off" for me here and I simply never noticed the point before. Interestingly, having enabled it once it appears to default "on" for subsequent edit attempts. (I just idiotically performed all that you recommended above before reading your recommendation to try exactly the same sequence out. So "caught up," at least on this one tiny issue. I had originally thought you were referring to that rather arcane rule about @charset having to occur in (I think) the first 4096 characters of an HTML document to be considered legal, and had dismissed this as unlikely bearing in mind all the cruft MW adds prior to any user-specified CSS.) AuFCL (talk) 01:55, 27 September 2015 (UTC)

Which brings me to the next point -- all of those @charset="UTF-8" that I've been adding to .css pages all this time at some point recently became unnecessary (if not non-compliant) per a handful of established validator checks. In some not-too-long-ago wmf update, <meta charset="UTF-8" /> was added to the HEAD section of every page (i.e. is now present by default) so all those manual additions to "smooth things over" prior to that change are now -- in essence -- redundant at least / non-compliant anymore at worst. One day - again when I get some good free time - I'll need to go through everything and remove every "local" instance of that rule. -- George Orwell III (talk) 02:08, 27 September 2015 (UTC)

It's been a long time . . . post #1

Hi. Still remember and think of you, if it means anything. So, just to keep you on your toes - there is a minor bug at the top of the Vector skin. The displays of "Your Alerts" and "Your messages" are cut off, in line with the text labels' baseline. If you need a screenshot let me know. — Ineuw talk 03:57, 27 September 2015 (UTC)

Known issue. Temp fix applied to your Vector.css. Its not perfect (several other real intricate adjustments are still needed for it to render "perfect" all around but I'm hoping the higher-ups correct all that jazz in next weeks' upgrade rather than bloat our local css files in the interim). Better? -- George Orwell III (talk)

Mobile rendering of WS pages

Perhaps you read my comments on mobile browsing in the Scriptorium. Also took yous words seriously about mobile displays and finally got my hands on a 5" screen cellphone to see how Wikisource and Wikipedia looks on a mobile display. In particular, I checked this on which AuFCL and I sweated for so long and it looks terrific.— Ineuw talk 04:37, 27 September 2015 (UTC)

That's great. Now that you actually have a cell phone to play around with, make sure you're visiting pages with the url en.m.wikisource.org -- otherwise its not a "true" mobile rendering that others are also seeing but something "in between" the normal desktop/mobile views that just you are seeing. -- George Orwell III (talk) 04:50, 27 September 2015 (UTC)

Did what you recommended and now I see some of the problems. Uploaded two images showing centering issues. Good night. — Ineuw talk 08:13, 27 September 2015 (UTC)

The table centering thing is by design - nearly all customized table "floating" (center & right; left being the default per the spec for tables) applied by the user is "stripped" in mobile view when the detected viewport (5 inches in this case) falls below some-yet-to-be-revealed-to-me pixel/width by design. There's not much you/we can do about that at this point in development. Sometimes simply rotating the physical phone itself by 90 degrees is helpful (e.g. going from portrait view to landscape view), so remember to check both for consistency's sake.

The other thing with the offsetting primarily to do with your preference of setting various widths in px rather than em (or accomplishing the same by imposing L & R right margins using percentages). I know that makes your desktop views seem consistent -- and they are just that to everybody else in the same ball-park as your settings happen to be -- but enter the realm of tablets and smart phones and those fixed-widths become problematic. For instance, the page grab you uploaded has such tiny text at first to accommodate one or more of the fix widths somewhere on that page that I must bump the font size up 2 to 3 "notches" to get the same font-size as a non PopScience mainspace work has by comparison. (using a 5th gen. iPod with latest iOS 9.0.1). More later when if I wake up. -- George Orwell III (talk) 09:05, 27 September 2015 (UTC)

Hope you had a good night's sleep, (I sort of did but not long enough). Was too tired to implement auto margins for the table, so I will try today. Both <center> or align=center didn't do it. All of this I find very interesting and hope I can contribute something to the process of improvement. — Ineuw talk 16:50, 27 September 2015 (UTC)

Page markers and terminating table row markers — we noted previously?

[I think that this has been raised before, I just don't remember the discussion/resolution]

Transcluding Chronicle of the law officers of Ireland/Chronological Table of Promotions, &c. and in the Page: ns and the respective pages have been set |- terminating the pages. From the main ns, if you look at some of the page numbering links through to the Page: ns they are hosed and ultimately point at Main page. For the first three transcluded pages I have moved the terminating row marker to be a lead row marker on the next page, and that resolves the page linking issue. At that point I thought that it was worthwhile point this out to you prior to further editing.

I can step through and fix all the errant tabular component, or you might see that there is an easy fix related to

• page 208 Y

<tr>
<td>July</td>
<td>8.</td>
<td>Richard Edwarde, Baron,—Draycott resigned. <span><span class="pagenum ws-pagenum" id="208" data-page-number="208" title="Page:Chronicle_of_the_law_officers_of_Ireland.djvu/233"></span></span></td>
</tr>

• page 209 N

<tr class="pagenum ws-pagenum" id="209" data-page-number="209">
<td colspan="3" style="text-align:center;">15 Eliz—1572.</td>
</tr>

Don't fuss that the table looks crap, that is in the process of fixing, re-engineering required from original transcription. — billinghurst sDrewth 13:40, 5 October 2015 (UTC)

and just found that it gives this ouch? ... Special:WhatLinksHere/Chronicle of the law officers of Ireland/Chronological Table of Promotions,_&c.

???? The pointers back to the siteUrl is new to me - its not the same old issue with spanning tables across multiple pages using wiki-mark up. I'm not even sure how we can figure out whats causing it until the table it self is rendering properly. Sorry. -- George Orwell III (talk) 21:40, 5 October 2015 (UTC)

It is quirky. I did a few later pages and it all seems to relate to the row marker. I have fixed the overlap issue, though will botify other repetitive text fixes. I will hold these fixes for a day in case you want another poke at the code. I will put an alert to the community to watch and review. Thx. — billinghurst sDrewth 06:47, 6 October 2015 (UTC)

I had more or less accidentally spotted a number of typos ("m" instead of "rn"; periods and comma interposed or missing; date column misaligned; and all sorts of incorrect dash usage. I might as well say this: not an outstanding proofing effort at all; and some of those pages were validated as well!) and had been chugging along slowly pushing things forward. If you would like me to stop right now and preserve a known error case until it is "properly" addressed I am happy to do so.

I have already mentioned my (fairly minor) misgivings about PageNumbers.js page-link creation beneath Billinghurst's Scriptorium post. I don't think this is by any means "broken" but maybe there is a crack or two in a load-bearing support could do with a bit of judicious reinforcement? AuFCL (talk) 08:44, 6 October 2015 (UTC)

Indeed; it is somewhat similar to the previous go-round you had dealing with this. To the best of my recollection, the matter hinges upon the in inherent behavior of wiki mark-up when it comes to tables. Take a table with just a single row as the primary reference point.

This...

{|
| cell 1
| cell 2
| cell 3
|}

... and this ...

{|
|-             <--- NOTE:
| cell 1
| cell 2
| cell 3
|}

... both produce the same exact thing in the end.

In the first example, there is no manual input of a table-row marker immediately after the opening table marker; the wiki mark-up/parser/Parsoid will "automatically insert" one before final rendering in order to comply with basic HTML formatting.

There is a table-row maker manually present in the second example so there is no need for the mark-up/parser/Pasrsoid to insert anything - it "passes" simply because the marker syntax is proper regardless of being the first table-row marker found immediately after the opening table marker or if it was any other table-row marker NOT immediately found after the opening table marker.

At the same time, this...

{|
| cell 1
| cell 2
| cell 3
|-             <--- NOTE:
|}

... will also produce the same exact thing in the end as the first two single row examples do. The manual input of a table-row marker immediately before the closing table marker will cause the wiki mark-up/parser/Parsoid to "automatically strip" that table-row marker before final rendering in order to comply with basic HTML formatting since no table-cell marker(s) are found immediately after it.

All things being 'equal', the simple takeaway here -- regardless of table elements being noincluded ON a Page: (or not) &/or any subsequent transclusion of table elements OF a page to another namespace (or not) -- should be to always strive to "follow the premise" that...

Typically, the 'final rendering odds' favor a manually inserted table-row marker residing immediately after an opening table marker but does not favor a manually inserted table-row marker residing immediately before a closing table marker.

Why?

Because a manually inserted table-row marker residing immediately after an opening table marker involves no automatic insertion or stripping by the wiki mark-up/parser/Parsoid -- it simply complies with proper marker syntax internally as well as HTML syntax externally (the HTML specification)

A missing table-row marker not residing immediately after an opening table marker has the 'additional step' of being "automatically inserted" by the wiki mark-up/parser/Parsoid to meet the same standard(s).

A manually inserted table-row marker residing immediately before a closing table marker has the 'additional step' of being "automatically stripped" by the wiki mark-up/parser/Parsoid to meet the same standard(s).

All NOP does, in its current incarnation is, provide a 'hiccup' for the wiki mark-up/parser/Parsoid in those instances where transclusion is involved. I find it "better" that it reside on it own and on the last line of the edit box of the preceding page; others might have a different/better view than I, however. -- George Orwell III (talk) 09:04, 6 October 2015 (UTC)

I hope that wasn't aimed top solidly at me alone because partly I already Believe™ but largely that went over my head anyway. (I'm just tired: don't be discouraged; it was a good rant.) AuFCL (talk) 10:39, 6 October 2015 (UTC)

Wasn't "aimed" at anybody in particular. I just wanted to put it 'paper' to see if anyone can find flaw with the premise outlined. You just happen to reply before I finished and had the chance to post it is all. I'm out of here until later today too. -- George Orwell III (talk) 12:39, 6 October 2015 (UTC)

Comparison of "Good" and "Bad" Page-links

These were captured from Chronicle_of_the_law_officers_of_Ireland/Chronological_Table_of_Promotions,_&c.. As the underlying Page:s appear to be currently subject to a storm of AWB activity I have no idea whether they can be reproduced at will (probably not. This is not how a fault ought to be analysed. My 2¢.) I find the code blocks captured from my browser) rather interesting:

A "Good" Link

<span><span class="pagenum ws-pagenum" id="215" data-page-number="215" title="Page:Chronicle_of_the_law_officers_of_Ireland.djvu/240"><span id="pagenumber_215" class="pagenumber noprint" style="color:#666666; font-size:inherit; line-height:inherit; font-family:monospace; font-weight:600; text-shadow:0em 0em 0.25em #A8A; vertical-align:top;"> [<a href="/wiki/Page%3AChronicle_of_the_law_officers_of_Ireland.djvu/240" title="Page:Chronicle_of_the_law_officers_of_Ireland.djvu/240">215</a>]</span></span></span>

A "Bad" Link

<tr class="pagenum ws-pagenum" id="216" data-page-number="216"><span id="pagenumber_216" class="pagenumber noprint" style="color:#666666; font-size:inherit; line-height:inherit; font-family:monospace; font-weight:600; text-shadow:0em 0em 0.25em #A8A; vertical-align:top;"> [<a href="/wiki/" title="">216</a>]</span></tr>

Note: not only is the link to Main page (per original complaint) but I am surprised the browser renders a SPAN at all enclosed by TR but with no intervening TD. Does this point to anything usable? Perhaps PageNumbers.js needs to more carefully vet candidates for insertion point? (Oh before I forget: captures were made with "Page links within text" mode enabled under "Display Options". Obviously everything lives as a DIV A nesting in "Page links beside text" and only the TITLE and HREF attributes differentiate between a "good" and "bad" link. The "bad" case is unsurprisingly: <a href="/wiki/" title="">216</a>.) AuFCL (talk) 10:39, 6 October 2015 (UTC)

I see what you're saying but not sure where exactly to begin to isolate possible causes. I'll think about that some more and <hopefully> have something by the end of the day. Otherwise: if its fixed it might just be worth moving on. -- George Orwell III (talk) 12:39, 6 October 2015 (UTC)

Oh it looks like it's been "fixed" all right. Forensics field day stuff. I'm outta this one. AuFCL (talk) 17:45, 6 October 2015 (UTC)

Collateral Benefits

Here is an unexpected side issue I'll share with you in case you are interested/know who to pass it on to. Buried in the middle of MediaWiki:PageNumbers.js is the following cryptic and somewhat alarming comment // don't know what the next 2 lines accomplish. Well I can confirm the precise purpose and necessity of retaining this code and even more weirdly the currently broken state of special:WantedTemplates makes finding examples a lot easier than normally would be the case.

The mystery "2 lines" looks forward one node on the DOM tree (var ll = page_span.parentNode.nextSibling;) and if it finds there (in effect examining the corresponding Page: transclusion to the page-link-under-construction) a red-link (ll.tagName === "A" && ll.className === "new": yes its cryptic) then it forces the new page-link to also be tagged as a red-link (? ' class="new" ' :.)

There is currently an easy-to-find example of this in action here (paired red-links at bottom of content).

I hope somebody finds this to be of use. AuFCL (talk) 17:40, 6 October 2015 (UTC)

Ah Ha! So please give me a better hidden summary so I can get rid of // don't know what the next 2 lines accomplish once and for all. Thanks! -- George Orwell III (talk) 23:29, 6 October 2015 (UTC)

I suggest replacing:

		// don't know what the next 2 lines accomplish
		var ll = page_span.parentNode.nextSibling;
		var class_str = ( ll && ll.tagName === "A" && ll.className === "new" ) ? ' class="new" ' : '';

with:

		// if transcluded Page: (ll) is a redlink then make page class (class_str) a redlink also
		var ll = page_span.parentNode.nextSibling;
		var class_str = ( ll && ll.tagName === "A" && ll.className === "new" ) ? ' class="new" ' : '';

Succinct enough for you? At least it might trigger some knowledgeable observer neurones into going off and researching the semantics of using class="new" in the context of mediawiki? AuFCL (talk) 06:51, 7 October 2015 (UTC)

Adjunct thought: if you don't trust my code analysis and want a quick verification whilst you're in an "editing PageNumbers.js frame of mind" you might consider adding this temporary line:

		// don't know what the next 2 lines accomplish
		var ll = page_span.parentNode.nextSibling;
		var class_str = ( ll && ll.tagName === "A" && ll.className === "new" ) ? ' class="new" ' : '';
		class_str = ''

Save the result and visit any main space page containing a <page> directive to transclude a missing Page: (e.g. our old friend). All ought to work perfectly as normal, except the page tag will not be red. (Obviously remove the line as soon as you are satisfied it makes a difference. Must...not...upset...or...teach..the...punters...that...would...be...sedition!) AuFCL (talk) 07:09, 7 October 2015 (UTC)

Adjunct thought 2: (Promise this will be the last one.) What looks like a red-link but is actually a normal link coloured red? The bloody page-links added by the above fragment when the transclusion fails in this very particular way. In fact my test proposal generates more honest output in that the blue links land you on the correct Page: but without invoking a pre-emptive "Create" operation as following the rather more obvious "Page:Three Books of Occult Philosophy (De Occulta Philosophia) (1651).djvu/166" would do so. Consider saving this thought away somewhere for use on a rainy day BUT DO NOT DO NOT FOLLOW THESE INSTRUCTIONS NOW! Suggest replacing (I shall assume you haven't improved upon my earlier suggestion):

		// if transcluded Page: (ll) is a redlink then make page class (class_str) a redlink also
		var ll = page_span.parentNode.nextSibling;
		var class_str = ( ll && ll.tagName === "A" && ll.className === "new" ) ? ' class="new" ' : '';

		$.data( page_span, "link_str", '<a href= "' + page_url + '"' + class_str + ' title= "' + mw.html.escape( page_title ) + '">' + mw.html.escape( name ) + '</a>' );

with:

		// if transcluded Page: (ll) is a redlink then make page class (class_str) a redlink also
		var ll = page_span.parentNode.nextSibling;
		var class_str = '';
		var action_str = '';
		if ( ll && ll.tagName === "A" && ll.className === "new" ) {
			class_str = ' class="new" ';
			action_str = '?action=edit&redlink=1';
		}

		$.data(
			page_span,
			"link_str",
			'<a href= "' + page_url + action_str + '"' +
				class_str +
				' title= "' + mw.html.escape( page_title ) + '">' +
				mw.html.escape( name ) +
			'</a>'
		);

Now both red-looking things are genuine red-links. Just another option to consider. One day consistency might actually be appreciated? AuFCL (talk) 07:49, 7 October 2015 (UTC)

Ok its implemented (please check) and I think I get the difference - the old way opened the page to the text giving you options (one of them create [this] page), while the new way opens the page to right to edit mode? -- George Orwell III (talk) 03:55, 8 October 2015 (UTC)

Bloody hell, what is it about you Yanks and following instructions? (Seriously: well done! Consistency, glorious consistency. Now on to the next of the other $\aleph _{0}$ issues remaining.) Oh and by the by haven't we just identified the precise area of code to implement that little link-suppression requirement of Scriptorium/Tables and terminating row markers? You just can't bet serendipity. Just have to figure out how to detect mobile mode from javascript and conditionally drop the A-tag generation from the above and you are done?

And yes, your bit about the different modes of operation of the "old" red-coloured links was what I had been trying to explain originally...and clearly had failed utterly to do so. It completely blows me away so much effort had been taken to create something which looked like a "create-page-and-go" link but in fact was nothing of the sort. If you are going to the effort of putting up a "Danger" sign and then putting the tiger behind the unmarked door across the street instead you should not be surprised when Johnny Public no longer takes you seriously, no? AuFCL (talk) 04:50, 8 October 2015 (UTC)

I did a bit of further background digging and turned up a couple of surprises to myself at least. You may well already know all this and if so I apologise ahead of time for boring you. Nevertheless I thought it might be useful to note these down together:

• class="new": despite the name has nothing whatsoever with new links beyond usage precedent except insofar as it yields the standard color: attribute (#BA0000)
• API parameter redlink=1: despite the name has nothing whatsoever with regards turning a normal into a "creation" link (API parameter action=edit does that as an "accidental" by-product of its use.) In fact the presence of redlink actually instructs the API to abort the creation operation if the invoked link is found to exist by the time it is actually executed. AuFCL (talk) 06:34, 9 October 2015 (UTC)

Problem with the enhanced toolbar code in my common.js

Hi GOIII. The day the (1.27.0-wmf.2 (2b6cc01) 19:16, 8 October 2015) was rolled out in WS, I began having problems with my enhanced editor toolbar setup. So, I filed a bug report in Mainphest. You can read the details there. Interestingly, this problem is restricted to Firefox in Windows but it doesn't happen in Windows IE11, Chrome, or Opera. So, The last thing I did is that I excised the code from my common.js relating to the enhanced toolbar, and everything was OK, except that I lost the "mdash". So, today, I restored the code and the problem is back now on every page I am editing. I was wondering if you could delete the code but leave the mdash? — Ineuw talk 05:05, 11 October 2015 (UTC)

Everything is back to normal for the time being.— Ineuw talk 18:04, 11 October 2015 (UTC)

Need some help

or will go nuts soon:) @George Orwell III: could you please explain to me what populates categories: Category:Author pages with authority control data, Category:Main pages with authority control data and the like. Cheeers, Captain Nemo (talk) 11:14, 12 October 2015 (UTC)

Sorry for bother. Figured it myself, it's Module:Authority control. Cheers, Captain Nemo (talk) 12:07, 12 October 2015 (UTC)

Guidance is asked for some minor irritating issues

The changes of the last wmf update affected my working environment in small but numerous ways, and which I would like to remedy if possible. This is not a request for your precious time (nor the precious time of your sidekick, Tonto, no offence intended), but rather an enquiry if you think it's worth bothering with. Of course, I can always bug the people at Maniphest.

1. When, proofreading, lost my default settings which displayed my selection of the character bar (it used to be always set to "User") when I began proofreading. (This is aside from the fact that there are too many silly character sets).
2. When proofreading, I lost the default settings which displayed enhanced editing toolbar with the default of the header/footer toggle. (This is an issue apart from my recent bug report to in Maniphest.)
3. I must assume that previously, these were stored in the WS cookies(?).
4. If I decide to file a bug report, to whom shall I report this changes at Maniphest?

Your opinion matters, Lófasz (please note the capitalization of (y)our favourite word). — Ineuw talk 03:44, 20 October 2015 (UTC)

This post has lost its validity. — Ineuw talk 21:21, 20 October 2015 (UTC)

Hakluytus Posthumus

Thanks a lot for helping out with Hakluytus Posthumus! I feel like I need to say a few words about the importance of this particular fragment in literary history. Apart from substantiating obvious ambitions of the British to follow in the footsteps of the Portuguese and the Spanish in exploring the world and penetrating into the Chinese market, these descriptions of Chinese society and language (among which the most detailed was that of Matteo Ricci, or Ricius as he is called in Hakluytus Posthumus) probably influenced the Utopian / pioneering science fiction works, most evidently in The Man in the Moone by Francis Godwin which in turn influenced later sci-fi works like J. Swift's "Gulliver's Travels". --Tar-ba-gan (talk) 13:30, 25 October 2015 (UTC)

Stripping Hickie

Would you be able to strip out the Google notice page from File:Comedies of Aristophanes (Hickie 1853) vol1.djvu? Or point me to someone who could? Removing the Google notices is one of the few things I'm still unable to do myself. --EncycloPetey (talk) 22:59, 31 October 2015 (UTC)

Done -- George Orwell III (talk) 23:22, 31 October 2015 (UTC)

Special:GadgetUsage

Tracked in PhabricatorTask T117120

I think I recall a long-ago conversation between Mpaa and yourself looking for something like the above promises to deliver? However I simply cannot believe (for example) nobody on enWS has "Easy_LST" enabled so can only hope the first few statistics cycles reflect flawed data. After all only a total cynic might suggest the calculations being made were (say) [total number of active users - reported figure] or suchlike? (In case you were wondering my "born with a silver spoon" was badly tarnished.) AuFCL (talk) 10:49, 3 November 2015 (UTC)

I was wondering if I should have quoted these before. The request/history is in phab:T115152 (now closed obviously); and phab:T116894 is open, relevant and may be of interest as well. AuFCL (talk) 07:00, 4 November 2015 (UTC)

Yes the open ticket you linked would compliment the other one nicely. The current count has got to be 'stuck in the past' or something. -- George Orwell III (talk) 07:08, 4 November 2015 (UTC)

Re: {{Hyphenated word start}}

Yes, well, umm... I know! Just exercising the job queue Sir!

(Grumble: I am sure I raised the trigger issue with B. months ago and proposed a solution back then... bloody inaction on the part of idiots who don't stuff up..all...their....edits..... Oh my! AuFCL (talk) 07:44, 17 November 2015 (UTC))

Index:The Battle of Jutland.pdf

I'd like a third opinion, I marked the Image pages specfically in a recent update, however certain other contributors have expressed a concern about this in respect of validated works, so I am happy to revert the changes, However I would appreciate a third view before doing this.ShakespeareFan00 (talk) 15:28, 21 November 2015 (UTC)

Index:The Aspern Papers.djvu

On a simmilar note, how do you mark something that's clearly a publisher imprint? (Fly perhaps?) ShakespeareFan00 (talk) 15:29, 21 November 2015 (UTC)

A question about the FIS template

Hi. Is it possible to insert a table in the FIS template? as I would like to do it HERE to eliminate the split paragraph? — Ineuw talk 19:56, 26 November 2015 (UTC)

What's wrong with setting display: to inline-table for the opening table tag? -- George Orwell III (talk) 22:59, 27 November 2015 (UTC)

Oh never mind... I see AuFCL had a better solution in place already. It wouldn't work using wiki mark-up table notation anyway; only true HTML table tags. -- George Orwell III (talk) 23:03, 27 November 2015 (UTC)

Sigh. It doesn't even help then. The real issue is that transitioning out of a running paragraph into a table (of any ilk or notation!) is responded to be the parser by slamming in a mindless </p> and you simply can not get around that. The whole DIV as a faux-P makes me heartily sick; yet is a practical example of how "what works" has to triumph "what is right" in this environment. If we are going to play the "if only" game: If only HTML had specified P as a reentrant enclosing element like DIV. But they didn't: and here is a necessary cost of that decision. AuFCL (talk) 00:07, 28 November 2015 (UTC)

Template:Wikilivres under footer

Hi. In the main namespace, where Template:Wikilivres is used, eg. Which Will Scarcely Be Understood it appears under the footer. Is this purposeful? To me it looks out of place. That said the whole citing a work and having nothing is still weird to me, and author pages should be the place we have a redirect page.

Unfortunately, the original designers thought it best to use a license based banner to effect what amounts to a soft redirect leading off-site. Why we need a footer for something that has no hosted content is another matter; why footer generation to begin with is not User: optional is still another matter.

Where would you like to start? -- George Orwell III (talk) 12:09, 29 November 2015 (UTC)

A Hiding to Nothing?

Please accept my heartfelt apologies for stepping upon your toes here. I (perhaps unreasonably) consider I have a foot in all camps concerned, yet have very little sympathy when it comes to administrators effectively calling for user support in propping up (clearly otherwise ineffective) sysop support. From one perspective the request were better made in Wikisource:Administrators' noticeboard and from the other any admission that sysops are not already all-powerful isn't necessarily going to lead anywhere nice...

As perhaps I have already expressed over-forcefully elsewhere if there is any problem that wikisource is unable to solve locally there is bugger-all chance anybody else will help solve it for us any way.

Hey it isn't as if I have any friends left here that care about that I haven't already p***d off already. Ostracism simply means effective freedom to tell the truth precisely as one happens to see it. AuFCL (talk) 02:04, 3 December 2015 (UTC)

Tsk... no need to apologize; you raised a valid point and expressed it rather plainly/respectfully so you did nothing wrong. I stopped what I was doing, considered your point as if a newcomer to the situation, clearly saw how "vote" could be construed at the least as over-bearing (if not lobbyist-like) so I made the change.

Your "second" point took a couple of re-reads before I felt I had a handle on the gist of the concern ('something sinister is afoot' - which I realized I also felt at first until I found the 'Phase 1' post, clearing the 'air' as a result); hopefully 'my dismissal' for "being too late to the party to complain about the hostess" didn't go over to harsh.

Finally (in confidence, here; alone together on my talk page) it's not like I don't know the current state of support sucks, development sucks, consensus sucks, administration sucks and so on. Or that little if anything will come from anything proposed this time either; I'm simply providing a little extra (documented) rope so "they" can hang themselves with greater ease when that personal view becomes a public reality.

Now get back to fixing the internet while I try to unravel the secrets of api_purge.php -- George Orwell III (talk) 02:32, 3 December 2015 (UTC)

Yah, well, I am well known for being "bitter & twisted (and lesser known for being unabashedly proud of said status)", so all criticism taken as constructive (especially (and aggressively) if not innately intended to be so taken. Bugger the sinister aspect as the window-dressing it inevitably turns out to be—I change the world as I can and regret only the inability... manifestos aside I will help where I can and offer sympathy where I can not... Thus far I believe we are in accord, on the same side, albeit in perhaps differing capacities. AuFCL (talk) 02:43, 3 December 2015 (UTC)

I truly believe that unless WikiSourcians (if I may coin such a term) can analyse any offending issue down to the level of "kindly, developer, change line xxxx to read yyyy instead of zzzz" we will not be taken all that seriously.

Even if we have to go through such a painful experience once or twice it will be worthwhile all round: both we (this community) will gain a degree of appreciation for the complexity of the monster mediawiki is/has become; and the developer community might reciprocally gain some degree of respect for a grouping which can come up with better than "poem is broke—you bastards had better fix it or we will cry!" and one which can hold a given solution to true account.

Need I re-quote the recent example of the travesty of special:wantedtemplates where a uselessly-specified user requirement was misinterpreted by a developer without challenge by end-users. Just how did that pan out for wikisource; and what has been done about fixing the total abortion-candidate that is the current consequence? Do I really need to say more? AuFCL (talk) 03:27, 3 December 2015 (UTC)

Pardon, are you sure:

this does not "look" right. Did you perhaps mean "forcerecursivelinkupdate: 1," instead? (In fact no change at all.) AuFCL (talk) 05:06, 3 December 2015 (UTC)

That's just it - I was expecting some sort of error message or console log alert. I became suspect that this damn force... via the Purge Gadget hasn't been doing anything more than a file cache purge after reading the contrary documentation note HERE saying one thing while THIS states another.

In short, when the "url" is ...w/index.php... only action=purge is valid and that is what the Gadget generates as a link. (it does have a "follow-up" event listener that seems to perform the correct url string execution using ...w/api.php... but its not giving me an error when I broke on purpose.

More as I discover it. -- George Orwell III (talk) 05:24, 3 December 2015 (UTC)

Oops. Pull my stupid head in. Good luck with the experiment. AuFCL (talk) 05:54, 3 December 2015 (UTC)

Template:Heading/parse

You reverted my changes here, I was trying to format some headings elsewhere - Page:Tenorio v Pitzer 10th Circuit.pdf/7, and it seemed reasonable to use the heading template, with some additional styles to offset the title, which in the CSS for the page is the additional margin-left, Without the pass thru, the additional styling is completely ignored.

Had something broken? ShakespeareFan00 (talk) 00:25, 15 December 2015 (UTC)

Another Google strip request

Could you strip the Google notice from the front of File:Euripides (Mahaffy).djvu?

Note: this is is uploaded locally, since it will be about 4 years before Commons will allow hosting (published 1879 in the UK; author died 1919; Commons has no license template between 80 and 100 years). --EncycloPetey (talk) 03:45, 17 December 2015 (UTC)

Sorry if I high-jacked the request. I took the chance to test a tool that I would like to put on tools-lab for this purpose. Bye— Mpaa (talk) 23:47, 17 December 2015 (UTC)

Er... PD-old-70 is fine for Commons if it's a UK work. We just want to know if it's PD in the UK. There are 80 pma countries, and Mexico is supposedly 100 pma, which is why we have those higher tags, which you can use if they apply (PD-old-80 would also work) so that users in those 80pma countries know it's also OK there. [Mexico is realistically about 63 pma at this point though... the 100pma is in name only.] And actually you'd probably use {{PD-old-auto-1923|1919}} which indicates that it was published before 1923 for US purposes, and the date of death of the author, so it will auto-update to PD-old-100 when appropriate. Carl Lindberg (talk) 23:51, 17 December 2015 (UTC)

NIOSH Hazard Review: Carbonless Copy Paper

Found a small issue here, apparently there are some 'illegal charcters' the page number script doesn't like, is there a list so that contributors can be advised accordingly? And thanks for the fix you made on Compendium II. ShakespeareFan00 (talk) 21:48, 23 December 2015 (UTC)

And a bonus, I took the solution I used on the above and applied to something that really hadn't been working for some time and ... success :) . With a little further investigation into what the pagenumber script expects, and an update to the documentation, a number of page number related issues can I think be quickly resolved by cleaning up the relevant Index pages :). ShakespeareFan00 (talk) 22:13, 23 December 2015 (UTC)

Checker: variant upon a theme

Thank you for providing some of the history I was missing on this (I note Mpaa came up for mention there too, so presumably is equally versed?) I did evolve my variant into an only slightly less dangerous form which Ineuw seems to think is the latest shiny thing even after repeated warnings that I fear will bite him. I take on board your concerns regarding it encouraging sloppy proofreading but wish to balance that against its advantages in detecting those "hosted content" OCR errors you also mentioned. If you think it a bad concept I am happy to drop it (or alternatively if somebody wants to make suggestions for fundamental improvement I am equally amenable to incorporating them or handing over the thing as it currently stands.) AuFCL (talk) 05:21, 29 December 2015 (UTC)

With the caveat that I'm still trying to catch up on everything that I've missed since my last "real" visit a couple of weeks ago -- I don't see why something like that can't be further developed in general but personally don't think it is a priority is all I'm saying. Plus I feel the real issue is with the degree of proofreading taking place - if we're finding such errors on validated pages we need to identify and advise the individual(s) to "do a better job"; not clean up after them post false status changes ...or try to BOT the crap out of everything in some attempt to cover up this nasty "reality" either. -- George Orwell III (talk) 07:28, 29 December 2015 (UTC)

People tend to do what they are rewarded for. Unfortunately all of the wikis have a tendency to value high edit counts (probably because that is easy to measure; whereas quality is rather more difficult.) As for the usual suspects I am sure you have a list of repeat offenders in mind, as do I.

Anyway the thing was an attempt to anticipate Mpaa's proposal by other means and as such I more found it yet another interesting exercise rather than of any priority whatsoever, or however misguided. Anyway, further explicit requests aside (most likely from I-friend) my personal intention is to drop it. AuFCL (talk) 11:19, 29 December 2015 (UTC)

Sorry to intrude ... My idea for checker-on-save was a way to "advise the individual(s) to "do a better job";" right away upon page save.

It is not to substitute other bot checks that we can think about. I am scanning PSM with other tools, and if the proofreader would have been warned right away, many errors would have not slipped through.— Mpaa (talk) 11:55, 29 December 2015 (UTC)

@Mpaa: - intrusions from you are always welcome here my friend.

Let us think this though for a second; so you want something to merely to advise the User: upon a save attempt that possible "typos" still exist and then let them be manually corrected (or automatically) corrected, right? If so, I assume the ability to simply ignore the "advice", hit save a second time and having the page saved with "detected typos" and all will still be possible - making this endeavor a bit more bullet-ridden instead of more bullet-proof the way I see it. And one of the caveats that pr-typos [indirectly] considered that this approach does not seem to factor-in was in those instances where proven false positives were neatly handled by a template(s) so the "next guy" would not be provided with the same false-positive again (and again?).

That said, I'm still not against pursuing what could be a valuable feature for most non-dickish, going-to-skip-the-detected-advisor-regardless contributor. I'm merely pointing out that it's not a guarantee that the "advice" will always be addressed and acted upon accordingly (making the development of this a low-priority in my own humble opinion).

On the other hand, develop it more like a regex expression-rich Abuse Filter where it is possible to either tag "ignored" matches that are saved without correction all the way up to blocking the save entirely unless the matches are addressed first (i.e. templatize the false-positives along with correcting the true errors), and then my support would be unwavering. Again, I'm just tired of being promised one thing, getting something less-than-promised delivered, having it fully rolled out & implemented in spite of that fact, but - because it seems to be a 'fractional improvement' at first glance only by a few enthusiastic Users - it still manages to become some sort of default, sacred-cow, untouchable standard for the rest of time. Even worse, it becomes a site wide default that -- at best -- one can opt-out of rather than only be in use if one decides to opt-in for it instead. There are too many features like this that are layered on top of and/or reliant upon each other as it is. -- George Orwell III (talk) 00:23, 31 December 2015 (UTC)

We can set the bar as high as we want regarding the ambition level. I do not have enough skills to develop such 'checker' so I started with a low profile, i.e. your assumption above: Detect->-Suggest->Warn and then it up the user conscience (in my view this will cover many from good but tired proofreaders ... I guess most proofread after RL :) ). This should be relatively easy to implement. But I would fully support also a more sophisticated concept.— Mpaa (talk) 10:10, 31 December 2015 (UTC)

Is there a less sophisticated approach? - is figuring out how get your existing spell checker (and/or grammar checker if you have something from Microsoft Office or similar installed) to "work" against the entire content of the textarea element upon request or upon a preview instead of just scanning the changed or new content being added a possibility?

Most browsers have a way to enable their built in or complimentary checkers simply by toggling/adding a setting or something. I know outside of the wiki world; I can add spellcheck="true" to most input or textarea elements and spellchecking is up and running on that edit session or input form right away. There has to be an easy way to the same for the three most popular browser platforms while under the wiki mark-up, no? (again way beyond my knowledge personally). -- George Orwell III (talk) 11:13, 31 December 2015 (UTC)