# User talk:George Orwell III

 George Orwell III (talk page)
 Note: Please use informative section titles that give some indication of the message.

## Wikisource:Scriptorium#More_on_unlocking_images

Hello.

The above discussion seems to have "died a death" during the period I was unable to participate. Is there any outcome along the lines of permitting free use of this concept in "real" works? I ask because I note the CSS being used is still being drawn from your private user namespace. Are there any plans afoot to migrate this somewhere a little more "official"?

Cheers, MODCHK (talk) 06:40, 6 June 2013 (UTC)

I'd love to make it "official" but there didn't seem to be enough positive feedback to fiddle with it further at that time. I take it you have no issues with its rendering/functionality (i.e. it is working as advertised for you)?
The concerns voiced to date "seem" to be that this, in effect, would make the entire wiki-system approach to "save resources by generating thumbnails instead of the full image" pretty much a moot approach. I'd accept that if it wasn't for the fact every thumbnail is being generated in 3 variants nowadays anyway (check the underlying html for any thumbnail of an image file if you don't believe me) and the whole 'saving resources' argument no longer seems to apply imho. Thoughts? -- George Orwell III (talk) 07:01, 6 June 2013 (UTC)
Short answer is "Yes, it seems to work perfectly well." Longer answer continues... "once I'd figured out not to be stupid and follow the examples exactly as presented!" (using Firefox if you need to know.) So please take this as one positive feedback datum.
Thats one more "works OK" - Thanks.
I'm not sure I entirely buy the "save resources" argument either, as surely this function belongs more in the world of proxies and load balancing (I am of course speaking through the hat I'm not currently wearing.)
I don't know what in blazes is going on lately with [image] files in general. PDFs no longer generate thumbnails... every thumbnail butchers HTML 5's "img srcset. the main css setting are changed from one build to the next...
I wish things would settle down into some sort of norm so I know what is "real" and what is "just passing thru". -- George Orwell III (talk) 08:06, 6 June 2013 (UTC)
I raised the matter because I caught myself proofing things like Page:Memory_(1913).djvu/50, and realised perhaps I shouldn't have been. If you don't believe this is going ahead I'd better back out the references to "freedImg2" and that would be a shame…
Yeah I wouldn't go about using or pointing to freedImg anything just yet. Until it is better discussed & accepted I don't see how we can legitimately start to apply it to real works just yet. -- George Orwell III (talk) 08:06, 6 June 2013 (UTC)
Incidentally, where is class "floatnone" sourced? I could not track that one down―Is it perhaps deliberately invalid/empty? MODCHK (talk) 07:49, 6 June 2013 (UTC)
Beats me. When you center an image, thats one of the class names used by one of the DIV containers in the "tree" of image rendering bullsh*t. All I was trying to do was mimic the existing "verbage & usage" as close as possible to better detect changes/conflicts. I would not be surprised if there was nothing defined under that class at all (would not be the first time they pulled stuff like that either.) -- George Orwell III (talk) 08:06, 6 June 2013 (UTC)
Ever more interesting. There is a write-up referring to "floatnone" at w:Wikipedia:Catalogue of CSS classes, although the pages referenced do not define it. I even searched (a slightly out-of-date!) copy of the wiki PHP code. I really don't think this thing is actually defined; even though in complete violation of normal coding practice it is in fact documented! (O.K., so I am a certified cynic. Don't act surprised.)
You'll pretty much go crazy trying to nail down every single thing like this but I can't stop myself either. Wrong is Wrong! period. <grumble grumble> -- George Orwell III (talk) 17:33, 6 June 2013 (UTC)
I also finally got around to looking into your observation regarding thumbnails being triply supplied. That srcset is just depressing, and seems sort of pointless(?) (Query: because I genuinely don't know.) Do they expect the browser to somehow cache the extra images just in case required? Beyond my realm of knowledge; but it does not look right. Perhaps this is a holdover from some feature long departed?
Its a new feature of HTML5 actually. When left to its own design, it would have solved much of the text-to-image ratio problems we have but since we like to pull a thumbnail of the original image, srcset is building its derivatives against a derivative rather than the original image file. If "we" would just get off our high wiki-horse once in awhile and treated images without this "save resources via the use of thumbnails" mentality, srcset would have at least solved the text-to-image ratios of desktop rendering compared to mobile device rendering. I doubt a properly functioning scrset would help with out with our own little bastard, dynamic layouts, however - but since normal srcset operation is pre-empted by thumbnail generation for the most part, I cannot say for sure. -- George Orwell III (talk)
Oh, and I've stripped out the temporary class from those pages I proofed earlier. Thank you for clarifying that. MODCHK (talk) 09:33, 6 June 2013 (UTC)
Bump the post up in WS:S - maybe it will re-kindle some interest? -- George Orwell III (talk) 17:33, 6 June 2013 (UTC)
Did so. Expected response. Now who was it wrote this:
:::: h-h..Hello?      Is there anybody out there?

Oh. MODCHK (talk) 22:57, 8 June 2013 (UTC)

I assume something you've changed in this template is the reason why the links for Index pages are no longer appearing side-by-side with images of the title page, yes? --EncycloPetey (talk) 00:44, 9 June 2013 (UTC)

And now the box telling where formatting information may be found is no longer appearing. --EncycloPetey (talk) 00:55, 9 June 2013 (UTC)
Sorry for the trouble - I went more than few rounds noodling this-parameter or that-value before I realized User added templates used for simple CATing is causing the TOC section to trigger even though it seemed empty in view mode.
Anyway - are you still seeing something out of whack? -- George Orwell III (talk) 01:42, 9 June 2013 (UTC)
Yes, the "Formatting information..." box only shows up on Index pages where the TOC appears on the Index page itself. If the TOC is not transcluded there (because it is too complex, e.g.), then no box appears. --EncycloPetey (talk) 01:57, 9 June 2013 (UTC)
I think I've checked every possible combination that touches the "Formatting" ambox and found the syntax that should account for all the various ways folks have been using that Remarks/TofC field to date. Let me know if you find anything contrary to the current functionality. The only caveat is when one populates that field just to add a category - it causes the table cell to expand as if normal text or the formatting pointer were in play (but that's what you get when you use the MediaWiki namespace for what really belongs in the Template namespace). -- George Orwell III (talk) 03:04, 9 June 2013 (UTC)
Hi. For what it is worth, may I suggest something along the lines of amending this fragment of MediaWiki:Proofreadpage index template:
 
{{Index talk remarks}}{{{Remarks|}}}
 to 
{{Index talk remarks}}{{-}}{{{Remarks|}}}

to address the formatting hints overlapping contents as is currently happening (e.g.) here: Index:The_European_Concert_in_the_Eastern_Question.djvu?
Regards, MODCHK (talk) 04:12, 9 June 2013 (UTC)
Well while we're at it -- the issue is really the presence of the "non-Remark" (Index talk remarks template) in the first place. ANYTHING in that TofC/remarks field other than the manual [or transcluded] text input makes co-existance problemtic. I was thinking of moving the entire notion OUT of what will eventually have to be a formal HTML input-form. So I was thinking more like this right under the heading title........

.... so it's completely out of that field and the core template for that matter.

I'm fairly confident that the MediaWiki namespace will be "reclaimed" for its intended usage sooner rather than later and crap like this will have "go" where it belongs (if it belongs) anyway - why wait? -- George Orwell III (talk) 04:25, 9 June 2013 (UTC)

That is so much beyond better. Forget I said anything at all!
B.T.W. what is a "fic" (I will regret asking, won't I)? MODCHK (talk) 04:39, 9 June 2013 (UTC)
"fic" is what you type instead of "fix" (note the location of eff and cee on your keyboard) when you are eating a slice of pizza in one hand and playing keyboard coder with the other. My baf. :-) -- George Orwell III (talk) 04:46, 9 June 2013 (UTC)
Worf a larf anyway! Hope you enjoyed your meal. MODCHK (talk) 05:03, 9 June 2013 (UTC)
Any ideas on what to do about Template:index validated date?
Same problem - folks treating a simple form field like a big ol' textarea box because the current MediaWiki namespace implementation as a faux template won't allow you to add things like categories etc. as one normally would. When its present, it forces the parent table cell to a width of 30% even though no remark-text is actually being displayed (EXAMPLE). The various icon-linked tools were originally put in the "same" container because it was understood they would be better positioned at some point down the road (currently scripted to force them up top). It doesn't bother me much - but I know somebody is going to bring it up sooner or later.... ideas? -- George Orwell III (talk) 05:15, 9 June 2013 (UTC)
No useful ideas unfortunately. How "permanent" do you think the "faux template" solution is going to be?
I don't know much about the ins & outs of today's coding nevermind the WikiCode itself... but I can still differentiate lame-o patch-work from serious revisions. I don't know who or what set the fire under somebody's ass over on the developer side but the last ~two wmf releases had oddles and oddles of additions/changes to the core "MediaWiki" files after 4 or 5 years + of being almost completely ignored. BTW, these are the "default" definitions, etc. that in effect make up the MediaWiki namespace (most of which we don't really "see" both literally as well as in action unless you create (i.e. change one of the pre-defined defaults) with a new local file. Based on that activity (& history) I'm guessing all the no-nos we've been getting away with re: Proofread & the MW namespace in particular, will have to be [re]addressed before we know it.
Not sure where this will lead, but is considering adding another field to MediaWiki:Proofreadpage_index_data_config going to be too big a can of worms? MODCHK (talk) 05:45, 9 June 2013 (UTC)
Imho, that entire "butcherization" the basics for the sake of expediency (i.e. was part of the original push deployment involving dynamic layouts before components were really done & tested) will be tossed eventually. It cannot sustain the changes to come to both in the new formal standards as well the old ones it managed it skirt so far. I wouldn't bother with most of the current proofreading extension (unless you know how to move it to Lua that is!)
This stupid faux-template thing should have been a standard form generated like all the other standard forms you are already familair with. For example : Copy & paste the following to a .txt file and save it; close then rename it from .txt to .htm : Now open as you normally would.
<!DOCTYPE html>
<html lang="en" dir="ltr" class="ws-client">
<title>Ripped the only way I know how</title>
<body>
<fieldset id="editControls-editform"><legend>Edit controls</legend>
<div class='editOptions'>
<span class="mw-summary" id="wpSummaryLabel"><label for="wpSummary">Summary:</label></span>&#160;<input class="mw-summary" id="wpSummary" maxlength="200" tabindex="1" size="60" spellcheck="true" title="Enter a short summary [b]" accesskey="b" name="wpSummary" />&#160;<span class='editCheckboxes'><input name="wpMinoredit" type="checkbox" value="1" tabindex="3" accesskey="i" id="wpMinoredit" />&#160;<label for='wpMinoredit' id='mw-editpage-minoredit' title="Mark this as a minor edit [i]">This is a minor edit</label>
</div>
<div id="editpage-copywarn">
<hr style="margin: 1ex 1ex 1ex 1ex;"/>
<hr style="margin: 1ex 1ex 1ex 1ex;"/>
</div>
<div class='editButtons' style='text-align:center;'>
<input id="wpSave" name="wpSave" type="submit" tabindex="5" value="Save page" accesskey="s" title="Save your changes [s]" />&#160;<input id="wpPreview" name="wpPreview" type="submit" tabindex="6" value="Show preview" accesskey="p" title="Preview your changes, please use this before saving! [p]" />&#160;<input id="wpDiff" name="wpDiff" type="submit" tabindex="7" value="Show changes" accesskey="v" title="Show which changes you made to the text [v]" />&#160;&#160;<!--
--><span class='cancelLink'><a href="/wiki/Template:Potus-eo" title="Template:Potus-eo" id="mw-editform-cancel">Cancel</a> | </span><!--
--><span class='editHelp'><a target="helpwindow" href="/wiki/Help:Editing_Wikisource">Editing help</a> (opens in new window)</span>
</div><!-- editButtons -->
</div><!-- editOptions -->
</fieldset>

<fieldset id="templatesandbox-editform"><legend>Preview page with this template</legend><span class="mw-templatesandbox-page" id="wpTemplateSandboxPageLabel"><label for="wpTemplateSandboxPage">Page title:</label></span>&#160;<input id="wpTemplateSandboxPage" tabindex="8" size="60" spellcheck="true" name="wpTemplateSandboxPage" /><input id="wpTemplateSandboxPreview" name="wpTemplateSandboxPreview" type="submit" tabindex="9" value="Show page preview with template draft" />
</fieldset>
<div class="visualClear"></div>
</body>
</html>

Look Familar? Well I think you get the idea regardless - all of this jazz from book templates, to hidden micro/metadata to faux templates should have been nothing more than the manipulation of a standard core HTML form with the User provided inputs.
Anyway - my POV is not to build anything more on top of this poor foundation & I'll leave the tail-chasing for the experts. Sorry. -- George Orwell III (talk) 06:44, 9 June 2013 (UTC)
Please note: I am not ignoring this. (First lie; in fact I really am.) In point of detail I am not quite sure why anybody should be surprised HTML can directly create the same effect that .. HTML generated by wiki .. can. Am I being dumb or too sharp, I genuinely cannot tell. (Hint: always assume the former.) At least I get the tail-chasing pointlessness, point. MODCHK (talk) 02:20, 11 June 2013 (UTC)

## rfc:inline style discussion ...

You are aware of my general iggorance on such matters as indepth style stuff, however, the discussion mw:Requests for comment/Deprecating inline styles may be of interest. I have dropped some comment with my limited understanding. — billinghurst sDrewth 13:30, 12 June 2013 (UTC)

This is one of those things best left to its own devices. The worst thing I can do is acknowledge that far-fetched premise by voicing an opinion - any opinion. The problem lies with mobile rendering - primarily with HTML tables (just like we have [other] issues with tables here on WS almost daily). You were right to say it was "sledgehammer to walnut" approach - the real solution is to enable colgroups and rowgroups for tables in the wikicode so it mirrors the current functionality found in HTML where a given parameter or parameters are set once but are applied to all the cells in a given table column or table row.

The whole reason we have the current column-by-column, row-by-row or even cell-by-cell christmas tree of repetative inline stylings is thanks almost entirely to the lack of this ability to utilize colgroup / rowgroup /tbody / etc. under the wikicode.

Talk about a solution in search of a problem - sheesh! scoped styles aren't even supported by any major browsers yet the last I checked! So no thanks, I'll leave the sure-to-go-nowhere debate to the usual keyboard commandos bent on solving thier own issues by imposing changes on others. -- George Orwell III (talk) 00:23, 15 June 2013 (UTC)

## Inherit in {{font-size90%/s}}

Hi. Can you kindly revive this cat and point me to the inherit property of this template in regard to the top and bottom padding? I am using both templates {{font-size90%}} and {{font-size90%/s}} in context. I set the padding in {{font-size90%}} to .6em to enhance paragraph separation from normal text. Then, I looked at the code of {{fs90/s}} and instead of "padding", there was "margin" parameter and the value was "inherit". I also noticed that the template is of class="fslhInherit", which I haven’t found anywhere, including in the MediaWiki:Common.css.

Common.css was getting too long and got split up (think sub-pages here) in order to start pruning the junk from the useful. You should now find your class definition in MediaWiki:Common.css/Tweaks.css along with most every other WS specific "oddity".

Finally, I also tried to add a documentation page (a modified version of the {{fs90}} relevant to {{font-size90%/s}}), and messed it up. - It should have been font-size90%/s/doc. Can you please help me correct this as well. Many thanks. — Ineuw talk 01:26, 15 June 2013 (UTC)

Think I got that worked out.... Let me know. -- George Orwell III (talk) 02:06, 15 June 2013 (UTC)
Thanks. Everything is clear. I found the info and would it be OK if I change the {{fs90/s}} template "padding" parameters from "inherit" to .6em? That would match the other template. — Ineuw talk 03:44, 15 June 2013 (UTC)
Think of padding as an inward buffer, the space between content and its boundary, and margins as a force field between a boundary and the environment. Typically, paragraphs <p> have margins not padding (the wikicode "default" is margin: .4em 0 .5em 0; for example).

There's no harm in applying padding other than in some cases where text alignment is set to justify. Of course if you're going to wrap several paragraphs under a single DIV, fiddling with the padding might be worthwhile but you'd need to be consistent throughout the work if you want to avoid mis-matched margins from one section to the next. -- George Orwell III (talk) 04:24, 15 June 2013 (UTC)

Thanks for the excellent explanation. . . . as usual. — Ineuw talk 08:22, 15 June 2013 (UTC)
Anytime. Good luck. -- George Orwell III (talk) 19:38, 15 June 2013 (UTC)

## Five children

Hi George, thanks a lot for replacing this file. Didn't know what to do with it, apart from doing the OCR manually on every page. Sincerely—Clockery Fairfield (talk·contribs) 04:26, 15 June 2013 (UTC)

## Thanks

George, thanks for this:

• George Orwell III (Talk | contribs) deleted page Index:File:Atreatisehumann00selbgoog.djvu ‎(WS:CSD G4 - Redundant: content was named in error. See Index:Atreatisehumann00selbgoog.djvu instead...' (and the only contributor was 'Peteforsyth'))

I regret not flagging that for deletion myself, I got a bit confused and forgot to clean up after myself. I think the entire file may be redundant actually, as there is also this file:

But, I'm not sure how to evaluate the relative scan quality. Any suggestions would be greatly appreciated! -Pete (talk) 17:21, 15 June 2013 (UTC)

Don't worry about missing the deletion request - the double-namespace would have caught someone's eye before long either way.
As far as inspecting DjVu files go - in my expierence there is no real easy way. The online book reader at Internet Archive is nearly as clunky as the viewer available on our main File: pages are. I find the only sure way to get at inspecting the nuts and bolts of any DjVu file is to use a 3rd party program called DjVuLibre. It can be configured as a browser plugin so it works much like Adobe Reader does for online .PDF files or you can use it as a stand-alone local program (which requires you to download the .DjVu in full to view it).

I should also mention that I'm pretty much trapped into using IE as my browser and Windoze as my OS so there may be better alternatives to DjVuLibre out there for other platforms and/or browsers. If you can't figure it out your own, I'm sure reaching out on the Scriptorium / Help section will get you pointed in the right direction. -- George Orwell III (talk) 19:51, 15 June 2013 (UTC)

## "When used for wrappers or as containers, DIVs must start and end on their own lines."

Hello. I saw your comment (reproduced above) here; and in the past Hesperian has made similar observations. Would you please be so kind as to expand upon this for the thickos (i.e. me)?

I can only assume the empty lines are of significance to the mediawiki parser, as I am pretty certain HTML is simply newline agnostic under these particular circumstances, and frankly the context of such observations as your/Hesperians leaves me a trifle confused.

To start with: when can a <div> ever be considered not to be a wrapper/container?

Regards, MODCHK (talk) 00:01, 16 June 2013 (UTC)

Well for "real" starters - I don't consider the wikicode handling of html as legitimate. Because of that POV, I always think and write in terms of the "current" html specification before anything else is even remotely considered or becomes factored. In short, I deal with the wikicode whereas most other folks believe they are utilizing it.

Second, I come from the old-school days of the internet so I'm biased in the old-school ways of doing things. Not much has changed when it comes to the use of Divs (&spans) however - those who once lived by the old standards seem to have been overwhelmed by the latest & greatest improvements and forgot the basics while newbies never get the chance to learn the proper foundations from jump...

A DIV element tag is today as it has always been and forever will be...

... and my favorite, especially when it comes to usage around here,
A div is placed around a group of block level elements. A span wraps a group of inline elements or (most usually) plain text. The key word is “group”: if a div wraps just one block-level element, or a span just one inline element, it's being used unnecessarily.
So the take-away is not that whatever browser you're using doesn't strictly treat divs like they are suppose to according to the specification or the fact that coupled with the illegitimate wikicode you can get away with making blocks act inline or vise-versa by squeezing div tags right up against each other or whatever - its the fact that now you know better and if you still decide not to adhere to what is clearly at least a "best practice" if not an universal rule per the spec., you just might be a galactic jerk or something.

In a nutshell, if the use of a div tag is unavoidable AND you find yourself with the need to produce the behavior of the tag when they do not open and close on their own lines, simply change/add the Display: attribute to match...

display:block; (the default for divs) to display:inline; or display:inline-block;
... as needed or as dictated.
The concern with FreedImg specifically is the not-so-reliable way the wikicode handles the inheriting of parameters. IMG is by default [display:]inline so the appropriate element (or parent if you prefer) to inherit some value or setting from would typically be a block element. While in theory the IMG could be "wrapped" by another inline element (such as A or SPAN) and then technically that becomes IMG's parent by some views, I find that to be an unreliable way of getting inherit to "work" - be it under the wikicode or not. It is akin in results to what I call "skipping a generation".

If you think of the Parent ~ Child element relationship as a real-world family tree, any offspring (child element; IMG in this case) typically has at least one true parent to answer to (parent element; ???). Now you'd think any block element would satisfy the parent element portion just fine but I find the closest block element in the document tree (the closest blood relation) works best when it comes to inheriting values. In theory, a DIV should behave as well a P would in this scenario since they are both block elements; yet in my experience the DIV seems too far removed (the "grandfather") compared to when using P (the "father"). I find using P works in more situations reliably than using DIV did so I go with that child (IMG, SPAN) to parent-father (P) to parent-grandfather (DIV) scheme (i.e. not 'skipping a generation') to insure inherit works as best as I know how in FreedImg. That's why I'm such a d*ck about keeping it as "pure" as possible or ask for proper div tag usage and so on in FreeImg's case.

Unfortunately most of the time we templatize around here by going DIV right to SPAN and forget P altogether. Take that and the wacky inline-or-not block DIV usage at work in most cases and we have one big non-compliant mess imo. Nobody seems to mind (yet) because it renders just fine at the end of the day - well I refuse to follow a lead I know to be faulty and that was in large part behind the edit you brought forward. Hope that helps. -- George Orwell III (talk) 03:01, 16 June 2013 (UTC)

Short answer: Thanks, it all helps.
Believe me I did not ask to explicitly provoke you; I asked because I want to understand. I consider myself in the class you describe as "newbies [who] never get the chance to learn the proper foundations from jump" in this area, so if that allows me to reserve the category of stellar jerk so be it. (I should never aspire to being a galactic-level one.)
Besides, if I really wanted to annoy you, I know (and I expect you ought to do so too) that I could do so far more efficiently than this. I do not anticipate ever needing to prove it.
All lessons gratefully received. Please consider me simply a slow student. I am sure this will take time to sink in. MODCHK (talk) 06:17, 16 June 2013 (UTC)
Frumpy-grumpy me aside - in general I don't mind being poked or probed on stuff like this. It is the best way to re-educate myself on such matters and frequently forces an internal review of sorts as well. Sometimes the timing sucks is all.... and that is probably why I'm overly intense one second and suddenly absent the next to most folks. Pay no mind & feel free to ask away. -- George Orwell III (talk) 06:57, 16 June 2013 (UTC)
In fact the only term you used I take serious exception to was "best practice." In my neck of the woods this is know-nothing M.B.A.-speak meaning: "just barely good enough to avoid getting me shouted at." I suspect you have slightly higher standards than that. MODCHK (talk) 09:10, 16 June 2013 (UTC)

### Re: Shameless Promotion

So―that hyphen really was required, wasn't it? Here endeth the teasing. Well done. MODCHK (talk) 01:50, 24 June 2013 (UTC)

Oopsies - must have clipped the negative value somehow in a rush to copy & paste the caption text & it's values... or maybe comparing hanging-indents to normal indents (I really don't know why I did that).
Thanks for pointing it out but in the future you should feel free to restore stuff as clear a mistake as that was asap on your to avoid possible confusion, etc.
and as a FYI - hanging-indents would not "margin-left" in the previous {{{Caption}}} string unless I added a span element set to display:inline-block; under the existing paragraph tag & added the text-indent & margin-left settings there instead.

This "inability" to manipulate the caption paragraph to produce a hanging indent makes sense since the Caption Paragraph is technically still within the primary div container's "control" where margin-right & margin-left are set to auto. Making the span an inline-block lets us circumvent the primary div container's overall centering thanks to auto and makes it a "true child" of the paragraph tag instead (hope that made sense). -- George Orwell III (talk) 02:14, 24 June 2013 (UTC)<?p>

## Index:The Galaxy (New York, Sheldon & Co.) Volume 24 (1877).djvu

Presumptuously but realistically assuming this will fall to you. Apologies for making this mess; there are a couple of articles in there that I really want to transcribe, and I didn't notice the missing pages until I had uploaded. Hoping you won't mind saving the day too much. Hesperian 10:08, 19 June 2013 (UTC)

Not a problem - should be able to get to it today/tonight. -- George Orwell III (talk) 16:10, 19 June 2013 (UTC)
Done - other than the lack of the faux faded-paper background, the patches seem as good as the rest of the pages. I added a text-layer for all 4 pages too. Hope that will do; let me know either way. -- George Orwell III (talk) 19:40, 19 June 2013 (UTC)
Thankyou! :-) Hesperian 02:43, 20 June 2013 (UTC)

There is also a problem here that could be fixed with this moved below; however I'm not intending to work on that article so not sure if it is something you would want to fix on principle, or leave for later.... Cheers, Hesperian 04:45, 26 June 2013 (UTC)

Of course I'll patch it somepoint this week now that I know about it... but I'm not sure that I should - are you done checking the rest of the pages that you won't be transcribing ever for scan integrity yet? or should I wait another week or so and do all the corrections at once? Its a good thing I just deleted all of last week's adventures in corrections just yesterday or I might have too much time on my hands to dwell on that. sarcasm off
Seriously - there's nothing more annoying to me than having to go back over my own work; lets try to avoid any more unforced errors if we can - I make more than enough of them on my own to fill everybody's online quota! -- George Orwell III (talk) 05:30, 26 June 2013 (UTC)
Aw. :-( In addition to cutting me to the quick, your sarcasm has had its desired effect: I have flipped through the volume and had a quick look at every page; and I will do so in future before asking you to patch something for me.
There is another problem at
There is also a tear on pages
but I think we can get away without patching those ones.
Sorry and thanks.
Hesperian 06:11, 26 June 2013 (UTC)
Easy mon. (& I can't believe that 'lesson' actually paid off!) -- George Orwell III (talk) 07:23, 26 June 2013 (UTC)

Hi, a new user has asked for help with uploading a file for the US edition of The Island of Doctor Moreau, so that we can replace our unsourced version. On looking at the IA list, I'm confused by the dates with the DjVu in 2006 and the pdf in 2011. Is this a time when I should simply grab the pdf? Or should it be re-derived? Beeswaxcandle (talk) 21:56, 19 June 2013 (UTC)

if you look at that identifier's history, you can see the current PDF is indeed a product of a later derive process (1.6 years ago) than the one that produced the current DjVu file (6.5 years ago).
That said, the rule of thumb when it comes to selecting a PDF over a DjVu is to go with the PDF only if the PDF was "born digital". Since most, if not all, of the uploaded PDFs on IA are of the scanned-then-digitized (i.e. not "born digital"), we typically get a better text layer from the IA derived DjVu than found in even a somewhat more recent PDF file. The caveat for this rule of thumb is when the somewhat more recently created PDF file happens to be a fixed, more complete, etc. .PDF compared to the state the original .PDF was (now long gone in most instances). Its hard to determine if this caveat applies since most uploaders do not bother to update the file's info so we are pretty much in the dark when it comes having a superior PDF in play or not - you'd have to download both and compare completeness, quality and the like.
Now in this specific case, the DjVu is almost 7 years old. This usually means a supeerior DjVu can be reproduced by taking the current PDF and re-deriving the whole thing as if it was a brand new indentifier/upload. On the other hand, you can use the current DjVu and hope any flaws within it can be overcome with some extra effort on our part. It might even be just as good as a new DjVu file would be.
Personally I would create a new DjVu using their latest PDF since its only about ~8M in size OR you can try to email someone at IA to re-derive the existing folder / files, creating a fresh DjVu in the process (I haven't had much luck with the email route fwiw). Hope that helps. -- George Orwell III (talk) 23:15, 19 June 2013 (UTC)
Definitely far quicker to do a re-upload then wait around for IA. Took about an hour all up. Beeswaxcandle (talk) 08:42, 20 June 2013 (UTC)

## A minor {{FI}} centering issue

Hi. I found that the {{FI}} template is offset by about 5 pixels to the right of center. Inserted my old image display "template" below the new and checked it with the Pixelruler. It’s not a big deal but my eye is trained to notice such differences and noticed it. Can you please take a look at this page? at your convenience? Thanks.— Ineuw talk 09:06, 26 June 2013 (UTC)

OK, check it now. Padding is a tenth of that it was before, but I can't guarantee that will remain the default until more and and more folks start to adopt/debug it. And I have to leave FreedImg with a little somethin' somethin' just in case; never know what crazy thing will come up in the future where a bit of space could be useful to exploit/resolve somebody's issue. -- George Orwell III (talk) 09:29, 26 June 2013 (UTC)
I was OK with it if you were. Only meant to bring it to your attention because offset from center exist in other templates as well and suspected that it may be the main CSS layout of the Page: proofreading layout margin is the culprit.— Ineuw talk 20:23, 26 June 2013 (UTC)
Oh. :| I thought it was problem.
You see, the "settings" for FreedImg are actually taken from the normal image thumbnail settings (because those are the only kind that have a "caption" box & a light border but you rarely see them all together & centered without the alt icon on the bottom right by design. So you were right to bring it up but it wasn't exactly an "unknown" factor.
Early on - I was thinking to mirror as much of the existing frame, frameless and thumb usage as I could in FreedImg so folks would be able to swap in or out without too much trouble or too many changes in the final rendering. That was always too much to hope for - the only "harm" you've done is remind me not to go crazy with mirroring what amounts to limitations unfairly imposed by the wikicode[rs] in the first place. So keep those observations coming as you discover them. Prost. -- George Orwell III (talk) 20:53, 26 June 2013 (UTC)

## Page move leaving no redirect

In the future, please check to make sure your deletion of a talk page doesn't leave any broken links. - dcljr (talk) 23:30, 27 June 2013 (UTC)

Wikisource Policy is to amend the source page to point to the current main Talk page (which I was going to do after I finished replacing the text). We don't pad our numbers with dozens of pointless redirects especially when it come to talk pages. -- George Orwell III (talk) 23:43, 27 June 2013 (UTC)

## Windsor talk pages

Hi. Thanks for everything you've done with United States v. Windsor, especially for the cleaned-up PDF. Just a quick question about the templates you added to the talk pages... I don't quite get the "contributors" and "level of progress" stuff. The three users you list as "contributors" are all inactive, and "level of progress" seems redundant to the ProofreadPage progress marker. Is there something I'm missing here? Thanks. — PinkAmpers&(Je vous invite à me parler) 10:09, 1 July 2013 (UTC)

Yeah, that's the gov't for you - wasting 2 and a half inches in margins all around. I couldn't read a thing unless I entered edit mode so I whacked that in Acrobat and re uploaded it.
As for the TextInfo Template, I just copied and pasted one from another case opinion along with the USSC banner and it seems I forgot to clear the previous case's names out - Sorry.

The Progress part is a deprecated left-over from another era & only makes sense in 25, 50, 75 & 100% increments anyway. You can ignore it or set it however you wish - the real status that is currently tracked, etc. is the Proofreading color coded status from the Page: namespace. The banner is really added so the Project (if it ever comes back to life again) can track USSC discussions easier. -- George Orwell III (talk) 10:25, 1 July 2013 (UTC)

## Applying FreedImg to <score>

Hi. What can I say? I am beyond mortified. This approach simply did not start to occur to me. Thank you.

I shall go away and swear at myself for a few hours! MODCHK (talk) 05:46, 30 June 2013 (UTC)

You lot can be so kind. I break {{FI}} for…(checks)… over 14 hours and nobody even yells at me? Maybe you were all doubled over in laughter waiting for me to realise how stupid I can be… MODCHK (talk) 06:52, 2 July 2013 (UTC)
Sorry, was too busy elsewhere explaining away why the assertions of Obama and his "923 Executive Orders" usurping the Constitution somehow is complete right-wing authoritarian nonsense.

Besides, you almost had it right - its not | default = but | #default = (you left out the number sign); restored w/proper syntax. -- George Orwell III (talk) 08:51, 2 July 2013 (UTC)

Or, indeed nothing at all. However, thanks for making the fix "official." I hope you don't mind my attempt to stretch this (FI) rubber band as far as possible before it (really) breaks. [WRT authoritarian nonsense I can think of a fair few responses, none of which extend to more than two words. Polite ones? That's quite a bit harder...] MODCHK (talk) 10:03, 2 July 2013 (UTC)
I'm rather irritatingly over-confident that the FI core (with the single primary DIV container in "control") can handle anything you throw at it - it's when people try re-impose some degree of the existing image-file limitations or start trying float an image in the middle of a block of text without adding the needed additional DIV containers/wrappers to compensate/accommodate for those situations is where things start to go off the rail.

The math and score outputs are just .png images compiled on the fly so they aren't that much different (if it all) than a static .png file hosted on Commons. Not much possible harm there. -- George Orwell III (talk) 10:42, 2 July 2013 (UTC)

Oops. Re: "or start trying float an image in the middle of a block of text...", I don't think I'm guilty of that one―though I must admit I'd love to know how the trick is legitimately achieved. I assume you mean with text flowing down both sides of the image? I did not think it was possible without use of a table.
Yes, I hang my head over the max-/min- width debacle. I still think there is (some) mileage; but now is not the time or place.
I think you have every reason to be proud of your "FI" core effort. Also, don't forget that without irritation, no pearls! MODCHK (talk) 11:32, 2 July 2013 (UTC)

### Applying FreedImg to [itex]

Just had a thought (not that I'm s--l--o--w or anything… apologies in advance; though short, the following thought bubble is a bit of a twenty-questions deal, although you might be able to dismiss most of them as non-productive):

FI does not work so well if the user selects Preference: Math/MathJax instead of "Always render PNG". To be quite frank I don't pretend to understand how the MathJax option performs it's trick; however it certainly does not produce an <img> tag for the dynimg.css: p.freedImg > img cascade to operate on. (And there's a bit of a potential gotcha with the Math/PNG option as well to think about: [itex] generates <img class="tex"… whereas <score> generates its img tag classless. Maybe I've just been lucky so far?) MODCHK (talk) 19:52, 2 July 2013 (UTC)

Just document that tid-bit. I'm not going to bend over backwards for anything other than the default settings/preferences in place for Users. -- George Orwell III (talk) 23:26, 2 July 2013 (UTC)
Second part first: Fair enough. I consider I have just done so, and if anything actually breaks―which at present I do not consider it does so―will copy it to a more prominent location and think about dressing it up, then. MODCHK (talk) 00:28, 3 July 2013 (UTC)
O.K. I weakened and went completely mad―extra (slightly loopy) examples and warning now here: {{FreedImg/doc}}. Please correct the deliberite eroors remaning at yor lesure. (If you feel so inclined, of course.) MODCHK (talk) 03:06, 3 July 2013 (UTC)
Note:
I didn't notice the other day that you used {{{1}}} as a parameter for the 'switch' statement. I'm expecting the full implementation of the TemplateData extension sooner rather than later and using numbered aliases seems to mess with the soon-afterwards ability to pull template values easily. I modified the FreedImg template & documentation accordingly. Please review it. -- George Orwell III (talk) 02:35, 4 July 2013 (UTC)
As they say in the Classics: /(Damn)+/. When I was being disrespectful to you above earlier I did not for a second really think I was creating so much work for you. Worse yet, I was even tangentially aware of the TemplateData drive, yet did not for a second think of this implication. There are a lot of templates with positional parameters out there as you are well aware. Visual Edit is going to cause nightmares, even if this is only one of the knock-on effects.
I have reviewed your changes and completely concur with what you have done. "file=(something which is not remotely a file to the user)" reads strangely, but technically I have no problems whatsoever.
And the slightly working crazy examples were semi-deliberate to demonstrate that even mildly daft things still work, although I agree with your typical real-world values change.
Once more sorry for having created the extra work. I really had no intention of so doing. ⁅(Road: Hell, Intentions: Good, Paving) ⇒ Material Excess, No?⁆ MODCHK (talk) 07:59, 4 July 2013 (UTC)
I wish you'd relax a bit - your input is valued and it is not "extra work" when differing POV's are being tested/rolled-out against each other; its a normal part of the development process the way I see it. We still might go back to using {{{1}}} just so there is a way to differentiate static image file inputs from the compiled-on-the-fly image file inputs. I can't be sure either way until the TemplateData extension is better developed to a point that shows us how exactly value extraction will be accomplished. So relax; no harm; no foul. -- George Orwell III (talk) 08:15, 4 July 2013 (UTC)
Relax? This is me relaxed. Why I haven't even bitten the head off so much as one idiot today. (Why is the dog suddenly looking nervous?)
Rants don't count though, do they? MODCHK (talk) 08:42, 4 July 2013 (UTC)

Q. re: "file=(something which is not remotely a file to the user)" reads strangely, but technically...

so we should drop the | type = altogether and go with a choice of | file = , | score = , or | math = to distinguish one from the others? -- George Orwell III (talk) 08:26, 4 July 2013 (UTC)
Two things predicate against this: 1. No idea if all the bases have been covered. Somebody is sure to come up with a new image-generating extension just after everyone thinks the template has bedded down and forgotten what to edit, and 2. ideally the template simply does not need to know how to handle each case, so long as the CSS hierarchy is obeyed with a usable <img> to operate on.
The presence of any amount of special case handling creates the expectation that all cases will be handled…a lesson I (should have) learnt the hard way with the {{stanza}} debacle… (Did I just come up with a re-expression of the "Cruel to be kind" gambit? MODCHK (talk) 08:42, 4 July 2013 (UTC)
OK - I'll leave it alone. Thanks. Hopefully if the User bothers to read the template documentation and sees the examples at work, there won't be all that much confusion about what to input & where. -- George Orwell III (talk) 08:50, 4 July 2013 (UTC)
I should make clear I'm not ruling your suggestion out totally (and I quite glossed over the "drop the type=" bit―that was accidental.) Do whatever is simplest and works and I'll do what I can to help maintain it. My core point was to try not to create expectations that will be impossible to satisfactorily deliver.
And in any case, where did you get this crazy idea any self-respecting User ever "bothers to read...documentation and sees the examples"? I've never even paid a visit to such a planet. MODCHK (talk) 11:23, 4 July 2013 (UTC)

## {{Paragraph tag}}?

I stumbled across {{P}} by complete accident, and consider the concept a complete winner (although I can foresee a few detractors… say-no-more.) Before I go completely overboard (see “Relax” commentary above) if by using this I am committing you to a concept you no longer wish to pursue, please let me know.

Regards, MODCHK (talk) 00:52, 7 July 2013 (UTC)

I never really "finished" working it up - and tested it even less than that. I saw your changes to the /parse sub-page the other day and moved it up near the top of my so-called "to-do" list because I remembered at one point I thought it might have the potential to squeeze out some of the current DIV nonsense/abuse found in our current editing practices. (wishful thinking)
In addition, you might want to toy with the H1 thru H6 tags with the class set to usei ( h3 class="usei" ) instead of forcing a paragraph tag to behave like a header tag. You'll still need to NOTOC the page in question but it won't create the usual '' section link to the right. Recovering these standard html header tags would solve dozens if not hundreds of the file format conversion issues we have (i.e. the whole Book making fiasco for starters). The rest of the planet starts with the assumption our document tree follows the norm - or in other words - having a header tag in place for the common chapter title or section header. Because we DIV everything from simple letter positioning to entire page layouts, the conversion routines for other file formats out there can't tell the difference between lists, paragraphs or section headings in our text content. Anyway, now at least you know about it/them.
Oh - & I fixed your Chart template thingy so your User: page should mirror the one on WikiPedia now as well. -- George Orwell III (talk) 01:51, 7 July 2013 (UTC)
You, sir, are an absolute «expletive-deleted» genius. I've only had that “tease” entry up for about…seven…months now without anybody reacting… let alone actually «fixing» the damned thing! MODCHK (talk) 03:06, 7 July 2013 (UTC)
I have been holding off making the documentation of {{p}} “visible” (ala {{ts}}) in case you wanted to keep it “quiet”. As I indicated before I like the concept, but―as my lawyer(s) keep(s) on telling me―I have been wrong before; and will likely be so again… MODCHK (talk) 03:06, 7 July 2013 (UTC)

### m0

Just saw …zero-out all 4 possibilites for ' m0 ' to mean… and yes: that is what I should have done. Once more Uncle George pulls me out the bottomless pit of “doesn’t my browser do things in a standard fashion?” Please keep an eye out for these indiscretions; and I shall similarly attempt not to make them! Cheers, MODCHK (talk) 19:21, 12 July 2013 (UTC)

### fsin

Hello.

I thought I'd run this by you before I made too much of a fool of myself about it. I realised I had been making fair use of {{smaller block}} without putting any thought into what the template actually generated… turns out to be nearly identical to {{p|fs85}} (a.k.a. sm85).

However, there is a small burr in the mix: at least in my browser, fsin (font-size:inherit) doesn't appear to... well... inherit (see Page:Gems of Chinese literature (1922).djvu/26.) Have I simply stumbled across a "future feature", or is Firefox perhaps not currently pulling its HTML5 weight?

Regards, MODCHK (talk) 11:05, 19 July 2013 (UTC)

Most "inherits" are not automatic nor typically the default behavior for HTML elements. Because most elements lack the normal 'grand-parent', 'parent', 'sibling', and 'child' relationship(s) around here, you'd probably need to either a.) experiment with the most simple of DIVs, Ps and SPANs to see what's possible & actually works; or (when you've become frustrated with that going in circles) b.) you need to force the behavior by assigning it a CSS definition with a priority of ! important and then use the element with the defined class in your template, etc.(FI is basically b.) plus the redundant equivalents again as style= to make sure the wikicode doesn't somehow remove the behavior during rendering). -- George Orwell III (talk) 11:57, 19 July 2013 (UTC)
Thank you very much for so patiently clarifying that. Upon further reflection I realised I was expecting a sibling precedent to have been taken, which is probably unreasonable at the best of times! In short, I have come to the conclusion that treating every individual paragraph styling as local to itself might be very much the safest choice. Cheers, MODCHK (talk) 21:20, 19 July 2013 (UTC)
Oh most surely yes - treating each paragraph with it's own set of stylings is the way I would go. The application of "inherit" for FI here on WS (or more correctly - under the Wikicode) is really the exception to all the expected norms re: inherit. If you are dealing with say, less than a dozen or more paragraphs in series, it doesn't make any sense to try to invoke any kind of cascade inheriting for the same reasons on behavior in relation to "blood relatives" as I gave before in the above - too much involved to get it to work under the Wikicode. -- George Orwell III (talk) 21:44, 19 July 2013 (UTC)

## {{FI}} and using values greater than 100%

I like to use a portrait oriented page width for images as 100%, and then fractions of it as they appear in print; this was done in the past by using "frameless" and "upright" parameters in the Image file. In continuing this logic (bare with me as I know this isn't necessarily the intent of function for this template) I've been led to want to use a larger percentage for landscape oriented images. In the "frameless" world, I would set upright to 1.4, or 140% of the defaulted frameless width setting. I was hoping to continue using this way of sizing in {{FI}}, or more specifically ((tl|FI/400}}. If you look at Brisbane from the air you'll see that the extra 40% is shifted to the right instead of centering, I assume because of the padding involved. Is there any way to resolve this, or am I totally out of bounds on this one? - Theornamentalist (talk) 03:33, 8 July 2013 (UTC)

Nevermind, I added an option in {{FI/400}}. - Theornamentalist (talk) 23:51, 9 July 2013 (UTC)
Thanks for cleaning up the template. However, the margin-right margin-left is defaulting the image to either the left or the right of the 400px container, not absolutely to the left or right. Check out The Lion, and other tales#1, the "L" was before all the way to the left, now it is only in the left of the container. I can resolve that (I think) with how I had it prior, but it may have not been the proper way to do so, can you check that out? - Theornamentalist (talk) 23:43, 11 July 2013 (UTC)
The real issue was that you added the same float named parameter to your secondary "400" DIV container when float was already in use in the main template. Why you insist on using your big wide "400" FI variant for tiny little first-letter only usage was throwing me off as a result. I removed the redundant float, left the default to zero margins when a "float" is present (what that accomplishes exactly I haven't a clue), and now you float the PRIMARY div container within your secondary container as designed. To float your secondary DIV container, you probably need to make your template use some other named parameter to invoke floating outside of the primary FI template's settings. -- George Orwell III (talk) 23:59, 11 July 2013 (UTC)
The reason for using FI for that, as opposed to DI or a hardcoded width, is so when the browser width is reduced the images all remain proportional. - Theornamentalist (talk) 00:14, 12 July 2013 (UTC)
Maybe on your particular monitor, with your particular settings & your particular browser it seems to remain proportional but [at least here @ home] rendering pretty much starts at 34px regardless of the % set and staggers up to 500-some-odd px as I cycle through my browser's "zoom" and/or font settings. You seem to be mixing-up the secondary DIV's possibilities with the set parameters of the Primary DIV in the core of FI. This is why forcing margin left or right had no bearing on your secondary DIV (those are primary DIV container settings and, until moments ago, were absent from the list of parameters availiable to FI/400 anyway), and making them fixed for "none" (or more correctly "zero" - 0.0em, 0px, 0, ...) or "auto" if the float parameter present or not results in one or the other being locked-in (i.e. not adjustable). -- George Orwell III (talk) 00:33, 12 July 2013 (UTC)
Wow, you bottom out at default on your PC? The point was for that to be the case on something like a tablet or mobile device, but sheesh, not on a PC. Your browser is really less than 300px width? Cos at 15% width, I was hoping in general (not on my wide screen) it'd be at ~120 or 150 or something. - Theornamentalist (talk) 01:20, 12 July 2013 (UTC)
No silly - that's whereabout it starts for certain images when I shrink (click-hold & drag left) the right- boundary of my browser window usually until a scroll bar appears at the bottom of the browser window, then incrementally bounce back out to a "full" window again. -- George Orwell III (talk) 01:30, 12 July 2013 (UTC)

## Proper structure

OK, I'll buy it. What do I, as an html neophyte, need to do to make a new work compliant with a good structure? I'm thinking particularly of Index:Ante-Nicene Fathers volume 1.djvu. The whole work is 24 volumes and if we can get it right at the beginning of working on it, then it could be the poster-child for your vision. I'm prepared to do the donkey-work, but I do need guidance on correct practice. I will also document techniques as I go, so that the help pages can be sorted to match. Beeswaxcandle (talk) 05:19, 12 July 2013 (UTC)

As I alluded to in WS:S, until the basic HTML tags are separated from their wiki short-hand, symbol driven counterparts, proper semantic markup is just not feasible (well not without major CSS additions that is).

Other than that happening, all we can do in the interim is be mindful of unnecessary template (over)usage. -- George Orwell III (talk) 07:10, 12 July 2013 (UTC)

So, for example, use a table rather than a series of templates that create (or mimic) a table? And avoid templates that are based solely on calls to other templates or that create multiple divs? Beeswaxcandle (talk) 07:53, 12 July 2013 (UTC)
Exactly - don't just pile on the templates to accomplish the same styling you know can accomplish with just a single tag and the matching series of styling attributes, parameters and/or values that could/should be associated with that single tag.

And as far the DIV element in general goes (as it has always been and forever will be...)

... and my favorite, especially when it comes to usage around here,
A div is placed around a group of block level elements. A span wraps a group of inline elements or (most usually) plain text. The key word is “group”: if a div wraps just one block-level element, or a span just one inline element, it's being used unnecessarily.
-- George Orwell III (talk) 08:11, 12 July 2013 (UTC)

## ? Ideographic Space

Hello. If this edit was intended to ask a question, the official answer is here w:Space_(punctuation)#Spaces_in_Unicode (Search forward for the table cell contining: "U+3000" (next cell contains 12288―hint enough?) As best I can figure out: UNICODE's attempt to have a {{fsp}} for Chinese/Japanese ideograms?

Assuming w:File:Punctuation Spaces.svg is accurate, it is effectively just another em-space, so far as English-language usage is concerned. MODCHK (talk) 03:04, 14 July 2013 (UTC)

That wasn't really behind my unwarranted addition - just a spur of the moment thing to be honest - but now that you've gone to the trouble of running it down, I might as well follow-up by picking your brain.

First, if I understand you correctly, I can use that character like I have on occasion to "pad" one thing or another without it making a mess of anybody's rendering (save the occasional Oriental? screw em') in the process? I was just happly to stumble upon something that never generated one of those little square boxes to indicate some character can't be rendered properly even under IE6.

but more importantly... can either one of these characters be used as substitute for when people do stupid things like make hundreds of <span style="visibility:hidden;">0</span> just to pad a series of 1 or 2-digit numbers to align right when bundled contiguously with a series of 3 to 4 digit numbers (think PageList rendering found on any Index: page here)? Even when some User is java-less/embedded-font-less/or similar -- will either reliably fill in as a simplified way to "pad" digits instead?

TIA. -- George Orwell III (talk) 03:31, 14 July 2013 (UTC)

O.K. If I understand that question; short answer: YES. Long answer: NO.
As I understand it, UNICODE defines a whole plethora of various-width "space" characters as described in the Wikipedia link above. The one you have stumbled across (&#12288;/&#x3000;/ideographic space) just happens to be the one appropriate to East-Asian ideogram font use. It would be quite useless for padding columns of figures; as the appropriate one in this situation is really (&#8199;/&#x2007;/figure space) (which is what I really meant when I lazily referenced {{fsp}} above.)
Gotcha & thanks.
To (perhaps mis-)quote yourself: if you find yourself doing this in bulk then you are clearly doing it wrong! (Surely creating another table column for purposes of alignment is not all that hard?) All these spacing characters only really work for monospaced content and will break any kind of proportionally-spaced font use.
Have I just answered a different question; one you didn't really ask? MODCHK (talk) 03:57, 14 July 2013 (UTC)
No its my fault for muddling the two. I should have made it clear that I've only used my little character in single instances to "pad" faux list-item-bullets to list-item-bodies to mimic things like clauses found only in U.S. legislation styleguides (hardly a major worry for anyone but me I suppose).

My real concern over the padding of numbers is primarily due to my inability to effectively open/edit certain Index: pages containing pagelist assignments running well into the 4-digit thousands (you might recall I reached-out about this in WS:S/Help a couple of days ago). My limited "debugging" skills seem to indicate the problem lies somewhere with resource consumption/script looping during the generation of all those stupid "hidden" zeros being applied just to pad the numbers to the right in the final rendering of all those neat-little-proofreading-color-coded-squares.

I'm not exactly well-off to start with plus I'm forced to keep the many outdated versions of software functional on my home setups for work anyway so "upgrading my PC and or OS" is not the immediate solution for me here. I was just pondering some other way of accomplishing the same via coding, et al. without all that waste by generating stuff only to hide it from displaying at the end of the day (seriously; open any lengthy, assigned pagelist with your HTML viewer, look closely at the scheme used just to pad the numbers - any linkage would be corrupted if the zeros were taken into account btw -- and you'll see what I'm talking about/thinking of). -- George Orwell III (talk) 04:22, 14 July 2013 (UTC)

Pardon the slow response. It took me a while to realise the complete c**p pagelist is generating. Surely a text-align: and width: CSS property pair could produce the same effect as all that visibility:hidden/padding stuff? I am severely behind here―any idea where the logic to produce this lives? (Cancel that: its in the PHP code: ProofreadPage.body.php:743: $txt = '<span style="visibility:hidden;">';et al) Assuming the "cure" is not worse than the disease, have you (or anybody else) raised this sort of thing with the GSoC mob? MODCHK (talk) 04:58, 14 July 2013 (UTC) Eeh, I think I've pretty much been summarily dismissed by those types by now thanks to much of my previous, long-winded rantings. The funny thing is I finally managed to work the Bugzilla site in under the applicable radars here [firewall, etc.] a couple of weeks ago after a year or two of being all too careful never to have such stupid domain name remotely associated with anything 'online-of-mine' (again re: work) only to misplace my PW right after making a single introductory rant there. I haven't bothered restoring that access since but it looks any further procrastinating on my part is becoming an issue on too many other WS fronts (I'd like to replace the current PHP generated ProofReading status bar with a more HTML5 compliant one . . . . . . that also depicts the currently flawed 'pages yet to be created' section for example). I only made the Unicode character <-to-> padding long pagelists connection again after looking over & adding that character to your list of useful stuff a little while ago anyways. I'd still need to mock something up first just to be sure nobody throws a hissy fit if the newly proposed pagelist rendered only 98.8% as well as the old pagelist did before I dared to bring it up formally. -- George Orwell III (talk) 05:58, 14 July 2013 (UTC) At the very least a hissy fit shows somebody is paying a minimum of attention… A deathly silence might be far worse! P.S. I do not believe anything defines qualitye/qualityf… yet? MODCHK (talk) 06:19, 14 July 2013 (UTC) If I remember right, qualityf (f for first?) is nothing more than assigning a null class to the first table-cell that was functioning as nothing more than a spacer width wise and something that line-height values could detect and work with height wise (It was a hard non-wrapping space before I used 12288 Unicode character instead). qualitye (e for ending cell? empty cell?) is really a "void" table-cell being generatated a couple of lines up in the related PHP. This is where currently all we get is a "skipped cell" (empty line in the HTML) instead of a proper row close with a right-ish border (and "white" should be defined for qualitye if I haven't done that already) depicting any yet to be created pages detected within the from= to= pages range input. Whether the math formula used to create all the sections and their width %s correctly calculates for qualitye (or the old "void" cell) I cannot say for sure since I've never seen it "work" (or error out) either way. -- George Orwell III (talk) 06:43, 14 July 2013 (UTC) UPDATE: Well the premise works like I thought it would when values for the number of pages/percentages for each PR status are a User driven input rather than API (or whatever) calculated; see Template:PageStatus & associated. Now if I just knew how to pull the current values automagically via Module: or Template: in addition to the total position count of a source file to work from, the whole bit could finally be trimmed once and for all from the christmas-tree of existing ProofReading/DynamicLayout server based stuff in addition to giving the W3.org HTML validator a well-deserved break. -- George Orwell III (talk) 12:09, 14 July 2013 (UTC) Addendum: Regarding "stupid" domain names, I recall some former workmates being inordinately proud of defining one machine ("shifty") outside of the corporate firewall. Manglement took a mere six+ years, a reorganisation and company takeover to realise; and then were―peculiarly―delighted somebody else had made the hard decisions on their behalf… (You will guess correctly corporate raison d’être was “secure” communications… need I say more?) Logic really is an RFP option in the human model software set… MODCHK (talk) 06:36, 14 July 2013 (UTC) I can relate. :) 'nuff said. :| George Orwell III (talk) 06:43, 14 July 2013 (UTC) ## Adding a ID to Pagenumbers.js Difficult script! Just as any ThomasV script. Nevertheless, if you can and if you are carefully bold, this is the edit to test: • row 236, original: a.innerHTML = " <span class=\"pagenumber . . . . • row 236, fixed: a.innerHTML = " <span id=\"pagenum"+num+"\" class=\"pagenumber . . . . • row 246, original: oh = oh + "<div class=\"pagenumber noprint\" . . . . • row 246, fixed: oh = oh + "<div id=\"pagenum"+num+"\" class=\"pagenumber noprint\" . . . . I can't test by myself since Pagenumbers.js change deeply and irreversibly the html code, then I can't run my edited script. Stay ready for a roolback. :-) Another option: to convert Pagenumbers.js into a gadget, leaving to the user the opportunity to activate/deactivate it (I don't know if you use to manage gadgets code). Already discussed - not an option - community thinks uniform Dynamic Layouts worth more than letting people decide themselves. :( A third option (my preferred one): simply to comment out mw.loader.load('//en.wikisource.org/w/index.php? title=MediaWiki:PageNumbers.js&action=raw&ctype=text/javascript');  into MediaWiki:Common.js :-) --Alex brollo (talk) 17:32, 14 July 2013 (UTC) Ha Ha.. that last one was very funny. It was almost a step too far just to locally host a slightly modified .js rather than the standard import from old.wikisource that other domains seem to follow. The only way to "eliminate" this file is to split it up into its various function parts first & then let people decide/discover what they can live without, what to gadgetize, etc. etc. etc. Some people would prefer 'inline' embedded page links; others like mouseover highlighting, and so on. Right now, too many interests are joined together as one just to keep the status quo = no desire to make improvements, etc. I will try your suggestions for modifying the .js later today and see what happens. Hopefully the worst that happens is I have to revert [quickly]. If I miss you somehow today, please touch back tomorrow, etc. Thanks again. -- George Orwell III (talk) 17:52, 14 July 2013 (UTC) I'd like try this too: >>>> Hidden <<<< --Alex brollo (talk) 10:23, 15 July 2013 (UTC) Yeah... you can forget about making any other changes other than the ones modifying the embedded link outputs without presenting it to the community first. I made the original 2 changes not hidden above just now so we will see what happens in a bit when I'm sure the change has cycled through the cache, etc. Please check lines 236 and 246 in MediaWiki:PageNumbers.js to make sure I've modified them correctly. And in the future, you really need to adopt the mentality that position numbers correspond to the source file's progression for physical leafs (or pages) in a DjVu or PDF file (so Page:Shortstorytitle.pdf/17 is position 17). page numbers are assigned to offset position numbers so they virtually match the numbering used by the publisher in the book such as the assignments made in the pagelist tag of Index: pages. (position 17 has a delta of 10 so the page number would be 7 & ' 7 ' is what the reader normally would see on the paper page in the printed book) If you keep proposing stuff with pagename, bookpagenumber and djvunumber, the community is going to be overly concerned about what you/we are proposing to change here not because they don't want or understand the proposed change but because we/you are using the wrong terms.-- George Orwell III (talk) 14:30, 15 July 2013 (UTC) ↑ Well? -- George Orwell III (talk) 22:29, 15 July 2013 (UTC) (conflicted) Hurra! Id appeared into ThomasV damned divs. But… Module:Lua points to #pagenum+position instead of #pagenum+pag number. No matter: I'm going to fix it into Lua module. --Alex brollo (talk) 22:33, 15 July 2013 (UTC) Spacing/Spacer issue in .js now Fixed #pagenum+position or #pagenum+pag number wasn't the problem yesterday because the Module: is now just  return v.name.."#"..pages.d2b[positionSource]  and that works. This is why I felt we/you had already defined 112 = 70 in the Data subpage and all that was needed was to call that conversion the proper way. Well at least the SPANS/DIVS get an id tag in the process: no harm; no foul. Please note that we never add any sort of "prefix" to our embedded page links that modify or differ in any way from what was exactly assigned in the Index: pagelist tag. So you should never see [p. 70] or [page 70] in any pure transclusion from the Page: namespace, sectionalized or otherwise. -- George Orwell III (talk) 23:32, 15 July 2013 (UTC) One more (hopefully the last one!) issue. Now anchors seem right, matching their ID; nevetheless, clicking a link with a #pagenumXXX anchor inside, borwser refuses to follow the anchor as the page opens - it follows it if you click the URL again. This comes from the fact IMHO that when the browser opens the page, it doesn't find any anchor into server html; the anchor is build in a following time. This is rather tricky. :-( Perhaps some more js code should be added to PageNumber.js, so that as soon the all the IDs have been added to html code, js "calls" again the url, so reaching the anchor with a small delay. I'll try to write the needed js code but then is a matter for you again. --Alex brollo (talk) 06:41, 16 July 2013 (UTC) I just dbl-checked again & the Book I page opens with the link to Book III, p. 70 in the first footnote just fine for me (IE8). Perhaps your browser is Fireman or Tenor?? (I forget the names but Mozilla/Google based). Maybe you need term pagenum in Lua script after all? Again, all PAG template generated links to URLs &/or their #Anchors working fine here. -- George Orwell III (talk) 06:54, 16 July 2013 (UTC) But: windows Internet Explorer scrolls to the anchor? Yes Microsoft IE has always opened the landing URL page and scrolled right to the #anchor to it 1st viewable line in browser window instantly. Pretty sure for you that is a matter of adjusting a browser setting -- or maybe is an add-in? -- or something but I have seen Goooogle Chrome do the same behavior several times. -- George Orwell III (talk) 10:16, 16 July 2013 (UTC) Chrome doesn't scroll properly. Anchor is fine into url, id is fine into div, nevertheless it doesn't scroll (it scrolls when url bar is clicked again: This forces the scroll: $("#"+window.location.hash.substring(1))[0].scrollIntoView();

But if I'm the only one faced with a "not-scrolling window", there's no problem. :-) --Alex brollo (talk) 07:13, 16 July 2013 (UTC)
No its OK to fix if its a known issue - where exactly should I put that line. -- George Orwell III (talk) 10:07, 16 July 2013 (UTC)
I can't say that I understand fully what PageNumbers.js does, but I'll try to add that line here:
if ($.inArray(mw.config.get('wgAction'), [ 'view', 'submit' ]) != -1) { //fixme : this is sensitive to order (detection of containers with "relative" position) addOnloadHook(init_page_layout); addOnloadHook(init_page_numbers);$("#"+window.location.hash.substring(1))[0].scrollIntoView();// HERE
}

If I guess, when js comes here (if previous calls are syncronous) the code should find its ID-containing divs ready. If not, the help of someone who can understand PageNumbers.js is needed. --Alex brollo (talk) 05:34, 17 July 2013 (UTC)
Sorry for the delay (real life got in the way) - I added the line though I'm not sure if I did it right. I might have assumed the ending } above was the existing one but all the way to the left in the .js and not in line with the $symbol as you have outlined above. -- George Orwell III (talk) 19:40, 18 July 2013 (UTC) It runs - I saw too Module:Pag fix. Thanks! --Alex brollo (talk) 07:29, 19 July 2013 (UTC) ## Fighting with Template:Content :-) No matter… try as long as you like; De re metallica is the only one index using it. --Alex brollo (talk) 22:10, 15 July 2013 (UTC) I won that Fight 10 or 20 revisions ago YOUR boxer cheated by not importing helper-template {{collegamento}} when I Assumed it would be (fair fight) :) George Orwell III (talk) 22:17, 15 July 2013 (UTC) ## Help for General indexes One more help - I hope I'm not abusing of your patience. Could you format properly (using the best of en.source conventions) ONE row of Page:De re metallica (1912).djvu/663 to use it as a model for the other, few rows of indexes? Here Module:Pag would give its best :-) --Alex brollo (talk) 05:50, 17 July 2013 (UTC) I re-did what little you had started already but such things seems like overkill to me. Still, your biggest problem is still using the deprecated style(s) that are not HTML5 compliant anymore. We [started to] switch to a true HTML5 based spec. not too long ago ( <!DOCTYPE html> ) and the "old" way of table formatting, etc. will eventually fail one day under it (or worse, will be handled by automatic work-arounds/re-formats built into the wikicode instead). Better to start learning how to apply the specification sooner rather than later. -- George Orwell III (talk) There's a marvellous Lua-based template into fr.source to manage such things, I opened a talk into scriptorium. --Alex brollo (talk) 07:38, 19 July 2013 (UTC) ## Wikisource mailing list Hey George, are you in the Wikisource mailing list (this one: https://lists.wikimedia.org/mailman/listinfo/wikisource-l)? We started a thread about the issue we were discussing in the Village Pump (XML, djvu text layers, etc.). Your competence and insights would be mostly welcome. --Aubrey (talk) 11:11, 17 July 2013 (UTC) Unfortunately because of the type of internet access I need to call upon is also tied to my work-place, things like that aren't really possible for me. Sorry. -- George Orwell III (talk) 19:51, 18 July 2013 (UTC) ## Removal request Would you be able to remove the Google statement from the following text before I bring it over to WS? [At your leisure] Thanks, Londonjackbooks (talk) 23:31, 18 July 2013 (UTC) Done -- George Orwell III (talk) 23:48, 18 July 2013 (UTC) Thanks. Londonjackbooks (talk) 23:49, 18 July 2013 (UTC) George Orwell III, that was excellent! Does one have to be an administrator to remove that Google page as you have done? Respectfully, —Maury (talk) 03:02, 21 July 2013 (UTC) Nope. All you need is the DjVuLibre software package and some time to learn the ins & outs of it. The downside is that one would need to download such DjVu files in need of fixin' in order to make any modifications and then upload over the previous file on Commons when finished. Being an admin only makes any subsequent bulk page moves or bulk page deletions a bit easier if at all. -- George Orwell III (talk) 03:15, 21 July 2013 (UTC) ## Tidbit I'm not following the discussion but your suggestion to make use of Page:De_re_metallica_(1912).djvu/0 leapt out at me, and I wanted to point out that we currently have no use for the root page Page:De_re_metallica_(1912).djvu. Hesperian 02:51, 21 July 2013 (UTC) Either / or would be fine by me (wasn't really the point) & the same would be true if the data was stored in a proper sub-page of the Index: namespace. All of this is a moot point unless Lua modules and/or helper templates can "recognize" the data exactly the same as if it were a sub-page of the current main Module: where it currently resides. The point is not to launch this approach unless the data can always be found under or nearly associated with a "child" based on the relation to the actual source File: naming (such as the Index: then Page: namespaces generate by design). Having dozens if not hundreds of sub-pages built for each source File:s data under a single the core Module: file is NOT the solution here. I just don't know enough about LUA scripting to even test that simple need myself. -- George Orwell III (talk) 03:10, 21 July 2013 (UTC) ## Moving to la.source Just to let you know that I'm going some time into la.source, where la:Liber:Agricola De re metallica.djvu and some willing friend are waiting for me... and for my tools. Thanks for suggestions and help. If you like or need, send me an email: I don't know how much time is needed to apply into la.source all what I learned here. Then, the bigger step: oldwikisource. --Alex brollo (talk) 21:30, 21 July 2013 (UTC) ## Deeper inside Module:Pag Here some projects and some comments about that confusing Module.Pag stuff. 1. first of all, you'll find at User:Alex brollo/parseIndice.js the js script that builds Lua data page. I just fixed it, so that it can run in it.source but in en.source and la.source too. It's a rough version (it just run once!) - expect for edits. And - don't expect any doc by now. Yeah I tried converting it to English already. See User:George Orwell III/parseIndex.js -- George Orwell III (talk) 13:53, 22 July 2013 (UTC) 2. as you know, Module:Pag needs a data page; parseIndice.js builds such a data page, but it needs pagilist tag output (not a problem) and Template:Content code into Index page (this is a problem). If you browse js code, you'll see two ajax calls: the first, to get html of Index page; the second, to get wikicode of the same Index page. Now, if I'll edit Content template so that needed data are wrapped somehow into html, former call wuold be sufficient; and if TOC templates could be edited too, so that they produce the same result, t.i. wrapping needed data into html, parseIndice.js could find them too in trascluded TOC's - this solving partly the problem. I suppose, I'll try to wrap data into a html5 data- "object", first using Template:Content, then (if community agrees) editing one or two from the most used TOCs. I'll follow this way: using HTML5 data- attributes by jQuery. You lost me here. -- George Orwell III (talk) 13:53, 22 July 2013 (UTC) 3. I'll ask wikitech-l about that question - in which namespaces Lua data can be stored. Why can't you just TEST the Lua script to point to other namespaces yourself? This is getting ridiculous and losing interest with every passing day. -- George Orwell III (talk) 13:53, 22 July 2013 (UTC) 4. Module:Pag has some limitations, the deeper being that it runs only when a strict 1:1 relationship exists between pag and num. A second one is that if a djvu page is sectioned and splitted into different chapters/sections, link nsPage->ns0 breaks. and there's usually no data to "guess" (General indexes of the book don't say at all, when they report "pag. x", if they point on a chapter or on another one, when "pag. x" contains pieces of different chapters! You can think if you like about this unsoluble issue, and my conclusion is, that deep fidelity to book data is broken by usual transclusion conventions, and that the "main digitalization" should be considered the nsPage one; the "columns issue" I discussed with Beewaxcandle being another proof of that). --Alex brollo (talk) 08:24, 22 July 2013 (UTC) My turn to "chip in". In re your 4th point about the Page: ns being the "main digitalization"—absolutely not! The ONLY place we want readers to read (or download) works is the Main: ns. We are not in the business of slavishly reproducing every nuance of the printed books. If we were, we would just point our readers to the Internet Archive's pdfs and jp2 scans and have done with it. We are making the text available to readers in as accurate a manner as we can provide. This is the web. It does not have the restrictions of the printed page (page dimensions, binding in signatures of multiples of 4, limited number of signatures causing chapter breaks to occur mid-page, &c.). We do seek to represent authorial intent (italics/bold/small caps as a means of emphasis, offsetting quotes, quirky orthography, &c.) along with adding value with wikilinks both internally within the work (page numbers, or "see above") and to other works on Wikisource (preferably en, but sometimes to holdings by other subdomains). With respect to the technical limitations you mention, these are a deal-breaker for me. Many English works skip pages in the print sequence for full-page images, which results in changes in the offset throughout the work. If the pagelist has been done correctly in the Index, you might be able to harvest that. Also have you talked to Phe yet about his indexing tool and how it works? Beeswaxcandle (talk) 09:54, 22 July 2013 (UTC) Thanks Bee for attention. No matter for the discussion about nsPage role: aside phylosophy, when a good, data-rich, well-structured html content is produced, anyone can use it as he likes. I'm in contact from a long time with Phe - to notify him my boldest ideas, letting him free to go ahead or to disregard them. About this Module:Pag see here. I mentioned too this stuff into wikisource-l some weeks ago; but, a test here was needed, and really I could not imagine at all the big PageNumbers.js problem (since it.source didn't install it). And now.... let we go to waste Template:Content trying to force it to produce a good set of HTML5 data- :-) --Alex brollo (talk) 11:17, 22 July 2013 (UTC) Got! :-) George or Bee (can I make your nick shorter?), try this in a js console staying in Index:De re metallica (1912).djvu, and try different values for eq() or do what you like: $(".toc-data").eq(1).data()

I feel that it's a good way, a KISS one. :-D --Alex brollo (talk) 11:55, 22 July 2013 (UTC)
You are obviously in love with throw-away, work bench called Page: namespace. Why? Its just a tool! Good source file is ALWAYS the best way to "digitize" from one file format to another -- not stupid space used to compare right-side picture to left-side transcription. Samething with Index: space and pagelist / off-setting. Good source file is ALMOST ALWAYS the easiest way to re-use or convert content.

Fix your source files to meet most basic semantic HTML markup &/or most common file specification and you can convert or re-apply content 1000s of times - here on WS or in real world as needed. Trying to fix content in Page: namespace is like patching bald automobile tire -- every 2 days tire needs attention. Good source file is always like new tire - run & run & run - any road, any time. -- George Orwell III (talk) 13:53, 22 July 2013 (UTC)

Probably my opinion comes, from being deeply concentrated about tools helping proofreading - if you think, Module:Pag too is merely a tool to add faster and better the needed links from book pakes into digital text. I didn't discuss with you my other tools, all devoted to the same goal. Take a look to User talk:Ineuw for them (absolutely the best is "toggle note").
Proofreading tools are fine to add and are useful to a point but PAG is not ready to become a standard. The need for double-namespace links like PAG facilitates are generally common across all works in the Table of Contents and Index whenever present. Other than that 7% of a total in a "book" - nobody cares; they just add/subtract offset as needed. For serial & reference works, PAG can be very helpful. Unfortunately, serial & reference woks are not the majority class of work being transcribed on a consistent basis - novels or prose are (= PAG is interesting but not that big of a deal). -- George Orwell III (talk) 17:14, 22 July 2013 (UTC)
Nevetheless, I see IMHO the echo of the present discussion in Wikidata about the difference between "book" and "work"; where digitalization of a "book" is to be approached with a TEI approach, while the best digitalization of a "work" is approached best with a Gutemberg-Distributed Proofreaders approach. In my mind, Wikisource covers both; but I'm far from skilled/interested into "strategics" since I'm trying to go deeper in "tactics"; if you like issues related to "strategics" my reference is User:Aubrey. And now... la.source is waiting for me (I just imported there the revised, KISS version of parseIndice.js :-) ). --Alex brollo (talk) 16:04, 22 July 2013 (UTC)
You can parse the workflow however it makes you feel better about your work, etc. but in general, we think of Books as being originally published/printed, and Works are [source] files/digitalization of those "Books".

The Page: namespace is only a tool to help get you from a Book to a Work; its not digital conversion at all. It is only a form of digititazion (a format). Focusing on one format over the others prevents them from ever being shared with other entities (e.g. No library will ever share their unique content with us unless our unique content can be shared with them in mutual return(s)). If that basic premise is not being applied here - folks will eventually skip Wikisource altogether and go directly to Project Guttenburg, Google Books, etc. instead. -- George Orwell III (talk) 17:14, 22 July 2013 (UTC)

I notified to Aubrey this interesting talk. --Alex brollo (talk) 07:06, 23 July 2013 (UTC)

## Demoting page quality

Hello George Orwell III,

Thank you very much for your support of my proofreading. I am however wondering why you bothered changing status to not proofread for this and this page. They look mostly legible to me but I might be unaware of some policy, so I figured it would not hurt to ask. Tar-ba-gan (talk) 18:18, 22 July 2013 (UTC)

Yeah you are unaware alright. I don't read Crylic or whatever that non-English tripe is found most if not all of your edit summaries so if you can't be bothered to update us with an edit summary (in English) for one of your edits/contributions, I can't be bothered with advancing the proofreading status of any of your edits - especially with the absence of that information in the edit history to go on. And As far as I can tell, the PR status was never higher than "red" before or after it was tagged problematic so?????????????? -- George Orwell III (talk) 18:36, 22 July 2013 (UTC)

## Wikisource User Group

Global message delivery, 23:21, 24 July 2013 (UTC)

## dotted TOC page listing

Hello. I noticed all your recent efforts regarding this template and its cross-page-support derivatives. Thank you.

In the remote chance this might save you wasting effort pointlessly (as I have apparently so done), I have spent the last week or so converting this template into Lua in the mistaken belief that the result might be less prone to the dreaded "Template include size is too large" warning. Regrettably I have come to the sad conclusion that Lua simply adds to the problem rather than (as hoped) reducing the thickness of the overall template "sandwich". I don't really suppose I ought to be surprised.

As all of my testing has been off-site, I have fortunately not cluttered WS with my (ultimately pointless) experiments. Please let me know if you want to see my (warning: less-than-pretty) coding effort.

I had rather hoped that HTML5 support might have "put to bed" the whole variable-(dot/whatever)-leader issue, but it appears not to be? MODCHK (talk) 02:00, 27 July 2013 (UTC)

I'm no fan of this series or set of templates but its popularity can't be denied. The "problem", if there ever were any, are a.) that the "dot-free" version should have been the core template with a choice to invoke a separate helper template to include the "dot" portion(s) if the User wanted that. Currently there seem to be too many choices for Users to select from when it comes to the reproduction of a TOC and that's why we can't seem to nail down a smaller batch of "issue-free" templates that cover the majority of the typical TOCs we encounter for Users to pick from.; and b.) a TOC is usually not semantically built upon HTML tables by most measure. Its HTML equivalent is typically based on modified item- or defined-lists (OL, UL & DL) more so than any other HTML element or layout approach. Our approach, for the most part, has been building TOCs on HTML Tables and that part of the reason we get such a "bloated" result. Lists however are real unfriendly in that you are limited to a fixed set of bullet items as well as hard to bottom align page numbers apart from the item-bodies. Find a way to accomplish much of the same we currently falsify using tables but with lists instead and you'll have solved a long bothersome quirk in our PR process.
As far as your Lua approach goes - don't feel like you shouldn't play with it here. I'd be curious to see & learn as much as possible about using Lua for starters and the worst that can happen is we wind up deleting the experiment at some point. -- George Orwell III (talk) 02:22, 27 July 2013 (UTC)
Apologies if my initial message was rather too passive-aggressive (the annoyance is aimed primarily at myself!) This issue looks initially simple, but can become deceptively nasty. "dot-leaders" is (are?) such a 'pretty' concept, and are so common in the word-processing field, that I am sure most consumers fail to appreciate how perversely difficult the effect is to reproduce in HTML. (Incidentally, I am assuming you have already seen things like [1] (or similar).)
Here is my (excessively debugging-rich version) of {{dotted TOC page listing}}, to be invoked via something like:
{{#invoke:dotted TOC page listing|dtpl|chaptertext={{{chaptertext|{{{1|}}}}}}|entrytext={{{entrytext|{{{2|Entry text}}}}}}|pagetext={{{3|{{{pagetext|{{DJVU page link|{{{djvupage|1}}}|{{{djvupageoffset|0}}}}}}}}}}}|spaces={{{spaces|{{{4|1}}}}}}|chapterwidth={{{chapter-width|2.5em}}}|chapteralign={{{chapter-align|right}}}|entrywidth={{{entry-width|80%}}}|entryalign={{{entry-align|left}}}|hi={{{hi|1em}}}|dottext={{{dottext|}}}|symbol={{{symbol|.}}}|col3align={{{col3-align|right}}}|col3width={{{col3-width|2em}}}|djvupage={{{djvupage|1}}}|djvupageoffset={{{djvupageoffset|0}}}|col4text={{{col4text|}}}|col4align={{{col4-align|right}}}|col4width={{{col4-width|2em}}}|col4text={{{col4text|}}}}}

Adding debug=yes pretty much reveals all. Please feel free to experiment with/improve/delete as you see fit. I expect I have set the initial bar pretty low! MODCHK (talk) 03:01, 27 July 2013 (UTC)

See this page, etc.... Something to do with tweaking the header template? Londonjackbooks (talk) 06:20, 27 July 2013 (UTC)

The problem does seem to be with the original header template. The author and override_author portions of the template code are not mirrored exactly by translator, editor, contributor, etc. portions and that is why author works and translator does not when being pulled from the pages tag command line. I think you'd better post the problem in Scriptorium - I have no idea nor the incentive on how to fix something like that. Its a stupid feature if there was one imho. -- George Orwell III (talk) 06:46, 27 July 2013 (UTC)
I think User:Tpt is the resident expert on the header template. Once you "restored to previous", my issue went away. Londonjackbooks (talk) 06:55, 27 July 2013 (UTC)
Nevermind - what you saw was revision in between attempts to fix a problem you don't have - your work has no translator= on the Index: page. -- George Orwell III (talk) 07:00, 27 July 2013 (UTC)
Yup. Thanks. Londonjackbooks (talk) 07:02, 27 July 2013 (UTC)

Hello. Please pardon my using you as a sounding board, but with any luck you will set me straight again.

Once more there is an election session which shows signs of starting to be dominated by "this person is not active: goodbye" style evaluations. Maybe I am over-sensitive to these kind of evaluations, but it does strike me the trite little summary given by {{admin confirmation}}—contributions/logs/crosswiki neatly misses the point. Surely the issue being assessed is how up-to-date, capable and incisive the person is; not when they last actually wielded a big stick?

Frankly, I would trust some kind of record of when the person last logged in and what proportion of their watch-list had been viewed; neither measure I have the slightest idea how to extract.

Is this perhaps yet another example of excreto-cerebral system inversion™—where people are evaluated on criteria which is largely irrelevant (yet easy to measure) simply because the useful measures are too inconvenient/intrusive to present? MODCHK (talk) 22:20, 6 August 2013 (UTC)

You first have to ask yourself if merely showing up is a good enough basis to continue to support the granting of added tools & responsibilities for somebody or is how well & how often are those tools utilized and those responsibilities carried-out the basis for your support. I'm of the mind the latter should dictate support but have learned that is the minority view. So while I was once under the impression that Admin Statistics
were suppose to be the tracking tool(s) provided to help aid in the decision making process, its clear today that actually using the added tools and performing the extra responsibilities is not the key measure of support for the majority of folks around here. I'd say take a look at those stats and touch back with your initial impressions before going any further. -- George Orwell III (talk) 23:05, 6 August 2013 (UTC)
Thank you for indulging my enquiry. Those links (or rather that link with variations) is definitely worth knowing. With regard the "magic question", I am bothered by the fact that an otherwise passive administrator who looks on reasonably frequently, and knows what needs doing would be voted out on the basis of inactivity; yet a random, lets-try-everything-and-do-it-again-to-fix-the-mess-I-made-first-timer would be rewarded as a responsive, frequent user of the tools. (Yes, I made a joke of the extremes to make the point. Incidentally, the output of your 1y link—taken I admit in isolation—implies there is nothing to pick between myself and user:BirgitteSB. Even my ego does not support that lie! Q.E.D.) MODCHK (talk) 23:43, 6 August 2013 (UTC)
Pardon my intrusion, but you seem to have missed the fact that the initial stages of support/oppose will not remove someone from adminship. The initial question is really just whether or not we should have a vote on that issue, and three oppose votes are needed in order to trigger such a confirmation vote. So, no one is yet being considered for removal of access to their mop. That said, I do agree in general with GO3: that if someone has gone a long time without showing any editing here, then allowing that inactive account access to the tools is at least a potential security issue. But if someone has been desysopped simply through inactivity, I also feel it should be a quick and simple procedure to have those tools reinstated should they return to activity and make a request. IT would probably be polite to post a statment to that effect on the talk page of someone who does have the tools removed under those conditions, to let them know it's nothing they did, and that it's merely a formality to be reinstated should they have the desire. --EncycloPetey (talk) 01:51, 7 August 2013 (UTC)
Exactly - the removal of Admin tools should never be done as "punishment" of inactivity or under-utilization just as granting the Admin bit should not be based on activity outside of the realm directly affecting [en.]wikisource in some way. I also agree w/E.P. on fast tracking the reinstatement of the Admin bit to previously "absent & desysoped" admins who left in "good" standing" is a no-brainer in those cases. -- George Orwell III (talk) 02:14, 7 August 2013 (UTC)
Very good - you realized the Admin stats only paints a limited picture.... but its worth noting the "top" shaded portion (meets the standards put in place as a "rule-of-thumb" @ MediWiki) vs. the "bottom" shade of the table (did not meet the minimum standards) as well. Its when somebody falls into the bottom portion do I take it upon myself to investigate one's edit history, watchlist, participation, etc. to balance out a more total view of the person. To me, the "lifetime" means very little - only the year & less stats should be considered for the annual reviews but, again, this seems to be a minority view.
In the end, if you are here on regular basis and frequently "stop" to look around & help, discuss policy making, etc. you should come to know who is really worth "keeping" and who is not. I can't speak to your inactivity concerns because truthfully I don't personally subscribe to the current standards as being serious & only follow them because its the current policy. -- George Orwell III (talk) 02:14, 7 August 2013 (UTC)
Right. I only bothered you (GOIII) in the first place because I thought this matter might not be of broader interest. Thank you also EncycloPetey for getting involved; because your interest (& I accept the point you made) both proves that point false, and also pretty much proves my original misgivings viz. the criteria being presented for re-election paints a mere part of the picture. Now suggestions please where should this discussion should really be taking place? MODCHK (talk) 02:42, 7 August 2013 (UTC)
Most discussion happens (or starts) in the Scriptorium, but the page Wikisource:Adminship is the one that baldly states "Adminship may be lost for reasons such as inactivity, or loss of confidence of the community, and this will be done in accordance with our restricted access policy." I think that statement could be expanded and clarified, and so the accompanying talk page, with a pointer from the Scriptorium, might be suitable. --EncycloPetey (talk) 02:48, 7 August 2013 (UTC)
I suggest that the best place for such a discussion is Wikisource talk:Restricted access policy as the bit of Wikisource:Adminship that EncycloPetey quotes is a very brief summary of a longer section on the Restricted access page. Beeswaxcandle (talk) 03:06, 7 August 2013 (UTC)

I started to write 2c worth on this, and then got caught up in other stuff. I think what I was going to say has more-or-less been said in the interim:

I think it all comes down to community presence. I want to know that our admins remain 'insiders': in touch with community norms and expectations; aware of the key issues and personalities; known to and accepted by the users who they might be called upon to 'administer'. As long as I have a sense that an admin is an active and present member of the community, I couldn't care less how many edits they have, when they last wielded the tools, or how they score on any other metric you might put forward as an alternative measure of active.

Looking at the current lot of confirmations, it seems to me that the level of community support reflects the level of community presence. So I see no reason to worry that we have become metric-based. True, some votes are rationalised in terms of counts and dates. That doesn't strike me as particularly meaningful.

Hesperian 03:24, 7 August 2013 (UTC)

Oh well, that is just me all over. MODCHK (talk) 03:59, 7 August 2013 (UTC) (Special Skill: asking the dumb questions everyone seems to want an answer to—but is just too embarrassed to actually come out and ask…)
The Administrators Statistics that George Orwell III posted above is fascinating! I especially like the one for "Lifetime". Once in a while I see one of those unknown to me Administrators actually edit or validate and I thought it was a new person or just another of the many "name change" people. —— Related to that I think perhaps there should be a limit set on the number of name changes. Also, do Administrators have an unlimited number of name changes or alternate accounts without notice to all others? —Maury (talk) 04:42, 7 August 2013 (UTC)
Those stat links were always available in the header-notes of the Wikisource:Administrators page for as long as I can remember. Not sure where you are getting the idea that there is "many name change people" though. -- George Orwell III (talk) 04:54, 7 August 2013 (UTC)
I have no doubt at all that the stats have been there as you say but that does not mean I have seen them or perhaps saw and forgot about or dismissed them since they don't include me. In regard to "user name change" I was thinking of one that was asked about today (now yesterday). Hesperian answered it and it has nothing to do with the Administrator stat pages. People are often asking him for a "name change". Have a good day, all. I am headed to bed. Kind regards, —Maury (talk) 05:20, 7 August 2013 (UTC)

## Many thanks!

For uploading a freshly OCR'd version of this: File:Protection afforded by volunteers of Oregon and Washington Territories to overland immigrants in 1854.pdf

A pleasant surprise :) -Pete (talk) 21:48, 8 August 2013 (UTC)

I do what I can - at least you provided a status that reflected the true condition (most folks don't and most works wind up forgotten soon after). The OCR is not perfect.... but its better than nothing. Prost. -- George Orwell III (talk) 21:54, 8 August 2013 (UTC)
I try to follow the best practices as much as I can figure them out -- getting this kind of unexpected help is the payoff, I suppose! The OCR is certainly better than nothing. This work has already been transcribed (by somebody else) -- but I thought it would be better to have the page scans on a Wikimedia site, and at least have that linked to from the Wikisource transcription. I may work on unifying them more tightly, but it's one of several projects I have going… -Pete (talk) 23:41, 8 August 2013 (UTC)

## 0.6250em

Agreed. No problem. Err, why?

was shown why we have such notable differences in sizing/rendering from one User (browser) to the next (the template font-sizing adventures) the other week. Long story short: 100% should be the CSS-set text size for the BODY tag and every other tag remotely related to layout should all use the same scale for measurements (em being the most used around here afaict) in order to render the same no matter the browser -- I wouldn't have believed it if I didn't see it with own eyes. I just had a knee-jerk reaction in your case but I plan on going around and converting px to em on a larger scale when I get the time (p.s. the engineering foundation for just about everything in based on the premise that 16px always = 1 em )

I think that just about sums it all up. Oh, and what a quick response; I was merely attempting to codify a fragment which I always have to look up again every time I want to use it (which isn't all that frequent) so thought—template, why not? Name choice is pure Tk.

Next and related thought, what about capturing <pre style="overflow:auto"> for all those times a thoughtless example (won't) wrap beyond the right margin...? Cheers, MODCHK (talk) 03:25, 11 August 2013 (UTC)

PRE is on its way to being obsolete/depracated if I'm not mistaken. We should design something using <syntaxhighlight></syntaxhighlight> instead. -- George Orwell III (talk) 03:52, 11 August 2013 (UTC)
Thanks (as always!) for the explanation(s). I was a little sensitive to th change (not that I disagree at all!) in the sense that 10px was my considered "pessimistic" estimate of how big to allow for scroll-bar insertion. I know (from experimentation) Firefox needs 8px; and I wanted to allow a safety margin.
So the rule ought to be always use em units? I am O.K. with that myself, but just want to be clear in case I need to answer a subsequent challenge. (Side note: I happen to have my browser set to 16px font default, but had previously thought that was atypically large, as I know many people who have it set to 10px... which is why I tended to mistrust your ratio; however, the figure chosen actually suits my personal situation perfectly.)
both em & px were fully tested (among the other stupid ones) and em was by far the best in the trials I saw. Anything starting around 4px+ started to gradually warp from one setup to the next and back as we cycled through the testbed examples so it didn't pay to use px for anything other than border widths and similar line drawings. As for your ratio thing - I believe >at least in IE< the font sizing is in pt (points) not px (pixels). 10pts is just about the universal default in any Windows setup that I've ever dealt with but maybe I'm wishing that was the case. Maybe FF is different altogether in such design points???
Point taken relating to pre/syntaxhighlight. I suspect however it will be /align/ all over again, deprecated for (I don't know) 15 years or more but still hanging around? I did warn you I am not a blue-eyed optimist! MODCHK (talk) 04:24, 11 August 2013 (UTC)
You're probably right but it should be no trouble to design something for syntaxhighlight first and then fork-off something for PRE from that for use in the interim afterwards.
I just don't have enough free time to properly address everything on my to-do list :( -- George Orwell III (talk) 04:55, 11 August 2013 (UTC)
Overarching point: I realise this and am grateful for you taking the time to explain to morons like myself. Having noted the point (re: moron, did I mention barely not-quite-but-almost-dribbling?) are there any rote tasks of sufficient straightforwardness that only an idiot could get them wrong I (but will probably do my best to, anyway) can assist with? MODCHK (talk) 05:24, 11 August 2013 (UTC)
Nothing in particular leaps out at the moment but I'll keep that in mind moving forward. -- George Orwell III (talk) 05:55, 11 August 2013 (UTC)

## Request

Hi George,

May I trouble you with a request for a file fix? The file is File:Villette (1st edition).djvu. After over two months and 900 pages of proofreading, I have belatedly discovered a problem with the file: where pages 266 and 267 (of volume 3) ought to be, there are instead repetitions of pages 206 and 207. It had me pretty worried for a minute there, I can tell you, but fortunately the missing pages are available: <https://archive.org/details/brontevillette03bronrich>. If you would sort it out for me I would be very much obliged.

Hesperian 02:27, 16 August 2013 (UTC)

Sure. I can address it this coming weekend. I'll drop you a note when it is done. -- George Orwell III (talk) 02:51, 16 August 2013 (UTC)
Thanks :-) Hesperian 02:56, 16 August 2013 (UTC)

Thankyou very much :-) Hesperian 00:52, 18 August 2013 (UTC)

In the process of doing a detailed check through...Schedules aren't yest linked, but I'd really appreciate someone else doing a pedantic check on this.. ShakespeareFan00 (talk) 22:06, 17 August 2013 (UTC)

## A Life of Matthew Fontaine Maury 1888 vs 2009 -- the 2009 should be discarded.

George Orwell III, [[2]] I think it is best to remove the 2009 work I placed on wikisource when I first came here and keep the 1888 version by Diana Fontaine Maury-Corbin book done years later due to confusion between the two.

For example, if one looks at the Index page of the Corbin book and clicks on the Title you do not go to the transclusion of her book. Respectfully, —Maury (talk) 13:38, 20 August 2013 (UTC)

I'm confused about which version you think should be deleted and why. Why don't you go through the normal steps by marking the pages in question as pending deletion and open a discussion for why they should be deleted at WS:PD. -- George Orwell III (talk) 22:36, 20 August 2013 (UTC)

### Fixed

George, as seen on the watchlist, AdamBMorgan has taken care of everything perfectly -- exactly as I wanted. The book had not been transcluded but it is now. To answer your question about why I didn't go through the normal steps, I have never used those steps to "delete" anything "as pending deletion and why". Therefore I did not know that process exists. You should remember that you are smarter than some others here regardless of how long others have been transcribing and validating books. That is why people come to you for solutions to problems and many have come here. You know more than the average person here on en.WS and certainly more than I. Anyhow, it has been remedied. I regret that I don't know as much as many others here but it is always like that in any person's life depending upon the subject matter. Kind regards, —Maury (talk) 16:01, 21 August 2013 (UTC)
Oh OK - maybe that's why I was a bit confused - Adam had already addressed some of the duplication, etc. in the interim. No harm, no foul & glad that its resolved. Prost. -- George Orwell III (talk) 17:39, 21 August 2013 (UTC)

I've started a deletion debate on something at Commons (using the alternate account I have for Image related issues) because of concerns that I can't find a clear release for the scans, Commons:Commons:Deletion requests/File:Copyright Act, 1956 (United Kingdom).djvu. Much appreciated if as the uploader you could comment in the thread there. I am of the view that the files probably are OK, but it's not exactly clear on the source site. In any case the actual text of the Act isn't contested as OGL. If you feel that the source sites OGL release covers the scans, then please comment in the Commons thread. ShakespeareFan00 (talk) 22:44, 23 August 2013 (UTC)

Hi, GO3. Although I do have doubts as to the doability of this request, nevertheless I thought it's worth a shot. Would it be possible to reduce the bottom margin below the caption of the {{FreedImg}} when used for left or right floating images. THIS IS ONE EXAMPLE and they all have the identical large white gap at the bottom. Centered images are not a problem because we can adjust the spacing, using the {{Dhr}} when needed.

I don't see any "large white gap" here & the bottom margin is no different than any other normal paragraph (div.freedImg, margin-bottom = 0.5em). -- George Orwell III (talk) 03:40, 27 August 2013 (UTC)
I beg to differ but please don't take this as a criticism. I am only trying to improve my understanding. The above comment that it's not being doable stems from my assumption that the surrounding normal text line-height (140%) interferes with the image's wrapper's bottom margin appearance. I say this because ALL floating images I inserted have the identical margin issue and appearance, regardless of the caption length. To test this, please look at the image again because I changed the right-margin of the image from 10px to .5em and the difference between the right and the bottom margins is great. An additional reason may be that we are working in two different browsers. I am using Firefox 22.0.1 in Win XP. I will now test Safari as well, just out of curiosity. Furthermore, I will take some snapshots of the screen to show how I see them and then you can judge. — Ineuw talk 04:20, 27 August 2013 (UTC)
My bet is that is Firefox's "problem" - you overridded the line-height and font-size manually in FI's settings so there is no 140% residual at play there - and as you can see in the .CSS I linked to, the only margin-bottom being set by FI is the 0.5em value.

What we do have is the Page: namespace's forced justification of all text (not just the caption's) so please take pictures of the transcluded rendering in the mainspace - your struggle to make stuff look "right" in the Page: namespace is frequently misplaced when all anybody cares about is the finished mainspace product; Page: is then ultimately there to verify nobody changed anything content wise and not for it's prettyness or exactness. I changed the line-height from 1.4 to 1.0 em anyway. -- George Orwell III (talk) 07:22, 27 August 2013 (UTC)

Your point is well taken and thanks for your time. Yes, the results are different in the main namespace. Just FYI, there is no discernible difference between Safari and Firefox rendering. — Ineuw talk 18:24, 27 August 2013 (UTC)

In a related question, how do I locate the the WS Common.CSS to view at the contents? Thanks. — Ineuw talk 02:44, 27 August 2013 (UTC)

See User:George_Orwell_III/common.css/dynimg.css - its being imported to the site-wide css from there until everybody chimes in & signs off on it. -- George Orwell III (talk) 03:40, 27 August 2013 (UTC)
Thanks for the link. Actually, I was referring to the WS copy to see how things are generally defined. — Ineuw talk 04:20, 27 August 2013 (UTC)
Oh that comes down from the servers before it gets to MediaWiki:Common.css and goes through numerous incarnations in the process (IE8 had tools that let you "debug" the css and lists the order the css is tapped but I don't know about IE 9 or 10) & I'd have to hunt that down for you then compile a list. In the interim see The CSS Cascade for a great explanation of how that all works. -- George Orwell III (talk) 07:22, 27 August 2013 (UTC)

### Result of the line-height change

By reducing the line-height to 1em, the bottom margin is reduced and proportionally varies as it should. Also removed my 95% line-height and 90% font-size setting. My universe no longer "wobbles". (I've been proofreading too many astronomy articles). Thanks again. — Ineuw talk 07:49, 28 August 2013 (UTC)

## Precious Stones

On reflection, my comments on WT:PotM stem from my desire not to be more of a nuisance than I have to be. Therefore I will always go for the path of putting up with things that aren't vital to have fixed (and in my eyes I'm being pragmatic by doing so). I suspect that this comes across as flippancy to those who don't live in my mind. Sorry if it came across that way, or any other negative way. I do very much appreciate the work you do for us all on fixing files and I don't want to increase that work if I can avoid it. Beeswaxcandle (talk) 09:11, 2 September 2013 (UTC)

## Page rotation request..

Is it possible to rotate some of the pages in : Index:Bradshaw's Monthly (XVI).djvu ?

The only way I know how to make that happen (& have it stick) is to rotate the page or pages in the original .PDF file before it's conversion to a .DjVu file. -- George Orwell III (talk) 20:05, 13 September 2013 (UTC)

The ones that need to be rotated should be obvious. This would aid transcription (and possibly make it easier for OCR tools to actually make sense of the scans..)ShakespeareFan00 (talk) 12:33, 12 September 2013 (UTC)

Look I have no problem tweaking files & such but I'm kind of short on free time nowadays so I urge folks to list everything, in detail, that needs to be done in advance of any request. It's just not possible for me to come up with what needs fixing as well as the fixes (never mind that it is sort of unfair to think that I can do a better job than anyone else can to begin with) right now. -- George Orwell III (talk) 20:05, 13 September 2013 (UTC)

## Removing watermarks from PDF

Hi. Can you please advise what software you use to remove the Google watermarks from a Pdf book? Thanks. — Ineuw talk 05:50, 14 September 2013 (UTC)

I use Adobe Acrobat Pro, ver. 10 but I think anything higher than ver. 9 will let you remove them. I hear ver. 11+ has this as an automated, built-in feature. Removing them manually is a pain in the ass but worth the trouble in the end more often than not. -- George Orwell III (talk) 04:15, 15 September 2013 (UTC)

Thanks for letting me know. The way I tried doing it was NOT the way to go. :-) — Ineuw talk 06:06, 15 September 2013 (UTC)

Hello, George Orwell III. You have new messages at Ineuw's talk page.
Message added 22:09, 16 September 2013 (UTC). You can remove this notice at any time by removing the {{Talkback}} or {{Tb}} template.

## Still needed?

Hi George, I'm just working through Special:WantedTemplates looking for misspellings and the like. I've just come across File:SaLv124.djvu, which has got a couple of Commons templates that we don't have. Do you still need this copy? The attendant information isn't the same as the Commons copy, so I didn't want to assume anything. Cheers, Beeswaxcandle (talk) 09:41, 21 September 2013 (UTC)

## Why have a template rather than a Mediawiki: ns page

I am not certain why we have a template {{Histlegend}} that is fully protected and then inhaled into the corresponding Mediawiki page. We may as well just have the Mediawiki: ns page where the protection is automatic. Can you explain the advantages of the new scheme — billinghurst sDrewth 10:41, 1 October 2013 (UTC)

Because its no longer a simple message that can possibly point to other internal mw.messages ( {{int:xxxxx}} ) anymore. Once we start pointing to external sites, directly to other namespaces etc. we've gone beyond the intended scope of the mw mainspace. ThomasV or some other galatic prick started the practice with no justification given nor with any consensus being reached so I aim to keep returning the intent to as normal as possible as more and more of these over-reaches are discovered. -- George Orwell III (talk) 23:17, 1 October 2013 (UTC)
Can we please not be calling other community members pricks? Even departed ones. You know I'm not generally precious about strongly expressed views, swearing, abrasiveness, etc.; but I am precious about casually flinging insults at real people with feelings who, you never know, might just stumble across this comment one day. Hesperian 05:00, 2 October 2013 (UTC)
Sorry - that is the way I feel about it however. -- George Orwell III (talk) 00:11, 3 October 2013 (UTC)
The purpose of MW namespace is to host system messages, and that allow for both a standard and default approach, with a fully applied protection. I do not see that it is beyond the scope or the intent the message and namespace to do what we have been doing. I see nothing philosophically incorrect about externally linking from within a MW ns message. I can see multiple examples of WMFs wikis that contain links that are external links, and can see that it is in the default WMF messages. This indicates to me the opposite of your approach. — billinghurst sDrewth 12:32, 2 October 2013 (UTC)
From what I've read - If we wanted to point to anything, let alone an external site, the proper way to do it is to first define it ( MediaWiki:Foo ) as a standalone ( External_Toolsites ) and then call it internally everytime it's needed {{int:Foo}}, thus automatically populating the defined [message] string or URL everytime its called. If we're going to call it directly, then calling a template makes sense without butchering the messaging premise. And as far as I can recall the only default external call to an URL is the donation URL -- everything else is defined first then called via int: -- George Orwell III (talk) 00:11, 3 October 2013 (UTC)
I can see George's point, but I would have left most of this in situ at MediaWiki:Histlegend and split off only the external tools ribbon into something like {{Histlegend tools}}. Hesperian 02:06, 4 October 2013 (UTC)
I only tweaked the previous layout primarily to see if I could narrow down the issue being reported in WS:S (or WS:S/help?) at the time. Feel free to revert/modify the current approach - nothing was written in stone there. -- 02:18, 4 October 2013 (UTC)

## Copyright question with Theda Kenyon poem(s)

This poem was published in periodicals before 1923. Not knowing the rules of copyright, but just wondering why this specific poem should be excluded. There is also another poem by this author within this text: "Stacking the Needles", also published pre-1923 in The Red Cross Magazine in 1919. I marked the "Relinquishing" poem page as problematic because even after User:ShakespeareFan00 marked it as having copyright issues, it was still showing as validated, and I wanted to "keep track" of it and not have it get lost in the mix. Thanks, Londonjackbooks (talk) 00:32, 17 October 2013 (UTC)

Well I redacted the 2 stories with their content replaced by the red copyright message (Relinquishing & Saecla Ferarum) based on the belief the investigation for copyright was done & verified.

If you're telling me that is not the case, then I need to restore one contribution or the other (or both?) before the knucklehead who nominated the entire DjVu for deletion on Commons manages to get that actually deleted. -- George Orwell III (talk) 01:10, 17 October 2013 (UTC)

I believe Saecla Ferarum (1924) is still under copyright, based on the text's "Acknowledgments", but I have not researched others. I was lazily waiting to see what SFan was doing since I am not up on copyright issues; but I thought I'd at least put my two cents in with Theda Kenyon's pieces since SFan had flagged them, and I wasn't sure why. Not sure what else I can do on my end, but let me know! Londonjackbooks (talk) 01:19, 17 October 2013 (UTC)
P.S. I think the text nominated for deletion at Commons is Canadian poetry and not Armistice Day.
OK, Let's pause a moment.. I've withdrawn the deletion requests at Commons.

The items currentyly blanked/flagged have been so because there was a concern that they were still in copyright for two main reasons. i) The author was alive post 1940 ( Applying Life+70) ii) Related works (or the parent work) had renewed ( Such as back issues of perodicals)

They were blanked pending further investigation. Saecla Ferarum is so far the only one confirmed to still be in copyright. The other flagged items are not confirmed as unacceptable, they however have not been confirmed as acceptable either. I think it's time for a uninvolved party to carefully review the scans, otherwise we are going to have an unproductive argument. ShakespeareFan00 (talk) 18:44, 17 October 2013 (UTC)

If it's possible to confirm a blanked item was in fact acceptable, then I certainly have no objections to it's reinstatment, It was the lack of confirmation that led to it being flagged up (And thanks for finding the confirmation Londonjackbooks). ShakespeareFan00 (talk) 18:51, 17 October 2013 (UTC)

George, is it possible for you to get the image with text back for this page? It was found to be PD. Londonjackbooks (talk) 23:52, 18 October 2013 (UTC)

Done - Relinquishing has been un-redacted and restored in the current DjVu source file. I still don't get why we're blanking pages, etc. before folks get around to verifying things one way or the other however. And thanks for starting the investigation table - should make life a bit easier for all of us. -- George Orwell III (talk) 00:58, 19 October 2013 (UTC)
Creating the table was the easy part; others have done the hardest part. Thanks! Londonjackbooks (talk) 01:05, 19 October 2013 (UTC)

## FreedImage option?

Hi. Is there a possibility to modify {{FI}} so that the image can be clicked on to enhance viewing or lead back to the source on the commons?— Ineuw talk 04:52, 23 October 2013 (UTC)

Sorry - no. Although {{FI}}'s documentation already explicitly states the |link= parameter can't be utilized/modified, it doesn't explain why. Between us, the reality, and a good part of the reason I needed the IMG tag proposal on WS:S to be implemented, is the current internal wiki-markup that adds the A tag for URL links screws with the project's objective of freeing up the image sizing, etc. in too many cases to have made adding it a workable option. In the normal wiki-markup, there is a thumb-nail to the right of the caption area that -- for lack of a more specific term -- "overrides" the expected HTML behaviour conerning the two tags (IMG, A) relationship when used in tandem in the normal, non-wiki world. Give me the ability to use the IMG tag as part of the universal wiki-markup, as my proposal requests, and I'm pretty sure I can give you what you ask for.

Otherwise, I can only suggest bastardizing the caption portion of FI to point to wherever you like, formatting permissible of course. -- George Orwell III (talk) 22:43, 23 October 2013 (UTC)

This was just a thought to be explored, and it is not at all important. Please don't be concerned with this. Moreover, I better understand the issue surrounding this. What I am most disturbed by is, the general attitude of the developers towards users' requests.— Ineuw talk 23:20, 23 October 2013 (UTC)
Well, someone enabled it earlier today so lets see what happens - so much of the overall code has changed since my initial findings, maybe things won't "collide" with each other as they once might have under today's wiki-code environment. Let me know if see anything odd come from using link= in {{FI}} moving forward. -- George Orwell III (talk) 23:32, 23 October 2013 (UTC)
Fine with me, I have image pages waiting to be proofread and will get back to you.— Ineuw talk 23:35, 23 October 2013 (UTC)
Update
I take that all back, even removing link= or giving it some value breaks Freedimg like it always has. Disabled once again. Sorry. -- George Orwell III (talk) 06:32, 24 October 2013 (UTC)
Many, many apologies. It was I who reinstated the link thinking innocently it had been removed by accident of other development. I note you have also (since) protected the template and also removed alt… presumably similar ill-effects? 121.216.230.74
alt was only removed from User type applications only (math or score generated images) since those tags generate their own alt= string regardless & can't be over-written. link is absolutely a no-go currently for any type in {{FI}}. -- George Orwell III (talk) 07:50, 24 October 2013 (UTC)
As far as my work concerned, there were no changes.— Ineuw talk 11:32, 24 October 2013 (UTC)
.... but perhaps, there's some hope about :-) --Alex brollo (talk) 13:54, 28 October 2013 (UTC)

## Index for Armistice Day

Index:Armistice_Day.djvu should now be stable.

The remaining concern would be which if any works were first published outside the US (for URAA reasons.)ShakespeareFan00 (talk) 15:16, 24 October 2013 (UTC)

I should be able to get to redacting the remaining marked problematic contributions on Sunday if not sooner. And thanks for your attention to this matter if nobody has thought to mention it yet. -- George Orwell III (talk) 22:02, 24 October 2013 (UTC)

## Two items

George,

(1) Thank you for whatever you have done on the Matthew Fontaine Maury book. I hope it "populates" with images. (2) You have mentioned Adobe Acrobat 11 Pro a couple of times and stated something about it having the capability to remove watermarks automatically once that option is set. I have the program and it is only automatic in removing watermarks in files created in Adobe but no others. So, save your money longer.Kindest regards, —Maury (talk) 05:46, 25 October 2013 (UTC)

1. I tried downloading and saving the PDF under Acrobat to see if it would clear whatever might be a PDF structure problem - after 2 re-uploads, no luck. I'm guessing it is another Wiki code issue & not the file itself (no thumbnails on the File:Matthew Fontaine Maury 1806-1873.pdf page for starters). I'll think about what else to try in the mean time.
2. Well that sucks - thanks for saving me the heart-ache (& a few x-mas bucks) -- George Orwell III (talk) 06:01, 25 October 2013 (UTC)
I had to rename that file could that be the problem. The original name was Matthew Fontaine Maury but I tried to place it in a Category filled with things about the man that use the same name. Therefore, I added the date behind his name. If you can delete that file I have another in apparently better condition that has all white pages and I got it from HathiTrust. The one on commons came from Internet Archives. Since there are only a few pages, I downloaded the HathiTrust files one by one in .PDF format and then combined the individual files. Then (the hard way) I removed the watermarks in the HathiTrust combined .pdf files which is what reminded me to warn you about Adobe XI Pro (ver.11.0.05) only being to automatically remove "Adobe watermarks" and no others in files. What a let-down! I purchased the thing to "automatically remove all watermarks". You are very welcome for saving you from the money loss and heart-ache that I still have after having this program as soon as it came out as well as the loss of my money. Ads are too often deceptive. Sincerely, —Maury (talk) 06:55, 25 October 2013 (UTC)
You might as well upload the HathiTrust file over the existing one to see if it is a system issue or just a file problem. We can delete or keep the file (& the file name) afterwards. -- George Orwell III (talk) 17:00, 25 October 2013 (UTC)

## Re: Javascript

Since I am always looking to sharpen my programming skills, I am happy to take a look at various .js files and try to improve them if I can. I am going to be a bit busier with work than usual this coming week, so I won't be as available. At any rate, could you point me to a page in the Translation namespace that transcludes Pages so I can see what happens in that case?

For the specific question you asked:

if ( wgNamespaceNumber != 0 && wgNamespaceNumber != 114 ) means "if the namespace is not 0 and the namespace is not 114"

if ( !(wgNamespaceNumber == 0 || wgNamespaceNumber == 114) ) means "if it's not true that the namespace is 0 or the namespace is 114".

These are logically equivalent. The first may be slightly more efficient.

In English, if the namespace is neither 0 nor 114, the function add_page_container "return"s (ends) without doing anything. That looks good.

Btw, I think it should be !== instead of != . "!==" means "is not exactly the same as" and "!=" means "is not equivalent to". != involves more computation than !== (for example, the text "3" is considered equivalent to the number 3, but is not the same). The corresponding positive operators are === and == .

I bothered with the detailed explanation since it seemed you would be interested to know. --Eliyak T·C 04:05, 27 October 2013 (UTC)

Thank you & yes - the more detailed the better!
The "test" Translation page for a simple transclusion is Translation:Daany_Beedxe & a full blown work is Translation:Sleeping Beauty
The corresponding positive operators are === and == .
Lost me on that point.
Anyway, the point is -- if & when you have the time -- to go through that damn MediaWiki:PageNumbers.js and try to not only to make it current, effecient, etc., etc. but to wrangle back some of the overreach caused by "Dynamic layouts" in it's current scripting approach. Thanks again. -- George Orwell III (talk) 05:11, 27 October 2013 (UTC)

Thanks for your comments! No time to go in depth right now, but I appreciate the sentiments. Also, I'll work on those additional points tomorrow. Plus I've managed to cut out some more junk in my test code - looking much slimmer, but nonfunctional at the moment. --Eliyak T·C 22:19, 8 November 2013 (UTC)

Really a good work, as I told you into Ineuw talk page! I imported it into it.source and I'll see if FreeImg is running into oldwikisource.

Just some days ago, I was faced with images manipulation, since I was faced with the issue of "cutting away" the bottom of images from commons:Category:De re metallica Mining Heritage CD JPG; they are excellent, but the caption too has been included and I felt better to cut it away from it while linking into Index:De re metallica (1912).djvu adding a text caption. So I built Template:Img float/Drm (see an example here) that makes very simple to add the image, the formatted caption and a parameter height that can be used to "cut away" the bottom of original image.

only potential problem: {{center}} has class that opens "inherit" path for indentation; other than that - its OK for the goal needed. -- George Orwell III (talk) 07:51, 27 October 2013 (UTC)
I didn't try all possible parameters; I simply was discouraged from the p tag nightmare (solved replacing dvi tasg wirh span tags) and from the link= puzzling question. About {{PAGENAME}}: it's a nonsense idea, since it will not run in transcluded ns0. Next step, a js tool to catch coordinates moving into the page image and to build the template with all its parameters (coordinates, djvu page name and anything needed). I'll try two small draggable images (a left top "corner" and a right bottom "corner"). --Alex brollo (talk) 10:10, 28 October 2013 (UTC)

When thinking to that template I was not aware about your template and about its surprising "resize trick by css". Now, inspired by it, (something like what you see, using plain html) I'm thinking about a template that includes images into the text using the thumbnail of the page already uploaded into nsPage, showing only the right part of it into a box. The advantage would be, to include a (draft) image into a page without any need to extract the image from the djvu file and to upload it into Commons; the drawback, the need to pass to template al least five parameters (the coordinates x1,y1 and x2,y2 into the original image (whose name is known: it's simply the page name) and the box width). I feel that it would be a useful exercise, and I'll try. --Alex brollo (talk) 06:36, 27 October 2013 (UTC)

Its not really a trick. Its more a workaround for stupid File: wiki-markup that restores the possible HTML behaviour expected when "inherit-tree" is properly setup and defined thru .CSS in the "real" world. Note that the IMG is wrapped in a Paragraph tag instead of DIV to make shortest block->inline / parent<-child chain. This way inherit has better chance to work under annoying wiki mark-up. Add back |link=$ and wiki mark-up breaks chain like always. Real pain in the ass. Same "bug" exists through-out most anything that is wiki mark-up compared to outside wikifoundation. There is always too many DIVs @ play (they should re-write using latest, like box-sizing:border-box; for example to reduce constant breaking of most simple of results/wishes). -- George Orwell III (talk) 07:45, 27 October 2013 (UTC) It would be even better if you? can make FI into a Module or at least have the template use Lua to calculate .css min-, max- settings on the fly (almost like Eliyak did Here with the width attribute) and other neat things templates can't do. -- George Orwell III (talk) 08:12, 27 October 2013 (UTC) Yes, I already thought to pass FI in Lua.... first, as it is. Then, if possible, to wrap "part-image selection" inside. :-) --Alex brollo (talk) 11:40, 27 October 2013 (UTC) I failed.... let's to go back to some basic edit. :-( --Alex brollo (talk) 16:36, 27 October 2013 (UTC) Am I any closer?? The problem is again the need for Lua to detect PAGENAME & SUBPAGENAME on the first call & then to make those into strings? that it can subst: in permanently when "outside" of Page: namespace or inside again (not 1st rendering) no? -- George Orwell III (talk) 18:07, 27 October 2013 (UTC) After some sleep, and a review of Template:DropInitial, two suggestions: 1. Try to avoid div tag and use two nested span display=block only; 2. add a stupid a {width:inherit} to a tag to avoid "inheritage break" and activate link= parameter. Width attribute in nonsense into a tag, but it seems that browser doesn't care about.... My tests are going (draft! Just to see what happens! ) into it:Modulo:FIL; see also it:Utente:Alex brollo/common.css. This evening I'll go on. --Alex brollo (talk) 08:52, 28 October 2013 (UTC) I was discouraged from the p tag nightmare (solved replacing dvi tags wirh span tags) and from the link= puzzling question. About {{PAGENAME}}: it's a nonsense idea, since it will not run in transcluded ns0. Next step, a js tool to catch coordinates moving into the page image and to build the template with all its parameters (coordinates, djvu page name and anything needed). I'll try two small draggable images (a left top "corner" and a right bottom "corner"). --Alex brollo (talk) 10:12, 28 October 2013 (UTC) ## Span vs div tags From tests related to the "p tag nightmare" and FI template, and going a little deeper,, I found that a span style="display:block" is simply identical in behavior to a div tag BUT never adds any p tag. So, if in the code of "div generating templates" any div would be replaced with a span style="display:block" all would be simple. About FI. Key seems to add this css: img.freedImg, a {width:inherit;}  and any width of parent span (set as block) will be passes to a tag, then to img tag. So, I'm working about a simple structure for FI: <span> main container, display:block <span> image container, display:block, width: defined by a template parameter, <a href....> width: inherit (tag doesn't use the parameter but passed parent width to children) <img .../> class="freedImg" therefore width:inherit (so it gets width from his "grandfather tag") </a> </span> <span> caption container, display:block, can contain any html but div and p </span> <span>  --Alex brollo (talk) 15:16, 28 October 2013 (UTC) Does it resize w/ browser window resize; without a forced width input & float left or right & take position top & bottom? Looks like I'm going to be too busy today but maybe tonight I can take a look. THanks --- George Orwell III (talk) 18:05, 28 October 2013 (UTC) And in this "p tag nightmare" you keep having; wasn't it possible to wake up and just set the paragraph tag to display: inline; just as easily as forcing an inline based span to display as block? Either way - the point I made was to mimic HTML produced by wiki-code for File: (thumb, frame & frameless) as much as possible and still avoid scourge of wiki mark-up breaking inherit-tree at times. Again - all this is not needed if IMG tag was made recognizable in textarea (e.g. please bump up IMG tag proposal @ Bugzilla). -- George Orwell III (talk) 19:11, 28 October 2013 (UTC) WIP at Template:FreedImg/span (css into User:Alex brollo/common.css) --Alex brollo (talk) 20:09, 28 October 2013 (UTC) As you saw, while reviewing FI code I focused on some FI issues, but I didn't consider some interesting running features (percentage width in particular; now I see that width doesn't run at all with user option). As soon as possible, I'll study again the original code to understand deeper it and to export its features into FIS. A very exciting run..... --Alex brollo (talk) 10:45, 29 October 2013 (UTC) Ok, by now width as percentage works too into {{FIS}}, and there's another undocumented parameter to crop bottom of the image (WIP: not an "elastic" height so far). --Alex brollo (talk) 15:13, 29 October 2013 (UTC) <sigh>, look my friend. Even your SPAN block will generate an automatic new line upon template expansion in some cases. This means the wiki mark-up will insert an opening and closing P paragraph tag around FIS's output. if input is...  {{FIS | file = Iceberg.jpg | width = 20% | alt = WS Iceberg | link = w:Iceberg }}  ... HTML source is <p><span id="mySpan1" class="floatnone" style="display:block; width:20%; margin-right:auto; margin-left:auto;"><span id="mySpan2" style="display:block; width:100%;"><a href="//en.wikipedia.org/wiki/Iceberg" title="w:Iceberg"><img alt="WS Iceberg" src="//upload.wikimedia.org/wikipedia/commons/a/ac/Iceberg.jpg" width="573" height="833" class="newFreedImg" /></a></span></span></p>  So unless you apply FIS as a true span and not start on its own line, you will always get P wrapping container applied. -- George Orwell III (talk) 22:36, 31 October 2013 (UTC) ## Users with lots of uncreated pages Howdy, Unsolicited dump of information that I think you'll find interesting: These are our users with the most pages not yet created in DjVu files they uploaded. i.e. these are the putative 'culprits' when it comes to uploading files, setting up the index, and then not transcribing the work. But of course it is full of anomalies e.g. your good self who repairs broken files on behalf of other users. (Joking about 'culprits' aside, I'm not suggesting that scoring high on this is necessarily a bad thing. I just really like data, and have been speculating on the facts of this matter for some time. And I thought I'd share the results. I myself scored much higher than I would have expected, which is cause for self-reflection.) • InductiveBot: 117046 • File Upload Bot (Magnus Manske): 61322 • Inductiveload: 55750 • Phe: 54459 • George Orwell III: 54328 • Spangineer: 39312 • Hesperian: 34978 • John Vandenberg: 26587 • Ingram: 23589 • Cygnis insignis: 20278 • Mattwj2002: 19153 • Tannertsf: 17050 • RJC: 15668 • Zyephyrus: 12847 • Henry Merrivale: 11455 • Beeswaxcandle: 9532 • Innotata: 8849 • Csörföly D: 8721 • Tarmstro99: 8701 • Heyzeuss: 7112 • AdamBMorgan: 6768 • Yann: 6563 • JVbot: 6530 • Misarxist: 5985 • Xxagile: 5764 • Htonl: 5714 • Blurpeace: 5696 • Daytrivia: 5598 • Ineuw: 5256 • Londonjackbooks: 5000 Hesperian 08:27, 31 October 2013 (UTC) You've probably forgotten, if ever was made aware at all, that my issue on creating those pages relies on finding a solution to the current generation of the list-item-marker under the wiki markup ($. ) when all these types of works in question need the same alpha-roman-numeric list-item-marker generation but without the dot suffix and encapsulated within parenthesis ( (\$) ) instead. Find me a javascript/Lua way to generate custom markers that works across more than just one browser and I'd gladly utilize it in the needed generation of those pages under the vast majority of .DjVu files that I've uploaded within a week or two.

I'm also not happy with some of the thumbnails being produced by some of the current DjVu source files. I have since learned how to crop the .PDF file so the resulting DjVu file produces far superior thumbnails - I just haven't got around to re-doing those (laziness) regardless of ever finding a solution to my list-item-marker problem. -- George Orwell III (talk) 22:03, 31 October 2013 (UTC)

Not only was I unaware, I don't even understand what you're talking about. Please do take the time to explain, as I am interested and likely willing to engage. Hesperian 01:17, 1 November 2013 (UTC)
For those U.S.-based, legislative or executive instrumental works in question, after the section heading and/or introductory paragraph, all the sub-sections, sub-paragraphs, clauses, sub-clauses and the like are basically the equivalent of HTML list items ( OL Li Li Li Li Li /OL ).
In the current wiki mark-up
# first level list-item
## second level list-item
### third level list-item
#### fourth level list-item
##### fifth level list-item

1. first level list-item
1. second level list-item
1. third level list-item
1. fourth level list-item
1. fifth level list-item
the marker is always some character followed by a period. I don't need the period and whatever the character may be, alpha, roman, numeric, they all need to be enclosed in parenthesis. So for example a currently wiki generated list item marker of III. somehow needs to finally render as (III) instead for it to be worth creating those pages and not having them devolve into attempts of reproducing true list-items & list-item-markers with tables or other just as clucky element manipulation.
Better? -- George Orwell III (talk) 08:55, 1 November 2013 (UTC)

div.parentheticlist ol {
counter-reset: item;
}
div.parentheticlist li {
display: block;
}
div.parentheticlist li:before {
content: '(' counter(item) ') ';
counter-increment: item;
}


to my personal css file, and then wrapped a bunch of nested # lists in

<div class="parentheticlist">


and the result was list item markers wrapped in parentheses. That css could be added to the site css, and the div class templatized.

I believe this will work with any browser that supports :before i.e. recent Firefox, recent Chrome, recent Opera, IE9 and IE10, but not EI8 or earlier.

Let me know if this is a step towards what you're after, and if so where to go with it next.

Hesperian 11:36, 1 November 2013 (UTC)

Looks a lot like what I've already tried in my User:George_Orwell_III/common.css but I was so fixated on mirroring the existing wiki mark-up's layout I might have went overboard in my efforts. I'll try your variant when I get home but I'm betting its going to be the same story (roman #s will align left instead of right & up against list-item block, list-item-marker margin will grow exponentially unless each level wrapped in its own DIV, must test with list-item long enough to wrap [e.g. a typical paragraph's worth] or "hanging-outdent" like marker behaviour won't reveal itself & some others I can't remember). It should "behave" somewhat like the table-based version seen in Executive_Order_13647 among other EOs. Will touch back later today. Thanks. -- George Orwell III (talk) 12:26, 1 November 2013 (UTC)
That said - those stats are surprising indeed. Especially since some of the heaviest hitters are pretty much absent in today's terms. -- George Orwell III (talk) 22:03, 31 October 2013 (UTC)
Yes, I agree. Also some who I expected to be high are not. For example an OCR posting bot was run through the entire Popular Science Monthly, else Ineuw and/or Matt would surely appear. Hesperian 01:17, 1 November 2013 (UTC)

We successfully importedi {{FI}} into it.source; and it's difficult to contain our enthusiasm. Please consider that we are using your User:George_Orwell_III/common.css/dynimg.css, therefore please notify us changes.... if you can. We're working too on a derived idea: it:Template:Box!. --Alex brollo (talk) 09:41, 31 October 2013 (UTC)

I've streamlined it to NOT affect images and links in general - just those falling under a parent element with the .freedImg class. The SPAN NewFreedImg variant continue to be problematic because it prevents many true inline usage of the feature with the current faux block setting. -- George Orwell III (talk) 09:16, 1 November 2013 (UTC)

## positioning of page numbering

Not sure what has occurred, however in Firefox I am now seeing the page numbering in an article like MacCormac, William (DNB12) positioned below the start place of the text. Seems okay in Chrome. — billinghurst sDrewth 15:37, 2 November 2013 (UTC)

Sorry - didn't think the highlight portion affected that. Clear U cache once or twice and let me know if its still hapening. -- George Orwell III (talk) 15:53, 2 November 2013 (UTC)

## My editor has lost + & - functions

My editor has lost + & - functions which has been working with no problems for a very long time. I have changed nothing. George, you have changed my common.js but have you done that again very recently? I see no changes with what you changed in my common.js but I don't think I needed any changes since my editor was working fine before and after that change. Whatever the problem is, it is very recent. —Maury (talk) 15:48, 2 November 2013 (UTC)

Sorry - I haven't touched anything since that day you imported the WikiEditor customization script. What exactly do you mean by + & - functions?

If you mean little bluish-buttons, all in a row - that type of button has been deprecated and is being phased out by the programers. If you mean something else, please explain further. -- George Orwell III (talk) 15:57, 2 November 2013 (UTC)

By + and - I refer to the "bluish bar" where it has the options of "zoom out" showing a (red minus sign), "normal" (shows a magnifying glass) and on the right of that is "zoom in" (enlarge image) which shows a plus sign (colored green) All three changes the size of the image on the right. Zoom out, normal, and zoom in. I often use "zoom in" to make the image larger in the editor so I can magnify the image and read the spellings of Aztec, Toltec, Maya &c names. I didn't think you did anything because I would see that on my watchlist. Kind regards, —Maury (talk) 16:18, 2 November 2013 (UTC)
Well the only thing I can think of is my messing around with {{FI}}, which deals with large images, but it might have affected the smaller button/icon type of images as well. I just narrowed it's focus to be sure - please check your editor again. If that didn't correct it, then its probably something the code folks did in their latest "upgrade". -- George Orwell III (talk) 16:39, 2 November 2013 (UTC)
Nope, it still does not work. I will have to use only horizontal mode but that's okay until the editor breaks again and perhaps that will break in the correct direction. This editor was working last night but not since I have been here today. I think I have made too many edits, something like one million and one. <smile> Well, I want to get back to my project and I thank you George. Respectfully, —Maury (talk) 17:33, 2 November 2013 (UTC)
George, this alternate account works fine using the common.js that my William Maury Morris II account had before the newest common.js was added. Respectfully, Maury Brother Officer (talk) 17:46, 2 November 2013 (UTC)
OK, your .js file has been restored to its state prior to Oct. 26. see if that did anything. -- George Orwell III (talk) 18:26, 2 November 2013 (UTC)
It works now. Thank you. Best, —Maury (talk) 01:20, 3 November 2013 (UTC)

## {{FreedImg}} Redux

Hi. Thanks for the modification in the template whereby I can click and access the image directly. One small issue has cropped up ON THIS PAGE when I used it just now. The caption font-size has been reduced. Is there a solution to this that I can apply? Thanks.— Ineuw talk 22:02, 2 November 2013 (UTC) P.S: If this is the new font size desired, it's fine with me. I know that it's impossible to get the exact size.— Ineuw talk 22:07, 2 November 2013 (UTC)

It's probably not going to stay that way. Long-story short, I re-discovered DevTools (F12 in IE8 & higher) and have been skimming through all the inline/inherited css branches. No exageration - the amount of css cascade applied before load.php/index.php gets around to our "local" or personal attribute settings is INSANE!!!!
The problem, in a nut-shell, is we start roughly with font-size:1em & line-height:normal but by the time wiki-code gets to the stuff folks actually put in the textarea box and submit/save, we're down to (or 'up to' depending on how you look at it I guess) font-size:0.8em & line-height:1.5em.
Find me fs & lh settings you can live with while keeping in mind their "parent" in a typical document structure will most likely be set at font-size:0.8em & line-height:1.5em. -- George Orwell III (talk) 22:21, 2 November 2013 (UTC)
Imagine my reluctance at posting this, knowing full well that there are issues which I don't even know, or think about (like other browsers. etc.). It's best if we leave things as they are for the time being and not have you waste time - especially when there is the "tstyle" option. I am sure that this will be revisited in the future by others as well - in which case we'll find a solution that everyone must live with. I am content. :-)— Ineuw talk 22:40, 2 November 2013 (UTC)

## Page numbering

Hi, George. "Undefined" replaced the page numbering in all articles (e.g., 1911 Encyclopædia Britannica/Allacci, Leone). Clarice Reis (talk) 21:48, 4 November 2013 (UTC)

## Going on with FreedImg idea

Just to let you know that we are furiously working about FreedImg into it.source, the last tool allowing to show a dynamic crop of page image as a temporary image insertion into the text (the 600px thumbnail of the whole page being used by default). If you like, take a look to result it:Pagina:Avventure di Robinson Crusoe.djvu/132 of follow links from it:Template:Ritaglio. --Alex brollo (talk) 09:58, 5 November 2013 (UTC)

## Proofreading status drop down doesn't drop at present

Hi George, can I draw your attention to WS:S#Index:FizeauFresnel1859.pdf not displaying correct status? The drop-down menu for the Status on the Index pages seems indeed to have disappeared and while the codes can still be entered, not many of our people know the codes. I've had a look at Viewer2's suggestion, but I can't figure out if that indeed is what's going on, or if that field is pulling data from somewhere else. Might you have the time to have a look? Thanks, Beeswaxcandle (talk) 07:53, 6 November 2013 (UTC)

Hello, please pardon my barging in — and also thank you @Beeswaxcandle for the above introduction.
I should explain my reasoning, based primarily from reading Wikisource:Scriptorium/Archives/2012-11#Changes_in_ProofreadPage_deployed_with_MediaWiki_1.21-wmf3 and some of the pages that snippet points to:
• Firstly I must clarify that I do not mean to suggest for a moment that MediaWiki:Proofreadpage_index_data_config ever contained the Progess/values clause. On the contrary I suspect some other process (which is beyond my ability to assess) supplied the "missing" values.
• What I am suggesting is that in the absence of restoring the missing logic, a possible alternate solution may be to simply add something like the following and let the "new" PHP logic User:Tpt described stand in.
• Finally, this is my test configuration reverse-engineered from examination of MediaWiki:Proofreadpage index template, and I fully expect it may need further corrections/tweaks for proper deployment. All I can really say is that it "worked on my local system without seriously breaking anything." I am afraid that is about the only recommendation I can realistically commit to at this point. May the undiscovered dragons be merely small ones!
   "Progress": {
"type": "string",
"size": 1,
"default": "",
"label": "Progress",
"values": {
"T": "Done",
"MS": "Ready for Match & Split",
"OCR": "Text Layer Requested",
"L": "Source requires fixing",
"X": "File to check",
"": "Unknown progress"
},
"data": "progress"
},

Humph! So much for trying to show off and use «syntaxhighlight» … doesn't understand lang="json". Viewer2 (talk) 08:55, 6 November 2013 (UTC)

### Suspicions: (i.e. Please prove me wrong!)

Subsequent to above, I've done a little more poking around and come to the conclusion that MediaWiki:IndexForm.js is not being invoked. For the life of me I cannot hazard a guess as to why? In any case, the javascript in this module seems to be the legitimate source for the drop-down logic. Somewhat bizarrely the constants used (progress_T, progress_V, progress_C, progress_MS, progress_OCR, progress_L, progress_X) seem to be all defined in MediaWiki:Common.js, so another possibility is that somehow IndexForm is being invoked, but cannot access its required constants, and subsequently dies friendless and lonely.

I hope some of this rings some bells; but in any case it now gives two completely independent lines of possible address. I shall leave the issue in more knowledgeable hands. Viewer2 (talk) 07:10, 7 November 2013 (UTC)

Well I've added the above values to the "Progress" entry in MediaWiki:Proofreadpage_index_data_config and that seems to work as advertised. I can't speak to the other issue(s) on what is being "called" (if at all) or when..... never mind why. Thanks for the help regardless & please don't hesitate pointing out other flaws in our framework (sadly its been neglected for quite some time now). -- George Orwell III (talk) 01:09, 8 November 2013 (UTC)
Kind of you to say so. Kinder yet to take my floundering attempts at diagnosis seriously. I had truly expected people to choose the javascript solution rather than the json method — shows how much I know.
One further small proviso to consider, which is that I came up with the list of JSON strings before I had discovered the list in MediaWiki:Common.js. In case there is some purist out there who needs the drop-down prompt list to match their expectations, I suspect the list in Common.js might be the up-to-date "expected" set…? Viewer2 (talk) 03:04, 8 November 2013 (UTC)
Done! I matched the list in our Commons.js just to be sure we avoid confusion like you mentioned whenever possible (though the displayed message upon save comes from MediaWiki:Proofreadpage index template in reality). Don't concern yourself about that - one day all templates will reside in the Template space and all messages (strings n' such) will reside in the MediaWiki message space like they were designed to. Now if I can only convince everybody how effin' straight-foward & obvious a concept that really is, I might actually get it done before year's end. That aside - Thanks again. -- George Orwell III (talk) 03:30, 8 November 2013 (UTC)
Excellent! O.K. (& just to prove I really am a world-class P.I.T.A.), how about correcting the spelling in the "Type" value-list, from "Dictionnary" to "Dictionary"? Purely cosmetic effect on the top Book/Journal/etc. drop-down.
I promise to stop bothering you (for a while) after that. Viewer2 (talk) 04:33, 8 November 2013 (UTC)
Also done. Keep the fixes coming - I'll be back tomorrow. - George Orwell III (talk) 04:37, 8 November 2013 (UTC)

## PageNumbers.js

Can you please describe what the issue was that caused you to revert? Thanks --Eliyak T·C 22:33, 7 November 2013 (UTC)

The embedded page numbers no longer appeared at all under all 3 layouts nor did the hide/show toggle option in the left hand menu (though that never worked for me unless set to inline self.proofreadpage_numbers_inline = true; anyway). Still the option always did toggle, just never did anything when the embedded page numbers were down along the left margin vs when set to inline manually.
Did they appear for you before my revert? Otherwise I liked where it was all going though folks were getting a bit rowdy thus the revert to where I left it ~Sunday + Tpt's changes afterwards. -- George Orwell III (talk) 22:44, 7 November 2013 (UTC)
They appeared for me, sure (in 2 browsers) Could it be that you were experiencing a cache issue? What browser were you in?
IE8. Don't think it was a cache issue - even with the IE Dev tool, it showed the loss of both entirely. Plus I learned my lesson over the weekend on how long it takes for changes to really work their way all the way through. -- George Orwell III (talk) 23:13, 7 November 2013 (UTC)
Another possibility is that I switched the page numbers to load after any images, so if you were not patient they would not have come up right away. I thought this was necessary to make them calculated to the right spot, but now I realize we can simply load them, then reposition them when the images load. --Eliyak T·C 23:04, 7 November 2013 (UTC)
Go for it - I'd rather get it fixed than worry about who is whining at the moment - its been broke/obsolete for far too long the way I see it. Please remember - images are always a secondary concern to content (think mobile view here) -- George Orwell III (talk) 23:13, 7 November 2013 (UTC)
This is a bit strange, since my test code works fine in IE8... I will test in that browser when I take it live. --Eliyak T·C 23:38, 7 November 2013 (UTC)
Its working like it never did before (under IE at least) with your last set of test changes applied to the main!! (sorry - the wait was crushing my soul so I went ahead with reverting to you last plus those 2 lines from your sandbox).

Even the highlight seems to focus on the actual point of "page" break - which was hit or miss before all this.

-- George Orwell III (talk) 00:23, 8 November 2013 (UTC)

## Armistice Day

I finished the peer review of Armistice Day. I followed up on the inconsistencies we pointed out but didn't find any need for new removals. I described the new findings on the discussion page of the index. ResScholar (talk) 12:31, 11 November 2013 (UTC)

FYI: I put individual copyright warnings on the index pages so the work could be shown today. ResScholar (talk) 20:29, 11 November 2013 (UTC)

## Regarding {{p}} et al

Hello again.

Pardon my bulk-synchronising the documentation page with the actual template actions. If this was a Bad Idea™, please let me know. I spotted the {{p}} idea and thought/still think it is a winner, then spotted a tiny typo and reasoned if I'm going to change 1 character then why not (checks) 16K of the little sods? I have learned JSON is a fiddly, fiddly beast; so not all is wasted!

No seriously thanks for that. It had to get done at some point, even though technically I(we) had not "finished" developing the premise entirely. Originally, I just wanted to develop the P aragraph tag as an alternative to the over-use (& mis-use?) of DIVs in the most basic of our templates. After interested folks like you came across my initial efforts to mimic the table parsing thing, it dawned on me that maybe expanding the premise to include SPANs and DIVs along with Ps would make for the most ultimate (& most proper?) method for end-usage. I never got off my ass to actual work that idea however so it is what it is.

The other thing is I'm not sure having the template data on the parse sub-page is actually the "right" way to incorporate that or not! -- George Orwell III (talk) 03:23, 20 November 2013 (UTC)

Of course, doing this blindly I completely glossed over the table/paragraph semantics. Thank you for picking this up.

Question: How to best represent the #default={{{1|display:block}}} case in the documentation, as I cannot figure out what you were intending…especially as the {{#if:{{{1|}}}|<p class='{{{class|pclass}}}' style= logic at the top of {{Paragraph_tag}} effectively renders this an unreachable case…?

I warned you on a previous occasion I am a professional P.I.T.(pick an appendage or organ to suit.) Or bitter & twisted (& proud of it.) Take your pick.

Cheers! Viewer2 (talk) 02:38, 20 November 2013 (UTC)

I add things like class and id attributes more out of habit than anything else so they really should not be documented/developed further until it makes sense to include them in the "final" RTL (release to lemmings vs release to manufacturing RTM) version. Do not document those just yet - although my recent exploration of the CSS handed down to us indicates a likely need to standardize the class attribute for additional User inputs somehow (btw; PCLASS is a faux definition used for place-holder/parameter satisfaction purposes only. same with display:block as it is the default for the P aragraph element. They are there just because I personally loath the lack of a graceful-fail/fall-back/default parameter - don't trouble yourself over any of them).

So what do you think?? Is it better/more-feasible to have 3 separate templates (P, SPAN, DIV) each with its own table of attribs & values to call upon or 1 template that rotates (switches?) between those 3 elements with one mega table of attribs & values to call upon?

In addition - isn't something like this better handled with LUA + templates rather than the current approach of just templates? -- George Orwell III (talk) 03:23, 20 November 2013 (UTC)

Thank you for the (kind) response. I am somewhat clearer now on your intentions, and appreciate you letting me in on your reasoning.
My inclination is that {{paragraph tag}} achieves so much in and of itself that to include <div> and <span> support might be an overreach. So I lean towards eventually doing something similar with a separate template (set?) for each tag type. Incidentally, don't forget <li>!
True enough & I think I agree. I guess each element having it's own template makes more sense here in the Wikiworld anyway - User:s need not trip over the various nuances possible for each but not necessarily applicable for the other (primarily the block, inline-block & inline aspect(s)). And the best way to do that is to lock in the choices available under each element so contributing User:s can't apply something outside of the specs/our practices even by accident. In short, I'll worry about additional tags & templates after I'm sure {{P}} tag is 'done'. Thanks -- George Orwell III (talk) 04:28, 20 November 2013 (UTC)
Not to give you nightmares or anything, but I have visions of somebody expecting "span" operations to work over multiple paragraphs (e.g. {{italic block}} Currently a <div>?). I have been guilty myself of using table operations like {{block centre}} to group {{p}} sets. HTML version of rock/paper/scissors (i.e table-cell may wrap div may wrap para may wrap span...)? How to enforce sane usage is a hard issue, to which I have no clear answers. Viewer2 (talk) 12:35, 20 November 2013 (UTC)
Sticking the template data on the parse sub-page is almost certainly the wrong place to put it, but I would prefer somebody putting the effort into making their damned parser look for it properly (i.e. expand the templates, then look at the result), rather than mindlessly expect the end-users to slavishly copy the same things into every template just to satisfy a stupid standard. (If you cannot tell I am a frustrated ex-programmer by now there is just no hope. I see bugs everywhere. Even when not drinking.) In short, good enough to have done it at all—worry about where it should properly live later on when something actually breaks—until then I'd treat it as an unusual presentation form. Too irresponsible?
Not really - I'm inclined to agree with your logic. But again, I don't know enough about the template data extension &/or what it's goals are to really form a lasting opinion either way. So far, I haven't seen anything "worthwhile" come from including the feature. -- George Orwell III (talk) 04:28, 20 November 2013 (UTC)
P.S. Love the RTL/RTM differentiation. Not come across that expression before. I usually settle for LART & associated concepts. Viewer2 (talk) 03:54, 20 November 2013 (UTC)
Well that's what I really feel like around here at times - George Orwell III (talk) 04:28, 20 November 2013 (UTC)
I just realised I omitted to respond to your raising the issue of a LUA approach. Please take these remarks with a suitably large grain of salt, as I am certainly not "toeing the line" here. Kindly place your coffee at a safe distance before reading on:
• I am rather of two minds regarding LUA. The overhead of launching and tearing down a new process for each #invoke must cost pretty highly, so use on a per-paragraph/div/span/whatever basis runs the risk of being even less efficient than the template equivalent (Yes, true blasphemy; but you did ask.)
• On the other hand, having fewer invocations acting upon large slabs of text has a hidden cost of its own. The syntax is deceptive in the sense an #invoke looks like a parser function. However in reality LUA gains control pretty late in the processing phase (I am not sure whether the input to the invoked routine is even "valid" HTML at that point, or part wikicode, or…?) The point is this: for certain actions the LUA code may have to partially parse its input (What happens if this sort of abomination happens to be the result of pre-LUA template expansion: <div>content</span>?), as well as face restrictions upon the output it produces. And in any case, the system must still post-process the result in any case, in order to maintain any kind of "trust" in the process.
• Worms^n, where n large. Clearly more investigation is required, if only in the interests of my own self-education. Surely somebody, somewhere has already addressed this kind of thing?
O.K. rant over (see what I mean?) I truly hope your keyboard survived that. You may safely resume caffeine (or substitute) intake. Viewer2 (talk) 12:35, 20 November 2013 (UTC)
Thanks. I just assumed LUA would be more efficient in the end but I guess that is not always the case - especially with Wiki-markup also in the mix. -- George Orwell III (talk) 04:25, 22 November 2013 (UTC)

## Is this as strange as I think it is?

Hi, on working through some of the Special:WantedCategories I've come across, which appears to be automatically assigned. However, these 11 pages are some of those listed at Index:Secret history of the French court under Richelieu and Mazarin and are transcluded to Secret history of the French court under Richelieu and Mazarin/Chapter I. There is also a list at Page:Secret history of the French court under Richelieu and Mazarin. This is so far out of my normal experience with the Page: ns that I'm not sure whether it's strange, weird, or a brain-fart of a certain person. Should we just trash it? Or is there something rescuable somewhere in there? Thanks, Beeswaxcandle (talk) 09:04, 20 November 2013 (UTC)

This seems like something set-up before the current ProofReading scheme was put into place & is most certainly "wrong" by today's standards.... but that is a lot of fairly decent content to just delete. I'd rather try to locate a source .DjVu or .PDF first and then - as a last resort - move the content into one of those unsourced/unknown mainpspace works without any transclusion, etc. being involved. -- George Orwell III (talk) 10:09, 20 November 2013 (UTC)
Lord help any possible new editors who may see it and then think we all are supposed to edit like that. AdamBMorgan, there is a "convoluted" example for you as those WikiPedians may say. The work doesn't state anything more or less but it sure is pretty. The editor has earned a dozen red roses (with thorns).—Maury (talk) 10:27, 20 November 2013 (UTC)
The source is cited: Google Books - http://www.google.com/books?vid=0nK-jqqYjmuZWxrAHhw4tsd&id=7ahF2CoP-ooC —Maury (talk) 10:31, 20 November 2013 (UTC)
Found a nice copy from the LoC and it's uploaded at Index:Secret History of the French Court under Richelieu and Mazarin.djvu. I'll get on to moving the pages around tomorrow. Thanks for the advice. Beeswaxcandle (talk) 08:51, 21 November 2013 (UTC)
That's great! I was going to go book-dumpster diving for a copy this coming weekend but my free-time is kind of spotty of late so this one is I can scratch off my list. Good job, people. That work did seem worth keeping in my view as well. -- George Orwell III (talk) 04:01, 22 November 2013 (UTC)

## Fixing scans

Hi, thanks for fixing up these scans, as well as some I remember from a while back, and sorry for the delay, this is all new to me (hopefully the derive's ok). I hadn't realised how often these books had missing pages! Rather than keep putting you to the trouble, would you be willing to show me what I'd need to do, and what software to use, etc. to fix it if I come across another one in the future? All the very best! --xensyriaT 06:16, 21 November 2013 (UTC)

There are really only two methods I use anymore - the main one is by "patching" an existing DjVu using the DjVuLibre software bundle to insert/delete pages as needed - the other is by repairing the original PDF with Acrobat Pro 10 and/or ABBYY FineReader 11 before conversion to DjVu by Internet Archive (I don't like the DjVu conversion routine used by ABBYY personally but it does let you erase things like library stamps from the cover page and similar).
The key to either method is really making sure all the pages are there before uploading something to Commons & and that usually means downloading a work locally to inspect it properly. It seems the temptation to go right from URL to Commons is too great to take the time out to verify the source file's structural integrity first.
Anyway, just ask me if you need more feedback/specifics on any of this. -- George Orwell III (talk) 04:15, 22 November 2013 (UTC)
Thanks; I'll try it out next time! --xensyriaT 04:20, 22 November 2013 (UTC)

## Your change tag: fix dbl redirect

Hello.

I assume I did something stupid to prompt the above change. If you can recall what you spotted, and why what I did was wrong please let me know so I can avoid doing it again. (I thought I was creating a redirect from Author:Napoléon Bonaparte to a pre-existing record in Author:Napoleon, but I must have been asleep as that is not how things appear to be right now!)

In any case thank you for fixing things up.

Regards, Viewer2 (talk) 11:34, 23 November 2013 (UTC)

Yeah but the actual content existed @ Author:Napoleon Bonaparte (without the french flag above the 'e') so you created a redirect pointing to another redirect that pointed to the target - thus 'fixed double redirect'.

It happens to everybody so don't worry too much about it. If I don't check the maintenance logs (Special pages in your left hand Tools menu) every time its refreshed to see if any new dbl redirects have been created, someone else eventually does.-- George Orwell III (talk) 20:44, 23 November 2013 (UTC)

Aha/Got it. Thanks for the explanation. I shall try to be more careful next time. Viewer2 (talk) 20:56, 23 November 2013 (UTC)

## pls see reply at Wikisource:Scriptorium#Request_for_div_align.3Dcenter-justify_option Thanks!

re center-justify

## Elision, Really?

Regarding this, after my initial surprise I got a laugh out of this. My ISP changes my IP address on average about every four hours, or so I have observed, and (not that I have been tracking it all that closely) I have never seen the same IP reallocated twice so far. Apart from driving any potential checkuser crazy, I cannot say I get too worked up about it. Any implications I might have missed?

Regards, Viewer2 (talk) 23:12, 28 November 2013 (UTC)

Its just something most admins automatically do per an over-abundance of precaution (or maybe just as a courtesy?) when they come across it. Since my crystal ball is on the fritz, there is no way ascertain how "static" anybody really is so we figure 'why take the chance?'
And the only implication, afaict, is: 'You are prone to making mistakes like everybody else'. Please do not worry about it any further - its not like the Guild of Calamitous Intent are big-time poetry proofreaders or anything. -- George Orwell III (talk) 01:45, 29 November 2013 (UTC)
The amusement remains. Oh, and—in case I hadn't already made it clear—appreciation for your taking such good care of my clumsy tendencies. Viewer2 (talk) 02:12, 29 November 2013 (UTC)

## ref Q

Hello, I added refs here, so (but) I don't know why they don't show up here. Am I missing something? (Thanks.) DanielTom (talk) 08:19, 2 December 2013 (UTC)

You needed a references tag of some kind. I've put {{smallrefs}} in for you. If you'd prefer a larger font change it to <references/>. Beeswaxcandle (talk) 08:30, 2 December 2013 (UTC)
Thanks Bees! Not sure what gave me the idea you had retired! I added "Footnotes" on top, hope that's okay. DanielTom (talk) 09:22, 2 December 2013 (UTC)

## talkback

Commons:User talk:Billinghurst#Quirk in workflowbillinghurst sDrewth 10:20, 3 December 2013 (UTC)