Content deleted Content added
m Archiving 1 discussion(s) to Module talk:WikiProject banner/Archive 16) (bot |
|||
| (3 intermediate revisions by 2 users not shown) | |||
Line 110:
:::::::Perfect, looks like you've solved the generalization problem entirely. [[User:Pharos|Pharos]] ([[User talk:Pharos|talk]]) 18:24, 7 July 2025 (UTC)
:::::::This does the job for this, but I would have liked to see a solution that was more expandable down the road by others that wouldn't require so much intervention into the actual banner lua code. (i.e. something less generic that wouldn't have a whole chunk of code just for taskforces in the global lua banner code) Does that make any sense? [[User:Tduk|Tduk]] ([[User talk:Tduk|talk]]) 02:05, 8 July 2025 (UTC)
::::::::No sorry, I can't understand your point. Can you give an example? I've put some of my thoughts below — Martin <small>([[User:MSGJ|MSGJ]] · [[User talk:MSGJ|talk]])</small> 15:30, 11 July 2025 (UTC)
:::::::::Maybe I'm missing something; what happens when someone comes along with a new parameter they would like to be added to the configuration file? [[User:Tduk|Tduk]] ([[User talk:Tduk|talk]]) 17:28, 11 July 2025 (UTC)
My thoughts on the possible benefits to moving to the configuration page approach:
* Simplification of syntax so <code><nowiki>{{{parameter1|{{{parameter2|{{{parameter3|}}}}}}}}}</nowiki></code> is replaced with something like {{para|trigger|parameter1, parameter2, parameter3}}
* Avoid having to pass through parameters completely, so things like {{para|attention|<nowiki>{{{attention|}}}</nowiki>}} will be removed
* Ability to do smarter things like comma-separated task forces (see above).
* Potentially add better support for projects like US Roads which uses {{para|state|AL}} instead of {{para|AL|yes}} and for Women in Red which uses an indefinite number of unnumbered parameters.
* More robust parameter checking and auto documentation which would include aliases. The current setup reads the wikicode of the template and attempts to work out what each parameter does. This has a performance impact.
* Significant simplification of module code which would make it easier for editors to maintain.
— Martin <small>([[User:MSGJ|MSGJ]] · [[User talk:MSGJ|talk]])</small> 15:29, 11 July 2025 (UTC)
== Assessment issue with "inactive" WikiProjects ==
Line 124 ⟶ 134:
:You have understood the situation pretty well. There is a {{para|PROJECT_STATUS}} parameter, which accepts values like "inactive" and "defunct", but currently the only effect is a slight change in wording and a microformat. Yes it would be possible to change in the way you suggested, if there was consensus for this. The current situation rests on rough consensus from 2022; please see [[Wikipedia:Village pump (miscellaneous)/Archive 73#Improper handling of assessment for inactive WikiProjects]] for more — Martin <small>([[User:MSGJ|MSGJ]] · [[User talk:MSGJ|talk]])</small> 08:26, 9 July 2025 (UTC)
::Good stuff, cheers for the link! Fun to see the origins of [[WP:PIQA]], and thanks again for all of your work on it. Thinking about it, a more resilient fix (and one that is beneficial in all cases) would be to make the creation of the assessment categories easier; I might take a look at rewriting [[Wikipedia:Version_1.0_Editorial_Team/Generate_categories|this bot]], as well as fixing the templates so that they display a warning about running the bot instead of just erroring out. [[User:Aluxosm|Aluxosm]] ([[User talk:Aluxosm|talk]]) 03:43, 13 July 2025 (UTC)
| |||