Wikipedia:Interface administrators' noticeboard

Archives

Archive 1 Archive 2 Archive 3

This page has archives. Sections older than 30 days may be automatically archived by Lowercase sigmabot III.

I hope this is the right place to ask. I just noticed (from the link on commons) that the global contribs tool seems to be working again. Would it be possible to have the link added back to the contribs page here? Thanks, –Deacon Vorbis (carbon • videos) 02:10, 9 August 2019 (UTC)[reply]

Comment. I sent this user here via WP:Discord. If it's the wrong place, blame me. –MJL ‐Talk‐^☖ 02:31, 9 August 2019 (UTC)[reply]

@Deacon Vorbis: If you're talking about https://tools.wmflabs.org/guc/, it should already be there. --DannyS712 (talk) 02:32, 9 August 2019 (UTC)[reply]

That's because I just put it there :) — xaosflux ^Talk 02:34, 9 August 2019 (UTC)[reply]

@Xaosflux: oh, thanks --DannyS712 (talk) 02:37, 9 August 2019 (UTC)[reply]

(edit conflict) Done @Deacon Vorbis and MJL: I made the change, but it didn't require an IAdmin. For reference any admin can maintain that footer via Template:Sp-contributions-footer (and anyone can put edit requests on its talk page). Best regards, — xaosflux ^Talk 02:32, 9 August 2019 (UTC)[reply]

Cool, thanks all! –Deacon Vorbis (carbon • videos) 02:37, 9 August 2019 (UTC)[reply]

I'm trying to clean up the Category:Shortcut templates with missing parameters maintenance category, and the only page that's left is User:Mr. Juicyfun/common.js. Mr. Juicyfun was blocked for disruptive editing. What he's done here is copied the Module:Shortcut Lua code into his common.js file, and somehow, the Shortcut module is being called and adding the js to the maintenance category. Can the page be cleaned up so that it's no longer put in the maintenance category, either by commenting the code out or by deleting the page? Harryboyles 02:44, 17 August 2019 (UTC)[reply]

 Done @Harryboyles: this page was deleted. — xaosflux ^Talk 14:10, 18 August 2019 (UTC)[reply]

Thanks a lot.Harryboyles 09:23, 19 August 2019 (UTC)[reply]

Hi, there are a couple of Wikipedia:Geonotice requests, one from 8 August 2019, & mine from 16 August 2019. However, neither of these have been added to Wikipedia:Geonotice/list.json. Is this the right place to ask an interface administrator to take a look? Peaceray (talk) 05:00, 19 August 2019 (UTC)[reply]

@

WP:AN instead. --DannyS712 (talk) 05:49, 19 August 2019 (UTC)[reply

]

It's okay, he didn't know. Peaceray, you're welcome to post here, even if you think that it might belong elsewhere. :-) ~Oshwah~^{(talk) (contribs)} 09:33, 22 August 2019 (UTC)[reply]

Sorry, I didn't mean to imply otherwise - of course you can post here, but if its urgent AN may be more help. Glad it was resolved --DannyS712 (talk) 09:34, 22 August 2019 (UTC)[reply]

I've fixed up the directions for getting help on that. — xaosflux ^{<spanstyle="color:#009933;">Talk} 11:52, 22 August 2019 (UTC)[reply]

Thanks everybody. Yes, there were a couple of places in Wikipedia:Geonotice that pointed to here. I took care of one & xaosflux took care of the other. Peaceray (talk) 04:19, 23 August 2019 (UTC)[reply]

Would an interested interface admin please close and implement the consensus at Wikipedia:Village pump (technical)#Enable chess PGN viewer for chess articles? Wug·a·po·des​ 23:59, 22 August 2019 (UTC)[reply]

I'm seeing support that some people want this, but it looks like there is still some discussion on "HOW" to make it happen. Pings to @Galobtter and Izno: who were involved in that discussion. @Wugapodes: can you spell out exactly the technical changes you are asking for below (or are you asking for someone to create the technical solution)? For any of these changes, has this been tested here yet? — xaosflux ^Talk 00:39, 23 August 2019 (UTC)[reply]

As far as using this for changing the display of an article to our readers, what is the expected fall-back article state for readers without javascript, those using screen readers, etc? — xaosflux ^Talk 00:42, 23 August 2019 (UTC)[reply]

@Xaosflux: These are good questions to which I don't have great answers off the top of my head. @קיפודנחש: might know how they answered this question on the Hebrew Wikipedia; when I turn off javascript and navigate to a chess article page, it alerts me that I need to enable javascript to see the game. That may or may not be a fall-back state we want, I also see the merit in simply not displaying anything, but ideally the fallback state would not display the raw PGN to readers without javascript as it is unlikely to be useful to them. I'm not familiar with how screen readers work and what they pay attention to in the HTML, so if anyone has knowledge or input on that point, it would be appreciated. As you've probably already realized, the specifics of MediaWiki gadgets is not exactly my strong suit, and while I propose(d) a particular implementation I also recognize a lot of people have way more knowledge on this than I do. I would welcome anyone giving what they believe is a better solution than this one.

The idea is that there would be a template which takes as its input the raw PGN text and wraps it in an HTML tag with a ".pgn-source-wrapper" class. I suggested a <div>, but there are likely better solutions which would play nicely with screen readers and disabled javascript. It would be this element which the javascript looks for and processes. While Galobtter has a solution which is likely more elegant, I don't understand it fully and will leave to them to explain so that I do not mess it up. The implementation which I understand and have in the proposal is that the javascript and css currently in use on the Hebrew Wikipedia is copied to EnWikipedia. These files would be placed in MediaWiki:Gadget-pgnviewer.js and MediaWiki:Gadget-pgnviewer.css respectively, though there may be a more standard naming convention. MediaWiki:common.js would then be modified to load the gadget if it encounters a page with an HTML element having the ".pgn-source-wrapper", otherwise it would not be loaded to avoid unnecessary resource usage on the many pages that do not need it. Wug·a·po·des​ 01:33, 23 August 2019 (UTC)[reply]

• I'm certainly a bit wary about running any script on every single page for every single reader just to see if there is a class that will be on <0.1% of articles. As far as fall-backs go, this isn't going to run for our huge number of readers on mobile, or on the wikipedia app this way. Is this only expected for desktop readers? — xaosflux ^Talk 02:21, 23 August 2019 (UTC)[reply]
  • That's understandable and a number of people, I think Izno was one, were concerned about that point as well. Galobtter I believe had a more typical solution? From what I understand, they suggested setting it as a default gadget, but in a way specific to the English Wikipedia. I think Galobtter explains it best here. From that comment it seems that the core gadget, in this case probably MediaWiki:Gadget-pgnviwer-core.j, would be loaded on demand by another gadget, MediaWiki:Gadget-pgnviewer.js. MediaWiki:Gadget-pgnviewer.js would be loaded as a default gadget, and that would be set up like MediaWiki:Gadget-geonotice.js which only loads the script when we need it to. Whether that is any different in terms of performance than the solution I suggested I am not really sure. Is your concern that searching the page in either case would still be a problem? I notice that MediaWiki:Gadget-geonotice.js only needs to perform a string comparison to check whether it should run. Wug·a·po·des​ 04:32, 23 August 2019 (UTC)[reply]
    • My initial concern is creep, having to load a different "is x here" on every single page read, for every single thing that someone may want to do something similar for will grow bloated. These cases are often better served by extensions (think of the media players, or even something small like the music score (probably a good example % of articles size). I'd like to hear more from Galobtter. If we really want to do this perhaps a check for some sort of "locally enhanced elements" that would only require 1 check that would then call the additional related helpers? — xaosflux ^Talk 11:22, 23 August 2019 (UTC)[reply]

Sorry for not having a great understanding of the technical implementation, but thank you for being so helpful by explaining what shortcomings you see. I've been reading up on extensions in the hopes that I can get this implemented at some point, and I get the sense that the most viable path is through an extension. Sorry if this is a bother, but would anyone be able to answer some questions I still have about extensions and perhaps give feedback on two possible implementations I'm thinking over?

• Are extensions exclusively written in PHP?
• Since extensions seem to run server side rather than client side, is it able to effectively handle interactive content such as the back and forward buttons on the chess game viewer?

If this were to be turned into an extension, my current idea is for the extension to output a chess board and the navigation interface in HTML so that the client-side javascript does not need to. It would use unicode glyphs for the chess pieces rather than images. I've got a working example in my sandbox at User:Wugapodes/sandbox4 (though it requires some css in User:Wugapodes/common.css to render properly), and I tested it with the GoogleVox screen reader which handles it well. Since it is in HTML and CSS if javascript is disabled the fallback would be displaying the starting position output by the extension.

I get a little stuck at this point with how to allow for the interactive content, hence the second question. For this to be server-side my understanding is that every click would require a get request from the server which does not seem ideal. An alternative would be to have a gadget which defines functions that are called when the interface buttons are selected, and these functions would change the board state. So while it would be on by default, other than the function definitions the javascript which makes it work would only be run when a user clicks a button on the interface which was constructed by the extension server-side. Many people are rightfully wary of site-wide javascript, but since I don't have the same depth of knowledge I'm not sure I can accurately evaluate which course would be better. Do these seem like they would work and move us in the right direction? Wug·a·po·des​ 21:12, 23 August 2019 (UTC)[reply]

The extension would have a PHP part that defines a tag (like extensions give us <ref> or <syntaxhighlight>), and a JS part that's basically the gadget which is loaded on the page by the use of the tag. Anomie⚔ 23:06, 23 August 2019 (UTC)[reply]

some answers to questions and reservations above

so i was mentioned above, with some questions. i will try to describe what we do on hewiki, and the rationale.

1. javascript disabled: we display a message saying something like "this space is for the interactive game. in order to see it, enable javascript on your browser". IMO, this is reasonable: in a similar fashion, people reading wikipedia with text readers do not see images and videos, but this is not good reason not to show images and videos to the vast majority of readers who _can_ see images and videos. we do not display the raw PGN on hewiki, even though a reasonable reader of a chess article is likely to find it useful (more precisely, they'll find the "algebraic notation" part of the PGN useful). one reason not to display it, is,the fact that we tend to use the viewer to display multiple games (e.g., all the games of a championship, or the games of one round of a tournament, in a single viewer with game selector), and displaying all of them is not reasonable, and displaying just one is too arbitrary.
2. mobile: this one is easy. if you activate the viewer on mobile (via Mediawiki:mobile.js), it works fine for mobiles too. it specifically sense for "minerva" skin, and displays without the tabs, as the tab library is not mobile-friendly. the question of "how does it look" on mobile is delicate: the script and css are somewhat "responsive", but on small enough devices it's less useful, e.g: on iphone 4, you can see the full board and notation, but you have to scroll to see the buttons and click "play". presumably, once you hit "play", scroll back a bit to see the full board). on "regular" iphone 6/7/8 (not "plus"), galaxy 5 and 6, and most other devices on the chrome simulation, it displays impeccably. what i'd suggest is to open, e.g., he:משחק האלמוות, and switch to mobile view. if you happen to use chrome, you can simulate different devices by clicking F12 and then hit the "mobile" icon at the left of the top toolbar. chrome will let you select the device, and the orientation. ruwiki, i believe, chose not to activate it on mobile. enwiki should choose. naturally, i believe what we did in hewiki (activating on mobile) is the better option. (note: if you use BRION's "mobile simulation, remember it's pretty old - it simulates a device significantly smaller than today's norm).
3. cost of scanning the page to test for "some class", and worry about "creep": personally, i don't worry. practically, this is something our software already does dozens of times on each page load, and i think the cost (jquery) is negligible. i do not think "creep" is something to worry about at this point. if this becomes a real worry, i outlined in wp:vpt what ruwiki does, and what hewiki does in this regard: basically, safe and simple "on-demand" loading of scripts, which requires a single test for specific class in common.js, and loads all the content-dependent scripts when needed. adding a new script that can be loaded "on-demand", does not add the code run on page load for pages which do not need it, so once you implement this mechanism, the "creep" stops. i am not advocating for enwiki to adopt this mechanism ATM, i mentioned it here just to say that we can use such scripts with no "creep", and indeed, this viewer on hewiki and ruwiki adds zero code to each page load. there are ~ 10 lines in common.js (and on hewiki, another 7 on mobile.js), which run once, and handle all the "on demand" scripts. hewiki has about half a dozen such scripts, and ruwiki may have a bit more.

some more comments

now, the viewer is somewhat "configurable", by the template that activates it. the actual implementation of the template that generates it sets all those params. so the viewer behaves differently on ruwiki and hewiki. this is because the ruwiki and hewiki templates used for the viewer, provide it with different configurations, even though ruwiki did not copy the script locally, and loads it from hewiki when needed, so both literally run exactly the same script. if enwiki is to install the viewer, it should decide on parameters. local CSS modifications are also an option. so if enwiki is to activate the viewer, there are some decisions to make, regarding how enwiki wants it to behave. i would suggest consulting the chess community about the choices enwiki wants to make.

DISCLOSURE: i really really want to see this activated on enwiki, and it will give me some small ego boost, so please, do not hesitate to ask questions, and ask for my help. i will assist in any way i can, including actually doing some of the work (someone granted me "template editor" perms on enwiki, so there are some things i could do), and including making reasonable modifications to the viewer code.

peace - קיפודנחש (aka kipod) (talk) 04:37, 24 August 2019 (UTC)[reply]

קיפודנחש have you tried publishing this as an extension? Seems like that would make it a lot more adoptable, not to mention maintainable across projects (including non-WMF projects). — xaosflux ^Talk 22:40, 24 August 2019 (UTC)[reply]

@Xaosflux: no, and i am not going to. i briefly peeked into it, and as far as i can tell, it's a lot of bureaucracy, with little or no perceived value in this case. extensions make sense for extending the functionality on server side, and less so as a vehicle to send JS code to the client. getting it "sanctioned" as safe would be nice, but that's it, and it's not enough, considering the cost of making it an extension.

afaik, there already _is_ pgn viewer extension: mw:Extension:PgnJS. i briefly looked into it (TBH, i looked into it before writing my viewer, and though i think the code have improved since, i still don't like it). dozens of files, many thousands of lines, multiple CSS. IMO, it's not a well engineered piece (and i could not find any demo site). please look at both viewers code - "mine" is a single source file, with less than 1000 lines, and single CSS, with some 120 lines. read the code of both, and compare. i don't think the extension is "more adoptable".

i mentioned "making reasonable modifications to the viewer code" - unfortunately, making it an extension is outside this scope. peace - קיפודנחש (aka kipod) (talk) 23:43, 24 August 2019 (UTC)[reply]

For what it's worth, I'm looking into how viable it would be to turn this into an extension and would be willing to go through the bureaucracy if it means we get an interactive chess game viewer. I tried the test wiki linked to from mw:Extension:PgnJS, but it crashed in my browser so while a good place to start looking, I think more work will be needed. There's still a ton of things I don't know, but Kipod's JS could probably still be used and may actually be an improvement. PgnJS is rather big and has a number of dependencies that Kipod's script doesn't have. If the PGN parsing was moved out of his script and into PHP, the extension would probably be pretty light and efficient. Wug·a·po·des​ 05:15, 25 August 2019 (UTC)[reply]

• My code creep concern is that while doing this for "chess viewer" isn't expensive, then we get another scan for "chemical viewer", "spaceflight path viewer", "dice roller", etc, etc. I still think that extension in general are better for these, but if we want to do this client-side we should plan for the future at the same time. Do you see any drawbacks to a multi-step process of: (1) single client check for "enhanced local content class" (2) Load the "enhanced local content manager" (3) load the script? In that method (1) can be very small and light and resuable for future enhanced content. This is meant to be high-level and some of these may be better "load the gadget). — xaosflux ^Talk 14:57, 25 August 2019 (UTC)[reply]

  IMO good should not be the enemy of perfect here - it would be nice if this was an extension, and if someone wants to put the effort into that (or vote for doing that in the community wishlist?), that would be good, but a gadget is still good to have. One - or even many - JQuery selector checks should not be particularly expensive either: their speed would be measured probably in the tens of thousands of operations per second. Nothing against a generic loader of enhanced local content, but if there is only gadget that can make use of it, I would personally wait until or if there are more gadgets doing such checks, to do that. Galobtter (pingó mió) 23:07, 25 August 2019 (UTC)[reply]

(edit conflict) before everything, disclaimer: i tend to be long-winded, and some would say tedious. sorry about that, but i'm going to be long-winded (at least) one more time - i interpret some of the above as questions addressed to me, and i'll try to answer the best i can.

@Xaosflux: - i don't want to sneeze at your concern, but (1) i don't see all those "on demand content-modification scripts" you mentioned. i did not see any "chemical viewer" or "spaceflight path viewer" or any of the other you mentioned proposed (TBH, i didn't see any of them at all) if there were such proposals which i missed - my bad. IMO, refusing something good because of some hypothetical "slippery slope" concern, which have no evidence of being real, is not good policy. (whether or not this viewer is "something good" is a different question. the consensus on wp:vpt seems to indicate it might be).

as to your question: this can be done simpler than what you alluded to "multi-step process of: (1) single client check for "enhanced local content class" (2) Load the "enhanced local content manager" (3) load the script?". i outlined in wp:vpt what ruwiki is doing (10 lines in ru:mediawiki:common.js, from #321) and what hewiki are doing (12 lines in common.js, plus 7 in mobile.js). see line #261 and forward in he:Mediawiki:common.js. i will outline it here again:

1. in common.js, look for one specific class (we use "executeJS").
2. for each element found with this class, look for "data-script" and "data-gadget" attribute (in mobile.js, look, e.g., for "data-mobile-gadget")
3. the content of the data attribute, indicates which script or gadget should be loaded. these scripts and gadgets must reside in a very specific place in mediawiki namespace: for scripts, their name _must_ look like "Mediawiki:Script/<script name>.js", and for gadgets, they _must_ be hidden gadgets whose name look like "Mediawiki:Gadget-ondemand-<gadget name>" (gadgets in hewiki only- ruwiki does not use this mechanism for gadgets). naturally, it means interface editors should vet the scripts and gadget that match these patterns as if they are vetting common.js itself.
4. from usability POV, this is exactly the same as "template styles": in a similar manner to the way a template can demand some extra CSS, by loading a "templatestyle", a template can demand some extra JS, by transcluding a template called "Script load", and passing the desired script as parameter. the mechanism is simple, contains almost no "moving parts" (10 lines in common.js and one template), safe, cheap, and adds a useful functionality. we (hewiki) use it for several such scripts: not those you mentioned, but, e.g., a script that enhances the usability of "image map", a script that allows use of "Tabs" (mainly in "portal" namespace), without having to always load the tabs library, the pgn viewer, and some more.

so bottom line: i'm not sure i fully understood your description, but inasmuch as i did, it sounds more complex than it should be. there is no need for "enhanced local content manager". those unenhanced dozen lines in common.js do it as well as it can be done.

if you ask i i'd recommend enwiki to copy this mechanism - i think the fact this is what hewiki does is all the recommendation i can give. i did take part in the discussions and in the implementation, and i think it's good and useful.

if think about doing something similar, i suggest you read 2 sources linked above, note the differences, and either use one or the other, or do something similar yourself (for hewiki, we use this mechanism for mobile too, so there's some code in mobile.js too).

@Wugapodes: feel free to do with this script anything you like - please read the "license" at its top. it is much more liberal than CCbySA. it basically says "do whatever you want with this". FWIW, i do not think wrapping it in an extension will add any value. you write "If the PGN parsing was moved out of his script and into PHP, the extension would probably be pretty light and efficient". if i may say so myself, the currnent implementation is already light and efficient. (FWIW, i did write another PGN parser in LUA (which is also used on enwiki), and is used to display multiple {{Chess diagram}}s from a single game, by passing to the template the PGN, and list of positions you want to show from the game)

iiuc, what you propose is for the extension to parse the game, and then pass this parsed game, using some notation you'll have to invent, to the script. forgive my french, but this is back-assward. we already have a perfectly good (and standard) notation to describe the game - it's called algebraic notation or pgn. the script does not break a sweat parsing the PGN, and your proposal describes a bad solution to a problem that does not exist.

bottom line: i see zero value in wrapping this in an extension (getting the "this is safe" seal from mediawiki team will be sweet, but this is a "political", not a technical consideration). you are welcome to do it, of course, but i do not think it will be good investment of your time.

@Galobtter: i totally agree (i know you did not really ask me, but anywhoo).

peace - קיפודנחש (aka kipod) (talk) 00:12, 26 August 2019 (UTC)[reply]

As far as using something reusable, what is the scope of the deployment for chess viewer expected to be? Even if this was used on every single page in Category:Chess recursively (which is a stretch) this would be used on <~0.01% of pages for an extra script that is needed on every page view. That is why I'm suggesting that if we want to do support for minority use scripts that we give them a single wrapper/loader so that when the next project comes along we don't have to have this discussion again. — xaosflux ^Talk 01:57, 26 August 2019 (UTC)[reply]

I would like to get the opinion of a WMF engineer. Jdl seems like a good resource here, but I'll take as many opinions as not. (I'm not sure who all has experience with JavaScript.)

As for the current fallback content on the external wikis, absolutely not ok. Advanced gadgets should fail or degrade gracefully; this case should naturally leave the Pgn visible.

This should still be an extension, regardless. It will be extra JavaScript (however small) delivered to every user of the platform, for benefits on some tiny proportion of articles; an extension would take care of that price. The other clear and obvious benefit is multi-wiki/multi-tool support in a way adding this script piecemeal will not provide. --Izno (talk) 02:15, 26 August 2019 (UTC)[reply]

I've managed to get mw:Extension:PgnJS set up on a test installation of mediawiki 1.33.0 and it seems to work fine. When javascript is disabled, it does not display any output. As a place to start, that seems the best option. I'm not sure if it passes the security standards to be deployed on the English Wikipedia, so that would need to be figured out and potentially fixed before anything else. Eventually the back end should probably be replaced with Kipod's code; the extension has not been updated in two years and it is worth having code that someone knows and actively maintains over potentially stale code. What does everyone think of that? Wug·a·po·des​ 03:14, 27 August 2019 (UTC)[reply]

• For whatever my opinion is worth, I've been following that discussion off and on, and I pretty much agree with Galobtter: I think it's a good enough solution to convert the code and loader into a gadget and include it in the gadgets section. I definitely would *not* support modifying common.js directly, but that shouldn't be necessary if we make things a gadget. I don't know that anything more heavyweight, like extensions, needs to be done. Writ Keeper ⚇♔ 14:52, 27 August 2019 (UTC)[reply]

  @Writ Keeper: I'm not opposed to the gadget route - as far as implementation what do you think of my idea of a generic "loader gadget" that then spins up any needed other gadgets (vs an always-on gadget, or a feature specific loader gadget that loads the feature gadget)? — xaosflux ^Talk 15:00, 27 August 2019 (UTC)[reply]

  Mmm, I feel that what prevents the proliferation of loader scripts for minority applications from being a problem is simply that, being gadgets, they can be turned off in Special:Preferences if you don't like the performance hit. I do like your common loader idea, though. Something like: create the code for gadget <X> in Mediawiki:gadget-<X>.js, per usual, but make the common loader class the only defined dependency of <X> in Mediawiki:Gadgets-definition, so that the only resource that's loaded on pageview is the common loader (i.e. <X>[ResourceLoader]|commonLoader.js). Then, it can go through and do something like:

  if(mw.user.options.get("gadget-<X>") == 1) && $(".<enhanced HTML class name>").length > 0)
  {
  	mw.loader.load("/w/index.php?title=Mediawiki:gadget-<X>.js&action=raw&ctype=text/javascript");
  }
  

  ...as a check to load the gadget itself, for each gadget that is supported by the common loader. Is that like what you're thinking of? Writ Keeper ⚇♔ 15:26, 27 August 2019 (UTC)[reply]

regardless of the actual mechanism to trigger the load, i think it's best to place the actual code in a hidden gadget, so the parameter you pass to the loader is not "/w/index.php?title=bla", but rather "ext.gadget.bla". some advantages are minimization, dependencies, and loading both js and css in one operation.

as to the triggering mechanism: personally, i do not see 3 lines added to common.js as a deadly sin - look at the content of this file now. it's filled with "special cases" stuff that do more work than sensing for a class and calling the loader, also for a small number of cases (BTW: this "extraJS" and "ExtraCSS" from address line seems fishy. what are they for?).

ALSO: some change to mobile.js can't be avoided if this is to work for the > 50% mobile readers (as mentioned, the viewer is happy to show on mobile - i suggest you try it on hewiki [ruwiki chose not to activate for mobile] ). peace - קיפודנחש (aka kipod) (talk) 17:07, 27 August 2019 (UTC)[reply]

Moving forward

Wanted to bump this again for those who are still interested. @Xaosflux and Writ Keeper: you both seemed to have been having a productive discussion on implementation; what are your thoughts on how to move forward with this? Wug·a·po·des​ 23:16, 1 September 2019 (UTC)[reply]

In case there are some who have not examined the relevant lines from the Hebrew Wikipedia common.js file, here it is:

// On demand loading of scripts and gadgets, initial version from ruwiki.
// Detects uses of templace "טען סקריפט"
// and loads specifically-named scripts or gadgets.
// for a script to be loadable this way, its name must begin with "Mediawiki:Scripts/"
// for a gadget, its name as defined in gadgets-definition must begin with "ondemand-"
if ( mw.config.get('wgCanonicalNamespace') !== 'Special' ) 
mw.hook( 'wikipage.content' ).add( function( content ) {
		var beenthere = {};
		$( '.executeJS', content ).each( function () {
			var script = $( this ).data( 'scriptname' );
			if ( script && $.trim( script ) ) {
				script = $.trim( script );
				if ( ! beenthere[script] )
					mw.loader.load( "/w/index.php?title=Mediawiki:Scripts/" + script + ".js&action=raw&ctype=text/javascript", "text/javascript" );
				beenthere[script] = true;
			}
			var gadget = $( this ).data( 'gadgetname' );
			if ( gadget && $.trim( gadget ) ) mw.loader.load( 'ext.gadget.ondemand-' + $.trim( gadget ) ); // np repetitions - resourceloader takes care
		} );
} );

As Kipod said, for each element with an "executeJS" class, the data attributes for scriptname and gadgetname are examined and the corresponding code loaded. This implementation is generic and will be able to accommodate future on-demand scripts, if desired and approved to be available to the on-demand mechanism. As suggested earlier, if the English Wikipedia implementation were to be limited to on-demand gadgets, the loading code could be put into a special on-demand loader gadget that is a dependency of the gadget. isaacl (talk) 17:43, 3 September 2019 (UTC)[reply]

The following interface administrator(s) are inactive:

• Evad37 (talk · contribs · blocks · protections · deletions · page moves · rights · RfA)

— JJMC89 bot 23:19, 28 August 2019 (UTC)[reply]

 Done notified user and removed. — xaosflux ^Talk 01:49, 29 August 2019 (UTC)[reply]