Wikipedia talk:Gadget/Archive 1
This is an archive of past discussions about Wikipedia:Gadget. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 1 | Archive 2 |
Way to discuss
I don't think a table is a good way to do it. We simply need a page where user would add a new section to propose and then discuss scripts to be added to Gadgets ∴ AlexSm 19:01, 4 December 2007 (UTC)
- Feel free to change the structure of the page. The table is copied from WP:US/S so as to list all existing scripts; the idea was to comment on each script to decide whether it should be included or not. That may turn out to be unworkable, though, and your idea may be better. --ais523 19:11, 4 December 2007 (UTC)
- Umm... I prefer you to do it, otherwise I would have to "sign for you" in a lot of places :) But if you feel like the existing structure is fine, we could try to continue using it ∴ AlexSm 19:56, 4 December 2007 (UTC)
Suggestion: more permissive rules
Gadgets must work in all major browsers. -> Gadgets must fail cleanly in any major browser that is not supported. (as it is, one can't even use prompt() in a script [was going to clean up my edit summary script] because IE7 blocks it).
Gadgets must not require their own source code to be edited to update them. -> this is confusing. OF COURSE you need to edit the code to add features, bugfixes, etc. Is this trying to say it has to be configurable? What needs to be configurable, exactly, in that case?
Gadgets must not be so powerful that new users using them would be likely to cause disruption by mistake. - and several more things that exclude useful stuff (not allowing sysop scripts, etc). Is there any chance at having a "power user" interface that lets you use any page as a gadget?
Another problem is that popups (currently the only one), twinkle, etc, have been taken away from people for disruption. This would mean they logically cannot be gadgets, unless there is a way for an admin to disable a user from using a particular gadget.
Something else that would be nice would be a way to load a framework (e.g. Prototype) that scripts can then use - either for my own userscript, or for a gadget using a kind of dependency system.
—Random832 19:28, 4 December 2007 (UTC)
- The "source code" rule was confusing to me as well. And popups indeed seem to be a powerful tool that's already included. As for "major browsers", that probably means IE6/7, Firefox 15/2, Opera 9 and Safari 3 for Windows? ∴ AlexSm 19:56, 4 December 2007 (UTC)
- I don't see why this (must work in all browsers) is needed. TW should be an option (!) - just make note that it's not for IE users. If they select it and their computer explodes, that's their own fault
- Also, admin scripts (etc) should be allowed too. If users try installing them, and get errors at every turn, that's their own fault. Just make note that it's an admin-only script in the description. – Mike.lifeguard | @en.wb 02:33, 5 December 2007 (UTC)
The source code rule was intended to exclude scripts like User:ais523 non-admin/adminrights.js, where the list of admins is hard coded and I update it every now and then. It could probably be worded more clearly. --ais523 10:05, 5 December 2007 (UTC)
Gadget's Configuration
- For stuff like popups and Twinkle, perhaps it would be possible to add a new special page only accessible by administrators that allows disabling of gadgets that users are using abusively. FunPika 19:59, 4 December 2007 (UTC)
- That is true, this would make it impossible to stop people abusing scripts. Also: popups has several configuration options. What to you propose doing about that? There is also a small bug, which I've asked AmiDaniel to look into. Prodego talk 20:53, 4 December 2007 (UTC)
- See MediaWiki talk:Gadgets-definition. Gadgets can still be configured via the user's monobook.js page. Also, rule 1 only applies to gadgets that REQUIRE configuration to function. If a gadget's configuration is OPTIONAL then it is just fine. FunPika 21:04, 4 December 2007 (UTC)
- I'm not talking about rule 1, I am the one who enabled popups! I wanted to know if anyone had any ideas on how to make people aware of the configuration options. —Preceding unsigned comment added by Prodego (talk • contribs) 21:06, 4 December 2007 (UTC)
- Can't you add a description to the title of gadgets? Maybe something in the description would help. FunPika 21:10, 4 December 2007 (UTC)
- Yes, though that is where that bug is :). One more problem - Navigation popups (and nearly every other script) require the use of the monobook skin. We should be able to only show scripts on the gadgets list if users have certain rights or a certain skin. Prodego talk 21:12, 4 December 2007 (UTC)
- Disregard that, I tested in CologneBlue, which is the only non-monobook based one. Prodego talk 23:27, 4 December 2007 (UTC)
- As far as I remember, there are 4 monobook-like skins: monobook, myskin, simple, chick, and 3 older skins standard, cologneblue and nostalgia that are "not compatible": they have different blocks, classes and ids ∴ AlexSm 00:01, 5 December 2007 (UTC)
- Disregard that, I tested in CologneBlue, which is the only non-monobook based one. Prodego talk 23:27, 4 December 2007 (UTC)
- Yes, though that is where that bug is :). One more problem - Navigation popups (and nearly every other script) require the use of the monobook skin. We should be able to only show scripts on the gadgets list if users have certain rights or a certain skin. Prodego talk 21:12, 4 December 2007 (UTC)
- Can't you add a description to the title of gadgets? Maybe something in the description would help. FunPika 21:10, 4 December 2007 (UTC)
- I'm not talking about rule 1, I am the one who enabled popups! I wanted to know if anyone had any ideas on how to make people aware of the configuration options. —Preceding unsigned comment added by Prodego (talk • contribs) 21:06, 4 December 2007 (UTC)
- See MediaWiki talk:Gadgets-definition. Gadgets can still be configured via the user's monobook.js page. Also, rule 1 only applies to gadgets that REQUIRE configuration to function. If a gadget's configuration is OPTIONAL then it is just fine. FunPika 21:04, 4 December 2007 (UTC)
- That is true, this would make it impossible to stop people abusing scripts. Also: popups has several configuration options. What to you propose doing about that? There is also a small bug, which I've asked AmiDaniel to look into. Prodego talk 20:53, 4 December 2007 (UTC)
Restrictions
- (in response to first two comments in section above) One way to disable the scripts selectively for users would be to put in a line of code into the script that checks wgUserName against a blacklist of users that can't use that particular script, and make the script refuse to function if the name matches. Tra (Talk) 21:25, 4 December 2007 (UTC)
- I was thinking about that, but that creates a whole new level of bureaucracy. It wouldn't be able to be as informal as it is now. Prodego talk 21:30, 4 December 2007 (UTC)
- To avoid putting the blacklist in one central location with an associated bureaucracy, another option would be to let the script support setting a variable in the user's monobook.js that triggers the script to not function. Tra (Talk) 21:45, 4 December 2007 (UTC)
- Another option would be to warn and then block users for their actions, no matter what tools they were using ∴ AlexSm 22:01, 4 December 2007 (UTC)
- I agree with that (but, then, my understanding is my position, being that users, rather than tools, should be held responsible for their own actions, is a bit extreme) —Random832 22:08, 4 December 2007 (UTC)
- Warn/block is a perfectly good way of dealing with misuse; after all, some people misuse 'edit this page' rather than a script. It would be nice to have technical protections too, though, such as a 'kill switch' that could be added to someone's monobook.js. --ais523 10:04, 5 December 2007 (UTC)
- Someone can just remove the kill switch unless you can protect monobook.js pages to prevent the abusive user from removing it. FunPika 10:59, 5 December 2007 (UTC)
- Even if monobook.js was protected, they could still refuse to press Ctrl + F5 to update their cache or they might be able to convert the script to, say, a Greasemonkey script which could not be controlled by admins. It probably would be simplest to use warn/block since that's harder to get around. Tra (Talk) 16:48, 5 December 2007 (UTC)
- Someone can just remove the kill switch unless you can protect monobook.js pages to prevent the abusive user from removing it. FunPika 10:59, 5 December 2007 (UTC)
- Another option would be to warn and then block users for their actions, no matter what tools they were using ∴ AlexSm 22:01, 4 December 2007 (UTC)
- To avoid putting the blacklist in one central location with an associated bureaucracy, another option would be to let the script support setting a variable in the user's monobook.js that triggers the script to not function. Tra (Talk) 21:45, 4 December 2007 (UTC)
Suggested gadget: HotCat
I suggest Commons:MediaWiki:HotCat.js, which is a very handy helper for manipulating categories of pages. It is already a gadget at Commons. See also Image:HotCat.png which shows the extra controls on cats that it provides as well as an example of adding a new cat, with autocomplete on category names. I'm not at all sure how exactly this page is supposed to work to make new suggestions. I just know that I use HotCat all the time, and it is very powerful. One caveat is that it may be too powerful for newbies, you can add a lot of categories pretty easily (but you can the old way too if you know what they are). HotCat is by Magnus Manske, a very prolific tool developer. ++Lar: t/c 23:59, 5 December 2007 (UTC)
- It seems to depend somewhat on other script at Commons; likely a good idea, but someone will need to adapt it to an enwiki-usable script first. --ais523 12:56, 6 December 2007 (UTC)
- I have a port of this script for over a week now btw. User:TheDJ/Gadget-HotCat.js. It hasn't been thoroughly tested enough to add to Gadgets just yet I think, but I thought it might be useful if people reading this page knew about it. If people are interested in testing, I can still use some feedback when it comes to compatibility with versions of IE, and earlier versions of Opera and Firefox. If anyone cares to help, just drop me a line on my talkpage. --TheDJ (talk • contribs) 01:17, 11 March 2008 (UTC)
Comments regarding disruptive users
There are several views above and elsewhere on how to deal with disruptive editors using Gadgets, or other scripts, and what technical controls are required to remove these from someone. IMHO, figuring that out is not the best use of our time, as we already have a solution, blocking. — xaosflux Talk 04:49, 7 December 2007 (UTC)
- The same could be said for disruptive use of monobook.js, but often the solution used there is to remove the scripts and protect the file. —Random832 17:19, 7 December 2007 (UTC)
- If users are violating policies through scripts, the solution is to block, after appropriate warnings. Superm401 - Talk 17:30, 4 March 2008 (UTC)
Admin Gadgets
- Section moved from MediaWiki talk:Gadgets-definition
Well, WP:BRD. I recently boldly imported and linked a set of protection tools (diff) that would be mostly useful for sysops. Was reverted, so lets discuss having Gadgets that are primarily useful to admins on here, so far I've got:
- Pros
- Using Gadgets instead of custom monobooks allows for the use of a single stable version
- Ease of use, not all admins know the ins and out of their .js files
- Cons
- All features of scripts may not useful for all editors
- Notes
- Related projects making use of gadgets (commons:, fr:) have been successfully in using these (though notably de: has not).
- Please comment here. Thank you! — xaosflux Talk 04:20, 7 December 2007 (UTC)
- I totally agree with AmiDaniel: "Admins should hopefully be competent enough to edit their own monobooks". Also, you cat't compare en.wp and Commons, since the proportion of administrative work on Commons is much higher. P.S. Please note that another related discussion is taking place at Wikipedia talk:WikiProject User scripts/Gadgets ∴ AlexSm 04:39, 7 December 2007 (UTC)
- It's not a matter of "can admins edit their own js" (probably yes, though I'm not sure we can assume that) but rather the fact that this allows enable/disable instead of always-on (unless you rack up tons of edits enabling and disabling stuff in your monobook. There are several tools that should be easily turned off, and always fiddling with monobook increasing the number of edits is a chore that this extension seems designed to circumvent. FYI, Duesentreib is (probably) going to add a feature so admin (etc) tools are only shown to those who are allowed to use them. Currently, the description just says "If you're not an admin, this will not work for you so don't bother." – Mike.lifeguard | @en.wb 06:31, 7 December 2007 (UTC)
- Can you please point out which tools need to be turned off and on on a regular basis? Nonetheless, there is another solution: make Myskin look like Monobook, put the scripts into your myskin.js, switch skins when necessary. This approach might be even more convenient, since you can have
...?useskin=myskin
links ready for a quick one-time script usage ∴ AlexSm 17:04, 7 December 2007 (UTC) - Until devs implement "hide admins gadgets" in MediaWiki (I saw "remind me in 2 months" comment on IRC), maybe we can hide that section with CSS and then display it via MediaWiki:Sysop.js. I think I'll try that on another project... ∴ AlexSm 17:04, 7 December 2007 (UTC)
- Can you please point out which tools need to be turned off and on on a regular basis? Nonetheless, there is another solution: make Myskin look like Monobook, put the scripts into your myskin.js, switch skins when necessary. This approach might be even more convenient, since you can have
- It's not a matter of "can admins edit their own js" (probably yes, though I'm not sure we can assume that) but rather the fact that this allows enable/disable instead of always-on (unless you rack up tons of edits enabling and disabling stuff in your monobook. There are several tools that should be easily turned off, and always fiddling with monobook increasing the number of edits is a chore that this extension seems designed to circumvent. FYI, Duesentreib is (probably) going to add a feature so admin (etc) tools are only shown to those who are allowed to use them. Currently, the description just says "If you're not an admin, this will not work for you so don't bother." – Mike.lifeguard | @en.wb 06:31, 7 December 2007 (UTC)
- Addressing AmiDaniel's points [1] in turn. "Most users will have no use for them nor will they know what they are" would only be a reason to disallow admin-only gadgets if all users were being forced to use all gadgets. Unsurprisingly that's not the case. Admin-only scripts are clearly marked as such and if a user has no use for one or doesn't know what it does then they simply don't switch it on. There are admin-only scripts listed on WP:US/S which some people will have no use for and nobody will be alarmed if the gadgets page is the same.
Whether admins are competent enough to edit their monobooks is just irrelevant; "sysop" is not a position acquired on the basis of technical ability and does not grant nor require any competence with javascript. Disallowing admin gadgets on the gounds that they should be able to manage without them being in Special:Preferences is just silly given that (a) many can't, and (b) there's no particular reason they should have to. – Steel 13:27, 7 December 2007 (UTC)- I've had a look and 70% of admins have a monobook.js so most do know about userscripts but there is a sizable minority that have not used a monobook.js. Also, I've tested the script and when it is used on a non-admin account, it adds the tag without actually protecting the page, which isn't really acceptable so the script would need to fail gracefully if used by a non-admin.
Additionally, it would be possible for a malicious user to direct an admin to a link likeTra (Talk) 17:54, 7 December 2007 (UTC)http://wiki.riteme.site/wiki/User:Tra/Sandbox?action=edit&jsaction=pp-semi-small
which would cause the admin to semi-protect the page unintentionally (or fully protect or unprotect it, depending on the link), which could cause problems especially if the script was widely used.- Actually those links (
?action=edit&jsaction=pp-semi-small
) are not meant to automatically protect (or unprotect) pages if an admin clicks them; they are supposed to only add the tag. I agree that there could be problems if the links could cause admins to accidentally (un)protect pages, but as it stands the most a malicious user could do is cause an admin to add a small lock icon to a page (the script prompts admins before it adds a regular tag). In fact, I mentioned on my talk page earlier that there are a few improvments I'd like to make to the script should it be added to Gadgets and one of them is related to this. On a side note, objections to my protection script should perhaps be kept separate to discussion of admin gadgets in general. – Steel 18:20, 7 December 2007 (UTC)- It is a great script and I'm sorry about the mistake with the actual protection of pages; I probably should have looked closer. Regarding my other comments, whilst I did apply them to your script, I would also mean them in a more general sense, since any script would need to fail gracefully if it doesn't have the right permissions/browser/settings enabled etc. I'd say this is more important for scripts in the preferences since people are less likely to know exactly what they are enabling than when they add javascript code to their monobooks. Tra (Talk) 21:40, 7 December 2007 (UTC)
- Yeah. I've thrown the sysop requirement from common.js into my script for good measure. – Steel 13:35, 12 December 2007 (UTC)
- Mmm, too much confusion. Let the admins, who hopefully know their way around a monobook add it themselves. Prodego talk 00:41, 13 December 2007 (UTC)
- I don't see what the problem is, as long as the section is clearly marked, letting people know that THESE WONT WORK if you ae not +sysop. — xaosflux Talk 01:26, 13 December 2007 (UTC)
- Mmm, too much confusion. Let the admins, who hopefully know their way around a monobook add it themselves. Prodego talk 00:41, 13 December 2007 (UTC)
- Yeah. I've thrown the sysop requirement from common.js into my script for good measure. – Steel 13:35, 12 December 2007 (UTC)
- It is a great script and I'm sorry about the mistake with the actual protection of pages; I probably should have looked closer. Regarding my other comments, whilst I did apply them to your script, I would also mean them in a more general sense, since any script would need to fail gracefully if it doesn't have the right permissions/browser/settings enabled etc. I'd say this is more important for scripts in the preferences since people are less likely to know exactly what they are enabling than when they add javascript code to their monobooks. Tra (Talk) 21:40, 7 December 2007 (UTC)
- Actually those links (
- I've had a look and 70% of admins have a monobook.js so most do know about userscripts but there is a sizable minority that have not used a monobook.js. Also, I've tested the script and when it is used on a non-admin account, it adds the tag without actually protecting the page, which isn't really acceptable so the script would need to fail gracefully if used by a non-admin.
- I totally agree with AmiDaniel: "Admins should hopefully be competent enough to edit their own monobooks". Also, you cat't compare en.wp and Commons, since the proportion of administrative work on Commons is much higher. P.S. Please note that another related discussion is taking place at Wikipedia talk:WikiProject User scripts/Gadgets ∴ AlexSm 04:39, 7 December 2007 (UTC)
It is not good to put in buttons all but the most experienced users (who can do this on their own) can't use. Prodego talk 01:39, 13 December 2007 (UTC)
- Because... – Steel 16:54, 14 December 2007 (UTC)
- It is confusing. People did ask why nothing happened for them, and admins know how to do this themselves. There is no gain, and this causes confusion. Prodego talk 23:19, 14 December 2007 (UTC)
- Who was confused? By what were they confused? Is this on-wiki anywhere? Can we not be so vague? And yes, there are gains; two of them are listed at the top of this section. More could be added (all the benefits of having gadgets in general also apply to admin-only gadgets). Of course, this is a moot point if Alex's suggestion below is implemented. – Steel 00:55, 15 December 2007 (UTC)
- It is confusing. People did ask why nothing happened for them, and admins know how to do this themselves. There is no gain, and this causes confusion. Prodego talk 23:19, 14 December 2007 (UTC)
Why don't you try to hide it as I suggested above? (<div id=adminsGadgets style="display:none">, then show through MediaWiki:Sysop.js) ∴ AlexSm 00:19, 15 December 2007 (UTC)
- You can apply it to the titles and the description, but not the section or the button. As for as the pros: we already have stable versions of scripts, which are loaded by each users monobook. (see how popups work) And any admin who doesn't know how to use their monobook, and about what scripts are, should question whether they actually know what they are doing, since these pages are very very commonly known, perhaps on the level of knowledge of policy pages. Prodego talk 02:47, 15 December 2007 (UTC)
"Rules"
I went bold and rewrite the "rules" for gadgets, though I don't know if this page still is the "official" gadget page, there are so many now. →AzaToth 02:27, 21 January 2008 (UTC)
- "Should work" in rule 2 is an ambiguous term. It is an absolute requirement that a script is compatible with all major browsers in the sense that they do not break anything or terminate with error messages. I do not see an absolute requirement for full functionality in all browsers.
- There are widely used and powerful tools like wikEd which are compatible with, but not yet fully functional under MS-IE. As long as a tool is suited as a gadget and is functional in a major browser I do not see problems - as long as the browser requirement is clearly marked. This interpretation of "must work" as "must be compatible, but not necessarily fully functional" is also in line with the earlier discussion above ("must fail cleanly"). It would also be in line with the other language Wikipedias and Wiktionaries which have already made browser-specific tools like wikEd into gadgets. Therefore, I have clarified the guideline accordingly.
- I think it would be better to say that they should work, and if they are known to not work in an major broswe, then they must be specified. →AzaToth 16:52, 21 January 2008 (UTC)
- To disambiguate the word "work" I had changed it into:
- Gadgets must be compatible with all major browsers and must not terminate with errors.
- Gadgets should be functional in most major browsers (cross-browser compatibility). Exceptions must be clearly stated.
- Сасусlе 04:02, 22 January 2008 (UTC)
- Number one may require utilizing non-standard constructs, and might be bad imo. →AzaToth 05:30, 22 January 2008 (UTC)
- It is meant to prevent messed up pages and irregular behavior (and the user irritation and service requests) caused by scripts crashed in the middle of their job. If it is too difficult to make a script fully cross-browser compatible it would simply require a browser check at the start or a test for critical methods before they are used. We might provide a browser check in a library to all scripts. Сасусlе 13:12, 22 January 2008 (UTC)
- Wouldn't it be simpler to say that the script should be JavaScript 1.6 compliant, unless noted. Personally I don't think there should be checks for like "document.all", as it's pretty ambigious, and non-standard. Personally I dislike to polute scripts with custom browser detection scripts, just to take care of people that doesn't care to read. →AzaToth 16:09, 22 January 2008 (UTC)
- As long as you use
addOnloadHook()
, you don't have to worry about really old browsers, sincerunOnloadHook()
checks fordocument.getElementById && document.getElementsByTagName
(see wikibits.js) ∴ AlexSm 16:20, 22 January 2008 (UTC)
- As long as you use
- Wouldn't it be simpler to say that the script should be JavaScript 1.6 compliant, unless noted. Personally I don't think there should be checks for like "document.all", as it's pretty ambigious, and non-standard. Personally I dislike to polute scripts with custom browser detection scripts, just to take care of people that doesn't care to read. →AzaToth 16:09, 22 January 2008 (UTC)
- It is meant to prevent messed up pages and irregular behavior (and the user irritation and service requests) caused by scripts crashed in the middle of their job. If it is too difficult to make a script fully cross-browser compatible it would simply require a browser check at the start or a test for critical methods before they are used. We might provide a browser check in a library to all scripts. Сасусlе 13:12, 22 January 2008 (UTC)
- Number one may require utilizing non-standard constructs, and might be bad imo. →AzaToth 05:30, 22 January 2008 (UTC)
- To disambiguate the word "work" I had changed it into:
- I think it would be better to say that they should work, and if they are known to not work in an major broswe, then they must be specified. →AzaToth 16:52, 21 January 2008 (UTC)
Merge
I propose we merge this page into Wikipedia:Gadgets →AzaToth 02:32, 21 January 2008 (UTC)
- I have moved Wikipedia_talk:WikiProject User scripts/Gadgets here as part of the suggested merge. I have also moved the "rules" from Wikipedia:WikiProject User scripts/Gadgets to this project page (Wikipedia:Gadgets). Сасусlе 03:58, 21 January 2008 (UTC)
- I have moved Wikipedia:WikiProject User scripts/Gadgets to Wikipedia:Gadget/evaluation and changed the current project page accordingly. I hope that makes sense... Сасусlе 04:15, 21 January 2008 (UTC)
Edittop fixes
Please see MediaWiki talk:Gadget-edittop.js for suggested fixes to EditTop gadget ∴ AlexSm 21:06, 21 January 2008 (UTC)
What is the preferred way to use scripts?
Is there a preferred method for using scripts that are available as gadgets? For example, I've been using "popups" for quite some time through my monobook.js file. It works well, no complaints, etc. However, I'm just curious if there is any advantage in terms of script performance, server load, etc. to remove that call and use the option under "Preferences:Gadgets"? Thanks in advance. --Ckatzchatspy 21:30, 27 February 2008 (UTC)
- I don't know about performance, but what I do know is that if you use gadgets, you get what the script provides: there's no way (AFAIK) to customize the script. With monobook.js (and other skins) you can customise the script to your heart's content. Harryboyles 03:03, 28 February 2008 (UTC)
- In general, it should be possible to customize gadget scripts on your monobook.js page. There is also no difference in server load etc., it is simply an easier way to install and uninstall these scripts. Сасусlе 05:32, 5 March 2008 (UTC)
Differences for users: 1) gadgets are easier to install, 2) gadgets are executed in all skins. For scripts developers: gadgets are called before site JS/CSS files. —AlexSm 15:57, 5 March 2008 (UTC)
Issue with the Article Quality gadget
- OS: Ubuntu Linux 7.10 (andLinux kernel)
- Browser: Firefox 2.0.12
- Skin: "Modern"
Whenever I view the main page, the words "Main Page" appear, which is a problem of itself, but they appear in black, as opposed to the normal white that modern-skinned pages usualy do. When I purge the server cache, the problem goes away, but if I go to another page and back it changes back to black. Clearing my browser cache did not fix the issue. Same issue occurs on other pages. ffm 00:02, 11 March 2008 (UTC)
- Ugh, the modern skin is awful when you are used to the other. I am lost :-D I had to clear my cache several times in several pages until it got working (but I guessed it was because I had a link to the script in my monobook before). When I go to the Main Page, it indeed appears white for a second, then turns black. Purging Wiki cache of the page makes it white until the next time you go there. However, I can't reproduce it in other pages. -- ReyBrujo (talk) 01:00, 11 March 2008 (UTC)
- Ah, wait, I think there is a bug here. Halo 2 is a featured article, but if you check this link, it appears as unassessed. Unassessed articles in the main space appear with black font. So, there are two bugs so far: the script should consider the color of different skins (black is the default in the classical, but white in the modern), and we should check why the Halo 2 article appears as unassessed. Thanks for reporting this. -- ReyBrujo (talk) 01:07, 11 March 2008 (UTC)
- Personaly, I find monobook a bit wasteful of space, and while Modern isn't perfect, I like it more. ffm 16:11, 11 March 2008 (UTC)
- I'm going to try and fix the bug now. ReyBrujo, I followed the link you provided and it worked in both the Modern and Monobook skins; Halo 2 is appearing featured as it should for me. Firefoxman, I'm using the same browser as you, and I'm not seeing the words "Main Page" appear in monobook. In modern, I'm getting the same issue with black color, which I'm just about to fix. Rey, could you make the change to the gadget once I change my userspace version? I can't edit the gadget version since it's in the MediaWiki namespace. Pyrospirit (talk · contribs) 23:40, 11 March 2008 (UTC)
- No matter whether I use as gadget or script, it says it is unassessed for me. Right now the script does not display page title (guess you are working with a white font for the page title). Wish others could try the diff to see if it is happening for others. And just leave a message here once you are finished and I will apply the changes. You could also try editing the talk page of the MediaWiki page with the change request. -- ReyBrujo (talk) 00:50, 12 March 2008 (UTC)
- I'm going to try and fix the bug now. ReyBrujo, I followed the link you provided and it worked in both the Modern and Monobook skins; Halo 2 is appearing featured as it should for me. Firefoxman, I'm using the same browser as you, and I'm not seeing the words "Main Page" appear in monobook. In modern, I'm getting the same issue with black color, which I'm just about to fix. Rey, could you make the change to the gadget once I change my userspace version? I can't edit the gadget version since it's in the MediaWiki namespace. Pyrospirit (talk · contribs) 23:40, 11 March 2008 (UTC)
- Personaly, I find monobook a bit wasteful of space, and while Modern isn't perfect, I like it more. ffm 16:11, 11 March 2008 (UTC)
Clock - peer review conflict
Can anyone help me with a conflict between one of my Gadget selections on Special:Preferences and the peerreview in my monobook. the Wikipedia:Help_desk#peer_review_-_clock_conflict (posted April 6)? Since this is a low traffic page and a response may take some time, please respond at my talk page.--TonyTheTiger (t/c/bio/WP:CHICAGO/WP:LOTD) 15:07, 7 April 2008 (UTC)
wikEd no longer available as a gadget?
I signed in today and noticed that the wikEd edit box was no longer working and wikEd doesn't show up in the Gadgets list anymore. Anyone know what happened? -Clueless (talk) 21:38, 9 April 2008 (UTC)
- This edit removed it after discussion at Wikipedia:Village pump (technical)#Improved diff gadget problem, although I don't see why Prodego removed wikEd, which explicity said "...for Firefox", and failed gracefully in other browsers. —AlexSm 23:00, 9 April 2008 (UTC)
- Agreed, wikEd is not wikEdDiff. I would have no objection to it being restored. --TheDJ (talk • contribs) 23:15, 9 April 2008 (UTC)
- Thank you both, and seconded. I love that thing. What would the proper procedure be for trying to get it restored? -Clueless (talk) 23:28, 9 April 2008 (UTC)
- Wow, I was just raving about how great that the WikEd Gadget is, and then noticed that it was gone, heh. Regardless of whether or not it's put back, perhaps it might be wise to link the Gadgets page to here, or at least mention the WikEd removal, to avoid confusion? --Elonka 03:04, 10 April 2008 (UTC)
- Thank you both, and seconded. I love that thing. What would the proper procedure be for trying to get it restored? -Clueless (talk) 23:28, 9 April 2008 (UTC)
- Agreed, wikEd is not wikEdDiff. I would have no objection to it being restored. --TheDJ (talk • contribs) 23:15, 9 April 2008 (UTC)
- I have added wikEd back and have asked Prodego to explain his not discussed changes here. Сасусlе 05:16, 10 April 2008 (UTC)
- Yay! Many thanks :) -Clueless (talk) 07:06, 10 April 2008 (UTC)
Picture Popups
I'd like to suggest the adoption of User:Zocky/Picture Popups. It provides DHTML popups with the largish picture, licensing information, and it integrates very naturally into the monobook interface and style. What needs be done to get this as a gadget? — Dispenser 00:03, 14 April 2008 (UTC)
- I'd say it has to be made cross-browser first. After all, it's not as complex as wikEd or Twinkle. P.S. By the way, Wikipedia:Gadget/proposals. —AlexSm 00:09, 14 April 2008 (UTC)
"must be discussed first" - ick
I removed that clause. There are a lot of Mediawiki pages that are much more visible than the gadgets list, but no rule that changes to them have to be discussed. It's just bureaucracy to require that, regardless of obvious merit or lack of controversy, any change has to be discussed first. If an admin messes around and breaks things, I expect they will be advised in strong terms to stop doing so. But admins who don't mess up should be free to go about their business. — Carl (CBM · talk) 03:29, 23 April 2008
- The removed new entry was:
- 8. Gadgets must be discussed on Wikipedia:Gadget/proposals before adding them
- I felt that this was merely codifying the current practice which was more or less consensus on these pages. It actually makes much sense in terms of transparency and getting a second opinion from users experienced with userscripts. It is very obvious from the recent controversial additions that such a peer review process is dearly required. This is very similar to editing the Main page or system messages which must/should be discussed before actually applying the changes. Сасусlе 04:11, 23 April 2008 (UTC)
- Most of the time there is very little discussion when system messages (i.e. Mediawiki pages) are edited. Someone makes an editprotected request, and if it seems reasonable it's just done. Or an admin notices a problem and fixes it. Only if there is actually a concern is discussion necessary. Also, unlike many system messages, the gadgets list isn't going to be cached by google or seen by IP users - there is very little risk from an edit to the gadgets page. — Carl (CBM · talk) 04:16, 23 April 2008 (UTC)
- Yes, CBM is right.
- Cacycle: Well, before you add a rule that you call a "guideline" you perhaps should first discuss it on its talkpage, especially if the rule itself says "first discuss, then add".
- And the only controversy surrounding those new gadgets so far was from one person, you. You didn't like that they "clogged up the preferences" and you removed them. I don't know what why you feel they "clogged up the preferences" since that can be interpreted in at least two ways. I have written a question for you about that over at Wikipedia:Gadget/proposals.
- --David Göthberg (talk) 06:51, 23 April 2008 (UTC)
- I thought I had made it quite clear that the reason for removing the gadgets was NOT that I did not like them (I actually support one, see here). The only reason is that the gadgets had been added without adequate discussion and review. Please also note that there is a fundamental difference between changing the wiki system through the addition of gadgets on the one hand (special precautions and regulations needed here) and article pages discussing this process on the other hand (normal Wikipedia conventions apply here). See also my longer comment below. Сасусlе 02:37, 25 April 2008 (UTC)
- Gadgets are different as they create something new. So when you add a gadget some people start using it, so it's not nice to remove it later. That's why it's much better to discuss first. Also, with your approach we now have things like MediaWiki:Gadget-DejaVu Sans, which is what ... experimental (?) and only for Safari users (?) ... —AlexSm 14:12, 23 April 2008 (UTC)
- AlexSm: Well, it is very hard to discuss when no one is responding. I wrote up a suggestion over at Wikipedia:Gadget/proposals#Tighter page top tabs in MonoBook, complete with code example and explanation. But I didn't get a single reaction for some days. So in the end I added a smaller simpler gadget to see how it worked. (A simple gadget that works in all browsers and all skins I have tested it in.) And then I did get one response from one single user, that is Cacycle came along and removed my gadget and the "addsection-plus" gadget that was not added by me. By the way, the "addsection-plus" gadget was discussed and approved at the village pump. And then Cacycle promptly wrote up that rule number 8 above, after he had removed the gadgets. I have still not gotten any other "discussions" about the gadgets I suggest over at Wikipedia:Gadget/proposals, instead I get these arguments over procedure.
- And I have announced the gadgets over at two of the village pumps too and asked people to come to Wikipedia:Gadget/proposals. Those village pumps were the places were the need for these gadgets became apparent. But I am still not getting any discussion. So who or what exactly am I supposed to discuss with?
- --David Göthberg (talk) 14:53, 23 April 2008 (UTC)
- Sorry, I guess two days wasn't enough time for me to answer :) Anyway, I've answered now at Wikipedia:Gadget/proposals#Tighter page top tabs in MonoBook. —AlexSm 17:20, 24 April 2008 (UTC)
I've altered the message at the top of Mediawiki:Gadgets-definition to declare WP:VPT as the venue for discussion. --Random832 (contribs) 16:53, 24 April 2008 (UTC)
- We are not in a hurry and can wait until we find consensus here, therefore I have reverted your premature change. Сасусlе 23:38, 24 April 2008 (UTC)
- I think a separate "proposals" page was a better idea. There is just too much traffic on VPT, and we'd also loose the archives of old proposals. Maybe we can we reach a compromise at "announce at WP:VPT, discuss at Wikipedia:Gadget/proposals"? —AlexSm 17:20, 24 April 2008 (UTC)
- I don't follow; the village pump is archived, so records aren't lost. I don't see how too much traffic there is a bad thing; you can always ignore other sections, and other people can ignore the gadgets section, but by having it on one page it's easy to see what's going on. — Carl (CBM · talk) 17:26, 24 April 2008 (UTC)
- "Records" aren't lost either way: after all, we always have page history. But finding stuff related to gadgets among hundreds other sections would be a bit difficult. —AlexSm 17:45, 24 April 2008 (UTC)
- I don't follow; the village pump is archived, so records aren't lost. I don't see how too much traffic there is a bad thing; you can always ignore other sections, and other people can ignore the gadgets section, but by having it on one page it's easy to see what's going on. — Carl (CBM · talk) 17:26, 24 April 2008 (UTC)
- That's true; I don't see why gadgets (just one of many technical things that can be put in the mediawiki namespace) need to have their own page for discussion, unless there are really lots of them. The editors who are likely to be interested in gadgets are likely to also follow VPT; I don't think there is a large contingent of editors who ignore all other technical issues apart from gadgets. — Carl (CBM · talk) 20:36, 24 April 2008 (UTC)
- Okay, I guess when someone suggests a gadget that's been discussed before, I'll just say "been proposed already, ask CBM for a link to the old discussion" :) Also, I keep wondering why bots and userscripts have their own discussion places. And another point: gadgets are supposed to be user-friendly, not overly technical, so why not use Wikipedia:Village pump (proposals) then? —AlexSm 21:07, 24 April 2008 (UTC)
- Sure, point them to me, no problem. The main reason for VPT is that people there tend to be more familiar with the technical issues that the gadgets could run into. I think userscripts are also quite frequently discussed on VPT. The "discussion" about bots is somewhat odd, but to save space I'll just say I would be happy if it was moved to VPT as well. — Carl (CBM · talk) 22:29, 24 April 2008 (UTC)
- Yes, the Village pump (technical) is a much better place, since there the gadgets will get more exposure and discussion. Wikipedia:Gadget/proposals simply doesn't work currently.
- Regarding Cacycles comment "premature change" and "concensus" comment above. Cacycle: You go around these pages adding rules and editing as you like. But as soon as anyone else does anything you revert it and say "discuss first", "find consensus first", "premature change" and so on. I think this is a case of WP:OWN.
- --David Göthberg (talk) 00:36, 25 April 2008 (UTC)
- Feel free to check the page histories to see that I created these pages from pre-existing but scattered content. This includes the rules which have since then be edited by quite a few users. I do not think that I was a major contributor to them beside the last (and quite obvious to me) one that gadget additions must be discussed. Please note (again) that there is a fundamental difference between changing the wiki system through the addition of gadgets on the one hand (special precautions and regulations needed here) and article pages discussing this process on the other hand (normal Wikipedia conventions apply here). Please see also my longer comment below. Сасусlе 02:52, 25 April 2008 (UTC)
- Cacycle: Regarding your comment further above (that was out of time order making discussion here hard to follow) and where you claim you actually support one of the new gadgets: Well, that's a very strange way of supporting a gadget, by removing all three and then not point out which one you would like to keep. Had you left one or two of them then you might have been speaking the truth, but you aren't. It is very clear to me what you and AlexSm are doing here after seeing how you behave: You two try to enforce that all gadgets should first be suggested and "discussed" at Wikipedia:Gadget/proposals precisely since that page doesn't get many visitors, since then you two can control this area and prevent any new gadgets from being added. It seems you two don't like anything that makes your 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 you have to respect any consensus reached on the village pump, since that overrules any local "consensus" (usually including only you and AlexSm) in less visited pages such as these. So I don't really know why I am discussing with you here. This discussion probably should be moved to the village pump.
- --David Göthberg (talk) 10:17, 26 April 2008 (UTC)
Why gadgets and how
Please let me address some of the topics above:
Gadgets are not comparable to any normal Wikipedia page, they are an extended part of the Wikipedia system itself and their malfunction can directly affect the usability of the site. The gadget feature has been added mainly for tools targeted at a wide normal-user audience. It was never intended to make every existing user script or every newly created user script a gadget. Many of the current gadgets should have never been added:
- Those aimed at a very small and technically versed audience
- Those that have not been tested and reviewed extensively
- Those that are only fixes for other gadgets or skins (report bugs to the authors or the MediaWiki bug reporting system)
- Those that are mainly statements in an ongoing discussion
- Those that are trivial and/or of limited or non-existing functionality
It is quite understandable that proud user script or style authors want to see their creation becoming a gadget as soon as possible. But even the most simple gadget can have implications (in terms of compatibility with different browsers, skins, userscripts, and other gadgets) far beyond what the typical gadget author or a Village pump visitor can foresee. Review takes time and can be very labor intensive, especially if people actually look at and review the code like Alex does (hats off!). No single gadget has ever been so important that it could not wait one or two weeks for a response before being added. If you do not get a response it could also mean that there is no great interest in it (and then it should not become a gadget).
Please note that it is not a major problem if a tool does not become a gadget (and it should definitely not create personal drama and overreactions) - please remember that we still have the standard ways to use an extension (monobook.js, monobook.cs, and local user scripts).
Wikipedia:Gadget and the current rules were created for one single reason: the old way of using Wikipedia:Village pump (proposals) did simply not work. Some reasons have been discussed above, another one is that you cannot expect people who are specifically interested in gadgets to wade through the massive traffic at Village pump (proposals) plus Village pump (technical). The current discussion clearly shows that we do not need less, but more detailed and explicit rules and consent about what should become a gadget and what not. I wholeheartedly agree that these pages and the current process are in need of more experts, but the only valid way for that is to attract them here and to ask them to bookmark this page (e.g. at the Village pump or the Community portal). Сасусlе 02:22, 25 April 2008 (UTC)
- I have now placed invitations to join this discussion at the Village pump or the Community portal. Сасусlе 22:52, 25 April 2008 (UTC)
- I don't see why it's desirable to limit the number of gadgets somehow - like someone said above, if the list gets too long it can always be rearranged. If there are 50 or 75 gadgets, it's not a big deal. Provided that a script is sufficiently stable and functional, there's no technical reason not to add it to the list.
- But more importantly, I disagree that gadgets are particularly important or dangerous compared to other Mediawiki pages. For example, if I want to change Common.js or Common.css, I can do that without any discussion or code review, and it will affect lots of people when they refresh their cache. On the other hand, a broken gadget will only impact the people who go out of their way to select it.
- Finally, I don't think that there are a large number of people who are interested in gadgets but not in any other technical aspects of the site. Presumably the people who write the gadgets mostly follow VPT anyway, because that's a common place for technical problems to be reported. If there are a few people who are specifically interested in gadgets, it isn't really difficult for them to scan VPT to find the relevant threads. — Carl (CBM · talk) 03:05, 25 April 2008 (UTC)
- Yeah sure... Try to sneak in some controversial changes into common.js (as people did recently with gadgets) and I will guarantee you that you will get grilled ;-) Сасусlе 13:47, 25 April 2008 (UTC)
- Controversial changes are bad, but there isn't any requirement for discussion first for noncontroversial changes. People who don't see the difference are discouraged from editing the page at all, but we don't stand in the way of people who are doing useful work. And lack of discussion on its own doesn't make a change controversial. — Carl (CBM · talk) 14:05, 25 April 2008 (UTC)
Possibly either some coding or at least organization could solve things rather neatly. People who use a gadget could simply rate its compatibility and functionality under diverse browsers and user environments (a compatibility matrix of sorts). Wikipedia table format already allows sorting, so people could rapidly pinpoint exactly the gadgets they want, of a quality that they want, and the system could run without external intervention.
That's just an initial impression because someone dragged me here, and I want to leave a reminder to myself. So don't worry if that's not entirely accurate yet. I'll totally come back and study gadgets more thoroughly. --Kim Bruning (talk) 13:31, 25 April 2008 (UTC)
- 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 not only based on functionality and compatibility, but also on user interest, quality, and usefulness (please also see the parallel discussion under Wikipedia:Gadget/proposals). Сасусlе 13:43, 25 April 2008 (UTC)
- Manageability can be achieved through sorting and the use of section headers. The list of user scripts, for example, is navigable despite its length. — Carl (CBM · talk) 14:05, 25 April 2008 (UTC)
- That's what I'm thinking too. It's the open content and open source tradition to provide a lot of choice. It's probably a better idea to make that tradition palatable by making the choice manageable, rather than to abandon the tradition. :-) --Kim Bruning (talk) 14:38, 25 April 2008 (UTC)
- Keep the user preferences interface manageable for normal users, per Сасусlе. But, as there so many useful user scripts, how about an extended gadgets page of its own? Think outside the box 15:15, 25 April 2008 (UTC)
Those that are only fixes for other gadgets or skins (report bugs to the authors or the MediaWiki bug reporting system) - are you talking to me? Because if you've got something to say to me, say it. You don't know what you're talking about - there's NOT a bug in the "modern" skin, it just doesn't hold to an assumption that script authors make - and this isn't one script that's affected by it, it's _hundreds_, including scripts that aren't maintained at all. And it's not even "bugs in other gadgets" - I've worked hard to make sure that none of the gadgets [except twinkle - that one's too complicated - and I have pointed out to AzaToth how it needs to be fixed. It wasn't even a gadget at the time I added mine anyway.] have the problem. --Random832 (contribs) 07:12, 26 April 2008 (UTC)
too much traffic? try not enough
You say VPT has too much traffic - the problem with the proposals page is that it doesn't get enough traffic. You removed a gadget that was proposed at the "proposals" page, that had no objections, simply because there was no-one there to respond. --Random832 (contribs) 06:58, 26 April 2008 (UTC)
- If you do not get a response it could also mean that there is no great interest in it (and then it should not become a gadget). - or it could mean that it wasn't posted to a wide enough audience - there could be interest in a given idea for a feature (and therefore it should become a gadget) without people knowing it would/could be implemented as a gadget. --Random832 (contribs) 07:21, 26 April 2008 (UTC)
- Well said, I full agree with Random832.
- --David Göthberg (talk) 10:20, 26 April 2008 (UTC)
Let me be very clear about this: David Göthberg and Random832, you better calm down and stop whining that you could not sneak in your trivial or redundant gadgets without any (real) discussion or notice and start working constructively towards a compromise or consensus to improve the process. I especially urge both of you to stop your personal attacks (like above [2], on my talk page [3], [4], and article edits [5]). Assume good faith and be assured that nobody is interested in useless bureaucracy, the main point is about transparency and the prevention of (potentially) disruptive changes. Сасусlе 18:18, 26 April 2008 (UTC)
- You are the only one here who thinks there is anything disruptive about this, that there's anything controversial about it, or that discussion must take place HERE and no place else (the one for the add section tab was placed there following a discussion on the village pump which also resulted in a change to another interface page that you did not revert). You're basically saying "Well, I wasn't consulted, so I'm going to unilaterally declare your changes controversial". WP:OWN, much? --Random832 (contribs) 22:50, 26 April 2008 (UTC)
And where the hell do you get off calling other people's gadgets "trivial", "redundant", "disruptive", "controversial" - and then accusing others of making personal attacks? --Random832 (contribs) 21:22, 27 April 2008 (UTC)
- You may want to move that discussion to a user talk page; I don't think it will help move conversation here forward. I think we will be able to work towards agreement better if we keep focused on gadgets rather than personalities. — Carl (CBM · talk) 21:45, 27 April 2008 (UTC)
Question
You (i.e. Cacycle) seem to be saying several things
- Gadgets are somehow more dangerous / more important / etc than other things such as common.js, and therefore need a more stringent approval process than edits in those other areas.
- Discussion needs to be on a separate page so that people who are somehow 'experts' on gadgets (I assume, you and AlexSm) can monitor it, rather than allowing the discussions to take place at the village pump, where a general audience - including numerous people already knowledgeable about javascript, etc - is already watching.
- There was/is something actually wrong with the recent additions that you reverted, and/or with other gadgets currently in use, and therefore their inclusion should have been prevented by having them go through an approval process.
Have I mischaracterized any part of your argument, or is there anything I'm missing? I'd like you see you back up these claims rather than stating them as though they are already accepted to be fact. --Random832 (contribs) 03:47, 28 April 2008 (UTC)
- While I can't answer #3 for Cacycle, I have something to say on #1 &2. First, gadgets are not more important than Common.js, but I think the problem is that you don't consider Common.js serious at all. You seem to share CBM's opinion that "if I want to change Common.js or Common.css, I can do that without any discussion or code review". This is just wrong. It's not normal to make so many unexpected additions to system files (a lot of which are later reverted) like you do. —AlexSm 04:40, 28 April 2008 (UTC)
- As for discussion place, I still think that a separate page would be a best choice, and nobody could raise any objections to my idea that Village Pump could be used for announcements. Still, if you move discussions to Village Pump, it's definitely should be Wikipedia:Village pump (proposals) because this is where non-trivial changes to system messages are discussed. There nothing "technical" in the decision whether to make some working code a gadget, and if you can't explain the gadget to an average non-technical user, then it's not supposed to be a gadget in the first place. —AlexSm 04:40, 28 April 2008 (UTC)
- P.S. Please do use "Show preview" button before saving the page. It's a bit difficult to answer you when you're making 13 edits in 20 minutes. —AlexSm 04:40, 28 April 2008 (UTC)
- My impression is that gadgets are not particularly important or special in any way that would justify building a special process just to approve them. Looking at the recentchanges for the MediaWiki namespace shows that most of the discussion links are to VPT, which is why I suggested that, but VPR is fine with me. — Carl (CBM · talk) 10:52, 28 April 2008 (UTC)
- I don't really see that we need to pick one or the other - It's a bit bureaucratic to say that a discussion isn't valid because it's not filed in the proper location - as long as it's a reasonably visible area, and both VPT/VPR qualify. --Random832 (contribs) 13:33, 28 April 2008 (UTC)