Module talk:Check for unknown parameters
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).
- Documentation (en): de:Wikipedia:Lua/Modul/TemplatePar/en/invoke, +more en-language pages.
- 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)
