User talk:Krinkle: Difference between revisions

User:Krinkle/X

Archives Archive 1 Archive 2 Archive 3 Archive 4 Archive 5

Hi, I want to write a query than give me user's contribute in each namespace in each month. I want to use it for most editing users in last month. would you please help me on writhing this code?--Reza1615 (talk) 11:15, 23 September 2011 (UTC)[reply]

1. ... using the API?
2. ... using toolserver.org?
3. ... using index.php and parsing HTML?

I assume 2. since you'd like to use SQL. Contributions count? Something like http://toolserver.org/~soxred93/pcount/index.php?name=Reza1615&lang=commons&wiki=wikimedia does? RE rillke questions? 12:02, 23 September 2011 (UTC)[reply]

I appreciate asking me but please post this somewhere central and public. Such as Commons:Village pump (if it's Commons specific), mw: Project:Support (if it's for the MediaWiki in general), or meta: Project:Babel (if it's in general for Wikimedia/Wikipedia wikis). I read those three pages regularly and so do other experts, that way others can answer easily as well and there's less chance of people asking the same question twice, since the questions+answered are archived there together. Thanks! –Krinkle^talk 16:35, 23 September 2011 (UTC)[reply]

Hi Krinkle, Thanks for your comments and removing the bot comments on my page. Regards, Alf

Hi, you created {{PD-geq}} as a placeholder, and then the uploader did this. Seems rather messy. How to fix it? Rd232 (talk) 23:20, 26 September 2011 (UTC)[reply]

Thanks, deleted again. –Krinkle^talk 23:27, 26 September 2011 (UTC)[reply]

Thanks, but that leaves quite a lot of files relying on the deleted template. Judging by a sample of files, the uploader was using {{PD-self}} for the license. Can we recreate PD-qeq with PD-self, or would we need to substitute PD-geq on every file? Rd232 (talk) 23:41, 26 September 2011 (UTC)[reply]

Recreating with {{PD-self}} would put two PD-self's on the page. I'm removing those PD-geq uses now. –Krinkle^talk 23:42, 26 September 2011 (UTC)[reply]

OK. Rd232 (talk) 07:11, 27 September 2011 (UTC)[reply]

Dag, zou je de 500 ledige en uncategorised cats van Babel Autocreate kunnen deleten ? Het vult Special:UncategorizedCategories helemaal op. Beste groet. --Foroa (talk) 12:03, 28 September 2011 (UTC)[reply]

Hoi Foroa, ik kom hier denk ik niet aan toe. Op Commons:Bots/Work requests is er vast wel iemand die het wil doen. –Krinkle^talk 17:41, 28 September 2011 (UTC)[reply]

Hi Krinkle, as suggested in IRC, I put my thoughts here, hope it's more or less clear. Do you think it's easy to implement? A JS script to implement it on a user-base would suffice for the moment. Thank you! --Elya (talk) 18:46, 3 October 2011 (UTC)[reply]

Hi, I see you working on the gadgets, could you do the following as well:

and optimize it by doing the same as here? Thanks. I also asked DieBuche but it seems to me this user took vacation. -- RE rillke questions? 17:50, 5 October 2011 (UTC) [reply]

DieBuche is back. But we need probably help or advice regarding resource loader. Thank you. -- RE rillke questions? 10:43, 10 October 2011 (UTC)[reply]

Bot has administrator status now. Please continue testing to finalize request. --EugeneZelenko (talk) 14:56, 11 October 2011 (UTC)[reply]

I'll prepare a test run soon. Thanks! –Krinkle^talk 16:55, 11 October 2011 (UTC)[reply]

Hi Krinkle, the main page of zhwiki is at zh:Wikipedia:首页, the next day's main page is at zh:Wikipedia:首页/明天, so you can include that in your testing when you have time ;) --Bencmq (talk) 13:14, 16 October 2011 (UTC)[reply]

Commons:Auto-protected files/wikipedia/zh –Krinkle^talk 21:24, 16 October 2011 (UTC)[reply]

Hi Krinkle, can you please clarify what's happening with MediaWiki:JSONListUploads.js? Are we waiting for you to find the time to review the script (or changes to it), or what? I appreciate the 1.18 MediaWiki update caused all sorts of issues that may have taken your time, but this thing has dragged on so long and it's not clear to me what's going on. Thanks. Rd232 (talk) 18:52, 14 October 2011 (UTC)[reply]

Hi Krinkle, are you sure the Thumbnail Purge of MediaWiki:Gadget-ExtraTabs2.js is working? I've got both ExtraTabs2 and Thumbnail Purge enabled, but I don't get any "generate thumbnail" links on file pages. Am I missing something? Rd232 (talk) 23:58, 31 October 2011 (UTC)[reply]

Recently, you added Tiny textareas in AbuseFilter are annoying, and never the right size. to common.js. I am not sure whether this causes that my browser becomes unresponsive when loading a abuse-filter-page or whether it is caused by something else.

Client: Firefox 7.0.1

Additionally this is superflous for users of modern browser since they can resize textareas without a js-plugin. Therefore I would appreciate being able to opt-out it. And: Please remember that $.getScript( isn't secure for Firefox. Sometimes it executes the function befor the script is actually interpreted. Happy fixing. Regards. -- RE rillke questions? 17:44, 2 November 2011 (UTC)[reply]

Making Cat-a-lot use RL causes i18n to fail because catALot is expected to exist globally so i18n files can modify it. Also please have a look at my editprotected requests on the talk page. Thanks. Liangent (talk) 05:12, 14 November 2011 (UTC)[reply]

Strange. I tested it and it worked after I explicitly bound it to the window-object. window.catALot = { -- RE rillke questions? 08:48, 14 November 2011 (UTC)[reply]

Not strange as ResourceLoader modules are not executed in the global scope. This is one of the core principles of how ResourceLoader works. A local var statement is kept local and not implied as a global. We found that in most cases people only want a variable to be local, and to avoid pollution of the global scope or accidental overwriting/overloading of other things we want to encourage people to take the object oriented approach (as far as possible in JavaScript – which you already seem to be doing in Cat-a-lot :)) and define your main object once as a global object and then refer to it by it's name and call/extend/do whatever with it –Krinkle^talk 00:06, 19 November 2011 (UTC)[reply]

This also forces/ensures that code is easier to understand. var catALot does not make clear in any way that another file may be using this variable, or is even supposed to, whereas window.catALot makes this clear. –Krinkle^talk 00:07, 19 November 2011 (UTC)[reply]

So window.catALot = { should work? But this message was posted after I did this edit. Maybe it is too late today and I didn't get it. BTW, DieBuche wrote Cat-a-lot. -- RE rillke questions? 00:38, 19 November 2011 (UTC)[reply]

Following up part of MediaWiki_talk:Gadgets-definition#Location_of_category_interface_gadgets: is there any way to make the |page parameter of {{Gadget-desc}} work again? In view of Bugzilla: 29398 is it worth filing a bug to support this, if necessary? If so, perhaps you'd be best placed to do it. Rd232 (talk) 17:39, 3 December 2011 (UTC)[reply]

The {{Gadget-desc}} template (and the related JavaScript in MediaWiki:Common.js) work just fine. The problem is that the descriptions using that template are still using the old format. Sections have a name instead of numbers (eg. 'rc', 'watchlist') see also template documentation at Template:gadget-desc. –Krinkle^talk 19:36, 3 December 2011 (UTC)[reply]

While debugging I discovered that nothing of Common.js loaded (well not Common.js in particular but anything that is site-specific (including Vector.js)). On Special:Preferences, certain scripts are not loaded. This is intended (to prevent corrupted gadgets from doing anything security related etc. - or locking yourself out unintentionally). However in MediaWiki 1.17 this system only prevented user-scripts from loading. In MediaWiki 1.18 this system was rewritten and it looks like it now prevents both user-scripts ánd site-scripts from loading. I'm not sure this was an intended change, I'm reporting this upstream now and will come back to you. –Krinkle^talk 19:39, 3 December 2011 (UTC)[reply]

Thanks. Rd232 (talk) 19:53, 3 December 2011 (UTC)[reply]

See also bugzilla:18186. Helder 13:38, 17 December 2011 (UTC)

Thanks. In view of that WONTFIX, Bugzilla: 33220 requests a native MediaWiki replacement for what was previously done in Javascript. Rd232 (talk) 17:36, 17 December 2011 (UTC)[reply]

Hi Krinkle, User:CommonsDelinker/commands is sleeping (inactive) since 24 hours now. Could you take a look? Thanks. --Túrelio (talk) 17:58, 20 December 2011 (UTC)[reply]

Thanks, I've killed the bot process and it should restart shortly. –Krinkle^talk 18:56, 20 December 2011 (UTC)[reply]

Yeah, it's running again. Thanks. --Túrelio (talk) 07:19, 21 December 2011 (UTC)[reply]

Hallo Krinkle, do you know what an edit comment is? :-) Best wishes for the new year! --Saibo (Δ) 00:49, 28 December 2011 (UTC)[reply]

Thanks for doing the script cleanup! :) --Saibo (Δ) 02:03, 28 December 2011 (UTC)[reply]

Thanks. And I'll try to fill in the edit summary more often :) –Krinkle^talk 02:04, 28 December 2011 (UTC)[reply]

I know, it happens every now and then - but especially in those important pages it is important. ...and it will happen despite this. Thanks for trying and good night! --Saibo (Δ) 02:19, 28 December 2011 (UTC)[reply]

May I ask why you moved that above user's talkpage to an archive then deleted the re-direct? All this instead of blocking this obvious serial copyvio uploader? You've moved, out of sight, all the evidence of his 'crimes'. I don't understand why. --Fred the Oyster (talk) 01:41, 28 December 2011 (UTC)[reply]

Hi, you're right, there was no need to archive. I mixed up two tabs. I've linked to the archive now (since it exists now) and have re-instated the block. –Krinkle^talk 01:45, 28 December 2011 (UTC)[reply]

Many thanks for taking the time to explain it and to action it, I'm much obliged. --Fred the Oyster (talk) 02:00, 28 December 2011 (UTC)[reply]

You're welcome. –Krinkle^talk 02:01, 28 December 2011 (UTC)[reply]

Hi Krinkle, I understand if you dislike me, since my visits on your talk-page always occur if something does not work ;-)

Following the latest changes at Special:PrefixIndex/MediaWiki:Stockphoto.js/ causes a runtime-error -at least in Firefox- preventing my common.js to be loaded. (This was a very strange symptom and it took me hours to find out what was responsible for this madness on file-pages, including deactivating all my gadgets) The folling is going on:

Firebug tells me the following stack (but I assume it is wrong... somehow weird)

init > ready > DOMContentLoaded > init > ParseXML

Error:
object is undefined
Sourcefile: https://secure.wikimedia.org/wikipedia/commons/w/load.php?debug=false&lang=fr&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20111213T185322Z
Line: 8

But there is no "object" in ParseXML; instead it is in each: function (object, callback, args) {. All in all, I am unable to understand what exactly caused the problem but I assume it was passing the pointer instead using the anonymous function. I am really curious whether you find it out. I just reverted de so far so you can play with &uselang=fr - e.g. [1]. Thank you. -- RE rillke questions? 22:53, 2 January 2012 (UTC)[reply]

And here is the output from Opera:

Uncaught exception: TypeError: Cannot convert 'object' to object
Error thrown at line 8, column 1641 in <anonymous function: each>(object, callback, args) in https://secure.wikimedia.org/wikipedia/commons/w/load.php?debug=false&lang=fr&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20111213T185322Z:
    var name,i=0,length=object.length,isObj=length===undefined||jQuery.isFunction(object);
called from line 63, column 3 in <anonymous function: init>() in https://secure.wikimedia.org/wikipedia/commons/w/index.php?title=MediaWiki:Stockphoto.js&action=raw&ctype=text/javascript:
    $.each(this.information_template_hints, function (k, v) {
called via Function.prototype.apply() from line 14, column 0 in <anonymous function: resolveWith>(context, args) in https://secure.wikimedia.org/wikipedia/commons/w/load.php?debug=false&lang=fr&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20111213T185322Z:
    callbacks.shift().apply(context,args);
called from line 6, column 248 in <anonymous function: ready>(wait) in https://secure.wikimedia.org/wikipedia/commons/w/load.php?debug=false&lang=fr&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20111213T185322Z:
    readyList.resolveWith(document,[jQuery]);
called from line 12, column 1813 in <anonymous function: DOMContentLoaded>() in https://secure.wikimedia.org/wikipedia/commons/w/load.php?debug=false&lang=fr&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20111213T185322Z:
    jQuery.ready();

Ah, I forgot: I wish you a wonderful and happy new year. -- RE rillke questions? 22:54, 2 January 2012 (UTC)[reply]

Thanks, I'm on it. Major edit. –Krinkle^talk 00:04, 3 January 2012 (UTC)[reply]

This was fixed last night, can you confirm ? –Krinkle^talk 15:15, 3 January 2012 (UTC)[reply]

Yes, thank you. -- RE rillke questions? 15:37, 3 January 2012 (UTC)[reply]

I've noticed that you've being playing around with some of the MediaWiki pages, not sure if you've done it or not but I now get Special:UploadWizard link rather then Commons:Upload with the "Upload file" in the Participate section of the side bar (in the Monobook skin). I don't want the file wizard since I hate using it, I've already did one javascript work around and I'm not wanting to spend more time getting the upload page (Commons:Upload) I want. It was working this morning (my time) but this afternoon I get the page that I dread seeing. Bidgee (talk) 04:44, 3 January 2012 (UTC)[reply]

Hi, I assume I was the culprit. Please look at Commons:Village pump#MediaWiki:Gadget-NoUploadWizard.js (deactivate Gadget-UploadWizard). Thank you. -- RE rillke questions? 11:15, 3 January 2012 (UTC)[reply]

Deactivating it doesn't work. I still get it. Bidgee (talk) 11:43, 3 January 2012 (UTC)[reply]

Now it should. Otherwise you have to disclose your language setting to me. -- RE rillke questions? 13:53, 3 January 2012 (UTC)[reply]

Krinkle, I wonder how we could speed-up the link replacement in MediaWiki:Gadget-UploadWizard.js since it sometimes takes long until $(document).ready fires but I experienced that it never caused problems to change the link right away. So why not doing so and simply doing again after $(document).ready? Objections? BTW, thanks for reviewing and correcting! -- RE rillke questions? 11:33, 3 January 2012 (UTC)[reply]

When working in MediaWiki core it's important to wait until document ready as the element doesn't exist yet otherwise. However gadgets are by default loaded from the bottom of the page (after the end of the main content, a little bit before "document ready"). At that point it is safe to manipulate anything above that line, so yes, feel free to remove the document ready wrapper for that gadget. –Krinkle^talk 15:14, 3 January 2012 (UTC)[reply]

Can you confirm this? Thank you. -- RE rillke questions? 14:49, 5 January 2012 (UTC)[reply]

Hi, just tried it and found it useful to be a gadget. So here it is: MediaWiki:Gadget-CUP.js. If you have concerns, let me know. Thanks. -- RE rillke questions? 21:27, 10 January 2012 (UTC)[reply]

Thanks, very nice! –Krinkle^talk 22:54, 10 January 2012 (UTC)[reply]

Hi, I see you've recently protected the uploads of Jorm (WMF): various SOPA-related icons and things, e.g. (1), (2), (3). Could I possibly ask that you add them to Category:SOPA initiative at some point? Thank you! It Is Me Here ^{t / c} 00:33, 18 January 2012 (UTC)[reply]

 Done Rd232 (talk) 00:49, 18 January 2012 (UTC)[reply]

Hi,

I just discover Commons:Deletion requests/File:Ricci - Trigault - Histoire de l expédition chrestienne au royaume de la Chine, 1616.pdf. This is a total non-sense for several reasons :

• the Google logo is not copyrighted (how could it be ? plus see Category:Google logos )
• nearly 90% of the PDF/DJVU files used on the Wikisources come from Google (directly or not). And most of it have this two first pages (because it’s easier and more “honest”). Even without this two pages, this pages are still on the original source, so deleting them didn’t change anythong.

So to be logical, there is two solutions : restore this file or procede to a mass deletion.

Cdlt, VIGNERON (talk) 15:30, 23 January 2012 (UTC)[reply]

Thanks for contacting me, however I can't help you. I nominated the file (instead of speedy-deleting as copyright violation) because I wasn't sure it was a violation. For those questionable situations, deletion nominations are ideal because they allow for discussion. The admin who decided to delete it was User:Jcb. Please re-open the nomination page or contact User:Jcb personally if you believe the taken action was not correct, or if additional actions should be taken. –Krinkle^talk

Hallo Krinkle, please have a look here http://commons.wikimedia.org/w/index.php?title=File:Srinagar_Sher_Garhi_Palace_01.jpg&action=history Why do you release the file to the wild (without problem tags) with such a poor license information? Cheers --Saibo (Δ) 02:31, 26 January 2012 (UTC)[reply]

Thanks, I had mixed up the creation date and the year of death. If the author would have died in 1923, it would've pretty much been PD-old, but such information is clearly not given here. You're right! –Krinkle^talk 17:31, 26 January 2012 (UTC)[reply]

Turned it into a deletion nomination instead. Hoping the user will provide the info soon. –Krinkle^talk 17:39, 26 January 2012 (UTC)[reply]

Okay, thank you! Cheers --Saibo (Δ) 17:53, 26 January 2012 (UTC)[reply]

Hi, last 2 times when visual merge of {{Information}} and {{Location}} was discussed you seem the most knowledgeable about how it is done. It seems like recent changes to {{Information}} broke it again, see Template_talk:Information#Edit_request. Any chance you can look at this? --Jarekt (talk) 15:01, 27 January 2012 (UTC)[reply]

Thanks, replied there. –Krinkle^talk 11:44, 29 January 2012 (UTC)[reply]

Revision of 66120826 — I hope you noticed that {{Information}} was reverted, too so it now does not contain an outer <div class="hproduct"> but {{Artwork}} has. Just look at File:David napoleon.jpg. -- RE rillke questions? 15:32, 29 January 2012 (UTC)[reply]

Hello!

Although I do not doubt your rationale with this DR, it is quite uncommon to close DR before the 7-day-rule based on own keep-comments. I'd wait for another admin to close it. Regards, High Contrast (talk) 01:03, 31 January 2012 (UTC)[reply]

I agree the format is uncommon. Normally an admin would call it "Speedy keep" and not leave a comment himself but put the reason in the speedy close reason. However I left a comment first and came back later, decided to speedy keep, so it looks like this now.. –Krinkle^talk 01:06, 31 January 2012 (UTC)[reply]

Hi Krinkle,

Thanks for your proposal: I think the "patroller" right may be useful to me. So, I'd welcome you to give me this right. Croquant (talk) 18:14, 5 February 2012 (UTC)[reply]

We always appreciate help. Keep up good working! -- RE rillke questions? 19:06, 5 February 2012 (UTC)[reply]

What do you think about allowing license-reviewers, too to patrol new uploads? Regards -- RE rillke questions? 19:06, 5 February 2012 (UTC)[reply]

Hi Krinkle, finally I was in the barnstar shop today - so here it is: your barnstar. Thanks for all your good work and nice communication! Currently especially in programming ResourceLoader and similar stuff and bringing patrolling much forward! Cheers --Saibo (Δ) 22:16, 5 February 2012 (UTC)[reply]

Hi Krinkle, I made this to prevent loading this huge code all the time. I would appreciate no changes because I am currently working on a new version. Furthermore, you did not use an edit-summary. Thank you. -- RE rillke questions? 12:33, 7 February 2012 (UTC)[reply]

Hi Rillke, I know what this script does and I use it myself for the same reason. The script is not stored in your user space and I didn't appreciate you reverting my edit for no reason. The adjustment I made to the script should be clear to any javascript programmer. void() is the most useless function ever since it has no useful purpose and was redundant where it was used (as was the loose {}-block, considering JavaScript has no block scope), there is also no point in passing a 'null' argument for 'tooltip' if you don't want a tooltip (worst case scenario passing 'null' might be worse than not passing, since 'null' would return true when checking for 'not undefined', however addPortletLink covers for both). If you pass it to be complete (cover all arguments), then why not pass another null for the arguments? Take a look at the diff 1 second and it should make perfect sense.

I'm going to re-apply that edit now since you seem to suggest that my edit would load it for everyone instead of just on-click but the contrary is true. That logic wasn't changed at all. –Krinkle^talk 12:44, 7 February 2012 (UTC)[reply]

My apologies, you are of course right. I cannot exactly remember why I've used this ugly syntax but I assume it was in times importScript returned a boolean value causing the browser showing the function-result instead of starting the script. Something like

window.fnboolres = function () { return true; }
mw.util.addPortletLink('p-tb', 'javascript:fnboolres("MediaWiki:VisualFileChange.js");', 'Perform batch task', 't-AjaxQuickDeleteOnDemand');

-- RE rillke questions? 13:00, 7 February 2012 (UTC)[reply]

Don't worry :)

importScript does indeed not return a true-thy value, however I just tested what would happen with a true-thy returning function. Looks like most modern browsers don't have a problem with it from the javascript:-href. However when testing in for example an old Firefox version I noticed that it indeed loaded the javascript-code in the address bar (instead of silently executing it).

The safest way is probably to either:

• Return false from an IIFE function:

mw.util.addPortletLink( .., 'javascript:(function(){ importScript(..); return false; }());', .. );

• Use an actual click event handler and just tell the browser to prevent the default behavior (recommended):

var link = mw.util.addPortletLink( .. );
$(link).click(function (e) {
  e.preventDefault();
  importScript( .. );
});

–Krinkle^talk 13:16, 7 February 2012 (UTC)[reply]

Hello again, yes I forgot about the arrays that actually aren't (yes I know that an array is just a special object) but what do you think about the mapping of the often used wg-variables (l.15) to local variables there? I think either replacing all or none of them with the overhead-mw.config.get . -- RE rillke questions? 21:23, 7 February 2012 (UTC)[reply]

I see that, but giving local variables names that clash with global ones is not a good habbit. Local scope should speak for themselves, and using "wg" ("wiki global") does not speak for itself when referred to for a local variable. I've renamed them to "pageName" instead of "wgPageName". Thanks, –Krinkle^talk 21:34, 7 February 2012 (UTC)[reply]

Hi, just to warn you: User talk:83.30.219.137 - this user is widely known for edit warring on Polish wikipedia, and also some others. He likes to edit railways-related articles and files, blank discussion pages and so on. He has a random IP, once he used to have a 77.255.*.* address and when it was blocked he returned with 83.30.*.*. Don't expect any answers from him. D T G (talk) 15:54, 8 February 2012 (UTC)[reply]

Thanks, investigation started at User:Krinkle/Socks#Rail-related_nonsense. Now that a connection is clear, reverting more questionable edits. –Krinkle^talk 17:58, 8 February 2012 (UTC)[reply]

See also: Commons:Administrators'_noticeboard/User_problems/Archive_20#Polish locomotive enthusiast , Commons:Administrators'_noticeboard/Vandalism/Archive_4#77.255.212.106 . D T G (talk) 18:23, 8 February 2012 (UTC)[reply]

Good morning. Yes, I am the author of this work. I put my keyword. I have two different acounts, (luissilveira or José Luís Ávila Silveira/Pedro Noronha e costa). I'm changing the name because that is more accurate since they are holiday pictures made with my friend Pedro Noronha e Costa. Hugs from the Azores Islands.José Luís Ávila Silveira (talk) 11:41, 9 February 2012 (UTC)[reply]

Thank you, vielen dank, merci, dziękuję bardzo, спaсиба 80.171.106.177 21:07, 9 February 2012 (UTC)[reply]

Hello, my name is Alex. Would you be so kind as to provide me with three or four images from the Royal Collection? I have seen a picture taken from there (high-res) that was uploaded by you. Please respond on my talk page. Yours truly, Alex. --Alexcoldcasefan (talk) 20:08, 7 March 2012 (UTC)[reply]

Hi Alexcoldcasefan, Thanks for asking, but I no longer have the tools to do this. You'll have to find someone else to help you with this. –Krinkle^talk 20:16, 7 March 2012 (UTC)[reply]

Okay, thank you anyway. --Alexcoldcasefan (talk) 06:32, 8 March 2012 (UTC)[reply]

Hi! I left a licensing question on at Magnus Manske's talk page that concerns you as well. Regards, /Skagedal (talk) 21:38, 7 March 2012 (UTC)[reply]

Your recent edit to MediaWiki:Gadget-Stockphoto.js left this remaining code line:

thumb_url = thumb_url;

A bit redundant, I'd say. :) /skagedal^talk 20:35, 19 March 2012 (UTC)[reply]

Thanks, Fixed. –Krinkle^talk 06:03, 20 March 2012 (UTC)[reply]

I see Commons:Auto-protected files/wikipedia/en has been around for 5 months or so, but I just became aware of it last night. Just a belated note of thanks for having your bot do that. --Floquenbeam (talk) 15:21, 23 March 2012 (UTC)[reply]

Hi! Please see [2] (this should be test2:User talk:Krinkle#redirect from an alias). Best regards ‫·‏לערי ריינהארט‏·‏T‏·‏m‏:‏Th‏·‏T‏·‏email me‏·‏‬ 07:44, 3 April 2012 (UTC)[reply]

I've replied there. –Krinkle^talk 18:35, 3 April 2012 (UTC)[reply]

Dear Krinkle, I kindly invite you to evaluate the usage of authority control data using ZCZC type BEACONS. template:Authority control has many limitations and is limited to some WMF sites. I try to be on irc. Regards ‫·‏לערי ריינהארט‏·‏T‏·‏m‏:‏Th‏·‏T‏·‏email me‏·‏‬ 23:05, 25 April 2012 (UTC) BiDi fixing signature trailer[reply]

Thanks for the help at http://test2.wikipedia.org/?curid=2827 . I am not a "regex" expert.

1. Please eliminate "w/index.php" from the link
2. Please use "p-cactions" — it is better accessible because it is at the top of the vector skin — no scrolling is required

var my_shortesturls_url (should be computed with regex)
var my_shortesturls_name = "Article Id:" + wgArticleId;
and also
addPortletLink('p-cactions',my_shortesturls_url,my_shortesturls_name);

Thanks in advance! Regards ‫·‏לערי ריינהארט‏·‏T‏·‏m‏:‏Th‏·‏T‏·‏email me‏·‏‬ 23:38, 25 April 2012 (UTC) BiDi fix[reply]

Hola queria preguntarte como debo hacer para verificar por que el autor me dio permiso pero la verda no entendi bien,.--DJMalik (talk) 23:33, 26 May 2012 (UTC)[reply]

Hi,

I don't speak Spanish, but I understand (by using an online translator) that you say you have permission. On Wikimedia Commons it is important that files are freely usable according to the License Requirements. Therefore, the permission to use a file under a free license has to either explicitly given on the website the file is from, or it has to be confirmed by e-mail to Permissions Team (COM:OTRS). –Krinkle^talk 23:38, 26 May 2012 (UTC)[reply]

Hallo Krinkle. "Skansen Parowozownia Kościerzyna" is old, now is "Muzeum Kolejnictwa w Kościerzynie" (in english "Railway Museum in Kościerzyna"). Please rename this. Thanks.

Gdaniec (talk) 10:23, 5 June 2012 (UTC)[reply]

Renaming of categories is not yet possible in the wiki software. We use a bot for that, please request it at User_talk:CommonsDelinker/commands#Category_moves. –Krinkle^talk 10:29, 5 June 2012 (UTC)[reply]

Hi. Just wondering why you are replacing uses of "{{W}}". Is this necessary? — Cheers, JackLee ^–talk– 20:43, 9 June 2012 (UTC)[reply]

Seems quite useless to have a template to do [[w:Foo|Bar]] as {{w|Foo|Bar}}>. –Krinkle^talk 20:45, 9 June 2012 (UTC)[reply]

Hopefully you're not intending on deleting the template. It's much easier to write {{w|something here}} than [[w:something here|something here]] (to get rid of the somewhat ugly w: prefix easily). Killiondude (talk) 20:49, 9 June 2012 (UTC)[reply]

Non-sense, if you don't like the interwiki syntax, that's your problem, get used to it. This is how the syntax is and always has been. If anything, the template is confusing for users who are trying to learn the syntax (since m:, File:, nl: etc. is still going to be in that syntax). Also if you don't want to write the name twice, use the pipe trick ([[w:Foo|]]). –Krinkle^talk 20:53, 9 June 2012 (UTC)[reply]

I am fully aware of interwiki syntax and how to use it. I'm not sure where the vitriol is coming from. Templates were specifically created to help people from re-writing things over and over. New users have to learn how to spot templates at some point (distinguishing {{}} from [[]]) so that's really a non-argument. Also, telling someone that they have a problem and to "get used to it" is kind of inappropriate in this context. Please refrain from making assumptions about me! Killiondude (talk) 20:58, 9 June 2012 (UTC)[reply]

For what it's worth, I didn't assume your motives or implied to know your opinion on the matter, emphasized by "if you ..". But if you feel wronged, I'm sorry, no offense intended. Either way, I'm not going to mass replace this or nominate it for deletion. But, if I'm editing or reading somewhere and notice this being used, I will not refrain from replacing its inline usage with a regular interwiki link. –Krinkle^talk 21:03, 9 June 2012 (UTC)[reply]

The main advantage of {{W}} is to shorten links. There isn't much difference if one is using a piped link (e.g., "{{w|Foo|Bar}}"), but if one is only setting out the name of the English Wikipedia article, then the template shortens the wikitext required by almost half (e.g., "{{w|Foo}}" instead of "[[w:Foo|Foo]]"). I therefore suggest that you avoid replacing uses of the latter nature. — Cheers, JackLee ^–talk– 21:57, 9 June 2012 (UTC)[reply]

 Delete -- πϵρήλιο ℗ 00:40, 10 June 2012 (UTC)[reply]

This isn't a deletion discussion about any template, so I'm not sure what you're referring to. — Cheers, JackLee ^–talk– 08:13, 10 June 2012 (UTC)[reply]

I can make one!? -- πϵρήλιο ℗ 20:29, 10 June 2012 (UTC)[reply]

I would oppose deletion. As mentioned above, {{W}} is a useful template. — Cheers, JackLee ^–talk– 07:52, 11 June 2012 (UTC)[reply]

Although I find it funny to wake up and find a {{delete}} vote in this thread on my talk page – I kindly ask you to stop or move this discussion elsewhere. Thanks, –Krinkle^talk 11:54, 11 June 2012 (UTC)[reply]

Tĥ for the information. How can I apply? -- Alan ffm (talk) 21:04, 9 June 2012 (UTC)[reply]

You just did . But normally, one can ask on COM:RFR. 21:06, 9 June 2012 (UTC)

Thank you -- Alan ffm (talk) 21:24, 9 June 2012 (UTC)[reply]

Did you delete the right file? The deleted file was uploaded as File:Blason dpt fr Sarthe.svg five years ago as own work by User:Syryatsu. The kept file was uploaded less than a month ago as own work by User:Fauntleroy. If the files were duplicates it seems more likely that the older file had correct information and should have been kept.
(I think both files could have been kept (with corrected sourcs/author information) since they were ment to represent coats of arms of two different places. Now the file name says one thing and the description something other.) /Ö 18:49, 11 June 2012 (UTC)[reply]

It was intended as uncontroversial maintenance. If there is any reason to belief something is odd... I've restored both in their original state. –Krinkle^talk 19:02, 11 June 2012 (UTC)[reply]

Thank you for restoring the images. The odd thing was that two duplicate images had different authors. But now that I can see both images I see that they are different and not duplicates. /Ö 19:52, 11 June 2012 (UTC)[reply]

	The Technical Barnstar
	For literally writing the entire code for two (very important) gadgets today. Siddhartha Ghai (talk) 01:35, 5 July 2012 (UTC)[reply]

What about using the new method on http://toolserver.org/~krinkle/AnonymousI18N.js? (is that page still needed?) Helder 14:32, 7 August 2012 (UTC)

Thanks, I've removed the file. –Krinkle^talk 01:09, 8 August 2012 (UTC)[reply]

Hi Krinkle, I thought you take a break but now there some questions, I'd like to ask:

• What happened with CUP and why?
• Why "normal" scripts can't be cached when loaded through action=raw? At least one can ask the server to set a header making the client caching the code and it was the way scripts were used the last 10 years (or still are).
• What do you suggest to get the validators back to Commons? A gadget that bundles all of them? I think there should be a way notifying people if the JavaScript they are going to save contains errors. I also intend adding a PST-term warning because I often saw people saving things like {{subst:x}} or ~~~~. Of course i18n has to follow, the code must be cleaned and that's why I limited it to the MediaWiki namespace (but someone changed the inclusion-code) yet.

-- Rillke^(q?) 15:46, 8 August 2012 (UTC)[reply]

I've put up the wikibreak for the entire duration of my vacation. However it actually covers 3 separate trips. I'm a few days at home this week.

• CUP: The hack I had on the Toolserver no longer worked properly and was causing my database account at the Toolserver to reach its maximum so often that my other tools suffered from it. I've disabled the tool and removed it from the publicly reachable space. As such gadgets referring to it were getting 404 errors (since I disabled the tool) so I've removed them. The only acceptable way to patrol files is in MediaWiki itself. The Toolserver tool was a proof-of-concept as opposed to a proposed reasonable workflow. I know some people used it and liked it (including myself), but the queue was unrealistically big anyway due to lack of an integrated 'autopatrol' for bots and experienced users (if done in MediaWiki that will automatically work). If we're going to get a patrol feature, it will have to be done in either MediaWiki core or as a proper MediaWiki extension (because it needs tight integration to avoid duplication of efforts).
• Cache: The server cache as well as the client cache for action=raw is just fine. I don't know what problem you're having, but I'd be interested in what makes you think they aren't cached (other than perhaps a misunderstanding from reading, did you actually try/experience issues with this?). That logic hasn't changed in essence since its original introduction years ago.
• Validators: I don't care. The code wasn't bad, I just didn't like how it looked visually. But all I ask is for it to be done as a ResourceLoader module (e.g. a gadget) instead of putting more stuff in Common.js that isn't properly cached, minified or disable-able by the user. And also isn't very mobile (hard to move to another wiki since it has tentacles in unrelated files such as Common.js).
  When I say isn't properly cached I mean that action=raw is not meant for script caching (never was and never will be) because it is just retrieving the raw page contents. And just like any index.php view, it is cached for 31 days unconditionally afaik. Which means any changes to it take up to 31 to affect users all abroad. This is especially problematic if different action=raw files "use" each other as the server/client may have cached them at different points in time (whenever the browser first saw them). This is one of the many reasons ResourceLoader was created, which properly handles dependencies and cache keeping, and (more importantly) cache destruction when needed. So it makes sense in all ways to use ResourceLoader as opposed to the old legacy load methods (aka no method at all, just injecting a script tag and cache for 31 days). –Krinkle^talk 18:28, 8 August 2012 (UTC)[reply]

Hi, I noticed you formatted the Common.css'es across several wikis. I would like to know which software you used for automatic prettifying, so I could analyse its behaviour. Best regards, Od1n (talk) 06:31, 4 September 2012 (UTC)[reply]

To expand my point, I noticed several glitches with the formattings:

/* this comment contains ; a semicolon _NO__DOTCOMMA__AFTER__ */

Undesirable "magic word" inserted, semicolons in comments are just fine and shouldn't trigger anything.

.foobar {
  /* an "inline" comment */;
  some: rule;
}

.foobar {
  some: rule; /* another "inline" comment */;
}

The semicolons added after these comments are superfluous (and make Recess to fail at parsing, but it should be fixed on their side). Notably, breaks syntax highlighting on some editors, for example Notepad++.

@media screen {
  .foobar {
  some: rule;
};
}

Same as above, superfluous semicolon inserted (makes Recess to fail parsing too).

.entete.defaut {}

/* becomes: */

.entete.defaut {
;
}

Same semicolon insertion problem.

/* comment about a <foobar> tag*/

/* becomes: */

/* comment about a  tag*/

<tags> are stripped from comments.

Hoping this report will be of some help. Regards, Od1n (talk) 20:27, 4 September 2012 (UTC)[reply]

I usually do it by hand, but if it is a real mess I tidy it up with http://procssor.com/ or the built-in prettifier in Panic Coda 1.x or Sublime Text 2 and go from there. These are harmless glitches inserted by ProCSSor that I missed in review. You may want to add some links so I can fix them (or if you're able to, fix it yourself). Thanks for sharing, –Krinkle^talk 20:36, 4 September 2012 (UTC)[reply]

Hi Krinkle, also because it might interesting for you, I would be pleased if you could poke the right people for bugzilla:40124, perhaps at a mailing list. Thanks in advance. -- Rillke^(q?) 21:57, 9 September 2012 (UTC)[reply]

The bot appears to be down - could you take a look? Thanks. --Rschen7754 17:52, 15 September 2012 (UTC)[reply]

It has been suggested that I apply a de minimis-template here. I would very much like to, but moderator 1veertje has protected that page indefinately. I have allready requested 1veertje to lift that ban, but she refuses. Hereby my request to you, so I can apply the template. Thanks in advance. Kleuske (talk) 09:42, 21 September 2012 (UTC)[reply]

Hi Timo, recently you ran a clean over MediaWiki:GallerySlideshow.js and this was the result:

$prevBtn = $('<a>').attr({
	'class': 'next gs-play gs-play-bwd',
	title: "blbla",
	href: '#previous',
	click: function (e) {
		console.log('Click handler on attr')
	}
});

This caused that the function assigned to the property "click" was immediately executed (without being clicked) which in turn lead to an infinite loop until all files of a category were loaded. Due to another bug, in small categories, the same files were loaded and loaded again until the user's browser crashed or the user clicked the red x :-)

Thanks for your suggestions and issues at MediaWiki talk:GallerySlideshow.js#Various bugs and of course for the clean up. Did you know that running a test before saving isn't difficult: Copy the whole code, paste it into your browser's console window and execute it. Then click the slideshow start button. This way, one avoids unnecessary edits and trouble and on top of it, it's a fast test. Regards -- Rillke^(q?) 12:40, 21 September 2012 (UTC)[reply]

Hi Rillke,

Not so quick there, I know what I'm doing. See documentation, the map passed to jQuery( .., map ); are key-value pairs that can be either jQuery methods, or (if no such method exists) attributes. The following works just fine:

$('<div>', {
    title: 'foo',
    click: function (e) {
        console.log(this, e);
    }
});

I must've missed a few cases where the map wasn't being passed to jQuery() but to .attr(). I should've seen that.

Anyway, I understand your reaction as it clearly did cause fatal errors in a very common case (I did test it, and it worked for me. I must've clicked other buttons).

Either way, part of the reason it was so hard to catch is because the code was rather messy. No heads or tail and vastly inconsistent in syntax. Like for example why sometimes it lets jQuery parse HTML strings for simple elements, and other times it uses jQuery('<tag>', { .. });, and even other times it uses jQuery('<tag>').attr({ .. });. And why are you concatenating strings of CSS and HTML together inside javascript to implement variables? You can change the styles directly by just passing it to .css() or .text() respectively. That also eliminates the need to escape everything (although you weren't doing that either) because that sets the values directly instead of instructing the browser to parse it. e.g. when setting a value in .css() or .text() it goes literally into where it needs to go whereas passing a string of CSS to the style="" attribute or HTML string to .html() or .append() it is parsed first which means it requires escaping. Oh, and the the inconsistent whitespacing - sometimes no spaces, sometimes tabs, sometimes one or two spaces, double quotes or single quotes, sutomatic semi-colon insertion or just leaving them off etc.

Anyway, I thought I'd take this opportunity to share 4 points I think you should know, based on what I've seen so far:

1. I'm not sure, but it appears you think of the web page as a long string of HTML. This is very much not so. The document is not at any point in time a string of HTML. At all times documents are interfaced with an object model. Some of the following you probably already know. Either way, I hope you get a few useful things from it.
Example:
$('<div>').append('<p>').append('Hello').append('</p>');
I didn't see this type of code in this gadget, but I've seen it before. This shows with no doubt that the writer of this code does not at all understand that a document is not HTML, HTML is only used to transfer the document between the browser and its input (the server or, sadly, sometimes a dynamic script). It is by design impossible to insert HTML into a document for the document is not HTML, its an object. This code snippet will create the following document (converted to HTML for shorter display): <div><p></p>Hello<p></p></div>. Here is roughly how that went down. I'm telling you this not because I happen to know how jQuery works internally, I'm telling you because this is how jQuery works on the outside as well. It just uses abstract the document and implements a few convenience methods to make it appear (sometimes) that you can do things that actually can't be done:

// $('<div>')
var my = document.createElement('div');
// .append('<p>')
// It is impossible to insert HTML into a document, so we instead create a new element,
// then ask the browser to parse raw html and then harvest the result.
var ret;
var tmp = document.createElement('div');
tmp.innerHTML = '<div>' + '<p>' + '</div>';
// Browsers parse the above like:
// - Create div
// - Create p, append to div
// There is no principle of "closing" a tag, so it just works, except in "stricter" browsers like old Internet Explorer, which error on this
ret = tmp.firstChild.childNodes;
// ^ Undo the <div> wrapper, extract the parsed node(s)
my.appendChild(ret);
// ^ Append to div

This is the sequence repeats itself for the other calls, too. And in .append(), .html() and any other method that uses HTML instead of objects. Another thing I noticed is you say that ".text() should only be used if you need escaping, otherwise just use .html". This could not be more wrong, it is completely the opposite. Nodes only have 3 things: properties, attributes and other nodes. Nodes can be element nodes or text nodes. There is no such thing as inserting HTML into any of them, all we do is change their values. For example, take an element and set its "title" attribute to <Hel"lo>. If you were to write it as HTML, it would look like <p title="&lt;He\"lo&gt;"></p>. However when dealing in javascript, we're talking nodes, not HTML. So the following is what you want: myParagraph.setAttribute( 'title', '<Hel"lo>' ); (or jQuery .attr). This does not do any escaping, it doesn't convert this into escaped HTML. This is what it is, this is the document itself, it has an attribute and it now has that value. Same thing with text nodes. You'd do this: myElement.textContent = 'I bet "' + x + '" is > 5.'; (or jQuery .text). If you would use innerHTML (or jQuery .html) it would have to be escaped and parsed first, only for it to then set the text as well. So the take-away point here is, .text() does not do escaping for you because there is nothing to escape, it sets the value of a text node. .html() doesn't do escaping for you either, but that one however requires you to escape text yourself. Which if you think about it is kind of silly. Why would you want to escape a string into HTML, then let the browser parse the html and create a text node, if you can just set the text directly? So the right way would be "always use .text(), unless you absolutely need to parse HTML, in which case you use .html() (and be sure to escape text)". By know you'll also understand that .text() is always significantly faster than .html() for this very reason. This is probably not explained the best way, I suggest just playing around with it a bit and see for yourself.

2. To avoid inconsistent whitespacing, use the white: true option in JSHint (or if you prefer another whitespace convention, look for a tool that enforces that, but be consistent).

3. To avoid leaking global variables, missing variable declarations, out-of-scope errors, missing semi-colons and other patterns that may work, but are more likely to be a sign or a problem, use JSHint (and use it always!). I know you know about JSHint, but no matter how high the tolerance level in JSHint, this gadget would not pass. During my daily work, it helps a lot by working in a code editor application (instead of in the browser) that has a JSHint plugin and automatically highlights problems in the text editor as you type (I use "Sublime Text 2", but there are plenty of others). I suppose you could also do it inside the browser (JSHint itself is also written in JavaScript, you could create a gadget that does this, that would be totally cool! On-the-fly linting when editing javascript wiki pages).

4. Thanks for this wonderful gadget!

–Krinkle^talk 14:11, 21 September 2012 (UTC)[reply]

Hi Timo, thanks for the comprehensive reply.

1. I had, indeed, a wrong idea about .text(). Now I know it simply creates a text node :-)

2. I will try complying with white space convention in future, though it's difficult for me.

3. I usually test my scripts and had started a validator gadget but someone found that I can't host it at Commons because

• Commons ≠ code hoster. I should test my scripts elsewhere. (I am going to ignore this)
• Far more important: JSLint and its derivative work, JSHint, are licensed under JSON license which has the aweful clause Shall not be used for evil. And because some people at the FSF and IBM said it's non-free, some Commons users were convinced that we can't host them.

→ Do you think it would be in Toolserver's scope to host such javaScript files?

I admit that I was lazy and didn't clean up this script before proposing it as a default. All new gadgets I write, validate through JSHint. Creating nodes using e.g. $('<a>', { map }) and setting attributes through map is not always possible: If a function with the same name was added to the jQuery.prototype, the function is invoked instead of setting the attribute. Recently exprerienced this negatively with the placeholder or size attribute so I had to use .attr(map). Since creating nodes is frequently carried out in JavaScript, it's unfortune that some plugIns interfer. Imagine, someone would add $.fn.title = function() {}…

Thanks for your help. Much appreciated. -- Rillke^(q?) 15:42, 21 September 2012 (UTC)[reply]

I agree the map-parameter to jQuery() is evil in that regard. I actually don't use it in my own code, I just noticed patterns like these: jQuery('<div>', { href: '', title: '' }).click( fn ).attr('style', 'x: y;').css( 'y', 'z' ).. where it really cries for consistency. I agree the better version would be to change it to not use map all-together (instead of moving more into it), like:
jQuery('<div>')
 .attr({ href: '', title: '' })
 .on('click', fn)
 .css({ x: 'y', y: 'z' })..
The nice thing is that "attr", "prop", "on" and "css" all take the same pattern. They take both "key, value" and "key: value, key: value". Which is a very nice pattern to repeat and build upon. –Krinkle^talk 17:16, 21 September 2012 (UTC)[reply]

Hi Krinkle, I think deactivating gadgets and marking them as obsolete, removed or replaced is ok but there is no real need to delete their description and destroy any back-reference to them in case someone likes to review the old code or whatever (I often did this when reading old village pump discussions and was disappointed when I couldn't see them). What are your thoughts about this? -- Rillke^(q?) 16:58, 10 December 2012 (UTC)[reply]

I also agree that they shouldn't be deleted. If they're so harmful there, archive them in some protected subpage with a (proper or soft) redirect... but it shouldn't be needed. --Nemo 23:25, 14 December 2012 (UTC)[reply]

How does preserving the description page help understanding the code, stored on a different page that is deleted? Also, wiki deletion is preservation by nature, it can always be undeleted. I just don't like pages in the MediaWiki namespace with no references or use of them. Makes it easier to scan for things that are relevant. –Krinkle^talk 23:42, 14 December 2012 (UTC)[reply]

Having a short description of what it does helps to prepare you mind or explaining where it was used if the code is not as extensively documented as we now do. Archiving sounds like an option. But leaving a soft-redirect would also display the link to that page as existing and cross-namespace redirects also aren't a real option. How about prefixing a letter that would move that page to the end of the list? BTW, is there a deployment plan for Gadgets 2.0? (perhaps you remember our IRC talk) -- Rillke^(q?) 16:00, 15 December 2012 (UTC)[reply]

hello, after your change in hotcat js page in bn Wikipedia, hotcat is not working at bn wikipedia. please take necessary steps to fix it.--Bellayet (talk) 04:23, 19 December 2012 (UTC)[reply]

Could you please check this revision http://commons.wikimedia.org/w/index.php?title=MediaWiki%3AGadget-HotCat.js&diff=85279306&oldid=83132026 Thanks, Deepugn (talk) 08:38, 19 December 2012 (UTC)[reply]

Yeah, I spotted it also. User:Odder beat me to it and fixed it. –Krinkle^talk 21:14, 19 December 2012 (UTC)[reply]

Hello! Please see w:en:User talk:Howcheng#ITN images. Thanks! —David Levy 00:31, 1 January 2013 (UTC)[reply]

Also, would it be feasible to program KrinkleBot to protect images appearing on this list (either when they're added or x hours before the relevant dates), provided that they were placed there by Howcheng (the English Wikipedia's featured picture director)?
Because non-administrators edit the blurbs, the protected versions (which result in the images' transclusion at Wikipedia:Main Page/Tomorrow) often aren't created until minutes before the main page appearance date. As a result, they sometimes make it to the main page before the bot is able to protect them (and unfortunately, admins are no longer in the habit of uploading local copies). Today's featured image was on the English Wikipedia's main page for more than thirty minutes before I noticed the problem and protected it at Commons.
Any help would be greatly appreciated. Thanks again! —David Levy 00:50, 1 January 2013 (UTC)[reply]

Hi David and Howcheng,

I'm sorry my bot "ate" your edit, however I have to decline the exact request of "supporting manual additions" to the auto-protect system. I understand Howcheng would like KrinkleBot to monitor more of English Wikipedia's highly visible pages and forward the local cascading protection to Commons. However adding them manually is not the way to go. Howcheng's comment "KrinkleBot overwrote my edit. That's the first time I've seen that happen." suggests that it worked before, however this is incorrect. The bot does not, never did (and, unless convinced otherwise, as I will explain below, never will) support this.

Since when has Commons:Auto-protected files become the method of protecting a file on Commons? Have we forgotten how to protect a file? By requesting on COM:AN/P or if you're an admin (which you both are), by simply pressing Protect on the File page itself.

Commons:Auto-protected files, as the name indicates, is an automated system managed by KrinkleBot to forward cascading protection affecting Files from other Wikimedia projects to Commons. It does so by monitoring a set of pages on a certain wikis and automatically list those files on a page that is similarly protected here on Commons (such as Commons:Auto-protected files/wikipedia/en). Any file not listed by KrinkleBot is by definition naturally outside the scope of the "Auto-protection" initiative. Files manually added are, unless they become part of the scope within the 10-20 minute window, are automatically removed when the next version of the page is composed. The reason I don't want to implement a "manual list" is simple: They are often forgotten (causing the protection to apply longer than needed), and it is no easier than protecting it directly (both require a manual action, both require admin rights) with the advantage that an actual protection can be given an expiration date. So please, don't try to edit it again. If for whatever reason it misses a file (either temporary, due to an issue in the bot, toolserver or whatever), protect it manually for real (with an expiration date), don't add it to this internal list of the auto-protect system!

The bot already monitors Wikipedia:Main Page/Tomorrow. If there is another fixed page name that should be added, let me know.

If you would like the list of monitored pages to be expanded, you're welcome to request so here or on Commons talk:Auto-protected files. If you're interested, the source code is available in a Git repository. –Krinkle^talk 10:44, 2 January 2013 (UTC)[reply]

Thanks very much for your detailed reply.

For the most part, you're preaching to the choir. In my view, some Wikimedia admins have become accustomed to relying on Commons:Auto-protected files/wikipedia/en for purposes other than that for which it's intended. I've argued against this on several occasions and continued to rely on the conventional protection method (both here and at Wikipedia).

When Howcheng wrote that it was the "first time [he'd] seen that happen", he meant that he'd never known the bot to perform a subsequent edit before detecting that the image had been added to a page in its scope. As noted on Howcheng's talk page, it must simply have been unfortunate timing.

To be clear, my suggestion was for KrinkleBot to not remove an image manually transcluded recently (e.g. within the past hour or half-hour), thereby leaving enough time for the image to be added to a page in the bot's scope (without the risk of it being forgotten and left protected indefinitely).

As I said, I don't use or recommend this method, but I understand why it's attractive for the English Wikipedia's ITN section (the only one in which an image is displayed for a non-finite duration, making it impossible to set an appropriate expiration date). An alternative, I suppose, is to set the protection to expire in the near future (e.g. in a day), thereby allowing the auto-protection to take over when it does.

Regarding the other issue, I just created a new page for KrinkleBot to monitor. It contains a transclusion of the following day's featured image (which sometimes doesn't make it to Wikipedia:Main Page/Tomorrow in time).

Thanks again! —David Levy 07:26, 6 January 2013 (UTC)[reply]

I've been looking into how this works and I think I found the problem. For some reason Wikipedia is maintaining the POTD pages in two places. At w:Template:POTD protected/2013-01-28 and w:Template:POTD/2013-01-28. The last one is created far enough in advance. The "protected" one (whatever that is) is only created on the day itself. w:Wikipedia:Main Page/Tomorrow is referring to the "protected" name variant, which doesn't exist in time so it it showing today's POTD instead most of the time. I don't know why that is but if that seemingly absurd construction is fixed then w:Wikipedia:Main Page and w:Wikipedia:Main Page/Tomorrow can just use {{POTD/Day|{{#time:Y-m-d|+1 day}}}} directly (Main Page would use it without +1 day, of course). I know why it is protected, but since the cascading protection happens automatically I don't know why there is a separate "protected" version. Maybe it wants a different visual layout, but that can be arranged by overriding the layout, no need to repeat all the data like this. 20:01, 28 January 2013 (UTC)

All you need is a version of w:Template:POTD row that doesn't do the "includeonly-noinclude" part at the end and pass |style=row from the Main Page:

<div id="mp-tfp">{{POTD/{{#time:Y-m-d}}|style=row}}</div>

There are various standardised "style" templates for POTD, the one for the Main Page can be just another one of them. No need to subst it, afaik the whole "protected" variant can be deprecated and gotten rid of. –Krinkle^talk 20:21, 28 January 2013 (UTC)[reply]

The current setup predates the advent of cascading protection. I suppose that we simply never thought about updating it, which seems like a sensible idea. (The downside is that there would be no unprotected version for non-administrators to edit within 24 hours of the main page appearance, but the other sections have similar limitations.)

I'm going to bring this matter to the attention of the section's primary maintainers. In the meantime, can you please have the bot begin monitoring Wikipedia:Picture of the day/Tomorrow? (Because of the aforementioned issue, unprotected featured images continue to appear on the main page.) Thank you! —David Levy 00:32, 14 March 2013 (UTC)[reply]

The reason we have two copies of the POTD is to allow non-administrators to edit the captions as needed. While this is not common, it does happen from time to time. It is true that other main page content areas don't permit that to happen, but it's only really true for TFA and ITN. SA/OTD pages are available for anyone to edit 362 days of the year, and DYK blurbs can be edited while on the nomination page or while in the queues. Because we're a wiki that "anyone can edit", the goal should be IMHO to maximize the opportunity for editing. The two-template setup allows that while maintaining a modicum of security against main page vandalism. —howcheng {chat} 06:11, 14 March 2013 (UTC)[reply]

Background: en:WT:Picture of the day/Archive 3#POTD protected. —howcheng {chat} 06:22, 14 March 2013 (UTC)[reply]

Especially since nobody seems to look at the queues...Crisco 1492 (talk) 10:29, 14 March 2013 (UTC)[reply]

The reason we have two copies of the POTD is to allow non-administrators to edit the captions as needed.

Yes, I noted this above. But the setup that Krinkle has proposed would leave the unified template unprotected until 24 hours before its main page appearance (like OTD, minus the annual recurrence). From what I've seen, most non-amin POTD caption editing occurs long before then. —David Levy 16:13, 14 March 2013 (UTC)[reply]

Since Crisco 1492 started writing the POTD blurbs, they've been actually been scheduled far ahead of their Main Page appearance. If we can keep that up, then I won't object to moving to the unified method (in fact, if you look through the WT:POTD archive I linked to above, I was actually against two separate templates to begin with). —howcheng {chat} 19:42, 14 March 2013 (UTC)[reply]

• Neither would I, if people actually seem to be checking the queue... we're queued up two weeks in advance, so there's a long time for them to check it.Crisco 1492 (talk) 23:20, 14 March 2013 (UTC)[reply]

Please check this edit [3] (I think I saw a similar behavior yesterday, but can't confirm). The problem is this: the bot added File:St Peter Syburg Front.jpg to the cascade protection queue [4], the en.wiki bot verified the protection and updated the en.wiki main page, then, 30 min after the update, KrinkleBot removed the image from the cascade page leaving it unprotected, though the image was stable and always present on en.wiki main page. (One bot is playing games with another :-) Materialscientist (talk) 01:37, 28 January 2013 (UTC)[reply]

This [5] has just popped up in my watchlist. Same story as above. (The problem is I can't watch it all day long, and some images to appear on the en.wiki main page are not known in advance). Materialscientist (talk) 09:59, 28 January 2013 (UTC)[reply]

I don't know what "other bot" you are referring to or what the actual problem is. If KrinkleBot removes an entry from the auto-protect gallery (or rather, re-generates the page and not including it this time) it means that that file is no longer used on the monitored en.wikipedia pages. It is as simple as that. –Krinkle^talk 19:50, 28 January 2013 (UTC)[reply]

The "other bot" is on en.wiki. Please re-read my message above. KrinkleBot removes entries that are on en.wiki page, and will stay there for many hours. Check the timestamps. The bot first places an image in the cascade protection [6]. En.wiki bots and people check the image is protected, updates the main page (at 00:00 UTC) and all are happy. Then, 30 minutes after the update (which is typically aimed for at least 8 hours), KrinkleBot removes the image from the cascade [7], leaving it wide open for vandalism. (Then sometimes it returns the image to the cascade. Take my word on that those image are not removed/returned forth-and-back from/to en.wiki main page.) The same here [8] [9] (the update was at 8:00 UTC). We don't have a routine for continuous protection check on en.wiki. So, the bot is basically fooling the existing en.wiki routines, both bots and humans. I think it misdetects that the image is no longer on the main page, maybe because of a database problem. Regards. Materialscientist (talk) 22:30, 28 January 2013 (UTC)[reply]

I noticed links of the form [[:File:Name.ext]] won't get replaced by the script. I checked File:Roger Willemsen signature.svg both on the English and the German Wikipedia (were your script is offered as a gadget) but it linked to the local file description page in both cases. Is this intended / a known limitation or can there be anything done about it? --Patrick87 (talk) 16:22, 29 April 2013 (UTC)[reply]

I hope Krinkle doesn't mind; This is how the gadget works:

1. Each image is tested whether it is a local file or a file at Commons (using uploadBaseRe)
   1. If the image is a Commons-Image, the link is changed
   2. If it is a local image, nothing is done.
2. This leads to the conclusion that an image (not just a link) must be present. Otherwise the script does not know whether it is a local or a Commons-Image.

The only way to solve this at the client side would be an API query but this isn't recommended, I think. Of course MediaWiki could offer a feature at the server side for this because the server knows where the image resides…

-- Rillke^(q?) 16:52, 29 April 2013 (UTC)[reply]

OK, I see now. The script uses an images src attribute to determine if it is embedded from Commons or stored locally. It doesn't parse the link's href at all. So there's nothing that can be done to solve this (at least not in a reasonable way)? --Patrick87 (talk) 17:15, 29 April 2013 (UTC)[reply]

Hello Krinkle!

May I point out that your RTRC seems to be not working for some reason. I'm not sure why. I followed your directions on the script page, and it had worked fine for me before, but suddenly it won't appear. I use it on en.wikipedia.org. Numbermaniac - T- C 06:42, 12 May 2013 (UTC)[reply]

Please provide more details. It works for me: https://s3.amazonaws.com/f.cl.ly/items/2L2Q1S3c1u0r013T2V3m/Screen%20Shot%202013-05-15%20at%207.25.09%20PM.png. –Krinkle^talk 17:27, 15 May 2013 (UTC)[reply]

I don't know why, it just was not working on any device on that day. But now it's working fine. Odd. Numbermaniac - T- C 22:30, 15 May 2013 (UTC)[reply]

	The Technical Barnstar
	The Technical Barnstar is awarded to anyone who has enhanced Wikimedia Commons through their technical work (programming, bot building, link repair, etc.). Many thanks for maintaining of Commons Delinker. -- Steinsplitter (talk) 10:29, 13 July 2013 (UTC)[reply]

The bot still makes errors when deciding which image is on the Main Page of en.wikipedia. File:Hanging 30? (8017221899).jpg was added there on 00:00　UTC 1 August and will stay until at least 8:00 UTC. KrinkleBot removed it from the protection cascade on 00:48 UTC [10]. Database problems? Materialscientist (talk) 02:42, 1 August 2013 (UTC)[reply]

Unless it is restored automatically in the next edit (within 15 minutes) this is not an error in KrinkleBot.

KrinkleBot lists all the images that are used on one of w:Main Page and w:Wikipedia:Main Page/Tomorrow (according to the imageusage database). If the bot removed an image, it is because according to MediaWiki itself, that image is no longer used on either of those pages. Though I do indeed see the image on w:Main Page, as you can see for yourself Special:GlobalUsage/Hanging 30? (8017221899).jpg and w:Special:WhatLinksHere/Hanging 30? (8017221899).jpg no longer shows it being used on Main Page. –Krinkle^talk 02:56, 1 August 2013 (UTC)[reply]

I purged the main page and now the image is showing up again in GlobalUsage and WhatLinksHere for that page. –Krinkle^talk 03:10, 1 August 2013 (UTC)[reply]

Can you revert the Block message to revision by Juliancolton ( 17:49, 11 March 2010‎) please. 96.5.241.8 15:51, 29 October 2013 (UTC)[reply]

No, not without a reason. Please continue at MediaWiki talk:Blockedtext#Revert the block text.. –Krinkle^talk 18:32, 29 October 2013 (UTC)[reply]

Hallo Krinkle, Dein KrinkleBot trägt dort nichts mehr ein. Ebenso auf den anderen Seiten der Category:Lists of files in use on highly visible Wikipedia pages. Schau mal ob Du das fixen kannst, Danke. Gruß --Knochen ﱢﻝﱢ‎  11:38, 13 November 2013 (UTC)[reply]

Vielen Dank, dies wurde behoben. –Krinkle^talk 23:06, 14 November 2013 (UTC)[reply]

Hello. I would like to inform you that I have granted you editor flag at the Arabic Wikipedia, all your edits there will be automatically marked as patrolled. Best regards.--Avocato (talk) 13:59, 6 December 2013 (UTC)[reply]

Thanks! –Krinkle^talk 17:37, 6 December 2013 (UTC)[reply]

I would like your bot to protect images in use on wikt:en:Main Page at Commons:Auto-protected files/wiktionary/en. CourtlyHades296 (talk) 18:51, 23 December 2013 (UTC)[reply]

 Done, code change. I've deployed it on Toolserver, should be included automatically picked up in the next run. Thanks! –Krinkle^talk 23:32, 23 December 2013 (UTC)[reply]

Commons:Auto-protected files/wiktionary/en is set up now (including protection). –Krinkle^talk 23:51, 23 December 2013 (UTC)[reply]

	The Barnstar of Diligence
	Thank you very much for developing RTRC in reducing the patrolling workload of mine! Credits goes to you! I look forward to your future creations. Jianhui67 talk★contribs 10:26, 6 January 2014 (UTC)[reply]