User talk:Ineuw/Archives/2015-12-31

From Wikisource
Jump to navigation Jump to search

A wikisource database question please[edit]

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)[reply] 

USE enwikisource_p;
SELECT page.*, templatelinks.* 
    FROM templatelinks INNER JOIN page 
        ON page.page_id = templatelinks.tl_from WHERE 
            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)[reply]
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)[reply]
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)[reply]
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)[reply]
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
       templatelinks
          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
       (templatelinks.tl_title = 'Font-size-x')
          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)[reply]
I tried something similar but there is no "text" table in enwikisource_p schema, even though it shows one :-)
please look at this database schema — Ineuw talk 05:13, 5 July 2015 (UTC)[reply]
P.S: try: USE enwikisource_p;

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

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)[reply]
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)[reply]
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)[reply]
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)[reply]

Rethink time[edit]

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)[reply]

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)[reply]

File:IA catalog of incomplete tasks.jpg[edit]

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

@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)[reply]
@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)[reply]

PSM + Henry Moseley + Illustrations of…[edit]

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)[reply]

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)[reply]

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

Gadgets: How brave do you feel?[edit]

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)[reply]

Never mind, Billinghurst has turned up and apparently the issue does not exist for him. AuFCL (talk) 10:33, 7 August 2015 (UTC)[reply]
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)[reply]
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)[reply]
MotherNatureIsATotalBitch? Master, however impolite, please enlighten this unworthy pupil.— Ineuw talk 19:37, 7 August 2015 (UTC)[reply]
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)[reply]

Conquest of Mexico[edit]

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)[reply]

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)[reply]
@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)[reply]
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)[reply]
@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.
Please ignore
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)[reply]
@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)[reply]

@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)[reply]

Sorry about it, went back and found the mistake, was missing }}...Problem corrected--Raúl Gutiérrez (talk) 13:54, 10 August 2015 (UTC)[reply]
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)[reply]

Float revisited[edit]

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)[reply]

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

Default settings[edit]

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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
Results posted to my Talk page. Thanks! Londonjackbooks (talk) 22:49, 14 August 2015 (UTC)[reply]

Javascript in the mediawiki environment[edit]

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)[reply]

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[edit]

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)[reply]

@Beeswaxcandle: 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)[reply]

Help:Font size templates[edit]

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)[reply]

@AuFCL:I am not worried about it. Also, the diff page link above doesn't exist. :-) — Ineuw talk 23:32, 12 September 2015 (UTC)[reply]
O.K. with me. Fixed link (too tired: too many slashes.) AuFCL (talk) 00:08, 13 September 2015 (UTC)[reply]
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)[reply]

Toolbar closure[edit]

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) @Londonjackbooks: 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)[reply]

In a recent fit of overconfidence...[edit]

... 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)[reply]

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)[reply]
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)[reply]
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)[reply]

PDF on Archive.org -- Balderdash[edit]

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)[reply]

so neither of these links opens/downloads one .pdf or the other? -- George Orwell III (talk) 13:07, 22 November 2015 (UTC)[reply]
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)[reply]
Hi @William Maury Morris II: 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)[reply]
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)[reply]

Humble Pie[edit]

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)[reply]
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)[reply]
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)[reply]

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)[reply]
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)[reply]
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)[reply]

You are NUTS! :-) — Ineuw talk 05:02, 12 December 2015 (UTC)[reply]
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)[reply]

@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)[reply]

┌──────────────────────────┘
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)[reply]

@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)[reply]

Typo checker[edit]

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)[reply]

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)[reply]
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)[reply]

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)[reply]
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)[reply]
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)[reply]
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)[reply]

@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)[reply]
@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)[reply]
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)[reply]

┌───────────────────────┘
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)[reply]

@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)[reply]
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)[reply]

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)[reply]
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)[reply]
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)[reply]
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)[reply]
I think you should quit while you're ahead. :-) — Ineuw talk

Typo checker 2 User:Ineuw/common.js[edit]

  • List of ideas:
    • lie --> he
    • { } --> single opening or closing braces.
  • highlighting of proofread and validated pages.

Typo checker: show stopper[edit]

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)[reply]

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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]

┌─────────────────────────────────┘
 @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)[reply]

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)[reply]
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)[reply]
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)[reply]
Yes master, could you advise how to refine it? signed the Great Nana. — Ineuw talk 06:53, 29 December 2015 (UTC)[reply]
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)[reply]
Done, and thanks for this valuable tool.— Ineuw talk 17:30, 29 December 2015 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
(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))[reply]
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)[reply]
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)[reply]

┌─────────────────────────────────┘
 Thanks for the snippet, and yes I was getting many lie's — Ineuw talk 08:16, 30 December 2015 (UTC)[reply]

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)[reply]
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)[reply]
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)[reply]
Retrieved from "https://en.wikisource.org/w/index.php?title=User_talk:Ineuw/Archives/2015-12-31&oldid=6126073"