At some point a few weeks ago, the UTC clock stopped appearing in the personal toolbar. I don't recall making any changes that might have interfered with it. I've tried turning it off and on but it doesn't help. I welcome suggestions for other things I could try to fix it. Jojalozzo 15:11, 5 January 2015 (UTC)[reply]
Works for me. There are a lot of scripts loaded from your vector.js; one of them might be broken, blocking all other JavaScript/gadgets. Disable them all and re-enable them one by one. -- [[User:Edokter]] ((talk)) 15:51, 5 January 2015 (UTC)[reply]
Thank you for the suggestion. I may try that but the last change to my vector.js was March 2013 so I don't expect that is where the problem is. Jojalozzo 05:09, 6 January 2015 (UTC)[reply]
The last change to YOURS, yes, but what about all of those scripts you are dynamically importing? — xaosfluxTalk 20:42, 16 January 2016 (UTC)[reply]
@Coconuts31: It's only shown for WP:AUTOCONFIRMED users. You've made sufficient edits, but not enough time has yet elapsed. You should become autoconfirmed four days after registration, i.e. on 5 July 2015 at 21:56 (UTC), which is in five and a half hours' time. --Redrose64 (talk) 16:24, 5 July 2015 (UTC)[reply]
Display green collapsible arrows and green bullets for changed pages in your Watchlist, History and Recent changes
but as far as I can tell, this gadget displays only green bullets and only for the watchlist. I see no collapsible green arrows and I see no effect on the History and Recent changes pages. (Note: this gadget requires you to bypass your browser's cache each time you toggle its preference for the setting to come into effect.) Can somebody confirm or deny that they see same behavior. The description may be out-of-date. Courtesy ping: Edokter. Jason Quinn (talk) 15:56, 5 July 2015 (UTC)[reply]
Jason Quinn, on my end, I don't need to clear my cache. The arrows mentioned are visible in the enhanced watchlist only, which you get by enabling both Group changes by page in recent changes and watchlist and Expand watchlist to show all changes, not just the most recent in your preferences. -- [[User:Edokter]] ((talk)) 16:34, 5 July 2015 (UTC)[reply]
Gadget usage statistics via revision hashtags[edit]
Gadget developers and users: we would like to have your input on the following proposal phab:T123636 aiming to simplify the generation of statistics on the volume and quality of edits as well as the user base of individual gadgets by using revision hashtags. For additional context on revtagging and how it differs from WP:Tags see mw:revtagging (ping Slaporte (talk·contribs)). --DarTar (talk) 17:05, 16 January 2016 (UTC)[reply]
The bolding of unread articles on my watchlist has for some reason turned itself on recently, despite not being selected in my preferences. I tried selecting it, saving, then unselecting, but I can't seem to make it go away. Any advice? Cheers, Number57 18:57, 10 October 2016 (UTC)[reply]
Why is MediaWiki:Gadget-WatchlistBase.css loaded as a gadget? Shouldn't it be loaded via the MediaWiki:Common.css or something similar since the line in preferences says "This loads the base style for the watchlist. Please do not disable this option."? --TerraCodes(talk to me) 03:44, 26 October 2016 (UTC)[reply]
@TerraCodes:MediaWiki:Common.css is loaded for all users, even those who are logged out, so it is a good idea to keep it as small as possible. Logged-out users don't have watchlists, so it makes sense to load the watchlist CSS only for logged-in users. This can't be done via Common.css, but it can be done using gadgets, so that's why it is the way it is. I think it should be possible to hide the entry for it in preferences, though, if it isn't already. — Mr. Stradivarius♪ talk ♪ 03:53, 26 October 2016 (UTC)[reply]
If the gadget is deactived, the notices are completely hidden. However, if JavaScript is deactivated, the notices are shown (and of course not dismissable). Od1n (talk) 07:11, 11 April 2017 (UTC)[reply]
@Andy M. Wang: please could you attend to the queries raised above? — Martin (MSGJ · talk) 07:30, 20 April 2017 (UTC)[reply]
@Od1n: Andy doesn't seem to be actively editing at the moment. Would you like me to revert the change above? — Martin (MSGJ · talk) 07:31, 20 April 2017 (UTC)[reply]
@Od1n and MSGJ: Sorry I'm late to this... my 2 cents: I don't think there's anything in the code or doc that really needs to be changed since the general case is that JavaScript is enabled (and we're pretty much assuming that on this site I think). If it's just about adding that comment a.k.a this change, sounds okay. (I don't have power to make any changes.) — Andy W. (talk) 04:26, 7 May 2017 (UTC)[reply]
I feel that we should do some reordering soon on the list of gadgets. It's getting a bit long, and some of the sections are a bit all over the place right now. Anyone have suggestions ? —TheDJ (talk • contribs) 08:37, 26 June 2017 (UTC)[reply]
TLDR: We should remove this gadget, both as a default-enabled gadget, and completely.
Details: The MediaWiki:Gadget-featured-articles-links.js / MediaWiki:Gadget-featured-articles-links.css is no longer needed, nor working. Edokter commented on this over 2 years ago. Examples can be seen at Blade Runner. (Note, the GA badges are using a more generic styling in order to be consistent across all languages. The same styling is shown regardless of whether the Compact Language Links betafeature is enabled - i.e. this is controlled directly by Wikidata.) Hence I recommend removing the gadget entirely. Quiddity (talk) 16:06, 4 September 2017 (UTC)[reply]
"Place the category box above all other content"[edit]
How can I find who maintains the "Place the category box above all other content" gadget listed in the Preferences panel? czar 05:25, 8 September 2017 (UTC)[reply]
Does MediaWiki:Gadget-RegexMenuFramework.js work? It's a no go for me on modern, but more to the point, why are we explicitly offering something in the preferences that is recommended against? Should it not be replaced with m:TemplateScript, or am I missing something? Pinging @TheDJ: as the last editor there. ~ Amory(u • t • c) 13:45, 5 February 2018 (UTC)[reply]
@Amorymeltzer: If i disable it I'll get angry people chasing me. I don't feel like dealing with that. Deprecating and encouraging people slowly takes me too much time, which I don't have. —TheDJ (talk • contribs) 09:25, 6 February 2018 (UTC)[reply]
I hear ya, and I don't by any means intend to impose my naïveté on your time, but does the gadget even function? I can't get the regex editor in vector or monobook either, and if it doesn't work I imagine nobody is using it. ~ Amory(u • t • c) 11:24, 6 February 2018 (UTC)[reply]
It exposes some global functions, that people are supposed to use in their common.js file to add functionality.. It's an incredibly outdated design and hard to figure out how many people depend on this, but it's definitely quite a few. —TheDJ (talk • contribs) 13:45, 6 February 2018 (UTC)[reply]
I have an idea.. we can hide it, so that new people cannot enable it any longer... —TheDJ (talk • contribs) 13:46, 6 February 2018 (UTC)[reply]
search-new-tab isn't needed any more, due to being default browser behaviour?[edit]
The search-new-tab gadget says it lets you ctrl-click on a link in the search results box to open it in a new tab. As far as I can tell, this is actually default browser behaviour nowadays, as even without this gadget a ctrl-click opened a search link in a new tab in Chrome, Firefox, and Internet Explorer for me. Given that the gadget appears to serve no purpose, I think it'd be best to remove it to remove clutter. --Deskana (talk) 14:38, 7 July 2018 (UTC)[reply]
I've removed the gadget. --Deskana (talk) 23:18, 10 July 2018 (UTC)[reply]
Ctrl+click doesn’t work for me in Firefox (61.0.1, Win7) on any form button (i.e. <submit>, <button> etc.). Ctrl+click on search suggestions works, as these are implemented with HTML <a> tags. (I haven’t used the gadget, though, as I don’t often need this functionality, just wanted to let you know about this.) —Tacsipacsi (talk) 00:11, 11 July 2018 (UTC)[reply]
I don't think Ctrl-click has ever worked on buttons in FF. I can confirm Tacsipacsi's suspicion that disabling this gadget has removed functionality for users, at least in FF. The gadget is required to open search results in a new tab. - dcljr (talk) 05:46, 11 July 2018 (UTC)[reply]
What version/operating system? Firefox 61 on Win 10 provides for ctrl+click to new tab. --Izno (talk) 13:56, 11 July 2018 (UTC)[reply]
I noted my primary system configuration above, but this doesn’t work for me on Windows 10 either (Win10 April 2018 Update with June security updates, Firefox 61.0.1). Maybe you’re using a browser extension to achieve this (see about:addons)? Or you mean regular links like this? These work for everyone, the problem is with buttons like . —Tacsipacsi (talk) 14:50, 11 July 2018 (UTC)[reply]
I'm confused. The gadget was described as "Open search results in a new tab or window when holding down the Ctrl key", but the complaints here are about ctrl-clicking on buttons, which is unrelated to what the gadget said it was doing. For example, the example immediately above this comment is a button, not a search result. Am I misunderstanding? --Deskana (talk) 15:12, 11 July 2018 (UTC)[reply]
Search on this wiki is implemented either through the search box at the top right of every page (in the Vector skin), where there is a magnifying glass button/icon to perform the search, or through Special:Search where there is a "Search" button to do the same. For me, both methods fail to open a new tab with Ctrl-click or with Ctrl-Enter on FF 52.6.0 for Gentoo Linux and on IE 11.0.9600.19035 for Windows 7. However, Ctrl-click in both places does work for me on Chrome 67.0.3396.99 for WIndows 7. I can only confirm Ctrl-Enter used to work on FF 52.6.0 (and at least a couple of previous versions — not sure which ones) on Gentoo Linux when the gadget was enabled. Do we know of any other Wikimedia wikis where this gadget is still enabled? I don't know of any, but if so that would enable further testing of the gadget itself. (Or you could just re-enable the gadget here, which is what I'd like you to do.) - dcljr (talk) 15:33, 11 July 2018 (UTC) [Edits to this comment after first reply: added "/icon", 15:38, 11 July 2018 (UTC); added "(in the Vector skin)". - dcljr (talk) 17:29, 11 July 2018 (UTC)][reply]
The following elements were manipulated by this gadget: #searchform, #searchbox, #search, .search-types, #search-types, #powersearch —TheDJ (talk • contribs) 15:35, 11 July 2018 (UTC)[reply]
Please note (primarily talking to Deskana here) that the gadget isn't about links at all (whether in search results or not), for which Ctrl-click always works on "all" modern browsers, AFAIK. It is about getting to the search results in the first place. - dcljr (talk) 15:40, 11 July 2018 (UTC)[reply]
So, it seems the gadget description was at best wrong, or at worst very misleading. So, I'm still fairly confused about what exactly the problem is. The issue is that with the gadget enabled when you clicked on the magnifying glass in the search bar then it would open in a new tab, but now with no gadget it doesn't? This seems like very niche functionality, and having niche functionality a bad pattern. That said, you can always still enable the gadget directly by putting importScript('MediaWiki:Gadget-search-new-tab.js') in your common.js. --Deskana (talk) 05:46, 12 July 2018 (UTC)[reply]
Actually, the description you quoted above says exactly what the gadget does. You just misunderstood and thought it had something to do with links. And like I said, I used Ctrl-Enter, actually, instead of Ctrl-click, but the results are (were) the same. Look, I'm not trying to be rude here, but you really shouldn't be disabling gadgets without understanding what they do in the first place. Did you look at the code? Did you ask the author of the gadget or (if different) the user who originally enabled it what it did? Did you test the gadget yourself, in the same manner you suggested I could use? Do you know how many users had the gadget enabled? I suspect the answer to all of these (based on what you have said here) is "no", in which case you are blindly trying out a blunt-force "solution" to a likely nonexistent "problem", thereby creating a problem (inconvenience, anyway) in the process. Sorry if this seems harsh. Things like this just piss me off (people doing something they shouldn't be doing and then refusing to undo it for no good reason). - dcljr (talk) 10:46, 12 July 2018 (UTC)[reply]
Whoa boy, that's a lot of assumptions. Let's go through them. Did I look at the code? Yes, but I clearly didn't understand it correctly based on what happened here. Did I ask the author? No. Did I test it myself? Yes, I enabled it through the gadget interface before I disabled it, and it worked the same for me both with and without the gadget enabled. Did I check how many users were using it? Yes, there are just over 7,000 users of the gadget. Anyway, I've undone my change, and you can rest assured that I won't work on gadgets again. --Deskana (talk) 19:01, 12 July 2018 (UTC)[reply]
Using common.js is by far the worst practice to enable anything. Yesterday people were told to use document.write() with HTTP links. It doesn’t work today, but 11,500 people still use it (including you). Today you suggest using importScript(), which will be gone by tomorrow (actually it’s planned to be deprecated in the near future). Tomorrow someone else will suggest another method, which may also be gone at some point. So people have custom JSs which are only useful to create security problems like using non-secure URLs. Maybe the description can be improved (although it seems that you’re the only one who didn’t understand it), but disabling a gadget on your own without understanding its functions is simply unacceptable. English Wikipedia is certainly not the place that lacks admins familiar with JavaScript, so let them manage gadgets. —Tacsipacsi (talk) 14:33, 12 July 2018 (UTC)[reply]
Why would I confuse it? I know that the user JavaScript is not the same as the site-wide one. I was only speaking about the former; the site-wide Common.js doesn’t contain any document.write() or importScript(). The user JavaScript can also have security problems; of course not for everybody, only for its owner, but for them it can. —Tacsipacsi (talk) 21:46, 12 July 2018 (UTC)[reply]
Sorry for giving incorrect advice about using importScript(). Sorry for apparently being the only person to misunderstand the gadget description. Sorry for not having good enough knowledge of JavaScript for you. I've undone my change, and you can rest assured that I won't work on gadgets again. Hopefully that resolves your concerns. --Deskana (talk) 19:01, 12 July 2018 (UTC)[reply]
@Deskana: It wasn't my intention to have you never "work on gadgets again", just to be (much) more careful about disabling things. BTW (to no one in particular), I find that I had to re-enable the gadget in my preferences, since it "came back" unchecked. This seems a little weird to me. I would have hoped that a more specific action would be required to make MediaWiki "forget" users' preferences than simply removing entries at MediaWiki:Gadgets-definition (like maybe a sysadmin running a script). I guess not! - dcljr (talk) 08:42, 13 July 2018 (UTC)[reply]
Same with flipping the default bit, that also wipes everyones setting. —TheDJ (talk • contribs) 08:47, 13 July 2018 (UTC)[reply]
@Dcljr: Don't worry about it. Working to improve the gadgets space seems like it'll be an uphill battle, and I deal with enough of those as a Wikimedian without adding more, so I've lost interest. It's not a big deal. I've got plenty of other things to do instead. --Deskana (talk) 10:35, 13 July 2018 (UTC)[reply]
BTW, on the matter of improving the description, might it help to say, "Open page of search results in a new tab or window when holding down the Ctrl key" (added text noted)? And I guess "or window" is stated just because some browsers provide their own option to change the Ctrl key behavior to open a window instead of a tab, in which case perhaps that phrase should be in parentheses? Thus: "Open page of search results in a new tab (or window) when holding down the Ctrl key". - dcljr (talk) 08:56, 13 July 2018 (UTC)[reply]
Another BTW: I'm not sure User:Timeshifter, the gadget author, needs to be consulted now, but he is still active. So if he'd like to weigh in on anything in this discussion… - dcljr (talk) 09:14, 13 July 2018 (UTC)[reply]
(unindent). I just tested with the gadget on and off. In Firefox 61.0.1 in Windows 7 Home Premium. Enabling the gadget helps when clicking the magnifying glass icon when doing a search from the top-right search form. Without the gadget ctrl-clicking that icon ends up with the search results list in the same tab.
Ctrl-clicking without the gadget works when clicking items in the dropdown list.
By the way, I did not create this gadget. I vaguely remember passing it on, and encouraging it be made a gadget in order to make it a lot easier to use by more people. I am not a developer, and I may have hacked at it, but someone else originally made it. --Timeshifter (talk) 18:09, 13 July 2018 (UTC)[reply]
Testing at Special:Search. The gadget helps more here. Enter a search term. Without the gadget ctrl-clicking does not help when clicking the "search" button. Also, ctrl-clicking items in the dropdown list does not open anything in a new tab.
After enabling the gadget ctrl-clicking the "search" button opens results in a new tab. Ctrl-clicking items in the dropdown list also opens results in a new tab. --Timeshifter (talk) 18:30, 13 July 2018 (UTC)[reply]
Maybe change the gadget description to something like this:
"Always get search result list in a new tab or window when holding down the Ctrl key."
Would it be possible to include a link either to the documentation of the gadget or to its Javascript page in the Gadget preferences page? I might also suggest including the name for each item as well. It would aid recognizability and findability for trying to get changes to gadgets made for our not-so-well-known-as-Twinkle gadgets in the list. --Izno (talk) 04:02, 24 October 2018 (UTC)[reply]
I think this is a great idea! Maybe VPT/VPPR? This page isn't highly-watched. Enterprisey (talk!) 05:41, 24 October 2018 (UTC)[reply]
I have no idea where but some page or another listed this one. @Enterprisey: As it happens, Special:Gadgets is linked on Special:Preferences, so that at least gets you to the Javascript page for the gadget. --Izno (talk) 14:09, 24 October 2018 (UTC)[reply]
The "work" on this is going to be finding all of the documentation pages and getting the edits made, feel free to tackle this and add edit requests to the definition pages. — xaosfluxTalk 14:16, 24 October 2018 (UTC)[reply]
Yes, I doubt it is controversial; I just don't know where to make the edit requests. --Izno (talk) 14:47, 24 October 2018 (UTC)[reply]
Hi, all, I'd like to make a change to Mediawiki:Gadget-markblocked.js, and wanted to discuss it here first. You can see the diff of what I'd like to change here: Special:Diff/862434408/884449263. Currently, when you go to an indefblocked user's talk page history, all of the datestamped history links will be styled as a link to an indefblocked user. This causes the distinction between revdeled and non-revdeled edits to be lost (at least for admins), since it overwrites the normal strikethrough-italic styling of a revdeled link. My changes exclude the datestamp links from consideration, preserving the extra information about revdel that is otherwise lost. Screenshots of the effect included. Thoughts? Writ Keeper⚇♔ 18:52, 21 February 2019 (UTC)[reply]
+1 Since becoming an admin (as if you're a non-admin, the revdeleted revision links are also grayed out), I've often had to view the history logged out (there are legit uses for an incognito window!) to make any sense of the history, which I shouldn't need to do since I don't see any reason for every revision link of the history to be struck-through. Galobtter (pingó mió) 19:18, 21 February 2019 (UTC)[reply]
This mess made me think the same thing today, thanks for taking action! Changes look good, although I think return`ing on just .mw-changeslist-date would be sufficient and looks clearer to me. Unless that mucks up sysops viewing history with suppressed revisions? ~ Amory(u • t • c) 01:58, 22 February 2019 (UTC)[reply]
Haha, nah, I just like having the (cur|prev) links be without lines, too (also shown in the screenshots). It's not necessary at all; in the interest of being conservative with changes, I'll leave it out. Writ Keeper⚇♔ 03:01, 22 February 2019 (UTC)[reply]
I'm not wild about it either, but in the case of editors editing a blocked user's talk page, they impart extra information that, yes, that user is blocked, regardless of whether the revision's editor is blocked. One thing to do might be to exclude some combination of .comment, .mw-history-undo, and .mw-rollback-link. It starts to get a bit unwieldy, but crossing out rollback/undo might send the wrong message. The edit summaries are somewhere in-between IMO; crossed out emphasizes the page you're on is that of a blocked user (à la cur/prev) but could(?) also be misleading/overly difficult to read. ~ Amory(u • t • c) 10:53, 22 February 2019 (UTC)[reply]
Yeah, I was considering doing the rollback and undo buttons, too, but decided against it just because of how bloat-y the if statement was getting. It's definitely a good idea, though. Writ Keeper⚇♔ 15:44, 22 February 2019 (UTC)[reply]
Sounds like a good idea. Thanks for writing the patch! Enterprisey (talk!) 05:08, 22 February 2019 (UTC)[reply]
Okay, I went ahead and did the thing. I did it for the history entries, rollback links, and undo links, but not the cur/prev links. LMK with any comments/questions/concerns, of course. Cheers, all! Writ Keeper⚇♔ 17:16, 22 February 2019 (UTC)[reply]
Gorgeous. ~ Amory(u • t • c) 01:58, 23 February 2019 (UTC)[reply]
Categories are not shown in the Minerva skin per discussion on mw.org. I've written a gadget that would add this missing feature. It could be made default for logged in users but I ask for now that it is installed so at least editors are given the option.
The module would be restricted to the Minerva skin, which should work on both mobile and desktop Minerva but not load on other skins where is it not necessary.
@MassiveEartha:@1997kB:@Pelagic:
PS. I'm a little confused by the gadget process. It might be necessary to post to Wikipedia:Village_pump_(technical) - in which case, it would be better coming from an editor more active on that page and you should feel free to link here in that conversation! — Preceding unsigned comment added by Jdlrobson (talk • contribs) 18:53, 10 October 2019 (UTC)[reply]
@Jdlrobson: I believe there is already a similar gadget available, MediaWiki:Gadget-MobileCategories.js and a beta feature is available. I think you can submit a edit request instead. Also your script uses wgTitle and it is restricted to mainspace. I don't think it will be much useful if you only include mainspace. Add another thing why you are hiding hidden categories on mobile? This script should detect user preferences for showing/hiding hidden categories and work accordingly. Masum Reza📞 19:49, 10 October 2019 (UTC)[reply]
As a developer on the mobile project, I can share that there is a possibility we might be removing the beta (and possibly with it the categories beta feature which hasn't been maintained in several years) - hence why I'm interested in getting a more simple global gadget available. MediaWiki:Gadget-MobileCategories.js also looks suitable - I didn't realise User:TheDJ had beaten me too it :-) .... but it should really be made global and available via Special:Preferences. I'm happy to update my script to detect user preferences if that's more useful. Either way there should be one gadget there now (especially given the issues with gadget on mobile should have been resolved now) Jdlrobson (talk) 04:25, 11 October 2019 (UTC)[reply]
I see. Let's suppose Categories beta feature is removed, and it is replaced by one of these scripts (yours/TheDJ's). We wouldn't be able to add(/remove) categories to a page easily. The beta feature currently allows one to add categories to a page without editing the wikitext. It is partially like a mobile hotcat. And the current HotCat won't run on mobile. I suggest you to update your script so it at least replicates the beta Categories feature. Then IMO, there will be no reason not to remove the beta. And if I am not mistaken HotCat is a global gadget and most wikis have it, not sure we had "a community discussion" to add this gadget on every wikis where it is installed. Sometimes it is hard to find discussion participants particularly on smaller wikis. IMO, if a gadget is useful, we should be bold enough to add the gadget ourselves. Masum Reza📞 03:09, 12 October 2019 (UTC)[reply]
i don't have any plans to expand the category gadget I wrote. I just wanted to provide an option if it does get removed. The code of the beta feature is pretty neglected. It has been touched in a couple of years so I would be hard pressed not to support its removal. Jdlrobson (talk) 19:11, 13 October 2019 (UTC)[reply]
User:FR30799386 has written an undo feature for mobile/Minerva skin. I would like to suggest it is added as gadget (possibly enabled for logged in users) per the mw.org conversation as it seems users are not discovering this important tool.
The module should be targeted to "mobile" only so it applies to all skins on the mobile domain but does not run on desktop.
@Bageense:@Masumrezarock100:@94rain:Jdlrobson (talk) 18:51, 10 October 2019 (UTC)[reply]
PS. I'm a little confused by the gadget process. It might be necessary to post to Wikipedia:Village_pump_(technical) - in which case, it would be better coming from an editor more active on that page and you should feel free to link here in that conversation! — Preceding unsigned comment added by Jdlrobson (talk • contribs) 18:53, 10 October 2019 (UTC)[reply]
I proposed the same thing few months ago. But it didn't get much attention. I believe it didn't reach many users who edit by mobile. There was no oppose but apparently the proposal didn't succeed. One concern was that the script had used plain HTML, CSS, and JavaScript to construct the button, which I believe has been addressed. I fully support this proposal. I can propose this gadget on Wikimedia Commons. Also there is a task on phabricator to add a undo button to diff pages, but it doesn't look like Readers web team is going to work on it anytime soon. Masum Reza📞 19:36, 10 October 2019 (UTC)[reply]
apologies. I wasn't aware of that. Thank you for flagging. Jdlrobson (talk) 19:10, 13 October 2019 (UTC)[reply]
No worries. There's feasibly someone who would be willing to port and maintain the tool here. --Izno (talk) 20:04, 13 October 2019 (UTC)[reply]
@Izno and Jdlrobson: He is not banned but blocked. They were banned here for sockpuppeting not script abusing. I've interacted with FR a few times, and I see no behaviourial issues. No abuse on other wikis. They are also active on phabricator and Gerrit, no sign of technical abuse there either. It sucks that some people like to gravedance over one block log. Just to be on the safe side, we should copy it to mediawiki and not import it from their userspace if we decide to make it a gadget. And yeah, proxying is allowed if an independent editor finds the content productive and verifiable, and I am pretty sure that we have some people here who can judge/review code. Also the current maintainer is DannyS712. Masum Reza📞 01:07, 14 October 2019 (UTC)[reply]
In one breath "socking", in the same "no behavioral issues". Yeah, no. That's not how that works. It's not gravedancing to say "he's not allowed to contribute here right now" and to point that out when he is apparently cited as the primary creator by the person suggesting the tool should be used here. --Izno (talk) 01:48, 14 October 2019 (UTC)[reply]
@Jdlrobson: I have created a fork of FR's script at User:SD0001/Gadget-mobile-undo.js. The code has been cleaned up extensively, so that is now hopefully readable, making maintenance easier. A few minor issues such as lack of failure handling for getting messages from the API have also been fixed. Also, the script will not modify the thanks button (or make any other CSS changes) if the page is not editable (due to lack of permissions).
Feel free to review the code. I guess this version can be converted to a gadget, barring any objections. I will leave a notification at WP:VPT. SD0001 (talk) 08:13, 16 October 2019 (UTC)[reply]
Hi - is there any way to make the UTC time toolbar display work for certain time zones, not just UTC? Would be a handy addition for Wikipedia. ɱ(talk) 00:54, 11 May 2020 (UTC)[reply]
Could someone with .js editing privileges make the necessary edits? T.Shafee(Evo&Evo)talk 05:12, 3 March 2021 (UTC)[reply]
Additionally, what do people think about replacing the entire caption background as white (similar to formatting at this page). T.Shafee(Evo&Evo)talk 05:16, 3 March 2021 (UTC)[reply]
Not done (as to the immediate edit request) this is a 'test' gadget so no big deal making tweaks to it; but they need to be written before they can be implemented. Once someone writes and tests changes, feel free to activate a new edit request at MediaWiki talk:Gadget-NewImageThumb. — xaosfluxTalk 14:44, 3 March 2021 (UTC)[reply]
@Tacsipacsi: The advance mode is so annoying. I wish there were more options to choose from. —hueman1 (talk • contributions) 17:34, 5 July 2021 (UTC)[reply]
@Tacsipacsi:mw:Manual:Interface/JavaScript says that it is for the "Mobile website". Now, that site happens to use Minerva so you should be able to do things there as well, but mobile.js is not limited to mobile users looking at pages in the mediawiki namespace as far as I'm aware (please point to any documentation that says otherwise and we can update the local description). — xaosfluxTalk 23:17, 6 July 2021 (UTC)[reply]
@Xaosflux: I mean only the mobile.js page that is specified in the MediaWiki namespace is loaded, not that the mobile.js page would be loaded only when seeing pages in the MW namespace (the latter would hardly make any sense). And no, the documentation you cited doesn’t say that Special:MyPage/mobile.js would be for the mobile website, there’s no such entry in the table in mw:Manual:Interface/JavaScript#Personal scripts. (§ Global scripts lists it, but that applies to the MediaWiki namespace version only, not to user subpages.) By the way, I looked at the code, and while it isn’t easy to prove that something doesn’t get loaded, I found nothing that would load /mobile.js. —Tacsipacsi (talk) 00:13, 7 July 2021 (UTC)[reply]
I think it would probably be a good idea to remove the table of available gadgets from this information page. The table is horrendously out of date and has been tagged as needing an update since 2010. It is missing several of the most commonly used gadgets (like twinkle) and contains several discontinued or removed gadgets (e.g. the teahouse gadget). Despite MediaWiki:Gadgets-definition asking that all gadgets be added to the list this very obviously hasn't been done. Finally this table largely duplicates the functionality of a special page that is automatically generated by the software, Special:Gadgets, which contains a sorted list of all available gadgets, a short description of what they do and a link to their source files. I think it would be better to replace this table with a paragraph explaining that users can browse available gadgets in their preferences page, and that a list of all gadgets can be found on the special page. 192.76.8.91 (talk) 13:45, 8 July 2021 (UTC)[reply]
Shortdescr gadget does not work on Tewiki with Vector-2022 UI[edit]
Request help to fix the Shortdescr gadget on Tewiki with Vector-2022 UI. It works fine in traditional Vector UI. Arjunaraoc (talk) 04:41, 27 August 2022 (UTC)[reply]
I suggest copy-pasting the Search and Replace functionality to the Wikipedia:RefToolbar to prevent the need to switch modules to locate it (and match experience of using Visual Editor). I have had a few instances when I was unable to use it natively on WP and had to use external programs simply because I couldn’t find it when editing a page. Respublik (talk) 23:39, 28 June 2023 (UTC)[reply]
copy-pasting the Search and Replace functionality. Can you elaborate a bit on this? I'm having trouble figuring out what you mean and how this is related to the RefToolbar. –Novem Linguae (talk) 00:13, 29 June 2023 (UTC)[reply]
I assume they're suggesting that the search and replace button in the Advanced subtoolbar be copied onto the Cite subtoolbar. Nardog (talk) 00:15, 29 June 2023 (UTC)[reply]
This ^ Respublik (talk) 03:01, 29 June 2023 (UTC)[reply]
@TheDJ: What does They have to be written to allow users to run without Javascript mean? Since all a gadget does is add JavaScript and CSS, for users with JS disabled, all gadgets already "allow users to run without JS", by not being available to them. Does it mean the CSS should not cause problems for them, or something else? Nardog (talk) 00:22, 24 January 2024 (UTC)[reply]
I think it means default gadgets should not required for the website to function, because the website should function with js disabled. Snowmanonahoe (talk·contribs·typos) 00:23, 24 January 2024 (UTC)[reply]
That and there are style only modules that might expect javascript to load from another module. This is pretty rare however... maybe we should remove that again, it might cause more confusion that it will be worth. —TheDJ (talk • contribs) 08:22, 24 January 2024 (UTC)[reply]
What about [Default gadgets should:] Not be required for content to be readable, except for styles-only gadgets? The current wording is confusing indeed, but on the other hand one can easily forget about no-JS users while developing a JS gadget, so it’s important to stress this. —Tacsipacsi (talk) 21:06, 24 January 2024 (UTC)[reply]
Sounds good, edited. Nardog (talk) 03:34, 26 January 2024 (UTC)[reply]