Module talk:Parameter validation

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
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.

Module improvements[edit]

Following up from Template_talk:Infobox_station#Parameter_validation:

  1. Userspace: No, perhaps not. Depends entirely on the template, but for infoboxes I suppose that may be correct. Editors may use a infobox on their main userpage though. Should that be categorised, if they're using invalid params? The module has flexibility to allow templates to do as they choose, so it's mostly a question of what's the sane default.
    • However, it is worth noting that bots may use these categories for maintenance work. Bots can be approved for non-articlespace work. And it's generally more performant to have them look over a precise category of params, than go through all transclusions or have to setup temporary cats for each run.
  2. Hmm, yes, that would be a good idea. I will see what I can do.
  3. The config page doesn't currently have knowledge of the number of entries in the list, which lies in the module. We can do "unknown parameter(s)"?

ProcrastinatingReader (talk) 23:18, 22 October 2020 (UTC)[reply]

  1. The standard Module:Check for unknown parameters allows for the use of {{main other}} to limit application of categories, while always showing the error message in preview mode. That way, a user-space or draft-space editor could see the red error message and fix their draft, but regular editors would not be bothered by user/draft-space pages cluttering up a maintenance category for actual encyclopedia articles. This module should provide that same capability in some form. If editors of a specific template want to expand categorization to other namespaces, they can do so, and then bots can do their work. The choice should be available to template editors.
  2. OK to trying to show both duplicated parameters. Something like "duplicate parameters: image/imagename, caption/image_caption" should work (that's two sets of duplicates in one message, to be clear).
  3. "unknown parameter(s)"/"deprecated parameter(s)" is a reasonable workaround. "duplicate parameters" will always be plural, since there are at least two. – Jonesey95 (talk) 23:35, 22 October 2020 (UTC)[reply]
1) Set {{main other}} as default for categorisation. Might need to parse it for it to work, actually, will test. Just working on the live config in module, since it's not actually being used anywhere, so using a separate sandbox is moot. Template editors can create custom configs for use and use them via parameter 3. This is documented in the module docs ("JSON-encoded string" / "Template:PV default options" part). It would seemingly be quite rare for infoboxes to deviate from the default, though.
3) Done
ProcrastinatingReader (talk) 15:03, 23 October 2020 (UTC)[reply]

Category naming tweaks[edit]

I don't know Lua at all, so I haven't figured out where categories get named. The normal tracking cats at Category:Infoboxes with unknown parameters use a lower-case "i" for the word "infobox" in the category name, but this module appears to assign an upper-case "I". I think we should go with the de facto standard. – Jonesey95 (talk) 15:48, 23 October 2020 (UTC)[reply]

Cause of issue is that this module pulls the page title. The page title in MediaWiki has uppercase I. Thought was to move over individual templates' cats to the uppercase with a technical move request, but we could also just obey the lowercase. It would mean doing a substitution on the template's actual title changing "Infobox" -> "infobox". Also maybe worth pinging Frietjes as they developed the other checking modules, so they may also have thoughts on this and may be able to spot other issues with the module on top of what you've identified. ProcrastinatingReader (talk) 16:33, 23 October 2020 (UTC)[reply]
We should be able to use simple string processing to change the first letter of the template name to lower case. – Jonesey95 (talk) 16:44, 23 October 2020 (UTC)[reply]
That may cause issues for templates whose titles are a proper noun, or otherwise intentionally capitalised. Code would have no way of knowing if the first letter is an intentional capital or not. So I think we can only account for the "Infobox" -> "infobox" case here. ProcrastinatingReader (talk) 17:30, 23 October 2020 (UTC)[reply]
True enough. We could have a parameter "template-name" for those edge cases. – Jonesey95 (talk) 18:00, 23 October 2020 (UTC)[reply]

Preview warning and hatnotes moving to templatestyles[edit]

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)[reply]

Request: sort pages in category by the first unknown parameter name[edit]

The standard usage of Module:Check for unknown parameters sorts pages in the unknown parameters category by the first unknown parameter name that is found. For example, if a page called Bar used the unknown parameter |foo=, Bar would be sorted under "foo" (under "F") on the category page. The standard documentation for unknown parameter category pages, {{Unknown parameters category}}, explains this: Pages are typically sorted alphabetically by the unknown parameter that is used, e.g. pages using unknown parameter |foo= will be sorted under "F". The name of the page is typically used as a secondary sort key.

Can someone please adjust this module so that it conforms to this standard usage and documentation? Thanks. – Jonesey95 (talk) 01:50, 9 May 2023 (UTC)[reply]

I took a look at the code for this, and was hopelessly confused. This is why we shouldn't have multiple modules doing the same set of things ... * Pppery * it has begun... 16:51, 9 May 2023 (UTC)[reply]
This module idea is great (and I was thinking of converting some templates to it until reading this), but I agree with Pppery that we shouldn't have multiple modules (and we have more than 2) that do the same thing. That isn't helpful. Gonnym (talk) 11:47, 27 November 2023 (UTC)[reply]
The module also appears to depend on TemplateData, which is often inaccurate and is not protected, since it is part of the template's documentation subpage. – Jonesey95 (talk) 04:54, 28 November 2023 (UTC)[reply]