User talk:Krinkle

Talk ?
Hi, for more info or contact, please check my page at Wikimedia Commons (talk), as I'm not a regular visitor here. -- Krinkle 21:58, 19 July 2010 (UTC)

---

Discussion

Wikisource does not have all the license templates of Commons, please do not tag those images as you are doing. If they are marked "Move to Commons", it's because Commons has the proper image copyright tag, not WS. Sherurcij ^{Collaboration of the Week: Author:Thomas Carlyle.} 14:03, 15 December 2009 (UTC)

Hi, I'm not creating any new things. Atleast I wasn't planning to.

What I'm planning to do on Wikisource is work on your backlog of MTC-tagges images (those were already tagged). And to make that a little bit easier I merely added a CommonsHelper-link. That's all. The "No license"-template, was already present on Wikisource.

If Wikisource is missing those license-templates and instead displays nothing at all, then how do you suggest I know what license it's supposed to be on Commons ?

I've stopped my activities for now untill I know more. I understand now why they had no license template. But if there isn't even a textual "This image is CC-BY-SA 3.0 by Author" or "The Author (John Doe) died in 1800 and this is PD-old", if that's not there then, with all the respect, I doubt it'll be accepted at Commons.

Ref.: File:10melody.jpg, File:1864 Pay Request.jpg.

Greetings, Krinkle (talk) 14:13, 15 December 2009 (UTC)

If they are marked MoveToCommons, the user who marked them believes it will/should be obvious to someone moving them to Commons which template to use - for example the 1864 pay request is clearly fit for Commons; so it's going to slow things down if you just remove the MoveToCommons tag and replace it with a noLicense. Sherurcij ^{Collaboration of the Week: Author:Thomas Carlyle.} 14:28, 15 December 2009 (UTC)

Okay, I suppose you're right. I thought it was a coincedence, but I now see a few that do have a license described aswell (I had the impression they were all without author/source/license information). I'll see if those without are obvious and if not, leave them be and leave it up to you - and else move them to Commons straightaway

Thanks for your quick response, and may we work side-by-side :-). Krinkle (talk) 14:33, 15 December 2009 (UTC)

:PS: For any further discussion I recommend doing so here as I'm not a regular here. Krinkle (talk) 14:33, 15 December 2009 (UTC)

No problem, thanks for your help with the backlog - I've started deleting the WS files you've already transferred :) Sherurcij ^{Collaboration of the Week: Author:Thomas Carlyle.} 18:15, 15 December 2009 (UTC)

Protected edit request

MediaWiki talk:Sharedupload-desc-here = Done. Please review? -- Cirt (talk) 03:24, 15 June 2011 (UTC)

Gadgetize

Hi,

I've been using your WhatLeavesHere.js with much appreciation and was wondering if its possible to make this a User selectable gadget for all while customizing it to reflect our namespaces rather than the MediaWiki defaults in the process. Thanks for any attention in advance. -- George Orwell III (talk) 02:15, 21 January 2012 (UTC)

Hey George,

Thanks for using my gadget. That's a very good idea, which should've been in the first version.

I've implemented the Namespace-feature right away, you may have to clear your cache before it's visible.

Krinkle (talk) 02:37, 21 January 2012 (UTC)

The namespaces now reflects our own in the Special Pages: Page Tools section using the "old" way where I called your script manually in my .js - and... -- George Orwell III (talk) 03:05, 21 January 2012 (UTC)

For gadget installation on this wiki, check m:User:Krinkle/Tools/WhatLeavesHere#Install as Gadget. Krinkle (talk) 02:44, 21 January 2012 (UTC)

... will check this out next, make the change(s) to gadgetized, bang it around a bit & will touch back with more results. -- George Orwell III (talk) 03:05, 21 January 2012 (UTC)

Well everything seems to work as it did before moving it to a gadget & the namespaces selection are our own as well. Please double-check my work as I added smaxage & maxage to the line in the .js.

One thing I did notice but is not all that important - when you open the typical WhatLinksHere tool and WhatLeavesHere is enabled at the same time, you get the option(s) of What links here / What leaves here? above the target input box but you don't get a What Links Here option if you go through the WhatLeavesHere page tool. No big deal but I thought I'd mention it.

As a side note - I sure do miss your SpeedPagePatrol thingy. The Diff/Top RC substitute for it is, I'm sorry to say, of little help; maybe because it defaults to Commons' RCID & DIFF entities rather than en.Wikisource's so we've never really seen it it in full action??? -- George Orwell III (talk) 03:59, 21 January 2012 (UTC)

Regarding the link back to WhatLinksHere from WhatLeavesHere is a good idea. I never added that but it makes perfect sense. Right now I have other priorities though, so please place a request at m:User talk:Krinkle/Tools so I'll get at it later.

Regarding SpeedPagePatrol, hear hear! I fully agree and I'm hearing this more often lately. I loved that one too! However due to changes in the MediaWiki software^[1] the technical methods that this tool uses no longer work from the Toolserver. In order to re-create this functionality I will have to develop something entirely new. I hope to get at it soon. Thanks! Krinkle (talk) 20:06, 1 February 2012 (UTC)

[1]: Ironically I actually made that change myself. The change was related to security. It made it so that it's not allowed to patrol an edit without authentication from JavaScript running on a different domain. That is a good thing, however it makes it impossible to do something like this with a few clicks from the Toolserver. I'll have to create a gadget, running on the wiki domain, instead.

Gadget-Site.js changes

Thanks for your edits to MediaWiki:Gadget-Site.js. We have way too much custom JS that is way insufficiently maintained (not to mention unconditionally loaded for all users, sigh), so I am always very happy when someone does any maintenance here!

But regarding this change… You wouldn't happen to have a link to somewhere discussing the deprecation of $(document).ready() handy? I'm probably just having a senior moment or something, but I can't immediately reason out why that construct would be deprecated in general.

And why this, seemingly unnecessarily complicated, construct?

$( function() {
  document.body.className += ' mainpage';
});

Why not simply:

$('body').addClass('mainpage');

Apologies if the answers should be blindingly obvious. --Xover (talk) 07:55, 2 August 2019 (UTC)

There is no meaningful difference between $('body').addClass() and document.body.className, except that the second one is significantly faster. I could write three to four paragraphs to describe what the first one is doing, it is a lot. The difference is probably not very noticeable on fast desktop machines, but may be more noticeable on low-end and mobile devices.

But, there is a meaningful difference between having and not having the $( function() { code wrapper. This wrapper instructs jQuery when to execute the code. The jQuery(Function) interface, with shortcut $(Function), will schedule the given function to execute after all page elements have been downloaded from the Internet and processed. Without this wrapper, the code might not work, because it can run too early (before the relevant elements are available).

The older instruction jQuery(document).ready(Function) did exactly the same, but has been deprecated in favour of jQuery(Function). The older instruction will be removed in a future version of jQuery and MediaWiki. --Krinkle (talk) 16:32, 5 August 2019 (UTC)

Ah, I see. I guess I didn't pay sufficient attention to the deprecation notes for jQuery 3.x, and wasn't familiar with the jQuery(Function) signature. Incidentally, just to be counted (not a point I'd bother arguing), I slightly disagree with optimising for computer cycles vs. programmer cycles in the choice of DOM vs. jQuery for adding the class. In this particular case the code is exposed to volunteer maintainers (i.e. mostly not professional developers) where the relative scarceness of cycles favours optimising for the grey matter processor over the silicon one. But, as mentioned, not a point I'd bother arguing, so just providing generalised input here. Thanks for the explanation! --Xover (talk) 16:38, 10 August 2019 (UTC)