Jump to content

Module talk:Check for unknown parameters

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by MSGJ (talk | contribs) at 12:10, 11 January 2023 (Use from module: Reply). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

WikiProject iconTemplates
WikiProject iconThis module is within the scope of WikiProject Templates, a group dedicated to improving the maintenance of Wikipedia's templates. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
Note icon
This template should only be transcluded in the Wikipedia talk, Help talk, or Category talk namespace(s).

automatic fetch of template parameter names

For quite some time I have thought that manually curating a list of parameters that each template supports is rather a waste of editor time. Recently this extra maintenance was discussed at Wikipedia:Village pump (technical) § Template:Infobox dog breed which caused me to wonder if there isn't a way to automate the supported-parameter list maintenance.

I have hacked this module's sandbox (lines 53–65) so that if given the template's name in new parameter |template_name=, the module will read the unparsed content of the template and extract parameter names to fill knownargs.

{{Infobox dog breed/sandbox}} calls the sandbox version of this template with |template_name=Template:Infobox dog breed/sandbox and all of the positional parameters have been removed. If you edit and preview Template:Infobox dog breed/testcases you can compare the sandbox to the live version.

If for some reason, a supported parameter isn't or can't be extracted from the template wikitext, positional parameters are still supported.

Alas, I know of no way for a module to get the name of the template that invokes it so I think that we are stuck with |template_name=. Is there a way avoid that parameter that I don't know about?

Keep? Discard?

Trappist the monk (talk) 23:19, 4 September 2022 (UTC) strikeout 15:11, 5 September 2022 (UTC)[reply]

To directly answer the question, you can use frame:getParent():getTitle() to get the name of the template. That said, the underlying idea was previously objected to at /Archive 1#Could this be automated? and /Archive 1#Blank usage * Pppery * it has begun... 23:45, 4 September 2022 (UTC)[reply]
(Do I need a self-troutslap? ahead). When Managing TemplateData in a template /doc page, the tool lists all missing (not-yet-TDdocumented) parameters. -DePiep (talk) 09:22, 5 September 2022 (UTC)[reply]
This discussion has nothing to do with WP:TemplateData. I did think about using TemplateData and a source for template parameter names but, because TemplateData are manually curated, using those data suffers the same issue as the manually curated list of positional parameter ins this module's invoke.
Trappist the monk (talk) 15:11, 5 September 2022 (UTC)[reply]
Yeah I got that. Now, what I tried to point to: when opening the Manage TemplateData screen, TD automatically checks for all parameter names (and then lists those not yet in the /doc page, with an Add-All-These-to-/doc button). So, step 1 is an automated find-all-parameternames tool somehow. (And has nothing to do with step 2, the manual /doc page content). DePiep (talk) 15:27, 5 September 2022 (UTC)[reply]
That's javascript isn't it? As far as I know, there isn't a way for a lua module to interact with javascript.
Trappist the monk (talk) 16:42, 5 September 2022 (UTC)[reply]
New hack to use frame:getParent():getTitle() when |autofetch= has any assigned value (lines 48–59).
At /Archive 1#Could this be automated? Editor Jonesey95 wrote:
The module can't always determine which parameters are actually supported.
At the time of that writing, Module:Check for unknown parameters relied on a manually curated list of the template's supported parameters; still does, doesn't it? If there was/is a problem such that the module cannot always determine which parameters are actually supported then that is a problem with the existing module that should be identified and fixed. That has nothing to do with auto-fetching parameter names from a template's wikitext.
and:
It sometimes fails to pick up valid parameters,...
Again, if the module is using a manually curated list of a template's parameter names and fails to pick up valid parameters then that too is a problem with the existing module that should be identified and fixed. That has nothing to do with auto-fetching parameter names from a template's wikitext.
and finishing that sentence:
...and sometimes picks up parameters that are being tested for but are not actually supported.
That makes no sense to me; if a parameter is being tested for that parameter is actually supported. How is it that a tested for parameter is not supported?
One thing that I take from the above is that it is possible for parameters to be hidden in <!--...--> tags which automatically makes any unique parameter name inside the html comment unsupported. To prevent those unsupported parameters from being included in the supported-parameter list, I have added a snippet of code to remove all html comments before fetching parameter names.
At /Archive 1#Blank usage, Editor Frietjes wrote:
that would be expensive and string parsing the infobox code every single time you use an infobox would be really expensive. The term expensive, in templates and modules, has a specific meaning. This hack to the module does not increment the expensive parser function count (see the parser profiling data table when you preview Template:Infobox dog breed/testcases). Yes, I agree that auto-fetching parameter names every time a page with an infobox is parsed is not necessarily the ideal, but usually, there is only one infobox per article so the cost in processor time and memory usage is relatively small.
Trappist the monk (talk) 15:11, 5 September 2022 (UTC)[reply]
The basic case in which the "make a list of all of the parameters" script does not work is when the template consists solely of a module invocation. See, for example, {{Track listing}}, which needed manual intervention. – Jonesey95 (talk) 16:05, 5 September 2022 (UTC)[reply]
Agreed; this module hack does not apply to that kind of template. Manually curated lists of parameters are not prohibited by this scheme because an editor must deliberately instruct the module to auto-fetch parameter names by intentionally setting |autofetch=<something>. The existence of these invoke-only templates should not be used as grounds to prevent the scheme's implementation for use with generic wikitext templates.
Trappist the monk (talk) 16:42, 5 September 2022 (UTC)[reply]

Use from module

Is it possible to use this module directly from another module, or does it always need to be placed on a template page? — Martin (MSGJ · talk) 16:11, 30 December 2022 (UTC)[reply]

@Frietjes: any chance you could help me with the above? — Martin (MSGJ · talk) 19:04, 8 January 2023 (UTC)[reply]
Something like this should work for you:
	local validArgs = { ... }
	local checkForUnknownParameters = require("Module:Check for unknown parameters")
	local result = checkForUnknownParameters._check(validArgs, args)
Gonnym (talk) 11:41, 9 January 2023 (UTC)[reply]
MSGJ, see the end of Module:Rugby box for a simple example or Module:Infobox3cols or Module:Flag for more complicated examples. Frietjes (talk) 15:50, 9 January 2023 (UTC)[reply]
Thanks both, I will give it a try — Martin (MSGJ · talk) 12:10, 11 January 2023 (UTC)[reply]