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

Please sync the changes from Module:Gadgets/sandbox (diff). The following change(s) have been done:

• fix get_usage function for gadget names that have hyphen (-) in them. Bug can be seen at MediaWiki:Gadget-dark-mode-toggle.js where it currently shows -1 users.

– SD0001 (talk) 17:50, 26 January 2024 (UTC)[reply]

 Done * Pppery * _{it has begun...} 19:59, 26 January 2024 (UTC)[reply]

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

Please sync from Module:Gadgets/sandbox (diff). This fixes "used by −1 users" at MediaWiki:Gadget-popups.js. Nardog (talk) 11:07, 7 May 2024 (UTC)[reply]

 Done — xaosflux ^Talk 20:25, 7 May 2024 (UTC)[reply]

@SD0001: currently, this module seems to remove all spaces, even where they are now legitimate, like the new |categories= keyword. See, for example, ru:MediaWiki:Gadgets-definition#ondemand. I tried fixing it locally by replacing the trimming with mw.text.trim but that makes Module:Validate gadgets to no longer work correctly with items containing spaces, see the top of ru:MediaWiki:Gadgets-definition.

Additionally, Wikipedia:GUS2Wiki seems to be updated differently in other wikis, where CSV also includes info on active users. I believe that can be fixed with this change. stjn 01:07, 9 October 2024 (UTC)[reply]

Feel free to propose the edits here using {{sudo}}. I don't have direct edit access either. – SD0001 (talk) 03:43, 9 October 2024 (UTC)[reply]

The problem was that I didn’t really know how to solve this issue. Now I think it just requires multiple edits: remove trimming in Module:Gadgets and then add trimming to Module:Validate gadgets. But maybe you as the author can propose a better solution. stjn 23:44, 9 October 2024 (UTC)[reply]

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

Please merge this edit into the module code. It supports the re-use of the module in other wikis, as clarified by the comment in ru:Обсуждение участника:Alexis Jazz. stjn 23:46, 9 October 2024 (UTC)[reply]

Stjn, this could be done more neatly by adjusting regular expression above it. I'm unsure about the regex syntax within Lua, but I'm thinking you could replace ,(%S+)\n with something like ,([0-9]*)[\n,]. (untested) — Alexis Jazz (talk or ping me) 03:19, 10 October 2024 (UTC)[reply]

Yes, just changing (%S+)\n in the Lua pattern to (%d+) should be enough – SD0001 (talk) 12:06, 10 October 2024 (UTC)[reply]

I wonder if a more fruitful endeavor might be for the AJ's script to poop out a JSON content page and then the module doesn't have to hack, it can just consume. Izno (talk) 03:33, 22 October 2024 (UTC)[reply]

The no-hacks solution is phab:T354890, after which the extension itself would export the data. Until then, I think a bit of string pattern matching is fine. – SD0001 (talk) 19:40, 22 October 2024 (UTC)[reply]

One could be done today, that one is going on a year since creation. Izno (talk) 20:59, 22 October 2024 (UTC)[reply]

Since it is potentially many more pages in other wikis as well for what is a pretty small use case (and not that useful for anything other than this module, tbh), the current way is better, IMO. stjn 16:09, 23 October 2024 (UTC)[reply]

Izno, there is a global JSON already at m:User:Alexis Jazz/GUS2Wiki.json but not locally.
After looking into it, I suspect the reason I didn't create local JSON pages is that AFAIK I'm not allowed to create JSON pages outside my own userspace. For a single wiki any admin can rectify this issue obviously (just change the page content model), but my script can edit hundreds of wikis and I don't want to argue with the admins of every single one. This leaves the following options:
1. Create the JSON in my own userspace. I dislike this idea, it should be in a neutral namespace. It would also prevent other users from updating that page.
2. Just create the /json subpage with the wikitext content model. If Lua can read it regardless (can it??), maybe the page content model doesn't matter, but it seems ugly.
3. Find a global sysop to run GUS2Wiki at least once so the pages can be created with the correct page content model.
For now, Wikipedia:GUS2Wiki/json will be updated on English Wikipedia only until this is sorted out. — Alexis Jazz (talk or ping me) 14:48, 28 October 2024 (UTC)[reply]

I've changed the model here. I don't super mind doing it either way locally, it just seemed more fruitful. You can do whatever you want on other wikis - the module that consumes it here is in use on only 6 others.

If Lua can read it regardless (can it??) loadJsonData can't. It looks like maybe jsonDecode may be able?

I bet you could probably also find a global sysop too.

It looks like a 4th option might be moving m:User:Alexis Jazz/GUS2Wiki.json to a Commons data table? Izno (talk) 15:58, 3 November 2024 (UTC)[reply]

Or for that matter, uploading the series of tables for each wiki separately e.g. Data:User script use/en.wikipedia.org.tab or whatever. (Naming is a bikeshed that someone else can paint.) Izno (talk) 16:10, 3 November 2024 (UTC)[reply]

 Done Made the change suggested by SD0001, but I think looking at the other option remains fruitful. Izno (talk) 16:07, 3 November 2024 (UTC)[reply]

{{edit fully-protected|Module:Gadgets}}

Many patterns in p.parse_line can be simplified. After line 31, opts no longer contains any whitespace characters, so %s* and :match("^%s*(.-)%s*$") are redundant. |? does nothing since [^|]+ already excludes pipes. Due to the same reason, [^=|]+ can also be simplified to [^=]+. NguoiDungKhongDinhDanh 08:21, 2 November 2025 (UTC)[reply]

On second thought, it's probably line 31 that needs fixing. Consider this case (from nl:wikt:MediaWiki:Gadgets-definition):

* Calculator [ResourceLoader | default | categories = Bladsye wat die gerief "Calculator" gebruik ] | calculator.js |calculator.css

Currently, p.parse_line would remove all spaces from the category name. That seems undesirable.
NguoiDungKhongDinhDanh 08:51, 2 November 2025 (UTC)[reply]

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

Instead of trimming spaces at the start and at the end of the options, spaces are removed completely. It is incorrect since sometimes options contain meaningful spaces, e.g. category names in gadgets definitions. This can be fixed by an edit like this. colt_browning (talk) 16:59, 8 February 2026 (UTC)[reply]

It isn't quite as simple since we'll then need to strip whitespaces around commas in option values. – SD0001 (talk) 20:37, 8 February 2026 (UTC)[reply]