User talk:Equazcion

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Equazcion (talk | contribs) at 21:47, 3 December 2014 (→‎Scripts: re). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

Follow-up

Hi Equazcion, while I opposed Wikipedia:Requests for comment/Template editor user right, congratulations for your hard work in making the proposal a success; I think you did a great job. In addition, as an admin who has handled masses of permissions requests in the past, I would like to state that I am more than happy to help in handing out this userright to editors who need it. Best. Acalamari 10:26, 17 October 2013 (UTC)[reply]

Thanks, it's been a trip, and I'm pleasantly astounded that it's actually happening. I see you've already granted it to a couple of people -- thanks for helping out there. :) equazcion 11:04, 17 Oct 2013 (UTC)

Nice work

The Teamwork Barnstar
Jianhui67,Equazcion, PinkAmpersand impressive work pulling together Wikipedia:Template editors in very short order SPhilbrick(Talk) 16:54, 17 October 2013 (UTC)[reply]
Thanks :) I've been doing my share between there, WP:PERM, and elsewhere, but Pink deserves most of the credit for getting the bulk of the content up at that particular page :) equazcion 17:13, 17 Oct 2013 (UTC)

On the subject of regex

(I was looking at User:Equazcion/OneClickArchiver.js) By the way, it's generally preferable to use regex literals (var exp = /xyz/;) as opposed to constructors (var exp = new RegExp('xyz');) unless you're dealing with a expression that needs to be dynamically generated. From Stack Overflow [1],

Especially the escaping makes expression a bit more difficult to write if you want to use RegExp [constructor]. It is actually only needed if you want to create expression dynamically, that is, if you want to include text stored in a variable for example. If you have a fixed expression, a literal /.../ is easier to write and more concise.

Additionally, literals are in most simple cases much faster. Hope this helps (and here are the MDN docs, which I generally find very helpful), Theopolisme (talk) 23:25, 20 October 2013 (UTC)[reply]

Thanks for the tips -- I've generally used literals in the past, but didn't know they were faster -- I actually just started using "new RegExp" recently because txt2re.com uses it :) I have a nominal grasp of regex and debugging it can sometimes cause areas of my brain to liquify and leak out my ear. I'll likely be lazy about trying to "convert" something that already works back into literals, but I'll keep this in mind and just start with those in the future. Thanks again, I appreciate you checking out the code :) equazcion 02:50, 21 Oct 2013 (UTC)

Weird topicon I found

Hey Equazcion, I see the topicon on Template:Top_icon has a bunch of text in it along with the pink lock, the text is [[File:{{{imagename}}}|15px||{{{description}}}]]. Do you know what's up with this or how to fix it? —  dainomite   20:37, 28 October 2013 (UTC)[reply]

(talk page stalker) That's actually more-or-less working as intended: it's the actual code of the top icon template, or more accurately the result of rendering the template's code. Since you're viewing the template directly, its parameters (imagename, description) haven't been given any values, so it spits out that text instead. As for fixing it, I think wrapping the template's code in <includeonly>...</includeonly> would prevent it from getting displayed, but Equazcion probably knows better than I. Writ Keeper  20:43, 28 October 2013 (UTC)[reply]
Ohhhh, interesting! How strange. Thanks Writ Keeper. —  dainomite   20:51, 28 October 2013 (UTC)[reply]
Writ Keeper is correct. The top_icon template is meant to produce a graphic in the same location where the lock shows up (I think the locks themselves might even use the top_icon template). So what you're seeing there, instead of an additional icon next to the lock, is the part the template's source code that normally is replaced with an image. Since it's a just a parameter-less template, there's no chosen graphic, and the code displays. It can indeed be fixed with some noinclude magic. equazcion 22:41, 28 Oct 2013 (UTC)
Added the includeonly's to fix that. equazcion 03:10, 30 Oct 2013 (UTC)

A barnstar for you!

The Brilliant Idea Barnstar
For your great work in simplifying and solving out the issues with the EotW Hall of Fame. Thanks for simplifing that huge mess! TheOriginalSoni (talk) 01:58, 4 November 2013 (UTC)[reply]
Your welcome, and thanks :) equazcion 06:01, 4 Nov 2013 (UTC)

Isn't it basically a dupe of {{js}} but not protected (which I fixed!)? Legoktm (talk) 00:41, 6 November 2013 (UTC)[reply]

It seems to be about the same, but with one important difference: I didn't know it existed. :)
Although in seriousness, even though they do the same thing in effect, I'm not sure what the benefit is to it inserting the full mw.loader line, as it just points statically to en-wiki anyway. Maybe it was written before the importScript function was available? I guess the two should be merged, unless there are situations I'm unaware of where using mw.loader is necessary for installing en-wiki scripts on en-wiki. equazcion 02:06, 6 Nov 2013 (UTC)
I wrote about that on {{js}}'s talk page. --V111P (talk) 21:57, 10 November 2013 (UTC)[reply]

Equazcion, your installation templates and scripts are nice, but...

1.Some scripts are only useful while source-editing articles, others only on article pages, etc. I believe users' common.js should load only the script files needed based on the type of page the user is looking at. So for example I use:

if ( $.inArray( mw.config.get( 'wgAction' ), ['edit', 'submit'] ) !== -1 ) {
    // import scripts for editing
}
else {
    // import scripts for wgAction == 'view'
}

Your {{InstallUserScript}} and the {{js}} template could be made to add an if-statement before the importScript(), but I realize that won't be pretty. What do you think?

2.{{userscript}}'s noautoinstall=yes param. Although it may be disabling your script installer, the text that users see in the footnote is still the same "Copy this in your common.js". If the script is not supposed to be installed automatically because more than a simple importScript() is needed, then it doesn't make sense the footnote to tell users to subst a template in their common.js that does only that. So it seems in those cases the {{userscript}} template just shouldn't be used at all, or it should be modified not to create a footnote, or the footnote should say something else.

--V111P (talk) 21:57, 10 November 2013 (UTC)[reply]

Your second point seems valid. It probably does makes sense to disable the ref when noautoinstall is specified. I'll look into doing that.
Regarding your first point, what you're suggesting is probably both ideal for performance, and possible, but would make the whole thing less reliable and automatic. There would be added complications and continued maintenance: We'd need to maintain additional data on which scripts need to load in which situations, and if there isn't someone around continually checking to make sure that information is accurate for all scripts, it'll start failing down the line. The current script/template can be used forever with no intervention, barring some unforeseen changes to MediaWiki.
It also seems like overstepping the intent of the script, and would make common.js more complicated for non-technical people to look at. I'm not looking to improve performance (a backend change seems more apt for that), but rather to simplify implementation of the current practices, reliably, so that they're less intimidating for general users. equazcion 22:27, 10 Nov 2013 (UTC)
OK. --V111P (talk) 01:21, 11 November 2013 (UTC)[reply]
But PS. If you want to take on writing an installation script that does what you suggest, and you're willing to maintain the required data, you should feel free. I'm certainly not stopping you :) equazcion 01:25, 11 Nov 2013 (UTC)

Now what?

OK, I've installed your gizmo. On Passage du milieu, I'm getting a full page width box with the translation of the language name in it. Everywhere else, the list appears in the side bar, looks around, doesn't like what it sees, rolls itself up, and disappears... Monobook, en-gb, Firefox 20, XP Pro (classic view) Peridon (talk) 18:27, 11 November 2013 (UTC)[reply]

Thanks for letting me know -- I'm gonna see if I can reproduce this error and report back. equazcion 18:37, 11 Nov 2013 (UTC)
Peridon, this should be fixed now. Thanks for the heads up, cause this bug was messing up in monobook altogether :) equazcion 18:58, 11 Nov 2013 (UTC)
PS. You may need to bypass your cache and/or restart your browser to see the fix, as this was a CSS change. equazcion 18:59, 11 Nov 2013 (UTC)
That's better. Great stuff. I keep wondering about learning how to do this sort of thing. I used to program COBOL (and create .COM and .BAT files), and these things now are so much shorter and more powerful. I created a password handling prog in COBOL once, and I hate to think how many pages of coding it took. Peridon (talk) 19:11, 11 November 2013 (UTC)[reply]
On the one hand, you should learn it, because it's so insanely easy and insanely useful. On the other hand, it's also pretty addictive. I can't even remember where I put my cat. equazcion 19:17, 11 Nov 2013 (UTC)

Arbitration request for clarification

The Arbitration Committee is considering a request for clarification which involves you.[2] Please act accordingly.—John Cline (talk) 10:42, 12 November 2013 (UTC)[reply]

A barnstar for you!

The Special Barnstar
Thanks for making the Arbitration Committee Chart readable,

Least we won't need binoculars to read it this year! :)
Anyway Thanks,
Regards -→Davey2010→→Talk to me!→ 01:15, 14 November 2013 (UTC)[reply]

Glad I could help, and thanks :) equazcion 08:30, 14 Nov 2013 (UTC)
You're welcome :) -→Davey2010→→Talk to me!→ 14:49, 14 November 2013 (UTC)[reply]

Adminship

Hi Equazcion. :) Would you be interested in running for adminship? Your blocks seem far enough in the past, and your content work seems good enough, and we need more JavaScript coders with the bit. And as well as your excellent coding work, you have shown yourself to have a very good understanding of how to reach consensus with your work on the template editor user right. I think now would be a good time for you to run, so how about it? I'll write you up a nice nomination statement if you accept. Best — Mr. Stradivarius ♪ talk ♪ 05:04, 15 November 2013 (UTC)[reply]

I'm honored that you'd suggest this, but I'm not really interested in being an admin. Frankly you couldn't pay me enough. Well, that's probably not true. I certainly wouldn't do it for free though, and I'd need a substantial bonus for voluntarily putting myself through one of those runs for public office and kissing enough ass to actually win it. :) It puzzles me a little bit that anyone wants to be an admin, but that's an essay for another time. Practically speaking, there isn't really any admin duty I feel I could contribute substantially to anyway, other than perhaps the ability to edit others' JS pages being useful once in a while. So thank you, but I have to decline, even though I do appreciate the offer and the accompanying ego stroke :) equazcion 05:45, 15 Nov 2013 (UTC)
The ability for you to edit others' JS pages would come in very handy around now, what with everyone's scripts breaking because of the removal of those deprecated functions. And how about answering protected edit requests? We often get requests for JS pages in the MediaWiki namespace, and we don't have any JS coders on the CAT:EP "team" right now. We could certainly do with your help there. I don't think you need to be super-active in admin duties to make having the admin tools worthwhile; even if you make only a few admin actions every now and again, your having the admin tools is still a benefit to the project. And being an admin doesn't mean that you have to change your editing patterns (and neither would I want you to). It just means that you have a few extra buttons that mean you can help out once in a while if you see a need for it. Honestly, I don't think you would have any problem at all passing RfA; I know answering the questions might be a bit of a pain, but as long as you don't ignore the RfA page entirely I think that you would be a shoo-in. Are you sure that you aren't willing to give it a try? — Mr. Stradivarius ♪ talk ♪ 07:47, 15 November 2013 (UTC)[reply]
I've made more enemies here than you might be aware of, as my demeanor has been far from one crafted with political ambitions in mind. But anyway yeah I'm quite sure that adminship is not for me. Sorry to disappoint, but thanks again anyway :) equazcion 08:20, 15 Nov 2013 (UTC)

Gadget idea

I literally just had an idea pop into my head for a gadget, and it seems right up your alley. Since I don't know how to program such a thing, I thought I'd put it here and see if it strikes you as something worth pursuing. Quite simply, it's an interwiki sidebar for your watchlist page. Since the mediawiki software doesn't allow for cross-wiki watchlists, the least we could do is provide the links for navigating. The gadget would need to get a list of which projects a user's unified login has an account with, and display a link to Special:Watchlist at each one. Obviously, the trick is getting the unified login information, but if toolserver tools can do it, we should be able to manage. VanIsaacWS Vexcontribs 15:06, 19 November 2013 (UTC)[reply]

Seems this offers a list of all wikis a user ever logged into using their global account, though ideally you'd want to limit it to wikis where the user has at least one page watched. The script could retrieve the watchlists for one but that'd be kinda inefficient -- If I come across a page that offers such a list it shouldn't be too difficult to make the script you're suggesting. equazcion 18:46, 19 Nov 2013 (UTC)
  • (talk page stalker) I'm not sure why mw:API:Watchlist feed or mw:API:Watchlist or mw:API:Watchlistraw can't be used to make an all-in-one watchlist. It pulls the watchlist information for the current user, and it doesn't seem to care which wiki you are on. The only time it would be an issue would be if you were trying to get someone else's watchlist, but you're not (although it could be configured with a way to get the watchlists of any sockpuppets you have by customizing your wl token and setting it, but that may be for another script). Technical 13 (talk) 19:38, 19 November 2013 (UTC)[reply]
Looks like they could theoretically do it. I'm not sure how fast it would be be with all the individual API calls, and again I'm not seeing any way to list only the wikis where you actually have a watchlist, so I think it would mean an API call for every wiki you've ever logged into on each load. equazcion 20:09, 19 Nov 2013 (UTC)
...although thinking non-gadget now, it could utilize a list of wikis the user wants to check, entered manually as variables. equazcion 20:15, 19 Nov 2013 (UTC)
Would have to run through a first cycle asking each wiki logged into if the user is watching any pages on that wiki and build a list or an array of wikis where the number of pages watched > 0. Then you would have to cycle through each wiki to pull the changes to the pages watched into the array. Once all of the changes are pulled into the array from all wikis (including current one), then the array could be sorted by time and displayed on the screen. Depending on how many wikis and how many pages are on each, could take a minute or two. Those people with large lists on all wikis would just have to accept the lag. Also, if there is a way to pull the number of changes to each list in the first cycle check for pages on watchlist and sort them by least changes first, it should be slightly more accurate in most cases. Technical 13 (talk) 20:29, 19 November 2013 (UTC)[reply]
I'm not really so concerned with the other workings, but pulling in all the possible changes using the API is the issue. You're suggesting a saved cache - it would need to update periodically, I think, rather than run once. I guess it would be saved on the wiki where the script is installed, updated something like once a day, with a link to update it manually. Thinking out loud. Gah. It seems unnatural. I'm not big on complex applications via script; they tend to be the most susceptible to breaking down over time. It seems almost trivial to do this on the back-end at Wikimedia, in comparison to this. equazcion 20:42, 19 Nov 2013 (UTC)
I don't know for sure, but I would think that in order to grab all the interwiki watchlist data, you'd have to be logged in to every project, since watchlist tokens are not public, and they differ across wikis. You couldn't just login to en.wiki and have any other work at that time. Since it's a Perennial proposal, it's obviously a technical swamp. But your username is available to a script, and that can be checked in some way, since toolserver tools use it, so that seems like the route to me. Plus, it has the advantage of looking exactly like other pages on wikipedia, with interlanguage links just tucked over to the left.
Using universal login as WP now does, logging into one wiki logs you in to all of them (or at least that is how it is suppose to work). Technical 13 (talk) 22:38, 19 November 2013 (UTC)[reply]
I was about to say the same -- I tested some API calls and I believe making an API call to another wiki automatically logs you in via the global account, the same way navigating to another wiki using a browser does. equazcion 22:40, 19 Nov 2013 (UTC)
Hmm, I still end up having to sign in to some projects individually, like commons. I'm wondering if the universal login just works across a single project space - eg I sign in to en.wiki, and it automatically signs me in to la.wiki, but not wikiquote or commons? VanIsaacWS Vexcontribs 23:13, 19 November 2013 (UTC)[reply]
I was playing with this idea a while back and never finished it. [3]. Legoktm (talk) 16:56, 3 December 2013 (UTC)[reply]

Time for the next RfC for TE?

Hey there Equazcion! Do you think enough time has passed since TE was created to ask if the community thinks expansion to include MediaWiki: might be appropriate? It uses exactly the same skill-set as template and modules, and if there are any specific MediaWiki pages people are concerned about (such as possibly MediaWiki:Common.js), they can still be full protected. I personally have 9 or 10 MediaWiki: edit requests that have been filled and I'm sure many other TEs have as well. What do you think? Technical 13 (talk) 02:57, 23 November 2013 (UTC)[reply]

Tough one. My gut tells me it has a good chance of failing as there isn't as much apparent need for it, as far as Ive seen, but I could be wrong. I'm also not really prepared to head up another one of those. If you got someone else to get something started I'd offer my input though. Thinking out loud, templates like reflist, infobox, naxvbox, !, •, etc are now also essentially interface elements that affect everyone the way MediaWiki pages do, so that could be one possible hook. But again, I'm predicting a lot of "solution in search of a problem" votes, unless there's enough credible testimony that this a need that's comparably dire to that of the original template editor user right. equazcion 07:53, 23 Nov 2013 (UTC)
Access to the MediaWiki namespace allows you to inject raw HTML onto the site, among other things. If you can't pass RfA, I don't think people will trust you to do that. Legoktm (talk) 08:30, 23 November 2013 (UTC)[reply]
The template editor right has very little to do with not being able to pass RFA. But I didn't know MediaWiki pages allowed all HTML -- that does make them significantly different from template editing. equazcion 08:40, 23 Nov 2013 (UTC)
MediaWiki: pages are somewhat finicky, some of them allow no formating, some allow wikitext, others allow raw HTML, and some can even contain JavaScript or CSS. The point is that like other templates and modules, it requires a level of technical knowledge, and I don't see administrators having any more knowledge (some even declare they have much less) than template editors in this area. If you guys think it is still too soon and there isn't enough data/requests to support it, then it can sit on a back-burner a little longer. Technical 13 (talk) 15:46, 23 November 2013 (UTC)[reply]

Me, again

Hi, Equazcion ... I'm baaaack :) It happened again, at Talk:Osteoarthritis. This time I was certain to have only one tab open, and to go slow. Nonetheless, it archived one section three times instead of three different sections once (that is, same problem as before). Sorry to be a pest, but I love the tool and thought you'd want to know. SandyGeorgia (Talk) 23:48, 2 December 2013 (UTC)[reply]

Again;[4] I carefully waited, and made sure I had only one tab open. It grabbed the same section twice. Best, SandyGeorgia (Talk) 16:36, 3 December 2013 (UTC)[reply]
The problem is easier to see here due to the new archive you set up in the middle. It looks like the script not only somehow pulled content that no longer existed, but despite your setting the archive template to point to Archive 2 [5], the script still pulled the older version of the page that had Archive 1 set [6] -- until you tried again a couple minutes later [7]. Seems to be the same caching issue. I'll need to look into bypassing the cache for these API calls. equazcion 07:16, 4 Dec 2013 (UTC)
I have a new diagnostic clue (I don't know what it means, but you may). I just archived one thread from my talk to the new monthly archive98.[8] It is now 12 minutes later, and the archive link on my talk page still shows red, even after a refresh, a hard refresh, and logging out and back in of Wikipedia. So, my talk page is not refreshing ?? SandyGeorgia (Talk) 15:48, 6 December 2013 (UTC)[reply]
Now half an hour later, I've restarted my computer, re-logged in to Wikipedia, and the link to archive98 from my talk page is still showing red although it has content. SandyGeorgia (Talk) 16:07, 6 December 2013 (UTC)[reply]

Draft

Do you know if there is an ETA on the draft namespace yet? If not I might consider escalating this request beyond the WMF team that appears to be delaying it. Kudpung กุดผึ้ง (talk) 01:49, 4 December 2013 (UTC)[reply]

This (28 Nov 2013) was, near as I can tell, the very last thing that happened as far as the draft namespace is concerned. That link depicts a comment I made blasting the handling of this implementation by the WMF's product manager, Steven Walling. I can only speculate as to that comment's possible role in the apparent lack of implementation activity since I posted it.
One could question the wisdom of posting such a thing, but I felt it was something that needed to be said; and the WMF would be in even more dire straits than I'd thought, if someone feeling insulted could actually halt the implementation of a community consensus. This is again just speculation. For all I know, the WMF developers are fully maintaining their professionalism and are moving ahead as appropriate, but I can't confirm either hypothesis. If you do know of a higher-up to contact, you have my support in doing so. equazcion 02:24, 4 Dec 2013 (UTC)
I have been closely following both Bugzilla threads. I think your comments were appropriate - but I wouldn't have risked my reputation or relations with the Foundation by saying it as I know Steven and his bosses personally ;)
I will email Maggie Dennis (Senior Community Advocate), and Philippe Beaudette (Director, Community Advocacy), whom I also both know personally. To save me searching, can you give me the links to the two Bugzilla reports. Kudpung กุดผึ้ง (talk) 04:06, 4 December 2013 (UTC)[reply]
I maintain a strict no-relations policy with everyone for that reason :)
equazcion 04:12, 4 Dec 2013 (UTC)
Difficult when one is as well known notorious as I am and involved in meet ups and conferences ;). Thanks for the links. I'll see what I can do. Kudpung กุดผึ้ง (talk) 05:02, 4 December 2013 (UTC)[reply]
I have now written to Maggie and Philippe. All we can do now is sit back and wait and I'm not sure through which channel(s) we will receive any feedback. Kudpung กุดผึ้ง (talk) 05:34, 4 December 2013 (UTC)[reply]
Hi to the both of you. Equazcion, this is the second time you've pinged my volunteer account about a work issue. I don't always check my personal notifications every day, but if you ping the work account I'm using in this thread, you'll always get a response within 24hrs unless I'm traveling, which is rare. The status is that yes, the Draft namespace will be implemented. It's been a couple weeks, but please be patient. Remember that, unlike a project like Flow or VisualEditor, article creation doesn't have a large team dedicated to it yet. The Growth team is small, and we also have other responsibilities (which is part of why I'm writing you this message at past 9 o'clock at night, still at the office). As I said on the bug, we'll try to wrap up agreement on the basic requirements shortly, and then we can work on launching the first version. From what's in Draft namespace I think you'll find that there is little unexpected in terms of what we've written for basic requirements? re: Maggie and Philippe's input: I'm not sure how much they know, if anything, about the project. Neither of them work directly on outreach for Growth engineering projects, so we'd have to get them up to speed. Steven Walling (WMF) • talk 05:46, 4 December 2013 (UTC)[reply]
As a quick example of why I asked for patience and to focus on making sure we know the exact criteria for saying Go/No go... Just today the code proposed for implementing the namespace was updated to make sure users who could not force indexing of a Draft by using the __INDEX__ magic word. Details like this are important to iron out so we know we're actually fulfilling even the basic requirements from the RFC, much less anything fancier. Steven Walling (WMF) • talk 05:53, 4 December 2013 (UTC)[reply]

"autism spectrum"

I don't care what you think of the task, but your comment here is completely unacceptable. Legoktm (talk) 01:37, 8 December 2013 (UTC)[reply]

People with autism like to put things in order, and might find that kind of data entry sort of hypnotically comfortable. Tasks most people find boring can be appealing to autistics. I've often thought I myself am a borderline case. I apologize if you saw my comment as making light of autism, but I had no such intention. equazcion 01:46, 8 Dec 2013 (UTC)

VP Visual Editor exchange

The exchange below was moved from Wikipedia:Village pump (technical)/Archive 121#VisualEditor template data filled by Google Code-in students? due to it stemming from my own erroneous interpretation of the original post. equazcion 07:23, 8 Dec 2013 (UTC)

Really? Data entry? That's what you had those kids doing? I'd be very surprised if anyone outside the autism spectrum would be considering sticking around after having that as their first significant "coding" (?) experience. equazcion 20:00, 7 Dec 2013 (UTC)
Your comment is wholly unacceptable. Legoktm (talk) 01:36, 8 December 2013 (UTC)[reply]
These are documentation tasks, not coding tasks. Check the link above, Google Code-in has other categories of tasks in addition to coding. Yes, I think some students will be interested by the fact that, by editing wiki pages with basic JSON syntax, they are giving shape to specialized user interfaces for Wikipedia editors. Anyway, if you have better ideas please share them. As said, we are looking for all kinds of technical tasks. PS: if you want to see what we had those kids doing, check the full list of Wikimedia GCI tasks.--Qgil (talk) 00:28, 8 December 2013 (UTC)[reply]
I don't see how that's documentation. It's data entry. Template parameters are already documented, but they need to be entered as arrays to make Visual Editor better. The reason no one here wants to do it is the same reason you probably shouldn't have had kids doing it -- it's boring, tedious, unchallenging grunt work that doesn't teach coding. It teaches a data markup syntax that usually is only seen in output, and practice entering it manually won't generally be of use to those interested in programming. Getting kids involved in some aspect of the actual MediaWiki PHP code (give them some of the simpler unresolved bugs, feature requests, or create new ones for them?) seems like it would more appropriately fulfill Google Code-in's goal of introducing them to open-source development. If no one wants them to be doing that stuff then it's pointless to participate in a program like Code-in in the first place. equazcion 01:33, 8 Dec 2013 (UTC)
Correction, I just checked this link you provided, and most of those seem much more on-target. On first read I thought this template parameter stuff was all there was, my mistake. Now I'm not really sure what the purpose of pointing out that one was, if you were just looking for new task ideas? ...but in any event, if this parameter stuff is still one of the tasks, I'd get rid of it. It's not programming or documentation. equazcion 01:40, 8 Dec 2013 (UTC)
We could be spending more time here discussing what Google Code-in students want and need. Instead, I'd rather let them decide with their feet. These students have hundreds of tasks to choose from. If they don't like these, they will choose other, if they don't like ours, they will go to another project. Can someone point me to templates welcoming VisualEditor template data, please? Thank you in advance. Equazcion and anybody else: your specific alternative proposals for GCI tasks are also welcome. We are creating dozens of new tasks every week. PS: the last GCI task completed is a rewrite of Template:Interval in Lua.--Qgil (talk) 06:20, 8 December 2013 (UTC)[reply]

New RFC on Article Incubator - Follow up to Draftspace RFC

Hi,

I have drafted a new RFC on the article incubator at User:TheOriginalSoni/sandbox3. I plan to be removing the nowikis and starting the RFC at the VPP soon (ideally in a couple of days). Could you please look through it, and make any changes as you see fit? I do not want this RFC to go through any hiccups like the last one did.

Thanks and cheers, TheOriginalSoni (talk) 05:58, 23 December 2013 (UTC)[reply]

Re: Gallery template issue

Hi there. Was just wondering if you have any updates after this? Best regards, Rehman 10:53, 12 January 2014 (UTC)[reply]

(was pinged...) hi. actually, the "interactive pgn viewer" does not need this help, but you might be interested, to look at an alternative gallery slideshow script - the one used on hewiki. you can see a demo in the help page of the template: the template itself is he:Tempalate:מצגת, and the help page with the demo is in he:Help:מצגת תמונות. note that because hebrew is rtl language, "play", "next" and "last" buttons point left, and "prev" and "first" buttons point right. this, of course, can be easily changed for ltr language like english. the template and script were developed by User:קובי כרמל ( = "Kobi Carmel"). you can find the script in he:Mediawiki:SlideShow.js, with accompanying css page at he:Mediawiki:SlideShow.css. It supports rich set of options (e.g., different "effects" for replacing the images, control of the timing, etc.).
I hope Koby will be willing to help you translate the template and the script, even if just for demonstration/testing/discussion purposes. peace - קיפודנחש (aka kipod) (talk) 16:05, 12 January 2014 (UTC)[reply]

Notification of automated file description generation

Your upload of File:Blue plus icon.png or contribution to its description is noted, and thanks (even if belatedly) for your contribution. In order to help make better use of the media, an attempt has been made by an automated process to identify and add certain information to the media's description page.

This notification is placed on your talk page because a bot has identified you either as the uploader of the file, or as a contributor to its metadata. It would be appreciated if you could carefully review the information the bot added. To opt out of these notifications, please follow the instructions here. Thanks! Message delivered by Theo's Little Bot (opt-out) 13:47, 13 February 2014 (UTC)[reply]

OneClickArchiver

Hello. First of all, thank you for writing such a fantastic script. I noticed a tiny spelling error, or at least I think its an erro. When you click on "Archive" and the dialogue box comes up, it says "retreiving section content", the "i" and "e" should be the other way round. Green Giant (edits) (talk) 20:24, 17 February 2014 (UTC)[reply]

That i-before-e thing always gets me. Yup it was a typo. I got it right in the other two instances, so I clearly knew the correct spelling, and am still smart. :) Corrected now, thanks for letting me know. I don't spend much time here lately hence the lateness of my response. equazcion 11:42, 26 Mar 2014 (UTC)

I just fixed an error in one of my tools. You are using the same function. Simply remove the .autoEllipsis() to make your script work again. This JavaScript function got replaced with CSS. --TMg 16:30, 10 May 2014 (UTC)[reply]

One click / mobile

Thanks for the one click archiver. It's awesome when the bots go down. Is there a way to disable it when using a mobile device? Thanks. NE Ent 23:50, 26 May 2014 (UTC)[reply]

  • (talk page stalker) NE Ent, if you want it to be just for a specific device, I'll need to know your userAgent string for that mobile device. If you want it to not run on anything with a small screen, I'll need to know your screen resolution for that mobile device (to make sure that the limit will be effective on that device). Thanks! — {{U|Technical 13}} (etc) 17:51, 2 December 2014 (UTC)[reply]

Precious again

writers strike
Thank you, drummer with a personal edition, for drumming up vigility, editors' pride, global consensus, objection to ownership, for letting me think about a writers strike, - great "retirement", you are an awesome Wikipedian!

--Gerda Arendt (talk) 07:41, 27 August 2013 (UTC)[reply]

A year ago, you were the 587th recipient of my PumpkinSky Prize, --Gerda Arendt (talk) 13:06, 27 August 2014 (UTC)[reply]

Your script ContribsTabVector.js on different lang mutation of wikipedia

Hi, I copied ContribsTabVector.js into my vector.js at cs.wiki, but it contribs and statistics of my en.wiki account. I managed to translate the tab labels to Czech, but I dont know how to make it to show statistics and contributions from cs.wiki... I thought that '&uselang=' + wgPageContentLanguage; and 'http://' + wgPageContentLanguage would tell the script what language mutation wiki they are at, but they dont.? Could you advice me on how to fix it? If it is a quick and easy fix, feel free to edit my vector.js page. Your help is appreciated, thank you. --Wesalius (talk) 06:06, 2 September 2014 (UTC)[reply]

IMDb

Just out of curiosity, are you by any chance the same equazcion on IMDb whose reviews I enjoy reading so much? --85.197.13.58 (talk) 06:43, 16 October 2014 (UTC)[reply]

A barnstar for you!

The Technical Barnstar
Thanks for all your great scripts. ScriptInstaller makes script installation much easier (almost all the scripts I have were installed using your tool, bar ScriptInstaller itself), and OneClickArchive is a very efficient way to manage talk pages. Keep up the great work! Biblioworm 18:24, 21 October 2014 (UTC)[reply]

Scripts

Hi. I decided to try your archiver script. Thanks. To avoid a security threat I have protected it. If you are an admin you can still edit it. If not we should make you an admin. Otherwise let me know if you need it unprotected. Jehochman Talk 08:19, 23 October 2014 (UTC)[reply]

  • (talk page stalker) Jehochman, why protect a page that only the user and admins can edit so only admins can edit it? That makes NO sense to me. I suggest unprotecting it as the only thing that protection is doing is preventing the maintainer of the script from maintaining it. Then, if Equazcion doesn't reply to my request below in a few days, would you be willing to take a look at it and make the changes please? Thanks. — {{U|Technical 13}} (etc) 18:10, 2 December 2014 (UTC)[reply]
    • Okay, I've done that. Sorry for my density in not realizing that these files are only editable by the author or an admin. Jehochman Talk 21:45, 3 December 2014 (UTC)[reply]
      • As programmers we may have unduly assumed all the admins were aware of how this works. Thanks for correcting it Jechochman :) equazcion 21:47, 3 Dec 2014 (UTC)

OneClickArchiver

Hey! Based on the need for this script on WP:ANRFC and the discussion in which it was discussed, I've sandboxed a working upgrade to your script that allows for it to be used on all talk pages and non-talk pages that are automatically signed (which should cover all of the noticeboards) and I've added the functionality to look for ClueBot III (talk · contribs)'s |headerlevel= parameter so it will work on level 3 headings (like what is used on WP:ANRFC). If you could take a look over my modifications on User:Technical 13/SandBox/OneClickArchiver.js and incorporate them into your script, there are a few people at least that would appreciate that. :) Thanks! — {{U|Technical 13}} (etc) 17:43, 2 December 2014 (UTC)[reply]

You've got mail from Technical 13!

Hello, Equazcion. Please check your email; you've got mail! The subject is You okay?.
Message added 18:15, 2 December 2014 (UTC). It may take a few minutes from the time the email is sent for it to show up in your inbox. You can remove this notice at any time by removing the {{You've got mail}} or {{ygm}} template.

{{U|Technical 13}} (etc) 18:15, 2 December 2014 (UTC)[reply]

Mail was returned to me undeliverable — {{U|Technical 13}} (etc) 18:22, 2 December 2014 (UTC)[reply]
I see you've been away a little over a month now, and I'm wondering how you are. I've commented on a few discussions on your talk page for you and have resolved a few of the questions asked, but I also have a request of my own that can only be resolved by you or an admin.  If you have a moment, please look it over and see what you can do.  I'd be happy to do any specific testing you want to make sure that none of the changes I made break anything (and I think I've already done most all of the test, although I didn't save them all).  Thanks! ~~~~ (yes, I know signatures don't work in emails)

--
This email was sent by user "Technical 13" on the English Wikipedia to user "Equazcion". It has been automatically delivered and the Wikimedia Foundation cannot be held responsible for its contents.

The sender has not been given the recipient's email address, nor any information about his/her email account; and the recipient has no obligation to reply to this email or take any other action that might disclose his/her identity. If you respond, the sender will know your email address. For further information on privacy, security, and replying, as well as abuse and removal from emailing, see <http://en.wikipedia.org/wiki/Wikipedia:Email>.