Template talk:Documentation

Show improve documentation if doc doesn't exists?

Should this template be modified to show {{improve documentation}} by default to templates/modules that doesn't have a documentation? This will auto list the template/modules to Category:Templates with missing or incorrect documentation, which is useful for tracking and fixing. Nvdtn19 (talk) 05:39, 2 December 2025 (UTC)

I support this. All templates should have documentation, even if it's something basic like "see the parent template for detailed information". What seems obvious to the creator of the template, might not be to others who encounter it and might not be 10 years down the road to no one. Gonnym (talk) 13:56, 2 December 2025 (UTC)

That said, there are cases where the documentation is in the body of template and not a /doc page, such as navboxes that use {{Navbox documentation}} or WikiProject banners that use the auto generated documentation. Those cases should be tested to make sure they don't fill up the category. Gonnym (talk) 13:59, 2 December 2025 (UTC)

Of course, {{improve documentation}} will only shows if the namespace is template/module, and if the template which is transcluding {{documentation}}, does not have any documentation. The viwiki version of this template have already implemented this feature, you can see some demo:

• w:vi:Bản mẫu:!w (with no /doc, no |content=, and no auto-generated doc. Thus it's showing {{improve documentation}})
• w:vi:Bản mẫu:Brackets (with inline |content=)
• w:vi:Bản mẫu:Valve (with {{Navbox documentation}} transcluded)
• w:vi:Bản mẫu:Sơ khai (with auto-generated doc from module).

If this change are also considered useful here then I'll suggest some changes, but I'll have to test first. Nvdtn19 (talk) 14:45, 2 December 2025 (UTC)

• I'm wondering if it wouldn't be better setting this up as a bot task to allow for a gap between the template creation process and building documentation. I know I've created a number of templates by starting off with a basic functioning and the standard <noinclude> {{documentation}} </noinclude> ending knowing that I won't be able to build documentation until I'm done working out all the kinks and details in the code, but having that blank documentation section reminds me to come back to instructions once I've finished programming. I would hate to have overzealous gnomes coming in to try to figure out my template while I'm still fixing bugs because it ended up in a tracking category prematurely. At least if a bot were coming in, I'd be able to remove {{improve documentation}} once it got added if things weren't ready for that step yet. VanIsaac, GHTV ^contr_about 17:32, 2 December 2025 (UTC)

  Ideally, if your template still has kinks in it, start it in your userspace or draft space (or /sandbox if it is one). We shouldn't be placing a non-functioning template in the "live" template space. Gonnym (talk) 17:57, 2 December 2025 (UTC)

  I agree with Gonnym. Don't expect unfinished things that is outside the sandbox can't be touched by others. I don't understand why it would be disruptive when {{improve documentation}} is present on templates that lacks documentation, while it clearly reflects the actual situation? So if the project currently has 10,000 templates without documentation, we have to deploy a bot just to add {{improve documentation}} to those 10,000 pages, while a better one-time methods exists? If you don't want your template be flagged, better start it in your sandbox, or not adding {{documentation}} until there is one. Nvdtn19 (talk) 05:35, 3 December 2025 (UTC)

  So, who's gonna implement this in the sandbox? FaviFake (talk) 15:54, 17 December 2025 (UTC)

  Yes, well that's just the thing, isn't it? Almost nothing operates on a platonic ideal. While I am more than willing, and have frequently built templates in userspace, that's not something that everyone would even think to do, let alone a well-known operating procedure that people follow to any extent. While we do have the draft namespace for articles, there's really no policy for anything but new accounts to even build any content in their private userspace as a matter of course. The point is that when dealing with seemingly simple templates, drafting in userspace and moving into the template namespace is usually more hassle than is warranted, but that doesn't prevent the intricacies of template logic from biting us from time to time. So I reiterate that I would think a parameter for empty documentation that is supported by a maintenance bot would be a more robust option for accomplishing the task. VanIsaac, GHTV ^contr_about 18:23, 17 December 2025 (UTC)

• I support this. Checking if a page or template parameter is empty is a perfect task for a template/bot. FaviFake (talk) 17:41, 2 December 2025 (UTC)

Edit request 19 April 2026 for Template:Documentation/preload's doc

Description of suggested change: A clean up to move the documentation of Template:Documentation/preload to the preexisting Template:Documentation/preload/doc. The proposed change is now at Template:Documentation/preload/sandbox, which was to replace and append {{subst:doc-code}}. Thank you.

Diff:

−

<noinclude><!-- This code must be kept in sync with that at [[Wikipedia:Template documentation#How to create a documentation subpage]]. --></noinclude>{{Documentation subpage}} == Usage == <include<includeonly></includeonly>only>{{Sandbox other|| <!-- Categories below this line --> }}</include<includeonly></includeonly>only><noinclude> {{Documentation|content= {{Preload notice|[[Module:Documentation]]}} This page contains the default wikitext that appears when an editor clicks "create" to begin creating a new template documentation page. }}</noinclude>

+

<noinclude><!-- This code must be kept in sync with that at [[Wikipedia:Template documentation#How to create a documentation subpage]]. --></noinclude>{{Documentation subpage}} == Usage == <include<includeonly></includeonly>only>{{Sandbox other|| <!-- Categories below this line --> }}</include<includeonly></includeonly>only><noinclude> {{Documentation}} <!-- Add categories to the /doc subpage and add interwikis to Wikidata --> </noinclude>

— Peterwhy (talk) 04:48, 19 April 2026 (UTC)

Support FaviFake (talk) 10:18, 19 April 2026 (UTC)

I note "preexisting" is a bit misleading. The page was created as a redirect in 2013 (unclear why) but apparently never used (the creation came after Special:Diff/582650318 and Special:Diff/582650843), and you just now un-redirected it to make this edit request. For such a simple page as this, I can't see why anyone would usefully be changing the documentation. 🤷 Anomie⚔ 14:21, 19 April 2026 (UTC)

1. Template:Documentation/preload currently mentions The above documentation is transcluded from Template:Documentation/preload/doc. (edit | history) at the bottom, which is the misleading part I noticed.
2. I undid my Special:Diff/1349843522 back to the redirect. Now I wonder why a simple Template:Documentation/preload would have a complicated and long doc Template:Documentation/preload/doc.
3. Since Special:Diff/1075652576 which introduced a doc in content, the summary documentation is centralised from Special:Diff/582650318 was no longer true.
4. Template:Documentation/preload even has a comment This code must be kept in sync with that at Wikipedia:Template documentation#How to create a documentation subpage. which can be in the documentation visibly.
5. From the doc Template:Documentation/doc (and even Template:Documentation/preload/doc), a purpose of {{documentation}} is that Use of this template allows templates to be protected, where necessary, while allowing anyone to edit the documentation and categories. Here the preload template is protected, but its doc needs not be.

— Peterwhy (talk) 20:08, 19 April 2026 (UTC)

Apparently {{Documentation|content=stuff}} still links the subpage if it exists, even if it's not being used. That seems like a bug to me. Anomie⚔ 21:24, 19 April 2026 (UTC)

Is this request still open, now that you have restored the redirect? — Martin (MSGJ · talk) 13:00, 23 April 2026 (UTC)

Yes, and I would redo the documentation move to Template:Documentation/preload/docTemplate:Documentation/preload/doc after this request. I undid Special:Diff/1349843522 to avoid misleading anyone. — Peterwhy (talk) 18:27, 23 April 2026 (UTC)

I agree with Anomie here; this is a lot of effort amounting to a solution in search of a problem. * Pppery * _{it has begun...} 16:48, 24 April 2026 (UTC)

I don't see "a lot of effort". This is just what we as a matter of course on every single other template ... — Martin (MSGJ · talk) 18:15, 11 May 2026 (UTC)

The reason we put documentation on a subpage is to allow editors to maintain it without protection. That rationale is no different on this template, so I intend to action this request, unless there is a substantive objection which I haven't yet seen — Martin (MSGJ · talk) 18:14, 11 May 2026 (UTC)

Yeah i think you can go ahead :) FaviFake (talk) 04:22, 12 May 2026 (UTC)

I'm having second thoughts. Just realised we are talking about documentation for a subtemplate ... can this not just be included in Template:Documentation/doc? Does very subtemplate really need its own documentation? — Martin (MSGJ · talk) 08:02, 12 May 2026 (UTC)

I suppose the respective /doc pages should also describe their usages. Template:Documentation/doc is for a template that should not be substituted. Template:Documentation/preload mentions This is a preloaded template used in Module:Documentation. and is in Category:Wikipedia preloaded templates. Apart from that, sure Template:Documentation/preload/doc can have a main page link to Template:Documentation/doc, in addition to the < Template:Documentation (| preload) links at the top. — Peterwhy (talk) 07:48, 13 May 2026 (UTC)

Though my above comment is about the content of the doc of the preload, replying to whether it really need[s] its own documentation. The proposed change is about where to place the doc text, in a less-protected /doc page. — Peterwhy (talk) 10:06, 13 May 2026 (UTC)

I suggesting that Template:Documentation/preload/doc be merged into Template:Documentation/doc — Martin (MSGJ · talk) 11:03, 13 May 2026 (UTC)

 Done — Martin (MSGJ · talk) 14:00, 15 May 2026 (UTC)

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)