MediaWiki talk:Gadgets-definition

MediaWiki:Gadgets-definition provides the content of the Gadgets tab of Special:Preferences (also visible at Special:Gadgets).
This interface message or skin may also be documented on MediaWiki.org or translatewiki.net.
The page forms part of the MediaWiki interface, and can only be edited by administrators and interface editors.
To request a change to the page, add {{edit fully-protected}} to this page, followed by a description of your request. Consider announcing discussions you add here at Wikipedia:Village pump (technical) to bring more people to the discussion.

Archives

Archive 1

Archive 2

This page has archives. Sections older than 30 days may be automatically archived by when more than 4 sections are present.

Remove MakeMobileCollapsible gadget

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Minerva has been updated to load collapsing code, example, so I believe this gadget can be removed. 🐸 Jdlrobson (talk) 02:24, 7 June 2024 (UTC)[reply]

@Izno: any concerns? — xaosflux ^Talk 12:17, 7 June 2024 (UTC)[reply]

Don't think so. Izno (talk) 15:32, 7 June 2024 (UTC)[reply]

Done removed, haven't deleted the files in case there are any issues that need this back. — xaosflux ^Talk 15:34, 7 June 2024 (UTC)[reply]

Edit request 17 June 2024

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Remove vector-2022 from the list of skins supported by responsiveContent in the Appearance section:

responsiveContent [ResourceLoader |type=general |skins=vector, vector-2022 |peers=responsiveContentBase] |responsiveContent.js

->

responsiveContent [ResourceLoader |type=general |skins=vector |peers=responsiveContentBase] |responsiveContent.js

It seems not to be functioning of late, and TBH I don't know why it was enabled to begin with since it wasn't designed for the skin. See also phab:T367646.

Izno (talk) 15:51, 17 June 2024 (UTC)[reply]

Also, responsiveContentBase currently in Browsing for both Vector and Timeless probably should be living in the proximity of responsiveContent. Don't really care if that's in Appearance or Browsing. (Why do we have section names that are almost exactly the same in intent?) Izno (talk) 15:52, 17 June 2024 (UTC)[reply]

Done It looks like when Vector 2022 was new somebody copied all Vector gadgets to Vector 2022, and nobody noticed this since. * Pppery * _{it has begun...} 01:05, 18 June 2024 (UTC)[reply]

Protected edit request on 13 July 2024

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Please delete the sentence Please add an entry for any new gadget to the table at Wikipedia:Gadget#Currently installed gadgets to make maintenance easier. at the top. The referenced table doesn't exist since 2021 per archived discussion. —⁠andrybak (talk) 13:15, 13 July 2024 (UTC)[reply]

Done * Pppery * _{it has begun...} 17:47, 13 July 2024 (UTC)[reply]

Removal of EditNoticesOnMobile

@Izno, I just noticed you removed EditNoticesOnMobile (ENOM) 10 days ago: MediaWiki:Gadgets-definition (Diff ~1251928150)
Shortly after the native implementation was rolled out there was a question of whether ENOM was still needed. My response was that the native implementation was missing some features, so I didn't think ENOM was obsolete. Assuming the native implementation hasn't been improved since, some shortcomings are:
1. Once dismissed, edit notice can't be read again. (unless the user opens the same page in a private/incognito tab or waits 24 hours) ENOM provides a link on the edit confirmation screen.
2. Will re-show popup every 24 hours no matter what. For ENOM this is 2 weeks or longer. This could result in what I call "notice fatigue" where users may stop reading them.
3. Can't be disabled on a per-page or per-namespace basis (ENOM is disabled in file namespace here IIRC because that notice is more informational than cautionary in nature)
4. Popup is always narrow, no matter how wide your screen is.
I'm more neutral on the matter these days, I have enough worries in my personal life so fewer responsibilities is a pro for me, and one gadget less slightly reduces bandwidth and stuff I suppose. Whether or not we should have an RfC for the removal (as the gadget was installed following an RfC), I'm unsure.
Ping @Xaosflux who helped massively with the deployment of ENOM. — Alexis Jazz (talk or ping me) 16:13, 28 October 2024 (UTC)[reply]

If the primary functionality is now being supported upstream, that does seem preferable - as there would be active maintainers. Was any usage data gathered prior to decom? — xaosflux ^Talk 16:38, 28 October 2024 (UTC)[reply]

I think there is room for opinion here without supporting a fork. Some of your suggested shortcomings look more like opinion than not. Some need improvement upstream rather than continuing to maintain a gadget locally that 'forks' the now-native functionality. On the specific points:

I filed phab:T378902 for this suggestion.
That we have any limit here is different than desktop contexts, either WTE or VE. It shouldn't be: we should shoot for uniformity here as best we can and encourage upstream to think about ways this can be improved in both locations. In which case, 24 hours is much closer to the native state of things than is 2 weeks.
I don't think this is necessary in any system. If we have "informational" edit notices, I think those should just go away in toto. :)
This has an upstream task since a week ago.

@Xaosflux, "usage data" can not be gathered for default gadgets. Theoretically the user experience will have simply changed based on the noted differences between the two. Izno (talk) 16:46, 3 November 2024 (UTC)[reply]

I don't have a strong worry if someone wants to keep this as an OPT-IN alternative gadget, but agree we shouldn't compete with the default anymore. — xaosflux ^Talk 18:18, 6 November 2024 (UTC)[reply]