User talk:George Orwell III

From Wikisource
Jump to: navigation, search
George Orwell III (talk page)

(Archives index, Last archive) Note: Please use informative section titles that give some indication of the message.


Contents

MediaWiki:Common.js cleanup[edit]

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

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

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

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

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

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

Test 123

Testing[edit]

Test 123

Need help from Bengali Wikisource[edit]

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.

EDIT TOOL..

Edittool not coming ...

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

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: ".&#x2008;.&#x2008;.&#x2008;.&#x2008;.&#x2008;.&#x2008;.&#x2008;.&#x2008;.&#x2008;.&#x2008;.&#x2008;.&#x2008;.&#x2008;.&#x2008;.&#x2008;.&#x2008;.&#x2008;.&#x2008;.&#x2008;.&#x2008;"
}

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

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

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

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

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

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

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

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

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. Face-smile.svg.— Ineuw talk 02:17, 31 January 2014 (UTC)

Testimony of a convert (to the new wiki editor)[edit]

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

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

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

Hi. I made a half-donkeyed mess when created the bug report about the echo spilling over the border. Face-smile.svg. 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[edit]

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

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

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


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

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

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

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

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

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

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

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.

 

PSM V18 D236 Water turbine driven sewing machine.jpg

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?.

 

PSM V18 D236 Water turbine driven sewing machine.jpg

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...

... 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. Face-smile.svg. 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. Face-smile.svg.— 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[edit]

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

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

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

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. Face-smile.svg.
  • 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[edit]

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

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

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)

wikiEditor custom toolbar (continued here)[edit]

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. Face-smile.svg.

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

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|&#x2129;}}

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

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

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

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

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

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

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

Thank you[edit]

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

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

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/sandbox}}[edit]

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


{| width="25%" {{td/dot/sandbox|Example text}}||{{fsp}}1{{tr}} |}

Example text................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................

 1

By comparison with the existing template:

Example text
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
 1


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...

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


Example text................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................

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

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

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

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

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)