Converting this script into a gadget might be a good idea since it has many users. This will help us to provide better performance, since ResourceLoader modules (including gadgets) are automatically minified along with various other features. It will load the code that is needed and saving data. Thoughts?
@DannyS712 if you agree, I believe we can port this gadget to mediawiki.org (best fit IMO) for now since you have interface adminship there. Keeping this gadget to meta is also a good idea but you don't have interface adminstrator rights there and we will have to wait on a interface admin to update the script if a serious bug pops up.
Except that the code needs to be executed on all wikis, not just when the user is on mediawiki...
T22153: Implement global gadgets (WMF-wide) would do that, but that appears to be waiting for T71445: Implement a proper code-review process for MediaWiki JS/CSS pages on Wikimedia sites
@DannyS712 I am aware that global gadgets isn't a thing at the moment. But we can just import the gadget module from Mediawiki.org. For example, https://en.wikipedia.org/w/load.php?modules=ext.gadget.dropdown-menus. The code of ext.gadget.dropdown-menus is extensively and automatically minified as you can see. Another example would be the RTRC gadget. It resides on mediawiki.org but can be loaded globally via global.js.
(mw.loader.getState('ext.gadget.rtrc') ? mw.loader.load('ext.gadget.rtrc') : mw.loader.load('https://www.mediawiki.org/w/load.php?modules=ext.gadget.rtrc&lang=en'));
After porting it to mediawiki.org as a gadget, your user subpage of the script can just mirror the gadget from mediawiki.
Yes, and making this an onwiki gadget is just a small but big step on that path. I think many users who wants a global watchlist do not know about your script. Making it a gadget will let users know about this (the Gadgets section in the preferences is a highly visited page).
True, how about making it a hidden gadget, like how gadget dependencies are added? This will remove keep the gadget hidden from the preferences page but we it will still function if we import the module via global.js until T22153: Implement global gadgets (WMF-wide) is implemented. This way people will not have to install it twice and they can still enjoy ResourceLoader features. Which is why I said making it a gadget (hidden or normal) on any project is enough. My original proposal was this. One benefit is that we can ship a lightweight version of the script while keeping the eslint, jshint and other documentation comments inside the script.
If we make it a hidden gadget, we can do the following:
- Make necessary changes to the script/would-be gadget. Split the script into multiple gadget modules if needed. Implement them as hidden gadgets.
- Then we can just deprecate the importing via your userpage JS method and redirect your userpage to the new gadget resourceloader module.
- We can ship a lightweight version of the script, better performance.
- Update the script documentation on enwiki to load the module instead of the userpage. We will not remove/hard-deprecate the previous import method, to avoid breaking its uses. We will redirect your userspace to the new resource loader module. We can notify users about this change. It is their choice if they choose to migrate the new import method.
- Importing via userpage will continue to work as I said above. Users will not notice anything significant, just the script's loading will be faster.
The script can always be split into multiple parts. There are many larger scripts, for example AQD and VFC on Commons. They work fine as a gadget. Well just copy-pasting the code isn't enough, the script needs to be modified so it can work as a gadget. I haven't looked at the full code yet. Maybe the script has some JS code that isn't supported by the ResourceLoader (T75714 is one of them). I wonder what exact problem you were facing.
The console shows a message "unclosed parentheses". Tried several variants, the message is the same, the location of opening "(" is different, but accordand ")" is always very far in the code. So my first thought was that not all the lines are accepted.
Here is an example of a "global" gadget within today's possiblities. My RTRC gadget is maintained at https://github.com/Krinkle/mw-gadget-rtrc. It is defined as gadget at https://www.mediawiki.org/wiki/MediaWiki:Gadgets-definition (rtrc.js and rtrc.css).
To use it from other wikis, I document the following snippet:
(mw.loader.getState('ext.gadget.rtrc') ? mw.loader.load('ext.gadget.rtrc') : mw.loader.load('https://www.mediawiki.org/w/load.php?modules=ext.gadget.rtrc&lang=' + mw.config.get('wgUserLanguage', 'en')));
What this does:
- Check if ext.gadget.rtrc is defined on the current wiki. This is true for example on mediawiki.org.
- If yes, then load it as a normal module. Then mw.loader takes care of making the url, the version, language code, caching etc.
- If no, then load it from mediawiki.org with lang= set to the interface language of the current user. This means that for RTL languages, the CSS will be automatically flipped by ResourceLoader.
Unlike RTRC, GlobalWatchlist has truly global functionalities. I see no need to define GW on other wikis. Just in a central wiki is enough. Since new users may get confused because of different install methods.
I'm in the middle of an RfA on wikidata, so I'm not planning to open a request anytime soon. Also, if the grant is approved this will all be moot, since I'll convert it to an extension instead. Lets wait until the grant results
[batch] My grant to create a global watchlist extension has been approved, and I will no longer be working on the user script. Please file any new bug reports and feature requests with the extension rather than here.