Module talk:Gadgets
Please sync the changes from Module:Gadgets/sandbox (diff). The following change(s) have been done:
Protected edit request on 26 January 2024
 | 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)
Protected edit request on 7 May 2024
| 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)
Done — xaosflux Talk 20:25, 7 May 2024 (UTC)
Some issues in module
@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)
- 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)
- 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)
Protected edit request on 9 October 2024
| 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)
- 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+)\nwith something like,([0-9]*)[\n,]. (untested) — Alexis Jazz (talk or ping me) 03:19, 10 October 2024 (UTC)- Yes, just changing
(%S+)\nin the Lua pattern to(%d+)should be enough – SD0001 (talk) 12:06, 10 October 2024 (UTC)
- Yes, just changing
- 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)
- 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)
- One could be done today, that one is going on a year since creation. Izno (talk) 20:59, 22 October 2024 (UTC)
- 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)
- 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)- 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)
- 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)
- 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)
- 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)
Protected edit request on 2 November 2025
{{edit fully-protected|Module:Gadgets}}
Extended content
| ||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
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)
- On second thought, it's probably line 31 that needs fixing. Consider this case (from nl:wikt:MediaWiki:Gadgets-definition):Currently,
* Calculator [ResourceLoader | default | categories = Bladsye wat die gerief "Calculator" gebruik ] | calculator.js |calculator.cssp.parse_linewould remove all spaces from the category name. That seems undesirable.
NguoiDungKhongDinhDanh 08:51, 2 November 2025 (UTC)
Protected edit request on 8 February 2026
| 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)
- 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)
Content Disclaimer
Informasi ini disarikan dari Wikipedia dan disajikan kembali untuk tujuan edukasi. Konten tersedia di bawah lisensi CC BY-SA 3.0. Kami tidak bertanggung jawab atas ketidakakuratan data yang bersumber dari kontribusi publik tersebut.
- The information displayed on this website is sourced in part or in whole from Wikipedia and has been adapted for the purpose of restating it. We strive to provide accurate and relevant information, however:
- There is no guarantee of absolute accuracy. Wikipedia is an open, collaborative project that can be edited by anyone, so information is subject to change.
- It is not intended to constitute professional advice. The content displayed is for informational and educational purposes only. For important decisions (e.g., medical, legal, or financial), please consult a professional.
- Content copyright. Wikipedia is licensed under the Creative Commons Attribution-ShareAlike License (CC BY-SA). This means that content may be reused with appropriate attribution and shared under a similar license.
- Responsible use. Any risk arising from the use of information from this website is entirely the responsibility of the user.