This is an archive of past discussions about MediaWiki:Gadgets-definition. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.
User:Cacycle/wikEdDiff.js wikiEdDiff (an additional diff mode that sometimes makes it easier to spot small diffs in my experience
Also, I was wondering. is it possible to set the default value of these gadgets ? I imagine some people might like to deactivate wikiminiatlas for instance ? just an idea. --TheDJ (talk • contribs) 19:40, 7 December 2007 (UTC)
I'm not familiar with HotCat, someone needs to port it to en.wp first. I'm against other scripts for various reasons, and I suggest we develop some kind of procedure and then discuss the scripts one by one, not a bunch at the same time. Note that similar discussions also takes place at Wikipedia_talk:WikiProject_User_scripts/Gadgets ∴ AlexSm20:33, 7 December 2007 (UTC)
I noticed popups were added as a test. If scripts like this are added, how does somebody customize the script's configuration? For example, I've configured popups in my monobook to add the disambiguation and admin features. Would the scripts added here be customizable somehow or are you stuck with the basic configuration if you enable it through preferences? - auburnpilottalk02:45, 4 December 2007 (UTC)
It is possible to write the script in such a way that it's customisable via monobook.js. I'm not sure if the version of popups added to the gadgets list is customisable like this or not. You might want to keep your popups configuration in your monobook.js, but comment out the inclusion of popups itself, installing through preferences instead, and seeing if it worked; it would be useful to know if popups-via-preferences is customisable in its current form or whether it needs changing. --ais523 08:36, 4 December 2007 (UTC)
I removed popups from my monobook.js, leaving the customizations, and enabled them via preferences. I was still able to use the disambiguation and admin settings, so I assume you can in fact customize these gadgets through the monobook.js. Thanks for the idea, Ais523; worked well. - auburnpilottalk13:03, 4 December 2007 (UTC)
(restore question self removed as the answer edit conflicted my removal)Standards questions, should we pipe Gadgets in to user: space, or bring them in to MediaWiki somewhere? — xaosfluxTalk04:46, 6 December 2007 (UTC)
My advice would be to establish a "stable" version in MediaWikispace and use that one as the gadget. The one in userspace should be for development purposes only, and the MediaWiki version should only be updated once changes to the userspace version have been tested and validated. As far as security goes, however, there's likely not much harm in leaving them in (an administrator's) userspace; it's more an issue of semantics. AmiDaniel (talk) 04:54, 6 December 2007 (UTC)
This has been proposed twice: 1, 2. If anyone wants to improve the script for performance/style/general usefulness, please do so. GracenotesT§21:03, 8 December 2007 (UTC)
It works in Firefox, IE, and Opera (I don't have Safari). If a browser does not support tabbed browsing, the link will open in a new window. If the browser does support tabs, the link will open either in a new window or a new tab, depending on the user's browser preferences. GracenotesT§22:38, 9 December 2007 (UTC)
I feel like only very few people would use this script. You could count my opinion as weak oppose, because at some point the list of gadgets is going to be way too long. As for suggestions, you could use document.getElementById('content').getElementsByTagName('a') to exclude all the portlet links and speed the script up a little ∴ AlexSm00:28, 10 December 2007 (UTC)
This is almost a perennial proposal, so having it as a preference makes sense. A long 'Gadgets' list is not a bad thing, in my opinion. --ais523 09:30, 10 December 2007 (UTC)
Agreed about having a long list of Gadgets; while I don't want to have five hundred or so to sort through, having a wide variety wouldn't be bad at all. EVula// talk // ☯ //09:43, 10 December 2007 (UTC)
Well, we do need to get to that point, no? I thought that the option being proposed on two different instances and supported by several people would be merit enough to include it. I only proposed it here because someone prompted me to. GracenotesT§00:46, 10 December 2007 (UTC)
Under Safari (my browser, which supports tabbed browsing, and on Mac OS X), enabling this gadget opens external links in a new window. I figure that that is useful information, as it was the only one to be tested. Nihiltres{t.l}03:28, 10 December 2007 (UTC)
It opens in a new window under Firefox 2 (running on Ubuntu Linux). Firefox's settings can be changed so that it opens in a new tab, though, because there is a preference on Firefox to override 'new window' with 'new tab' everywhere. --ais523 12:55, 14 December 2007 (UTC)
Browser specific?
How do we handle browser specific tools? My tools would be very useful here, but I have no desire to waste time on making them IE compatible, especially since we don't use any real cross-browser libraries. Zocky | picture popups13:09, 12 December 2007 (UTC)
Per discussion on #mediawiki-scripts@freenode, I've been pondering a cookie-based preference system that could work with gadgets, and in fact all user scripts. Of course, some people have cookies disabled or use multiple browsers or machines, so a good fallback would be some sort of global variables in their user/skin.js.
Can we please have gadgets that work for everyone, and not just for users who happen to have QueryString already installed in their monobook.js? ∴ AlexSm00:06, 12 January 2008 (UTC)
The rights log is pretty spammy now due to rollback. Per request, I've created a pretty useable interactive filter script for the user rights log at User:Splarka/lifilter.js (Note: Now expanded to work in all logs li-lists). The features include:
Creates the button to generate the form on Special:Log/rights or type=rights (the form can also be auto-generated on page load via var AutoLoadLogsFilter=true; in your user scripts).
Choose to match only (for log=rights only):
Log entries that added this right, eg "sysop" in "(none) to sysop"
Log entries that removed this right, eg "rollbacker" in "rollbacker to (none)"
Log entries that added or removed this right
Log entries that mention this right, eg "sysop" in "sysop, rollbacker to sysop"
Regex string search for the match chosen above, eg "sysop" or "(sysop|checkuser)". In the rights log, the string regexly searched is a space-delimited list of the rights (not comma separated). In all other logs, it will search the entire string's plain text representation (minus XML markup, but leaving in invisible unicode).
[hilight] will hilight the log entries that match the above critera.
[filter] will hide the log entries that do not match the above critera.
Invert will reverse the match behavior of [filter] and [hilight]
So for example, if you do not care about "rollbacker" changes, you can choose "Added or Removed", put in "rollbacker", select "[x] invert", and click "[filter]". It will then hide any entries where the "rollbacker" right was added or removed (but will show lines where it was not changed, eg "rollbacker to rollbacker, sysop").
Can I get some tests in IE6/7 and Opera, and if it behaves, can it be added to the available gadgets? Streamlining/fixes/comments cheerfully tolerated (heh heh). --Splarka (rant) 01:33, 12 January 2008 (UTC)
Opera 9.2 is fine, I'll be able to check it in IE6 when you remove semicolon from style.display = 'none;'. Also I think the script could apply regex filter to other types of log as well ∴ AlexSm02:42, 12 January 2008 (UTC)
Damn IE. Done. And yes, it probably could be adapted to a general log filter, but right now it is somewhat custom-made for user rights (in english) due to the sloppy way in which the log displays them (that is, it specifically only searches for the rights). Also: The API could possibly be utilized to display them much cleaner. --Splarka (rant) 02:52, 12 January 2008 (UTC)
Okay, expanded it for all logs, please test the new version. Note that if you are not on Log/rights, you'll be searching the entire line as if it were a plaintext string (no XML markup) and there is no "added/removed" as that only pertains to rights. --Splarka (rant) 04:51, 12 January 2008 (UTC)
I think it should be Wikipedia:Gadgets since it's project-specific, and I also suggest that we organize gadjets descriptions, for example as Wikipedia:Gadgets subpages. At least this should be better than current e.g. Wikipedia:Tools/Disable access keys. As for #3, maybe «Wikipedia:Gadgets proposals», or another subpage «Wikipedia:Gadgets/Proposals» ? I could suggest some gadgets but I'm still waiting for a stable "Proposals" page ∴ AlexSm18:22, 14 December 2007 (UTC)
Would there by any opposition to my reorganizing this page and adding a few more section headers? It's getting harder and harder to find individual gadgets because of how many there are. –Drilnoth (T • C • L) 02:58, 2 July 2009 (UTC)
Why don't you experiment on a subpage or in your user space, that way the interface would not change too much and irritate users until we have an good final solution. I have noticed this too and had thought of adding the bold gadget name (link) after the checkbox and before the explanation. For the cosmetic gadgets we could come up with a concise explanatory name - just an idea... Cacycle (talk) 18:39, 2 July 2009 (UTC)
Because of a bug during the first attempt to deployement interface messages were failing a bit (gadgets are technically also interface messages), during the later deployement this was fixed Krinkle (talk) 11:04, 8 March 2011 (UTC)
ResourceLoader
Gadgets are not loaded through ResourceLoader by default, instead we can opt-in on a per-gadget base.
Although in most cases opting in it should only do good things (saving requests by combining them in 1 request, making it load less and faster (minified() and cache more (served from bits.wikimedia.irg), some edgecases can break.
For that reason I've added a duplicate entry for Navigation-popups (one of the most popular gadgets) and opted it in for ResourceLoader to see how it goes.
If no bugs are found we could opt the normal entry and remove this one. I suggest we follow this procedure without rush and only one or few gadgets at a time (there's no deadline set). Krinkle (talk) 11:04, 8 March 2011 (UTC)
Are you planning to combine the preference settings of all users once we're satisfied, or will all users of the RL version have to switch back manually?. Cheers, Amalthea11:13, 8 March 2011 (UTC)
That will have to happen manually. So I'd say switch to the new one now, and either wait untill you see no popups and switch your preference back then. Or test it for a few hours and switch back so you won't forget. Either way, they won't be merged. Krinkle (talk) 20:56, 9 March 2011 (UTC)
I'm completely confused. How does one make a gadget to be loaded through ResourceLoader? (so I can start making those improvements on other wiki).
I only see you duplicated a line on the deifnitions page, but the exact same sourcefiles (popups.js and navpop.css) are being loaded. Magister Mathematicae (talk) 07:31, 12 March 2011 (UTC)
Indeed, that's what I was thinking too when I saw it. I just assumed that there was something going on that simply was not meant for mere mortals like me to understand. Gary King(talk · scripts)07:41, 12 March 2011 (UTC)
Just adding [ResourceLoader] does not change the "name" of the gadget in user preferences in the database so the gadget stays checked if it was checked. I mean that's the only logical way to implement such a switch anyway. — AlexSm14:53, 12 March 2011 (UTC)
With regard to Popups, I have implemented at Commons and Wikisource. To note that I couldn't get the navpop.css file to import by various means, so in the end, I just put in local copies. The popups component worked fine once Krinkle helped me with the syntax. billinghurstsDrewth23:35, 12 March 2011 (UTC)
@Magister Mathematicae: ResourceLoader is a way to load modules. The modules themselfs aren't any different. So it uses the same sources files (no need to duplicate that), but loaded in a different way. The difference between the two lines is two fold.
A) It has a slightly different name ("NavigationpopupsRL" instead of "Navigation_popups"), this is to prevent collisions with existing preferences, it has to be a different name
B) It has the [ResourceLoader] which isn't part of the name but a magic word to trigger the resource loader (which will minify, optimize and combine all resources into 1 single request)
@AlexSm: Indeed, the magic word is not part of the name. So once a gadget is known to not break when loading through ResourceLoader (via a temporary copy), the magic word can be added to existing ones and everybody using that gadget will be switched because it didn't change the name thus uses the same preference. That's the whole idea :)
So, what am I doing wrong? I uncheck the regular Popups and check the RL version, only to find out Popups is defunct. Do I need to check both checkmarks in my gadgets? — Edokter (talk) — 11:37, 3 April 2011 (UTC)
I'm looking at Special:Preferences#preftab-9 through the eyes of a newcomer, and it seems awfully confusing. Why is there both "editing gadgets" and "user interface - editing gadgets"? And gadgets that are simple enhancements (easy to understand and use, maybe zero-configuration) like the UTC clock are mixed in with advanced stuff (CIDR? Even I don't know what that means) and useful-but-some-learning curve (like Twinkle). I get the impression changing the structure isn't straightforward, but I'm rather tempted to suggest starting again and designing a new structure from scratch. Rd232talk18:51, 6 June 2011 (UTC)
Yeah the whole thing needs a makeover. The problem is that some admins just add their favorite scripts to the list and it eventually gets bloated, especially with scripts that are used by less than a few dozen people. Gary King(talk · scripts)19:07, 6 June 2011 (UTC)
I guessed that. The black/green screen thing seems a bit out there... How hard is it to change the structure? Rd232talk19:13, 6 June 2011 (UTC)
Not hard at all. It's all on this page. Of course, we'd need a discussion on the structure before proceeding, but I am definitely in favor of one. On a related note, I've written a few dozen scripts but even I know that only a handful are useful to a large audience. Many of the scripts on this page are so specialized that they inherently only interest a small number of people. Script packages like Twinkle, however, are useful to such a broad audience that they belong on this page. Also, here's a list of users for each gadget, it's about a year old. Gary King(talk · scripts)19:21, 6 June 2011 (UTC)
OK. What about having a separate "Advanced Gadgets" tab? That would make it easier to really clear some of the more obscure/confusing stuff out of the way. Rd232talk19:31, 6 June 2011 (UTC)
That's a good start. I'd say more than half would belong there; essentially, anything that mentions technical terms such as "regex" (regular expressions), "CIDR" (Classless Inter-Domain Routing), etc. would belong. Gary King(talk · scripts)19:38, 6 June 2011 (UTC)
Also, as I mentioned on WP:VPP, a few scripts could be merged into one. The only problem is that each script has a different author; but if we were to create something like MediaWiki:Gadget-contributions.js which all admins are allowed to edit, then we could import related scripts together and they would then come in a package, therefore no longer requiring that the user install each script separately and instead allowing them to install several related scripts at once. Gary King(talk · scripts)19:47, 6 June 2011 (UTC)
Comment I'd be loathe to remove gadgets as it is easier to access them here than the other way. (There are many interesting scripts that users don't find out about as they are hard to find.) However, I do appreciate the concerns raised over the issue of simplicity, and would support a reorganization of the page to that effect. I'm not sure how easy it is to add a tab for "advanced gadgets" (would that require coding from the devs?) but at the very least we could move "advanced" gadgets to the bottom under their own heading. --Ckatzchatspy20:40, 6 June 2011 (UTC)
I'm thinking if we had an Advanced Gadgets tab we could add quite a few useful (perhaps underused) scripts, since that tab could be quite a bit more complex. Rd232talk20:46, 6 June 2011 (UTC)
Incidentally, on the subject of adding tabs - I wonder if the Twinkle Preferences panel could be an additional tab for those users who have Twinkle installed? Rd232talk20:48, 6 June 2011 (UTC)
You want to add another tab to Preferences? I don't think we can do that. But, it's easy to add new sections to the Gadgets tab; you just edit this page. Yes, there are a lot of scripts that people will never discover because they aren't listed. The more scripts you have listed, though, the fewer get installed because people don't want to sift through so many scripts, especially when many of the descriptions are hard to decipher. That's why a year ago, I started working on Wikipedia:Script Installer, which lets you go to a script and click "Install this script" without requiring that the user edit anything (check the gallery). The Script Installer was supposed to also create a Script Gallery where scripts could be listed, broken down by category, and show many users installed each one to indicate the more popular ones (screenshot). I stopped working on it a few months ago because I've been busy, etc. but perhaps there's still a need for something like this. Gary King(talk · scripts)18:44, 7 June 2011 (UTC)
Twinkle adds extra tabs at the top of the page. Is it really not possible to do something similar for Preferences tabs? Anyway, anything's possible if the software is changed. But if your Script Installer were finished, that could actually serve a similar purpose. It would become a gadget, with an explanation that lots more scripts, some advanced, are available through it. It would remove the "easy installation" motivation for cramming the Gadgets tab. If you can make it happen, more power to you! Rd232talk19:45, 7 June 2011 (UTC)
Well Script Installer is already done and about a dozen people have it installed already. It's definitely still in beta mode, though, since some features are still missing, such as the ability to uninstall scripts. I've got the most crucial part of being able to install scripts completed a while ago, though. Also, I thought you meant adding tabs to Preferences for everyone, which can't be done. The user would have to install a script to see new tabs in Preferences; I think that's the only way. Or, through a MediaWiki extension, I guess. Gary King(talk · scripts)06:24, 8 June 2011 (UTC)
" The user would have to install a script to see new tabs in Preferences" - well that would actually make sense, if a Gadget on the Gadgets tab, when activated, gave access to an additional Advanced Gadgets tab. Rd232talk06:32, 8 June 2011 (UTC)
The simplest course of action would still seem to be to move the "advanced" gadgets to the bottom of the page. I'm not sure if another tab is the best approach overall, since it is better to keep gadgets to one tab (as with other option tabs). However, what if there was a gadget that - when selected - enabled the display of the more advanced gadgets? --Ckatzchatspy06:59, 8 June 2011 (UTC)
This page needs a makeover indeed. One big improvement is reorganizing according to functionality. Basically, this means renaming the sections, adding some explanatory text and shuffling some gadgets. My initial suggustion would be:
Appearance
Provides more options to change the appearence of Wikipedia
Editing
Options to change common editing functions
Miscellaneous
Options that do not fall under any other category
Advanced functionality
These gadgets provide advanced functions during reading and editing pages
I think putting "advanced" gadgets at the bottom of the page (or in it's own section) is a great idea, also I would like to encourage the further development of Script Installer, is there any documentation links to explore ? Mlpearcpowwow17:13, 10 June 2011 (UTC)
I can't find the MediaWiki page that contains the actual gadget descriptions, so could an admin who knows where it is make the following correction: "Adds two new dropdown boxes below the edit summary box, with some useful default summaries" should be changed to "Add two new dropdown boxes below the edit summary box, with some useful default summaries" (basically change "Adds" to "Add"). Sorry if I'm reporting this in the wrong place... --Andrew(User:90)(talk)23:16, 16 February 2012 (UTC)
True, it works either way, but the modification makes it consistent with the other options which start with Add, Make, Focus, Disable, etc. Thanks! --Andrew(User:90)(talk)23:48, 16 February 2012 (UTC)
ReferenceTooltips on by default
This edit request has been answered. Set the |answered= parameter to no to reactivate your request.
Could you get someone to check your code? (The last few times I have deployed your code, there have been some mistakes!) Thanks — Martin (MSGJ · talk) 19:25, 13 September 2012 (UTC)
It needs fixes before it can be implemented here. I've outlined the issues I see, including some much less pressing ones, on the proposals page. -— Isarra༆18:12, 14 September 2012 (UTC)
Open search result list and search suggestions in new tab
This edit request has been answered. Set the |answered= parameter to no to reactivate your request.
In all search forms this gadget makes the search result list or search suggestion open in a new tab via Ctrl-click (PC) and Command-click (Mac). Please add this gadget. It has unanimous support in these two Village Pump discussions:
Please see the main Bugzilla thread: Bugzilla:35974. It seems that this JavaScript will not get implemented in core MediaWiki until after it gets implemented as a gadget. Several people in that thread said it should first be implemented as a gadget. --Timeshifter (talk) 20:05, 17 September 2012 (UTC)
Again, this is does not belong in a gadget. It is a basic fix for a deficiency in 2-3 major browsers, just like the js to write in the 'Search' text in the vector searchbox is a basic fix for browsers not supporting that particular html5 feature, and the browser-specific stylesheets for the different versions of IE make up for IE being... well, IE. Is there any particular reason why we need to shove the technicalities of web design in our users' faces with yet another checkbox when this is something that should just work in the first place, and something that people will expect to just work in the first place? -— Isarra༆20:33, 17 September 2012 (UTC)
There may have been some misinterpretations involved there, but it does need to work consistently and not break any existing browser functionality before being turned on in core. -— Isarra༆22:56, 18 September 2012 (UTC)
Oooh, you don't need to go through bugzilla to change the site javascript. That's what MediaWiki:Common.js if for; any admin can edit that same as the gadget pages, although for temporary fixes, it'd probably be best to get someone to make a subpage for the thing so it's easier to remove later. Best ask around there what the practice is on this wiki, though. -— Isarra༆20:37, 17 September 2012 (UTC)
I like this idea. I am the bureaucrat on a wiki at Wikia. I have changed MediaWiki:Common.js on that wiki. So I know what you are talking about. I don't see why a subpage would be needed. It is only 2 lines of JavaScript that is being added or removed. --Timeshifter (talk) 21:25, 18 September 2012 (UTC)
Modularity. From those two lines, though, I have to wonder - does it follow any different key combinations other browsers may use, since there was concern about that in the last discussion, and is the thing it breaks in chrome resolved? Or really, need it activate at all for browsers that already have the intended functionality? -— Isarra༆22:56, 18 September 2012 (UTC)
Ctrl-click (PC) and Command-click (Mac) is fairly standard for opening links in new tabs in most browsers. All this does is extend that functionality to all search forms on Wikipedia. It works for me in Chrome, Internet Explorer, and Firefox. Those are the web browsers I have installed. Try it yourself and see. It also works in Safari according to what others have said. See the link in the next paragraph.
Right, I apologise for not looking more closely sooner, but js is really not my strong suit. You need to address known issues before trying to get it applied on a wider scale, which includes testing it in all major browsers, including different versions, and removing redundancies and conflicts. This is why it was not added to core, and despite what I said, even a gadget would probably be premature at this stage. Please, do that before continuing with this, and again I'm sorry I assumed it had already been past that before it got here. -— Isarra༆16:01, 19 September 2012 (UTC)
Maybe I'm just being paranoid, but yuvipanda added a check for fringe cases, which should help prevent anything weird from happening. I dunno; maybe just throwing the thing in and seeing what happens would be best at this point. Just not in a gadget. Seriously. -— Isarra༆20:00, 19 September 2012 (UTC)
Request disabled, because I am not sure what is being requested. Please reactivate when you have made your minds up. — Martin (MSGJ · talk) 20:46, 19 September 2012 (UTC)
I suggest that since the Commons has implemented this as an optional gadget we can too on Wikipedia. I have not heard of any problems on the Commons. And if there are some peculiar bugs people can always turn this gadget off in preferences.
Yuvipanda left this message on my talk page on the Commons: "Hey! Sorry for the delayed reply. I think it should be a gadget, with default on/off left to community. I see it has already been implemented, so maybe I'm too late?"
(unindent). From looking at how it was done on the Commons it looks like a JavaScript page needs be created in the MediaWiki namespace. I suggest using the same name and JavaScript code as on the Commons page:
I am an not an admin, and so I can not create or edit pages in the MediaWiki namespace. I don't know if there are more steps involved. --Timeshifter (talk) 10:01, 27 September 2012 (UTC)
In that discussion one person said: "Took another look at this and completely agree with it being used as a gadget, albeit not as default. I'll see if I can ping an admin in IRC to add it."
The other person in that discussion said to put it into MediaWiki:Common.js. I'd be happy with that too, but I think the majority view in the discussions is for it to be a gadget so that it can be turned off if desired. --Timeshifter (talk) 06:30, 30 September 2012 (UTC)
Surprised to see this request still open. I was hoping an admin familiar with javascript would tackle it. I had a go, and followed your request but it didn't work properly. In the list of gadgets it displayed <gadget-search-new-tab> and no description of the gadget as the other ones do. So I will disable the request for now and hope (again) that a js-knowledgable admin comes along soon. — Martin (MSGJ · talk) 17:43, 29 October 2012 (UTC)
Thanks for trying. I am figuring this out as I go along. I found this:
See the section called "Interface: Other". There one finds "Search results in new tab" and a link at the end of it labeled "View source." It is the source for a page on the Commons that also needs to be created here on Wikipedia: MediaWiki:Gadget-search-new-tab - on the Commons it is: commons:MediaWiki:Gadget-search-new-tab
Thanks! I enabled it in my preferences and it works fine. Does the Mac ⌘ Command key also need to be mentioned in the gadget description here?: MediaWiki:Gadget-search-new-tab. Or do Mac users automatically know to use it when the CTRL key is mentioned for PC users? I use a PC, and so I don't know. --Timeshifter (talk) 18:25, 1 November 2012 (UTC)
I'm on a Mac, and I just enabled the gadget; it works just the same in Safari when I use either command or control. (though it opened it in a new window, not in a new tab) EVula// talk // ☯ //18:51, 1 November 2012 (UTC)
OK. Do some Mac keyboards only have a ⌘ Command key? No Ctrl key?
According to this page, in Safari opening a page in a new tab (instead of a new window) is decided by the browser preferences. In Safari : Preferences > Tabs. --Timeshifter (talk) 22:48, 3 November 2012 (UTC)
Where to ask somebody to turn HotCat on for more editors?
You would do it more or less the same way we did it for the "my sandbox" gadget: change [ResourceLoader] to [ResourceLoader|default|rights=???] in the line for HotCat, with an appropriate choice for "???". With "my sandbox" createpage was a logical choice since that right is needed for the gadget to work in the first place. For this one, the choice of right to use will be rather arbitrary; pick anything from Special:ListGroupRights that is listed for "Users" and not listed for "(all)". Too bad the VP discussion didn't go for "enable for autoconfirmed editors only", because then autoconfirmed would be the obvious right to use. As it is, createpage is probably still the best arbitrary choice.
Note that this works for "make this gadget available only to users with these rights, and enable it by default for them"; there is no way to enable a gadget by default for some users while still making it available to a larger group. In the case of anons versus registered users, this distinction doesn't matter since anons cannot enable or disable gadgets anyway; "not available" and "not enabled by default" are effectively the same for them. Anomie⚔04:29, 16 November 2012 (UTC)
It is enabled now. If this causes any serious problems, feel free to roll back this edit of mine. If you notice non-critical problems, please report them at Wikipedia talk:HotCat. (BTW, I used for the time being the "purge" right, which anons don't have. See bugzilla:42171.) Lupo08:58, 16 November 2012 (UTC)
follow up
So, the decision to turn HotCat on by default was a result of a discussion where a whopping four users supported doing so. That action caused caused some problems and has now been undone. In the future it would probably be good to be sure that there is a significant consensus, arrived at by something like an RFC, before making any such changes. I'm not suggesting anyone acted in bad faith or anything like that, but there was not enough input and not enough critical thinking about the possible confusion it would cause when noobs started using a tool without even knowing they were using it and without explanation of how it works and what it is for.
It looks like the process of installing it is actually a little more involved: see Wikipedia:Gadget#Installation. Also, has anybody double-checked the code per the comment by Tucoxn at the discussion you linked? Equazcion's code usually seems reliable (not that I'm in any position to judge), but it can't hurt to have someone else give the ok independently. Legoktm, Edokter or TheDJ, maybe you could do the honours, or maybe you know someone who can? — Mr. Stradivarius♪ talk ♪07:49, 27 November 2013 (UTC)
@Equazcion: why is .attr('hidden','') used instead of .hide(), and .removeAttr('hidden') instead of show()? I guess it doesn't really matter, just curious. In the .find('a').each function, you call $(this) a few times. You can just do var $this = $(this), and use $this everywhere. Legoktm (talk) 17:42, 27 November 2013 (UTC)
Oh also, I'm a bit concerned about defining a function named sort in the global scope, and that someone will accidentally clobber it. Maybe rename it to 'sidebartranslate_sort'? Or move it into the $(document).ready function since it isn't needed outside of it? Legoktm (talk) 17:47, 27 November 2013 (UTC)
On the hide thing, the answer is I don't remember. I got into the habit of using the attribute method some time ago, when I had some trouble with hide() and show() in certain situations, whereas I've never had any issue with the former. This may have been in an earlier version of jQuery, or in some special circumstance. I can try hide() and show() here if it'll make the code more readable or something.
Calling $(this) is another force of habit after reading something a while back about variable assignment of $(this) having barely any performance gain as compared to assigning other jQuery selectors to variables. I find it easier to read, probably just due to my own habit, but I can make that change too.
I'll change the name of the sort function. I kinda thought Wikipedia does something magical to separate the scopes of imported scripts, but I don't know where I got that idea from. equazcion→18:13, 27 Nov 2013 (UTC)
Did all those now. Seems to be working. equazcion→18:33, 27 Nov 2013 (UTC)
After reading a bit of that, I still have no idea what ResourceLoader is =D Let's start this this: How did you determine that this script doesn't work with ResourceLoader? And what is ULS? And PS. If someone wants to go ahead and make my script compliant rather than deal with having to get me to understand this, they can feel free, if that might be easier. equazcion→19:09, 27 Nov 2013 (UTC)
ResourceLoader is basically the system that runs most JS/C
Resolved.svg)
