@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.

In T243489#5825762, @Masumrezarock100 wrote:

@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

I'm not sure what the hard part is: MediaWiki-extensions-GlobalPreferences and/or GlobalCssJs should make it pretty easy

@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.

In that case, it would probably make the most sense to host on meta wiki, since that is the "central" wiki

In T243489#5825805, @DannyS712 wrote:

In that case, it would probably make the most sense to host on meta wiki, since that is the "central" wiki

True, but I am concerned about the comments I made in T243489#5825762. You'll need to apply there for interface adminship if you wish to keep it updated as soon as possible.

In T243489#5825831, @Masumrezarock100 wrote:

In T243489#5825805, @DannyS712 wrote:

In that case, it would probably make the most sense to host on meta wiki, since that is the "central" wiki

True, but I am concerned about the comments I made in T243489#5825762. You'll need to apply there for interface adminship if you wish to keep it updated as soon as possible.

True... let me think about it. The eventual goal is an extension :)

In T243489#5825833, @DannyS712 wrote:

True... let me think about it. The eventual goal is an extension :)

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).

Making it a gadget doesn't mean that it will always be loaded - it'll still require an import in the global.js

In T243489#5827215, @DannyS712 wrote:

Making it a gadget doesn't mean that it will always be loaded - it'll still require an import in the global.js

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.

Pros:

• 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.

Cons

Any?

If we keep the gadget visible. Users may get confused because of two installing methods.

Actually, tried to do this and failed. Did not investigate what's happening, but my wild guess is that the script is too large to be a gadget. Do not know.

In T243489#5844765, @IKhitron wrote:

Actually, tried to do this and failed. Did not investigate what's happening, but my wild guess is that the script is too large to be a gadget. Do not know.

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.

In T243489#5878627, @Masumrezarock100 wrote:

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.

This line loads all CSS/JavaScript files from the gadget via one url. Combined by ResourceLoader.

In T243489#5878657, @Krinkle wrote:

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.

This line loads all CSS/JavaScript files from the gadget via one url. Combined by ResourceLoader.

On what other wikis is ext.gadget.rtrc defined? Do you need to update the source on each of those?

In T243489#5887115, @DannyS712 wrote:

On what other wikis is ext.gadget.rtrc defined? Do you need to update the source on each of those?

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.

In T243489#5887115, @DannyS712 wrote:

On what other wikis is ext.gadget.rtrc defined? Do you need to update the source on each of those?

No, it only needs to be defined as a gadget once, on one wiki (for RTRC, I choose mediawiki.org). ResourceLoader takes are of the rest.

In T243489#5899735, @Krinkle wrote:

In T243489#5887115, @DannyS712 wrote:

On what other wikis is ext.gadget.rtrc defined? Do you need to update the source on each of those?

No, it only needs to be defined as a gadget once, on one wiki (for RTRC, I choose mediawiki.org). ResourceLoader takes are of the rest.

Okay. Given that the global functionality is on meta, and that is where I have been updating it, it makes sense to define it there (imo). Thanks for the info

Nice. Metawiki or Mediawiki either one is fine to me. But my concerns in T243489#5825762 are valid. May I ask when you are planning to start a discussion there, and request for interface adminship?