This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the
current main page.
At commons, there are two gadgets that place categories differently on monobook screen. Both work fairly well. I think
MediaWiki:Gadget-CategoryAboveAll.js would make a good addition here too. The other is meant primarily for images and less useful here. Both take some time to get used to, but it's worth having it. --
签名 sig at
00:11, 3 October 2009 (UTC)
I would like to see this script imported from the Commons. I am using Firefox 3.5 and it works fine. It places the items inside the toolbox, but I am sure it needs some editing to make it use wikipedia templates and procedures. I copied the code from the Commons to MediaWiki:Quick-delete-code.js so admins here can see it.
User:Zscout370(Return Fire)18:32, 20 October 2009 (UTC)
Please review
User:Kirbylover4000/addthis.js for use as a gadget.
It adds a "Bookmark and Share" link to the Toolbox (powered by
AddThis), which the user can hover their mouse over for a list of places they can bookmark or share the current article with others.
I'd like to propose a gadget that identifies a user's gender on their user and user talk pages (if they have it set in their preferences), by appending ♀ or ♂ to the firstHeading <h1> at the top of the page. It'd be useful, for example, for determining whether to use "she" or "he" when referring to an editor one's not yet familiar with.
The script as-is is located at
User:Fran Rogers/dimorphism.js, if you'd like to try it out (add importScript("User:Fran Rogers/dimorphism.js"); to your skin.js). Confirmed working fine in Trident, Gecko, and WebKit based browsers, with all skins. What do y'all think?
Fran Rogers (
talk)
20:12, 21 January 2010 (UTC)
Here is a
combined script that is a complete rewrite of Splarka's script. This 7.5k script tries to be more user-friendly by putting the information into plain English, and it does include the gender identifier part of Fran Rogers's. Please note that most users do not specify a gender, so that part is probably the least useful.
PleaseStand(talk)03:50, 14 March 2010 (UTC)
Then again, there are many who do specify a gender, and I have found the user age part to be helpful when checking suspicious edits.
PleaseStand(talk)19:31, 11 April 2010 (UTC)
I just wrote this script and propose it for inclusion as a Gadget; it is my first use of jQuery, so I appreciate criticism. As described on
WP:CUSTOMSIG, users have been able to highlight the userpage links in their signatures. However, this fails to highlight the entire comment. jQuery is capable of selecting the parent "p", "dd", or "li" element of such a userpage link (even with most custom signatures) so that at least the last paragraph of a comment is highlighted (and as a bonus highlight your revisions in diffs, edits to your own user page in contributions, etc. also).
The JavaScript part of the proposed gadget will be all the lines starting with addOnloadHook the "function names" one and ending on the second-to-last line. The CSS part will be as described in the code's comments, unless anyone can propose a better color(s) or other CSS style. No special configuration is necessary, unlike the currently-recommended CSS code. However, the color can be configured by the user in the skin.css file. Go ahead, try it out to see if there's anything I missed.
PleaseStand(talk)00:20, 10 March 2010 (UTC)
Just to add, I have replaced the addOnloadHook line with its jQuery equivalent. And just as a note, the script is less than perfect. If the user does not use a bullet when indenting posts, all posts indented under the user's post would be highlighted as well (in the HTML, the indented post is "inside" the earlier post). Other than that though, it seems to work OK, at least under Firefox.
PleaseStand(talk)02:31, 10 March 2010 (UTC)
Another change: It now should highlight correctly, and it now has a toolbox link that needs to be clicked to turn it on. Need to test it in browsers other than Firefox though, but results in Firefox look promising. Any way to make the added wrapper code less messy (look at it in the Firebug debugger)?
PleaseStand(talk)02:36, 13 March 2010 (UTC)
Yes, it's cross-browser compatible. Tested on and works on IE 8, FF 3.6, Safari 4, and Opera 10 (don't have Chrome installed so didn't try that).
PleaseStand(talk)02:55, 13 March 2010 (UTC)
Doesn't seem to work for me, on Monobook.
Equazcion(talk) 01:41, 14 Mar 2010 (UTC)
You need to look at the comments in the actual script and put the CSS line in
Special:MyPage/skin.css. I'm using Firefox 3.6 and it works for me even when using Monobook in its default configuration rather than Vector, as it now automatically loads jQuery if it has to. I had tested it in Internet Explorer (version 8) and it should work fine in that browser also. You need to single-click the link in the Toolbox section of the page (the one with "what links here") called "Toggle comment highlighting". Clicking the link again clears the highlighting. Oh, and you do need to be looking at a page that has your signature (or at least one link to your user page on it, see the script for technical details).
PleaseStand(talk)05:33, 14 March 2010 (UTC)
This script can error on Safari, because it doesn't check for jquery presence after attempting to load it. Due to the asynchronous nature of WebKit it is possible that importScript has not finished before the other code is executed. —
TheDJ (
talk •
contribs)
13:03, 11 April 2010 (UTC)
YFixed, but it could be more elegant if jQuery were capable of performing a callback once it is done loading. Adding if(typeof jQueryLoaded == "function") jQueryLoaded(); at the end of jquery.min.js would do the trick.
PleaseStand(talk)19:26, 11 April 2010 (UTC)
The described behavior only really seems to work on Firefox. It launches a new window on all other browsers. Someone should put some work in that, before we can use the script here I think. —
TheDJ (
talk •
contribs)
13:00, 11 April 2010 (UTC)
Ajax preview
User:Js/ajaxPreview.js is a handy script which adds "preview" and "changes" buttons above the edit toolbar which use Ajax to preview edits. It is slightly faster than the built-in function, but more importantly when you hit preview it will also show you a reflist if you're editing a section containing references and there isn't already a reflist (making it much easier to check ref syntax). I use it a lot when making section edits, although not as much with full-page edits since it doesn't scroll back up to the top of the page automatically. –
Drilnoth (
T •
C •
L)
02:40, 2 July 2009 (UTC)
I agree, ajaxPreview is a fantastic script. I have timed it on several different computers, it gives you about 3.5 times faster edit preview. This is especially useful if you have a slow computer or a slow Internet connection, but it is a noticeable improvement even on faster computers. Actually, since Wikipedia pages now take about 30-60 seconds to load on older computers this script is almost a requirement if one has to edit Wikipedia from an old computer.
This script also gives a faster diff view, but not as fast as the edit preview. And this script works in pretty much all web browsers.
There are some problems with it however. Most notably, missing inclusion of css of geshi and other extensions, if I remember correctly. This is being worked on for Beta, where it will be a part of the editwindow by default. —
TheDJ (
talk •
contribs)
02:43, 26 January 2010 (UTC)
Those "problems" are not much of a problem. Especially since this script still leaves the old "Show preview" and "Show changes" buttons so one can use them if one wants to see the Geshi <source> markup etc.
True. I think that the primary reason that this hasn't been added yet as a gadget, is that wikEd basically provides the same functionality. —
TheDJ (
talk •
contribs)
14:01, 26 January 2010 (UTC)
WikEd doesn't work on Internet Explorer and Opera. And we who have old slow computers can't use wikEd since it makes things way to slow, while ajaxPreview makes things faster. And ajaxPreview does the preview part much better than wikEd. So wikiEd is not an alternative to ajaxPreview.
I repaired the script. The old ajaxpreview method was no longer available in MediaWiki 1.16 and I had to upgrade the script to use the API instead. —
TheDJ (
talk •
contribs)
23:30, 22 April 2010 (UTC)
The script basically adds little (t)s to translatable (by Google Translate) links in the language sidebar. It allows users to get information from the other wikis without having to look for a translator. For example, on the main page, the
Spanish link changes to
Spanish(t) . This is a great research tool and also helpful for fixing interwiki links.
ManishEarthTalk •
Stalk02:05, 10 February 2010 (UTC)
Here is a screenshot of part of the sidebar of the main page.
A screenshot of the tool. The blue t's indicate translatable links, the red t's indicate links which cannot be translated
Wikipedia usually doesn't endorse third party tools (and if so, we try to do it in neutral manner like
Special:BookSources or GeoHack). I think this would be better as browser plugin and I'm quite sure those already exist.
Svick (
talk)
12:38, 7 March 2010 (UTC)
I made this primarily as a research tool (Though its good for interwiki wanderers...). I realized that there is a lot of extra info on WP out there, in other languages. So, for my convenience, I made it. Later, someone suggested I make it a gadget, so I posted this request.
ManishEarthTalk •
Stalk12:49, 7 March 2010 (UTC)
I guess nobody with the ability to add gadgets (i.e. administrator) watches this discussion. Maybe you can try {{
editprotected}} to get their attention if you feel this is uncontroversial enough. Or maybe post a note to
WP:AN?
Svick (
talk)
12:34, 11 April 2010 (UTC)
OK, made some improvements to the script (most importantly namespacing it). Will run a few days for testing and then I propose we make this a gadget. —
TheDJ (
talk •
contribs)
14:29, 11 April 2010 (UTC)
We'll need a disclaimer basically saying: "Do not trust machine translations" and "Google is a separate entity--we're not liable". How 'bout: "This gadget uses Google Translate. Google Translate is a service operated by Google and is not, affiliated with Wikipedia. Also, please note that machine translations are not completely reliable."
For the name, we could use: "Sidebar translation links", or something like that
For the description, try: "Adds an extra link for each language in the language sidebar, linking to a Google translated version of the non-English wiki page"
And any thoughts about the supplementary proposal at the top of this section?
OK, this things seems just fine. So what we need now are the following:
Who is gonna maintain the script ? You Manishearth ? you are not an admin right ? Are others ok, with an importScript, or should we move the file and have manishearth make requests for each change he wants to do ?
No, I'm not an admin. I have no inhibitions against keeping it in my userspace and importing, but I'm not sure if policy allows non-admins to touch gadgets directly. In that case, I'm fine with requesting changes.
ManishEarthTalk •
Stalk18:18, 4 May 2010 (UTC)
I agree that 'Sidebar translate links' sounds kinda dry and weird. 'Other Language Translator' is good. Or, how 'bout 'Language bar translate links', 'Language bar translator', or 'Interwiki translator.'. I can't come up with anything better.
ManishEarthTalk •
Stalk18:18, 4 May 2010 (UTC)
I'll keep it in my userspace. I'm writing I've written the doc right now at
my incubator. there's not much because this script isn't configurable, though I might add configuration support later.
ManishEarthTalk •
Stalk18:18, 4 May 2010 (UTC)
RefToolbar modifications
With the upcoming default skin change, I'd like to make some changes to the refToolbar gadget. Basically:
If the user is using the new toolbar and a compatible browser (everything except IE),
User:Mr.Z-man/refToolbar 2.0 will be used.
except referring to some subpages of the gadget. Ideally, something other than direct browser sniffing could be used, but I think that may be how the usability code determines it until the incompatibility can be fixed. It would be good to confirm that the new toolbar but not the dialogs works in IE, I've been having some issues with IE on my computer. Mr.Z-man03:10, 12 May 2010 (UTC)
It would be nice to have a gadget that activates
user:js/watchlist, or one of the other scripts that puts an "unwatch" button on the watchlist.
I understand that some people are happy to open the page and then unwatch it. But I make edits to dozens of pages a week, and I intentionally keep each of them on my watchlist for at least a month. When that cycle is up, I want to be able to remove them from my watchlist ... and others in my situation probably feel the same way ...
I too would like this. Especially with the change to the new version of Wikipedia, the old "unwatch" scripts seem to no longer be working, so a gadget would be greatly appreciated. It's the thing I dislike most about the new version, is losing that easy unwatch toggle. --
Elonka19:58, 16 May 2010 (UTC)
Picture popups
The script was broken in vector, so I went and rewrote it completely in jQuery. A useful consequence is that it now works in IE7 and probably IE8 (haven't tried). It doesn't work in IE6, and since debugging in it is nearly impossible, and it's dying out anyway, I'm not going to bother. Instructions for installation of the script are at
User:Zocky/Picture Popups#Vector.
No, because it has some strange bugs in Safari—the [-] button squishes the image horizontally but not vertically, for example. I'd forgive errors in Internet Explorer (I just spent some time debugging my scripts for IE), but Safari and other standards-compliant browsers shouldn't be seeing visual errors that nasty. Sorry, but I can't support it yet. It's a great idea, and I think I might even try my hand at an implementation, but the visual bugs I see so far don't give me confidence that it's ready to be a Gadget. {{
Nihiltres|
talk|
edits|
⚡}}04:53, 26 May 2010 (UTC)
How about a plugins tool?
I am troubled that we have to decide which of the items at
WP:JS become available as checkboxes at My Preferences. What troubles me is that there is such a wide array of .JS options, but such narrow real estate to display them in the Gadgets section.
I'm wondering whether we need to be making this compromise in the first place. Is there any possibility of creating a "Find Plugins" gadget, which grants a user access to a "JS store", so that the novice user can have access to the wide array of plugins available at WP:JS -- just as the novice Firefox user can easily click a button to add plugins to her firefox?
Andrew Gradmantalk/WP:Hornbook05:27, 25 April 2010 (UTC)
Yes, that would certainly be more ideal. I would prefer that way than the way it is setup right now, where admins sometimes decide, without discussion, to add scripts. However, it probably won't happen unless there's an existing MediaWiki extension that does just that.
Gary King (
talk)
06:18, 25 April 2010 (UTC)
I am making a lightweight script which allows easy enable-disable of all
WP:US/S scripts. At the moment, I don't have much time, though I'll let you know when I finish.
ManishEarthTalk •
Stalk14:56, 25 April 2010 (UTC)
Thats what my script does. I'll have a page, Special:Scripts, where all userscripts are categorized and tabbed, with easy checkbox enabling like the gadgets page in prefs.
ManishEarthTalk •
Stalk18:30, 4 May 2010 (UTC)
Maybe we could make it so that at the top of the page there would be a list of some of the most widely used gadgets (like
Twinkle and
Friendly), and at the bottom there would be a search bar for looking for other less used gadgets (like the one on the gadget list in the preferences that says "Use a black background with green text on the Monobook skin"). This also brings up another point, that all of the gadgets, especially the ones in the list in the preferences, should have links to their documentation, so that users can see what exactly they're getting. --vgmddg (
look |
talk |
do)22:24, 3 June 2010 (UTC)
Vector sidebar toggling script
I have a few scripts in a custom collection,
nothingthree.js, that I've written for my personal use, and recently ported off so that it's relatively easy for other users to grab from. I think that a couple of the scripts might be useful Gadgets.
In particular, I have a sidebar-toggling script for Vector. Here's how it works:
The user hits a "Toggle sidebar" tab in the drop-down menu.
The sidebar slides gracefully (animated!) off the left side of the screen, widening the content area.
New pages opened while the sidebar's collapsed will also have their sidebars automatically collapsed—the script sets a cookie that remembers the state of the sidebar across pages.
When the user wants to switch back or use the sidebar again, they hit "Toggle sidebar" again and the sidebar slides back into place.
The script is mostly written in jQuery, which handles the animations and much of the necessary document-traversing. It should work in most browsers—I even special-cased one part for Internet Explorer to render the expanding animation correctly. Due to the use of jQuery and referencing particular class-names in the code, the script is specific to the Vector skin.
While this script is currently integrated into my collection, I think it'd be great to have it as a Gadget, and I'd be willing to split off the sidebar routine into its own script. But before I do the work involved in that, I'd like to know if it would be worthwhile—is this Gadget material?
I tried it, but I do not like the animation that shows every time a page is loaded. Mine is not animated and therefore does not suffer from that issue.
PleaseStand(talk)00:30, 27 May 2010 (UTC)
Yeah, I've been thinking about modifying it to disable the animation as called from the remember subroutine. I'll go fix that, then. {{
Nihiltres|
talk|
edits|
⚡}}01:54, 27 May 2010 (UTC)
It should be fixed now; the animation on the remember subroutine now has its duration set to 0 (i.e. 0 ms). Also, people using my library version can now use custom settings to do crazy, crazy things like the code that follows… {{
Nihiltres|
talk|
edits|
⚡}}02:24, 27 May 2010 (UTC)
I've created a version of the script at
MediaWiki:Gadget-sidebarToggle.js that implements just the necessary functions for sidebar toggling, and is completely self-contained. If no one comments (I haven't seen any input on this in days), I'll add this as a Gadget in a day or two. {{
Nihiltres|
talk|
edits|
⚡}}02:02, 2 June 2010 (UTC)
Are you saying that the script itself doesn't work? I know about the error—it's an issue with the Usability Initiative's collapsible-tabs script—but I haven't seen any noticeable problems associated with that error, having tested in the following browsers: Safari (4.0.5) & Firefox (3.6.3) & Chrome (5.0.375.55) on Mac OS X 10.6, and Safari 4 & Internet Explorer 8 on Windows 7. I should be able to remove the problem for the sidebar-subset script, and I'll try getting more aggressive about getting help with the more general problem, which is that the collapsible-tabs usability script often has issues with custom tabs, either failing to work properly or producing (invisible) "$settings is not defined" errors. {{
Nihiltres|
talk|
edits|
⚡}}21:58, 2 June 2010 (UTC)
The error should probably be completely gone now, at the cost of some minor functionality (that of placing the tab in the tab bar instead of the dropdown menu when in the Special namespace). If it isn't fixed now, then the problem will also apply to existing Gadgets such as the purge-tab Gadget, which uses the same routine (addPortletLink()) to add a tab to the same place (the drop-down menu). I'll still look into a better solution, but for now there should be no more errors. {{
Nihiltres|
talk|
edits|
⚡}}22:26, 2 June 2010 (UTC)
Good, it does not generate an error anymore. I'm not sure whether the older version of your script "worked" or not; I might have overlooked the toggle option (mine hides the sidebar by default and resets to "hidden" on every page load).
PleaseStand(talk)22:30, 2 June 2010 (UTC)
I'm sure that the older version worked, in retrospect, because the same error would have been generated by the version from my script collection, which I know worked for you because you noted (correctly) that the slide animation on page-load from then was annoying. Are there any further issues with this being used as a Gadget? {{
Nihiltres|
talk|
edits|
⚡}}19:46, 3 June 2010 (UTC)
I do not see anything wrong in Firefox 3.6.3 (aside from a minor issue with text color during the animation, which also affects the search box regardless), Internet Explorer 8, or the latest version of Opera. Internet Explorer 6 (not sure about IE 7, needs to be tested) is problematic. When showing the sidebar once it has been collapsed, the Wikipedia logo does not show, and it might be causing some other background images to not appear when the page is loaded (didn't check closely). My script, which does not use jQuery, worked perfectly on IE 6. I do know that IE users tend to prefer the Monobook skin because Vector breaks the ability to right-click a tab and open in a new tab/window on IE 6 and 7.
PleaseStand(talk)20:36, 3 June 2010 (UTC)
I've added a bit more special-casing for Internet Exploder Explorer to isolate it from anything attempting to change opacity, and so it should probably be fixed for IE6 now, though I'm not yet able to test that directly. I'll see if I can get copies of IE6 & IE7 for debugging at some point, at which time I'll boot into Windows (ugh) and ensure that that awful browser works with the script. In the worst-case scenario, I'll special-case the incompatible version(s) of IE to use a very minimal routine for the collapsing/expanding parts of the script. {{
Nihiltres|
talk|
edits|
⚡}}22:11, 3 June 2010 (UTC)
The opacity change fixed the IE 6 problem (again, I have not tested IE 7). Just a couple questions: 1) are you aware that display: none prevents the affected accesskeys from working, at least in Firefox? 2) Would this script be useful on other skins. I looked at Monobook; coding a version for that skin should not be difficult, albeit it would involve moving elements within the DOM (might not work with some user scripts) and not have animation (Monobook does not load jQuery).
PleaseStand(talk)01:18, 4 June 2010 (UTC)
I wasn't aware that setting display:none would affect accesskeys. I've never considered accesskeys, partly because I don't use them. Would using visibility:hidden work better? I seem to recall issues with visibility:hidden of some sort, but I might be confusing that with something else.
As for Monobook … I'll take a look into it. {{
Nihiltres|
talk|
edits|
⚡}}05:48, 4 June 2010 (UTC)
Here is a working version of your script that includes Monobook support that works on IE 6:
User:PleaseStand/sidebarToggle.js. There is no movement of elements within the DOM actually needed, except if animation is required—something I didn't implement. This version also incorporates the change from display:none to visibility:hidden, which has the advantage of making accesskeys usable (at least in Firefox) but the disadvantage that the sidebar links can still be tabbed to. Of course, there is no difference in IE 6. In contrast, support for the Modern skin seems to be very easy to implement; I'll do that in a few minutes.
PleaseStand(talk)23:43, 4 June 2010 (UTC)
Did that. Should I even bother with support for Classic (skin="standard"), Cologne Blue, or Simple, which are the other skins that have sidebars? On Simple, the sidebar contains the edit link and therefore the sidebar toggle would have to be elsewhere. Additionally, the other two are really old skins.
PleaseStand(talk)02:06, 5 June 2010 (UTC)
I've moved the main version under your userspace version—we can collaborate on it there without creating divergent branches. I think that if we load jQuery manually for the other skins, we may be able to animate the transition for other skins. For example, the following seems to do the tricky collapsing part for Monobook once you've imported jQuery:
I've only tested that on Safari, and messing with the positioning would likely break horribly if it didn't work perfectly, but it looks promising. It's late here, so I'll continue sometime tomorrow later today. {{
Nihiltres|
talk|
edits|
⚡}}06:58, 5 June 2010 (UTC), minor fix 18:07, 5 June 2010 (UTC), converted to a shorter, chained version 02:44, 6 June 2010 (UTC)
I've got some code to do the animations on the other skins (and have done some testing in IE8), but it's hard to bring jQuery in reliably. Do you understand AJAX well enough to set us up with a wrapper that brought in jQuery and ran the rest of the script through the callback? I'm having trouble getting it to work. {{
Nihiltres|
talk|
edits|
⚡}}02:44, 6 June 2010 (UTC)
I propose a fix for the gadget "Focus the cursor in the search bar on loading the Main Page". As you know, the search label doesn't disappear if you start typing in the search box, so the text is overlapping. Thanks to
User:Begoon I've found a css solution to solve the problem in all browsers:
I kindly present you a user script which is already a gadget on German wikipedia and used by about 1'500 users there. I presented it at a lightning talk on Wikimania 2010 and people also wanted to use it on English wikipedia. So I translated my
German howto and created new screenshots for vector and would kindly ask you to correct my English wherever it is needed to because I'm not a native English speaker. After having asked in 2009 why our interface does not allow easy navigation in diffs I wrote the script
de:MediaWiki:Gadget-revisionjumper.js which was
continously developed and is now stable for more than one and a half years. Default setting can be personalized in one's monobook or vector skin (those ones tested) to remove the script from diffs or permanent links resp. add it to articles' histories resp. articles' view. All links and menues will only appear when it is useful, so that the interface will not be overloaded. It works at least in Firefox, Opera and Internet Explorer (most parts); secure connection is supported. It is already
localized and accessible via
de:MediaWiki:Gadget-revisionjumper.js, so only a short code needs to be added (which can be found on
User:DerHexer/testrevisionjumper.js).
Drop down menu in a diff
All functions and configuration parameters are described on User:DerHexer/revisionjumper, the most important ones shall be explained here, too. Main function of the script is to generate new diffs inbetween
diffs and permanent links—and with modification also in articles' histories and view (action=view; no idea how you call that ^^). The difference between the first selected and requested revision can either be produced by a
number of revision or by a
given time. Whoever wanted to know what happened during the last year or since
creation of the article can now do it with one single click. As you can see in the right image some recommended numbers and intervals are already enabled. Further, functions are added which individually request whatever
number or
interval you want to skip over (of course only useful values are accepted). There is also a function to
skip to a given time.
The functionality should be enlightened by following images:
Before having clicked to skip over 10 revision
The generated diff
Furthermore,
one function creates a diff between all changes of the last editor. That's mostly useful for unexperienced users who rarely use the preview button. Another button generates a diff between one's last edit and the current revision.
The link is part of the 'player', its easily disabled for 3rd party sites via a configuration option. The code running for Wikimedia projects is part of the Kaltura / Wikimedia development partnership.
[1] --
mdale (
talk)
19:22, 10 October 2010 (UTC)
Friendly merged to Twinkle
Per
this discussion Friendly was merged to Twinkle. Could/should an administrator (or whoever is capable of doing this) remove Friendly from the my preferences menu. Hundreds of people would be surprised when friendly is suddenly yanked out from under them but at some point we gotta do it.
MarcusQwertyus19:05, 3 October 2010 (UTC)
at some point we gotta do it - Why? Unless there's some technical reason why this needs to be done in order to complete the merge, I don't see why this needs to be done at all. At the very least, there should be some sort of warning. Mr.Z-man20:59, 3 October 2010 (UTC)
Well, Friendly is technically no more, as I think the plan was to make Twinkle do everything and remove Friendly altogether. But it is too early right now; the merge is not complete. /
ƒETCHCOMMS/21:11, 3 October 2010 (UTC)
If Friendly is enabled in preferences, but Twinkle is not enabled, will Friendly still work after the merge? If no, then the field to enable Friendly should be replaced with a message. If yes, would having both Friendly and Twinkl both enabled be an issue? ---—
Gadget850 (Ed)talk21:15, 3 October 2010 (UTC)
The way it really should be done is something like this:
Friendly continues to work as normal until the merge is completed.
The description for the gadget should be changed to tell people not to install it.
Something should be modified in Friendly to tell users to switch to Twinkle
Ample time should be given to allow people to make the switch (at least 30 days)
I disabled Friendly and lost the welcome tab, so it looks like it would be premature to remove it yet. Looks like you have a workable plan in place for when it is not needed. ---—
Gadget850 (Ed)talk10:44, 4 October 2010 (UTC)
Indeed, if you have both tools installed, it works like a merged tool, and all the branding is "Twinkle", but we're not there (yet) on making it truly one tool. Once we're there, however, the plan is perfectly workable, but right now, it's a shade premature.
SchuminWeb (
Talk)
20:00, 1 November 2010 (UTC)
OSM
We've enabled the OSM gadget
MediaWiki:Gadget-OSM.js on German Wikipedia for everyone by default. For every article with a coordinate, it shows a little "Map" link next to the coordinate in the upper right corner. Clicking on that opens an OpenStreetMap map at the top of the page; another click closes the map. The maps are serverd from the toolserver, so we won't nuke the poor OpenStreetMap servers :-) I've been asked to set it up as a gadget here; it might eventually become default as well. As this is tried with a large user base already, I'll add it to the gadget list myself soon, unless someone else beats me to it. --
Magnus Manske (
talk)
12:37, 2 November 2010 (UTC)
Sparked by
this proposal and suggested by Evula, as well as by past discussions relating to element- and page design, where there is always the few that object change because "the font is too small!", here's a gadget that provides a one-click solution to those that loathe small fonts. It basically resets the fontsize of those elements, such as navboxes, infoboxes and reference lists to 100%. The list can be extended as I am bound to have forgotten a few. This should help readability for those that have problems with small fonts. —
Edokter •
Talk • 22:16, 30 November 2010 (UTC)
Edit on arrival
How about "Edit on arrival"? Where every page you open directly goes into edit mode.
Meta has it; probably just a matter of copying it here.
Rehman03:41, 2 December 2010 (UTC)
ProveIt
I'd like to propose
ProveIt, a tool we've developed at Georgia Tech for managing references. It supports adding and editing references, as well as inserting citations to existing references. It has been tested as an on-Wikipedia user script since August 2010 , and was developed in other forms before that. It requires jQuery, but should support the latest versions of Firefox, Chrome, Safari, Opera, and Internet Explorer. Additional information is available on
ProveIt's website.
I suggest
PrettyLog to be offered as a gadget to users. It gives log pages a layout similar to the search results. If the log contains file uploads, the gadget also adds a small thumbnail for each file. --
Leyo13:10, 3 November 2010 (UTC)
It's been reverted to 1.16wmf4. Due to caching, gadgets were broken after the revert, but it should work fine now. Is it working again for you? And don't worry about PHP files. That doesn't concern normal users. Unless there's a dangerous security vulnerability that the developers don't know about, MediaWiki won't run PHP files stored on the wiki.
Reach Out to the Truth15:19, 8 February 2011 (UTC)
A link in the toolbox that adds missing information to references in an article, and corrects common errors (misspelt parameters, etc);
A button under the edit field that completes partial citations, so that one can type, for example, "{{cite journal|pmid=12345}}", and have the full reference details completed ready for you to check them before you save the page.
English Wikipedia: Retention Rate after one year: 2004-2009
I would like to propose
WikiLove as a new Gadget for the English Wikipedia. Right now it only supports Vector, but it is the first Gadget of its kind—designed to make people happy instead of pissing them off :P It currently supports giving barnstars, cookies, cupcakes, pies, and kittens. More features are planned for the future.
Kaldari (
talk)
01:03, 3 March 2011 (UTC)
Interesting, but doesn't seem to have any practical purpose. I don't think most people would be pleased to see an increase in barnstar-giving, etc. Personally I don't mind (see: barnstars on my own user page), although I think that the current level of barnstar-giving is sufficient. Gary King(
talk ·
scripts)17:55, 14 March 2011 (UTC)
You might want to take a look at the
March 2011 Update. The level of positive reinforcement given to new editors is absolutely not sufficient. Indeed, it is practically non-existent compared to the proliferation of warning templates and negative reinforcement dished out via Twinkle, etc. This is one of the main reasons that editors cite for leaving the project. Have you seen the
editor trends study or the graph at right? Sorry if I sound frustrated, but your response is identical to the response I got from the Twinkle community. Isn't making Wikipedia a more friendly environment a good thing? How are a few more barnstars going to hurt Wikipedia? It just doesn't make sense to me.
Kaldari (
talk)
19:07, 14 March 2011 (UTC)
For other skins such as Monobook, can't there only be one link that opens a dialog box where the user can then choose which of the existing three options they'd like to use, and then the dialog changes to their option? This seems like it'd allow for new options to be added without requiring more tabs or a longer dropdown box. Gary King(
talk ·
scripts)04:54, 15 March 2011 (UTC)
I'm definitely in support of adding this as a gadget. I added it as a userscript and it's clearly pretty bug free, so that, plus the fact that it could potentially be expanded to use such as welcoming templates (please!) makes it useful and stable enough to add in my mind.
WikiLove isn't a nice-to-have part of the 'pedia, it's a need to have. :-)
Steven Walling21:40, 14 March 2011 (UTC)
Kaldari has also
proposed adding this capability to Twinkle in much the same way that Friendly has been merged in. This would reduce menu clutter, make it available to a large number of users quickly and provide monobook support. This could be done near the end of the current Twinkle rewrite effort. We could have a single "Award" menu item that brings up a dialog to select the class of award followed by the appropriate dialog for the chosen class. That said, I have no objection to making it an independent gadget if users prefer that option. —
UncleDouggie (
talk)
03:36, 15 March 2011 (UTC)
Switching it to a single dialog box is the plan for version 2. I'm a bit reluctant to integrate with Twinkle at this point for two reasons: Firstly, the code behind Twinkle is a bit antiquated. I like having the speed and flexibility of using jQuery and ResourceLoader. Do you know if they're planning on rewriting it in jQuery? Secondly, I'm designing WikiLove to be extremely easy to use with a very user-friendly interface. Twinkle is a bit more of a power-user tool which is more intimidating to newbies.
Kaldari (
talk)
05:26, 15 March 2011 (UTC)
The internals of Twinkle are being migrated to jQuery right now. Converting the dialogs has been deferred to a later phase because we're up against the clock on HTML 5. However, there is no problem with adding an "Award" item to the TW menu and having it bring up your current jQuery UI. I've already done exactly this for one my Twinkle testing utilities. We could keep your page edit code temporarily, but it would be more reliable to migrate it to the new Twinkle page edit methods because they have more robust support for the MediaWiki API. The problem is that the Twinkle page edit methods are currently incompatible with jQuery UI, but that's on my list to fix soon. —
UncleDouggie (
talk)
01:08, 16 March 2011 (UTC)
This is a bad idea. Indiscriminate issuing of nonsense (kittens, cupcakes, ...) would encourage more of the same, and we may get a subculture who focus on doing not much more than issuing pretty boxes. We need useful contributors, not people who think kittens are cute and who like spreading wikilove. If an editor does some good work, please give them a barnstar. If necessary, make a couple of "good work" barnstars for new editors who really do something useful (even if quite small). However, it should not be a simple click to issue such a barnstar because there should be some thought involved.
Johnuniq (
talk)
10:18, 16 March 2011 (UTC)
Originally the script did nothing but facilitate giving barnstars (as you suggest), but everyone complained that it would cause "abuse" of barnstars since they are only supposed to be given for extraordinary achievements (according to some people). To address this criticism, I added other less prestigious awards. Although I admit the kittens are just for fun, the other awards (barnstars, cookies, brownies, etc.) are all designed to accompany a personal message from the awarding person. In other words, they are designed to facilitate positive communication, not just act as page decorations. The barnstar interface even allows you to send an email notice to the user. I hope you've actually tried the script and aren't just judging it from the two screenshots. Are there any changes I could make to the script that would address your concerns?
Kaldari (
talk)
17:18, 16 March 2011 (UTC)
Johnuniq, I have to say I completely disagree with the idea that there should be some thought put into the gifting of a barnstar. Barnstars aren't awards for "good work". They're markers of appreciation. Everyone can use more appreciation. This script can and will be abused—and that is a good thing: the underlying goal of barnstars is to spread appreciation. {{
Nihiltres|
talk|
edits|
⚡}}19:36, 16 March 2011 (UTC)
I am not the only one who thinks that indiscriminate templating is a bad idea, even if it's wikilove. A recent case at ANI resulted in a user being indef blocked, although the indiscriminate templating in that case was more weird than is being proposed here. However, it does show what I have observed on other occasions, namely that while some think handing out treats for no reason is desirable, others do not. The ANI report is
here (permalink). If I walked down the street and said "I love you" to everyone I saw, I would not expect a good result. It's the same with wikilove. By all means, if you see a new user fix a typo, give them a junior-style barnstar saying "thanks for helping to build the encyclopedia!". But don't encourage the mistaken belief that indiscriminate anything is desirable here. I don't need talkback, thanks.
Johnuniq (
talk)
00:31, 17 March 2011 (UTC)
I'm not really sure I understand what your criticism has to do with this script becoming a gadget. If an editor abuses a template, that's a problem with the editor, not the template itself or the tools they used to add it. Are you saying that you just oppose talk page templates in general? Would reducing the script back to a barnstar-only tool alleviate your concerns?
Kaldari (
talk)
00:41, 17 March 2011 (UTC)
My view is that such a gadget would be regarded as "official", and therefore it should be used. For example, the MediaWiki interface can show the contributions of any user, and anyone can check such contribs. Likewise, a gadget would be regarded by many as part of the user interface, and if it is ok to click it once, it is ok to click it 100 times every day (and that helps my edit count!). I have no problem with handing out minor barnstars to encourage new users who make even a very simple contribution—that would be encouraging because it would show that someone had noticed and cared about the contribution. However, if someone were to hand out even 10 such rewards per day, the exercise would be greatly cheapened and not much different from the mechanical and insincere
"have a nice day". I urge that some strong guidelines be attached to any such gadget: use it only with a reason (and "I want to" is not a reason). Finally, yes, it would be good if a gadget could not hand out kittens and so on—only barnstars, although some "new contributor" style barnstars should be used when encouraging new editors.
Johnuniq (
talk)
01:22, 17 March 2011 (UTC)
Of course indiscriminate awards are a bad idea. Including this feature in Twinkle would make it not standout as a separate gadget and it would only be used by Twinkle users, who should know what they're doing. There have been times that I probably should have given someone a barnstar, but I just didn't think about it. Because of this script, I recently gave an editor, who has been here for 2 years and has 2500 edits, their first ever barnstar. It wasn't a service award; I had a good reason and it was very appreciated. Perhaps my barnstar award rate will increase from my typical 3 per year to 10 per year. Is that really so bad? I still remember the excitement of receiving my first barnstar. It helps retention by letting editors know that they're contributions are valued. Still, I don't want one for just doing routine things and I apply the same standard in giving them to others. I could do without the kittens as I'm not a cat person and the food would just make me hungry. A lesser award consisting of one of the smile templates would be useful. —
UncleDouggie (
talk)
05:18, 17 March 2011 (UTC)
After thinking about it some more, I'm open to the idea of merging some of the functionality into Twinkle, especially if Twinkle is getting a much-needed rewrite. Feel free to steal any of the code from WikiLove that would be useful. In the meantime, I'll keep improving the user script for the people that find it useful.
Kaldari (
talk)
05:45, 17 March 2011 (UTC)
Merging into a tool that clueful editors use sounds good. I would still hope the docs provide a brief outline of the principles I am trying to support: rewarding even a small contribution from a new user is great; quickly handing out rewards without thought is bad. @UncleDouggie: Using a tool to deliver 10 or even 100 barnstars per year would be excellent—my problem is with the over-excited users I have occasionally noticed who hand out wikilove and smiles at that rate per week, or even per day.
Johnuniq (
talk)
06:11, 17 March 2011 (UTC)
A volunteer developer has expressed interest in helping to develop the WikiLove idea into an experimental extension (ala
Wikilabs). The extension would be localizable to both project and language (and work in all skins). This means I won't be doing any further work on the User Script, so I guess you can consider this proposal withdrawn.
Kaldari (
talk)
00:51, 28 April 2011 (UTC)