# User talk:Ineuw

## A wikisource database question please

Conversation was moved from User talk:Mpaa

Hi,

Would you know where the value of a template like Font-size-x is stored in the database. I looked at these 10 records extracted from "enwikisource_p", but couldn't find it. Spent an hour studying the schemas linked to the "page" and the "templatelinks" table but could't find it. — Ineuw talk 15:01, 3 July 2015 (UTC)

USE enwikisource_p;
templatelinks.tl_title = ('Font-size-x') AND page.page_namespace = 104 LIMIT 10;

Are you sure this is what you want to do? Your query effectively lists ten Page:(i.e. name space 104) names whose content refers to {{Font-size-x}}. If you want to access the template data itself you might try something like:
USE enwikisource_p;
SELECT text.old_text,revision.rev_text_id,page.page_id,page.page_title
FROM page INNER JOIN revision
ON page_id=rev_page INNER JOIN text
ON old_id=rev_text_id
WHERE page_title='Font-size-x';


This lists all contents of all accessible revisions of the template, which might be considerably more than you wanted! AuFCL (talk) 11:21, 4 July 2015 (UTC)
About 2+ years ago, Mpaa provided me with a list of pages where the {{font-size}} template was used, and the actual % values like 85%, 90%, etc., were used. I am looking to extract this data for the {{Font-size-x}} using SQL, but then I remembered that he did this using Python.— Ineuw talk 14:20, 4 July 2015 (UTC)
Aha! My misunderstanding. You really want the content of all the pages your first query selected…to then further filter out the parameter values on? AuFCL (talk) 21:41, 4 July 2015 (UTC)
I have the list of pages which use the template, but I don't know in which table are the pages stored. Only when I link this data to the pages, perhaps I can extract the size values of the template. — Ineuw talk 01:25, 5 July 2015 (UTC)
Yes…well…you see in principle the table you seek is called (I am not kidding) "text" and ought to look like this structure (ripped from an off-line mediawiki installation):
mysql> show create table text;
+-------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Table | Create Table                                                                                                                                                                                                                                                             |
+-------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| text  | CREATE TABLE text (
old_id int(10) unsigned NOT NULL AUTO_INCREMENT,
old_text mediumblob NOT NULL,
old_flags tinyblob NOT NULL,
PRIMARY KEY (old_id)
) ENGINE=InnoDB AUTO_INCREMENT=3854 DEFAULT CHARSET=binary MAX_ROWS=10000000 AVG_ROW_LENGTH=10240 |
+-------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.11 sec)

However don't waste your time ironing the bugs out of things like the following, as the mongrel situation is that the enwikisource_p view does not appear to incorporate table text (maybe it did back the 2+ years ago when you asked Mpaa before?):
SELECT page.page_title
FROM
INNER JOIN page ON page.page_id = templatelinks.tl_from
INNER JOIN revision ON page_id = rev_page
INNER JOIN text ON old_id = rev_text_id
WHERE
AND (page.page_namespace = 104)
AND (text.old_text RLIKE '85|90') limit 10;

And yes, I know the last query includes every page which used to contain 85/90 in prior revisions. I stopped refining it when I realised it cannot possibly be used for enWS. AuFCL (talk) 03:02, 5 July 2015 (UTC)
I tried something similar but there is no "text" table in enwikisource_p schema, even though it shows one :-)
please look at this database schemaIneuw talk 05:13, 5 July 2015 (UTC)
P.S: try: USE enwikisource_p;

describe text — Ineuw talk 05:15, 5 July 2015 (UTC)

I really cannot add anything more. You have found a very pretty diagram there—what a pity it no longer tells the truth (or rather, it does—we just can't get to that part of the database.) With regards describe I deliberately used the other form for the extra detail it gives. I assure you that whilst the table must exist, it cannot be accessed (by the likes of us anyway) via enwikisource_p. I shall be very pleased if you can demonstrate otherwise. AuFCL (talk) 08:49, 5 July 2015 (UTC)
Accessed the hallowed freenode where I was told by one of the gods that I need to use the en.wikisource.org/w/api.php. — Ineuw talk 19:27, 5 July 2015 (UTC)
Oh hells! I think I know what is being suggested (I just cannot remember where I saw the discussion: please ask Mpaa (or was it GOIII?) about "grep"?) AuFCL (talk) 22:58, 5 July 2015 (UTC)
As I expect that last comment was too terse there is/was an abandoned toolserver utility [1] of that name. Either your IRC contact is suggesting you effectively re-implement it or locate its successor, perhaps? AuFCL (talk) 23:07, 5 July 2015 (UTC)

### Rethink time

Yes, I know you groan every time I try one of these newfangled "thought" things. Nevertheless if your sole purpose in this exercise is to locate all instances of (specifically) {{font-size-x}} used in Page:-space pages which are invoked with first parameter set set to a specific value (80%,90% etc.) why not modify the base template to create a (series of) temporary tracking categories, which you can as a sysop delete later on—at the same time cleaning up the template of course—when you have finished your maintenance? To this end you could add something along the lines of:

-->{{#if:{{{1}}}|[[category:font-size-x-{{{1}}}]]}}<span <!--


to the template and simply let the job queue do its magic? So for example {{font-size-x|85%|blah-blah}} would populate category:font-size-x-85% with a link back to the invoking Page:?

Note this is a technical solution and you might need to ask for permission (or at least forgiveness if you choose to proceed along these lines. Some people might take exception if you don't fully clean up; and although the system load would not be high certain individuals might be alarmed by any precedents being set.) AuFCL (talk) 03:29, 6 July 2015 (UTC)

Overall, please consider these efforts partly as an "intellectual" exercise, and partly of becoming more familiar with using php API, because I forgot what I knew from 7 years ago.

If you are "fishing" to guess what I wanted to do, here is the lowdown: Wanted to figure out if the template was used elsewhere for font sizes over 100%, and did anyone ever use it with measurements like "px", "pt", or "em" apart from %.

In order to achieve this, I extracted all the records in the page namespace linked to this template, removed all references to Popular Science Monthly, and made two copies of the list. In one copy, eliminated all duplicate entries and yieldede approximately ~639 different publications in the page namespace which used the template.

The second list, lists all the pages excluding PSM by their djvu number. In the pages randomly looked at, the template was used for sizes greater than 100% - which was a wasted use of the template, but don't intend to do check them manually.— Ineuw talk 04:04, 6 July 2015 (UTC)

## File:IA catalog of incomplete tasks.jpg

Please restore the image, it's linked from Help:Internet Archive. --Nemo 19:50, 15 July 2015 (UTC)

@Nemo bis: It's done, but all the images on the above mentioned page are outdated. IA changed their looks in a major way. — Ineuw talk 03:20, 16 July 2015 (UTC)
@Nemo bis: Captain, I think your Nautilus went astray, hit an underwater mountain and perhaps it's sinking. My image in the above title appeared nowhere on the Help:Internet Archive page, but noticed your upload of a similar image. Wonder why did you ask me to restore the deleted image when you already uploaded one? - just asking. Both our images are obsolete, so requested at IA a new link to that page and will upload it. — Ineuw talk 05:31, 16 July 2015 (UTC)

## PSM + Henry Moseley + Illustrations of…

Just in case you were wondering what I was going on about with this edit, I shall try to explain: apparently the planned series of books tentatively titled "Illustrations of Science by Professors of King's College" resulted in the publishing of only the first book, in March, 1839 by the mathematician Henry Moseley (there were at least three famous Henry Moseley's, but this one is the only one whose dates are early enough) titled "Illustrations of Mechanics." Apparently P.S.M. has attributed the whole series (and also name of the series) to the author of the sole issue. This is also why you are not likely to find a match searching for Moseley and "Illustrations of Science." I believe this is the relevant VIAF entry (Though VIAF thinks Ill.Mech. was published 1852 which doesn't exactly tally with the google books reference above? WikiPedia seems to only know about the German listing.) AuFCL (talk) 08:52, 20 July 2015 (UTC)

Additional notes: Before you shoot me for being utterly boring, I have since discovered the three Henrys were a granfather-father-son set (no real surprise?) and Henry-senior even has a page here on Wikisource already: Moseley, Henry (1801-1872) (DNB00). Now you can ready,… aim,… bang! (talk) 10:08, 20 July 2015 (UTC)

You're up early :-D — Ineuw talk 02:04, 21 July 2015 (UTC)

## Gadgets: How brave do you feel?

Hi Ineuw.

Gadgets are currently (partially) broken on wikisource as you have discovered in the case of "Special characters". The solution is know and (kind of) documented but there doesn't seem to be any other sysops conscious (see Wikisource:Administrators'_noticeboard#Special:Gadgets) apart from yourself. Do you care to fly this plane? (Take me to Havana!) I'll help if I can if you want or we can wait for the breakers to scrap-metal this baby… AuFCL (talk) 09:56, 7 August 2015 (UTC)

Never mind, Billinghurst has turned up and apparently the issue does not exist for him. AuFCL (talk) 10:33, 7 August 2015 (UTC)
Hi. If you are referring to my plea for Help about the missing advanced toolbar, I realized that mother nature was interfered with. I switched to the "legacy" toolbar which still works fine, — Ineuw talk 18:52, 7 August 2015 (UTC)
Indirectly, yes. MNIATB (let you figure that out—hint: it's impolite.) Billinghurst performed the set of changes I was intending to coach you through had you so been willing but its only fixed about 80% of the problems. Until anybody else complains bitterly (or everybody rolls over and just lives with the latest minor mess) there really is nothing more I can suggest. For me at least the ProofreadPage toolbar has completely disappeared but A.B. claims all is working O.K. so no incentive there. AuFCL (talk) 19:26, 7 August 2015 (UTC)
MotherNatureIsATotalBitch? Master, however impolite, please enlighten this unworthy pupil.— Ineuw talk 19:37, 7 August 2015 (UTC)
I had thought the derivation obvious. Mind you I have just completed my tax return and am probably feeling a bit mean.

On a lighter note, in case you are still interested in <poem> esoterica I recently put together a little piece for Einstein95 which might prove handy some day? AuFCL (talk) 07:23, 8 August 2015 (UTC)

## Conquest of Mexico

Good morning. Questions, Should I continue using the anchor stuff for references, I tried changing to what you did, but somehow are not showing in the text. Also please confirm the need to remove the {{ }} as per the first note. I keep on using them. Muchas Gracias.--Raúl Gutiérrez (talk) 13:12, 7 August 2015 (UTC)

We are missing this image on the list
https://en.wikisource.org/wiki/Page:The_Conquest_of_Mexico_Volume_1.djvu/125
Raúl Gutiérrez (talk) 16:22, 7 August 2015 (UTC)
@Gumr51: Hi. We should keep the anchors by the superscript numbers because it's not much extra work and if we cease adding them, we may regret it later.
I don't understand "I tried changing to what you did, but somehow are not showing in the text." - could you please elaborate?
"Also please confirm the need to remove the {{ }} as per the first note." I don't know what you mean by this?
For image sizes, I proportion the image width by the page text width. (500px) So, I modified the the sizes on this page. — Ineuw talk 18:41, 7 August 2015 (UTC)
P.S: One addition. I removed the {{smaller}} template from the caption because GO3, already reduced the caption size to 83% - which is the same as "smaller". When you apply the template, it makes the text 83% of 83%. Wherever you've done so with previous captions, I will adjust it. — Ineuw talk 18:45, 7 August 2015 (UTC)
@Ineuw:Please do not edit when I am editing, because your pages does not like it and I just lost my notes.(LOL)
Ok with the anchors.
This has to do with the first entry a top this page.
Feel free to edit. Will stop using the smaller command.
New quation, how can I chnage the editing language to english, it is in spanish and does not help proofread.}
Muchas gracias--Raúl Gutiérrez (talk) 18:57, 7 August 2015 (UTC)
@Gumr51: Sorry Raúl, but I had nothing to do with the loss of your notes. When getting an edit conflict message, I copy out my changes and paste it in a notepad and leave the page untouched. Change of the image sizes were done after you completed your proofreading.
The language setting is in the /Preferences, /User profile tab, /Internationalization. I also think that some of the personal preferences (like language) are also stored in the wikisource cookies. To be sure, one needs to remove the cookie, and redefine the personal references and log off and on to see if the language is correct. Test the English Wikipedia if you have the same problem. At one time there used to be a single universal login to all accounts, but I am not sure anymore. — Ineuw talk 19:21, 7 August 2015 (UTC)

@Ineuw:Something is not working with the images on this page, please review. Would like to know what I did wrong. https://en.wikisource.org/wiki/Page:The_Conquest_of_Mexico_Volume_1.djvu/242 Muchas Gracias--Raúl Gutiérrez (talk) 13:31, 10 August 2015 (UTC) Samething with this one: https://en.wikisource.org/wiki/Page:The_Conquest_of_Mexico_Volume_1.djvu/243, but please no rush, when you have a chance.--Raúl Gutiérrez (talk) 13:47, 10 August 2015 (UTC)

Sorry about it, went back and found the mistake, was missing }}...Problem corrected--Raúl Gutiérrez (talk) 13:54, 10 August 2015 (UTC)
my friend, we are missing image. https://en.wikisource.org/wiki/Page:The_Conquest_of_Mexico_Volume_1.djvu/278 --Raúl Gutiérrez (talk) 13:46, 11 August 2015 (UTC)

## Float revisited

Hi,

Noticed your addition to Table_style/doc and thought it might not be best to specify a single usage (the floated image scenario) for it might be construed as "universal" or something.

The problem whenever using float is that it implies the use of the block layout -- which is hardly always the intent. In short, float modifies the computed value of the display values in some cases. See the table here for a list of scenarios where the existing display value gets "usurped" when using float. -- George Orwell III (talk) 22:37, 8 August 2015 (UTC)

No problem. Removed reference to the FIS template.— Ineuw talk 02:22, 9 August 2015 (UTC)

## Default settings

In case you couldn't find this question hidden on my Talk page: To be clear, I set to default (by using the link at the bottom of each page) EVERY page of Preferences? Even the User Profile page, e.g.? Londonjackbooks (talk) 22:12, 14 August 2015 (UTC)
That's fine. I do the same because there is no info what it saves. But, what are the results of the changes? — Ineuw talk 22:14, 14 August 2015 (UTC)
Haven't done it yet... Just checking again to be absolutely sure. I'll post my findings on my Talk page after I set the pages back to default. But as of right now, with my common.js page blanked, I get a consistent toolbar. Londonjackbooks (talk) 22:19, 14 August 2015 (UTC)
I set each page to default... Editing default settings have both "Show edit toolbar" AND "Enable enhanced editing toolbar" checked. Which should I uncheck, if any? Londonjackbooks (talk) 22:24, 14 August 2015 (UTC)
Inserted this reply because we simultaneously posted here. Disable the "Show edit toolbar" which is the "legacy" toolbar. I remember the reason why both were activated, and it's no longer relevant. — Ineuw talk 22:29, 14 August 2015 (UTC)
That's fine just let us know, especially now that our Prince Charming has returned from the forest. It seems that the background color function may have been at fault. — Ineuw talk 22:26, 14 August 2015 (UTC)
Results posted to my Talk page. Thanks! Londonjackbooks (talk) 22:49, 14 August 2015 (UTC)

## Javascript in the mediawiki environment

I know you can "get away" with things like:

if (wgAction == "edit" || wgAction=="submit"){


—but you should know the browser emits warnings like:

"Use of "wgAction" is deprecated. Use mw.config instead." load.php:156:550


—as a result. The alternate form:

if(.inArray( mw.config.get( 'wgAction' ), [ 'edit' , 'submit' ]) > -1) {  —might just be more robust with regards future developments? AuFCL (talk) 03:57, 15 August 2015 (UTC) Thanks. I will replace this tomorrow. Now, I am resting with the proofread of a couple of pages.— Ineuw talk ## Some orphaned pages you created on 6 August Hi, I'm checking through Special:LonelyPages and there's a series of pages created by you from The Conquest of Mexico Volume 1 (list #2610 to 2620. The page numbers have all got leading zeroes, so must have been deliberately created, rather than taken through the usual process. I see the pages that they duplicate are all validated already. Are they still needed? Beeswaxcandle (talk) 06:40, 23 August 2015 (UTC) Hi. Thanks for the info. Those pages were numbered by mistake (generated the list with numbers padded with 0 for even column widths), and noticed the numbering error later but had no clue what happened to them. So now I know that what goes around, comes around. Tried to find them, to delete them, but don't know where they are. — Ineuw talk 19:44, 23 August 2015 (UTC) ## Help:Font size templates I saw your overnight work on the above and concur. However in light of Bob/Guy's response earlier I am seriously wondering if all references to {{font-size-x}}, {{font-size70%}}, {{font-size75%}}, {{font-size85%}}, {{font-size90%}} and their {{fs…}} equivalents ought to be quietly dropped from this page on the basis Mr. B. seems to be treating them as his personal plaything &/or at least tied rather strongly to his own projects and thus not for public consumption at least under those names? Yes I am aware you have either constructed or had a hand in the evolution of several of these but the change comment here fills me with concern that our friend considers he might have co-opted the rest of the family as well. I may be misquoting you but I had gathered the impression longer term you were thinking of moving away from using this family of templates in any case and so the privation may not have a lot of real impact? In any case I would very much appreciate a second opinion. AuFCL (talk) 21:32, 12 September 2015 (UTC) @AuFCL:I am not worried about it. Also, the diff page link above doesn't exist. :-) — Ineuw talk 23:32, 12 September 2015 (UTC) O.K. with me. Fixed link (too tired: too many slashes.) AuFCL (talk) 00:08, 13 September 2015 (UTC) Both changes refer to either {{font-size-x}} or {{fsx}}(a redirect to the same) are LG's responsibility and I don't go near it. Now take a rest. :-) — Ineuw talk 00:20, 13 September 2015 (UTC) ## Toolbar closure Good morning, Ineuw. I think they are looking for some closure for this ticket. I thought you might write a better comment than I could. Thanks! Londonjackbooks (talk) 12:39, 15 September 2015 (UTC) Hi. Yes, we got the same message and I took care of it and the issue is closed. Thanks for letting me know. — Ineuw talk 17:24, 16 September 2015 (UTC) ## In a recent fit of overconfidence... ... I proofread Page:Popular Science Monthly Volume 55.djvu/468 only to realise I know nothing about the PSM convention for font-size-template choice for "aside" sections more or less filling space at the end of a major article (I used {{fine block}} which I am sure is the "wrong" choice. Worse yet (although I looked) I could find no guidance as to the rules. Either there is none or my ability to find it is shot.) Either way—at your infinite leisure—would you please review the page and embarrass me with appropriate correction or (hopefully mild?) abuse. AuFCL (talk) 02:36, 12 November 2015 (UTC) Thanks for the proofread. I don't think that you should be concerned about the exact style because I check every page and (correct) update the format to standardize the same layout. I will check and add the missing info to the PSM Proofreading Guide.— Ineuw talk 19:49, 12 November 2015 (UTC) I started on a bit of a personal blitz on Cite errors...and wound up here, amongst other places. As this change was rather naughty would you please do me the honour of placing it somewhere on your review list so that I may learn what (if any) is the "sanctioned" approach? AuFCL (talk) 10:37, 15 November 2015 (UTC) First, consider yourself honoured and please have confidence in your undertakings. I don't know if you are religious or not, but for what it's worth, you have my blessing to insert the information in any document I have put my finger into. It help me to learn more. — Ineuw talk 17:00, 15 November 2015 (UTC) ## PDF on Archive.org -- Balderdash https://archive.org/details/cassellsillustra09lond Ineuw, I come to you with a plea and partly because you taught me some of this awhile back but things have changed. We did a couple of books that were originally in .PDF format before .DJVU became so prominent. There are times I prefer a .pdf file over .djvu and although the above link shows various formats which are supposedly downloadable (i.e. PDF file & others formats are shown to download at the above, and on the following page, .PDF is not downloadable on either page. Where, or How, would find the PDF file *if* it even exists? I don't believe it exists but I know you well enough that f it can be had then you would have the "know-how". Please assist just as others, especially George Orwell III has assisted you, in so many things with his intellectual wizardry. Kind regards, —Maury (talk) 12:31, 22 November 2015 (UTC) so neither of these links opens/downloads one .pdf or the other? -- George Orwell III (talk) 13:07, 22 November 2015 (UTC) Hi George! No, neither of the links you posted do anything. The link I posted takes me to the area and shows the potential files to be download and 1 as the item, but that's all. Turn to the next page where I am used to the djvu files and they downloaded easily. VOL.1 is on Wikisource. We used to have to place a .PDF file on Archives and let it work up several formats to get a .djvu. Now it has .DJVU that we bring here -- or at least the 9 volumes of Cassel's Illustrated History of England I want are .DJVU only. PDF is shown and the file size is shown but is not downloadable. —Maury (talk) 13:27, 22 November 2015 (UTC) Hi Maury. I gladly help you anytime. The problem cannot be IA because when I clicked on the link, it opened up immediately in the browser. Right click on the link and select "save as" to download to the desktop. See this image I uploaded for you., OR use http://tools.wmflabs.org/commonshelper/ to transfer the file directly to the commons. And since color is nice use the file without the "bw_". If you need me to download/transfer, let me know. — Ineuw talk 17:24, 22 November 2015 (UTC) Thank you Ineuw & George! It worked. Ineuw's explanation for downloading (save as) is what I was not doing right. I knew to go to the smartest people I know here and I knew where there was one intellectual the other intellectual would be around. You both are very kind for helping. You two are what makes Wikisource a good place. My sincere respect, —Maury (talk) 03:01, 23 November 2015 (UTC) ## Humble Pie Hi. Please remind me again what is that thing that traditionally follows Pride in the 7 Deadly &c.? Well you were quite right! I had not anticipated that SF00 had nested things three deep at one point—with the result transcluding the Index as a unit blew all the expansion-depth limit constraints (I don't even understand how that expression makes sense bearing in mind much of this thing is written in LUA; blowing memory size or taking too long to execute, sure, but E/D surely is a concept which only makes sense in the template world? Maybe this is uncorrected/inappropriate error message text?) I have sort of recovered and the (now four!) part results are here if you are interested in seeing that width-sizing in action in action in action in action. Hey! is there some kind of an echo in here? AuFCL (talk) 10:01, 9 December 2015 (UTC) It looks good to me but each section is still a different width. Also, Pride is followed by sorrow/despair/despondency . . . pick and choose. Now, the index entries should be linked to the subject. :-) — Ineuw talk 06:24, 10 December 2015 (UTC) Isn't stage 9 of the despondency cycle planning of revenge on the amateur psychologist who thought you would need to know about the steps in the U-bend model? I am pretty sure it was for me the last time this issue arose and afterward nobody really ever asked any really hard questions about the fire. Judicious and irresponsible applications of lashings of width=464px would do the trick. But I would not stoop so low as to contemplate playing such a mean trick would I? AuFCL (talk) 10:02, 10 December 2015 (UTC) After playing around with this template, trying to add |width:464px, I am more convinced than ever that a wiki table is much simpler to design and thus superior.— Ineuw talk 19:03, 11 December 2015 (UTC) Oh well it was an attempt. And this issue isn't really its basic purpose. If it is no use to you I'm certainly not twisting your arm. Oh, and to misquote: "An equality, an equality, my Kingdom for an equals sign!" (Are you sure you meant to write |width:464px when I clearly specified width=464px earlier. Now whom is teasing whom here because in all that excitement I've kinda lost count? AuFCL (talk) 21:47, 11 December 2015 (UTC) Dear I. Reflecting further upon this I realise the situation has revealed less of a problem with the template/module than a split in various party's expectations. If I may so presume: you appear to like to wrap content in <div>s which control the overall width of the final presentation and thus in your circumstance option compact=yes is fighting against your expectations; in Londonjackbook's case it provides the very behaviour she desires. ShakespeareFan00 happens to be this specific example provider and (at least so far) has not expressed an opinion as to prefereed behaviour. The issue in fact at present remains open: can the template provide (or be modified to provide) the specific behaviour that a particular party wishes under a given circumstance? (I happen to remain generally optimistic—at least so far!) On the other hand will any codified solution satisfy all viewpoints simultaneously: the answer is already well-known and that is DREAM ON THOU'ST FOOL! Joking aside, unattainability of any acceptable solution whatsoever rather perversely yields a great deal of freedom: if one accepts from the get-go that nobody will ever be satisfied with any solution, then any (even partial and unsatisfactory) solution presented is clearly an improvement upon the status quo: nothing at all. AuFCL (talk) 01:48, 12 December 2015 (UTC) You are NUTS! :-) — Ineuw talk 05:02, 12 December 2015 (UTC) Of course. Did you ever doubt it? And now we have Prosody endorsing the conclusion as well (waves!) You still haven't answered my question as to what you want the styling algorithm to actually do—I suspect you really want the default behaviour which I further expect you haven't even seen yet: and that is everything stretched across all available display width. In fact have a look at the "cheat-sheet" for what I am trying to describe here. AuFCL (talk) 09:56, 12 December 2015 (UTC) @AuFCL: This shows how little attention is paid to my surroundings as I go about doing my "thing" aka PSM. When I look at a template's history, it usually reveals a "multitude" of contributors and their edits. Didn't even know that the template existed, and then surprised that it was the sole creation of your impressive coding. My comment was only about the column widths which should be of the same every page. Please consider this an apology, and not ass kissing. — Ineuw talk 18:43, 12 December 2015 (UTC) ┌──────────────────────────┘ Thank you for rescuing me from my own stupidity even though I (thought I) had explicitly asked you not to bother! The following is the message I was going to send (but please do not follow the instructions for what I hope in hindsight are incredibly obvious reasons!): Payback time? Bearing in mind our last exchange I am giving you right of first refusal on this. Mpaa's post at the Scriptorium Wikisource:Scriptorium#Checker set me thinking (don't laugh—yet!) as usual along—different—lines and I have come up with a prototype code fragment Special:permalink/6025842 which I would like to present there. Whilst looking around for a nice sample page to demonstrate the intended effect I came across Page:Popular Science Monthly Volume 78.djvu/455. However as you were the putative proofreader you may not want this. In any case naturally I would appreciate it if you might be so kind as to give it a trial and let me know if you consider the outcome not too embarrassing for either one of us? I will accordingly act only upon your advice. In essence the fatal bug is to choose ID="content". I shall have to choose a less ambitious anchor point and until then treat this code with respect due its unexpected teeth! AuFCL (talk) 07:33, 24 December 2015 (UTC) @AuFCL: Sorry for removing that error on vol 73 page 455 - but it can be put back and you can go ahead and do your thing anywhere on my proofreads. — Ineuw talk 09:42, 24 December 2015 (UTC) ## Typo checker Yah boo! You still missed "modem"--->"modern" on that page! (Still working out a usable script which won't create—too much, I hope!—havoc.) AuFCL (talk) 09:50, 24 December 2015 (UTC) Oh bah! The correction wasn't even correct: the fragment should read "We are coming to recognize…", not "Ye are coming to recognize…" anyway. AuFCL (talk) 09:54, 24 December 2015 (UTC) Would you (or even better your IneuwPublic avatar) please do me the kindness to be a guinea-pig for this? I have considerably defanged some of the nastier aspects of my earlier quick-and-dirty typo scanner prototype and believe it is now fairly safe for use (if anything the code is too cautious and thus not nearly as efficient as it might be—it probably has a tendency to run too long and scan too many times, yet seems to give up after it tags one typo even though there are others to find...) Anyway the latest attempt is now here which may be copied and added to (say) user:IneuwPublic/common.js. Yes I know it is a fair whack of code! With my luck somebody will immediately point out a standard library/routine which does it all better anyway! After doing so I hope you ought to be able to see the effect by looking for example at Seventeen lectures on the study of medieval and modern history and kindred subjects/The Reign of Henry VII. (1) AuFCL (talk) 12:21, 26 December 2015 (UTC) I did as you asked, and it's very interesting, . . . except, could it be activated in the edited text rather than the view/preview mode? It would be a lot quicker to correct. IneuwPublic (talk) 19:26, 26 December 2015 (UTC) Ooo, that is bad for the eyes. I am so sorry! (Every so often the scanner seems to pick up sequences like '~W' (deliberately not one searched for so you can read this!), marks it and then picks up the marked version and marks that... No we did not both take L.S.D. To disable the thing either comment-out or remove the three lines: //jQuery( document ).ready( // HighlightTypos() //);  The line containing:  if( !( /search=/.test( location.href ) || /special(:|%3A)/i.test( location.href ) ) ){ //don't bother scanning search results or Special: pages.  —contains (some) conditions to suppress its execution: currently search results or Special pages as stated. Two reasons for not activating it on the edited text: firstly it was intended to draw your attention to pages which still need touch-ups and secondly I simply don't know how to highlight specific areas within the edit area; especially without messing things up even more for the editor. AuFCL (talk) 20:07, 26 December 2015 (UTC) Thanks for the info, and please leave it as is. The color is not my issue, it's finding the place of correction quick (I am lazy). I am going to transfer the code to the "Ineuw" account. Is there anything I have to watch for when I append it to my code? Or, I will find out sure enough. :-) — Ineuw talk 22:17, 26 December 2015 (UTC) I have modified the thing a little more: tried reversing the highlighting order in hopes to resolve that "recursive" bug—no improvement really. What might be useful though is I further restricted the pages it is active upon:  if( !( /((oldid|search)=|(mediawiki|special|talk|user|wiki(media|source))(:|%3A))/i.test( location.href ) ) ){ //don't bother scanning search results or given ns pages.  —this kills scanning of Special:/system namespaces/talk and User: pages, permalinks and (some) difference and search displays, on the basis there is probably no point in confusing things you could not fix anyway. I recommend this part (or you can risk copying the whole of user:AuFCL/common.js if this is easier.) Thank you for taking a chance on this experiment. It may yet turn out to be a waste of time! Oh, and I am currently experimenting on stopping the scan after an arbitrary number of "hits" are marked. As I've not fully tested that part I'll not subject you to that yet. AuFCL (talk) 22:43, 26 December 2015 (UTC) @AuFCL: I don't consider it a waste of time, please continue and I will gladly test it. I do have a minor question. I removed the word "double" from 'border:5px double red;' ); but now I don's see anything. Any sugestions? Re: "double" (at least that part is easy): The string is just—as you probably realised—inserted into a <span style="...">. Regrettably the CSS default is "none" here so as you can see <span style="border:5px green;">this</span> does nothing to "this"; but maybe what you want is the "solid" keyword: <span style="border:5px solid green;">something!</span> ought to produce "something!"? AuFCL (talk) 23:27, 26 December 2015 (UTC) @AuFCL:File:Typo highlight script issue.jpg one pic is worth a thousand words, or so they say. Firefox crashed. and the picture will show why. — Ineuw talk 23:13, 26 December 2015 (UTC) Ooo! Yuck! Sorry! Time to roll out the "limited matches" version (currently in user:AuFCL/common.js. At least when it messes up the smear should be a lot shorter! (And also should do so much damage as to crash anything.) AuFCL (talk) 23:27, 26 December 2015 (UTC) ┌───────────────────────┘ If you just copied my common.js please do so again. I have further removed scanning of Index: pages and amended the "^" check, so that Page:Popular Science Monthly Volume 43.djvu/813 should no longer misbehave. AuFCL (talk) 23:41, 26 December 2015 (UTC) @AuFCL: Hi, It doesn't highlight these characters �, '<' and '>'. which I probably not defined proplerly, but do occur. Just playing.— Ineuw talk 03:26, 27 December 2015 (UTC) You have unerringly chosen some of the "hard cases"! Strictly I cut-and-pasted the "�" from a known problem page—however in point of detail I suspect there is a whole raft of distinct UNICODE characters the browser does not understand and substitutes this to display instead—i.e. I think it might be a firefox analogy of the famous IE open-square-box? (Finally note that when editing common.js this character generates a warning: "This character may get silently deleted by one or more browsers.") As for the other two if you reflect a bit you'll realise these are potential open and close characters for tags: e.g. <div> et al and my code is currently jumping through hoops to try to avoid hitting tag/style stuff; so the fault most likely is mine rather than yours. Unfortunately I have a choice of two distinct means of modifying the display page via javascript: updating via nodeValue won't permit adding active tags like <span> so I used the innerHTML modification technique instead... which won't let you insert < or >s without analysing them as potential tags. May I declare these (and if truth be known "^" as well) too hard for right now? (I do have a few ideas left but they involve a total rewrite and probably won't give any net benefit anyway.) AuFCL (talk) 04:29, 27 December 2015 (UTC) I was aware of the common.js warning about other browsers. About the ">" and "<", suspected that I was doing something wrong. but you shouldn't "jump through hoops" about potential "unwanted" tags, show them for now because (to my mind) they don't exist in unedited text, and how many could there be on a proofread page? I understand how you would like to foresee all possibilities at once and cover all the bases. Don't waste your time on it. The glitches will work out eventually. I'd rather have you tell me when to test with the other browsers, which I will wait until you let me know. I still have IE 11, Chrome, and Opera installed in Windows. — Ineuw talk 05:06, 27 December 2015 (UTC) Re: other browsers: please feel free to give it a try at will. I hope I've chosen the "non-specific-to-browser" choices but you never know until they're tried. AuFCL (talk) 05:27, 27 December 2015 (UTC) One more thing that occurred to me. If possible restrict the script to function only on proofread and validated pages. You will save yourself a lot of pain. Before proofreading, all page have the same errors repeated and a lot of them. For example, I just came across a word for Maine, as ^\ine. which makes another mess on an unedited page. — Ineuw talk 05:15, 27 December 2015 (UTC) Simple one to push under the rug: right at present the code is not particularly name-space-aware and as such does nothing "special" for any of the ProofRead states. Good idea but for future? (I am going to declare burnt-out-for-today I think.) AuFCL (talk) 05:27, 27 December 2015 (UTC) I think you should quit while you're ahead. :-) — Ineuw talk ## Typo checker 2 User:Ineuw/common.js • List of ideas: • lie --> he • { } --> single opening or closing braces. • highlighting of proofread and validated pages. ## Typo checker: show stopper Thank you very much for participating in this experiment. However I have just made a discovery (you may laugh) which makes the whole thing useless when run from common.js. It appears that common.js actions "run" far earlier than I had anticipated they would. As I had relied completely upon the fragment jQuery( document ).ready( HighlightTypos() );  —to ensure the typo checking code ran only after page display was otherwise completed; and this turns out not to be true at all—the various hang-ups and crashes (and worse) will be unavoidable. I strongly recommend removing it and going back to your old set-up until such time as an alternative becomes available. In case you are interested the final straw was this: please have a look at Page:Popular Science Monthly Volume 1.djvu/90. The checker ought to pick up the double-hyphen (should be mdash?) O.K. whilst simply browsing the page. If you then open the page for edit you may note the checker changes the Header contents to {{rh|80|''THE POPULAR SCIENCE MONTHLY.''|<span style="border:5px double red;">}}</span>  Oho! it has picked up the double-close-braces, and indeed it has. Please do not save this state! However this is a disaster because it means you cannot save any legitimate changes to the page without including this one, which of course will break the template. But why is it changing this at all? The code is supposed to explicitly not hit the edit fields like this! And now the sad truth emerges. During page edit mediawiki first draws the page outline; then prepares the edit boxes (header/body/footer) and starts loading the scan image; then (insanely!) runs common.js and finally constructs the Preview area. But I wrote the code using the presence of the Preview area as the trigger to behaviour, and as it is not there the code thinks it is examining a normal main-space page with the result the edit boxes are scanned in error. I repeat, please remove (or disable as discussed previously) the typo checker from common.js (that includes on IneuwPublic) until such time as this is resolved. I apologise for the inconvenience. AuFCL (talk) 21:05, 27 December 2015 (UTC) You are up early. I am using Ineuw and not IneuwPublic, and made some minor changes/additions to the Ineuw copy (take a look) and it works fine for me without any problems. Are you sure? — Ineuw talk 21:21, 27 December 2015 (UTC) Rest assured you have been lucky then. I originally wrote and tested this thing under the GreaseMonkey extension in Firefox, which does fairly carefully ensure scripts don't get launched until the destination page fully "settles down." However as that does not appear to be reliably true of running stuff in common.js I think the opportunities for it all to end in tears make it far too dangerous for general use. (Mind you, if you choose to go the G/M way I'll be more than happy to pass on the full script. Such a pity it overlaps into the TemplateScript arena—sometimes there are too many choices available due to parallel development.) AuFCL (talk) 22:52, 27 December 2015 (UTC) I am happy with it and I've had no problems. Hence my confidence in you, in spite of, and because of, your worries. What is the G/M way? Is there more code which your held back because of your concerns? Just "go boldly where no programmer has gone before." Does that date me or what? — Ineuw talk 23:04, 27 December 2015 (UTC) Oy vey! And this is why the task of kicking puppies ought to be left to professionally trained heartless bastards! Right. Consider yourself suitably warned you are now officially playing with fire after being nicely warned of the consequences! Braces, and in fact both brackets and parentheses are all symbols with special meanings within regular expressions. Which is why:  HighlightTyposLike( '{', 'border:3px solid blue;' ); HighlightTyposLike( '}', 'border:3px solid blue;' );  —recognise those?—are probably not working. To fix this the two lines may be merged into one thus:  HighlightTyposLike( '[{}]', 'border:3px solid blue;' );  —the '[]'s effectively "protect" the '{}' by making a search condition which matches either an opening- or a closing- brace. Now your troubles will really start. If you choose to go down this path then there is a race-condition (maybe that is why you have been lucky and I have not: perhaps your fast internet connection has saved you?) under which occasionally the script gets confused and mistakenly analyses the input fields of an edit session—with the result that normal template calls may be marked incorrectly with consequences outlined above. Maybe your luck will hold and then maybe it won't and you will then blame me. At which point there may be much acrimony deflected by "I told you so." I don't want to take that risk. You may see matters otherwise. AuFCL (talk) 03:20, 28 December 2015 (UTC) Thanks about the braces, Was sure you'd come through, because I knew that it must be a reserved character. Of course I could have looked it up on the web, couldn't I? As for my "high speed" connection it's only 8.5 mbits, (but unlimited use), and I am envious of my neighbour George, who just installed cable (also unlimited use) at 30 mbits. He has no clue what it means, except he knows that it's quicker than he had before. All he does is reads email, watches the weather channel and business news. :-) — Ineuw talk 03:35, 28 December 2015 (UTC) I wash my hands of you—truly hopeless. You do realise:  HighlightTyposLike( ' [.]', 'border:3px solid blue;' );  —is effectively the same as:  HighlightTyposLike( ' .', 'border:3px solid blue;' );  —and thus matches any space followed by anything at all? You must really like the colour blue. Eh. You could do worse than read a Javascript RegExp Reference. AuFCL (talk) 05:35, 28 December 2015 (UTC) I am not that hopeless. I am familiar with Regex but how is it a direct part of javascript I am ignorant of. So, I just did it and waited until you let me know. And you certainly did! So my strategy worked. At least now I know that string manipulation in javascript uses Regex. And yes, I am aware what ' .' means in Regex. So, if that's the case, I should specify ' \.' correct? I am trying to find the occurrence of errors like: 'Blue .danube' etc. <- Notice the Blue my example. — Ineuw talk 05:57, 28 December 2015 (UTC) ┌─────────────────────────────────┘ @AuFCL: You have no idea how many modems were used, and written about in the 19th century. I wonder if they were dial-up or ADSL. :-D — Ineuw talk 05:27, 29 December 2015 (UTC) Why else do you suppose I chose it as a suitable "almost-always-in-this-context" typo? I would have gone for "arid" as a pretty common one as well (should be "and".) However PSM has quite a few legitimate uses as well (I think I picked up the bulk of the ones in error a few months back.) AuFCL (talk) 05:59, 29 December 2015 (UTC) One problem is that it picks up the capital letters at the end of a word. Which means that Roman numerals like II, III, IV, VI, VII, VIII, etc. get tagged and there is a lot of them in PSM. — Ineuw talk 06:05, 29 December 2015 (UTC) Well you, you great nana, did that yourself here:HighlightTyposLike( 'ii', 'border:3px solid blue;' ); //14 More seriously maybe it would simplify things a lot if the case-insensitivity were removed and instead of the code messing around with string conversion to regular expressions you were to put them in directly (seeing as a certain show-off has revealed he knows all about such things)? AuFCL (talk) 06:48, 29 December 2015 (UTC) Yes master, could you advise how to refine it? signed the Great Nana. — Ineuw talk 06:53, 29 December 2015 (UTC) O.K. THE great nana (better?) Step the first: let's get rid of the duplicate of HighlightTyposUnder in user:Ineuw/common.js (the one which starts off: function HighlightTyposUnder( node, pattern, emphasis ){ if( node ){ if( node.nodeType == 3 /* TEXT_NODE */ ){  —for the rest, oh you might as well just strip out the whole thing and model it on User:AuFCL/common.js/typoscan.js, which lets face it I modelled upon your copy anyway so it ought to contain all of your scan scans (or at least my understanding of them.) AuFCL (talk) 09:39, 29 December 2015 (UTC) Done, and thanks for this valuable tool.— Ineuw talk 17:30, 29 December 2015 (UTC) Checked all the main namespace page articles of PSM Vol 43, which is the fastest way to check and found quite a few of missed typos. I also found and corrected some misspelled words when correcting the typos, and I am sure that there are more. In any case thanks again.— Ineuw talk 19:33, 29 December 2015 (UTC) I forgot to mention (my) last night: if you want to add new search sequences please bear in mind this version gives you full control over the match. If you omit the /g part then only the first encountered match will be marked (I think the "/g" stands for "general"?; the other useful value is "/i" which makes the pattern match both upper- and lower- cases—"insensitive"?. There is also "/m" ("multiline") which so far I've not found particularly useful and as such have ceased using.) AuFCL (talk) 20:14, 29 December 2015 (UTC) Thanks again, but unbeknown to you, I have been reading up on Regex (again) at the link you provided, as well as have used it occasionally with the Regex search & replace on the sidebar. As a great nana, I feel responsible to let you know that I think that "/g" means "global". — Ineuw talk 20:48, 29 December 2015 (UTC) Just demonstrating there are others old and lazy enough to sometimes be cunning as well. I debated "grated banana" but y'know…mushy…Γραμρα… 58.164.17.191 20:58, 29 December 2015 (UTC) (Out of curiosity only: does wikisource occasionally log you out without warning, as it just did me above? Something is flaky. AuFCL (talk) 21:01, 29 December 2015 (UTC)) Not logged me out when I was working, but did loose my auto login on may occasions. — Ineuw talk 21:06, 29 December 2015 (UTC) I know you will scoff for me pointing out the obvious but how about making the substitution: HighlightTyposLike( /\Wlie\W/g, 'border:3px solid blue;' ); //12  —of course I am assuming you are trying to catch typos for "the" (or like.) The old string is catching lots of legitimate words like "believe" and at least this chops them out. Worth trying? AuFCL (talk) 06:36, 30 December 2015 (UTC) ┌─────────────────────────────────┘ Thanks for the snippet, and yes I was getting many lie's — Ineuw talk 08:16, 30 December 2015 (UTC) Here is another one I think seems to come up often enough—worth considering?  HighlightTyposLike( /\WAve\W/g, 'outline:5px double olivedrab;' ); // typo of "we""  Of course amend to suit your current preferred style-colour-weight-scheme. AuFCL (talk) 07:05, 31 December 2015 (UTC) Don't know if you've been thinking in these terms but here is a small "gotcha" might be worth you knowing as well. I trialled a check for multiple consecutive spaces on the basis most of the clean-up or tidy scripts available do this anyway so why not check if they've never been run in a former edit session? Originally I tested for two or more spaces but have now discovered transcluding across {{hws}}/{{hwe}} if there is also a footnote on the earlier page (i.e. the usual case) actually ends up injecting two spaces into the final result and this is legitimate and not addressable by the editor. So I ended up with this sort of thing:  HighlightTyposLike( /[ \t]{3,}/g, 'outline:5px double olivedrab;' ); // three or more consecutive space or tabs (worst case two can be legitimate in transclusion)  —it will be interesting to find out if it ever actually triggers? AuFCL (talk) 21:30, 31 December 2015 (UTC) The presence of the footnote was an irrelevancy: I have since noted the double space appears when hws/hwe is used in every case under <pages>. AuFCL (talk) 21:39, 31 December 2015 (UTC) ## 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 <sup></sup> 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.

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)