Jump to content

MediaWiki talk:Gadgets-definition

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

Edit request 17 June 2024

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

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:
  1. I filed phab:T378902 for this suggestion.
  2. 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.
  3. 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. :)
  4. 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]

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)[reply]

Seems fine. Izno (talk) 19:51, 20 December 2024 (UTC)[reply]
mw:Template gadgetsNovem Linguae (talk) 21:22, 20 December 2024 (UTC)[reply]
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)[reply]
Heavy as in? – SD0001 (talk) 07:59, 21 December 2024 (UTC)[reply]
Presumably the million or two rows added to catlinks. Izno (talk) 17:51, 21 December 2024 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]