Jump to content

Module talk:Check for unknown parameters/Archive 1

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

Just some ideas

Great and useful. Here are some earlier thoughts.

0. Change name to e.g. module:Parameter check, to cover more wide goals. Definitely do not limit to infoboxes.

The parameter whitelist could be a module:Parameter check/data/Template:Foo page for the Draft:Tlno template (module data page). With that whitelist, some extra options are possible:

1. Unnamed (positional) parameters could be defined white or black
2. Per parameter, an "accept blank input yes/no" switch can be added.
3. Per parameter, a more special value check could be performed (numeric, pattern, listcheck).
4. Big-issue parameters (black/white) or special interest parameters could have their own category or their own catsort letter.
4b. Deprecated parameters can be defined and categorized separate (idea added later).
5. Category name automated? Parent cat available (using template name, by "parameter check module" name?)
Tree suggestion (all are maintenance categories):
Category:Template foo maintenance categories (could be existing name, any name, host cat for this module outcomes)
Category:Parameter check categories -- The module's view.
Category:Parameter checks for template foo -- dedicated for & created through module:Parameter check
-- Has the default checks (forced adding of the word "pages" makes the name awkward. Better not use title word "articles", because that is to be an option for the template editor).
Category:Foo template parameter 'country' checks -- special checks
Category:Foo template parameter '1=' checks --spcial checks

6. We could add a maintenance tag to the pages, demo Draft:Tlno:

Lorem {{do something|latincehck=ipsum}} foo. → Lorem ipsum[unknown parameter] foo. Currently in {{convert}}: 12 kilometres ([convert: unknown unit]).

7. Note: As always, categorising a wikilabel works out bad. Say the template is used in the {do something} template, which is used like this:

[[Mercury (element)|{{do something|Mercury}}]]. When the category name is expanded into the page including a category name, it shows like this in the article: [[Mercury (element)Mercury blabla foobar]]. The template could have a "|parametercheck this instance=no option (the offended page must be edited for this).

8. Options for (easy) ns differentiation please.

9. Catsort could be [[Category: ... |__VALUE__, {{PAGENAME}}]] -DePiep (talk) 08:04, 25 March 2014 (UTC)

I like the idea of loading the required parameters from a module data page, rather than using frame args and parent frame args. This option will be much better performance-wise, especially for templates that are called many times on one page. (This is assuming we are loading the data with mw.loadData.) — Mr. Stradivarius ♪ talk ♪ 08:53, 25 March 2014 (UTC)
Agree. Even more: it allows for unlimited parameter sub-specifications. Each whitelist parameter can have its own check-properties, like "is deprecated", to be used. Also, an "is blacklisted=yes" property can be added for notorious bad parameters). -DePiep (talk) 10:19, 25 March 2014 (UTC)
feel free to create a more general version as suggested. this was just a first iteration at solving a specific problem. in response to point 7, I modified it to clobber non-whitelisted characters from the VALUE parameter. the list of valid characters could be expanded, and what the clobbered characters are replaced by, but this seems to work for sorting purposes. again, feel free to fork/pilfer/modify this module to create something better. I won't care if it is replaced by something better and deleted. Frietjes (talk) 15:33, 25 March 2014 (UTC)

@Frietjes: maybe you could add something for such cases - when you can use arg1 to arg100 (or now with Lua - even arg1 to argN). So using this module in some template 

{{#invoke:check for unknown parameters|check
|arg}}

And it accepts all arguments with arg - from 1 to N. OK, you should name somehow it, because currently it would cause some unexpected results. --Edgars2007 (talk/contribs) 14:01, 8 June 2015 (UTC)

I wonder, how does this module compare to Module:TemplatePar? DePiep? Alakzi (talk) 14:28, 8 June 2015 (UTC)

About Module:TemplatePar

re Alakzi. I have applied Module:TemplatePar in {{Chembox}} and {{Drugbox}} (together causing nearly all the 16000 tranc's then), and from that will make some remarks. I did not a comprehensive comparision.

  • TemplatePar (TPar here) only comes in module form, #invoked. I've added after the infobox code like this:
{{#invoke:TemplatePar
|check |template=Template:Chembox
|all= |opt= IUPACName_hidden= IUPACNames_hidden= Name= ImageAlt= ImageCaption=
|cat=Chemical articles with unknown parameter in Chembox
|format=0|preview=1|errNS=0
I did not research, but I imagine it can be invoked from a module too (instead of wikicode template).
  • The parameter list smartly has separator "=" (because that can not be part of any param name).
I guess numbered params can be added like 1= 2= 3= 4=, that's individually not by range.
TPar has very many options by various parameters. The params do interact which can make building & testing horrible.
The doc mentions the option of value-testing for a param (not tried), and presence-testing, in the code above applied by |check= (it is the parameter being there that is the setting, where one would expect like |check=yes for readible code. What would do |check=no?), and other options (counting?).
The parameter list giving hints on what can be done:
--[=[ TemplatePar 2015-02-14
Template parameter utility
* assert
* check
* count
* countNotEmpty
* downcase()
* match
* valid
* verify()
* TemplatePar()
]=]
Error messaging/categorising can be limited to a list of namespaces.
Visual effects can be set to handcrafted errormessage with @variables, and to show a message only in Preview view.
I have not looked at performance (parsing times etc).
One absolute negative I: when used in a subtemplate, an error does not survive in the top template. That is, in
|Chembox
| Name = Foo
| Section1 = {{Chembox Identifiers
  | CASnumber=12345
  }}
}}

a TPar message raised in sub {Chembox Identifiers} does not take effect in any way (killed along the route). I have not spend time on researching & solving this (though in {{Chembox}}, 80% of the parameters are in subtemplates...).

  • In general I like it because it has multiple options and does not require parameter-name tricks. Also the flexibility of messaging & categorising is a useful feature. Although documentation is elaborate, for me it required extra probing to get the intentions ('programmer wrote the /doc situation' - no offense). I got cooperative responses & code changes (it is maintained at dewiki).
  • As said, this is not a comparision, and I don't know how this Check for unknown parameters would score on those features.
-DePiep (talk) 22:01, 8 June 2015 (UTC)
Thank you for the thorough rundown. Alakzi (talk) 23:21, 8 June 2015 (UTC)
Added its own param list, link to english /doc at dewiki. Minor fizes. -DePiep (talk) 11:42, 9 June 2015 (UTC)
why is this thread on this talk page? Frietjes (talk) 14:42, 14 June 2015 (UTC)
It's a reply to [1]. New section, good. -DePiep (talk) 23:00, 14 June 2015 (UTC)

Should the ignoreblank parameter apply to the preview message?

As far as I can tell, when there is an unknown but blank parameter in {{infobox person}}, the category is not applied (since |ignoreblank= is set), but the preview message complains about both populated and blank unknown parameters.

This may be pure personal preference, but I think that the preview message should listen to the |ignoreblank= parameter, showing red error messages only for populated parameters. Does that make sense to others here? – Jonesey95 (talk) 22:32, 16 March 2016 (UTC)

the idea was to allow editors to find and clean up blank deprecated parameters, but not elevate them to the point that they are tracked. how about if we add an additional option for say |ignoreblank=all or |ignoreblank=preview or whatever? Frietjes (talk) 00:12, 17 March 2016 (UTC)

Polluting content

Hiding the text with an inline style attribute containing "display: none" (as the usage guidelines encourage) is problematic, because the text is only hidden on visual web browsers. Screen readers and web spiders still treat it as part of the page content. This causes the error text to appear in Google search snippets, as you can see in this screenshot. If you search the web, you can find other examples. --Ori Livneh (talk) 03:30, 24 April 2016 (UTC)

Hi. In general, if you find a problem with Google's search results, it's best to tell Google. The English Wikipedia does not control Google search results. Google search is a closed-source proprietary search engine, as far as I'm aware, basically a black box.
At least for me, limiting your search query to site:wiki.riteme.site is a better demonstration of the issue. If there's additional or better markup that can be used here that will signal to Google and other search engines that this text is meant to be stripped or ignored, I think we'd be happy to accommodate, assuming the markup isn't stupidly vendor-specific. Maybe some WAI-ARIA HTML attributes or similar?
Broadly, why are we using a Scribunto/Lua module to find unknown template parameters? We should probably put this functionality in a MediaWiki extension or in MediaWiki core. Perhaps in TemplateData? I'm reminded of Wikipedia:Database reports/Articles containing invalid template parameters and the horror of learning just how crazy template parameter names can be. --MZMcBride (talk) 05:08, 26 April 2016 (UTC)
See also, phab:T133504, which contains links to 2 prior VP discussions. Quiddity (WMF) (talk) 20:27, 17 May 2016 (UTC)
I have removed any hidden text directly generated by this module, and removed any mention of using hidden text in the documentation. this "feature" was really only there to assist with finding the offending parameter without creating visible output in the article. but, since we have the ability to show verbose output in preview-mode only, the hidden comment feature isn't really needed. hopefully the preview-mode feature doesn't go away [2]. Frietjes (talk) 16:59, 17 June 2016 (UTC)

False positive

I am assuming that this module is responsible for the error message reported at Wikipedia:Teahouse/Questions#Infobox error regarding article Kohat, but I cannot see any use of a parameter "1". Can one of the experts explain, please? --David Biddulph (talk) 17:24, 21 June 2016 (UTC)

There was a parameter in that article that was missing the = sign between the parameter name and its value. I fixed it. Not a bug in the module. The error message could be clearer. – Jonesey95 (talk) 17:33, 21 June 2016 (UTC)
the error message for numeric parameters should be more informative now. Frietjes (talk) 14:43, 23 June 2016 (UTC)

Checking for only known parameters (or no parameters)?

Is there a way to use this module to check for templates that only use the known (specified) parameters? Or to check if no parameters have been passed to a template? That would be useful for checking if infoboxes are entirely drawn from Wikidata, or if they have any locally defined parameters (e.g., including South Pole Telescope in Category:Articles with infoboxes completely from Wikidata via Template:Infobox telescope). Thanks. Mike Peel (talk) 22:53, 18 December 2016 (UTC)

Mike Peel, your first question is "to check for templates that only use the known (specified) parameters". yes, this is exactly what this template does. you provide the list of known parameters, and it returns whatever you put in |unknown=. your second question is "to check if no parameters have been passed to a template". yes, you can use the following code: 
{{#if:{{#invoke:check for unknown parameters|check|preview=1|unknown=1}}|<!-- do nothing we found parameters -->|[[Category:Pages using infobox telescope with paramters]]}}
. in other words, wrap the output inside an #if: to reverse the logic. if you want me to add tracking to a particular template, just tell me the name of the tracking category and what it should track. Frietjes (talk) 14:19, 19 December 2016 (UTC)
That's great, thanks! I was trying something similar to that yesterday but I couldn't get it to work - I think the missing element that you've added to get it working is "safesubst". Thanks for adding it to the template! Mike Peel (talk) 16:09, 19 December 2016 (UTC)
Mike Peel, the safesubst: was just for debugging so you can see what is happening with {{subst:infobox telescope in preview mode. it looks like you tried 
{{#ifeq:{{{1|}}}|||[[Category:Articles with infoboxes completely from Wikidata]]}}
which is just testing for |1=. Frietjes (talk) 16:19, 19 December 2016 (UTC)
Hmm, this was the first version of the code I was using. Maybe it was the order that "main other" was being called, then. diff between my version and now. Anyhow, thanks for getting it to work! Thanks. Mike Peel (talk)
Mike Peel, I am guessing you wanted #ifeq: instead of #if: there? Frietjes (talk) 20:37, 19 December 2016 (UTC)
Aah, that's probably it! Mike Peel (talk) 21:15, 19 December 2016 (UTC)

Should I Anticipate Challenges if the Parameter is Post-Hoc Added to the Template?

Hello all; I'm an editor from long ago who no longer uses an account or edits regularly, and I pre-dated Lua, so apologies if this is a oft-asked question. The short form of the question is: if, instead of deleting an un-used parameter, I add that parameter to the template, should I anticipate any problems with this module?

More detailed question: I added a parameter, {{{expanded}}}, to Template:Infobox convention center (diff). The parameter was advertised on the template documentation, but for some reason it was not a part of the actual template code. As it had been advertised on the documentation, many pages used it, including, for example, Kansas City Convention Center. I had been trying to fix pages on Category:Pages using infobox convention center with unknown parameters, which is generated with this module, and I noticed that adding the parameter did not take any pages off the list. (And, more specifically, a preview of the pages still generated the error message: Warning: Page using Template:Infobox convention center with unknown parameter "expanded" (this message is shown only in preview).

Now I assume it's just a cache issue; that this will resolve itself, and I will look silly, but in the spirit of ensuring that I didn't make a harmful edit, I thought I'd check here to make sure. Thanks!--216.12.10.118 (talk) 01:16, 1 April 2017 (UTC)

Update: Idiocy confirmed. {{{expanded}}} is no longer generating the message. Sorry!--216.12.10.118 (talk) 01:27, 1 April 2017 (UTC)
The parameter has to be added as a known parameter. — JJMC89 (T·C) 01:32, 1 April 2017 (UTC)
Ah I see! I'm glad I checked, then; sorry for making you do the work. I appreciate it, --216.12.10.118 (talk) 01:33, 1 April 2017 (UTC)
For anyone looking for this same answer in the future, here it is in plain text: The unknown parameter check is typically at the bottom of the template code. If you add a parameter to the template, you also need to add it to the list of valid parameters (typically in alphabetical order) in the unknown parameter check section. That addition will prevent the red error message when you preview a page. – Jonesey95 (talk) 03:53, 1 April 2017 (UTC)

Restrict to certain namespaces

Apparently there is no namespace selector ("only list pages in ns=x" or "... ns=/=y"). Is there a good practice to add this? -DePiep (talk) 12:53, 30 May 2017 (UTC)

We usually wrap the category with {{main other}}. See {{Infobox mountain}} for an example. Here's the standard invocation of the module:
{{#invoke:Check for unknown parameters|check|unknown={{main other|[[Category:Pages using infobox mountain with unknown parameters|_VALUE_{{PAGENAME}}]]}}|preview=Page using [[Template:Infobox mountain]] with unknown parameter "_VALUE_"|ignoreblank=y| (... parameters separated by pipes ...) }}
Replace the template name with the template you are working with, of course. 12:57, 30 May 2017 (UTC)

"this message is shown only in preview"

The messages generated by this module (such as Warning: Page using Template:Infobox writer with unknown parameter "influenced" (this message is shown only in preview). on Neal Stephenson) are in fact also shown when editing in VisualEditor (e.g. https://wiki.riteme.site/wiki/Neal_Stephenson?veaction=edit). Therefore I suggest to change the wording from "in preview" to "when editing", which is still correct for the wikitext editor. (If this is done, the same change should be applied to the modules/templates found here: [3].) Matma Rex talk 22:42, 5 July 2017 (UTC)

Visual editor's edit screen appears to be an attempt at previewing what you will see when you publish your changes, so "in preview" is accurate there as well. Some people do not have "Show preview on first edit" selected in their Editing preferences, so "when editing" would not be accurate for them. – Jonesey95 (talk) 23:44, 5 July 2017 (UTC)
I'm inclined to Jonesey's position. I've marked the edit protected request answered until a consensus is had. --Izno (talk) 12:18, 7 July 2017 (UTC)

Discussion

A relevant discussion has been initiated at Template talk:Infobox#Improvement. You are invited to share your comments. -- Pankaj Jain Capankajsmilyo (talk · contribs · count) 18:21, 26 August 2017 (UTC)

Not working on Android app

Tracked in Phabricator
Task T174977

The preview messages from this template are appearing on the Android app even outside of preview mode. It's an app bug, not a template one, but still something we should keep an eye on. See phab:T174977. — PinkAmpers&(Je vous invite à me parler) 13:07, 5 September 2017 (UTC)

Recommendation to universally support the "reason=" parameter?

SMcCandlish recently added a section to this template's documentation saying that "Unless there's a very good reason not to, the parameter |reason= should always be supported." Can that editor please provide a link to a discussion supporting that sweeping statement?

This generalization does not make sense to me. Why would there be a reason parameter in an infobox, or a navbox, or in {{Iso2country}}, to name a few templates and template types off the top of my head that make use of this module? Thanks for any enlightenment you can provide. – Jonesey95 (talk) 04:31, 20 October 2017 (UTC)

Not sure how many times this needs to be explained; this is very, very old news. For over a decade, we've been using |reason= as a de facto standard way to include a template-related rationale without a) pestering readers with a visible note or b) cluttering the wikicode with HTML templates outside the actual template code. It's tidy, because it keeps the rationale or cleanup note or whatever as part of the template itself (so it goes away if the template does). This is usually a pseudo-parameter – most templates have no code in them to actually process a |reason= parameter, and this is by design. There are a few that use it explicitly, and these are mostly internal, admin/maintenance templates, like {[tlx|Rm}}, in which exposing the reader to WP-internal language isn't a concern. Various templates also explicitly document use of |reason= without actually having code to do anything to the parameter's content, and even if they did not it's just how we do things there – use of it wouldn't magically stop if you went around and deleted those references. What we really, really do not need is for this module to start throwing up errors in editors' faces when what they're doing is part of normal, everyday template use. I'll let you do your own homework on prior discussions in favor of using |reason= this way.

The ideal solution would probably be for this module to auto-permit |reason= by default, and require it to be overridden for the rare, odd case there would be a need to actively exclude it, since the entire point is that a |reason= can be used with any and all templates, without anyone having to check and see whether it has special code to "enable" it, much less to create code that does something with what is almost always mean to be invisible except in source mode.
 — SMcCandlish ☏ ¢ >ʌⱷ҅ᴥⱷʌ<  04:44, 20 October 2017 (UTC)

PS: An obvious use for |reason= in the case of an infobox or some other template the purpose of which is always clear is for when the consensus to include it is not clear. Thus, e.g., |reason=Per consensus at Talk:Article_name#RfC_about_using_an_infobox_at_this_article.  — SMcCandlish ☏ ¢ >ʌⱷ҅ᴥⱷʌ<  04:46, 20 October 2017 (UTC)

I did my own homework, searching in various talk spaces, and was unable to find a single discussion or other documentation about this |reason= parameter. I have added this module to dozens of infoboxes, maybe over one hundred, and I have never seen the |reason= parameter used or requested in any of them. That is why I asked for a link to a previous discussion justifying the addition of this instructional text. Can you please link to a previous discussion? Thanks.
Also, can you please link to three or four templates that use a hidden |reason= parameter? The only templates I know of that use a reason parameter are cleanup templates, in which the parameter's value is exposed, or even required (I found this discussion while doing my homework). Thank you. – Jonesey95 (talk) 14:05, 20 October 2017 (UTC)
@Jonesey95: You don't seem to be following. It's not a "hidden parameter", as in a parameter coded into the template with suppression of the output. It's just a de facto pseudo-parameter (except for a handful of templates that actually use |reason= to display something, e.g. {{rm}}); its a way to provide an in-code comment, without having to resort to HTML comment markup, and which can optionally be turned into a real parameter to display the content (e.g. as a tooltip, or in plain text) on a per-template basis. Who cares if this wasn't the subject of a discussion about infoboxes in particular? Showing how it could be used in one was just an example. The most common use is in dispute and cleanup templates, to explain in brief what the issue is, more concisely than on the talk page (a step many people forget or don't bother with). If you're going to do "homework" on this, please do it well; a simple insource regex search [4] constrained to Template namespace (which includes template documentation) finds what you're looking for.  — SMcCandlish ☏ ¢ 😼  12:16, 2 March 2018 (UTC)
Above, SMcCandlish said "Various templates also explicitly document use of |reason= without actually having code to do anything to the parameter's content". If that is not the definition of a hidden parameter, I don't know what is. Whether the parameter's output is explicitly or implicitly suppressed, the value of the parameter does not appear in the rendered template. It is hidden in the wikicode.
Here's a better insource search that shows a |reason= parameter being used in, at most, 129 templates. Implementing the unknown parameter check in those templates with an explicit |reason= parameter would be a much more reasonable process than allowing |reason= across the board in thousands of templates where that parameter would be an error. The burden is on SMcCandlish to show that there is a consensus or a rationale for allowing this unsupported parameter to exist in potentially thousands of templates. – Jonesey95 (talk) 16:08, 2 March 2018 (UTC)
Arrived here with the same question. Still not convinced. First of all, why should this be enforced through this module? Why is it not mentionend in WP:TEMPLATE?
Further questions: Not sure how many times this needs to be explained — just once would be nice, and without blaming other editors nor dishing obscure homework as a claim for stupidity. And the place to do so is, for starters, WP:TEMPLATE. For over a decade, we've been using: No we haven't. Never met it (and, like Jonesey95, I've seen enough insides of templates). As for background described: it keeps the rationale or cleanup note or whatever as part of the template itself: better not. Any disputable or questionable reason that might be needed should go on the talkpage in the first place. I propose removal of that section from the doc. - DePiep (talk) 15:49, 1 March 2018 (UTC)
I have reverted the original edit. – Jonesey95 (talk) 15:57, 1 March 2018 (UTC)
Letting the discussion proceed would make more sense. DePiep having a WP:IDONTKNOWIT moment is not much of a rationale, nor evidence of a "controversy", it's just one person not understanding or bothering to find out the facts.  — SMcCandlish ☏ ¢ 😼  12:16, 2 March 2018 (UTC)
@DePiep:, please turn the hostile invective down several notches. Not sure why you're trying to pick a fight with me, given that we haven't much to fight about. I cannot help it if you somehow think you don't encounter |reason=. It's actually impossible for you to not encounter it yet be a regular editor; you're simply not noticing and remembering. It's specifically documented in various templates, and is used thousands and thousands of times (just go look [5]; however, these regex searches can time out and are slow). You're making an argument that amounts to "I don't like it and I don't think we should do it", which is just an opinion about a change you'd like to see someday. My argument is "It is done by many and has been for a long time, so it must be accounted for or things will break", which is plain fact. PS: "Why is it not mentioned in WP:TEMPLATE?" Because no one bothered to write it down there, obviously. Wikipedia is not a magical psychic machine that reads minds and documents itself, ha ha. It's a hand-written project we do in our spare time as volunteers, and we don't codify every consensus-evolved bit of minor best practices; we do that only when we need to, or our documentation would be 100 × longer than it already is. Finally, "why should this be enforced through this module?" is backward. This module is "check for unknown parameters" not "check a list of parameters and make sure people are using them." The point of documenting |reason= here and making an exception for it in this module's code is to do the exact opposite of "enforce" anything at all: it's to stop throwing errors when people include |reason= (as they very often do) but the template isn't presently doing anything hard-coded with it (which is usually the case).  — SMcCandlish ☏ ¢ 😼  12:16, 2 March 2018 (UTC)
Your opening line is not an invitation to editors, nor is "you do your own homework". All in all it would be enough if you just pointed to the guideline or discussions where this parameter usage is established. - DePiep (talk) 14:18, 2 March 2018 (UTC)
Fine, I could have posted differently; can you please address anything substantive? See also WP:WIKILAWYER; actual practice establishes consensus quite clearly; it does not always derive from rule-thumping or arguing stuff to death on talk pages.  — SMcCandlish ☏ ¢ 😼  19:29, 2 March 2018 (UTC)
SMcCandlish: Showing an error and an error category when people use |reason= (or any other parameter that is not supported) and it is not supported in a template is exactly the purpose of this template. – Jonesey95 (talk) 16:08, 2 March 2018 (UTC)
Please read the actual thread. Using |reason= as a pseudo-parameter is a widespread convention we should account for and not do violence to; it is not an error, it's just something different. Different != bad.  — SMcCandlish ☏ ¢ 😼  19:28, 2 March 2018 (UTC)
I have read every word of the thread. Saying that something is true does not make it true. The burden is on SMcCandlish to show that |reason= as an unsupported parameter is in widespread use and that there are reasons for that purported "widespread convention". As a start, link to a search result that shows the number of articles using |reason= as an unsupported parameter.
Adding |reason= as a parameter that will not be classified as unsupported in any template where this module is used means that invalid uses of |reason= will go undetected. That is a drawback. Because that drawback exists, the burden is on SMcCandlish to show that any benefits of excluding |reason= outweigh the drawbacks. Put in a different way, can you show a case where this module is causing harm by adding a hidden error category to an article that uses |reason= in a template in the way that is described by SMcCandlish above? – Jonesey95 (talk) 17:58, 3 March 2018 (UTC)
I already have demonstrated it [6]. Please stop playing WP:ICANTHEARYOU games.  — SMcCandlish ☏ ¢ 😼  11:58, 7 March 2018 (UTC)
The link SMcCandlish provided immediately above shows that |reason= is used in templates. Of course it is, when it is supported. The first hit in the search when I click on the link is a {{clarify}} template, which explicitly supports |reason=. I asked you to link to a search result that shows the number of articles using |reason= as an unsupported parameter. The link immediately above is not that. You would need to exclude the roughly 129 templates that explicitly support the |reason= parameter. Within those results, you would need to show examples where this module is causing harm by adding a hidden error category to an article that uses |reason= in a template, as I wrote above. And please stop with the inaccurate personal accusations. They do not help your case. – Jonesey95 (talk) 14:42, 7 March 2018 (UTC)
Totally bogus request. There is no mechanism by which two distinct uses of |reason= can be teased apart from each other in such search results; you simply have to pick examples from the search results and look at them. I know you know this or you would not actually be competent to be doing significant works in this namespace. So maybe it's not an "I can't year you" issue, but a gaming one, specifically Wikipedia:Gaming the system#Gaming the consensus-building process, point number. It's not an "personal accusation", it's a description of observable debate tactics, which you are using to try to WP:WIN instead of progress towards compromise. This denialism about the use of |reason= isn't going to fool anyone, since they can just go look for a minute or less, at the search results already provided, and see for themselves.  — SMcCandlish ☏ ¢ 😼  12:36, 8 March 2018 (UTC)
I don't understand what the existence of a reason parameter in {{clarify}} has to do with this module. if you want to track the reason parameter in {{clarify}}, then add tracking there not here. Frietjes (talk) 16:19, 8 March 2018 (UTC)

Image error

This module is listing errors which require such edits for fixing. But the issue is this doesn't let to any visual change and hence the community is not willing to accept it as helpful edit. So I guess the module should not list such a page as error or add it to cat. Capankajsmilyo (talk) 18:01, 11 April 2018 (UTC)

you already have a thread open at VPT, no need to have a discussion in two places. Frietjes (talk) 18:07, 11 April 2018 (UTC)

Blank usage

Please enable blank usage of this module. I mean if no parameter is given, it should just auto-fetch all defined parameters of template. Frietjes, would you like to help? Capankajsmilyo (talk) 04:52, 9 April 2018 (UTC)

Capankajsmilyo, that would be expensive. if you want an automated method for adding this with the list of parameters, try User:Frietjes/addcheckforunknownparameters.js. Frietjes (talk) 13:02, 9 April 2018 (UTC)
Thanks. This is definitely better but not exactly what I'm looking for. Any other alternative method to reduce Infobox code or automate things? Capankajsmilyo (talk) 05:21, 11 April 2018 (UTC)
string parsing the infobox code every single time you use an infobox would be really expensive. it's much better to do the processing once, when you change the parameters, rather than every single time the infobox is used. you could, in theory, make a new self-error checking infobox module, but that would be an entire rewrite. others have suggested having the list of parameters stored separate from the infobox, and have module:infobox call this module directly (since it is already processing the input). but, again, that would require a rewrite, and it's not clear how that would work without the danger of having the parameter list get out-of-sync from the particular infobox code. Frietjes (talk) 17:56, 11 April 2018 (UTC)
Thats seems a good theory to include the check in Module:Infobox itself. Is that possible and/or feasable? This will enable huge lot of editors (not technically capable to get their template errors populated). This will also add the check to numerous infobox which doesn't have the check yet. It will also eliminate the need for code update and most importantly reduce template coding and make it cleaner. That's what I feel. Capankajsmilyo (talk) 18:06, 11 April 2018 (UTC)
go ahead an start writing some code, or see if anyone at WT:Lua or Template talk:Infobox is interested in doing so. Frietjes (talk) 18:09, 11 April 2018 (UTC)
If anybody needs generation of parameters without JS, I added it to russian version as function p.generate. Wikisaurus (talk) 09:53, 25 September 2018 (UTC)
looks very useful. thank you! Frietjes (talk) 12:52, 26 September 2018 (UTC)
please update the module to use this version of the sandbox and credit Wikisaurus in the edit summary. thank you. Frietjes (talk) 12:52, 26 September 2018 (UTC)
@Frietjes: this appears to have over 8million transclusions, can you describe some intensive testing that has been done? — xaosflux Talk 00:19, 27 September 2018 (UTC)
Xaosflux the change adds another function which is not accessed by the main code path. however, given the number of transclusions by this module, it may be better in terms of overhead to keep this new feature in a submodule. I will ask for input at WT:LUA. thank you. Frietjes (talk) 12:38, 27 September 2018 (UTC)

Additional code

@Frietjes: happened to glance at the sandbox and saw you added some code back in September that doesn't look like it ever made it into the live module. I was about to do some testing in the sandbox but didn't want to mess up what you had going on... --Zackmann (Talk to me/What I been doing) 19:18, 30 November 2018 (UTC)

Zackmann08, you can sync it with the main module. if that code is implemented, it will be put in a submodule to avoid additional overhead. Frietjes (talk) 19:20, 30 November 2018 (UTC)

Incorrect error report for ampersand

If I use {{WikiProject Biography}} with |s&a-work-group=yes as documented, all is well. But if I mistype this as |s&a=yes and preview before saving, Module:Check for unknown parameters throws the wrong error:

Warning: Page using Template:WikiProject Biography with unknown parameter "s?a" (this message is shown only in preview).

instead of ... with unknown parameter "s&a" ... Something seems to be misconverting the ampersand into a question mark. --Redrose64 🌹 (talk) 23:06, 29 December 2018 (UTC) This also happens for parentheses. If an article uses {{Infobox train}}, with parameters like |weight (per train set)=335t and |capacity (per train set)=1,240 passengers(360 seats) (see e.g. this revision of MTR Rotem EMU), they are reported as

Warning: Page using Template:Infobox train with unknown parameter "weight ?per train set?" (this message is shown only in preview).

and

Warning: Page using Template:Infobox train with unknown parameter "capacity ?per train set?" (this message is shown only in preview).

Frietjes, is this being looked at, please? --Redrose64 🌹 (talk) 23:37, 23 January 2019 (UTC)

Redrose64, I changed the mangling to something less aggressive. hopefully this is an improvement. it looks like it does some funny stuff to <ref>...</ref>, but until I figure out a better solution, this should work. Frietjes (talk) 12:41, 24 January 2019 (UTC)
Thank you, working as expected now. --Redrose64 🌹 (talk) 19:15, 24 January 2019 (UTC)

False positives

I'm missing something here. I'm trying to add this capability to Template:Amtk/sandbox, but it flags every transclusion. It should be detecting two parameters, |2= and |dab=. Mackensen (talk) 14:19, 6 March 2019 (UTC)

Mackensen, replace |2|dab with |1|3|4 if you want it to track all unknown parameters. you provide a list of the known parameters. if you only want to track |2= and |dab=, you don't need this module, you can just use {{#if:{{{2|}}}{{{dab|}}}|[[Category:Pages using amtk with unknown parameters]]}} instead. Frietjes (talk) 15:26, 6 March 2019 (UTC)
Sigh, thanks. Amazing how you can read the docs and your eyes just skip over the really relevant part. Thanks again, Mackensen (talk) 16:22, 6 March 2019 (UTC)
@Mackensen: I have SOOOOO done that my friend!! Don't kick yourself too hard. :-p --Zackmann (Talk to me/What I been doing) 17:22, 6 March 2019 (UTC)

Fix for T137900

Implement the change in Special:Diff/892193938. After T137900 was implemented yesterday, using the revisionid magic word will not work. As such, this change is needed so the module can continue to work as intended. This change does not change how this template functions.--Snaevar (talk) 20:05, 12 April 2019 (UTC)

Dumb questions from a template editor who does not know Lua: Do you have a test case to illustrate the new functionality? How does the mw.addwarning statement know which closing parenthesis is the end of the statement text? – Jonesey95 (talk) 20:08, 12 April 2019 (UTC)
I have added the module sandbox to Template:Infobox surname/sandbox and then used that template sandbox at User:Jonesey95/sandbox3. I don't see a preview error message, and the error category is not applied. I am probably doing something wrong. Snaevar, you are welcome to edit my sandbox3 page or the Infobox surname sandbox in order to test your changes. – Jonesey95 (talk) 20:16, 12 April 2019 (UTC)
​Yeah, there's some errors in the code; I'll fix the code. (as a side note, if you use User:Jackmcbarn/advancedtemplatesandbox.js, you can preview the sandbox code as if it is the live module, which makes testing as simple as previewing an article that has errors) Galobtter (pingó mió) 05:33, 13 April 2019 (UTC)
FYI, the task explicitly states the revisionid magic word will continue to work to detect preview mode ("This will not be broken.") and it continues to work. Galobtter (pingó mió) 05:33, 13 April 2019 (UTC)
Actually, I think we need to discuss this more; while when Module:Check for unknown parameters is used in infoboxes, the error is displayed at the top the vast majority of the time, it can also be used for other templates not at the top of the page, and the warning is displayed next to the template. We'll need to discuss if it is reasonable to have the warning at the top always. Galobtter (pingó mió) 05:45, 13 April 2019 (UTC)
Template warnings should be displayed adjacent to the template, since templates may occur multiple times on a page. – Jonesey95 (talk) 06:51, 13 April 2019 (UTC)

Entry point for other modules

Could the maintainers of this module add a function to allow other modules (not templates) to use this? Would be very helpful for me. --Gonnym (talk) 15:24, 25 December 2019 (UTC)

I've gone ahead and edited the sandbox to enable this. I've added basic tests to the testcases to show it still works. Again, these are basic tests as this page wasn't setup at all so there are no previous tests to compare. Please review code and tests. --Gonnym (talk) 19:14, 29 December 2019 (UTC)

Out of curiosity, where would you be using this feature? * Pppery * it has begun... 19:48, 31 December 2019 (UTC)
When needed in modules, same as it's usage in templates. I've written a few modules myself where they are needed. --Gonnym (talk) 10:42, 1 January 2020 (UTC)
Again, I would appreciate an example. It seems like the concept of checking for unknown parameters only makes sense for Wikitext arguments, at which point you're likely to have a frame object around anyway so a separate Lua interface is not needed. * Pppery * it has begun... 04:23, 2 January 2020 (UTC)
As a recent example, see getUnknownParametersErrors(args) at Module:Redirect template handler/sandbox. However from reading into your question (and if I'm mistaken, then apologies), I think we differ on design philosophy. Even if that module was called by 1 template (which it isn't), I'd still want the code in the module and not the template. Trying to write code that is close as possible in Wikipedia to some sort of MVC or similar approach, means that when I write a module, I don't want the actual template to have any logic, which includes using this module. --Gonnym (talk) 10:00, 2 January 2020 (UTC)
You're right that we differ in design philosophy (this was already known since February, however you did misunderstand my suggestion, which was to call Module:Check for unknown parameters from Lua, passing it a frame object. The usecase of one submodule handling argument parsing for many different parents modules such as Module:Redirect template handler (sidenote: which really needs a less generic name) does make my suggestion not feasible, however.
From a coding point of view, what is the point of the type checks on args and pargs? The module does nothing useful unless both parameters are given as tables, and it seems better to me to raise an error rather than do nothing when given bad data. * Pppery * it has begun... 20:28, 2 January 2020 (UTC)
Regarding the type check, I agree with you that an error is better and to be honest, would be much better to handle that check right at the beginning of the function before any parameter validation is done. If you prefer that the default module failure error handle this instead, I have no issues with that. --Gonnym (talk) 20:47, 2 January 2020 (UTC)

Request disabled due to lack of consensus. Gonnyn: as a template editor you can make this change yourself if/when you have support for the change. — Martin (MSGJ · talk) 14:12, 6 January 2020 (UTC)

Seems quite a strange close. There was no one opposing and only Pppery who was engaging in a discussion, which means that per WP:SILENCE there was no "lack of consensus". I placed the template so someone other than myself can take a look at the code so closing it is counter-productive, but what's done is done. --Gonnym (talk) 14:32, 6 January 2020 (UTC)
@MSGJ: There is definitely no "lack of consensus" here. * Pppery * it has begun... 23:18, 6 January 2020 (UTC)
Thanks both for confirming your opinions and sorry if I misread the discussion. It looked like a fundamental disagreement on the way forward! If the sandbox is ready I can deploy, or Gonnym can do it. — Martin (MSGJ · talk) 11:05, 7 January 2020 (UTC)
Thanks MSGJ and Pppery, I'll do it later today when I have time. --Gonnym (talk) 11:51, 7 January 2020 (UTC)
 Note: Closing request per Gonnym's comment. qedk (t 桜 c) 17:46, 7 January 2020 (UTC)

False warning of unknown parameter

This module seems to be giving a false claim of an unknown parameter for Template:Infobox disputed islands. You can see this in the usage on James Shoal if you open the edit window and then click the Preview button. Any ideas why it's giving this error? The parameter is clearly in the template, and I've added it to the docs and the Wikidata entry, so I'm not sure what else to do. ···日本穣 · 投稿 · Talk to Nihonjoe · Join WP Japan! 16:54, 22 July 2020 (UTC)

@MSGJ: as the most likely to know. ···日本穣 · 投稿 · Talk to Nihonjoe · Join WP Japan! 16:55, 22 July 2020 (UTC)
 Fixed. All valid parameters need to be added to the parameter check at the bottom of the template. I have added |type=. Also, please put the Template Data programming code into the /doc template, not into the template itself. Take a look at Template:Infobox organization/doc to see how it is normally done. – Jonesey95 (talk) 17:46, 22 July 2020 (UTC)
@Jonesey95: Fixed, I believe. I'm not sure who put that into the template (I haven't looked in the history). Please review the changes to Template:Infobox disputed islands and Template:Infobox disputed islands/doc to make sure I did it correctly. Thanks! ···日本穣 · 投稿 · Talk to Nihonjoe · Join WP Japan! 18:33, 22 July 2020 (UTC)
The documentation looks better. I think you did it correctly. – Jonesey95 (talk) 18:44, 22 July 2020 (UTC)

Preview warning and hatnotes moving to templatestyles

Page watchers may be interested in MediaWiki talk:Common.css § Preview warning and hatnotes moving to TemplateStyles Izno (talk) 00:22, 29 April 2021 (UTC)

Could this be automated?

Forgetting to update this module is one of the most common mistakes when updating a template; I've fallen victim to it a few times myself. Is it necessary to list out all the parameters in a template when using this module, or would it be possible to code it so it just automatically checks for all the parameters defined in the code? {{u|Sdkb}} talk 23:04, 2 September 2021 (UTC)

The module can't always determine which parameters are actually supported. It sometimes fails to pick up valid parameters, and sometimes picks up parameters that are being tested for but are not actually supported. Also, sometimes people remove parameters from the check as a way of deprecating them, even though they are still displayed by the template (not the best process, but it works). An editor needs to oversee the parameter list, unfortunately. – Jonesey95 (talk) 04:31, 3 September 2021 (UTC)
See /Archive 1#Blank usage * Pppery * it has begun... 14:13, 3 September 2021 (UTC)
Thanks for the replies both. That makes sense from the archive that it's an expensive call. Here's a possible alternative: could we set up an edit filter that produces a warning if you try to add a parameter to a template but forget to update this module? {{u|Sdkb}} talk 17:56, 3 September 2021 (UTC)

Unnamed parameters: documentation please

Could someone add documentation on how to declare all unnamed parameters accepted? Or point to examples? I cannot get |regexp1=[%d][%d]* working. Thx. -DePiep (talk) 10:32, 18 November 2021 (UTC)

@Frietjes: -DePiep (talk) 12:02, 18 November 2021 (UTC)
DePiep, this is fixed in the sandbox (positional parameters were not compared with regexp values before the fix). I will request an update to the main module. Frietjes (talk) 15:33, 18 November 2021 (UTC)
Thanks, great. -DePiep (talk) 19:24, 18 November 2021 (UTC)

Protected edit request on 18 November 2021

Please update to this version of the sandbox, which implements this change to allow for the regexp parameters to be applied to positional parameters per the discussion above. the logic is almost direct copy of the logic used for the string parameters, but with some minor tweaks to convert numbers to strings and to continue to support the showblankpos logic. the changes were tested in my userspace tests (User:Frietjes/c4u). Frietjes (talk) 15:37, 18 November 2021 (UTC)

support. My single simple testcase situation confirms (works well). -DePiep (talk) 19:23, 18 November 2021 (UTC)
 Done — Martin (MSGJ · talk) 20:28, 18 November 2021 (UTC)

Sime minor issues with this module

I think line line 6, the function trim does not need to be defined because there is mw.text.trim present. Besides, line 69 frame:preprocess( "{{REVISIONID}}" ) looks strange because frame can be directly used to call the magic word, instead of process wikitext. == SolidBlock (talk) 02:09, 11 December 2021 (UTC)

I notice that there is also a mw.addWarning() function. @Izno as the creator of Module:If preview/configuration, any thoughts on this? Gonnym (talk) 07:43, 11 December 2021 (UTC)
Gonnym, mw.addWarning() adds stuff to the top of the preview for all things emitting a warning, rather than at the 'site' of the template. (Go make a sandbox and try it out, you might be (un)pleasantly surprised about its behavior.) I make no judgement on whether that is good or bad, I just know that if-preview and its friend preview_warning sprang up organically on our side. Izno (talk) 05:56, 17 December 2021 (UTC)
Yes, I suppose (every) module which currently deals with stripping whitespace before/after could use mw.text.trim. No comment on whether that's a good idea.
I do not know what you are talking about regarding using frame to call the magic word directly. What do you have in mind? If you are referring to callParserFunction, I believe I tried that in the context of if-preview and could not make it work. Feel free to spin up a small functioning sandbox to see if it will work the same. Izno (talk) 06:02, 17 December 2021 (UTC)

Preview warning when non-breaking spaces are detected

Hello! I was brought here after a user posted to the Teahouse that they had an issue with an infobox template that resulted from non-breaking spaces being used in the parameter name. When previewing the edit, because of the non-breaking spaces it said it was an unknown parameter. Would it be possible to include some way to cue the user in that it may be due to non-breaking spaces, by either adding something that says "Check for non-breaking spaces" or by giving a unique error message if it detects there are non-breaking spaces in the parameter name? ― Blaze WolfTalkBlaze Wolf#6545 02:03, 18 February 2022 (UTC)

Yes if it clearly mentions what is the issue not only new users also users who lave low experience in this CODING programs can catch the problem easily. ... २ तकरपेप्सी talk 02:13, 18 February 2022 (UTC)

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)

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)
(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)
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)
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)
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)
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)
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)
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)

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)

@Frietjes: any chance you could help me with the above? — Martin (MSGJ · talk) 19:04, 8 January 2023 (UTC)
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)
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)
Thanks both, I will give it a try — Martin (MSGJ · talk) 12:10, 11 January 2023 (UTC)

Works great. I will add instructions to the documentation when I get time. Non-urgent feature request: it would be nice if I could specify which namespaces I want to check unknown parameters in. Easy enough to do locally of course, but would be tidier if it was in this module. — Martin (MSGJ · talk) 13:15, 11 January 2023 (UTC)

Pagenames involved

For de-confusion, pagenames involved:

-DePiep (talk) 07:37, 28 February 2023 (UTC)

Feature request

Would it be possible to distinguish between unknown and deprecated parameters? It would be useful sometimes to track deprecated parameters in a different category, or with a different preview message. — Martin (MSGJ · talk) 20:17, 4 December 2023 (UTC)

Module:Check for deprecated parameters. – Jonesey95 (talk) 16:06, 5 December 2023 (UTC)
Thanks — Martin (MSGJ · talk) 17:42, 5 December 2023 (UTC)

Error category should also be added in preview

If there is an error category for unknown parameters then it's only added in the rendered page, not previews which instead show a preview warning. That can be very confusing. Consider for example Copa Libertadores Femenina (permanent link) with Category:Pages using flagicon template with unknown parameters. The page has 135 {{flagicon}}. The unknown parameter is in {{flagicon|BRA|side=30px}} (should have said size). It's common to track down where a category is added by previewing different parts of the code. That fails here when the category is never added in preview. You can search for the preview warning in the preview but users may not know that. Previews can add things but shouldn't remove things. PrimeHunter (talk) 11:36, 9 December 2023 (UTC)

Lua patterns

Is it possible to add a function to use Lua patterns and also limit the number? For example, if the parameter |date= can be between |date1= and |date8= and using regexp1 = "date[%d]+" and something like reglimit1=8 to limit the allowed parameters? Gonnym (talk) 12:26, 23 June 2024 (UTC)

Why not write a specific pattern? regexp1 = "date[1-8]"
—Trappist the monk (talk) 12:59, 23 June 2024 (UTC)
Didn't even cross my mind to do that for some reason. I'll try that out, thanks! Gonnym (talk) 13:01, 23 June 2024 (UTC)
@Trappist the monk doesn't work. Tested it on TNA Impact! by using the /sandbox version in preview. Gonnym (talk) 13:06, 23 June 2024 (UTC)
Nevermind, got it to work without the quotes of course. I'll update the /doc here. Gonnym (talk) 13:09, 23 June 2024 (UTC)
You could also look at the check at {{Interlinear}} for a fun example. It supports values of 1–99 for some parameters (actually 1 and higher, but I'm hoping nobody will put in more than 99 unnamed parameters). – Jonesey95 (talk) 19:43, 24 June 2024 (UTC)
The pattern [1-9][%d]* (should probably be written [1-9]%d*) is not limited to the range 1–99. %d* means 0 or more digits. So, as long as the first digit is not zero, any number of digits (within reason) will be accepted. If you want to actually limit the range to 1–99 you might use %f[%d][1-9]%d?$ where (right to left) $ anchors the pattern to the end of the parameter name string; %d? means 0 or 1 digits; [1-9] requires the first digit of the enumeration to be in the range 1–9; %f[%d] is the frontier pattern where the next character is a digit but the previous character is not a digit – in abc123 the pattern finds the boundary between c (parameter name) and 1 (first digit of the enumerator).
—Trappist the monk (talk) 22:00, 24 June 2024 (UTC)
Retrieved from "https://wiki.riteme.site/w/index.php?title=Module_talk:Check_for_unknown_parameters/Archive_1&oldid=1247318819"