User talk:Ineuw/Archives/2016-06-30

PSM Consultation: {{Pt}}?

I wanted to address a quite unrelated matter on Page:Popular Science Monthly Volume 67.djvu/199 but before I change anything at all there please have a look at this page and let me know what you think. The <ref> (second parameter to {{Pt}} "floats strangely" upon normal page display due to the long title (first parameter) wrapping around and the reference being rendered in its' very own table cell. Is there a good reason why it is presented this way, rather than as an optional adjunct to the title? If represented this way then wrapping effects "make sense" again but I am hoping you know better (and perhaps will please explain to MereMortals™)? AuFCL (talk) 10:10, 31 December 2015 (UTC)

Hi. I saw it and corrected it as best as I knew how. This problem occurred elsewhere as well. <history>The pipe "|" was intended to separate the {{Pt}} font size from the "ref" number font size, but it works only when the title is shorter. If one removes the pipe, this also has unintended consequences.</ history> I only care about the title font, size and the line height when the title wraps to the next line. If you want to tweak the template and make it look closer to the original, please feel free to make any modifications you see fit. — Ineuw talk 18:02, 31 December 2015 (UTC)

Thank you. Your edit to the Page: was precisely what I would have proposed. I have further incorporated the changes I originally intended (and more!) into a validation operation so I hope the result is to your satisfaction too.

As for the template; it generates a stand-alone table viz:

{| {{ts|mc|bc|bgt}}
|-
|{{ts|ac|pb.5|font-family: liberation, serif; font-size:125%|line-height:1.20em;}}|{{{1}}}
|{{ts|sm80|al}}|{{{2|}}}
|-
|}

I would propose amending it from a two- to a single- column version like this:

{| {{ts|mc|bc|bgt}}
|-
|{{ts|ac|pb.5|font-family: liberation, serif; font-size:125%|line-height:1.20em;}}|{{{1}}}{{#if:{{{2|}}}|{{span|fs80}}{{{2}}}</span>|}}
|-
|}

—which ought to work irrespective of whether its first parameter wraps around or not. Any objections to me making the template change? AuFCL (talk) 21:21, 31 December 2015 (UTC)

Just go ahead do whatever you think is best. All my title templates were done when I knew even less than now. Hard to believe isn't it? — Ineuw talk 01:59, 1 January 2016 (UTC)

I just made a dummy edit of the template and previewed a random page Page:Popular Science Monthly Volume 4.djvu/11 which happened to meet the criteria. The result looks O.K. but here is a small mystery: to match the dimensions of the superscripted reference number using a span requires font-size:60% whereas on the old table-cell the factor was 80%. There must be some kind of ripple-effect I had not accounted for. I also threw in a small amount of padding to cater for the (now lost) invisible table borders and padding. I hope the result meets your exacting standards.

How do I answer your last question without losing a gumboot in the morass? AuFCL (talk) 02:47, 1 January 2016 (UTC)

Needed to adjust the template and used  but I don't know why the table increased the row space below the title and the author. Can you figure it out why? — Ineuw talk 09:25, 1 January 2016 (UTC)

P.S: removed the bottom padding as well. — Ineuw talk 09:26, 1 January 2016 (UTC)

O.K.:

1. I forgot completely to revert Page:Popular Science Monthly Volume 67.djvu/199. Thank you for remembering.
2. I don't understand at all about the template changes. Your net edits since mine have almost completely reverted it to an earlier state, but with {{ts|vtt}} now applied to the row. What did I do wrong? AuFCL (talk) 09:40, 1 January 2016 (UTC)

You didn't do anything wrong. I couldn't figure out where the {{ts}} and the <span> fitted together. Rather than reverting to an earlier version, I removed the span and used the superscript for the ref number. In the span, the superscript and the vertical text-align didn't work and the ref number ended up in the middle of the title text and not on the top. Also, couldn't figure out how to put the .33em padding back to separate the superscript from the end of the title.

I suggest we should copy the template to a sandbox and figure out why is the row below the table and the author is so high and everything else. — Ineuw talk 11:32, 1 January 2016 (UTC)

@AuFCL: Found the reason for the large gap between title and the author name. :-) — Ineuw talk 20:37, 1 January 2016 (UTC)

Oh Bloody Hell! I am so sorry. I remember introducing that when I "cut in" the span code and thinking I would need to fix it up again. A telephone call later and…instant virtual senility! Think I'd better stay away for a while and think on being stupid. AuFCL (talk) 20:43, 1 January 2016 (UTC)

Please don't fret. Would have not have realized the issue if I did not spend an unreasonable amount of time on exploring the effects of line feeds and carriage returns in the world of HTML. Now to push my luck further, I will be adding the padding-left:0.33em to the <sup> tag. According to the W3 it is applicable. — Ineuw talk 21:08, 1 January 2016 (UTC)

Typo script - a tall request

@AuFCL: Although it may already be so, I don't wish to appear nagging you, but rather try and persuade you with my twisted logic.

The JavaScript typo script is excellent, in fact may be too good. (How is that for a compliment?) If it's possible, would you modify it to have the script check the page status, so that only proofread or validated pages are acted upon. I ask because a raw scan will always show up any and all typos, and seeing them at their raw stage is not important, but the JavaScript freezes the browser and it takes forever to let go. I only tried it on Firefox, but will test this on my other browsers. — Ineuw talk 22:56, 1 January 2016 (UTC)

I take your point...but here is an example which shows how messed-up that may become if I put it into practice: Popular Science Monthly/Volume 56/November 1899/The Real Problems of Democracy transcludes pages which are not proofread. If I were to incorporate a test for proofread status it would kill both Page: space scanning (good) but also this transclusion (which might happen to be the trigger for somebody to go "Hey, what?" Do you see the problem?

Please try reducing the typoFuse count from 10 to 5 and see if that reduces lockups for you. If that fails I'll modify the code to bail out more aggressively when the count is reached. Please let me know how you go. AuFCL (talk) 23:17, 1 January 2016 (UTC)

I understand, but I don't believe it to be a great problem because the transcluded pages' status is indicated on the top of the page. Also, I offer to write the documentation to clarify any limitations. Also, we can omit the main namespace for now and try it only in the Page namespace. — Ineuw talk 23:30, 1 January 2016 (UTC)

O.K. Done. Latest version is (based once more upon your own latest set-up) in User:AuFCL/common.js/typoscan.js. As best I can make it it is what you asked for but I truly suspect it is not what you want. Only time will tell. AuFCL (talk) 00:18, 2 January 2016 (UTC)

Dear I. I am sure I reminded you of this some time ago. Kindly open up your Ineuw/common.js and DELETE lines 25–58 inclusive. You have a whole extra copy of an obsolete version of function HighlightTyposUnder and that, probably more than any single other factor is the cause of your occasional JavaScript freeze. Please, please do this right now. AuFCL (talk) 03:29, 2 January 2016 (UTC)

Done and thanks. — Ineuw talk 03:32, 2 January 2016 (UTC)

No you did not. I asked you to delete 25–58 and you actually deleted 25–28 (I am getting concerned as to your eyesight.) Now please delete lines 26–56 of what remains. You should end up with this fragment (obviously with existing code above and following—this is just to show what the "join" ought to look like):

window.charinsertCustom = {
	"User": ' —  œ  £  §  ·  º  Æ  É  Ë  Ñ  Œ  Ó  Ö  à  á  â  ã  ä  æ  ç  è  é  ê  ë  î  ï  ñ  ò  ó  ô  ö  ù  ú  û  ü '
};

// <nowiki>
var typoFuse = 5;	// maximum limit on number of items to highlight

function HighlightTyposUnder( node, pattern, emphasis ){
  if( typoFuse >=0 && node ){
    if( node.nodeType == 3 /* TEXT_NODE */ ){

Goodness knows why it is so necessary to keep a sharp eye on these sysop types! AuFCL (talk) 03:55, 2 January 2016 (UTC)

Sorry, now, I hope it's OK. — Ineuw talk 07:11, 2 January 2016 (UTC)

┌───────────────────────┘
It has probably been long enough now to ask: are you still experiencing lockups/freezes due to the script since removing the duplicated routine? AuFCL (talk) 20:12, 3 January 2016 (UTC)

Only once, but I am not sure if it was caused by the script. I am starting to proofread now and see. Otherwise, everything is OK.— Ineuw talk 21:44, 3 January 2016 (UTC)

Typo script #2

@AuFCL: Hi, I took the "bull by the horns" looked at your setup and copied it. So now I am linked directly to your script. So please don't delete it. — Ineuw talk 00:16, 3 January 2016 (UTC)

(Sweetly as I dare) Why, what kind of a fool would I be to give up such an opportunity to subvert your power?

More seriously however security aspects aside what you have done is fine but please don't similarly load directly to my common.js as I (reasonably) frequently and unexpectedly use that for short-term experimentation and/or debugging of other user's set-ups, and the loss of that freedom may be onerous.

I really one day would like to try the experiment of splitting typoscan.js into a code component and a configuration component and make sure the combination still functions but this can wait pending (unlikely) interest in converting any part of the concept into an official gadget, or (even more unlikely) upon some sensible application or support for that whole empty wasteland known as Gadget: name space. AuFCL (talk) 01:50, 3 January 2016 (UTC)

These veiled threats made me redirect the link to my copy. :-) — Ineuw talk 03:33, 3 January 2016 (UTC)

What a clever little Ineuw thou truly art? AuFCL (talk) 03:41, 3 January 2016 (UTC)

@AuFCL: I am not above (or below) swallowing my pride and admit that I was wrong about asking you to block some views. "I was wrong.". Would it be possible to revert and permit script to mark pages in any namespace in any state, "not proofread", main namespace, etc? My error cropped up after saving the page as proofread, a typo which would have been seen before opening the page for editing. "Mea culpa." — Ineuw talk 05:04, 3 January 2016 (UTC)

No problem. As I so cleverly scared you off leaving the exercise in a state I could edit, please see changes in User:AuFCL/common.js/typoscan.js. I have merged a few of the typo test cases and added a couple. The only one you might find objectionable is "Ave" as it catches abbreviated "Avenue". Feel free to delete it if not useful. AuFCL (talk) 06:18, 3 January 2016 (UTC)

There is nothing wrong with adding any text. How many Avenues will I come across anyways? I also intended to put in " — " mdash surrounded by space(s) to be trimmed. I may also have a couple more. — Ineuw talk 07:09, 3 January 2016 (UTC)

Both mdash and ndash cases are now catered for, variously in rules //5 and //6. AuFCL (talk) 07:12, 3 January 2016 (UTC)

Thanks. — Ineuw talk 07:14, 3 January 2016 (UTC)

┌─────────────────────────────────┘
First the easy part: I don't know the answer to the Carl Sagan question you left me, but I can tell you that I read "Contact" a long long time ago. — Ineuw talk 22:49, 3 January 2016 (UTC)

Same here. As I recall there was an epilogue to the story along the lines that many years later the evolved "advertising scanner" mentioned earlier in the plot uncovered a perfect binary representation of a circle buried within the digits of π—which is inevitable when you think about it as it is accepted wisdom that all possible sequences must be found present in the infinite expansion of any irrational number, so e, φ and $\scriptstyle {\sqrt {\text{any prime}}}$ would be equally eligible (although not as plot-worthy?) AuFCL (talk) 00:14, 4 January 2016 (UTC)

After writing the above I found this. AuFCL (talk) 01:16, 4 January 2016 (UTC)

Re typoscan: Came to realize that prior to proofreading, a page can easily have 10+ typos highlighted. When I had it set to 5, it missed a circumflex "^", so I changed the minimum to 15, and may up it higher if necessary. — Ineuw talk 22:49, 3 January 2016 (UTC)

In point of detail the whole concept of typoFuse is a bit of a rushed-solution. The way it is implemented it "cuts-off" the search after marking the given number of distinct matching HTML text-elements (which could actually be a higher number than the "obvious" value) but at the expense of perhaps never marking the later alternatives at all. From a satisfaction perspective it would be better to search for all alternatives but that would defeat the purpose of making the scan quicker… Catch-22 in a nutshell. AuFCL (talk) 00:14, 4 January 2016 (UTC)

At first I thought that some of my questions to come will drive you batty, but then I realized that I can't do more damage. So here is the first. — Ineuw talk 22:49, 3 January 2016 (UTC)

Insanity shared can only lead to evolution in the genre; a "survival of the battiest" if you will. Recall you were the one who pronounced me nuts earlier? I challenge you to a balms race. AuFCL (talk) 00:14, 4 January 2016 (UTC)

What is the status of the document when it is displayed using "Show preview"? Is the display still in edit mode? — Ineuw talk 22:49, 3 January 2016 (UTC)

In the sense of the comments in the code: yes. In point of detail the action= component of the URL changes: on initially commencing an edit session (including creating an entirely new page) it is set to action=edit but upon first Preview or Show Changes (and thereafter until eventually saved or abandoned) it becomes action=submit. Was this the answer you were seeking, or did I misunderstand the question? AuFCL (talk) 00:14, 4 January 2016 (UTC)

Thanks for looking into it. — Ineuw talk 09:21, 4 January 2016 (UTC)

Typo script #3 a new day

Done In my script, changed "lie" to "li" because this definition ignored a number of errors. I will expand the list to be more specific to reduce the number of li's, because every page has about a dozen of correct "li".

Mission Impossible?

@AuFCL: There are missions to be had, and if you choose to accept, there will be great rewards for you in the afterlife.

• Could you explore the possibility of highlighting the possible typos in 'Preview' mode and in the Main namespace only??? And only turn on the script in these two modes?

• These are the two places that are crucial to identify a typo. In Preview, which is at the end of editing but before saving, and then when reading in the main namespace because a chapter, or an article occupies one page and it's easier than paginating in the Page: namespace.

• Is it possible to add an exclusions list?

Finally, am I asking too much? — Ineuw talk 22:42, 6 January 2016 (UTC)

Ironically you are precisely describing my "initial aberration" away from Mpaa's basic conception. The world turns full-circle, and if we are lucky (and observant) we notice the fifth (or fifty-fifth?) time around? Ground-hog day?

Please expand upon your expression "exclusions list" as I do not believe I understand. From my perspective most of the damned script is exclusions; so I am a bit lost looking for a tree in an apparent forest of the b⸻y things. (Oh and lucky I noticed this time. Damned W/S had logged me out again without warning.) AuFCL (talk) 06:08, 7 January 2016 (UTC)

Nice to hear from you, for I was sure you are going to send me to afterlife and search for my reward. There are some much repeated words in PSM that contain "li" and they appear in some topics, paragraph after paragraph, page after page, numerous times. Words like "familiar", "lie" or "lies", which I would like to exclude - if possible. — Ineuw talk 18:04, 7 January 2016 (UTC)

1. I missed seeing your question due to (somehow?) this page dropping off my watchlist.
2. In theory regexp should handle these "exclusions" through the ?!n logic. (However I have yet to find a case which works per—my interpretation of—documentation so you are on your own anyway.)
3. It could be argued you are a victim of your own enthusiasm. If you are scanning for a so-called typo that appears legitimately frequently perhaps that is not a useful string to be scanning for in the first place? AuFCL (talk) 08:34, 8 January 2016 (UTC)

I see your point and you are right, so don't bother with the exclusion list. I had a feeling that I was on shaky ground.— Ineuw talk 08:38, 8 January 2016 (UTC)

┌────────────────┘
Pardon my taking so long to respond. I am a bit in two minds whether this is going to be worth your bother but I have rejigged the script, in effect turning the scan logic inside out. Regrettably this involved (once more) changing the layout of the pattern specifications and I am sorry if this turns out to be confusing. In essence the new version in AuFCL/common.js/typoscan.js now tries out every possible pattern (up to the limit) on each potential text component of the page being examined; rather than the old way which tried to find every possible location matching the first choice before moving on to the later ones.

I have also relaxed the restriction on edit mode so Preview can work once more. Have a look and if the new scheme is not too foreign you are welcome to give it a go.

Oh, before I forget one of the reasons I've not put a lot of effort into this is I am keeping a casual eye on m:Talk:TemplateScript#Using_TemplateScript_for_a_OCR_checker.3F as it is possible TemplateScript might be about to make all of this obsolete anyway. AuFCL (talk) 07:14, 11 January 2016 (UTC)

Contrary to your expectations, for me it's well worth (my) the effort. I understand perfectly well what you're saying about changes and that doesn't confuse me at all. — Ineuw talk 07:40, 11 January 2016 (UTC)

Thank you for being so kind and accommodating. (Now here is the sneaky admission. That last change fundamentally made one-day conversion to a Gadget a lot easier. Ambitious, moi?) AuFCL (talk) 08:06, 11 January 2016 (UTC)

Seeing the typos in preview is great! Saves me from the embarrassment of having to reopen the page for a minor typo. Much thanks. — Ineuw talk 08:09, 11 January 2016 (UTC)

Exclusions Are Possible

I misread the syntax earlier. ?!n is only effective when inside parentheses, so for example /\WAve(?!(\.| Maria))\W/g catches typos of "we" as intended whilst excluding "Ave Maria" or "Ave." (Now if only I could figure out how to additionally exclude colloquial speech's "'Ave" then C. J. Dennis' stuff might be tolerable too!) AuFCL (talk) 20:07, 11 January 2016 (UTC)

Bugs, Could-Be Bugs and Cosmetic Stuff

Since last notifying you I've made some further (pretty minor) updates to our friend. Chiefly adding diff to the list of "don't bother to scan" cases (it only ended up trying to highlight mostly things somebody had already fixed—both confusing and rather pointless?) and a few more typo cases. Which neatly leads to:

…Hoping that two heads ≥ one on these? I have a known issue-and-a-half which you ought to be aware of:

• this one I know how to fix but does not seem worth the effort: the two patterns /\w&/g and /&(?!c\.)\w/g pick up erroneous cases just fine but because "&" is (partially) significant to all of HTML, javascript and regex the highlighting code messes up. However it still draws attention to stuff worth fixing and is nice and quiet (so far) when things are O.K.…
• The Ave check still fails with legitimate Latin phrases like "Ave paternoster" (e.g. Page:Verses.djvu/48) but I think that remains in the "too hard" basket. AuFCL (talk) 02:34, 13 January 2016 (UTC)

I can tell the difference between "Ave Maria" or (Ave)for 'we'. Just leave it as is, because 'Av' as 'W' is quite common in PSM. There are a few others that are common as well, but I forgot to write them down until now.

What really amazes me is that we have proofread ~40,000 pages and more than half of that is also validated, and so few typos were overlooked.— Ineuw talk 03:19, 13 January 2016 (UTC)

I do agree and in case the point gets lost it is in fact a major achievement. My motivation here is to try to isolate the broad categories of typo worth noting (and perhaps even more fundamentally) techniques for sensibly detecting the various types of cases. Did that just get far too meta (aiming to minimise errors in detecting errors in other things)? (Also—and this could get dangerously political fast—I seem to be picking up certain editors work time and again. There is a certain scale of merit: I'd better say no more as experience and seniority are not a reliable guide.) AuFCL (talk) 03:41, 13 January 2016 (UTC)

Special:AbuseFilter/18 still being used?

Hi. Is there still active monitoring of this abuse filter? What is the criteria for who should be exempted from the monitoring list? — billinghurst sDrewth 22:31, 9 January 2016 (UTC)

Hi. Absolutely, I am using it regularly to check what is being done and by whom.— Ineuw talk 00:44, 10 January 2016 (UTC)

Son of a … typo script

Thou false flatterer. I gave your malformed-year idea a try and basically failed. Four-character words (/\W\w{4}\W/) is a relatively easy regex. Mixed digits and letters (/\d\D/) in any order (/\d\D|\D\d)/) and exactly four of those; excluding decimal points and sod knows what else is beyond my skill. Even any string of four digits with one non-period other letter looks like this (/(^|\W)([^.\d]\d{3}|\d[^.\d]\d{2}|\d{2}[^.\d]\d|\d{3}[^.\d])(\W|$)/) which might as well be un-de-buggable. (Speaking of which I tried that last on this page. Want to have a look; or just cry right now and get it over and done with? AuFCL (talk) 06:10, 21 January 2016 (UTC)

I happen to be an honest flatterer! I think that you went into the problem a bit too deeply. This writer would be happy to have a regex search of a string of any length containing a mix of numbers and characters, excluding the space character. — Ineuw talk 07:25, 21 January 2016 (UTC)

I am being a bit of a victim of my own self-imposed strait-jacket. I don't believe it can be done purely as a regular expression but I could look into expanding the javascript to do it as custom code if that is what you were suggesting? It does open up rather a design can-of-worms but who am I to set the rules? I'll get back to you as this might take a while. AuFCL (talk) 11:06, 21 January 2016 (UTC)

@AuFCL: At this point, I am planning to propose to the community that we place the typoscan.js script in a commonly accessible? namespace like Mediawiki:typoscan.js or Wikisource:typoscan.js (whereever it should be) and where everyone can connect to with the connection string, rather than install it individually. — Ineuw talk 05:41, 22 January 2016 (UTC)

That's great news!. Fwiw... If this script can't be made part of an existing 'add-on' features/functions utility somehow (specifically as a module run through Pathoschild's template-script thingy), it has to should be made into a formal, user selectable gadget option rather than loading it the way it has been until now. Beside the fact a major switch to something called Gadget 2.0 is slated to be rolled out a some point this coming year, you can't really claim it ready for "prime time" for everybody unless it gets some testing beyond from I can gather has been limited to you 2 or 3 User:s to date - introducing the possibility of undesired refinements & what-not as a result of 'going gloabal' to boot.

So if that doesn't compel you to stfu and continue to quietly develop & enjoy the benefits of something "specifically working for you" (and x, y & z), I'd be more than happy to work with AuFCL to create a 'legit' gadget for in lieu of any formal announcement for community consumption.

Either way, the consensus is not to make subpages (scripts or otherwise) to existing scripts regardless of namespace anymore; so at the very least, you all should make that move if no other reason than 'not standing out' in the proverbial forest of trees when viewed from the 'outside' -- George Orwell III (talk) 06:28, 22 January 2016 (UTC)

I considered both points but waited for a comment from someone with more knowledge, so thanks for the comments. Placing it where it's accessible to all possible users would help to implement changes, additions or corrections to a single script - a much faster way of doing things. It should be installed as a gadget for now, since all this script does is highlights typos, it doesn't change the text. When version 2.0 comes along, then we can discuss our options.

The idea is to get input from as many users as possible, so a wider community participation is desirable. In any case, I don't consider its use by our more active editors as "prime time". And few users are insufficient for testing. I already collected info on how to deal with typos appearing in the main namespace because of justified text. This also applies to hws|hwe joins, math symbols, etc. . . — Ineuw talk 07:40, 22 January 2016 (UTC)

A melody of relevance from the old country for GOIII.

@George Orwell III: Since you brought up the matter of the eventual appearance of Gadget2.0, it reminded me of an ancient and beautiful Slavic shepherd's song from Eastern Slovakia. It is sung in Hungarian and the refrain is repeating the question "when will that be?" (mikor lesz az már?) Enjoy. — Ineuw talk 02:16, 29 January 2016 (UTC)

Probably somewhere in the next major release (1.28; we're at 1.27wmf11 currently). You should have noticed the Gadget namespace(s) being listed anywhere there is a selectable menu of namespaces by now so the major parts seem to be in place and await the next steps as "time permits" -- George Orwell III (talk) 03:57, 30 January 2016 (UTC)

Brackets - clashing posts in the talk AuFCL ns.

@AuFCL: Our posts have clashed when I was about to add the following.

Taken the liberty to make some minor colour changes in my copy of the code. Changed the outlines to 1px, and the first set of search parameters to 'background:orange;outline:1px solid blue;' and the second set of search parameters to 'background:salmon;outline:1px solid green;' to see how the different group of parameters can be identified. The combination of the thinner outline and coloured background have positive results. I can see clearly the problem, whereas before I was often guessing. I hope you approve. — Ineuw talk 21:23, 29 January 2016 (UTC)

Thank you. This is the point I was probably making badly before. Before this thing becomes eligible for conversion to a (shareable) gadget, of whatever species it needs to be rigidly split (logically) three ways: (1) the program code; (2) "shared" or "standard" patterns, activation rules and highlighting styles and (3) personal customisations—such as you just made above—which make my or anybody else's "approval" a moot issue.

It is all fairly clear in my own mind but I have just been too lazy to push out the final form. AuFCL (talk) 21:52, 29 January 2016 (UTC)

I realize that your current code is catering to my demands :-), and may not meet the needs of others. Through my minor changes I see your and GOIII's point about implementing it for general use. All I can do for others is randomly scan pages and see how it shows up in different texts. More on this later.  — Ineuw talk 21:58, 29 January 2016 (UTC)

O.K. I am an idiot. I just followed up on a message you had never seen due to my incompetence. I am still catching up from last night's extensive power failure here. AuFCL (talk) 22:01, 29 January 2016 (UTC)

The power failure in itself does not make you an idiot. But praying for (more) rain (in your neck of the woods) would do that.  — Ineuw talk 22:34, 29 January 2016 (UTC)

You have permission‥

‥to hate me. AuFCL (talk) 01:52, 30 January 2016 (UTC)

• Aha. So that's how they do it. &amp;. I went offline or awhile because I was getting tired. Thanks.

  P.S:I don't hate.  — Ineuw talk 02:33, 30 January 2016 (UTC)

Collision?

In a similar vein to the above section I came across and mutilated Page:Popular Science Monthly Volume 18.djvu/554 on the strength of bad {{brace}} usage whilst it was nagging me that it looked a bit familiar. Now that I have done the damage was User:Ineuw/Sandbox2 an experiment towards fixing this page or is it all some horrible coincidence? (I think it might be because I really have not encountered {{columns}} before. What a good idea—in general—and what a bad one in combination with {{brace}}. You might notice I bent it too. AuFCL (talk) 06:39, 13 February 2016 (UTC)

It looks OK to me, except I always seek simpler solutions. For me using columns and segmented braces is too much. {{brace2}} is better and neater. What's wrong with User:Ineuw/Sandbox2? That took me awhile to figure it out which was very stupid. I forgot my own maxim - should have done it with two tables. Also there is another biggie I did perhaps two days ago (think), somewhere in volume 14 or 15. — Ineuw talk 07:28, 13 February 2016 (UTC)

(edit conflict resolution) There is absolutely nothing wrong with your solution. Especially since you have just confirmed it was a solution, and not just an accidental repetition of a table used in disparate parts of PSM. I came about this from the complete opposite direction. I was trying to track down stupid uses of {{brace}} which did not use the recommended table helper {{brace table parameters}} (even the bloody Help: page was wrong!) Tp my horror I came across several pages including this one which did not use a table directly, as {{brace table parameters}} expects but instead used {{columns}}. So I bent {{columns}} to accept at least some kind of compromise style and thereafter kind of wedged myself into fixing Page:Popular Science Monthly Volume 18.djvu/554 and there is your back-story lead-in to where this post started. Yes, I would prefer {{brace2}} as well. I shall leave the choice merge/replace/kill in your capable hands, if that is O.K. with you? (I am currently too confused to trust myself not to mess it up even more.) AuFCL (talk) 07:50, 13 February 2016 (UTC)

Found the one I was looking for. At the bottom of the page Page:Popular Science Monthly Volume 15.djvu/104. — Ineuw talk 07:40, 13 February 2016 (UTC)

I warned you I am easily confused. Looking for what exactly? AuFCL (talk) 07:50, 13 February 2016 (UTC)

The table layout with braces. Of which I am very proud because I avoided doing that for the longest time. — Ineuw talk 07:52, 13 February 2016 (UTC)

Styled poem

Here the code I posted into your topic about poem runs:

verse one
verse two
verse three

I added the dotted border just to see better the padding. Position:relative allows this simple trick (here I use html, there's a template to get the same result):

1verse one
Hey!verse two
3verse three

--Alex brollo (talk) 18:32, 17 February 2016 (UTC)

Hi Alex, Nice to hear from you. Thanks for the help about padding the poem tag. — Ineuw talk 19:59, 17 February 2016 (UTC)

Continuing in a less-public forum

This is a tension of multiple conflicting interests. In truth typoscan ought to be made smart enough not to "look" inside of sub-structures like image names like this. But then adding lots more exclusional logic makes it run slowly, and you may remember a time when that was a major concern. I could change the code to isolate this stuff before scanning but that loses context later on resulting in reports of the type "there is a typo of type X somewhere on this page. Getting all Heisenberg there are some choices which are mutually exclusive, notably marking exactly where the typo occurs vs risk of marking inside structures where typo does not matter, or where "marking" it is actually a destructive operation. Transcluding {{hws}} results in pages which cannot have less than two consecutive spaces. The recently introduced <ce> tag actually creates "false" (hidden) single braces and even quadruple-space blocks. I am beginning to realise the fuller implications of GO_III's stfu remark above. AuFCL (talk) 02:05, 18 February 2016 (UTC)

Please don't touch anything. I fixed the typos that created the error on a previous page and the PSM rule is fine. — Ineuw talk 02:08, 18 February 2016 (UTC)

DJVU

@Ineuw, please pardon for my posting here. I need to ask you (because I know you know these things if it can be done) how a person can make a .djvu from several images? Is there a program to do this? Thank you beforehand. Respectfully, —Maury (talk) 07:26, 19 February 2016 (UTC)

@William Maury Morris II: No apologies necessary! In what format are they, the info may help? .jpg? .png? I have several .djvu tools but must check them, and will get back to you soon. — Ineuw talk 22:42, 18 February 2016 (UTC)

@Ineuw:, .jpg, and I've answered your e-mail to me. Thank you for the name of the program you mentioned. I will explore multiple images later. I would have to make a clean .pdf file with what I want first. I tire of seeing garbage stamped books (water-marked) on images. I'll remove the .pdf watermarks. —Maury (talk) 07:26, 19 February 2016 (UTC)

@William Maury Morris II: Just saw your email. Before installing software, I would upload an image or two to a free conversion service of .jpg to .djvu and see how it works, quality etc. I think that the best would be to upload it to Internet Archive to process it. That generates all formats including JP2000. Post a question, to the AI forum, give the details, and will get a notice of reply overnight. It takes them 12 hours to process an uploaded document. — Ineuw talk 08:39, 19 February 2016 (UTC)

PSM and {{fs90}} usage

Hi Ineuw. I have been coming across this issue sufficiently frequently of late I thought I'd better stop "just fixing it" and bring it formally to your attention.

There are lots of occasions for example here where {{fs90}} is being utilised both as the last item on a page here 601 and (effective) first on the following one (I am discounting here the nominally-invisible <section begin=…>). Anyway the issue is that two {{fs90}}s do not really "play nicely" together as shown here:

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.

The result ought to look like:

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.

Up until now I have been replacing the two {{fs90}}s with (on initial page){{fs90/s}}+{{fs90/e}}(in footer) + (on subsequent page){{fs90/s}}(in header)+{{fs90/e}} combinations.

Was this working seamlessly at some point in the past, or do you have any better advice? AuFCL (talk) 05:04, 20 February 2016 (UTC)

@AuFCL: I am also replacing them with {{fs90/s}} & /e. The only place I ignored them if it was used for a single paragraph. Originally {{fs90}} was designed to be used for formatting the author's name below the article title and it couldn't span paragraphs and/or pages, so some kind editor came along and created the /s and the /e versions.

The font size rules for PSM are very simple.

For article titles, the template is {{Pt}}. P = PSM and T = Title. My very first template.

For author names, it's always fs90,

For poems and fine printed paragraphs are always {{fs90/s}}

For image captions the font size is always {{tl|fs85}

You will come across {{fsx}}, with sizes of 85% and87%. which were my frustrated efforts to get a proportional line height and progressively were/and are replaced with fs85.

For tables it's sm85 because most tables in PSM are the same font size and they look similar in proportion to the scan, but I make exceptions on a occasion, when the table fonts are larger or smaller, just to remain close to the original.

You will also come across some paragraph lead-ins which are small-caps and 105% font size because the original seemed larger as well. In this case use your judgment. — Ineuw talk 05:57, 20 February 2016 (UTC)

Thank you for the clarification. I have a nasty feeling I've been replacing a few {{fs90/s}}s surrounding <poem> and will stop doing that. I am fairly confident the only cases where I have made such a change are benign so I hope it doesn't cause too much friction. If I miss changing any back please address as you feel appropriate, and shout at me if necessary. AuFCL (talk) 06:18, 20 February 2016 (UTC)

Here is one. Is that too perverse? AuFCL (talk) 06:26, 20 February 2016 (UTC)

@AuFCL: This is exactly what I am doing whenever I come across the variety of poem formats I come across. Our code is almost 100% the same. The reason I am using this is because with every other scheme the spacing between a poem and the paragraphs surrounding was noticeably uneven. I tested every known (to me) possibility of style that works with the < poem > tag before I figured out how to get the even spacing above and below.

This is your code

<poem style="display:table;font-size:90%;line-height:130%;margin:0 auto 0 auto;padding:0.5em 0 0.5em 0;">
{{fqm}}To me the meanest flower that grows may give
Thoughts that do lie too deep for tears."</poem>

and this is mine

<poem style="display:table; line-height:130%; font-size:90%; margin-left:auto; margin-right:auto; width:auto;">
{{fqm}}To me the meanest flower that grows may give
Thoughts that do lie too deep for tears."</poem>

The last thing remaining with the poem tag that it can't span pages. — Ineuw talk 08:40, 20 February 2016 (UTC)

The two sets of code are close enough I doubt the differences matter. I had most doubts about the padding values (which I had lifted straight out of the current coding of {{fs90}}.) For my money if I were coding a new piece of poetry I would not bother with <poem> at all but put the <br/>s in directly. But that is just unfettered me. I try to "fit in" if somebody else has established a pattern.

Unfortunately <poem> generates, unavoidably, an internal <div> and at least one sub-level <p> below that: the net effect of which butting two of them together is never going to be all that "pretty." Have you ever read the technical documentation? The line Nikola Smolenski made the extension in order to practice working on extensions, after an idea by Yann Forget. gets me every single time I read it. AuFCL (talk) 09:15, 20 February 2016 (UTC)

I have no problem using < div > with < br > or < br / > as long as the font-size is 90% and the line-hight is 130%. Usually, I respond positively to a higher authority. — Ineuw talk 22:49, 20 February 2016 (UTC)

In the long run many respond, not necessarily positively, to higher voltage. Perhaps that was not (quite) the message you were endeavouring to send? AuFCL (talk) 23:24, 20 February 2016 (UTC)

Changing horses mid-stream

I have by no means formalised this change but just a heads-up regarding typoscan. I have cooked up a private version which accepts all of the various patterns in a single rather complicated structure. Perhaps of most interest to you is that gives me the opportunity to make some of the search patterns dependent upon the title of the page being scanned. That is I can have patterns appropriate to PSM which are not eligible to be checked on, say NIOSH pages (taking an extreme example; some of the latter use new mediawiki features that happen to legitimately spray multi-blank sequences and stray braces all over the searchable page. Sort of makes the broken-template checks, well, broken.)

Anyway bearing in mind your earlier comments along the lines of leaving this thing unchanged for a while until you work out your cases of interest I thought I might bounce this off you without committing you to a change. AuFCL (talk) 08:43, 21 February 2016 (UTC)

Think I got you hooked on Regex. Do you smoke it, inhale it, or eat it baked into brownies? I can test it, but am concerned about loosing the color schemes which highlight the different errors. — Ineuw talk 19:07, 21 February 2016 (UTC)

Not at all. I have seen stuff done with bash, cut, grep, sed and even awk (funny how easily shell scripting can be made to sound violent?) which would make your toes curl (that's another one!) And preservation of your psychedelic fantasy colour schemes was integral to the change, Hippy. AuFCL (talk) 22:07, 21 February 2016 (UTC)

Am not, nor was I ever a hippy, just a hippy wannabe, got married early, so missed the goings on around me, and psychedelia is not violent. And yes I am slowly becoming acquainted with bash, and am aware of grep, sed and even awk, but not "cut". Now, I am heading to your new procedure. . . . — Ineuw talk 22:34, 21 February 2016 (UTC)

Re. H. Only teasing. Re: new procedure I have not made it available anywhere you have access to, yet. Could not live without cut. AuFCL (talk) 03:08, 22 February 2016 (UTC)

I tried the new procedure but it's not highlighting space + period, ^ the caret, and one other typo which I don't remember for the moment, (it was only three hours ago, and it seems that my short term memory is affected by something from my non-hippie past.) — Ineuw talk 03:19, 22 February 2016 (UTC)

O.K. Mr. Keen. The real change is now in the usual place. Please retrofit your colors and patterns as you see fit (and of course I hope the new structure is immediately obvious from context. Let me know if there are any doubts.) The keywords are:

exclude

a global test which if when executed returns "true" causes the entire set of scans to be skipped for this page.

limit

a loose bound on the maximum number of matches to highlight per page.

groups

collection of arbitrary number of repetitions of (see below):

include

a local test which if when executed returns "true" permits this sub-group to be acted upon. Overriden by "exclude" above.

patterns

group of regular expressions which if found will be marked using:

styling

CSS style to apply to any matched pattern.

I hope this is useful. AuFCL (talk) 03:56, 22 February 2016 (UTC)

┌─────────────────────────────────┘
Very impressive, very nice. Just need to redefine my color choices. :-) — Ineuw talk 04:38, 22 February 2016 (UTC)

Just a side-note. Because I "rushed" getting the last-round code to you I left a number of comments all containing the word DISABLED: against certain patterns, which I never intended for circulation. In fact these were the patterns I had considered deleting completely before realising they applied to certain pages but not necessarily others. In fact these were the very cases which prompted the last code change, which sort of renders them moot now. And yes, the colour scheme was awful: it is intended to catch your attention, not at all to be pretty. AuFCL (talk) 06:41, 22 February 2016 (UTC)

I will copy the new code, and the colors to be changed were my color choices, changed after pasting your original, but for now I will use your color choices. To finalize my color selections, I copied some colors from W3 to see which colors provide good visibility of the highlighted word HERE. — Ineuw talk 07:04, 22 February 2016 (UTC)

@AuFCL: Can you please look at the bottom of THIS PAGE when you have the chance? Also IMHO, I think that we'll need to regroup some Regex strings differently because of the color groups? — Ineuw talk 10:24, 22 February 2016 (UTC)

Oops! Apologies, I really stuffed that one up. I was trying to catch single brackets but avoid page numbers or reference markers and clearly failed totally. (Also I tried to check for stray <>s in case there were malformed tags on page. This just made things worse so I've taken that out again too.) As for regrouping and colour changes please go ahead: this is exactly what I was trying to make easier to do anyway and I look forward to seeing what you come up with. AuFCL (talk) 11:22, 22 February 2016 (UTC)

Your Oops! is accepted, unfortunately some of the typos are not picked up. spc + . or char.char is one that I noticed, test it when you have the time. I didn't yet change anything. — Ineuw talk 20:24, 22 February 2016 (UTC)

Pardon. I don't quite follow your spc + . or char.char statement.

• "F.G." of "F.G.S." is picked out here.
• various standalone punctuation caught here

I could not quickly find a nice example, but things like "a.m." seem to be picked out. Is that what you meant by "char.char"? What am I missing? AuFCL (talk) 22:43, 22 February 2016 (UTC)

P.S: A better grouping of colors — Ineuw talk 20:54, 22 February 2016 (UTC)

Never noticed "tomato" before. Nice. AuFCL (talk) 22:43, 22 February 2016 (UTC)

Loved the tomato shade as well. I don't look for examples, just create the typos. As for (spc + .char, or char.char) was my error and apologies. It does pick up "word.word" and omits "word .word", I just have to get used to it, since the difference between the two, depends on whether editors use Pathoschild's OCR cleanup tool, or not. At this point it's a confusing issue for me how one should look at the typos, before or after cleaning up the text. — Ineuw talk 23:23, 22 February 2016 (UTC)

Phew! Off the hook then at least for now. I am sure this sort of thing will still crop up from time to time, and we'll take it up again next time it happens. AuFCL (talk) 00:02, 23 February 2016 (UTC)

Font size rules for PSM

I took the liberty to get rid of fsx|90% -> fs90 for Authors, fsx|75% -> fs75 for the line below authors and some of the various fsx|85% around in captions/body. Hope you are OK with that.— Mpaa (talk) 09:42, 21 February 2016 (UTC)

Thanks, I really appreciate it. — Ineuw talk 19:02, 21 February 2016 (UTC)

′OUR country, right or wrong,"

May I have your opinion on this, please? I do not want to open up a straight-vs-curly-quote argument here but do think mixing the styles is wrong. I vote for either:

• {{di|‘O}}UR country, right or wrong,”
• {{di|'O}}UR country, right or wrong,"

Neither of which exactly match the current coding, being {{di|′O}}UR country, right or wrong,". Your thoughts? AuFCL (talk) 00:34, 23 February 2016 (UTC)

As far as I am concerned one can use, straight, curved or slanted quotes (〝〞). I accede this issue to the proofreader/validator, whichever style is preferred or easy to type, but hopefully using the same style throughout an article.

1. The original is rounded or slanted.
2. Firefox's new search feature (Ctrl-F), straight, curved or slanted styles, are searchable with specifying the "'straight quote'" — an interesting refinement from previous browser versions.
3. When an editor replaces straight quotes with the slanted or curved, they are bound to place it properly.

My concern was for floating straight single and double quotes, of which I find many when checking the proofread/validated pages for typos. — Ineuw talk 15:02, 23 February 2016 (UTC)

I am afraid I did not make my complaint entirely clear. The issue which is bothering me is this is an instance where within a single quotation the leading quote is a single, curled quote (incidentally of a variety not matching the scan, but that is a whole 'nother potlatch!) and the trailing quote is of the straight variety. This is inconsistency within the line, let alone within the entire chapter. I have made my favoured alteration to Page:Popular Science Monthly Volume 2.djvu/728 and if you change it back I will take note. AuFCL (talk) 20:27, 23 February 2016 (UTC)

Another day, another typoscan color

@AuFCL: Needed to start a new section, the one above was too long.

Copied & created a new highlight section with lime, a color which I find minimally intrusive. Moved the Regex for square braces [] to it, and to my surprise, it works. Now that I entered this brave new world of modifying javascript, how many sections can be added for different colors? — Ineuw talk 13:58, 23 February 2016 (UTC)

In principle unlimited though in practice I expect the limit will be that of human confusion somewhere before some machine limit is reached. Strictly I believe this vista of the BNW is known as JSON and is useful to be familiar with in mediawiki control structures anyway (e.g. mw:Extension:TemplateData). AuFCL (talk) 20:33, 23 February 2016 (UTC)

Random acts of kindness

When you made this edit, if really you wanted the message to be suppressed whilst execution to proceed as if you had always chosen "OK" then perhaps further changing:

 		//		this.add_trailing_nop(parts);

—to instead read:

 				this.add_trailing_nop(parts);

—might just be the trick you need?

You should also listen to your uncle Mpaa more.

Management never approves of staff discussing the content of their pay-packets under any circumstance, as this might lead to (managerial) embarrassment. 20:50, 23 February 2016 (UTC)

If Ineuw will be let go, it is not because he posted at Wikisource:Administrators'_noticeboard.--Mpaa (talk) 21:39, 23 February 2016 (UTC)

No, of course not! It will be for "personnel reasons", won't it? AuFCL (talk) 21:59, 23 February 2016 (UTC)

Dear uncle Mpaa,

You have no idea how happy I am to be in the family. . . . and much thanks for looking into it. Also, my sincere sympathies regarding the passing of uncle Umberto. A great man and a favorite author. May he rest in peace. — Ineuw talk 22:04, 23 February 2016 (UTC)

A minor addition to typoscan.js

@AuFCL: What happened to my talk page, Spring cleaning? Did you archive my talk page? Just curious. — Ineuw talk 06:57, 26 February 2016 (UTC)

YOU—all 116,539 bytes of erasure—happened to your talk page. Don't ask me what goes on inside of your head as I have no idea. AuFCL (talk) 07:20, 26 February 2016 (UTC)

Also, I added //g, // typo of "ü" to my typoscan.js. It is the OCR's interpretation of "ü" because there are many German towns and academics mentioned in PSM. — Ineuw talk 06:48, 26 February 2016 (UTC)

Cannot use it on account of the roman numerals. Sorry. — Ineuw talk 06:57, 26 February 2016 (UTC)

Shame but spell-checker stuff yet again. AuFCL (talk) 07:20, 26 February 2016 (UTC)

Yes another change which I must make is on this regex /(^|\W)[a-zA-Z]+[.,]+[a-zA-Z]+(\W|$)/g // period surrounded by letters because I have m.m. for millimeter. So, I need one with space preceding. — Ineuw talk 07:45, 26 February 2016 (UTC)

I presume this is PSM usage of "m.m."? Regrettably the modern (there is that damn' word again) stylistic recommended usage for millimetre is in fact "mm"—note not even a single full-stop. AuFCL (talk) 08:27, 26 February 2016 (UTC)

Yes, m.m. is a PSM issue (I know that it should be mm, so I had to change it. — Ineuw talk 08:29, 26 February 2016 (UTC)

Please pity me when it comes to units. I am old enough to remember that a so-called 44-gallon drum holds 50 U.S. gallons or 200 litres and weighs ⅓ ton when full of molasses… and unless it happens to be empty it will kill you if some fool just rolls it off a truck on top of you. AuFCL (talk) 08:36, 26 February 2016 (UTC)

┌─────────────────────────────────┘
I didn't know abut molasses. I wonder if it applies to Quebec maple syrup? Just in case I come across a barrel of it. — Ineuw talk 14:03, 26 February 2016 (UTC)

Deleted posts

Honestly didn't delete my posts. Archiving them about every six month or so meticulously, (if there is such a thing). Who, or what could have done it? Below is the log entry, and the time. If it is my local time (EST) then there is something wrong.

17:05, 23 February 2016 Ineuw (talk | contribs | block) . . (1,038 bytes) (-116,539) . . (Random acts of kindness: Thanks) (undo)

17:05, 23 February 2016 Ineuw (talk | contribs | block) . . (1,038 bytes) (-116,539) . . (Random acts of kindness: Thanks) (undo)

Unfortunately that bit above disagrees. Beyond that I have no theories…worthy of public consumption. AuFCL (talk) 20:22, 26 February 2016 (UTC)

I also find it interesting that no posts were made between the 23 and the 26th of February. — Ineuw talk 14:00, 26 February 2016 (UTC)

Assuming that you are correct, this means that I must be crazy and (no or), Al Zheimer paid me a visit, and in this bout of memory loss I erased everything but left one post untouched. Interesting. :-) — Ineuw talk 21:47, 26 February 2016 (UTC)

One nice thing I have been told about Al Zheimer is that if you think you might have got it then in all probability that proves you have not.

More seriously, the "big delete" happened six minutes after the prior edit—is it conceivable there was an edit conflict and in the confusion all bar the section you, personally, were editing was expunged? I raise this only as a possibility. AuFCL (talk) 22:39, 26 February 2016 (UTC)

No one in my family tree ever had it, and completely forgot about edit conflicts, but a similar event did happen to me here on a small scale. Also, Tuesday night, I have a French class and prior to that I was "extremely" focused on the upcoming, partly because I missed the previous class on account of the weather (so did every other classmate). Didn't know what to prepare, what material was handed out at the previous class (nothing). And partly, returning to classes and structure after 50+ 40+ years is difficult. Under these circumstances I could have done the deed. — Ineuw talk 22:58, 26 February 2016 (UTC)

Some questions about typoscan.js expressions

@AuFCL: This regex expression /(^|\W)Sts?(?!\.)(\W|$)/g,, which searches for "St" is quite complex. I analyzed the elements, and don't want to touch it.

But in PSM, aside from " St " and " St," there are a lot of bona fide " Sto" " Stö" which are also included. Would it be possible to create a Regex expression where only " St " or "St," is found? — Ineuw talk 00:48, 27 February 2016 (UTC)

On the whole get rid of it. It was an experiment based on the presumption that "St" or "Sts" may only be followed by a full-stop (as in abbreviation for Saint, Street or their plurals.) Your experience has more than proven that this is wrong and thus so is the search pattern. AuFCL (talk) 02:26, 27 February 2016 (UTC)

::Replace it with two separate expressions? — Ineuw talk 02:29, 27 February 2016 (UTC)

┌──────┘
In passing I note these two (currently under 'salmon' section):

/\>/g,										// ">"
/</g,										// "<"

They are not necessarily wrong but may not be—indeed probably are not—doing quite what you expect. Not all "<>"s are equal due to their special status as delimiters to HTML tags. In fact I believe they are explicitly prohibited for any other purpose (than tag-related) and the only "visible" forms you will ever see are in fact the entity codings "&lt;" or "&gt;"—which make them doubly difficult to scan for, as then you have to escape the special treatment of "&" as well. Frankly I tried and gave up as my tiny mind was overwhelmed—I truly don't believe they are worth the agonies of getting exactly right. (On another tack due to the fact their meaning is quite different inside of <math> I am beginning to wonder about the value of searching for "{}" as well. On the whole I am becoming somewhat despondent about the basic wisdom of typoscan altogether.) AuFCL (talk) 23:54, 9 March 2016 (UTC)

Please don't despair. The basic wisdom is fine, and your explanations are perfectly clear, and my additions are not important. According to the Regex bible, (not the King James, but a later version), in specifying braces "{}" only the opening "\{" brace needs escaped, and with "<>" only the greater than "\>" needs to be escaped. But, I understand and share your concerns that we are on thin ice here. Let's keep on mulling the possibilities. — Ineuw talk 01:20, 10 March 2016 (UTC)

Yes and no. The point is with "\>" not that the regex needs escaping so much that HTML has already done a bait-and-switch upon you before you started... Also with regards "\{" that escape is only needed when there is ambiguity regarding the match-count specifiers (i.e. "{2,}"-syntax.) Before this edit removed it, the last active check was of the form /[{[\]}]{1,}/g. If you carefully follow the nesting you may notice the search (as opposed to count-specifying ) "{}"s are entirely within "[]" which renders the need for extra "\"s moot. There is a lot going on there so you may need to look quite carefully. AuFCL (talk) 01:44, 10 March 2016 (UTC)

I did make the script go haywire, but wasn't sure if it was the "<" or ">" that did it. As for the "\{", it's no longer in the script. — Ineuw talk 03:51, 10 March 2016 (UTC)

I hope this does not make your script go haywire, or unduly bend your brain but here is a compromise (sounds ever so much better than "wimpy"?) fragment you might like to try. To prevent groups running on pages which contain math (or {{brace2}} which internally uses math) try something like this:

    {
      include:
        /Popular.Science.Monthly/.test( location.href ) && // this group applies only to PSM pages
        document.evaluate(
          "//span[contains(@class,'mwe-math-mathml-inline') or contains(@class,'mwe-math-mathml-ally')]",
          document,
          null,
          XPathResult.UNORDERED_NODE_SNAPSHOT_TYPE,
          null
        ).snapshotLength===0,                              // ...which contain no <math>
      patterns: [
        /[{[\]}^]{1,}/g                                    // mis-terminated template, link or standalone "^"?
      ],
      styling:
        'background:orange;outline:1px solid blue;'
    },

This relies on the fact that math (currently) generates either CSS class=mwe-math-mathml-inline, or class=mwe-math-mathml-ally (or usually both.) The document.evaluate(…).snapshotLength (crudely) counts how many times either class is used and of course fails (thus forcing the group to be skipped) if the result is non-zero. Oh and the "&&" ties this check back to the earlier check for PSM in the page title in this example. Any use? AuFCL (talk) 07:49, 10 March 2016 (UTC)

Thanks. I added it to the script.

fsx with strange factors usage in PSM

@AuFCL: It is about time I distracted you in a new direction. Of late I keep coming across usage like {{fsx|105%}}, or {{fsx|85%}} (why—when there is also {{fs85}}?) or even {{fsx|83%}} (which just seems like a complicated version of {{smaller}} to me!) Is this kind of usage (as far as you know) for legitimate reasons, or just somebody getting overly enthusiastic about fine control?

I am inclined to translate them to the closest appropriate {{smaller}}, {{larger}} or none at all match but if this gives you conniptions I would like to know at least some reasons if I may? AuFCL (talk) 07:15, 3 March 2016 (UTC)

Before I knew anything (absolutely nothing), I was entertaining myself with the hope that varying the font size will give me the desired change in the line-height. When I realized that this won't happen and it was an exercise in futility, it didn't matter what I used. Now I am removing and changing all fsx to fs as follows:

• {{fsx|83%}} or {{fsx|85%}} = {{fs85}}. I never use {{smaller}} because it doesn't scale the line height.
• {{fsx|87%}} or {{fsx|90%}} or {{fsx|95%}} are all {{fs90}}
• {{fsx|105%}} = {{fs|105%}} was used to make the small caps a bit larger because it looked larger in the original. You can remove it and leave it to be standard font. I never use {{larger}}.

Now good night and sweet dreams to myself. — Ineuw talk 08:50, 3 March 2016 (UTC)

In fact I was glossing over a couple of details for the sake of making this a simple lead-in. In fact I was going to suggest {{fsx|83%}} be replaced by {{smaller block}} which does set the line-height but not precisely to the same ratio as does {{fs85}}. And surely 2% (83–85) variation is imperceptible? And going in the other direction a remarkable number of {{fsx|120%}}'s turn up—guess what {{larger block}} does? No, I am not insisting on the substitutions but perhaps there has been a bit of parallel evolution between some of these templates resulting in their differences reducing somewhat over time? AuFCL (talk) 09:28, 3 March 2016 (UTC)

I dislike named templates like "smaller, block" because they don't indicate very features I rely on, namely font-size from which I can deduce the line height. I do change them when I find them. My idea is to reduce the number of templates and standardize them. The sizes were set from the 100% and smaller font size and style comparisons table these sizes supersede any other size defined by me earlier.

• font-size >= 97% standard line height
• font-size >= 90% line-height = 125%
• font-size >= 83% line-height = 115%
• font-size >= 75% line-height = 105%
• font-size >= 68% line-height = 95%
• font-size >= 60% line-height = 95%
• font-size <= 59% line-height = 85%

— Ineuw talk 21:19, 3 March 2016 (UTC)

In response to your last note I submit this link with no further commentary. AuFCL (talk) 21:27, 3 March 2016 (UTC)

While you're setting the standard, I could not resist to remove the fsx|105% and the fs|105. Holding it for a while, just in case you have objections. See MpaaBot contribs to check what I did.— Mpaa (talk) 21:34, 3 March 2016 (UTC)

Hi @Mpaa:, For font sizes over 97% I don't care what is used. I don't know if you are familiar with this User:Ineuw/Sandbox1 page, which is based on this User:Ineuw/T1 attempt, which was designed to overcome the shortcomings of {{fsx}}. :-) — Ineuw talk 22:09, 3 March 2016 (UTC)

OK, I will kill 105% for uniformity over the volumes. And will refer to tht page for smaller font in case.— Mpaa (talk) 22:13, 3 March 2016 (UTC)—

┌─────────────────────────────────┘
Please do so. Standard font size for small caps is fine. My past problems with small caps and 105% were corrected with a new pair of glasses. :-) — Ineuw talk 22:16, 3 March 2016 (UTC)

I am glad Mpaa raised this explicitly because I confess to removing a few fsx's in the 98–105% range to see if anyone noticed and complained. Which they did/have not so far. It is nice if we are all singing from (similar) hymn books. Oh, that analogy does not really work here. AuFCL (talk) 02:47, 4 March 2016 (UTC)

Please pardon my perversity folks for even thinking to search for this but the results are too good not to share before addressing them. {{fsx|100%}} is not {{blackletter}}—I wonder how anybody ever came to that conclusion? [1] AuFCL (talk) 18:18, 4 March 2016 (UTC)

How right you are. But it's no use to blame the validator, as it was one of the designer's/proofreader's many faults, but thanks for pointing it out. I am also convinced that you'll find a few more of such anomalies. — Ineuw talk 19:10, 4 March 2016 (UTC)

Well that wasn't quite the response I expected. Do you have a PSM policy against use of Fraktur? AuFCL (talk) 19:26, 4 March 2016 (UTC)

Not at all, only my efforts with blackletter was not successful. I really appreciate your and Mpaa's help, and feel free to change both the style and size of the title fonts as you feel is right. — Ineuw talk 19:32, 4 March 2016 (UTC)

comment about the typoscan.js

@AuFCL: The script works fine as it is now and highlights all typos. So, I don't understand your previous comment that it was not intended to highlight every and all typos. — Ineuw talk 23:24, 12 March 2016 (UTC)

Well sometimes it does (and here is the point!) sometimes it does not. It always strives to find at least one instance of each category of pattern, but as soon as it finds one there is the problem of marking the damned thing and this is where it all goes runny: as soon as a span (to contain the highlighting) is inserted the so-called DOM tree is altered, and that in turn technically invalidates subsequent searches without restarting the process all over. And that would both slow the process down and open up yet another can of worms (well said can is already open at this stage but this would make it an order of magnitude worse!)—what if the pattern happens to match part of the highlighting just inserted? Can you see how truly dangerous scanning for "<" might be if it actually worked as expected? A large hint: just what character does <span> start with?

So your comment to the effect it "works fine as it is now and highlights all typos" is nice and kind and only proves the old rule "you can fool some of the people all of the time; and all of the people…all of the time."

And just to embarrass me properly Remember the Dot's script has just decided to work for maybe the first time in my experience during this edit session, which you may dimly recall I mentioned long ago as a better technical solution if only I could get my mind around how it worked. Maybe some more study is in order? AuFCL (talk) 00:02, 13 March 2016 (UTC)

FYI, Just to mention, floating single and double quotes (surrounded by spaces) are all and always highlighted regardless of how many there are. There may be other symbols that do this. but there aren't enough of them to know. Then, there is the caret "^" which may or not show when it's followed by a space. Go figure, but don't worry or do anything about it. — Ineuw talk 00:23, 13 March 2016 (UTC)

Problematic anchor link

@AuFCL: Firefox browser facilitates cursor movement on the web page. This means that the cursor always lands exactly at the anchor link except with this link. Do you see anything anything wrong? — Ineuw talk 08:00, 13 March 2016 (UTC)

Explanation

• Some publications listed in the index are placed in paragraphs and their titles are styled in italics.
• Most paragraphs refer only to a single publication, and the paragraph's index anchor link is placed at the start of a paragraph.
• Exceptions are when there are multiple books mentioned in a single paragraph. Then, for each additional publication an anchor link is placed before the publication name.

Examples

• The anchor link #D871-5 refers to an anchor on djvu page number 871, and the 5 refers to the fifth paragraph of that page. Partial paragraphs at the top of the page belong to the previous page.
• D871-5 = The first anchor is always placed at the beginning of a paragraph, regardless of the additional titles listed in the paragraph.
• D871-5.1 = 2nd publication name in the same paragraph, always placed at the start of the italicized title.
• D871-5.2 = 3rd publication name in the same paragraph, always placed at the start of the italicized title.
• etc., etc.,

The link looks good and works here for me under FireFox, although quoting Popular_Science_Monthly/Volume_45/October_1894/Literary_Notices#D871-5.1 might be rather more usual. After a false try I modified the {{anchor}} to {{anchor+}} as the highlighting makes the link selection more obvious. Please try again and when you've finished experimenting please back out the two changes to Page:Popular_Science_Monthly_Volume_45.djvu/871. One thought: were you expecting the Page: link to scroll the anchor-point right up to the top of the screen? For some time now firefox has not bothered to do that if the anchor is already somewhere on-screen which can make it difficult to distinguish when the anchor is in the final paragraphs of a page. That is all I can suggest at present. AuFCL (talk) 09:34, 13 March 2016 (UTC)

I was referring strictly to the Page: namespace. In the main namespace, the paragraph always rolls up to the top edge of the screen (in both FF and Chrome), and I don't care about the main namespace. I am also aware of the issue of the bottom paragraphs in the Page namespace. Even though the window is unable to scroll to the lower paragraphs for obvious reasons, the cursor does, and that's why I set the browser to display the cursor position. Also, this is only for my verification purposes. Thanks for taking time out and helping. — Ineuw talk 20:33, 13 March 2016 (UTC)

Pardon my earlier incomprehension. I am in the habit of turning the accessibility features off (which of course obscures this whole area of interest.) However when enabling the in-page cursor the original link works correctly...I wonder if in all the fooling around editing the page between us we have caused some caching issue to finally "catch up?" (In other words has the error "gone away" from your perspective or is it still happening? Purely academic from my point of view as it apparently never misbehaved for me.) AuFCL (talk) 21:52, 13 March 2016 (UTC)

It is still not OK for me but start from the page where I start: —Geology of the North Shore of Long Island849 index entry near the bottom of the page and let me know where it lands. I am also considering the issues of the cache (of Firefox which I do regularly), and the whole Index: page, which I tried on more than one occasion but it's not working for me. Some pages which were proofread, still show up as red. — Ineuw talk 22:02, 13 March 2016 (UTC)

Now that is interesting: it took several "goes" before I could figure this out but perhaps a slow(er) internet connection can have its uses. Following Popular_Science_Monthly/Volume_45/October_1894/Literary_Notices#D871-5.1, the "cursor" initially paints as being just between the initial mdash and "S" of: paper—Some Further Notes on the Geology of the North Shore of Long—but as soon as the bracketed blue page numbers update the cursor disappears again never to reappear. (In fact subsequent sleuthing reveals it is at that point off-screen and is in fact lurking just after the closing bracket of the last blue page number drawn.) In this case:[852]projectors, G. N. Chase and H. W. Kirchner. The system includes an—which pretty much reveals this is a case of MediaWiki:PageNumbers.js not preserving the cursor position when it does its thing. Want me to investigate more closely, or is it enough we now have an answer? AuFCL (talk) 03:06, 14 March 2016 (UTC)

Please don't waste anymore time on this nonsense. Just float away from it while cursing me under your breath. — Ineuw talk 06:06, 14 March 2016 (UTC)

Hang on, at an estimated great circle separation of around 15k6m why should you care how loudly I am cursing you? Surely you ought to be more concerned with the effectiveness of said cursing—assuming of course you were being cursed in the first place? In the 21st century there are more modern and efficient alternatives available. AuFCL (talk) 07:01, 14 March 2016 (UTC)

Typo needs explanation

@AuFCL: Towards the end of this page, one paragraph is highlighted (salmon) by typoscan.js

This should be the start of the paragraph Work for Amateur Astronomers.—Professor Edward C. Pickering,

And this is what I am seeing for the whole paragraph >>>>>>Work for Amateur Astronomers.>>—Professor Edward C. Pickering,

Can you explain why? Thanks. — Ineuw talk 00:22, 19 March 2016 (UTC)

Partially. On Page:Popular Science Monthly Volume 22.djvu/883 there was a genuine typo. ">" which I think is in reality a broken-typeface ";" (I have validated the page based upon this assumption; and the issue has "gone away.")

As to why it coloured the entire paragraph I can only surmise there was an unfortunate ripple-back effect—i.e. the act of adding a <span> to mark the erroneous < added another < which then was marked and the process repeated all the way back to the start of the paragraph. Which as it occurred on the prior page meant only the transclusion result was affected but not the individual pages. I repeat this is a bit of a guess.

As I have mentioned previously I am not particularly happy with the implications of using:

        /\>/g,										// ">"
        /</g,										// "<"

and consider them not really worthwhile. As you have just seen here even when they trigger the result does not really indicate what or where the true cause lies. AuFCL (talk) 02:05, 19 March 2016 (UTC)

We, (I mean the Royal We) will remove them. — Ineuw talk 14:01, 19 March 2016 (UTC)

NopInserter

Pending the outcome of your other enquiries might I suggest a compromise? Instead of your last variant:

				$('#ca-proofreadPagePrevLink').css({'outline':'3px solid green'});
				setTimeout(function() {
					$('#ca-proofreadPagePrevLink').css({'outline':''});

might I suggest substituting instead:

				$('#ca-proofreadPagePrevLink').children().css({'background-color':'palegreen'});
				setTimeout(function() {
					$('#ca-proofreadPagePrevLink').children().css({'background-color':''});

This approach works under both Vector and Monobook and does not suffer from the "chopped off outline" effect which plaques the original approach. I changed to palegreen as I consider it a more fluorescent tone but of course add paprika according to taste. (What a pity paprika is not a standard colour?) AuFCL (talk) 06:59, 22 March 2016 (UTC)

Before going to sleep, my sixth (or seventh) sense told me that I should look at my watchlist. Any more explanation would be superfluous. Thanks for the code snippet. It works beautifully. — Ineuw talk 07:20, 22 March 2016 (UTC)

I have been putting in an occasional thought as to modifying the "official" version of MediaWiki:Gadget-NopInserter.js and realised that it already has one means of user-modifiable "control" over the function of the monolithic gadget code, viz. use of mw.user.options.set({'nopinserter_auto_advance':true}); to control whether using the gadget should result in "jumping" back to the previous page; or to remain on the page from which the tool was launched.

A little experimentation revealed this code too has a small bug, which I believe I have corrected. However this is a bit of a side issue. I have added a couple of new "controls" and the result can now be directed to behave like the old gadget (with confirmations); like your variant, and (an independent control) to vary the colour of the "success flash". The changes (between the original gadget and my proposed modification) are: here, and surprised me how relatively little change was called for. (And yes, that was probably an illegitimate use of the change utility. So sue me.)

Now I am not suggesting this is a necessary immediate change or even if you should try it yourself—though you are welcome if you so feel inclined. However if you or somebody else ever contemplates overhauling the central gadget I would like to be on record expressing a wish that these be incorporated the queue of suggestions for change. AuFCL (talk) 12:04, 23 March 2016 (UTC)

Will try it perhaps by tomorrow. Still struggling to rebuild Windows and install apps. — Ineuw talk 04:38, 24 March 2016 (UTC)

Clearing the cache of an index page problem.

@AuFCL: Before Mpaa throws us both out of his talk page, I moved the conversation here. The 'Not proofread' of the listed pages occurred when they were proofread March 9 and 10 (more than two weeks), and remained so until I posted on Mpaa's page. — Ineuw talk 04:00, 26 March 2016 (UTC)

Ah. Apologies. I had assumed the other order. Theory just ran aground. AuFCL (talk) 05:06, 26 March 2016 (UTC)

@AuFCL: The issue of thumbnails displayed in edit mode, was around for months. Long before I disabled the frame around the main namespace pages of PSM. — Ineuw talk 04:13, 3 April 2016 (UTC)

No problem friend. We are all able to go astray on the road of presumptions. I was glad to be able provide you with a map. :-) — Ineuw talk 00:23, 27 March 2016 (UTC)

There is something weird in en.wikisource and at this point I think also more specifically to PSM. Very often I see no color indication in PSM Index pages and I need to make a null edit to get them (Vol 45 is an example, yesterday I checked when you left me a message and was OK, today I got a B&W page ...). PSM is also used as a sample page in pywikibot test suite and the need of purging pops up very frequently. I have not observed a similar rate with other pages. Problem is I am clueless about it. See for example https://phabricator.wikimedia.org/T128994. Ideas welcome ...— Mpaa (talk) 08:06, 26 March 2016 (UTC)

@Mpaa: I've known about this "problem" for a long time, and restore the colors instantly with the clock/purge gadget, so it didn't bother me. I always assumed this because of the number of pages in a volume (~900). But, in the past months, did notice that the color is lost in a matter of a few hours, as opposed to several days/weeks of inactivity on the project's pages. I vaguely remember a Scriptorium discussion about this in which User:billinghurst was involved. But it was a number of years ago, perhaps the archives can be searched if this was important. — Ineuw talk 00:23, 27 March 2016 (UTC)

/me does his very best vague and confused look. Not seen it, nor remember it being discussed. I know not even the data component to where the Index: pages get their data, let alone how it even goes wrong, or why it fails. — billinghurst sDrewth 08:20, 3 April 2016 (UTC)

I now realise your issue was so completely unrelated to the matter for which I thought I was offering suggestions that your rejection now makes total sense. Nevertheless, when you happen to collect the screen capture you promised Billinghurst, would you mind also please accessing this link (reasonably soon) afterwards and noting the results as well? I am primarily interested in the figure which will appear there against title "jobs" as I still expect this issue to be potentially process queue related. AuFCL (talk) 06:54, 3 April 2016 (UTC)

This RESULT was the subject that Billinghurst was responding to someone complaining in a Scriptorium post, eons ago. It is also what is Mpaa mentioned above. This happens to me all the time, but is not a problem. The Clock gadget purges the page and restores it instantly. My problem in the Page: namespace may or may not be related to this. — Ineuw talk 06:07, 4 April 2016 (UTC)

I've seen that color-status loss "happen" to various Index: pages, large and small, with no clear indication as to why as well. A simple purge also takes care of the problem here too (the simple purge for this talk page is https://en.wikisource.org/w/index.php?title=User_talk:Ineuw&action=purge for example. note the use of index.php). Purging forces MediaWiki to clear the cached version of a given page, forcing the page to be redisplayed from its source.

All "we" really suspect about that phenomenon is that its an out-of-synch-status caching/retention issue of some sort occurring at certain times just for some folks. Its been hard to work the issue as the natural tendency has been to purge the page upon encountering such color-status losses - giving others visiting the Index: afterwards "nothing to work with" essentially.

I believe resolving a color-status mismatch between a single Page: and it's Index: page pagelist indicator is a somewhat different matter that is not always resolved with a simple purge. Using a complex purge and/or a null-edit usually will resolve these type of mismatches in my experience (these use api.php btw and cannot be done thru the clock gadget purge. The other purge gadget gives you all "three" option fwiw). A complex purge using the API does involve the Job Queue which @AuFCL: mentioned earlier (it varied from 0 to 102 over the course of an hour being check every 10 min or so - hth).

My state of confusion is which namespace technically counts as the "source" needing to be refreshed for a specific type of issue. See some background on that point beginning with this discussion. -- George Orwell III (talk) 20:55, 6 April 2016 (UTC)

@George Orwell III: I have no idea of the mechanics of this situation but here is an observation which might trigger a connection: when logged out, performing a purge on Index:Popular Science Monthly Volume 28.djvu recreates the missing colour-states (as expected). Now the surprise is if one then "hard purges" the same page the no-colour-status version reappears immediately and does not return after waiting for the job queue to quiesce. This appears to be repeatable at will but only while logged out. (I suspected interference from Mediawiki:Gadget-mark-proofread.js but disabling this does not appear to influence the situation.) Any thoughts? AuFCL (talk) 23:42, 6 April 2016 (UTC)

I got sort of fed-up with waiting for GOIII to cease being busy elsewhere and re-reported the last into Phabricator. Feeding the fishes, or applied vandalism? AuFCL (talk) 07:25, 21 April 2016 (UTC)

Math tags in the new mobile world.

@AuFCL:, Greetings. You mentioned something to me about the use of <math> being obsoleted? (phased out?) due to required changes for mobile. Does this apply to all math tags I used to depict and enhance the math symbols like $+$, $-$, $=$, $\times$ and $\div$? — Ineuw talk 18:03, 17 April 2016 (UTC)

No that isn't right (either that or I have given you the entirely wrong impression.) Please try to calm down and read this. Which supercedes this. Then for background (and pretty much will confuse you all over again) this, but make particular note of the comment near the end "If we introduce new features, we do not want to make them backwards compatible with the old png rendering mode."

Now taking all of the above together with the further side-issue of this (being the matter I raised as possibly affecting you) the situation appears to me that <math> is here to stay however in a somewhat mutated form to that we currently know and love/hate. In particular the current logged-out default mode of operation in WikiSource (PNG) is slated to be (possibly) be eliminated. The semantics of certain constructs has already changed and things like <math>\mbox{δ}</math> which used to be illegal (and still are under PNG mode—I know: why bother?) are now acceptable. Perversely <math>\text{@}</math> which used to be legal now no longer works under any circumstance.

Oh, and PNG mode was compatible with usage as a pseudo-image under FI/FIS but the new replacement MathML mode is not. And MathJax mode appears to have already been eliminated.

So the news is bad (math is being ripped apart and reassembled under our feet and this process has been going on for some time) yet not as bad as perhaps you seem to have taken it. If you can take all this as reassurance I am happy to so offer it. Just not sure I believe it myself. AuFCL (talk) 22:34, 17 April 2016 (UTC)

Thanks for another eminently clear reply. Now, I just have to study (and understand) the details in the links, which will take me awhile. — Ineuw talk 00:17, 18 April 2016 (UTC)

Aha. I have found a new way of keeping the I-man distracted for long periods of time. May I suggest you have a read of phab:tag/Math and all that links thencefrom? And I'll speak to you again in Spring, umm 2040? AuFCL (talk) 04:12, 18 April 2016 (UTC)

How well you know me, but sure that I will be speaking to you earlier than 2040. As for spring, it finally arrived to Montreal today. — Ineuw talk 05:24, 18 April 2016 (UTC)

My 2 cents on the subject. Why bother for $+$, $-$, $=$, $\times$ and $\div$ ...!? There are nice plain symbols for that +, -, ✕, ÷ ...— Mpaa (talk) 18:26, 18 April 2016 (UTC)

Hi Mpaa. The typoscan script from AuFCL, highlights every free standing math symbol as a typo. I could have used &nbsp(;) to surround them, but if one looks closer at the originals, the math operators are identical to the ones I enclosed with the math tags, except the "✕". This ✕ is new to me, never having seen it before, otherwise I would have used it. Call me crazy. — Ineuw talk 19:26, 18 April 2016 (UTC)

O.K. "You are crazy." (I know the offer was made to Mpaa but you did not say I could not borrow the right for just long enough?) More symbolically there are equivalents: &minus; &times; &divide; should you so prefer (no plus or equals because they are already there on your keyboard…which makes minus a bit of a teaser.)

They might be similar in the original but in the transcript they are rendered a bit oversized, I would say ... The fact that typoscan detects them is a bit weak to justify all the markup IMHO.— Mpaa (talk) 17:23, 19 April 2016 (UTC)

I agree 100%. Also, didn't realize that I had so many of them. I work with Firefox, and suspect that you are working in Chrome because I checked how it renders in Chrome and it's definitely large. So, when coming across math operators again, I will weigh the different options because we haven't exhausted them all. As for typoscan, I don't change everything it detects. I was adding the math tags elsewhere before I installed typoscan. I would not change that script, but there are ways to indicate to the user that the change is optional. — Ineuw talk 18:13, 19 April 2016 (UTC)

@Mpaa: I heartily agree. My intent with the typo script was that each individual user customise the warning patterns to suit their own preferences. There is no "requirement" that standalone punctuation be forbidden, merely a suggestion that it might not always be legitimate.

And consider the oversized font in certain browsers/rendering modes an early heads-up as to the horror which is about to burst upon us. Math size rendering (and that includes such subtleties as {{brace2}}—used all over) is going to go completely yo-yo should PNG usage finally be retired. (And don't forget our own dear Billinghurst requested this which would have had equivalent impact—don't be fooled by the closed status: this request has simply been merged into phab:T131177 and is still pending activation.)

To spell it all out: when these changes come to pass, braces will render only about ⅔ size; all math expressions specified as \scriptstyle (and I have written lots of them!) will be unacceptably small; there is a risk that all Ubuntu/Firefox users will have line-height math problems (lines containing math will render about 2½ times too far apart) due to font incompatibilities (I am not sure if webfonts will save this one but I am not confident.)

We are already in a world of varying math rendition according to browser; local font installation; operating system; Preference options chosen, and finally whether logged-in or logged-out. I am uncertain as to whether the current state represents "Peak divergence" and things will calm down again; or whether things are simply going to get even worse. Please pardon the doom and gloom but I truly do not believe wikisources interests will be well served in the near term, and I truly hope that I am wrong. AuFCL (talk) 21:46, 19 April 2016 (UTC)

┌─────────────────────────────────┘
@Mpaa: I often use BabelMap (unfortunately it's only for Windows), and looked through it earlier today for math operators and there are several repeats with different Unicode numbers. If you haven't used it yet, I recommended it. — Ineuw talk 06:06, 20 April 2016 (UTC)

John Tyndall image in PSM 2

I am probably obsessing unnecessarily here but it bothers me that the supposed image of Professor Tyndall lies so many pages from the article, which starts properly on page 103, especially when the signature under the image bears only passing resemblance to supposedly valid signatures of the same man reproduced elsewhere on the internet. On second thoughts forget it—there appears to be something of a market for his autograph and I have already seen three quite distinct variations—and I make no claims at being a handwriting expert. No way would I pay out for this stuff. AuFCL (talk) 08:29, 21 April 2016 (UTC)

Yes, you are obsessing. About what, I am not sure. It makes logical sense to place the image of the person above their bio. This is so with every biography article in PSM. It's a minor liberty I took (along with several others), in the main namespace transclusions. Why the picture was placed some 100 pages before the bio, only the original editors can answer. Unfortunately, they refused to reply to my emails, postcards, phone calls and the Ouija board, as I have tried to contact them several times about various inconsistencies in the publication. As for Tyndall's signature, there is evidence that he was aware of the monetary value of his signature in the 21st century, (it was free in the 20th), so to keep the intrigue and the bank tellers off balance, he signed his name in various ways. On the other hand, and for what it's worth, you can have my signature. — Ineuw talk 17:29, 21 April 2016 (UTC)

I'd rather have your P.I.N. Don't worry about the card number—I do Luhn like Sudoku. AuFCL (talk) 21:58, 21 April 2016 (UTC)

My signature is worth more than my PIN number (but not by much).:-) — Ineuw talk 22:08, 21 April 2016 (UTC)

A small heads-up

Oh ye who hast:

/* Fix dimensions in Page namespace 1st = original, 2nd = modified but line-height becomes 25.6px or 1.6em*/
.pagetext { width: 500px; margin: 0 auto; color: black;}

in your Ineuw/common.css, look well what is looming upon the horizon: phab:T133294. I think you can doubtless figure out the consequences? AuFCL (talk) 00:47, 22 April 2016 (UTC)

Oh crap, ("dreck" in German), why are they doing this? Why can't they leave things alone? Will I be able substitute it with something else? — Ineuw talk

Who knows? I am sure something can be "figured out" at the moment of crisis, but sometimes we are left in the hands of "code warriors" who never seem to actually use the products they evangelise over. I have been biting my tongue over this because I simply cannot think of a response which will not come across as flammenwerfer-ish. Bear in mind Quim is "Engineering community manager at the Wikimedia Foundation." AuFCL (talk) 02:07, 22 April 2016 (UTC)

Worth a shot?

Popular Science Monthly/Volume 47/August 1895/To Barbara—your right of refusal. Tweak or reject as you see fit. AuFCL (talk) 11:10, 9 May 2016 (UTC)

Reject??? It's perfect. Very classy and more for me to know! Thanks, and may you be blessed, just choose the blessing and let me know. — Ineuw talk 22:01, 9 May 2016 (UTC)

Just in case this is not already obvious, the factor of 138px represents half of the width of the widest <poem> block you wish to keep aligned (i.e. 276px scaled by 50%.) In hindsight this might even be simpler expressed as a {{left margin}} and the right margin simply left to run ragged. AuFCL (talk) 23:04, 9 May 2016 (UTC)

The formula is clear. — Ineuw talk 02:09, 10 May 2016 (UTC)

A(nother) small heads-up

Dear I.

Despite not being mentioned recently, it appears (to me) that Enable MathML by default has "gone live" in any case already here on wikisource. As I was foolish enough (in 20/20 hindsight) to have taken much earlier advice and installed the firefox MathML extensions, my browser might no longer be a fair test for this particular issue. Would you be so kind as to take a quick look at Page:Popular Science Monthly Volume 18.djvu/543 and ensure the chemical formula don't look too silly? Irrespective of mode (PNG/MathML) I choose in my preferences I am getting MathML presentation (i.e. <math><semantics>… tags—with an extra unwanted trailing space in PNG mode, possibly due somehow to the extra <meta> tag theoreon?

Anyway, would you please have a look and let me know if this is worth stirring up further trouble over? Thanks, AuFCL (talk) 09:16, 18 May 2016 (UTC)

It looks great, thank you, and just keep on as you wish. — Ineuw talk 17:37, 18 May 2016 (UTC)

In which case I shall let sleeping dogs alone. There are numerous Phabricator tasks still active or stalled to address the spacing issue (the most detailed I can find is: Extra space after equations in MathML mode.) or, through a completely different path, Remove PNG only rendering mode. Satisfactory resolution of any of these might—I would hope—eliminate the remaining quirks. AuFCL (talk) 21:57, 18 May 2016 (UTC)

Interesting link. In any case, I will use these tags from now on. — Ineuw talk 22:21, 18 May 2016 (UTC)

CSS attributes: font-spacing?

Hello. I just happened to note this edit. Are you sure you didn't really mean letter-spacing:.2em? As far as I know there is no such attribute as font-spacing, or if there is it certainly is not universally recognised by all browsers. AuFCL (talk) 06:20, 23 May 2016 (UTC)

How did you know that I was using a Hungarian browser? There may not have been until now, but Hungarian CSS attribute rules permit its use. On the other hand the attribute's existence makes no difference visually. — Ineuw talk 03:15, 24 May 2016 (UTC)

Wow. You are right! I simply never realised. AuFCL (talk) 03:23, 24 May 2016 (UTC)

<ce>

I was amused to note this correction. Please do not bother changing it but as <ce> is intended to be used for representing chemical equations—in point of fact I've searched the documentation and can find no formal confirmation of this assumption so this whole thing might be just a house of cards—you must realise that technically you have called for the representation of a double-bond, not a physical equality? AuFCL (talk) 07:05, 7 June 2016 (UTC)

{{pps2}} doesn't (always) cut the mustard?

Hello Mr. I.

This begs an obvious question. I have not (yet) come across many pages where this title is italicised as it is here. If it turns out there are more than this one what are your thoughts on, either a new template or adding a suitable "exceptional style" parameter? AuFCL (talk) 01:50, 19 June 2016 (UTC)

Mr. Hawkeye, It seems to be the only one. Just checked the other titles of {{pps2}}. The difference between {{pps}} and {{pps2}} is the period at the end of the first one, and perhaps the font size and style. (with which is very easy to deal with.) Just leave that one italicized to be faithful to the original. — Ineuw talk 04:28, 19 June 2016 (UTC)

Hawkeye I doubt. Nonetheless glad I asked. AuFCL (talk) 05:33, 19 June 2016 (UTC)

Male ordinal number vs degree symbol

Before I go offending you by changing a bunch of these may I ask if there is a reason for you choosing this symbol (º) instead of (°) for example here? To me they are visually distinct (the former resembles an underlined version of the latter) yet I keep encountering cases where somebody has made a conscious decision to make the change and I simply do not know the reason why. AuFCL (talk) 03:06, 24 June 2016 (UTC)

Take no offense whatsoever in fact I am grateful for your pointing it out. I should have used ANSI 0176 (°) and not ANSI 0186 (º) please feel free to replace them (there quite a few of them). Also if you find other mistakes, please let me know so that I correct my macro tools as well. — Ineuw talk 03:29, 24 June 2016 (UTC)

Not to worry, it appears Beeswaxcandle has caught the same virus you did: See? AuFCL (talk) 05:28, 24 June 2016 (UTC)

I'm only using it because it's the one in my user symbols list. I hadn't realised that there was a distinct symbol for the two, which means that the wrong one will be throughout both volumes of the Antarctic Voyage. It would be worthwhile finding the works with the wrong one in and running a bot across them to change it. I'll go and fix my list so that I can get it right from now on. Cheers, Beeswaxcandle (talk) 06:52, 24 June 2016 (UTC)

I had a clean-up session some time ago in PSM, so there should not be many instances there, maybe some places whee I was uncertain. @Beeswaxcandle:, I have already a script if you need help.— Mpaa (talk) 17:50, 24 June 2016 (UTC)

All this help is much appreciated. — Ineuw talk 20:41, 24 June 2016 (UTC)