Wikipedia:Gadget/proposals

This page is used to discuss the addition of user scripts as Wikipedia gadgets.

Existing discussions may continue on this page, but new proposals should be directed to the village pump to reach a wider audience.

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.

wikEd as a gadget

Discussion started at Wikipedia:Village pump (technical)#wikEd as a gadget.

wikEd is a full-featured Wikipedia-integrated text editor that adds enhanced text processing functions to edit pages. Currently it works only for Firefox and other Mozilla browsers. wikEd is already a gadget on the German, French, Hungarian, and Occitan Wikipedia as well as the Polish Wiktionary. I suggest to add it as a gadget on the English Wikipedia. ?????l? 03:00, 17 January 2008 (UTC)

A localized version of wikEd is now enabled at the Vietnamese Wikipedia and Wiktionary. – Minh Nguy?n (talk, contribs) 10:02, 17 January 2008 (UTC)

Usually I'm against scripts that only work in one browser. Also, I agree with some users that the code is kind of bloated. On the other hand, a lot of users seem to like it, and I guess we cannot expect major improvements right away, so why not? ? AlexSm 22:11, 17 January 2008 (UTC)

I agree with AlexSm. Gadgets should be cross-platform; Mozilla and Internet Explorer are both big browsers. However, I think that the amount of people requesting IE support will boost if this becomes a gadget, prompting Cacycle to add IE support to wikEd, so why not give it a shot? --PostScript 15:30, 21 January 2008 (UTC)

Should I then add the version 0.9.60b of wikEd as a gadget sometimes soon? ?????l? 04:26, 5 February 2008 (UTC)

As I said in that last VP discussion, it has my support. I also like the idea that giving this more exposure could help development. Not just from a pressure standpoint :) but possibly finding people who would be willing to do some of the grunt work or whatever, to help make this work in IE (and maybeplease in Safari :D ) -- Ned Scott 07:15, 5 February 2008 (UTC)

OK, it's now a gadget. ?????l? 02:55, 6 February 2008 (UTC)

Metadata script as a gadget

Discussion started at Wikipedia:Village pump (technical)#Suggestion for new gadget.

I suggest that the script at User:Outriggr/metadata.js be made into a gadget. The script displays an article's assessment rating below the page title and colors the page title accordingly.

Making this script into a gadget would result in the assessment system, a good judge of the overall quality of an article, becoming more generally known and available to more people. For more detail on how it meets all the criteria for gadgets, see the village pump discussion.

There's a slightly different version of the script in my userspace at User:Pyrospirit/metadata.js. The only difference is that I changed one condition for the begin function so that it works on diff pages and old revisions. It's a useful additional feature, so I recommend that this change be made to the gadget version as well.

The script can't do any damage, and since it seems to be compatible with all major browsers, I really don't see any reason not to turn it into a gadget. Pyrospirit (talk · contribs) 14:23, 17 January 2008 (UTC)

I think the code can be shortened by using existing sajax_init_object(). Also, if assesment is always on the top of the talk page, &action=raw should be changed into &action=raw&section=0 (this feature has been added quite recently). And while I don't like scripts that query the server on every page, I guess this can't be improved in this particular case ? AlexSm 22:11, 17 January 2008 (UTC)

I'm very inexperienced with JavaScript, so could you show me how you would do this? You can make the change you suggested to my slightly modified version at User:Pyrospirit/metadata.js; it already has the change that lets it work on diffs and old revisions, which means it'll probably be the version the gadget will be copied from. Pyrospirit (talk · contribs) 23:51, 17 January 2008 (UTC)

I found that the script, apparently, cannot parse & correctly. See this for an example. -- ReyBrujo (talk) 15:18, 20 January 2008 (UTC)

Well, it is not &, as this works correctly. -- ReyBrujo (talk) 15:19, 20 January 2008 (UTC)

I'm not sure what's causing this, but my best guess would be that it's the parentheses since those are the only characters other than the &, letters, and spaces in the title. Fortunately, it seems to fail silently in the first diff you linked to instead of giving annoying error messages or something. I'll try to fix it, but it doesn't seem to happen very often. Pyrospirit (talk · contribs) 15:30, 20 January 2008 (UTC)

I've done some testing, and it seems to occur whenever there is an & symbol inside parentheses. For examples, see Gnome (Dungeons & Dragons), Character class (Dungeons & Dragons), Wizard (Dungeons & Dragons), and any other page with (Dungeons & Dragons) in the title. Pyrospirit (talk · contribs) 15:36, 20 January 2008 (UTC)

The problem is that it is requesting the wrong talk page: http://en.wikipedia.org/w/index.php?title=Talk:Gnome%20(Dungeons%20&%20Dragons)&action=raw&section=0

Note that it is not escaping the &. -- ReyBrujo (talk) 15:49, 20 January 2008 (UTC)

And Mario & Sonic is not working, the URL is http://en.wikipedia.org/w/index.php?title=Talk:Mario%20&%20Sonic%20at%20the%20Olympic%20Games&action=raw&section=0

that means it is taking the assessment from Mario instead of Mario & Sonic. -- ReyBrujo (talk) 15:52, 20 January 2008 (UTC)

I tried escaping the wgTitle variable, but it seems to have made no difference. Did I do that correctly? I'm still learning JavaScript, and this is the first script of this size written by someone else that I've worked on. I don't see what else could be wrong with it at this point. Pyrospirit (talk · contribs) 16:42, 20 January 2008 (UTC)

Took a while to figure out what was wrong, but it is now fixed and seems to work on all pages as it should. Pyrospirit (talk · contribs) 20:44, 20 January 2008 (UTC)

So... anyone going to actually make this a gadget? Admin needed, please! Pyrospirit (talk · contribs) 22:07, 15 February 2008 (UTC)

Well, I will see if I can make it on this weekend. -- ReyBrujo (talk) 17:44, 4 March 2008 (UTC)

 Done -- ReyBrujo (talk) 19:40, 9 March 2008 (UTC)

Special:Log Table

Moved from MediaWiki talk:Gadgets-definition.

I propose adding LogPage Table script as a gadget. I guess some icons could be changed to better ones. One possible problem is the maintenance, since new kinds of logs seem to appear regularly these days ? AlexSm 02:42, 12 January 2008 (UTC)

I've just started using it and it seems pretty nifty. I'd support this. -- Ned Scott 07:12, 5 February 2008 (UTC)

I've been using this a while, and I keep finding myself reverting back to list view. I think the technical concept is great, but the actual layout could use some work. -- Ned Scott 03:56, 10 March 2008 (UTC)

Gadgets

I skipped the process, since I was unaware it was necessary, and installed the following gadgets:

• Move tabs to sidebar (monobook)
• Move tabs to sidebar (modern)
• Compatibility layer to run monobook scripts in modern

—Random832 02:34, 26 January 2008 (UTC)

The process doesn't matter at all, frankly. I don't like either of the gadgets above myself, so I won't be adding them, but I won't oppose them until they are actually made into gadgets, because they are messy, and not likely to have a wide audience. I personally don't like WikiEd either, I think it is too bloated, but I'll let that one be. Prodego ^talk 01:08, 7 February 2008 (UTC)

Language Links

I've finally gotten my language links tool to work properly in IE, and I think it's a good candidate for a gadget. The (heavily commented) code is at User:Zocky/LanguageLinks.js, and it can be of course installed with

importScript('User:Zocky/LanguageLinks.js');

The tool basically turns the language link box in the sidebar into a miniature multi-language dictionary, by displaying the titles of linked pages instead of language names. It needs to be tested against IE7, otherwise I think it's ready to go. Zocky | picture popups 13:46, 14 February 2008 (UTC)

We already discussed this on IRC, but still: creating a table instead of a list breaks {{Link FA}} and any user's custom CSS. —AlexSm 21:30, 25 February 2008 (UTC)

Twinkle

I know there are obviously going to be objections to this, but wouldn't WP:TWINKLE make a good gadget? I know it is not compatible with IE but neither is WikEd. Parent5446^{(Murder me for my actions)} 03:43, 18 February 2008 (UTC)

There is still some things missing in gadget to account for Twinkle optimally, otherwise there would have to be 15 additional separate gadgets. etc... —Preceding unsigned comment added by AzaToth (talk) 18:49, 18 February 2008

watchlistSorter

I have just created a new watchlistSorter because the existing one no longer works. I think this could become an gadget candidate and I would like to hear your opinion to improve the script. See the script's page User:Cacycle/watchlistSorter and the code User:Cacycle/watchlistSorter.js. ?????l? 05:41, 25 February 2008 (UTC)

I responded with some notes on User talk:Cacycle/watchlistSorter. —AlexSm 21:30, 25 February 2008 (UTC)

Watchlist: only new, sort, unwatch

I propose testwiki:Wikipedia:Gadget/Watchlist as a gadget. It's primary function is to show only new changes, this is very useful and I think should be built into MediaWiki. The code is borrowed from User:Ilmari_Karonen/watchsince.js. Two other functions are ajax unwatch (borrowed from my wlUnwatch script) and a simple sorting. Currently this gadget is live on test.wp and ru.wp. —AlexSm 21:30, 25 February 2008 (UTC)

HotCat.js can now be tested

I have started work on a port of HotCat.js I know quite a few people want this as a Gadget, but it needs some thorough testing of course before it can be. So User:TheDJ/Gadget-HotCat.js is the code to test. A short list of important changes from the original:

• blacklisting code is disabled.
• all code for the uploadForm has been removed
• autocommit is disabled
• will be enabled on pages without categories so that you can easily add them
• uses javascript:void() as a dummy value for href in order to avoid a conflict with popups.
• checks for {{Uncategorized}} and removes it if a category is added
• does not use JSconfig for configuration options like its Commons original

If you have any problems or comments then please leave them on the talk page of the script or on my usertalk --TheDJ (talk • contribs) 19:22, 28 February 2008 (UTC)

Added as a Gadget. --MZMcBride (talk) 16:21, 21 March 2008 (UTC)

Contributions ranges

I've got an in-progress script that might be a candidate for gadgetude: User:Splarka/contribsrange.js. It is for looking up ranges of contributions (specifically CIDR), or wildcard searches, which is an oft requested item. There are toolserver tools to do this, but they work on the replagged database and are a bit inconvenient. If it detects a valid /16 or /24 to /32 CIDR in the input box or URL parameter, or if it sees a string ending in an asterisk, it performs an API call to &ucuser or &ucuserprefix, via <script> &format=json (so has the potential to work across domains if required), with an event handler when that script loads that decodes the returned information. It respects the namespace selection, year and month "start" date (both required), and has crude pagination. Obviously there are several ways to improve it (or in fact, deprecate it, by supporting these formats native in Special:Contributions), but I'd like feedback and opinions on it (even if it isn't worth Gadgeting). There is one problem with spaces (see bugzilla:13157), as the API (as of this writing) doesn't seem to handle spaces in the string.

However: it needs testing on alternate browers, as well as esoteric test cases I can't predict. --Splarka (rant) 00:22, 3 March 2008 (UTC)

A wonderfully useful tool and much faster than the toolserver-based one. Possible issue - MediaWiki allows usernames to contain an asterisk. Mr.Z-man 05:57, 3 March 2008 (UTC)

Per asterisks in names: I was aware of that, but couldn't offhand think of any easy way to indicate a prefix search in a known wildcard syntax that wasn't allowed in usernames. I think the cross-occurences would be rare enough and harmless in the long run. Obviously this tool could have been disassociated with Special:Contributions in a way that would make it more intuitive, but I was going for simplicity and almost invisible background operation. --Splarka (rant) 06:56, 3 March 2008 (UTC)

Cool. Prodego ^talk 22:54, 5 March 2008 (UTC)

The output of special:contributions/127.0.0.0/16 is interesting as it finds user:127.0.01 which is not an IP address - it is an actual username. Same goes with special:contributions/216.126.89.0/24 which finds an IP address written in the old UseModWiki format, user:216.126.89.xxx. I'm unsure whether these are bugs with the API because it does say it will find an IP range *or* wildcard. Graham87 06:46, 6 March 2008 (UTC)

This is also used as a gadget on commons and meta. I've gone ahead and added it as a gadget. Mr.Z-man 03:49, 20 March 2008 (UTC)

Sweet. --Splarka (rant) 07:32, 20 March 2008 (UTC)

Twinkle (default settings only)

I'd like to add a gadget for Twinkle (default settings only). The default settings should work fine for most users, and having it as a gadget would make this very useful tool easier for nontechnical users to install. Any thoughts? —Remember the dot ^(talk) 22:51, 5 March 2008 (UTC)

Doesn't it not work in IE? Prodego ^talk 22:55, 5 March 2008 (UTC)

It doesn't work in IE due to IE's incomplete JavaScript support. The gadget would clearly state that it is for Firefox, Safari, and Opera only. —Remember the dot ^(talk) 06:55, 6 March 2008 (UTC)

I'd like Twinkle as a gadget too, but see the Twinkle post above Think outside the box 14:18, 6 March 2008 (UTC)

I went ahead and added it to the list. It does work as a gadget, you just can't customize it.

By the way, I set up the Twinkle gadget to just import Twinkle from AzaToth's userspace. Since all user scripts are automatically protected, there's no danger of vandalism, and we won't have to maintain two copies of the script this way. —Remember the dot ^(talk) 21:55, 6 March 2008 (UTC)

Thats great! Any chance of getting Friendly as a gadget too? Think outside the box 09:45, 7 March 2008 (UTC)

Sure thing. —Remember the dot ^(talk) 00:28, 8 March 2008 (UTC)

Thanks! Think outside the box 12:09, 8 March 2008 (UTC)

Would there be some way of adding a link/note so that when someone is selecting things as gadgets they could be told that there are customizable options outside of the gadgets interface? I bet there's some editors out there that will be using this out of convenance, but would still be knowledgeable to edit their own monobook.js file, but might not be aware of normal userscript stuff. -- Ned Scott 04:01, 10 March 2008 (UTC)

I think they already do; "Twinkle uses the default settings only; to customize Twinkle you must install it the traditional way." Think outside the box 10:14, 10 March 2008 (UTC)

Less edit clutter

At User:Magnus Manske/less edit clutter.js. Tested (by me;-) successfully on Firefox 2/3, IE7, Opera. It was suggested to add it to the gadgets, and maybe even turn it on for newbies by default. One step at a time, though ;-)

From my mail to wikien-l:

It separates

• templates, images, and horizontal lines at the top of a page
• templates and some magic words at the end of a page
• categories
• language links

into text boxes of their own. This happens automatically right after loading the edit page, and it all gets reconstructed into a single text the moment you save, preview, or diff the edit. On preview or diff, everything gets separated again.

It is only enabled for the article namespace. Top and bottom edit boxes can be hidden (I could add an option to hide either as default), and everything can be reset to "standard", giving the normal edit page for the moment.

Besides better structuring of article body and "meta" content, it does clean up whitespace, sort categories and language links alphabetically, etc.

See a screenshot. --Magnus Manske (talk) 10:27, 11 March 2008 (UTC)

Agree as a gadget but not by default. Think outside the box 14:17, 11 March 2008 (UTC)

Some notes:

• When user clicks on a save/preview/changes button, I think the script should hide additional textareas, otherwise it might be a bit confusing on a slow connection.
• The script absolutely have to empty additional textareas before joining, otherwise sequence "Show Preview" - press-escape-button - "Show Preview" doubles all interwiki, categories, etc.
• I'm afraid you cannot rely on a simple regexp to find all interwiki and you have to keep a list of all interwiki prefixes. Some prefixes are more than 6 characters long. For example, try to edit Elephant: after preview the script resorts interwiki the bad way.
• We need some kind of announcement that many editing gadgets are not compatible with each other.

—AlexSm 16:05, 11 March 2008 (UTC)

In addition, if the references in the text have a lot of info, it extends the page width, extending the bottom three textboxes along with it, making the process more difficult. Parent5446^{(Murder me for my actions)} 23:21, 12 March 2008 (UTC)

Batch proposal

I have a batch proposal of gadgets. I took them from the Simple English Wikipedia and they seem pretty cool. They all work, obviously, and I think they are all compatible with major browsers. I copied all of the scripts into my userspace. They are in the following pages:

User:Parent5446/MediaWiki/GadgetDiffs.js - Adds a button to the top of the page that shows the diff of the last edit. (I think this might not be added since TWINKLE is already a gadget and TWINKLE includes a last button.

User:Parent5446/MediaWiki/GadgetHotCat.js - Allows users to add, remove, and change categories using plus and minus buttons at the bottom of the page.

User:Parent5446/MediaWiki/GadgetNewpages.js - Adds a box in the sidebar that shows recently created pages. Updates every five seconds (Or ten, I forget which).

User:Parent5446/MediaWiki/GadgetRecentchanges.js - Same as above except with a Recent Changes box.

They are all pretty useful and I think they would help out a lot. Parent5446^{(Murder me for my actions)} 22:21, 12 March 2008 (UTC)

As a small note. The GadgetHotCat.js (as in use on simple ) is a copy of my User:TheDJ/HotCat version that has been in testing on en.wp I think that it might be safe by now to make a Gadget of that. The big changes have been tested for a while, and I'm not aware of any issues atm. Although recent changes to the Category HTML box might require me to take another look at it, just to be sure. --TheDJ (talk • contribs) 12:03, 20 March 2008 (UTC)

I was wondering btw. if people would appreciate to have the hotcat functionality for the upload form. I figured it would be less useful here, but if need be, it can easily be actived/re-added --TheDJ (talk • contribs) 12:07, 20 March 2008 (UTC)

I'm not sure about the upload form. Some people might find it useful. However, I think the main tool should definitely be a gadget. It is very useful in articles. Parent5446^{(Murder me for my actions)} 19:56, 20 March 2008 (UTC)

Just so you know, all of the scripts I listed were duplicates of scripts on Wikipedia. So I deleted them. I still think they should be added, though. Parent5446^{(Murder me for my actions)} 13:26, 21 March 2008 (UTC)

HotCat has been added as a Gadget. --MZMcBride (talk) 16:21, 21 March 2008 (UTC)

MediaWiki Scripts

I've started of a discussion about Lupin's Anti-Vandal tool here about it being a possible Gadget, would this be possible I find it very useful when I patrol wikipedia for any vandalism. Terra ^{What do you want?} 13:26, 14 March 2008 (UTC)

Embedded font support now live

The latest version of Safari includes support for embedded fonts, opening up new possibilities for font support on Wikipedia. To demonstrate the concept, I added the DejaVu Sans font as a gadget. If you are using Safari 3.1 or later, just checking the box will enable you to use this font even if you can't install it directly onto your computer.

Please try this out and let me know how it works. DejaVu Sans is not the most useful font, and I'd be interested in hearing about other fonts that might be useful to have as gadgets. —Remember the dot ^(talk) 17:28, 21 March 2008 (UTC)

Everyone keep in mind that this needs to be limited to fonts which are available under a free license. —Random832 (contribs) 17:38, 28 March 2008 (UTC)

Advisor.js proposal

I'd like to propose a script I've written—it scans the wikitext as you edit and suggests fixing some common formatting and stylistic issues. It works in most major browsers, I try to keep the code clean, commented where necessary, non-invasive (no pollution of the global namespace, no augmented prototypes of built-in objects), with reasonable defaults, and independent of the skin. I usually fix bugs and add new functionality in the weekends. --Cameltrader (talk) 12:36, 23 March 2008 (UTC)

Just so you know, there is a suggestion it adds that should be be made. I suggests that you change the standard ellipsis ("...") to the special character for ellipsis ("…"), which MoS discourages greatly. This should be fixed where the advisor changes ". . ." and "…" to "...". (Just as a reference, "..." is three periods, "…" is the special ellipsis character, and ". . ." is three periods with spaces in between. MoS recommends the first, discourages the second, and says the third is deprecated.) — Preceding unsigned comment added by Parent5446 (talk • contribs)

You are right. I will have to invert the original idea. --Cameltrader (talk) 17:01, 28 March 2008 (UTC)

My concern with that is that part of the MOS is marked for cleanup. I don't know if that means it just needs reformatting or if a change is expected. It seems to indicate that the ellipsis character isn't recommended because of difficulty to input and readability in certain fonts. We use standardized fonts, and difficulty of input shouldn't impact an editing tool. I may have missed something though. Jay32183 (talk) 18:44, 29 March 2008 (UTC)

The purpose of the script is to help editors follow the MOS. I view this as an evolutionary process, and not something static. Whenever I notice that the MOS and Advisor.js are out of sync, I usually adapt, so the MOS cleanup is welcome.

What I'd expect you to discuss here is whether it is justified to include the script as a gadget or not. --Cameltrader (talk) 20:41, 29 March 2008 (UTC)

I support this tool as a gadget. I was suggesting the MOS may need change because of the tool. If this is a gadget, the ease of input isn't a concern because the tool will turn either input into the same thing. So this should be a gadget and that should help the evolution of the MOS. Jay32183 (talk) 06:24, 30 March 2008 (UTC)

Wow, changing the MOS because of a tool sounds ambitious :) In this particular case, ease of input is a hurdle, but I think they had other reasons too when recommending not to use U+2026—it appears too narrow in some fonts or is completely missing. Your counter-argument might be that an ellipsis carries different semantics than three periods, and as long as Unicode provides such a character, we should use it ("support standards!").

I just hadn't paid enough attention to this topic before you mentioned it. Thanks for your support.--Cameltrader (talk) 07:22, 30 March 2008 (UTC)

Picture Popups

I'd like to see User:Zocky/Picture Popups which provides DHTML popups for images to become a gadget. It is currently unmaintained and doesn't work in IE. I, however, hope by writing this the someone manage to make the necessary changes to get this as a gadget. I have listed some of the issues that need addressing

• It uses CSS position:fixed property which isn't support by IE6. IE7 and others do support it, if there's a need for IE6 support I'd recommend using the code from IE7.js
• The script is old. It may be more efficient to utilize api.php and wikibit.js library.
• Minimizing might move the pop-up off screen.

— Dispenser 04:12, 14 April 2008 (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.

A much simpler gadget

Distinguishing links to redirects in a different colour has been a long-standing request on bugzilla (bugzilla:4709, open since 2006). Recently that bug has been fixed, in such a way that although links to redirects appear the same as links to other articles, it's now a trivial two-liner to make them appear differently:

a.mw-redirect {color:#308050}
a.mw-redirect:visited {color:#3070A0}

I'd like to propose that this be added as a CSS gadget. It should be completely portable, due to its simplicity, and is ideally suited as a CSS gadget, because it's a preference that some users will want and others won't. The only problem is in the choices of colour; I don't think that link colours differ too much between skins, but some colours might presumably work better in different skins. (In case you're wondering: nonvisited redirect, visited redirect; 'visited' means that you clicked on a link that linked to a page via that redirect.) --ais523 20:31, 18 February 2008 (UTC)

It's probably something that should be added as direct option in user preferences, but until then this would be a good solution. -- Ned Scott 18:14, 25 February 2008 (UTC)

I'm not against this code as a gadget, but given the small size and possbible other color choices, I think this makes is ideal for a simple personal CSS snippet. —AlexSm 21:30, 25 February 2008 (UTC)

I think this gadget would be very useful. Most users have no idea how to add CSS snippets to their own monobook.css and that is exactly why we need gadgets.

--David Göthberg (talk) 15:31, 23 April 2008 (UTC)

Actually, now I think that this code would indeed make a useful gadget for many users, but I think it should have a description page that would explain how to add CSS for other color choices. And it doesn't have to be complicated: we could create a direct link that would start editing user's monobook.css and on top of that offer insertable code snippets with <charinsert>; I'll try to create an example later. —AlexSm 17:29, 24 April 2008 (UTC)

Fix the sidebar

I think a lot of people are interested in the meta:Help:User style/floating quickbar (which could probably be updated...) — Omegatron 03:46, 4 April 2008 (UTC)

• First, IE7 (unlike IE6) does support attribute selectors (see Comparison of layout engines (CSS)), so you need to either try to make your code work for IE7 or find some other way to exclude IE7. Also see (more than a year old) thread meta:Help talk:User style/floating quickbar#Does not degrade gracefully in IE7.
• Second, the documentation is confusing, it's a bit difficult to understand what exactly needs to appended to user subpages, considering there are several options there.
• I don't mind Floating Sidebar as a gadget, although personally I prefer quite an opposite approach: user:js/bottomSidebar

—AlexSm 19:34, 4 April 2008 (UTC)

Fixed positioning has been implemented in IE7,[1] so we don't want to degrade there.

Since the CSS is included in the script, javascript can be used to hide it from older versions of IE instead of the attribute selector. Whichever is the better choice. I am sure other people here are more familiar with how to do this than I am.

Yeah, it's confusing because people want the personal links as a sidebar. So we have two configurations:

1. Personal links as a sidebar
   • Needs extra CSS to format them
2. Personal links at the top
   • Needs extra JS to fix their position in the page structure

To keep things simple, this script will only do case 2, and move the personal links so they stay at the top like the default look.

Then an independent script can undo the move, put them back to the sidebar, and add their CSS if desired.

See User:Omegatron/monobook.js/floatingSidebar.js for the self-contained script.

importScript('User:Omegatron/monobook.js/floatingSidebar.js'); — Omegatron 01:22, 8 April 2008 (UTC)

I think you have to do more thorough testing, maybe from a different clean account? The current version (floatingSidebar.js) makes most p-tb ('toolbox') links inaccessible because your code relies on some CSS rules in your monobook.css (such as #p-logo {display:none} #column-one {padding-top:0} —AlexSm 15:52, 11 April 2008 (UTC)

I tested with and without the logo, and it wasn't affected either way. Can you describe the problem in more detail? — Omegatron (talk) 16:48, 20 April 2008 (UTC)

Oh, I see. The logo is position:absolute; which screws up the height:100% thing, which makes it not show scrollbars at the correct height when you have the logo. I'll fix it. — Omegatron (talk) 17:17, 20 April 2008 (UTC)

Both the personal links sidebar and floating sidebar scripts have been fixed. — Omegatron (talk) 17:33, 20 April 2008 (UTC)

New Gadget/Script

I would like to request a new gadget or script that allows a user to see if there are any new comments on an articles talk page since the last time they edited that page. Maybe change the color of the talk tab to another color or add a link to the header (similar to how it is for the assessment) when the page is opened. If this is not possible then maybe a user defined date (like today, last X days).--Kumioko (talk) 21:37, 14 April 2008 (UTC)

That sounds like an interesting endeavor. But what pages would this apply to? And what should "new messages" be defined as; an edit to the page since its last visit, the creation of a new section, etc.? I will attempt to work on a basic script, but I encourage others to work on it also since I am a beginner at this kind of stuff. — Parent5446 ^{(t n c k e l)} 00:48, 19 April 2008 (UTC)

I was thinking mostly for the talk page of an article. Basically, if you click on the article then a small message is displayed saying that the last message was left on XX date. Or if possible since the last time you left a message on that talk page, whichever is easier. This way you don't have to open every talk page to see if something has changed.--Kumioko (talk) 15:33, 23 April 2008 (UTC)

"if you click on the article" - does that mean "when you're on the article page"? Checking the talk page would require an extra API request to the server, on every article page, even when you're not interested in its talk page. Here's a different approach: open your contributions, filter by article talk pages, and see on which pages your edit was not the last one. Also you could simply use your watchlist. Please also see my note on using Wikipedia:WikiProject User scripts/Requests below. —AlexSm 16:09, 23 April 2008 (UTC)

Tighter page top tabs in MonoBook

At the Village pump there has been a discussion which lead to the change of the name of the "+" tab to "new section" yesterday. (A talkpage top tab in MonoBook.) The discussion showed that many admins and other users have problems to room all their extra tabs. So I would like to add a gadget with CSS only that makes the tabs tighter. Here is the code I myself currently use:

/* David's tighter page top tabs, v0.4, for MonoBook.
   Change only the second value if several values. */
#p-cactions {
	padding-left: .6em;      /* Outside left of first tab. */
}
#p-cactions li {
	margin: 0 .3em 0 0;      /* Outside of all tabs. */
}
#p-cactions li a {
	padding: 0 .6em .3em;    /* Inside of all tabs. */
}
#p-cactions #ca-addsection a {
	padding: 0 .6em .3em;    /* Inside "+/new section". */
}
#p-cactions li.selected a {
	padding: 0 1em .2em!important;   /* Inside current tab. */
}
/* Extra outside space to distinguish the tab groups. */
li#ca-talk, li#ca-history {
	margin-right: 1.0em;
}
li#ca-watch, li#ca-unwatch, li#ca-varlang-0, li#ca-print {
	margin-left: 1.0em;
}

I can supply code for even tighter tab spacing if that is deemed necessary. But to me it looked a bit ugly to have tighter tabs than that. The code above uses the same narrower spacing for the "+/new section" tab as for the other tabs so I think it looks okay both if the tab is named "+" or "new section". The code works in all three web browsers I have and it does not interfere with other skins.

We could of course have two gadgets:

• "Tighter page top tabs in MonoBook."
• "Even tighter page top tabs in MonoBook."

If you want to test the code paste it into your own monobook.css, then refresh your web browser cache, then wait about 20 seconds and then reload some page to see the change.

--David Göthberg (talk) 13:58, 20 April 2008 (UTC)

I do not think that we should add this more or less trivial change as a gadget. It clogs up the preference page and the only users interested in it must already have plenty of code on their monobook.js page. Additionally, it feels a bit too much like a statement for the linked discussion. Also, I have removed this from the gadget definition page as it has not been discussed properly. ?????l? 00:36, 23 April 2008 (UTC)

Ehm, no, the code I suggest above have never been added to the gadget definition (yet). The gadget definitions you just deleted were other things, among others a very popular fix to add back the "+" tab instead of the "new section" tab on talk pages. And that "+" gadget was not added by me.

--David Göthberg (talk) 00:51, 23 April 2008 (UTC)

Oops, sorry for the confusion. The removed gadgets were addsection-plus and the diff-underlines. I have started new discussions for all of these below. ?????l? 03:41, 23 April 2008 (UTC)

Is there a rule that additions have to be discussed? I would find that very surprising. It turns out there was indeed a "rule" that changes had to be discussed here. I'm going to boldy remove that bit of bureaucracy. There is no similar rule for any of the numerous more visible Mediawiki pages.

In any case, I can't see that this gadget is going to be particularly controversial, and just adding it and going on with business was reasonable enough. — Carl (CBM · talk) 03:23, 23 April 2008 (UTC)

Yes, Cacycle added that "guideline rule" right after he removed those gadgets today.

Cacycle: Since you have responded similarly to several of these gadgets I have responded to you in a separate section below named Clutters the preference page?.

--David Göthberg (talk) 05:36, 23 April 2008 (UTC)

First, I suspect that most users having problems with 'p-caction' width are those users that added some extra personal tabs. Which means they should have no problems editing their monobook.css. Second, this CSS makes tabs look a bit ugly in IE6. Third, when I tested it, I saw it actually breaking other skins: in Modern the tabs become wider, in Simple the tabs (which are located in SideBar) become misaligned. —AlexSm 15:09, 23 April 2008 (UTC)
And I'm not sure this interfering with other skins is fixable at all. —AlexSm 17:29, 24 April 2008 (UTC)

This doesn't work at all for me. I've got "six tabs" and twinkle, maybe that's why. Equazcion •?/C • 18:14, 25 Apr 2008 (UTC)

Diff underlining or borders

Some days ago the devs added a function to Wikipedia that caused red dotted borders around text that had changed in the diff views. This made it possible to see where spaces had been added or removed and made it much easier to find small changes like changes in punctuation. (Which can be crucial in template coding and sometimes even in article layout.) However, many disliked the red dotted borders so the new function was removed again. But many had good use for it and wanted to keep it. I have coded up three variants of this function that can be added as gadgets so those that want it can easily turn it on:

• Red dotted borders. Exactly like the original function.
• Red underlining. Less intrusive but still very clear.
• Yellow-green underlining. Even less intrusive since the diff view is yellow to the left and green to the right. But still pretty clear. I use this one myself.

These gadgets are based on CSS code only. They need no javascript so they are very compatible and work in all web browsers I have tested them in, including my old Internet Explorer 5.5 from 2001. And it works in all the skins I have tested it in.

Here is the CSS code for the three gadgets:

.diffchange {
    border: 1px dotted #f00;          /* Red dotted border. */
}

.diffchange {
    border: none;
    border-bottom: 1px solid #f00;     /* Red underlining. */
}

.diffchange {
    border: none;
    border-bottom: 1px solid #6AD500;   /* Yellow-green underlining. */
}

I already added these gadgets today since I thought they were uncontroversial and many had expressed that they liked the red dotted borders etc. But I was reverted by ?????l?.

--David Göthberg (talk) 04:43, 23 April 2008 (UTC)

I have removed diff_red_underline, diff_yellow-green_underline, and diff_red_dotted_border which have been added today and for which I could not find a previous discussion.

To start the discussion here: I think this is actually very useful, but having three minor design variants is overkill and just clutters the preference page. ?????l? 03:37, 23 April 2008 (UTC)

Cacycle: Since you have responded similarly to several of these gadgets I have responded to you in a separate section below named Clutters the preference page?.

--David Göthberg (talk) 05:37, 23 April 2008 (UTC)

Addsection-plus

This is about the gadget that puts back the MediaWiki default "+" to the "new section" talk page top tab. The gadget was created by Random832.

The addsection-plus gadget has been added last weekend [2] without any discussion here (there was a mini-discussion on Village pump (proposals). I have removed the gadget, requesting a discussion here (unfortunately, it has since been added back, again without discussion [3]).

To start the discussion: I think this is a trivial task that should not be added as a gadget as it clogs up the preference page and the only users interested in it must already have plenty of code on their monobook.js page. ?????l? 03:37, 23 April 2008 (UTC)

I don't really have a lot of active code on my monobook page (at least none that affects the number of tabs I have), but I think that the change is useful for two reasons:

1. At lower resolutions, space can be a real concern...
2. There was fairly broad-based support for changing the tab to "new section", but numerous regular editors – including some who favoured the change – expressed a preference for "+" (for reasons ranging from extra space to ease of use) or, in some cases, a strong dislike for "new section".

While this is certainly not a critical change, I feel that it's sufficiently worthwhile. Black Falcon ^(Talk) 04:04, 23 April 2008 (UTC)

This gadget was discussed and supported in a much more public place than this usually very inactive page. The gadget puts back the well established MediaWiki default "+" to the "new section" talk page top tab. I fully support this gadget.

Cacycle: Since you have responded similarly to several of these gadgets I have responded to you in a separate section below named Clutters the preference page?.

--David Göthberg (talk) 05:39, 23 April 2008 (UTC)

First of all, that Gadget was written by Random832, not me - I noticed it in the discussion leading to the tab text change and enabled it momentarily before I actually changed the tab text, so that users who preferred the original version would have a "personal revert" button, as it were. It greatly decreased opposition to the change, which is good as the change is a usability improvement for newbies. I, among other users, am using it, and I think that it should therefore not be removed. Nihiltres^{t.l} 16:55, 23 April 2008 (UTC)

Alternate idea

Honestly, how many editors past the "autoconfirmed" stage actually use that button? By the time an account is autoconfirmed, I'm fairly certain that they understand how to make a header, and to add to the bottom of a talk page.

So how about not have the preferences, but just have the button "disappear" once an account is autoconfirmed? Sounds like the best of both worlds to me : ) - jc37 06:37, 23 April 2008 (UTC)

No, since some of us have slow computers and/or slow connections. So we don't like to edit the whole page just to add a new section at the bottom. Using the "+/new section" button loads much faster for us. Some talk pages are hideously long.

And it avoids edit conflicts totally. Very nice, especially if you for some reason write English slowly, like not being a native English speaker.

--David Göthberg (talk) 08:35, 23 April 2008 (UTC)

I also find it irritating when people do a section edit of the final section of a talk page to create a new section, and don't fix the default edit summary. Another benefit of the + tab is that the default edit summary is always correct. — Carl (CBM · talk) 12:56, 23 April 2008 (UTC)

Ah, I see. Thanks for the clarification. - jc37 15:58, 23 April 2008 (UTC)

Clutters the preference page?

Cacycle has today removed several gadgets and several times written similar comments above. So I want to respond to that here in one place.

Cacycle wrote:

It clogs up the preference page and the only users interested in it must already have plenty of code on their monobook.js page.

I think this is actually very useful, but having three minor design variants is overkill and just clutters the preference page.

I think this is a trivial task that should not be added as a gadget as it clogs up the preference page and the only users interested in it must already have plenty of code on their monobook.js page.

But there is no lack of space in the preferences page. If the number of gadgets become many we can add more detailed subsections for more types of gadgets. We can not request that all users learn to handle javascript and CSS code and how to handle their monobook.js and monobook.css pages. Most don't even know about those subpages in their user space. Why should we deny all those users this functionality?

The whole purpose of the gadget system is that we programmers can package functionality in convenient gadgets that less knowledgeable users can choose to enable by just a click in their preferences.

--David Göthberg (talk) 05:30, 23 April 2008 (UTC)

"must already have plenty of code on their monobook.js page." Which is why I recently nuked it and started fresh after some tools stopped working. The gadget options for Twinkle and Friendly are welcome since I don't have to clutter up my monobook.js. If there are gadgets that make the WP experience better, then give us the option. --— Gadget850 (Ed) ^talk - 11:32, 23 April 2008 (UTC)

I think that we need some more definite ideas of what Gadgets should be. Here are the facts:

• Gadgets are, effectively, extra preferences; part of the interface.
• Gadgets can use JavaScript and/or CSS.
• Gadgets are either enabled or disabled, with only a checkbox.

This leads me to some general conclusions:

1. Gadgets, as, effectively, part of the interface, must be stable and fail gracefully where applicable.
   1. If a Gadget can be used with its own preferences, it should gracefully change to default preferences when these are not specified.
2. Gadgets should either be broadly compatible with major Internet browsers, or, if not, follow an official standard (e.g. the font Gadget works only in Safari at present, but uses a web standard recommended by the W3C). Exceptions can be made here as some browsers, like Internet Explorer, can be awful this way. If this is the case, the exception must be made plain to all users and fail gracefully.
3. Gadgets should bypass the user difficulties in using monobook.js and monobook.css, since not bypassing the manual solutions defeats part of the purpose of the feature: to let technologically-illiterate people easily use advanced features.
4. No two Gadgets should interfere with each other, and where one Gadget would override another, this should be made plain.

As a general idea, I would support as many Gadgets which fit these criteria to be implemented. We have no space limit, and anything useful is a worthwhile addition. We can use sections and subsections to sort Gadgets into different "categories" and allow users to pick and choose their user experience. Nihiltres^{t.l} 17:15, 23 April 2008 (UTC)

I mostly agree with Nihiltres and the existing rules, but I miss a very important consideration: There are hundreds of existing user scripts and many more to be written. While it would be technically possible to add them all as gadgets, we must keep the user preferences interface manageable for normal users. This implies that we have to find criteria for inclusion that are also based on user interest, quality, and usefulness. Please see my comment here. ?????l? 03:09, 25 April 2008 (UTC)

Forgive me as I haven't read the discussion up until now; but I just wanted to chime in nonetheless. I think gadgets should be limited to those scripts that have proven to be the most widely used. Every little customization doesn't need to be placed there. These are listed in preferences, which means they get seen by everyone as, in a way, "official" functions of Wikipedia, and we should make sure it's a quality listing of features. That means only listing scripts that have been tested extensively, and discussing all additions. This isn't the place to just add something yourself just cause you think everyone would find it useful, without actually discussing it first. Especially, new or unheard-of scripts shouldn't be made gadgets without further testing and discussion. And yes, it should be a rule that new gadgets must first be discussed. This is preferences, the most widely-used "page" on Wikipedia, and it needs to be taken very seriously; it shouldn't change erratically, be subject to wheel-warring, etc. Equazcion •?/C • 18:12, 25 Apr 2008 (UTC)

Equazcion: The problem here really isn't if gadgets should be discussed first or not. The problem is that Cacycle and AlexSm is trying to enforce that all gadgets should first be suggested and "discussed" here at Wikipedia:Gadget/proposals precisely since this page doesn't get many visitors, since then they can control this area and prevent any new gadgets from being added. It seems they don't like anything that makes their own gadgets become less prominently exposed.

I say any further discussion of which gadgets should be added or not should go on the Wikipedia:Village pump (technical). And I say that any consensus reached on the village pump has to be respected, since that overrules any local "consensus" (usually including only Cacycle and AlexSm) in less visited pages such as these. And this discussion itself probably should be moved to the village pump.

--David Göthberg (talk) 10:32, 26 April 2008 (UTC)

I'd agree there. If it's merely a choice between requiring discussion here vs. a more general place like VP, definitely VP should be the place. This page should be deleted, in that case. Equazcion •?/C • 15:26, 26 Apr 2008 (UTC)

Edit button for Infoboxes and Persondata

I would like to suggest a new Gadget to add a plus sign or edit button to to infoboxes and persondata templates. This would allow that infobox or persondata template to be modified more easily than opening up the whole page or section.--Kumioko (talk) 15:35, 23 April 2008 (UTC)

This page is mostly for discussions which existing scripts are to be made as gadgets. I think it would be better to places requests for new scripts at Wikipedia:WikiProject User scripts/Requests, (optionally with announcement on this page). —AlexSm 16:01, 23 April 2008 (UTC)

Requesting rollback options

While this isn't a "gadget", it's a request for something on the preferences page, and it's something that currently can only be done by js. So this seems as good a page as any.

I'd like 2 options for rollback added to preferences. Users shouldn't have to use javascript for this finctionality.

A checkbox as to whether clicking rollback would open an edit window and prompt for an edit summary, or not.

An "inpuboxline" to input a raw text default summary (similar to the inputbox used for custom signatures).

I (and I presume others) would find these to be very useful. - jc37 17:15, 23 April 2008 (UTC)

• Please use Wikipedia:WikiProject User scripts/Requests
• Did you actually mean "shouldn't have to edit monobook.js" when you said "shouldn't have to use javascript"?
• There are two scripts listed at Wikipedia:Rollback feature#Custom edit summaries, but I was thinking on improving those a bit. —AlexSm 17:51, 23 April 2008 (UTC)

Yes, that's what I meant. js isn't an option for some, for one thing. And since rollback is now available on request to most editors, I think that having these two preferences would be comparable to having the preferences for the watchlist or custom signatures (for example). - jc37 17:55, 23 April 2008 (UTC)

From #wikimedia-tech:

[17:56:37] <MrZ-man> brion: what are your thoughts on adding a user preference to prompt for an edit summary when using rollback?
[17:59:19] <brion> MrZ-man: my general thought is that rollback is supposed to have a minimally-invasive ui so you can do things in bulk very quickly
[17:59:31] <brion> and that adding user prefs is evil ;)
[17:59:45] <brion> if you want to leave a summary you can just click the revision, edit, and save

--Mr.Z-man 18:25, 23 April 2008 (UTC)

Which is quite a few more "clicks". I guess it doesn't make sense to me that attempting to foster communication and clarity is more difficult than not.

Also, I'd argue that this would be "higher priority" to be on preferences than more than a bit of the rather lengthy gadgets section (among quite a few others).

That aside, since it's Brion, does this mean that this has no chance whatsoever?

(I prefer to avoid brick walls, whenever possible : ) - jc37 18:57, 23 April 2008 (UTC)