Wikipedia:Gadget/proposals/Archive 7

This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Archive 1

←

Archive 5

Archive 6

Archive 7

m:User:Erwin/SBHandler - Spam blacklist handler

Would anybody be able to port m:User:Erwin/SBHandler-gadget from meta to en.wikipedia. I have tried to port it manually (using my userspace) but it (at that time) did not work because of something that was not enabled on en.wikipeida. Moreover, I am not knowledgeable in the programming language of the script.

When ported, it would be great if it could be changed to handle the following:

MediaWiki talk:Spam-blacklist
- handling is pretty much the same as for meta, same templates and data is used
User talk:XLinkBot/RevertList
- handling is pretty much the same as for meta, same templates and data is used
the pages in the tree Wikipedia:WikiProject Spam/Local/ (e.g. [[1]]
- handling is pretty much the same, though a different 'indicator' template is used in the Discussion-section: {{LinkStatusLocal|en.wikipedia.org|open}} in stead of {{LinkStatus|open}} (the script changes the 'open'/'close'-state of the template on meta.
- (the discussion section is the only section that is edited by humans and this script, the rest of the pages is handled by COIBot)

When this is working, the script needs tweaking further, as I would like it to be able to handle additions to XLinkBot's revertlist - the 'add' function needs to be duplicated, one for 'add to blacklist' (adds to MediaWiki:Spam-blacklist) and one for 'add to revertlist' (adds to User:XLinkBot/RevertList).

Both the blacklist and the revertlist have logs, which should also be updated according to the addition of the links, these may be formatted slightly different from meta. I have no problem if XLinkBot's-RevertList-Log has to be unified to the Spam-blacklist-Log if that makes programming easier.

Feel free to enable this in e.g. my userspace first, I am of course very willing to test this first as a user-gadget, and I may be able to help tweaking it a bit (I do know how to program).

Thanks! --Dirk Beetstra ^{T C} 09:15, 25 April 2014 (UTC)

Thinking that maybe the sections on the spam wikiproject talkpage should also be enabled, so links can be blacklisted immediately from there (as long as it is properly logged to the discussion, it does not matter). --Dirk Beetstra ^{T C} 10:05, 25 April 2014 (UTC)

Useful tool globally, a local rendition would most certainly be useful. Quick and most importantly LOGS! — billinghurst sDrewth 16:01, 25 April 2014 (UTC)

I'll see if I can get it to work tomorrow.—cyberpower ^Chat_Online 20:33, 25 April 2014 (UTC)

On second thought, looking at the code with my rudimentary JS knowledge, it would be in better hands of a more experienced user.—cyberpower ^Chat_Online 02:22, 27 April 2014 (UTC)

I believe Excirial (Excirial—Cyberpower678) may be able to help.—cyberpower ^Chat_Online 17:25, 27 April 2014 (UTC)

Sorry, I meant Equazcion. (Equazcion—Cyberpower678) —cyberpower ^Chat_Online 17:30, 27 April 2014 (UTC)

Bumping thread. Guy (Help!) 19:57, 22 May 2014 (UTC) Any progress on this? It's a great idea. Guy (Help!) 19:56, 22 May 2014 (UTC)

Bumping thread again. Can s.o. please have a look at the implementation of this. --Dirk Beetstra ^{T C} 12:52, 4 August 2014 (UTC)

Bumping thread again. --Dirk Beetstra ^{T C} 06:51, 13 October 2014 (UTC)

Bumping thread. --Dirk Beetstra ^{T C} 11:54, 24 November 2014 (UTC)

Bumping thread. --Dirk Beetstra ^{T C} 03:10, 19 January 2015 (UTC)

Bumping thread. --Dirk Beetstra ^{T C} 03:23, 3 March 2015 (UTC)

@Beetstra: Just giving advice from my own observations, you may have to reach out beyond this venue to get any attention. I'd recommend WP:VPR or WP:VPT if you haven't tried that already. Best — MusikAnimal ^talk 04:40, 3 March 2015 (UTC)

@MusikAnimal: Don't remember if that was tried. I may 'canvass' those venues, thanks for the heads up. --Dirk Beetstra ^{T C} 04:47, 3 March 2015 (UTC)

I am however not sure if it belongs on any of those - it is not something for the MediaWiki developers (this is for local developers), nor a proposal for some change .. --Dirk Beetstra ^{T C} 04:49, 3 March 2015 (UTC)

I'm confused, are you just looking for another JS developer to look over it? I happen to fall in that category, though I'm not very familiar with the spam blocklist or how that works. Where is the source? — MusikAnimal ^talk 05:02, 3 March 2015 (UTC)

The code is on meta, described in m:User:Erwin/SBHandler. On meta, it adds 'add', 'remove', and 'close' buttons to all sections on m:Talk:Spam blacklist and to the discussion section of the reports in the XWiki-tree of COIBot, e.g. m:User:COIBot/XWiki/1.fm (this is one example report, there are bot generated reports for many domains, all prefixed with 'User:COIBot/XWiki'. Clicking the 'add' button on that section runs the script, and the reported domain is blacklisted (added to m:Spam blacklist and logged to the current log.

Here, it should 'read' from MediaWiki talk:Spam-blacklist and all domains under 'Wikipedia:WikiProject Spam/Local' (e.g. Wikipedia:WikiProject Spam/Local/iiitdm.in), and upon pressing 'add' add the reported domain to MediaWiki:Spam-blacklist and log it appropriately. --Dirk Beetstra ^{T C} 05:29, 3 March 2015 (UTC)

For m:Talk:Spam blacklist, clicking 'add' does the following sequence: diff, diff, and diff; for one of the COIBot-reports: diff, diff, diff. There are also 'closed' and 'reverted' buttons, which resp. do diff and diff (one edit only), and 'remove' which does diff, diff and diff. --Dirk Beetstra ^{T C} 05:57, 3 March 2015 (UTC)

Bumping thread. --Dirk Beetstra ^{T C} 04:25, 22 April 2015 (UTC)

HideSandboxLink

mw:Extension:SandboxLink was enabled on enwiki and the old mySandbox gadget was removed. This means that there is no easy way for users to disable the Sandbox link.

I am proposing a CSS-only gadget to replace mySandbox to hide the personal sandbox link added by mw:Extension:SandboxLink to the personal tools menu:

/*  _____________________________________________________________________________
 * |                                                                             |
 * |                    === WARNING: GLOBAL GADGET FILE ===                      |
 * |                  Changes to this page affect many users.                    |
 * | Please discuss changes on the talk page or on [[WT:Gadget]] before editing. |
 * |_____________________________________________________________________________|
 *
 * Hide personal sandbox link (added by [[mw:Extension:SandboxLink]]) from the personal tools menu */
 */

#pt-sandbox { display: none; }

--Ahecht (TALK
PAGE) 21:07, 9 April 2015 (UTC)

No. Let's break routine here and not deploy a gadget to reverse any little software change that is rolled out. There were 62 wikis with a default-enabled gadget to show the sandbox link, so obviously there was a need, and now it has been incorporated into the software. We also need to look out for option bloat. -- [[User:Edokter]] {{talk}} 22:03, 9 April 2015 (UTC)

That's nonsense, sorry. There is also a need for having an easy removal option. Replacing that gadget is surely not a bloat. --Leyo 22:10, 9 April 2015 (UTC)

Any needless option removed is good. Can you demonstrate the need to add an option to remove the link? -- [[User:Edokter]] {{talk}} 22:12, 9 April 2015 (UTC)

A need? No. Nor is there a need to support any skins other than Vector, or to not show green bullets in the watchlist, or to show changed pages in bold, or to change the new section tab to a + sign, or to justify paragraphs, or to move section edit links, or to display diffs with the old colors, or to change the edit box font, or to make any of the dozens of other cosmetic changes possible in Preferences. However, while I don't have actual stats, I am sure that there were many editors that had disabled the mySandbox gadget out of personal preference, constrained screen width, or a variety of other reasons. A quick search showed complaints at WP:VPT#Sandbox link and mw:Help talk:Extension:SandboxLink. --Ahecht (TALK
PAGE) 22:41, 9 April 2015 (UTC)

I'm leaning towards Edokter's opinion on this one. Our list of Gadgets is pretty huge and we could theoretically add a separate gadget for hiding pretty much every UI element that a user might not want or need. Instead, we should either just use our User CSS (since that's what it's there for), or write a more comprehensive gadget that gives you a stripped down UI (rather than just hiding one link). Giving the user more and more customization options eventually hits the law of diminishing returns, so we should be conservative in adding new ones. Kaldari (talk) 23:43, 21 April 2015 (UTC)

The best alternative IMO would be to have the hiding option at Special:Preferences#mw-prefsection-rendering. --Leyo 08:17, 22 April 2015 (UTC)

That is a terrible idea. Actually, I'm so fed up with this kind of stuff, that I actually have been thinking about it quite a bit. The problem summarizes basically as: "We have 10000 UI elements and you can probably for each of those elements find one or more users who would like to hide it. 10000 UI options don't scale". So my idea was actually, that we could make a gadget that alla 'Adblock' would allow you to highlight an area. The area would show the CSS selector for that part of the page. It then asks you to confirm if you want to hide this part only for this page or for all pages. We would save the result to global.css. Then everyone can kill their user experience to their hearts content on their own responsibility. Wish I had the time to write it. —TheDJ (talk • contribs) 11:20, 22 April 2015 (UTC)

Note to self, stuff that could help with this: https://vimeo.com/52055686 and https://selectorgadget-plus.appspot.com —TheDJ (talk • contribs) 11:25, 22 April 2015 (UTC)

Show Revision Number

Hi Gadgeteers! As one who often needs to get revision numbers for specific pages (for copyright/revdel/attribution tagging), I've found it would be most helpful if there was a gadget to display the revision number right there in the main History page where it could be easily Ctrl-C'ed. Just a suggestion looking for a bored coder! Crow^Caw 22:20, 30 April 2015 (UTC)

Which revision number would be provided by such a script? The one for the latest revision of the page? I usually copy that from the permanent link in the sidebar. Helder 14:26, 4 May 2015 (UTC)

Ideally, this would be on the history page for an article, so each line would only have one revision applicable. Crow^Caw 15:34, 4 May 2015 (UTC)

div.GoogleMap

I am proposing to discuss possibility of using a script div.GoogleMap as a default-enabled gadget. Nitobus (talk) 14:17, 4 May 2015 (UTC)

Aren't there privacy implications from loading external scripts? Helder 14:20, 4 May 2015 (UTC)

Nonprofit organizations may use Google Maps JavaScript API without usage limits. The Developer's Guide is offered to load JavaScript API via link to external script: <script type="text/javascript" src="_https://maps.googleapis.com/maps/api/js?..."></script> This external script contains link to another script: document.write('<script src="_https://maps.gstatic.com/maps-api-v3/api/js/20/8/main.js"></script>') Obviously this does not work in Wikipedia, so I just copied both external scripts. I think this method of loading the scripts does not affect the privacy rules and does not apply usage limits. Nevertheless maybe someone know is it possible to use these external scripts without copying them to Wikipedia? This is "technically" interesting for me regardless of the decision on the gadget. Nitobus (talk) 07:53, 8 May 2015 (UTC)

As Helder's pointed out, this would expose everyone using it (more or less "all users") to whatever tracking Google wants to use. I have to strongly oppose it being enabled by default. Moreover, the gadget text should probably include a disclaimer that as an external service, it's subject to Google's TOS and all that. {{Nihiltres|talk|edits}} 15:53, 4 May 2015 (UTC)

Addendum: besides, if we're going to include an external mapping service, it damn well's going to be OpenStreetMap. {{Nihiltres|talk|edits}} 15:54, 4 May 2015 (UTC)

I'm surprised that Magnus's new OSM.js script isn't available on English Wikipedia (it uses OpenStreetMap). Kaldari (talk) 21:58, 11 May 2015 (UTC)

FormWizard

Some Wikimedia Foundation folks on Meta have developed FormWizard, a neat feature that allows you to create a new page by clicking a button and filling out a form (as opposed to getting an edit window). I specifically would like this for meetups, where you click a button, fill out a few details (name of the event, date, venue, etc.), and then you have a meetup page, easy as that. There are other use cases beyond this; it would help streamline some processes on Wikipedia. However, in order for it to be effective, it would have to be an opt-out gadget (enabled by default). Also, though the FormWizard is still under development, it appears to be stable enough to be used on live pages; see e.g. meta:Grants:PEG/Submit request. Would people support this gadget being enabled? Harej (talk) 22:37, 5 October 2014 (UTC)

Just wanted to add that some background info about the meetup idea can be found here. Thanks for helping with this "idea", Harej. ----Another Believer _(Talk) 14:38, 6 October 2014 (UTC)

I'm taking this page off of my watchlist. If any progress comes on this front, let me know on my talk page. Thanks! Harej (talk) 00:05, 20 January 2015 (UTC)

Harej, Another Believer, I_JethroBT, Soni, Ragesoss (various people who've asked me directly about the FormWizard) Jeph paul and I have completed our final updates to the FormWizard and it should be ready for use within the Wikipedia namespace on English Wikipedia. There's an instance on test.wiki (click "Find a mentor" on this page to try it out. I'm an admin there and will delete your page later). I've substantially expanded the documentation on MetaWiki, and will continue to beef it up this week, and we've completed code review. My primary goal is to enable FormWizard for the WP:Co-op, as a tool to make it easier for learners to create profiles. That means it would be enabled by default for all logged-in users. But I am also happy to help other wikiprojects set up their own instances of the Wizard (for things like Meetup page creation)--the gadget is heavily customizable and can support wizards on multiple wikiprojects simultaneously.

Any objection to enabling this gadget for a 1-month trial on the Co-op, with supervision from me and User:I_JethroBT? Jmorgan (WMF) (talk) 21:24, 21 April 2015 (UTC)

As Jmorgan (WMF) mentions above, FormWizard in the context of The Co-op would be a big help in profile creation, where editors describe what they want to do in order to be matched to a mentor interested in teaching the relevant skills / policies / guidelines / etc. Last month, when we were piloting the space, I encountered numerous cases where improper inputs to a pre-filled editing window would result in failed matches. I would need to correct these as a result (e.g. [2], [3], [4]). Standardizing inputs through FormWizard will help avoid these errors and help editors get matched more quickly and will not require editors to constantly patrol new profiles for such errors. I agree that the FormWizard would also be helpful for standardizing the creation of pages for various projects like meetups, edit-a-thons, or WikiProjects. I, JethroBT ^{drop me a line} 21:52, 21 April 2015 (UTC)

@Jmorgan (WMF): Before it is enabled on English Wikipedia, it would be good if the documentation was improved. For example, a critical step of setting up a FormWizard is creating the button to launch the wizard, but this step isn't explained in the documentation at all. Kaldari (talk) 00:02, 22 April 2015 (UTC)

I agree @Kaldari:. That's one of my current tasks. Given I'd be running the setup for the Co-op trial personally, do you think that the incomplete setup documentation blocks a 1-month pilot? Jmorgan (WMF) (talk) 00:05, 22 April 2015 (UTC)

@Jmorgan (WMF): I don't think it blocks it, but I think it would be an easier sell if the Gadget were easily reusable by the community (rather than just for the co-op project). I would personally love to use it myself. I wouldn't oppose enabling it anyway though :) Kaldari (talk) 01:12, 22 April 2015 (UTC)

@Kaldari: I've updated the doc and will continue to do so. I've also launched an additional demo on testwiki, showing that the FormWizard supports multiple portals in the same namespace (testwiki:Wikipedia:Co-op and testwiki:Wikipedia:WikiProject_Testwiki), as well as multiple wizards per portal (buttons at testwiki:Wikipedia:Co-op/Become_a_mentor and testwiki:Wikipedia:Co-op/Become_a_mentor).

One question for you: where does it make sense to put the configs on enwiki? On test (and Meta) they're subpages of the documentation page, in the Project namespace:

...but I don't know if that's the best place to store big json files? Jmorgan (WMF) (talk) 21:29, 28 April 2015 (UTC)

@Jmorgan (WMF): I've usually put JSON config pages in MediaWiki space (since it's technically JavaScript code). For example: MediaWiki:WikiLove.js. Thanks for the documentation improvements. Hope to see more. This seems like a great tool with a lot of potential and I would support turning it on as a gadget here. Kaldari (talk) 21:41, 28 April 2015 (UTC)

Alright, here goes nothing. I_JethroBT and I have migrated the FormWizard code on Enwiki. Currently it's an opt-in gadget under "Browsing" in Special:Preferences#mw-prefsection-gadgets. Once you have enabled the gadget, you can test it by creating a Co-op mentor profile at Wikipedia:Co-op/Mentor_button (Jethro will delete your test profile when you're done with it). We followed Kaldari's suggestion and placed the config files for the mentor profile workflow and the learner profile workflow (not yet enabled) in the MediaWiki namespace, along with the JS, CSS, and description pages.

Our current plan is to leave this as an opt in gadget for a week while people test it out. Then, if there's consensus to move forward, we will make the gadget "opt-out" for all logged in users in the Wikipedia namespace, and if any other projects want to pilot FormWizard, I can help them create configs. Jmorgan (WMF) (talk) 21:27, 30 April 2015 (UTC)

Alright, the FormWizard is turned on by default in the Wikipedia namespace for logged-in editors now, and I_JethroBT and I are hoping to get our related bot approval completed soon, so that we can start testing out the Wizard in the Co-op with real users. But as of now, any admin can create a Wizard by creating a JSON config like MediaWiki:Gadget-formWizard/portalName/workflowName (example) and then placing a button (example) on the page they want to use as the starting point for their workflow. Questions can be posted here, or on the FormWizard documentation talkpage on Meta. Cheers, Jmorgan (WMF) (talk) 21:25, 7 May 2015 (UTC)

Whoops! Spoke too soon. Will follow up with Edokter, figure out possible next steps, and then post an update. Jmorgan (WMF) (talk) 21:28, 7 May 2015 (UTC)

I noticed CharInsert was not triggered on WP:AN and other discussion boards (and getting a JS error), but continued to work on articles. I noticed the edit in gadget-definitions, so I determined that was the cause. It did clear the fault, but I have not investigated the exact cause yet. I guess FormWizard is playing with the edit form and perhaps changing a few thing so CharIsert misses the mark, or possible, both gadgets use the same global variable? -- [[User:Edokter]] {{talk}} 21:37, 7 May 2015 (UTC)

The error was due to a missing dependency on mediawiki.cookie, so this issue has been resolved. Now we can focus on creating a loader below. -- [[User:Edokter]] {{talk}} 09:04, 12 May 2015 (UTC)

Loader

On another note: It is quite a large script, so I would like to suggest you split it up into a lazy-loader and a core mudule, like we did with geonotice and CharInsert. -- [[User:Edokter]] {{talk}} 21:44, 7 May 2015 (UTC)

Thanks, Edokter. Jeph_paul has looked into this as well, and thinks the culprit is mw.cookie(). I've opened a bug report [5]. I'm hoping that someone in the know can take a look at the code and suggest a fix soon. Any ideas, Kaldari? Jmorgan (WMF) (talk) 19:09, 11 May 2015 (UTC)

Just looked at the code briefly. A few notes:

mediawiki.user and mediawiki.cookie should be declared as dependencies
It should use protocol relative URLs
Code could be made smaller by using jQuery more often
Agree with Edokter that it needs to be split into two pieces to minimize loading unneeded code
The console logging should be commented out

Kaldari (talk) 19:41, 11 May 2015 (UTC)

Also, the code should probably be restricted to loading when mw.config.get('wgAction') === 'view', but I don't know enough about the intended uses of FormWizard to be sure of that. Kaldari (talk) 20:29, 11 May 2015 (UTC)

Thanks for the code review, gentlemen. Your proposed changes make sense to me. Two questions for you both Edokter and Kaldari:

. can you point to an example of a gadget that splits its JS into multiple files to minimize load time?
. if the changes you both propose above are implemented and no new bugs are discovered, will you both support turning this gadget on as default for logged-in editors?

Thanks again, Jmorgan (WMF) (talk) 22:17, 11 May 2015 (UTC)

As Edokter mentioned, MediaWiki:Gadget-geonotice.js is a good example. The idea isn't necessarily to minimize load time, it's to prevent loading unneeded code on every page. I'd be happy to support once any and all issues are resolved. Kaldari (talk) 22:38, 11 May 2015 (UTC)

I see the split has been made. To answer #2: If the gadgets runs without (major) issues, I'd support it being loaded as default. -- [[User:Edokter]] {{talk}} 10:20, 21 May 2015 (UTC)

Alright, as you noted Edokter, we've made the split. MediaWiki:Gadget-formWizard.js loads MediaWiki:Gadget-formWizard-core.js in the Project namespace. We've turned it on by default for logged-in editors, and I've confirmed that it works. I don't see any errors in the console. Could you or Kaldari take a look and let us know if this can stand as written?

As a secondary request, I tried to hide the second script call in MediaWiki:Gadgets-definition by passing in |hidden|rights=hidden to ResourceLoader so that the unnecessary second checkbox does not appear in Special:Preferences#mw-prefsection-gadgets. I saw other gadgets that use this loader pattern have done this. But it doesn't seem to be working for me: the second checkbox still appears for me. What did I do wrong? Many thanks, Jmorgan (WMF) (talk) 18:57, 21 May 2015 (UTC)

I can see nothing wrong. It does this sometimes. I'll try kicking it by removing and readding it. -- [[User:Edokter]] {{talk}} 20:04, 21 May 2015 (UTC)

OK, known issue, see phab:T99557. It should resolve itself in 24 hours. -- [[User:Edokter]] {{talk}} 20:17, 21 May 2015 (UTC)

The $(function(){ ... }) call which is on MediaWiki:Gadget-formWizard.js seems to be unnecessary since that loader code doesn't interact with the page, and there is another call to $(function(){ ... })inside MediaWiki:Gadget-formWizard-core.js. Helder 17:02, 22 May 2015 (UTC)

Good point. Removed $(function()). -- [[User:Edokter]] {{talk}} 17:34, 22 May 2015 (UTC)

Mark blocked users

I propose a script (the source code is here, and the enwiki script is here) that will automatically mark temporarily and indefinitely blocked users in discussions, listings, and logs. This may be very convenient to use for editors that actively fight vandalism, who can quickly revert the edits of blocked users. Epic Genius (talk) 17:13, 4 March 2015 (UTC)

Support. I like and use this as a userscript currently, via my global.js Quiddity (talk) 02:26, 30 May 2015 (UTC)

Persistent table of contents

A gadget to add persistent table of contents on articles. It moves the table of contents to the left sidebar after scrolling past the first section. Expands on hover. — Prtksxna (talk) 19:18, 25 May 2015 (UTC)

I've added a screenshot, and support this gadget addition. Quiddity (talk) 14:44, 27 May 2015 (UTC)

I've been using it and I'd support, too. A couple of things, though:

The expanding on hover can be really annoying, especially when there's not very much there and/or the section titles are particularly long, and it's only made worse using a smaller screen. Is wrapping out of the question when this wouldn't make the toc too long to fit, or, for that matter, when it's already too long to fit anyway (this happens surprisingly often)?
When the sidebar is really long (usually due to the article being in a lot of different languages), the end of the original sidebar just gets cut off and you lose the links to the rest of the languages. The toc should only appear after the end of the sidebar and persist at the top when scrolling down, not simply replace it.
It would still probably be useful with the preview when editing a full page, but apparently only activates on view action. Could also be particularly useful here if it included a link to the edit window.
Since the table of contents is not at the top of the page anymore, an added link to the top/first section would be really useful (probably just labelled as the page title).
When nothing is overflowing and it all fits in the sidebar anyway, the hover shadow effect looks really weird.
Might want to actually label it as being the table of contents, even if that's just on hover too or something. I can see people turning it on, wandering off for awhile, and then coming back and seeing it and getting confused.

Yup. Still good enough to add as is, though. -— Isarra ༆ 15:20, 5 June 2015 (UTC)

editProtectedHelper

I wrote editProtectedHelper about a year and a half ago to assist in responding to protected edit requests. I'd like to now convert it to be a gadget rather than a user script. Jackmcbarn (talk) 19:09, 19 July 2015 (UTC)

DisambiguationLinks

Thanks to the Disambiguator extension, it is now possible to display links to disambiguation pages differently than links to other pages. I've created a gadget to render them as orange links: MediaWiki:Gadget-DisambiguationLinks.css. That way editors can easily identify such links and correct them. I would like to propose adding this as a gadget option (off by default). Kaldari (talk) 23:09, 27 May 2015 (UTC)

Interesting! I currently have User:Anomie/linkclassifier installed as a userscript, but with the LinkClassifierOnDemand=true; and I rarely use it (because effort). This would be a good lightweight alternative, that meets my primary use for the other script.

I would tentatively suggest using the same color scheme as Anomie's script (blue links, with a yellow background), but otherwise I fully support this. Quiddity (talk) 02:41, 30 May 2015 (UTC)

Too simple for a gadget on its own. Why not adapt linkclassifier instead? -- [[User:Edokter]] {{talk}} 10:24, 30 May 2015 (UTC)

Why is it too simple for a gadget? It's a feature that's been asked for since 2006. Personally, I would never use linkclassifier as a gadget since having 20 different colors of links seems pretty useless to me. (How can anyone actually distinguish that many different link colors?) Kaldari (talk) 19:34, 1 June 2015 (UTC)

FWIW, the Spanish Wikipedia has a gadget that only colors disambiguation links. Kaldari (talk) 18:42, 24 July 2015 (UTC)

Enable wpxstyling gadget by default

Hi,

The wpxstyling gadget adds some extra styles for the Wikipedia:WikiProject Directory and its subpages. Example with styling and without styling. Normally the CSS could have been inlined into a template, but that would have caused the page to be too large and probably been larger than 2MB.

Thanks, Legoktm (talk) 15:38, 16 July 2015 (UTC)

(Link to gadget) I don't like CSS that is targeted at specific pages, and I really wish they hurry with page-dependant CSS. -- [[User:Edokter]] {{talk}} 15:54, 16 July 2015 (UTC)

I agree that per-page CSS would be a better approach, but until then, this is the best approach (better than editing Common.css). Harej (talk) 16:50, 16 July 2015 (UTC)

I'm not so sure about that. It's still prettyfication for a very minor subset of Wikipedia. There is always inline. If that generates too much code, perhaps look at simplyfying the design. -- [[User:Edokter]] {{talk}} 20:54, 16 July 2015 (UTC)

Inline css is never an appropriate solution. -— Isarra ༆ 16:51, 19 July 2015 (UTC)

The WikiProject Directory is a pretty obscure part of Wikipedia. The main directory page only gets about a dozen views per day. I'm not sure it makes sense to load CSS on every page of Wikipedia just to prettify this one area. Kaldari (talk) 18:16, 19 July 2015 (UTC)

We're talking about 288 bytes of CSS after minification and gzip. Legoktm (talk) 03:42, 24 July 2015 (UTC)

I won't block it, but it seems like a bad precedent. Kaldari (talk) 19:21, 27 July 2015 (UTC)

It is a bad precedent. Every wikiprojetct will want their own styling included as well, and then it is much more then 288 bytes. -- [[User:Edokter]] {{talk}} 21:00, 27 July 2015 (UTC)

WatchlistNotice

Over at Commons, I noticed that they have a default gadget called WatchlistNotice. It allows users to select which watchlist notice topics they'd like to see; this is evidently a wonderful idea. The box for configuration is shown at right. Why don't we add it here? APerson (talk!) 01:52, 29 July 2015 (UTC)

AssessmentHelper

I've created a user script to provide a nice user interface for adding WikiProject assessments to article talk pages. To try it out, add ...

mw.loader.load( '//en.wikipedia.org/w/index.php?title=User:Kaldari/assessmentHelper.js&action=raw&ctype=text/javascript' );

... to your common.js or vector.js. It currently supports over 1000 WikiProjects and knows how to deal with templates such as {{WikiProjectBanner}} and {{WikiProjectBannerShell}}. As this would be useful to anyone participating in a WikiProject, I would like to propose it as a gadget. Kaldari (talk) 20:11, 6 July 2015 (UTC)

@Kaldari: Hey Kaldari, nice idea for a script. I just tested it out on a few pages, and it seems to be working just fine, but I think its usage could be expanded. Two things I noticed is that I can't use the script when an article talk page is being initially created, which is usually when WikiProject banners are added to talk pages. The second is that the script can't be used to reassess importance or class. Any possibility these might come into play with the script down the road? I, JethroBT ^{drop me a line} 22:24, 6 July 2015 (UTC)

@I JethroBT: Those are both great ideas. I've gone ahead and added support for using it within editing mode, including during talk page creation. Doing reassessments is a bit more tricky. The main problem is that most WikiProject templates have one or more aliases and there's no way for me to know about all of them beforehand. Thus there will never be a reliable way for me to retrieve the values of existing WikiProject assessments, and since it will never be reliable, I don't want to give editors a false sense of security that it is successfully pulling existing values. Hope that makes sense. Kaldari (talk) 00:43, 7 July 2015 (UTC)

@Kaldari: Wow, great! In terms of reassessment, I see your point about aliases and how that would be challenging. One clarification was that I don't think the gadget needs to read in the actual assessment values, but be able to detect that the template is there and overwrite it with the input values from the user. Still, I think the alias issue persists there. In any case, I think this would make for a useful gadget for some of us. I, JethroBT ^{drop me a line} 20:12, 7 July 2015 (UTC)

It looks like there is a similar script that also supports editing existing WikiProject assessments: User:Kephir/gadgets/rater.js. Kaldari (talk) 23:00, 30 July 2015 (UTC)

Deprecating JavaScript Standard Library gadget

The JavaScript Standard Library gadget is pretty ancient (2007). At this point it's support for older versions of IE is pointless since the gadget has to be loaded via ResourceLoader and ResourceLoader doesn't support older version of IE. Also most of its JS shims are now in core, except for execScript, and it doesn't look like anything on English Wikipedia uses execScript.[6] I would like to propose that we either move it under the Deprecated header of MediaWiki:Gadgets-definition (which is currently empty) or remove it altogether. Kaldari (talk) 03:56, 11 August 2015 (UTC)

This sounds generally sensible, but for context: which polyfills are in core, and/or where can I check them out? I'm working on overhauling another gadget, it includes an Array.indexOf polyfill, and if it's redundant, I'll remove it. This might be true for other gadgets as well. {{Nihiltres |talk |edits}} 19:36, 12 August 2015 (UTC)

All defined modules of core can be found here. Shims include the modules: json, es5-shim, don-level2-shim. Most shims can be easily identified because they have a "skipFunction" property. —TheDJ (talk • contribs) 20:37, 12 August 2015 (UTC)

Kill with fire. The browsers it was targeting don't even run any of our JS anymore most likely. —TheDJ (talk • contribs) 20:37, 12 August 2015 (UTC)

Killed it. Kaldari (talk) 04:56, 13 August 2015 (UTC)

Overhaul of assessment metadata script

See MediaWiki talk:Gadget-metadata.js § 2015 overhaul. Long story short: I'm overhauling the assessment metadata gadget code, taking over as maintainer (current maintainer hasn't edited for approx. 3 years), and would like some quick review and/or testing of the revised code, which I've posted at User:Nihiltres/Gadget-metadata.js, before I update the main script. {{Nihiltres |talk |edits}} 15:51, 16 August 2015 (UTC)

GoogleTrans gadget not loading all the time starting 2/10/2015

Hi there,

For some reason the GoogleTrans gadget is loading intermittently. Sometimes it loads (check MORE menu item to see if it has). When it does load there is no javascript error message. When it doesn't load the following javascript error message can be seen:

LOG: Exception in module-execute in module ext.cx.interlanguagelink:

TypeError: Unable to get value of the property 'data': object is null or undefinedTypeError: Unable to get value of the property 'data': object is null or undefined

I assume this is a wiki thing since the gadget was last changed two weeks ago, and has run well since then. MediaWiki hasn't been updated, according to SignPost, either.

Endo999 (talk) 00:22, 2 October 2015 (UTC)

I got a slightly better error message in the javascript:

function pageInLanguageExists(code){return $('li.interlanguage-link.interwiki-'+code).length===1;}

there is an error in the function above, I believe, and this seems to be stopping the GoogleTrans gadget from properly loading.

Endo999 (talk) 04:46, 2 October 2015 (UTC)

DejaVu font

'See MediaWiki:Gadget-DejaVu Sans.css

Is this still usefull? The font version (2.24) is seven years old and quite outdated. Today, most OSes and browsers have improved glyph support, so it is essentially obsolete. I suggest we kill it. -- [[User:Edokter]] {{talk}} 10:58, 13 August 2015 (UTC)

It's also one of the ugliest fonts I've ever seen, but I guess that's a more subjective assessment :P Would be good to find out how many people have it turned on. Kaldari (talk) 23:29, 13 August 2015 (UTC)

According to Wikipedia:Database reports/User preferences, 14002. That is quite a lot, but I bet most of them don't even know they have it turned on. Fact remains that the font (embedded in CSS) is quite out of date, and the payload is out of proportions. And that is only the basic font; no bold or italics. -- [[User:Edokter]] {{talk}} 10:58, 14 August 2015 (UTC)

Moved to the Deprecated section for now. -- [[User:Edokter]] {{talk}} 16:16, 16 August 2015 (UTC)

I'm going to kill it now. I really can't see any net benifits to this gadget. If anything, it causes broken text because of lacking glyph support. -- [[User:Edokter]] {{talk}} 11:10, 26 December 2015 (UTC)

HotKey Edit

I make the little gadgets for quickly edit: http://see.sl088.com/id/4e2

http://see.sl088.com/id/4e1

Make SidebarTranslate into a gadget

See the proposal at Wikipedia:Village pump (proposals)/Archive 107#Make SidebarTranslate into a gadget. equazcion → 11:35, 8 Nov 2013 (UTC)

Request for gadget that does intersection of different categories

How about a feature where you can take the intersection of two categories. Let's say you had two categories:

Category:Athletes (track and field) at the 1984 Summer Olympics

Category:French sprinters

Both groups are a little too big to go through by eye, but the intersection of the two lists would suddenly give you a nice concise list of french sprinters who were at the 1984 games. It's not really worth making a categories for this but the intersection of the two categories would be really useful behavior.

Endo999 (talk) 07:42, 30 January 2016 (UTC)

incategory: "Athletes (track and field) at the 1984 Summer Olympics" incategory:French_sprinters — Cpiral Cpiral 08:40, 31 January 2016 (UTC)

Thanks, that worked. Endo999 (talk) 20:59, 31 January 2016 (UTC)

The following article shows the progress towards "category intersection". It is a desired feature but not currently implemented

Wikipedia:Category_intersection

Endo999 (talk) 20:55, 31 January 2016 (UTC)

Note: the AutoWikiBrowser has a tool that can compare categories in this way. bd2412 T 14:03, 17 April 2016 (UTC)

Searching for external links popup

Is there a gadget for easily searching for external links using Special:LinkSearch? Ideally the user would be able to hover above an external link and a navigational popup would come up and provide the number (or estimated number) of additional links. The popup should contain a link to the full Special:LinkSearch result which has been properly formatted. For example, a use case would be when removing spam because the same URLs are often spammed elsewhere, possibly by different accounts. LinkSearch would be the easiest way to find them. Having the gadget operate here would be helpful too, as it's a tedious process to manually select/copy the suspected spam URL, format it (*.example.com) and submit it to LinkSearch. Thanks. Elaenia (talk) 00:17, 11 March 2016 (UTC)

MarkBlocked

For at least the past four or five years, I've been cross-wiki importing a script from the Russian Wikipedia that strikes out usernames that have been blocked. I finally bothered to copy and paste the code here: User:Keegan/MarkBlocked.js. Added it to my common.js, performs as it did before (but faster, of course). I think this could make a useful gadget. Keegan (talk) 23:01, 11 March 2016 (UTC)

I've been asked why not just keep cross-wiki importing. The answer is that cross-wiki imports can cause cookie confusion on occasion if a user has more than one account for various reasons, logging a user out. Keegan (talk) 23:10, 11 March 2016 (UTC)

Support. I used this script for a while and appreciated the way it saved me time. Quiddity (talk) 23:24, 11 March 2016 (UTC)
Support. Been using via User:NuclearWarfare/Mark-blocked script.js for a while. Only concerns I have is how increased ease of information on blocked users might impact wiki interactions. For example consider users that are mostly good editors that have crossed a line in a content dispute and rightly have been short term blocked for that, as a gadget such a block would be visible to a larger percentage of editors. Self-requested vacation blocks would show up as well. I slightly worry that on the average person seeing a blocked username might just assume that it means they are a vandal. I know the block log information is in the tooltip, but I can't imagine that is checked out often. Still I find it useful when I history dive articles to key in on changes to which to pay extra attention. PaleAqua (talk) 17:29, 12 March 2016 (UTC)

Speculation on my part, but I think the average user probably won't be using this gadget. Usage statistics would bear that out. Keegan (talk) 06:13, 13 March 2016 (UTC)

Support. Sounds like a useful gadget, especially for admins. Kaldari (talk) 17:54, 13 July 2016 (UTC)
- I went ahead and prepared a Gadget definition for this: MediaWiki:Gadget-markblocked.js. It's based on the latest version of the Russian gadget with the Russian-specific parts removed. Kaldari (talk) 18:23, 13 July 2016 (UTC)
  - Done Added as a gadget. Kaldari (talk) 18:17, 15 July 2016 (UTC)

Reproposing DisambiguationLinks

A year ago I proposed adding a gadget that displays links to disambiguation pages in orange (so that they can be easily distinguished from other kinds of links and fixed). At the time, the proposal received one supportive comment and one negative comment (that the gadget was too simple). Personally, I think this would be a really useful gadget despite its simplicity. I use it myself on a daily basis to fix disambiguation links. I know there is another user script that also changes the colors of disambiguation links, but it does so in a way that is inefficient (requiring calls to the API), and it also changes the colors of numerous other types of links, which IMO, just makes things confusing. I would like to repropose the DisambiguationLinks gadget since there was no consensus reached last time and a year has passed since then. Kaldari (talk) 20:41, 15 April 2016 (UTC)

Weak support since it's so simple. Might be worth considering changing the selector to a.mw-disambig:not(.hatnote a), too, since hatnote disambiguation links are almost always intended. {{Nihiltres |talk |edits}} 20:56, 15 April 2016 (UTC)
- I think highlighting the hatnote links as disambiguation pages is fine. Just because they're highlighted doesn't necessarily mean they have to be changed. If nothing else, it lets people know the gadget is still working :) Kaldari (talk) 17:50, 13 July 2016 (UTC)
Support. I use Anomie's link classifier, which works wonders but is complicated to install. If we could achieve the same end by clicking a button in preferences, that would be great. bd2412 T 13:55, 17 April 2016 (UTC)
Support. I use Anomie's script, which I found needed help to install just to focus on dab links. I think this would be useful to many people, gadgets are much easier to use than js/css. Jenks24 (talk) 19:19, 13 July 2016 (UTC)
Done Added as a gadget (since I couldn't get anyone else to close this). Kaldari (talk) 18:17, 15 July 2016 (UTC)
Sorry I didn't get to this in time. I would have added it too, for the record :) — MusikAnimal ^talk 23:24, 20 July 2016 (UTC)