Content deleted Content added
m Archiving 1 discussion(s) from Template talk:WPBannerMeta) (bot |
m MSGJ moved page Template talk:WPBannerMeta/Archive 11 to Module talk:WikiProject banner/Archive 11: discussion more relevant to module not the wrapper template Tag: Disambiguation links added |
||
(3 intermediate revisions by 2 users not shown) | |||
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: <
|class={{class mask |dab|disambig=yes}}</
:#Create {{cl|Disambig-Class Disambiguation articles}} with the following content: <
[[Category:Disambig-Class articles]]</
: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]] 🌹 ([[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;">{{[[User:Nihiltres|<span style="color:#233D7A;">Nihiltres</span>]] |[[User talk:Nihiltres|talk]] |[[Special:Contributions/Nihiltres|edits]]}}</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]]: <
:::::::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]] 🌹 ([[User talk:Redrose64|talk]]) 12:48, 3 September 2017 (UTC)
Line 413:
::I think there's a case for renaming it FP-Class since it's used exclusively for Featured Pictures. Maybe that's a discussion for [[WP:VP]] though? [[User:PC78|PC78]] ([[User talk:PC78|talk]]) 22:41, 18 September 2019 (UTC)
:::I would suggest leaving it at FM class just in case [[Wikipedia:Featured sounds]] ever gets restarted — Martin <small>([[User:MSGJ|MSGJ]] · [[User talk:MSGJ|talk]])</small> 11:21, 30 September 2019 (UTC)
== What does ¬ do? ==
What does the ¬ character do in this template? Why is it important to use <pre>{{{category|¬}}}</pre> and not <pre>{{{category|}}}</pre>? I am asking because I was having trouble with {{cl|NA-Class Animals in media articles|count=yes}} depopulating after adding a class subpage to {{tl|WikiProject Animals in media}}. I noticed that the ¬s were missing, added them, and the category emptied. --[[User:NessieVL|Nessie]] ([[User talk:NessieVL|talk]]) 19:11, 1 October 2019 (UTC)
:It helps the template to spot the difference between {{para|category}} being present but blank, and being completely absent. --[[User:Redrose64|<span style="color:#a80000; background:#ffeeee; text-decoration:inherit">Red</span>rose64]] 🌹 ([[User talk:Redrose64|talk]]) 20:13, 1 October 2019 (UTC)
:It basically tells that whatever has ¬ in it isn't desired. So <pre>{{{category|¬}}}</pre> means 'don't categorize'.  <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> 20:14, 1 October 2019 (UTC)
== Importance params - undiscussed change ==
{{u|Wugapodes}}, where was {{diff|Template:WPBannerMeta|prev|955070895|this edit}} discussed? I don't even see it in [[Template:WPBannerMeta/sandbox|the sandbox]], so it can't have been tested either. --[[User:Redrose64|<span style="color:#a80000; background:#ffeeee; text-decoration:inherit">Red</span>rose64]] 🌹 ([[User talk:Redrose64|talk]]) 20:56, 5 May 2020 (UTC)
:Nowhere, and it wasn't. Having a single parameter that uses a completely different naming scheme from the rest of the parameters is a horrible design, so—assuming editors will expect a consistent naming scheme—we should at least accept the dominant naming scheme as an option. Seemed pretty obviously uncontroversial. It's an alias, so it doesn't break templates that use the idiosyncratic name for this parameter; I've created a parameter alias before, so I didn't feel the need to test that the software still does aliases the way it always has. <span style="white-space: nowrap;">— [[User:Wugapodes|Wug·]][[User talk:Wugapodes|a·po·des]]</span> 21:14, 5 May 2020 (UTC)
::Thanks for starting this discussion Redrose, I have reverted this change. The naming scheme is actually very logical and I see no reason to change it without proper discussion. You will notice that uppercase parameter names are ones defined by the banner template whereas lowercase parameter names are defined at the article level. So the banner templates just pass these through <nowiki>|class={{{class|}}}</nowiki> etc. — Martin <small>([[User:MSGJ|MSGJ]] · [[User talk:MSGJ|talk]])</small> 21:30, 5 May 2020 (UTC)
:::That's great for developers but incredibly unintuitive for end users who are using the template. I didn't just make the change on a whim, it's a problem I actually ran into while editing. <span style="white-space: nowrap;">— [[User:Wugapodes|Wug·]][[User talk:Wugapodes|a·po·des]]</span> 21:36, 5 May 2020 (UTC)
::::WPBannerMeta isn't intended for general use, it should only be used within WikiProject banners, where we expect a certain level of competence in the art of template editing. That said, its doc page does give a full list of parameters that if copied and pasted will already be in the correct form. --[[User:Redrose64|<span style="color:#a80000; background:#ffeeee; text-decoration:inherit">Red</span>rose64]] 🌹 ([[User talk:Redrose64|talk]]) 22:04, 5 May 2020 (UTC)
::{{ec}} It's not "a horrible design", it's a deliberate design. There are two kinds of parameters, distinguished in two parallel ways: by having their names in upper or lower case, and by using underscores or spaces. Those in upper case (with underscores) are configuration parameters, setting characteristics that, regardless of the talk page that the WikiProject banner is used on, do not change themselves - {{para|TF_1_LINK}} for the page to link to, {{para|TF_1_NAME}} for the text to show for that link, {{para|TF_1_IMAGE}} for the image, params for the categories and so on. By contrast, those in lower case (with spaces) are used to pass values through from the individual talk pages: {{para|tf 1}} and {{para|tf 1 importance}}, etc. Since there are two of these for each task force, your claim "a single parameter that uses a completely different naming scheme from the rest of the parameters" is incorrect.
::Please revert your change, sandbox it and obtain consensus. --[[User:Redrose64|<span style="color:#a80000; background:#ffeeee; text-decoration:inherit">Red</span>rose64]] 🌹 ([[User talk:Redrose64|talk]]) 21:34, 5 May 2020 (UTC)
=== RfC on parameter alias ===
Should the {{code|tf n importance}} parameter of {{tl|WPBannerMeta}} accept an alias that makes it consistent with the other {{code|TF_N_DESCRIPTION}} parameter names? <span style="white-space: nowrap;">— [[User:Wugapodes|Wug·]][[User talk:Wugapodes|a·po·des]]</span> 22:14, 5 May 2020 (UTC)
;Background
Currently, {{tl|WPBannerMeta}} has some parameters that use {{code|ALL_CAPS_UNDERSCORED}} style, and others that use {{code|all lower spaced}} style. The style difference is due to how the inputs are handled by the meta template. Configuration parameters use the all-caps style, while those passed from the article are in the lowercase style. For wikiprojects that have task forces, this leads to code such as:
<pre>
|tf 1={{{floridiae|}}}
|TF_1_LINK = Wikipedia:Wikiproject Tulips/Task forces/Floridiae
|TF_1_NAME = the Floridiae task force
|TF_1_NESTED = Floridiae
|TF_1_TEXT =
|TF_1_IMAGE = Tulipa florenskyi 4.jpg
|tf 1 importance={{{floridiae-importance}}}
|TF_1_ASSESSMENT_CAT = Floridiae articles
|TF_1_MAIN_CAT = Floridiae articles
</pre>
If a template uses {{code|TF_1_IMPORTANCE}} the meta template fails silently. In {{diff|Template:WPBannerMeta|prev|955070895|this edit}} I added an alias so that the template will accept either {{code|tf 1 importance}} or {{code|TF_1_IMPORTANCE}}, and it was reverted.
;Rationale
Allowing either style is more intuitive for editors who create wikiproject banners. While the ''wider'' style is consistent, for those maintaining or adding functionality to task force sections of banners, the most obvious parameter name given the data above is {{code|TF_1_IMPORTANCE}}. Should an editor make that assumption, the meta template gives no indication that something is wrong, and the reason why this task force parameter is different from the others is not obvious. Using an alias so that the template accepts either style makes the interface more intuitive and prevents silent errors when an editor assumes the naming scheme is like the other {{code|TF_N_DESCRIPTION}} parameters. The change is backwards compatible, and no existing transclusions will be broken.
<span style="white-space: nowrap;">— [[User:Wugapodes|Wug·]][[User talk:Wugapodes|a·po·des]]</span> 22:14, 5 May 2020 (UTC)
* No please do not. The current naming of the parameters is sensible and logical. Adding additional aliases for parameters which are not even used by article editors is not helpful, may cause confusion and template bloat — Martin <small>([[User:MSGJ|MSGJ]] · [[User talk:MSGJ|talk]])</small> 22:34, 5 May 2020 (UTC)
*'''Oppose''' There is no demonstrable need. WikiProject banners are not created frequently, and are sufficiently complex that the documentation should be checked each time - it is bad practice to guess at the name of ''any'' parameter. This is why we have provided boilerplates that may be copied and pasted. --[[User:Redrose64|<span style="color:#a80000; background:#ffeeee; text-decoration:inherit">Red</span>rose64]] 🌹 ([[User talk:Redrose64|talk]]) 22:37, 5 May 2020 (UTC)
*It does seem to me that at least the lower case param should not be in the middle of the all caps params but should rather come after the other lower case param, <code>tf 1</code> (in the boilerplate). Grouping params by their type makes it less likely to use the wrong naming convention. [[User:Galobtter|Galobtter]] ([[User talk:Galobtter|pingó mió]]) 23:12, 5 May 2020 (UTC)
*:I have no opposition to that. People normally just copy and paste from the boilerplate. — Martin <small>([[User:MSGJ|MSGJ]] · [[User talk:MSGJ|talk]])</small> 11:12, 6 May 2020 (UTC)
|