Wikipedia:Categories for discussion/Log/2021 April 16

The cat is useful to determine the extent of non-hyphenated CS1 param usage; similar non-error cats exist like Category:AC with 0 elements.

It could actually even make/keep the case for keeping non-hyphenated params in the future. Regardless, everyone interested can easily see, and track, if they choose, the size and/or contents of the cat, instead of performing a large array of disparate searches to

dgaf)  18:34, 16 April 2021 (UTC)[reply

]

Moving on from the meta matters, I do not see that the second close of the RFC demonstrates that this category cannot continue to exist. Were we to remove the relevant parameters from the documentation and continue to put little green messages that these are discouraged and a category to go with the latter, that in no way would actually be contrary to the close from the RFC (which I'm |this close| to challenging itself given that the headcount at AN was almost all "I'm a C person and I don't like the close"). But even if you can argue that there shouldn't be little green messages and a category that says "discouraged", you still haven't demonstrated that these can't be tracked in some way. Whether for maintenance or otherwise. We have multiple such categories already in the CS1/2 system, so you can't even approach it from a "this would be inconsistent" (or you could nominate the rest I guess, but good luck with that consensus). So, straight Keep, second option rename/move. --Izno (talk) 21:13, 16 April 2021 (UTC)[reply]

Is this a suggestion that an RfC will be needed in order to create a category? A software writer may have legitimate technical reasons to create/delete categories as needed and as a way to gauge end-user usage. I am not fond of categories that produce visible errors, but I have no problem with tracking categories especially since there are very few diagnostics/survey tools available to those who produce the software that this CfD nomination nitpicks. 65.204.10.232 (talk) 13:15, 17 April 2021 (UTC)[reply]

I'm not suggesting an RfC would be needed (although I'm not going to stop you if you want one) just a simple talk page consensus that the non-zero overheads of adding thousands of pages to a category will bring some actual benefits to the project that are greater than those overheads. As it stands I'm struggling to understand what these benefits are, and it appears I'm not the only one (including some people who know far more about templates than I do). It is also clear that some people very clearly believe they exist, and indeed the failure to successfully communicate what they are does not mean they do not exist, but it does strongly suggest that at the very least more discussion is required before the existence of the category can be said to be a net benefit to Wikipedia. Thryduulf (talk) 00:30, 18 April 2021 (UTC)[reply]

To repeat, there is no obligation whatsoever - in policy, guidelines, or common practice - for an editor to submit a maintenance/tracking category for approval to the wider community. Especially a technical one such as the one now discussed. The place for such discussion is at the appropriate page (the talk page for the module). And categorization is being discussed there, often in a somewhat technical manner because this is a technical subject. If you have followed these discussions, you would have seen that it is not unheard of for categorization to be introduced speculatively. That is, without a goal per se, but in order to discern how the software is used, or because of a hunch that established practice is inefficient and data is required to make informed design decisions. Or for any other reason that may or may not impact, now or in the future, continuing maintenance. Apart from that. The question of overhead is not entirely relevant. Under such assumptions, any categorization is suspect. Overhead is an objective quantity measured in page load time, server overload and all kinds of other tangible things. What you call "actual benefits" is a subjective evaluation. Using one to justify the other is a false comparison. When you mix the two, the result is also an evaluation, because opinions always contaminate facts. So what are we doing here? Wasting time, a familiar practice in these "discussions". In the meantime, the reasoning for deleting the category becomes more & more convoluted, with tinges of paranoia. As if the continuing existence of this category is a nefarious conspiracy that soils the purity of the precious RfC outcome. This may be becoming more enjoyable by the minute. 98.0.246.242 (talk) 03:33, 18 April 2021 (UTC)[reply]

There are only two sorts of actions on Wikipedia: Those that are uncontroversial and those that need consensus before being implemented. While making a tracking category might normally be uncontroversial this one clearly isn't, therefore it needs consensus. Thryduulf (talk) 11:25, 20 April 2021 (UTC)[reply]

And what is the nature of the "controversy"? Apart from the fact that the nom thinks that these parameters don't need maintenance because they were linked to an RfC. That's over and done, and the result is being complied with. Time to move on and stop obsessing about this. 24.103.101.218 (talk) 12:47, 20 April 2021 (UTC)[reply]

Are you seriously claiming that a discussion that has approximately equal numbers of editors in favor of deletion and retention is not controversial? The nature of the controversy is shown by this very discussion's existence. (And it's not just the nom who has the opinion that these parameters don't need maintenance because they were linked to an RfC; I do as well, as do (I presume) the many editors who explicitly cited my comment as a reason for deletion) * Pppery * _{it has begun...} 13:06, 20 April 2021 (UTC)[reply]

Sure, anything can be whipped up into a frenzy. Especially when you start with foregone conclusions, like "maintenance is not needed". Which is as interesting or relevant as any other opinion. Here's another one: centering your argument on your "personal interpretation" of what you think is the gist of the RfC close Here is the fact: the RfC decided that certain parameters should not be deprecated, and that they should not presented as "discouraged" or anything else. The "controversy" may just be this nomination, which expands the RfC close to cover the mundane workings of module maintenance. Because of what? bad faith assumptions and conspiracy theories? 66.65.114.61 (talk) 15:21, 20 April 2021 (UTC)[reply]

The category itself has no maintenance purpose whatsoever, since the citations it flags do not need changing as per the RfC. Nikkimaria (talk) 18:35, 17 April 2021 (UTC)[reply]

(edit conflict) None of these "this has a set maintainance purpose" comments are explaining what that maintenance purpose is or why, in the post-RfC world, people are caring whether parameters use hyphens or not at all. * Pppery * _{it has begun...} 18:39, 17 April 2021 (UTC)[reply]

There is no obligation for module maintainers to explain the reasoning behind a housekeeping task such as the existence of a tracking/maintenance category. At least I have not seen any policy, guidance or even widespread practice that mandates submission of such tasks for approval by the wider community. Feel free to enlighten me and anybody else who wonders what the fuss is all about. The pathology regarding this non-issue is somewhat amusing. 98.0.246.242 (talk) 22:11, 17 April 2021 (UTC)[reply]

There is a general obligation for all Wikipedia editors to explain the reasoning behind any decision they make when asked to do so in good faith. Just because something is usually uncontroversial does not mean it always will be or remove the obligation to gain and follow consensus when it is. Indeed complaining about being asked to explain and justify rather than explaining and justifying when asked does not encourage others to view your arguments in good faith. Thryduulf (talk) 11:20, 20 April 2021 (UTC)[reply]

And you do not think that explanations were provided in this discussion? Even when there is a case to be made that this was not a good faith nomination? Just because there was an RfC of very narrow scope and purpose that was decided solely by counting hands does not mean these or any parameters are placed in a "special" category. They can, and should be, tracked like any other parameter. 24.103.101.218 (talk) 12:47, 20 April 2021 (UTC)[reply]

Indeed, I do not think that any explanation was actually provided, despite repeated requests from me and from many other editors. I've seen only the unsubstantiated assertions of usefulness or lack of harm, attempts to set up for future relitigation of the RfC, and the tautology The cat is useful to determine the extent of non-hyphenated CS1 param usage (from Tom.Redding's comment), which immediately brings up the question of what the purpose of determin[ing] the extent of non-hyphenated CS1 param usage is. * Pppery * _{it has begun...} 13:06, 20 April 2021 (UTC)[reply]

Can you tell us what makes tracking these parameters different from any tracking category? I mean apart from forever linking its existence to a personal interpretation of the RfC's close. At least try to provide some evidence of underhand practice or conspiracy before you assign motivation. Or should any tracking category be suspect? They could be used to undermine all sorts of things. Or one could AGF and wait for a crime before rushing to arrest. 66.65.114.61 (talk) 15:21, 20 April 2021 (UTC)[reply]

WP:OTHERSTUFFEXISTS is not a persuasive argument. I would personally support deletion of several of the categories you provided as examples. Besides, I (and I presume the many editors who say "per Pppery et al.") don't support deletion solely because the category tracks things for which no action needs to be taken, but because (in my interpretation) the gist of Option C of the big RfC is that editors should not care whether citation parameters are specified as |access-date= or |accessdate= and this category constitutes caring about that difference. By contrast, no consensus says that editors should not care about whether articles use slang, whether archive boxes use the |box-width= parameter, the publication frequency stated in {{infobox journal}}, etc. * Pppery * _{it has begun...} 00:55, 18 April 2021 (UTC)[reply

]

That RfC is not a persuasive argument. It had nothing to do with tracking categories. And no tracking category that I know of has ever been created based on the premise of editors should not care or editors should care about the pages that populate that cat. As noted above, template:tracking category has a specific meaning/definition. Isaidnoway (talk) 09:26, 19 April 2021 (UTC)[reply]

1. The category is implemented as a maintenance category. As per the new RfC close, what it's flagging is not something that requires maintenance. This implementation is actively causing issues, such as cluttering up reference popups. If a tracking category is needed at all (see #3 below), this category is not that, no matter what the wording says.
2. The category was created solely as a function of the initial RfC close, which has now been reversed. Thus it follows that it is appropriate for the categorization also to be reversed. It was not created because anyone independently thought it was a good idea, and the post-hoc justifications do not change that.
3. When fully populated, the category can be anticipated to have millions of entries. Something that huge should have a comparatively strong rationale behind it; none has been presented. Rationales so far have suggested it's "useful" but have not specified for what purpose, or why a less invasive solution such as searching is inadequate for whatever those needs may be. The fact that other tracking categories exist is not a rationale to make more of them (possibly others may warrant deletion, but this isn't the place to address that).
4. Also per Thryduulf. Nikkimaria (talk) 02:12, 18 April 2021 (UTC)[reply]

If you look at the proper place to discuss this (that is Help_talk:Citation_Style_1#RFC_reclosed, not here), you will see that the category will likely be renamed to a more neutral name (although the second closure of the RfC does in no way mandant this) and changed to a mere tracking category, so it won't cause any visual clutter, but is still there for those to inspect who care about it. This is nothing new, we are doing this for all kinds of other properties as well - and for years, and we do not need RfCs or CfDs for this. And if the OP wouldn't have decided to undermine the normal good-faith process by starting a totally unnecessary parallel discussion here instead of participating there, we would likely be further already in adjusting stuff according to the outcome of the RfC.

However, if there is one thing that the RfC has shown, it is that there are two very large community groups of people with opposing views who do care about the topic. The fact, that the RfC could be closed in vastly different ways within just a couple of days also demonstrates that there is no true underlying consensus in the community in regard to the topic. A good RfC closure can still indicate some path how to proceed, but it cannot keep people from having opinions just because someone says so. Among well-meaning people it should be possible to find a workable solution and, if the arguments are good, to even convince one another in peace rather than attempt to force people to act in undesired ways.

Either way, it is clear that this is, unfortunately, a topic that will continue to interest people of both sides for years to come and the second closure has further enlarged this interest. So, even if this particular category is new, it is clear, that it is needed now even more than it was before the RfC. One of the fundamental ideas of Wikipedia in general, and for citations specifically, is to present knowledge based on provable facts and in a neutral way. This tracking category helps to get insight. People who are trying to suppress facts-based information gathering are not in line with our principles, they are agenda-driven trouble-makers harming the project.

--Matthiaspaul (talk) 09:31, 18 April 2021 (UTC)[reply]

I have not only looked but have participated in the discussions at CS1 (Help_talk:Citation_Style_1#RFC_reclosed and Help_talk:Citation_Style_1#Protected_edit_request_on_16_April_2021); they have convinced me to post here. Simply renaming (never mind keeping as-is, as suggested above) is not a viable solution given the RfC, and name-calling is not a viable means of working towards a collaborative solution. Nikkimaria (talk) 00:51, 19 April 2021 (UTC)[reply]

There is nothing in the (second) closing that prohibits a tracking category for non-hyphenated parameters. The RfC option chosen, among other things, removes "discouraged" as a description for such parameters. As long as a category name adheres to that nomenclature, what is the problem? The RfC decided a very specific issue. Other than that narrow scope, there is nothing to say. The RfC close certainly did not dictate what editors should be interested in or not, never mind the "personal interpretation" of the "gist" of the RfC by Pppery. So why is such a category not "viable"? 98.0.246.242 (talk) 02:05, 19 April 2021 (UTC)[reply]

The category was implemented only as a result of the first closure; since that's been undone, so too should the changes resulting from it. Nikkimaria (talk) 01:16, 20 April 2021 (UTC)[reply]

Not necessarily. The category should be renamed to comply with the RfC, and that is about it. It was created because of the superseded close, but that does not mean that it is useless otherwise. Parameter usage is regularly tracked in CS1/2 for a variety of reasons or no reason, for purely informational purposes. The fact that similar information can be found with a properly structured search is neither here nor there. Such logic invalidates the existence of any tracking/maintenance category, not just the one under discussion. 98.0.246.242 (talk) 04:44, 20 April 2021 (UTC)[reply]

Yes necessarily. Looking at the bigger picture: no one thought a tracking category would be useful in the events leading up to the RfC, or during the RfC itself. This maintenance category was implemented solely because of an RfC close that has since been undone. Post-hoc justifications are now being made to try to maintain elements of that undone close and undermine the intentions of the new close. In that context, this is not a typical tracking category, not something solely informational (see the suggestion below that it could be used for mass edits), and not something uncontroversial. Nikkimaria (talk) 12:49, 20 April 2021 (UTC)[reply]

It may come as a surprise that maintenance categories often result, or are used to determine the need for mass edits. This category is no different, with one exception: per the RfC, it cannot be used to deprecate, remove, or "discourage" the usage, of the parameters it covers. Just like any other RfC, this applies until another RfC decides differently. This could be next week or never. And there we are. There are no post-hoc justifications, because nobody needs to justify such use. Actually, following the extraordinary RfC process, it would not be surprising to ask that such a category be created, if it hadn't existed already. Just to give an easily accessible ongoing picture of the related usage. The controversy here could be that some consider this a controversy. 66.65.114.61 (talk) 15:21, 20 April 2021 (UTC)[reply]

It's not a surprise at all, and that's my point. If another RfC reaches a different conclusion in future, then a maintenance category to facilitate mass editing may be appropriate, and such a category could easily be implemented at that point. But that's not where we are today. Nikkimaria (talk) 01:51, 21 April 2021 (UTC)[reply]

First, the existence of a tracking category does not mean any mass edits will happen. Secondly this category does no harm. And as long as it complies with the RfC, there is no issue. Any tracking category can be implemented at any time. Who decides when? I trust the editors of the related project to propose when they should be created. Whatever the related project is, the existence of such maintenance categories should be discussed at the project's talk page. Not as a part of a prejudicial nomination at CfD. 71.167.45.141 (talk) 13:06, 21 April 2021 (UTC)[reply]

This implementation is actively causing issues, such as cluttering up reference popups. Where?

For this category, this is the markup emitted by cs1|2 templates:

<span class="cs1-maint citation-comment">CS1 maint: discouraged parameter ([[:Category:CS1 maint: discouraged parameter|link]])</span>[[Category:CS1 maint: discouraged parameter]]

which MediaWiki modifies to this:

<span class="cs1-maint citation-comment">CS1 maint: discouraged parameter (<a href="/wiki/Category:CS1_maint:_discouraged_parameter" title="Category:CS1 maint: discouraged parameter">link</a>)</span> – the category link from the template is listed elsewhere in the html source with all of the other categories attached to the article

The css class, cs1-maint, is defined at Module:Citation/CS1/styles.css at line 92 which, as you can see, hides the messaging by setting display to none. The css class, citation-comment, is not defined by cs1|2 but is a legacy form that remains available to editors for use as they see fit.

To see the maintenance messaging, editors need to use some sort of css in their custom .css pages. This is described at Help:CS1 errors § Controlling error message display. None of your .css pages have this css (or its citation-comment legacy form). It is possible that a script in one of your .js pages is applying the css for you. If it isn't a script, perhaps your chosen skin is ignoring the markup. If not your chosen skin then perhaps you have custom css in your browser.

When I open an incognito browser and, without logging in, look at any article in Category:CS1 maint: discouraged parameter (how easy that is...) I don't see any maintenance messages in the references that popup when I hover over a reference superscript. That suggests to me that the issue is not with cs1|2 but with something custom to your browser, to your scripts, to your skin. When you discover the cause, let us know so that we can document it at Help:CS1 errors.

—Trappist the monk (talk) 16:29, 18 April 2021 (UTC)[reply]

WP:POPUPS. Nikkimaria (talk) 00:51, 19 April 2021 (UTC)[reply

]

Looks like that tool is pretty oddly crippled. Examples:

• text rendered by templates, in this case {{lang-fr}}, is omitted; see Canadian Confederation – empty parentheses following bolded article title in the lede
• the tool ignores css in some cases but applies it in others
  • redlinks aren't displayed as redlinks; see Peter Turk#Prizes where both links are redlinks (Permalink). Redlinks are styled by class="new" – don't know where new is defined
  • cite errors (created by cite.php) are styled in the popup; click this link and hover over the reference 32 superscript to see a styled error message; that styling is applied by class="error mw-ext-cite-error" – don't know where error and mw-ext-cite-error are defined
  • cite errors (created by Module:Citation/CS1) are styled in the popup, even those that are hidden; click this link and hover over the reference 1 superscript to see a styled error message; that styling is provided by class="cs1-hidden-error error citation-comment" – cs1-hidden-error is defined at Module:Citation/CS1/styles.css at line 83, citation-comment is not defined as described above, don't know where error is defined

These limitations are not the fault of cs1|2, so these issues should be taken up elsewhere; see Wikipedia:Tools/Navigation popups § Feedback.

—Trappist the monk (talk) 14:02, 19 April 2021 (UTC)[reply]

Using a gadget last seriously developed c. 2010 (and only maintained in elementary ways since) will break in ways similar to Ttm's listing. If you are seeing crud in it, it is decidedly the fault of that gadget. Izno (talk) 15:15, 19 April 2021 (UTC)[reply]

Is this a new rule? I did not know that categories are to be deleted when they reach a certain size. And what size might that be? 98.0.246.242 (talk) 18:56, 18 April 2021 (UTC)[reply]

• The "rule" is not about size but about purpose. Categories are created for the purpose of easy navigation between similar articles, or for the purpose of maintenance. Neither easy navigation nor maintenance can realistically be achieved with a size like this. Marcocapelle (talk) 19:48, 18 April 2021 (UTC)[reply]

  I am glad that size has nothing to do with this rule. Is there a category that includes categories that have unrealistic expectations of navigation or maintenance due to... size...?? Maybe I can help in their deletion. To get a better idea of what I should be doing, please point me to the log of such deletions, and the attendant rationale. 98.0.246.242 (talk) 19:57, 18 April 2021 (UTC)[reply]

  This "large categories are useless" argument is incorrect. The size of this tracking category will give editors useful information about how many pages will be affected by any proposed change or mass edit proposed in a future RFC. Other tracking methods, including insource searches, are not as accurate as tracking categories. Tracking categories can easily be intersected with other categories and templates using Petscan to look for a wide variety of conditions in pages. As for the usefulness of category size, Category:Living people currently has 996,154 pages, but that is not seen as a problem by the community. Editors can make decisions about mass edits and perform intersection searches using categories of this (or any other) size. – Jonesey95 (talk) 17:50, 19 April 2021 (UTC)[reply]

  • If an article count is needed in a next RFC, that count can be done as a one-off exercise at the start of that RFC. A permanent category is not needed for that purpose. Marcocapelle (talk) 21:24, 19 April 2021 (UTC)[reply]

  Searches provide sufficiently granular information for any future RfC. Editors should not be making mass edits based on this category - this is a rationale for deletion, to avoid that kind of behaviour. Nikkimaria (talk) 01:16, 20 April 2021 (UTC)[reply]

  • I wonder where all these new rules come from. Why is any category considered "permanent"? Why is a so-called permanent category prohibited from certain purposes that may be related to it? Why should editors not be making mass edits based on certain categories? Are there any objective answers? Or is it just throwing something in the argument to see if it sticks. 98.0.246.242 (talk) 04:31, 20 April 2021 (UTC)[reply]
    • I was countering an argument to keep the category. That has nothing to do with rules, that has to do with discussion processes. Please do not conflate the two. Marcocapelle (talk) 05:40, 20 April 2021 (UTC)[reply]

      Correct. Part of the "discussion process" is to question statements that seem unrelated or opportunistic. Maybe that's what this is. 24.103.101.218 (talk) 12:47, 20 April 2021 (UTC)[reply]

      • My comment was most certainly not unrelated, it was a direct reaction on an earlier comment. Marcocapelle (talk) 17:11, 20 April 2021 (UTC)[reply]

Why not? Please explain. 24.103.251.114 (talk) 12:03, 19 April 2021 (UTC)[reply]

M.Nelson: Tracking categories are used for this purpose all the time. Many examples are given above. – Jonesey95 (talk) 17:50, 19 April 2021 (UTC)[reply]

Tracking categories can be created at any time for any reason related to the relevant project. They don't require a specific "issue". I recommend heading to the project talk page and voicing your opinion, with justification (please), over there. Btw, that category is being renamed to comply with the RfC both in spirit and letter. 50.74.165.202 (talk) 14:15, 21 April 2021 (UTC)[reply]

You should ask the nominator. Since the relevant category was renamed to comply with the RfC, this may be a frivolous nomination, a good example of the link you posted. 50.74.165.202 (talk) 14:15, 21 April 2021 (UTC)[reply]

• It's the other way around: it was the CS1 maintainers who disrupted the work of the rest of us by deprecating and converting nonhyphenated parameters. The RfC was what was necessary to convince them to stop. Levivich ^harass/_hound 14:41, 23 April 2021 (UTC)[reply]