Jump to content

Wikipedia:Gadget/proposals/Archive 5

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

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)

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

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)

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

AFC Helper Script

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

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)

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)
Support Useful for lazy people, like myself. Arcandam (talk) 04:41, 24 June 2012 (UTC)
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)
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)
  • Nonsense. Stroopwafels are the best possible thing. Is it possible to create the most delicious thing ever by combining this script with a cup of tea? Can you use this script as a mini-frisbee? I think not. Arcandam (talk) 22:29, 25 June 2012 (UTC)

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

Any admin, see Wikipedia:Gadget#Installation. KTC (talk) 21:30, 1 July 2012 (UTC)
 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)
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)

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)

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)
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)
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)
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)
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)
None of those methods work for submit buttons for search. They only work for links. --Timeshifter (talk) 17:41, 11 July 2012 (UTC)
Either search for another extension for your browser, or install Opera. mabdul 18:30, 11 July 2012 (UTC)
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)
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)
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)
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)
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)
  • 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)
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)
What and where is this "Wikipedia Shop"? --Redrose64 (talk) 15:48, 3 August 2012 (UTC)
Link to it is in the left sidebar of the Wikipedia main page. --Timeshifter (talk) 17:59, 3 August 2012 (UTC)
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)`
It's geotargeted. Non-US users might not see it. Anomie⚔ 18:52, 3 August 2012 (UTC)

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

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)

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)

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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
It has been added to the gadget list for testing, as you sensibly suggested. the wub "?!" 21:11, 24 June 2012 (UTC)
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)

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)

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)
Which is why I am against it. --Nouniquenames (talk) 14:56, 24 June 2012 (UTC)
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)

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)

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

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

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)

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

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)

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

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)

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 (as done on testwiki); and
  2. Undo this at MediaWiki:Gadget-EditTools.css, by means of a CSS rule which restores the display: block; (see the code on testwiki)
I do not oppose any change to the name of the "MediaWiki:" pages to be used by the gadget, neither 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)
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)
I added the CSS to the gadget on testwiki. Now when the user disable the gadget the (non-clickable) special characters from MediaWiki:Edittools will also be hidden.
The behavior for users without JavaScript (and for those who disabled it) continues as it was in the non-gadget version: the characters are still shown so that they can copy them while editing. Helder 16:25, 16 September 2012 (UTC)
I'm not sure I follow all of that, but from what I can tell the only reason not to remove the insertion text entirely is a fringe case of people who have disabled js, no? But making everyone load both the insertion stuff and the styling to make it disappear is unfair, especially when the reason is a client-side problem with client-side solutions. -— Isarra ༆ 18:29, 16 September 2012 (UTC)
I'm confused. Are we getting rid of MediaWiki:Edittools, MediaWiki:Edittools.js, both or neither? I hope it's neither, because I use MediaWiki:Edittools.js pretty much every day (if only for the en-dash), but if the servers are slow, MediaWiki:Edittools appears instead which is a useful fallback - I copy/paste the required characters. --Redrose64 (talk) 18:48, 16 September 2012 (UTC)
Well, the idea is mostly just to move everything into a gadget, but since gadgets are entirely js- and css-based and MediaWiki handles js horrifically, you make a very good point. By any chance would you also be interested in helping form an angry mob to try to force Wikimedia to focus on making the MediaWiki javascript handling suck less? -— Isarra ༆ 19:10, 16 September 2012 (UTC)
Good luck with that. While you are at it, point the mob at revising the site JS so that search result lists and search suggestions open in a new tab via Ctrl-click (PC) or Command-click (Mac). --Timeshifter (talk) 00:56, 17 September 2012 (UTC)
Hah. At least for the latter thing you just need an admin and a bottle of absinthe; should be enough to elicit compliance from even the most hesitant. -— Isarra ༆ 03:04, 17 September 2012 (UTC)
But seriously, you're right about using css to hide it and thus not having to use js being useful in general, so yeah. As for the default of on or off, I tried to start an RfC including a thing about that, so hopefully we'll get some kind of consensus one way or the other. -— Isarra ༆ 22:18, 16 September 2012 (UTC)

Thanks to Yuvipanda, MBisanz, and Anomie, this has now been gadgetised as MediaWiki:Gadget-charinsert etc and is on by default for the time being. -— Isarra ༆ 07:22, 25 September 2012 (UTC)

My question still stands, though: currently all the JavaScript is loaded on every page, even if the user is not in edit mode (or if the page is do not have an editbox, as in special pages - except Special:Upload). Wouldn't better to separate the JavaScript into two parts? We would still have a small "loader" in all cases, but the significant code would be loaded only when it is useful... Helder 00:27, 26 September 2012 (UTC)

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)

This is a special case addition that would only be useful for a small subset of users, as most do not extensively use subpages of their userspace beyond their sandbox. For those of you who do, should an included script in your personal js not be enough? Should probably document it on teh massive list of scripts so other folks can find it, although that page could have a better sorting/searching system, and could really use more prominence in general... -— Isarra ༆ 17:57, 16 September 2012 (UTC)

Comment. The closer at the Village Pump discussion said that "the consensus leans most towards opt-in gadget." I agree with that. There are already several gadgets in preferences for adding links to the sidebar or to menus at the top of every page. See: Special:Preferences#mw-prefsection-gadgets. This seems as useful, or more useful, than most of them.

A creative solution would be combine all the link-adding gadgets into one gadget in preferences that adds all the links into one menu in the sidebar. Maybe call that menu "More tools". By the way, Toshio Yamaguchi, you can ignore the more overzealous of the gadget deletionists. I do. Maybe Gadgets 2.0 that is being worked on will provide more tabs in preferences. Tables of content on preference tab pages would help too with sorting through the gadgets. --Timeshifter (talk) 01:13, 17 September 2012 (UTC)

Wikipedia:Disambiguation detector

I propose to create a tool for disambiguation detector as Spanish Wikipedia (es:Wikipedia:Detector de desambiguaciones, German Wikipedia (de:Wikipedia:Helferlein/Begriffsklärungs-Check), Galician Wikipedia (gl:Wikipedia:Detector de homónimos) and Portuguese Wikipedia (pt:Wikipédia:Detector de desambiguações) have. This tool is used to detect the links pointing disambiguations pages. For example, someone put the link Cuatro in an article in a television program, but would have to be this Cuatro (TV channel). And these links are marked yellow.

This gadget also marks the articles with topics of unclear notability.

I have already created the description page Wikipedia:Disambiguation detector. Now an administrator have that copy the code of Spanish Wikipedia es:MediaWiki:Gadget-DetectaDesambiguaciones.js, German Wikipedia de:MediaWiki:Gadget-bkl-check.js or Portuguese Wikipedia pt:MediaWiki:Gadget-desambiguacoes.js The administrator have to change the next code: 

Categoría:Wikipedia:Desambiguación > Category:All disambiguation pages
desambiguación > disambiguation
Categoría:Wikipedia:Sin relevancia aparente > Category:Articles with topics of unclear notability
SRA > (To the favorite word or phrase)

If anybody wants, can add more thinks to marks. Anybody checks the translation in Wikipedia:Disambiguation detector, because I know little English. --Vivaelcelta {discusión  · contributions} 18:12, 23 September 2012 (UTC)

  • Looking into this:
    • As best I see it, this script detects disambiguation pages, highlights the link in some shade of red and adds a BKL superscript (begriffsklärungs— disambiguation). See the screen shot to the right.
    • I don't like the color nor the BKL link, although both could be changed. This is a quite large script for this one purpose and would need a bit of translation.
    • I have been using User:Anomie/linkclassifier for years; it does much more than Disambiguation detector and appears more efficient.
---— Gadget850 (Ed) talk 12:19, 21 October 2012 (UTC)
Since my script keeps getting mentioned here , I took a look at the "competitor". I note the following issues, none of which are insurmountable:
  • It uses really old code like sajax and importScript, rather than jQuery ajax.
  • It won't work on old revisions, since it always fetches the list of links for the current revision of the page.
  • It doesn't take advantage of whether the user has apihighlimits, since it uses callback to get the results.
  • It can't handle a page being in multiple categories at once. Perhaps that's not supposed to happen with the three categories they check.
  • It allows the browser to cache the results for the pages linked from a page, which means if someone edits a linked page to make it be a dab or stop being a dab it might not pick up the change on reload.
  • In some cases it could be more efficient in API queries than mine:
    • Depending on whether the user has apihighlimits, mine will make at least 1 API query per each 50 or 500 distinct wikilinks on the page. For normal page views, the German script will make at least 1 API query per each 500 distinct wikilinks on the page. For preview page views, the German script will make at least 1 API query per each 50 distinct wikilinks after trying to filter out links to non-mainspace pages.
    • If the average categories per page in a group of 50/500 is more than 10, mine will make additional queries to fetch all the categories in that group of 50/500 pages. The German script for normal pageviews would need an average of more than 1, but since it is able to use clcategories that is unlikely.
    • Since mine cares about redirects, it will make extra queries to check for categories on any redirects in the page.
  • And, of course, mine will indicate a whole lot more than just disambiguation pages.
I'm not sure whether the various DOM accesses are faster in mine or theirs, or whether it's enough to really matter either way. HTH. Anomie⚔ 17:06, 21 October 2012 (UTC)

HotInterwiki

As you are aware that I am doing lots of my efforts on Urdu Wiki. I often work on Wikipedia to update Interwiki links and Categories link between the two Wikipedias i.e. Urdu & English Wikipedia. I am using "Hot Interwiki" link in Urdu wiki (find here) but couldn't succeed to find this link in English Wiki. Can you help me out to get this tool in English Wiki too so that I may enter Urdu interwiki link into English as I am usually make new categories on Urdu Wiki to categorize all article in a proper way. I only use English Wiki to enter Urdu interwiki and for this I've to spend lot of time to push the edit button on every single article on English Wiki to enter Urdu interwiki link.

I hope you will help me to get access to "Hot Interwiki" tool on English Wikipedia. Thanks --ساجد امجد ساجد (talk) 08:30, 20 October 2012 (UTC)

Higher res images in articles

On high-res devices, especially those that have touch gestures such as tablets and smartphones, it would be nice to zoom in to find a finer image. I'm constantly finding myself going to the description page to view the image in a higher resolution.

  • Add an option for bitmap interlacing to decrease visible page loading time.
  • Add an option 'Image size limit: (for articles)' for up to 1280x1024px.

I use recent versions of Mozilla Firefox on all of my Ubuntu and Android devices. I generally use 3G (soon to be 4G), but I have plenty of data allowance.

JamesHaigh (talk) 01:42, 2 November 2012 (UTC)

Neither of these are possible in a gadget, however MediaWiki is already serving the new HTML5 srcset attribute for high-resolution devices, including Javascript fallback for devices that don't yet support the property natively. Anomie⚔ 03:27, 2 November 2012 (UTC)
Thanks, srcset sounds great! How new is it? Does Firefox support it yet? Where is the correct place to report general feature requests on WP? I would still appreciate an option for progressive bitmap interlacing. JamesHaigh (talk) 04:13, 2 November 2012 (UTC)
There is a bit of info on Gerrit. See also the draft spec. ---— Gadget850 (Ed) talk 07:26, 2 November 2012 (UTC)

MathML

Please add an option to convert the TeX source into MathML for the browser to render. (Conversion should be done server-side, and cached.)

JamesHaigh (talk) 04:14, 2 November 2012 (UTC)

This page is only for requesting the addition of existing client-side scripts to the list at Special:Preferences#mw-prefsection-gadgets. Wikipedia uses the MediaWiki extension "Math" to render LaTeX markup, which only currently supports PNG and MathJax output. There is a link in that page's infobox for reporting bugs and requesting new features. PleaseStand (talk) 06:37, 2 November 2012 (UTC)
There is actually someone working on this right now, using latexML. The patches are in gerrit, though we are still far away from including this in WMF wiki's I think. —TheDJ (talk • contribs) 11:47, 2 November 2012 (UTC)
Oh and already right now, it's possible to choose MathJax from your preferences, which can render in multiple modes, including MathML. —TheDJ (talk • contribs) 11:50, 2 November 2012 (UTC)
DONE
Script was promoted and installed by Kaldari (talk) 21:50, 8 December 2012 (UTC)

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 the Direct imagelinks to Commons gadget. This was discussed briefly on the Village Pump a while back, where it received support from the few people who commented. It's already available on several other wikis. Kaldari (talk) 18:44, 21 October 2012 (UTC)

  • Support: If a file is hosted on Commons and someone clicks a thumb or a link (from en-wiki) they end up on a local page on en-wiki and they now have two options: 1) To click the link to the file on Commons and edit/add there or 2) to edit/add locally. In 99,x % of the cases the edits are (or should be) made on Commons. The gadget will send users directly to Commons and thereby reduce the number of clicks needed to edit the correct place and reduce the number of edits placed in the wrong place.
The gadget does not affect files hosted on en-wiki and it does not make it impossible or very difficult to edit pages locally if it for some reason is relevant. The gadget does also not move files to Commons or force anyone to upload files to Commons. So no harm is done by this gadget. --MGA73 (talk) 10:59, 22 October 2012 (UTC)
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.

Simplified move proposal process

A few months ago I proposed a simplified move proposal process, and shortly afterward there was consensus in favor of the idea. The specifics of the script weren't discussed very much, nor was the issue of testing it before enabling it by default. Testing and improving a script to the point where it's widely usable is difficult when there isn't an easy way to test it short of directly editing one's JS, so perhaps the best way to go about it is to add it as an opt-in gadget for a while first. So, I propose adding User:Yair rand/ControversialMoves.js as an opt-in gadget for users with the "move" right, so that it can be tested, discussed, and further improved until it is enabled by default. --Yair rand (talk) 02:29, 6 November 2012 (UTC)

Syntax highlighter

Hi all, a recent RFC showed widespread consensus for adding syntax highlighting features to the edit box. I'd like to suggest adding meta:User:Remember the dot/Syntax highlighter.js as a gadget with the following note:

I tested the script in Internet Explorer 9 and 10 as well, and while it doesn't do anything, it doesn't appear to cause errors either. I was not able to test Safari, but it should work the same as Chrome. The bottom line is that while this script will not work for everyone, I think it is useful enough to consider making a gadget. —Remember the dot (talk) 21:29, 10 November 2012 (UTC)

When you say that it "Must not be used with the browser's page zoom feature", is this a critical problem? That is, will the page be corrupted if saved when zoomed, or is it merely that the display to one user is not as might be expected? --Redrose64 (talk) 21:39, 10 November 2012 (UTC)
Good question. It won't corrupt anything, but the colors will be all out of place making editing difficult until default page zoom is restored. I'm open to alternate wordings. —Remember the dot (talk) 21:41, 10 November 2012 (UTC)
Yeah, I would suggest saying "may not work at anything other than standard browser resolution" or the like. Steven Walling (WMF) • talk 23:26, 10 November 2012 (UTC)
Maybe it just needs a softer word: "Should not be used with the browser's page zoom feature." I don't think many users will understand the phrase "may not work at anything other than standard browser resolution". —Remember the dot (talk) 20:44, 11 November 2012 (UTC)
  • Are you proposing it be added as a gadget, or as the default for all users? In coding my SnipManager script, I encountered some serious bugs in wikiEd's syntax highlighting. I do not have any reason to believe that these same bugs are present in Dot's syntax highlighter, but it raises the issue that using customized edit areas can cause both browser incompatibilities and javascript errors to occur. --Odie5533 (talk) 01:52, 11 November 2012 (UTC)

{{edit protected}}

Over the two weeks that this request has been open no objections have been made and I have made a number of improvements to the script in that time also. I am sure that we will find additional ways to improve the script in the future, but right now I'd just like to have a stable version of it available through the preferences menu. Therefore, I'd like to ask that:

  1. The contents of meta:User:Remember the dot/Syntax highlighter.js be copied to MediaWiki:Gadget-DotsSyntaxHighlighter.js
  2. MediaWiki:Gadget-DotsSyntaxHighlighter be created with * [[:meta:User:Remember the dot/Syntax highlighter|Dot's syntax highlighter]], make syntax stand out colorfully in the edit box. Works best in [[Mozilla Firefox|Firefox]], works almost all of the time in [[Opera (web browser)|Opera]], and works most of the time in [[Google Chrome|Chrome]]. '''Should not''' be used with the browser's page zoom feature.
  3. The following line added to MediaWiki:Gadgets-definition under "editing": DotsSyntaxHighlighter[ResourceLoader]|DotsSyntaxHighlighter.js

—Remember the dot (talk) 21:20, 24 November 2012 (UTC)

Looking at the documentation: what is the issue with <br>? Now thet we render HTML5, both <br> and <br /> are valid.[1] ---— Gadget850 (Ed) talk 14:43, 25 November 2012 (UTC)
The main reason is that while HTML5 has declared many previously invalid syntaxes to be "valid", <br/> is less confusing because it makes it obvious that the element has no closing tag. In fact, MediaWiki automatically converts <br> to <br /> when rendering a page. The highlighter does not support other confusing syntaxes such as </br> and <b><span>asymmetric tags</b></span> either, both for performance reasons (the script is already quite slow on large pages) and to encourage a single clear, unambiguous syntax on Wikipedia. While supporting <br> would probably not incur a significant performance penalty, I still feel that it's best to encourage only one syntax.
I realize that a lot of people are going to disagree with me on this, and if there's consensus to adopt only a modified form of the highlighter as a gadget then go ahead. —Remember the dot (talk) 20:56, 25 November 2012 (UTC)
Can you split the the script to make it lazy-load on edit pages only (MediaWiki:Gadget-DotsSyntaxHighlighter.js/core.js)? As it is now, the entire script is loaded for each page view, which is a bit of a waste of bandwidth. — Edokter (talk) — 15:53, 25 November 2012 (UTC)
My understanding is that local caching takes care of all that. Nonetheless, mw:ResourceLoader/Migration guide (users)#Keep gadgets central suggests making the script a gadget on MediaWiki.org first and then loading it from there. Do you happen to know who I would have to talk to to make that happen? —Remember the dot (talk) 20:56, 25 November 2012 (UTC)
Local caching still allots bandwidth to users who never edit. As script-packed as Wikipedia is, one should always strive to load code only when needed. As for hosting the script on Meta or MediaWiki, simply ping a local admin to move/copy the code to a local MediaWiki: page. — Edokter (talk) — 21:08, 25 November 2012 (UTC)
I finally found mw:Project:Requests. I asked that the script be copied as-is; if you'd like to add additional loading conditions locally on the English Wikipedia that's fine too. That said, I doubt that a user who never edits is the kind of user who would install an editing gadget. —Remember the dot (talk) 21:53, 25 November 2012 (UTC)
True, I lost sight of the scope. — Edokter (talk) — 21:14, 26 November 2012 (UTC)

It seems that few administrators are familiar enough with the gadgets pages to know how to add new ones, so I've put in the syntax highlighter gadget myself. Let me know if it causes any problems. —Remember the dot (talk) 03:21, 6 December 2012 (UTC)

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