MediaWiki talk:Gadgets-definition

src: upload.wikimedia.org

For information about gadgets, see Wikipedia:Gadget; for the addition of user scripts as gadgets, see Wikipedia:Gadget proposals.

Video MediaWiki talk:Gadgets-definition

Customization

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? - auburnpilot talk 02: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. - auburnpilot talk 13:03, 4 December 2007 (UTC)

Yes, that should work. But it makes it more difficult to change the settings. Prodego ^talk 20:55, 4 December 2007 (UTC)

The documentation for this doesn't seem to match our implementation, questions:

1. Should there be a matching MediaWiki:Navigation_popups page for this?
2. Where is the control that is making it link to Wikipedia:Tools/Navigation popups

-- xaosflux ^Talk 04:46, 6 December 2007 (UTC)

Semi answered myself, see MediaWiki:Gadget-Navigation popups. -- xaosflux ^Talk 04:50, 6 December 2007 (UTC)

Got the rest, just really not used to the prefix naming scheme. -- xaosflux ^Talk 04:53, 6 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? -- xaosflux ^Talk 04: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)

Does anyone have the expertise to move the css portion of popups over? Prodego ^talk 12:07, 6 December 2007 (UTC)

Looking on Wikipedia:Tools/Navigation_popups#Changing_the_appearance_of_your_popups .css is not required, but is used to set per-user options to change the appearance, am I missing something else? -- xaosflux ^Talk 13:04, 6 December 2007 (UTC)

Look at the very top of popups.js. It calls a css page there, if I remember correctly. Prodego ^talk 13:06, 6 December 2007 (UTC)

Yes, it does call a CSS page there, User:Lupin/navpop.css. I will go make a request for MediaWiki:Gadget-navpop.css to be created (and then the needed changes for the other relevant pages). FunPika 02:20, 9 December 2007 (UTC)

Maps MediaWiki talk:Gadgets-definition

To Do's

1. Get some better definition and description pages for the headers (could very well be sections using Page#Section markup.
2. Create Help:Gadgets or Wikipedia Gadgets for general information and documentation
3. Have a centralized location for requesting additions (here?) -- xaosflux ^Talk 13:06, 6 December 2007 (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 ? AlexSm 18:22, 14 December 2007 (UTC)

Ok, if nobody minds I think I'll create WP:Gadgets Proposals ? AlexSm

I have just created Wikipedia:Gadgets and Wikipedia:Gadget proposals. ?????l? 03:40, 17 January 2008 (UTC)

Thank you ? AlexSm 22:11, 17 January 2008 (UTC)

src: upload.wikimedia.org

Admin Gadgets

• Thread moved to Wikipedia_talk:WikiProject_User_scripts/Gadgets#Admin_Gadgets to centralize the discussion. -- xaosflux ^Talk 04:51, 7 December 2007 (UTC)

src: 4.bp.blogspot.com

Normal Gadgets to consider

These should all be multibrowser compatible (Opera, FF, Safari and IE). I have used all of them at times, and none of them are admin scripts.

• a ported HotCat.js from Commons
• Wikipedia:WikiProject_User_scripts/Scripts/Formatter the format tab
• User:Rparle/monobook.js/purgebutton a purge tab
• User:Alex_Smotrov/qpreview.js Quick preview
• 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 o 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 ? AlexSm 20:33, 7 December 2007 (UTC)

HotCat was ported to fr: so should be able to work here after translation. -- xaosflux ^Talk 00:48, 8 December 2007 (UTC)

src: upload.wikimedia.org

Suggested addition: external links

Opening external links in a new tab/window:

This has been proposed twice: 1, 2. If anyone wants to improve the script for performance/style/general usefulness, please do so. Gracenotes^T § 21:03, 8 December 2007 (UTC)

Added {{editprotected}} - any objections to including this? Gracenotes^T § 21:41, 9 December 2007 (UTC)

Is it firefox only, and, if not, what happens in a browser that does not support tabbed browsing? Prodego ^talk 21:47, 9 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. Gracenotes^T § 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 ? AlexSm 00:28, 10 December 2007 (UTC)

Well, I'll let you decide that, we can always remove it. Done. Prodego ^talk 00:30, 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. Gracenotes^T § 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)

src: upload.wikimedia.org

Change to popups line

{{editprotected}}

Please change * Navigation_popups|popups.js to * Navigation_popups|popups.js|navpop.css. FunPika 03:17, 9 December 2007 (UTC)

Y Done - Nihiltres^{t.l} 03:41, 9 December 2007 (UTC)

src: upload.wikimedia.org

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 popups 13:09, 12 December 2007 (UTC)

Which scripts do you think would be useful? I wouldn't mind making them IE compatable, if such is possible. Gracenotes^T § 16:00, 12 December 2007 (UTC)

The 4 that are listed at the top of my userpage. Zocky | picture popups 17:57, 12 December 2007 (UTC)

src: upload.wikimedia.org

cookie-based Preferences?

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.

So, I've written up a mostly-working proof of concept of both of these combined, which may prove to be useful after some heavy testing/cleanup. See Wikipedia:WikiProject User scripts/preferences and the associated talk page for details. --Splarka (rant) 04:59, 29 December 2007 (UTC)

src: previews.123rf.com

UTCLiveClock

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? ? AlexSm 00:06, 12 January 2008 (UTC)

Oh, missed that, forgot I had that changed a while back. _->AzaToth 00:14, 12 January 2008 (UTC)

_->AzaToth 00:17, 12 January 2008 (UTC)

src: upload.wikimedia.org

Special:Log/rights

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 ? AlexSm 02: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)

src: upload.wikimedia.org

New gadget pages

As suggested above, I have created Wikipedia:Gadget for general informations about gadgets and Wikipedia:Gadget proposals for discussing the addition of user scripts as gadgets. ?????l? 04:03, 17 January 2008 (UTC)

src: i2.wp.com

Reworking

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 o C o L) 02:58, 2 July 2009 (UTC)

As long as the new organization makes sense, go ahead; it needs it. :) {{Nihiltres|talk|edits}} 14:40, 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)

Sure; I'll work something up in a sandbox soon and let you know when I think it's ready. -Drilnoth (T o C o L) 18:50, 2 July 2009 (UTC)

src: upload.wikimedia.org

Gadgets dont work on new MediaWiki software

Since the new Wikimedia Software came online on Tuesday, my GoogleTrans gadget does not load anymore

The NavPopups gadget does not load either.

There is a help file on how to load 'Extensions'. Should we follow this? It requires that a PHP file be made.

Would this PHP file be gadgetname.php?

Would'nt administrators need to make this file since it would have the same name as the gadget?

Has anybody else noticed what I have this morning?

In the description file for the gadgets all the gadgets now link to Gadget-Gadget file, which doesn't exist

Endo999 14:16, 8 February 2011 (UTC)

Back to normal for me now. ----- Gadget850 (Ed) ^talk 14:42, 8 February 2011 (UTC)

For 10 Min for me. JackPotte (talk) 19:46, 8 February 2011 (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)

src: ordinaryphilosophy.files.wordpress.com

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, Amalthea 11: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)

I'm assuming the maginc is in the [ResourceLoader] tag in the message. Amalthea 08:33, 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. -- AlexSm 14:53, 12 March 2011 (UTC)

mw:ResourceLoader/Migration_guide_(users)#Keep_gadgets_central and surrounding pages billinghurst sDrewth 23:32, 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. billinghurst sDrewth 23: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 :)

Krinkle (talk) 11:27, 3 April 2011 (UTC)

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)

In fact, in Chrome, all javascript is dead when the RL version of Popups is enabled. -- Edokter (talk) -- 15:12, 3 April 2011 (UTC)

Gadget tab structure

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. Rd232 ^talk 18: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? Rd232 ^talk 19: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. Rd232 ^talk 19: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. --Ckatz^chat_spy 20: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. Rd232 ^talk 20: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? Rd232 ^talk 20: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! Rd232 ^talk 19: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. Rd232 ^talk 06: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? --Ckatz^chat_spy 06: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

Thoughts? -- Edokter (talk) -- 13:37, 10 June 2011 (UTC)

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 ? Mlpearc powwow 17:13, 10 June 2011 (UTC)

Yes, it's all in the link I provided, Wikipedia:Script Installer. Gary King (talk · scripts) 17:32, 10 June 2011 (UTC)

Thank you, and sorry, I missed the previous link. Mlpearc powwow 19:50, 10 June 2011 (UTC)

Any ETA? The currently layout sucks. I'd do it myself, but that requires running for RfA. -- Dispenser 14:08, 19 July 2011 (UTC)

No it doesn't - for this situation you can always do a userspace draft and then propose it and if necessary use {{editprotected}}. Rd232 ^talk 15:33, 19 July 2011 (UTC)

I've made a start. -- Edokter (talk) -- 15:30, 19 July 2011 (UTC)

HideFundraisingNotice gone

If MediaWiki:gadget-HideFundraisingNotice is unlisted then anyone updating their preferences will have it removed. We had some annoyance at the village pump this year since it was originally stated that users wouldn't have to re-enable the gadget every year. This becomes more important if the fundraiser is held more often (the fundraising team is looking into it). -- Dispenser 21:44, 17 January 2012 (UTC)

Already done Edokter (talk · contribs) appears to have taken care of this on January 19.[1] Anomie? 14:07, 9 February 2012 (UTC)

Note, this gadget was suppressing ALL central notices, not just fundraisers - it has been forked now for all and the original is being worked on to be for just FR's (this was done to preserve the UI goal of hiding FR notices without making users re-enable). -- xaosflux ^Talk 04:12, 17 February 2015 (UTC)

Typo

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)

Both versions seem correct (as in "[this gadget] adds..."), but I've changed it anyway. -- Edokter (talk) -- 23:41, 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

Please change the line * ReferenceTooltips|ReferenceTooltips.js|ReferenceTooltips.css to * ReferenceTooltips[default]|ReferenceTooltips.js|ReferenceTooltips.css, so as to enable the ReferenceTooltips gadget by default. There was consensus for this at Wikipedia:Village pump (proposals)/Archive 89#Reference_Tooltips. See also WP:VPM#ReferenceTooltips. Thanks. --Yair rand (talk) 23:58, 16 July 2012 (UTC)

Done - Penwhale | ^{dance in the air and follow his steps} 00:28, 17 July 2012 (UTC)

Edit tools

See Wikipedia:Gadget/proposals#Edit tools. Helder 21:25, 12 September 2012 (UTC)

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)

You can check it directly on test.wikipedia.org, where it is implemented (and working) right now. Helder 03:25, 14 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

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:

• Wikipedia:Village pump (technical)/Archive 102#Support or oppose adding gadget to open search in new tab - Village pump discussion showed good support for adding gadget.
• commons:Commons:Village pump/Proposals/Archive/2012/08#Support or oppose adding gadget to open search in new tab - Discussion showed good support for adding gadget.

The search gadget:

• commons:User:Timeshifter/Open search in new tab.js - JavaScript (JS).
• commons:User talk:Timeshifter/Open search in new tab.js - description and JS import info.

It has been thoroughly discussed in several locations. Discussion links:

• commons:User talk:Timeshifter/Open search in new tab.js#Discussion elsewhere

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)

According to several people at Bugzilla:35974 it does belong in a gadget. --Timeshifter (talk) 21:25, 18 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.

I could not figure out what Helder was talking about concerning Chrome. See commons:Commons:Village pump/Proposals/Archive/2012/08#Revised version that also works for Mac users. Maybe you can duplicate his problem. He is not a native speaker in English, though, and I think that makes it all the more difficult to figure out. Wikipedia search opens in a new tab for me in Chrome when I use Ctrl-click. --Timeshifter (talk) 04:30, 19 September 2012 (UTC)

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)

Interesting. Concerning commons:User:Yuvipanda/newtab-search.js. I left a message here: mw:User talk:Yuvipanda#Open search in new tab. --Timeshifter (talk) 05:41, 20 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)

{{edit protected}} - I reactivated it after seeing no opposition to my latest request below. --Timeshifter (talk) 19:32, 10 October 2012 (UTC)

The search gadget is now a preference on the Commons

See:

• commons:Special:Preferences#mw-prefsection-gadgets - see "Interface: Other".
• commons:User talk:Rillke/Discuss/2012/2#Gadget implementation. Open search in new tab
• commons:MediaWiki:Gadget-search-new-tab.js
• commons:MediaWiki talk:Gadget-search-new-tab.js

The last link provides more info, and explains what it does. --Timeshifter (talk) 07:14, 21 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?"

I think we should install this on Wikipedia as an optional gadget for now. --Timeshifter (talk) 23:16, 23 September 2012 (UTC)

Please specify exactly what needs to be added where. -- Martin (MSGJ · talk) 14:52, 26 September 2012 (UTC)

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

• commons:MediaWiki:Gadget-search-new-tab.js
• MediaWiki:Gadget-search-new-tab.js - Wikipedia page.

Then a line needs to added to MediaWiki:Gadgets-definition. See this diff to see what was added on the commons:

* search-new-tab [ResourceLoader]|search-new-tab.js

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)

Was there a discussion on this wiki to have the gadget added? See Wikipedia:Gadget/proposals. Rjd0060 (talk) 22:50, 29 September 2012 (UTC)

Yes. Higher up I linked to the main discussion. It got unanimous support in that discussion:

Wikipedia:Village pump (technical)/Archive 102#Support or oppose adding gadget to open search in new tab.

See also:

Wikipedia:Gadget/proposals#Open search result list or search suggestion in a new tab

Wikipedia:Gadget/proposals#Support or oppose adding gadget to open search in new tab.

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:

Commons:Special:Gadgets

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

I believe once that page is created on Wikipedia, then the description will show up. --Timeshifter (talk) 20:04, 29 October 2012 (UTC)

You indeed forgot the create the description page at MediaWiki:Gadget-search-new-tab. I've added the gadget. -- Edokter (talk) -- 21:04, 29 October 2012 (UTC)

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)

Use Resource Loader for HideFundraisingNotice

Can we have Resource Loader enabled for HideFundraisingNotice? Or would that cause trouble with the javascript of this gadget? Helder 22:14, 29 October 2012 (UTC)

We can try. Though in the past, gadgets that didn't use document.ready tended to fail with ResourceLoader. -- Edokter (talk) -- 20:55, 30 October 2012 (UTC)

It'll work fine without document ready, in fact, it must not have a document ready wrapper as that will make it impossible for the gadget to do what it intends to do. And on that, though I haven't confirmed, I suspect the gadget is already unable to do what it intends to do. Can someone confirm that it is working currently at all? Krinkle (talk) 01:33, 30 June 2013 (UTC)

I changed it to have ResourceLoader load HideFundraisingNotice. I'm not sure if the JS is actually working as intended though. Regardless, the CSS component of the gadget should effectively hide any banners. Kaldari (talk) 03:41, 11 August 2015 (UTC)

@Kaldari: You did it only with HideCentralNotice. HideFunraisingNotice is still loaded without ResourceLoader. Jack who built the house (talk) 15:18, 30 January 2017 (UTC)

Where to ask somebody to turn HotCat on for more editors?

Per the outcome of a community discussion (see here) for details, it is agreed to make HotCat available for more editors (turn it on by default). However, nobody really knows how to make it so; posting here was a suggestion from the Village Pump. --_{Piotr Konieczny aka Prokonsul Piotrus| reply here} 17:38, 15 November 2012 (UTC)

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.) Lupo 08: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.

For the record, what happened was that the "+" that HotCat adds to the bottom of the page was repeatedly mistaken for a way to add comments at the bottom of a talk page. Because these users saw a sign indicating they could add something and they got no further information they ended up creating category pages that were actually comments, for example Category:Hello Kintetsubuffalo. I am writing regards the history of the Asociacion de Guías y Scouts de Costa Rica, I am member of the national Council, Obviously that's not a good thing, and a brief discussion, which nevertheless had far more support than the original one that turned it on, resulted in it being turned back off. Beeblebrox (talk) 02:07, 30 June 2013 (UTC)

Please delete oldeditor.js

Please delete oldeditor|oldeditor.js as it has no effect. VisualEditor is not enabled by default, and if it is enabled from Special:Preferences#mw-prefsection-editing, this gadget will still have no effect. --MK (talk) 07:21, 6 October 2013 (UTC)

 Done. -- Edokter (talk) -- 07:36, 6 October 2013 (UTC)

User:Equazcion/SidebarTranslate.js

Please add * SidebarTranslate|User:Equazcion/SidebarTranslate.js to the "appearance" section of the page per Wikipedia:Village_pump_(proposals)#Make_SidebarTranslate_into_a_gadget. Armbrust ^{The Homunculus} 15:23, 26 November 2013 (UTC)

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)

 Done. @Equazcion:, it would be helpful if it could work with ResourceLoader for efficiency. Might be some weird stuff if ULS hasn't loaded yet. Legoktm (talk) 18:47, 27 November 2013 (UTC)

I could work on that, I just don't know what ResourceLoader is. Is that another gadget? I don't see it in the list. equazcion -> 18:51, 27 Nov 2013 (UTC)

See mw:ResourceLoader. -- Edokter (talk) -- 18:59, 27 November 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/CSS on the site through load.php. For example, [2] loads jQuery. This currently only loads the CSS because I removed the [ResourceLoader] specification. mw:ULS is an extension that adds the #p-langs menu even if there are no language links. I'm not sure if it even matters, I was just thinking of what might have been making it not work. Legoktm (talk) 20:36, 27 November 2013 (UTC)

What I suspect as cause of failure under Resourceloader is load order. Under RL however, this is somewhat controlable. I want to put the gadget under the test section first to see if I can load SidebarTranslate with a dependency on ULS, which in theory, should load both in correct order and prevent any misfires. -- Edokter (talk) -- 21:16, 27 November 2013 (UTC)

Looking for ULS's module name, I suspect 'ext.uls'. Please correct me if I'm wrong. -- Edokter (talk) -- 21:27, 27 November 2013 (UTC)

Uncaught Error: Unknown dependency: ext.uls. -- Edokter (talk) -- 21:37, 27 November 2013 (UTC)

After a few misfires, it seems to work with RL just fine, even without the dependency. But that may be random. Please test the version under the Testing gedgets section. -- Edokter (talk) -- 21:58, 27 November 2013 (UTC)

When you say "after a few misfires", do you mean it took you a few page loads before it worked? Your test version seems to be working for me immediately, at any rate. equazcion -> 02:28, 28 Nov 2013 (UTC)

It did. Seems to work consistently for me as well now. I still want to test with dependency tonight. -- Edokter (talk) -- 11:05, 28 November 2013 (UTC)

If you read PHP, you can see all the (shockingly many) ULS module names here. Anomie? 03:10, 28 November 2013 (UTC)

I think I want 'ext.uls.interface' then; it seems that one handles #p-lang. -- Edokter (talk) -- 11:05, 28 November 2013 (UTC)

Works fine with RL for me, not sure why it wasn't earlier. Yay :) Legoktm (talk) 16:54, 3 December 2013 (UTC)

Twinkle preferences

Which page would you edit to add a piped link to the Twinkle preferences panel next to the Twinkle gadget button? -- John Reaves 05:52, 19 December 2013 (UTC)

I think you want MediaWiki:Gadget-Twinkle? Legoktm (talk) 16:09, 19 December 2013 (UTC)

Specify skin support for a few gadgets

Hi. I'm coming here from bugzilla:64975.

old

  dropdown-menus|dropdown-menus.js|dropdown-menus.css  

new

  dropdown-menus[skins=vector,monobook,modern]|dropdown-menus.js|dropdown-menus.css  

old

  CategoryAboveAll|CategoryAboveAll.js  

new

  CategoryAboveAll[skins=monobook]|CategoryAboveAll.js  

old

  MenuTabsToggle[ResourceLoader|dependencies=jquery.cookie]|MenuTabsToggle.js|MenuTabsToggle.css  

new

  MenuTabsToggle[ResourceLoader|dependencies=jquery.cookie|skins=vector]|MenuTabsToggle.js|MenuTabsToggle.css  

old

  Blackskin[ResourceLoader]|Blackskin.css  

new

  Blackskin[ResourceLoader|skins=monobook]|Blackskin.css  

old

  widensearch[ResourceLoader]|widensearch.css  

new

  widensearch[ResourceLoader|skins=vector]|widensearch.css  

Five lines to update total. Thanks! --MZMcBride (talk) 03:39, 8 May 2014 (UTC)

(cc: Helder.wiki, MatmaRex, Jaredzimmerman)

All done. I'll note (if I read mw:extension:Gadgets correctly) that this option only hides the gadgets; it does not disable them when initially enabled and switching skins. -- Edokter (talk) -- 10:38, 8 May 2014 (UTC)

That looks like a bug. Helder.wiki 12:14, 8 May 2014 (UTC)

Depends on intended behaviour. As far as I can tell after some experimenting, when switching to a different skin, the gadgets are disabled, and even reset to default when coming back. It seems the documentation is wrong. -- Edokter (talk) -- 17:55, 8 May 2014 (UTC)

Thanks again for taking care of this. --MZMcBride (talk) 23:14, 8 May 2014 (UTC)

GeoNotice

Shouldn't this only be enabled for logged in users with something like rights=purge? Legoktm (talk) 08:30, 8 August 2014 (UTC)

That would save only one line of code. (And IPs can purge, can't they?) -- [[User:Edokter]] {{talk}} 09:27, 8 August 2014 (UTC)

@Legoktm and Edokter: I'm fine with that. The "purge" user right allows purging a page without a confirmation step, while unregistered users are required to do that extra step. Helder 13:45, 8 August 2014 (UTC)

IPs don't have a watchlist, therefore, don't see watchlist notices; and the geonotice is a special class of watchlist notice. --Redrose64 (talk) 14:36, 8 August 2014 (UTC)

The gadget already ensures that the core code is only loaded on the watchlist page. It is one of the reasons we moved it to a gadget in the first place; adding the right has no added value. -- [[User:Edokter]] {{talk}} 15:07, 8 August 2014 (UTC)

@Redrose64 and Edokter: the addition of rights=purge would be to make this loader code not to be loaded for anonymous users reading any article. We already know beforehand the geonotices are not useful to them, so by adding this restriction we would save loading these extra bytes which will just confirm that we don't want to load the core of geonotices. Helder 15:43, 8 August 2014 (UTC)

I was going to suggest using a right which is more related to what the gadget does (and is still only available for logged in users): viewmywatchlist. However, I noticed bugzilla:69301. So, rights=purge seems good for now. Helder 16:13, 8 August 2014 (UTC)

Ideally, we would be able to specify user groups under rights ('user' for registered user in this case), but that doesn't work. Using these specific rights is a hackity hacky hack! Is it really worth those 20 bytes? -- [[User:Edokter]] {{talk}} 19:21, 8 August 2014 (UTC)

@Edokter: not really. The use of user rigths instead of groups is by design (see Brion's comment on bugzilla:12211#c4). The problem is that the most appropriated user right for this specific gadget is currently added to anonymous users when it shouldn't. Helder 19:45, 8 August 2014 (UTC)

That comment is from 2007. Anyway, your comment kind off exposes my concern; who is to say IPs won't get purge right in the future? -- [[User:Edokter]] {{talk}} 19:51, 8 August 2014 (UTC)

Well, until then we will be avoid sending these bytes to the readers (and hopefully the bug will be fixed soon). Helder 19:55, 8 August 2014 (UTC)

DRN wizard

The DRN wizard uses lazy loading, but does so using importScript. I'd like to turn it into a module, and as far as I can tell, it has no dependencies, but I'd like to be sure. -- [[User:Edokter]] {{talk}} 20:17, 8 August 2014 (UTC)

@Edokter: MediaWiki:Gadget-DRN-wizard.js uses mw.util.wikiScript (from module "mediawiki.util"), mw.user.tokens (from module "user.tokens") and importStylesheet (from "mediawiki.legacy.wikibits"). Helder 21:14, 8 August 2014 (UTC)

Moreover, there are a few functions which are assumed to be globals, such as showStep3, and this won't be the case once the script is converted into a module. These needs to be attached to the window object explicitly. Helder 21:17, 8 August 2014 (UTC)

WP MED 3 month trial

There has been good consensus at Wikiproject Medicine to assess the impact of a more prominent link to the contributors of a medical article. In discussion, it was agreed that the tagline "From Wikipedia, the free encyclopedia", which gives attribution to Wikipedia, would be a good spot to place a link to wmflabs tool that gives full article info, including the list of contributors. There is a (lengthy) general discussion at Wikipedia:Village pump (proposals) #Adding a link to "authors" in Wikipedia's by-line which is inconclusive about the general principle, so WPMED is looking for ways to try the idea out on a limited number of medical articles. TheDJ has very kindly build a gadget to allow that (see MediaWiki:Gadgets-definition #test "ContributorsHack[ResourceLoader|skins=vector|top]|ContributorsHack.js|ContributorsHack.css"), which places the link close to the tagline in articles that are in the hidden Category:Articles with contributors link for those with Vector skins and who have the gadget enabled.

As this trial is confined to a narrow range of articles - at present, only those containing {{Infobox disease}} - I'd like to seek agreement to turn on the gadget by default, and perhaps extend its application to Monobook skin as well for testing. All comments welcome, --RexxS (talk) 15:36, 4 September 2014 (UTC)

I'm having a bit of a problem with a WikiProject hijacking a part of the interface outside article space for the purpose of promoting a link to a tool, which btw, is already available in the 'Page info' page. Why should editors of this particular WikiProject deserve such a prominent presence? -- [[User:Edokter]] {{talk}} 23:32, 4 September 2014 (UTC)

Probably because we asked so nicely? What WPMED is trying to ascertain is whether making the link more prominent leads to unforeseen problems or brings a benefit. It is recognised that going to article 'History', then selecting from the 'External tools' menu the link marked 'Revision history statistics' will give the same information, but several folks have suggested that that is hardly intuitive for a visitor who wanted to see who the contributors are. The trial is only for a short time and on a limited number of articles, so there's an argument that there's little harm possible. Personally, I'm open-minded about the pros and cons, but I regard it as worthwhile to try things out once in a while, just to get a better idea of what might work. --RexxS (talk) 00:03, 5 September 2014 (UTC)

I think that this is an interesting research question. I don't really care which articles are chosen, but it's probably preferable if the chosen articles are mostly supported by people who think this is a good idea. It might be okay if the contributors didn't care, but I'd be sad if we ran this trial on a group of articles that was selected on the basis of the most likely contributors being opposed to it. WhatamIdoing (talk) 01:18, 12 September 2014 (UTC)

• Support This is one WikiProject attempting to study something to see if it 1) results in harm 2) is useful It is the result of hearing concerns from academics regarding the transparency of Wikipedia Doc James (talk · contribs · email) (if I write on your page reply on mine) 23:05, 11 September 2014 (UTC)
• Support Health articles are different from other kinds of articles because they are under extreme scrutiny from media and research organizations, because some high-level expertise will be required to make them all as good as we would, and because more than some other parts of Wikipedia the health articles need to be made to be as good as possible as quickly as possible so the interest in meeting needs of potential new editors is greater in this space. For examples of the scrutiny of health content, see Wikipedia:WikiProject_Medicine/Research_publications for published. No other WikiProject is pressured to respond to such assertive, off-wiki contributors to Wikipedia as those who publish in this list. Greater recognition of contributors is a recurring demand of critics in Wikipedia's health content.

To help recruit more medical professionals into contributing to Wikipedia, I feel that easier access to information about the contributors to Wikipedia's health content would be a step toward meeting the needs of the demographic we want to invite. This byline project has the potential to better match Wikipedia's health content with the expectation of traditional academia, who cannot currently be credited for their contributions to Wikipedia in a comparable that they could if they published in traditional channels. This change has little chance of harming the Wikipedia community and could be a powerful bridge to getting health professionals to recognize Wikipedia as a place where any health professional should consider sharing encyclopedic content of the kind Wikipedia strives to provide.

Wikipedia is the most consulted source of health information for some demographics, and this project is a great experiment for Wikipedians, readers, potential new contributors, research organizations, and those that like reporting on Wikipedia's health information in academic articles. I am not convinced that claims of harm from this experiment outweigh the likely benefits. Blue Rasberry (talk) 00:19, 12 September 2014 (UTC)

• Comment See WP:Wikicredit for discussion of the general concept of giving credit on Wikipedia. Blue Rasberry (talk) 00:20, 12 September 2014 (UTC)
• Moderately oppose The link does not provide increased ability to research the contributors to an article, but merely makes it more convenient. Thus those who are seriously concerned about the credibility of an article can already find the information, and we are mainly making it easier for casual users to find it. My concern is that the former group probably includes most of those whom the proposal is intended to influence, and the latter group may include more activists and those who may be interested in outing or harrassing editors. We have lots of IP editors here who are anti-psychiatry activists, engaged in lawsuits against manufacturers (fluoroquinolones, Paxil, olanzapine, Accutane, Propecia, and others), and I'm not sure its a completely benign thing to encourage them to identify article contributors. I've already been the topic of a series of articles on one anti-psychiatry website and been tracked down by one activist who contacted me by phone to demand reversion of my edits.

Second, since most editors do not self-identify, I'm not sure how making this information more convenient increases crediblity.Formerly 98 (talk) 16:08, 12 September 2014 (UTC)

Interesting! Ping Doc James, RexxS, Edokter: What is the status of this, not started yet, already ended, evaluated? This feature is similar to tools on german Wikipedia, that are becoming more popular:

• wikihistory @tools.wmflabs by user:APPER, WikiHistory-user script showing contributors with percent (calculation see de:user:APPER/WikiHistory/Autorenbestimmung), see de:user:Atlasowa/edit history visualization#WikiHistory, APPER

• de:user:Schnark/js/artikel-statistik via user script, see de:user:Atlasowa/edit_history_visualization#Schnark_artikel-statistik

I think it's really useful stuff. What do you think? --Atlasowa (talk) 22:29, 12 March 2015 (UTC)

What you have is excellent. I love how it color codes who write what and how much of the content it represents. We were unable to get consensus to trial our idea here on En Wikipedia. The page we were linking to was not organized well enough and not reliable enough. We have not got around to improving it further. Doc James (talk · contribs · email) 22:47, 12 March 2015 (UTC)

dropdown-menus-vector/nonvector

I notice that two recent additions, i.e.

• dropdown-menus-vector[ResourceLoader|hidden|rights=hidden]|dropdown-menus-vector.js
• dropdown-menus-nonvector[ResourceLoader|hidden|rights=hidden]|dropdown-menus-nonvector.js|dropdown-menus.css

do not specify |skins= - presumably, these two gadgets don't work on all skins, hence their naming. --Redrose64 (talk) 20:02, 19 January 2015 (UTC)

Correct. Loading is governed from MoreMenu (which will be renamed at a later stage). -- [[User:Edokter]] {{talk}} 23:11, 19 January 2015 (UTC)

Teahouse description

I notice that the gadget is described as "Wikimedia Foundation's Teahouse project" but as far as I remember it's not a Foundation project. I propose we change it into something that describes what the teahouse actually is for... --TheDJ (talk o contribs) 09:14, 4 April 2015 (UTC)

@TheDJ: makes sense to me. I made a request on the Teahouse hosts forum. Thanks, - J-Mo ^{Talk to Me} _{Email Me} 20:59, 21 April 2015 (UTC)

 Done ...by Writ Keeper [3] - J-Mo ^{Talk to Me} _{Email Me} 21:35, 21 April 2015 (UTC)

mobile-sidebar

please add "skin=vector" to this gadget, until the script is fixed to support other skins. peace - ???????? (aka kipod) (talk) 02:37, 16 February 2016 (UTC)

type=general

Should type=general be added to gadgets that show warnings about it? Such as: "Gadget "ReferenceTooltips" styles loaded twice. Migrate to type=general. See <https://phabricator.wikimedia.org/T42284>." --Amir E. Aharoni (talk) 08:53, 13 October 2016 (UTC)

I did it for a few gadgets and they all seem to work. More may be needed--I didn't check every single one. --Amir E. Aharoni (talk) 10:42, 17 February 2017 (UTC)

@Amire80: Pretty sure the watchlist one should be a type=styles, not general. --TheDJ (talk o contribs) 10:48, 17 February 2017 (UTC)

True, thanks. --Amir E. Aharoni (talk) 10:53, 17 February 2017 (UTC)

New rules for hidden gadgets

Later this week (December 1st), a change will go into effect on English Wikipedia affecting gadget definitions: "Gadgets will have a new option called "hidden". This means you can register gadgets that can't be turned on or off from the preferences page. Hiding gadgets was already possible by using [rights=hidden]. You should now use [hidden] instead. [rights=hidden] in old gadgets should be changed to [hidden]." Kaldari (talk) 21:53, 28 November 2016 (UTC)

Thank you, we already have both parameters, suppose we can remove the deprecated parameter after the update. -- xaosflux ^Talk 00:20, 29 November 2016 (UTC)

Could someone remove the obsolete hack "|rights=hidden"? The extension now supports the option natively (see phab:T33150 and mw:Special:Diff/2288649). Helder 20:41, 27 December 2016 (UTC)

 Done -- xaosflux ^Talk 14:48, 28 December 2016 (UTC)

Add responsiveContent gadget

I request the following edits:

• Copy User:TheDJ/responsiveContent.css to MediaWiki:Gadget-responsiveContentBase.css. (Note, this triggers an error, because the validator does not recognise the valid @supports rule).
• Copy User:TheDJ/responsiveContent.js to MediaWiki:Gadget-responsiveContent.js.
• Add * responsiveContentBase[ResourceLoader|type=styles|hidden|skins=vector]|responsiveContentBase.css to MediaWiki:Gadgets-definition in the Browsing section.
• Add Improved appearance for mobile, narrow and wide screens. Used by Gadget-responsiveContent to MediaWiki:Gadget-responsiveContentBase
• Add * responsiveContent[ResourceLoader|type=general|skins=vector|peers=responsiveContentBase]|responsiveContent.js to MediaWiki:Gadgets-definition in the Appearance section.
• Add Improved appearance for mobile, narrow and wide screens. [[User:TheDJ/responsiveContent|documentation]] to MediaWiki:Gadget-responsiveContent

This was previously discussed at Wikipedia:Village_pump_(technical)/Archive_153#Responsive_content_gadget. Identified issues have since been dealt with. --TheDJ (talk o contribs) 11:09, 3 March 2017 (UTC)

@TheDJ: Did these edits. Jo-Jo Eumerus (talk, contributions) 15:59, 3 March 2017 (UTC)

ResourceLoader for CSS

@TheDJ: Marking explicitly as ResourceLoader compatible is not needed for CSS as it's always considered as compatible; if you really want to mark it as such, please note that it's ResourceLoader and not ResourceLoaders. --Tacsipacsi (talk) 21:34, 28 March 2017 (UTC)

Blackskin for Vector

  Blackskin[ResourceLoader|skins=monobook,vector]|Blackskin.css  

-- Dispenser 22:04, 11 April 2017 (UTC)

Tested and done. --TheDJ (talk o contribs) 07:32, 12 April 2017 (UTC)

Make WatchlistBase hidden

The WatchlistBase gadget should be marked 'hidden' as it's not really a gadget. It provides the base styles for the watchlist needed by other gadgets. It's already marked as 'default' and shouldn't be turned off. Kaldari (talk) 17:32, 21 June 2017 (UTC)

 Done -- xaosflux ^Talk 02:07, 22 June 2017 (UTC)

@Kaldari and Xaosflux: This change just broke my preferred watchlist configuration. I had all of the gadgets disabled, to give me the default MW presentation, so I had a consistent appearance across multiple wikis. Hiding the base has broken that for me. Murph9000 (talk) 17:52, 22 June 2017 (UTC)

 Undone @Murph9000: - change has been reverted - can you confirm you are back to normal? -- xaosflux ^Talk 18:35, 22 June 2017 (UTC)

@Xaosflux: Yes, I had to go into preferences and disable it again (and interestingly, it wasn't forced on (with the default + hidden config) until I changed something unrelated in prefs). With all watchlist gadgets disabled again, I'm back to my preferred MW default watchlist. Thanks for the quick response! Murph9000 (talk) 18:48, 22 June 2017 (UTC)

@Xaosflux and Murph9000: I think what actually needs to happen here is for WatchlistBase to be marked as just hidden, not hidden and default. It is listed as a peer dependency by the other Watchlist gadgets that need it, and if those gadgets are turned off, WatchlistBase should not be loaded. Can we try that out? Kaldari (talk) 20:31, 22 June 2017 (UTC)

@Kaldari: care to try that out on testwiki first? I have not delved far in to this, but am a bit hesitant to just turn off something we have on by default, especially as it is specifically labeled as "do not disable". The most recent editors of this are: @Krinkle: and @MSGJ: who may have some more input. -- xaosflux ^Talk 01:57, 23 June 2017 (UTC)

@Kaldari and Xaosflux: I don't think (-default, +hidden) would work well with the current implementation of the modules. The base suppresses standard MW functionality, with the other modules adding functionality back or adding new functionality. It seems to have been done that way to give a default level which is minimal (less than MW), then optional additional features. My use case is I'd just like the standard MW functionality without the extra CSS, so I turn all of them off. What's really needed may be support for radio options, selection lists, and generally more advanced configuration in gadget preferences; to give things like {off, reduced, A, B, A+B}. Murph9000 (talk) 08:10, 23 June 2017 (UTC)

@Kaldari, Xaosflux, and Murph9000: IIRC, the sordid history is that "the community" asked for watchlist bolding to be enabled, then when that was done "the community" (different people) had a fit and changed MediaWiki:Common.css to hide it by default for everyone. Eventually that migrated into a default gadget to hide the bolding, with other gadgets to override that gadget. IMO the best solution would be to lose the default gadget and let people who hate it enable the gadget to turn it off. Anomie? 14:54, 23 June 2017 (UTC)

Disabled request as there is not yet an actionable request here -- Martin (MSGJ · talk) 10:51, 27 June 2017 (UTC)

ShowJavascriptErrors

TheDJ: I'm confused. Doesn't MediaWiki:Gadget-ShowJavascriptErrors.js need mediawiki.notify? Nirmos (talk) 19:21, 25 August 2017 (UTC)

Good point. (it'as autoloaded by mediawiki.util, so you usually it'll be ok, but yeah.. --TheDJ (talk o contribs) 20:03, 25 August 2017 (UTC)

Beta feature on watchlists and gadgets compatibility

Hello

The Global Collaboration team will release soon a new presentation and more features on watchlists. This Beta feature introduces a new design for some features:

• as you know, each new change is an item on a list. Unseen changes are displayed in bold with the list bullet filled. Seen changes are in normal typeface and the list bullet is unfilled.
• it is possible to highlight some particular results (example on RCs, needs to enable the Beta). The highlight also restyles the list bullet with the chosen color. If two highlighting options match on one change, two bullets, with the two colors will be displayed (example).

You can try them on Watchlists on the beta wiki (don't forget to enable the 'New filters for edit review' Beta there).

Two existing gadgets can significantly change the user experience we want to propose:

• WatchlistGreenIndicators (displays green collapsible arrows and green bullets for changed pages in your watchlist, page history and recent changes -- I include the Mono version in it) is enabled by default. Unseen changes have a green dot replacing the usual bullet. This gadget is not compatible with the contextual bullets we want to provide. Our bullets have the same purpose as the green dot and can replace it.
• WatchlistChangesBold (displays pages on your watchlist that have changed since your last visit in bold) is not enabled by default. When activated, this gadget removes the bold experience we want to provide, which may complicate the experience so as the feedback process.

Beta's goal is to have a test phase, that will allow users to provide feedback on everything we propose. We want to provide the same experience on all wikis. To achieve this, we want to make the two gadgets inactive only on the Beta Watchlist (no visible changes for non-Beta testers). We can do those changes, but we want to have your opinion about them first.

The Beta release is on the 5^th, so we will take a decision at the beginning of next week, based on your actionable and consistent with the project opinions.

Thank you! Trizek (WMF) (talk) 18:05, 1 September 2017 (UTC)

@Trizek (WMF): To correct this slightly, we indeed want to show the bold to users of the beta feature. The bold is removed by MediaWiki:Gadget-WatchlistBase.css currently. We would like to change this so users of the beta feature get bold by default. Mattflaschen-WMF (talk) 18:18, 1 September 2017 (UTC)

We've had some hellish response by editors the last time we messed with those things, and the stack of specificity overrides that various gadgets have is HUGE in this area. Maybe we can do something like this: User:TheDJ/deleteWatchlistModifications.js ? It's not ideal, but it's prolly the only way to make sure that it won't affect users outside of the beta. --TheDJ (talk o contribs) 20:21, 1 September 2017 (UTC)

@TheDJ: I don't think that's necessary. We can have different CSS for RCFilters-on/RCFilters-off using an ancestor class. I have working CSS up now to test. See phab:T175062. Mattflaschen-WMF (talk) 02:46, 12 September 2017 (UTC)

Source of the article : Wikipedia