Jump to content

Wikipedia:Gadget/proposals/Archive 1

Add links
From Wikipedia, the free encyclopedia
< Wikipedia:Gadget | proposals

This is the current revision of this page, as edited by MalnadachBot (talk | contribs) at 16:18, 15 April 2023 (Fixed Lint errors. (Task 12)). The present address (URL) is a permanent link to this version.

(diff) ← Previous revision | Latest revision (diff) | Newer revision → (diff)
Archive 1Archive 2Archive 3→Archive 5

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

  1. ^ To avoid confusion, note that this version has some bugs that are fixed in User:Pyrospirit/metadata.js, which should be used instead. — Pyrospirit
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)

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)

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)

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

The default tabs, for an administrator using the default settings* on a watchlisted project page with a new section tab, are 908 pixels wide. And the first tab starts at pixel #203. I'm actually considering proposing making the spacing tighter for everyone. It's disingenuous to assume that this is only people who are adding personal tabs that have a problem with this.
*p-cactions computed font size is 16.2px and the actual tab computed font size is 15.333px. computed font family is sans, actual typeface is arial.
This is not a comment on the merits of a particular solution, merely noting that there is a real problem
--Random832 (contribs) 03:58, 28 April 2008 (UTC)

I don't get the "disingenuous" part of your message ... if we make tabs tighter for everyone, this would only prove my point that we didn't need this code as a gadget. —AlexSm 04:23, 28 April 2008 (UTC)
I sometimes use words incorrectly - I looked up "disingenuous" and it doesn't mean what I was trying to get across. --Random832 (contribs) 13:16, 28 April 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)

I think this would be really useful as a gadget. Kaldari (talk) 18:34, 28 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)

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)

Anti-vandal tool

Someone has probably said this before, but Lupin's Anti-vandal tool? 79.75.137.77 (talk) 19:15, 24 May 2008 (UTC)

A few scripts i use

Wikipedia:WikiProject User scripts/Scripts/Six tabs -- Very simple, is useful. User:Alex Smotrov/histcomb.js -- Combines a users group of edits to a page when looking at the history

would there be any objections to implementing these two scripts as gadgets? The Placebo Effect (talk) How's my editing? Please contribute to my editor review. 16:40, 27 May 2008 (UTC)

Transparent skin

Cobi has created a new stylesheet, that gives a sorta "transparent" look to MonoBook. I am using it right now, and all that you need to put into a gadget is something like this: 

if (navigator.appName != "Microsoft Internet Explorer")
 {
     importStylesheet('User:Cobi/transparent.css');
 }

What do people think about this? Feel free to shoot it down, it would still be a nice thing to add to gadgets. Soxred 93 20:57, 27 May 2008 (UTC)

Just a couple of suggestions: 1) The skin really slows down my browser. It is probably because it is being imported using javascript. The best way to go with this is to suggest this be implemented as a whole new skin in and of itself. 2) Maybe make the skin fade into opaqueness near the title of the page. It could provide a cool effect if done right. 3) Change the link color. Neon light blue is not flowing with the rest of the page. 4) Put a think border around the sidebar as done with the main content. 5) If you have not done so already, try rounding all of the edges (i.e. around the main content section, toolbar, etc.). 6) Change the look of the search bar. It is sort of out-of-place. Other than these complaints, the skin is awesome, seriously. I would love to see this as the newest skin in my preferences page. — Parent5446 ☯ (message email) 23:15, 15 June 2008 (UTC)
Gadgets can also add stylesheets, so the Javascript won't be necessary. Mr.Z-man 00:10, 16 June 2008 (UTC)

I think there should be a gadget to move the section edit links right next to the headings as they are in the German Wikipedia. It makes it easier to navigate by headings for screen reader users, as the word "Edit" is spoken after the section name instead of before it. It is in my Monobook.js for that reason. Some sighted users must like it too because it has been added to a few projects such as the German Wikipedia and the English Wikiversity. The code is as follows: 

//== Change section heading links ==//

 // ============================================================
 // BEGIN Moving of the editsection links
 
 /*
 * moveEditsection
 * Dieses Script verschiebt die [Bearbeiten]-Buttons vom rechten Fensterrand
 * direkt rechts neben die jeweiligen Überschriften.
 * This script moves the [edit]-buttons from the right border of the window
 * directly right next to the corresponding headings.
 *
 * Zum Abschalten die folgende Zeile (ohne führendes Sternchen) in die eigene
 * monobook.js (zu finden unter [[Special:Mypage/monobook.js|Benutzer:Name/monobook.js]]) kopieren:
 * var oldEditsectionLinks = true;
 *
 * dbenzhuser (de:Benutzer:Dbenzhuser)
 */
 function moveEditsection() {
     if (typeof oldEditsectionLinks == 'undefined' || oldEditsectionLinks == false) {
         var spans = document.getElementsByTagName("span");
         for(var i = 0; i < spans.length; i++) {
             if(spans[i].className == "editsection") {
                 spans[i].style.fontSize = "x-small";
                 spans[i].style.fontWeight = "normal";
                 spans[i].style.cssFloat = "none";
                 spans[i].style.marginLeft = "0px";
                 spans[i].parentNode.appendChild(document.createTextNode(" "));
                 spans[i].parentNode.appendChild(spans[i]);
             }
         }
     }
 }
 // onload
 addOnloadHook(moveEditsection);
 
 // END Moving of the editsection links
 // ============================================================

Is there any reason not to add this as a gadget? Graham87 09:03, 28 May 2008 (UTC)

This is a very good idea, thank you. I would like to have this functionality in all Mediawiki Wikis and hope, there is no reason against it. This would be a huge improvement for the usability experience of blind screen reader users. -- Lalue (talk) 11:08, 28 May 2008 (UTC)
Wouldn't CSS be more appropriate than JavaScript for this gadget? —Remember the dot (talk) 01:26, 29 May 2008 (UTC)
Sounds like an excellent idea to me. Is there any reason not to go the way of the German Wikipedia (which, thanks apparently to Lalue here, seems to have a better grasp on accessibility than us) and just incorporate it into the software? I actually think it looks much more streamlined that way. L'Aquatique[talk] 15:49, 1 June 2008 (UTC)
Please could somebody check that if there is a way to move the edit link to the right while keeping the screenreader order. If so, then this should become part of the software/skin, not a gadget. Also, it might not be compatible with other gadgets (such as the first paragraph edit link). Otherwise, it is fine to have this accessibility gadget.Cacycle (talk) 13:17, 2 June 2008 (UTC)
Actually, see bug 11555 for more information about this. The edit link shouldn't even be part of the heading, and that's the way it was before October 2006. This is just a temporary solution for screen reader users until the bug gets fixed, which should happen relatively soon because it's marked as an accessibility bug. Graham87 14:07, 2 June 2008 (UTC)
Fixing the bug would be the best solution, especially for the masses of blind readers without an account. Because nobody knows when this problem could be fixed, a gadget would be a solution for the remaining time. Although it's an accessibility bug, we perhaps have to wait for a long time for a fix. Brion and his team have lots of other things to do. @L'Aquatique: I was not the person who made or inspired this improvement at the German Wikipedia, I just noticed the difference between the German Wikipedia and all other Mediawiki based Wikis and after that I informed my partners from our accessibility project about the issue and user Revolus extracted the JS-snippet from an already existing JS-modification. Best, Lalue (talk) 10:23, 3 June 2008 (UTC)

Proposal for new gadget: : TimeTraveller.js

I'd like to propose the following script for inclusion in the list of gadgets: Wikipedia:WikiProject User scripts/Scripts/TimeTraveller. Any comments welcome. Pcarbonn (talk) 03:05, 1 September 2008 (UTC)

User Page Maintainance

I'd like to suggest a gadget that reverts any edits to a user's user pages by anyone else besides the user. The user can also specify which pages in their User: and User_talk: namespace it will apply to. -- Melab±1 22:58, 6 September 2008 (UTC)

If such a script exists, it should be deleted, as it would be massively inappropriate. Mr.Z-man 20:26, 29 September 2008 (UTC)

Username highlight

I'd like to propose turning User:Ais523/highlightmyname2.js into a Gadget. It highlights instances of a user's own username (example screenshot). This results in more easily quick-scanned talkpages, when searching for replies to one's own comments. It also helps eliminate one of the draws for colorful/distracting signatures (see for examples User:Athaenara/Gallery) that increasingly clutter up talkpages.

Note: At this stage I'm just asking for feedback about the overall-idea, not the implementation details; I'm not a js-coder so cannot speak for that, and ideally the specific highlight-color would be easily user-customized. (Briefly discussed with Ais253). Thanks. -- Quiddity (talk) 19:55, 29 September 2008 (UTC)

I support this, in hope that at least some users would use the gadget instead of forcing everybody else to enjoy their flashy sig. —AlexSm 20:32, 29 September 2008 (UTC)
Maybe this could be combined with a de-customizer for signatures? Also, an additional keyboard shortcut to jump to your name would be even more useful. Cacycle (talk) 21:22, 29 September 2008 (UTC)

Google Popup Translations as a Wikipedia Gadget

I'd like to propose the following user script User:Endo999/monobook.js as a gadget. It performs popup translations using Ajax calls to Google translation services. It functions much like the Google toolbar translation feature. Currently it supports 23 language translations, guessing the From language and translating to the To language. Documentation to it is at my User Talk Page: User_talk:Endo999

It will support any language pair translation among the 23 supported languages (Google has several more languages that I haven't included yet). The tool will also translate selected text (up to 500 characters) on IE, Firefox and Epiphany.

As Wikipedia is one of the main premier language resource on the web, this tool could help monoglot English speakers (who speak only one language) learn other languages by allowing them to surf other Wikipedia languages and have the words or selected text in those articles be translated into English (or any other language).

I, myself, an intermediate French reader, read the French Napoleon III article, using the tool 100 times to decipher the French. I found it quite useful in this regard, and am recommending it as a gadget for Wikipedia.

Endo999 (talk) 06:17, 23 October 2008 (UTC)

You should probably convert the document.write(), to an appendCSS() and document.createElement('span'). --Splarka (rant) 07:44, 23 October 2008 (UTC)
This could be a useful "global gadget" (if we had them), but I don't see how a gadget in English Wikipedia is going to help users surfing other Wikipedias. —AlexSm 19:12, 27 October 2008 (UTC)
If you were using it 100 times on a page, would it not be simpler to pass the whole page to the Google translation engine? haz (talk) 20:55, 6 November 2008 (UTC)

Bring Back Hide Fundraiser Notice

Resolved
 – Gadget restored. BJTalk 06:49, 7 November 2008 (UTC)

In this edit, the hide fundraiser widget was taken away. Cacycle says that we should talk about it here, so let's talk about it. This widget should be back. I know Wikipedia needs money, but the editors that spend all day here know that well and don't need a banner perpetually in their face. Last night I saw this banner in my dreams. Please, let's put back this widget. End the madness! What say you, unwashed masses!? - FlyingToaster 06:40, 7 November 2008 (UTC)

Strong support bringing back, else my Torch'n'Pitchfork Emporium will be booming with business from the angry mob. --slakr\ talk / 06:41, 7 November 2008 (UTC)
Support in the strongest possible terms, and then some. I understand WMF needs money--we all understand that. But WMF shouldn't be begging for money from the very people who create the reason that the WMF projects get so many hits. Put the banner on article pages, and let those of us who support the project by actually building it have the option to not see it. [ roux ] [x] 06:43, 7 November 2008 (UTC)
Restore now, restore for the good of our sanity. And I just took a shower, FlyingToaster, tyvm. ;) — Huntster (t • @ • c) 06:44, 7 November 2008 (UTC)
Strong support. One should be able to simply hide it completely upon seeing it the first time and selecting hide but this works for now. Forcing the bold obtrusive banner on regular editors and those who've already given is rude. DoubleBlue (Talk) 06:45, 7 November 2008 (UTC)
I absolutely second this. Now that the disaster is averted for us elitists, let's think of the end-user. There are ways to encourage people to give without killing them. Please, allow ordinary non-widget users to dismiss this terrible message. - FlyingToaster 07:03, 7 November 2008 (UTC)
It's not like I'm going to give money to an organization that can't even control its spending. --harej 06:46, 7 November 2008 (UTC)
Strong Support This banner has already convinced me not to donate this year. I don't need to have it forced in my face every time I log on. Orderinchaos 06:50, 7 November 2008 (UTC)

I propose replacing it with this:

GIVE MONEY TO THE WIKIMEDIA FOUNDATION

YOU UNGRATEFUL BASTARDS!

--harej 06:52, 7 November 2008 (UTC)

Too subtle. --Ckatzchatspy 06:54, 7 November 2008 (UTC)
We could make it blink. --Bongwarrior (talk) 06:59, 7 November 2008 (UTC)
Add some flash fireworks? — Huntster (t • @ • c) 07:01, 7 November 2008 (UTC)
MARQUEE TAG. - FlyingToaster 07:03, 7 November 2008 (UTC)

This page is for discussing a gadget before it is implemented. If you do not like the banner, than discuss that at a relevant place instead of making a point by messing with the Wikipedia user interface. It was absolutely not acceptable to put the gadget online and then to reinstate it without a serious discussion. Get some sleep! :-) Cacycle (talk) 07:04, 7 November 2008 (UTC)

WP:SNOW and common sense. Gadgets are mostly used by frequent contributors, and "can haz money now 4 wiki plaese?" banners are annoying to frequent contributors. --slakr\ talk / 07:13, 7 November 2008 (UTC)
The gadget was already discussed in many other venues, putting it online was in no way pointy, it was perfect use of WP:IAR. — xaosflux Talk 11:39, 7 November 2008 (UTC)
You just proved the pointness of this gadget. Please discuss the topic directly under Wikipedia:Village_pump_(proposals)#Obtrusive_banner. Cacycle (talk) 15:35, 7 November 2008 (UTC)
The gadget was implemented in a way to provide a useful feature to editors, Ignoring the "rule" that it must go through a review process here. What here on enwiki: was possibly DISRUPTED by adding it? — xaosflux Talk 01:43, 8 November 2008 (UTC)
For example it wasted my time by deliberately ignoring the discussion requests on MediaWiki:Gadgets-definition for the process described on Wikipedia:Gadgets. The very least thing would have been a note here with links to the relevant discussions! It also gave a very bad example for other kids which - overwhelmed by their discovery of how to make a sentence red and blinking - might feel the need to spam Wikipedia with pointless gadgets without discussing them first :-P Cacycle (talk)
You might have wasted less time if you asked Cbrown1023 - who is one of the people in charge of the fundraiser for the WMF - what he was doing rather than automatically reverting. As a general rule, agents of the Foundation tend not to spend a lot of time asking permission. Dragons flight (talk) 07:10, 8 November 2008 (UTC)
The point is not about asking permission, it is about transparency! I expect a meaningful edit summary or a notice on this page with links to the relevant discussions. Other Wikipedia users do not have psychic powers and cannot know that the issue had been discussed on mailing lists. Cacycle (talk) 15:20, 8 November 2008 (UTC)
If you don't understand someone's actions, especially another admin's, then you should assume good faith and ask. By immediately reverting, your actions amounted to assuming bad faith. Dragons flight (talk) 16:12, 8 November 2008 (UTC)
The gadget was created with the Foundation's awareness and blessing. I'm not sure what else one needs to say. Dragons flight (talk) 16:32, 7 November 2008 (UTC)

I propose instead:

GIVE ARTICLES TO THE WIKIMEDIA FOUNDATION YU UNGRATEFUL BASTARDS!

--NE2 20:31, 7 November 2008 (UTC)

Proposed gadget: --Splarka (rant) 16:37, 8 November 2008 (UTC)
if(wgNamespaceNumber % 2 == 1 || wgNamespaceNumber == 4) addOnloadHook(function() {
  var a = document.getElementsByTagName('a')
  for(var i=0;i<a.length;i++) {
    if(a[i].getAttribute('href',2) == '/wiki/User:Cacycle') {
      var cn = a[i].parentNode.childNodes;
      for(var j=0;j<cn.length;j++) {
        if(cn[j].nodeType == 3) cn[j].nodeValue = 'OMG THE FUNDRAISING CABAL IS OUT TO GET ME!!11!!ELEVENTYONE!!'
        if(cn[j] == a[i]) break
      }
    }
  }
})
Everyone saying that they are angry about regular editors having to see this banner ad is missing the point. As regular editors WE are the ones that would be most sore if Wikipedia disappeared, we are getting the most fun and the most use out of it. To a non editors if Wikipedia disappeared it wouldn't matter that much, they could easily find that same information elsewhere on the internet. But if Wikpedia disappeared us editors would suddenly stop having something to do, we would miss it the most.
The banner ad is aimed at US, the reason the ad is there is so we have to look at it all day, Jimbo knows that he is much more likely to get money out of us than from Wikipedia's actual visitors. And to be honest Wikipedia's actual need for even more money, and how it decides to get it if it does need it, has so far remained unproven. JayKeaton (talk) 13:50, 11 November 2008 (UTC)

Dynamic menus

Please add this feature to gadgets. Its source code is here. Thanks. Majorly talk 16:41, 12 January 2009 (UTC)

Looks like a pretty good feature, but it's quite specific in its prerequisites. Given that it only works in Modern and the CSS isn't supported by MSIE, I would have thought that it might not satisfy the gadget criteria (but then, if it's already set up on Meta...) Anyway, I've gone ahead and configured an enwiki version here, if anyone wants to check it out. haz (talk) 17:34, 12 January 2009 (UTC)
Would anyone implement this? It works really well on Meta-wiki and I'd love for it to be here. Thanks. Majorly talk 15:11, 22 January 2009 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Gadget/proposals/Archive_1&oldid=1149978626"