Template talk:Script doc auto

For the discussion that lead to the creation of this template see MediaWiki talk:Clearyourcache#Script documentation.

1: I have done some more thinking and I think we can let this template do its detection in all namespaces. For the .css and .js pages in MediaWiki space we usually don't have a doc page. But if people start to add doc pages there then it would be convenient to have this template link to them too. (Well, we should not add doc pages in MediaWiki space for performance reasons, but redirects to doc pages are probably okay there.)

2: A possible extension of this template would be to detect if for instance a .js page has an accompanying .css page. Then it could output something like this:

This script seems to have a documentation page at User:Davidgothberg/clock and an accompanying .css page at User:Davidgothberg/clock.css.

And when there is no doc page but only an accompanying .css page:

This script seems to have an accompanying .css page at User:Davidgothberg/clock.css.

A funny but useful effect would be that MediaWiki:Common.css and MediaWiki:Common.js would then automatically link to each other. If we don't want that then we can of course modify this behaviour in the MediaWiki space.

3: We could show the editnotice of a script, above the script. But we should probably only do that for MediaWiki space. See for instance MediaWiki:Common.css and its editnotice Template:Editnotices/Page/MediaWiki:Common.css. For all other spaces we should probably just link to the documentation for the script. Otherwise people might start to use the editnotice as the documentation page for the script, which would be weird.

--David Göthberg (talk) 13:41, 14 December 2009 (UTC)[reply]

Looks good! Concerning your last remarks at MediaWiki talk:Clearyourcache, and without having looked at the template source, some incoherent thoughts:

• Only pages in User and MediaWiki space handle .js/.css specially and consequently show the Clearyourcache message, right? However, people might want to place scripts in Wikipedia space as well, but they'll need to invoke the template manually. Project space is probably too diverse, and things like (Wikipedia:Articles for deletion/User:Aditya Kabir/monobook.js should not automatically gain a documentation link anyway (even if we found a message where to transclude this template from).
• Showing it in User and MediaWiki space if the doc page exists should be the desirable behavior. However, I'm unsure about the best course in MediaWiki space. What was the actual problem with the edit notices in MediaWiki space: the number of bytes in the cache, or the number of messages? If the latter, placing the documentation in MediaWiki talk right away would be a solution, but would be inconsistent, so for now, I agree we shouldn't worry about performance too much unless told otherwise.
• Having a redlinked documentation page would go a long way to standardize script documentation here on en-wiki. However, displaying the redlink on people's skin scripts (monobook.js) and inviting them to document those would be weird in almost all circumstances, so those would need to be excluded. Not sure about the MediaWiki js files, documentation for the gadgets is usually in some Wikipedia page, since nobody ever uses the scripts there directly.

Amalthea 16:05, 14 December 2009 (UTC)[reply]

Oh, I wasn't aware of that MediaWiki only handled .js and .css pages as scripts when in User and MediaWiki space. But as you state, that kind of is a good thing, so we only need to think about those two spaces.

I don't know if the size or number of messages is the problem in MediaWiki space. What I do know is that the servers keep all the MediaWiki messages in RAM at all times, thus any message we add takes up RAM in the servers. So my guess is that both the number of messages and the size matters, since there probably is some overhead per message. But I know that loading from a template into MediaWiki space does not cost RAM in the servers, since that template only gets cached the normal way. So we don't need to worry much about the size of templates we use in MediaWiki space. But the number of .css and .js pages in MediaWiki space is pretty low, so if we would add documentation there by putting a redirect in the "doc page" of those pages, then it probably would not cost much. That redirect should then go to a page in "Wikipedia:" space or so. But personally I think it would be better to instead show the editnotice on top of the .css and .js pages in MediaWiki space. Then people can add links in those editnotices instead, and in many cases we already have such links in those editnotices.

Right, if we add red links to possible documentation pages, then we should not do that in MediaWiki space, and not on the standard user skin scripts like /monobook.js. The red links could look something like this:

Example 1:

This user script could have a documentation page at User:Davidgothberg/mytools.

The texts I use in these boxes might need some improvements, suggestions are as always welcome.

So what I am saying is this:

• When in user space we should show links to doc pages and perhaps also red links to doc pages if they don't exist.
• When in MediaWiki space we should instead load the editnotice of the page.
• We can also link between .js and .css pages that has the same name. I think we can do so both in User space and in MediaWiki space. (For instance some gadgets have both a .js and a .css page so it would be neat to auto-link between them.)

--David Göthberg (talk) 17:29, 14 December 2009 (UTC)[reply]

Sounds good! And I looked it up in MediaWiki's Title.php, it's really only MediaWiki space pages and User space subpages ending with .css or .js (i.e. not User:Foo.js). Amalthea 18:12, 14 December 2009 (UTC)[reply]

Ah, nice that you like the extension ideas. And thanks for checking the MediaWiki code.

I have now deployed the basic version of this template: It is only active in user space and only links to existing doc pages. I will wait some days with adding the rest of the functionality to give people some time to come here and comment. It looks good on for instance User:Davidgothberg/clock.js.

I noticed that when I edit scripts then this template isn't visible. So we should add this template to some of these messages: MediaWiki:Usercssjsyoucanpreview, MediaWiki:Userinvalidcssjstitle, MediaWiki:Userjspreview, MediaWiki:Usercsspreview. But we should not add it to all of them, since then this message will show twice under some circumstances. I'll look into that.

--David Göthberg (talk) 20:11, 14 December 2009 (UTC)[reply]

Great, thanks! Amalthea 20:59, 14 December 2009 (UTC)[reply]

I have now deployed the function that says "This script seems to have an accompanying .css page at User:Davidgothberg/clock.css". For the time being I didn't bother to filter out the user skin files like /monobook.js, so they are are now linking between their .css and .js versions, if both exist. But that is kind of nice. If/when we add red links to possible doc pages then we of course have to filter out the user skin files.

--David Göthberg (talk) 00:50, 15 December 2009 (UTC)[reply]

Yes, it could have a documentation page, but it could just as easily not. That template almost makes it look like one is obliged to create a dcoumentation page. Not sure I like it, personally, but meh. Ale_Jrb^talk 11:28, 16 January 2010 (UTC)[reply]

I agree that the text I show above is to strong, but I couldn't come up with any better text at the time. And that's one of the reasons why I have not deployed that part yet. But how about one of these?

Example 2:

Documentation for this script can be added at User:Davidgothberg/mytools, but some scripts don't need any documentation.

Example 3:

Documentation for this script can be added at User:Davidgothberg/mytools, but not all scripts need documentation.

Example 4:

Documentation for this script can be added here, but not all scripts need documentation.

Example 5:

If this script needs documentation, it can be placed at User:Davidgothberg/mytools.

Example 6:

If this script needs documentation, it can be placed here.

I'm not sure which one I prefer. Other suggestions are of course very welcome.

--David Göthberg (talk) 12:14, 16 January 2010 (UTC)[reply]

Perhaps the first one, but without the 'but some scripts don't...' part. So,

Documentation for this script can be added at User:Davidgothberg/mytools.

That makes it sound more like it's a possiblility, rather than something that should be done. Hmm... Ale_Jrb^talk 15:15, 16 January 2010 (UTC)[reply]

Yes, I like your short version. Should we ask some more users for opinions, or should we boldly deploy it? There's no better way to get feedback than deploying a feature. :)

--David Göthberg (talk) 19:54, 16 January 2010 (UTC)[reply]

Tbh, I don't think it's a very big deal - if it's deployed, and people don't like it, it's simple to remove it again. I'm not adverse to mentioning it at VPT either though. I don't mind. Ale_Jrb^talk 22:48, 16 January 2010 (UTC)[reply]

Y Updated - This template (and thus this system message) now gives a red link to possible documentation pages, using the text from Ale jrb's example above. And it handles user skin file separately, it uses different text for them and doesn't link to documentation on them. See the /testcases page for examples of the six different message combinations.

This template is still only loaded used in user space. It is not used in MediaWiki space, and seems unnecessary there.

--David Göthberg (talk) 23:19, 25 January 2010 (UTC)[reply]

When I just wanted to manually create the doc pointer on Wikipedia:Dazzle!/code.js I created the redirect Wikipedia:Dazzle!/code → Wikipedia:Dazzle!, but then figured I could just point to WP:Dazzle! right away and bypass the redirect since I had to transclude the template manually in Wikipedia space. I intuitively used {{script doc auto|Wikipedia:Dazzle!}}, which of course doesn't work since there are no numbered parameters in the template, but even using the page parameter I'd have to write {{script doc auto|page=Wikipedia:Dazzle!.js}} which is quite a hack. Hardcoding the fmbox is of course no option, not least because this template is going to gain more functionality than it currently has. So how about adding a parameter to pass in the actual documentation page itself, which bypasses the name shortening logic? Would probably require an additional subtemplate, but that's probably necessary anyway once more functionality is added.
Cheers, Amalthea 20:59, 14 December 2009 (UTC)[reply]

I am currently working with the extended version. I tried to add parameters for manual linking to the doc page as you suggest, but that messed up the code. And when manually adding a doc link on a Wikipedia space page we have slightly different needs. For instance then the message should not say "seems to have a documentation page", instead it should say "has a documentation page". So it is better if we make a separate template for that. We could for instance call it {{script doc manual}}. I'll create that one later on.

--David Göthberg (talk) 22:38, 14 December 2009 (UTC)[reply]

Note to other readers: This template used to be named {{script doc}}.

Amalthea: I did some thinking. I have now renamed this template to {{script doc auto}} since this template is only called from the system message MediaWiki:Clearyourcache. So now we can use the shorter name {{script doc}} for a template for manual human use.

--David Göthberg (talk) 02:38, 21 December 2009 (UTC)[reply]

Sounds good. Amalthea 09:40, 21 December 2009 (UTC)[reply]

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

Please replace with the current version of the sandbox (diff). This will remove an unneeded parser function, since if a parameter isn't specified a default can be supplied (in this case the pagename magic word) --DannyS712 (talk) 19:00, 13 July 2019 (UTC)[reply]

 Done — xaosflux ^Talk 01:25, 15 July 2019 (UTC)[reply]

We should change "script" to "user script" and then link it to WP:US. Enterprisey (talk!) 21:48, 13 December 2020 (UTC)[reply]

• Love this idea... surprised it wasn't done already. There should be more explicit recs to WP:US. (are there any examples of non-user scripts that trigger this?) – SJ + 21:48, 13 December 2020 (UTC)[reply]
• Good idea. – SD0001 (talk) 07:56, 14 December 2020 (UTC)[reply]
• Done, since any objections seem unlikely. Enterprisey (talk!) 07:49, 17 December 2020 (UTC)[reply]

  Can I suggest that we use "Wikipedia" instead of "WP" in the links? DannyS712 (talk) 00:52, 18 December 2020 (UTC)[reply]

  Sure, will do. Enterprisey (talk!) 09:03, 18 December 2020 (UTC)[reply]

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

Please sync with Template:Script doc auto/sandbox. Changes:

• Converts template to Lua, making the code simpler and more amenable to future changes. The current wiki template is complex and uses /core and /core2 sub-templates. The /core template call is only needed according to the documentation so that {{str len}} is called only once, because, wait for it, in the pre-lua era before 2013, {{str len}} was expensive on the servers due to its abuse of parser functions.
• Adds a header on top of gadget pages as well – indicating the gadget to which the page belongs and the number of users it has. If the gadget is default, a bold "enabled by default" is included. For hidden gadgets, the list of gadgets depending on it is included in the message.

Right now, this template is not used for MediaWiki namespace, so the 2nd point is not a visible change. I have separately requested an edit to make it so.

Testcases available at Template:Script doc auto/testcases, which show the sandboxed version giving identical output for user space cases. – SD0001 (talk) 09:24, 26 January 2024 (UTC)[reply]

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

@SD0001, great module, but currently it fails (with Lua errors) if styles gadgets do not have ResourceLoader, even though it is fine for them. You might also consider this change to the code because it would make module not include anything in noincluded parts. (I adapted this module for Russian WP, maybe you’ll see something you might want to adopt back.) stjn 21:36, 21 February 2024 (UTC)[reply]

@Stjn Will look into porting over some of the improvements, thanks! However, as for this, it doesn't reflect reality – MediaWiki reads the gadgets definition page as plain text and considers anything beginning with a bullet as a potential definition. Putting something within noinclude tags doesn't make any difference. – SD0001 (talk) 17:15, 22 February 2024 (UTC)[reply]

In Russian Wikipedia MediaWiki:Gadgets-definition has some stuff in the {{Flatlist}} that is marked with bullets, and I suspect it would trip up your parsers while not tripping up Special:Gadgets etc. stjn 17:19, 22 February 2024 (UTC)[reply]

This edit request to Template:Script doc auto/core has been answered. Set the |answered= parameter to no to reactivate your request.

Template:Script doc auto/core has been listed at Templates for discussion (nomination), but it was protected, so it could not be tagged. Please add:

{{subst:template for discussion|help=off}}

to the top of the page to complete the nomination. Thank you. Gonnym (talk) 09:20, 11 March 2024 (UTC)[reply]

 Done — Martin (MSGJ · talk) 09:35, 11 March 2024 (UTC)[reply]

Template:Script doc auto/core2 has been listed at Templates for discussion (nomination), but it was protected, so it could not be tagged. Please add:

{{subst:template for discussion|help=off}}

to the top of the page to complete the nomination. Thank you. Gonnym (talk) 09:20, 11 March 2024 (UTC)[reply]

 Done — Martin (MSGJ · talk) 09:37, 11 March 2024 (UTC)[reply]

This probably needs the same changes as {{doc}} to work in dark mode i.e. have the styles

        background-color: #0b1e1c;

in dark mode (from Module:Documentation/styles.css). — Qwerfjkltalk 16:13, 15 August 2024 (UTC)[reply]

Looks like this was done some time back (Special:Diff/1250343929). – SD0001 (talk) 09:48, 14 February 2025 (UTC)[reply]

Moved from Wikipedia:Village pump (technical) § Adding support for .vue pages in {{Script doc auto}}

 – Aasim (話す（はなす）) 16:35, 2 August 2025 (UTC)

It is now possible to create Vue codepages in addition to CSS and JS. See my test in User:Awesome Aasim/test.vue.

I want to know if we can add support for detection of such pages in Module:Script doc auto. I synced Module:Script doc auto/sandbox but this module seems quite rigid in how it detects pages associated with a code page. Aasim (話す（はなす）) 17:59, 1 August 2025 (UTC)[reply]

I don't see why this is at VPT. Izno (talk) 16:06, 2 August 2025 (UTC)[reply]

It is here because I can't figure out how. It might require an entire rewrite of the module. I don't know. Aasim (話す（はなす）) 16:12, 2 August 2025 (UTC)[reply]

And so you started a discussion here instead of at the module talk page? Izno (talk) 16:14, 2 August 2025 (UTC)[reply]

I have been all over the place for a bit. I'll move this discussion then. Aasim (話す（はなす）) 16:29, 2 August 2025 (UTC)[reply]

@Awesome Aasim I did a rewrite in the module sandbox that supports .js, .css, .json, and .vue files in any combination. Please try it out. --Ahecht (TALK
PAGE) 19:41, 6 August 2025 (UTC)[reply]

I tweaked the module again so that it also returns accompanying pages for gadgets. You can see this in the testcases. @SD0001, wanted to get your input here as well. --Ahecht (TALK
PAGE) 15:09, 7 August 2025 (UTC)[reply]

 Done With no objection after a week, I merged the sandbox version into the main version. Feel free to revert if I just broke Wikipedia. --Ahecht (TALK
PAGE) 15:33, 14 August 2025 (UTC)[reply]

Do the thing with doc pages on this later. jp×g🗯️ 21:12, 19 October 2025 (UTC)[reply]