Jump to content

Wikipedia:Gadget/proposals

From Wikipedia, the free encyclopedia
< Wikipedia:Gadget

This is an old revision of this page, as edited by Isarra (talk | contribs) at 06:23, 16 September 2012 (→Edit tools). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

Shortcut

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)[reply]

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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
So is this a good idea for a gadget? --Kangaroopowah 04:38, 8 December 2011 (UTC)[reply]
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)[reply]

(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)[reply]

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

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)[reply]

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)[reply]
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)[reply]
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)[reply]
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)[reply]
Got it working for IE7. --Yair rand (talk) 06:15, 21 December 2011 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
I LOVE IT. —danhash (talk) 20:33, 14 February 2012 (UTC)[reply]
Looking at the code review, I think this will not be enabled by default. ---— Gadget850 (Ed) talk 19:21, 14 February 2012 (UTC)[reply]
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)[reply]
Hm, apparently editprotects can't actually be placed except on talk pages... --Yair rand (talk) 16:38, 3 April 2012 (UTC)[reply]
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)[reply]

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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]

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)[reply]

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

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)[reply]

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)[reply]
Proposal withdrawn I feel stupid now. --Krenair (talk • contribs) 17:55, 27 February 2012 (UTC)[reply]

Regex li filter

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

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

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]
"Shift to open search in new tab" works on every page with the Opera (web browser). Regards, mabdul 16:13, 30 June 2012 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]

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)[reply]

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)[reply]
See proposal farther down to add this gadget to Special:Preferences#mw-prefsection-gadgets. --Timeshifter (talk) 05:33, 15 August 2012 (UTC)[reply]

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)[reply]

I just added it 15 minutes ago. — Edokter (talk) — 22:02, 23 April 2012 (UTC)[reply]
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)[reply]

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)[reply]

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)[reply]
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)[reply]

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)[reply]

Turning Sharebox into a gadget

We still get requests like this once in a while, so I think turning Sharebox into a WP:Gadget may be a good idea. Personally I strongly dislike Facebook, but that is just my POV. Arcandam (talk) 01:47, 23 May 2012 (UTC)[reply]

Hmm I was under the impression that it already was. Yeah that should be a gadget. Gets requested often enough. Equazcion (talk) 05:58, 23 May 2012 (UTC)[reply]
As long as its description comes with a reminder of the privacy concerns which were mentioned on previous discussions... Helder 12:43, 23 May 2012 (UTC)[reply]
Good point. I asked TheDJ for a good description of Sharebox which mentions the possible privacy concerns. If this becomes a gadget they will be mentioned. I expect that those with privacy concerns are not very interested in using this gadget anyway BTW. I would strongly oppose a opt-out version, but as long as it stays opt-in its no problem. The stream of requests for a share button (an opt-out version), which is never going to happen anyway, would stop; we can simply tell people to use that gadget if they want to. Arcandam (talk) 20:33, 23 May 2012 (UTC)[reply]
Agree with Arcandam and Helder. Privacy concerns would have to be stated up front, and it would need to be opt-in. --Nouniquenames (talk) 05:51, 24 June 2012 (UTC)[reply]

Advisor.js proposal, II

This has already been suggested four years ago, I wonder why it hasn't been added as a gadget. I've been using this script now for several months, and it is simply amazing. Very, very helpful. --bender235 (talk) 18:49, 7 June 2012 (UTC)[reply]

  • I support the addition, although I would like to see that somebody would overtake the development... (I have some ideas and already implemented (in an other script) solutions...) mabdul 11:37, 24 June 2012 (UTC)[reply]

Easy "leave a comment" gadget

NOT DONE
The need for this gadget has been superseded by improvements to the Article feedback tool and its deployment to Help pages. the wub "?!" 20:33, 4 September 2012 (UTC)[reply]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

I would like to propose adding a new gadget, which would be enabled by default. This is based on Andrew's #Teahouse gadget discussed above, but more flexible and with some slight changes in behaviour. Basically wherever the template {{commentr}} is used, it creates a link which pops up a small form. This can be used to leave a message, which is saved as a new section either on the current page or on a page specified as a template parameter. If JavaScript is not available, or the browser's implementation is FUBAR (glares at Internet Explorer 6), then the link will just go to the standard edit form.

The initial use case for this will be part of my Help Project fellowship. The idea is to place this template on certain important help pages, and collect feedback in a centralised location such as Wikipedia:Help Project/Feedback for attention and action by Help Project members. Since many of the people using the Help pages are not experienced Wikipedians, having a simple popup form without the complexities of the standard editing form will be better for them. In creating this gadget I've attempted to make it fairly flexible, so that it can be adopted for other projects in future if desired. The text and style of the form are all customisable by using template parameters.

I've tested in most major browsers (Chrome, Firefox, IE 7+, Safari), and apart from the above mentioned IE6 problem didn't see any issues. If people want to see the code it's currently at User:The wub/commentr.js and User:The wub/commentr.css, and if you wish to test you can add the following to Special:MyPage/common.js: 

importScript( 'User:The wub/commentr.js' );
importStylesheet( 'User:The wub/commentr.css' );

If there are no problems or objections, I'd like to go ahead and enable this next week. the wub "?!" 12:54, 17 June 2012 (UTC)[reply]

It sounds like a bad idea to me. Why did you re-invent the wheel? You are not fixing the problem you claim exists, you are creating a workaround. If your popup form has an advantage over the default edit window because it is easier to understand we should change the default edit screen. Teaching n00bs two methods (or three if you include the WP:AFT5, or four if you include WP:New editor feedback) to leave some feedback is more difficult than just one. Do you have consensus to "go ahead and enable this next week"? Do you think the decision to "go ahead and enable this next week" should be made by you? Why? Did you coordinate a community discussion about this? Where? Arcandam (talk) 09:00, 18 June 2012 (UTC)[reply]
Hm, it wasn't my intention to sound rude, I apologize if I did. The people in my country are famous (and infamous) for being blunt and brutally honest which can be interpreted as being rude. I am happy to see the great number of new proposals for tools that all have one thing in common: they enable a person who reads an article to leave a comment without visiting the talkpage. But if using a separate talkpage is simply too hard, why not move the functionality of the talkpage to the bottom of every page? Arcandam (talk) 15:02, 18 June 2012 (UTC)[reply]
The standard editing form has a lot of features that are important for normal editing of the encyclopedia, but for readers and new editors to leave a quick comment it's slow and overcomplicated. They click the link, get taken to a big form with all these irrelevant features and warnings ("Content that violates any copyrights will be deleted. Encyclopedic content must be verifiable.", "If you wish to run a test, please edit the Sandbox instead."), and then once they find and click Save they get dumped to a different page from the one they were looking at. It's possible to add editnotices for guidance, but they can easily be overlooked among the other interface elements. Also note that I'm hoping to deploy this to reader-focused help pages such as Help:Searching, where people won't be familiar with editing.
In contrast the Teahouse gadget has been well received among new editors there (see the recent pilot report), and makes for a much more streamlined process which is consistent with expected behaviour from other websites. In fact I'd say we aren't really teaching people two methods of editing: this method is intuitive enough that it doesn't involve teaching at all.
Obviously there's some overlap with the Article Feedback Tool, and using a version of that was my initial plan. However the extra development time that would have been needed on an already stretched project was too great for the payoff. This javascript approach was a quick and simple alternative. I'm in complete agreement that we need to improve the standard editing and talk page experience, but that's a little outside the scope of my project and skillset. You'll be pleased to know that people far more qualified than I am are hard at work on this, with the visual editor program.
As for community discussion: well, this is it. Wikipedia is not a bureaucracy, so we have a fairly lightweight process for proposing new gadgets. the wub "?!" 20:54, 19 June 2012 (UTC)[reply]
once they ... click Save they get dumped to a different page from the one they were looking at - how so? --Redrose64 (talk) 20:58, 19 June 2012 (UTC)[reply]
See the bottom of Help:Searching for an example of the current system. They click that link, and end up editing Help:Searching/feedback, so are left there once they click save. the wub "?!" 21:42, 19 June 2012 (UTC)[reply]
Sorry, because you began with The standard editing form has a lot of features that are important for normal editing of the encyclopedia I was under the impression that you were discussing the regular Edit tab, or a section's [edit] link. Upon hitting "Save page", those take you back where you came from. --Redrose64 (talk) 12:05, 20 June 2012 (UTC)[reply]
Apologies, I should have been clearer. We want the feedback to be recorded on a different page (not cluttering up the help pages themselves), but do want a visible link on the help page to add feedback. That's where I'm worried confusion could arise. the wub "?!" 14:19, 20 June 2012 (UTC)[reply]
Well, if this is the discussion then I must inform you there are objections and problems, so you cannot "go ahead and enable this next week". I don't know you so please do not take this personally, but I do know the WMF, so I will have to make this very clear:
Do not, I repeat, do not enable this until we've had a decent discussion about it.
I apologize for treating you like this, I feel like I have to. To be honest I have no reason to assume you should be treated like this other than the fact the WMF is sponsoring you. I feel like I am being mean to you, but that is not my intention. I think you are probably aware why I act in this strange way. Just in case you are not: the reason is that I had a couple of bad experiences with the WMF making hasty and stupid decisions and overruling knowledgeable users and ignoring feedback. Again I must stress the fact this is not your fault and you have nothing to do with that. But would you be so kind to promise me we can have a decent discussion first before this will be enabled? I know, I am paranoid and crazy (sorry about that!), but reading that promise would be a huge relief to me. Remember: "Spoilers" may be excluded. Arcandam (talk) 23:24, 19 June 2012 (UTC)[reply]
You need to calm down. The wub proposed the gadget in a public forum the same way any community gadget is added to the site. If the Foundation wanted to impose something on the site, we could just add it. We wouldn't go to a community forum and ask for feedback. The wub is doing that because he's a community member first and foremost, and is here in good faith. I would ask that you show the same. Steven Walling (WMF) • talk 02:03, 20 June 2012 (UTC)[reply]
Would you please be so kind to explain what you mean with that last sentence? I am not a native speaker. How should I interpret that sentence? I hope I misunderstand. Are you claiming I did not act in good faith? If so, do you have any proof whatsoever? If not, would you be so kind to explicitly state that? Thanks in advance, Arcandam (talk) 02:10, 20 June 2012 (UTC)[reply]
I am aware of the fact that the WMF can do whatever it pleases. Like I said before I've had a couple of bad experiences with the WMF making hasty and stupid decisions and overruling knowledgeable users and ignoring feedback. But the world is a complicated place; just because the WMF did some things I disagree with does not mean I am anti-WMF in general. I know for a fact that at least two people who work for the WMF are very smart. I also know that I agree with at least 80% of what those people say/do/decide. I also know that some other people working for the WMF have made decisions I agree with. If I would believe the WMF was evil I wouldn't be here. But I do believe two heads are better than one. And I do believe that good-faithed people can make mistakes (I know this from experience). I also believe in giving honest feedback but I will always try to take the circumstances in consideration. As far as I can remember I have never spoke to the wub before so I have no reason to like or dislike the wub. I am politely asking the wub to delay the implementation until we have had a decent discussion about it. Even though it is likely the wub is already aware of it I posted a link about excluding spoilers, a rule that protects us from editors who do not participate in a good-faith effort to move the discussion forward. That means I believe it is possible to have a constructive discussion about this. The worst case scenario is that the community discussion about implementation is a complete waste of time. If that is the case at least we can say we've tried. But there are plenty of smart people in this community, with valuable opinions, so I think that that worst case scenario is rather unlikely. Arcandam (talk) 06:05, 20 June 2012 (UTC)[reply]
I'll be the first to admit the Foundation have made mistakes in the past, but I think we're getting sidetracked here. Did my reply above address your concerns about this gadget or not? What objections or questions do you have that I can help with? the wub "?!" 14:32, 20 June 2012 (UTC)[reply]
Yeah, we got a little sidetracked. Basically the only important thing I want to ask you for now is to give the community some extra time to give feedback instead of turning the gadget on next week, with an opt-out system. I am not talking about months or years, you said next week and I ask for a couple of extra days if that is possible. I am intentionally being a bit vague by saying "until we've had a decent discussion about it", I am not sure how long that would take, but it should be doable with an extra couple of days. Your reply above was very helpful, I think we want to move in the same direction, we just picked different ways to achieve the same goal. I will try to find some spare time in the next couple of days to write a more detailed explanation of my opinion. Feel free to use or ignore it. It may be a good idea to ask a couple of people if they are willing to provide feedback. Do you mind if I do? Even though the name Arcandam suggests otherwise I will not pretend I can predict what the result will be, but I can tell you what I hope for: things like bugfixes, mergeproposals, feature requests, designtweaks et cetera et cetera. Maybe we can also brainstorm together as a community about where and how we want to receive feedback. I think it is a good idea to make it an opt-in gadget ASAP so that those who want to test it can do so more conveniently BTW. Arcandam (talk) 14:46, 20 June 2012 (UTC)[reply]
Bugfixes, fair enough if you see any, that's the main reason I posted here. Although the code is mostly the same as the already-enabled Teahouse gadget, Andrew Garrett has looked at my changes and didn't mention any problems with them, and I've done pretty extensive testing of my own. I'm not however willing to spend weeks bikeshedding over this, or building it into some über-comments system, since my work on this is for a limited time which is already ticking away. Perfect is the enemy of good. I believe this gadget in its current form is a marked improvement over the current system for leaving feedback on help pages, and will prove valuable for improving them. the wub "?!" 21:01, 24 June 2012 (UTC)[reply]
It has been added to the gadget list for testing, as you sensibly suggested. the wub "?!" 21:11, 24 June 2012 (UTC)[reply]
Well, OK, go ahead and enable it if you don't have the time, but I hope you don't mind if I start dreaming about what v2.0 should be like. Arcandam (talk) 00:55, 26 June 2012 (UTC)[reply]

I would oppose adding such a gadget based upon the idea that it would be enabled by default. --Nouniquenames (talk) 04:48, 24 June 2012 (UTC)[reply]

It would have to be enabled by default, since the whole point is to target new and anonymous users. Making it opt-in would be completely pointless. Remember that this gadget will only have an effect where the {{commentr}} template is used, and use of that template on any page would be subject to discussion anyway. the wub "?!" 14:44, 24 June 2012 (UTC)[reply]
Which is why I am against it. --Nouniquenames (talk) 14:56, 24 June 2012 (UTC)[reply]
Well it would be possible to do the same in MediaWiki:common.js, but gadgets:
  • are easier to document
  • can be opted-out if someone really has an objection to them
  • make it easier to take advantage of ResourceLoader for performance
  • can be easily exported to other wikis that wish to use them
-- the wub "?!" 21:15, 24 June 2012 (UTC)[reply]

As suggested by Arcandam, I have added this to the gadgets list for people to test, although it is not yet enabled by default. the wub "?!" 21:18, 24 June 2012 (UTC)[reply]

Thanks. Arcandam (talk) 00:55, 26 June 2012 (UTC)[reply]

Comment as the instigator and creator (with significant help) of the current {{Leave feedback}} system, I have some comments.

  1. Improving help pages is important, and I supported the fellowship on Meta (AFAIR). Getting feedback is part of improving it. Getting more and/or better feedback is good.
  2. Despite some clever coding, there are limitations of wikitext, and in general I'm a fan of using Javascript to overcome them (as the only currently available way to do that in a well-integrated way).
  3. I'm not entirely convinced about what the gadget adds to the {{Leave feedback}} system. Yes, the popup form is simpler, and that's good. But it also leaves users not engaging with talk pages, and beginning to understand those. Also, right now the gadget keeps the user on the help page once the form is submitted, which may leave the user wondering where their comment went, and the novice may not be able to find it in their contributions list. It certainly makes it less than clear that their comment will be reviewed by volunteers on a standard talk page, and not by some nebulous Organisation (never mind staff).
  4. {{Leave feedback}}'s ability to have custom editintros and preloads is lost (see {{Leave feedback}} documentation). Duplicating it would further complicate matters.
  5. I'm not sure if there are consequences of leaving out MediaWiki:Wikimedia-copyrightwarning.
  6. Overall, I like the idea of tinkering with the edit box to make it simpler and easier to submit comments and suggestions about help pages and articles, maybe without having to leave the page itself. But I don't like taking users completely out of the talk page context they should be introduced to. Maybe we can have a Simple Editbox, which can be used at any time; and a Leave Feedback button at the top of every page which draws people into using talkpages slightly more than the "talk" link does. That button gadget would ideally somehow show both the page being commented on and the comment (discussion) page; I wonder if it's feasible to do a split screen, or maybe show a small preview of the talk page in a popup on the subject page somehow. Bottom line, I think the best bang-for-buck for this idea is to generalise it. I know that's not exactly your remit, but a generalised version can also help people leave feedback on help pages.
  7. Having said all that, the very limited remit of the proposed gadget means I'm not opposed to turning it on by default in the near future and getting some experience with how people use it, and how people react etc. However I wouldn't want it replacing the existing system in its entirety without some development and experience. Rd232 talk 21:04, 29 June 2012 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

AFC Helper Script

DONE
Script was promoted and installed by The Earwig (talk · contribs). mabdul 10:47, 11 July 2012 (UTC)[reply]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

The AFC Helper Script (code) is heavily used in reviewing by WikiProject Articles for creation. It is tested and works in all major browsers (Chrome, Firefox, IE, Opera, Safari) and skins (Monobook, Vector, Modern), and can be used by members of all user groups (except for creating submissions, which is only possible by autoconfirmed, nor on protected or title-blacklisted pages (obviously)). In its three-year history, it has grown to something beyond a simple script by Tim; it is now actively maintained by multiple users, including Mabdul, Excirial, and I. I believe that making this script a gadget would invite more users to participate in a project that is currently suffering from a massive backlog (see various talk page threads: Time to invite new users!, Backlog too large, Backlog is only going to get worse.), since prospective reviewers do not need to learn the complicated parameters for {{AFC submission}} nor do they need to muddle in their userspace Javascript. It will also make the project known to those who are unaware of its existence. Thanks. — The Earwig (talk) 23:33, 23 June 2012 (UTC)[reply]

Support, as the 'main developer' now, Nathan2055 (talk · contribs) and I started to create new documentation pages, a beta script (for being actively test before the push, after realizing that some situations are not always recognized) and (obviously) an 'alpha' script which is getting new improvements.
I want to explain our history and the resulting situation:We changed the project in last September/October by placing a submit button on every {{userspacedraft}} and increase the new submissions every day from former ~60 to over 200 now. We also want to place the same link to {{usersandbox}} and thus we might get even more submissions every day. The whole process was simplified for the submitters by creating simple links to resubmit or our bot who is cleaning up the pages and moving them out of the user space to WT:AFC/submissionname. Moreover the script got many cleanup functionalities (some are still one the to do list) so that the reviewers don't have to clean up by hand (e.g. simple wikilinks, see this diff for an example). Increasing the usability for the reviewers is the logical next move to get more active users involved! mabdul 00:25, 24 June 2012 (UTC)[reply]
Support Useful for lazy people, like myself. Arcandam (talk) 04:41, 24 June 2012 (UTC)[reply]
Support Per Arcandam's comments, plus it ensures that there is a uniform process for dealing with and managing submissions and limits reviewers making simple mistakes. Callanecc (talk) 04:49, 24 June 2012 (UTC)[reply]
Support as it allows for efficient, consistent activity within the AfC process. System works while not a gadget, but it would be easier if it were made a gadget. --Nouniquenames (talk) 04:53, 24 June 2012 (UTC)[reply]

I think we are done here, right? Who can we ask to implement it? Arcandam (talk) 14:04, 1 July 2012 (UTC)[reply]

Any admin, see Wikipedia:Gadget#Installation. KTC (talk) 21:30, 1 July 2012 (UTC)[reply]
 Done. I realize I'm the proposer (lol, what is a COI?), but consensus seems very clear. — The Earwig (talk) 01:13, 4 July 2012 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Gadgets for watchlist customization

Remember that watchlist RfC? It established that highlighting of unwatched changes should be off by default, but that an option should be available to enable it in preferences. Therefore, I would like to ask that two gadgets be enabled using the CSS at WP:CUSTOMWATCH: one enabling bold styling for unwatched changes, and one enabling an underscore (these received the most support in the RfC). Also, could you put a link to WP:CUSTOMWATCH—in case they want to make changes that aren't one of the gadgets—in the description of the gadgets? Thanks, David1217 What I've done 15:01, 6 July 2012 (UTC)[reply]

See https://bugzilla.wikimedia.org - It has a link for advanced search (Special:Search) in the sidebar. Is there any reason this link can not be added to the Wikipedia sidebar? This would allow people to do searches in a new browser tab without covering the current page.

Can a gadget allow one to place this link in the sidebar? --Timeshifter (talk) 10:56, 7 July 2012 (UTC)[reply]

It already has! Non-vector skins have an additional button, vector has such a small loupe in the search field: click on that and you get to the custom/advanced search! mabdul 11:33, 7 July 2012 (UTC)[reply]
But it does not allow you to go to keep your current page open. I want to be able to get to Special:Search in a new tab. --Timeshifter (talk) 12:22, 7 July 2012 (UTC)[reply]
Some background to this is at Wikipedia:Village pump (technical)/Archive 98#Problem with search on mobile also Wikipedia:Village pump (technical)/Archive 99#Preference for opening search result list or search suggestion in new tab. I'm sure that it's come up elsewhere, because I recall responding to at least one such thread myself, other than this one. --Redrose64 (talk) 14:35, 7 July 2012 (UTC)[reply]
Only one of those threads has putting a search link in the sidebar as a topic, and it got no discussion. I am talking about a subsection of this one:
Wikipedia:Village pump (technical)/Archive 99#Preference for opening search result list or search suggestion in new tab. The subsection is:
Wikipedia:Village pump (technical)/Archive 99#Search link in sidebar would fix the problem too. I started that subsection of the thread, and no one replied.
I have never asked before about a gadget to put the search link in the sidebar, as far as I can remember. In the past I have asked that it be put there by default. At one time it was there by default but it was removed. So since there seems to be little enthusiasm for that I am now asking that a gadget be put in preferences. --Timeshifter (talk) 15:35, 8 July 2012 (UTC)[reply]
Simple explanation: many don't need that feature, others have it built in in their browsers (+extensions) by pressing [shift]; [ctrl], [command] or whatever browser, preferences or operating system they use... mabdul 02:30, 11 July 2012 (UTC)[reply]
None of those methods work for submit buttons for search. They only work for links. --Timeshifter (talk) 17:41, 11 July 2012 (UTC)[reply]
Either search for another extension for your browser, or install Opera. mabdul 18:30, 11 July 2012 (UTC)[reply]
Average Wikipedia users, and web users in general, do not install specialized browser extensions for search. They just use the search form, or they click a search link to get to a search form. This is not rocket science.
A very few people might install the revised gadget discussed higher up (ctrl-click to open search in new tab). But most people are not going to do that, or will even know about it. So a search link in the sidebar is simplest. --Timeshifter (talk) 18:57, 11 July 2012 (UTC)[reply]
Do you think it is more likely that the average user who does not install extensions/AddOns will enable a gadget? -- Rillke (talk) 19:33, 12 July 2012 (UTC)[reply]
That is a good point. I adjusted more basic preferences in Wikipedia long before I installed gadgets from Special:Preferences#mw-prefsection-gadgets. Like most noobs I understood basic preferences and options from my experience with browser and email options. Gadgets, addons, and extensions sounded esoteric and dangerous to me at first. I was a default kind of noob. :)
I suggest putting the search link option in Special:Preferences#mw-prefsection-searchoptions (the search options tab in preferences). I suggest it be the default that the search link be in the sidebar. Like the default settings for some Commons preferences: commons:Special:Preferences#mw-prefsection-gadgets --Timeshifter (talk) 01:31, 13 July 2012 (UTC)[reply]
A while ago, I proposed we add a separate entry in the drop down. "Advanced search" or "Advanced search options". See also bugzilla:29448, mockup. Would that satisfy people ? —TheDJ (talk • contribs) 09:00, 2 August 2012 (UTC)[reply]
I don't understand why the MediaWiki developers in charge seem to be pathologically opposed to a search link in the sidebar. That is an unbelievably simple and logical solution. I have been asking about this for years. At one point it was put in the sidebar on Wikipedia after much discussion 4 years ago. See: MediaWiki talk:Sidebar/Archive 1#Advanced search is hard to find.
Bugzilla (bugzilla.wikimedia.org) has two search links in the sidebar. So developers think they need search links in the sidebar, but the unwashed masses of Wikipedia readers are undeserving. Personally, I am fed up with the perennial naysayers who seem to populate many Wikipedia discussions the last few years. I believe this fanboy clique has driven away tens of thousands of Wikipedia editors and their enthusiasm and their money. Just one more reason there are more articles, but less editors. Editor retention depends on overall cooperation which is sorely lacking at all levels of Wikipedia. Who actually is in charge of Wikipedia anymore? It seems that no one really is. No group at the top seems to care much.
I will leave a comment or two at bugzilla:29448. --Timeshifter (talk) 20:30, 2 August 2012 (UTC)[reply]
  • Search bugs
  • Advanced search
  • Enter a new bug
Maybe those "search links" in bugzilla sidebar (on the right) are supposed to motivate people to search more before entering a new bug. Plus they have fewer links overall so they don't need to care about space. — AlexSm 21:58, 2 August 2012 (UTC)[reply]
See the Wikipedia main page. How is "Random article" or "Wikipedia Shop" more important than a search link? And there is plenty of room in the click-open menus such as the toolbox menu. --Timeshifter (talk) 15:04, 3 August 2012 (UTC)[reply]
What and where is this "Wikipedia Shop"? --Redrose64 (talk) 15:48, 3 August 2012 (UTC)[reply]
Link to it is in the left sidebar of the Wikipedia main page. --Timeshifter (talk) 17:59, 3 August 2012 (UTC)[reply]
I don't see one - logged in or out, Vector or MonoBook. What is above (or below) it? --Redrose64 (talk) 18:31, 3 August 2012 (UTC)`[reply]
It's geotargeted. Non-US users might not see it. Anomie⚔ 18:52, 3 August 2012 (UTC)[reply]

Edit tools

Please make the edittools script into a default gadget so we can disable it and it is easier to import to other wikis and avoid code duplication. See MediaWiki talk:Edittools#Remove unused code for details. Helder 22:18, 1 August 2012 (UTC)[reply]

To make it easier, here are the steps needed to implement this gadget:
  1. Create a description for this gadget at MediaWiki:Gadget-EditTools (e.g.: "Add old edit tools under edit box");
  2. Create MediaWiki:Gadget-EditToolsLoader.js with this code, which comes from MediaWiki:Common.js + MediaWiki:Common.js/edit.js;
  3. Move MediaWiki:Edittools.js to MediaWiki:Gadget-EditTools.js (without leaving a redirect, since this do not work on JS/CSS pages);
  4. Define the (default) gadget by inserting the following line at MediaWiki:Gadgets-definition:
    * EditTools[ResourceLoader|default|rights=edit]|EditToolsLoader.js
  5. Remove the code "|| wgPageName == 'Special:Upload'" from MediaWiki:Common.js and the edit tools code from MediaWiki:Common.js/edit.js
Could someone do that, please? Helder 20:01, 11 September 2012 (UTC)[reply]
You might want to copy this to Wikipedia:Village pump (technical). Many more technical people seem to pay attention there. Almost nothing seems to get implemented from this page. I don't know why. --Timeshifter (talk) 17:50, 12 September 2012 (UTC)[reply]
It is already mentioned at Wikipedia:Village pump (technical)#Edit tools. I just added an {{edit protected}} on MediaWiki talk:Gadgets-definition#Edit tools. Helder 21:33, 12 September 2012 (UTC)[reply]
PS: To make sure it still works as expected, I implemented and tested the code on test.wikipedia.org. Helder 03:25, 14 September 2012 (UTC)[reply]

While I certainly agree in principle with turning this into a gadget, I see a few issues here:

  • You need to do more than just move the js that makes the insertion happen from the default to a gadget. The charinsert interface still appears when the gadget turned off, but doesn't do anything, so that will either need to be hidden, or removed from MediaWiki:Edittools entirely and then added to the page using the gadget itself. The latter would probably be preferable considering only the gadget will use that at all, and since the list below the charinsert is redundant with the copyrightwarning, might as well just kill the entire edittools page, though perhaps that would be a discussion for elsewhere.
  • The gadget should probably be renamed to something more specific to its function - as it is, 'edit tools' is often confused with the edit toolbars, and since this thing just does character and string insertions using the CharInsert extension, perhaps calling it a CharInsert gadget would be less confusing, and describe it as 'Add a toolbar under the editbox to insert special characters' or some such. (Calling it the 'old edit tools' won't mean anything to new users, and even those familiar with the thing may not catch on right away.)
  • Does it really need to be turned on by default? Since it seems like on this project people would just ignore it most of the time, well... would it be possible to get any usage statistics for the thing?
  • It should probably be moved above the save and whatnot buttons, perhaps to directly under the editbox itself, since it is directly related to editing. Where it is currently doesn't really make much sense.

These should be pretty easily resolvable, however. -— Isarra ༆ 17:49, 14 September 2012 (UTC)[reply]

The first issues you mentioned are essentially what bugzilla:11130 is about (open since 2007).
While that bug is not fixed, the HTML from MediaWiki:Edittools will always be sent to all users, even to those who not use it or who disable JavaScript on their browsers (and it seems enwiki wants those characters to be sent to all users). So, the only alternative for users who do not use those characters is to hide them after thei are downloaded, by using CSS. I believe this could be incorporated to the gadget in the following way:
  1. Add a CSS rule such as #editpage-specialchars{ display: none; } to MediaWiki:Common.css; and
  2. Undo this at MediaWiki:Gadget-EditTools.css, by means of a CSS rule which restores the display: block;
I do not oppose any change to the name of the "MediaWiki:" pages to be used by the gadget, not a better description for it (native English speakers would probably describe it better than I, but maybe something similar to "Add clickable links for inserting special characters and wiki markup under edit box"). What really matters is to get a work around for bugzilla:11130 and enwiki's choice of adding characters to MediaWiki:Edittools for all users (the names and descriptions can be improved latter if needed).
Once this is converted into a gadget, its usage will could be added to statistic such as Wikipedia:Database reports/User preferences#Gadgets / Wikipedia talk:Gadget#Usage-Stats. In case it is kept enabled by default (as it currently is), it would be good to advertise that people can now disable it. On the other hand, if it is disabled by default, people will notice it was disabled, but anon users won't be able to use it, unless we create also some kind of workaround for bug 29301 as well. Helder 15:18, 15 September 2012 (UTC)[reply]
bugzilla:11130 doesn't make any sense and should be closed as such (though I certainly wouldn't object to a new one being opened about related issues with the CharInsert extension), since any wiki admin can edit MediaWiki:Edittools. That needs doing, and the relevant content moved into the gadget; there is no reason for people not using it to have to load it at all if they're not using it. -— Isarra ༆ 06:23, 16 September 2012 (UTC)[reply]

Teahouse Response gadget

All users have a gadget enabled by default for asking questions at Wikipedia:Teahouse, hence the smooth question box that pops up there. After some talk of adding another gadget for responding to existing questions, I'd written a script for that purpose, which I understand several editors have been using for a while, including some Foundation people. I wonder if someone could have a look into the possibility of enabling this too as a default gadget.

The aim of this script is to make it easier for new users to respond to these discussions, when they don't necessarily understand that this entails editing the section. Once in a while, people actually ask how to post a response. The script is based on the Ask gadget, and uses a similar input box, for uniformity. Equazcion (talk) 14:56, 10 Aug 2012 (UTC)

I think this belongs at Wikipedia:Gadget/proposals. Is there a reason why the code cannot be simply added to the existing Teahouse gadget? — AlexSm 16:04, 10 August 2012 (UTC)[reply]
Oops, you're right -- moved No, there is no reason it can't be added to the existing Teahouse gadget. Equazcion (talk) 20:26, 10 Aug 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)[reply]

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)[reply]
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)[reply]
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)[reply]
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)[reply]

Village pump discussion shows strong support for adding gadget

Please see:

Gadget removal proposals

Since this page is for proposing addition of gadgets, I posted a pair of removal proposals at Wikipedia talk:Gadget#Deprecate textareasansserif? and Wikipedia talk:Gadget#Does Gadget-NewDiff actually do anything anymore?. But it doesn't seem that page is actively watched. Please comment. Thanks. Anomie⚔ 18:33, 12 September 2012 (UTC)[reply]

Judging by Timeshifter's post less than an hour before yours, this page probably isn't actively watched either. --Redrose64 (talk) 18:42, 12 September 2012 (UTC)[reply]
I did also post a note at WP:VPR. OTOH, I don't know whether Timeshifter's problem is because of that, or because gadgets don't get implemented here so much as added after they're already written, or because no one is interested in the gadgets he is proposing, or because of some other reason. Anomie⚔ 18:50, 12 September 2012 (UTC)[reply]
The other person with a lack of response had already been posting at WP:VPT. He also added {{edit protected}} recently on a section of MediaWiki talk:Gadgets-definition, and that seemed to speed things up. My working gadget (see the section just above this one) already got good support at WP:VPT. So I guess I need to go to MediaWiki talk:Gadgets-definition. --Timeshifter (talk) 15:04, 14 September 2012 (UTC)[reply]

I propose User:PrimeHunter/My subpages.js as a new gadget. PrimeHunter suggested this after I came to the help desk here following the Village pump discussion here. I already use it and it does exactly what I want, providing a link to all pages in my userspace at the top of every page I read. -- Toshio Yamaguchi (tlk−ctb) 12:59, 14 September 2012 (UTC)[reply]

Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Gadget/proposals&oldid=512829808"