Jump to content

Wikipedia:Gadget/proposals/Archive 4

Add links
From Wikipedia, the free encyclopedia
Archive 1Archive 2Archive 3Archive 4Archive 5Archive 6Archive 7

Edit Summaries dropdown

Per the discussion here and a consensus agreement to implement an edit summary dropdown list ([[ here) is there any objections raised (as a final hurdle) to me making this script into a gadget.

It is stable and has been tested by a few people. --Errant (chat!) 10:44, 6 June 2011 (UTC)

Wikipedia:Village_pump_(proposals)#Show_blocked_users_gadget

FYI, Wikipedia:Village_pump_(proposals)#Show_blocked_users_gadget. I've been using the Russian Wikipedia gadget mentioned there for quite some time, without any problems. Rd232 talk 18:11, 6 June 2011 (UTC)

Integrated, interwiki, global watchlist

I would like to be able to use preferences to use User:Yair rand/interwikiwatchlist.js

Can some developers please implement this? Maybe some money would help? --Timeshifter (talk) 06:50, 4 July 2011 (UTC)

SnipManager - Citation Template Ribbon Toolbar

I would like to propose my script (disclaimer: I wrote it) SnipManager. I haven't found any incompatibilities with it and it plays nice with wikiEd, Twinkle, etc. It's easy to add more templates to it, and the templates have the ability to show previews, descriptions, etc. The templates I installed also have tooltips if you hover over an entry, as well as automatic date insertion. It's designed for both newer users (citations) and power users (cleanup tags etc.). It even supports complex things like long infoboxes and previews for them as well. If I don't get it accepted as a gadget hopefully it will at least get some more exposure. I think only one person other than myself uses it. --Odie5533 (talk) 00:00, 8 August 2011 (UTC)

Tab shortening (friendlytabs.js reincarnated)

People have been asking at WT:TW for Twinkle to shorten their tabs, like it used to. But we decided that tab shortening is not tied to Twinkle, and should be spun off into its own gadget. I have prepared a gadget based on User:Ioeth/friendlytabs.js, stored at User:This, that and the other/temp/MediaWiki:Gadget-TabShortener.js. It works in IE9, Firefox 5 Beta, and the latest Chrome. Could a friendly admin please consider installing it? — This, that, and the other (talk) 07:52, 11 June 2011 (UTC)

Does this gadget have any benefits for people other then those using Twinkle? If not, then I believe this functionality should have remained a part of Twinkle's configuration. But that's just my opinion. (edit:) After testing with Twinkle, I found the impact very minimal. On my 1280px wide screen, most tabs are still obscured. — Edokter (talk) — 12:02, 11 June 2011 (UTC)
Wasn't the reason this functionality exists was because Friendly and Twinkle added so many new tabs? So it would probably still work best for users of those scripts, shouldn't it? I don't understand why someone not using either script would use this to shorten their tabs. If this is to be a gadget, then at least expand it with more features so it isn't such a standalone, one-feature script. For instance, allow users to, if they want, choose which tabs they want to shorten, what alternative text they want instead, etc. Gary King (talk · scripts) 05:59, 12 June 2011 (UTC)
Indeed. But providing options for a gadget is complicated, however Twinkle already has a framework for that. So I think removing that function from Twinkle may not have been the best decision. — Edokter (talk) — 10:53, 12 June 2011 (UTC)
They can just use the same options method as other scripts do, including Twinkle. If the user is tech-savvy enough, let them know that JS customization is available; they'd have to add something like TabConfig = { setting: true } to their skin.js page. Gary King (talk · scripts) 19:41, 12 June 2011 (UTC)
It is primarily intended for those using the Monobook skin who have lots of page tabs. It is conceivable that they may not be using Twinkle, and besides, the tab-shortening functionality is not specific to Twinkle. So AzaToth and I thought to break this functionality off into a separate gadget. — This, that, and the other (talk) 00:56, 14 June 2011 (UTC)
I note we already have the addsection-plus gadget: 'Change the "new section" tab text to instead display the much narrower "+"'. Would it be to daring to extend/replace that one? Amalthea 10:03, 14 June 2011 (UTC)

Two months later... does anyone want it? The discussion seems to have petered out. — This, that, and the other (talk) 08:13, 7 August 2011 (UTC)

If one searches for "importScript('User:Ioeth/friendlytabs.js');" in Userspace, then there appears to be 62 users using it. I for one, would not like to lose it.  Ronhjones  (Talk) 12:55, 12 August 2011 (UTC)
I used to have the short tabs, but they went and never said goodbye. I want it back somehow or other. (I've been pointed at http://en.wikipedia.org/wiki/User:Ioeth/friendlytabs.js and don't really know what to do with it. I'm not exactly a newbie here by now, but I'm more on the front line than in the back rooms. I could understand COBOL, but not this stuff...) Peridon (talk) 16:51, 6 September 2011 (UTC)
I made a small script to shorten the tabs. Should work in Vector and Monobook. User:Edokter/CompactTabs.js. — Edokter (talk) — 17:00, 6 September 2011 (UTC)
Thanks for that - but I've still got the same problem. (Same as a friend the other day complaining about a manual that didn't tell her how to do something fairly basic - because it was written by an expert...) What do I do with it? Peridon (talk) 18:06, 6 September 2011 (UTC)
Sorry for leaving you in the dark. Add this on a new line at the bottom of Special:MyPage/skin.js:
importScript("...");
replacing ... with the page of the script, e.g. 
importScript("User:Edokter/CompactTabs.js");
Then WP:BYPASS your cache when added. If Edokter's script doesn't work for you, try Ioeth's. — This, that, and the other (talk) 06:41, 7 September 2011 (UTC)
Had problems getting into the MyPage thing ('Reading meta.wikipedia' thingie stuck several times). OK now - working without even needing to clear the cache! Thanks. Peridon (talk) 19:58, 9 September 2011 (UTC)

Wiki Table Editor

Wiki Table Editor from the SIMILE project, WikEd needs to be disabled before using it. — Dispenser 13:56, 19 July 2011 (UTC)

Where does the code live locally? In order to enable it as a gadget, there needs to be a local JS file to point to. It looks like most of the code at simile is here. Perhaps someone could migrate it if it isn't already. Kaldari (talk) 21:38, 19 July 2011 (UTC)
Looks good. I copied it to User:Gadget850/wiki-toolbox.js for testing. Major issue is the copyright by MIT. ---— Gadget850 (Ed) talk 03:19, 20 July 2011 (UTC)
I think it is a CC copyright where MIT is the attribution. There is a CC-BY icon with a link to here:
http://creativecommons.org/licenses/by/2.5/ --Timeshifter (talk) 02:35, 2 September 2011 (UTC)
Must have missed that. Need to attribute it in the code. I have played with it and it does some odd things; need to characterize what I have seen. ---— Gadget850 (Ed) talk 02:50, 2 September 2011 (UTC)
I haven't tried it yet. I just happened to see it here. I added a link to it here:
commons:Commons:Create charts and graphs online#Wiki chart editors --Timeshifter (talk) 14:41, 2 September 2011 (UTC)
Sometimes when I edit a table, I just get blank cells. Try it and see. ---— Gadget850 (Ed) talk 14:49, 2 September 2011 (UTC)
How do I install this? Is it like how I installed the interwiki watchlist here:
User:Timeshifter/common.js --Timeshifter (talk) 17:11, 3 September 2011 (UTC)
Add importScript('User:Gadget850/wiki-toolbox.js'); to Special:MyPage/skin.js. ---— Gadget850 (Ed) talk 17:53, 3 September 2011 (UTC)
Thanks. Special:MyPage/skin.js sends me to User:Timeshifter/vector.js
Is that right? --Timeshifter (talk) 22:29, 4 September 2011 (UTC)
Yes, it automagically opens the JS file for your selected skin; Vector in this case. ---— Gadget850 (Ed) talk 22:34, 4 September 2011 (UTC)
Will it work in User:Timeshifter/common.js? --Timeshifter (talk) 23:58, 4 September 2011 (UTC)
Yes. ---— Gadget850 (Ed) talk 01:11, 5 September 2011 (UTC)

(unindent) I installed it to User:Timeshifter/common.js, and added double quotes instead of single quotes. I did that because either way I do not see anything added to the editing toolbar. I clicked the table insert button, and it looks the same as before:

header 1 header 2 header 3
row 1, cell 1 row 1, cell 2 row 1, cell 3
row 2, cell 1 row 2, cell 2 row 2, cell 3

I must not be using this new table editor correctly. I looked at

It shows some additional table editing buttons on the edit toolbar. I see no additional ones anywhere on the editing toolbars. --Timeshifter (talk) 18:12, 5 September 2011 (UTC)

It needs to be single quotes, exactly as shown. After you fix that, follow the instructions at the top of the page. ---— Gadget850 (Ed) talk 18:12, 5 September 2011 (UTC)
Still nothing. I changed to your exact JS code, and then added the bookmarklet in Firefox 6.0.1. according to the instruction page. When I go to a page with a wiki table such as the one above, and click inside the table wikitext, and then click the bookmarklet, I see nothing added to the editing toolbars anywhere. I must be doing something wrong.
Here is the bookmarklet properties on my bookmark toolbar:
javascript:(function(){var%20script=document.createElement('script');script.type='text/javascript';script.src='http://simile.mit.edu/repository/wiki-toolbox/trunk/src/wiki-toolbox-bundle.js';script.id='wiki-toolbox-bundle';document.getElementsByTagName('head')[0].appendChild(script);})();
I don't understand JS, but it looks like it is calling up the same JS, but from the original source instead of from your JS page. --Timeshifter (talk) 18:43, 5 September 2011 (UTC)
I also tried double quotes in the JS import code, and then used the bookmarklet in the edit window. No change. --Timeshifter (talk) 20:17, 7 September 2011 (UTC)

Show the page actions dropdown menu as tabs (Vector)

I'd like to turn this script (an improved version of Svick's original script) into a gadget, which turns the dropdown menu for page action (in Vector) into tabs, which saves having to hover over the dropdown arrow before an item can be clicked... I'm sure I'm not the only one hating that. — Edokter (talk) — 12:53, 10 June 2011 (UTC)

No opinion on whether this should be added, but:
  • Script should only start its work if vector skin is used
  • Wrapping the anchor in a span tag by innerHTML manipulation can be bad since it may lose events or data bound to the nodes. Better to use DOM manipulation (and faster, too, with all modern browsers)
  • Script adds spans to all LI tags found, this might conflict with more complex portlet items like those created by User:Haza-w/Drop-down menus or User:Haza-w/Drop-down menus (haven't tried it, but I'd rather play it safe).
FWIW, I happen to have one of those, too, from back when I was trying out Vector: User:Amalthea/VectorMenuToTabs.js. I think it doesn't have any of the potential problems I noted above, although it may of course have others.
Amalthea 14:27, 10 June 2011 (UTC)
There is always room for improvement (I'm stealing some of that code). To address you concerns:
  • Filter added.
  • There are no events attached to any of the menus that I can find or know of, but if your code is safer, I'll use it.
  • Script only adds spans to those itmes that do not have them, and only to items under #p-cactions. Don't know if Haza uses the same ids (I'll test for clashes). [Edit] No incompatiblilities found; both work as intended together.
In any case, I do believe the functionality is a welcome addition. — Edokter (talk) — 16:13, 10 June 2011 (UTC)
Twinkle started using click events recently, that's why it's still on my mind, and people can configure it to place its stuff in p-cactions. Amalthea 16:56, 10 June 2011 (UTC)
I adapted the code to use .wrap instead. Should that work? — Edokter (talk) — 17:46, 10 June 2011 (UTC)
I think so. All my concerns are addressed, now someone decide whether this is useful enough for a gadget. :) Amalthea 18:57, 10 June 2011 (UTC)
I really can't imagine that there's enough demand for this functionality to justify making it a gadget as opposed to a user script. Kaldari (talk) 07:04, 25 October 2011 (UTC)

I have posted the same proposal in WP:Village pump (technical)#Adopting internal link helper from Chinese Wikipedia. It is already greatly applied in Chinese Wikipedia and at least one editor in en.wp supports it. The basic templates and documentation are ready. -- Sameboat - 同舟 (talk) 02:39, 30 October 2011 (UTC)

Diff Categorizer

We have a research project for evaluating edits on English Wikipedia. Within this project we would like to collect user input, where users categorize edits. To collect user inputs we have written a small application and would like to install it as a gadget.

First of all I would like to verify that it complies with the general criteria for gadgets. I am, however, confused by the fifth criteria: "Collections of scripts should be applied as own entities. (No collection of scripts dumped as a gadget, unless the collection is specially defined as an own entity.)" What does "dumping scrips as a gadget" mean? That several independet scripts are merged on one gadget page? What does "entity" mean here? Does it mean an entry in MediaWiki:Gadgets-definition?

The application consist of four scripts, and two actual gadgets, in addition to a off-site server component that receives the user input (running on the toolserver). Here are the scripts:

  • diffrater.js is the diff categorization gadget.
  • diffrater-admin.js is the administration panel for the gadget, that is used to update the active selection of edits.
  • validation.js is a jQuery validation plugin, used by both diffrater.js and diffrater-admin.js.
  • diffrater-config.js declares a global variable containing the current configuration parameters of the application.

The application is enabled by copying the four scripts to the corresponding gadget page and adding these two items to MediaWiki:Gadgets-definition:

  • edit-categorizer [ ResourceLoader | dependencies=jquery.ui.dialog,mediawiki.util,jquery.tipsy ] | validation.js | diffrater-config.js | diffrater.js
  • edit-categorizer-admin [ ResourceLoader | rights=admin | dependencies=jquery.ui.dialog,mediawiki.util ] | validation.js | diffrater-config.js | diffrater-admin.js

Is this an acceptable way of structuring a gadget? --Fikonträd (talk) 16:16, 1 September 2011 (UTC)

Sounds interesting, but do you have a documentation page to explain this in more detail? Seems like something that should definitely have more information on it, perhaps something explaining the privacy of what a user submits, etc.? Gary King (talk · scripts) 17:46, 1 September 2011 (UTC)
Yes, the idea is to launch the application via a link from an instruction page such as this, that should also cover the privacy issues. --Fikonträd (talk) 19:03, 1 September 2011 (UTC)
Hey Gary, just to answer, we do need a full documentation page before this gets enabled. Also, just to be transparent, the project was paid for by the Foundation to support our research work. We have various tools to get a list of diffs and then code them, but we really want an on-wiki way to do so that might let community members tell us what they think the content of diffs is all about. :) Steven Walling (WMF) • talk 17:07, 2 September 2011 (UTC)
I don't have any particular opinion on this gadget. It's definitely a unique one though; it might be better to get further input from Wikipedia:Village pump (technical). Gary King (talk · scripts) 17:18, 2 September 2011 (UTC)
Just to kick off the documentation necessities, I've begun something at User:Steven (WMF)/Diff Categorizer. Please edit. Steven Walling (WMF) • talk 23:39, 12 September 2011 (UTC)
We worked on a specific proposal research question for the trial of this gadget, with documentation here. The basic gist is to turn it on and ask folks to categorize one set of mainspace diffs as a simple test of how much people agree about the content of edits and how to respond. This means that the data is all anonymized; a measurement of agreement is just an aggregate number. Steven Walling (WMF) • talk 18:56, 30 October 2011 (UTC)

Links/Templates autocompletion

I would like to propose a gadget that I've developed in Hebrew Wikipedia which allows auto completion for links and templates in the edit box. The gadget determines when the editor adds text such as double [, or double {, and suggests links or templates the same way the search box do. The gadget is resourceloader compatible and already works in Hebrew Wikipedia, where it gain many good feedbacks. The code is in he:MediaWiki:Gadget-autocomplete.js, and it doesn't require any internationalization. ערן (talk) 21:46, 7 November 2011 (UTC)

Limit page content width to 800px with a nice page-like view (Vector skin)

I created this simple CSS file User:Agent007bond/vector.css which makes the changes shown in this screenshot: [1]. In words, it does the following:

  • Restricts the main body of a page on Wikipedia to 800 pixels width.
  • Centers the content on screen (or browser window).
    • Note: The sides of the body are at equal distance from the edges of the screen/browser window, not from the edges of the white area of Vector skin template.
    • This also works well with the narrowing of browser window width, displaying horizontal scroll bars only when the content is truly overflowing (the invisible border created by the CSS does not force scroll bars to display).
  • Creates a nice blue border around the content to give it a 'page' look and feel.
    • Without the border, the text looks strange as though it's "hanging in mid-air" when considering the large whitespaces on the sides.

My purpose of creating this CSS is to make the content of Wikipedia more readable in large screens, especially widescreen monitors. Many professional websites and blogs follow this 'restricted width' format to make their content well-presented and easily readable. Without it, articles tend to have extremely long lines from screen edge to screen edge, and the reader has to move eyes (and sometimes head) across uncomfortably long distances left and right.

I would like to know if this CSS can be added as a gadget for every Wikipedian to use. Basically, in My preferences > Gadgets, I would like to see a checkbox "Limit page content width to 800 pixels and center it on page (for Vector skin. Non-content elements of page will remain intact)" under the Appearance section.

I don't expect this CSS to function properly with any other skin although it could give some results. However I don't know how a CSS can be limited to a particular skin, as CSS cannot be programmed to verify anything unlike JS. -- ADTC Talk Ctrb . 23:45, 25 November 2011 (UTC)

I wrote a script a few years ago for myself, for the Monobook skin, that makes page widths about 1000px. It shrinks everything, moving the menus in too, so it doesn't look as strange. It still keeps discussion pages like WP:ANI at full width though, because it's easier to read huge, long paragraphs of discussions at full width, I find. So, I'd suggest making a script that moves in everything, rather than just the content since it looks really strange at the moment. The code I personally use is a bit complex, but can be found at User:Gary King/layout.js under "function pagesLayout()". Gary King (talk · scripts) 18:29, 26 November 2011 (UTC)
Thanks for the reply. To me, it doesn't seem strange that only the content is squished to 800px because I don't find a need to have everything other than the content nearby when I'm reading the content. I actually find it suitable to focus on the content I'm reading and not be distracted by the extra elements on the page. This is just my viewpoint anyway. As for the script, I was trying to do this in CSS so that it's merely an application of style sheet properties rather processing of JS. I have attempted to make everything on page restricted to 1000px, but it just makes the page very messy and doesn't work properly. Properties applied on the body or html tag do not affect the left sidebar or the top user links.
I know that JS gives much more power and control over the page elements than CSS, but it wasn't something I had in mind at the time I created the CSS. For me, squishing the content to 800px seems to work well for me, including discussion pages. One place I miss the extra width is logs such as page history. My point in creating in this discussion is actually to make a gadget or preference of similar results (squishing either the contents or entire page) available to all registered users of Wikipedia at their disposal. Or have Wikipedia squish content pages (but not logs or history) by default. Currently neither of my suggestions have been implemented. It's not necessary to be my own CSS or your JS, but something ought to be made available.
Great JS script btw. I don't know what exactly it does (a screenshot would be nice) but it seems to do a lot of useful things :) -- ADTC Talk Ctrb . 06:29, 27 November 2011 (UTC)
There are a lot of things that Wikipedia could do to improve its layout. I suspect it would require a lot of time and discussion to change much around here, though, so I have hundreds of lines of code to make it look exactly how I want. A few examples include adding spacing between separate comments to easily tell them apart, removing most colors from the Monobook skin, such as the logo and the background image, so only the content stands out, highlighting discussion sections that I have commented in or that have had activity in the past 24 hours, etc. Regarding only using CSS, I understand that because JS is sometimes applied after the page finishes loading, which makes it look like things are moving even after the page already loaded. That's why I have both CSS and JS at work here; CSS covers most situations, like 95% of them, and then JS is purely for backup. Feel free to click on "scripts" next to my username to check out some of my stuff, although not all of it is listed there. Gary King (talk · scripts) 07:44, 27 November 2011 (UTC)
I think the Vector skin (now default) is a very nice and clean improvement over the older Monobook skin. It already does some of the things you mentioned, such as removing background image and avoiding unnecessary use of colors. It's cleaner and nicer to look at, IMO. Anyway I hope Wikipedia considers making the option of restricting the page/content width available to all users. PS: I have made some slight modifications today to my CSS. -- ADTC Talk Ctrb . 07:57, 27 November 2011 (UTC)

what's happened with importScript()

What's happened with importScript(). It isn't running anymore and my GoogleTrans gadget won't load.

Has the version of mediaWiki changed? and importScript is not supported anymore. If so, is there any documentation of coding in the new regime.

Endo999 (talk) 03:21, 6 December 2011 (UTC)

importScript() still works for me. I would be shocked if it stopped working in the next few years, because hundreds of thousands of users still use it. Are you using the Monobook skin? If so, then you aren't using importScript() anyway, since you copied the entire script to User:Endo999/monobook.js. It's highly recommended to use importScript() instead, which updates your code whenever the developer does so, which may explain why your version is now broken. Gary King (talk · scripts) 03:28, 6 December 2011 (UTC)
If possible look to use mw.loader.load('//xxxxxxxxxx.js&action=raw&ctype=text/javascript'); is the recommendation these days. This way the script can be cached effectively. More information about Resource Loader is available, especially at mw: — billinghurst sDrewth 11:39, 6 December 2011 (UTC)
+ try adding it to Special:MyPage/common.js as that file is independent of the skin in use. — billinghurst sDrewth 11:40, 6 December 2011 (UTC)

I have more information on this failure to load using importScript(). It happened to me while I was working at the Dept of Social Security in Canberra Australia. They have a heavy proxy filled restrictive environment. It did not happen to me while I was at home. I also received a message (at work) about mw not loading before the error message about importscript not being present. I assume therefore that the underworks of importscript() now actually uses the MW loader feature, and that this new feature was not surviving the heavy proxy restrictive environment of the Social Security dept environment of Australia. It happened while I used either Firefox or IE. Endo999 (talk) 16:25, 6 December 2011 (UTC)

Tabify Vector Skin

Commons has a gadget called "Tabify Vector Skin" at commons:MediaWiki:Gadget-DropdownToTabbar.js:

Tabify Vector Skin: Remove the Vector skin dropdown menu, moving each menu item to an individual tab. (Vector only)

I copied it here and it works fine, it's a trivial script. I think it could be extremely helpful for users who do large numbers of admin actions or moves, since it takes substantially less time to click on a single target than to use a drop down menu (this can be predicted without experiment using Fitts's law). Dcoetzee 14:45, 20 January 2012 (UTC)

That gadget has been deprecated here in favor of MenuTabsToggle, an advanced version. Look for "Enable toggling between tabs and dropdown menus in the Vector skin." under gadgets. — Edokter (talk) — 14:49, 20 January 2012 (UTC)

Feedback tab

User:Slaporte/FeedbackTab.js adds a tab for Article feedback (version 5) for an article if there is any. Try it on the article on Wikipedia, Barack Obama, or any article that shows up in the stream. Stephen (talk) 02:26, 3 February 2012 (UTC)

One my friends developed internal link translator this code helps users to translate articles, templates, categories with their internal links also it has option to change language

how it works?

it adds translate links to fa button next to title of the page and whit clicking on translate it replace other wikis links inside the text .in edit view or general view it has two different works. now we are using it in fa.wiki as external extention and it is realy useful for translating nave boxs . by clicking on fa you can change the language to home-wiki

case for templates

I translated Template:Fars Province Labelled map and Template:Persian Constitutional Revolution Persions from fa.wiki to en.wiki.(by one click!)

case for categories;

in fa.wiki many of the users use this script to copy categories with their upper category

case for lists

I translated many list of cities from de.wiki to en.wiki and fa.wiki

next features

in my opinion it is much better to add possibility to use it as gadget in home wiki but the major problem is when you want to transfer a template or text from second-wiki->home-wiki you must instal it in second-wiki and it is very difficult for elementary users that they cannot work with vector.js also they can not handle it from their home-wiki.if some one can extend this script to ask page name in other wiki (with text box) and transfer translated text to user's sub-page or predefined page it will be useful and possible to handle it in home-wiki.Reza1615 (talk) 20:49, 8 February 2012 (UTC)

Bug tracking helper gadget

The release of 1.19 is imminent, and, to help track any issues reported on WP:VPT, I'd like to get the gadget we have been using on enwiki.beta deployed here. I've found this gadget very useful on the problem reports and hope to use it here. Please add it. -- ☠MarkAHershberger☢(talk)☣ 00:02, 13 February 2012 (UTC)

Does it also need any templates like {{tracked}} on enwiki beta? — Edokter (talk) — 00:23, 13 February 2012 (UTC)
Never mind :) — Edokter (talk) — 00:24, 13 February 2012 (UTC)
 Done. — Edokter (talk) — 00:39, 13 February 2012 (UTC)
arrow Reverted by Tim Starling. Apparently, it overloads Bugzilla. Mark, can you find out what's wrong with the script? — Edokter (talk) — 11:36, 13 February 2012 (UTC)
It looks like the script MediaWiki:Gadget-BugStatusUpdate.js makes its request on every pageview, instead of only when it finds at least one id from {{tracked}} to look up. Anomie⚔ 15:31, 13 February 2012 (UTC)
I had the same idea. I'd fix it myself, but ajax is not my cup of tea. — Edokter (talk) — 15:36, 13 February 2012 (UTC)
That should fix the "query on every pageview, even where {{tracked}} is not used" issue. Whether just the readers of WP:VPT and other pages where {{tracked}} is used would be enough to overload bugzilla, I couldn't say. That's for others (mainly Tim Starling) to decide. Anomie⚔ 16:08, 13 February 2012 (UTC)
I think the <= 0 part is not needed, but it doesn't hurt. Shall we start again by enabling the gadget, this time not as default? Just asking before Tim torches me again. — Edokter (talk) — 21:42, 13 February 2012 (UTC)
Ah, it was enabled by default?!
Nonetheless, I would very much recommend to have Mark or Tim give the OK first. Tim sounded pissed enough to flip a bit in the database if it blows up again … Amalthea 23:26, 13 February 2012 (UTC)
True, !ids.length would work, although ids.length == 0 is a little more explicit about what's going on. My <= 0 is probably a habit from situations where -1 can be returned on error. Anomie⚔ 03:03, 14 February 2012 (UTC)
Tracked in Phabricator
Task T36353
Mark asked me to re-eanble it (default off). Testing to the right. (EDIT) Unfortunately, it does not seem to work. (EDIT2) Fixed. — Edokter (talk) — 22:38, 15 February 2012 (UTC)

Image Siblings

How it would look like

I propose offering Image Siblings written by Magnus Manske as a gadget. --Leyo 17:06, 6 December 2011 (UTC)

The image doesn't quite make it clear what this script does. Does it grab other images in the same category as the image we are currently viewing? Gary King (talk · scripts) 01:15, 7 December 2011 (UTC)
Yes, exactly. If the file is on Commons, it shows files of the same category/categories and gallery/galleries. You can test the gadget in de.wikipedia by enabling it and watching any Commons image over there. --Leyo 08:28, 7 December 2011 (UTC)
I enabled the gadget "ImageSiblings" on de.wikipedia.org and went to this image. I didn't see what was shown in the screenshot, or anything different that I can tell was from the gadget. Gary King (talk · scripts) 18:31, 7 December 2011 (UTC)
I just tried it and it worked for me. But I know that sometimes, probably related to Toolserver problems, it does not work. --Leyo 00:31, 8 December 2011 (UTC)
Still not working for me, with only that gadget enabled (I've never used my de.wiki account), and purging and hard refreshing the image. Gary King (talk · scripts) 20:54, 8 December 2011 (UTC)
After optimizing and internationalizing the script, it also works here. It can be tested using this code. --Leyo 18:39, 16 February 2012 (UTC)

My Sandbox

hello,

I proposed a link to my sandbox, but it was not implemented. There, Anomie adviced me to request it here. Thanks. ♫GoP♫TCN 10:17, 14 January 2012 (UTC)

And?--♫GoP♫TCN 12:51, 13 February 2012 (UTC)

Note the original proposal is at Wikipedia:Village pump (proposals)/Archive 83#Add link to sandbox on the top right corner. The gadget would add "my sandbox" between "my talk" and "my preferences" at the top of the page. The necessary javascript would look something like this: 

mw.util.addPortletLink('p-personal',
                       '/w/index.php?title=Special:MyPage/sandbox&action=edit&preload=Template%3AUser_sandbox%2Fpreload&editintro=Template%3AUser_sandbox',
                       'My sandbox', 'pt-mysandbox', 'Go to my sandbox', null, '#pt-preferences');

The line for MediaWiki:Gadgets-definition should probably go in "appearance", and would look like: 

* mySandbox[ResourceLoader|dependencies=mediawiki.util|default|rights=createpage]|mySandbox.js

Unless there are any overriding last-minute objections, I'll add this soonish. I'll also protect Template:User sandbox/preload and add Template:User sandbox to Wikipedia:Cascade-protected items#Interface templates. Anomie⚔ 17:20, 13 February 2012 (UTC)

 Done Anomie⚔ 03:53, 15 February 2012 (UTC)
It doesn't show on the preferences page. —danhash (talk) 20:56, 15 February 2012 (UTC)
Any site or user JavaScript and CSS do not work in preferences and login pages because of MediaWiki security restrictions. — AlexSm 21:06, 15 February 2012 (UTC)
Makes sense, thanks. —danhash (talk) 21:11, 15 February 2012 (UTC)
Wouldn't it be easier/faster/better in the long run, if this is an interface change that's wanted as a default, to update the appropriate MediaWiki page to add this link, instead of adding more JavaScript to load and run? —danhash (talk) 21:03, 15 February 2012 (UTC)
If implemented as MediaWiki feature this would need an extra checkbox in preferences and devs usually do not want to do that. — AlexSm 21:06, 15 February 2012 (UTC)
Is it a time/benefit tradeoff issue? —danhash (talk) 21:11, 15 February 2012 (UTC)
There is no MediaWiki page that can be edited to add the link. Such a change would require either editing MediaWiki itself (SkinTemplate.php, to be specific) or creating and convincing the devs to install an extension that would use the PersonalUrls hook to add the link. And then, of course, there would have to be the user preference added and such. Anomie⚔ 16:26, 16 February 2012 (UTC)
Should the "My Sandbox" link be appearing in the Monobook skin? I'm not seeing it. Oh nevermind, never figured it'd be near the "my preferences" links. Gary King (talk · scripts) 17:08, 16 February 2012 (UTC)

Okay, I can get why such a thing might be useful to folks, but I have to ask... why was it made default for everyone, especially given the apparent lack of any wider consensus? — Isarra (talk) 05:29, 26 February 2012 (UTC)

The original proposal was to make this link for all users, and was overwhelmingly supported provided that it would be easy to remove (i.e. without adding user css). There are three ways to do this: modify MediaWiki, write a MediaWiki extension and convince the sysadmins to install it, or create an "enabled by default" gadget that people can turn off.
Since the very intention of this was to create the feature for new users who don't know about gadgets and such, having the gadget not enabled by default would completely miss its target audience. Anomie⚔ 20:38, 26 February 2012 (UTC)
Ah, didn't find that one; thanks. — Isarra (talk) 21:01, 26 February 2012 (UTC)

I made a pretty basic gadget on MediaWiki.org that might be of some small use to others here. It shows a contributions link (just a simple link to Special:Contributions, specifying the user's name) on each user/user talk page. (Below the move button on vector.)

It's based on blocktab, with some improvements which I then integrated back into blocktab.

Code.

--Krenair (talk • contribs) 16:53, 27 February 2012 (UTC)

There is already such a link ('User contributions') in the toolbox on the left side of the screen. — Edokter (talk) — 17:41, 27 February 2012 (UTC)
Proposal withdrawn I feel stupid now. --Krenair (talk • contribs) 17:55, 27 February 2012 (UTC)

Regex li filter

I suggest adding Splarka's regexlifilter which Mike.lifeguard amended. --Kangaroopowah 04:43, 21 March 2012 (UTC)

Link: commons:MediaWiki:Gadget-rightsfilter.js --Leyo 08:44, 21 March 2012 (UTC)

Watchlist script

I propose User:Js/watchlist.js (documentation at User:Js/watchlist) as a new gadget. It adds the ability to unwatch pages directly from the watchlist using Ajax, and has some other handy features. Ucucha 12:10, 19 June 2011 (UTC)

This seems like a great idea, but why are you using so many obscure symbols for your interface? It makes it quite confusing to use. Why not just use words like "Add unwatch links", "Use alternate sorting", and "Hide options"? This would make it a lot more user friendly. Kaldari (talk) 07:14, 25 October 2011 (UTC)
Also it seems rather pointless that I have to re-enable the unwatch links every time I visit my watchlist. Why not just turn them on by default? Isn't that the main reason for people to use the script? Kaldari (talk) 07:16, 25 October 2011 (UTC)
The main reason for "obscure symbols" was to occupy less space and it can be changed very easily if needed. The same goes for "onload" unwatch links (which is a user-defined parameter right now). As for the last question, I use the script mostly for "only new" link. — AlexSm 20:49, 25 October 2011 (UTC)
The watchlist options area has plenty of space. I don't see any reason the links need to be shortened into mysterious symbols. Also, why not store the users settings in a cookie, so it remembers them? This would be easy to implement. Kaldari (talk) 21:31, 25 October 2011 (UTC)
The symbols aren't really mysterious, I think everyone knows what an x is and there are hover descriptions. As for the cookie, well that could be useful but it's really just one click. --Kangaroopowah 06:06, 14 November 2011 (UTC)
So is this a good idea for a gadget? --Kangaroopowah 04:38, 8 December 2011 (UTC)
I think it's a great idea for a gadget, but needs some polish before it is added as an official gadget. I stand by my contention that the use of symbols for many of these links is confusing. For example, it is not at all obvious that 'x' means 'add quick unwatch links'. Usually 'x' means remove something, not add something, so this is very unintuitive. This should be changed to simple text: 'Add unwatch links'. Actually, the link should be removed completely and this should be the default behavior. What's the point of me enabling the gadget if I have to manually activate it every time I go to my watchlist page? Also, it is not at all obvious that a pair of up and down arrows means change the sorting method. I would assume that it meant show older or newer changes than the current view if I had to guess (based on the context). And the hover description for this link isn't even accurate—it sorts by title first, then by namespace. This link should be changed to 'Sort alphabetically'. As I said before, there's plenty of space here for long link titles, so there's no logical reason for us to use symbols. I'm fine with having the x's next to the change listings for actually unwatching, but the other links should be removed or spelled out. Kaldari (talk) 20:51, 8 December 2011 (UTC)

(Reset Indent)I agree with you on everything except that the unwatch should be by default. I don't want to accidentally unwatch something. --Kangaroopowah 02:36, 9 December 2011 (UTC)

Any new comments? --Kangaroopowah 02:00, 6 April 2012 (UTC)

Reference Tooltips

A reference tooltip. (Not actual screenshot.)

I propose adding mw:Reference Tooltips (designed by Brandon Harris) as a gadget. JS and CSS at User:Yair rand/ReferenceTooltips.js and User:Yair rand/ReferenceTooltips.css, respectively. --Yair rand (talk) 22:02, 6 December 2011 (UTC)

How do this differ from the existing feature in navigation popups, enabled as a gadget for 34,000 users? — Dispenser 23:52, 6 December 2011 (UTC)
Mostly in the presentation. I don't think many users are interested in seeing "Article#cite_note-XXX-2 ⋅ actions ⋅ popups / ^ a b c" in the tooltip, and many users would probably prefer to be able to see references without going to the bottom of the page and probably losing their place, but not have every link bring up a large popup box. (Also: I'm hoping that this script, or something like it, will eventually be enabled by default at some point, and I thought being a gadget might be a good intermediate step.) --Yair rand (talk) 00:13, 7 December 2011 (UTC)
I would definitely use this gadget, but not navigation popups. I have no use for pop-ups on every link, but ref pop-ups seem quite useful, and the presentation of the ref pop-up in this gadget doesn't make my head hurt. I would support this being added as a gadget. It should be noted, however, that the current implementation only works in modern browsers (as far as I can tell). Kaldari (talk) 00:34, 7 December 2011 (UTC)
I wasn't able to test it on old browsers, but I had hoped the only issues would be a purple coloring of the arrow and the lack of box-shadowing. Do you know what else breaks? --Yair rand (talk) 03:19, 7 December 2011 (UTC)
Got it working for IE7. --Yair rand (talk) 06:15, 21 December 2011 (UTC)
I will test this later. How does it compare to User:Blue-Haired Lawyer/Footnote popups or User:Anomie/reftooltip.js. ---— Gadget850 (Ed) talk 01:27, 7 December 2011 (UTC)
Anomie's script just overwrites the title attribute, so it's not possible to click on the references, and Blue-Haired Lawyer's creates a box that covers the whole area, including the words surrounding the ref. --Yair rand (talk) 03:19, 7 December 2011 (UTC)
Well popup can be configured (I think) to not show with general links, but plenty of people like that. The designed (based off classic skin) has yet to be changed after 7 years despite the ease of doing so. Finally, WMF generally rewrites everything added to the site (for security reasons), so I'm afraid your efforts are in vain.
An improvement I'd suggest is to make it function more like the Office 2007's floating tool bars where it become non-linearly less transparent with the closer the mouse is. — Dispenser 02:15, 7 December 2011 (UTC)
Re: "WMF generally rewrites everything added to the site", I don't think that's correct... --Yair rand (talk) 03:19, 7 December 2011 (UTC)
I like this, especially compare to the other scripts.
  • It seems to only work with Vector
  • If the in-text cite is at the top of the window, the popup is not visible
  • If regular popups are enabled, you get two popups
  • Links in the popup do not popup— they do with regular popups
---— Gadget850 (Ed) talk 05:30, 22 December 2011 (UTC)
Re non-Vector skins: Thanks for pointing this out, I've now fixed it so that it works with other skins. --Yair rand (talk) 05:38, 22 December 2011 (UTC)
I prefer fr:MediaWiki:Gadget-tooltipRef.js and fr:MediaWiki:Gadget-tooltipRef.css and the screen is in fr:Aide:Gadget-tooltipRef. it has link to bibloghrafy and citacion part.Reza1615 (talk) 19:58, 8 February 2012 (UTC)
To the best of my knowledge, on English Wikipedia references don't generally have standardized links to a further Bibliography section with a convenient renvois_vers_le_texte CSS class (or equivalent) over every link, like they do on the French Wikipedia, so that specific feature couldn't really work here. --Yair rand (talk) 20:27, 8 February 2012 (UTC)
From the picture, I would love this script. I haven't been able to get it to work though. Is the current code working? —danhash (talk) 19:12, 14 February 2012 (UTC)
You need to also import the CSS for it to work. The full code for importing both the JS and the CSS is importScript('User:Yair rand/ReferenceTooltips.js');importStylesheet('User:Yair rand/ReferenceTooltips.css');; you only added the first part. --Yair rand (talk) 20:05, 14 February 2012 (UTC)
I LOVE IT. —danhash (talk) 20:33, 14 February 2012 (UTC)
Looking at the code review, I think this will not be enabled by default. ---— Gadget850 (Ed) talk 19:21, 14 February 2012 (UTC)
Just discovered this one while testing scripts for inclusion in the new user script list, and I think it should definitely be a gadget. Everyone will love being able to read ref info without jumping away from the text, and this does so quite elegantly. It can be marked as vector-only in the gadget list, if that's an issue... Equazcion (talk) 16:15, 27 Mar 2012 (UTC)
I'd place an editprotect request over here, tbh. I use it and I'm really happy with it. --Kangaroopowah 00:54, 3 April 2012 (UTC)
Hm, apparently editprotects can't actually be placed except on talk pages... --Yair rand (talk) 16:38, 3 April 2012 (UTC)
I started Wikipedia:Village_pump_(proposals)#Gadget_proposal. Equazcion (talk) 17:02, 3 Apr 2012 (UTC)
User:WOSlinker has added this as a gadget. Equazcion (talk) 18:55, 4 Apr 2012 (UTC)

You know, I love the idea of this; given that hypertext is such a dynamic medium I've actually been surprised in the past that something like this wasn't built-into the extension already. In that vein, I can't help but think that some of the folks who would benefit the most from this are readers - people without accounts at all. What of them, might that be a possible later step once bugs and other issues are worked out? — Isarra (talk) 21:40, 4 April 2012 (UTC)

I had that same thought. Convincing the powers that be to implement new javascript for all might prove difficult though. Equazcion (talk) 22:19, 4 Apr 2012 (UTC)
Can it hurt to try? — Isarra (talk) 23:10, 4 April 2012 (UTC)
For javascript changes to this project, the only "powers that be" are the English Wikipedia community. I plan to propose at the Village Pump in about two weeks that this gadget be enabled by default. --Yair rand (talk) 23:30, 4 April 2012 (UTC)
Well, in theory yeah, but then you need to contend with the developers and Foundation people who answer bugzilla requests, and their accompanying egos. I've been through that before and I'm just saying, in practice it's proven not quite as simple as getting community consensus. But no it can't hurt to try, and I'll support it. Equazcion (talk) 12:38, 5 Apr 2012 (UTC)
This doesn't actually need a bugzilla request, that's only for installing extensions, modifying the Mediawiki software, changing local Mediawiki configuration, everything that uses PHP. For this, all that's necessary is for an admin to add "[default]" right after ReferenceTooltips in Mediawiki:Gadgets-definition. --Yair rand (talk) 15:34, 5 April 2012 (UTC)
I guess I stand corrected. Though I have a feeling they'd still get involved for something like this. They view stuff that affects anons by default pretty seriously. I'm up for proposing it, just saying it could be tough. Equazcion (talk) 16:21, 5 Apr 2012 (UTC)
Maybe, but I don't know why there should be issue with this particular proposal. Now turning the skin pink, that might... nevermind.
Regardless, two weeks from now should prove fun. The community here can be a very scary power. — Isarra (talk) 17:53, 5 April 2012 (UTC)
A feature very similar to this is part of the new mobile interface that is currently being beta tested. Also, I would like to see a half-second delay set on the pop-up trigger, so that simply moving the cursor across a ref by accident doesn't trigger it. Kaldari (talk) 18:28, 5 April 2012 (UTC)
identical functionality is available in hewiki for about a month now, and activated as default for a little less then this. our version use the tipsy jquery plugin, and as a result "delayIn" and "delayOut" are available (we use 300 ms for delayIn and 1500 for delayOut). code is significantly simpler (can be made even more simple for enwiki, because part of it deals with bidiretionality - in hewiki cites can be LTR or RTL). because we use tipsy, we don't need an additional css page, either.

you can see how it works (even if you do not read Hebrew), e.g., here, because it's on by default.

the script itself is here: he:Mediawiki:Gadget-CiteTooltip.js. peace - קיפודנחש (talk) 16:27, 21 April 2012 (UTC)

cat-a-lot

Hi, I found a version of commons:MediaWiki:Gadget-Cat-a-lot.js that works on wikis ( change page's instead of file's categories). we use it in fa.wiki (fa:مدیاویکی:Gadget-Cat-a-lot.js) may be it is interesting for you.Reza1615 (talk) 09:41, 16 February 2012 (UTC)

Yes, please! :) Kaldari (talk) 23:35, 15 May 2012 (UTC)

Diffs: old colours

There is a CSS gadget at commons, commons:MediaWiki:Gadget-DiffOldStyle and associated commons:MediaWiki:Gadget-DiffOldStyle.css, which gives something approximating the old yellow/green style for page diffs. Please could it be added here; and, if possible, brought closer to the actual old behaviour (slightly bigger font, bolded red text). --Redrose64 (talk) 21:59, 23 April 2012 (UTC)

I just added it 15 minutes ago. — Edokter (talk) — 22:02, 23 April 2012 (UTC)
Oh yes, Thank you - I wasn't watching MediaWiki:Gadgets-definition but fooling around with User:Redrose64/common.css and wondering how far back from rev:113098 I'd have to go to find the old colour scheme. --Redrose64 (talk) 22:43, 23 April 2012 (UTC)

Gadget to assist people with Red/Green colour-blindness issues (from de.wikipedia)

Hi. I'd like to propose the import and usage on this Wikipedia of a useful little gadget which exists at the German Wikipedia as part of their project to assist people with disabilities - simply known there as the Red/Green Sight deficiency gadget, it's intended to change the background of red & green text in situations where it would be difficult for people with Red/Green colour-blindness to distinguish them.

I have some issues with this particular form of colour-blindness, and have found the gadget to be really useful there, and would like to see it imported here as an accessibility feature. At present, it's optimised for monobook, but I am sure it could be adapted to work in other skins, and may already do so - I don't know, since I only use monobook on all wikipedias. You can see a copy of the (very basic) script, here. Cat in the Hat | To the Thinga-ma-jigger | Whistle for Things 1 and 2 21:36, 15 May 2012 (UTC)

Needs to be tested in the other skins and updated to work with all skins if possible. Would you please describe the specific changes and possible a reference that shows us why this is useful. ---— Gadget850 (Ed) talk 22:27, 15 May 2012 (UTC)
Of course. The primary changes are that when a page colour is unsuitable to display red/green against, without the risk of misidentification, the script can change the background colour surrounding the text to increase its contrast or luminosity, so that colours show up better and become more distinguishable. Red and Green for example, even to a person with red/green deficiency, show up better against a yellow background, than say, grey, or pale blue.
The difference between the colour of the text and the background has to be sufficiently high enough to enable the reader to separate and distinguish the variant colours for identification. You can read more about it in this piece from Penn State University which includes a table showing the contrast colours and how they vary. The main place sit works at the moment are on diffs and unpatrolled pages, as you can see from the CSS there. Cat in the Hat | To the Thinga-ma-jigger | Whistle for Things 1 and 2 22:49, 15 May 2012 (UTC)

Note - A friendly editor of the German Wikipedia has politely pointed out to me that I linked to the wrong code on the site, and the correct one is now included above - this is the one I have switched on at de.wp, not the one you may have seen previously. Thanks. Cat in the Hat | To the Thinga-ma-jigger | Whistle for Things 1 and 2 00:01, 16 May 2012 (UTC)

Open search result list or search suggestion in a new tab

commons:User:Rd232 has developed some JavaScript that opens search results and suggestions in new tabs. It works on both the Commons and Wikipedia. See:

Could a gadget for this be put in preferences? --Timeshifter (talk) 04:52, 4 April 2012 (UTC)

Putting an "advanced search" (Special:search) link in the sidebar would fix the problem too. People could right-click it to open it in a new tab. Most readers do not know much about how to find stuff on Wikipedia. They try the search form, but soon see that it covers up the page they are looking at. Many people stop using the search form after that, and use Google Toolbar instead for site searches.

But Google Toolbar does not allow one to pick and choose namespaces to search. Special:search does do this. Also, Google no longer makes Google Toolbar for Firefox. So, putting an "advanced search" link in the sidebar would solve many problems. --Timeshifter (talk) 23:50, 23 April 2012 (UTC)

There is already a preference (on the gadgets tab) to "Open external links in a new tab/window". Why not search too? If there was a preference to "Open search results list and search suggestions in a new tab/window" then clicking on the magnifying glass icon to the right of the search box would take one to Special:Search. This works even when the search form is empty. See commons:MediaWiki talk:Search-results-new-tab.js to test this. It works. --Timeshifter (talk) 17:33, 31 May 2012 (UTC)

Shift to open search in new tab

Another possible option is to hold shift to open search results in new tab. I suggested the code in mediazilla:23866#c3 and then added for everybody in my home wiki (ru:MediaWiki:Vector.js). The major disadvantage of course is that most user will not read the help page and won't know about this ... — AlexSm 14:14, 1 June 2012 (UTC)

There is related discussion here:
https://bugzilla.mozilla.org/show_bug.cgi?id=17754
mw:Thread:Extension talk:InputBox/Option to open results in new tab
I wonder if anything has been suggested for inclusion in a future HTML standard: That submit form buttons should have the ability to be right-clicked and opened in a new tab. One of the above threads concerns Firefox. But even though it is a highly requested feature, it looks like Firefox management is not going to implement it. --Timeshifter (talk) 12:39, 30 June 2012 (UTC)
"Shift to open search in new tab" works on every page with the Opera (web browser). Regards, mabdul 16:13, 30 June 2012 (UTC)
I use this on Wikipedia for the Firefox browser: commons:MediaWiki talk:Search-results-new-tab.js - but sometimes I don't want to open search result lists in a new tab. So it would be better if a MediaWiki gadget could be developed that allowed one to right-click search form buttons. Then I could choose every time whether to open search result lists in a new tab. --Timeshifter (talk) 08:12, 1 July 2012 (UTC)
Using right-click requires you to disable the browser context menu. Many people find this annoying, plus not all browsers allow you to do that. — AlexSm 02:46, 11 July 2012 (UTC)
Right-clicking search submit buttons (not links) in Firefox does not do anything. No context menu pops up. Right-clicking search submit buttons (not links) in Internet Explorer sometimes brings up a context menu but it never contains "open link in new tab", or "open link in new window". That only happens when right-clicking links. So for my idea to work search submit buttons would somehow have to also be a link. I believe this is possible. In Special:Search all the search options initially below the search form are in the form of links, and can be right-clicked and opened in a new tab or window. --Timeshifter (talk) 18:33, 11 July 2012 (UTC)
AlexSm. I see that the JS at ru:MediaWiki:Vector.js is this:
$('#searchform').bind('keyup keydown mousedown', 
  function (e){ $(this).attr('target', e.shiftKey?'_blank':'') })
I tried it at User:Timeshifter/common.js and it works fine for the top-right search form on every page.
I expanded the list to this:
$('#searchform, #search, #powersearch, #searchbox, .search-types, #search-types').bind('keyup keydown mousedown', 
  function (e){ $(this).attr('target', e.shiftKey?'_blank':'') })
So now it works on Special:Search and archive searches such as this:
Template:Village pump page header
I got the expanded list from here: commons:MediaWiki:Search-results-new-tab.js. I do not understand JS. I just experimented by copying the list from there.
It does not work perfectly. Some of the tab searches in Special:Search open in new windows in Firefox instead of new tabs. I have Firefox option set to open in new tabs instead of new windows. So I do not understand why some of tab searches in Special:Search open in new windows instead of new tabs. --Timeshifter (talk) 12:13, 7 July 2012 (UTC)
Tab browsing is a feature of the browser. Choosing a new window or tab is at the discretion of the browser. I'm not sure why you get inconsistent results and I cannot reproduce this. — AlexSm 02:46, 11 July 2012 (UTC)
My bad. Your JS code with my additions works perfectly for all search submit buttons. Even here:
Template:Village pump page header - shift-click the archive search button.
As you said, how links are opened though is dependent on the browser and its options. I was confusing the search links with the search buttons. --Timeshifter (talk) 18:49, 11 July 2012 (UTC)

Ctrl-click to open search in new tab

Add the following revised JS to Special:MyPage/common.js 

/* Ctrl-click to open search buttons in new tab */

$('#searchform, #search, #powersearch, #searchbox, .search-types, #search-types').bind('keyup keydown mousedown', 
  function (e){ $(this).attr('target', e.ctrlKey?'_blank':'') })

Ctrl-click now works for opening both Wikipedia search buttons and Wikipedia search links in new tabs.

In Special:Search the search options initially found below the search form are in the form of links. The search form itself uses a submit button.

Changing the JS gadget code discussed in the previous talk section to use ctrl-click instead of shift-click solves most problems discussed in the previous talk section.

This is because in Firefox and Internet Explorer one can ctrl-click to open links in new tabs. One can shift-click to open links in new windows.

So the above JS code allows ctrl-click of search buttons on Wikipedia to also open up in new tabs. --Timeshifter (talk) 19:24, 11 July 2012 (UTC)

There is more discussion here:
There is a JS gadget import that works across wikis:
commons:User talk:Timeshifter/Open search in new tab.js --Timeshifter (talk) 21:33, 8 August 2012 (UTC)
See proposal farther down to add this gadget to Special:Preferences#mw-prefsection-gadgets. --Timeshifter (talk) 05:33, 15 August 2012 (UTC)

Support or oppose adding gadget to open search in new tab

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

Please indicate your support or opposition, and why. Of the various search gadgets I am focusing on this one. I think it gives the most options to users. Can this gadget be put in Special:Preferences#mw-prefsection-gadgets?

This gadget enables the opening of search result lists and search suggestions in a new tab by using Ctrl-click (PC) or Command-click (Mac). See JavaScript (JS) here:

See import info, and other info here:

I am starting a discussion at Wikipedia:Village pump (technical) also, since this discussion forum is not always very busy. --Timeshifter (talk) 05:28, 16 August 2012 (UTC)

Oppose. If you really want to make a do this then make it so that when you click the search icon it opens in a new tab. Much more effective, and gives much more preference to the user. Btw, who actually has wanted this except you? (Not trying to be mean or anything, I'm legitimately curious) --Kangaroopowah 17:05, 16 August 2012 (UTC)
Many people hate it when clicking a link or search button auto-opens a new tab. There is a tool that does that. You have to import it to your JS. See: commons:MediaWiki talk:Search-results-new-tab.js.
Everyone commenting so far at the Wikipedia:Village pump (technical) supports adding the gadget. This gadget gives the user more control. Sometimes I want a new tab when doing searches at Special:Search, and sometimes I don't. This gadget gives me the option just by holding down the control key when clicking the search button. --Timeshifter (talk) 18:10, 16 August 2012 (UTC)
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 and admin in IRC to add it --Kangaroopowah 23:10, 16 August 2012 (UTC)
Even if enabled by default in gadget preferences which is what most people want at Wikipedia:Village pump (technical), it will not auto-open search in a new tab ever. One has to hold down the control key at the same time as clicking the search button. See:
Wikipedia:Village pump (technical)/Archive 102#Support or oppose adding gadget to open search in new tab --Timeshifter (talk) 05:26, 17 August 2012 (UTC)

Village pump discussion shows strong support for adding gadget

Please see:

This really does not belong in a gadget, but in the site js or possibly even mediawiki core. Not opening a new tab with the ctl/whatever combination is purely a browser issue for which cluttering up the gadgets list would be needless; clicking on the search thing with the appropriate key-combination really should do that already, and does in Opera and Chrome. Since apparently other browsers currently don't support that, however, adding a workaround module to the site js for those for the time being until they do seems in order, but it would need to be consistent with the new tab combinations used elsewhere on said browsers. -— Isarra ༆ 19:03, 16 September 2012 (UTC)
There has been a lot of discussion about all those things you mentioned. See:
commons:User talk:Timeshifter/Open search in new tab.js#Discussion elsewhere
There are several Bugzilla threads linked there. Core MediaWiki developers seem to be preoccupied making crap like Wikipedia:LiquidThreads and later boondoggles.
This gadget works now in all tested browsers, and consists of a couple lines of JavaScript. I use it frequently. For people who actually use Wikipedia's search and Common's search instead of Google site search this is very useful. It got good support at the Village Pumps. People will use it. Why wait years for it to be incorporated into MediaWiki. Plus as a gadget it risks nothing since it can be turned off. --Timeshifter (talk) 20:16, 16 September 2012 (UTC)
Okay, stick it in the site js. Problem solved. Seriously, there are too many gadgets already, and if it causes Bad Things in the main js down the road, they can be fixed there same as in a default gadget. -— Isarra ༆ 22:08, 16 September 2012 (UTC)
No, getting it into the site JS won't happen anytime soon. If you think so, feel free to propose it again at Bugzilla. The old "too many gadgets" line does not fly in this case. --Timeshifter (talk) 00:51, 17 September 2012 (UTC)
MediaWiki:Common.js. -— Isarra ༆ 20:43, 17 September 2012 (UTC)
There is further discussion at these 2 locations:
MediaWiki talk:Common.js#Open search result list or search suggestion in new tab.
MediaWiki talk:Gadgets-definition#The search gadget is now a preference on the Commons. --Timeshifter (talk) 12:59, 25 September 2012 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Gadget/proposals/Archive_4&oldid=1144526673"