Module talk:WikiProject banner/Archive 11: Difference between revisions

Revision as of 04:37, 2 October 2020

Revision as of 12:57, 8 May 2022

Line 161:

I would like to add "class = Disambig" to [[Template:WikiProject Disambiguation]] so that all the tools that rely on PageAssessments data (XTools, CopyPatrol, Popular Pages Bot, etc.) will recognize these pages as disambiguation pages (as most of them don't have any other WikiProject banners). However, this would needlessly categorize all of these pages into a new [[:Category:NA-Class Disambiguation articles|NA-Class Disambiguation articles]] category, which would be silly. Is there any way to suppress the creation of class categories (besides not passing a class)? If not, could a way be added? [[User:Kaldari|Kaldari]] ([[User talk:Kaldari|talk]]) 20:27, 8 December 2017 (UTC)

:I rather think that XTools etc. recognise pages as disambig-class by their being in a subcategory of {{cl|Disambig-Class articles}}, and not by the presence of parameters in WikiProject banners. That being the case, here is what I would do:

:#Modify {{tlx|WikiProject Disambiguation}} to have two new lines: <sourcesyntaxhighlight lang=moin>|QUALITY_SCALE=inline

|class={{class mask |dab|disambig=yes}}</sourcesyntaxhighlight>

:#Create {{cl|Disambig-Class Disambiguation articles}} with the following content: <sourcesyntaxhighlight lang=moin>{{CategoryTOC}}

[[Category:Disambig-Class articles]]</sourcesyntaxhighlight>

:After a while, the category will populate. There should be no need to create any other categories. --[[User:Redrose64|<span style="color:#a80000; background:#ffeeee; text-decoration:inherit">Red</span>rose64]] &#x1f339; ([[User talk:Redrose64|talk]]) 15:59, 9 December 2017 (UTC)

::Or instead of step 1, you could add the category to the banner without displaying the class type. <code><nowiki><includeonly>[[Category:Disambig-Class Disambiguation articles]]</includeonly></nowiki></code> -- [[User:WOSlinker|WOSlinker]] ([[User talk:WOSlinker|talk]]) 20:13, 9 December 2017 (UTC)

Line 196:

:::::I understand the concern of Lua being opaque to you, but either way—multilevel-transclusion conditional wikitext or Lua—we've got complexity that's excluding ''someone''. We should work on making it so that ''most people'' don't have to deal with the complicated stuff, of course, and I think that this project is in line with that through its design goal of moving "adding support for custom processes" (like A-class reviews) away from weird systems and so on into "just specify some extra properties for the class definition".

:::::I think that our goals synergize well: we both want these systems to be easy to use and well-documented. My approach is just more dramatic, mostly by pushing things from "implement stuff yourself in wikitext" to "use the standard systems the banner module offers". My ''personal'' preference would be that we just force every WikiProject to use only a single standard set of classes and processes—that would give us site-wide consistency at a stroke—but I know that that's not politically feasible. As an alternative, I'm trying to make a system that offers support for custom classes and processes but ''makes them machine-readable'' so that we can deal with them (and yes, presumably ''document'' them) mostly automatically. <span style="white-space:nowrap;">{&#123;[[User:Nihiltres|<span style="color:#233D7A;">Nihiltres</span>]]&#8202;&#124;[[User talk:Nihiltres|talk]]&#8202;&#124;[[Special:Contributions/Nihiltres|edits]]}&#125;</span> 17:32, 30 August 2017 (UTC)

::::::OK, here's an example. I've just improved [[Template:WikiProject Libraries/doc]]; whilst doing so, I found an unusual line in [[Template:WikiProject Libraries]]: <sourcesyntaxhighlight lang=moin>|INFOBOX = yes</sourcesyntaxhighlight> Wondering what the effect of that might be, I looked in the source of [[Template:WPBannerMeta]] for the sequence <code><nowiki>{{{INFOBOX</nowiki></code> and not finding it, I knew straightaway that the parameter was unrecognised, and I could safely ignore it. If [[Template:WPBannerMeta]] had been converted to a module, there would have been ''no way'' for me to find out whether that parameter is recognised or not, regardless of the difficulty in determining (if recognised) exactly what it does. --[[User:Redrose64|<span style="color:#a80000; background:#ffeeee; text-decoration:inherit">Red</span>rose64]] &#x1f339; ([[User talk:Redrose64|talk]]) 08:47, 3 September 2017 (UTC)

:::::::If that's a desired feature, we could easily implement a parameter check like several templates do, and put out an error message when previewing the results. <span style="font-variant:small-caps; whitespace:nowrap;">[[User:Headbomb|Headbomb]] {[[User talk:Headbomb|t]] · [[Special:Contributions/Headbomb|c]] · [[WP:PHYS|p]] · [[WP:WBOOKS|b]]}</span> 12:20, 3 September 2017 (UTC)

::::::::Parameter checks which display error messages on preview - such as the one that I {{diff|Template:Infobox London station|prev|796859992|recently added}} to {{tlx|Infobox London station}} - are fine if the person adding that check knows what the valid parameters actually are. Once a template has become a module, you no longer know this. You are then dependent upon the module writer to keep the valid parameter list up to date, something which we cannot guarantee will be done, just as we cannot guarantee that those who amend templates will also amend the documentation. Any computer programmer will tell you that fully-documented functions are an ideal that is never achieved. --[[User:Redrose64|<span style="color:#a80000; background:#ffeeee; text-decoration:inherit">Red</span>rose64]] &#x1f339; ([[User talk:Redrose64|talk]]) 12:48, 3 September 2017 (UTC)