Jump to content

MediaWiki talk:Gadgets-definition/Archive 1

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

Admin Gadgets

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.

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

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)

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)

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

Opening external links in a new tab/window: 

addOnloadHook(function() {
    var alinks = document.getElementById('content').getElementsByTagName("a");
    var tablink, sitename;
    for (var i = 0, leng = alinks.length; i < leng; i++) {
        tablink = alinks[i];
        if (tablink.className.indexOf("external") != -1 && tablink.href.indexOf(wgServer) != 0)
            tablink.target = "_blank";
    }
});

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)

Added {{editprotected}} – any objections to including this? GracenotesT § 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. 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 ∴ 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. 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 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. GracenotesT § 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)

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)

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

→AzaToth 00:17, 12 January 2008 (UTC)

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)

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)

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)

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 • C • 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 • C • L) 18:50, 2 July 2009 (UTC)

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)

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. --Ckatzchatspy 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? --Ckatzchatspy 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)

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.wiki.x.io, 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:

The search gadget:

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

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)
Usage share of web browsers.
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:

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:

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)

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, [1] 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)

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)

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.[2] 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)

WP MED 3 month trial

Screenshot with the proposed change to the page circled in magenta to make it easier to find.

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:

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)

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

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)

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)

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 <http://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 • contribs) 10:48, 17 February 2017 (UTC)
True, thanks. --Amir E. Aharoni (talk) 10:53, 17 February 2017 (UTC)

Add responsiveContent gadget

I request the following edits:

This was previously discussed at Wikipedia:Village_pump_(technical)/Archive_153#Responsive_content_gadget. Identified issues have since been dealt with. —TheDJ (talk • 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 • 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)
eraser 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 • contribs) 20:03, 25 August 2017 (UTC)

Beta feature on watchlists and gadgets compatibility

Tracked in Phabricator
Task T175062

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 5th, 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 • 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)

MobileMaps error

Hi,

I keep seeing this in the JavaScript console in desktop Firefox when I simply open English Wikipedia articles:

Error: Unknown dependency: ext.gadget.MobileMaps Stack trace: sortDependencies@http://en.wiki.x.io/w/load.php?debug=false&lang=en&modules=jquery%2Cmediawiki%7Cmediawiki.legacy.wikibits&only=scripts&skin=vector&version=14kbqyi:159:205 resolveStubbornly@http://en.wiki.x.io/w/load.php?debug=false&lang=en&modules=jquery%2Cmediawiki%7Cmediawiki.legacy.wikibits&only=scripts&skin=vector&version=14kbqyi:160:353 load@http://en.wiki.x.io/w/load.php?debug=false&lang=en&modules=jquery%2Cmediawiki%7Cmediawiki.legacy.wikibits&only=scripts&skin=vector&version=14kbqyi:170:972 @http://en.wiki.x.io/wiki/Pedro_II,_Piau%C3%AD:9:4 startUp@http://en.wiki.x.io/w/load.php?debug=false&lang=en&modules=startup&only=scripts&skin=vector:85:372 script.onload@http://en.wiki.x.io/w/load.php?debug=false&lang=en&modules=startup&only=scripts&skin=vector:85:764 EventHandlerNonNull*@http://en.wiki.x.io/w/load.php?debug=false&lang=en&modules=startup&only=scripts&skin=vector:85:708 @http://en.wiki.x.io/w/load.php?debug=false&lang=en&modules=startup&only=scripts&skin=vector:1:743 load.php:177:79

This has been happening for a few months. I strongly suspect that this is not supposed to happen.

If it's "MobileMaps", why is it loaded on the desktop at all?

I suspect that TheDJ has something to do with it ;) --Amir E. Aharoni (talk) 07:09, 18 February 2018 (UTC)

MobileMaps is in the list (Test section), explicitly marked as mobile-only. It seems that this makes it unknown on desktop. So I think it's not a big problem, maybe a check could be inserted to make sure it can be loaded (although I have no idea where does it come from, I found only two, commented-out references to it). --Tacsipacsi (talk) 08:50, 18 February 2018 (UTC)
But that's the part I don't understand: if it's mobile-only, why does the desktop site try to load it at all? --Amir E. Aharoni (talk) 11:22, 18 February 2018 (UTC)
Because some code doesn't mind if it's not available, and just uses mw.loader.load( 'ext.gadget.MobileMaps' ); I don't know what. --Tacsipacsi (talk) 19:50, 18 February 2018 (UTC)
@Amire80: This is phab:T171180 —TheDJ (talk • contribs) 09:24, 19 February 2018 (UTC)
Thanks! --Amir E. Aharoni (talk) 10:40, 19 February 2018 (UTC)

removeAccessKeys

Hello, MediaWiki:Gadget-removeAccessKeys.js looks for an optional array window.removeAccessKeys, to be defined in the user's javascript. Thus, the dependency user should be added to this gadget's entry. Regards, Od1n (talk) 17:09, 24 February 2018 (UTC)

user is for other purposes. This gadget waits until the page load, so user JavaScript should have been run by that. —Tacsipacsi (talk) 20:27, 24 February 2018 (UTC)
It's quite tricky, I know... user is not mediawiki.user. The former is really to ensure beforehand loading of <user>/common.js, <user>/common.css, etc. References: search 'user' in Resources.php, then see ResourceLoaderUserModule.php. Od1n (talk) 11:43, 26 February 2018 (UTC)
Oh, I see. However, as I said, not declaring the dependency should have no impact on the results, not even in edge cases. (It doesn’t mean that we should not declare it, but I don’t see it as an absolute and urgent necessity.) —Tacsipacsi (talk) 19:26, 26 February 2018 (UTC)
The "DOM ready" event makes the code execute later, but it's really a different thing. Maybe it works in practice, but you should consider it as luck. Just add the dependency to do things properly. Indeed this fix is not an urgent one, but it's still a fix, and a good practice to spread. Od1n (talk) 12:49, 28 February 2018 (UTC)
I didn’t say it should be leaved unfixed, feel free to ask an admin to do that (I’m not one). —Tacsipacsi (talk) 14:14, 28 February 2018 (UTC)
Sure thing, I have just added the template for requesting edit. Od1n (talk) 23:45, 28 February 2018 (UTC)

Please clarify exactly what change needs to be made? — Martin (MSGJ · talk) 18:05, 1 March 2018 (UTC)

Replace existing line with this one:
removeAccessKeys[ResourceLoader|dependencies=user,jquery.accessKeyLabel]|removeAccessKeys.js
Od1n (talk) 18:49, 1 March 2018 (UTC)
Thanks and  Done — Martin (MSGJ · talk) 20:09, 1 March 2018 (UTC)

Wiki For All: MediaWiki for People with Visual Challenges.

The intrinsic value of MediaWiki is that it enables human communication, commerce, and opportunities to share knowledge. In contributing gadgets to MediaWiki, my primary objectives is to make these benefits available to all people, whatever their hardware, software, network infrastructure, native language, culture, geographical location, or physical or mental ability.

The WikiForAll project focuses on accessibility of MediaWiki to people with disabilities — people with auditory, cognitive, neurological, physical, speech, and visual impairments.

The gadget below is a project in continuous development that focuses on receivable information/user interface including text size, text style and text layout, color and contrast and text-to-speech (speech synthesis)

User:WebIntegrity/common.js —Preceding undated comment added 17:27, 29 April 2018 (UTC)

a project in continuous development - it's not changed since July 2016. --Redrose64 🌹 (talk) 07:16, 30 April 2018 (UTC)
@WebIntegrity: I would have no problem adding this, really encourage it even, but it does have to actually work... Half the buttons do nothing right now. —TheDJ (talk • contribs) 08:34, 30 April 2018 (UTC)
Ah, it would help if it actually loaded it's CSS...
  • The dark skin only seems to work for Vector. As such, the option should be limited to Vector
  • The options are inserted straight under the header for Tools, which looks a bit weird. That should be cleaned up.
I guess other than that, it's a start... —TheDJ (talk • contribs) 10:02, 30 April 2018 (UTC)

Switching watchlist notices to use web storage instead of cookies

Not directly related to this page, but I figured the audience would be more suitable. I'm proposing we move geonotices away from cookies and start using localstorage instead. The reason for this is that cookies get transmitted unnecessarily. For this we would add the mediawiki.storage dependency to geonotice and watchlist core modules in the gadgets. The code would look something like: [4] and [5] respectively. It would have backwards compatibility for already hidden notices via cookies during the transition period.

Alternatively, I have even considered moving notices into (invisible) userpreferences. This should be possible with the API, but we would need to protect against large keys/ids for the notices and a few other potential safety issues. It would have the benefit of really dismissing a notice on all your computers, but it brings more unknowns (like how does that work with globalpreferences, harder to reset manually etc) —TheDJ (talk • contribs) 09:02, 14 June 2018 (UTC)

@TheDJ: I'm a bit behind on localstorage mechanics, is this what we are already using for CentralNotice dismissals? — xaosflux Talk 22:35, 14 June 2018 (UTC)
@Xaosflux: Correct. Although CN still uses cookies for it's session management, all dimiss and all other information for CN is in Web storage. —TheDJ (talk • contribs) 05:44, 15 June 2018 (UTC)
Geonotice is now switched —TheDJ (talk • contribs) 16:39, 17 June 2018 (UTC)
Watchlist is now switched as well. —TheDJ (talk • contribs) 20:48, 20 June 2018 (UTC)
@TheDJ: still using the cookie=n syntax for new messages? — xaosflux Talk 00:44, 21 June 2018 (UTC)
Yup, didnt change anything about the messages structure. —TheDJ (talk • contribs) 10:21, 21 June 2018 (UTC)

Protected edit request on 13 January 2019

The first line currently reads: 

<noinclude>'''Changes to this page should first be discussed on [[Wikipedia:Village pump (technical)]] or [[Wikipedia_talk:Gadget]].'''

Please change it to: 

<noinclude>'''Changes to this page should first be discussed on [[Wikipedia:Village pump (technical)]] or [[Wikipedia talk:Gadget]].'''

The difference? Wikipedia_talk:Gadget vs Wikipedia talk:Gadget (removing the underscore).

Thanks, --DannyS712 (talk) 01:36, 13 January 2019 (UTC)

 Done — xaosflux Talk 02:08, 13 January 2019 (UTC)

Add table of contents?

Our gadget list is long. MediaWiki:Gadgets-definition displays a table of contents on the page itself. Is it possible to make one at Special:Preferences#mw-prefsection-gadgets? "Browsing" and the other headings do not currently have an id in the html. I guess that could be requested at Phabricator but without that I imagine something like changing == browsing == to == <span id="Browsing">browsing</span> ==, or saying <span id="Browsing">browsing</span> in MediaWiki:Gadget-section-browsing. Then it should be possible to make a TOC manually in MediaWiki:Gadgets-prefstext with links like [[#Browsing|Browsing]]. I don't know whether MediaWiki would accept anchors when it processes MediaWiki:Gadgets-definition or MediaWiki:Gadget-section-browsing. PrimeHunter (talk) 11:51, 28 February 2019 (UTC)

I don’t think adding IDs to MediaWiki:Gadgets-definition would work—I think it would at most cause MediaWiki to try to load MediaWiki:Gadget-section-<span_id=* pages, or just fail somehow. Maybe adding these IDs to MediaWiki:Gadget-section-* pages could work. But asking on Phabricator to add IDs based on the internal section names (which are given as section titles on MediaWiki:Gadgets-definition) seems a better solution for me, especially as that can be more relied upon than a bunch of other pages, and also makes it easier to create the TOC automatically using Lua. —Tacsipacsi (talk) 09:58, 2 March 2019 (UTC)
It's a good idea while we have that tab. All of the pages could use a table of contents right now.
The longer-term improvement might be integration of gadgets on to separate preference pages. That way someone looking for stuff about the watchlist would find it on the watchlist tab. --Izno (talk) 14:20, 2 March 2019 (UTC)
Added a phab task. --Izno (talk) 21:48, 4 March 2019 (UTC)

Gadget-extra-toolbar-buttons

The old toolbar is going away sooner rather than later (WP:THURSDAY). See WP:VPT#Support ends for the 2006 wikitext editor. I suspect this gadget can be removed as a result. --Izno (talk) 23:18, 29 October 2018 (UTC)

For the benefit of latecomers: Wikipedia:Village pump (technical)/Archive 171#Support ends for the 2006 wikitext editor. - dcljr (talk) 05:59, 16 September 2019 (UTC)

Interface-protected edit request on 14 November 2019

Please wrap and edit in 

<span class="sysop-show">and edit </span>

since non-admins cannot edit the descriptions. Thanks, --DannyS712 (talk) 18:22, 14 November 2019 (UTC)

Why is it worth it? These are just quick links, and should be kept at code level as simple as possible to avoid being misinterpreted by the extension. I think most people who get here already know a bit about access levels and doesn’t get very disappointed when finds out that the descriptions aren’t freely editable. By the way, .sysop-show would hide the text from eventual interface administrators who are not “regular” admins, while interface admins can edit the descriptions as well. (There are currently no such users on English Wikipedia, but it’s technically possible. For example, this is the case for me on the Hungarian Wikipedia.) —Tacsipacsi (talk) 11:00, 15 November 2019 (UTC)
 Not done not really needed here. — xaosflux Talk 14:53, 15 November 2019 (UTC)
Did update the verbiage a bit. — xaosflux Talk 14:57, 15 November 2019 (UTC)

Gadget-teahouse.js inactive for 2 years now

MediaWiki:Gadget-teahouse.js has been inactive for 2 years so it should probably be removed from this page. – Thjarkur (talk) 19:33, 6 January 2020 (UTC)

minus Removed @Þjarkur: I've removed this from the definition. — xaosflux Talk 19:41, 6 January 2020 (UTC)
Thank you but shouldn't we remove the entire line? The option "Enable the Teahouse Ask a question feature" is still a part of Preferences even though the button doesn't do anything. – Thjarkur (talk) 02:00, 7 January 2020 (UTC)
@Þjarkur: is that CSS still otherwise being used at Wikipedia:Teahouse? — xaosflux Talk 02:03, 7 January 2020 (UTC)
No, it's just CSS accompanying this JS – Thjarkur (talk) 02:08, 7 January 2020 (UTC)
minus Removed the entire gadget line. — xaosflux Talk 03:12, 7 January 2020 (UTC)

Hide WatchlistBase.css?

Is there a good reason why we shouldn't hide the WatchlistBase.css gadget? It was pulled out of Common.css in 2015 (the watchlist has undergone a lot of changes...) but it's enabled by default and explicitly asks users not to disable it, so at the very least there's no reason for it to be visible? ~ Amory (u • t • c) 14:31, 4 October 2019 (UTC)

It appears to be hidden to me? --Izno (talk) 14:44, 4 October 2019 (UTC)
IIRC you're a timeless user, right? It's only loaded for vector, monobook, and modern. ~ Amory (u • t • c) 15:01, 4 October 2019 (UTC)
That would explain it. :D --Izno (talk) 15:53, 4 October 2019 (UTC)

Resurrecting an old section to note MediaWiki_talk:Gadgets-definition/Archive_1#Make_WatchlistBase_hidden from 2017. ~ Amory (u • t • c) 22:18, 2 March 2020 (UTC)

Delete unused messages

I think the following messages to make headings at Special:Preferences#mw-prefsection-gadgets have been unused since this 2011 edit:

I suggest deleting them as uncontroversial maintenance per WP:G6. There are no other unused messages of this type, based on comparing Special:PrefixIndex/MediaWiki:Gadget-section and the current MediaWiki:Gadgets-definition. The last message MediaWiki:Gadget-section-miscellaneous has never been used as far as I can tell. I guess Edoctor was planning to use it per the last post at MediaWiki talk:Gadgets-definition/Archive 1#Gadget tab structure, but it didn't happen in the edits at the time [6]. PrimeHunter (talk) 18:28, 22 May 2020 (UTC)

Ordinarily, I'd ask Erwin, but they left four years back. Their technical skills are greatly missed. --Redrose64 🌹 (talk) 19:33, 22 May 2020 (UTC)
FWIW, I was planning on proposing a restructuring of this page, just hadn't gotten around to it. Neither here nor there for this, but just to say I think it's worth rethinking this sort of thing. ~ Amory (u • t • c) 16:18, 23 May 2020 (UTC)

Move options for legacy editing toolbar closer together, clarify description for extra buttons more.

Under the == editing == heading, it currently looks like this: 

legacyToolbar[ResourceLoader]|legacyToolbar.js
refToolbar[ResourceLoader|default|dependencies=user.options,mediawiki.util]|refToolbar.js
refToolbarBase[ResourceLoader|hidden]|refToolbarBase.js
extra-toolbar-buttons[ResourceLoader|default]|extra-toolbar-buttons.js
extra-toolbar-buttons-core[ResourceLoader|hidden]|extra-toolbar-buttons-core.js

I propose this: 

legacyToolbar[ResourceLoader]|legacyToolbar.js
extra-toolbar-buttons[ResourceLoader|default]|extra-toolbar-buttons.js
extra-toolbar-buttons-core[ResourceLoader|hidden]|extra-toolbar-buttons-core.js
refToolbar[ResourceLoader|default|dependencies=user.options,mediawiki.util]|refToolbar.js
refToolbarBase[ResourceLoader|hidden]|refToolbarBase.js

To bring the relevant options for the legacy toolbar closer together.

Also propose that MediaWiki:Gadget-extra-toolbar-buttons should be changed to Add extra buttons to the legacy (2006) editing toolbar to make it really clear what these options do. This will make it match with MediaWiki:Gadget-legacyToolbar, which says Enable the legacy (2006) editing toolbar. This will be overridden by the "Enable the editing toolbar" option in the Editing tab.

It's kind of easier to understand what's going on when the wording stays the same -NottNott 14:23, 13 June 2020 (UTC)

Good ideas, I think;  Done Writ Keeper ⚇♔ 18:18, 15 June 2020 (UTC)

Twinkle dependencies are incomplete

Twinkle loads MediaWiki:Gadget-twinkleblock.js and the later uses `mw.Api()` so a dependency for `mediawiki.api` should be listed in Twinkle's definition. It is missing, and Twinkle works despite that only because mediawiki.api happens to be loaded faster than Twinkle code is executed by the browser. However, when in debug mode, you can occasionally get an error message about mw.api not being defined. Please consider adding mediawiki.api as a dependency in the definition. New definition would look like below. Thanks huji—TALK 14:23, 17 June 2020 (UTC) 

* Twinkle[ResourceLoader|dependencies=ext.gadget.morebits,ext.gadget.select2,mediawiki.api|rights=autoconfirmed|type=general|peers=Twinkle-pagestyles]|Twinkle.js|twinkleprod.js|twinkleimage.js|twinklebatchundelete.js|twinklewarn.js|twinklespeedy.js|friendlyshared.js|twinklediff.js|twinkleunlink.js|friendlytag.js|twinkledeprod.js|friendlywelcome.js|twinklexfd.js|twinklebatchdelete.js|twinklebatchprotect.js|twinkleconfig.js|twinklefluff.js|twinkleprotect.js|twinklearv.js|twinkleblock.js|friendlytalkback.js|Twinkle.css
 Done thank you for the info Huji. — xaosflux Talk 15:42, 17 June 2020 (UTC)

Remove mobile categories gadget

Now that mobile categories are enabled for registered users, we should probably just remove the gadget ? So remove the entire line beginning with MobileCategories. See also https://www.mediawiki.org/w/index.php?title=Topic:Wbq4re10yup0y61t —TheDJ (talk • contribs) 17:46, 28 June 2021 (UTC)

@TheDJ: is this phab:T152199? (That task appears to still be open?). — xaosflux Talk 18:15, 28 June 2021 (UTC)
And while logged in, I just went to this random article, and I don't see any categories. — xaosflux Talk 18:25, 28 June 2021 (UTC)
With the gadget on, I do see them, and they are not duplicated. Is that other discussion about the "mobile app" as opposed to all mobile users? — xaosflux Talk 18:32, 28 June 2021 (UTC)
Ping in to @Jdlrobson: from the other site's thread. — xaosflux Talk 18:34, 28 June 2021 (UTC)
While logged in, if you go to settings and enable "advanced mode" you'll see categories. With the gadget they will appear twice. I agree that the gadget is likely redundant now. Jdlrobson (talk) 18:59, 28 June 2021 (UTC)
Hmm, OK looks like we've got 3710 users using this - may be a good try of the "use the gadget to activate the preference and then disable itself" function. — xaosflux Talk 19:12, 28 June 2021 (UTC)
Looks to be: "mf_amc_optin": "0", to "mf_amc_optin": "1",. — xaosflux Talk 19:18, 28 June 2021 (UTC)

That seems like a good way to do it! Nice! Jdlrobson (talk) 18:47, 29 June 2021 (UTC)

 Done removed - didn't want to force-on "extra" advanced features that others may not want. — xaosflux Talk 14:27, 30 June 2021 (UTC)

Protected edit request on 8 October 2021

Replace the line: 

Navigation_popups[ResourceLoader|dependencies=mediawiki.user,mediawiki.util,user.options|type=general]|popups.js|navpop.css

with 

Navigation_popups[ResourceLoader|dependencies=mediawiki.api,mediawiki.user,mediawiki.util,user.options,mediawiki.jqueryMsg|type=general]|popups.js|navpop.css

This adds two dependencies so that these do not have to be late loaded by the Gadget itself. —TheDJ (talk • contribs) 21:21, 8 October 2021 (UTC)

 Done — xaosflux Talk 21:58, 8 October 2021 (UTC)

Edit request

−
* script-installer[ResourceLoader]|script-installer.js
+
* script-installer[ResourceLoader|dependencies=mediawiki.ui.button]|script-installer.js

Added .button, credit for Tacsipacsi for finding the correct dependency

http://en.wiki.x.io/wiki/User:Alexis_Jazz/reply-link?withJS=MediaWiki:Gadget-script-installer.js has an unstyled install/uninstall button. Adding an image anywhere on the page fixes it, presumably that causes the required CSS classes to be loaded. See mw:ResourceLoader/Core_modules#mediawiki.ui. @Enterprisey: fyi, and note that mediawiki.ui is deprecated in favor of OOUI. — Alexis Jazz (talk or ping me) 12:57, 12 December 2021 (UTC)

This change won’t fix it: withJS loads MediaWiki:Gadget-script-installer.js directly, it doesn’t use ResourceLoader, thus any dependencies specified here will not be loaded. Either this dependency should be loaded by MediaWiki:Gadget-script-installer.js itself, or MediaWiki:Common.js should provide a way to load gadgets using ResourceLoader, and the link should be changed to use the new feature, and then can this diff make difference. (mw:MediaWiki:Gadget-site.js has a withModule parameter that does exactly this.) —Tacsipacsi (talk) 14:22, 12 December 2021 (UTC)
Tacsipacsi, oh okay, I provided the withJS link for convenience, didn't know it made a difference. If you just enable the gadget and view User:Alexis Jazz/reply-link the button is also unstyled. That should be resolved by this diff, no? — Alexis Jazz (talk or ping me) 15:45, 12 December 2021 (UTC)
Yes, gadget enabling should be resolved by providing the correct dependency here. However, if I enable the gadget, the button isn’t unstyled for me, even though the mediawiki.ui RL module isn’t loaded, only mediawiki.ui.button (a dependency of compact language links), so I wonder whether mediawiki.ui is the correct dependency. —Tacsipacsi (talk) 17:16, 12 December 2021 (UTC)
Tacsipacsi, you are absolutely 100% right. I was wondering why mw.loader.using( [ 'mediawiki.ui' ] ).then( function () { button = '<form><button class="mw-ui-button mw-ui-progressive mw-ui-big">Uninstall</button></form>'; $( '.firstHeading' ).append(button) }) didn't add the styling. Replacing mediawiki.ui with mediawiki.ui.button makes it work. — Alexis Jazz (talk or ping me) 17:29, 12 December 2021 (UTC)

Protected edit request on 30 January 2022

For the dark-mode gadget, please add supportsUrlLoad boolean param, so that the preview link mentioned in its documentation continues to work. This param is documented here.

So, it will look like: 

* dark-mode[ResourceLoader|supportsUrlLoad|targets=desktop,mobile|skins=vector,monobook,modern,minerva,timeless]|dark-mode.css

– SD0001 (talk) 11:39, 30 January 2022 (UTC)

  •  Done, thanks. I will note that the "light mode" toggle doesn't actually do anything, but I'm guessing that's not really avoidable. (There's also a minor display issue on my screen, but I suspect that's due to some of my personal styling.) Regardless, I think it still does the job. Writ Keeper ⚇♔ 16:00, 31 January 2022 (UTC)
    Hmm, wonder of the other gadgets need it too, if they are calling eachother. — xaosflux Talk 16:17, 31 January 2022 (UTC)
    The toggle gadget relies on whether the user has turned the gadget on in Preferences, so if you already have the toggle on but the dark mode off and open the demo link, the toggle will think the dark mode is off when it's on, and if you toggle on that page the toggle will think the mode is on when it's off, and so on. That can be addressed by something like: 
    if (!isOn && mw.loader.getState('ext.gadget.dark-mode') === 'ready') {
	mw.user.options.set('gadget-dark-mode', 1);
	isOn = true;
}
    but I'm not sure if it's worth the trouble. Nardog (talk) 16:24, 31 January 2022 (UTC)
    Probably not, especially not just for a demo link of "what the dark css looks like" functionality. — xaosflux Talk 16:30, 31 January 2022 (UTC)

Protected edit request on 31 January 2022

Please add supportsUrlLoad to script-installer, per the above request, so templates like {{Script installer link}} continue to worj. Qwerfjkltalk 17:49, 31 January 2022 (UTC)

 Not done--this shouldn't be necessary for the script to work. Unless you want it to install scripts without first having installed the gadget, but that doesn't seem like a good idea. Writ Keeper ⚇♔ 19:05, 31 January 2022 (UTC)
Tend to agree there, that template seems somewhat dangerous already - probably shouldn't be used. — xaosflux Talk 19:11, 31 January 2022 (UTC)

Consider making User:Jdlrobson/mobilecontribs.js a default mobile gadget

See Wikipedia:Village pump (technical)#The style of Special:Contributions on mobile version has been changed for more background. Not sure what the criteria are for making this a "default" on mobile gadget, but given the disruption caused, it seems like it should be considered (see "We need interface administrator to fix this"). Jdlrobson (talk) 00:03, 15 February 2022 (UTC)

@Jdlrobson: so that would make enwiki appear different from all other projects - not sure this is wise; also not a fan of pushing client-side hacks. If this is the desirable display state is there a phab open on it to set it (back) to that? — xaosflux Talk 01:46, 15 February 2022 (UTC)
That's a fairly sizeable gadget that we would be enabling as a default for the total of two people who were perturbed the change. Izno (talk) 02:13, 15 February 2022 (UTC)
Haven't done a close reading of the code yet, but at a glance, it looks like it needs some work before becoming a gadget; pretty sure the naked URL on line 5 isn't valid Javascript. Writ Keeper ⚇♔ 02:19, 15 February 2022 (UTC)
Huh? No, that's simply commented lines. Izno (talk) 02:35, 15 February 2022 (UTC)
Well, it is now. Writ Keeper ⚇♔ 02:46, 15 February 2022 (UTC)

If you'll don't want to make it as a gadget, then bring back the former style of it. Or make the current style as a gadget, then bring back the former one, it would be nice. I don't know why they changed the style of users contribution, while there is AMC that has this advance style. —Ctrlwiki (talk) 10:37, 15 February 2022 (UTC)

Same question as above, is there an open phab on this requested change? — xaosflux Talk 11:02, 15 February 2022 (UTC)
The task which led to this change was phab:T300185. The mobile version of the page was becoming a security risk and not keeping up to date with other changes.
We have plans to restore the headings in the page: phab:T301798.
There is no plan to bring back the design exactly as it was but we are keen on feedback to this phab:T293268#7709654 about specifically what is missed about the old version. Jdlrobson (talk) 16:42, 15 February 2022 (UTC)
Note I have not personally objected to making it a gadget, just objected to making it a default on gadget.
However, I am not personally a fan of these gadgets we seem to continue adding whenever the UI changes or something like the 2006 toolbar disappears. They are inevitably technical debt, for the same reasons they were removed or changed on the MediaWiki development side, except now there are N versions across M wikis. Izno (talk) 18:48, 15 February 2022 (UTC)

I only worried about the changes, cause when I look at my/others users contributions, it loads too long, than the former one. The advantage of the former one is, edits by the user is arranged per day, I easily find the day of the edits were made. The current one, every edits are combined, the words are too complicated to understand, and it loads too long. And it's weird because, in the original, the Watchlist, Page history, Users Contributions, all of them are the same style, which is good for simplified mobile view. Now, Users Contributions are different from them, really weird. —Ctrlwiki (talk) 10:25, 16 February 2022 (UTC)

If no one can bring the former style back, can anyone improve the current style and arrange the users edits to day by day like edits on February 1, 2022, so edits in a particular date can find more easily like the former style. —Ctrlwiki (talk) 10:49, 16 February 2022 (UTC)

Yes that is planned in phab:T301798.

Regarding inconsistency, unnfortunately the mobile versions of watchlist and page history are also security and maintenance problems, so those two pages will need to be eventually removed too, therefore it's imperative we learn from this experience to reduce the impact on mobile users when that happens. Jdlrobson (talk) 15:32, 16 February 2022 (UTC)

If you'll going to change the style of Page History and Watchlist, is there anything you can do to reduce the time of waiting? Or just remove the unnecessary features like tags, I hope you can do it. And what the securities you're talking about? —Ctrlwiki (talk) 22:30, 16 February 2022 (UTC)
Another thing I noticed in every listed edit that is inconsistent are the layers. When the title of the article is long, there are 4 layers, the first layer are Time, Date, and Bytes, the second layer is the Title, the third is the Edit summary, and the fourth is the Tags. But when the title of the article is short, there are only 3 layers, the first layer are Time, Date, Bytes and Title, the second is the Edit summary, the third is the Tags. So it's need a fix and should be always 4 layers to reduce the confusion. —Ctrlwiki (talk) 22:55, 16 February 2022 (UTC)
I think the reason why you change the style cause you want your script to use as a replacement, and make it as a gadget also. And if not, how the style has change without any interface administrator, or who are the people who change it, are they have special permissions to change something in interface without notifying users? —Ctrlwiki (talk) 23:41, 16 February 2022 (UTC)

Wide-vector-2022 definition

Should the type= option for the wide-vector-2022 gadget definition be styles instead of general since it is only loading CSS styles? It would avoid a minor FOUC (most noticeable on slower devices) and instead load the gadget file much quicker upon page load. unshayani (talk) 05:55, 24 May 2022 (UTC)

 Done @Unshayani: I've udpated that. — xaosflux Talk 10:01, 24 May 2022 (UTC)
Thanks! unshayani (talk) 11:06, 24 May 2022 (UTC)

Protected edit request on 12 August 2022

Since the beginning of this year, gadgets can be set to load only on specific page actions. See mw:Extension:Gadgets#Options / gerrit:747112.

Please add the actions=edit directive to the following gadgets, as they only need to be available while editing (when action in the URL is either edit or submit):

  • refToolbar (default gadget)
  • DotsSyntaxHighlighter
  • ProveIt-classic

(not an exhaustive list, I suspect there are others too)

We can also do one-by-one just in case there's some issue. – SD0001 (talk) 16:56, 12 August 2022 (UTC)

I will look at this in the morning. Izno (talk) 04:45, 15 August 2022 (UTC)
 Done Izno (talk) 16:31, 15 August 2022 (UTC)
Retrieved from "http://en.wiki.x.io/w/index.php?title=MediaWiki_talk:Gadgets-definition/Archive_1&oldid=1191926321"