Template talk:Documentation

Adding Template:No documentation and attempting Lua auto documentation with Template:Lua autodoc if the module has no documentation

I updated the module sandbox and testcases with two changes, one that adds {{no documentation}} to templates and modules when no documentation is specified in the content field of the template or module, and the other attempts to add Lua auto documentation if the module does not have documentation present.

I did garner feedback at Wikipedia:Village_pump_(technical)/Archive_215#Thoughts_on_Docbunto? about a year and a half ago but it mostly has been abandoned. The autodoc module is still in beta and is wrapped in pcall so even if it gets used here it may only need semi or XCON protection for now.

If there are no objections over the coming days I'll open an edit request. Aasim (話す（はなす）) 15:20, 3 June 2026 (UTC)

Since there have been no objections I will be opening an edit request. Aasim (話す（はなす）) 04:28, 8 June 2026 (UTC)

Edit request

Please implement my changes in the sandboxes, which:

1. Adds {{no documentation}} if the content field is empty, which saves work of template editors to add "no documentation" to doc pages
2. For modules, uses an autodoc module Module:Docbunto to attempt to generate documentation. This autodoc module does not need to be protected at the same level as Module:Documentation since it is called in pcall( ... ), which means that if the auto doc generation fails it will not generate any red text and instead will display nothing. If there is something present on the doc page it will instead override the Lua autodoc with the content on the doc page. Module:Docbunto could be semi- or extended-confirmed protected if there is concern that leaving the page unprotected in this pcall arrangement would make the module high risk.
3. Adds appropriate doc tags for generating auto documentation, which has the added advantage of documenting the various functions in a format that can be used by other Lua programmers.

Aasim (話す（はなす）) 04:28, 8 June 2026 (UTC)

Support – I missed the original post but this sounds like a great change. FaviFake (talk) 10:56, 8 June 2026 (UTC)

Do you want to add something showcasing the auto documentation at Template:Documentation/testcases? It seems to not break anything but I would like to actually see the auto documentation in action somewhere before implementing. Trialpears (talk) 12:30, 8 June 2026 (UTC)

It's difficult for me to add testcases here, but I can potentially show you demos on Test Wikipedia: testwiki:Module:Docbunto/demo1, testwiki:Module:Docbunto/demo2, testwiki:Module:Docbunto/demo3. Things may look more broken than they actually are because testwiki does not seem to want to load messages from Wikimedia Commons. Aasim (話す（はなす）) 14:25, 8 June 2026 (UTC)

Personally, I still think it'd be better to encourage people to write documentation on the doc page than to read doc comments from the module to display in the documentation section, for the same reasons Scribunto doesn't do that already. Anomie⚔ 22:18, 8 June 2026 (UTC)

I see one major problem with Module:Docbunto at the moment: it focuses on functions with multiple arguments, which are usually module functions called by other modules. By contrast, the documentation of functions that must be called via {{#invoke:...}} (which often have a single frame Lua argument) is only confusing. For example, among the modules documented only via Docbunto (e.g. Module:Multiformat, Module:Format, Module:Escape input), I cannot understand the wikitext syntax of even a single function, except for a superficial overview of its parameters. In short, Docbunto could work with Lua libraries (e.g. Module:Arguments), but it is currently terrible at documenting modules that must be invoked via wikitext. For the latter, any automated solution should take the documentation of Module:String, Module:String2, Module:Params, and others as examples (i.e. one section for each function, titled accordingly, with a brief description, a syntax overview, an explanation, and examples). Consider also that {{Mfl}} expects functions to have sections named after them. It could also be argued that modules intended to be invoked only via wikitext should hide the documentation of their Lua code from the documentation page; otherwise, they risk confusing people who simply want to use a module and know nothing about Lua (nor do they need to). Comments in the code should be sufficient for that. --Grufo (talk) 22:27, 8 June 2026 (UTC)

I personally don't know if that is a limitation of Docbunto or just my poor documentation. But from what I see one can type in the function documentation @usage {{#invoke:Module|foo}} or @usage {{Foo}} for wikitext usage of a module function. It also is possible to specify keys in a table such as @param {string} args.echo Text to echo for functions which can be invoked either in a module or a template (that is why Module:MakeInvokeFunc was spun out into its own module and why its code is all over the place). But it still would help beginners who do not know Lua understand how specific functions operate and how to reference them in other Lua modules, since invoking them in wikitext is very similar to calling a template. Aasim (話す（はなす）) 01:50, 12 June 2026 (UTC)

I like to be pragmatic. Imagine a module function that expects this wikitext invocation: {{#invoke:foobar|my_func|first param|second param|third param|hello=hello param}}; how do you document that |1= should be, let's say, a number? How do you document that |2= should be a string? How do you document that |3= should be a boolean (yes/no)? How do you document that |hello= should be a comma-separated list? And why do you think it is useful for people who are interested in using such a module to know that in its Lua code my_func() requires a single argument named frame (which, by the way, is a constant across modules—except for the argument's name)? --Grufo (talk) 02:55, 12 June 2026 (UTC)

I think you can do this:

--- Echos something
--
-- @function p.echo
-- @param {Frame} frame calling frame
-- @param {string} frame.args[1] what to echo
-- @param {number} frame.args["num"] number of times to echo
-- @return {string} output wikitext

Aasim (話す（はなす）) 19:37, 14 June 2026 (UTC)

@Aasim: Thank you. Could you please create a dummy module with its Docbunto documentation similar to what I wrote above? You don't actually need to write any Lua code, p.my_func = function (frame) end will do. --Grufo (talk) 20:29, 14 June 2026 (UTC)

I think you can see Module:Example as an example of this. Yes there is a weird bug where the [1] is not showing up in brackets but that is why the entire module is enclosed in pcall as a beta module. Aasim (話す（はなす）) 15:50, 15 June 2026 (UTC)

Okay I fixed that error, it was a bad Lua pattern that was causing that issue. Aasim (話す（はなす）) 16:27, 15 June 2026 (UTC)

Thank you. I see. Do you think that it could be changed to become more similar to how, let's say, {{#invoke:string|replace}} documents its parameters? Someone who wants to use a module function designed for wikitext does not need to know how Lua works, and seeing frame.args.bananas might look quite obscure, whereas bananas or, even better, |bananas= would be much clearer. --Grufo (talk) 18:53, 15 June 2026 (UTC)

Error in preload

When I click [create] for the testcases pages on Module:Women in Red event/sandbox, I see the following boilerplate:

-- Unit tests for [[Module:{{ROOTPAGENAME}}]]. Click talk page to run tests.
local p = require('Module:UnitTests')

-- Example unit test.
function p:test_hello()
	self:preprocess_equals('{{#invoke:Example | hello}}', 'Hello, world!')
end

return p<noinclude>
{{Documentation|content={{Preloaded template|[[Module:Documentation/config#L-257]]}}}}
</noinclude>

The noinclude bit at the end is misplaced, and I can't work out where it is coming from — Martin (MSGJ · talk) 08:24, 9 June 2026 (UTC)

A quick test tells me that, for whatever reason, the preload just doesn't handle noinclude tags like it normally would on any other page (compare it on Template:X_Y_Z and Module:X_Y_Z). I assume it's a content model difference issue, though I couldn't tell you how this'd be fixed. Aidan9382 _(talk) 10:17, 9 June 2026 (UTC)

I've reverted the change to Template:Documentation/preload-module-testcases — Martin (MSGJ · talk) 11:53, 9 June 2026 (UTC)

Is this worth reporting as a bug? — Martin (MSGJ · talk) 11:54, 9 June 2026 (UTC)

Add links to documentation header

I have written a script that adds sandbox and testcases links to the top, as shown in the image to the right. I was going to add them directly to the module... Any objections? Zackmann (^{Talk to me}/_{What I been doing}) 22:22, 6 July 2026 (UTC)

For modules, I would be OK with moving the whole linkBox at the top (under or even above the header), because module documentation is above the code, which puts the linkBox in an awkward position that is hard to get to quickly.

For the templates, the documentation is by convention put at the bottom. Pressing End or Page Down on the keyboard to get to the contents of the linkBox is quick enough. We don't need to have these links near the top. As mentioned two years ago in a similar discussion about linking to "Help:Template", the header itself is too crowded. —⁠andrybak (talk) 00:58, 7 July 2026 (UTC)

Missing prot icon on protected template

Template:Documentation#Automatic functions says This template also automatically adds {{pp-template}} to a protected template page. But this does not appear to be working at Template:REVISIONUSER, and the template is not in Category:Wikipedia semi-protected templates either. What has changed? --Redrose64 🌹 (talk) 08:28, 15 August 2026 (UTC)

Some kind of transient/caching issue? Both the indicator padlock icon and the categorization seem to be working fine now. I checked Vector 2022 (Parsoid/legacy parser), Monobook – all seem fine. —⁠andrybak (talk) 11:33, 15 August 2026 (UTC)