Wikipedia:Gadget/proposals/Archive 2

Bookmarks for Wikipedia
I'd like to suggest a script I recently created, WikiMark, for evaluation to be added to the gadgets list. This is a very simple script that allows one click bookmarking of articles. Requires no configuration, and is comfirmed to work in Firefox, Opera and Chrome. My IE doesn't load it, but this could be a problem with my IE, so someone who uses it more should probably test & report. — Twinzor Say hi! 18:31, 13 January 2009 (UTC)
 * After some testing, the script has been confirmed to work in Firefox, Opera, Chrome and Safari. It has also been confirmed that it doesn't work on IE, but it wont cause any errors or unintended behaviour either. — Twinzor Say hi! 16:19, 15 January 2009 (UTC)

Safe edit links for Internet Explorer
While we're suggesting gadgets to add, I'd like to suggest this, which makes it safe to click on most links when editing a page in Internet Exploder - normally, the links open in the same window, and any edits made are lost; the script forces them to open in a new window. Firefox, Opera, Safari and others (AFAIK) are smart enough to save the form data, so the script ignores them. The script was written by Alex Smotrov (see discussion on his talk page; the whole thing was spurred by this VPT discussion), and I've made some minor adjustments since then. 「ダイノ ガイ 千 ？！」(Dinoguy1000) 22:31, 13 January 2009 (UTC)
 * * nudge* anyone? 「ダイノ ガイ 千 ？！」(Dinoguy1000) 18:24, 21 January 2009 (UTC)

Add the "Localize Comments" script
I've created a script which I call Localize Comments. Documentation can be found at Localize Comments. I've been working on it and tweaking it for nearly a year now, and I think that it's ready for primetime. What it does, in a nutshell, is it converts all timestamps generated in signatures, etc. (such as those from ~ ) to the user's local time. The format can be changed on by the user to "2009-01-01", "January 1, 2009" or "1 January, 2009". Here's an example input:

20:22, 14 January 2009 (UTC)

And here's the output:

Yesterday, 3:22 pm (UTC-5)

As you can see, it gives me the local time, plus it gives a relative date. Other relative date possibilities include "Today, "2 days ago", "1 month 5 days ago", "1 year, 2 months, 3 days ago", etc. The actual date will be returned if it is more than one day ago, so like 2009-01-13, last Tuesday (2 days ago), 11:50 pm (UTC-5). Also, it works for timestamps in the future, like:

00:16, 22 January 2009 (UTC)

Appears as:

2009-01-21, this Wednesday (6 days from now), 7:16 pm (UTC-5)

Future timestamps are normally used in proposals such as RfAs to give the day and time that it ends. I have tested it in several browsers, and it works, but more testing from others is also appreciated. I don't think it will conflict with any other scripts, and it certainly requires no configuration—it will determine the user's timezone by their computer's setting that gets sent to the script via JavaScript. I'd like to point out that the date is returned with a font that's 90% the normal size, because the output is a bit longer so it needs more space. The bright side is that it has nowrap, so the entire timestamp is held together and completely intact no matter how squished it gets. Also, I am open to suggestions for a better and more appropriate name, although I think "Localize Comments" gets the point across even though it might not be entirely accurate, as the script actually converts any timestamp, not just in comments. In the case where the script's output is incorrect, you can mouseover the date to get the actual date that exists on the page. Questions? Comments? Gary King ( talk ) 22:12, 15 January 2009 (UTC)
 * 'last Wednesday (6 days from now)' appears to be broken output. Algebraist 22:24, 15 January 2009 (UTC)
 * Indeed... it shouldn't be that hard to have it display "next Wednesday", should it? (but then, this could just be one of those "1 objects" issues...) 「ダイノ ガイ 千 ？！」(Dinoguy1000) 22:28, 15 January 2009 (UTC)
 * Ah; the "last" has been removed from future dates now. Timestamps for past dates have much fewer, if any, bugs than future timestamps as I rarely check future timestamps. They are only usually shown for RfAs, at least for me :) Gary King  ( talk ) 23:59, 15 January 2009 (UTC)
 * So far, I have tested on Mozilla Firefox versions 3.0.1 and 3.0.5; it seems to work fine. Is there any way to change the date format? Dabomb87 (talk) 00:00, 16 January 2009 (UTC)
 * How do you want the date format to look like? Also, regarding adding "next", I've made it show "this Saturday" instead when it is the upcoming Saturday. I'm open to suggestions on better wording, though, but I'd rather try and keep it as simple as possible. "Next" is ambiguous sometimes; personally, I use it to refer to two Saturdays from now, not the directly upcoming one. Gary King  ( talk ) 00:18, 16 January 2009 (UTC)
 * Just giving users the option to use whatever date format they want; I guess the date formats that can be used with date autoformatting, preferably month date year or day month year. Dabomb87 (talk) 00:26, 16 January 2009 (UTC)
 * Okay done; use LocalizeConfig = { dateFormat : 'mdy' }; (options are 'ymd', 'mdy', 'dmy') Gary King  ( talk ) 01:40, 16 January 2009 (UTC)
 * Nice, everything works fine now however ymd is buggy: for dates, it shows: false-01-13, last Tuesday (2 days ago), 05:56 am (UTC-6) (italics mine) . Dabomb87 (talk) 01:51, 16 January 2009 (UTC)
 * I've been using this script in IE7 (FF2 on occasion) since April 21, 2008. Sometimes I got buggy wording, but that all seems to have gone away in the recent past. I do find it very useful and can't find any current problems. §hep   •  Talk  00:54, 16 January 2009 (UTC)

- No consensus yet that this should be a gadget. Oren0 (talk) 08:32, 19 January 2009 (UTC)

If there is no opposition, could someone please add it to the list of gadgets? I think it's very useful to a general audience, more so than Friendly or Twinkle, in my opinion. :) Gary King  ( talk ) 19:03, 18 January 2009 (UTC)
 * I have installed this script and I think it's cool. I'd like to see some consensus before it's added to the list though.  Also, you should write up a page explaining what the script does and how to set any options. Oren0 (talk) 06:27, 19 January 2009 (UTC)


 * There is a very low chance that this proposal will see a consensus. There have been very few, if any, proposals on this page that have even had proper discussions (besides the fundraising one, an exception because it was a fairly urgent request that many people wanted implemented ASAP essentially). Most of the Gagdets that exist were added unilaterally by administrators; some of them only work in a single browser, like Safari which has single-digit market share. I already posted a link to here at WP:VPT, which I think is the most relevant noticeboard. I have written a documentation at Localize Comments. Gary King  ( talk ) 18:24, 19 January 2009 (UTC)
 * OK, I'm sold. If anyone cares enough about gadgets to object, they should have this page watchlisted and should have said something by now.  Before I add it, are you sure that "localize comments" is the name you want?  Localization usually refers to language and cultural differences, not time zones. Oren0 (talk) 17:54, 21 January 2009 (UTC)


 * I'm open to suggestions on the Gadget's name. I think it's important to keep the word "Comments" in the name, though, even though it's not entirely accurate—the script works on timestamps regardless of whether or not it's in a comment—but as I said, it gets the point across the easiest. Probably the most obvious name would be "Comments in Local Time", which definitely gets the point across, but I dislike the "in" as it makes the Gadget's name harder to remember and more like a description than a name. "Local Time Comments" is unfortunately not nearly as clear, though. Ultimately, "Comments in Local Time" is probably the best name.


 * Also, even though I am not an administrator (so I can't actually add Gadgets), I'll watch this page and try my best to better organize the proposals that come through here, to make the addition of Gadgets more coordinated. Something really needs to be done. Gary King  ( talk ) 17:58, 21 January 2009 (UTC)
 * ✅. "Comments in Local Time" is now a verified gadget.  Oren0 (talk) 04:45, 22 January 2009 (UTC)

Caction tool
I'd like to propose User:Haza-w/Caction tool as a gadget (script: User:Haza-w/cactions.js).

It passes the general criteria:
 * 1) It works without configuration, although configuration is possible if installed manually.
 * 2) It is compatible with all major browsers (those that support DOM, anyway...) and although it makes XMLHttpRequests by default, the script bypasses this feature if the browser does not support XMLHttpRequests.
 * 3) It is functional in all major browsers, as above.
 * 4) Not a duplicate.
 * 5) Not a collection of scripts.
 * 6) Doesn't require permissions, although adds a few extra links if the sysop flag is present.
 * 7) Only works in Monobook and Modern skins (those which include a cactions toolbar), but fails gracefully if run on a different skin.

More info on the above is available on the documentation page. haz (talk) 22:24, 19 January 2009 (UTC)


 * I've been testing this for a few days now; it is quite useful, and does not appear to conflict with the extensive list of scripts I'm currently using. If there is no objection, I will add this to the list. --Ckatz chat spy  17:55, 22 January 2009 (UTC)


 * As there has been no objection, I have added this rather useful gadget to the list. The script has been copied to MediaWiki:Gadget-Drop-down menus.js (to make the name slightly more intuitive) and the description is at MediaWiki:Gadget-Drop-down menus. The description reads as follows:"'Add page and user options to drop-down menus on the toolbar. (documentation; works in Monobook and Modern skins)'"The documentation link is still going to Haza-w's user page (User:Haza-w/Caction_tool)) as I'm not sure where the proper location for documentation is. Thanks again to Haza-w for developing this tool. --Ckatz chat spy  18:55, 3 February 2009 (UTC)

Long edit summaries
It's a little-known fact that while the edit summary box is limited to 200 characters, MediaWiki can sometimes actually accept up to 250 characters. What actually happens is the database field is limited to 250 bytes, and since some characters take up more than one byte, MediaWiki allows for a 50-byte margin.

For a while now I've been using a script that gives me a lot more precision over my edit summaries. It counts the number of bytes in my edit summary, and if possible silently keeps me from entering more than 250 bytes, no matter the number of characters I've entered. If I copy and paste a bunch of characters at once totaling more than 250 bytes, JavaScript can't detect this until it's too late, so the script warns me and disables the "Save page" button until I fix the problem.

This has been useful to me because it's allowed me to better explain myself in my edit summaries. For example, when I've made a lot of small, uncontroversial changes to an article and I'd like to briefly mention as many of them as possible in the edit summary.

The script is at User:Remember the dot/Long edit summary.js. I've tested it on Internet Explorer 6, 7, and 8, Firefox 2 and 3, Opera 9.5, and Safari 3. It works excellently in most of them, however Firefox and Safari will clip the edit summary if you click Preview. I'd like to include this as a gadget, what do the rest of you think? —Remember the dot (talk) 04:18, 21 January 2009 (UTC)


 * Do you think it would be possible to add an option to increase the height of the edit summary field when working with long summaries, so you can actually see the whole thing? Other than that, this looks really nifty and I think it would make for a good gadget. I support it. 「ダイノ ガイ 千 ？！」(Dinoguy1000) 18:22, 21 January 2009 (UTC)


 * OK, I've added it as a gadget. I'm not sure it's a good idea to make the edit summary box more than one line - at the very least line breaks would have to be changed into spaces before the form is submitted, which would take some extra work. We could however make the edit summary box as wide as the page contents box by adding


 * to MediaWiki:Common.css. Would you support that? —Remember the dot (talk) 06:22, 22 January 2009 (UTC)


 * Yeah, but it feels a bit hackish to me. Isn't there any way to force the text to wrap without inserting line breaks? 「ダイノ ガイ 千 ？！」(Dinoguy1000) 18:53, 22 January 2009 (UTC)


 * I can't think of anything short of turning it into a textarea, which would have a whole lot of other problems. -- Amalthea 22:24, 9 February 2009 (UTC)


 * Ehh, forget I asked, then. I've actually been using that CSS for awhile now, I really like it. One other request that would be nice, but is hardly a deal breaker: a characters remaining counter? 「ダイノ ガイ 千 ？！」(Dinoguy1000) 07:04, 10 February 2009 (UTC)

AJAX auto refresher
Ok, this gadget allows auto-refreshing page loads. User:Coconut-Freak/AJAX auto refresher.js. &mdash;  HK22   \ my contributions  /  (  my talk  ) 09:39, 21 February 2009 (UTC)

InterWiki Title
I wrote a new gadget which can display the meaning of each interwiki link in English by popping up a little yellow tooltip. --百楽兎 (talk) 03:53, 22 February 2009 (UTC)


 * You may be able to glean some improvements/new features from User:Alex Smotrov/iwiki.js, which is an interwiki synchro tool I use (though the synchronization parts have been down since the switch to the new API). Using this script, clicking on the "languages" header in the toolbar cycles through original language names, English language names, and the interwiki link contents. Also, I'd suggest stuffing this script into a subpage in your userspace, and you can then just link to that instead of having to copy the whole script. 「ダイノ ガイ 千 ？！」(Dinoguy1000) 18:50, 23 February 2009 (UTC)

regex framework
Gah, I nearly added m:User:Pathoschild/Scripts/Regex menu framework without asking ;-)

It adds regex functionality to the edit window; I dont see any similar tools already installed. I recommend it is placed in the "Editing gadgets" section.

It is installed on Wikisource, and I have copied the pages MediaWiki:Gadget-RegexMenuFramework and MediaWiki:Gadget-RegexMenuFramework.js from there. If this proposal is denied, they should be deleted. John Vandenberg (chat) 04:10, 24 April 2009 (UTC)
 * Due to the overwhelming support, this has been ✅ Done. John Vandenberg (chat) 09:49, 25 April 2009 (UTC)
 * It doesnt work with the modern skin. In order to avoid users reporting odd errors all over the place, this has been ! John Vandenberg (chat) 10:38, 25 April 2009 (UTC)

TinEye gadget
I have ported the TinEye gadget at Commons to en.wikipedia.org: User:Twp/tineye.js. TinEye is an image search engine. This gadget adds a "tineye" tab to the top of File and Image pages which, when clicked, performs a TinEye search on the desired image. It's a useful tool for uncovering potential image copyright violations, so I am proposing adding it as an official Wikipedia gadget.

I have tested and found it to work on both Firefox 3.0.9 and Safari 3.2.1 on Mac OS X. I do not have a Windows platform handy on which to test it on MSIE or Chrome. Because it adds a new navigation tab to image pages, it appears to work only on the Monobook, MySkin and Chick skins.

Comments welcomed. Tim Pierce (talk) 12:15, 27 April 2009 (UTC)


 * Huh, I didn't know that one. It says that their search index is still "very small". How useful is it? It's using  to add the tab, so it should be OK compatibility-wise. It should work with Modern if the compatibility function gadget is activated. I'm wondering though if it's useful enough for editors, since obviously fewer editors will search for image copyvios here than on commons. An alternative would be to just announce it at WT:WikiProject User scripts and maybe WT:Media copyright questions.  Amalthea  12:35, 27 April 2009 (UTC)


 * The search results do say that the index is "very small" when it can't find the requested image, but please also note that it says "searched over 1.04 billion images". "Very small" is a matter of degree. :-)  I ported the gadget because I was speaking with a couple of new image patrollers who seem to find the TinEye engine very useful.  Other than that, I can't speak directly to its utility for copyright patrol.  I'm intrigued by your comment; even though more and more images (maybe most?) are coming now from Commons, my understanding is that there are far more editors working copyright patrol on Wikipedia than on Commons.  I do think that offering a copyright-checking tool through the Wikipedia interface would be helpful, even if the material it checks often lives on Commons.
 * That said, I'm happy to start with giving it a field test through relevant Wikiprojects here. I couldn't find a "new images patrol" or "image copyright patrol" project but I'll certainly start with the two pages you mentioned. Tim Pierce (talk) 13:21, 27 April 2009 (UTC)


 * Well, there are probably 1.04 billion transparent one pixel images out there, so yes, it's quite subjective indeed. ;-) I certainly will try it and immediatley added it to my scripts (both here and on commons). It's a tool that I've missed for a while, and I've repeatedly checked if google image search didn't offer that some way (they must already keep hash codes of their indexed files). Anyway, I personally am just unsure whether we want such highly specialized tools in the gadgets. It's quite hard to remove one once it's listed. Let's see what others say. Amalthea  14:33, 27 April 2009 (UTC)


 * An entirely fair point. I just want to make sure it's visible to the people who can make the best use of it.  Thanks. Tim Pierce (talk) 14:41, 27 April 2009 (UTC)


 * FWIW, I've tried it on over a dozen copyrighted images thus far which I eventually found via google image search, but tinyeye didn't know any one of them. :( Is it possible that it needs the full-size image to work, and simply can't find it with a scaled version since it's using a file hashing algorithm? I haven't looked at their FAQ. Amalthea  11:52, 7 May 2009 (UTC)
 * No their database just isn't that big yet. Atm, it seems not so useful. Commons uses it to check new uploads, but even there it only has several hits per day. —Th e DJ (talk • contribs) 12:42, 7 May 2009 (UTC)

Translation Popups from Google gadget
My monobook.js file has code that successfully queries Google translation services on any word that you hover your cursor over (and in ie, firefox, chrome and epiphany any selected text you hover the cursor over). The result is that nonEnglish speakers with intermediate command of English can quickly look up words or phrases in 40 languages in any article in the English Wikipedia.

Code is at User:Endo999/monobook.js if anyone wants to try it out.

The code establishes a tab at the top of the article: "translation popups on/off". You can toggle the popups on and off this way. You can change the language at this tab as well.

An earlier version of this code (98 percent of code is the same) has been successfully running on the Spanish Wikipedia for 6 months without complaint. It seems to be used in moderate amounts by the users there.

I have tested this earlier code further and made some small enhancements to it. This is the second round for this proposal. Around 7 months ago I made it. Some people thought it was a good idea but nobody implemented it.

Endo999 (talk) 23:14, 7 May 2009 (UTC)


 * Looks nice. Not sure how useful it would be here, but why not. However some points
 * It uses a "non-free" service (though i don't think anyone will mind)
 * It is REALLY yellow
 * It visually conflicts with "title" tags when I hover links.
 * It visually conflicts with WP:POPUPS if I have both tools enabled.
 * It might be very handy if you could select a snippet of text and hover that for a translation.
 * Just some thoughts. —Th e DJ (talk • contribs) 18:32, 8 May 2009 (UTC)

Thanks for the feedback about this proposal. The google translation services are free to use. Google does not charge for it. I can change the styles (the yellow) of the popup window if people wish it. On IE, Firefox, Chrome and Epiphany you can select up to 500 characters of text, hover the cursor within it, and then the translation of the text will appear in the popup. On Opera and Safari this will not happen. I can lower the popup window a bit so that it doesn't conflict with the title tags. Just tell me and I will do it. Endo999 (talk) 20:59, 8 May 2009 (UTC)


 * I was talking about Free as freedom, not free as in gratis. Like Wikipedia and Linux are Free, whereas freeware is just gratis.
 * Also, could you add "prefixes" to your classes and IDs ? things like "userdata" are easy to duplicated. As a matter of fact, for safety reasons, you should prefix all your JS variables and functions as well (they mostly already are it seems). And I think the Safari check is only needed for Safari version before 3.0, because if something works in Chrome, it should work in Safari 3.0. They use the same rendering engine. Lowering the translation below the title tag seems like a good idea to me. I'm not sure what to do with the popups gadget conflict. Perhaps popUP, instead of popDOWN ? Just an idea. —Th e DJ (talk • contribs) 00:02, 9 May 2009 (UTC)

As per your comments I have done the following:

1) the background color of the popup is now beige. It can be set by a variable in monobook.js 2) all variables and function names now have SC prefixed to them 3) when the cursor is over a link with a title the popup now appears below the title (42 pixels lower) 4) when NavPopups are on and the cursor is over a link the popup now appears above the navpopup, that is, above the cursor. Otherwise the popup appears at the cursor as before.

Endo999 (talk) 07:00, 9 May 2009 (UTC)


 * I seem to remember that we discussed this script before. While it is useful, imho the main problem is that most users who visit enwiki from other languages projects simply will not know about this gadget. — AlexSm 19:15, 8 May 2009 (UTC)

Although this is true, with the unified logins it is not as bad as might be thought. A french member of fr.Wikipedia will now be able to log into en.wikipedia.org with his own account. And thus be able to turn on the gadget there.

My pitch for this code as a gadget is that there are 1 billion people who read English as a second language. Many of them are intermediate proficient. Tens of millions of these would use the en.wikipedia.org to read English language articles. These people could use this tool to help them along. I am an intermediate French/Spanish reader and I use the tool to read the French and Spanish wikipedias. I can read such articles when normally I would have trouble without the tool. I would have to manually use a dictionary which is a lot slower. Endo999 (talk) 20:59, 8 May 2009 (UTC)


 * Look GREAT ! I'm one of this foreign user with intermediate English (I'm French). I'm already used to such Firefox Add-ons, which exist to ease learning/reading of Japanese and Chinese ('Pera kun'). Have it in a LARGE SCALE may help a lot all foreign users. And yes : I think we are many. This would frankly need a large scale advertising campaign, especially since foreign users with intermediate English : 1. are still helpful editors (creating and expanding article with their intermediate English) ; don't find easely the good place where gadgets are ; DO NEED such tools to improve faster their English skills.
 * Important to notice : I was studing Spanish and Chinese at school, I learnt English alone, this 5 last years, using the Google toolbar. I'm now wrinting English article such China in Africa, and leading project such the Graphic Lab ;). This can help to multiply my story ! Yug (talk)  22:55, 12 July 2009 (UTC)
 * I will look at this gadget again next week. It still needs some brushing up, mostly HTML wise, but it shouldn't be too hard. to get it all cleaned up. —Th e DJ (talk • contribs) 23:14, 12 July 2009 (UTC)


 * Just tell me what you wanted changed or added in the Translation Popups tool and I will do it. If the changes are minor and you want to do them yourself, go right ahead.  As Yug has said, there are many intermediate learners of English that could use a tool like this.

Endo999 (talk) 08:18, 13 July 2009 (UTC)

Dereference
User:M/monobook.js contains a script that rips out refs, replacing [2] with [2][1][3]. Puts refs back when the save/preview/changes buttons are clicked. Currently just 'hides' the refs, which is working great for heavily-cited articles.  M  00:06, 18 May 2009 (UTC)

Gadget to increase size of diff text
Any objections to a gadget that increases the size of the diff text? I imagine it annoys a lot of people having it so small. Something like... Thoughts? --MZMcBride (talk) 23:10, 21 May 2009 (UTC)
 * Dunno, I somewhat prefer it small. Diffs are for scanning briefly, not really for reading, so I don't have a problem with the small text. Bigger text would make it hard to scan. I might use it if it were a button, though.   M </b>  02:48, 22 May 2009 (UTC)
 * Give User:Splarka/diffsize.js a try. Feedback and features optional. --Splarka (rant) 00:53, 23 May 2009 (UTC)

Ingenious (In My Opinion) Gadget Proposal
I have no qualifications, whatsoever, to create code for gadgets. However, I have an idea for a gadget that I could see almost every editer using, so I hope that a reader of this post could code the gadget. The gadget I speak of would be a spelling checker on the edit pages, so that editers could check their spelling in the edit box as they write, or, at the very least, click on a shortcut that would check the spelling in the edit box after the editer is done writing; the gadget could point out grammar or spelling errors and skip Wikipedia formatting code. I have needed this gadget for nearly every edit I have ever made, including addition of sections on talk pages. Furthermore, thus gadget does not yet exist. I believe the widespread applicability of such a gadget is obvious; Wikipedia editers just need someone to make it!

--Some Old Man (talk) 04:56, 8 June 2009 (UTC)
 * Most modern browser have a spell checker built in, all you have to do is to update your browser or switch to a browser that has it (e.g. Opera, Firefox, Safari, or Chrome). Cacycle (talk) 13:03, 8 June 2009 (UTC)
 * (ec) As most modern browsers have a built-in spell check, and people may not be posting in consistent languages (or consistent versions of the same language), I'm not sure this would be a useful gadget. Stifle (talk) 13:04, 8 June 2009 (UTC)
 * Indeed, Firefox let's you download dictionary databases for various languages and language dialects. While this is a good idea, it just isn't necessary given the built-in abilities of modern browsers. — Huntster (t • @ • c) 13:11, 8 June 2009 (UTC)

Ah yes; all very good points. I am a bit embarassed since I use a Macintosh with Safari and have noticed the spell checker, but I usually sign in on Wikipedia using my PC with Internet Explorer (maybe out of just tradition). I have heard somewhat reliable rumors about Internet Explorer being defunct anyway; I simply use it on my PC because I am so used to it. Anyway, I very much appreciate you all responding to my idea! Feel free to delete this section.

--Some Old Man (talk) 22:13, 8 June 2009 (UTC)
 * This gadget is need. I guess that just an half of people editing wikipedia are able to customize firefox, and just 20% did so for spell check. I personally didn't until 6 months ago.
 * The key principle of Wiki is that all should be provide to ease your life, 'especially' for non-geek.
 * For en.wiki, it just need one dictionary : the English one, which is available only for Free like freedom.
 * PS: gadget especially great for foreigners like me ! Yug (talk)  17:54, 13 July 2009 (UTC)


 * Firefox ships by default with spellchecking capabilities; there's no setup required unless you specifically need to alter the spellchecker's behavior (e.g. adding new languages). 「 ダイノ ガイ 千？！ 」? · <small style=font-weight:normal>Talk⇒Dinoguy1000 21:42, 13 July 2009 (UTC)

User:Lenore/autolink
I need opinions about a tool, I think it could be very useful Lenore (talk) 23:54, 12 June 2009 (UTC)
 * FYI, you should use  rather than  . The latter has a tendency to break in unexpected ways. —Preceding unsigned comment added by Mr.Z-man (talk • contribs) 02:21, 13 June 2009
 * Thanks Lenore (talk) 15:31, 20 June 2009 (UTC)

Lefteditlinks
Per discussion at VPR, I would like to enable MediaWiki:Gadget-lefteditlinks.js as an option for the users who supported the change. The code has been extensively tested at the German Wikipedia, where it is included in de:MediaWiki:Common.js, and I only added a 5px padding and made the text slightly larger. I believe that it meets all of the criteria for a gadget because: It works without configuration (in fact, it can't be configured; testing by users at VPR indicates that it functions in at least recent versions of IE, Firefox, Safari, and Google Chrome, but has a bug in Opera; it does not duplicate another gadget; it isn't a collection of scripts; it doesn't require permissions; and it works in all skins (except for "Vector", which isn't an officially usable skin yet but works via ). –Drilnoth (T • C • L) 18:34, 20 June 2009 (UTC)
 * Support (should we use this type of !voting format? nothing really seems set here yet), I can't see anything wrong with this. 「 ダイノ ガイ 千？！ 」? · <small style=font-weight:normal>Talk⇒Dinoguy1000 22:13, 22 June 2009 (UTC)
 * That format seems to be as good as any. –Drilnoth (T • C • L) 22:27, 22 June 2009 (UTC)
 * I'm not seeing any bugs with Opera 9.64 – do you know which version(s) throw errors? Haza-w.debug (talk) 10:36, 23 June 2009 (UTC)
 * User:Sswonk reported Opera problems in 9.64 and 9.63 at Village pump (proposals). User:Ed Fitzgerald also noted that it wasn't working except in article space in IE7, which I forgot to mention earlier (my bad). However, if these are the only incompatibilities the description could probably just have a notice. I haven't personally tested either (I don't have Opera, and I hadn't really noticed his note about IE). –Drilnoth (T • C • L) 14:06, 23 June 2009 (UTC)


 * Support It works fine for me in Opera 9.64, IE 8.0.6001, Chrome 1.0.154.65, and Safari 3.2.3 under Windows XP in all tested namespaces. Also, the code is so simple that it is hard to imagine that it could not work in any browser that supports J(ava)Script... It actually works in the vector skin if another loading mechanism is used as addOnloadHook does not (yet) work under vector (I could not yet figure out why). The oldEditsectionLinks variable check to turn the script off is not needed for a gadget and the lines can be deleted. In general I think we should add this as a gadget (until the developers move the edit links next to the headers by default). Cacycle (talk) 03:27, 25 June 2009 (UTC)
 * Thanks. So you think that  can be removed? I don't quite fully understand the code since I basically just stole it from de:MediaWiki:Monobook.js (actually, that's the only line that I don't understand). If that's what you mean, I can remove it. –Drilnoth (T • C • L) 03:59, 25 June 2009 (UTC)
 * Yes, it is just a mechanism to disable the script that runs by default on the German Wikipedia. Cacycle (talk) 04:04, 25 June 2009 (UTC)
 * Okay, ✅; I'll double-check it with a test momentarily. Thanks for mentioning this! –Drilnoth (T • C • L) 04:05, 25 June 2009 (UTC)
 * Looks good. –Drilnoth (T • C • L) 04:06, 25 June 2009 (UTC)

I have made some improvements to the script, please see the top of my monobook.js page. I have added user customization, made the script faster (presumably), fixed the spacer size (is now set in relative units for a better look with different heading font sizes), and have added comments to the code for maintainability. It works in Opera 9.64, IE 8.0.6001, Chrome 1.0.154.65, and Safari 3.2.3 under Windows XP. Cacycle (talk) 07:58, 27 June 2009 (UTC)
 * Comment Support this useful bit of code; my only wish is that there were some way to configure the font size as the default is too large for my taste. (I'm actually running the code straight from my monobook file, just so I can customize the size at 50%. I'd like to find a size code that isn't relative, though, as it is affected by the size of the heading level.) Thanks for all the work. --Ckatz <sup style="color:green;">chat <sub style="color:red;">spy  04:11, 25 June 2009 (UTC)
 * I'll see if I can create a variable for this so that it can be configured from monobook even when the script is installed as a gadget. I need to get some shut eye for now, but I'll try to code it tomorrow (shouldn't be too hard). –Drilnoth (T • C • L) 04:19, 25 June 2009 (UTC)
 * Comment - this has been up for a week, and the only concerns raised have been an unnecessary line of JS that wouldn't really have any effect on the gadget (and was rapidly resolved) and an expressed desire for some customizability. Since neither of these affects the gadget itself, and no other objections have been raised (and since it's been a week since this discussion was started, plus the older discussion on left edit links in general), I'm going to go ahead and add this as a gadget. 「 ダイノ ガイ 千？！ 」? · <small style=font-weight:normal>Talk⇒Dinoguy1000 03:09, 27 June 2009 (UTC)
 * Sounds good. –Drilnoth (T • C • L) 14:24, 27 June 2009 (UTC)
 * Great! Thanks. I'll update the code momentarily and the documentation later today. –Drilnoth (T • C • L) 14:24, 27 June 2009 (UTC)
 * On a long test page it was about four times faster than the previous solution (Seamonkey 1.1.17). Cacycle (talk) 17:05, 27 June 2009 (UTC)

CSS selection

 * Following up from Village pump (technical)/Archive 62

I would like to see the three CSS snippets which controls the display of coordinate as Decimal and DMS as a gadget. — Dispenser 18:26, 27 June 2009 (UTC)
 * Could you elaborate on what this does and why three more gadgets should be added to accomplish it? How many people would really use it? –Drilnoth (T • C • L) 02:28, 2 July 2009 (UTC)
 * The code allows users to set the display preference for geographical coordinates, in Decimal degrees, in Degrees Minutes Seconds (DMS), or both. Three gadgets are needed as the gadgets extension does not support options and even if it did it would likely be only for JavaScript settings.  Readers are unaware that the coordinates format can be changed nor know how to do it and adding this gadget will simply things for them.  — Dispenser 16:22, 2 July 2009 (UTC)
 * Sounds good, can you prepare the code that would allow to activate it? User:Docu 18:23, 2 July 2009 (UTC)


 * This was always my intention, when I first proposed Coord. Any progress? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 11:30, 31 August 2009 (UTC)

de:Wikipedia:Helferlein/Begriffsklärungs-Check
This is a very useful gadget which is extensively used in de-wp. It has the simple purpose to highlight links to disambiguation pages. These should normally not exist inside articles but are hard to spot, making the gadget really valuable for editors, many links are fixed due to it. Additionally, it highlights links to “redirects from misspellings” (which are not really redirects in de-wp), and individual categories can be added in one's monobook.js. I have no idea how to port this, but I miss its functionality here, so I hope it can be included in some way. -- Momotaro (talk) 09:01, 1 July 2009 (UTC)
 * By the way, the source code can be found here: de:MediaWiki:Gadget-bkl-check.js. -- Momotaro (talk) 09:08, 1 July 2009 (UTC)


 * Yes, this looks like a great idea, and I'd have ported it already, but I don't know German and don't trust computer translation to tell me everything I need to know. Any German language folk out there willing to do so? — Huntster (t • @ • c) 10:29, 1 July 2009 (UTC)
 * Wouldn't User:Anomie/linkclassifier.js make more sense? It highlights all kinds of links, not just dabs (e.g., non-free images get a special border, pages marked for deletion are shown in pink, and redirects to the current page are highlighted in green). The default CSS probably isn't the best for wide use (e.g., it highlights all redirects, a bad thing IMO), but having a more extensive highlighter might make more sense. I've found that it is very useful. –Drilnoth (T • C • L) 02:35, 2 July 2009 (UTC)
 * I didn't know that one, it sounds very good as well. The de-wp tool can also handle arbitrary categories, as I mentioned. It seems easy to add new ones:
 * This adds the category "Wikipedia:Falschschreibung" (Wikipedia:Misspelling) to the tool,  gives links to misspellings the proper CSS class,   adds the label Falschschreibung to the tooltip and   puts a small FS next to the link.
 * I don't know Wikipedia scripts, so I cannot say which one is better. Should you choose to port the German one, I can translate the help page for you (although it might need a quick style check by a native speaker afterwards). The script itself doesn't contain a lot of German, apart from the comment at the very top which says Assigns the CSS class 'bkl-link' to links to disambiguation pages, in normal article view as well as in preview. - Momotaro (talk) 09:12, 3 July 2009 (UTC)
 * I was about to port this, but it really provides just about the same functionality as the linkclassifier. Anomie's script doesn't add actual text after links it marks, only css classes, but with a modern browser that's of course no problem since you can add the text via CSS. If you want to give it a try and need help setting it up, just say the word. Cheers, Amalthea  18:58, 4 July 2009 (UTC)
 * This adds the category "Wikipedia:Falschschreibung" (Wikipedia:Misspelling) to the tool,  gives links to misspellings the proper CSS class,   adds the label Falschschreibung to the tooltip and   puts a small FS next to the link.
 * I don't know Wikipedia scripts, so I cannot say which one is better. Should you choose to port the German one, I can translate the help page for you (although it might need a quick style check by a native speaker afterwards). The script itself doesn't contain a lot of German, apart from the comment at the very top which says Assigns the CSS class 'bkl-link' to links to disambiguation pages, in normal article view as well as in preview. - Momotaro (talk) 09:12, 3 July 2009 (UTC)
 * I was about to port this, but it really provides just about the same functionality as the linkclassifier. Anomie's script doesn't add actual text after links it marks, only css classes, but with a modern browser that's of course no problem since you can add the text via CSS. If you want to give it a try and need help setting it up, just say the word. Cheers, Amalthea  18:58, 4 July 2009 (UTC)
 * I was about to port this, but it really provides just about the same functionality as the linkclassifier. Anomie's script doesn't add actual text after links it marks, only css classes, but with a modern browser that's of course no problem since you can add the text via CSS. If you want to give it a try and need help setting it up, just say the word. Cheers, Amalthea  18:58, 4 July 2009 (UTC)

I think I do need help … I added  to my monobook.js, emptied my cache, went to Special:WhatLinksHere/John_Smith, from there to British Honduras, but nothing is highlighted (both in Firefox and Internet Explorer). The same in some random new page,, where all of the ship links point do disambiguation pages. I must be doing something wrong … but what? -- Momotaro (talk) 05:48, 7 July 2009 (UTC)
 * Try clearing your cache again: I've added the styles proposed by Anomie to your stylesheet, the script doesn't do that automatically. I've copied them instead of loading them via javascript cause I imagine you might want to tweak them a little to be more like what Begriffsklärungs-Check does. Cheers, Amalthea  22:23, 7 July 2009 (UTC)
 * Of course, thank you very much, now it works! I feel a bit stupid now ... :-) Now I'll play around with the CSS classes a bit. -- Momotaro (talk) 09:31, 8 July 2009 (UTC)

Six tabs
WikiProject User scripts/Scripts/Six tabs replaces the standard page — edit this page — discussion trio with a page — edit — hist — talk — edit — hist set of tabs for easier navigation to article or talk page edit and history pages regardless of current view. Makes things go much faster. –Drilnoth (T • C • L) 02:43, 2 July 2009 (UTC)

Sidebar translate
(last one!) User:Tra/sidebartranslate.js translates interwiki links in the sidebar into English, so that instead of seeing the characters for Chinese, for example, you'll just see "Chinese". I've found this very helpful since I don't know the names of each language in the language, so this helps me quickly see what interwikis there are and which ones lead to what Wikipedia. –Drilnoth (T • C • L) 02:45, 2 July 2009 (UTC)

Red-green color blindness
Having an issue with reading the diffs myself due to red-green color blindness I've edited the style a little to make reading the diffs easier on the eyes. My redgreen.css -- Max Duchess (talk) 15:13, 19 July 2009 (UTC)

Search engine gadget
FYI, there appears to have been a discussion regarding the most recent gadget (search engine choice) at Village pump (proposals). --Ckatz <sup style="color:green;">chat <sub style="color:red;">spy  20:44, 25 July 2009 (UTC)

Should we remove vector thunks now?
Since most ids of vector are now compatible again with monobook, I think we should remove it again. In my opinion it has served it's purpose (being handy for the first deployment fase) and any scripts that are not yet compatible should be fixed. —Th e DJ (talk • contribs) 21:07, 25 July 2009 (UTC)
 * I have no objections (as long as at least the most widely used gadgets have been updated). What specific stuff does it still correct for? I know some of it was corrected by 19527 and maybe another bug report or two. 「 ダイノ ガイ 千？！ 」? · Talk⇒Dinoguy1000 10:21, 27 July 2009 (UTC)
 * It still corrects for the ones listed here. —Th e DJ (talk • contribs) 10:27, 27 July 2009 (UTC)
 * I have now removed it. —Th e DJ (talk • contribs) 13:48, 22 August 2009 (UTC)

PermissionOTRS
Could we please import commons:MediaWiki:PermissionOTRS.js? -- John Vandenberg (chat) 13:22, 6 August 2009 (UTC)
 * What browsers is it known to work in? The inline documentation only indicates testing on Firefox 2.0.0.6. 「 ダイノ ガイ 千？！ 」? · Talk⇒Dinoguy1000 21:49, 7 August 2009 (UTC)

Rounded style
User:Drilnoth/rounded.css contains a script which rounds many of the corners in the user interface and generally prettifies the sidebar, cactions, footer, etc. I don't believe that it works in IE (haven't tried it, but it uses -moz styles), but if that's mentioned I don't think that it would be too big a deal. I think that this makes pages look much better and would make more sense as a gadget then as a standard script (namely, because many users who just want visually changes might not yet understand how script importing, etc. works). –Drilnoth (T • C • L) 02:38, 2 July 2009 (UTC)
 * Have you looked into expanding support by also using e.g.  and  ? I'm not sure if all of the properties you use can be converted straight through to Webkit-proprietary and CSS3 properties, but border-radius, at the very least, will work fine (and no, it won't work in IE7 or lower - no idea about IE8, though). 「 ダイノ ガイ  千？！ 」? · <small style=font-weight:normal>Talk⇒Dinoguy1000 19:52, 2 July 2009 (UTC)
 * Webkit values for rounded corners can easily be distilled from the skin that I use User:TheDJ/milky.css which has webkit rounded corners. —Th e DJ (talk • contribs) 18:52, 3 July 2009 (UTC)
 * Ooh... I hadn't known about Webkit. I'll give it a try when I have a bit more time. Thanks! –Drilnoth (T • C • L) 22:32, 3 July 2009 (UTC)
 * I wondered why this (and Animum's) didn't work under Chrome... guess I should have looked at the code! -- King Öomie 15:27, 11 September 2009 (UTC)

Skip Toolserver Geohack
I'd like a gadget that would take me to my favorite map site instead of taking me to toolserver.org's GeoHack page where I have to scroll down each time to click on the same link I want. --Gpaper (talk) 02:28, 9 September 2009 (UTC)
 * You may wish to request someone write such a script at the technical Village Pump - this page is for seeking approval to get existing scripts made into gadgets. 「 ダイノ ガイ 千？！ 」? · Talk⇒Dinoguy1000 19:18, 9 September 2009 (UTC)
 * My mistake, thank you for showing me the correct page. --Gpaper (talk) 12:06, 11 September 2009 (UTC)

Translations Popups from Google Gadget Resubmitted
I have been asked to resubmit my proposal by TheDJ that my monobook.js be made a gadget on enwiki.

The javascript implements Google toolbar translation feature functionality on any webpage you go to on enwiki. It can be easily turned on and off (and language set) by a tab at the top of the window.

Hover the cursor over a word for 1.5 seconds and a popup appears with a translation of that word. All languages that google supports are offered. (43 at the moment)

Select text (up to 500 characters) and hover the cursor within the selected text, and the selected text will be translated within a popup window. Move the cursor again and the popup window disappears.

It was proposed four months ago and TheDJ evaluated it favorably and asked for some changes:


 * 1) repositioning of the popup window so that it does not conflict with tooltips and/or navigation popups.
 * 2) changes to the popup window
 * a) changing color to beige
 * b) taking out some extraneous text and putting an 'x' link in it.

Yug expressed strong approval of the tool, and asked for some more changes:


 * 1) weeding out all extraneous links and text
 * 2) taking out the from language (which is extraneous)
 * 3) simplifying of the text and links within the popup window (this was good advise)
 * 4) putting the pretranslated word in the popup. ie., "brother: frere"

Yug said he could use the tool everyday, and that he was more interested in the single word popup rather than the selected text feature, because he had taught himself English this way using the Google toolbar.

There are 10s of millions of intermediate English learners who regularly use enwiki who could use the tool like Yug does. He is an administrator on enwiki with the help of such tools as this.

This tool generalizes and extends the Google toolbar translation feature, which does single word translation from English to ten other languages. As good as it is, it does not currently do the other 30 languages that Google supports. English to Bulgarian, Romanian and Farsi are not supported yet. The Google toolbar also does NOT translate from French to English, Spanish to English etc (as the javascript proposed could also be used by other language wikis to allow English readers to view their wikis).

gTranslate is a Firefox addon that does allow translation for the full Google language set. It is only available on Firefox (whereas my javascript will work on IE, Firefox, Safari, Chrome, Opera and Epiphany (doesn't work on early versions of Konqueror that I have tested on, probably will work on later versions)). gTranslate takes a


 * 1) cursor position over text to be translated
 * 2) selection of text
 * 3) right click over text
 * 4) selection of context menu item to translate
 * 5) only shows 1 line of translation and hides rest with elipses: "un deux trois ..."

Single quotes in gTranslate are translated with the html code '&amp;#39;' shown instead of '.

My javascript only needs the following to translate selected text


 * 1) select text
 * 2) position cursor within selected text for 1.5 seconds
 * (translated text shows up in popup)
 * 3) move cursor away to erase popup window.

With single word translation you don't even have to select the text. The javascript has code within it that determines the word the cursor is over.

There has been quite a bit of coding put in the gadget so that large wiki files do not upset the javascript or tie it up. If the file is too big for processing (like 70,000 characters) then parts of the text will not have the popup effect enabled, but the javascript will not go into a expensive computation loop in this case.

Finally, an earlier version of this gadget has been working as a gadget on the Spanish Wikipedia for 10 months now, without incident. It does seem to be used moderately, and the implementor of the gadget told me on my talk page:


 * OK, done [1]. Thanks for the tool, is really good. Muro de Aguas (write me) 17:17, 30 April 2009 (UTC)

I am willing, if the tool becomes a gadget to include work within it that allows for the translation (and replacement of text) within input fields and textareas as well. This would allow easy communication between people who do not have a common language in the messages on people's talk pages.

Thanks for the time taken to read this proposal.

Endo999 (talk) 16:55, 2 September 2009 (UTC)


 * I have just played a bit with it. There are some minor user interface issues (missing spaces, all-caps language names, "-OFF" should better be "(off)", it is not obvious that you can configure the tool by clicking the language name...). I you want I could go over the text. Some real issues are:


 * 1) It shows a language UNKNOWN in the dropdown menu which gives a Google error message
 * 2) For me it it very annoying to have popups popping up all the time even if you do not want them. I would like to have a hot-button implemented such as Ctrl/Meta Shift so that it pops up only if you push the button and hover over a word at the same time. That way you don't have to enable/disable the gadget from the toolbar all the time.
 * 3) I suggest to give it a distinct and unique name as we already have a "popups" as a gadget.


 * With these changes I would really like to see this as a gadget. Cacycle (talk) 23:06, 2 September 2009 (UTC)

I have done the changes Cacycle wanted. It is now necessary to hold the SHIFT key down to get the popup. This is a default option. You can turn it off by going to the Translations Popups Tab and turning the option off by clicking on the link regarding it. If you do that Popups happen just by hovering the cursor over a word or selected text.

Endo999 (talk) 06:31, 3 September 2009 (UTC)
 * What do you think about giving it a distinct and unique name as we already have a "popups" as a gadget? Cacycle (talk) 02:54, 8 September 2009 (UTC)

How about 'GoogleTrans', as it is Google that does the translations. Many people do know about the Google translation services. You are welcome to change the text in the code for this.

Endo999 (talk) 08:58, 8 September 2009 (UTC)


 * Even in its beta-esque form, this tool is INCREDIBLY useful. My suggestion is to basically copy and paste the default Popups visual scheme, to alleviate the contrast, but (in Firefox 3 anyway) there's no actual popup OVERLAP, which is good. I'd also suggest case-correct before the text is piped through Google, and possibly error-catching spellcheck (google's "Did you mean...?", or a similar fast service, first suggestion) in the case of equal input/output, for talk pages.
 * That third one may be a little out there. -- King Öomie 15:16, 11 September 2009 (UTC)

The tool's name has been changed to GoogleTrans to stop it conflicting with navpopups. Thanks for the support Kingoomieiii. Your suggestions:
 * 1) I don't know how to copy and paste the NavPopups visual scheme. Someone who deals with that code would have to do that.  This tool would be used by intermediate learners of English, so they

may not run the NavPopups gadget as well. So the need to be visually consistent with navpopups may not be necessary.
 * 2+3) what is to be translated is already part of a Wikipedia webpage and so is already checked for those things such as correct spelling and case-correct.

Endo999 (talk) 20:51, 11 September 2009 (UTC)

The userscript has been moved to User:Endo999/GoogleTrans.js (tool homepage: User:Endo999/GoogleTrans, tool discussion page: User_talk:Endo999/GoogleTrans). Please change your monobook.js loader to

. Cacycle (talk) 01:15, 12 September 2009 (UTC)


 * If everybody agrees it I will add this as a gadget this weekend. Cacycle (talk) 12:32, 18 September 2009 (UTC)
 * Done! I think this is a really ambitious and useful contribution. Please feel free to report issues and suggestions on User_talk:Endo999/GoogleTrans. Cacycle (talk) 00:41, 22 September 2009 (UTC)