Template talk:Cfd all

Should the tags for nominating categories to be renamed be purple in stead of pink?

Back in November 2008, David Levy changed {{cfr}} (the tag for nominating categories to be renamed) and {{sfr-c}} (the same, but for stub categories) to be purple in stead of pink ([1], [2]). In December 2009, Rich Farmbrough changed {{cfr}} ([3]), but left {{sfr-c}} unchanged. I think that the purple color was better (it helps distinguish the rename nominations, where the deletion is merely a technicality, from the deletion nominations). I think it should be changed back. עוד מישהו Od Mishehu 08:25, 10 January 2011 (UTC)

Considering quite frequently a nomination to delete takes a turn to rename (or vice versa), I think the delete and rename colors should be the same. Doesn't matter to me, though, what color that is. --Kbdank71 15:31, 10 January 2011 (UTC)

In my opinion, it makes sense to distinguish between a category's renaming (effectively a move, with deletion occurring only on a technical level) and a category's outright elimination (deletion in the traditional sense). If the discussion's focus changes, so can the tag (which can be either switched or doubled up).

Note that we're discussing Wikipedia's formally designated "delete" and "move" colors, so this isn't a matter of aesthetics or an arbitrary distinction drawn only here. If it's decided that it would be better to use a single color across the board, pink makes more sense (because a category's outright elimination doesn't pertain to a move on any level). But I believe that we should apply the same color coding used to designate proposed deletions and moves in every other namespace. —David Levy 16:55, 10 January 2011 (UTC)

I agree with David Levy. To give just one example, WP:TfD follows the red/violet distinction to differentiate between merge and deletion nominations. Categories are different from all other namespaces, because they cannot be moved in the way other pages can, but I don't think this technical distinction influences the experiential one. --Bsherr (talk) 17:53, 10 January 2011 (UTC)

If the discussion's focus changes, so can the tag The problem is, that never happens. We already have people complaining when(for example) the nomination says "rename" and the end result is "delete". I think a change like this will just compound the problem. That said, I don't rely on the tags to notify me of a cfd discussion, so the color (or wording, for that matter) doesn't make a difference to me. --Kbdank71 18:31, 10 January 2011 (UTC)

The problem that you describe exists regardless of what color is used. As you note, people object to such an occurrence anyway, as it's the wording that's most important. The solution is to ensure that the tagging accurately reflects the discussion, not to make all of the tags the same color and hope that people will get the gist. If anything, the absence of Wikipedia's standard color coding reduces the likelihood of someone noticing the discrepancy and switching to or adding the appropriate tag. —David Levy 18:47, 10 January 2011 (UTC)

The solution is to ensure that the tagging accurately reflects the discussion The second someone says "I'd rather delete than rename", the tag is inaccurate. And it doesn't get changed to reflect that. So that really isn't a good solution. Making the colors different just makes it easier to dismiss a discussion because "it's just a rename, not a delete". A better solution is to draw people's attention to the discussion itself, without stating what the nominator wanted (via color or wording). It's a novel approach, but if people are forced to actually read the discussion, instead of assuming how it's going to go based upon a color, there will be far less confusion and complaining. --Kbdank71 19:00, 10 January 2011 (UTC)

The second someone says "I'd rather delete than rename", the tag is inaccurate. And it doesn't get changed to reflect that. So that really isn't a good solution.

I don't follow. The event that doesn't occur isn't a good solution...because it doesn't occur? Wouldn't it be a good solution if it were to occur?

I'll note that a single "delete" comment in a renaming debate (or a single "rename" comment in a deletion debate) doesn't necessarily impact the discussion's focus to the extent that a tag change is warranted. The tagging should reflect the outcomes advocated by substantial segments of respondents. If there is substantial support for both deletion and renaming, there's no reason why both tags (or a combination tag) can't be used. And if a proposal clearly shifts from one change to the other, there's no reason why the tag can't simply be replaced.

Making the colors different just makes it easier to dismiss a discussion because "it's just a rename, not a delete".

Evidently, the template's wording (a far more significant factor than its color) already has that effect.

A better solution is to draw people's attention to the discussion itself, without stating what the nominator wanted (via color or wording).

I like this idea, but until it's implemented, we can only deal with the setup that exists (under which users rightly expect the tag to convey the discussion's nature). In such a situation, Wikipedia's standard practice is to incorporate color coding. —David Levy 20:02/20:27, 10 January 2011 (UTC)

And if a proposal clearly shifts from one change to the other, there's no reason why the tag can't simply be replaced. Ok, that is true. There is no reason why it can't be replaced. But let's be realistic. Sure, it can be replaced. But in the years I've been working CFD, I've never seen it done. So I guess my problem is, how are you going to accomplish this? Who is charged with changing the tag mid-discussion? And how are you going to enforce it? Because if we can't accomplish this, and I don't think we can, then merely changing the color of the tag because "that's what the rest of WP does" isn't solving anything. --Kbdank71 20:40, 10 January 2011 (UTC)

You appear to have misunderstood my position. I don't know how to reliably ensure that the tags are updated, and I'm not suggesting that the use of Wikipedia's standard color coding would solve the problem. My point is that the issue already exists and will continue to exist (unless resolved via unrelated means), regardless of what colors are used. —David Levy 21:02, 10 January 2011 (UTC)

Perhaps. I have been known to do that. :) I am in agreement that the issue exists and will continue to exist, but I do think that different colors for renaming and deleting will just make the problem worse. Perhaps we should work instead on solving the underlying problem? --Kbdank71 21:06, 10 January 2011 (UTC)

I disagree that the color coding would worsen the situation, but I obviously agree that we should work on solving the underlying problem. As noted above, I like your idea to eliminate the differentiation entirely (though I don't know how popular such a proposal would be). —David Levy 21:09, 10 January 2011 (UTC)

I was unaware that I had changed a colour. But I would agree just have a CfD template where d=discussion, colour it the deletion colour since that's a significant chance of being the outcome. Rich Farmbrough, 23:13, 10 January 2011 (UTC).

Shall we put together a formal proposal? —David Levy 00:04, 11 January 2011 (UTC)

Template-protected edit request on 10 July 2015

It seems odd to me that "pages" is bolded while what may actually happen to the pages in question is not. To that end, I propose the following change:

This does '''''not''''' mean that any of the '''{{#if:{{{stub|}}}|stubs|pages}}''' in the category will be deleted. They may, however, be recategorized.<br/>

to

This does '''''not''''' mean that any of the '''{{#if:{{{stub|}}}|stubs|pages}}''' in the category will be deleted. They may, however, be '''recategorized'''.<br/>

Izno (talk) 17:49, 10 July 2015 (UTC)

Well, we want to emphasise that the pages won't be deleted, specifically. Is it better now? Alakzi (talk) 22:49, 11 July 2015 (UTC)

Yeah, taking the bold out works for me. --Izno (talk) 00:56, 12 July 2015 (UTC)

Template-protected edit request on 19 August 2020

Please add .mbox-cfd as a class to this template to make it easier to locate this template using code. Aasim 09:11, 19 August 2020 (UTC)

 Done * Pppery * _{it has begun...} 13:58, 19 August 2020 (UTC)

Template-protected edit request on 26 February 2021

Please add the target2 parameter from {{cfm-double}} to this template. {{Cfm full}} displays it correctly in the top line, e.g. currently at Category:Transport in Karditsa, but not in the "add entry" part of the template for creating the CFD log section. – Fayenatic London 14:17, 26 February 2021 (UTC)

Fayenatic london Currently {{Cfd all}} has no logic for adding target to the first sentence, but if I remember correctly some other templates have it (suboptimally) implemented in the first nameless parameter. Is it something like the following from the sandbox you're looking for?

This category is being considered for merging into Category:TARGET1 and Category:TARGET2.

This does not mean that any of the pages in the category will be deleted. They may, however, be recategorized.
Please share your thoughts on the matter at [[Wikipedia:Categories for discussion/Log/{{{year}}} {{{month}}} {{{day}}}#Template talk:Cfd all|this category's entry]] on the Categories for discussion page. Please do not empty the category or remove this notice while the discussion is in progress.
add entry: {{subst:{{{2}}}2|Cfd all|TARGET1|text=Your reason(s) for the proposed {{{4}}}. ~~~~}}

Administrators: If this category is empty, and all incoming links have been cleaned up, click here to delete.%5B%5BWikipedia%3ACategories+for+discussion%2FLog%2F%7B%7B%7Byear%7D%7D%7D+%7B%7B%7Bmonth%7D%7D%7D+%7B%7B%7Bday%7D%7D%7D%23Template+talk%3ACfd+all%5D%5D

--Trialpears (talk) 13:21, 19 March 2021 (UTC)

@Trialpears: No, after |TARGET1, |TARGET2 needs to be inserted. Two targets appear there when using Cfs, and two are likewise needed in Cfm-double. – Fayenatic London 08:01, 20 March 2021 (UTC)

I think I got it.

This category is being considered for merging into Category:Target1 and Category:Target2.

This does not mean that any of the pages in the category will be deleted. They may, however, be recategorized.
Please share your thoughts on the matter at this category's entry on the Categories for discussion page. Please do not empty the category or remove this notice while the discussion is in progress.
add entry: {{subst:Cfm2|Cfd all|Target1|target2=Target2|text=Your reason(s) for the proposed merger. ~~~~}}

Administrators: If this category is empty, and all incoming links have been cleaned up, click here to delete.%5B%5BWikipedia%3ACategories+for+discussion%2FLog%2F2021+March+20%23Template+talk%3ACfd+all%5D%5D

Like this? Generated from {{cfm-double/sandbox}}. If that's all I can implement it immediately. --Trialpears (talk) 11:59, 20 March 2021 (UTC)

Thanks, yes please... but the next problem is that Cfm2 doesn't then use Target2 in generating the nomination for the CFD log page. – Fayenatic London 18:46, 21 March 2021 (UTC)

Hum, yeah that's a problem, I'm a bit unsure what the optimal way to handle it is though. This part is done now though. --Trialpears (talk) 19:02, 21 March 2021 (UTC)

I have belatedly fixed parameter target2. [4] [5] – Fayenatic London 11:11, 31 May 2023 (UTC)

Hmm, further to the above, my edit to {{cfm2}} [6] works fine when pasted from {{cfm-double}}, but the code

{{#if:{{{target2|}}}| and [[:Category:{{{target2}}}]]}}

is also appended (albeit not displayed) as

{{#if:| and [[:Category:{{{target2}}}]]}}

when sub'sting cfm2 from {{cfm}}, e.g. at Wikipedia:Categories_for_discussion/Log/2023_June_6#Category:Andalusi_manuscripts. How can we make this code generate nothing when target2 is empty, please? – Fayenatic London 13:49, 10 June 2023 (UTC)

OK, user:Qwerfjkl has given me the solution using safesubst. – Fayenatic London 12:22, 11 June 2023 (UTC)