MediaWiki talk:Gadgets-definition

• MediaWiki
• Meta
• Commons
• Wikibooks
• Wikiquote
• Wikisource
• Wiktionary
• de
• fr
• pl
• ja
• jbo
• it
• nl
• es

Convert MediaWiki:Gadget-switcher.js to a template gadget

This default gadget only needs to be loaded on pages having an element with switcher-container class, so is a textbook fit to be a template gadget. From a quick search, looks like Module:Mapframe, Module:Location map and Module:Random slideshow will need edits to insert a category which is specified in the gadget definition. – SD0001 (talk) 18:54, 20 December 2024 (UTC)

Seems fine. Izno (talk) 19:51, 20 December 2024 (UTC)

mw:Template gadgets –Novem Linguae (talk) 21:22, 20 December 2024 (UTC)

We are talking about something invoked on millions of pages here though correct? I'm certainly a fan of not using default loads when we don't need to - but this seems a bit heavy. — xaosflux ^Talk 21:46, 20 December 2024 (UTC)

Heavy as in? – SD0001 (talk) 07:59, 21 December 2024 (UTC)

Presumably the million or two rows added to catlinks. Izno (talk) 17:51, 21 December 2024 (UTC)

That and depending on category inclusion when the category is so heavily populated, may have unreliable results. — xaosflux ^Talk 17:21, 22 December 2024 (UTC)

Only unreliable part is the initial population of the category which can take some time due to parser cache. We already use template gadget for WikiMiniAtlas which has a million+ pages and didn't see any issues, due to a 2-stage rollout (adding the template gadget first, then removing the common.js load a month later). The same can be done here. – SD0001 (talk) 18:19, 26 December 2024 (UTC)

Difference there, that is basically a single-purpose gadget - I suspect this one may continue to be reused for more applications as a general utility. This isn't a hard oppose, more of a caution that we could be setting ourselves up for future problems. — xaosflux ^Talk 19:35, 26 December 2024 (UTC)

I don't really see new uses creating a problem either, except that adding the category to a highly-used template would cause the gadget to take a while to propagate to users, which is natural. – SD0001 (talk) 10:58, 4 January 2025 (UTC)

Edit request 3 May 2026

Description of suggested change: Reference Tooltips is currently enabled by default for anonymous users. mw:Extension:Popups and mw:Extension:Cite provides this feature. Having this feature enabled by default creates an inconsistent experience when navigating across projects. We removed default from Navigation_popups for similar reasons. Apologies if this has been discussed before, but in future, Minerva is likely to use mw:Extension:Cite so this would lead to loss of the feature for mobile users in current form. Could we at least add "rights=viewmywatchlist" to restrict it to logged in users who can opt out?

Diff:

−

ReferenceTooltips [ResourceLoader |default |skins=vector, vector-2022, monobook, timeless, modern, cologneblue |type=general |dependencies=mediawiki.cookie, jquery.client] |ReferenceTooltips.js |ReferenceTooltips.css

+

ReferenceTooltips [ResourceLoader |default |rights=viewmywatchlist |skins=vector, vector-2022, monobook, timeless, modern, cologneblue |type=general |dependencies=mediawiki.cookie, jquery.client] |ReferenceTooltips.js |ReferenceTooltips.css

🐸 Jdlrobson (talk) 21:26, 3 May 2026 (UTC)

Navigation popups (the enwiki gadget) has never been enabled by default here.

I'd actually like to disable the gadget, I just don't know what the differences are and nobody upstream has ever enumerated them that I know of. Izno (talk) 00:25, 4 May 2026 (UTC)

@Jdlrobson I'm sorry to be the problem-causer here, but the reference tooltip implementation for nested citations is just plain better and (imo) more usable than the broken Minerva variant and the space-inefficient and Cite extension variant (which has no awareness or respect for nested citations). As a reader, I would much prefer Reference Tooltips over the latter even if that means some slight inconsistency when I switched wikis (which imo wouldn't bother readers at all). This is particularly important since typically the articles linked from the Main page (the place that sees a significant amount of traffic) will have complex citation patterns that require the nested citations feature. Sohom (talk) 02:24, 4 May 2026 (UTC)

I disagree it is a better experience but my request doesn't impact you as an account holder. I personally disabled it on my account but anonymous readers cannot opt out of a gadget. I don't think we should ever override a mediawiki feature for anonymous users without a strong reason.

The references tooltip is not being actively developed and hasn't benefited from the usability research, and A/B tests that were carried out building the native page previews experience. The development was data-driven.

If the default feature needs improvement we should be requesting those improvements but please let's stop forcing this on anonymous users and assuming we know better based on personal taste. 🐸 Jdlrobson (talk) 16:03, 4 May 2026 (UTC)

@Jdlrobson Is there user research done to directly compare these two components? If so please link to it. In my eyes this is indeed not a matter of taste, it is broken functionality in the upstream version needing to be replaced by the community. Sohom (talk) 16:08, 4 May 2026 (UTC)

phab:T425363 now exists describing the functionality that is broken in case you want to fix it. Sohom (talk) 16:20, 4 May 2026 (UTC)

(I will note if you somehow tell me this behavior is somehow intentional and data-driven, I'm sorry but that points to a flaw in the methodology) Sohom (talk) 16:23, 4 May 2026 (UTC)

No the nested reference seems like a bug that should be fixed. I never noticed that before. It works fine on the mobile site. There has been no research comparing the two directly, and no research at all for the gadget. I'm referring to the research that happened during roll out relating to the user experience of page previews which the Cite feature is built upon (https://wikimediafoundation.org/news/2018/05/09/page-previews-documentation/) 🐸 Jdlrobson (talk) 17:11, 4 May 2026 (UTC)

I would suggest doing this research. In my eyes Reference Tooltips is the more usability focused product of the three since (besides the bugs I mentioned) it allows the user to customize how and when the tooltips will be seen (on click vs on hover, as dotted lines or not). I'm open to be proved wrong be research. In my eyes, if y'all do want to make ReferencePreview the default for readers, I think (besides fixing the obvious usability bugs) bringing ReferencePreview to be feature complete enough with ReferenceTooltips would be my ask (particularly the expectation of being able to customize click vs hover) Sohom (talk) 18:06, 4 May 2026 (UTC)

Not done for now: per Sohom. Izno (talk) 17:23, 4 May 2026 (UTC)

Help me understand this logic here that places the burden of proof on a vetted core feature rather than a local override.

Reference Tooltips (Page previews for citations) is the default for all wikipedias ($wgCiteReferencePreviews). It is a platform-level solution designed for long-term sustainability that has undergone WMF research, design review, security audits, and performance/accessibility reviews (per link shared earlier). The gadget disabling it lacks these rigors.

The software's core code is the true status quo. A gadget is an optional override.

English Wikipedia is disabling this feature for anonymous users. By prioritizing the gadget we are:

• Creating UX friction: We are providing a fragmented UX where users have to navigate two settings area to disable what feels like the same feature to them.
• Ignoring global usability: While this gadget serves a specific group of existing editors, the default feature is designed to lower the barrier for the thousands of new contributors who never go into their 'Preferences' to enable gadgets. We shouldn't let local status quo bias hinder global usability.
• Increasing technical debt: we are increasing the JS payload and failing to benefiting from all the good work that went into building the core feature

If you are going to disable a global feature for anonymous users, the "onus" should be on the gadget to prove it is superiority. Relying on "it was here first" and "I prefer it" isn't a technical justification for bypassing a platform standard. The WMF doesn't touch gadgets so will never run research on a feature they don't own.

[Note in case this is not clear: I am writing this as a volunteer not a staff member.] 🐸 Jdlrobson (talk) 15:51, 5 May 2026 (UTC)

Protected edit request on 5 May 2026

Please remove mediawiki.ui from formWizard-core's dependency list. It was removed in T420678. To reproduce the warning, go to any page in the Wikipedia namespace (say, WP:GADGETS) and open the browser console.

mediawiki.ui.button, a dependency of script-installer, has also been marked for deprecation, though not removed yet. See T420685. NguoiDungKhongDinhDanh 19:44, 5 May 2026 (UTC)

Was the actual need for the dependency that formWizard has on mw.ui removed (at some point)? It doesn't look like it based on a cursory review of the history, but perhaps you can see something I don't. Izno (talk) 20:30, 5 May 2026 (UTC)

@Izno: I skimmed the source code, and it seems formWizard is just using mediawiki.ui via class names (there are five instances of mw-ui within MediaWiki:Gadget-formWizard-core.js).

A simple way to check is to run this at Wikipedia:WikiProject Medicine, then click the "Participate" button:

mw.loader.using(['mediawiki.api', 'mediawiki.cookie', 'mediawiki.user', 'jquery.chosen', 'jquery.ui', 'user.options']).then(() => {
    mw.loader.load('https://en.wikipedia.org/wiki/MediaWiki:Gadget-formWizard-core.js?action=raw&ctype=text/javascript');
    mw.loader.load('https://en.wikipedia.org/wiki/MediaWiki:Gadget-formWizard.css?action=raw&ctype=text/css', 'text/css');
});

Four out of the aforementioned five are actually from mediawiki.ui.button rather than mediawiki.ui, so removing the latter (or replacing it with the former) most likely will be fine. Currently the gadget just straight-out refuses to run.

NguoiDungKhongDinhDanh 20:28, 7 May 2026 (UTC)

 Done Had a look at things, there's been enough other bit of breakage in the wizard due to various upstream changes. Have just removed.

Please evaluate whether the gadget needs to change also. Izno (talk) 22:54, 7 May 2026 (UTC)

Redundant dependencies

If a given module, say mediawiki.api, is listed as a dependency on a gadget, any modules that *it* depends on shouldn't need to be listed for the gadget as well, right? For example, mediawiki.api's dependencies include mediawiki.jqueryMsg, mediawiki.Title, user.options, and mediawiki.util, all of which are listed alongside mediawiki.api at one time or another on this page.

If I'm right about the above, could/should the redundant dependencies be removed? Mr. Starfleet Command (talk) 22:53, 14 May 2026 (UTC)

Even if it works that way, I'd recommend declaring anything the gadget actually uses anyway. That will avoid surprise problems if, to use your example, mediawiki.api stops depending on mediawiki.jqueryMsg but the gadget still needs it. Anomie⚔ 23:25, 14 May 2026 (UTC)

Yes, this is a general best practice in other ecosystems I've seen. Maintainability trumps the tiny extra bit of processing the system will need to do. Izno (talk) 23:34, 14 May 2026 (UTC)

Understood. Thanks for the swift replies! Mr. Starfleet Command (talk) 23:41, 14 May 2026 (UTC)