User talk:George Orwell III/Archives/2014

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

MediaWiki:Common.js cleanup

Hello.

I noticed you have recently (bravely) been cleaning up bits of this module. May I just remind you of the "Index-page-dropdown-not-working" issue of about a month-and-a-half ago, which pretty much proved that (at least) these constants within the self.ws_messages block at the top are redundant (I am hoping you have some technique for verifying this because I'm not sure how to check myself!):

• 'progress':'Progress',
• 'progress_T':'Done',
• 'progress_V':'To be validated',
• 'progress_C':'To be proofread',
• 'progress_MS':'Ready for Match & Split',
• 'progress_OCR':'Source file needs an OCR text layer',
• 'progress_L':'Source file is incorrect (missing pages, unordered pages, etc)',
• 'progress_X':'Pagelist needed (to verify file is complete and correct before commencing proofreading)'

---

In addition to the above (which I am pretty sure of!) I suspect these may be unused as well:

• 'volume':'Volume',
• 'school':'School',
• 'book':'Book',
• 'collection':'Collection',
• 'journal':'Journal or magazine',
• 'phdthesis':'Thesis, report',
• 'dictionary':'Dictionary'

There is, of course no truly compelling reason to remove these, and if you consider the risk unacceptable I quite understand. Cheers, Viewer2 (talk) 10:43, 21 December 2013 (UTC)

No problem - I will whack as much as you suggest and sit back to see what happens (I have no clue how to "test" for anything like that). I will give it a bit in between edits because changes have funny way of showing up instantly or up to half-hour later. -- George Orwell III (talk) 10:50, 21 December 2013 (UTC)

O.K. If you are happy to try the "brave" approach, I'd suggest making the change; purging Common.js, and then dummy-editing any Index: page (maybe after purging that too to play it really safe?). If the drop-downs still work on the "Type" and "Progress" fields then that is at least an 80-90% proof. Regrettably making sure of the rest I suspect is the wait-and-see-if-anything-unexpected-breaks as you described. Feel free to blame me if it turns out to be a stupid idea. Viewer2 (talk) 10:59, 21 December 2013 (UTC)

Nope - the progress labels are still needed but the "type" could go - though nuances like "Journal or magazine" would be lost. I'm inclined to restore the whole set. How much of a drag on resources could it be? -- George Orwell III (talk) 11:16, 21 December 2013 (UTC)

I think it would have worked if you hadn't restored the load of MediaWiki:IndexForm.js (i.e.

   mw.loader.load('//en.wikisource.org/w/index.php?title=MediaWiki:IndexForm.js&action=raw&ctype=text/javascript');

—because as far as I know that is the only thing which uses those constants... Viewer2 (talk) 11:25, 21 December 2013 (UTC)

Look mon... if you can't lead the way don't xpect me to, iree? That .js hasn't been stopped from loading for some time now so I don't know what to make of your last. -- George Orwell III (talk) 11:51, 21 December 2013 (UTC)

No problem. Horse dead. Whip exhausted. Candle not worth the game (or is it the other way 'round?) Pardon having wasted your time.

I can only assume I misread your changes. Viewer2 (talk) 12:12, 21 December 2013 (UTC)

I'm sorry - I didn't mean to come off like that. The truth is - I can use all the help I can. The problem is nobody wants to take a week or two "time-out" to address this even though its killing some of us from one upgrade to the next. After looking around and comparing one sister project to another, WikiBooks is the only one who seems to "get it right" in my view & we should be copying their approach moving forward. Very little in the way of site-wide stuff being forced on every user but still lets folks pick and choose features as needed via gadgets instead.

The other problem for us is old.wikisource - where we still import a part of our settings from (though people wonder why the load order is so finicky from one week to the next). Like I said before, I'm in need of wiki-break from here (its not like I have toolbar in the Page: namespace or anything, so why bother?). -- George Orwell III (talk) 12:26, 21 December 2013 (UTC)

'Tis O.K. I have just has a copious-sterca day myself and did not wish to risk offending. I quite understand I should have given more detail from the start rather than assume you were on top of the situation. This is the delta which triggered the "restored load of MediaWiki:IndexForm.js" remark. It looked as if you had restored the load of IndexForm.js in the very same edit you removed the values upon which it relied. I can only assume I can't read when I am as tired as this. And as you quite validly pointed out: "How much of a drag on resources could it be?"

I hope this clears the air a little. Viewer2 (talk) 12:52, 21 December 2013 (UTC)

You must be tired - all that happened there re: .js files was a re-ordering - none of the calls to load each .js were enabled/disabled - I just put that entire section at the top of Common.js and moved the ProofReading/dynamic layout stuff down below it. In a perfect world - the call to import scripts would be at "the bottom" of the main .js file (well at least that is what I've come to realize on my own). -- George Orwell III (talk) 13:01, 21 December 2013 (UTC)

┌─────────────────────────────────┘
This is what I (quite deservedly!) get for firing off a thought without doing proper diligence. I'll try very hard not to do this again. Viewer2 (talk) 23:06, 21 December 2013 (UTC)

Ye Gogs, Little Fishes et al!

Am I the only one who can spot a pattern here, here and here? Man who straddle fence in truly precarious position! For pity's sake: kindly choose between a Javascript or a PHP solution and stick with it. Yes/no? Viewer2 (talk) 06:33, 4 January 2014 (UTC)

Yes please (but when I have gone 'bold' in one direction or the other (or still another?) something either stops working or breaks the whole thing altogether). I am open to any & all "solutions" provided but for now, the best that I do is merely stay current. -- George Orwell III (talk) 06:51, 4 January 2014 (UTC)

I understand and sympathise with the compromises you have to make. However, if/when the ultimate "expert" actually does make an appearance (hint²!) I would hate for you to have to admit you did not apparently know what you are doing. (That is of course much too much too harsh, but I think you get the intent?) Viewer2 (talk) 07:09, 4 January 2014 (UTC)

Technical promiscuity wanted

Hi, sorry if this feels like shopping for admins, but compared to the other ones who might be afraid of breaking Common.js I think you are pretty tech-savvy enough to better handle some of the MediaWiki code as of late. I wanted to point out some of the features I addressed to other admins which were lacking on this site, here and here, and one of which (CentralAuth) you've managed to implement which I am grateful for. I'd like you to consider using the fullurl I pointed out as well, and making the purge function the default for the site as per this proposal. I'm not sure if anyone has wanted to opt-out as of late but I guess you can repurpose the old PurgeTab.js into suppression code

<nowiki>{display: none;}</nowiki>

for the purge function if you feel like it. TeleComNasSprVen (talk) 18:05, 21 December 2013 (UTC)

I'd be happy to make technical changes - if I can get past your assumption that details aren't important. Please, take the current code, make the changes you'd like to see, wrap them in SyntaxHighlight and post it back here.

The purge-tab thing is fine the way it is - a gadget that is pre-enabled for all logged in users. If you think we have alot of annon. traffic making positive contribs, you haven't been here long enough to realize that is just not true. -- George Orwell III (talk) 21:40, 21 December 2013 (UTC)

For MediaWiki:Sp-contributions-footer (and MediaWiki:Sp-contributions-footer/en-gb):

<table id="anontalktext" class="plainlinks" style="font-size:90%; background-color:#F8F8F8; border: 1px solid #B8B8B8; padding: 0.25em 1.0em; clear:both; text-align:center; width:100%;">
<tr>
<td style="width:40px;">[[File:Wikisource-maintenance2.png|frameless|38px]]</td>
<td style="padding:0.25em 1.0em;"><!--
	--><span style="white-space:nowrap;">[[Special:Prefixindex/User:$1/|User's pages]] · </span><!--
	--><span style="white-space:nowrap;">[{{fullurl:Special:ListUsers|limit=1&username={{urlencode:$1}}}} User rights] · </span><!--
	--><span style="white-space:nowrap;">[{{fullurl:tools:~daniel/WikiSense/Gallery.php?wikilang=en&wikifam=.wikisource.org&format=html&img_user_text={{urlencode:$1}}&order=-img_timestamp}} WikiSense] · </span><!--
	--><span style="white-space:nowrap;">[[:meta:Special:CentralAuth/$1|CentralAuth]] · </span><!--
	--><span style="white-space:nowrap;">[{{fullurl:tools:~quentinv57/tools/sulinfo.php?username={{urlencode:$1}}&showblocks=1&showlocked=1}} SUL accounts] · </span><!--
	--><span style="white-space:nowrap;">[{{fullurl:tools:~luxo/contributions/contributions.php?user={{urlencode:$1}}}} Global contribs] · </span><!--
	--><span style="white-space:nowrap;">[//tools.wmflabs.org/xtools/pcount/index.php?name={{urlencode:$1}}&lang=en&wiki=wikisource Edit Counter]</span> <!--
--></td>
<td style="width:40px;">&#160;</td>
</tr>
</table>

For MediaWiki:Common.js append to the page:

/**
 * Action link: Purge (Action menu)
 *
 * @source: www.mediawiki.org/wiki/Snippets/Purge_action
 * @rev: 6
 */
$( function() {
    if ( !$( '#ca-purge' ).length && mw.config.get( 'wgIsArticle' ) ) {
        mw.util.addPortletLink(
            'p-cactions',
            mw.util.getUrl( mw.config.get( 'wgPageName' ), { action: 'purge' } ),
            mw.config.get( 'skin' ) == 'vector' ? 'Purge' : '*',
            'ca-purge',
            'Purge the server cache of this page',
            '*'
        );
    }
});

Difference for the first is changing toolserver.org to fullurl:tools:, support for the second is here but the proposer asked for more tech-savvy people to implement it because he didn't know how himself, as he noted in an edit summary. As to anons not doing anything constructive, I think that's because there's nothing new to construct in Wikisource, we're simply reproducing existing printed works in public domain, unlike Wikipedia and Wikibooks. TeleComNasSprVen (talk) 00:02, 22 December 2013 (UTC)

OK. I took care of the MW changes with a slight modification of what you gave. You had a slash as the delimiter between the CentralAuth & SUL account entries instead of a mid-dot. I hope that doesn't matter but if it does I'd gladly change it to a slash if there is some mysterious valid reason for that.

As for the purge thing - again, as per the previous discussion, I'm not in favor of this until a lot more of the old/duplicate/custom junk is pruned from the current Common.js. Long story short; I'm hoping to mirror WikiBooks approach to site-wide settings. The problem is I'm not all that fluent with java, Lua or JQuery (hence the suicide editing by trial & error).-- George Orwell III (talk) 00:37, 22 December 2013 (UTC)

lol re your section change; to be honest on the internets you gotta have thick skin, and even thicker ones on volunteer-run sites where the volunteers don't really care. I'm actually amazed at some of enwiki Arbcom's draconian censures of their admins, reprimanding them for even one outburst against another editor or using any 'f-word' or some such, and I feel it's much more relaxed at enwikt, enwv et al. But I digress again.

Anyway, the leaving of the dot separator is fine, I don't really prefer any separator over the other. For the Common.js I like him above assumed you knew what you were doing, i.e. writing the code instead of copy-pasting, and I'm sorry I didn't double check your changes. I'm going to work my way up the Common.js and provide some suggestions.

• I think you can remove the XP unicode issues if you feel no one uses XP anymore.
  • LoL. XP SP3, IE8 up and running here. Got hotfix?
• You can also remove the complete list link as I don't think it'll find much use, you're much better off with a more prominent link to oldwikisource closer to the top of the Main Page if you want to keep it, like say next to the four links siteindex, communityportal, news, sandbox.
  • Agreed. Its also associated with MediaWiki:Multilingual-link.js loading at the top. I suppose I can remove that .js from loading as well?
• I'm not sure what the icons on the top right are meant to be so you can test removing that and see what happens, revert afterwards etc.
  • Its to avoid being usurped when Dynamic Layouts are in play in the mainspace - otherswise things like the protection or featured article icons won't appear inline with the article [first] heading. This might no longer be the case since "we've" redone PageNumbers.js recently - I'll have to remember to test that.
• Documentation for withJS/withCSS here; it disallows imports of scripts in User namespace and allows script importing only in MediaWiki namespace. If you choose to keep withJS I feel wikipedia's withJS code is much more elegant.
  • Alright you lost me there. I see the section for it (& follow the basics of the premise) but I don't know if that is security thing or a long-abandoned tweak or what. Need more advantages/disadvantages before acting.

• Actually, I was going to put down that it seems like just another security check that a small wiki like this doesn't really need, but when I look at the mw: documentation again it looks like it's also meant for something else. In other words, I don't really understand this either. I just realized Wikipedia's Common.js deprecated jsMsg which is probably what's cluttering up our Common.js; theirs is:

• /**
   * @source www.mediawiki.org/wiki/Snippets/Load_JS_and_CSS_by_URL
   * @rev 5
   */
  // withCSS
  var extraCSS = mw.util.getParamValue( 'withCSS' );
  if ( extraCSS ) {
  	if ( extraCSS.match( /^MediaWiki:[^&<>=%#]*\.css$/ ) ) {
  		importStylesheet( extraCSS );
  	} else {
  		mw.notify( 'Only pages from the MediaWiki namespace are allowed.', { title: 'Invalid withCSS value' } );
  	}
  }
   
  // withJS
  var extraJS = mw.util.getParamValue( 'withJS' );
  if ( extraJS ) {
  	if ( extraJS.match( /^MediaWiki:[^&<>=%#]*\.js$/ ) ) {
  		importScript( extraJS );
  	} else {
  		mw.notify( 'Only pages from the MediaWiki namespace are allowed.', { title: 'Invalid withJS value' } );
  	}
  }
  

• Basically looks cleaner, so we might as well go with their version.

• I can't read Hebrew.
  • Ditto. Why it needs to be site-wide instead of a User selected gadget is beyond me though.
• this shows hasCache as deprecated. CTRL+F for the comment and replacement.
  • Again; lost me. I don't see "hasCache" in the WP diff.

• Sorry, I misread hasClass as hasCache (because reCache appears in the next line).

• You could move the Faster Collapsible Tables code block to MediaWiki:Common.js/CollapseElements.js like Wikibooks, if as you say Wikibooks does it better.
  • There seems to be too much relating to collapsible there & I could have swore some of that was made part of the skin.php defaults but, again, I'm no expert.
• secure.wikimedia.org deprecated in favor of https:
  • yeah I figured as much
• I think you can move the quality indicators onto a subpage.
  • I'd love to but the pr (proofreading) police would need to sign off on something like that first. I'll make a formal proposal in the coming week, maybe two.

That should cover it for now. TeleComNasSprVen (talk) 02:28, 22 December 2013 (UTC)

Thanks. I'll start fiddling in a bit. Still, all that table collapsing stuff "bothers" me the most.

Curious about your user nick... if I said "B8ZS" to you, would that mean anything to you? -- George Orwell III (talk) 03:08, 22 December 2013 (UTC)

I'm sorry, I have no idea who that is. If I had to guess, I'd say it was a really bad password. TeleComNasSprVen (talk) 04:33, 22 December 2013 (UTC)

Bit 8, Zero substitution. I guess you're not involved in network delivery/transportation. Never mind. But can you please check the contributions footer - those changes are producing 404's here. -- George Orwell III (talk) 04:52, 22 December 2013 (UTC)

{{FIS}} behavior modification requested

Hi. There is a caption display behavior change from {{FI}} in the same context. I often have dual style captions like:

Caption line 1
Caption line 2

which worked fine with {{FI}}, but now with {{FIS}} the style breaks when utilizing <br /> in the text and all formatting is lost. These being the font-size, line-height, and text-align. It's not an urgent issue, but rather I wanted you to be aware of it.— Ineuw talk 05:08, 22 December 2013 (UTC)

I built an example HERE and I can add additional info: Regardless of the text alignment specified, it always looks as if it reverts to left but I think it's really justified. I say this because in one image there was hanging indent specified for a long caption, as

| mleft        = 2em

| indent       = -2em

It was justified and the hanging indent was placed way off to the left. The line height is also ignored.

Not related but may be relevant, this talk page is missing the edit option from the individual posts. — Ineuw talk 00:11, 23 December 2013 (UTC)

OK - its at the point now where less is more.

First, I've provided you with a legend of sorts depicting the defaults for the available parameters governing the image's text caption (when the image is being floated or inline with a larger body of text). You should refer to it whenever you can't seem to get the caption to behave.

Keep in mind caption alignment is most dependent on the talign & tdisplay params (both of which can still be complimented or overridden by the tstyle parameter as before) but can be "tricked" into doing various things by tweaking some of the other setting as well as adding line breaks or non-breaking spaces between words in the caption (examples 2 & 3 in your sandbox).

Finally, please note the mleft parameter is now tmleft (stands for 'text margin-left'). Try not to use it because its more flakey than flawless in most cases & will hopefully be phased out at some point anyway. I don't think too many people have applied it; most folks seem to use the container's margin-right, margin-left (unless I'm mistaken & caption indentation is more common than I can tell). any questions? -- George Orwell III (talk) 02:43, 23 December 2013 (UTC)

Thanks. It's fascinating. I must study it more to understand but it looks great. — Ineuw talk 03:15, 23 December 2013 (UTC)

The template works fine. I think you also commented somewhere about a margin-top parameter. That is unless I dreamed it which can happen. :-) As for hanging indent captions, there are too few to be concerned about the "tmleft". Thanks again. — Ineuw talk 21:59, 23 December 2013 (UTC)

Try cstyle = margin-top: xxx ('cstyle' being container style)

This is what I meant by 'less is more' earlier - I've come to realize there are far too many possible combinations of User needs and situations for FI to be locked into a chain of pre-defined parameters with defaults. If I keep the available named template parameters and their defaults to the bare minimums needed to just to align & resize itself but leave in place the ability for Users: to add/override parameters as needed via a "general" catch-all xstyle= parameter for each element, the possibilities for usage (in theory) becomes limitless. Heck, we can eventually go the table-style parsing route and abbreviate certain style settings if it can be done in a way where even newcomers can grasp the concept and edit using FI from day one.

These particulars are all nice to think about in the abstract but the truth is I can only do & test so much before it becomes self-serving or redundant. More support and refinements are still needed on the FI front. You, among a handful of others, have been great to work with in this aspect to date; I hope it becomes infectious one day. -- George Orwell III (talk) 00:11, 24 December 2013 (UTC)

Please start a discussion rather than unilateral decisions on tools

Hi. Before changing the tools that the community has in place, please have a discussion of what is that you are desiring to do, get a consensus, and then we can inform people what is happening so they can take appropriate action. I have reverted the changes as they took away my favourite and expected tools from ready reach. — billinghurst sDrewth 11:51, 24 December 2013 (UTC)

Granted. Unless you or someone else picks up the load and further develops EditTools to be compatible with WikiEditor / VisualEditor one day, it cannot remain the site-wide default. CharacterInsert (charainsert) is the default now - please disable it and re-enable EditTools in your personal preferences if you wish. (clear your caches people!!). More info when I get around to tidying up. -- George Orwell III (talk) 12:01, 24 December 2013 (UTC)

FFS, it is Xmas eve, I just want to edit, I don't want to have to frig around with preferences etc. Announce to the community, let us know ahead of time, what they will need to do, what to expect, and with some leeway to implement. Forcing a new default over an old default is bloody idiotic and guaranteed to cause issues. — billinghurst sDrewth 12:13, 24 December 2013 (UTC)

Sorry but I didn't expect anyone to care on this date. If you'd give it a chance all should have been made right (without anyone knowing even - oh well too late for That). Its already almost exactly the same set of characters if not better & can be floated outside the Fieldset & Edit form like the old one was way below the gray edit form field... but I just couldn't get all those foreign characters to render properly, making the transfer from one to the other a bit complicated. I had hoped those who can work in those characer sets would pitch in and miror the old within the new MediaWiki talk:Gadget-charinsert.js. -- George Orwell III (talk) 12:26, 24 December 2013 (UTC)

I don't expect this opinion to gain much acceptance—nor should it be taken as criticism of your efforts, laudable as they are! However, in my humble view anybody who is relying upon this category of gadget simply has not seriously thought out the implications. I simply never use it—bar for exactly one purpose: it is a moderately handy reference of what symbols are likely to be universally effective across the various browsers.

As you are probably already aware I am fairly loyal to Firefox, and its so-called abcTajpu extension. This means I can generate all of the "special characters" I desire for all sites—not merely the WS-and-family ones. When push comes to shove, I completely agree with George's comments (made elsewhere) that this gadget serves as a port-of-last-resort-fallback, and to expect anything more is at best naïve in the extreme. My 2¢ (guess how I produced that glyph? Frankly I have no idea if Gadget-charinsert even momentarily supports it—and should not need to care either—Q.E.D.)

Too blunt? Viewer2 (talk) 03:34, 25 December 2013 (UTC)

More 'too soon' than was 'too blunt'

Sadly - the only way to show the community how completely worthless & stupid this add-on is, was to update it. I'm well aware of those 'other browsers' out there and how pointless loading this (script reliant version) as a site-wide default was. But you couldn't convince anybody around here of that until you first draw attention to the matter at then spend the time guiding and honing the focus until the community as a whole reaches the inevitable conclusion here "all on their own" (oh... I can turn that off or oh... I can tweak that). So what is going to take place here is a complete overhaul of the feature until its "perfect" followed by removal as a site wide-default. In the end, hopefully only a handful of users will come to still "rely" on it; but that is their problem, if any trouble at all, and not the community's (which is the way should have been all along, no?) -- George Orwell III (talk) 03:52, 25 December 2013 (UTC)

You are preaching to the converted—I am on your side in this matter. In fact I only realised you'd responded when I came back to draw your attention to a consequence of your introducing me to…(well, remember "Penney for a Penney"—your spelling?): Long story short. Viewer2 (talk) 04:05, 25 December 2013 (UTC)

Humble? My arse! Completely pompous claptrap. I want something easy to get sets of characters, and it was a means that worked and you have fouled it up, and you now make my editing difficult. I am getting totally fed up with the unilateral changes, and the lack of concern for users, and the constant changes without reference to the community. I DON'T BLINKING WANT TO HAVE TO PROBLEM SOLVE TOOLEDITING ISSUES EVERY TIME I COME TO DO SOME WORK ON SOMETHING. THIS IS COMPLETE BULLSHIT. @Viewer2. Oh please! Unless you are going to plug in the characters for all my edits, go and kiss arse eleswhere, this is not about you and your freaking halo, it is about making it easy people to edit and remember that this is a community where we consult. — billinghurst sDrewth 11:19, 29 December 2013 (UTC)

@Billinghurst knows precisely what my answer is and will always be. Diagrams will be only provided upon his demonstrated need for them! Viewer2 (talk) 06:33, 4 January 2014 (UTC)

Did you disable CharInsert and enable Old Edit Tools in your user preferences - gadgets tab or not? -- George Orwell III (talk) 11:29, 29 December 2013 (UTC)

Never mind - enable CharInsert & disable Old Edit Tools. I inserted a command in your Common.js file to move CharInsert back out of the fieldset edit form and display it under the edit form like the old EditTools gadget did. Please note: one day, sooner rather than later, inserting "junk" outside of the edit form will be impossible to do; at that point we either have to find a way to insert the character sets box under the Save Page button container (don't think that is possible because different namespaces will have different add-ons appearing there) or you'll just have to adopt CharInsert as it stands now, then. All these custom toolbar buttons / additional insertable character sets will all be done through the vector skin and the WikiEditor extension (eventually, worse than that - VisualEditor). -- George Orwell III (talk) 11:58, 29 December 2013 (UTC)

Broken ref template

We already have (broken) ref categorisation in place, and the templates are not needed, and had previously been deleted anyway. For all the flavours of break, we only really have a couple — empty tags, or forgotten reference markers — both of which I fix weekly, or thereabouts. — billinghurst sDrewth 12:24, 28 December 2013 (UTC)

Page namespace mouse scrolling issues

Greetings and wishing you a very happy and problem free new year.

This post is an exploration of the possibility to correct a change introduced by the last two mw software updates. I didn't want to post this in the Scriptorium because no one reacted to my first post: HERE.

Specifically, I am referring to the Page namespace edit mode, using the over & under display & edit, where previously the upper display window was at least one row higher, and the default display was the window's width, so that the horizontal scroll bar was not activated in the default size. I could scroll the .djvu image about one row at a time using the mouse, and very easily find the corresponding row in the text layer and vice versa - a proofreading method I consider superior to the side by side editing mode. Furthermore, with a double click, I was able to enlarge or diminish the image with the same scroll button.

I was wondering if there may be way to re-implement the previous functions in my personal .js and bypass community practices. Currently, I switched my focus to the PSM main namespace articles - categorizing - because I am unable to retrain myself to proofread with the new system where inexact scrolling of the text is with the vertical scroll bar on the right side and any erroneous scroll movement makes me loose the place, (I am a left handed mouse user leaving my right hand free for the keyboard).

The categorization will soon be completed which only leaves me the somewhat less important work of searching for the missing authors. Afterwards, I am not relishing the thought of proofreading ~40,000 more pages under the current conditions. Thanks for reading this. — Ineuw talk 03:25, 31 December 2013 (UTC)

Did this past Tuesday's update change anything for you re: the above? It pretty much put me back to where I was before December rolled around - maybe you should try that cache clearing thing one more time and report back. -- George Orwell III (talk) 20:40, 2 January 2014 (UTC)

Happy New Year. I am aware of only two cache clearing options. One is the page cache (clock), and the other is the file cache purge on the Index page. In any case these two changed nothing. If there are any other cache purging utilities I don't know about them.— Ineuw talk 00:11, 3 January 2014 (UTC)

Hmmm... maybe more troubleshooting is needed here because I have just this past Tuesday regained nearly all what you describe as "gone" with the "past 2 updates or so" back again. For starters - can you reproduce the same when you're not logged in? What about on the test site? -- George Orwell III (talk) 00:48, 3 January 2014 (UTC)

Think I found the problem. I tried the test site, both logged and not logged in. Please bear with me until I test the issue thoroughly by proofreading and will get back to you, as there was a change which I may have missed. — Ineuw talk 01:47, 3 January 2014 (UTC)

errr... you realize the test site is testing the upcoming wmf9 release - ready for next-Tuesday's, Jan 7th roll-out - while we (here on this site where my talk page is) is only up to wmf8. Plus you may need to set your preferences on the test site. I was more concerned about not-logged-in and "here" actually.

And didn't you get jammed up with old cookies or something not too long ago as well? -- George Orwell III (talk) 02:17, 3 January 2014 (UTC)

It's on the test site I realized that the mouse behavior has changed again and now it works with a minor alteration which I just have to get used to through practice. Also thanks for the cookie reminder. I cleared all cookies, and re-logged in.— Ineuw talk 03:31, 3 January 2014 (UTC)

Testing

Test 123

Testing

Test 123

Need help from Bengali Wikisource

Hi, George Orwell III, I am from bnwikiource.I am going to re-organized our bnwikiource, with latest js & css, from enwikisource. I have import all necessary js & css files from Wikisource. I have found some problem in two area, so I need some help from you. Please help me.

MAIN PAGE This is my proposed main page https://bn.wikisource.org/wiki/Main_Page1 which is just copy-paste code from https://en.wikisource.org/wiki/Main_Page, but left & right column not adjusted as shown in enws.

• https://bn.wikisource.org/wiki/Mediawiki:Common.css
• https://bn.wikisource.org/wiki/Mediawiki:Common.css/Boxes.css
• https://bn.wikisource.org/wiki/Mediawiki:Common.css/Lists.css
• https://bn.wikisource.org/wiki/Mediawiki:Common.css/Mainpage.css
• https://bn.wikisource.org/wiki/Mediawiki:Common.css/Tweaks.css
• https://bn.wikisource.org/wiki/Mediawiki:Common.js
• https://bn.wikisource.org/wiki/Mediawiki:Common.js/IEFixes.js
• https://bn.wikisource.org/wiki/Mediawiki:Common.js/watchlist.js

EDIT TOOL..

Edittool not coming ...

• https://bn.wikisource.org/wiki/Mediawiki:Edittools
• https://bn.wikisource.org/wiki/Mediawiki:Gadget-Edittools
• https://bn.wikisource.org/wiki/Mediawiki:Gadget-Edittools.js

Thanking you in advance. --Jayantanth (talk) 06:10, 11 January 2014 (UTC)

For starters, we don't use EditTools anymore but CharInsert enabled by default for everyone instead.....

• https://en.wikisource.org/wiki/Mediawiki:Gadget-Charinsert
• https://en.wikisource.org/wiki/Mediawiki:Gadget-Charinsert.js
• https://en.wikisource.org/wiki/Mediawiki:Gadget-Charinsert.css

There are ways to make sets appear in the old EditTools area far under the edit form as before too.

Let me take a look at the others when I have some time... -- George Orwell III (talk) 07:05, 11 January 2014 (UTC)

Hi George, Could you please have a look for our issues.Jayantanth (talk) 21:00, 7 March 2014 (UTC)

CSS Content Semantics

Hello. Just thought I'd better point out that this as used here:

div.dotLeader1 span.dotStart:after {
	float: left;
	width: 0px;
	white-space: nowrap;
	content: ". . . . . . . . . . . . . . . . . . . . "
}

—simply doesn't work in Firefox (maybe it does for you in Internet Explorer?) FF renders it as literal characters i.e. ".-&-#-x-2-0-0-8.-&-#-x-2-0-0-8", instead of substituting the punctuation space I think you probably intended instead. Viewer2 (talk) 13:31, 12 January 2014 (UTC)

font-size:, line-height style interdependencies

I was fascinated to see your change remark here, to the effect line-height: is ineffective unless font-size: is numeric. I had previously understood "smaller" to be a synonym for "83%" but admit I didn't know where the association was made. Is your rule universal, or simply a particular browser worst case? Either way: useful to know. Viewer2 (talk) 23:54, 12 January 2014 (UTC)

Only "smaller" & "larger" are relative sizings. They make an existing absolute sizings "go" up or down 1 notch depending on which is used.

Absolute sizes [ xx-small | x-small | small | medium | large | x-large | xx-large ] refers to the scaling factor being applied. They do not have directly corresponding percentage values though HTML roughly lines them up this way......

CSS absolute-size values	xx-small	x-small	small	medium	large	x-large	xx-large	?
scaling factor	3/5	3/4	8/9	1	6/5	3/2	2/1	3/1
HTML headings	h6		h5	h4	h3	h2	h1
HTML font sizes	1		2	3	4	5	6	7

Both absolute & their relative modifiers are dependent on your browsers built in font tables & junk. This is what makes haters out of FF, Chrome and IE users - dumbed-down leftovers from the AOL era! - and while it "looks great" on your pooter', the same setting looks like total sh!t on anothers. Always try to use "real" sizes first - those measured in pt, em, px, etc. followed by percentages.

For basically the same nuance, something called a strut can only be properly calculated by "line-height" when its numeric in nature - not a factor of something numeric in nature. Again, your browser compensates for all this "wiggle-room" one way while making someone else & their browser go nuts another way. Long story short - always use a real number before using a factor. -- George Orwell III (talk) 00:50, 13 January 2014 (UTC)

At the risk of ticking off Billinghurst again (I refer prior and standing response) brilliant answer. Thank you very much for pulling the threads together. Viewer2 (talk) 01:19, 13 January 2014 (UTC)

If it's any help, the point sizes for the HTML font sizes are 1=8pt; 2=10pt; 3=12pt; 4=14pt; 5=18pt; 6=24pt; 7=36pt. Beeswaxcandle (talk) 23:00, 13 January 2014 (UTC)

{{FreedImg}} <math> support?

I'd have posted this at the Scriptorium only the old discussions regarding FI seem to have dropped off into the archives. As you probably know at the bottom of {{FreedImg/doc}} there is a footnote warning that use of the |type=user|file=/<math> variant is only supported under certain conditions.

Well today this blog entry popped up on my radar. Assuming it is quoting any kind of official line I take it to imply the one mode FI relies upon is in the removal pipeline (the visual editor is mentioned, so maybe it makes that project too hard?)

On the assumption you might see more of this kind of announcement than I do should I be concerned? Viewer2 (talk) 07:56, 13 January 2014 (UTC)

Custom user character set of CharInsert disaappears

Hi. I've been testing the CharInsert feature and noticed that the characters (and the double headed arrow) of the "User:" randomly disappear and reappear. On disappearance, the list freezes.

At first, I thought that by clearing the page cache, (the clock), or refreshing the page (Ctrl+F5), or clearing the browser cache makes it reappear but the only action which restores the character set is the clearing of the browser cache. However, this lasts for only a page or two. So, I set the browser cache to 0, two hours ago. Unfortunately, the character set appears and disappears intermittently. here is a screenshot. I gladly test any and all editing ideas, so this is not a complaint, but just to let you know what's happening under continuous use.— Ineuw talk 16:34, 22 January 2014 (UTC)

I give up. It seems I can't help you no matter what I try. -- George Orwell III (talk) 11:06, 23 January 2014 (UTC)

Dear GO3, I am afraid that you misunderstood my post. You have given me an IMMENSE amount of help! As I said before, I am only reporting to you. I am more than happy to test your, and others' software ideas. I benefit from them greatly and especially in this particular case. I wholly agree with your view that the custom edit toolbar is a deprecated idea. I was VERY surprised that they bothered to repair the problem (to a degree), considering their dismissive replies to my Bugzilla reports. I felt grateful to those, behind the scenes, who had a hand in this, while also realizing that they don't have a better solution as yet. Your solution is very elegant.

FYI, I've tested Alex brollo's editing tools as well, and the only reason I don't use them is because I already had all the elements in place for PSM work in Windows. But was looking forward to implementing them & others' in Xubuntu (I have a dual boot desktop) and perhaps in Mac (I have an older Intel Macbook with OSX 10.75 which for the time being, has other issues which I am not used to).

If you give up, give it up for now, but I hope that you'll revisit the issue at a later date. I will continue testing it and learn from it.— Ineuw talk 16:51, 23 January 2014 (UTC)

Bugzilla 54144 request regarding $wgAllowImageTag

Received this message Bugzilla 54144 this morning. Someone is asking for more info, so I thought it's better to contact you.— Ineuw talk 13:49, 25 January 2014 (UTC)

Main ns footer header incorrect width

Have a poke at Men-at-the-Bar/Chalk, William Swinborne as example of main ns page where the footer component has broken the formatting and going full width of the page, over the left hand channel for page numbering. — billinghurst sDrewth 14:11, 25 January 2014 (UTC)

Huh. Seems to be fixed now--did anyone do anything? —Clockery Fairfeld [sic] 14:23, 25 January 2014 (UTC) Scratch that! Got it here. —Clockery Fairfeld [sic] 14:24, 25 January 2014 (UTC)

And the issue is _______? -- George Orwell III (talk) 22:38, 25 January 2014 (UTC)

Sorry, I had to go then. I think what Billinghurst means is that the footer section goes further left than is needed, over the space where the page numbering usually is. On the other hand, I don't even know whether this is default or not, so... —Clockery Fairfeld [sic] 03:33, 26 January 2014 (UTC)

'Further left than needed'? Needed for what exactly?

Look, you (or he?) are just making stuff up because you've become sooooooo comfortable to the broken rendering of dynamic layouts all these years, it seems you don't know up from down anymore. The header wasn't suppose to resize with the text; the footer wasn't suppose to resize with the text, all VIAF authority control bars were never suppose to reisize with the text nor should have the license banners. WHY WOULD THEY?

The only reason they do is because ThomasV couldn't get DL to work without corrupting the entire default skin generated content in the process. Coming up with that faux virtual header to replace the standard header template was going to be part of the solution to fixing all that - but again - he never got that far. You all think that its some sort of feature because its since been hijacked to hand down parameters from other namespaces or some similar nonsense.

So you see, its not broke at all but fixed back to it's proper state. The next phase is freeing the header from being subject to dynamic layouts too along with the license/viaf/etc. banners btw. -- George Orwell III (talk) 03:56, 26 January 2014 (UTC)

Calm down, calm down, I got it. I don't find any problem with it, anyway--I was just saying what I thought he meant... thanks for the explanation. —Clockery Fairfeld [sic] 04:14, 26 January 2014 (UTC)

GOIII it is a changed width to what it had been, and to me the header and footer being of different widths looks weird If you would prefer, I will label this the Main ns header is incorrect width, I am just looking for the same width on both, and whichever is easiest to get them that way.

I just wish that you would discuss these changes with the community rather than your unilateral decisions. No one wants edit wars, and your grumpiness and stridency about these make others not edit such things, and by de facto you get your way. Please consider that others have their opinions, and they are entitled to them, and entitled to express them without you going off the deep-end. — billinghurst sDrewth 04:21, 27 January 2014 (UTC)

Discuss what?? Its broken, you accepted that, you moved on and I didn't. Does that make it less broken somehow? Its fine because you've moved on to x, y or z? The passage of time and the indifference borne as a result makes it all OK somehow today?

Look, I'm working the problems that I know and that I see. You've just come to accept them is all. Deal with that fact, raise whatever point you feel needs to be raised, argue whatever you think is right or whatever you think I'm doing "wrong -- I'm confident in the knowledge of what I speak, of what I've managed to get done and of what still needs to be done; the question is are you?

I don't think its as much as you think you do -- not for some time now -- or you wouldn't be discovering months old changes for the first time this week. In my opinion your attention is spread too thin and you're hissy fit over the EditTools episode just reinforced that for me. I listened to and worked with "others" and their "opinions" on that as well (granted that there were not many who voiced anything negative at all). Still, you prattled off a rant, then up and vanished. I still took the time to try and appease your concerns by applying a fix to restore the tools position & content - you didn't respond either way. Wtf else was I suppose do for you? And tell me again who is not listening, investing the time and not considerate of others. ME? That's rich! :) -- George Orwell III (talk) 05:07, 27 January 2014 (UTC)

As for footer: as far as I'm concerned; its fine. The footer is outside the effects of dynamic layouts and eventually so will anything else similar applied at the end of the textarea field like license banners. Things at the begining of the textarea field, like the header template (& the hidden WSdata its hosting), will also be independent of dynamic layouts once Tpt & Co. get the .phps up to provide the PR & DL schemes independent of any javascript requirements. Once both the start and end textarea-applied templates are outside of the effects of dynamic content layouts, sidenotes can then be fixed once & for all. If we need any template to "be dynamic" in addition to the content (like in Layout 3), a separate routine loading after the content is re-formatted will need to be applied (not difficult). This would also open up the possibilities for somesort of overhaul of the header template as per Adam's inquiry the same in WS:S.

And your plan to address all that is...? -- George Orwell III (talk) 05:07, 27 January 2014 (UTC)

If it has been broken for a period and that I have just noticed the break more indicates that I have been working on longer pages, and not transcluding short biographical works. I left a note, that was not about time, just that it was broken, there was no criticism, zip, it was a factual report as I saw it. The spray at Clockery was surely unnecessary.

To the other personal bits, fire away I have broad shoulders, I am not however joining that battle, there will be no winners. Thanks for efforts to fix edittools, that is very much appreciated. — billinghurst sDrewth 14:03, 27 January 2014 (UTC)

I guess the fact the appearance of any footer at all on pages not long enough for the needed "scrolling into/out of view" is just another [broken] point 'lost' on folks over the years of not questioning what ThomasV had dealt the community on day one of roll-out (if the article is that short, I agree - a nav footer is distracting). Hopefully I'll get to addressing that after the more important stuff gets done; maybe sooner if I find a solution on my own. -- George Orwell III (talk) 14:24, 27 January 2014 (UTC)

Daphne's father or Diana's father?

Hi George, I see you've reverted my edit on Ovid's poem Apollo and Daphne. More specifically this part from verse 487: “dedit hoc pater ante Dianae.” This was translated as "Previously Daphne’s father allowed this." I changed this to "Previously Diana's father allowed this." I'm not the best translator around but I'm pretty confident it's supposed to be Diana's father considering Dianae is just the genitive of Diana, the goddess of the hunt. The genitive of Daphne would be Daphnes since it's a Greek name. Can you give me reasons as to why this wouldn't be correct? Plusboy (talk) 12:44, 26 January 2014 (UTC)

I reverted myself in light of your assertion above. -- George Orwell III (talk) 14:11, 26 January 2014 (UTC)

Zionist Peel Commission resolution

Apparently "The source document of this text is not known" has meaning here different from what it means in ordinary English, and "source" doesn't mean the same as what it does at en.wikipedia (where I'm an admin). Perhaps the wording should be changed to say what it actually means. The absence of a scan is an entirely different matter from the absence of a source.

If a scan is on archive.org, can that be given as the "source" or must it be copied to commons?

Zero0000 (talk) 01:36, 27 January 2014 (UTC)

@Zero0000: the template is to be used where we do not know the source of the text that is pasted here. If we are going to proofread/validate it, then it needs a source that includes year of publication, edition, etc. or even from whence it was pasted on the web. If it sits nude as pasted text, it gets a {{no source}}. If you have a source, then use the edition parameter in the header, and on the corresponding talk page put a {{textinfo}} with a pointer to archive.org. That said, we will always prefer a commons version as then we can proofread/validate. — billinghurst sDrewth 04:33, 27 January 2014 (UTC)

@Billinghurst: It already has a complete citation including year and page numbers (everything it would have in a scholarly publication). Nothing nude about it. It seems that what you want is not a "source" but a "scan of the source". You should say so; I have no objection at all to providing a scan and I like that as a standard. What I object to is a tag saying that the source is not known, when the source is clearly stated. It's like a badge of shame. What it should say is something like "No scan of this document has been provided", which would be true and useful to readers. At the moment it states a falsehood and is sort of insulting. Zero0000 (talk) 05:15, 27 January 2014 (UTC)

Mine was a general response about the use of template, not specific to any particular use. — billinghurst sDrewth 09:56, 27 January 2014 (UTC)

@Zero0000, @Billinghurst:. While a scan is overwhelmingly preferred, it is not currently essential (unlike de.ws, for example). "Source" here is closer to Commons' use of the term; ie. where did you get this text? If you copied it from Project Gutenberg or the Internet Archive, please say so. If you transcribed it manually from a physical copy, please say that instead. Practically, this corresponds to a reference on en.wp, so the fidelity of the text can be verified by any other user. (For the record, the hierarchy of preference is roughly: Scan on Commons > Scan Elsewhere Online > Online Text > Offline Text (eg. a library book), all of which are allowed.) - AdamBMorgan (talk) 09:09, 27 January 2014 (UTC)

Djvu upload advise is sought

Hi GO3. Index:Popular Science Monthly Volume 66.djvu contains two unreadable pages (djvu nos. 526 & 527) with the total page count of 616. Luckily (for me), I found another clean AI copy with the page count of 598 pages. By removing two blank pages at the beginning, the two volumes match up perfectly from djvu 1 to 589. The additional pages at the back of the current Commons copy are either ads or empties. My problem is not the upload, but the text layer with a lot of proofread pages. How do I protect these if I upload a new copy? Thanks in advance?— Ineuw talk 16:15, 30 January 2014 (UTC)

Once a page is created in the Page: namespace, regardless if the content saved is from a text-layer dump or added/edited manually later, the text-layer to File: to Page: relationship is over. What you have text-wise in the Page: namespace now will be what you have even if the source file is replaced - only the thumbnail images will change. And only pages not yet created at all at the time of the source file's replacement will reflect a text dump from the new source file (Vol66 seems to have all its Pages: created already so this is also not an issue in your case).

stupid question: why replace the entire file instead of just the two problematic pages? -- George Orwell III (talk) 00:24, 31 January 2014 (UTC)

Not a stupid question, it was the easiest way to do it and I still have the same size upload. (I've been sitting on this for the past 3 months). Then, because of my ignorance about the text layer. I have several others with small modifications in which I have to delete in the middle and then replace. Another reason is that it has a few pages less of adverts which are non essential.— Ineuw talk 00:37, 31 January 2014 (UTC)

Suit yourself. Seems like testing the djvu-proofreadings gods for no good reason to me, however. What about the changes I made to Vol. 17? No longer "blurry" here. -- George Orwell III (talk) 02:06, 31 January 2014 (UTC)

I would have inserted the bad pages if the two volumes would have been different in other ways as well. Also, I am also happy to report that PSM Volume 17 displayed perfectly until I changed my editor. .— Ineuw talk 02:17, 31 January 2014 (UTC)

Testimony of a convert (to the new wiki editor)

Dear GO3. Everything, including the Charinsert works great. Thanks for all your efforts to help me get going. — Ineuw talk 15:46, 31 January 2014 (UTC)

Just imagine when we get to turn off the old toolbar component for good. Those original pieces worked well for us all this time but are now obsolete and are just slowing everybody down (not to mention all the conflicts they can cause). The sooner they go, the better. -- George Orwell III (talk) 18:49, 31 January 2014 (UTC)

I've tested the Find and Find/Replace of the new editor and it works fine. It doesn't need the / /g parameter for global replacement. One enhancement would be welcome is to be able to insert a CharInsert selection into the Find/Replace fields. Another minor issue discovered is that an echo of a text line appears imprinted on the CharInsert characters but it must be a browser issue because when the browser vertical bar was moved (I tried to locate the origin of the echoed text), it disappeared.— Ineuw talk 15:07, 1 February 2014 (UTC)

P.S: I've uploaded THIS IMAGE to show the echo. In other cases, the echo is more prominent and covers the character selection.

Did that start happening "today"? I only ask because I added the "underline" and "strikeout" buttons yesterday to your .js and am wondering if that is causing it. -- George Orwell III (talk) 18:18, 1 February 2014 (UTC)

No. Noticed it after CharInsert began to work trouble free. This happens with any set selection, not just User. It's not your code that causes it. Remember, I wouldn't have noticed it before because I always reverted to my toolbar. I suspect that the implementation of CharInsert with some ill defined frame is the cause of it. Additional info: if I notice it when proofreading/correcting row number 5, the echo is a line 8 or 9 rows below it.

Weird. Never saw or heard anything like that. I'll keep working it, though I haven't a clue how something like that could be happening - is it always happening in the Page: namespace or all namespaces? - George Orwell III (talk) 18:52, 1 February 2014 (UTC)

Think I found the reason. I was adjusting the Edit window settings from 12 rows to 11. Now, I reset it to 12 and will post here the results.— Ineuw talk 21:58, 1 February 2014 (UTC)

I believe the default is 25, no? Might as well try that too in case 12 fails as well. -- George Orwell III (talk) 22:49, 1 February 2014 (UTC)

Will do so.— Ineuw talk 23:36, 1 February 2014 (UTC)

┌─────────────────────────────────┘

Edit box text echo anomaly

Just FYI, to report back on the issue of the text echo mentioned directly above, Over the past couple of days, I've had a chance to test several window sizes. There is no behavior difference between various edit box sizes. It occurs sometimes and only when the a text line is cut in half by the edit box border while selecting a CharInsert character! I can recreate the echo in one out of four tries. I can do this with any window size, 10, 11, 12, 15, 20 or 25. In my layout of upper display and lower edit mode, the preferred window size is 10 to 12 rows. Otherwise, the upper display and the Charinsert are not wholly visible simultaneously.

What I immediately noticed after switching to the new editor. is that in the Page namespace, the line height of the text layer is greater in the new than in the old editor - thinking that the edit window size vs line height is not divisible? Another of (my) theory is that the CSS definitions of the two elements overlap? — Ineuw talk 21:41, 4 February 2014 (UTC)

Don't think so. I'm starting to think it has something to do with selecting Canada/English just like it sometimes does for those in Great Britain selecting English. For example, I blanked the menu titles "Zoom" and "Other" from the WikiEditor Proofreading Tools menu months ago and I noticed they still render for you from your screen grab of the other day. I think there is some sort of difference being envoked from those settings because, according to the IE8 debugger, there are no noticeable differences in line height or anything else between the old editor and WikiEditor here. I will look into this further as free time permits. -- George Orwell III (talk) 00:23, 5 February 2014 (UTC)

Update: I've forced the background & background-color to "white" in MediaWiki:Gadget-charinsert.css. Lets see if that made any difference on bleed-thrus. -- George Orwell III (talk) 00:56, 5 February 2014 (UTC)

Gadget-charinsert.css and the Page namespace

Hi. Copied Gadget-charinsert.css to my common.css (since removed), and instantly noticed that this .css not affect the margins & padding of the Page namespace CharInsert layout. In fact, the Edit boxes and Charinsert frame, while identical in every namespace, it's different in the page namespace layout. Please compare any CharInsert layout with the one on the text edit page. This indicates that the problem is not the Charinsert.css but the text edit .css. — Ineuw talk 16:54, 6 February 2014 (UTC)

Thanks for your observations but if that is the case, its out of my hands. You already know the Page: namespace needs further refinement to be absolved of the old toolbar scheme and, at least in the main namespace, we need to be "free" of dynamic layouts a bit more in order to isolate textarea (text box) properly in both edit & view modes. My real concern was stopping the "bleed" through into the CharInsert bar and you didn't mention anything about that still happening or not. -- George Orwell III (talk) 23:18, 7 February 2014 (UTC)

Just came to this post to give you some more info, and thus read your reply. I don't expect/want you to do anything, just wanted to keep you up to date with some additional info. First to answer your question. Yes, it bleeds into the CharInsert whenever I select a character from the CharInsert list and the upper portion of the text is visible above the border. But, a second selection makes it disappear. The reason I post here now is because it bleeds into the footer in the same manner, when the header/footer is visible! I just noticed this because usually I work with the h/f closed. Think I will search Bugzilla and post a Bugzilla report accompanied by screenshots if no one else has.— Ineuw talk 01:59, 8 February 2014 (UTC)

The bugzilla report

Hi. I made a half-donkeyed mess when created the bug report about the echo spilling over the border. . I should have first reported that without enabling the legacy edit toolbar, the enhanced toolbar & edit layout doesn't show. This was confirmed by Andre Klapper, but I confused him when I imbedded my reply to his inquiry about why both tool bars were enabled, then issue got messed up. So now, I am waiting for him to wake up (I guess he's in Germany), and hopefully resolve the issue of the enhanced editor.

Only when that is resolved, we'll be sure whether the text spillover is related or not. So, in the meanwhile I had to go back and use the legacy editor until everything is fixed. There is no text spillover, and CharInsert works perfect.

My assumption, that the two are related, is based on when the two editors are activated, their .css definitions overlap. First, the legacy editor has a "sunken" 3 dimensional appearance, while the enhanced editor is flat. The text echo/spillover ONLY occurs when the lower border slices through a line of text at a certain interval. I can regularly repeat this - when selecting Italic text. I was also correct that the line height of the two editors differ by 1 pixel. The legacy is 4 pixels high and the enhanced editor is 5 pixels. Doing the math, I can predict which line will echo. — Ineuw talk 03:50, 11 February 2014 (UTC) P.S: The line height difference affects the number of rows one can use in editing. The enhanced layout further reduces the screen's vertical space.— Ineuw talk 04:38, 11 February 2014 (UTC)

Just in case you're interested, here is the Bugzilla link to the corrected report: Enhanced editor is not visible in Wikisource Page namespace edit mode. It's interesting that the enhanced editor mode works fine here.— Ineuw talk 18:34, 11 February 2014 (UTC)

Yes thanks - I'm highly interested but just don't have the free time to "dive in".

In general, the original code was rather "stupid" and things like the old toolbar and the old EditTools would "load" regardless of being in use/needed or not. This made any other development based on the assumption such - for lack of a better term - "stupidity" would always be present and need to be "accounted" for even though whatever it was that was being added or improved code-wise had nothing to do with such old components one bit. Now that "we've" come to the point where such mindless loading of x, y or z is getting in the way of new features or gobbling resources better used elsewhere, there has been an over-all shift away from the oldies and old load order to one that better meets the ever-evolving code. In simple terms - the best case scenario is nothing loaded from common.js & common.css and everything once enabled that way became "gadgetized" instead with the key components "hidden" from deselection but loaded by default at the same time (See WikiBooks' .js & .css for example). This cuts down on all the global parameter calls, the needed scripting hooks and similiar jazz from once being a server fed requirement into locally selected options. This supports your theory that .css/.js settings or load orders for the two separate toolbars manage to conflict with each other - especially in the Page: namespace.

The problem, like we're having with old toolbar, is not everybody is operating from the same page anymore (if ever) and some folks are intensely adverse to allowing the "killing" off of the before-mentioned stupidty because they are unaware of the conflicts they are causing. You've taken the first steps from letting stupidity go - most others will not right up until the day the option is completely removed from preferences. In the meantime, the rest of us are forced to keep stupidity around at the price of crippling some functionality or the nother. I told Tpt that the Page: namespace is broken unless the old toolbar is activated by itself (or in tandem) with WikiEditor enabled. His response was basically one of those claiming the old toolbar is needed I guess because its a favorite in his circles or something; unaware of the stupidity he's prolonging in the process. Even if we get movement on this bug, I suspect the current (old time) OCR button implementation will also become an issue - will it break the Page: namespace the same way? Can't tell unless the bug you filed is fixed first. -- George Orwell III (talk) 00:00, 12 February 2014 (UTC)

Re: SimpleLeader

Where can I hang my head? I had no idea I was going to cause so much trouble. And on top of which I've just made a fool of myself with Beeswaxcandle as well. Not bad for a first day back? Many many pardons. I shall endeavour not to screw up again, but am not so confident at present. Do you want me to keep plugging at getting the "bug" demonstrated in Template:SimpleLeader/doc ironed out, or have I done too much damage and should keep my hands off for a while? It looks like we have quite distinct approaches and so might trip one another up if we both try at the same time. AuFCL (talk) 09:21, 2 February 2014 (UTC)

As far as I'm concerned - screw everyone who isn't working on fixing dumb-ass templates or improving others.

Look, the issue is the same as last month - we're trying to do too much at once. The notion we could put "Chap#" in front of "Subject" and "Page No." all together in a "single" template and hope to have them all render nicely at once is crazy. Its got to stay simple in my view; "left" (subject), "center" (technically the dots) and "right" (page no.).

Once you start hanging & padding, you loose all hiding of the overflow so hanging indents are also not likely to work in a stand-alone either. If you get rid of the Text-Indent in the last example, we regain control of the overflow and any dots not between the last and 2nd to last span are hidden again.

My other idea was to use CSS and have the 2nd to last (empty faux) span always trigger dot leader creation. Worked fine but there is no easy way to change the character, spacing, etc. without each scenario having its own CSS definition(s).

Anyway, feel free to tinker, etc. but lets stick to using the Template's sandbox for testing if possible. -- George Orwell III (talk) 10:05, 2 February 2014 (UTC)

I'm torn between largely agreeing -- but. However I'm in no position to argue my case as I haven't got the cases straight enough in my own head, let alone trying to describe them without using diagrams. Might have to resort to that yet.

Don't want to cause more stress, but I have thought of yet another approach radically different. I am working through some cases and this might end up being more a lesson to myself than generally useful, but if you like please have a quick glance at User:AuFCL/SandBox. If you think this idea simply won't fly (and I'm not yet convinced either way myself) I'd really value your letting me know and I'll stop wasting time on it.

If the Javascript is too much to swallow (and it isn't my language so I expect it could be done better), the general idea is to:

• Scan the HTML/DOM looking for any element tagged with the fake class "JavaScriptTagTestLeaderPrototype" (name just chosen to be unique and used as a multiple-item ID. Not intended for CSS use at all.) Any element found is considered to be the "core" of a leader, saved and temporarily removed.
• Then the elements parents are successively searched until the tightest enclosing paragraph, div or table-row (not sure about the last) is located. (What I really want is a containing block element whose height will change upon content insertion overflow.)
• Finally attempt to modify the leader element by inserting 1..200 copies of the original contents, and backing off by one once the container height overflows. The 200 limit is arbitrary and intended only to control infinite looping. This is intended to establish the maximal length leader possible without disturbing the original layout.

Obviously this is a very rough proof of concept, but do you think it may have possibilities? The empty headings are my personal outline of some of the cases I want to think about more as how to best handle. AuFCL (talk) 06:13, 3 February 2014 (UTC)

Sorry for the late reply, but it should not have prevented you from trying out what you've outlined above. My free time is limited so feel free to experiment on your own. -- George Orwell III (talk) 00:13, 5 February 2014 (UTC)

Don't let me leave you with the impression my trials have not continued, as at this stage in the process most issues are easily testable locally. If only "real life" wouldn't keep interrupting I might be making more progress. (The script is already out of date, I'll re-synch the example page right now, but more progress is hoped for and expected. And more research for my own sake.)

Probably fortunate I forgot to sign the above, as this addition just flows on. I am now happy enough that User:AuFCL/SandBox is "demonstration" quality. That is not to say it is by any means perfect, and in particular I am dissatisfied with using "position:absolute" in one of the samples, or indeed tweaking with "position:relative;left:..." in others. However I think it gives a fair indication of possibilities, and I shall now start looking (as time permits I expect to "lose" tomorrow) into templates and properly wiki-compatible javascript conventions. AuFCL (talk) 12:18, 5 February 2014 (UTC)

O.K. I have pushed the Javascript idea about as far as I am capable. I expect you have been quietly laughing waiting for me to realise of course this idea is quite hopeless, as irrespective of whether it works or not as soon as the final product (ebook, whatever) loses a scripting environment there is no way of guaranteeing the last produced code is in any way appropriate to the device. So this particular concept is utterly dead in the water. Sorry to have wasted both of our time.

Back to CSS. AuFCL (talk) 07:07, 7 February 2014 (UTC)

Content floated to right — whilst remaining eligible for text flow — do you know of a "nice" method for achieving this?

Pre-note: As you will see from my remarks in the prior section, this question has become utterly academic. I am still interested in any possibilities you may suggest, but my primary reason for asking the question has now long gone, and if you chose not to waste any effort on the matter I completely understand. AuFCL (talk) 07:07, 7 February 2014 (UTC)

Hello. I am hoping you might be able to suggest a better solution. Indeed I am not even certain how to best couch the desired effect, but here goes:

I would like to achieve a right-float-aligned content block which remains inline with the main text flow, yet which still participates in the overall box-allocation-model text flow. Style "float:right" will not suffice as seen in my example below (red box), as when "pushed aside" by excessive content to the left, the overall enclosing container height is not affected.

Use of style directive "position:absolute" achieves the same alignment effect, but removes the element from flow consideration altogether, and so is not particularly useful either.

My best effort (and I'll be the first to admit it is really ugly) so far is this:

<p style="position:relative;"><span style="margin-right:1em;">Left</span>........................................................................................<span style="color:transparent;margin-left:0em;">Steadfast Right</span><span style="position:absolute;right:0;">Steadfast Right</span></p>

—which you will note involves repeating the right-floated content twice, one copy for display content using "position:absolute;right:0;" styling, and one transparent copy which actually guards the space allocation. The net effect is (centring and width restrictions added to shorten sample code):

Normal "float:right" styling ("push" causes leakage outside of containing box):

Left........................................................................................Floated Right

"Ugly" solution using "position:absolute" and dummy space occupier (when "pushed" aside forces containing element to expand):

Left........................................................................................Steadfast RightSteadfast Right

Surely there exists a better/simpler solution than this monstrosity, but right at present I cannot think of one. So any suggestions you might be kind enough to make would be gratefully received. AuFCL (talk) 12:25, 6 February 2014 (UTC)

I'll need to look at this more closely over the weekend - time allowing of course. I'll post back then but continue to tinker on your end if you think of something "better" in the interim. -- George Orwell III (talk) 23:20, 7 February 2014 (UTC)

Back to "Hanging & Padding"

Permit me to assert that I cordially detest the template/doc/sandbox environment. Making "preview" useless should not be a prerequisite. That aside, I have revisited the "styles everywhere" version in Template:SimpleLeader/sandbox, merged in your latest changes to {{SimpleLeader}} and established a few trial cases in Template:SimpleLeader/testcases. I also stole the idea embedded in {{dotted TOC page listing}} to "blank" the artefact leader which appears as a result of outer container use of "margin-left". Of course this is not bullet-proof, but I believe the thing behaves reasonably for a majority of normal uses now. If you concur I'd like to propagate /sandbox into the template proper and try it on some "real" uses. (If you are too snowed-under please consider this fore-notice of my intentions for, say, tomorrow.) AuFCL (talk) 07:03, 11 February 2014 (UTC)

Yes, that looks like a better approach for now. I'm not entirely "in love" with the blanking of the bleed-over leaders but it does seem to render like we need it to. I say the sandbox code is a go for replacing the main. Good Work! -- George Orwell III (talk) 00:16, 12 February 2014 (UTC)

My highlighting added to your above comment. Oh Hell Man! Amen to that! It is so far from anything I am proud of; but as you concede, it does get out of a (certain particular) tight corner. Now if I can figure out how to get the "overrun-flow-float upwards" effect of the Javascript version demonstrated (perhaps rather too gaudily) here I think the thing might limp by. AuFCL (talk) 00:52, 12 February 2014 (UTC)

I think you hope for too much with that one. Even with a faux height (height: auto;), I don't recall being able to get something vertically aligned "bottom" to wrap "upwards" (if I'm following you right there that is). -- George Orwell III (talk) 01:02, 12 February 2014 (UTC)

I heartily agree. It is a reach too far for the CSS version, yet strangely sort of falls out naturally with the (add leader dots until something breaks then back off one iteration) javascript approach. I don't seriously think it is a case likely to be in demand: so no real loss. AuFCL (talk) 02:06, 12 February 2014 (UTC)

request

Hi George,

Might I trouble you to make me a DjVu out of http://books.google.com.au/books?id=D6_PAAAAMAAJ please? It's not available to me here in Australia, and my attempts to download the PDF via a US proxy have failed. I've also asked Any2Djvu to convert it direct from the download url, but it fails every time; I guess the PDF is behind a captcha.

(It contains two Henry James short stories that aren't available anywhere else — one was first collected in book form in 1948, the other in 1950).

Hesperian 04:29, 6 February 2014 (UTC)

Maury is going to email me the PDF, and I'll hopefully muddle through from there. As you were, and thanks anyhow. Hesperian 00:31, 7 February 2014 (UTC)

Sorry for the late reply. My free time is sparse right now but let me know if it doesn't work out and I'l get on it from this end. -- George Orwell III (talk) 23:22, 7 February 2014 (UTC)

PDF was way too big to email so Maury has uploaded it to IA. I have the PDF now and presumably will have an IA DjVu soon! So thanks for the offer but I think it is well in hand. Hesperian 00:57, 8 February 2014 (UTC)

Old runningheader change

Do you remember why you moved clear: both to the wrapping div in this revision last year? It looks like that's doing some weird things for invocations of running header with 3 params, the middle one left blank, as here. Prosody (talk) 23:31, 6 February 2014 (UTC)

Please pardon my jumping in here. For what it is worth, I think the problem boils down to this code in the "three-element-running-header" section:

	-->{{#if:{{{2|{{{center|{{{centre|}}}}}}}}}|<!--
		--><div style="text-align:center;"><!--
			-->{{{2|{{{center|{{{centre}}}}}}}}}<!--
		--></div><!--
	-->}}<!--

—because if there is no central parameter present, only left or right, all generated divs inside the enclosing "cleared" one are floating. It might be better to replace the above fragment with something like this:

	--><div style="text-align:center;"><!--
		-->{{{2|{{{center|{{{centre|&thinsp;}}}}}}}}}<!--
	--></div><!--

—on the basis of ensuring there is always something present for the "clear" to act upon. (You might want to replace the &thinsp; with &nbsp; if you think it might be a safer choice.) AuFCL (talk) 07:41, 7 February 2014 (UTC)

AuFCL is pretty much "right" in this case although, imo, the template should have never made {{{2}}} the un-named parameter the one assigned for "center" to begin with - it would never have reached this 'either / or' point from day one that way (Too late now). Feel free to make any changes you think resolves everybody's issues; I'm not married to the current varaiant especially if its not working for some. -- George Orwell III (talk) 23:29, 7 February 2014 (UTC)

That seems like a pretty conservative solution. Implemented. Thanks all. Prosody (talk) 05:19, 8 February 2014 (UTC)

Statutes at Large

Hello,

My name is Joe Carmel. I’ve been working on a small project along with Daniel Schuman and Joseph Jerome to breakdown the pre-1951 Statutes at Large into Public Laws and Public Resolutions as individual PDF files. See http://www.legisworks.org/sal. I’m thinking these files could/should be hosted at wikisource.org . Does that makes sense? I don’t want to start posting these files and then find out wikisource isn’t the right place. Thanks,

Joe

Actually, the place to upload those would be at Commons so any & all of the Wiki-type Projects, including WikiSource, can call upon the files if need be. If you upload them here just to Wikisource, only WikiSource can call upon them. -- George Orwell III (talk) 00:20, 12 February 2014 (UTC)

Is FI/{{FreedImg}} remaining in draft status still appropriate?

Hello. This template has been tagged as being in "draft" status for a considerable time now. If you don't object to the question (and its presumptions): what if any are your criteria for it remaining so? My personal view is this ought to be regarded as "mature" by now, but perhaps are you aware of developments in the pipeline (for example any kind of direct user-level-CSS-control? As if!) which may influence it keeping this status? AuFCL (talk) 01:41, 14 February 2014 (UTC)

For the sake of appearances more so than anything else - I can't really be the final "judge, jury & executioner" on every half-brained attempt I and/or others come up with and give birth to. It just looks bad after awhile. As for what those knuckle-head developers have placed in the pipeleine that could conflict with it - just enable the "beta" in your Preferences and see what happens for you. I can't find anything "broken" under it w/FI but I haven't checked every single week when the new refinements come out either; soooo.... ymmv?

I was hoping those who have used it - and used it for multiple purposes - would come back and sign off on things like that, update the documentation, etc. but no such luck. So if you haven't been able to find any holes or issues when using it - then its just fine by me to "finalize" the damn thing I suppose :) -- George Orwell III (talk) 02:02, 14 February 2014 (UTC)

Have used it. Like it. Multiple times. As far as I can tell documentation more than adequate. Tell me where I should sign. PGP O.K.? Or do you really need blood? AuFCL (talk) 02:42, 14 February 2014 (UTC)

Clearly that argument went down like the proverbial lead balloon. May I be permitted to couch it in other terms? Look at it this way, if FI were to be abandoned, how long do you think it might be before an infuriated Ineuw performs a one-man invasion south? Or alternately, on my estimation, at least half of Beeswaxcandle's 773 musical scores (the last part is his count) depend upon FI. Now I know he is a calm guy, but never underestimate the capabilities of a man from a culture where attempting to terrify a newly met party is considered to be a mere polite "Hello." AuFCL (talk) 00:40, 15 February 2014 (UTC)

Being a prolific user of {{FI}}, please accept my apologies for not getting back on a minor anomaly with indentation. Some time ago, it's behavior has changed but being busy with other issues, I forgot to mention it. Please look at this page where the indent is used and the problem is evident. This is only a sample but it would be like this everywhere. — Ineuw talk 16:50, 20 February 2014 (UTC)

Look again at your linked paged.... you used |mleft= (deprecated? if ever was a valid parameter) intstead of |tmleft= (i.e. text margin left). Boy, I hope the documentation reflects as much. At any rate, we probably need Mpaa to run a bot to change that parameter name if its "wrong" a couple of 100 times or something. -- George Orwell III (talk) 22:36, 20 February 2014 (UTC)

Another related subject forgotten to be mentioned. Also a long while ago, I created this Help page to be added to wherever it is suitable. If it has any merit, please point me to the place(s) where it could/should be inserted. — Ineuw talk 16:56, 20 February 2014 (UTC)

Thanks. I'll take a closer look at some point today and hit you up for some more feedback then. -- George Orwell III (talk) 22:36, 20 February 2014 (UTC)

{{FIS}} hanging indent revisited

Forgive my bothering you . . . again, and it's for another day. The hanging indent exceeds the left margin of the page (or the defined image width). This previous example doesn't reveal the issue because the image is floating on the right, but this page does. Would this be an mw. software error?

I experimented with hanging indents as in the example below (using {{ts}} parameters which I know by heart), and noticed the same problem. The hanging indent of 2em is added to the 360 text block width. In the context of images this is problematic because the image size is the defining measure of the image & text combination.

 

Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

— Ineuw talk 07:16, 22 February 2014 (UTC)

Got it, Thanks. — Ineuw talk 17:47, 22 February 2014 (UTC)

well whatever you "got" yesterday was by error (I neglected to revert my test edit so obviously you thought that meant something; my fault - sorry).

First - The issue turned out to be too many !important calls in the .CSS settings which prevented [some] manual-input template values to be ignored when the opposite should have been taking place. So other than the ' mleft= really should have been tmleft= the whole time ' thing mentioned elsewhere earlier, the corrections I just made to the .CSS should not cause you to have go back and change any FIish settings at all. Please dbl-check that & report back either way.

Second - the above example is not something I have control over - if you use FI or FIS, the recomendation is to always use the caption= parameter to apply caption text. I get that "hanging indents" starting with the letter "F", applied on days when the moon is out but still have a low tide, while wearing one sock and so on wasn't rendering as it should have until a couple hours ago but THAT is kind of a minor issue all things considered, No?.

 

Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

Seriously - I'm tired of the whole IMG tag / FI thing and want to put it out there once and for all, for everyone to use in any case. If there is something else not quite right with it in your opinion, NOW would be the time to address it.

Finally & on a separate note -- re: Bug 61220; its kind of critical to get the "old separated from the new" so maybe the component should be changed from the current to specifically ProofreadPage instead. It might get picked-up & worked faster that way. -- George Orwell III (talk) 00:24, 23 February 2014 (UTC)

Reply to "First" - I looked at the change you made and checked the results. It's fine.

Reply to "Second" - I understand that you have no control over the above sample. Only used it to demonstrate that I am aware of the issue when using other methods as well.

Re Bug 61220 - There is no ProofreadPage component available. I flipped through all the Products but none would has that component. Also, it was Andre Klapper who set it up.— Ineuw talk 00:59, 23 February 2014 (UTC)

?? Look under MediaWiki Extensions maybe? -- George Orwell III (talk) 01:04, 23 February 2014 (UTC)

• I looked under Extensions and it no longer exists there - or any other group. Only as 'Page edit'.
• As for the bug 54144 relating to the <img> tag, more people were added to the mailing list but nothing being done.— Ineuw talk 02:04, 23 February 2014 (UTC)

I must be going insane (or your en-CA language settings are up to no good again). Please try...

• https://bugzilla.wikimedia.org/buglist.cgi?product=MediaWiki%20extensions&component=ProofreadPage

... I see the component is abbrv. as Proofrea but every way I try to get - I find it regardless. Anyway, I think that is where a 2nd ticket should be opened (or where the original should be "moved" to??) -- 02:13, 23 February 2014 (UTC)

You're not crazy, we are both right, and the English-CA works fine. . In order to change, a new ticket must be opened. Only then is the Proofread sub-selection is accessible. Changing the current selection from Mediawiki to Mediawiki extensions doesn't change the sub-selection list. Let me do this in the morning because I want to run one last test on Macbook using Safari. Firefox on Linux and Apple OSX have the same problem as FF on Windows. Also, Andre Klapper has already confirmed the problem in both FF versions 26 & 27, but interestingly, he removed his name from the CC list.— Ineuw talk 05:00, 23 February 2014 (UTC)

Thanks - any time you get around to it is fine. And make sure you add my also-broken rendering under IE8 with your findings.

As for en-CA & en-GB Users: - you only think you're fine because you don't know what you've been "missing" all this time [apparently]. I went through a few commmon paces under both lang. settings yesterday & earlier today and found both drop settings-&-such to varying degrees throughout the site compared to EN. The recent changes to the Universal Language Selector only seems to have made the "drop-outs" more pronounced afaict. I'm going to keep whittling as much as I can to at least mirror the default, but that can only go so far. :( George Orwell III (talk) 05:24, 23 February 2014 (UTC)

George Orwell III, This is the new bug report. I listed my three browser tests, in three OS's, and indicated the previous bug report. But they will ban (kill) me for sure. First, because of filing a duplicate bug report. Second, because after creating the 2nd bug report, I modified the description of the first and that's the action needed to change the bug parameters - which I did. Now they have two reports listed in Wikimedia extensions/Proofread from me and finally, because they'll find out that we are in cahoots. .— Ineuw talk 03:13, 24 February 2014 (UTC)

The above mentioned new bug has been closed by User:Tpt as a duplicate and we are back to the old bug #. I also tested all the other skins and the problem is the same, so it's not Vector related. This post is getting to be too long and if I have anything new to add, I will start a new post. — Ineuw talk 22:51, 25 February 2014 (UTC)

Styling for hanging indents - apparent anomaly

Hello. This is a very low priority matter. I just noticed in passing that the related quartet of templates {{Hanging indent}}, {{Hanging indent inherit}}, {{Table style}} and {{Paragraph tag/parse}} use two different CSS style combinations to achieve their effect. The first two use "margin-left:x;text-indent:-x;", whereas the other pair use "padding-left:x;text-indent:-x;". Whilst all work fine here:

{{hi|{{hanging indent}}

{{hanging indent inherit}}

{{table style}}

{{paragraph tag}}

1. —do you think there might be a case for matching styles between all four, in which case what are the merits of padding- over margin-left (or vv)?

   Well thanks for pointing this out. Originally, I just copied the Table/parse to P/parse and edited from there so that is why the latter 2 match (which was not my intent). I'm a "margin" man personally and would typically use margin-left over padding-left for most cases, including hanging indent (I like manipulating the margin attribute mostly because they are "transparent" and easily noticed when improperly applied).

   The overall, benefit/hit reasoning between the two escapes me at the moment but, as with most other proding, it will come to me at some point. After I check the next point, I'll probably look into seeing if at least P merits a switch to "margin-left" or not.

   I also lean toward the margin choice, but for the life of me I am not sure why. I was just a bit surprised to discover the split decision and thought the matter might be worth an airing. No real drama either way. AuFCL (talk) 01:47, 21 February 2014 (UTC)

   Well, yes there is drama; it dawned p/parse has been using the normal text-indent (it or ti) assignments for producing hanging-indents (hi or hit) all this time. I'll delve into what, if anything, can be done to rectify that at this point after I'm done toying with the other thing below. --George Orwell III (talk) 02:09, 21 February 2014 (UTC)

2. —for some reason which I cannot spot, in the Page: namespace {{p|it}} intrudes about 5px into the left margin, which I am fairly sure is new(ish) behaviour.

   Regards, AuFCL (talk) 06:31, 20 February 2014 (UTC)

   Just in the Page: namespace? Weird. I'm going to take a look at that in a bit now that I have some time. I will report back here. Thanks for pointing this out regardless. -- George Orwell III (talk) 22:24, 20 February 2014 (UTC)

Not sure which of these edits nailed the Page: sub-issue, but well done, gets my vote! AuFCL (talk)

It was the removal of

/* Paragraph markers (no IE6 support) */
body.ns-104 div.pagetext > p {
	/* @embed */
	background-image: url('//upload.wikimedia.org/wikipedia/commons/thumb/b/b6/Paragraph-mark.svg/6px-Paragraph-mark.svg.png');
	background-position: 0 .33em;
	background-repeat: no-repeat;
	margin-left: -10px;
	padding-left: 10px;
}

... which means sooner or later those few folks who saw a little paragraph-marker symbol to the left of every paragraph start in the Page: namespace before the above removal will eventually realize it stopped working and demand it be restored. I've been trying to find a way to get it to work while preserving the paragraph start positions/margins with no luck - which irks me even more because I'm pretty sure this was not an issue and suspect you are right about "new"ish behavior recently changing all that "smoothness". Let me know if you have any ideas. -- George Orwell III (talk) 02:09, 21 February 2014 (UTC)

Yes I realised that. Pardon my not having been clearer. What I meant was that getting rid of the ¶ (pilcrow?) makes for a cleaner display, and that gets my vote. As for replacing the damned thing, I am wondering if there was a good technical reason for using an image in the first place (perhaps it dates to a time when browsers... cancel that, I think this character has been in the extended ASCII IBM set since 1986 at least.)

Why on earth wouldn't something equivalent to <span style="position:absolute;left:-1.1250em;">¶</span>¶ be good enough (see margin—works here)? Perhaps:

/* Paragraph markers (no support for IE6 & IE7) */
body.ns-104 div.pagetext > p:before {
	position: absolute;
	left: -1.1250em;
	content: '\00B6';
}

—might work? (Took me longer to get the syntax right than to come up with the idea!) Mozilla copes with this fairly sensibly. YMMV.

Second thoughts: I hope I haven't just bulldozed you with a suggestion which runs counter to some issue which I have blithely ignored. For example, is there some reason for remaining loyal to the background-image approach (for example, I believe IE(6,7) may not support the :before styling)?

AuFCL (talk) 06:57, 21 February 2014 (UTC)

Not at all - what you came up with was something similar to my tinkering yesterday. I paused for the same IE reason(s) then realized IE6 was never supported anyway and IE8 is OK with before so its only IE7 that would get hosed. And if the available stats can be trusted, IE7 usage is not anywhere near IE8's or higher so I'm OK with the change to the character/symbol approach - even though applying a hanging indent seems to push the paragraph symbol even farther to the left. Considering the number of instances needing a hanging indent is kind of on the low side, I don't think that additional offset is an issue (well not one worth dropping the symbol approach over).

That said, I'll get around to taking your above (if that is OK with you) and making into a user selected gadget rather than reinserting it universally back into Common.css sometime this weekend. Keeping the whole does 16px equal 1em or not thing in mind, I'll be changing the value defined from using px to em however. -- George Orwell III (talk) 23:14, 21 February 2014 (UTC)

Of course this matter is always O.K. with me. By the way, please consider the whole px/em thing to be a:

(a) force of (bad?) habit on my behalf;

(b) "development/proof-of-concept" issue (if I may be permitted to be so arrogant.) Not having convenient access to a Microsoft system I am completely dependent upon you to keep me a little more "generally" focused—once any point has been proven/demonstrated, absolutely any advance upon that may be considered an improvement, and at worst this is at least something which may be fallen back upon if the world goes to utter pot.

I don't know if it is a bad habit or not; time will tell? As far as "focus" goes, I don't have the time to play MSDN anymore and build multi-boot system(s) for every browser out there either so I consider input/discussions with folks like you just as valuable for stuff like this. Thanks again. -- George Orwell III (talk) 01:06, 22 February 2014 (UTC)

Good thinking making it a gadget/option. My personal preference would(will) be to leave it off. AuFCL (talk) 00:38, 22 February 2014 (UTC)

Gadget created. Please verify the notice announcing as much at the top your Watchlist page. If so, please enable/disable to verify it does indeed work. TIA. -- George Orwell III (talk) 01:06, 22 February 2014 (UTC)

The gadget (assuming you mean "Generate paragraph (pilcrow) markers, ¶ , in the left margin of the Page: namespace to indicate HTML paragraph tag starts. ( IE7 and lower not supported )" works well; the notification rather less so. I don't know what is supposed to appear to the top of Special:Watchlist, but nothing (new) appears for me. AuFCL (talk) 01:43, 22 February 2014 (UTC)

<sigh> my bet its another "fork" resulting from more Universal Language Selector tinkering (see Scriptorium for 2/21 "restoration" or something) resulting in a new need for more & more /en-ca and /en-gb duplication of MW message defaults. Please see if you are set to one of those and if so, test all 3 (straight en, en-ca & en-gb) to verify "notice" is absent and under what language setting(s). -- George Orwell III (talk) 01:54, 22 February 2014 (UTC)

Good thing one of us has our brains engaged (hint: not mine!) Under Preferences/Internationalisation/(en-GB and en-CA): nada. Under …/en, however: "Auto-generation of paragraph (pilcrow) markers, ¶ , in the left margin of the Page: namespace to indicate HTML paragraph tag starts is now handled via pilcrowMarkers Gadget in your User: preferences. Users must enable the gadget to restore the feature ( Note: Internet Explorer 7 and lower not supported )" (Return sigh!) AuFCL (talk) 02:09, 22 February 2014 (UTC)

Of course :( Why should anything around here be easy? Anyway, at least the Gadget works. Not that this 'Watchlist announcements' thing isn't already a hack using 'Watchlist summary' to begin with either. Sheesh! will it ever end?.

I'm going to hold off on creating message sets for en-GB & en-CA for a bit and first see if there is anyway to force the use of the the "main" EN message set when a particulat MW message has been created locally; that should be fun :| George Orwell III (talk) 02:38, 22 February 2014 (UTC)

P support for (hanging) v (normal) indents

Hello. Noting this edit to Template:Paragraph tag/parse I assume you are planning upon either

1. spitting out direct support for the hanging indent case, or
2. leaving the styling choices in the hands of the individual editor.

This I can applaud, although may I point out the regrettable precedent {{ts|it}} has set for you. May I suggest it might be better to utilise the form {{p|ti}} for "text-indent:" and either eliminate the "it" case altogether (so it fails gracefully) or better deliberately trigger an error category so that current "misuses" may be detected and corrected?

I am aware of one case Page:Russell, Whitehead - Principia Mathematica, vol. I, 1910.djvu/35 where I have used it in the assumption "it"="hanging indent".

I am happy to fix it either way, but I would not mind knowing which way you are thinking so that I don't go chasing too many shadows.

Regards, AuFCL (talk) 04:07, 23 February 2014 (UTC)

I paused to think over just that. I'm close to removing both [regular] text-indent (be it ti or it) as well as hanging-indents. If there are any instances where either needs to be applied to more than handful of paragraphs, it should be done thru a container element or by CSS definitions. One or two instances can easily be done "long hand" imo. Plus table-cell padding is not a comparible equivalent for our needs here.

Add to that the padding-left vs. margin-left question and all "we" wind up doing by locking-in & abbreviating the inline styling of one over the other is to further muddy the issue. I say let user's build a helper-template with the variation & values needed for multiple reps or do it long hand for each instance as well. -- George Orwell III (talk) 04:23, 23 February 2014 (UTC)

No problem. I shall assume it is/will be removed and act accordingly. If I spot any instances "in the wild" I shall remove/replace them on sight from now on. (Oh, and as an aside, please forget my idea of a tracking category: the effort involved in bending the template simply would not be worth the tiny pay-off!) AuFCL (talk) 05:02, 23 February 2014 (UTC)

Last I checked, template usage was still in the hundreds not thousands so I don't think there is too much to worry about on that point.

I've decided I'm going to keep & expand the proper text-indent:$1 strings using your ti suggestion from before and just ax the constructed "hanging-indent" ones. That way, Users can just add padding-left or margin-left as needed to accomplish the "hang". (I think I still need to keep it and just make them pass thrus or something for those table-style folks no?) -- George Orwell III (talk) 05:35, 23 February 2014 (UTC)

May I suggest looking at it this way: one-off hanging indents are really rather rare. If a whole page of them occur, then only an idiot would not enclose the entire set in an overarching div with suitable styling (ala existing {{hii}}). I think you might agree that is the appropriate use for div? Also has the advantage that re-jigging indents (of either kind) involves only editing specified control points, rather than the n affected separate paragraph styles, with the near-certainty of missing one. In short: I agree with what you are doing. AuFCL (talk) 06:43, 23 February 2014 (UTC)

An obvious question never asked

Hi GO3. Can you count the number of users of Wikisource who have the enhanced edit toolbar enabled? — Ineuw talk 22:54, 25 February 2014 (UTC)

I'm pretty sure I can't even if I was sure how. Hesperian might be able to being a 'Crat. He's also the one I'd expect to know how to do something like that thru the API without revealing which Users have what enabled or not. Why do you ask (if I may be so forward)? -- George Orwell III (talk) 23:06, 25 February 2014 (UTC)

I was curious if others have the enhanced toolbar enabled because I assume that others would have the same problem, or so I would think.— Ineuw talk 00:52, 26 February 2014 (UTC)

Good point. I wouldn't think many have since its not(?) selected by default - only the "old" toolbar is selected by default. At somepoint, the nuance indicating the "enhanced" toolbar was in beta and meant one day to replace the existing (or "old") toolbar was lost when they moved the option checkboxes to that normalized section of User preferences. This is why the true test of separation is enabling one or the other but not both.

Currently, when both are enabled and you enter edit mode, the old toolbar (and all the scripting crap that comes with it) is still loaded then usurped by WikiEditor (a true extension of the wikicode) shortly afterwards. This is what I called "stupid" loading earlier, a waste of resources and a constant source of conflict when moving forward. Tpt is under the assumption a backdoor or something will always exist to support the "old" and I find absolutely no evidence of that.<?p>

If the WikiEditor developers would get off the VisualEditor love-bus for a minute or two and make the customization of the WikiEditor buttons & menus far less complicated than they currently are, folks would eventually make the switch (simply to avoid the "stupid" loading that more & more will, if not already, conflict with one thing or another). I believe once that door is closed, the "old" support will be completely removed and the User: preference that was once considered "enhanced" will replace it and be considered the "standard" at that point. In short, separation (one or the other but not both) must be established in every namespace and on every sister site for that switch to become a reality. At that point Tpt & friends will finally stop believing the "old" toolbar will always be around. -- George Orwell III (talk) 01:26, 26 February 2014 (UTC)

Comments on the advanced editor issue

Just to ease your concerns about being the only one who tried using the advanced toolbar - don't be concerned. I gladly did the testing, for you or anyone else, because that's how I learn - and I should understand the inner workings of wm a bit better by now.

• The attempt to switch editors began in early autumn because the old CharInsert? selector was too far below the text area to insert non Latin characters.
• So, I switched to the enhanced editor/toolbar to resolve the issue. It turned out that the Hebrew and Arabic were in reverse order because it was claimed to be tied to the language selected by the user. This turned out to be incorrect when I tested this on my Hebrew WS home page (since removed). It seems to be tied to the natural language of the site.
• To pursue this issue further, I emailed to User:Amir Aharoni, one of the wm language development team and pointed out this issue. He also sent me Bugzilla to report the issue. So far this was not addressed the last time checked and I became philosophical abut the whole issue. .
• As for the advanced toolbar editor which works fine on Wikipedia and the Commons, using it negates access to much needed 'button' activated templates like the Wikipedia version of {{PSM link}}, {{Wikisource}}, etc. This means, that I lose some fairly important (to me) tools which was offered by the legacy toolbar, and hasn't been addressed yet in the advanced editor. Thus, I understand the reluctance of others to switch.— Ineuw talk 18:06, 26 February 2014 (UTC)

Patching the advanced edit toolbar

As for the patch TpT says fixes the toolbar issue - unless its only to come down to us in the next update for 1.23wmf16 - I don't see any difference here (1.23wmf15) or on the test site (another 1.23wmf15). -- George Orwell III (talk) 23:19, 25 February 2014 (UTC)

I forgot to mention that Tpt's patch doesn't work. I also went through all four skins to see if they have an effect on the advanced editor & toolbar problem but all are the same as Vector.— Ineuw talk 00:55, 26 February 2014 (UTC)

Yeah, I saw the "patch" creation but I don't see where it was [properly} merged into either the "master", wmf15 or even wmf16 source codes. Something does not appear to have gone all the way thru when I looked at previous "commits" as a comparison as well. Of course, all that is beyond my understanding to be honest. Take a look for yourself.....

• https://gerrit.wikimedia.org/r/#/admin/projects/

and scroll down until you find ProofreadPage Extension. I don't know much but I don't see anything merged in the past 2 days or so... -- George Orwell III (talk) 01:26, 26 February 2014 (UTC)

FYI. Just got notice that a patch was applied.— Ineuw talk 18:06, 26 February 2014 (UTC)

Yup, but it won't get to us until sometime next Tuesday with the update to 1.23wmf16. Still, true "separation" seems to have been achieved if the Test Site is to be believed. Once I set my Preferences there (old=off, enhanced=on), the WikiEditor was indeed the sole utility loaded in edit mode. Progress made! -- George Orwell III (talk) 02:21, 28 February 2014 (UTC)

@Ineuw: -- On a separate note, Mpaa remarked his HotCat no longer works in Scriptorium - wasn't that the reason you started down this WikiEditor path? I forget if it was just your customized old toolbar buttons that conflicted with HotCat or the entire old toolbar scheme being present/loaded in general that blocked HotCats for you. -- George Orwell III (talk) 02:23, 28 February 2014 (UTC)

Thanks for the note, I will respond to Mpaa. HotCat was one of the issues. As usual, now it's working fine. However, it's possible that a simple reset to default will ork as well. — Ineuw talk 05:31, 28 February 2014 (UTC)

HathiTrust - white perimeter surrounding every book page

George, the books on HathiTrust have a white perimeter surrounding every book page. I have no problems removing watermarks but if you would be so kind, should I leave the white space perimeters behind the book page or try to edit that perimeter out leaving only the book page. For example, a book page is brown but yet there is that white perimeter surrounding that brown original page. When I am done cleaning all watermarks away should I also try to cut away that white perimeter? What size in pixels is a book page? I come to you because of your knowledge others here don't have. Kindest regards, —Maury (talk) 17:01, 1 March 2014 (UTC)

HathiTrust makes life hard on us here at WikiSource - that much is sure. A couple of things first...

1. Every downloadable PDF page at HT is (re)sized upon save to print/render as if the original was published on 8.5 inch by 11 inch sheet of plain paper (the standard dimensions for a typical American "letter"). The original content as originally published, however, may have been much smaller than that. This is why we get the original page-size (with the original type) "centered" in what amounts to a lot of wasted whitespace on all 4 sides.
2. HT primarily "hopes" to retard attempts to restore the scanned content back to original dimensions by asserting its source(s) via watermarks, as you know, along the bottom of the added whitespace. This is then furthered by inserting metadata-like text along the left and/or bottom margin(s). More often than not, some of this added text is hidden from normal display in Acrobat.
3. In order to "trim the excessive whitespace" this metadata-like text, hidden or otherwise, needs to be removed prior to cropping the page or the reduction in size won't "take" properly (e.g. looks cropped in Acrobat but once converted/uploaded to Commons, extra whitespace is still present. See an example HERE )

That said, I would recommend going through all that just to get the page "size" as close as possible as the original. If you don't, the side-by-side thumbnail during ProofReading is frequently not easy to work with 'cause the text is woefully too "small" even under ontop-below (horizontal?) view in the Page: namespace.

Hope that helps... just ask if it didn't. -- George Orwell III (talk) 23:44, 1 March 2014 (UTC)

Documentation shared by two different templates

Hi. Just noticed that {{fs90/s}} and {{fs90}} share the same documentation (which they shouldn't because of the

<noinclude>{{documentation|{{NAMESPACE}}:{{BASEPAGENAME}}/doc}}</noinclude> statement.

I have no clue how to separate them to create the accurate info for the {{fs90/s}}. Can you possibly direct me? Thanks.— Ineuw talk 19:49, 2 March 2014 (UTC)

Not sure what you wanted but I turned the "sharing" off leaving the start variant needing its own documentation from scratch. -- George Orwell III (talk) 23:15, 2 March 2014 (UTC)

Thanks, I copied the documentation and revise it accordingly.— Ineuw talk 01:16, 3 March 2014 (UTC)

the deletion of Index:ARyada 1prep SB T2 E 2014.pdf

It was part of the Egyptian Math curriculum the aim was to create a wikisource entry to that students can have a digital copy of the book and for teachers to use and contribute to. Why was it deleted?

I restored it so you can see for yourself - Error: No such file. What else was I suppose to do? -- George Orwell III (talk) 01:48, 9 August 2014 (UTC)

wikiEditor custom toolbar (continued here)

Hi GO3. I've been using the new enhanced editor and everything is just fine. In addition to your modifications, I also found ways to increase the vertical window space by hiding Firefox objects. This provides access to everything needed without having to constantly scroll up and down as this this was the major concern, perhaps more important to me than to others, because PSM pages are identical (and there are so many of them). The proof of this improvement was day's productivity. .

Thanks for ALL your hard work.

P.S: I hope you don't mind but I thought that this conversation which started on my talk page is better continued here because more people read your page and thus gets a wider audience.— Ineuw talk 07:38, 11 March 2014 (UTC)

Unicode feedback — thanks.

Thank you for your kind feedback here. I fear my general state of annoyance at yet another unnecessary (not the right word, but I currently cannot think of anything else mildly polite) μSoft divergence rather coloured my immediate response. If it showed through please be assured it was not in any way aimed at yourself.

May I take this opportunity to properly thank you for getting back to me? If the latest (horrible) attempt fails I might have to resort to use of another, tiny, image.

Oh, and if I have learned one thing it is this: if I ever find myself asking again "Will this Unicode point work?" the generic answer will have to be a resounding "NO!" AuFCL (talk) 05:09, 13 March 2014 (UTC)

AuFCL, The only solution that covers everybody seems to me is to add the 'DjVu sans' gadget currently on Wikipedia. IE Users would still need to apply the font-pack manually if I remember right... but if time is taken out to explain how to do that, I'm sure we can cut down on the amount of browser to unicode compatibility issues. Thoughts? -- George Orwell III (talk) 18:42, 13 March 2014 (UTC)

Well, you've certainly thrown me there. I was not even aware of such a gadget until you pointed this out, so everything from here on in is based on five minutes or less of research.

According to the Preferences blurb (quote in full: "DejaVu Sans, a font with support for various dingbats. This gadget works on Google Chrome, Mozilla Firefox 3.5, and Safari. Install this gadget if you need better font and character support but cannot install fonts directly onto your computer.") this gadget is aimed at providing extra support to the very group of systems which the informal poll seem to indicate do not have a problem by default. Doesn't this indicate the gadget might not be very useful (or worse have passed its effective version use-by date)?

My more general searches keep turning up things like this external link which imply LaTeX supports the very character at the heart of this matter via some kind of phonetic font. How (or even whether) it is possible to somehow translate this into terms acceptable to <math> regrettably is currently quite beyond me, but would be my (Yep: selfish eh?) ultimately preferred solution if it could be reasonably achieved.

Frankly I feel bad about stirring up so much effort even discussing this over one measly symbol which probably ought to be added as a File: image to Commons? (Guess what!!) AuFCL (talk) 22:17, 13 March 2014 (UTC)

After saving the above I realised I'd only responded to search leads to here. Looks like the licensing is friendly, so I wonder if there is a case for adding this to whatever this month's name for WebFonts-extended (IPA?) might be? Please pardon the throw-away nature of this note. AuFCL (talk) 22:39, 13 March 2014 (UTC)

AuFCL, progress is progress - don't worry about anything coming off offensive or whatever as long we're making progress.

Off-hand however, I personally wouldn't know how to add something like that to whatever this month's name for WebFonts-extended (IPA?) might be. It's probably done through opening a Bugzilla first and some expert there the gadget half of your suggestion. I did a bit of digging locally and finally unearthed my system is sourcing the offending glyph from the "FreeSerif" font, which a shortguiding it through the rest of the process (but I've been wrong before). Why not ask about adding this over on the ol' Village Pump on WP for starters - I don't think Scriptorium has the traffic for something like this (but I've been wrong before). -- George Orwell III (talk) 23:31, 13 March 2014 (UTC)

┌───────────────────┘

{{Unicode|℩}}

℩

Any help? The Unicode' template was in the Symbols set of CharInsert all this time btw. -- George Orwell III (talk) 00:00, 14 March 2014 (UTC)

Now you have me both confused and intrigued. A quick conversion confirms 2129(hex)=8489(decimal), so we are dealing with exactly the same code point…Fact. Now are you telling me that there are things in CharInsert which do not work for Internet Explorer? AuFCL (talk) 01:24, 14 March 2014 (UTC)

First, a reminder. Our CharInsert gadget is exactly the same as the one found currently on WP. The indivdual characters grouped into selectable sets are nearly the same as well. The only difference is our selectable groups are labeled different than their's and each group contains different characters compared to WP's groups.

Next; generally under 'IPA', 'Math (& Logic)' & 'Symbols' groups, there are several individual characters that render as a "null box". The language sets are mostly complete (except for things like your odd-ball 5th dimension, reverse, small, upsidedown, backwards iota). IE is the worst when it comes to rendering these - both here & at WP - but NO BROWSER renders ALL the characters for one reason or another on WP either (Commons too). This is why additional templates are added towards the end of certain CharInsert sets - to compensate for the lack of function or rendering for as many Users as possible. You should inspect the Unicode template (& @ WP) in this case to isolate the issue at hand (IE does not force the loading of the needed font-family on its own; an inline span does it for us instead).

So to be clear, its not IE alone that has trouble- only the most trouble. Its not the browser in use that has trouble- its a combination of the browser, the stupid debate over translations w/Universal Language selector both contrasted against WebFont usage. -- George Orwell III (talk) 02:03, 14 March 2014 (UTC)

Thank you for so clearly laying out what I had only hitherto suspected. I (finally) understand, well perhaps only a little, but at least a little more than before. I agree all points. (See rant already committed to other place! Oh and also consider {{rotate}} issue raised there, at the very least I think we ought to synchronise with w:Template:Transform-rotate. No? Or possibly dispose of the currently non-functional implementation?) AuFCL (talk) 02:25, 14 March 2014 (UTC)

Seriously. Thank you for your kind forbearance with regard this trivia. The dent in my office wall where I keep banging my head is starting to get so deep there is danger of structural failure in the building. And yes, I did see your call to arms regarding CharInsert compatibility, but did not at the time (or indeed right now) feel able to add anything useful. AuFCL (talk) 02:57, 14 March 2014 (UTC)

┌─────────────┘
No, thank you. I've come realize that the "hack" in MediaWiki:Common.js

/**
 * Fix for Windows XP Unicode font rendering
 */
if ( navigator.appVersion.search(/windows nt 5/i) !== -1 ) {
	mw.util.addCSS( '.IPA { font-family: "Lucida Sans Unicode", "Arial Unicode MS"; } ' + 
		'.Unicode { font-family: "Arial Unicode MS", "Lucida Sans Unicode"; } ' );
}

... is less than optimal.

Sure it adds 2 class definitions for the 2 needed families so why didn't they keep the same XP-conditional detection and just add the 2 families to the default families? I think the fonts would always render without the need for wrapping the character in question within a span calling class="Unicode IPA" ever. And why make it XP or XP Pro conditinal over making it IE browser version conditional?

...or am I crazy @AuFCL:? -- George Orwell III (talk) 03:16, 14 March 2014 (UTC)

Always settle for crazy. After a while you realise it really isn't (even intended to be) an insult after all.

Simpler is better, unless I've misunderstood Occam's Razor? AuFCL (talk) 03:40, 14 March 2014 (UTC)

Pardon, shouldn't this change have rather become:

	mw.util.addCSS( '.IPA { font-family: "Lucida Sans Unicode", "Arial Unicode MS"; } ' + 
		'.Unicode { font-family: "Arial Unicode MS", "Lucida Sans Unicode"; } ' );

i.e. always select those fonts (so that failure to find them simply fails gracefully)? AuFCL (talk) 03:56, 14 March 2014 (UTC)

That was an interim edit just to see what I could test in my local .js for XP. Turns out no matter which way I try, I can't get normally the wiki code loaded "sans-serif" for HTML/BODY to co-exist (or neatly fail to as the font fall-back) with "Lucida Sans Unicode" added via as you envisioned. In other words everything becomes rendered under "Lucida Sans Unicode" instead of just supplementing the wiki-code induced "sans-serif" scheme.

I decided instead to change my IE8's 'webpage font' in IE's settings to "Lucida Sans Unicode" and, lo-&-behold, your &#8489; (℩) even works - no {{Unicode}} template needed & "sans-serif" resumes being the font rendered just like always. This is OK by me until somebody comes up with a way to reproduce the same behavior I just did without altering IE's settings since this station is almost dedicated just to accessing wiki-whatever anyway.

PS I installed that "free-font" or whatever as a test but some of the characters (including your's) renders too lightly & a tad small for my taste. Same issue however - needs to be Forced as well as Co-Exist with the wiki-code default loading ("sans-serif") to always render without any extra class or template aid. -- George Orwell III (talk) 04:41, 14 March 2014 (UTC)

Just musing here: I'm wondering if "mw.util.addCSS" might be a misleading name, as it is starting to sound like it inserts the selected fonts at the "front" of the priority order. Pure speculation, but could there be an alternate equivalent which post-pends the insertion? (Bugzilla: 33305 suggests addCSS is not necessarily a good choice...? Regrettably it does not suggest a better option.)

No that is pretty much is the issue the way I've just tested it so you are not off by much if at all. The point, imho, should first be to amend the font-family class definitions loaded via load.php &/or index.php rather than post .php load thru some code or script locally in common or user's .js settings. If that "cannot" be done, then the 2 Unicode font families should prepend (add at the begining of) the existing string (or whatever) with that info rather than append (add at the end of) it. I just don't know if any of that is even possible nevermind how to do it myself. Will keep trolling for experts from other domains and sooner or later - hopefully - one of them will know how. -- George Orwell III (talk) 06:05, 14 March 2014 (UTC)

Look I know I am being insufferable about this but since you moved this out of MediaWiki:Common.js, once the change beds down/proves itself a little might it be worthwhile merging it into the ieCSS string logic just above? (I know I'm drawing a long bow here and don't really understand the processing but it may just be that appending the new CSS to the end of the prior addCSS call might end up putting the new fonts closer to the end of the list where they ought to be; whereas a new call to addCSS appears to insert them ahead of the previous values (obviously assuming earlier observations hold this is not an optimal solution.) As always, please confirm if possible with those "trolled experts" you refer to as I am likely to be wrong. AuFCL (talk) 06:24, 14 March 2014 (UTC)

AuFCL, I revised the patch into ieCSS form but I don't see the benefit since we're still defining the Unicode & IPA classes post load.php. Unless those classes are manually added inline or templatized, normal browsing won't trigger the needed forced result. I'll keep this one in mind - but unless somebody "votes" to the contrary, I don't see how we could further the quest for a solution at this stage.

Still, I noticed {{Unicode}} adds a 2nd font-family /**/:inherit; at the end of the inline-style string and I suspect that oddity is related to this loading/merging/coexisting font nuance we are trying to nail down somehow. I didn't find anything to support that yet however. -- George Orwell III (talk) 23:05, 14 March 2014 (UTC)

More good news (not!) The next strange character which comes up in R&W is an upside-down "D" which does not even appear to have any kind of Unicode "cheat"; so perhaps I will have to look into {{rotate}} more seriously after all. Damn. Why do I insist on getting into these things? AuFCL (talk) 05:52, 14 March 2014 (UTC)

tsk.. what did you expect from a 100 year old publication dealing with "math" or whatever all that is... simplicity? George Orwell III (talk) 06:05, 14 March 2014 (UTC)

Note: I never said I was not pig-headed. Or an idiot, come to think of that.

But at least I am a pig-headed (long-time-ago now once-was mathematics student) logic-trained idiot. Did I mention stubborn? AuFCL (talk) 06:24, 14 March 2014 (UTC)

Opinion requested

I am hesitant to move (and transclude) [the unindexed] Dover Beach to The poetical works of Matthew Arnold/Dover Beach and delete the associated Talk page, for there is a bit of work/info/contributions that went into it. Am I being too timid? Should I create a versions page to include both or just carry on as usual with the move/deletion? Thanks, Londonjackbooks (talk) 23:35, 17 March 2014 (UTC)

Plain & simple ---> No scans to support a version? Then that version pretty much equals garbage.

Go ahead and replace it with the scan backed version - I can copy & paste a bunch of text without a working source-link too and claim its proofread too. That piece was created some 6 years ago when "we" didn't know our ass from our elbow when it came to transcribing then proofreading. -- George Orwell III (talk) 23:57, 17 March 2014 (UTC)

Thanks again for the direction. Londonjackbooks (talk) 00:01, 18 March 2014 (UTC)

When moving pages, should I or should I not choose the option to also move the associated Talk page? It seems that creates more deletion work, yes? Londonjackbooks (talk) 00:43, 18 March 2014 (UTC)

If the "old" talk-page has nothing of note in relation to the new mainplace replacement work, then by all means - don't move it. Just tag it for speedy deletion. Its been so long that I forget what is an Admin-only option and what isn't & that was one of them. -- George Orwell III (talk) 00:52, 18 March 2014 (UTC)

Thanks. Londonjackbooks (talk) 01:36, 18 March 2014 (UTC)

Display/watchlist et al

Just a reminder in case its slipped your mind: Might it be worth at least including some kind of hint to update (whatever: personal biological 404 status) are the enCA and enGB equivalents of MediaWiki:Watchlist-summary when the main (en) version changes? Your dismissal test looks good so far, but only for the en(US!) case. AuFCL (talk) 04:30, 18 March 2014 (UTC)

Kindly ignore. By the time I remembered /en-gb you'd already done it. AuFCL (talk) 05:07, 18 March 2014 (UTC)

MediaWiki:Gadget-addViafData.js syntax?

Noticed in passing this change. I admit I am not familiar with the "$'" query syntax, but from context something here looks slightly wrong. Are you sure you didn't mean:

	var viaf_query_input = $('<input type="text" name="viaf_query" id="viaf_query_input" size="60" value="' + wgTitle + '"/>');

—instead? (In case it is not obvious, I think there should there be an "=" between "size" and its value: here 60?) AuFCL (talk) 21:55, 21 March 2014 (UTC)

Sectioning formatting

Question. Has something changed with sectioning formatting within the last day? See output here. Thanks, Londonjackbooks (talk) 06:32, 23 March 2014 (UTC)

It has been fixed or it fixed itself. Thanks, Londonjackbooks (talk) 06:49, 23 March 2014 (UTC)

It was propably me alright - Sorry about that - was done with best of intentions :( I restored the "old" code covering that nuance so you should be fine (now that I know not to go anywhere near it again).

How many pages did I screw up and where? Just point me to them & I'll help out b4 I call it a night. -- George Orwell III (talk) 06:58, 23 March 2014 (UTC)

Just that one page, and I re-saved it. Sleep well! Londonjackbooks (talk) 07:00, 23 March 2014 (UTC)

A minor question about FIS

Hi. In the process of proofreading, I am replacing all floating images of unbroken text-wrap with FIS. I rarely use the margin-top parameter, but when I applied it HERE, there is no spacing difference when I tried 10 or 20px, so thought that I should let you know. It's really not an urgent issue, so please don't feel pressured.— Ineuw talk 08:29, 24 March 2014 (UTC)

I think even I can field this one. At present there is no margin-top parameter to {{FIS}} which is why setting it does nothing at all. There is, however, a cstyle parameter which (interestingly) does not appear in the template documentation. I modified your page from margin-top=10px to cstyle=margin-top:10px as a working example which you should be able to fine-tune as appropriate? AuFCL (talk) 11:57, 24 March 2014 (UTC)

Help:Maintenance tags

Oh sorry, I forget it. Thanks for reminding me. Bozky (talk) 09:48, 28 March 2014 (UTC)

Thank you

Thank you for your help at Author:Frank James Sensenbrenner, Jr., much appreciated, -- Cirt (talk) 13:36, 1 April 2014 (UTC)

Please explain when reverting

I noticed that you recently reverted (within an edit that also included some other changes) my contribution with this: https://en.wikisource.org/w/index.php?title=Dhammapada&action=historysubmit&diff=4841345&oldid=4841236

I understand that in the English Wikisource, other than in the German one, you're generally not linking to external sources other than sister projects. However, it'd be a good idea for you to explain, even shortly, the reason you're reverting other users' contributions in order to motivate new users, as long as they seem to be trying to be productive.--Flekstro (talk) 19:37, 1 April 2014 (UTC)

Just to keep you updated

Hi GO3. Everything is running fine, and just to let you know (in case someone wonders), that the "CharInsert" gadget is superior to the "Special characters" of the new wiki editor, which is limited to the basic characters while CharInsert has the full extended range.— Ineuw talk 19:57, 4 April 2014 (UTC)

Thanks for the feedback, Ineuw - it does make a difference

From what I've been able to gather from the sidelines, CharInsert was "developed" with an eye towards many of the now-realized enhancements in mind. All the recent code updates bringing us Universal Language Selector, the typography refresh, and other accessibility enhancements have only worked to improve my local copy - even the most unlikely of characters render properly for me for the first time (in view & after a save that is; still a null box more often not in edit mode though).

The issue now seems to be just cosmetic; too much repetition and overlap between character sets - plus the layout is still sort of disorganized/sloppy. We really need to trim it down to definitive default sets and let folks add & remove additional groups as needed on their own. ⊕ I'll get to it one day! -- George Orwell III (talk) 09:52, 5 April 2014 (UTC)

td/dot

Thank you for looking into this but the following doesn't work...

{| width="25%" {{td/dot/sandbox|Example text}}||{{fsp}}1{{tr}} |} {| width="25%" {{td/dot/sandbox|Example text}}||{{fsp}}1{{tr}} |} By comparison with the existing template: {| {{td/dot|Example text}}||{{fsp}}1{{tr}} |} The 1 should be at the end of the line. ShakespeareFan00 (talk) 07:49, 6 April 2014 (UTC)

@ShakespeareFan00:, I did mention it wasn't going to swap right in for the existing template & more refinement was needed. It works without all that extra table-cell creation involved at the end (fsp ) is all...

<nowiki>{| width="25%" |{{td/dot/sandbox|Example text|111}} |}




Template:Td/dot/sandbox

</nowiki>:::Plus I couldn't figure out where one cell was opened and the next closed in the template "tree of trees" - Good luck either way.

ps You might want to review it's history - please see {{SimpleLeader}} -- George Orwell III (talk) 08:33, 6 April 2014 (UTC)

OK, As I don't have the expertise to look at this in depth, I've effectively deprecated {{td/dot}} by it's removal form use, until someone else can come up with an effective soloution. ShakespeareFan00 (talk) 08:50, 6 April 2014 (UTC)

For some obscure reason, removing all line feeds worked. :( ShakespeareFan00 (talk) 10:31, 6 April 2014 (UTC)

Dr. Johnson

Many printed works of Samuel Johnson appear signed "Dr. Johnson". (Indeed, that is how he is best known.) There is also a redirect on WP from "Dr. Johnson" to "Samuel Johnson" (as the lead says, ...often referred to as Dr Johnson). Hence the redirect here, too (though you've deleted it). ~ DanielTom (talk) 10:35, 6 April 2014 (UTC)

And the point of the having such redirects over simple, piped-inline wikilinks here on wikisource would be what exacly? Timesavings? Do you expect those who follow your transcriptions to have sooooooooo much follow-up proofreading troubleshooting to do that the time saved by having this kind of redirect already in place will surely save them 6 maybe 10 seconds per instance encountered? - a life-time investment of maybe 5 extra minutes to pipe this kind of interlink instead too much of a burden here? What am I'm I missing exactly?

Sorry if I sound a little peeved here - the little lady has been at the desktop looking over Doc Johnson's fine line of "toys" ever since she glimpsed me come across and delete it many hours ago  :( -- George Orwell III (talk) 11:07, 6 April 2014 (UTC)

I thought you were going to tell me why "Dr. Johnson" isn't a valid redirect, even though it is used in numerous wikis, and Author:Samuel Johnson leads to a disambiguation page, but judging by your "argument", you seem to be against redirects in general, so expecting a serious answer from you on this was perhaps misguided of me. ~ DanielTom (talk) 11:25, 6 April 2014 (UTC)

@DanielTom:, It might very well be a legit "A.k.A." for this author in certain circles (or even in many, many distinguished circles) but it is just not unique or notable enough for me to be comfortable with keeping it around so the unknowing can "trip over it" and start associating it with some other 'Johnson' who also happens to be a doctor...or worse - champion the practice as an example setting a precedent, justifying similar pointless excursions in template or redirect 'arts n' crafts'. Pen-names like Bught Rindestone, Kata Puphin or James P. Qwuirk rise to the level where there is no question about the association between real & fake even to most of those who are encountering the nuance for the first time. I can't say that about ol' Doc Johnson - sorry. Its little more than an earned title & his real last name the way I see it.

Ultimately, things like this make more clutter than anything else.

And honestly. How many times would you expect to apply such a redirect-driven wikilink here on Wikisource in your transcription lifetime? A dozen? maybe 2? What is the point exactly? Now you can explain that to me. -- George Orwell III (talk) 12:00, 6 April 2014 (UTC)

You don't necessarily need to apply them in transcriptions, readers (never mind editors) might still look for the page "Author:Dr. Johnson", as I did yesterday. ~ DanielTom (talk) 12:04, 6 April 2014 (UTC)

Yeah but you already know Samuel is his first name so your searching was going to be skewed even before seeing the results come up compared to someone who is on this trail of bread-crumbs for the "first" time - nevermind the nuances of setting search parameters here in on-site.

And why wouldn't a piped wiki-link serve the same purpose ultimately? In both cases you only see Dr. Johnson in blue amongst the rest of the text & either method takes you to the full Author page anyway. Is not stating this familar nick's 'crush of significance' re: the author in the Author: header's note field enough to inform readers about this? Again, I don't see the possible benefits outweighing the possible negatives here - not with that usage. Sorry. -- George Orwell III (talk) 12:29, 6 April 2014 (UTC)

That's okay, thanks for your time. ~ DanielTom (talk) 12:41, 6 April 2014 (UTC)

Lost in renaming

@George Orwell III: Please hold off on name changes and moves until the parties involved resolve the names.— Ineuw talk 16:03, 8 April 2014 (UTC)

Hi GO3. I was asked to look at this project which has internal sections named Book I, Book II, etc. but then, I found out that it's also a physical series of three two volumes (also named Book 1, Book 2).

Thus, I created commons:Category:Mexico,_Aztec,_Spanish_and_Republican_(Books) with the three sub categories to store the book and images, but the existing volume Index:Mexico,_Aztec,_Spanish_and_Republican.djvu wasn't renamed because I don't know what happens to the validated contents on WS. Can you please help me here? Many thanks.— Ineuw talk 04:40, 8 April 2014 (UTC)

cc:@William Maury Morris II: and @Gumr51:

For clarification purposes, please note it is actually two physical books, Volume I, already proof read, has three internal sections (called Books) and each its own chapters. we are about to begin with Volume II, not sure how many internal books and chapters.--Raúl Gutiérrez (talk) 14:44, 8 April 2014 (UTC)

@George Orwell III: In Ineuw's statement above he asks to "hold off on name changes and moves until the parties involved resolve the names." That decision Ineuw mentions was done several hours ago immediately after he contacted us. Respectfully, —Maury (talk) 00:22, 9 April 2014 (UTC)

{{paragraph tag}} — sans parameters?

Hello.

For some time I've been aware that this template generates exactly nothing when not accompanied by any parameter. May I tap you for your thoughts on why it was designed like this? Did you code it this way deliberately as a hint that a raw <p> might be a better way, or is there some other subtlety I've overlooked?

Unless you have any objection, I'd like to slightly recode the opening line from:

-->{{#if:{{{1|}}}|<p class='{{{class|pclass}}}' style='<!--
...elided...
-->{{Paragraph tag/parse|{{{10|}}}}}<!--

-->' lang='{{{lang|en}}}' dir='{{{dir|ltr}}}' {{#if:{{{id|}}}|id='{{{id}}}'}}<!--

-->><!--

-->}}<!--

—to:

--><p class='{{{class|pclass}}}'{{#if:{{{1|}}}| style='<!--
...elided...
-->{{Paragraph tag/parse|{{{10|}}}}}<!--

-->'}} lang='{{{lang|en}}}' dir='{{{dir|ltr}}}' {{#if:{{{id|}}}|id='{{{id}}}'}}<!--

-->><!--

—i.e. to generate the class/lang/dir/[id] attributes on an otherwise empty <p> tag in this situation instead.

I would have made this a /sandbox mock-up, but you appear to already have an experiment in progress, and I do not feel what I am proposing is really all that technically fraught. However I really would like your thoughts particularly if you think this proposal is a bad idea.

Regards, AuFCL (talk) 11:00, 14 April 2014 (UTC)

This is conflicting. First point, this nuance wasn't by design and only realized it myself much later on. Second, I decided to leave it as it was for the simple reason that I saw no benefit in "correcting" it. As you know, the application and possibilities of the paragraph tag are largely lost on the average contributor and I figured why generate the tag when its not applying any "real" attributes & settings - nobody really cares either way. My hope was if you're not going to use the template at least get into the habit of using the [paragraph] tag (also largely a fail to date).

But if you feel uniformity trumps all else in this instance then I can't in good conscience argue with that - templates should be making life easier for all; not used to carve out poor practices or policies that, lets face it, 99.8% of folks just don't care about never mind grasp to begin with. -- George Orwell III (talk) 00:04, 15 April 2014 (UTC)

Thank you for the background. Pretty much as I suspected, and truth is, I am somewhat similarly conflicted. In some respects I'd like to at least change the template to indicate when it is in fact generating nothing useful to let one community know what is going on…

Of late I have caught myself typing {{p|aj}} as a "filler" paragraph start and wondering if <p> (or {{p}} if it didn't actually make things even worse!) is more "honest" as I really don't want to be limiting subsequent future display option choices. Also the though of hitting the parser with effective strings of </p>s gives me the willies, as I know it broke things badly not so very long ago…

In short, no real compelling case for change. Thanks again for the lesson. Stupidity über Alles (← may need grammatic attention)? AuFCL (talk) 02:39, 15 April 2014 (UTC)

Template:Header page displays a mysterious reference to notes.

Hi. I noticed that right below the template page header, a mysterious {{{notes}}} parameter(?) is being displayed. I tried locating it's source in the template (which I understand very vaguely) and in the documentation, but found nothing. It causes no problems, I was just curious and thought of asking where it's originating. — Ineuw talk 19:54, 14 April 2014 (UTC)

From what I've been able to gather - its just a leftover from the early days to help illustrate & differentiate what amounts to html tables, green part & blue part, making-up a single template in the end.

This was easily accomplished by not piping a default null value for the notes parameter in the code. In other words, in the template code,...

{{{notes}}}

... should have been (note the inclusion of | )...

{{{notes|}}}

...for the parameter to still be valid but never display a value unless manually added by an editor.

You're right about it not "hurting" anything but it is unusual and "poor practice" to say the least. -- George Orwell III (talk) 00:14, 15 April 2014 (UTC)

{{Css image crop}}/{{FI}} et al

First up, thank you for fixing my idiot mistakes here and here. Both change remarks noted and (more than) entirely agreed. D'Oh!™ indeed.

To the main issue: If you squint a bit, these two templates overlap in what I consider an uncomfortable way. May I propose stepping back a bit and considering the "building blocks" involved a bit, so that future users can construct what they really need instead? It strikes me that between these two there are (at least):

1. presenting a resizable image
2. captioning an arbitrary image
3. rotating an image
4. cropping an image
5. selecting a sub-page from a multi-page image

As you've already noted I have attempted to add the last (#5) to FI/FIS, with your help I consider reasonably successfully.

What are your thoughts regarding #3 & #4? Should these be imported into FI/FIS? In which case a true rival to Css image crop emerges (with different syntax/semantics); or should #2 be stripped out of FI/FIS to permit the building-block approach to be adopted?

It strikes me this is a bit of a minor crossroad of opportunity, with both opportunities and pitfalls either way. Your thoughts appreciated. AuFCL (talk) 01:42, 20 April 2014 (UTC)

Really? I consider "the cropping of images" to be something that should take place off-line, then uploaded to commons when done; end of story. This whole on-the-fly, CSS-image-crop template approach, while quite interesting & quite worth the time screwin' around with it imho as well, will "never" a.) become an acceptable practice around here; not to mention b.) ever work properly. Without getting lost in the weeds, your [our] 'boundary box' is not "static" from namespace to namespace nevermind transclusion from Page: to Main, then add in the ~3em lost on the "left" thanks to Dynamic Layouts and you [we] are pretty much dreaming out loud here.

Point 1: images should [dynamically] render automatically in a size appropriate to the User's settings & setup without infringing upon those who do not share the same setup or settings themselves. This is why I first hoped to recover the IMG tag from the wiki-markup only to find myself working on FI as a result of inaction on my hopes.

Point 2: drives me crazy cause there is no standard practice here afaik. Personally, if I was in the position of "cleaning-up" low-quality image files for high-quality ones like most respected contributors seem to do ideally, I'd keep the original caption as part of the image & alt= the same in the mark-up's File: string. Why folks insist on cropping out the existing caption only to struggle with re-adding it manually later on kind of makes me laugh to be honest. Also the wiki-markup's built-in "caption" is useless & should be avoided rather than emulated imho.

Point 3: was "working" on that until I stopped to reply. I think the feature is sorely needed now when once did not. The reasoning; the amount of complex-table re-creation madness might be curbed if folks could re-use the printed tables found in the original work(s).

Point 4: I addressed first in the opening sentences (I think)

Point 5: Kudos to you for that one. Its something that I 'meant' to get to and just plain forgot to address (which is the reason I truly appreciate our little chats/experiments - you always make me "think")

I'll leave it there until you catch-up. -- George Orwell III (talk) 02:16, 20 April 2014 (UTC)

Not at all a "vomit;" rather thank you for validating my own (suspicions.) Pity I stuffed up the page logic and thanks again for fixing it.

My (previously carefully unstated to try not to influence your response) observations were:

• Image cropping is an "interesting" diversion: technically possible, but functionally irresponsible.
• Similarly rotating images. However, as a sop to proofreading I do have a quick-and-dirty Javascript helper. If interested please ask, otherwise omitted for brevity.
• #2 (captioning) Guilty as charged, though often performed whilst wondering why. Thanks for confirming doubts.

These are the only issues I consider worth pursuing. Does this constitute being "caught up"? AuFCL (talk) 02:36, 20 April 2014 (UTC)

Let me back-up re: Image-cropping a bit. It's not that I think having this feature is a waste of time; just that without advances on the PR extension's developmental front to go along with it, I don't see how it can become a game changer on a large scale around here. Part of the problem is 99.8% of our source documents are not born digital, thus dimensions (e.g. 'boundaries and boxes') vary from one scan-set to the next - making standardization of header and/or footer (& lets not forget sidenote) cropping a one-off affair with each new work requiring a re-tooling of the defaults to align logically, again, with 'boundaries & boxes' at hand.

But if you take something serialized as well as 'modern' (like the latest volume of the U.S. Statutes at Large for example), one could consistently "crop" thousands of left then right facing pages without worry - the dimensions never change throughout in other words. If the PR extension would let us manipulate the text layer instead of just dumping it - true & valid programic transcription could take place & "cropping" of some sort could have a role in that case. Too bad they are still stuck on properly recognizing a text-layers as something other than 'really long file metadata'.

Anyway, I just wanted to clarify my previous re: "cropping".

Rotating: Thanks but no-thanks. god damn if we can't get this guy's "formula" into a Lua script and templates or something (I'm kind of on an anti-javascript jihad lately). Damn if I know how & WikiData has sucked all the oxygen out of the room it seems. -- 03:08, 20 April 2014 (UTC)

Converted/Preaching to/You are.

Bugger it: I have to admit Yoda got reverse-Polish just about spot-on right. AuFCL (talk) 03:36, 20 April 2014 (UTC)

Re: Internet Archive re-derive

I've rerun the derive for that item.[1] Just dropping me a link to stuck items (on email or any talk page of mine) is enough. The general process is to wait for the regular cleanup admins do there, or email info a t archive.org. --Nemo 06:18, 20 April 2014 (UTC)

Thanks very much

Thank you for your formatting help at Author:Adrianne Wadewitz !

Much appreciated,

-- Cirt (talk) 09:06, 26 April 2014 (UTC)

{{Index talk remarks}}

Hello. I hope this is not a foolish question: what exactly is the advantage of the current form in the above template of:

{{#ifexist:{{ns:107}}:{{PAGENAME}}|<includeonly>
...
</includeonly>}}

over

<includeonly>{{#ifexist:{{ns:107}}:{{PAGENAME}}|
...
}}</includeonly>

—in other words why test for something you may not subsequently want to include, when you might as well cut out both the test and the contents up-front? AuFCL (talk) 23:50, 3 May 2014 (UTC)

You're right. I was more concerned with the resource usage and was thinking of ways to reduce it. Turns out specifying the Index talkspace for detection (ns:107) uses less resources than the previous magicword "talkspace" did. At the same time, this specificity prevents the display of the template without any 'clude tags needed. Edited. -- George Orwell III (talk) 00:28, 4 May 2014 (UTC)

Thank you—worth knowing. BTW how are you assessing "resource usage?" (Not criticising: just curious.) AuFCL (talk) 00:49, 4 May 2014 (UTC)

In edit mode & after at least 1 "show preview" submit, you should get the parser profiling data wayyyy at the bottom of the page. I just removed the doc template and compared the before and after. In that case, results were pretty clear so I saved the changes.

Please tell me the ppd table isn't lost like some other components when Users are set to UK or Canadian English. -- George Orwell III (talk) 01:01, 4 May 2014 (UTC)

(Pardon my tardy response.) Thanks again. Not a surprise (you appear to have addressed my only potential concern with the profiling data by performing a dummy initial view.) Checked presence both with en-CA and en-GB: O.K. both cases. AuFCL (talk) 04:24, 4 May 2014 (UTC)

Author:Ermine Cowles Case

Umm. Curious. Why above? I assume the plan is to eliminate the non-english-language authorities; or is there another matter I should know about for next time? I just sort of went mad and piled in all the "majors" I stumbled across when correcting the prior VIAF mix-up. AuFCL (talk) 23:11, 8 May 2014 (UTC)

I'm just sour per the latest exchange with another self-absorbed wiki-pinhead over the whole wikidata/authority control thing and took it out on all the recent additions is all. While I admittedly waivered on this from one week to the next, I've decided from now on that if an authority is not easily verifiable in "English", its not worth the trouble of adding locally here (which in all honesty, should have been the approach taken that would be the most inclusive as well as the most reliable considering the domain language at hand). Don't consider it a policy or anything; just me. -- George Orwell III (talk) 23:44, 8 May 2014 (UTC)

I can live with sour. Doesn't that just mean experienced and a moderately observing student of human nature?

"self-absorbed wiki-pinhead" is interesting, though, as I think it accurately describes you, me, and just about everyone who cares (or indeed does not care) about this slightly warped exercise we all seem mildly addicted to.

I'll try to be good and not insert the BNFs / SUDOCs et al in future. I mainly read them merely to verify alternate names or dates which may be missing or vague in VIAF, and that part usually comes across pretty much despite language, doesn't it? AuFCL (talk) 05:42, 9 May 2014 (UTC)

Addendum: I think the aforementioned SAWP just identified themselves. FFS! If I start acting anything like that I grant you full authority to slap me, please! AuFCL (talk) 05:56, 9 May 2014 (UTC)

Kolja21?

Anyway - insert whatever you like. My point goes to the desired ISO standard that will usurp them all (well, capture them all at once if I understand right) and rarely will you find anything other than the original 4 associated with an ISNI. Its just taking forever thanks to the German switch to a single GND in the interim. -- George Orwell III (talk) 19:50, 9 May 2014 (UTC)

Mysterious changes in Editor icons

Hi. I noticed in the past two mw releases that the editor icon for Italics keeps changing between A and I. Just curious how this comes about.— Ineuw talk 04:41, 9 May 2014 (UTC)

Two reasons likely; the first being your primary lang being set to en-ca and, for whatever developer reason(s), that causes all sorts of quirks like that. Apparently, it doesn't cycle through the assigned list of letters per languages properly or something and gets thrown off where to "stop" and render. I'll take a closer look & see if I can't reduce/modify the list when I get the time.

The entire en, en-us, en-ca & en-gb thing is turning into a real issue in many places. So far, only Wikidata had addressed it with any meaningful results; results where the other two not selected become fallbacks for the primary more often than not. This was accomplished by both listing all 3 in the user preferences there and applying all 3 babel boxes for en, en-ca & en-gb on the User's front page. Now, when a data item has no "description" for example, I no longer get French or Spanish or German as alternatives to my primary (en) but get en-ca & en-gb instead. I never got around to seeing if we could accomplish the same through the babel thing fwiw.

The second thing will become moot sooner or later. The WikiEditor folks used spirited icons originally but are moving to individual .svg/.png files the last I checked. Spirited icons are compiled into a single "sheet" and each image is then selected by giving the x/y coordinates for the icon somewhere in the coding or the coresponding .js file(s). They finally accepted the fact this approach caused more bloat than doing toolbar button images the "old" way with stand-alone image files and are moving in that direction if not already there (which might also be behind your bouncing button). Again, I'll have to take a closer look time permitting. -- George Orwell III (talk) 20:14, 9 May 2014 (UTC)

As usual, everything makes perfect sense. Please don't waste your time with it. Mentioned it just because I noticed the changes. As I now recall, we already had a similar issue regarding the commons link icon/button on images related to the user's language setting. Thanks for reminding me of its importance.— Ineuw talk 02:21, 10 May 2014 (UTC)

Remembering Adrianne Wadewitz by National Collaborative for Women's History Sites

• Remembering Adrianne Wadewitz by National Collaborative for Women's History Sites

Your reformatting changes at Remembering Adrianne Wadewitz by National Collaborative for Women's History Sites seem to cause the image to load incredibly slowly, line-by-line, on my browser -- why is that?

-- Cirt (talk) 02:32, 10 May 2014 (UTC)

Its cause your browser loaded then cached a thumbnail of the core image yesterday or whatever while after the changes it loads and caches the core image - letting it dynamically resize itself if need be from then on. It should happen once (unless you don't use a [large] cache) if at all. If its an issue just revert my changes. -- George Orwell III (talk) 03:10, 10 May 2014 (UTC)

Forgive for butting in. I watch {{FI}} and {{FIS}} templates' related issues closely because I use them exclusively since their implementation. Based on my experience, I think that the images' slow rendering relates to the namespace and not the template. I have the same issue with the PSM grayscale images. I pasted your article into this sandbox and it renders instantly.— Ineuw talk 03:21, 10 May 2014 (UTC)

Ah but was the .jpg already cached by then? Its filepath remains the same regardless of what namespace is calling it. Try again but substitute an image you haven't viewed yet File:Cartoon explaining how to orphan an image.png and then I might change my mind. -- George Orwell III (talk) 03:28, 10 May 2014 (UTC)

As usual GO3. You're 100% correct. After clearing the cache & browser cache, the first time, the image rendered just as slowly in the sandbox as in the main namespace.— Ineuw talk 03:34, 10 May 2014 (UTC)

Yeah, unfortunately it still loads quite slowly for me too, virtually line-by-line. Is there a way to fix that ? -- Cirt (talk) 17:48, 10 May 2014 (UTC)

It was line by line at the first upload, but very fast from the 2nd visit onwards.--Mpaa (talk) 21:41, 10 May 2014 (UTC)

Exactly. If this was an example transcluded in from the Page: namespace or viewed on a tablet/mobile device, the image would/should quickly resize itself on-the-fly if the dynamic layout changes or when a view-screen is rotated after that intial load takes place. I'm sure there is even a way to speed that up but a solution hasn't presented itself just yet.

Like I said before, if the slowness is a problem a.) try using fixed widths instead of percentages in {{FIS}}; or b.) go back to the wiki-markup image thumbnail approach. -- George Orwell III (talk) 21:57, 10 May 2014 (UTC)

Thanks

Hi,

I'm going to do a test run of 10 imports due to the https://en.wikipedia.org/wiki/Wikipedia:WikiProject_Open_Access/Signalling_OA-ness project. My first times writing a bot for Wikisource, so thank you for cleaning up that minor test edit. Maximilianklein (talk) 23:02, 10 May 2014 (UTC)

Love among the chickens

Looks like the whole thingamajig has been fixed now. Thanks a lot once again for your help! :D —Clockery Fairfeld (ƒ=ma) 12:17, 11 May 2014 (UTC)

Re: Collapsible Nav Menus

Brilliant! I confirm it works under enGB for whatever that is worth. Thank you. AuFCL (talk) 01:20, 22 May 2014 (UTC)

I can't take the credit. fyi - the gadgetized .js is exactly the same as the .js that was removed from the main wmf vector-skin folder and the .css was also trimmed from the existing definition set(s) prior to their "removal" as well. Edtoker just verified where I was hoping to go with this first so I figure best not to wait on the fools behind the change - especially when comes to skins overall - and copied his efforts to en.WS instead (sometimes being lazy pays off eh?).

And, as I suspected, the removal was self-serving for some and annoying for the rest but neither side seems to want to take up the core "problem(s)" behind the removal. If I waited on them for the proper "fix", I'd probably forget all about this and overlook the fix if and when it took place. I figure this way we are less likely to miss that fix while restoring the feature in the interim. -- George Orwell III (talk) 01:37, 22 May 2014 (UTC)

Thou art preaching to the converted. Got the hat, tee-shirt somewhere and merely awaiting allocation of official membership number… Credit offer still good. If unwanted feel free to distribute however you see fit. AuFCL (talk) 02:27, 22 May 2014 (UTC)

{{center block/s}}, {{center block/e}}

A bright lad like you ought to be able to figure out the question. Want me to go ahead and do 'em? AuFCL (talk) 06:52, 3 June 2014 (UTC)

Umm, there is a problem with Template:Block center/s and Template:Block center/e? — billinghurst sDrewth 13:35, 4 June 2014 (UTC)

@sDrewth: Sigh. No. Just me being overly cryptic. This was a carry-over from an off-topic suggestion elsewhere where GOIII suggested replacing {{block centre}} with {{centre block}}, and my pointing out the two template (families) have a lot of dis-similarities, at least one of which included the fact that no provision for cross-page usage (i.e. above two templates mentioned in title sort of don't exist!) had been made in one "family."

Hope this defuses the confusion. I was going to await his thoughts on related matters pending (i.e. committal of sandboxed template changes: {{dotted TOC page listing/sandbox}}, {{center block/sandbox}}) before proceeding with *real* damage. O.K.? AuFCL (talk) 14:04, 4 June 2014 (UTC)

Ugh, I didn't even know that we had picked up center block and don't think that we should have ever done so due to the naming confusion. Personal preference is one set that does it, not multiples. These templates have been through iterations and discussions about naming before they ended up at block (center|left|right) plus float (left|right) and our discussions then were the desire and intent to keep it simple. — billinghurst sDrewth 14:13, 4 June 2014 (UTC)

…and…I'm…supposed…to…be…disagreeing…with…this? Exactly why? I didn't create the damned things. My role was to try to bend them both into somewhat similar shape before some other cowboy decides to axe one of them without thinking the consequences through properly. However if the "proper" people want to carry this through I am more than happy to bow out and let you get on with it… AuFCL (talk) 14:31, 4 June 2014 (UTC)

Yeah all that is was "beta stuff" at best so nothing was written in stone here just yet. I should have some more free time after this weekend but don't let me stop anyone from experimenting until then either. -- George Orwell III (talk) 21:39, 6 June 2014 (UTC)

I saw you pushed out {{dotted TOC page listing/sandbox}} and then backed it out again almost immediately. What broke? Anything I can help with (or should I take Billinghurst's veiled hint and butt out and let you guys play in private)? AuFCL (talk) 11:52, 7 June 2014 (UTC)

No such thing & never back down... I rolled it out only to learn even more TOC type templates call upon {{Dotted TOC page listing}} so I backed out until I get around to looking into the effect on those templates (Talk about resource bloat!). Otherwise, the straight usage looked fine for the handful of uses I checked before reverting. -- George Orwell III (talk)

Not in the slightest attempting to teach/suck eggs, but this might be handy? AuFCL (talk) 01:10, 8 June 2014 (UTC)

I have deliberately held off tainting {{centre block}} directly, but currently believe {{centre block/sandbox}} to be stable and usable. I added a three-way comparison with {{block centre}} to {{centre block/testcases}} and will concentrate on making it exactly compatible only if you think it worthwhile (I really currently do not.) Only {{centre block/doc}} left to be updated if/when the sandbox is merged (or you catch up via things like this. Good change tag, by the way. Hope this is clear this time? AuFCL (talk) 09:45, 17 June 2014 (UTC)

Personally, I don't think its worth merging Center Block with Block Centre but if push comes to shove, the real compatibility testbed would be to take one or two poems from Londonjackbooks' repository of works and see if the two are truly interchangeable or not. I'm still having trouble accepting {{{title}}} - it's width value specifically. To me, the title still seems to be centering to the boundary box (page) rather than the column (div) when it comes to verses of poetry (caveat: maybe I'm just tired). -- George Orwell III (talk) 10:26, 17 June 2014 (UTC)

Wonder if this is another one those IE vs... situations? I updated the sandbox to test this and it definitely works under Firefox with the current template. I also modified the sandbox to make "title" its own sub-div in hopes this might work more broadly. The 100%/inherit width was only necessary to establish the maximum span size and was probably not really beneficial. Hope you catch up on your rest. I'm off too for now. AuFCL (talk) 11:12, 17 June 2014 (UTC)

Re: Template:SimpleLeader/doc

Pardon misunderstanding. I thought your intent had in fact been to capture a particular point in evolution of the template. Just for my edification, what is the advantage of referring to &hellip?curid=349627 over {{dotted TOC page listing}}, unless you anticipate retiring the whole template/development line (eventually)? Otherwise I must be missing the point… AuFCL (talk) 03:26, 8 June 2014 (UTC)

per...

"Not in the slightest attempting to teach/suck eggs, but this might be handy? AuFCL (talk) 01:10, 8 June 2014 (UTC)"

...I just wanted to stop it from appearing on "the list". Using the page id method accomplishes that while also landing on the current version as if I kept the proper interlink. Move on; nothing special about cleaning that list (for now).

The bigger remaining problem is {{dotted TOC page listing}} being called by {{TOC row 1-dot-1}} (less than 100 uses) and {{TOC row 2dot-1}} (less than 500 uses). Completely insane. I don't know where to begin on that front so I went ahead and recycled {{Dotted TOC line}} to mirror {{dotted TOC page listing/sandbox}} - thinking a fresh forked start might be better in moving

forward - but that raises all sorts of other issues & I can't seem to focus on an approach either way. Comments? Thoughts? -- George Orwell III (talk) 03:57, 8 June 2014 (UTC)

O.K. clever.

Once again, pardon the fact I was previously thinking somewhat at cross-purposes to you: i.e. I was thinking in terms of evolving {{dotted TOC page listing}} and its sub-variants and perhaps eventually eliminating things like {{Hansard/TOCwa}} (~2 uses?) entirely; whereas I think you are approaching it in terms of starting a new line entirely(?)

My thoughts run along lines of: all approaches being similarly painful, might as well produce a "reasonably generic" approach—i.e. your work on the "recycled" {{Dotted TOC line}})—and then (maybe via some kind of robot?) dragging all the outlying cases back to the now-trusted central instance.

Right at present I feel I am being a bit of a useless onlooker merely playing catch-up. Thanks for your kind explanations. I think my best strategy is to hold off for now and maybe jump back in later if there is anything I can usefully do without interfering with the general scheme. AuFCL (talk) 04:45, 8 June 2014 (UTC)

Consider the current approach not just for TOCs but html tables in general - all inline styling via template or templates; first to attain a "baseline" table setting throughout, then to have cell or cells / row or rows / column or columns deviate from that "baseline" by further (or contrary?) inline styling. The eventual problem(s), even with shortcuts such as table style parsing, is that application of such methods become too complex for the newbie to easily grasp all the way up to exceeding built-in resource limits, etc. (e.g. template bloat).

I've "solved" the need to waste setting "baseline" inline resources once before by defining classes for each cell expected in a single table row - see this 4 column list of EOs using {{Eolist-item}} where hardly any inline-styling, to override the baseline(s) or otherwise, is needed. I was thinking of starting something similar for TOCs from scratch with a 'new' family of templates mirroring the EOlist-item approach OR at least prune the attributes that can be class defined in the existing template(s) whenever possible and see what can be done to eliminate/unify templates at that point. I just don't know if the effort is worth it when folks are so hard to "re-train" if you understand what mean by that. -- George Orwell III (talk) 05:20, 8 June 2014 (UTC)

The basic idea is sound, and I for one applaud it. However, doesn't it lay a lot of responsibility on the part of sysops to preempt all the nuance CSS which users "just expect to be there," however unreasonably? This whole tortured issue of tweaking potential leader content is representative of the problem, and regrettably I personally am nowhere near even the suggestion of an answer. (That aside, please continue. Sounds good, bearing in mind I think I am condemned as(/to be) one of your retraining converts. AuFCL (talk) 06:09, 8 June 2014 (UTC)

Ah, but even the leader tweaking takes place within an unmodified TD element. The "constant" problem is sometimes the cell (TD) is styled and in other instances the element (usually a DIV) within the cell (TD) is styled. If the table related elements were css defined to some agreed upon standard(s), then templates could strictly deal with formatting just the content - as well as allow overriding the definitions (if need be) - using inline styles. -- George Orwell III (talk) 06:38, 8 June 2014 (UTC)

Point accepted. Still sounds good. I probably had 'content:' on the brain. AuFCL (talk) 09:26, 8 June 2014 (UTC)

...and class-"basicWS" is drawn from MediaWiki:Common.css/Tweaks.css I see. I can see I shall have to get more of a grip on the CSS storage structures (not because I really need to; rather more because I'm a nosy b*****r.) AuFCL (talk) 09:39, 8 June 2014 (UTC)

right - I broke most of the definitions out into "sub-pages" hoping to identify what is needed and what is mirroring the defs coming down from the servers (work in progress). I added basicWS & commonWS a few weeks ago in hopes it would be applied in some form or another as explained earlier. -- George Orwell III (talk) 10:03, 8 June 2014 (UTC)

Media Viewer

@AuFCL - is Media Viewer working for you in the File: namespace? If not, disable it in your user prefs for now. -- George Orwell III (talk) 05:20, 8 June 2014 (UTC)

I don't quite follow this hint: as I do not believe I ever enabled Media Viewer (and it no longer appears to be on the list of alternatives, at least under that name. Checked if it appeared if I suppressed enGB as well: no dice.) Maybe the option only appears if previously enabled back when it was on the Beta program? AuFCL (talk) 06:09, 8 June 2014 (UTC)

Preferences, Appearance tab, Files section. Apparently, this is what you should see if it is "working" File:Media_Viewer_Desktop_-_Large_Image_Opaque_Info.png for all? image files. -- George Orwell III (talk) 06:25, 8 June 2014 (UTC)

Eep. What can I say? I am an idiot. Yes, it was selected (now OFF.) Frankly if Zonotrichia atricapilla was supposed to change its appearance it must be pretty subtle. (I think that must mean it was working for me all along, no?) AuFCL (talk) 09:24, 8 June 2014 (UTC)

I've never seen any change in my File: namespace's layout but that is probably due to my still running IE8. I just saw the new layout as depicted in the linked PNG on a friend's laptop (iMac w/ Safari) for the first time last night. Otherwise, it was just loading modules that never seem to change anything for me here and thought I'd mention it. 'nuff said. -- George Orwell III (talk) 09:54, 8 June 2014 (UTC)

Revert button

Dear George, we had already an unpleasend conversation @Captain Nemo. (Example: Author:José P. Rizal is still faulty.) The revert button is for vandalism! You use it for edits you don't understand and/or dislike. Your behavior is arrogant and unproductive. I will stop correcting errors at Wikisource. --Kolja21 (talk) 15:46, 13 June 2014 (UTC)

@Kolja21: ??? I never touched that author after your edit. Please clarify.

Plus, I only changed one recent edit of your's where a lower case "x" in the GND string should have been a capital "X". Is Author:Archibald Standish Hartrick the Author you really mean? Wasn't my capitalization correction of your edit (a removal) the optimal GND file at the end of the day? -- George Orwell III (talk) 21:26, 13 June 2014 (UTC)

I think I owe you thanks...

...but for what I am (for I hope obvious reasons) not sure. Does it even make sense asking just what in hell happened in the last twelve hours? (If too painful then just accept the undirected thanks and move on...) AuFCL (talk) 01:55, 16 June 2014 (UTC)

It all started with BeeswaxCandle deleting some giberish added to your front User: page by an annon. IP contributor earlier today. For laughs, I opened the "new" page view stat tool I had just discovered & that's when I saw the jump in page views and the like starting back around the 26th of May. I don't know who or what was going on exactly. After pouring over the data, I've come across several accounts getting blown up for weeks at a time then whatever it is moves on to someone else (see Logs in Admin Noticeboard for the top 4 offenders). Funny thing is, its almost always a User: or User talk: page that was never created (by the owner) or deleted by one of us at somepoint. Weird stuff.

That's why I figured the best thing to do was undelete something of your's and move that to the open User: page to "close" or "throw off" whatever it is pointing to that url. ... or maybe you are just that popular on the interwebs? ... know where flight 370 went down for sure? ... playing in the world cup on the side? One never knows for sure who's on the other end :) -- George Orwell III (talk) 02:21, 16 June 2014 (UTC)

O.K. Pretty much as I had suspected, but thank you for filling in the blanks. Perhaps there is a lesson in this (for me too of course) and that is when a new user is {{welcome}}d, perhaps a dummy User page might be worth creating as well? (At least until the spammers evolve. Hah! Anyone for an arms race?) AuFCL (talk) 02:33, 16 June 2014 (UTC)

..and where is MH370? Well according to the aircraft spec.s, without refuelling about the only place you can guarantee it isn't is (maybe) Heathrow airport. AuFCL (talk) 02:50, 16 June 2014 (UTC)

┌──────┘
This may be a rather long shot (and is almost certainly not worth following up) but I wonder if I provoked somebody when I made this edit? The timing curiously matches the sudden surge in pageviews directed against my user page. AuFCL (talk) 12:27, 16 June 2014 (UTC)

Diving into stuff like this really isn't my bag. And I see not much has changed in the last ~24 hours but I took a stab in the dark anyway and blocked that IP for a day just in case it is still somehow behind this (if it ever was that is). I'll come back to this in day or so.

Either way, if this continues to be of concern I'd open a discussion on the Admin Noticeboard where there has been some movement since my last concerning other User: accounts w/similar traffic.

FYI... I'm slated for a workstation replacement in the coming week (still trying to bribe my way down to Windows 7 instead of 8) so if I suddenly "disappear" for any noticeable amount of time, please understand its not of my choice. -- George Orwell III (talk) 22:52, 16 June 2014 (UTC)

—

Do you know why the pagelist elements at Index:The Bostonians (London & New York, Macmillan & Co., 1886).djvu that are labelled with mdashes have so much left padding? It looks horrible. It seems to me this is a recent change of appearance but maybe it has been there for a while but I have not noticed. I had a look in the template and the css class is "index-pagelist", the definition of which I cannot find. Hesperian 02:30, 18 June 2014 (UTC)

Pardon my interference, but where-ever it comes from, I do not believe any class to be the offender here. Each dash is prepended by a <span style="visibility:hidden;">00</span> and that I believe is the origin of your padding. May I venture a run-away javascript might be a useful direction for further researches? AuFCL (talk) 07:46, 18 June 2014 (UTC)

Thanks for that hint. Culprit is PagelistTagParser.php, lines 66–71, written into the code by Tpt on 23 November, presumably deployed here more recently. Hesperian 09:11, 18 June 2014 (UTC)

Congrat.s on pinning it down. I was close, but gave up after realising it was no longer JS. The best (nasty!) "fix" I can think of for the moment is to put something like a > span[style="visibility:hidden;"] {display:none} into your common.css. If this seems too scary, you might want to put multiple lines and qualify the "a" selector with .quality0, .quality1….quality4 viz:

a.quality0 > span[style="visibility:hidden;"] {display:none}
a.quality1 > span[style="visibility:hidden;"] {display:none}
a.quality2 > span[style="visibility:hidden;"] {display:none}
a.quality3 > span[style="visibility:hidden;"] {display:none}
a.quality4 > span[style="visibility:hidden;"] {display:none}

On second thoughts, doing it that way might be best for now. AuFCL (talk) 09:46, 18 June 2014 (UTC)

FWIW... I know Tpt has recently added several parser tests to the PrP extension but I can't see how any of those would affect a change in the normal .php(s) and typical rendering. IMHO, the first step would be to bring this to Tpt's attention. -- George Orwell III (talk) 23:36, 19 June 2014 (UTC)

Update: Looks like Tpt knew about this and has applied a patch already - see https://git.wikimedia.org/summary/mediawiki%2Fextensions%2FProofreadPage. Problem is, the patch won't likely come down to us until the next 1.24wmf "upgrade" is released next week. -- George Orwell III (talk) 00:24, 20 June 2014 (UTC)

…which is what I meant (but apparently did not make clear) when I wrote "for now" two responses back. Must admit I'm mildly concerned about that public function testIsNumerci. Looks like a possible typo. for testIsNumeric to me? AuFCL (talk) 01:58, 20 June 2014 (UTC)

Good catch! I left him a note about it on his French talk page.

Plus I see no reason to patch this locally. Its not like a super major exclamation-point spacing violation or anything. -- George Orwell III (talk) 02:29, 20 June 2014 (UTC)

Osric: A hit, a very palpable hit. AuFCL (talk) 03:50, 20 June 2014 (UTC)

About FI and FIS

Hi, here I am seeking for news about FreeImg and FreeImg/span. The idea is, to re-import the updated version into it.source and perhaps to convert it in Lua. Did something substantially changed into the code (yes, I could browse history, but I feel more comfortable to ask you for a brief comment)? Have you any suggestion/warning? Are they somewhere in wikisource world other similar templates/modules? Thanks! --Alex brollo (talk) 21:59, 13 July 2014 (UTC)

Offhand, I'd say 'yes' some changes were made and stuff was added/removed as well but I'd need to review things myself in order to accurately list them too; sorry. @AuFCL:? -- George Orwell III (talk) 23:08, 14 July 2014 (UTC)

Hello @Alex brollo:. As I am not sure of the starting point for your familiarity with FI/FIS, the most recent changes (~April?) were to add some page-selection capability (ability to select which image within say a TIFF or PDF file) and a limited ability to rotate the image (mainly achieved through the application of CSS classes.)

This is the broadest outline of recent changes I can think of. Please let me know if you need me to dig out the details. AuFCL (talk) 00:10, 18 July 2014 (UTC)

Something is jiggered with Template:Chart

Something is jiggered with Template:Chart, it has scripting errors. I cannot see which underlying templates invokes which module, hopefully you know the underlying guts of the components. — billinghurst sDrewth 12:06, 14 July 2014 (UTC)

@Billinghurst:, Not really my baby - I just imported the latest revision(s) at the time from WP in hopes it would set things right (I think it did at the time fwiw). Its John Vandenberg who did away with our locally developed version and instead imported the christmas tree of templates and sub-templates in the Chart family we have now so maybe he knows more than I do in this case.

Update: Its not the Chart template et. al causing LUA errors, it was the documentation subpage causing a timeout. I disabled the call to the documentation for now. -- George Orwell III (talk) 00:22, 15 July 2014 (UTC)

On a related note, this is but one "family" of templates that relies more and more on advances made in LUA scripting over the passage of time. We have fallen woefully behind in this aspect. I've tried to keep WS as current as possible to new/replacement Module:s found primarily on WP with some good fortune to date but find myself "boxed out" more & more by high template protections imposed on WP when it comes to differences, collaborating, etc. Not being an admin there, is there any worth in applying for the "lesser" right of (I believe) template editor and how should go about it? TIA. -- George Orwell III (talk) 23:40, 14 July 2014 (UTC)

I pretty much guessed something like that, though was in the middle of other issues, so just had to drop and run. Found similar issues trying to resolve other errors when the template was <includeonly> so was hiding all the components to resolve but showed all the bits for the documentation. <ugh> Re template editor right, I have granted that (it is admin allocatable) and left a note to that effect at enWP. I much prefer the low fuss approach, as I know that it isn't your wish to be playing in that pool.— billinghurst sDrewth 06:59, 15 July 2014 (UTC)

Cases

Earle cites, for example, "Lynch vs. Turrish, 247 U.S. 221", which is was 247 U.S. 226 (wrong-now fixed) here at WS. Is the second number in the case citation a page number? If so, would not page 226 be the first page of the case? How would Earle's "221" come before 226? Not sure how these things work... Londonjackbooks (talk) 03:41, 17 July 2014 (UTC)

You're not going bonkers - You've come upon an error in the original case citation listing here on en.WS is all. I've fixed up the redirs and listing to correctly reflect the case's real start page, 221. Thanks for that. -- George Orwell III (talk) 01:14, 19 July 2014 (UTC)

Good to go. I did a little more digging, and found this website... Too bad WS doesn't display page numbers as well for reference. Thanks for making the corrections, Londonjackbooks (talk) 01:40, 19 July 2014 (UTC)

"We" couldn't work that in at the time because the inline page embedded page numbers thing [the 'page numbers within text' option] wasn't working and that is how almost all court reporters are published (see this example page & scan for where pages 535, 536 & 537 originally started in the original record to see what I mean).

I'm sure there is a way to back-track and work page numbers in with a BOT but without actual scans to back up all the current cases to begin with, it seems more work than its worth right now. -- George Orwell III (talk) 02:17, 19 July 2014 (UTC)

I see. Thanks for the explanation, Londonjackbooks (talk) 02:33, 19 July 2014 (UTC)

Shaw essay on Ibsen

As you are the only person to reply to my copyright inquiries, I'm posting this question directly to you. Shaw (d. 1950) published this essay in 1891, without copyright claim stated, but in London. Is it eligible for upload at Commons? Here? Thanks for any assistance you can provide. --EncycloPetey (talk) 02:11, 18 July 2014 (UTC)

I don't see why not as it was published in 1891 in the US (pre-1923) as well... & assuming they are both relatively the "same" content-wise of course.

And fwiw... that whole U.S. requirement to affix copyright, etc. etc. was made formal in the 1909 U.S. Copyright Law(s) so anything published before then should not rely on that nuance in your considerations regardless. -- George Orwell III (talk) 01:41, 19 July 2014 (UTC)

So, to be sure I understand, a work published in both the US and the UK prior to 1923 would not be under copyright in either country, even if the author is British and died less than 70 years ago? I just want to clarify that it's OK to upload the work to Commons. --EncycloPetey (talk) 02:36, 19 July 2014 (UTC)

Yes, that is the way I've come to operate the requirements (and even more so if the work is pre-1909 & published in English in both nations). I find this table of checklists to be quite helpful whenever I face these questions - though it does tend to overstate post 1996 & restoration cases a bit. Plus Commons is good for policing stuff like this & the worst that can happen is we'd need to host the source file locally instead.

Again, I'm but one American idiot - you really should ask these @ Possible Copyright Violations to get a wider & more accurate view. -- George Orwell III (talk) 02:55, 19 July 2014 (UTC)

Thanks for the Cornell link; that will be useful. However, it does look to me as if that table only considers status of works with regard to US copyright. As I said, you're the only person who seems to field these questions here, so I might need to ask on Commons. --EncycloPetey (talk) 03:18, 19 July 2014 (UTC)

Index:NTSB RAR-92 01.pdf

OK, If you'd like to consider a cleanup on the HTML tables at the rear of this, I think I can this one is nearly complete. ShakespeareFan00 (talk) 00:47, 21 July 2014 (UTC)

Template:Index

Is Template:Index still needed or can we cull it? It is unused. — billinghurst sDrewth 01:00, 22 July 2014 (UTC)

Done -- George Orwell III (talk) 01:04, 22 July 2014 (UTC)

+ Template:Element — billinghurst sDrewth

also Done -- George Orwell III (talk) 02:38, 22 July 2014 (UTC)

The last is a bit of a shame, as I understood and applauded the intent; but was awaiting it reaching a stage where I thought I might be able to usefully contribute. (Obvious) offer extended if you ever want to resurrect it. AuFCL (talk) 03:14, 22 July 2014 (UTC)

In the end, that wasn't the optimal approach for the task at hand as some block elements 'can't use' inline elememnt attributes and vise versa; in addition to even more caveats coming into play when, among other nuances, display:inline-block is set for example (thus the birth of the Paragraph tag template approach where every tag should host its own 'table' of parsed stylings to select from in order to avoid such pitfalls).

I know that seems excessively redundant at first - hosting x number of basically the same set(s) of attributes & their values for each element over and over again - but thats the 'path of least resistance' when it comes to balancing newbie usability with customized flexibility imho.

But If you have the time and still cope with an "urge" to stamp-out stupidity, why not start similar templates to Paragraph tag like Div[ision] tag and Span tag yourself? -- George Orwell III (talk) 03:39, 22 July 2014 (UTC)

Re: last paragraph above. O.K. That should extend me just enough to make a fool of myself. I have a couple of minor ideas in that area anyway. (2½ points: 1. No spare time immediately. 1.5. I intend to start off slowly on this. 2. Open invitation to look in from time to time and stamp out my stupidity should it come to light [please?].) AuFCL (talk) 22:36, 22 July 2014 (UTC)

┌──────┘
Perhaps I've taken your kind offer a little too literally, but I have made a (trivial at this stage) start on {{span tag}}—based heavily upon your very own {{paragraph tag}} but with a limited variant attribute ability. I hope this remains within your perceived bounds of utility. If it is a Bad Idea please let me know before I push the concept too far. AuFCL (talk) 11:16, 23 July 2014 (UTC)

No worries - its along my lines of thinking exactly. The question was always the approach to a closing tag and I would have folks type </span> too rather having start & end tags. -- George Orwell III (talk) 23:05, 23 July 2014 (UTC)

Index:Practical Treatise on Milling and Milling Machines.djvu

To aid transcription is it possible to get the pages noted on the talk page rotated?ShakespeareFan00 (talk) 16:24, 24 July 2014 (UTC)

125 Stat.

Volume 125 awaits! Would you like to do the honors? I should be able to tend to it in the near future if you prefer. Hope things are well. Tarmstro99 16:43, 25 July 2014 (UTC)

No, I got it:) I can do the 'trim excessive margins' thing on it over the weekend and have it up by Tuesday or so. Thanks for the heads up & hope this finds you & your's well too. -- George Orwell III (talk) 00:14, 26 July 2014 (UTC)

Request sanity check on Dropinitial template please

Hello.

Absolutely no urgency on this as (sofar as I am aware) I have a working, just not terribly pretty solution. I noticed the {{Dropinitial}} template was generating margin: CSS-value strings which Firefox 31.0 at least completely rejects. Things like margin:0.00em0.10em0.00em0.00em; (prior default) are being treated by this browser as effectively identical to margin:0 0 0 0;. You will see my couple of false attempts at correcting the template and if you have any suggestions for a more robust approach I would value them.

I hope at worst I am salving an outright browser bug? Regards, AuFCL (talk) 07:58, 1 August 2014 (UTC)

Looks like you over-thought the solution. Your last would have spaced only the default values (when no overriding User: input was made). Putting the space "outside" of the #if string produces the spacing regardless of a manual input or the automatic default being used. -- George Orwell III (talk) 01:27, 2 August 2014 (UTC)

Brilliant! That both works and looks a lot neater. Much appreciated. AuFCL (talk) 01:50, 2 August 2014 (UTC)

Re: your recent edit of MediaWiki:Proofreadpage index template

Noted in passing: I suspect the second id="ws-author" should most probably be id="ws-illustrator" perhaps? AuFCL (talk) 11:31, 3 August 2014 (UTC)

Thanks. id="ws-translator" actually. -- George Orwell III (talk) 11:34, 3 August 2014 (UTC)

Lesson for both of us then. I noticed the edit just at the point where I was about to rush off and attend to domestic demands; my primary alarm was multiple occurrences of identical id= values and was not paying (sufficient) attention outside that narrow scope. Good thing you were, and perhaps also good I didn't have the control bit or I might have made a stupid "correction" no matter how well-meant. AuFCL (talk) 20:45, 3 August 2014 (UTC)

problem with ar.wikisource.com not connecting to wikicommon file correctly

I'm at wikimania right now and I had a talk with the wikisource guys during a meet-up. if there is a bug with the arabic wiki page is it possible for me to create pages in the multi-lingual domain till it's fixed? When is a document created there?

Re: old.wikisource versus en.wikisource

I started by Multilingual Wikisource because it is used in other projects as well, so bug fixes would have more impact, but I'll take a look here as well (probably not today) :-)

Careful - the "trend" for other language-wikisources lately has been to import our scripts; not the old.wikisource ones.

Where can I see the "page-highlighting" script?

It's part of our MediaWiki:PageNumbers.js file when it probably should be its own .js. The "problem" at one point was nobody knew that highlighting & toggling was suppose be working with the introduction of "Dynamic Layouts" (e.g. on any mainspace work transcluded in from the Page: namespace (Boyle, Roger (1617?-1687) (DNB00)), you should have a 'Display options' sidebar with 3 working choices. On Mul.Wikisource, many complained these options do no appear let alone work when it does appear). When en.WS divested from importing these scripts from old.wikisource and hosted our own versions did we correct the broken features.

And by "re-writes of Base.js & PageNumbers.js" you mean local changes on English Wikisource or recent changes to the Multilingual Wikisource?

Local English re-writes. If you compare ours to mul.ws, you'll see alot of differences - the remaining headache being MediaWiki:Base.js overriding the normal LST scheme only to disable it again as a default. Its when we tried to isolate Base.js from the now working PageNumbers.js did the portlet-display-option & their cookie settings go a bit overboard.

What is the problem you noticed with the cookies? Helder 01:52, 10 August 2014 (UTC)

No problem, it works but it seems [to me] its a bit overkill & probably does not need to deviate from existing cookie approaches that any other sidebar option use by design ... but I've been wrong before. -- George Orwell III (talk) 02:10, 10 August 2014 (UTC)

Other issues

Some of the existing "issues" that existed prior to deprecated .js modules, etc.

• The sidebar 'Display options' should only appear on mainspace and Translation: space pages that contain content transcluded in from the Page: namespace. Currently, the 'Display options' header without any options under it is always generated for any main namespace work (like Executive Order 13625) and/or is generated in the Translation: namespace with just the layout options (Translation:Phoenix Pin) regardless of having transcluded content within it or not. I'm sure this can be corrected somehow by detecting the proper ext.xxxxx.js file or something similar.
• arrgg... my memory fails me!! I know there are more things and will add them here when they come to me.

A common.js script that doesn't need loading

Hi, I'm in the middle of biting the bullet and moving to WikiEditor. I can't work with half a toolbar on a small laptop screen. In the process, I've just looked at MediaWiki:Common.js and note that there's a script being loaded for DL links for use in the Dictionary of Music and Musicians. I assume that ThomasV put it in about 3.5 years ago. We dumped that method of doing the Dictionary as it wasn't behaving as expected and Phe said that frWS weren't doing things that way anymore either. As a result the script for MediaWiki:Dictionary.js doesn't need loading for everyone, everytime. Beeswaxcandle (talk) 02:37, 16 August 2014 (UTC)

Done - I always had the feeling it wasn't up to scratch but since I never used it myself, I left it alone in case other folks did.

Since I have you, I'm curious to know if you also lost your tool bar when NOT logged in. Plus - do you have nop inserter gadget enabled? -- George Orwell III (talk) 02:50, 16 August 2014 (UTC)

Can't tell you about not logged in as I never edit without being logged in. However, I do have the nop gadget enabled, but I've only ever had that appear in the tools menu on the left side of my screen (monobook). I've just switched it off and tried back to the old toolbar, but it's still overwriting with a cut-down version of the WikiEditor bar. Beeswaxcandle (talk) 03:02, 16 August 2014 (UTC)

You should see what happens when not logged in - your common.js file has over 150 errors in it (if one can trust IE's debugger that is). Might as well check your preferences per Help:WikiEditor/Troubleshooting afterwards. -- 03:11, 16 August 2014 (UTC)

Index:Paradisus Londinensis 1(2).djvu

What happened to Plate's 18 and 89 in this?

They appear to have been omitted from the original scans. (Although are present in the Google Books PDF) 11:35, 21 August 2014 (UTC)

fuck if I know. I didn't upload the file originally & never worked a single page in the file either - looks like I only re-ran an OCR routine on it to add a text-layer. Personally I wouldn't wipe my ass with such garbage uploads but some folks can't resist putting the cart before the horse it seems. I can't fix it at the moment either so move along to something worthwhile. -- George Orwell III (talk) 20:57, 21 August 2014 (UTC)

Tweak common.js

Sorry to bother you; is it possible for you to tweak my common.js so that a new line is not inserted after a <br /> is added? Thanks, Londonjackbooks (talk) 01:50, 22 August 2014 (UTC)

@Londonjackbooks: DONE! How about now? -- George Orwell III (talk) 02:07, 22 August 2014 (UTC)

Like magic! Always appreciated, Londonjackbooks (talk) 02:14, 22 August 2014 (UTC)

Page replacement help

Hello. No hurry on this, but there are images missing from Volume 5 of Byron's Works, and I have uploaded page replacements to Commons from a similar edition of the work. I have created a gallery of the images here (the work's Talk page), hopefully for your convenience. Please let me know if you need anything else. Thanks, Londonjackbooks (talk) 03:11, 17 August 2014 (UTC)

I'm out of the page replacement business for a bit. I just upgraded to 64bit Windows 8.1 & IE 11 so much of my "old" software still sits on my old workstation & I don't know when I'll get around to importing all the tools I need to do this again - sorry. -- George Orwell III (talk) 20:38, 20 August 2014 (UTC)

No problem. I believe it will take a while for that volume to be completed anyway... Slowly but surely... Do you know anybody else who knows how to do the task? Thanks, Londonjackbooks (talk) 23:16, 20 August 2014 (UTC)

{{FI}} or {{FIS}}

I am only using {{FIS}} for images because it's good for left or right offset and centered images and thus find {{FI}} redundant. any comments? — Ineuw talk 09:56, 21 August 2014 (UTC)

<shrug> lofas a sheged be? <-- very poor Hungarian>

What else am I suppose to say here exactly? Use what works for you.

Personally I'd use FI for whole page (or centered) images only - you might not see any difference nor may there be any actual difference as well. -- George Orwell III (talk) 21:04, 21 August 2014 (UTC)

If I may contribute my—probably unwanted—2¢:

I am inclined to use FI everywhere I can get away with it (perfect for centre and full-width situations.) My only quibble is that float= usage "drops down a line" with respect to flowed text around the image; and this last I consider is a problem affecting all <div> usage (and even affects "raw" [[File:…|side]] usage as I'm sure you both would know—do the developers?) under mediawiki and not at all specific to FI. AuFCL (talk) 23:34, 21 August 2014 (UTC)

You know the answer to this - change the containing div to display:inline or display:inline-block depending on the situation no? -- George Orwell III (talk) 23:42, 21 August 2014 (UTC)

In short I pretty much represent the mirror to @Ineuw:'s original statement, so you still hold the casting vote. (You probably didn't want that rôle either.) AuFCL (talk) 23:34, 21 August 2014 (UTC)

What in blazes am I missing here - Vote for what? Deprecate one for the sake of the other? I'm confused -- who is complaining exactly? -- George Orwell III (talk) 23:42, 21 August 2014 (UTC)

:-D Ha ha. Your Hungarian delivers the message perfectly. I like a person who speaks their mind. A minor correction "lo fas" should be "lofas". Also, judging from this and your response to the following post, it's time for you to take a nice vacation. In all honesty, I was wondering when you'll hit this point. My best advice would be is close this office and don't respond to idiotic posts like mine and the one below. Remember, I am on your side. — Ineuw talk 23:12, 21 August 2014 (UTC)

Sorry. Its not you folks. Its Microsoft and their god-damn changes from XP to 8.1 & from ie8 to ie11 that is making me "irritable" today. -- George Orwell III (talk) 23:42, 21 August 2014 (UTC)

Kulcha differences. Don't sweat it. As Ineuw stated earlier: we side yours are on: O.K.? All is appreciated. AuFCL (talk) 23:51, 21 August 2014 (UTC)

CharInsert and WikiEditor in ProofreadPage

Hi, I have a suspicion that there's some interaction going on between the various extensions. In the Page: namespace the CharInsert section is putting itself above the WikiEditor toolbar. In all other namespaces, it's below the edit window. I tried not logged in at work this morning so that was the Vector skin on a big monitor and it was doing the same. Except that it was initially drawing in the usual place and then redrawing above the toolbar. My normal set up is FF (currently 31.0), Win 7, 14″ screen, monobook skin. I've just tried not logged in on IE8 and it does the same. If I had a larger monitor I wouldn't worry about it so much, but with a small one I'm continually scrolling to see the character list, the page image and the insertion point. It's particularly bad with the Greek tranch of characters as these are usually footnotes with the text on the image and the insertion point in the edit box at the bottom. If you've got any thoughts that could direct me to a way of solving it, I'd be appreciative. Beeswaxcandle (talk) 08:45, 19 August 2014 (UTC)

Whoa! That's a new one. Can you do a screen grab so I can "see" what you mean exactly. CharInsert "was" suppose to replace EditTools (old setup where character stuff was in its own div container after the edit summary, etc.) and I see you have already toggled the setting that controls that (true/false) since this post so I'm wondering if anything has changed since then.

Please be patient, I am also struggling to learn Windows 8.1 & IE 11 for the first time on top of all this Wiki stuff. -- George Orwell III (talk) 20:35, 20 August 2014 (UTC)

@Phe:, @Tpt:

== The new location of the CharInsert ==

Many thanks for moving it to the top and for the space gained at the bottom.— Ineuw talk 03:54, 21 August 2014 (UTC)

First I post and then noticed the above post from User:Beeswaxcandle Here is my screen grab: — Ineuw talk 03:59, 21 August 2014 (UTC)

File:New toolbar layout.jpg

@Ineuw: -- Same thing as BWC? only happens in the Page: namespace?

I don't know what happened but I'm not behind the change and it's not happening for me under Win 8.1/IE 11 either. — George Orwell III (talk) 04:07, 21 August 2014 (UTC)

Yes. Exactly the same. I don't know who did it, if it wasn't you. (still take the credit and we chalk it up to a miracle.) But you should ask user:Helder.wiki. He seems to be looking into things and perhaps reading some posts where I commented some time ago about the lack of vertical editing space without having to move the scroll bar. — Ineuw talk 04:20, 21 August 2014 (UTC)

That's one option, but I don't think anything he did caused that - otherwise I suspect it would happen in all the namespaces. I don't really know which extension a new bugzilla for this should go under either. - ProofRead Page, CharInsert or WikiEditor. Either way, the best case scenario would be to make that position a per User: option instead of "fixing it" back to the way it was before; that would solve BWC's problem while letting you keep it there. -- George Orwell III (talk) 04:32, 21 August 2014 (UTC)

@Ineuw:: I didn't change anything related to this (at least not intentionally). And for me (on Firefox 31) the tools are below the edit area (above the summary field). Helder 00:16, 22 August 2014 (UTC)

@Helder.wiki: - just to be clear - w/Firefox, the CharInsert bar appears above the Summary: field in all namespaces including the Page: namespace (the namespace where at least 2 users report the bar appearing above the Wikieditor tool bar.) -- George Orwell III (talk) 00:49, 22 August 2014 (UTC)

In my previous comment, I was referring to what I see when editing this page (ns = 3). On Page:A Compendium of Irish Biography.djvu/615 it appears above WikiEditor toolbar. On Wikisource:Authors and Help:Audio it appears bellow the edit area. The results are the same with Google Chrome 36. Helder 01:06, 22 August 2014 (UTC)

Well again, not seeing this under IE11.

The only thing that leaps out me is the fact all the other namespaces w/WikiEditor enjoy the benefit of a null clear:both div tag prior to the start of the .editOptions div while the page namespace doesn't have one and that happens to be where the #editpage-specialchars div is 'inserted before' normally. -- George Orwell III (talk) 02:17, 22 August 2014 (UTC)

I modified the CharInsert css to include a clear:both ; any changes for you folks? -- George Orwell III (talk) 02:43, 22 August 2014 (UTC)

Just to be clear, I don't care if the CharInsert appears on top or bottom. For me it's the same, so don't worry about me because I now have vertical screen space. I only mentioned it to back up BWC and I understand his concern. It is still on the top for me after you included clear:both in Windows XP, Firefox 31.0. In a short while, I will provide you with a table of all OS + browsers I have installed. — Ineuw talk 03:30, 22 August 2014 (UTC)

Well then its something more than I can isolate - @Helder.wiki:, how about you? -- George Orwell III (talk) 03:41, 22 August 2014 (UTC)

┌─────────────────────────────────┘
Just to flog a dead horse . . . I created this small reference table of Browsers and OS's for what it's worth. Everywhere it's on top.— Ineuw talk 04:39, 22 August 2014 (UTC)

re: Windows 7 Ultimate / Internet Explorer 11... F12 Developer tools should "tell you" fairly quick what's possibly causing the bar to load above WikiEditor in the Page namespace. There's really not much else I can do about on this end; an hour or so into it & I can't even find a way to force-replicate this. Looks like one of youse should open a bugzilla on this. -- George Orwell III (talk) 04:53, 22 August 2014 (UTC)

Here is the Windows 7 Ultimate / Internet Explorer 11 output: Perhaps it helps you. User:Ineuw/Sandbox2.19:40, 22 August 2014 (UTC)

I'll look through it but its really the "next button down" (Console and/or debugger) in the sidebar of F12 Developer Tools that tells us what is going on with the loading of components.

On a side note - you still have the Old LST and OCR button gadgets loading when their equivalents are being loaded directly in your common.js file. This means they are loading 2x for no good reason. Please disable the 2 gadgets in your User Prefs and the lines your Common.js should still enable those features with less loading & resource drain. -- George Orwell III (talk) 20:42, 22 August 2014 (UTC)

I will try again. — Ineuw talk 01:16, 23 August 2014 (UTC)

tl;dr above. In short the charinsert stuff flops around in Page: ns and has for a while. Similar the old toolbar loads in different slabs. I put it all down to ResourceLoader, and the order that it is fed. It even flops around on the same page depending on the caching. <shrug> As long as it is there, I put up with the variability. — billinghurst sDrewth 00:32, 23 August 2014 (UTC)

Thnks. I agree the loading must play a role here in some way (& was the reason coders walked away from the old EditTools scheme for CharInsert in the first place), but the fact its only happening in the Page ns - and is bouncing in above the WikiEditor UI where CharInsert supposedly doesn't have a position setting coded for in it - reveals some inconsistency between the way normal edit boxes (textarea) are rendered versus the header-body-footer design in the ProofreadPage extension.

Fwiw... I pinged Tpt & Phe for this discussion but I doubt that will get their attention anytime soon. -- George Orwell III (talk) 01:01, 23 August 2014 (UTC)

@billinghurst: actually, I would say ResourceLoader is what allows you to be sure that modules will be loaded in the correct order. It is usually just a matter of setting the appropriated dependencies for each script (let it be with the option "dependencies" on MediaWiki:Gadgets-definition or with mw.loader.using( ['some', 'modules'] ).done( andSomeFunctionWhichUsesThoseModules ) ). Helder 01:04, 23 August 2014 (UTC)

Of all the people and of all our issues, you'd be the one we'd beg to review & refresh our various gadgets/scripts that have been "left behind" over the months of deprecations & the like related to .js usage. I think I correctly mirrored the RL dependencies for CharInsert & CharInsert core javascripts for example but the 'placeholder' portions no longer seems to target the correct container to insert itself before under the latest core refinements (at least not before the right one in the page namespace that is). -- George Orwell III (talk) 01:15, 23 August 2014 (UTC)

For some reason, if I disable the gadget and then execute mw.loader.load( 'ext.gadget.charinsert-core' ); (copied from MediaWiki:Gadget-charinsert.js) in the console after the page is loaded, the tools appear in the botton even if I'm on "Page" namespace. Also, if I disable "Enable the editing toolbar" (some other script is still loading it even if I choose not to use it, but that is a separate problem) and re-enable the gadget, it appears in the botton. I'm not sure about the cause of this. Helder 03:02, 23 August 2014 (UTC)

Not unheard of. Stuff like that happens for a period of time, goes away and sometimes comes back later; sometime not.

I've always found it strange we load MediaWiki:OCR.js from MediaWiki:Common.js for example, which is a toolbar button that should never be used anywhere but in the Page namespace - but it doesn't load like the other Proofreading tool buttons do. Then we have a "gadget" to "disable" it MediaWiki:Gadget-ocr.js. Nobody questioned it when it was introduced and now its been so long that nobody cares to ask either but it seems like the button generation script should be the gadget and users should choose to enable it if they want to or not; not the other way around like it is now. -- George Orwell III (talk) 03:48, 23 August 2014 (UTC)

Agreed. Since the introduction of default gadgets a long time ago (on rev:85902), we should not be creating gadgets to set global variables just to disable scripts which otherwise would be loaded. We just need to move the loader code into the gadget, set it as default and let users disable them (saving a request and making the global scope cleaner). Although we need to think in something to avoid loading Base.js multiple times (e.g. once per gadget). Maybe creating a mw.hook there and using it on the gadgets. Helder 12:48, 23 August 2014 (UTC)

That would be fine BUT I think you've fallen into the old Labeled Section Transclusion trap. The LST extension is part of wikisource's default package & the default method for using LST is to wrap content in <section begin.... and <section end... tags. At some point, this normal state was overridden in [what remains] of our MediaWiki:Base.js file (which is called, again, from MediaWiki:Common.js) to use ### symbols to wrap content instead. Then, the overridden LST method is restored by setting the MediaWiki:Gadget-old LST.js gadget as a site wide default! Its crazy!

So what you have in the sandbox needs to be further separated so this LST & OCR button nonsense no longer has anything to do with each other as well. -- George Orwell III (talk) 19:37, 23 August 2014 (UTC)

So, I noticed this recent change to the ProofreadPage extension and then decided to paused the execution of the JavaScript code in the beginning of that function. Executing the three lines step by step, I can see the "editpage-specialchars" being moved above the "wikiEditor-ui" by the following line:
$editForm.find( '.wikiEditor-ui-text' ).append( $editForm.find( '.prp-page-container' ) );

Helder 22:36, 23 August 2014 (UTC)

I think that should be .insertAfter instead of .append but I am confused as to why they are fiddling with the editForm at all as well as somewhat illiterate when it comes to coding so don't go by what I say. All I know is the core CharInsert.js should decide where the bar should go (before the editOptions container for most Users) via...

$( '.editOptions' ).before( placeholder );

or before/prepend the old editTools container, which comes well after both the editForm & editOptions containers are rendered. -- George Orwell III (talk) 22:58, 23 August 2014 (UTC)

The gadget position its buttons correctly, the problem is that a few moments later the script from ProofreadPage extension moves it to another place... Helder 23:08, 23 August 2014 (UTC)

Helder, then how did Inuew (directly below) manage to stop the loading of the CharInsert bar above the WikiEditor bar by avoiding some Gadget(s) in his User: prefs altogether and just added their equivalent self... message lines directly to his common.js file instead? -- George Orwell III (talk) 23:59, 23 August 2014 (UTC)

@George Orwell III: The Charinsert returned to its position at the bottom below the edit box. All I did was is set self.proofreadpage_disable_ocr = true; and removed the tick mark from the gadget for the section tags. — Ineuw talk 02:12, 23 August 2014 (UTC)

That's the ticket!

@Beeswaxcandle: - should see your talk page re: user's .js settings as well. -- George Orwell III (talk) 02:19, 23 August 2014 (UTC)

@Beeswaxcandle, can we take it that your changes along Ineuw's remarks earlier today has also rectified the CharaInsert toolbar over the WikiEditor toolbar in the page namespace problem for you too? -- George Orwell III (talk) 04:42, 24 August 2014 (UTC)

Unfortunately, no change for me. Still showing up above the toolbar. Beeswaxcandle (talk) 04:50, 24 August 2014 (UTC)

Resolved. See relevant discussion. -- George Orwell III (talk) 05:48, 24 August 2014 (UTC)

Old toolbar no longer appears in Page namespace

Tracked in PhabricatorTask T71447Resolved

<UGH!> We have lost the old toolbar, and now I only have the advanced/newer toolbar. I haven't been in the page ns for a couple of weeks, so don't know when that occurred. — billinghurst sDrewth 05:37, 23 August 2014 (UTC)

Now no toolbar with the setting on, and need to tick enhanced to have it on. — billinghurst sDrewth 21:31, 23 August 2014 (UTC)

Slow down and back up a bit please. First, see Help:WikiEditor/Troubleshooting and you'll see that only one of three settings should be giving you the "old" toolbar (unless that's been demoted recently; I don't know of that happening however). Next, you should verify this behavior is happening when not logged in as well. Please report back. -- George Orwell III (talk) 21:38, 23 August 2014 (UTC)

In the page: ns we have no old toolbar with the settings that I have had for years (tested Firefox and Chrome), and that has occurred sometime in the past two weeks, I have had no configuration changes in that time. No value in testing logged out as that gives you the default advanced toolbar. Old toolbar works fine in main and WS: nss. — billinghurst sDrewth 22:27, 23 August 2014 (UTC)

While personally I feel this is due to some combination of User Prefs settings and gadgets selected interfering with the normal loading of components and/or order of loading in relation to the Page namespace and the PR extension, others have reported the much the same and "blame" something to do with the Proofread extension itself. Please escalate Bugzilla: 69447 & lets also get Tpt & Phe in on the discussion.

Other than that, I can only go by the above instances where whittling down the amount and manner of the loading of certain gadgets has helped users in their move to using the new advanced (WikiEditor) toolbar - which if you look at LJB's and BWC's common.js files, they have moved their favorite old buttons to the new tool bar in anticipation of the "death" of the old toolbar scheme once and for all. I plead with you to [re]consider this avenue of resolution instead of giving CPR every three or four weeks to save some [apparently] super sentimental means of contributing that has been "dying off" for some time now. -- George Orwell III (talk) 22:41, 23 August 2014 (UTC)

That looks like the bug with the timetable about right. — billinghurst sDrewth 00:06, 24 August 2014 (UTC)

If so, then we might be looking at multiple fixes for other issues encroaching into this one - just go through the linked Blocks & See also bugzilla reports to see what I mean. Some of those seem pseudo related and can go as far back as being first reported in ~October 2013 if not older :( -- George Orwell III (talk) 00:26, 24 August 2014 (UTC)

Notification

Hi!

I don't know if your intention on this edit was to generate a "mention notification" (those from mw:Extension:Echo), but if so, it probably didn't because you need to be adding a new comment, signing it, and (due to bugzilla:54639) not rewritting anything in the page (which you did when changed "unknown" to "All"). Helder 00:52, 23 August 2014 (UTC)

yeah but I also added the Ping template. Wouldn't that notify Krinkle to the discussion in spite of the mentioned Bug? -- George Orwell III (talk) 01:03, 23 August 2014 (UTC)

Not if by notify you mean a notification from Echo. It doesn't really care which method the user uses to add a link to the name of another user (it can be directly, with "Ping", with "Reply to", etc...). Helder 01:06, 23 August 2014 (UTC)

File:Compendium3-draft.pdf

Any objections to me making a start on this? ShakespeareFan00 (talk) 20:47, 23 August 2014 (UTC)

Yes. Do not touch it until the Admin discussion decides the best way to host it - as a single file or by chapter files. -- George Orwell III (talk) 20:51, 23 August 2014 (UTC)

Continuation of the button fun

Conversation quoted and continued from User talk:Beeswaxcandle#Button fun:

@Ineuw talk, the changes I was referring to were dealing with removing all the drop down tabs in the advanced editor (WikiEditor) and just placing the needed buttons across the visible toolbar. Those were a few edits back however. -- George Orwell III (talk) 21:12, 26 August 2014 (UTC)

That is my dream. If the advanced editor toolbar would do away with the two drop down lists - the "Special characters," which is replaced by a better and more versatile ChrInsert, and the "Advanced". . . . and eliminate the 2nd row of the bars. — Ineuw talk 00:15, 27 August 2014 (UTC)

You mean like it is now? I can't get rid of the Proofread dropdown yet as I haven't worked out how to get those functions to work outside of it. But it should be down to two lines instead of three. Beeswaxcandle (talk) 05:51, 27 August 2014 (UTC)

Thanks for the back-up BWC, I was unavoidably away from WS for a couple of days. I think you answered Ineuw's request just like you did for yourself which is fine... but the old button temptress seems creep into his head regardless <sigh> -- George Orwell III (talk) 21:02, 28 August 2014 (UTC)

Orphans

What would you like to do with the work on orphans? Continue it in September, maybe adding the workspace? Resume it later on?--Erasmo Barresi (talk) 09:57, 27 August 2014 (UTC)

If there are no other pressing tasks, I don't see why not to continue it into the next month (and even expand it for that matter). I was surprised it got picked up so fast in the first place so I leave it up to you, Erasmo. -- George Orwell III (talk) 21:05, 28 August 2014 (UTC)

There are no pressing tasks awaiting. We could do "Work index revision" (i.e., decide what to do with WS:Works), but it is not a high-priority one. Besides, I have the feeling that orphans get more attention than other maintenance fields. So yes, let's continue it.--Erasmo Barresi (talk) 16:33, 29 August 2014 (UTC)

Thank you

Thank you for adding data. I am brand new to Wikisource. I enabled the gadget that is supposed to copy metadata from Commons but it did not seem to work and I haven't figured out why yet. And being new the rest of the workflow looks like Greek to me! Laura1822 (talk) 01:19, 29 August 2014 (UTC)

Edited to add: Did you intentionally remove the categories I had added, and if so, why? Repository of Arts, Series 1, Volume 01, 1809, January-June.djvu Laura1822 (talk) 01:30, 29 August 2014 (UTC)

You won't have much luck categorizing Index: pages since they tend to "erase" manually added ones once the available fields start to fill up (like it did for me on my edit. Those type of Cats would go under the finished product in the mainspace (or under the File: itself over on Commons).

The Index namespace is more of a "workbench" until all the individual Page:s have been transcribed. Once all the Page:s have been transcribed and Proof Read, the content is then transferred (transcluded) into the main namespace where manual categorization is much the same as if adding Cats on Wikipedia. At that point, the Index: is pretty much ignored and just kept around for edit history purposes and the like. -- George Orwell III (talk) 01:45, 29 August 2014 (UTC)

I see. Is that explained on a help page somewhere? And how am I supposed to find unfinished projects that I might like to work on if works in progress cannot be categorized? Thanks very much for your help! Laura1822 (talk) 03:55, 29 August 2014 (UTC)

We should be submitting a bugzilla to Tpt to see how we can categorise Index pages successfully. Laura's point about highlighting availability is credible, and as we continue to make the entrypoint to WS scans more visible based on interests, categorisation is one that has value. — billinghurst sDrewth 04:16, 29 August 2014 (UTC)

Thank you for that. I would like to point out that as a casual user (before I activated my account and logged in), it looked to me like there was very little here since the in-progress projects were hidden. Laura1822 (talk) 15:14, 29 August 2014 (UTC)

A while ago Chris55 proposed to categorize index pages. We don't need a change to the extension, just community approval and maybe a script to remove the categories when one changes the status to "validated".--Erasmo Barresi (talk) 16:56, 29 August 2014 (UTC)

I agree with Chris55. As a new user, I could give you a litany of things I found confusing, but the #1 would be the difficulty of finding something to work on. There's almost nothing on the main page beyond the Proofreading of the Month. Why not some links to Projects or Portals (and what's the difference)? These comments probably belong in a more public forum. Laura1822 (talk) 21:48, 30 August 2014 (UTC)

Proofreading font

Does the proofreading extension use the "ugly font" like at PG/DP? I would like to use it for proofreading. If it's supposed to be there, then something must be overriding it in my common.css: can you fix it for me? If it's not, can you tell me how to add it? Thanks for all your help! I discovered several things I didn't know were evem there (like navigation arrows) after you fixed my commons.css! Laura1822 (talk) 13:44, 31 August 2014 (UTC)

@Laura1822, I don't know anything about an "ugly font" and couldn't find anything like that being set in your .css either.

I did bump up the font size in the various textareas (edit boxes) but I don't know if it that will help. I'm leery of making changes to your .css cause its basically set to cascade settings down from one section of the layout (or skin) to the next already and if I change a setting too "high-up" in the chain, one part or another is going to be so huge that all you'll see is part of a line/letter before it get's clipped.

Anyway, let me know if the changes need reverting/tweaking. -- George Orwell III (talk) 15:11, 31 August 2014 (UTC)

Thanks! The slightly larger font size is nice. I am talking about Project Gutenberg's Distributed Proofreading font, called DPCustomMono2: faq, wiki, direct link to font. If you aren't familiar with PG/DP, then I guess I asked the wrong person! I think it makes proofreading much easier, because many of the "scannos" (l for 1, 0 for O, etc.) pop out. (They used to call it "ugly font" in some of the old faqs and help docs, but those references seem to be removed now.) Laura1822 (talk) 15:35, 31 August 2014 (UTC)

Laura1822, Okie-dokie.

If you have that font installed locally on your computer, I think it might work now in the edit boxes. I reverted the slightly larger font sizes changes I made earlier at the same time -- Plus I don't think that font will "float" anywhere else but in edit mode for the textarea fields. Let me know. -- George Orwell III (talk) 15:59, 31 August 2014 (UTC)

Works great, thanks! But of course it works in all editing spaces (like this one), not just within the Proofreading extension. I suppose that is a more complex request. Where should I make it? On the main Scriptorium? I am so grateful for all your help! Laura1822 (talk) 16:29, 31 August 2014 (UTC)

Laura1822, check it again - the "ugly font" should only be in the Page: namespace edit boxes now (hopefully). -- George Orwell III (talk) 16:56, 31 August 2014 (UTC)

Nope, still seeing it here. Thanks for trying! It's okay, I can live with it. Laura1822 (talk) 18:36, 31 August 2014 (UTC)

Laura1822, check it one last time - after that, I'm out of ideas. -- George Orwell III (talk) 19:48, 31 August 2014 (UTC)

Perfect!!!! Yay, thank you!!! If I knew how to make a full-page image display as a thumbnail here, I would show you this ! Laura1822 (talk) 19:53, 31 August 2014 (UTC)

Your recent post on Bugzilla

My hat (if I would wear one) is definitely off to you.— Ineuw talk 00:09, 2 September 2014 (UTC)

Thx!

Thank you for your help! --Zyephyrus (talk) 10:02, 9 September 2014 (UTC)

Add button request

Hi, GO3. Would you mind adding a button to my toolbar via my common.js page? The button I would like to use is Commons:File:Button redirect.png, and the text I would like to enter upon clicking is #REDIRECT[[]]. Thank you, Londonjackbooks (talk) 18:55, 11 September 2014 (UTC)

It was already there, just with a different button. I've changed it to have your preferred button. Beeswaxcandle (talk) 06:41, 12 September 2014 (UTC)

Thank you; I didn't realize I already had one. Londonjackbooks (talk) 13:43, 12 September 2014 (UTC)

School Song Of New RSJ Public School

You deleted the page saying work without author permission.. but the author had given the permission.

Please refer to the deletion discussion. Permission was granted on behalf of the author, but we received no permission from the author. There were other issues that, in addition to this problem, meant that the work was beyond the scope of Wikisource and would not be hosted here. --EncycloPetey (talk) 21:19, 6 October 2014 (UTC)

A minor FIS issue

I hate to bother you during this important month of your pending incumbency, but I would like to clear up some issues held back during the 2nd toolbar wars. (Not unlike the 2nd Punic War).

I cannot reduce the font size as it appears in the originals. If it's not possible just tell me and shall no longer pursue the subject. — Ineuw talk 23:27, 8 October 2014 (UTC)

What's the problem Ineuw? Your script/app/keystroke/etc. at some point inserted an extra equal (=) symbol for the | tstyle = = font-size:70% line and, being the little "fa feh" you can be at times, have been repeatedly spreading the improperly syntaxed parameter ever since. Remove one of the extra equal (=) signs from that line and FIS will once again deliver for you. -- George Orwell III (talk) 00:09, 9 October 2014 (UTC)

Are you intimating that I am spreading a contagion? Who else used a double = ??? What is a "fa feh"? It's not Hungarian. In any case I am grateful. Thank you.— Ineuw talk 00:25, 9 October 2014 (UTC)

No worries; just foolin' around in case that wasn't made clear.

Fa feh = hardheaded (your head is made of wood) no? Note: I'm spelling like it sounds to me based in English rather than Magyar. -- George Orwell III (talk) 00:36, 9 October 2014 (UTC)

Thanks for the clarification of the meaning of "fa fej" the "j" is pronounced as a "y" (not like Spanish), so in English it would be "fa fey". = "wooden head". (Hungarian is a phonetic language and unrelated to the Romance languages i.e. Latin/Spanish etc., or for that matter, any other language.) However, "lack or loss of focus" is more apt. — Ineuw talk 11:02, 9 October 2014 (UTC)

I soooo love the Hungarian cursing - if 'kurva' some how means whore, 'kurva ish-tan-eet' means whore of a God & not so much [wW]hore God right? -- George Orwell III (talk) 12:58, 9 October 2014 (UTC)

AH-HA !! fej = head so tej must = milk ! -- George Orwell III (talk) 13:01, 9 October 2014 (UTC)

Wow, who is teaching you Hungarian? Considering that you're in my time zone (I think) and it's early in the morning, I think that you are either in bed with, or at least having breakfast with the teacher. Am I correct? As for the exclamation of kurva istenem = "my whore God" and kurva istened = "your whore God" but neither is correct as it is impossible to translate the expression accurately. . . . and yes tej = milk. — Ineuw talk 13:20, 9 October 2014 (UTC)

Nah. nothing as titillating as that (in this case that is). I guess you can say my lineage runs down & around the Danube is all.

And afaict, the closest workable translation comes of as plain old God damn!! or God damn it :( . -- George Orwell III (talk) 13:33, 9 October 2014 (UTC)

Agreed as far as the closest translation, but the Hungarians added some paprika to make it zestier. In any case the word "kurva" is a loanword. I am not sure from which surrounding country. It could be Austrian German, Czech, Slovak, Ruthenian, Romanian, Serbian, Croatian, Slovenian, or just good old Turkish.— Ineuw talk 13:40, 9 October 2014 (UTC)

PageNumbers

Sorry about that. If you're willing to try again, I've corrected the mistakes and actually tested it here this time, rather than at OldWikisource. (Maybe the two scripts should be sync'd up?) – Minh Nguyễn (talk, contribs) 05:46, 14 October 2014 (UTC)

Its re-implemented; see prior talk page for results.

As for synching up the two scripts; you should note the Display options sidebar menu options actually work under the en.WS approach and the Old.WS never did (& believe still does not even today). So if you want a universal synch/approach you should ask them to mirror us for a change. -- George Orwell III (talk) 23:18, 17 October 2014 (UTC)

self.proofreadpage_raw_lst handling

Well aware as I am I shall be shot at dawn for bringing this up, but with regards to Wikisource:Scriptorium#HHVM_revealing_new_weirdness, what exactly is happening? Your vector.js currently specifies (line 22) self.proofreadpage_raw_lst = true; Is it conceivable that either:

1. Internet Exploder is not processing this correctly (any more? checked for console errors?); or
2. (assuming I'm reading MediaWiki:Base.js correctly—and that is a big ask) perhaps mw.config.get( 'wgCanonicalNamespace' ) is returning a case-variant of 'Page' ('page' perhaps? I just checked here: I am getting 'Page' but referrer-agent/user-agent browser quirks etc. possibly affect this kind of thing(?)) just enough to mess up the check at

function easy_lst_setup() {
        if (self.proofreadpage_raw_lst || mw.config.get( 'wgCanonicalNamespace' ) !== 'Page')
            return;

Pardon in advance—also as usual—for/if stating the bleeding obvious. AuFCL (talk) 01:38, 20 October 2014 (UTC)

I don't see any console errors or anything like that. I'm pretty sure its a load order thing - one where ResourceLoader & any dependencies should be defined in the gadget first & then I'd have to use the gadget instead of my one-line solution. I can't be bothered with Base.js for more than just the easyLST parts; any effort in resolving this would be geared towards gadgetizing the relevant portions in Base.js in the near future rather than waste time [re]patching something that has been broken from day one. Neville's comments were the catalyst I needed to re-address this. -- George Orwell III (talk) 05:45, 21 October 2014 (UTC)

Preaching→converted. I was merely thinking out loud (or whatever is typing equivalent thereof.) Neville—love it. (I had always thought he was more of a Gordon…) AuFCL (talk) 06:02, 21 October 2014 (UTC)

IDs — a nomenclature

It seems that there is an inclination to create ids for spans, etc. that allow for manipulation and metadata. As you have been doing such ids for a while, I am wondering whether you have a nomenclature, and one that we can document. If things are trending that way, I am thinking that we should be considering how we step into how we may identify things like external links (in templates). Your guidance appreciated to nomenclature would help in undertaking this. I can see that there is possibilities for letting users colour their links, hide their links (or we can for "print" versions), and other components of annotations, etc. — billinghurst sDrewth 09:09, 26 October 2014 (UTC)

Well the first thing I refer to when facing what an id designation "should be" is to make sure one doesn't already exist in Special:AllMessages first (a pain in the ass thanx to its ever increasing length). All this recent jazz with readable metadata for image/license templates are all defined there already. All we needed to do (if we had followed what was pre-defined for us) was to wrap the link/URL/etc. with the corresponding span w/id= ....

See MediaWiki:Wm-license-cc-by-sa-3.0-text for what should have been part of the text found in our {{CC-BY-SA-3.0}} for example.

It would have been a snap to wrap the int: calls in such templates with the appropriate licensetpl spans if you follow me there. The Book and Information templates are good example of pulling defined labels/ids/names/classes/etc. from System Messages. Plus utilizing System Messages makes for smoother exporting & junk to other domains/languages if need be.

If no specific system message exists, I will still generally try to follow their lead by mimicking the syntax used for something similar to the need at hand before I devolve into "making it up" on my own. What exactly are you thinking needs this sort of attention btw? -- George Orwell III (talk) 09:36, 26 October 2014 (UTC)

Looking at templates in Category:External link templates, (and idly wondering about Category:Internal link templates especially the lkpl series). The first inline with what I mentioned earlier; and the second to look to identify the difference between standard linking methodology, and those using templates, and part of this is to identify where the template isn't used (some diagnostics here, and thinking through to WD linkage). Basically there are now plenty of tools being developed for diagnostics and link analysis, that we may be able to set up smarter. — billinghurst sDrewth 13:45, 26 October 2014 (UTC)

Well in that case, you'd look to associate a class rather than an id when it comes to linkage regardless of an internal or external target - but these are already "done" for us for the most part by wikimarkup of the <A HREF=..... tag (ex. class=external text, class=extiw). The class does not necessarily need to be "defined" in a css or anything; its a way to avoid the possibility of two url tag being assigned the same id (which, of course, would screw up any anchored links using that same id if they happen to be on the same page). Assigning ids - span tags or otherwise - is really more for single (or specific parameters (or labels) & their respective value(s) within a template than for a template itself - that's where DIV wrappers or containers take over.

So I'm still not sure what you'd like to accomplish there exactly - tracking template usage overall or analyze parameter value [re]occurrences maybe? -- George Orwell III (talk) 14:18, 26 October 2014 (UTC)

Problems with the Fs90 templates.

Hi. Please take a look at the BOTTOM OF THIS PAGE. The templates enclose a paragraph which is NOT line wrapped. This causes a line break after the first line, and a break before the last line. Could this be corrected? Thanks in advance, — Ineuw talk 00:59, 28 October 2014 (UTC)

@Ineuw: corrected? Unless you also remove the CR (carriage returns), the [auto] line return (or line wrap) will always still be there regardless of preview or save (see the edit diff). You probably definitely miss a good of number of those "carriage return" instances because your editing window happens to work out to be the same width more often than not I'm guessing. -- George Orwell III (talk) 01:12, 28 October 2014 (UTC)

Hmmm... On second thought, I think you knew that based on re-reading the not in your NOT line wrapped again. In that case, just move the start & end templates so they reside on their own lines...

{{fs90|
"Leaving out of his 'Exposition' those pre-established general
doctrines which are the common property of modern thinkers, these
are the general doctrines which remain—these are the doctrines
which fundamentally distinguish his system. From every one of them
I dissent. To each proposition I oppose either a widely different
proposition or a direct negation; and I not only do it now, but
have done it from the time when I became acquainted with his
writings. This rejection of his cardinal principles should, I
think, alone suffice; but there are sundry other views of his, some
of them largely characterizing his system, which I equally reject"}}

.... equals.

"Leaving out of his 'Exposition' those pre-established general doctrines which are the common property of modern thinkers, are the general doctrines which remain—these are the doctrines which fundamentally distinguish his system. From every one of them I dissent. To each proposition I oppose either a widely different proposition or a direct negation; and I not only do it now, but have done it from the time when I became acquainted with his writings. This rejection of his cardinal principles should, I think, alone suffice; but there are sundry other views of his, some of them largely characterizing his system, which I equally reject"

You are right, the unwrapped line was the exact width of my window ~5430px, or 68 characters with fixed font. With the inline addition of the templates it broke the line. I can make the line shorter that is not the problem. The reason I place the templates on the same line is because if the bottom template is on it's own line, the gap between the 90% and regular paragraphs is greater on the bottom than on the top. - In Hungarian it's known as uneven.— Ineuw talk 01:36, 28 October 2014 (UTC).

A true Hungarian wouldn't use the start & end template approach for a single paragraph that's not being broken up across a Page: or Page:s in the first place. And the last time I checked, all P's (paragraphs) wind-up rendering with 0.5em top and> bottom .css margin values now instead of the previous margin-top:0.4em; margin-bottom:0.5em; settings so I don't think you need to do that over-compensation thing anymore either. Skin differences are now the most glaring problem afaict. -- George Orwell III (talk) 03:52, 28 October 2014 (UTC)

The reason I use this template is because, I want to limit the number of templates (one template to fit all) - especially for new editors of PSM. It's as simple as that, even non-Hungarians can understand the logic. I wrapped your sample with {{fs90| and look at it now. Is it because of my carriage returns?— Ineuw talk 04:13, 28 October 2014 (UTC)

When working under wiki-markup, the answer is yes. Why?... because wiki-markup will ALWAYS try to insert a opening paragraph tag upon the first new line it thinks it's detected. Since the {{Fs90| template(s) use DIVs, the "first line" is skipped from this "auto-detection-&-auto-P" insertion thing; thus the "second line" gets the opening P tag -- only then will wikimark-up begin to start "combining" un-wrapped lines to render as if they where "unbroken" until the last line.

So, again, by putting the Template on its own line (see above edit to your last), the auto detection/insertion thingy also sees the opening DIV but now the "first" line is no longer "seen" as a fragment -- that point is now where wiki-markup "believes" a Paragraph starts and begins to combine all the lines to render as [one] paragraph. Note that this only "appears" to be a .css compliant P[aragraph] - it still uses DIVS to achieve this, again, whenever operating under the wiki-mark-up.

The only alternative would be to combine all the line fragments into proper sentences making up a paragraph without any carriage &/or line returns and then apply the Fs90 template the way you had it (at the very left start of the first fragment or line).

{{Fs90|"Leaving out of his 'Exposition' those pre-established general doctrines which are the common property of modern thinkers, are the general doctrines which remain—these are the doctrines which fundamentally distinguish his system. From every one of them I dissent. To each proposition I oppose either a widely different proposition or a direct negation; and I not only do it now, but have done it from the time when I became acquainted with his writings. This rejection of his cardinal principles should, I think, alone suffice; but there are sundry other views of his, some of them largely characterizing his system, which I equally reject"}}

Equals...

"Leaving out of his 'Exposition' those pre-established general doctrines which are the common property of modern thinkers, are the general doctrines which remain—these are the doctrines which fundamentally distinguish his system. From every one of them I dissent. To each proposition I oppose either a widely different proposition or a direct negation; and I not only do it now, but have done it from the time when I became acquainted with his writings. This rejection of his cardinal principles should, I think, alone suffice; but there are sundry other views of his, some of them largely characterizing his system, which I equally reject"

In a nutshell, either the .css standard or wiki-markup will undermine you one way or another when it comes to paragraphs in general. They only way to insure a paragraph is treated, rendered and saved as a "real" paragraph as defined under the standard when operating under the wiki-markup is to apply opening and closing paragraph tags whenever possible. The Fs templates should have been P &/or Span tag based instead of strictly DIV based. The fs-start and end variants are the only ones who properly apply the DIV approach.

Better? -- George Orwell III (talk) 04:42, 28 October 2014 (UTC)

As usual, the best explanation from the best explainer on the planet. Even on the planet of Hungarians. Based on what you wrote, I will explore my options further, and then give up. — Ineuw talk 15:48, 28 October 2014 (UTC)

About time

I am desperately trying not to swear here. (breath) well done. I am beginning to think you are the only being in power around this place with more than two brain-cells looking lonely and forlorn together. In case you haven't already guessed: Module:Citation/CS1/Configuration. AuFCL (talk) 21:47, 7 November 2014 (UTC)

... <shrug> I can't be on top of every little thing all the time, every single time -- but that particular gripe should have been brought to my attention (if not the community's) a long time ago instead of simmering in somebody's head all this time. It took longer to figure out WTF the issue was than actually fixing it did to boot. People are strange if not redundant. -- George Orwell III (talk) 22:01, 7 November 2014 (UTC)

I owe you a very real apology. You caught the tail-end of a week in which it seems every single human interaction I have had has ended with my shaking my head in despair. If you meet three morons in a row you may dismiss it as being a normal day; five makes me wonder what is wrong with me for apparently being so harsh.

Anyway, you did not deserve the "looking at you" prefix to the heads-up, and it was never seriously aimed at yourself. I am simply horrified at the complete lack of mental acuity/responsibility displayed by those I did notify; the hoops they were prepared to jump through to avoid facing what was in fact a relatively simple issue, and if I hear "that is the Wiki way" again as an excuse for indolence I shall become violent. No wonder nobody bothers reporting issues around here. Why waste your time?

In any case, the point of the original post was to genuinely thank you for doing the right thing (yet again!) without resorting to the dubious "look at that guy in the field of mental defectives: he looks out of place" because you might quite rightly think I was criticising you and not your laughably classified "competition."

I am right on the knife-edge of giving up on "the wikis" altogether; or perversely applying for sysop status on the basis a damaged mollusc could do as well as average current incumbent… May their ears burn. AuFCL (talk) 01:01, 8 November 2014 (UTC)

Not sure I have all the facts (you where the 2nd anonymous IP I take it?) but I'll accept the apology based on our history & stuff.

Fwiw... I've come to learn you should keep your expectations in check on such an all-volunteer system as Wiki____, maybe you should too? Or look to take on the admin bit at some point and try to improve upon this fabulous disaster from within rather than loathing it from the "outside" (I did). -- George Orwell III (talk) 20:56, 8 November 2014 (UTC)

@AuFCL: - Hope "powers that be" doesn't mean "me". I have no issue with you whatsoever except I'd hate to see you go for -as far as I can tell- no real reason. -- George Orwell III (talk) 06:22, 14 November 2014 (UTC)

NO!With the possible exception of the immediate remark I have never considered any comment of yours silly or offensive. On the contrary I have always valued your advice, lessons and (numerous) corrections and hope in turn some of my own suggestions have found to be of at least a little value.

From my own jaded perspective the "PTB" referred to above are painfully obvious and I am somewhat relieved they do not appear to be quite so starkly obvious from another perspective. Strangely I find this last reassuring now that I have chosen to move on before the canker erupts; as I truly believe their eventual fall from grace will be long and painful and I would not like to be seen to be the catalyst.

(Got bells on myself, haven't I? Well I believe there are degrees of truth in all this anyway.) Please continue fighting the good fight. Bye. AuFCL (talk) 21:17, 15 November 2014 (UTC)

Again, I only saw what I was I directly involved in and did not look any further into anything else but I'll accept your observation(s) as sound nevertheless. Still, this is the interwebs and its not always easy to apply real world judgments against virtual world apparitions so I'd advise taking some time off and see how you feel then.

In addition, I don't do so well with those still "under the realm of the Queen" at times and this place is crawling with them so you must not go by my assessments either I suppose.

Adios my friend & I will adopt span tag (show off) some point in the future as if it were my own. -- George Orwell III (talk) 22:53, 15 November 2014 (UTC)

Hello. One-time inmate just visiting the asylum (I hope just passing through.)

Thanks for the good wishes and I could not ask for better hands into which to place span tag. I always considered it to have been of your inspiration in any case. (Feel free to disbelieve; the "showing off" was not entirely intentional; but of course glad it had a positive impact.) AuFCL (talk) 13:43, 6 December 2014 (UTC)

Might be of some interest - think I've found a way (or ways) to defeat wiki mark-up handling of the paragraph tag - see my common.css file. -- George Orwell III (talk)

Defaults in FIS template

Greetings. I looked at the template code, and I could learn that the image defaults to center automatically (auto margins). Can I assume this parameter can be omitted from the template when used for a page centered image? If you have the chance, can you tell me what other defaults exist in the template? I would be much obliged.— Ineuw talk 02:28, 16 November 2014 (UTC)

I thought AuFCL broke all that info out in Template:FreedImg/span#Parameters a couple of months ago, No?

And -- as far as I can tell/recall -- nothing has changed template-code wise since then so the documentation is pretty much up to date (the only thing not documented is the experimental image rotation related stuff cause its still not ready for prime time yet; that shouldn't affect you & should not be applied even it somehow does). Anything still unclear; just ask. -- George Orwell III (talk) 02:43, 16 November 2014 (UTC)

Many thanks, I haven't seen this. (May hat's off to to you both.)— Ineuw talk 02:48, 16 November 2014 (UTC)

A proofreading mystery

@George Orwell III: & @AuFCL: I always wrapped the proofread text lines, which renders nicely, but wrapped lines have a shortcoming. I use the over/under editing view for the main reason that I can follow the matching text as the scanned lines are the same as the original above. Using this as a coordinate of row and approximate column position, helps me locate the original or vice versa when a correction is required. With line wrap this advantage is obviously lost and it's the main reason I shy away from validating.

I use an external text editor with a macro capability to correct global scan errors and wrap the text. Global scan errors are spaces at the start of the paragraph, spaces before colons, semicolons, question and exclamation marks, hyphens and mdashes surrounded by spaces (left, right or both) etc., except hyphenated words at the end of a text line which I deal with separately.

Now I wrote another set of macros which do all of the above corrections and joins the hyphenated end of line words, but breaks the line immediately after the joined word. This way, I am retaining the original row length everywhere except the two modified rows. Hoping thereby to make the text seem wrapped as it looked before proofreading, But SEE THIS PAGE, how the text looks without wrapping, and then the following page which is wrapped. Could this be the new line code used in the text editor. I looked at the document in binary mode but can't tell. Perhaps there is a solution to having the proverbial cake and eat it? — Ineuw talk 05:29, 16 November 2014 (UTC)

I'm not sure what exactly I'm suppose to "see" difference-wise between /141 & /142 (screen grab?). I understand the nuance that one page is pretty much what the OCR generated and was first saved upon page creation and the latter page has been entirely [re]formatted -- plus what you're doing macro wise -- but the question comes down to why I guess?

First off, you're working against/in-tandem with the wiki mark-up regardless. So the instant an asterisk, number-sign or semi-colon happens to be the last standalone character of an OCR'd line, more often than not that character will be "moved" to the front of the next line -- causing erroneous formatting when saved (locate 'Edinburgh : Oliver' for example and see how wiki mark-up won't let you win even with your macro to back you up). Its the same story with trailing [white]spaces at the end of a line & the wiki mark-up.

I could go on but will wait until you catch up or grab some pics of what the "difference" that I'm not seeing is. -- George Orwell III (talk) 06:10, 16 November 2014 (UTC)

I uploaded two images of what I see. Should have been titled "Broken rows" and File:Lines wrapped.jpg. I loaded the pages in 3 other browsers I installed for testing. In Opera that paragraph is not broken, In the other browsers Firefox, Chrome and IE 11 they look the same, My question is why must I wrap the lines when single row spacing appears wrapped (before proofreading).— Ineuw talk 08:03, 16 November 2014 (UTC)

Check again; I just tweaked it. It was mainly your PSMLitReview template suffering from what we talked about the other day - your opening and closing DIV tags must reside on their own lines otherwise your {{{1}}} will have its first line detected as an opening to a SPAN (expected) but the 2nd line will be detected and auto converted to a start as a P tag. Upon save, the opening SPAN tag will get closed since you can't have a block-element (P) nested within an inline element (SPAN) ---> that's why the 2nd (sometimes the last) line(s) become have CR/LR (breaks): ITs WIKI MARK-UP

The second example on that page had a line that started with a " : " --> causing automatic wiki mark-up conversion to DL/DD/DT (defined list, defined term etc.) upon save -- better known as a simple indent -- but same old can't start out as an inline element hosting a block element cause wiki-mark-up will get ya (on top of being non-HTML spec compliant). -- George Orwell III (talk) 08:21, 16 November 2014 (UTC)

This is what I wrote before your reply: ... and now they seem OK on all browsers. All I did was is modified the template temporarily and then returned the original code. After clearing the cache it's OK. It's driving me batty. I read your reply and understand. This means that I should check all the templates I created and move the divs, since they are probably all like that. — Ineuw talk 08:26, 16 November 2014 (UTC)

Okie-dokie but remember!! Sometimes "we" want to "fake out" the wiki mark-up by nesting {{{1}}} right after the opening DIV around here in certain cases for certain templates (a long time bad practice if you ask me but I also accept its too late to get that genie back in the bottle at the same time). -- George Orwell III (talk) 08:37, 16 November 2014 (UTC)

Many thanks,. . . . again. I owe you gulyás, and lecsó.— Ineuw talk 08:49, 16 November 2014 (UTC)

paprikas krumplee(?) - leves - teiful-ish kenyer - is enough for me; I keep things simple. Look for an email one of these days if I ever get around to it - I do need some unrelated Magyar-ish guidance, etc. -- George Orwell III (talk) 09:00, 16 November 2014 (UTC)

Your wish is my command. It's spelled paprikás krumpli - leves - tejfel és kenyér . . . .you can have it all. Actually what I call gulyás, is your paprikás krumpli. Lecsó is a very simple dish, just ask around. a Gerbaud dessert perhaps?— Ineuw talk 09:19, 16 November 2014 (UTC)

Hello

George Orwell III aka GO3, this is just a short "hello" because I have not communicated with you for a long time. I do hope that all is well with you and your loved ones. Kindest regards, —Maury (talk) 02:31, 18 November 2014 (UTC)

Citation question

GO3, would you mind taking a look at the history on this page. "The Path of the Law" WS page used to be linked to, but now the entry points you to a Gutenberg text. Uniformity of text entries was also affected as a result. My opinion is to revert it back to your edit, but I'll leave it in your hands, if you don't mind... Thanks, Londonjackbooks (talk) 02:06, 19 November 2014 (UTC)

It was not a helpful edit at all (Prog Guttenberg had nothing to do with your transcription for example) so I restored it to basically what you had before. If anything, it would start to make sense to have a master template covering the Harvard Law Review's output over the decades at some point. -- George Orwell III (talk) 03:23, 19 November 2014 (UTC)

Thanks for the adjustments. Londonjackbooks (talk) 04:55, 19 November 2014 (UTC)

An example of proofreading without line wrapping

[2] — Ineuw talk 22:26, 21 November 2014 (UTC)

Part of the caption is missing with the use of FIS

Szervusz, The long caption on this page is truncated by the template. Could you, would you, be so kind as to look at it and tell me what I am doing wrong? — Ineuw talk 01:07, 10 December 2014 (UTC)

So shoot me now. Template ended without introduction. This is what I think you meant? 121.217.126.120 07:37, 10 December 2014 (UTC)

Shooting you is not an option. My apologies for completely missing the template's closing brackets. Couldn't figure out what was happening.— Ineuw talk 07:59, 10 December 2014 (UTC)

On second thoughts, inviting a Canuck to shoot oneself might not be a very smart career move. I unconditionally withdraw the aforementioned offer. AuFCL (talk) 09:24, 10 December 2014 (UTC)

Edit conflict

I did not understand at first that you were doing parallel editing at this work, sorry for any inconvenience. Hrishikes (talk) 06:35, 13 December 2014 (UTC)

My bad for butting in to begin with; I was working my way towards a similar work around for Dent fwiw... -- George Orwell III (talk) 07:38, 13 December 2014 (UTC)

Harper's Magazine

George, I have tried but have not been able to fix this area https://en.wikisource.org/wiki/Harper%27s. It is the 1st article. Please jump in with a smile and fix the danged thing. The article has Robert Edward Lee's name as "Edmund" which is correct since Harper's also goofed up and gave him the middle name of Edmund. Happy Trails in the NJ snow. —Maury (talk) 06:45, 13 December 2014 (UTC)

Is that what you wanted, Maury? -- George Orwell III (talk) 07:47, 13 December 2014 (UTC)

Yes, thank you. Happy Holidays to you and your family. —Maury (talk) 21:53, 13 December 2014 (UTC)

Caption block in FI/(possibly)FIS

Gidday.

I'd like your thoughts upon this before I make a complete fool of myself. As you are no doubt aware the allowable caption content with these templates can be pretty complicated and yet still most cases cope extremely well. However, width inheritance does not always appear to be effective, at least on some browsers.

As current, the caption block beneath a FreedImg is composed of a display:block (by default, overrideable by parameter tdisplay) styled <p> further enclosing a fixed display:inline-block styled <span> in turn enclosing the user's choice of caption content.

On Firefox (at least) this hierarchy loses inheritance of any width: styling of the outermost <div> unless explicit width:inherit stylings are supplied at both intermediate levels (i.e the caption's <p> and <span> containers.)

Hope that dissertation has not completely lost you. In short what I propose is replacing fragment:

-->{{#if:{{{caption|}}}|
<p class="imgCaption" style="display:{{{tdisplay|block}}}; text-align:{{{talign|center}}}; {{#if:{{{tstyle|}}}|{{{tstyle}}};}}"><span style="display:inline-block; margin-right:{{{tmright|0.00em}}}; margin-left:{{{tmleft|0.00em}}}; text-indent:{{{indent|0.00em}}};">{{{caption}}}</span></p>
}}

with:

-->{{#if:{{{caption|}}}|
<p class="imgCaption" style="display:{{{tdisplay|block}}}; text-align:{{{talign|center}}}; {{#if:{{{tstyle|}}}|{{{tstyle}}};}}; width: inherit;"><span style="display:inline-block; margin-right:{{{tmright|0.00em}}}; margin-left:{{{tmleft|0.00em}}}; text-indent:{{{indent|0.00em}}}; width: inherit;">{{{caption}}}</span></p>
}}

I believe this change should be benign with regards current usage, but would appreciate your thoughts (in particular have you tried/rejected something like this kind of change before)?

Finally what is my driver for exploring this area? Well not having to commit the following travesty might be a good starter:

Mars.
NORTH POLAR CAP.⁠SOUTH POLAR CAP.
At maximum
At minimumfull extent of white
inner circleAt maximum
At minimumwhite
nothing

Whereas a "clean" version currently does not work under Firefox ("white"/"At maximum" overlap final "e" with initial "A"; overall caption width only approx. 80% of available width):

Mars.
NORTH POLAR CAP.⁠SOUTH POLAR CAP.
At maximum
At minimumfull extent of white
inner circleAt maximum
At minimumwhite
nothing

Regards, AuFCL (talk) 05:48, 15 December 2014 (UTC)

Up to my elbows w/ something else right now so take this as just a first glance - seems like the span should be inline by default rather than inline-block -- or at least variable/inverse to whatever the paragraph is set to display: wise -- but if your testing proves width:inherit works just as well or better than go for it. I'd rather it not be fixed attribute though. -- George Orwell III (talk) 06:24, 15 December 2014 (UTC)

Thanks for your advice—you have already suggested a line of attack I omitted to try earlier. I shall try not to distract you further. AuFCL (talk) 08:08, 15 December 2014 (UTC)

Re: Friendly Advice

Whilst I very much doubt what you had in mind when writing Special:Diff/5175715/5175726 whilst researching the Poetlister affair so that I did not have to ask the obvious question, I incidentally stumbled across so much accumulated bad karma for the two strine 'Drew's (both south and west) that I can clearly see I am wasting my time in butting up against such thick skins. I ought to have known better especially since I was already aware of the ex-govt. part.

So—satisfied? Never! Resigned? Yeah, O.K.

May your next fight be successful (and all the ones after that similarly likewise.)

AuFCL (talk) 21:49, 26 December 2014 (UTC)

LUA in {{header}}

Obviously I am not the diplomat to break this, so in case they are of any use some experimentation here: User:AuFCL/SandBox. How to crack a walnut using the LHC? Talk about over-complicated. AuFCL (talk) 02:02, 28 December 2014 (UTC)

About FreedImg again

I'm going on using our it.source version of FI (great idea!) and I'd like to share two ideas:

1. an additional parameter thumbs (thumb size) that is converted into the plain picture width in pixel of basic image markup; this avoids to upload a full-size image when it is not needed;
2. a fourth option into float parameter, "floating-center". This means that the picture will be shown as centered, but the text floats dinamically around the picture (really, it is simply a float=left image, but left and right margin are calculated so that the resulting width is 100% of the parent block). A recent version uses the calc() css3 option, and margins width is calculated as margin-left:calc((100% - {{{width}}})/2). Css3 is perfectly supported by mediawiki, and is supprted too by some ePub readers, as Readium.

See it:Template:FreedImg and it:Pagina:I promessi sposi (1840).djvu/19 for a living example of float=floating-center option if you like. --Alex brollo (talk) 14:22, 29 December 2014 (UTC)

That sounds like 'Constrained' Image rather than 'Freed'. They both sound like worthwhile to have but I don't think they fall under the FI premise anymore. Personally, I think those should be mad possible in some other template -- even if at the heart its just a copy of the current FI & FIS templates. -- George Orwell III (talk) 20:32, 29 December 2014 (UTC)

Please excuse me putting my oar in.

Alex's example is constrained, but the concept appears sound: I think his floating-center idea should be noted for its cleverness if nothing else. (I do rather suspect he has discovered a degree of automation of {{FIS}} Example 4?)

When width is expressed as a "%" value the image does correctly resize in a dynamic fashion.

"thumbs" on the other hand I comprehensively do not understand. Is there supposed to be any support for this within it:template:FreedImg, because I am unable to spot it if it is in there? AuFCL (talk) 22:15, 29 December 2014 (UTC)

Maybe its just me but I don't see any text floating around any picture -- the text stops above the pic and starts again after the pic (e.g. there is no text dynamically floating on either side of the pic). I don't see anything "new" here if what I'm seeing is the case.

Next calc() isn't really finalized as part of CSS3 (see Status of this document).

The way its applied here makes more sense but that approach goes towards manipulating the overall container compared to its host parent instead of the image compared to its host container (at least that's how it reads for me that is). -- George Orwell III (talk) 22:55, 29 December 2014 (UTC)

Thanks for comments.

About thumbs: dealing with a low size image as File:Iceberg.jpg, a thumbs parameter is unuseful to save band and/or uploading time and/or ePub size. Replace the example image with this one: File:Iceberg at Elephant Island.jpg (a 1.34 Mby jpg) and I guess that things will change. FI uploads a full size image into the browser, then it resizes it; but the full sized image is living into the background and it will be exported into ePub (if I'm not going wrong).

Is this really a problem? -- George Orwell III (talk) 23:58, 29 December 2014 (UTC)

About "floating-center": a centered image breaks the text if posted inside a paragraph; some text have very long paragraphs, and we found very disturbing to break them. Please note the "floating text effect" into it:Pagina:I promessi sposi (1840).djvu/19. The FI template has been posted just after "... pubblica un bando contro di essi." and is followed by "Dichiara e diffinisce tutti..."; but the following text "floats" before the image avoiding a broken line of text.

There is no such thing as "float[ing]: center". You either center something or not; relative positioning or otherwise. Isn't this your FIS coming back to haunt us by doing the exact same thing already? -- George Orwell III (talk) 23:58, 29 December 2014 (UTC)

About percent sizing: we found disturbing that the image dynamically resizes when the container div resizes. What is disturbing is that the original ratio font size/image size is lost; on the contrary, using an absolute sizing of image, or an "elastic" but font-size related sizing, this ratio is saved. Again, this is particularly obvious in ePub rendering. It.source doesn't use so far your marvellous dynamic layout, but I presume that difference between image fixed/percent sizing should be obvious using it.

??? Only the image caption text should be affected if anything at all. I'm not sure what you mean here. -- George Orwell III (talk) 23:58, 29 December 2014 (UTC)

About {{FIS}}: simply, I'll study it, since it's new for me :-( --Alex brollo (talk) 23:45, 29 December 2014 (UTC)

Oooopppppss.... yes, I already know FIS. ;-) --Alex brollo (talk) 23:48, 29 December 2014 (UTC)

examples

Fino dall’otto aprile dell’anno 1583, l’Illustrissimo ed Eccellentissimo signor Filippo II di Spagna don Carlo d’Aragon, Principe di Castelvetrano, Duca di Terranuova, Marchese d’Avola, Conte di Burgeto, grande Ammiraglio, e gran Contestabile di Sicilia, Governatore di Milano e Capitan Generale di Sua Maestà Cattolica in Italia, pienamente informato della intollerabile miseria in che è vivuta e vive questa Città di Milano, per cagione dei bravi e vagabondi, pubblica un bando contro di essi. Dichiara e diffinisce tutti coloro essere compresi in questo bando, e doversi ritenere bravi e vagabondi... i quali, essendo forestieri o del paese, non hanno esercizio alcuno, od avendolo, non lo fanno... ma, senza salario, o pur con esso, s’appoggiano a qualche cavaliere o gentiluomo, officiale o mercante... per fargli spalle e favore, o veramente, come si

---

Is this perhaps what you were looking for?

Fino dall’otto aprile dell’anno 1583, l’Illustrissimo ed Eccellentissimo signor Filippo II di Spagna don Carlo d’Aragon, Principe di Castelvetrano, Duca di Terranuova, Marchese d’Avola, Conte di Burgeto, grande Ammiraglio, e gran Contestabile di Sicilia, Governatore di Milano e Capitan Generale di Sua Maestà Cattolica in Italia, pienamente informato della intollerabile miseria in che è vivuta e vive questa Città di Milano, per cagione dei bravi e vagabondi, pubblica un bando contro di essi. Dichiara e diffinisce tutti coloro essere compresi in questo bando, e doversi ritenere bravi e vagabondi... i quali, essendo forestieri o del paese, non hanno esercizio alcuno, od avendolo, non lo fanno... ma, senza salario, o pur con esso, s’appoggiano a qualche cavaliere o gentiluomo, officiale o mercante... per fargli spalle e favore, o veramente, come si

Regards, AuFCL (talk) 03:59, 30 December 2014 (UTC)

Don't thinks so. I get 3 columns -- as you styled in the DIV container -- but the original print itself is merely justified text; nothing floating around the image to the left nor the right; so I'm still not sure what we're trying to accomplish here. -- George Orwell III (talk) 04:31, 30 December 2014 (UTC)

Oh well (browser limitations? transform() all over again?) it was merely a thought. On firefox the image (roughly) occupies the middle of the three columns and the text wraps down the left hand side and continues flowing again on the right. If this description does not suffice do you want a screen dump (bearing in mind the idea is a fizzer anyway)? AuFCL (talk) 04:44, 30 December 2014 (UTC)

Yeah that happens when I shrink my browser window width to something smaller than the width of the 3rd column alright -- and the image becomes itty-bitty at the same time too; not what the original publication reflects either. Please. Let's stop the madness.

Show me an example that can't render as faithful as possible to the original print using the current FI or FIS templates rather than trying to sell code additions or re-writes to solve issues nobody has actually encountered never mind reported. -- George Orwell III (talk) 04:51, 30 December 2014 (UTC)

(Especially final point) Good argument. Cogently expressed. I concur. (I still don't like that LUA bad joke code embedded in header but that is a fight for another time.) AuFCL (talk) 05:13, 30 December 2014 (UTC)

I also should beg pardon for misunderstanding earlier. I was not trying to reproduce the page with the three-column effort; I was merely stealing your example to illustrate what I had thought you were expecting Alex's floating-center idea to support (much earlier.) So a case of a double redirect misconception at the very least. AuFCL (talk) 06:11, 30 December 2014 (UTC)

example 2

I apologyze for my forgetfullness and for wasting your time. Just now I realized that {{FIS}} is simply a previous version of it:Template:FreedImg with a different name. Another issue has been the bad idea to call "floating-center" what was merely the previous FIS option "not-breaking-center". Both new bits of code I mentioned can be obtained into a tricky way with FIS, new parameter setting simplifying things for the user.

Here an example of both "enhancements" of FIS got with its original code:

Because the density of pure ice is about 920 kg/m³, and that of seawater about 1025 kg/m³, typically only one-tenth of the volume of an iceberg is above water. The shape of the underwater portion can be difficult to judge by looking at the portion above the surface. This has led to the expression "tip of the iceberg", for a problem or difficulty that is only a small manifestation of a larger problem.

Icebergs generally range A 400px "thumb" of original 1.34 Mby image is uploaded only into the browser, from the {{!}}400px code into file= parameter. A "not-breaking-center" effect is got by calculated margin-right and margin-left, so that both image size and centered effect are saved when you resize the container div (please try); using percent sizing, image size will as the containder div is resized.from 1 to 75 metres (3.3 to 246.1 ft) above sea level and weigh 100,000 to 200,000 metric tons (110,000 to 220,000 short tons). The largest known iceberg in the North Atlantic was 168 metres (551 ft) above sea level, reported by the USCG icebreaker East Wind in 1958, making it the height of a 55-story building. These icebergs originate from the glaciers of western Greenland and may have an interior temperature of −15 to −20 °C (5 to −4 °F).[4]

Icebergs are usually confined by winds and currents to move close to the coast. The largest icebergs recorded have been calved, or broken off, from the Ross Ice Shelf of Antarctica. Iceberg B-15, photographed by satellite in 2000, measured 295 by 37 kilometres (183 by 23 mi), with a surface area of 11,000 square kilometres (4,200 sq mi). The largest iceberg on record was an Antarctic tabular iceberg of over 31,000 square kilometres (12,000 sq mi) [335 by 97 kilometres (208 by 60 mi)] sighted 150 miles (240 km) west of Scott Island, in the South Pacific Ocean, by the USS Glacier on November 12, 1956. This iceberg was larger than Belgium.[5]

When a piece of iceberg ice melts, it makes a fizzing sound called "Bergie Seltzer". This sound is made when the water-ice interface reaches compressed air bubbles trapped in the ice. As this happens, each bubble bursts, making a 'popping' sound.

New thumbs parameter avoids that tricky {{!}}400px code, and float=floating-center avoids code into margin-left and margin-right parameters; they can be simply avoided at all. --Alex brollo (talk) 07:40, 30 December 2014 (UTC)

For the last time - WE (THE ENGLISH WIKISOURCE) have at least 4 dynamic layouts in the main namespace for works transcluding a range or ranges of Page:s from the Page: namespace. Therefore, creating DIV containers at 40em or setting FI widths to 400px DEFEATS the entire purpose of making DYNAMIC IMAGE RESIZING work under DYNAMIC LAYOUTS.

After a Page: in the Page: namespace is validated, the chances or need for anyone to revisit that particular Page: in the Page: namespace becomes more and more unlikely to occur; that's why we really only care about resizing images in the main namespace. it.WS doesn't seem to use Dynamic Layouts; if true, why are you even bothering to resize an image when you are locked into a fixed width of 400px in the main namespace again. -- George Orwell III (talk) 08:00, 30 December 2014 (UTC)

User:Alex brollo, Use the Index:/Page:s used in the Temp Image Testing page to illustrate your idea instead of my talk page; then we'll see if its practical or not for en.WS if not the entire Wikisource project. -- George Orwell III (talk) 08:15, 30 December 2014 (UTC)

Ok. My only aim was to let you personally (as FreedImg author) know of FreedImg use into it.source. Feel free to dismiss the whole thing; by now, I'll simply add alternative templates code into a template subpage with no disturbing contribution into user talk pages. I apologyze again for wasting your time. --Alex brollo (talk) 08:31, 30 December 2014 (UTC)

User:Alex brollo, Its not a waste of time - its just not clear to me what we're trying to do exactly. Please see Temp Image Testing page to see your above example transcluded from the Page: namespace and we'll go from there after you review it. -- George Orwell III (talk) 08:35, 30 December 2014 (UTC)

Ok, I posted into {{FreedImg/span/sandbox}} it.source code, used here: Page:4test01.djvu/6, while equivalent but harder code is used with {{FIS}} into the next page. In transclusion, both not-breacking-text centering and image absolute size are saved in different layouts; this was our aim, but obviously it's a matter of preference, if you prefer to save the image/container div size ratio the trick is unuseful and disturbing, while percent sizing of both image and margins does its job. Happy 2015! I go back at home.--Alex brollo (talk) 10:22, 30 December 2014 (UTC)

Delete request

Hi, GO3... I have a list of 10 delete requests in my sandbox. I thought it might be easier than tagging all titles with speedy delete. If you think it would be better practice to tag them, let me know and I will do so. Thanks, Londonjackbooks (talk) 23:38, 29 December 2014 (UTC)

Please tag them and I'll get to it if nobody else does eventually. -- George Orwell III (talk) 23:52, 29 December 2014 (UTC)

OK. Londonjackbooks (talk) 23:54, 29 December 2014 (UTC)

May I have a little heeder 101 please?

Hello. In trying to come to grips with your suggestions regarding {{heeder}} I am having some degree of initial culture shock. No imperative on answers, and if you should happen to know of an existing backgrounder link I'd be grateful and will go away and play catch-up. Right at present some (likely irrelevant?) curiosities jump out at me:

• Use of flags like "!important" within styles unfamiliar. I presume they do nothing but are not actually error-prone?
• <table…style="display:table;">…legal but surprising. Why necessary? Indeed why all the embedded <table>s at all?
• Finally the concept: what is the basic driver for converting from tables to divs at all? I (naïvely) thought the only criteria for carriage of metadata was an arbitrary container capable of carrying a "class" designator; so span/div/table-cell all eligible. Obviously there is more to this cake than mere ingredients+cooking?

As ever, pardon the dumber questions; the merely dumb ones come integrally with the fact it is me you are dealing with. AuFCL (talk) 09:10, 31 December 2014 (UTC)

• The use of !important inline is me being lazy when it comes down to it. I'm trying to avoid upsetting the status quo re: the existing class=headertemplate "definitions" and found it easier than making 3,000 edits to an actual .css file. Applying it in this manner is hit or miss of course but it does manage to override some wiki index.php/load.php initiated crap.
• The application of display:table coupled with additional setting also seems to prevent the unwanted inheritance from "parent" elements defined in some css or another before final rendering locally. Don't ask - just be anal about having it present for any html table tag for now.
• In a nutshell - Mobile view (way down the bottom of every page where the powered by & disclaimer junk resides) Just go to any mainspace page - both those transcluded in from the Page: namespace and the straight text dump type - and then enter "mobile view". The Header is the most obvious 'hurts-the-eye' issue but the truth is we need to move the header, footer, license banner, and authority control banner out of dynamic layouts and the only way to successfully do that is with json manipulation of DIVS. Tables larger than a single-row any number of row-cells can be dynamic if wrapped in a DIV too but try to make a multiple row table dynamic and the trouble begins.

/**
 * Force certain div containers to render outside of main content wrapper.
 * See ___
 */
jQuery( document ).ready( function ( $ ) {
	$( 'body.ns-0 div#headertemplate' )
			.insertBefore( $ ( 'div#mw-content-text' ) );
	$( 'body.ns-0 div#heedertemplate' )
			.insertBefore( $ ( 'div#mw-content-text' ) );
	$( 'body.ns-114 div#headertemplate' )
			.insertBefore( $ ( 'div#mw-content-text' ) );
	$( 'body.ns-114 div#heedertemplate' )
			.insertBefore( $ ( 'div#mw-content-text' ) );
} );

GO ahead and add it to your local .js. It won't help mobile view but it at least validates proof-of-concept for now. Did you notice that there is no way to link back to the Page: namespace with either a source tab or an embedded pagenum link in mobile view? Those teams realized stuff like this months ago and decided to not to bother with WS (e.g. PR extension/dynamic layouts). -- George Orwell III (talk) 09:40, 31 December 2014 (UTC)

Thanks for your patience. I did not intend to upset your dyspepsia. Most of your answers were per my guesses but I have never experimented with the "mobile" options before and have very little background to go on. My initial reaction is as you'd expect "YUCK." (I think I smell the edges of a plot to drive users away?) AuFCL (talk) 09:55, 31 December 2014 (UTC)

User:AuFCL -- Think about this way with mobile-view as the foundation.

The header should retain info (title author, illustrator, pub date, edition, publisher, editor, etc.) like it does now but it should be "separate" from the actual navigation of volumes and/or chapters of the work (automated would be even better than adding previous/next etc. for every page. Finally the value add-ons -- plain-sister links and any notes -- should also be "separate" from the other two.

Sure, they can all render together as one green-ish banner at the top of the page like it does now but underneath they should only be concerned with "doing" one thing; not three.

Take a look at Template:book or Template:information. They use the internal message, label & form systems to deal with "input" and so should the header class of templates. Otherwise, all this crap coming down the pipe in the coming year will never be 'overly concerned' with keeping WS "relevant" (as if they do now; not). -- 10:19, 31 December 2014 (UTC)

Despite your best attempts to appear curmudgeonly that was a brilliant exposition and (I shan't pretend to grasp the implications yet) contains all the pointers I shall need for now. Thanks.

Complete aside—this may be a consequence of installing your javascript patch; I haven't figured that out yet—I was able via a convoluted series of navigations to end up deposited in mobile mode upon an Index: page. And hence could not resist trying a Page: link. Now I think I know where that elusive over-and-under layout (transcription above; scan image below) which occasionally has bothered people like Zhaladshar from time to time and appears to pop up after software "upgrades" comes from. AuFCL (talk) 22:07, 31 December 2014 (UTC)

Mobile frontend

User:AuFCL,

Keeping with the above discussion re: header templates in mobile-mode -- felt it necessary to document findings before moving on.

• Mobile-mode .css structure is considerably different than "normal" desktop view. Most noteworthy difference is it's application of rules (/* @media all and (min-width:768px) */ for example). This means, depending on the particular device/browser settings the User: happens to be using to "visit" mobile-mode, multiple .css values can be set then rendered in a pseudo if... then... manner. In short -- using the previous rule example -- two values can be set for something like text-align: . One for viewable screen areas smaller than 768px and another for viewable screen areas larger than 768px.

  Check out Lodge, William (DNB00) and Executive Order 12992 in mobile-mode. Slowly shrink your browser's width until the rendering of the header template in each "dynamically" shifts at the point where you cross the 768px width.

As "cool" as this may seem, the same is not true in desktop view -- and the use of such rules are slowly creeping in there too (only @ 968px instead)

• I can't seem to have the text in the Page: namespace under mobile-mode align justified. I'm not sure local .css settings to override what comes down from the servers is possible even.

... more as I come across new stuff like this. George Orwell III (talk) 23:28, 31 December 2014 (UTC)