User talk:Equazcion: Difference between revisions

Archives

Index Archive 1 Archive 2 Archive 3 Archive 4 Archive 5 Archive 6 Archive 7 Archive 8

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)

		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)

(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)

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)

	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)

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)

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]