Wikipedia talk:Templates for discussion/Archive 26

Page Size Exceeded

So we need to discuss the size of this page. Currently the page is landing in Category:Pages where template include size is exceeded. Pppery is doing a valiant effort trying to cut down the page size so that things will transclude properly, but in my opinion their solution (which they have self-described as a hack) is creating other problems. For example, edits like this. While yes that does cut down the size of the page, there is a reason that {{tfdl}} is used for template links on a TFD page. I think we need to look at other solutions. Do we really need to be transcluding ALL tfds onto one page? What about just a link to the currently open discussions? It should be noted that part of the reason this is coming up is that there is a group of us who are working to eliminate unused templates, so we are nominating a LOT of templates for discussion. In the coming weeks I predict a dramatic increase in the number of templates being discussed so I think we need to figure out a good long term solution. @Gonnym, Jonesey95, Tom (LT), and Pppery: I'm sure you will all want to chime in here. --Zackmann (^{Talk to me}/_{What I been doing}) 21:42, 27 February 2019 (UTC)

I think this specific iteration of the problem will likely go away when all the discussions on the same days as the very highly-attended infobox merge discussions near the bottom of the backlog are finally closed, but you are right about the general idea. {{3x|p}}ery (talk) 21:57, 27 February 2019 (UTC)

@Pppery: gotcha. Well let me know. I appreciate you attempts to fix the issue. --Zackmann (^{Talk to me}/_{What I been doing}) 22:33, 27 February 2019 (UTC)

@Pppery: I'm going to have to strongly recommend you stop the hack you're doing as I just realized that it breaks XFDcloser from working correctly. When there are bulk nominations, that is particularly important. --Zackmann (^{Talk to me}/_{What I been doing}) 00:34, 28 February 2019 (UTC)

... just revert my edit when you try to close the nomination. The template limit issue is more pressing that what will happen days in the future. {{3x|p}}ery (talk) 00:39, 28 February 2019 (UTC)

Zackmann08, I endorse Pppery edits in log pages. But I think when TfD is in Category:Pages where template include size is exceeded, we can use {{tl}} template in a mass templates nomination. When a closer is closing TfD, they should use {{tfd links}} temporarily. After closing, use {{tl}}. Hhkohh (talk) 00:55, 28 February 2019 (UTC)

@Hhkohh: that creataes a whole extra level of complexity for those of us closing these nominations. Now we have to go in and edit each nomination just to be able to close it? --Zackmann (^{Talk to me}/_{What I been doing}) 00:57, 28 February 2019 (UTC)

@Pppery: in essence what you are doing is saying that in order to facilitate the use of Wikipedia:Templates for discussion to view EVERY open nomination, you are going to restrict the ability of editors to use the TFDL links on every other nomination. If the pages are so big that they won't transclude, then go view the pages themselves. Don't restrict the content so that the entire page can be transcluded. Either way, I would ask that you please follow WP:BRD and now discuss this before making any additional changes that remove {{tfdl}} from pages. --Zackmann (^{Talk to me}/_{What I been doing}) 01:01, 28 February 2019 (UTC)

Zackmann08, because this issue has been appeared last year, see last year this date page history. Oh, I forgot it! If log page is no longer transcluded in TfD (all nominations in this log page has been closed). Back to TfD links template Hhkohh (talk) 01:07, 28 February 2019 (UTC)

Zackmann08, Also, there is a rare TfD case. See WP:Templates for discussion/Log/2018 April 20#Mass Fb team templates Hhkohh (talk) 01:10, 28 February 2019 (UTC)

I don't know anything about the history of this page and why it appears to transclude every TFD discussion. Would it be possible to "noinclude" sections with closed discussions on this page? That might help. – Jonesey95 (talk) 07:50, 28 February 2019 (UTC)

Jonesey95, good idea! But no need to perform further action for now because TfD page is not in Category:Pages where template include size is exceeded for now Hhkohh (talk) 08:33, 28 February 2019 (UTC)

We had this problem over at WP:PR (see my documentation page). The solutions are (1) close more threads or (2) transclude less either via not including full text, or including full text partially with a size limit as we do over there. Cheers --Tom (LT) (talk) 09:53, 28 February 2019 (UTC)

I've addressed thi problem on many pages over the years. In this case the issue seems to be overly officious attempts to "clean-up" the template name-space. If you need the name of an existing unused template, then you have a case to delete it. And for some of the old redirects like {{Physics}} there may be a case for preemptively clearing the way. But a lot of the stuff people are trying to delete lives at names that are unlikely to be wanted. It would be more useful put the effort into categorizing these templates in case they are useful in the future, rather than into analysis of whether they are useful now (which I venture to suggest, many !voters don't actually do). All the best: Rich Farmbrough, 10:56, 28 February 2019 (UTC).

One thought, @Evad37: could you possibly update XFDcloser so that it does not include |module=}} in every nomination? Obviously if the module link is needed it can be included, but removing it when not used would be great. Only saves 10 characters, but those will add up! See this diff for example... Many thanks in advance. --Zackmann (^{Talk to me}/_{What I been doing}) 18:36, 28 February 2019 (UTC)

That's not an XFDCloser thing, that's a Template:Tfd2 thing (I wrote the code), and no that can't be easily done without re-duplicating all the code in the current implementation of Template:For loop. {{3x|p}}ery (talk) 20:22, 28 February 2019 (UTC)

Pppery, can we modify {{tfd top}} template? Like {{rfd top}} template, after closing the discussion, we only see a result summary instead of the whole discussion in WP:TfD Hhkohh (talk) 21:48, 28 February 2019 (UTC)

That could in theory be done, but wouldn't resolve much of the problem, since open TfDs contribute more than closed TfDs. {{3x|p}}ery (talk) 21:49, 28 February 2019 (UTC)

I think it will resolve more. Try it! Although opening ones are more than closed ones. But why WP:RfD works well? Hhkohh (talk) 21:53, 28 February 2019 (UTC)

Pppery, can you update the TfD top code? Thanks. BTW, now February 21 is excluded now Hhkohh (talk) 22:10, 28 February 2019 (UTC)

I think consensus is necessary for that change, and if it is done, the better solution would be to get AnomieBOT to #section-h the open discussions in the "Old discussions" section. Furthermore, I don't like the way RfD does it, because it is a hack that relies on Template:Rfd top producing unclosed wikimarkup. {{3x|p}}ery (talk) 22:14, 28 February 2019 (UTC)

Pppery, we also should modify {{tfd bottom}} as well to avoid unclosed wiki markup. Oh, WP:TFD/All is down now Hhkohh (talk) 22:19, 28 February 2019 (UTC)

The main reason is today TfD log is over 100+ nominations Hhkohh (talk) 22:24, 28 February 2019 (UTC)

I have borrowed format from CfD. Hope works well Hhkohh (talk) 22:38, 28 February 2019 (UTC)

Just my 2 cents, I LOVE the current format of just linking to the last 7 days. A+++++ --Zackmann (^{Talk to me}/_{What I been doing}) 00:06, 1 March 2019 (UTC)

Looks like the problem is resolved now. What I would have suggested is <noinclude>-ing {{tfd links}}, and putting plain links in <includeonly> tags – or if there are a whole bunch in one nomiation, noinclude-ing all the tfd links except the top few, and putting something like "and 16 more, see [link to logpage discussion]" in the includeonly. - Evad37 [talk] 00:56, 1 March 2019 (UTC)

That's rather clever. {{3x|p}}ery (talk) 02:07, 1 March 2019 (UTC)

@Evad37 and Pppery:, good idea but if the mass TfD goes closed, we should back to previous version. Hhkohh (talk) 07:13, 1 March 2019 (UTC)

... although I personally think that when Zackmann08 finishes his unused-template-cleanup campaaign and the number of open nominations goes down, we should revert to the original method, except for the obvious change of not showing closed discussions that were opened on the same day as open ones. {{3x|p}}ery (talk) 01:39, 2 March 2019 (UTC)

• Ha Hhkohh (talk) 01:41, 2 March 2019 (UTC)

@Hhkohh: "Ha" how? {{3x|p}}ery (talk) 01:43, 2 March 2019 (UTC)

@Pppery: I concur. Once the number of TFDs per day returns to a normal number, we should definitely revisit this. :-) --Zackmann (^{Talk to me}/_{What I been doing}) 20:35, 2 March 2019 (UTC)

• And now the elephant in the room. If there are so many TfD nominations that the main page can't load them all, then possibly, maybe, I guess, it might be the case that there are, well, too many TfD nominations. We do need volunteers to look at and comment on nominated templates. Or has the recent surge of nominations of unused templates been matched by an equal increase in the availability of editors willing to participate?. – Uanfala (talk) 00:49, 3 March 2019 (UTC)

The elephant in the room is that it has become far too bureaucratic to nominate unused and hence unnecessary templates for deletion. If admins were willing to act rather than wait for discussion that either doesn't happen or takes a long while, the problem would diminish. Peter coxhead (talk) 09:08, 3 March 2019 (UTC)

I think the "elephant in the room" comment is a bit out of place. From one side there was an objection of allowing unused templates to be speedy deleted, and now from the other that either don't nominate unused at all or just nominate less. Can't have it both ways and this is just the compromise we all have to make I guess. --Gonnym (talk) 15:46, 3 March 2019 (UTC)

with so many open discussions, it's hard to get useful feedback, and we have situations like this one where the only additional comment is "keep", but the discussion closes as "delete". in the past, these would have been relisted. Frietjes (talk) 16:28, 3 March 2019 (UTC)

Frietjes, in fairness that should have been relisted. Not really sure why the closer made that decision. Primefac (talk) 02:06, 4 March 2019 (UTC)

@Frietjes: I think I need to agree with Primefac here. I'm happy to give my rationale if people are really interested, but at the end of the day I think I got a little overzealous here. Need to step back and be a bit more cautious with closing of TFDs, particularly because I am NOT an admin. --Zackmann (^{Talk to me}/_{What I been doing}) 18:29, 4 March 2019 (UTC)

I have asked for a deletion review of Template:Nippon Professional Draft by year. Because you closed the deletion discussion for this page, speedily deleted it, or otherwise were interested in the page, you might want to participate in the deletion review. Hhkohh (talk) 06:29, 9 March 2019 (UTC)

Challenge

So I wanted to issue a challenge to everyone watching this page... Let's see if we can get the Wikipedia:Templates for discussion/Holding cell down to ZERO! :-) And yes, I realize this is coming from the guy with like 500 open TFDs.... But would be great to get some assistance with finishing up the stuff in the Holding Cell. Just a fun idea. --Zackmann (^{Talk to me}/_{What I been doing}) 01:00, 9 March 2019 (UTC)

@MarnetteD, DannyS712, JJMC89, Hhkohh, and Pppery: pinging frequent contributors to the holding cell. --Zackmann (^{Talk to me}/_{What I been doing}) 17:45, 11 March 2019 (UTC)

I will be happy to help when I can Zackmann08. Best wishes to everyone that works on this. MarnetteD|Talk 23:43, 11 March 2019 (UTC)

Backlog monitoring

Thanks to some cunning Lua programming by @Pppery at Module:XfD old, I have created a template to dynamically display the current state of the backlog at WP:CFD and WP:TFD.

The template is {{XFD backlog}}. --BrownHairedGirl (talk) • (contribs) 03:03, 15 March 2019 (UTC)

Point of clarification re CSD of UNUSED doc templates

There are a whole host of unused documentation templates (1,111 to be exact). The vast majority are the result of the base page being redirected. For example, you have Template:Bible/doc. Well Template:Bible now redirects to Template:Bibleverse. Since the base page has been redirected, there is really no reason to keep the documentation. Technically you COULD redirect the old doc as well, but why? Again I want to emphasize this is ONLY regarding documentation subtemplates (I.E. Template:<sometemplate>/doc) that are UNUSED. It seems to me this is a clear WP:G8. Anyone have any strong feelings? --Zackmann (^{Talk to me}/_{What I been doing}) 20:13, 13 March 2019 (UTC)

This is not a G8, as the parent page does exist. What is wrong with redirecting the doc of the old template to the doc of the new template? {{3x|p}}ery (talk) 20:21, 13 March 2019 (UTC)

To clarify, does G8 then apply to documentation pages for deleted or otherwise nonexistent templates? I would assume so, as documentation pages are technically subpages, though it is not entirely clear. ComplexRational (talk) 02:35, 14 March 2019 (UTC)

Yes, I would say so. If Template;X doesn't exist and wasn't speedy deleted out of process, then Template:X/doc is a proper G8 deletion. {{3x|p}}ery (talk) 02:49, 14 March 2019 (UTC)

If you really want to pursue the claim that doc pages of redirects should be deleted, then take it to the proper venue (RfD) rather than misusing speedy deletion criteria that do not apply. {{3x|p}}ery (talk) 20:23, 13 March 2019 (UTC)

For goodness sake Pppery AGF. I'm discussing it at templates for deletion because they are TEMPLATES. You are of the opinion that G8 is not valid, but so far that is just your opinion. --Zackmann (^{Talk to me}/_{What I been doing}) 20:29, 13 March 2019 (UTC)

Transcluded to Wikipedia talk:Criteria for speedy deletion. {{3x|p}}ery (talk) 20:32, 13 March 2019 (UTC)

• Simply redirecting them or deleting them per WP:CSD#G8 are both perfectly fine and functionally equivalent options. -- Ed (Edgar181)
• Support only for non-subst templates. like CSD C1. It should await 7 days after tagging CSD before actually deletion. For any subst templates, should always be posted to TfD Hhkohh (talk) 23:01, 13 March 2019 (UTC)
• Zack, some of these could be the result of cut-and-paste moves, if the template at the base page was moved. Some could also be the result of a merge, for which the page should be preserved for attribution, and might not be properly labeled as such. I'd worry that expanding a speedy deletion criterion to this therefore could be problematic. --Bsherr (talk) 01:16, 14 March 2019 (UTC)
  • Template:Black metal is a redirect. There is absolutely no justification for keeping any sub-pages: Template:Black metal/doc was, quite rightly, deleted. — RHaworth (talk · contribs) 19:02, 14 March 2019 (UTC)

    ok. Based on feedback from two admins (Edgar181 & RHaworth) I am going to continue to CSD these templates. If anyone else has any strong feelings, feel free to {{ping|zackmann08}} me. --Zackmann (^{Talk to me}/_{What I been doing}) 20:30, 14 March 2019 (UTC)

• In my opinion these /doc pages leftovers should be deleted. A redirect has a function (or purpose if you will), in that it serves to lead users reaching it to the correct end-point. How exactly would a user reach an unused and unlinked sub-page of a page that itself was redirected? The only way is by manually searching for that exact title, and that should not be a valid result for a page that serves no purpose. --Gonnym (talk) 21:22, 14 March 2019 (UTC)

  (edit conflict) In reply to Gonnym, who I edit-conflicted with: I'm not necessarily saying we need to keep these unused or otherwise "orphaned" /doc subpages. I'm just saying that CSD is completely inappropriate to use in this case. I don't think you need to go about putting in a TFD for every one (hell, I don't really think we need to worry about these pages), but at the very least there needs to be a discussion to determine their fate. Primefac (talk) 21:24, 14 March 2019 (UTC)

  As seems to be case with all the latest discussions making the system more efficient, more bureaucratic proceedings which serve absolutely no editors. The result of this will be that they will just get put up on TfD slowly, make the discussion list longer for no reason, and end up with the same exact arguments - "unused and should be deleted" and "redirect to new /doc page" - as there can't be any other argument (for valid unused /doc pages of redirect). --Gonnym (talk) 21:33, 14 March 2019 (UTC)

  Or Zach could go through and BOLDly redirect all of the /doc subpages and call it good. It's a heck of a lot easier to undo the creation of a redirect than it is to deal with an undeletion, should it prove necessary. Primefac (talk) 21:38, 14 March 2019 (UTC)

  Exactly, if we're striving for efficiency and we absolutely must do something about these doc subpages, then redirecting them is the one action that's the least time for everyone. And yes, a proposal for extending some CSD criterion to cover them is unlikely to pass: they don't do any harm that I can think of and there all sorts of problems that can arise if they get deleted: attribution could get broken (as pointed out by Primefac), or it might be difficult to fix errors resulting from template merges if you don't have access to the merged template's documentation. – Uanfala (talk) 02:29, 15 March 2019 (UTC)

• No. ​ The /doc subpages do not meet the criteria of G8, and WP:G6 is not a deletion criteria that means "well I don't really like it so it should be deleted". In the Black Metal example above, the /doc actually precedes the newer doc, and there could have been an attribution issue if the newer /doc had been copied from the old one. There is nothing in G8 or G6 that allows for deletion of these templates, barring IAR from admins who don't really care and just click "delete" when they see a CSD tag. Primefac (talk) 21:24, 14 March 2019 (UTC) Reasonable argument made below... still not overly thrilled but w/e. Primefac (talk) 00:12, 16 March 2019 (UTC)
• Support CSD If the base template was made into a redirect, then G6 should apply: the doc template was "orphaned as the result of a consensus at WP:TfD". In other cases, I note that the list at G8 says "Examples include", not "these are the only possible cases" as some above seem to want to interpret it. An unused doc subpage would be "a page dependent on a nonexistent page": doc subpages exist only to document a template, and if there's no template to be documented then it's dependent on something that doesn't exist. If someone really did do a cut-and-paste move of the doc page (but not the template? why?), WP:REFUND exists. Anomie⚔ 23:51, 15 March 2019 (UTC)

  Eh... fair point. I suppose my main concern is that some admins don't care why a template/page has been nominated, just that it's not an "obviously wrong" tag. I know REFUND exists, but I would just strongly caution anyone wanting to deal with this "issue" to take care and not just batch-nominate 1k+ pages, because that's when mistakes get made. Primefac (talk) 00:12, 16 March 2019 (UTC)

Requested move 9 March 2019

The following is a closed discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. Editors desiring to contest the closing decision should consider a move review after discussing it on the closer's talk page. No further edits should be made to this section.

The result of the move request was: moved (closed by non-admin page mover) SITH (talk) 14:10, 16 March 2019 (UTC)

---

• Module:TfdLinks → Module:Tfd links

– Module and template should have the same name. {{3x|p}}ery (talk) 04:33, 9 March 2019 (UTC)

• Aren't these move requests a lot of make-work? Why should a module match the name of a template, particularly when it is possible that the module will do extra things in the future? I mean this as a serious question because I don't know if a discussion somewhere has decided that uniformity is required. The template says "This template uses Lua: Module:TfdLinks" so there is little room for confusion. Johnuniq (talk) 04:44, 9 March 2019 (UTC)

  Why should a module not match the name of a template? To me, there's no reason for the naming of a module that does nothing but implement a template to not have the same name as it; that's just arbitrary inconsistency. And this module has no potential for growth in my opinion, and in the unlikely event more functions are added, the name can be discussed then. {{3x|p}}ery (talk) 05:01, 9 March 2019 (UTC)

  The fact that you may feel that it's not necessary for a module to have the same name as the template it implements does not mean that my efforts to reduce said inconsistency are "make-work"? {{3x|p}}ery (talk) 05:02, 9 March 2019 (UTC)

  Pppery, Module move cannot leave a redirect due to technical reason. As we happened last year Hhkohh (talk) 05:08, 9 March 2019 (UTC)

  ... I knew that already. In this case, it's not a problem because the module is only used by the template {{3x|p}}ery (talk) 05:10, 9 March 2019 (UTC)

• Reasonable move, but this is the wrong page for this? --Izno (talk) 05:29, 9 March 2019 (UTC)
• Cool and make sense Hhkohh (talk) 06:44, 10 March 2019 (UTC)

---

The above discussion is preserved as an archive of a requested move. Please do not modify it. Subsequent comments should be made in a new section on this talk page or in a move review. No further edits should be made to this section.

Please can the consensus above be implemented? SITH (talk) 14:11, 16 March 2019 (UTC)

 Done StraussInTheHouse although you should actually use WP:RMTR for these kind of requests. Galobtter (pingó mió) 15:04, 16 March 2019 (UTC)

Galobtter, thanks, I've applied +te at WP:PERM/T because I'm seeing more of these types of requests. SITH (talk) 15:25, 16 March 2019 (UTC)

New script!!!

FYI all, I wrote a little user script that others might find useful... User:Zackmann08/unwatch_deleted.js. All it does is add an Unwatch deleted link to the tools when you are on your watchlist. This will remove recently deleted pages from your watchlist. Feedback welcome! --Zackmann (^{Talk to me}/_{What I been doing}) 20:56, 16 March 2019 (UTC)

Changing when non-administrative closures are permitted

Editors may be interested in participating in this discussion about what types of non-administrative closures are permissible. Best, Barkeep49 (talk) 16:35, 22 March 2019 (UTC)

I'm concerned about NACs

I have been pinged lately to a number of TFD-related DRV discussions regarding what some view as poor closures by non-admin editors. Some of these discussions are awfully troubling (supervotes, closing a discussion one is involved in, etc). While I most definitely appreciate the support of these editors in helping to keep the backlog down, I am also concerned that they're trying a little too hard to either be the "first" or the "fastest" or (heaven forbid) purely using TFD as a gateway towards an RFA. I have left a few notes in a few places, and I think the editors I'm referring to know who they are, but before I start wondering if there should be a temporary moratorium on NACs at TFD (for specific editors or everyone) I thought I would just say something.

Again, I totally appreciate the work everyone is doing, both here and at the Holding Cell. However, we all need to remember to weigh consensus (not count !votes) and also remember that TFD isn't as highly-patrolled as other XFD categories. Some quick tips:

• If a discussion has only one vote (especially if it's a "keep") it should probably be relisted.
• If you !vote on a discussion, you should consider yourself involved and thus recuse yourself from relisting or closing.
• If you're on the fence about how to close a discussion, then don't close it (you're welcome to comment/vote of course).

We all make silly mistakes (my talk archives can attest to that), so don't beat yourself up if you've made some, but also remember that a small(ish) backlog at TFD isn't the end of the world (especially now that we've got our new layout that will keep the page a little more manageable). Take your time, make good decisions. Cheers, Primefac (talk) 20:13, 11 March 2019 (UTC)

@Primefac: yea this DEFINITELY applies to me... Appreciate the reminder. I'm being MUCH more careful about not closing things that I've commented on in anyway. --Zackmann (^{Talk to me}/_{What I been doing}) 20:40, 11 March 2019 (UTC)

Thanks Primefac, it's not always easy to close discussions and I want to say your and other editors' work is very much appreciated. You make some reasonable points in a levelheaded way that I hope are taken on board. --Tom (LT) (talk) 21:33, 11 March 2019 (UTC)

If I could a piece of general advice re the Holding Cell? It's great that people have been working so efficiently, but it's only natural that mistakes do occasionally happen – we all make mistakes, that's fine. But when a mistake has been pointed out – it might not always feel very pleasant (nobody likes being told they've made a mess!), and it might be natural to feel like responding with something not nice in return, but the decent thing is to go back and fix those mistakes. We can't expect other people to do that for us, and for something as technical as templates, chances are there isn't going to be anyone else with skills to do that anyway. – Uanfala (talk) 23:10, 11 March 2019 (UTC)

Primefac, any chance you could take a pass at Wikipedia:Templates for discussion/Old unclosed discussions? I know there is no deadline, but there are currently 75+ old discussions that are still open. Would be great to get some of them resolved if/when you have a chance! --Zackmann (^{Talk to me}/_{What I been doing}) 20:52, 16 March 2019 (UTC)

Zackmann08, we have set a setting: if backlog is more than 75 lists, admin backlog will be automatically turned on. So do not worry it Hhkohh (talk) 09:53, 18 March 2019 (UTC)

Hhkohh, not worried about it bud... Just asking if he would mind taking a look. Zackmann (^{Talk to me}/_{What I been doing}) 17:14, 18 March 2019 (UTC)

I cleared out a bunch today. Work caught up with me, though, so I didn't have time to tackle the longer ones. Will try to take a look in the next few days. Primefac (talk) 00:31, 25 March 2019 (UTC)

Common outcomes

Based on a rather interesting reversal of past precedent I finally got around to creating WP:TFDOUTCOMES; I haven't populated it with anything yet but I would encourage anyone interested to help edit it and flesh it out a bit more before I go and add it to places like Wikipedia:Common outcomes or {{precedents}}. Primefac (talk) 04:26, 1 April 2019 (UTC)

Good idea. An actual improved guideline on templates would be better than the few bullet points we got scattered around different pages, but since that ain't happening, this should do. --Gonnym (talk) 12:57, 1 April 2019 (UTC)

Closing instructions for merging: update needed

The instruction for merging at WP:TFDAI includes:

2. On the to-be-deleted template page, replace {{Tfd}} with {{being deleted|YYYY Month DD}}. For YYYY Month DD, use ...

I am experienced at CFD, but new to TFD, and could not make out what to do to (permalink). It does not start with {{Tfd but with {{Tfm/dated. Being confused, I did nothing about that part of the instructions. – Fayenatic London 21:28, 2 April 2019 (UTC)

I have updated the directions, thanks. As a note, you should use WP:XFDCloser to assist with and semi-automate the closing so you don't have to worry about the nitty-gritty details. Primefac (talk) 22:10, 2 April 2019 (UTC)

Twinkle will place TfD/TfM tags on the doc subpage and other changes

Just FYI, WP:Twinkle should now, if invoked from a page with the Scribunto content model, attempt to place the tag on the documentation subpage, as per instructions. Relatedly, the module display type will be checked. Also, if nominating an infobox, Twinkle should autoselect the sidebar display type. Other recent changes here. Please let me know if there are any issues! ~ Amory (u • t • c) 15:37, 3 April 2019 (UTC)

Add a link to Jarry's tranclusion count to Template:Tfd links

So that {{tfd links|Foo}} gives

• Template:Foo (edit · talk · history · links · transclusions (count)· logs · subpages)

instead. Headbomb {t · c · p · b} 16:20, 5 April 2019 (UTC)

Special:Search/hastemplate:Navbox also yields a number and is rarely off by too much. --Izno (talk) 17:12, 5 April 2019 (UTC)

Feedback on a law enforcement-related infobox

Hey guys.

I made an infobox draft for law enforcement units as shown here. I had a talk with someone who has voiced the use of the military unit infobox to illustrate law enforcement units such as police tactical units and the like.

So I did have a talk with the user and agreed to do this one. Except that this is a draft and I wish to bounce some ideas. I looked at it now and it seems that I'll have to remove anything related to military stuff since this proposed infobox will be for LE units/divisions that are under civilian police control.

Appreciate any thoughts on this.

Ominae (talk) 08:09, 15 March 2019 (UTC)

Cross-posted/transcluded to WT:WPT. Primefac (talk) 10:44, 15 March 2019 (UTC)

How is this different from Template:Infobox law enforcement agency? – Jonesey95 (talk) 10:57, 15 March 2019 (UTC)

Thanks Primefac.

Jonesay95, I'm trying to specifically boil it down to make it to a specific division within law enforcement (civilian) agencies? I've seen wiki pages of police units using the military unit infobox and I think that it's not the proper infobox to use. Ominae (talk) 13:23, 24 March 2019 (UTC)

Currently revising it. Ominae (talk) 11:12, 19 April 2019 (UTC)

UPDATE: Proposal for law enforcement infobox for specialist units

Hello.

I was busy updating the template proposal for a separate infobox for law enforcement specialist units (e.g. SWAT units, etc...)

Though there wasn't much reception, I was wondering if [the LEA infobox] should just be strictly implemented at all. Ominae (talk) 03:52, 20 April 2019 (UTC)

Hide tfd-inline for unregistered users

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.

Proposal fails. Primefac (talk) 20:01, 23 April 2019 (UTC)

---

Currently Template:Infobox U.S. state is nominated for TfD, and as a result every single U.S. state (e.g. California) has a notice saying ‹ The template Infobox U.S. state is being considered for deletion. › Now as an editor, I appreciate the notification, but for the vast majority of our readers that the TfD discussion has very little to do with, it looks ugly and unprofessional (and certainly unacceptable for a featured article like Oklahoma). Infoboxes by their very nature are highly trafficked, and I don't think it is useful to serve up a deletion notice to every one of those visitors. Is there a way to display it only for logged in users? -- King of ♥ ♦ ♣ ♠ 03:37, 11 March 2019 (UTC)

@King of Hearts: maybe we should wrap the notices with class=autoconfirmed-show and take advantage of MediaWiki:Group-autoconfirmed.css. If implemented properly, this would hide tfd notices from all non-confirmed users --DannyS712 (talk) 04:21, 11 March 2019 (UTC)

Pinging users who participated in the previous (to my knowledge) discussion about TfD tag visibility: @Xaosflux, Jc86035, Uanfala, Thryduulf, Verdy p, Fornaeffe, Jo-Jo Eumerus, and George Ho: {{3x|p}}ery (talk) 04:26, 11 March 2019 (UTC)

Seems like a pretty good idea to only show only to autoconfirmed/users (one can use user-show to only display to logged-in users using MediaWiki:Group-user.css). Would hide the notice from 99% of people who don't even know what a template is but display it to 99% of people who actually would comment on a Tfd/understand what is going on. Galobtter (pingó mió) 07:12, 11 March 2019 (UTC)

Oppose. Non autoconfirmed users who are interested in our processes do exist; it's been a Wikipedia philosophy for a long time. Besides, maintenance tags are a common sight, one non-problematic tag is surely not a problem. Jo-Jo Eumerus (talk, contributions) 07:16, 11 March 2019 (UTC)

• Oppose per Jo-Jo. Not every person interested always logs in when they read Wikipedia. Some people (e.g. me) read Wikipedia on mobile devices logged in to a different account to their main editing one, and the possible deletion of a template could be what causes a new editor to start editing. Also per the comments in the last discussion. If deleting a template causes problems then perhaps consider whether the template should be nominated for deletion in first place. Thryduulf (talk) 07:37, 11 March 2019 (UTC)
• Oppose per Thryduulf. Openness to editing and the fact that we're unfinished (and may improve) is one of our core principles as an encyclopedia. I don't see a convincing reason to hide these templates. In addition they are only attached for a relatively short period of time and really aren't that disruptive. --Tom (LT) (talk) 10:53, 11 March 2019 (UTC)
• It appears that I missed Redrose64 in my previous list of pings. {{3x|p}}ery (talk) 13:07, 11 March 2019 (UTC)
• Support as a step in the right direction. TfD notices aren't much use anyway: their intended audience is the editors who use the templates concerned but they instead reach the people (most of whom are not editors) that happen to be looking at the articles that use the template. These two sets of people: the ones that the message is intended for and the ones that it actually reaches, are different, and it's only by a fluke that there might occasionally be a tiny bit of overlap. Even removing all tfd messages altogether is unlikely to make a massive difference to participation, and hiding them from unregistered users is unlikely to make a difference at all: I don't buy the argument that a casual reader might be tempted to become an editor by seeing a notice for what is probably wikipedia's most arcane deletion venue. – Uanfala (talk) 16:15, 11 March 2019 (UTC)
• Oppose this has long been established as Wikipedia policy. At the VERY LEAST this would require a much broader RFC. --Zackmann (^{Talk to me}/_{What I been doing}) 16:39, 11 March 2019 (UTC)
• Support as the arguments presented above to not show (to non-editors and a few editors) are much more compelling than those to show. If editors are particularly interested in knowing about TFDs there are many other ways (watchlisting templates, looking at wikiproject alerts, looking at TFD). DexDor ^(talk) 17:05, 11 March 2019 (UTC)
• Note Given Zackmann08's comment about needing a wider audience (which I agree with) I've made this into an RfC . Thryduulf (talk) 17:12, 11 March 2019 (UTC)
  • I've also placed a notice advertising this discussion at Wikipedia talk:Deletion policy. Thryduulf (talk) 17:16, 11 March 2019 (UTC)
• Support – I agree with Uanfala that this is a step in the right direction. After almost 20 years, the encyclopedia isn't as unfinished as it once was, and "the encyclopedia anyone can edit" isn't as novel of an idea as it once was. People know they can edit Wikipedia; I doubt that a TfD notice will prompt new editors to start editing. Anyway, do we really want completely new users voting in TfDs? The inconvenience for those editors who use alternate accounts that are not registered or autoconfirmed doesn't strike me as a reason to show TfD notices to millions of readers. Leviv ich 17:52, 11 March 2019 (UTC)
• Oppose I see no worthwhile reason to hide such information from anyone.--Paul McDonald (talk) 18:45, 11 March 2019 (UTC)
• Oppose You are falsely equating "users who are not logged in/autoconfirmed" and "readers". {{3x|p}}ery (talk) 18:54, 11 March 2019 (UTC)
  • @Pppery: good point! --Zackmann (^{Talk to me}/_{What I been doing}) 19:18, 11 March 2019 (UTC)
• Support as the previous talk about TfD notices, I prefer if Wikipedia doesn't not show notices at all in pages where the template is used, except from the template pages. I think an editor interested in that templates will probably visit their pages and find the TfD discussion, while any other users (i think about 99,9%) would only be bothered by the notice, and (99%) does not know what a "template" is, or (0,9%) doesn't care about the deletion/merging. But almost all users care about readability of wikipedia pages. However, hide tfd-inline for unregistered users could be a quite fine solution, IMHO. 100% agree with Uanfala and Levivich.Fornaeffe (talk) 21:36, 11 March 2019 (UTC)
  • That's simply not true - I only discovered today that Template:Wikipedia categorization navbox had been nominated for deletion when I saw the notice above its transclusion on Wikipedia:Categories, lists, and navigation templates. I've never had cause to visit that template's page and it's not on my watchlist. Thryduulf (talk) 23:12, 11 March 2019 (UTC)
• Oppose. It's arbitrary to single out TfD template messages. --Bsherr (talk) 23:24, 11 March 2019 (UTC)
  • If this proposal passes, then TfD's will get advertised in exactly the same way that all other XfD's are advertised: by a message at the top of the page concerned. TfD is the odd one out at the moment: advertising a discussion on every page that transcludes a template is without parallel elsewhere; I'm trying to imagine what the same system could look like when applied to articles, placing AfD notifications on all pages that link to the nominated article? – Uanfala (talk) 23:48, 11 March 2019 (UTC)
    • Templates are primarily encountered through their transclusion onto another page. Thus the existing system of transcluding an abbreviated deletion template message with every transclusion of the template is actually parallel to how deletion template messages appear in other namespaces. Not transcluding that deletion template message with templates is, for other namespaces, actually akin to placing the deletion template message only on the talk page instead of the subject page (thus, in both instances, one page removed, so to speak). But also, I didn't only mean singled out in relation to other deletion processes, but also other template messages. --Bsherr (talk) 00:13, 12 March 2019 (UTC)
• Oppose Unregistered editors are not prohibited from participating in XFDs, hence, they must not be prevented from being made aware of those XFDs. Also, our readers are potentially our editors of the future. --Redrose64 🌹 (talk) 23:34, 11 March 2019 (UTC)
• Opppose since there is not a technical difference between "readers" and "IP Editors" to differentiate upon. If someone wants to propose never transcluding TFD tags at all, that is a different discussion to be had. — xaosflux ^Talk 00:48, 12 March 2019 (UTC)
• Oppose (invited by Legobot) -- per the opposes above. ~ ToBeFree (talk) 04:57, 14 March 2019 (UTC)

  ...and below. :) ~ ToBeFree (talk) 14:22, 14 March 2019 (UTC)

• Displaying these sort of notices to non-editors is a good thing! It's easy to just be a consumer of the encyclopedia and not even think about editing (there's a lot here) but showing messages like this to readers increases the chance that someone will be curious and join in. It may not all be great, but deletion notices are probably one of the best "advertisements" we have for non-editors that they can edit. It's a (hopefully welcoming) invitation, and we should encourage it. I'm against this, whether for just inline TfD or anything else, and if we hid them would support unhiding them. ~ Amory (u • t • c) 11:18, 14 March 2019 (UTC)
• Oppose (Summoned by bot) Per above, could invite people to edit Wikipedia. SemiHypercube 11:23, 14 March 2019 (UTC)
• Support TfD notices are very often just not relevant to the articles they show up at. Tags like {{unreferenced}} and {{copyedit}} are inviting (in a sense), but TfD notices are confusing. If they have to be shown, what about showing them below the templates instead of at the top? Currently these notices are one of the first thing you see when opening an article with an infobox. – Þjarkur (talk) 01:26, 29 March 2019 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

NAC delete closes

Can I non-admin close a TfD as delete if there are no transclusions to orphan?

Background (copied from User talk:JJMC89)

Hi. I wanted to ask you about this edit with the summary revert delete closes done contrary to WP:NACD. I realize that I made a mistake with the tagging of the category for deletion, but can you explain how this is contrary to NACD? Thanks, --DannyS712 (talk) 01:06, 19 April 2019 (UTC)

@DannyS712: The relevant part of NACD is below. Those closes only required deletion, not orphaning, so a non-admin should not close them as delete.

• Non-administrators should limit their closes to outcomes they have the technical ability to implement; for example, non-admins should not close a discussion as delete, because only admins can delete pages.
  • Exception: a non-administrator may close a TfD as orphan.

Additionally, itAs an aside, such closes just makes more work for admins since WP:XFDC can't be used if the discussion is already closed. — JJMC89 02:09, 19 April 2019 (UTC)

@JJMC89: I have read that policy, and have observed other non-admin closes. I have realized that "orphan" means "delete once all transclusions are removed". For the relevant background, See Special:Diff/695098674, where the TfD exception was first added to NACD, Special:Diff/716267935, where it was partially corrected, and Wikipedia talk:Templates for discussion/Archive 19#RfC: Proposal to allow non-admin "delete" closures at TfD, which proposed that non admins be allowed to close TfDs as delete (Consensus in favor of this proposal would interpret the WP:NACD guideline as permitting delete closures of uncontroversial discussions by experienced editors where enacting the short-term outcome is within the technical ability of non-administrators.) and was closed as consensus in favor of implementing that idea (However, there is clear support for at least trying out the alternative proposal. I recommend looking into a trial of the orphan/CSD mechanism, and if this fails to resolve the issue then the first question can be revisited.). Since the templates were already orphans, the CSD mechanism applied. There is no evidence that the closes are limited to orphan only when templates are still transcluded, and since orphaning a template is the same as marking it ready for deletion, I merely skipped the step of listing it as "to orphan" and then immediately moving it as ready for deletion and tagging the templates individually. While I understand you point about XFDC, I don't believe that you desire to use it warrants undoing my close with a summary that says I violated a wikipedia guideline. In short, as far as I can tell you reverted my close claiming I violated a guideline that I believe I followed, and then proceeded to make the same close yourself. --DannyS712 (talk) 02:18, 19 April 2019 (UTC)

Orphaning a template is just removing all tranclusions. It is a prerequisite for deletion. Something that has no tranclsuions does not require orphaning, thus NAC is not permitted. The initial proposal in that RfC (delete NACs) did not have consensus, only the alternative proposal, which allowed orphan NACs. XFDC was just an aside about increasing the amount of work needed and had nothing to do with reverting your close. (Clarified above.) — JJMC89 05:41, 19 April 2019 (UTC)

@JJMC89: Would you be okay with moving this discussion to WT:TFD? I disagree with your interpretation, and believe that NACs can close a discussion as delete even when there are no transclusions. --DannyS712 (talk) 07:26, 19 April 2019 (UTC)

NACD would just say Exception: a non-administrator may close a TfD as orphandelete. if that were the case. Discussing the interpretation of NACD there is fine. — JJMC89 21:41, 19 April 2019 (UTC)

@JJMC89: discussion copied. --DannyS712 (talk) 06:18, 20 April 2019 (UTC)

IMO TfD NAC-closed-as-delete isn't a bad thing. We shouldn't prevent users from being helpful provided they've spent the time to review each discussion and are willing to be accountable for each close. -FASTILY 19:52, 21 April 2019 (UTC)

• Wikipedia:Non-admin_closure#Templates_for_discussion explicitly says that non-admins can close TFDs as "delete". There is nothing to discuss. Primefac (talk) 21:48, 21 April 2019 (UTC)

  WP:NACD is the actual guideline. As an explanatory supplement, WP:NAC must agree with WP:NACD. Also, read the RfC. — JJMC89 (T·C) 22:02, 21 April 2019 (UTC)

  Indeed, I'm a bit perturbed at WP:NAC getting quoted as much as it does. :^) --Izno (talk) 23:27, 21 April 2019 (UTC)

  I'm a little surprised at how much mincing of words seems to go on. I'm genuinely confused - it's okay to close as discussion as "orphan then delete" but it's not okay to close an identical discussion where orphaning is unnecessary? At that point we're just splitting hairs; when I started at TFD (Sept 2015, shortly after the RFC) I was closing discussions as "delete" and as far as I recall no one ever had issue with it between that time and when I got the mop. If people insist on codifying what has been acceptable practice since that 2015 RFC then so be it, but let's not pretend that there's a significant difference between "orphan then delete" and just "delete". Primefac (talk) 23:45, 21 April 2019 (UTC)

  For an orphan close, there is work (orphaning) that a non-admin can do before deletion, but nothing for them to do when orphaning is not needed. NAC deletes when no orphaning is required just create more work for admins compared to just letting an admin close it. That is a significant difference given that the point of the RfC was to reduce, not merely displace, admin backlogs. A delete NAC (with no orphaning) only displaces the work (and prevents the use of scripts like WP:XFDC) from TFD to WP:TFD/H and/or CAT:CSD. NAC delete (original proposal) closes did not have consensus in the RfC, only orphan (alternate proposal). Primefac, if you were closing as delete when orphaning wasn't required, perhaps no one noticed. I noticed it happening now largely due to the recent trend of TfDing unused templates. — JJMC89 (T·C) 01:33, 22 April 2019 (UTC)

  Fair points, though I'm a bit confused by your statement A delete NAC...prevents the use of scripts like XFDC - XFDCloser works perfectly well for NAC closures; tagging the page with G6 and listing it at the holding cell. If that's not right, what is it supposed to do? Primefac (talk) 10:53, 23 April 2019 (UTC)

  Sorry if I was unclear. I was referring to the admin not being able to use it since the discussion was already closed. This is more meaningful for batch TfDs. — JJMC89 (T·C) 03:13, 24 April 2019 (UTC)

Talk page archiving - how many threads to keep?

Fastily recently dropped the "number of threads to keep" to 0, likely because there are two long(ish) RFCs on this page. I don't know of any "big" WP talk page that does this (CSD, AN, and a handful of others I frequent all keep 4 threads). Rather than have an edit war over something so silly, I figured I'd get opinions from TFD regulars. My !vote is to keep 4 threads, since that seems to be the norm and allows the most recent conversations to be seen. Primefac (talk) 20:01, 21 April 2019 (UTC)

Uh yeah, because this page looks like shit on mobile. Instead of citing a hand-wavy "seems to be the norm", why don't you actually try justifying zombie threads which are de facto archived and therefore belong in an archive. -FASTILY 20:08, 21 April 2019 (UTC)

The oldest thread here is from 29 March, which is less than a month ago. Doesn't really sound like much of a zombie to me. Primefac (talk) 21:43, 21 April 2019 (UTC)

You're missing the point. If threads are eligible to archived, then they should be. I've already stated my reasoning above, so I won't be repeating myself here. -FASTILY 22:10, 21 April 2019 (UTC)

That's fair enough, and you're entitled to your opinion, as am I. I'm starting this discussion to see what other users feel, since a consensus either way will stop us from bickering about it via edit war. Primefac (talk) 23:32, 21 April 2019 (UTC)

Why not just archive the things you think should be archived? --Izno (talk) 23:26, 21 April 2019 (UTC)

Because that defeats the purpose of automatic archiving? Primefac (talk) 23:32, 21 April 2019 (UTC)

• Archiving any talk page to blank, zero threads, makes it look like not a talk page, and discourages uncertain people from posting. If the only thread is massive big and irrelevant, manually archive it and leave an explanation or what you did as a lingering thread. —SmokeyJoe (talk) 23:43, 21 April 2019 (UTC)
• To be fair, I also believe that it's pointless leaving threads that should be archived on the talk page, even if that leads to 0 open threads, as to me that is a non-issue. --Gonnym (talk) 12:48, 27 April 2019 (UTC)

RfC: Proposal to make TfD more RM-like, as a clearinghouse of template discussions

 Passes: The proposal passes with almost unanimous consensus. The general intent is to move towards a RM-like process where discussions are held on talk pages. No further consensus was reached on exact procedures. --qedk (t 桜 c) 16:02, 6 May 2019 (UTC)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Should we make TfD more RM-like, as a clearinghouse of template discussions? 05:12, 27 February 2019 (UTC)

We have four issues (at least) that are combining in a negatively synergistic way:

1. There's a WP:PROCESSFORK of sorts between coding (and discussing) templates versus doing so with modules, despite the latter being an adjunct to the former.
2. Few editors care to participate and watchlist in either namespace, but it's probably at least an order magnitude lower for Module namespace.
3. The editors involved in implementing and maintaining modules are a much smaller and more self-selecting group. While this is necessary when it comes to directly changing the code, it's an unproductive narrowing when it comes to decision-making and consensus formation.
4. Templates are being converted into Lua modules without good reason, making them further developable by a far smaller number of editors; such conversions need broader discussion on a case-by-case basis.

Overall, getting stuff done in Template and Module namespaces is taking longer and longer, with more inconsistent results. Particular individuals deeply involved in modules have much more personal control over Module space than Template space, and our "geeks" in general (especially those with the TemplateEditor user level) have more control over both namespaces compared to main (article) or project ("Wikipedia:") namespaces – which leads to problems even with the best of intentions. In the "Extended discussion" section below I've outlined some examples (and I do so as someone with the TemplateEditor permission bit; this is not a sour-grapes "class struggle" between user levels).

A possible solution: The status quo seems likely to continue (or worsen) if an explicit change isn't made. WP:Templates for discussion (TfD) should serve as more of a "clearinghouse" of template and module changes (like how WP:RM works for proposed moves), not just as an XfD process; this will draw additional editorial attention to template and module matters. It should be as simple as having a {{subst:tfd-thread}} template and bot that adds RM-style pointers to the WP:TFD log, directing people to Template_talk and Module_talk discussions, in addition to the existing "settle it here at TfD" deletion and merger entries. I think this would both even out the discrepancies between Template and Module namespaces in "getting the work done", and also give the WP community much more say into how its templating system operates. It's also consistent with TfD's rename several years ago to "Templates for discussion" not "deletion". It would be a new norm that any potentially controversial template/module change proposals should be listed in this manner, the way potentially controversial moves are listed at RM. (As with manual moves and WP:RM/TR, trivial fixes need not be so listed – if you need to fix an obvious typo in a template, just do it; this is not a bureaucracy.)
 — SMcCandlish ☏ ¢ 😼  05:12, 27 February 2019 (UTC); links added 10:42, 10 March 2019 (UTC)

Comments

• Comment. I might be relatively new here, and I might be showing my youth and inexperience. However, this is news to me that we have a module namespace. ―MattLongCT -Talk-^☖ 19:38, 27 February 2019 (UTC)

  @MattLongCT: Yes, we have two different namespaces (and associated talk spaces) for dealing with templates, and this leads to some problems this proposal would help address.  — SMcCandlish ☏ ¢ 😼  03:19, 28 February 2019 (UTC)

  SMcCandlish, I see... ―MattLongCT -Talk-^☖ 03:21, 28 February 2019 (UTC)

• Uh? I can't figure out what exactly is being asked, what 'RM-like' means, or what supposed problem this is even supposed to addressed. Headbomb {t · c · p · b} 03:02, 28 February 2019 (UTC)

  @Headbomb: The proposal seems pretty clear to me. Look at WP:RM and what it does: it lists ongoing move-related discussions which are at various talk pages. Look at WP:TFD and note that it does nothing like this, but only hosts deletion/merged discussions in TfD itself. It can also provide listings of ongoing template and module-related discussions, through the same method as RM (apply a template to the top of the discussion, and a bot will list it; we also have bots that do this with RfCs, listing them in topical pages according to which {{RfC}} parameters are used).  — SMcCandlish ☏ ¢ 😼  03:19, 28 February 2019 (UTC)

• Simplify this please, as technical jargon will probably not be known to the majority of Wikipedians. Kirbanzo^{(userpage - talk - contribs)} 21:59, 3 March 2019 (UTC)

  I've linked all the jargon at first occurrence.  — SMcCandlish ☏ ¢ 😼  10:42, 10 March 2019 (UTC)

• Support some kind of clearing house system that gets more eyes on discussions. No opinion on specifics of implementation such as putting them in its own section, auto-collapsing, etc.. ---- Patar knight - ^chat/_{contributions} 00:23, 6 March 2019 (UTC)
• Support general concept per Patar knight. Good to get more voices in some discussions --Tom (LT) (talk) 09:44, 6 March 2019 (UTC)
• Support Agree with above. {{3x|p}}ery (talk) 12:38, 6 March 2019 (UTC)
• Support – It's easier to keep track of and participate in conversations (and watchlist just those you've participated in) if they're held at the template talk pages, with a central listing of all of them, like RM. Leviv ich 18:14, 11 March 2019 (UTC)
• Support - per above. MrClog (talk) 23:25, 12 March 2019 (UTC)
• Support: the proposal would aid organisation of discussions on little-watched pages and speed up uncontroversial code fixes. — Bilorv (he/him) _(talk) 22:51, 17 March 2019 (UTC)
• Strong oppose. The nom identifies as a problem the lack of clearing house for discussion on changes to templates and modules. That need clearly should be met ... but this is the wrong way of solving the problem.

TFD is full of discussion about deletions and mergers. Most of those discussions are rightly non-technical -- nobody needs to know how to code even a navbox to know that a navbox with >1300 links is way too big or that one with 2 bluelinks is too small. Just as most of the topics are non-technical, most of the participants are not technical.

TFD is already quite busy. Plenty of days in March had over 40 deletion discussions.

So what this proposal would do is dump the "experts assess how to do this" issues into the already-busy workspace of the "should we do this at all" discussions. That's an oil-and-water combination, not helpful for either oil or water.

Additionally, adopting an RM style format would involve moving deletion discussions to the talk pages of templates which might be deleted ... so we'd end up either deleting those discussions along with the template, or retaining a mound of talk pages with no corresponding template.

It would be much better to create a new page with an RM-style centralised log page for the technical discussions, and leave the deletions/merges/renamings at TFD. That way the geeks wouldn't be tripping over debates about whether to zap the navbox Template:My neighbour's ex-husband's second cousin's abysmal garage band, and the navbox debaters wouldn't be wading through discussions about the intricacies of Lua code .. but the geeks would finally get that much-needed clearinghouse for geek issues. We could call it something like "WP:Requested coding". --BrownHairedGirl (talk) • (contribs) 02:39, 6 April 2019 (UTC)

• Comment (Disclosure: I'm a template editor and converted the WP:Automated taxobox system to Lua.) I agree with BrownHairedGirl that it's important to distinguish between discussions about the purpose and functions of modules and discussions about their technical details and coding. I can't either support or oppose the proposal because I don't think it's clear what it entails. It would be a new norm that any potentially controversial template/module change proposals should be listed in this manner – is converting a template's inner working to Lua to be considered potentially controversial if it makes no change to either the parameters of the template or its behaviour? If so, this would be a proposal that I would strongly oppose. Peter coxhead (talk) 21:22, 6 April 2019 (UTC)
• Comment: Some kind of process like described can be very helpful as it can help in situations where low participation can block changes with WP:OWN issues. --Gonnym (talk) 13:38, 7 April 2019 (UTC)

Extended discussion

While I've been thinking about this for a few year, this was more immediately spurred by a comment at a particular module fix-it request:On a more general note, the fact that this request took three months to get executed is exactly why I think there is far too much use of lua and go around TfDing modules. {{3x|p}}ery (talk) 05:05, 22 February 2019 (UTC)

I certainly agree in general. There have been other cases where it's taken much, much longer, including when only Template-namespace, not Module-namespace, code was involved. Ex.: Despite it being stark raving obvious, it took over two years and a pointless RfC to get Template:YesNo fixed to support values of on and off. This did not happen because there was any legit reason to stall or oppose. Rather, some TemplateEditors are excessively wary about blame (declining even simple requests if they don't see a prior discussion about it), and some editors who fancy themselves TemplateEditor candidates have no idea what they're talking about, and will make bogus (like, utterly disproven) claims about server/parser efficiency (adding a single pair of #switch cases has no measurable impact on performance, and we have templates, like for railway lines, album/singles chart stats, and post-nominal letters, with hundreds of #switch options, sometimes in nested levels of templating).

Rarely, it's actually been easier to add options to a module than a template, including in this very case, at Module:Yesno. However this can (and in that case did) easily result in an undesirable WP:TEMPLATEFORK, with the module version supporting options (e.g. T and F) not supported in the old-school template edition, for no actual reason other than probably another round of WP:DRAMA at the template talk page with the tiny handful of people trying to over-control it. This is also an example of the unhelpful forking of template and module editors (and non-code-editing concerned parties) into WP:FACTION nonsense across namespace lines (not out of any kind of ill will, but just as a consequence of isolation from broader community input).

Usually, it's the other way around, due to the larger and broader participation in Template_talk than in Module_talk. Ex.: Implementing consistent hatnote-style italicized cross-reference templates that work inline instead of being indented and on their own line has been simple, as templates. Getting this implemented in Module-space has been like pulling teeth from a smilodon because of WP:IDONTLIKEIT antics by some self-appointed gatekeepers; it took an actual code fork to do it, despite the modules being identical except for one or two lines.

We had a similar "gatekeepers" problem for several years in which two or three individuals had near-total control over MediaWiki namespace (where the CSS and JavaScript live), defying changes they didn't personally agree with – even when consensus was against them and when what they wanted produced WP:ACCESSIBILITY problems, WP:MOS rendering style conflicts, etc. Yet they remained convinced they were doing The Right Thing, mostly based on their subjective sense of what other websites have in their own house style, or (much worse) based on nothing but what WHATWG has browsers do by default (browsers made by members of that small consortium, anyway). One of them ended up just quitting the project after being overruled a few times, and this mostly brought the WP:CONLEVEL / WP:OWN / WP:VESTED] problem to an end at those pages (though the ability to just go change them willy-nilly has of course been locked down tighter with the InterfaceAdmin bit). But it should never have happened in the first place, and it's incrementally happening again in Module space. This will not do.
 — SMcCandlish ☏ ¢ 😼  05:12, 27 February 2019 (UTC)

Any chance of an executive summary? Did you mention WT:Lua? It's likely that a request for technical assistance at WT:Lua (say to fix Module:Zh) would get a reasonably fast response. Johnuniq (talk) 06:06, 27 February 2019 (UTC)

This discussion appears to be about multiple things. The extended discussion portion appears to be about how long it takes to get simple things done, but the first example did not appear to use an edit request template, and the second example used such a template, had an objection, and the objection was not responded to. In both cases, the onus is on the person who wants the change to draw attention to the change and to show consensus for the change.

As for some TemplateEditors are excessively wary about blame, I am absolutely one of those template editors who is wary of changes, and I do not consider wariness excessive in cases where I have never seen the template before, let alone seen it used, and where there are zero or limited testcases to illustrate the suggested change. Templates are often used in many pages, and changes can have unexpected effects. When an edit request appears on a template that I have never visited, and I see no discussion about the change other than the request, I am unlikely to make the change unless I trust the requester's reputation or the change is transparently harmless; as the editor making the change, I am responsible for the edit and its effects. Again, the onus is on the requester to do a bit of work beforehand. As someone who frequently responds to edit requests, I have found that it is the rare request that has been sandboxed and tested, let alone discussed. – Jonesey95 (talk) 07:31, 27 February 2019 (UTC)

@Jonesey95: Given your comment above, as well as the high(er) number of watchers on this page, can someone please take a look at Template talk:Single-purpose account#Template-protected edit request on 26 February 2019 - both sandboxed and tested --DannyS712 (talk) 07:40, 27 February 2019 (UTC)

I have to agree with Jonesey95, I understand the concern over blame, as looking at code that you aren't familiar with or a template that you don't know what it does, it is something hard to understand the overall impact of a change. If we look at the 2 current examples of template edit requests, one is following the guidelines on how to ask for one, while the other just mentions the issue, leaving the research work to whoever responds to the request. I also think that the resistance in creating a consistent coding style makes changing (and reading) other editors code even harder. --Gonnym (talk) 08:27, 27 February 2019 (UTC)

@Jonesey95 and Gonnym: As a TE myself, I would suggest that the appropriate response when you are uncertain is to leave the edit request unanswered, so that someone more familiar with the template/module in question can address it later, rather than marking it answered but declined out of simply uncertainty/unawareness. There's a major meaningful difference between "I don't know" and "I'm certain this requires closer examination by the community". (This is a variant of the WP:IDONTKNOWIT principle.) Another solution, of course, is to actually find out – see how the template is used, how much it is used, what it is doing step-by-step in the code, what its talk page may say about why it is written the way it is, etc., etc. There's not really a rationale for "I don't know and refuse to bother to find out."  :-) I regularly resolve template editing requests by taking the time. Probably the majority of them have been at templates I wasn't intimately familiar with when I arrived at them. It's work, but it's one of the reasons this is an advanced user-right. Being a page-mover, file-mover, edit-filter-manager, or admin also generally entails judgement and direct experience, which are arrived at by effort.  — SMcCandlish ☏ ¢ 😼  03:12, 28 February 2019 (UTC)

So, you proposing to get rid of any centralized hub where templates can be deleted or discussed? And admins will need to jump from one talk page to another one to find the specific discussion instead of just looking at a single page? What will happen with the holding cell? What will happen with archives as with this change there will be no way to just look at one page and read all discussion that happened on a particular date? Ruslik_Zero 08:46, 27 February 2019 (UTC)

Ruslik0 I'm not sure who this is in response to. The proposal here says the exact opposite of "get rid of any centralized hub where templates can be deleted or discussed"; rather, it's an aim to make TfD do this more broadly, as a centralized hub to at least find template/module discussions that are not only about deletions and mergers; TfD's more traditional functions would be completely unaffected.  — SMcCandlish ☏ ¢ 😼  03:12, 28 February 2019 (UTC)

I've been thinking about a similar (if not the same problem) in that, because template editors are generally conservative (being one of them) because our templates and modules are usually highly-used, and the standard edit page requires an edit request, which requires a consensus, we do need some better way to generate input (not per se consensus). This is not a problem isolated to templates and modules however. All pages behind a protection have this issue as well. I regularly reject some proposed changes in the semi-protection queue as being inappropriate because they don't have consensus for change. --Izno (talk) 14:21, 27 February 2019 (UTC)

Izno Right. And the gist of this proposal is that we actually have a centralized protection/unprotection queue. This proposal is to have TfD serve, in part, a similar purpose for templates/modules changes. — Preceding unsigned comment added by SMcCandlish (talk • contribs)

I think I'd have to see what this looks like. Are you thinking a section on each day's TFD page which is "Discussions started February 28" and then a bulleted list? I think that would be interesting/valuable, though it almost duplicates the template-protected edit table that AnomieBot does, it would allow for the kind of discussion I'm thinking. --Izno (talk) 04:55, 28 February 2019 (UTC)

That would work for me. I don't have a particular layout vision in mind. A difference from AnomieBot's table is it would include discussions about more than {{edit template-protected}} requests.  — SMcCandlish ☏ ¢ 😼  10:44, 10 March 2019 (UTC)

I think there is far too much use of lua and [so I] go around TfDing modules. -- 3xpery - how obnoxious. It's a crusade and not good behavior for anything on Wikipedia. It's funny, on the one hand they say only a small number of people use Lua. But in reality more and more people are using Lua, and more Modules are being created all the time. To which they respond, there are too many Lua modules. It's crazy! -- GreenC 14:38, 27 February 2019 (UTC)

GreenC as modules and templates that I write are a frequent target of Pppery's clean-up campaigns, I sympathise. However, for creation of articles, we have firmly established criteria of notability as the threshold required, but when it comes to templates and modules, there is virtually no bar on creation, and little consensus on standards or criteria for deletion or merging. I am sometimes guilty of thinking "I'll just knock up a solution to this in a module (or template)" with scant regard for what might already be available, thus increasing the proliferation of modules and templates. It's a truism that having built a better mouse-trap, nobody will be beating a path to your door if they don't know the mouse-trap exists.

I'd like to see solutions to the problems caused by the lack of policies on creating, naming, organising, merging and deleting modules and templates; and to the problem of organising and advertising what's currently available in the area. That will need a lot more discussion. --RexxS (talk) 16:04, 27 February 2019 (UTC)

GreenC, see also [[User:|Pppery]]'s own comments below. I think you're misreading and assuming the worst without evidence. Pppery isn't anti-Lua, but just shares a concern about unnecessary complication with insufficient discussion. Note that Pppery even defends the Lua-ization of Module:Yesno, one of my examples (though I wasn't actually criticizing that particular conversion, but rather the later forking of functionality between versions due to lack of cohesive discussion, the kind of thing this proposal would help resolve).  — SMcCandlish ☏ ¢ 😼  03:12, 28 February 2019 (UTC)

To be honest, I actually do consider myself anti-Lua, but don't hold the extremist view that all Lua modules are bad. My position is that Lua modules should only exist if there is some specific reason that the code in question needs to be in Lua rather than Wikitext, and furthermore Lua modules should be generalized rather than focused on one specific case. Many Lua modules in existence fail these standards, and I then TfD them. But this is veering a bit off-topic from the proposal. {{3x|p}}ery (talk) 03:33, 28 February 2019 (UTC)

The problem of how few module coders there are is largely a problem about documentation and helping newcomers to code. The solution is to encourage new editors in the module namespace. It would not surprise me that some of those simple modules are made from users that are new to the module namespace. Very few users can just jump to the level of writing a complex module. Look at phabricator. There is a reason why bugs are marked as easy and suggested to new developers.

Many modules are used on multiple pages or are complex. Updating those is going to cause either many updates in the job queue or take a bit longer per page to update. Changing that practise is not going to happen, but I would welcome any well thought attempt to improve ways to generate input.--Snaevar (talk) 21:45, 27 February 2019 (UTC)

@Snaevar: I don't agree that encouraging more editors in Module space is "the" solution. We're here to write an encyclopedia, not learn new general-purpose programming languages. While no one's going to be harmed by learning Lua, of course, it's not the point and doing so should not be an effective barrier to entry, or a discouragement, to helping determine consensus on what our templates are doing and why, from an editorial standpoint.  — SMcCandlish ☏ ¢ 😼  03:12, 28 February 2019 (UTC)

@SMcCandlish: Module:Yesno isn't an undesirable template fork, see Template talk:Yesno#Switch to lua. Furthermore, as far as I can tell, it supports "T" and "F" because CRwikiCA edit-requested that they be added in 2015 but never made a request to add them to the template. As to the general merit of the proposal, it seems like a reasonable idea (but may exasperate the template limit issues). {{3x|p}}ery (talk) 22:08, 27 February 2019 (UTC)

Also, Mr. Stradivarius, the editor who declined the Template:Yesno request based on performance, isn't a editor[] who fanc[ies] [himself] a TemplateEditor candidate[], but rather an admin. {{3x|p}}ery (talk) 22:12, 27 February 2019 (UTC)

@Pppery:, I didn't suggest that all Lua conversions are undesirable (though someone above thinks you think they are!). Plenty of them are vast improvements, but as a general matter they need broader discussion than they've been getting. If we had a more efficient and inclusive process, then adding a feature to a module and its corresponding non-Lua template variants would be much more likely to be consistent, without depending on any single editor to "auto-know" that the variants exist; more brains in situ would likely ferret out other places to implement conforming changes. We also have a conflict involving WP:CONSENSUS, WP:NOT#BUREAUCRACY, WP:PROCESS: A consensus discussion is what it is; it's helpful process to centralize certain kinds of them to some extent (to get more eyeballs on them), but it's not helpful to treat a discussion as meaningless because a specific template wasn't used, or because a specific individual dropped out of the discussion. An idea should proceed or be rejected on its own merits, and this happens best when more editors are involved, which is what this proposal is about.

Side matters: The problem of people making bogus efficiency arguments is a general one; the fact that in one case someone who should know better did it doesn't affect the overall issue, and he was not the only one to raise the idea in discussions relating to YesNo. (Nor does being an admin confer technical knowledge automatically.) Let's not get hung up on nit-picks; this proposal is about an overall site-wide issue, not three particular cases.

PS: I'm not sure what "may exasperate the template limit issues" refers to in the context of the proposal as a whole; maybe that's actually about YesNo details?
 — SMcCandlish ☏ ¢ 😼  03:12, 28 February 2019 (UTC)

@SMcCandlish: Wikipedia:Templates for discussion is currently very close to ending up in Category:Pages where template include size is exceeded, and I've had to resort to several hacky fixes to keep it out of that category (see #Page Size Exceeded below). Adding even more content to it would make it harder to deal with that issue. {{3x|p}}ery (talk) 03:18, 28 February 2019 (UTC)

Noted. I'll go over that other thread and catch up.  — SMcCandlish ☏ ¢ 😼  03:21, 28 February 2019 (UTC)

Done. This is it right here: "Do we really need to be transcluding ALL tfds onto one page?" Obviously, the answer is "no" (WP:AFD and WP:CFD don't, and instead provide a by-day index; WP:MFD and WP:RFD do as TfD does, but they are comparatively quite short). I also have to observe that one proposed solution, "What about just a link to the currently open discussions?", is remarkably in line with my own proposal. TfD should be a way to get to discussions, like RM is, not a monolithic pile of entire discussions. It could also be by-day as AfD and CfD are; they're not mutually exclusive. RM includes the opening statements of each RM listing, since it's templated that way, and this is an idea worth considering for TfD, both as to what I'm proposing and perhaps as to its current "in house" deletion/merger discussions; or go ahead and display all the !voting for the within-TfD merge/delete threads, but not for those being, per this proposal, cross-referenced from other talk pages in Template_talk or Module_talk.  — SMcCandlish ☏ ¢ 😼  03:35, 28 February 2019 (UTC)

• Well, I agree that there needs to be more of a connection between templates and modules in terms of discussions, deletions, etc., so to that extent I support the proposal.

It does concern me though that there's an "anti-Lua" flavour to some of the comments above. As one who works with both the template language and Lua, I am very aware that for complex problems, Lua is vastly easier to write and to maintain. Yes, you need to learn Lua, but it's much easier to read and write than the template language whenever the problem requires complex control statements. If you look back at the history of templates, they started off as a way of using "boilerplate text" and later developed into a poor quality programming language. Ingenious editors (Smith609 is a great example with the automated taxobox system) managed to use templates to do things they were never designed to do. But they always did them badly.

So we should be clear about the value of each approach. The template language is valuable for straightforward uses, such as those which avoid repeating text, with limited control logic involved. Use Lua for cases where complex if/then logic or repetition is needed. Peter coxhead (talk) 19:34, 28 February 2019 (UTC)

Fair points. Nothing here's intended as "anti-Lua". Lua does have more of a learning curve, and the concern is that a) conversion of templates to modules without any actual gain in functionality or noticeable efficiency isn't helpful, and b) conversion of high-use templates into modules without discussion (and often with idiosyncratic functionality changes or mismatches) is probably also contra-indicated. But that's only a small part of this; it's mostly about discussion centralization like we have for other things.  — SMcCandlish ☏ ¢ 😼  10:42, 10 March 2019 (UTC)

---

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Seeing military unit infobox being used for police tactical units of a civilian character

Seeing this infobox being used for agencies like the basic SWAT unit in North America. I did ask about making a separate template and there's no good reception. Should the law enforcement infobox be strictly implemented (eg it should be used to replace the military unit infobox)? Ominae (talk) 03:37, 21 May 2019 (UTC) ~

Process for performing merges

I see that if a closer finds consensus to merge, they'll list the template at Wikipedia:Templates_for_discussion#To_merge (and in Category:Wikipedia templates currently being merged or deleted). I'm curious what happens at that point. Does the user who proposed the merge usually do the work of updating the transclusions and merging the template code? Can anyone help out by just picking one off the list? If they're not an admin, do they leave a note behind so an admin can delete the template that got absorbed? Or should it just be turned into a redirect to the absorbing template? Colin M (talk) 21:32, 12 July 2019 (UTC)

Anyone with the required technical skill can help implement the result of a merge. Sometimes the closing admin does it, but more often it is done by someone else. When a merge is complete and one of the templates should be deleted, the template is moved to the "ready for deletion" section and tagged with {{db-xfd}}. * Pppery * _{it has begun...} 00:20, 13 July 2019 (UTC)

How to nominate hundreds of templates for deletion at once?

All of the templates in Category:Rus templates by country, Category:Rut templates by country and Category:Rut templates by competition are simple links and it really isn't necessary for them to exist as templates. I would therefore like to nominate them all for substitution and then deletion. However, there are hundreds of templates in those categories (and their sub-categories). It would take ages for me to tag them all for deletion, so I'm wondering if there is a simple way to mark them all using a bot or an external tool or something? – PeeJay 15:35, 22 August 2019 (UTC)

@PeeJay2K3: I have a bot to assist with the tagging of categories for CfD(s), and could file a new brfa to tag these templates. But, I suggest first doing a small scale tfd on a few of the templates. DannyS712 (talk) 17:38, 22 August 2019 (UTC)

This is really an IAR situation too, tagging and listing THOUSANDS of templates is a complete waste of everyone's time - especially in this case where they are all basically the same template. List a few exemplars and then heavily advertise the TFD. — xaosflux ^Talk 17:42, 22 August 2019 (UTC)

@DannyS712 and Xaosflux: Thanks for the advice, you two. I'll do a trial run on a couple of the templates in the lesser-populated subcategories and then, if those are deleted, have a go at the wider lot. – PeeJay 18:50, 22 August 2019 (UTC)

Just as a note for when you go for the "whole group" nomination - on the TFD "daily log" page itself, you should only list a small handful (maybe 5) of the templates, and put links to the rest in a subpage. This way, users can see which templates are being nominated but it doesn't clutter the daily log with thousands of pages. I suggest using Petscan to create the full list of templates if and when you get to that point. Primefac (talk) 20:23, 22 August 2019 (UTC) (please do not ping on reply)

What sort of subpage are you talking about? – PeeJay 21:11, 22 August 2019 (UTC)

For example, when the {{link language}} wrappers were nominated, they were listed here as a subpage of Wikipedia:Templates for discussion/Log/2019 June 9. Another (less complex) example is this subpage for when a bunch of Olympics templates were deleted. Primefac (talk) 06:30, 23 August 2019 (UTC)

And notably on that second batch, with the templates all being virtual identical with identical use cases and authors, there was no need to manually tag each one with a TFD discussion notice. — xaosflux ^Talk 11:12, 23 August 2019 (UTC)

Notifying the authors/editors of them, related wikiprojects, etc is usually enough. — xaosflux ^Talk 11:13, 23 August 2019 (UTC)

RfC on templates storing data

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.

The majority of the participants felt that it either was acceptable to store data in the template space or that it should be dealt with on a case by case basis; with no outright consensus for "yes, all data templates must be kept", the status quo of dealing with potentially problematic templates via the TFD process shall be maintained. Primefac (talk) 23:29, 20 April 2019 (UTC)

---

Is storing data an acceptable use of template namespace? {{3x|p}}ery (talk) 23:35, 15 March 2019 (UTC)

Background: Zackmann08 has recently nominated a large number of templates that are used to store multiple pieces of data, each intended to be used on only one article, for deletion. These have ended in inconsistent results:

1. Wikipedia:Templates_for_discussion/Log/2019_February_15#Template:Metadata_population_AT-9 closed as delete
2. Wikipedia:Templates_for_discussion/Log/2019_February_22#Metadata_population_AT_templates closed as delete (although this was kind of a fait accompli since the templates had been orphaned during the discussion).
3. And there are many currently open, often with the !votes heading in opposite directions despite the arguments for keeping v. deleting generally being the same.

Feel free to tweak the above list. Thus, I am presenting this issue to a wider discussion. {{3x|p}}ery (talk) 23:35, 15 March 2019 (UTC)

Survey

• No it is not The below is copied from the most recent TFD I started and I think really lays out the arguments.

Storing data in a template like this creates a number of problems.

1) Ease of access What this means is that if a user wants to update the information (say for example the population), rather than editing the page, just like every other article on Wikipedia, they have to track down the sub template that is being called and then understand how the switch statement works and find the right value to change. For those of us experience with template editing, this is no problem. But Wikipedia is meant to be open for anyone to use. Storing data in this way just makes it more difficult to update.

2) Outdated references with invalid dates If right now I update the value of Imatra's population, I have to update it on {{Infobox Finnish municipality/population count}}. First, lets assume I am using the same reference as the one that is provided. Well now my access date needs to be updated to today's date. But I'm only updating one value... If I change the reference, I am saying that ALL the values are current as of today's date. But that isn't the case, I'm only updating one value. Furthermore, what if I'm using a different source? I am locked in to using the same source as every other value on the page because that is the source that is being returned by the template.

3) Dangerous precedent Additionally this sets a dangerous precedent. Should we next create a {{Chembox/boiling point}} that contains a massive switch statement with the boiling point of every chemical? Or {{Infobox NFL team/coach}} with a switch statement containing the current coach of every NFL team? That isn't how this works. If you want to change the data, you change it on the article in question.

4) Performance issues With the current implementation of 20 different subtemplates, that means that any time one of these articles loads, it has to parse 20 different switch statements. In somecases, because of the way the error handing is written, the switch statements are parsed multiple times. All to return plaintext numbers or references that can and should be included directly on the page.

The only reason I have heard for keeping these templates is that it makes it easier to update. Well that is just false. It may make it easier to BULK update, but how often are you updating EVERY value in one go? Rarely... And if it needs to be done, WP:BOTs are your answer for bulk updating pages. --Zackmann (^{Talk to me}/_{What I been doing}) 23:37, 15 March 2019 (UTC)

If thousands of boiling points or NFL coaches were changed at least once a year on the same day by the same organization, probably we would have a meta template for them. --eh bien mon prince (talk) 00:51, 16 March 2019 (UTC)

Underlying lk, read that as boiling points of NFL coaches. cygnis insignis 10:52, 16 March 2019 (UTC)

• No For the same reason that single-use templates are generally deleted. {{3x|p}}ery (talk) 23:43, 15 March 2019 (UTC)
• More examples are needed to form a general consensus. I recall seeing some census/statistics information that came from a few reliable sources and which was stored in a template (or was it a module?). Each article used a code (from the RS) to identify which set of data was needed. It worked well and was much easier to verify because all the information was in one place. In particular, it was much easier to update the information when changes occurred because the changes came from one RS and were made in one template/module. Sorry I can't find an example at the moment but it might have been something to do with Swiss settlements. Johnuniq (talk) 00:04, 16 March 2019 (UTC)
  • Johnuniq, I think you mean {{Swiss populations data CH-ZH}} and other templates in the series.--eh bien mon prince (talk) 00:27, 16 March 2019 (UTC)
    • Yes, that's it, thanks. Johnuniq (talk) 00:37, 16 March 2019 (UTC)
• (edit conflict) Pinging users who participated in any of the TfDs about this issue: @Apalsola, Markussep, Underlying lk, Scope creep, Darwinek, Pigsonthewing, Tom (LT), Keith Edkins, Number 57, Michael Bednarek, Nyttend, SPQRobin, Kusma, RexxS, Uanfala, and Gonnym: (apologies if I missed anyone). {{3x|p}}ery (talk) 00:10, 16 March 2019 (UTC)
• Yes. Take any series of related articles, e.g. the ones in Category:Nations at the 1992 Winter Olympics. Imagine that the Olympics wikiproject decided that it would be useful for all of these articles to have a template with some of that year's final medal counts. What would be wrong with that idea? It's raw data (see full form at 1992 Winter Olympics medal table), and it would seemingly be beneficial to include in all the articles in question. The opposing arguments demonstrate potential problems with storing data in certain circumstances, but saying "it's not always a good idea to do this" is very different from "it's never a good idea to do this". Dump the bathwater and keep the baby. Nyttend (talk) 00:27, 16 March 2019 (UTC)

  Nyttend, see but the example you highlighted is very different... A formatted table that is used in multiple places is a perfect use of a template. I don't think anyone is suggesting elimination of {{Medals table}} templates. What we are talking about is purely raw data where a massive switch statement returns a number. Zackmann (^{Talk to me}/_{What I been doing}) 03:14, 16 March 2019 (UTC)

  No, what you're talking about is using the template namespace to store data. See no true Scotsman and don't try to redefine the proposal in your favor. Nyttend (talk) 03:30, 16 March 2019 (UTC)

  There's no "no true Scotsman" here; I was never intending to include the kind of template you are talking about (although I think it merits deletion for an unrelated reason). {{3x|p}}ery (talk) 03:32, 16 March 2019 (UTC)

  Sorry, I misremembered the meaning and was attempting to switch it to Moving the goalposts when I edit-conflicted with you. The point is that you can't propose one thing and then get claim that you proposed something else when the absurdity of your proposal is demonstrated. Nyttend (talk) 03:34, 16 March 2019 (UTC)

• Yes. The RfC asks if it is acceptable, and it certainly is, most of those templates have been around for nearly a decade. The objection regarding the difficulty of updating an individual entry within them is beside the point: when statistical offices publish updated population figures (which can happen quarterly in some countries) you will want to update all of the entries. It is a tedious and largely uncontroversial task, which is why it is accepted to forsake some ease of access in order to make the update process more manageable. In many cases there might be better way to achieve the same result (such as using Wikidata for storing statistics), but that hardly means that meta templates are somehow now unacceptable.--eh bien mon prince (talk) 00:39, 16 March 2019 (UTC)
• Yes Templates like {{Israel populations}} are extremely useful ways of keeping hundreds of articles easily and consistently updated, whilst ones like {{English football updater}} ensure that the style of presentation is consistent, and helps ensure all articles do get updated (before this was introduced, numerous articles weren't being updated every season). Getting rid of data templates like these would be madness, and I think the rationales opposing them above are heavily flawed. Firstly. templates like Israel populations are updated in one go, once a year when the new population figures are released. Secondly, the outdated references bit can be easily resolved by having a requirement that all entries are updated in one go (and putting them on template protection to prevent drive-by editing). Thirdly, these aren't setting a dangerous precedent; in some cases they're useful, in others not – if editors feel they're not useful, then they can be taken to TfD or discussed at the relevant WikiProject. I also disagree that these are complex to edit – they're far simpler that trying to complete something like {{cite}}, and even if they were more complex, actually in many cases these are things that we probably wouldn't want drive-by editors updating in most cases. Number 57 00:48, 16 March 2019 (UTC)

  Number 57 & Underlying lk you both make good points. I don't agree 100% but I do respect the way you presented the argument. Can I ask, what say you to things like {{Infobox Finnish municipality/land area}} I don't see that being updated all that often (seems more like my NFL coaches example?). Now with {{Infobox Finnish municipality/population count}} I totally get where you are coming from. I take a different stance on it, but I can at least understand where you are coming from! But with something like land area, total area, etc. Why the need to update those constantly. I would think those would be pretty darn static. Additionally, population density should be automatically calculated. I'm going to repost this comment at that specific TFD for more discussion there... Zackmann (^{Talk to me}/_{What I been doing}) 03:20, 16 March 2019 (UTC)

  It's not inconceivable for areas to need to be updated: for example in the case of administrative reorganisations. But ease of updating is only one among several advantages of storing this data inside a template. Another advantage is that it makes the data more secure: if it's stored inside the complicated template machinery it's much more difficult for disruptive editors to tamper with it than if the data were in the article or on wikidata, and it's also much easier to keep an eye out for such tampering: watchlisting a single template page is better than having to watch hundreds, oftentimes regularly edited articles for such changes. – Uanfala (talk) 03:36, 16 March 2019 (UTC)

  I agree that things that will rarely/never updated don't need to be in templates – this was part of my point above about in some cases they're useful and in other cases not – the issue is that a blanket ban leaves no room for decision on where they're appropriate. As an aside, population density can be calculated by using a mix of static and templated data like at Subdivisions of Scotland#Council areas. Number 57 11:57, 16 March 2019 (UTC)

• Yes – In addition to the arguments above I refer to the Keep arguments at Wikipedia:Templates for discussion/Log/2019 March 2#Template:Metadata Population BE. -- Michael Bednarek (talk) 05:30, 16 March 2019 (UTC)

  Number 57, Underlying lk & Zackmann08 very useful like {{English football updater}} templates. We are using in Turkish wikipedia. Those are also protective for vandalism. We thought same templates for population but after that we entered all province and district population wikidata page. There are almost 1.000 pages. We collected all Q numbers in a excel file. And we are working going on to take those datas from wikidata. And next years will be add automatically with BOT, because of collecting data excel file. Wikidata example is Trabzon, in Turkish wikipedia example also tr:Trabzon. Regards, Sakhalinio (talk) 05:45, 16 March 2019 (UTC)

• No - WP:Wikidata is for data. The project was created in part because the template namespaces were becoming perverted into data stores. The template namespace is for structures, navigation, and aesthetic design - not data. Templates are perfectly capable of invoking calls to Wikidata properties, and more of those are converted to do so every day. Now, if we're talking about article text content (prose), that belongs in the article where editors can easily access it and track changes. This also avoids single points of vandalism. In fact, I think the current guideline would be better with one word struck to read: Templates should not normally be used to store article text. If you want to read a horror story about how messy it is to misuse the template namespace for data/prose, read up on Template:Cite doi and its like. Took months of cleanup. -- Netoholic @ 06:48, 16 March 2019 (UTC)
  • The problem with Wikidata concerns the work required to update, say, 100 articles with population changes when a new census arrives. If the data is in a template, one edit can be made, and it's easy to compare the template with the source for checking. Updating 100 items at Wikidata would be extremely time consuming and fragile (hard to check for typos). Also, it's very easy for vandalism to occur at Wikidata and very hard for enwiki editors to notice bad changes. A blue-sky plan would be to have data in a JSON page at enwiki, with a bot that updates Wikidata to match changes in the JSON page. The bot would also have to monitor changes made at Wikidata and report conflicts in a single location on enwiki. Johnuniq (talk) 10:18, 16 March 2019 (UTC)
    • I agree with the general approach Johnuniq suggests. We need to retain control over changing data that is used here. Yes, in principle, templates should not be now be used to store data because there are better technologies, such as JSON, available to us. However, this requires hard-pressed editors to learn yet another new coding language – there are plenty of complaints around about templates that have been changed into Lua modules, with the consequent need to learn Lua to alter or maintain them. But it's an approach that should be considered for new projects, even if converting existing ones (like the automated taxobox system mentioned in my comment below) is unlikely to happen. Peter coxhead (talk) 10:30, 16 March 2019 (UTC)
      • I think that Wikidata is good place to move that data. However, currently there is no support for wikidata in infobox templates. In example only thing what template:Infobox settlement reads from Wikidata is coordinates, photos and webpage so even if the census data is updated to Wikidata the infobox doesn't use it. --Zache (talk) 12:38, 16 March 2019 (UTC)
        • @Zache: There is support available for Wikidata in infobox templates. See Module:WikidataIB and Category:Infobox templates using Wikidata for examples of how and where – and Template:Wikidata Infobox for an extreme example. Anyone is free to update infoboxes to draw data from Wikidata, although I would recommend testing in the sandbox and then getting consensus first. --RexxS (talk) 12:51, 16 March 2019 (UTC)
          • @RexxS: I didn't mean that if it is technically possible, but that there should be implemented support in infoboxes like template:infobox settlement etc before the existing solution to store data to templates can be deprecated. With implemented support, I mean that infobox is actually showing the data from Wikidata or from Commons tabular data. --Zache (talk) 09:00, 19 March 2019 (UTC)
    • Johnuniq, it is actually quite manageable to update thousands of Wikidata entities using QuickStatements, and it doesn't take any more time than doing it with metadata templates. I did it for Belgian, Russian, Swiss and German municipalities, and wrote a short guide on how to do that on {{Austria metadata Wikidata}}.--eh bien mon prince (talk) 11:07, 16 March 2019 (UTC)
• Yes – at least in some cases. About 220,000 articles have taxoboxes generated through the automated taxobox system, which stores its taxonomy in almost 60,000 taxonomy templates. No alternative to this system is currently viable, and even if it were, conversion would be extremely difficult and time-consuming. If you want to know why Wikidata isn't a possible alternative, I'll be happy to try to explain, but be warned that the history of this discussion is very long and detailed (see e.g. here). Wikidata is fine for storing straightforwardly and uncontroversially structured data that changes very rarely, if at all, so sure, once it was available, mapping doi's to citation details is better handled in Wikidata. It is not suitable for storing data that does not fit into its rigid relational database model (e.g. it cannot model real world relationships such as the non-1:1 relationships between articles in different language wikis or the overlapping taxonomic hierarchies that result in a network of relationships rather than a tree). It has many, many fewer active editors than there are here, so data that changes does not get updated and maintained as well. Peter coxhead (talk) 09:58, 16 March 2019 (UTC)
• Yes, as the question is currently phrased. Just to pick one of many examples, take a look at the data in Template:Sacramento Kings roster. The data in that template is transcluded in Sacramento Kings, List of current NBA team rosters, and 2018–19 Sacramento Kings season. Being able to reuse data of this sort is one of the reasons that we have templates. To pick another (admittedly more controversial, judging from a recent no-consensus TFD discussion) example, take a look at the series of templates described at and linked from Template:LDS Temple/doc. Each piece of data in those templates is stored in a single location and used in a variety of pages. Having that data stored in individual pages or templates would lead to forking and more difficult maintenance. – Jonesey95 (talk) 10:44, 16 March 2019 (UTC)

  Jonesey95, @Pppery: I think you might need to clarify this RFC, because the example that Jonesey used above is NOT what we are talking about here... What we are talking about is massive switch statements that return nothing but an integer value. --Zackmann (^{Talk to me}/_{What I been doing}) 20:51, 16 March 2019 (UTC)

  @Zackmann08: Just do so, then (although I suspect it will provoke more "moving the goalposts" triigers). I give you permission to edit the opening statement of this RfC to make it clearer. (Although my intent was not just "massive switch statements": templates that do the same thing using subpages could also be considered here. {{3x|p}}ery (talk) 20:55, 16 March 2019 (UTC)

  I was just responding to the question as written: Is storing data an acceptable use of template namespace? It seemed to me that the obvious answer was yes. In writing RFCs, it is important to get the question(s) correct if you want to get useful answers. I find that sometimes a pre-RFC discussion can help craft a good question. Template:Sacramento Kings roster is without question storing data, and in this case it's in a very nice, sortable table format. – Jonesey95 (talk) 21:35, 16 March 2019 (UTC)

• Yes I'm in strong agreement with application of the principles outlined above that generally conclude this ought to be deprecated, there needs to be a good foundation and exceptional reasons to transclude information. The exception is what Peter refers to above, I highly recommend that people examine what has been done with our taxobox system before concluding there is another solution. Wikidata doe not provide the means to accommodate what is done here, a century's old classification built on a web of citations, and I that is probably a good thing as I have reflected upon the arrangements at the sister sites. cygnis insignis 10:46, 16 March 2019 (UTC)
• Yes: We would be foolish to reject storing data in templates on principle. Why would we want to restrict our choice of ways of accomplishing a job? There are three main ways of storing a dataset for use in an article, and each of them may be optimal for some cases:
  1. Code the dataset directly into the page that uses it. This is fine for single-use datasets, especially when frequent updating isn't needed. Any non-Wikidata-enabled infobox is a good example of this.
  2. Place the dataset in another page (Template: namespace is then the obvious choice) and programmatically read that data into the article, or transclude the raw data directly if it needs no further processing. A recent example that I saw is in the article Bordeaux #Population where both the population change table ({{Table Population Town}}) and the population over time chart ({{Chart Population Town}}) draw their data from the same source, {{Database Population Bordeaux}}.
  3. Store the dataset on Wikidata. This makes the data available to other projects, but suffers from all the problems deriving from the lack of editors maintaining Wikidata, and needs somebody to write a piece of code to fetch that data for use in an article here. {{Infobox gene}} is a good example of using Wikidata datasets and how an English WikiProject maintains the data on Wikidata for its uses here.

There is a spectrum of abilities and of needs in curating data for use in Wikipedia articles. Our most valuable resource is committed editors and we should retain the flexibility to use whatever solution is preferred by the editors curating that data. It's not our place to impose our own preferences on them. --RexxS (talk) 11:52, 16 March 2019 (UTC)

• Very clearly put; I entirely agree. Peter coxhead (talk) 11:54, 16 March 2019 (UTC)

• Yes, but it depends. Templates should be considered on a case-by-case basis, and not blanket-ly. Also,

1. Re #1: sometimes, data in templates provides ease of access.
2. Re #2: look at the template's edit history and ask someone to update the entire template if you can't do it yourself.
3. Re #3: a contrived example, akin to 'ladders exist, so how should someone get to the 100th floor of a building, use a bunch of ladders?'. No, take the stairs, i.e. Wikidata. {{Wikidata}} and other similar templates exist for this purpose, and can be used in satisfy said examples.
4. Re #4: WP:DWAP.   ~ Tom.Reding (talk ⋅dgaf)  12:32, 16 March 2019 (UTC)

• Comment: The RfC is unfortunately worded. What should be asked is "should we be migrating data to Wikidata, and transcluding it from there rather than storing it in back-end data templates", to which the answer is a resounding yes. As with most things on Wikipedia, there is no deadline, and exceptions (for circumstances where Wikidata is not yet ready, for example) apply. Arguemnts about the ease with which multiple articles can be updated by changing a single Wikipedia data template are flawed, because they ignore the possibility that those articles exist in up to 300 Wikipedias in different languages; and they ignore the tools that exist, for conveniently making batch updates to Wikidata. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:06, 16 March 2019 (UTC)
• Yes, agree with the above, should be assessed on a case-by-case basis where these types of templates would be very useful. A blanket ban would not be helpful. Vaselineeeeeeee^★★★ 14:59, 16 March 2019 (UTC)
• Is storing data an acceptable use of template namespace? Generally no. I would much prefer migration to Wikidata. "Only 1 edit" argument can be a non-issue with e.g. d:Wikidata:QuickStatements (which is actually easier to manipulate IMO than a template which could be prone to operator error). Exceptions may apply (for example, I don't particularly support automatic taxoboxes here rather than Wikidata, but to enable those the best we would need to be able to query up the subclass chain, and that particular effort is not supported yet). --Izno (talk) 15:56, 16 March 2019 (UTC)
  • @Izno: "that particular effort is not supported yet" – it could be, see c:Module:Taxontree. I'm not sure you'd like the results, though. c:Medicago sativa is a typical example of it embedded in an infobox. --RexxS (talk) 16:19, 16 March 2019 (UTC)
    • @Izno and RexxS: This sub-discussion is at the wrong place; it should be at Wikipedia talk:Automatic taxobox system. {{3x|p}}ery (talk) 16:34, 16 March 2019 (UTC)
      • Not really? It was brought up above as a "we should allow this kind of data". I don't think we should so I commented on it. :) --Izno (talk) 16:41, 16 March 2019 (UTC)
      • @Pppery: My small note is fine here. The subject of broadening Wikidata usage is perfectly relevant to this discussion, and you don't get to decide where I post comments. Stop trying to over-regulate everything. Your compulsions are not shared by the vast majority of editors. --RexxS (talk) 16:54, 16 March 2019 (UTC)
    • I certainly wouldn't support the identifiers, but the class hierarchy seems entirely reasonable, which is the predominant reason for the automatic taxobox system existing in the first place. IIRC it currently requires multiple arbitrary access to a Wikidata item (each step up the tree), which is expensive, which is why I said "not supported". Embedded SPARQL queries would make that much more powerful, but that is not supported at all (and which is what I made reference to). --Izno (talk) 16:41, 16 March 2019 (UTC)
      • @Izno: The code I write no longer makes use of the old calls to enable arbitrary access. Previously it had to load the entire Wikidata item (statements, links, labels, descriptions, etc.), which was classed as expensive. The latest API lets us fetch a single statement from an arbitrary entity, which is not expensive. That has allowed these sort of chains to be followed. Another example is the location function in Module:WikidataIB which produces results like Selby, Selby District, North Yorkshire, England. Cheers --RexxS (talk) 16:54, 16 March 2019 (UTC)
      • @Izno: actually, it's very wrong to speak of the classification hierarchy. Different wikipedias use different and incompatible systems of classification for the same group; we here use different and incompatible classification hierarchies for different groups (e.g. for birds and dinosaurs). This is perfectly justified, since taxonomic decisions are in the end subjective. No-one has yet shown how different but overlapping classification hierarchies, together forming a tangled network, can be stored in Wikidata. (We manage it here in an ad hoc fashion via skip and variant taxonomy templates plus customized code.) The general point is that each proposed use of Wikidata must be considered on its merits, not by some blanket decision. I'm in no way opposed to using Wikidata when it can be made to do what we want (e.g. taxonbars). Peter coxhead (talk) 21:04, 16 March 2019 (UTC)
        • Careful, careful, not to straw man what I have said, which was specific to the example that RexxS provided. I am aware there are differing hierarchies for certain groups. No-one has yet shown how different but overlapping classification hierarchies, together forming a tangled network, can be stored in Wikidata. Wikidata already does so? You add a source for the particular system's hierarchy or even an ad hoc paper for a particular arbitrary grouping. If you were interested in all of a particular system's hierarchy for a specific taxon, as you walked up the classification tree you would filter out all of the systems not equal to the one of interest on a particular wiki page. If you were interested instead in a list of all the parent classes and their parents, that could be a table embedded in the article-proper. I think this is clearly in the realm of the possible based on my own experience. That said, perhaps these infoboxes fail in that what they should provide is only the most immediate classes in the hierarchy up or down. Other infoboxes have little issue with this way of looking at things. --Izno (talk) 23:08, 16 March 2019 (UTC)
• Yes Certainly on a case by case. I see now reason why it would be of benefit. scope_creep^Talk 16:48, 16 March 2019 (UTC)
• Yes, and I think with how the question is framed, it would be difficult to say no—even if one believes that it's not desirable, there are some WP:COMMONSENSE cases where it might be, so unacceptable is a very strong word. In any case, I actually believe that it's also generally desirable in the provided use cases, until there is an alternative solution that does the same. I think the benefits it brings are largely the ones said to be disadvantages by User:Zackmann above:
  • Ease of access: yes, one would need to go to a different page to edit the template, but this is the case with any template on Wikipedia, and it's easy to pick up even for relatively inexperienced editors who understand WikiMarkup (not sure how it works with VE). However, when editing the template, all the data is in one place, which improves ease of access.
  • Outdated references: I haven't personally encountered such a problem in data templates, but I would imagine that the point of a data template would be to have a list of data points that comes from the same source or a small number of sources. In such a case, updating references is significantly easier with a data template than a thousand different articles. I think the example given by Zackmann actually proves this point.
  • Dangerous precedent: I think that only the contrary, any of the nominated templates is a good example of how to resolve the very annoying problem of having to update hundreds of articles when new data is available, so it sets a good precedent to follow. If there are use cases where data templates don't work well, editors will realize that it's not working and go back to the old method—or just not create these tempaltes in the first place.
  • Performance issue: To be honest I don't know how switch statements are implemented on MediaWiki, so it could be that Zackmann is correct and it's a huge performance drain. However, there is a possibility for Lua templates now which bring templates closer to the actual computational performance (it's not exactly a low-level language, but far more efficient than WikiMarkup conditional statements). Making 1000 switch/case comparisons in PHP 7.x takes tens of microseconds on a typical machine, which doesn't seem like a big deal to me, even assuming a single-server architecture (not the case) and no cache whatsoever (also not the case). In any case, it should be the other way around: if we find data templates really useful but they are slow, we should all vote to have the performance improved in the annual community tech wishlist survey—not avoid using the feature. If it's catastrophic, WMF engineers are likely to intervene, like they did with the custom fonts.

—Ynhockey ^(Talk) 19:32, 16 March 2019 (UTC)

• Yes. "Bulk updating" is actually fairly common: usually new population data is released by statistics offices for an entire country (or country subdivision) at the same time. Some of the data can't be easily bulk-moved to Wikidata for license reasons. I believe in performance issues only when a dev tells us not to do something. So the data template setup works. The argument that I can agree with is that data can be hard to edit, but a lot of the data is not supposed to be edited. There should be clear instructions in the infobox or other templates that call the data how the data can be updated. Editing the entries on Wikidata isn't intuitive for the first time user either, so overall the case against data storage templates isn't very strong. And finally, I can't see how creative use of the template space sets anything but a good precedent. —Kusma (t·c) 20:17, 16 March 2019 (UTC)
• Invalid question. Technically anything counts as data, so the answer is of course yes. I think we should discuss what we mean by "data," and formulate some red lines over what is and isn't acceptable, before delving straight into !voting. -- King of ♥ ♦ ♣ ♠ 01:18, 17 March 2019 (UTC)

  Certainly the question should be focused on encyclopedic content/data which normally requires a WP:CITE on a main space article. -- Netoholic @ 15:00, 17 March 2019 (UTC)

  Good point, the population templates I'm familiar with (for German states like {{Metadata Population DE-NW}}, {{Population Cape Verde}}) have a reference and offer easy transclusion of that reference. Markussep ^Talk 19:41, 17 March 2019 (UTC)

• Yes, per Kusma. Markussep ^Talk 19:43, 17 March 2019 (UTC)
• We're getting into snow territory here, but most definitely yes. A great example is something like Template:Extrasolar planet counts: it uses the numbers subpage to store all the data needed, and is faithfully updated each month by a dedicated user. It's simple and designed to solve a few of the exact issues presented above. I don't think "ease of access" isn't a huge concern, as the mere usage of templates ({{whatever}}) is enough to complicate things, and I certainly don't think the precedent can be called dangerous. See also WP:PERFORMANCE. I also take the comments above about how one defines data to be well-said. Similarly, there are a ton of modules with data stored in /config or similar subpages. ~ Amory (u • t • c) 10:49, 18 March 2019 (UTC)
• Yes Bulk updating is obviously needed to be done regularly in regards to census and other similar results which may be updated yearly or ever 5 or 10 years. Makes it more convenient in some cases, but that doesn't set a "dangerous" precedent for other cases where the data is not updated in one go by one authority. Ease of access isn't an issue when the data does not need to be changed unless an update is released by the relevant authority. Galobtter (pingó mió) 18:36, 20 March 2019 (UTC)
• Yes at present. I think some effort could be made to gradually move some data to Wikidata (especially if used on multiple Wikipedias) but that should be a process guided by local discussion specific to each template or group of templates. --Tom (LT) (talk) 06:35, 22 March 2019 (UTC)
• No, it is not. Let's not nitpick on the definition of data. For the described kind of purpose(s), Wikidata is the platform to use, not the enwiki template namespace.
  Disclaimer: Invited by Legobot, am a fan of the Wikidata idea, typing on mobile
  ~ ToBeFree (talk) 18:05, 30 March 2019 (UTC)
• Yes some templates should be used to store some data. There are sure to be cases where that is unwise—like everything, discussions on a case-by-case basis are needed. The suggestions to use Wikidata, perhaps with QuickStatements, might work in some cases but this RfC cannot mandate that procedure. Wikidata is subject to vandalism that cannot be detected at Wikipedia. Using Wikidata is a timebomb until there is a bot which can transfer data from a central page on Wikipedia (which can be watched for changes) and report daily on any changes made at Wikidata. Editors are volunteers who know how to deal with wikitext. They should not be compelled to use QuickStatements or other foreign systems, particularly when those systems cannot check for vandalism. Johnuniq (talk) 00:02, 4 April 2019 (UTC)
• Sometimes. This is a case-by-case matter. Some good use cases have been outlined above (and have been heavily used, enjoying long-standing consensus). Others are very wrong-headed, and are rightly TfDed.  — SMcCandlish ☏ ¢ 😼  10:14, 4 April 2019 (UTC)

Discussion

• I find some of the examples and justifications used in this RfC so far to represent naive "cleverness" rather than good sense, and give no consideration to the long-term health of the project. This RfC as worded does not make a clear recommendation as to the overall direction use of this namespace should head. The choice is this: do we acknowledge that some data is currently in the template namespace but that the long-term plan is to move toward deprecating such uses in favor of other methods ("list of" articles, wikidata, bot updates, etc.), or are we saying that we should encourage moving more and more data into templates? Well, I think only the first of these options is in alignment with the intended use of templates. The template namespace is not a database, and our policy should be to constantly move toward eliminating article content from it. This has been the stated purpose in this guideline for almost 15 years. We have deleted templates which contained whole paragraphs of prose to be used on multiple articles. We have deleted a whole system of citations being stored in templates. And now we've already got many templates with individual data points (populations, planet counts, etc.) which change over time. The problem is, where does that end? Do we create #switch templates to cover the current head of state in every country, the current roster of every sports team, the current Billboard top 100, the current outdoor temperature in every city? This RfC has developed no guidelines, limitations, or recommendations which would prevent the creation of any of these or for any data set imaginable. In fact, if the present trajectory holds, it would almost seem to encourage them. But I will point out that in the cases I mention above deprecating prose and cite_ templates, the first instinct of the community was to support them, their use and scope grew over time, and then the problems became apparent and the community rejected them, but not after a lot of effort and clean-up - all of which could have been avoided by sticking to the proper scope of the template namespace in the first place. Article content (and the citations that support them) belong in the articles themselves. We have no requirement that such data be "current", only WP:Verifiable, and there is no deadline. Let's not go down the wrong path again. -- Netoholic @ 12:50, 18 March 2019 (UTC)
  • Storing data in a template works well when a single reliable source regularly issues a set of data that is used in multiple articles. With one source and one template, updating and checking for typos is greatly simplified and made much more reliable. No single source issues a table of heads of state, so gathering that information into a single template would not be useful. Data-in-a-template works well in some situations and not in others. Johnuniq (talk) 22:37, 18 March 2019 (UTC)
    • All you're doing is repeating how convenient this is, on the small scale, but not addressing why this is a good practice long-term or on a wide scale. Also, I'll point out that relying on only a single source can itself lead to WP:Verifiability or WP:NPOV problems, so maybe its a really poor practice. -- Netoholic @ 00:16, 19 March 2019 (UTC)
      • The alternative to {{Swiss populations data CH-ZH}} would be to edit around 200 articles to change the population values when the source releases new data (and for other editors to check each change to the number in each of the 200 articles). Single-source problems apply to an article and are not applicable for one item such as the population in a municipality. Editing data in one place (when that data comes from one source) is easier and much more reliable. I agree that some templates will be inappropriate—each needs to be considered on its merits. When there is a magic system to update Wikidata and monitor the Wikidata values, we might get population information from Wikidata. Johnuniq (talk) 01:34, 19 March 2019 (UTC)
        • "when the source releases new data" - why? You're operating under the assumption that Wikipedia articles must include data points which are absolutely current. -- Netoholic @ 02:25, 19 March 2019 (UTC)
          • I think it's good practice to aim for the most up-to-date information. You're right that the template namespace is not a database, but the guidelines do not prohibit using it as such. IMO, a population number is not a piece of text as meant in the first guideline (Templates should not normally be used to store article text, ...). Markussep ^Talk 10:18, 19 March 2019 (UTC)
            • I've always been open to changing "store article text" to "store encyclopedic content" or anything else that makes it more clear that any data (text, information, citations, etc.) about a topic should not be stored in the template namespace. This is why template calls within articles is fine, because the data point is stored in the article's history as a parameter. -- Netoholic @ 14:06, 19 March 2019 (UTC)
              • That's your opinion, not an accepted guideline. Markussep ^Talk 14:27, 19 March 2019 (UTC)
                • No, in fact it is the accepted guideline: "article text" links to Wikipedia:What is an article?. That page describes the content found in articles, including text, citations, etc. My point was that I am open to better wording, but the guideline already says that article content does not belong in the template namespace. -- Netoholic @ 19:23, 19 March 2019 (UTC)
                  • Wikipedia:What is an article? is an information page, "... not one of Wikipedia's policies or guidelines, as it has not been thoroughly vetted by the community." Templates like {{Table Population Town}} are article content and contain data, as is {{Chart Population Town}}. Surely nobody is suggesting that we hard-code each of those (along with the same data each time) in every article that would benefit from them? --RexxS (talk) 19:41, 19 March 2019 (UTC)
                    • I think we all know what qualifies as "article content" - that being the facts and figures related to a particular topic. You're being pedantic. But no, those templates only provide stylistic elements. The actual article content related to those templates is within the individual "databases" like Avignon Template:Database Population Avignon or Template:Database Population Bordeaux. These numbers are what belong stored within the article for those individual towns - there is only one article that benefits from each of them: Special:WhatLinksHere/Template:Database Population Bordeaux. Having them split out like that is exactly against the WP:Template namespace#Guidelines. -- Netoholic @ 20:21, 19 March 2019 (UTC)
                      • This is another illustration of a way in which this question is poorly formed and should have been the subject of discussion prior to this RFC. Template:Database Population Avignon is article content, and it used in only one article. The existing guideline already covers this sort of thing; the template should clearly be substed and deleted. The existence of Template:Database Population Avignon does not really bear on what this RFC should have been about, but because the question is too broad, we are talking about things that we shouldn't even need to discuss here. – Jonesey95 (talk) 21:28, 19 March 2019 (UTC)
                        • But that's not what I said. Please don't call me pedantic when you've not even read what I wrote. Look at Bordeaux #Population. There are both of the templates {{Table Population Town}} and {{Chart Population Town}}, each of which use {{Database Population Bordeaux}}. The data is used twice in the same article. Are you seriously contending that we should subst those templates and then delete the data? What happens when it's time to add another year's population information? What is easier: to redo the table and chart to accommodate the new value; or to simply add another datapoint to {{Database Population Bordeaux}} (which is done by bot anyway)? That's what datasets are for. And the same sort of argument applies to hundreds of sports-related templates which are updated even more frequently. Whoever wrote WP:TPG had failed to consider the case when the same data is used indirectly via two different templates in the same page. The only pedantry is thinking that guidelines are prescriptive, rather than descriptive. If you don't believe me, try using TPG as a rationale for deleting {{Database Population Bordeaux}} and see how far you get. --RexxS (talk) 22:02, 19 March 2019 (UTC)
                          • Guidelines are prescriptive. The word is taken from rope (line) which is laid along a path which is intended to be used by a traveler to hold onto and be led (guided) along the path. -- Netoholic @ 02:24, 20 March 2019 (UTC)
                            • Absolute nonsense. Policies and guidelines have always been descriptive on Wikipedia. Have a read of this useful essay, Wikipedia:Product, process, policy and note this:

                              Since the policy is a result of process and practice (instead of the other way around) it is quite possible that policy changes as a result of practice changing. Another important principle is that Wikipedia is not a bureaucracy. Policy is subservient to product, not the other way around.

                              The result of this setup is that policy pages are often a step or two behind process. Whenever the result of process does not correspond with policy, it means that the policy is outdated. When we encounter a new situation, we are not required to base our discussion on policy. Rather, we base a new policy on the process of discussion. A corollary of this fact is that we, as a rule, do not vote on new policy or guideline pages. Frequently, we simply write down what already happens. Anything that describes the usual outcome of a common process is a good guideline for the future.

                              You envisage an encyclopedia where rules are in place in order to determine how we must edit. That's not Wikipedia. --RexxS (talk) 18:29, 20 March 2019 (UTC)
                              • You just quoted an essay, not a guideline. Guidelines are prescriptive, in that, if someone want's to go against them, they are considered to be going against the established consensus. Consensus can change, and something like an RfC can certainly describe how we want to change them, but then they become prescriptive until a new consensus is shown. -- Netoholic @ 19:31, 20 March 2019 (UTC)
                                • Yes I quoted a useful essay as I stated. Which part of it do you disagree with? You've cited nothing but your own mistaken opinion. Policies and guidelines are descriptive, not prescriptive. They are descriptive in that they describe our consensus on what is best practice. They are not prescriptive in that they do not prevent an editor from making an edit. If that edit is shown to be improving Wikipedia, then it will stand. See WP:IAR. That's not an essay, by the way. --RexxS (talk) 20:02, 20 March 2019 (UTC)
        • "The alternative to {{Swiss populations data CH-ZH}} would be to edit around 200 articles" Not true; use Wikidata. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 00:07, 20 March 2019 (UTC)
• Other options Wikidata is being presented as the better solution, but some people prefer to not use Wikidata as they see it as hard to access or understand or monitor for vandalism and it is off-site. And Wikidata is not always a good fit for certain data. If the templates were converted to Lua the data could be stored in Lua tables as separate files, is commonly done. There is also the little known but interesting Tabular Data on Commons - "Tabular data allows users to create CSV-like tables of data, and use them from other wikis to create automatic tables, lists, and graphs." This is cool as you can create and maintain the CSV file using a bot, then a template from any wiki can render the data in articles without the need for a bot to edit the wikis directly. For example keeping weather or election data up to date. -- GreenC 02:36, 19 March 2019 (UTC)
  • While people make the argument that maintaining a template in one location is more convenient - that only applies to this Wikipedia. Do we want to maintain copy-cat templates in all 300+ Wikipedia languages? Well, suddenly updating in a central location (Wikidata) doesn't sound like such a burden after all. -- Netoholic @ 14:06, 19 March 2019 (UTC)
    • There aren't 300+ Wikipedia's that use templates to store population data, I count 28 at {{Metadata Population DE-BY}}. Markussep ^Talk 14:27, 19 March 2019 (UTC)
      • Thank you for proving my point. There are currently only 28 using that template, but in all we have 300 Wikipedias which this could be copied to. This does not scale. Even maintaining "only" 28 is more work than updating Wikidata centrally. -- Netoholic @ 19:23, 19 March 2019 (UTC)
        • Tabular data on Commons is a single location accessible to all Wikis. IMO it's better than Wikidata for many applications, and much easier to work with. Wikidata is not the right solution for everything. -- GreenC 14:54, 20 March 2019 (UTC)
• Let's go back to basics. Any set of structured data is a database, by definition. So I reject the argument that template space is not a database. It quite clearly can hold databases. The only factor that differentiates templates from other namespaces is that you don't have to include the namespace prefix when transcluding the page. The whole purpose of templates is to transclude them into multiple other pages, so if you have a dataset that needs to be transcluded in other pages, then template namespace is a perfectly logical place to put it. Where things started to go awry was when editors started to process the data in the dataset before including it in an article. The programming ability of template space is rudimentary, to say the least, and it is only through the ingenuity of editors that we have developed complex templates that process data (which is usually held in template space as well). Does this work? Yes. Is it the best way to process data in the long-term? Almost certainly not. Surely we would want to move toward a situation where data is stored in a central location and is processed by an efficient, fully-featured language. The issue at present is that our main central location is Wikidata, and that site is not yet capable of curating the data held there because of lack of editors relative to the size of the database. Commons might look like an attractive alternative for a flat-file database, but at the expense of having to maintain another watchlist in order to keep a check on data that you have placed there – there is, at present, no means of monitoring relevant changes on Commons from your enwiki watchlist. Until we have better quality data on Wikidata, with far more robust anti-vandalism and more mature policies on verifiability and BLP, we are going to have to accept that there will be many places where we simply cannot deprecate storing a dataset locally (and that includes within template namespace in many cases). And once we accept that, you can see why this RfC will remain merely "blue-sky" thinking for the foreseeable future. --RexxS (talk) 13:03, 19 March 2019 (UTC)

Is watching a single page on Commons really not possible? If that is the only hurdle, it wouldn't be difficult to create a public watchlist program that logs a page on Enwiki every time the Commons page is changed (filtered for bots). Then anyone can watchlist the log page. BTW I love your idea to "move toward a situation where data is stored in a central location and is processed by an efficient, fully-featured language" .. unfortunately we have a minority who believe a "fully-featured language" is a detriment for the majority. -- GreenC 15:06, 20 March 2019 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Change TfD headers to links

Could a link to the subpage be added to the date headers (ie September 9) under the "Current discussions" section? These links are already present in the old discussions section and the apperance on the subpages will be the exact same, but navigation will be slightly easier. Posted here to gain consensus after request at User talk:AnomieBOT/Archive 11#Change TfD headers to links.--Trialpears (talk) 22:10, 9 September 2019 (UTC)

I've done this for this weeks subpages and if noone complains will ask for it to be the default again. --Trialpears (talk) 16:27, 19 September 2019 (UTC)

I object to this being done manually. the bot should be the one to do it, since the bot repairs any unrecognized headers. I have fixed the double headers on the ones that were changed manually. Frietjes (talk) 19:44, 19 September 2019 (UTC)

I just saw that, thanks for fixing it! I thought it wouldn't interfere with the bot, but apperently it does. It did accomplish the thing I want though, until the bot "repaired" it. --Trialpears (talk) 20:17, 19 September 2019 (UTC)

Infobox historic subdivision

What's the cause of the delay in merging Template:Infobox historic subdivision with Template:Infobox historic subdivision, which was listed here on 13 April 2018? There's nothing on either template's talk page. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:59, 19 September 2019 (UTC)

Besides that you are trying apparently to merge two templates that are the same template? :) --Izno (talk) 12:24, 19 September 2019 (UTC)

Meh. With {{Infobox former subdivision}}. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:05, 21 September 2019 (UTC)

Been working on some other mergers, honestly didn't see this one. Will get to it this weekend. Primefac (talk) 13:43, 19 September 2019 (UTC)

Seems done. Thank you. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:35, 23 September 2019 (UTC)

Resolved

 – Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:35, 23 September 2019 (UTC)

Log time glitch

Hey, this doesn't exactly reflect well on me I guess, but I added a new entry to the log at midnight, September 23. The time in the signature is 00:01 on the 24th, but it's under the heading of the 23rd. Also, a minor thing that isn't a problem: That signature is an hour slow, it's 01:14. MaelstromOfSilence (talk) 00:14, 24 September 2019 (UTC)

MaelstromOfSilence, it looks (based on the lack of tags) that you added it manually to the 23rd. If you had wanted it on the 24th, you should have edited the 24th subpage. However, it's not the end of the world, as a few minutes either way isn't going to break things. Primefac (talk) 00:21, 24 September 2019 (UTC)

Ah, okay, thank you Primefac, my bad.MaelstromOfSilence (talk) 00:24, 24 September 2019 (UTC)

No worries, weird stuff like this happens all the time. If you think you might be nominating other things in the future (or just want a cool tool), you should enable and use Twinkle, which automates a lot of the annoying stuff like adding the nomination template to the page and the XfD log. Primefac (talk) 00:40, 24 September 2019 (UTC)

Discussion at Module talk:XfD old#Section edit links

 You are invited to join the discussion at Module talk:XfD old#Section edit links. (A proposal to add edit links to the "Old discussions" section) * Pppery * _{it has begun...} 02:17, 4 November 2019 (UTC)

Archives for holding cell?

Shouldn't we archive the holding cell? Plenty of discussions occur in the holding cell that could potentially be useful in the future. While it is avalible in the page history, having them in archives makes it significantly easier to find since it shows up in the normal search function. I could make a quick bot that archives anything marked with {{done}} or similar. ‑‑Trialpears (talk) 12:52, 8 November 2019 (UTC)

With the exception of a few big discussions recently, there is very rarely (if ever) discussion about templates in the holding cell. I don't know if there would be a ton of use. Primefac (talk) 22:12, 9 November 2019 (UTC)

I guess it's just me who's using it like that then. I still think that many of the discussions recently ought to be archived and having the option of tagging items with discussions as  Done to prompt a bot to archive it would be beneficial. Would you object to me implementing this? ‑‑Trialpears (talk) 22:21, 9 November 2019 (UTC)

Let's back this up a second before we jump straight into whether I object wholesale; I mainly don't see what you're trying to accomplish. So, some questions:

1. What type of discussions would be archived? Does the discussion about the {{Copied}} merge (permalink) need to be archived? Would all template listings be archived?
2. Where would they be archived?
3. Based on #1, how frequently are you seeing conversations that would require archiving being removed?

I won't tell you what my answers would be to necessitate this process, as I'm curious to see what yours are first as it was your idea. Primefac (talk) 23:17, 9 November 2019 (UTC)

Sure,

1. No, I don't see a particular need to archive that short ecxchange, it doesn't discuss anything about the implementation it self, just who's going to perform it (sorry for the delay, have been doing quite some non-Wikipedia related programming). In general I don't think all discussions should be archived, but the option to do so would be valuable.
2. Wikipedia:Templates for discussion/Holding cell/Archive 1 seems like the obvious choice.
3. A few times a month, take for instance this revision which contains 8 discussions, all of which I could see a small benefit in archiving, especially since several of them got another reply or two. This is admittedly an extreme case since a few have stayed there for many months and this falls into a period where I started a lot of discussions for educational reasons as well as a quite large backlog, but even just in the last month there were four I would concider appropriate to archive (1, 2, 3, 4)

I really don't see any harm to it and a not insignificant benefit. ‑‑Trialpears (talk) 23:48, 9 November 2019 (UTC)

Eh... I'm still not convinced it's necessary, but I don't mind waiting for some other opinions. Primefac (talk) 01:17, 10 November 2019 (UTC)

Chinese name infobox merges

Our most long-standing merge requests are {{Infobox name module}} and {{Infobox East Asian name}}, both into (or with) {{Infobox Chinese}}, dating from April and May 2017, respectively. Is there an issue holding these up? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:40, 23 September 2019 (UTC)

As usual it's mostly that noone has gotten to it. I'll give {{Infobox East Asian name}} a go tonight. --Trialpears (talk) 11:18, 23 September 2019 (UTC)

Yeah. Some of them just look complicated. Never know 'til you try, though; the subdivisions merger was actually not as bad as I thought. Primefac (talk) 20:38, 23 September 2019 (UTC)

@Trialpears: Any joy? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:27, 21 November 2019 (UTC)

Pigsonthewing {{Infobox East Asian name}} is mostly ready and will be added to my long list of things I should do this weekend, {{Infobox name module}} is significantly trickier and will require more module changes. Trappist the monk may want to help out though? The main reason for the stop now was the drawn out RM which decide to keep {{Infobox Chinese}} at its current unfortunate name. ‑‑Trialpears (talk) 14:21, 21 November 2019 (UTC)

"Out of process" actions on templates

I've had a couple of recent TfD discussions concerning "out-of-process" actions on templates.

By that I mean—

• the orphaning, or
• substituting (in the case of templates not mandated to be substituted)—

of a template prior to listing it at TfD, or while a discussion at TfD is pending.

Sometimes this is accompanied by a subsequent claim in the nomination that the template is unused or has few transclusions (because of the beforehand orphaning or substituting), and usually without disclosing that the disuse or low use is due to the prior actions to orphan or substitute it.

There is a long history of identifying when this happens, and sometimes admonishing the editors responsible for it, in TfD discussions. I gave a quick look to try to find one of the earliest examples of this, and here's one from 2005. However, as much as I can tell, a proscription against "out-of-process" actions is not in our guidelines.

So, is there a consensus that this is a proscribed practice (acknowledging that there would be exceptions for templates that are, for example, immediately breaking pages)? And if so, should it be documented somewhere? --Bsherr (talk) 15:27, 19 January 2020 (UTC)

If someone orphans a template, and then tries to TFD it based on it being "unused", and someone notices this, then by all means it should be discussed at the TFD. Occasionally it will be a valid orphaning (i.e. "single use template that I subst'd into the article"), but if it's been done purely for the purposes of having the template deleted then the reason of "unused" is no longer valid and a better reason will be needed.

To answer your last question, I could potentially see something along the lines of "it is inappropriate to orphan a template prior to nomination" in the guideline, but with so much text on the page already I don't know if it would really do any good. Plus, I'm not sure it's that common of an issue. Primefac (talk) 15:46, 19 January 2020 (UTC)

The perpetual problem of the choice not to document something on Wikipedia is the doubting that a consensus exists about it. I think there's a larger question about whether some of what appears on WP:TFD shouldn't be made a summary of prospective content at a page like Wikipedia:Deletion process and other policy and guideline pages (perhaps even a new page), which could contain better advice about templates and when each of the outcomes we use is appropriate. --Bsherr (talk) 16:00, 19 January 2020 (UTC)

I'm not really sure what you mean; WP:TfD is set up pretty much the same as WP:AfD, and they both link to the same secondary pages about deletion. Primefac (talk) 16:40, 19 January 2020 (UTC)

Bsherr is apparently referring to my TfD nominations here, and here (two sections of the same page), albeit without the courtesy of a ping or notification. In the former case, I substituted a single use wrapper, leaving behind the template that it wrapped. I subsequently nominated the wrapper template for deletion noting the substitution in my nomination, on the basis that it "can be replaced by a more generic 'busy' template with suitable message content". In the second case, I removed just three outdated instances of a time-limited template ("I am busy with exams") from the pages of people who have not edited in the last two years or more. I then nominated the non orphaned template for deletion, again on the basis that it "can be replaced by a more generic 'busy' template with suitable message content". Having failed to provide the requested evidence to substantiate his allegations that I acted "out of process" and was being "disingenuous", Bsherr has instead brought us here. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:24, 19 January 2020 (UTC)

Because I'm simply asking about documenting the guidance. Not about your conduct. And I said in that discussion that I would start this discussion on this talk page, which I assumed you would be watching. --Bsherr (talk) 16:34, 19 January 2020 (UTC)

You mentioned no specific talk page. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:53, 19 January 2020 (UTC)

As we were at WP:TFD, I thought WT:TFD would be apparent, but I can see I could have been clearer. Sorry. --Bsherr (talk) 17:12, 19 January 2020 (UTC)

(edit conflict) Well, as I said above, the argument in those two discussions is both "unused" and "unnecessary", and I'd say that your removals (with or without the subsequent TFD) was reasonable. I think raising the issue here is perfectly reasonable, especially since it was done without specifying either the editor or the templates in question. Primefac (talk) 16:38, 19 January 2020 (UTC)

• Well, I've had cases where, as part of general cleanup, I would remove inappropriate uses of a template, only to realise at some point that there are no appropriate uses left and that the template ought to get TfD'ed. Though of course, it's a must for there to be a mention of the prior orphaning. But yeah, over the years there have been occasional situations where editors would orphan a template and then immediately nominate it as unused, "forgetting" to mention the reason for it being unused. You would think this should all be common sense, but I guess we can't completely take that for granted. I don't think it will hurt to have a one-sentence mention of that somewhere at the top. At the very least, we'll have somewhere to point to if an editor asks "Where does it say I can't do that?". – Uanfala (talk) 17:13, 19 January 2020 (UTC)

Can non-admins close as delete or orphan?

I made this edit to WP:Deletion policy changing a non-administrator may close a TfD as orphan to a non-administrator may close a TfD as delete, but was reverted by JJMC89. I think this should be changed since non-admins closing as delete is a common practice and the guideline should reflect this especially since it has previously been discussed at Wikipedia talk:Templates for discussion/Archive 26#NAC delete closes where I interpreted it as a consensus for allowing non-admins to close as delete with JJMC being the only dissenter. I don't think a whole RfC should be needed to change this just a small change to the guideline to reflect current, uncontroversial, practices, but feel free to turn this into a RfC if you have to. ‑‑Trialpears (talk) 17:13, 20 January 2020 (UTC)

Keep doing what you're doing and don't worry about changing WP:DEL. Primefac (talk) 18:23, 20 January 2020 (UTC)

(You changed the deletion process guideline, not the deletion policy.) Non-admins may only close as orphan, not delete. Allowing non-admins to close as delete was originally proposed and failed to gain consensus in the RfC. As such, it is not an uncontroversial change, and you'll need a new RfC to demonstrate that consensus has changed in favor of allowing non-admins to close as delete. The archived discussion was not advertised like the RfC (not representative of the wider community) and therefore doesn't demonstrate a new consensus on the matter.

On the substance of it, I oppose non-admins closing as delete. They do not have the tools to implement the close. If they are trusted enough to close as delete, WP:RFA is that way. Otherwise, it just creates more work for the admin that will have to process the NAC instead of just closing it themselves. — JJMC89 (T·C) 04:45, 21 January 2020 (UTC)

JJMC89, fair enough. I still think consensus has changed here as can be seen how these nominations are handled in practice. There was also the 4 day holding period for the CSD tagging, from the same RfC and that did not need a new RfC to remove. I really don't think the RfA argument works since I think my track record clearly shows the competency required to close these discussions but if I were to go to RfA I would undoubtedly fail. ‑‑Trialpears (talk) 08:19, 21 January 2020 (UTC)

I completely agree with JJMC89. Furthermore, a track record of competency is exactly what is needed to become an admin, even if that competency is narrow (eg: I ran solely to close RfDs as delete with a track record built primarily at RfD). -- Tavix ^(talk) 12:26, 28 January 2020 (UTC)

Tavix, a lot more is also needed such as tenure of probably more than 18 months, a stellar civility record and not too many controversial opinions. I can come up with several users that I would trust with closing these discussions but doubt would pass an RfA, at least yet. We should of course encourage our good closers to go to RfA, their work would be even more valuable if they're admins, but stopping them from doing good work now is not productive. I will continue closing as usual, but I guess it's not a good idea to put this into policy without significant discussion since there is significant opposition. ‑‑Trialpears (talk) 09:13, 29 January 2020 (UTC)

When you're ready to run for admin, I'd be happy to support or even nominate you. Until then, I recommend you leave deletion to those with the technical ability to actually carry out such closures. -- Tavix ^(talk) 12:13, 29 January 2020 (UTC)

Fair enough. It's not that many 0 transclusion templates and the benefits are close to zero in these cases. I will be more hesitant to close these in the future. ‑‑Trialpears (talk) 10:07, 30 January 2020 (UTC)

Question regarding Political party shortname templates

Is there any consensus discussion on the use of the templates in Category:Political party shortname templates? I know that the football teams had similar templates which resulted in around 12k templates being deleted. --Gonnym (talk) 10:27, 13 February 2020 (UTC)

Time to start planning...

...for the party to mark the third birthday of {{Infobox Chinese}} being listed in the holding cell.

Seriously folks, what's the hold up here? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:32, 16 February 2020 (UTC)

Despite the TfD, the editors on that talk page and on related TfDs keep claiming either that it can't happen, or that Chinese is not an OK name, which was enough to be cause at least one TfD to end at no-consensus. --Gonnym (talk) 11:40, 16 February 2020 (UTC)

Whereas the TfDs listed closed with consensus. Have they been overturned at deletion review? Complaints about the name are straw men, since there is no proposal to or mandate for the retention of the name "Chinese". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:01, 16 February 2020 (UTC)

No deletion review as far as I'm aware. You also don't need to convince me that opposing because of name change is irrelevant. I'm not the one that closed that as such, and would have never even gave any weight to those arguments. --Gonnym (talk) 12:26, 16 February 2020 (UTC)

Several reasons really. First there's the naming issue. Using Infobox Chinese without Chinese in an article not in any way related to China is problematic. My attempt at changing the name was unsuccessful, partly due to misinformation and partly due to differences in what people think the template should be used for. Perhaps it's worth another go addressing some of the consents from the get go and after some improvements to the template and it's documentation. There's also the issue of direct replacement not being possible. The module version and the template versions of Infobox Chinese don't have the same features requiring significant changes to the modules before going ahead with the merger. I was not knowledgeable enough with lua to do it at the time and the original creator Trappist the monk didn't want to do it either. I think I'm capable of fixing the module now but I still have quite a few ongoing projects so it will probably be a month away. ‑‑Trialpears (talk) 12:13, 16 February 2020 (UTC)

Documentation changes related to templates

I made some changes to Wikipedia:Templates for discussion/Closing instructions#Delete (diff) and added a new section Pages in the Template namespace under Wikipedia:Deletion guidelines for administrators#On deleting pages (diff) to clarify that transclusions must be removed before deleting any page in the template namespace. davidwr/(talk)/(contribs) 21:17, 6 March 2020 (UTC)

Wikipedia's transclusion mechanism will transclude articles if there is no template page with the same name Is this really true? * Pppery * _{it has begun...} 21:25, 6 March 2020 (UTC)

Odd, it has happened to me before. Must have been a bug or more likey a misplaced colon after the [[. It is not happening now. I left the first change and part of the 2nd change as they are generally helpful. davidwr/(talk)/(contribs) 21:41, 6 March 2020 (UTC)

Discussion at Template talk:Infobox royalty#Infobox advisory detached from infobox

 You are invited to join the discussion at Template talk:Infobox royalty#Infobox advisory detached from infobox. (relating to a recent edit that had the effect of hiding all non-inline TfD tags on mobile) * Pppery * _{it has begun...} 16:04, 31 March 2020 (UTC)

Is Template:Tfd2 used only to propose deletion?

Text for Template:Tfm2 is explicit in that a merge is proposed. However, Template:Tfd2 is not so explicit. Documentation does not mention deletion. Instructions at WP:TFDHOW suggest that {{subst:Tfd2}} is about deletion:

• For deletion: {{subst:Tfd2|template name|text=Why you think the template should be deleted. ~~~~}}

Is {{subst:Tfd2}} used exclusively to propose deletion of template? And related question: is merging and deleting the only proposals made at WP:TfD? —⁠andrybak (talk) 12:44, 2 April 2020 (UTC)

{{tfd}} is used on the template, {{tfd2}} is used on the daily log page. {{tfm2}} is for merging, {{tfd2}} is for everything else. Templates can be nominated to TFD for things other than deletion or merging, which is why it's called Templates for discussion (there's a rather long history behind that, but it's likely the reason why deletion isn't mentioned on the template /doc). Primefac (talk) 23:22, 30 April 2020 (UTC)

What should be the venue for discussing Rcat templates?

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

What should be the venue for discussing rcat (WP:Redirect categorization) templates/categories?

This question is prompted by Wikipedia:Templates for discussion/Log/2020 January 20#Template:R from meme where this question was raised. I personally think it should be at RfD since the audience at RfD will likely be more experienced with redirect categories making them better at making decisions about them then the audiences at TfD or CfD. While this is quite different from RfDs regular content I still believe that they are the most suitable for handling these template with RfDers generally having experience using them. Both TfD and CfD have a reasonable claim since they are templates and they are used for categorizing pages. I will transclude this section at WT:RFD, WT:TFD and WT:CFD so all interested parties can participate. ‑‑Trialpears (talk) 22:12, 24 January 2020 (UTC)

Trialpears, Good discussion. In theory, I'd say TfD because of the namespace. However, in practice, since rcats are so widely used, I'm wondering if we shouldn't be discussing these in a more prominent place? CfD proposed by MJL seems reasonable, but CfD, too, sees even less participation than TfD in most cases. RfD is reasonable, though not necessarily dealing with redirects so the editors/admins there may be less familiar with the template nuances. What about MfD (like userboxes), or, possibly, at one of the Village Pumps? (Twinkle would need to be updated in any case.) Doug Mehus T·C 22:21, 24 January 2020 (UTC)

I'll be honest and say that I would also prefer to have those conversations here. RFD regulars are the ones who have the most familiarity with them, but I have a hard time squaring my preference with the mandate of CFD to discuss all categories. The last place, imo, that should be the venue for RCATs would be TFD since they're just a unique type of categories and TFD regulars would be the less familiar with their usage than RFD regulars. (edit conflict) –MJL ‐Talk‐^☖ 22:27, 24 January 2020 (UTC)

MJL, Yeah, similar thoughts as well. RfD makes the most sense to me, too, but its regulars may be less familiar with the intricacies of the rcats and categorization. What about MfD? Doug Mehus T·C 22:35, 24 January 2020 (UTC)

@Dmehus: No, definitely not MFD; they're mandate doesn't come close to RCATs. –MJL ‐Talk‐^☖ 22:41, 24 January 2020 (UTC)

MJL, Okay, fair enough. No clear answer for me then. It's been RfD and CfD; neither of which are ideal (for different reasons). Doug Mehus T·C 22:42, 24 January 2020 (UTC)

• CFD -- they're a type of category. The template is simply a vehicle for applying the category, similar to stub templates which are discussed at CfD. -- Tavix ^(talk) 22:53, 24 January 2020 (UTC)
• CfD - MJL, who maintains the Archer script, does seem to favour CfD because those editors/administrators are more familiar with the subtleties. RfD would notionally make sense as well, so I wouldn't be opposed to that, and it does generate (somewhat) higher participation than CfD. No real clear, runaway "winner" for which venue is best, but on balance, I concur with the sentiments expressed by MJL and Tavix to firm up my support, for the reasons expressed above. Doug Mehus T·C 23:07, 24 January 2020 (UTC)
• TfD These are templates; I see no good reason to add yet another special case. * Pppery * _{it has begun...} 01:10, 25 January 2020 (UTC)
• TfD or CfD depending on what is discussed. If the issue is with the category itself, then nominate the category and hold the discussion at CfD. If the issue is with the template, then nominate it at TfD. --Gonnym (talk) 10:17, 25 January 2020 (UTC)

  Gonnym, There is established precedent, though, to discussing certain types of templates in other venues. For example, userbox templates, regardless if in userspace or template space, are discussed at MfD. In this case, as discussed above, there are wide-ranging implications with rcats, both in terms of how they're categorized, how they're used, and the impacts to scripts like Archer, Capricorn, Twinkle, etc. CfD does seem to have modestly higher participation than TfD, at least on some days, though it really varies. Crucially, though, the active CfD editors are more likely to be keenly aware to the intricacies of the rcats as the two are closely related. Doug Mehus T·C 14:40, 25 January 2020 (UTC)

  I see those as rare (and IMO bad) exceptions to the rule. I also disagree with your participation analysis. I had a category nomination relisted twice with 0 participation. I'm not changing my opinion on venue. --Gonnym (talk) 15:12, 25 January 2020 (UTC)

• I have to go with CfD, because they're almost entirely about maintenance categorization. That the categories are usually placed via templates is simply incidental; many maint. cats. do not have templates, but they wouldn't suddenly become TfD "jurisdiction" if someone created templates for them. I could see TfD maybe being the right venue when there is no correspondence between a template and a cat., but this is uncommon. Thinking back, we used to have other cases like this, where things that were mostly categories but also with a template or other "feature" were discussed in other venues. E.g., Stub categories/templates used to have their own WP:SFD, but this has been closed, and CfD is now the venue. It would be strangely inconsistent to declare CfD not the venue for the parallel case of Rcats. Pppery's "No good reasons to add yet another special case" actually is a better rationale to use CfD than TfD. WP not being a bureaucracy (and per Gonnym, above), it should be fine to occasionally TfD an rcat template (if it doesn't implicate a corresponding category; e.g. there are various more-specific rcat template variants that still go to the same maint. cat. as the more general one, unless/until we decide to split the cat. to be more specific; and we might need to discuss a template in template terms only, without any effect on a category that did directly correspond). See also WP:RM being the conventual venue for template renames, yet TfD has sometimes been used for template-related rename discussions. Consensus can form anywhere, if there's sufficient clueful editorial input. A further complication is that many rcats are actually template redirects, not templates, yet they all relate to categorization in the end, even if not exactly corresponding categories. So, if there's to be a default, it should be CfD, because a category is always involved one way or another, and moving categories around or deleting them is a more complicated process than doing the same with templates and redirects. This isn't even really about Rcats in particular; any template that exists solely to apply a category is really a CfD matter, being an incidentally templatey means to a categorization end.  — SMcCandlish ☏ ¢ 😼  03:28, 30 January 2020 (UTC)
• Need to think about this but whatever the outcome, it should be cross-advertised so people who don't follow all related discussions will see it. My gut sense prior to thinking about it is to prefer CfD if the change will affect categorization, or TfD if it will not. For example, if there was an effort to merge {{R from move}} and {{R from merge}} so they used parameters, but the net result would not affect categorization, then TfD is the place to discuss it. If there is an effort to split {{R from move}} so that some moved articles wind up in a new category, then CfD would be the place to discuss it. Again, I may need to give this more thought. Either way, cross-announce the discussion so people who follow only TfD or RfD discussions will be aware of it. davidwr/(talk)/(contribs) 18:08, 30 January 2020 (UTC)

  I didn't proofread the above comment very well. To correct and summarize: The original discussion should start wherever it makes sense to start it, CfD, TfD, or RfD. However, if there is any impact on the other two areas, there needs to be cross-advertising as appropriate. davidwr/(talk)/(contribs) 23:40, 30 January 2020 (UTC)

  Already done; this entire discussion is sectionally transcluded into both WT:CFD and WT:TFD. Also "advertised" at WP:VPPOL.  — SMcCandlish ☏ ¢ 😼  23:48, 30 January 2020 (UTC)

  I didn't proofread the above comment very well. To correct and summarize: The discussion of changes to a specific RCat template should start wherever it makes sense to start it, CfD, TfD, or RfD. However, if there is any impact on the other two areas, there needs to be cross-advertising as appropriate. davidwr/(talk)/(contribs) 23:58, 30 January 2020 (UTC)

• TfD or CfD on a case-by-case basis. Well, I learn something new every day. I assumed such templates were for the benefit of other editors looking at a redirect's history and status, and wasn't aware of the categorization purpose. From my naive perspective, these are page templates first with categorization as a side effect. But as editors above me argue, the venue really depends on the action contemplated. --{{u|Mark viking}} {Talk} 19:07, 30 January 2020 (UTC)
• Anarchy per WP:NOTBURO and WP:CREEP. Either TfD or CfD is an appropriate venue and regardless of where the deletion discussion occurs, as long as interested editors are properly notified "a procedural error made in a proposal or request is not grounds for rejecting that proposal or request." Leave where to nominate it up to the nominator based upon what they think is the most important factor to discuss. — Wug·a·po·des​ 23:00, 30 January 2020 (UTC)
  • RfD is actually an interesting option. If we must choose a place to have these discussions, I would prefer that forum since the people familiar with rcats are most likely to see it there. — Wug·a·po·des​ 23:10, 30 January 2020 (UTC)

    Wugapodes, I agree with you here. My first choice would probably be RfD, but secondarily, CfD since the template itself is just the vehicle, as Tavix and SMcCandlish explain, by which the redirect gets categorized. Without the maintenance categories, these rcat templates would serve no purpose. Doug Mehus T·C 23:33, 30 January 2020 (UTC)

Beg to differ, Dmehus, rcats have two important functions: 1) to sort redirects to maintenance categories, and 2) to inform editors who come the the redirect page by explaining the reasoning behind the categorization. Reason "2" is why there are text messages on each rcat. The informative explanations and descriptions are especially helpful for editors who are inexperienced and are learning the details about redirect categorization. P.I. Ellsworth  ed. ^put'r there 23:52, 16 March 2020 (UTC)

• TfD if discussing a particular Rcat template, CfD if discussing the underlying category, and RfD if whichever type of page is being discussed is itself a redirect to another page. In all cases, a note should be left at WT:REDIRECT as changes to any of these types of pages shouldn't be made without input from editors with experience working in the overall redirection pseudo-namespace. Ivanvector (^Talk/_Edits) 15:14, 31 January 2020 (UTC)
  • All Rcat templates have a corresponding category (because that's the purpose of the Rcat template), so it isn't possible to separate the two. If one gets deleted, so does the other, and so on. -- Tavix ^(talk) 17:20, 31 January 2020 (UTC)

  What Tavix said...completely. The template is just the conduit by which the rcat categories are applied, since it involves adding text below the redirect destination. We could, in theory, categorize redirects without the template, but then how would we easily apply the category descriptions below the destination of each redirect? We'd still need a template from somewhere to do this efficiently; copying and pasting doesn't strike me as efficient. Doug Mehus T·C 17:29, 31 January 2020 (UTC)

• ...TfD. Is anyone else in this discussion besides me aware of the existence of {{Catfd}} and {{Catfd2}}? See WP:TFDHOWTO for instructions in regards bundling related categories with TfD discussions. (Apparently, this method has been in place since 2006 or so.) Steel1943 (talk) 20:30, 31 January 2020 (UTC)
• Yes, although they weren't on my mind when I !voted above. * Pppery * _{it has begun...} 21:25, 31 January 2020 (UTC)
• TfD, per the principle of least astonishment. I think it would be advisable to notify WikiProject Redirects, but I do not think these nominations belong at CfD (can decide what to do with a template-populated category but not whether the template itself should be kept, deleted, redirected, etc.) or RfD (unless the template is a redirect). -- Black Falcon ^(talk) 23:44, 2 February 2020 (UTC)
• I'd say here RfD if the aim is to fine-tune the scope of the templates, because the RfD crowd includes a majority of people who go around tagging the redirects, but TfD/CfD if the proposal is to delete certain templates and categories, by the principle of least astonishment. Deryck C. 00:09, 4 February 2020 (UTC)

  "here" is ambiguous because this dicussion is transcluded on the talk pages of all relevant XfD. I assume you mean RfD. * Pppery * _{it has begun...} 23:11, 5 February 2020 (UTC)

  True, in theory, but when a section is transcluded as Trialpears has done (very handy, thank you! Now I know how to do that properly!), in practice, it becomes very difficult for an editor to reply on the talk page with the transclusion because they will see no other discussion. So, yeah, I assumed Deryck Chan meant RfD unequivocally. Doug Mehus T·C 23:14, 5 February 2020 (UTC)

  Corrected. I didn't realise this was section-transcluded to other noticeboards. Deryck C. 22:40, 15 March 2020 (UTC)

• Hate to say it, but generally amenable to most of the above. My instinct is TfD, just because it'll be the default assumption, but I do agree that the folks at CfD are most likely to care or have an opinion. I actually think RfD is the least-good option; they are related to redirects, but have little in common with them (to borrow a line from Mitch Hedberg, Rcats are to redirects as cooking is to farming). Steel1943 brings up the catfd templates, which I like and would seem to support TfD, but they wouldn't increase awareness unless someone stumbled on the category, would they? ~ Amory (u • t • c) 21:12, 1 March 2020 (UTC)
• TfD. Late to this discussion and surprised that I had to hear about it by checking Wikipedia:Administrators' noticeboard/Requests for closure, rcats are templates, not categories nor redirects. They should be discussed at TfD, nowhere else. As always, the category would follow, i.e., if an rcat is deleted, then its maintenance category is also deleted. P.I. Ellsworth  ed. ^put'r there 00:00, 17 March 2020 (UTC)
  • Oh weird, I didn't know that WP:RCAT is for "templating redirects". I always thought it was for Categorizing redirects. My point is that we are categorizing redirects, so its the categories that matter. I find it shocking that someone with so much experience with RCATs would so wrongly declare that they are not categories when they clearly are. -- Tavix ^(talk) 14:12, 23 March 2020 (UTC)
    • Oh, friend Tavix! Rcats have been sooo misunderstood, as exemplified by this entire discussion. Rcats serve TWO main purposes, and only one of those is categorization. You're a pretty smart editor, and I would bet ten dollars to a doughnut that if you were to give it just a few moments of thought, you are probably one of the few editors who will then realize what the other main purpose is. Okay, I won't leave you in suspense. The other main purpose is to make visible text appear on the redirect page, text that provides information to whomever comes to the page, information about the categorization of the redirect among other things. Rcats are so much more than sorting tools. If they weren't so much more, then we would just still be hard-catting redirects using the [[]]s instead of the {{}}s. Spread the word, rcats are much more than just redirect sorters, they are sources of important information! especially to those editors who possess little or no experience in redirect categorization. P.I. Ellsworth  ed. ^put'r there 06:45, 25 March 2020 (UTC)

P.S. Maybe it would be a good idea here to mention that I almost always refer to the templates as "rcats", which is actually an acronym of sorts for "redirect categories". That's just me. Back in the old days I called them "rcat templates"; however, with age and decrepitude I shortened it to just "rcats". So I'm guilty... sundowners is setting in. P.S. left by P.I. Ellsworth  ed. ^put'r there 07:13, 25 March 2020 (UTC)

• CfD to be consistent with how stub templates are handled. Both are wrappers for a category. They definitely don't belong at RfD since they are only associated with redirects. Alternatively, have stub and rcat templates discussed at TfD like all other templates. — JJMC89 (T·C) 19:15, 22 March 2020 (UTC)
• TfD With stub tagging, the main part of the system is the categorisation, as it helps interested editors to find articles to expand. With redirect tagging, I've always thought the main thing are the templates themselves, which convey useful information to the person viewing the redirect. The categorisation, on the other hand, is incidental (save for few exceptions like Category:Printworthy redirects) and exists just because it's easy to add a line to the template causing the categorisation. Maybe someone like SMcCandlish or Tavix can enlighten me how categories like Category:Redirects from other capitalisations or Category:Redirects from ASCII-only titles are useful in the way ones like Category:India road stubs are. SD0001 (talk) 13:45, 23 March 2020 (UTC)
  • Huh? Categories have different purposes so it's disingenuous to compare two completely separate categories that have different purposes and declare one more useful than the other. The categorization is what is actually being done, the templates simply explain what the category is. -- Tavix ^(talk) 14:12, 23 March 2020 (UTC)
    • I don't think it is an either–or situation (or, "actually" versus "simply"). The rcat templates serve two functions: they categorize redirects and they provide context/explanation for why the redirect exists in a way that is standardized and can be understood by someone who is only casually familiar with redirects. While I tend to agree that categorization is the more important of these, that does not nullify the other function. -- Black Falcon ^(talk) 04:00, 24 March 2020 (UTC)

Evaluating consensus

So, what's the verdict? It looks a lot like "no consensus", but is there something from this discussion that we can apply? According to my count, TfD received a plurality of support (5.67) (6.67) (7.83), followed by RfD (4.67) (5.33) and then CfD (3.67) (4.67) (4.83). If one takes the view that the discussion was specifically about where to discuss rcat templates, then TfD enjoys a narrow majority (8–6) (9–7) (10–8). Of course, whether the rcat template is separable from the rcat category was one of the points of disagreement. Some argued it is not and that the template's sole purpose is to categorize, while others (including me) think it is—e.g., a rcat category can be merged or renamed (at CfD) without impacting the existence, name, or display text of the rcat template.

Venue	Editor(s)	Argument(s)
CfD	JJMC89, SMcCandlish, Tavix	The template is purely a vehicle for applying the category.
RfD	Deryck Chan, Dmehus, MJL, Trialpears, Wugapodes	Editors at RfD are more likely to be familiar with redirects, though perhaps not with categorization and templates.
TfD	Amorymeltzer, Black Falcon, Paine Ellsworth, Pppery, SD0001, Steel1943	Templates should be discussed at TfD.
CfD or TfD	Gonnym, Ivanvector, Mark viking	CfD if the category is being discussed, and TfD if the template is being discussed.
CfD, RfD, or TfD	Davidwr	Discussion should be had at whichever venue makes the most sense, and should be cross-advertised (at WT:REDIRECT or the other venues).

I know this is an imperfect analysis and oversimplifies people's opinions (for example, I belong in the "CfD or TfD" group but responded "TfD" because the original question specifically asked about the rcat template), but I wanted to at least try to reach some sort of an outcome. Thoughts from others on how to move forward would be appreciated. -- Black Falcon ^(talk) 00:49, 15 March 2020 (UTC) — Counts updated on 00:26, 23 March 2020 (UTC). — And again on 01:11, 1 April 2020 (UTC).

​(I participated in the above and a no consensus likely supports my slight preference so take this with a grain of salt but) I agree with no consensus, the discussion particulars makes that clear to me. There's a lot of gray to be considered, even if folks feel one way or another. I think a "no consensus, don't jump down anyone's throat if they do it somewhere other than TfD" would be reasonable. ~ Amory (u • t • c) 10:57, 22 March 2020 (UTC)

Appears to be "no consensus" to me also. I !voted for TfD, because I've always thought that when necessary, it is the rcat templates that should be taken to task. Yet when Mac or someone else takes the maintenance category to CfD, I've never been bothered enough to jump down their throats. It's all the same in the end result, either the cat and rcat are kept, or they're deleted. Only problem has been when a deleter forgets one or the other. Happens sometimes, however somebody has always caught it and dealt with it effectively. P.I. Ellsworth  ed. ^put'r there 16:05, 31 March 2020 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Comparing transclusions

Anyone know a tool to compare transclusions of two templates? For example, if you have two navboxes, determining the extent to which they appear on the same pages? --Bsherr (talk) 20:15, 9 May 2020 (UTC)

WP:PetScan. Usually used for cats, but can be used to do the same for templates. Primefac (talk) 20:17, 9 May 2020 (UTC)

Thanks Primefac. Seems to be timing out on me at the moment, but I look forward to checking it out. --Bsherr (talk) 21:15, 9 May 2020 (UTC)

Special:Search/hastemplate:"Warcraft universe" hastemplate:"Blizzard Entertainment" will give you the intersection. --Izno (talk) 00:07, 10 May 2020 (UTC)

Good point, I forget that the search tool has more than just "insource", "intitle", and "incategory". I've been using PetScan because you can set negative templates (e.g. Template A but not Template B). Primefac (talk) 18:34, 11 May 2020 (UTC)

Which you can do also with Special:Search. :D --Izno (talk) 23:06, 11 May 2020 (UTC)

Nothing like learning new things :-) Primefac (talk) 19:03, 14 May 2020 (UTC)

Edit summaries

Dear fellow contributors, I have been prompted by a couple of users that my edit summeries when trying to he propose nominations to the templates for discussion pages have been inadequate. When trying to provide better edit summaries, I have been informed that they are not good enough. Is this edit summary requirement unique to this location on Wikipedia, and if so why? When and where was this requirement originally discussed and then decided upon? Thanks. PPEMES (talk) 14:06, 27 May 2020 (UTC)

@PPEMES: are you referring to your edits such as this one? "Inadequate" is a bit of an understatement - as you are using no summary at all. The directions for listing TFD, with examples, are on the associated page here, and it doesn't really matter what some other project (say the Belarusian Wikipedia) does. Now, it is unlikely anyone is going to be very very picky about this, and putting "nominated for merge", "list at tfd", or anything that is a bit more helpful for page watchers as your edit summary will generally suffice. — xaosflux ^Talk 14:16, 27 May 2020 (UTC)

@Xaosflux: I didn't know that edit summaries were required also on template pages. I have strived to use "Suggestion" as edit summary on templates for discussion since some users nagged on my talk page about it. Yet, now I found that edit "Suggestion" is inadequate enough to risk a topic block on Wikipedia!

Throughout out my years, I have met with a few mistakes and inadequacies around Wikipedia. Yet, my general attitude is always gratefulness of the time and effort that the contributors offer. Never have the preposterous thought crossed my mind of complaining about anyone's edit summaries, much less threatened them with blocking for that reason! For starters, what right have I to demand that other people are generous with their time and efforts to contribute to Wikipedia - and even less so to demand that they report how they are doing this service to me in edit summeries in the fashion that suits for my personal convenience as a mere observer while they are doing the hard work? That is why I am addressing this page to ask how and when and why this policy was up for policing on this location, if you don't mind? In order to learn which of Wikipedia's five pillars that blocking-grounding policing relies on? PPEMES (talk) 17:38, 27 May 2020 (UTC)

Well, I never said anything about blocking anyone - think this is mostly about how everyone can work together the best? Help:Edit summary has some good tips for what makes a good edit summary. I think it is way to early to think about blocking anyone, but the stretch guideline would probably be the catch-all Wikipedia:Disruptive editing. I hope you can take the feedback as a way to make things better, by improving your ES's when nominating pages for xfd; think about it from the point of view of other people using watchlists: they may not bother to check up on a small edit from an established editor such as yourself, but when the edit is for xfd reasons they may want to participate in the discussion you started and it would help bring them to it. Using WP:TW as Primefac mentioned below is a way to automate that most of that, but it is completely optional. Best regards, — xaosflux ^Talk 17:48, 27 May 2020 (UTC)

Well. To have a local rule that says not providing edit summaries according to special standard equals disprupting editing, I'm curious, do you know where this policy was discussed and decided upon? PPEMES (talk) 17:08, 28 May 2020 (UTC)

PPEMES, you should probably use Twinkle to assist in nominating templates for merging or deletion; it will take care of all of the edit summaries, put things in the proper place, etc. The only time you should really be manually editing a TFD log page is if you're a) !voting on a nomination, or b) combining multiple nominations into one (which, unfortunately, Twinkle cannot do at this time). Primefac (talk) 14:33, 27 May 2020 (UTC)

Infobox Book series

Having, rightly, decided not to merge this (see 27 May 2020 discussion) how do we remove the irritating little template that says we're thinking about such a merger? See the example, top right, here, A History of Monmouthshire from the Coming of the Normans into Wales down to the Present Time. I can't see how to get rid of it. KJP1 (talk) 07:49, 1 June 2020 (UTC)

I don't know why WP:TFDAI isn't linked from WP:TFD, but I'd encourage Knowledgekid87 to read through it (WP:XFDCloser can also make it easier to close discussions). That being said, both templates are protected, so a {{TPER}} would be required had I not seen and responded (and done what is necessary). Primefac (talk) 20:29, 1 June 2020 (UTC)

Appreciated. KJP1 (talk) 20:31, 1 June 2020 (UTC)

@Primefac: The link is at the very top right of the page. Easy to miss. --Bsherr (talk) 03:14, 2 June 2020 (UTC)

Yeah, I see that now, but I've added an explicit section as well. Primefac (talk) 15:52, 2 June 2020 (UTC)

Essay or speedy deletion criteria

Hi all,

We have some really recurrent types of proposals here that almost entirely seem to result in deletion. I want to discuss with people active around here about whether it's worth, and what their thoughts would be, about either making some proposals for speedy deletion criteria, or otherwise codifying some of these in an essay that can be easily referred to.

Things that we see all the time are

1. Topic-specific (I just wonder if we could have some limited duration 'cleanup-type' speedy deletion criteria for some of these):
   • Squad templates for non national teams used once or no times
   • Election result templates used once
   • Train route templates that have been superseded by lua modules and are unused
2. Topic agnostic:
   • Unused subtemplates of templates
   • Unused multiple sandboxes of templates (like /sandbox2 etc.)
   • Templates that are just a reference that are unused
   • Templates that are just a link that are unused

I am fully in favour of having discussions about some templates, however it's clear that there is a limit to how many proposals a day this venue can sustain, because of the fact that the vast majority are very straightforward and repetitive. In my mind it might be better just to find a way to deal more speedily with those ones, so that more thoughtful discussion can occur with the remainder. Looking forward to hearing your thoughts and comments! --Tom (LT) (talk) 04:46, 2 July 2020 (UTC) Ping to PPEMES, Izno, Primefac, TheImaCow, and I do heartily apologise to others I've missed.

The bar at WT:CSD for frequency is pretty high. Some of these also have uncontestability issues, specifically that lack of use is not necessarily a controlling reason to delete. However, I have long desired and fully support the idea of better documentation about general principles for deleting templates. --Bsherr (talk) 05:56, 2 July 2020 (UTC)

Regarding "unused" - a CSD category for that grouping has been shot down at least a dozen times in the last few years.

As far as "rules and guidelines" go, I think the best we can do (in the short-term) is to flesh out WP:TFDOUTCOMES (which I must admit is so far down my priority list that I often forget I created it). Primefac (talk) 16:24, 2 July 2020 (UTC)

(Get back to reading that novel length RFC. *whipcrack* --Izno (talk) 17:03, 2 July 2020 (UTC))

@Primefac didn't realise that exists, but that's where some of the supplementary material should go.

@Primefac and Bsherr. Just wondering about the unused thing. Putting that to the side some of the common nominations (eg for a reference that has been put into a template, or for a link to an article that's put into a template, or for a subtemplate of a template). These are independent reasons for deletion; the fact that they are unused just highlights how useless they are. It doesn't sound like either of you are optimistic at all for passing something at CSD. I'm thinking of proposing two trial proposals - one for the train set (as it's so pointless to have it recurrently here), and one relating to templates that are just a link or reference. Is there a way I could word it to be more likely to pass? --Tom (LT) (talk) 00:44, 3 July 2020 (UTC)

I'll cite our discussion at Wikipedia talk:Criteria for speedy deletion/Archive 72#Proposal to add T4: Unused, and add that, if you could show (1) that the criterion's issue is likely to occur indefinitely (so, of your examples, that probably rules out the train templates, which will eventually be exhausted), (2) that the criterion has super clear boundaries that enable the admin to make a split-second objective determination of whether the criterion is met, (3) that the existence of the page is creating an immediate need for summary deletion, as opposed to allowing the 7 day wait at TfD, like it's causing confusion or presenting a technical issue, and (4) that it arises more than a couple times a week, then I think you stand a chance. Also helpful would be if there is a backlog closing TfDs. Not saying these are any kind of inclusion criteria, just circumstances I think would make a proposal persuasive. --Bsherr (talk) 13:29, 3 July 2020 (UTC)

I agree with Tom. Ignoring the regular "unused" kind, a lot of these, such as election templates being replaced in article, or train routes replaced with the module, or football templates being replaced with its module, are always deleted, usually with no actual discussion. Just seems a waste of time and more importantly, makes finding other templates harder. --Gonnym (talk) 17:12, 2 July 2020 (UTC)

Reason number 5

I propose adding a fifth reason for deleting a template: "The template is currently used, but you believe it should not be used on any pages, because it does not serve the interests of readers or editors." I've seen people object to proposed deletions because they don't fit any of the four reasons, but the reason for deletion was something like:

• A navigational template that is unsuitable, either because it's not scoped well or just doesn't lend itself to an intuitive or helpful organization of articles.
• A "problem tag" like {{cleanup}} that is seldom used or overused or badly used or which the nominator thinks shouldn't be applied to articles.

It's a bit odd to have to find a particular guideline that is violated by a template, rather than just being able to say that using it is worse than not using it, for some concrete editorial reason. That's generally what editing means. -- Beland (talk) 20:04, 8 July 2020 (UTC)

Your rationale/examples sound like mixtures of #2 and #3 (leaning obviously more towards #2). Primefac (talk) 21:30, 8 July 2020 (UTC)

This might be related to Beland's attempt to delete {{rn}} which is used at Roman numerals (example: one is I versus one is I). The correct procedure would be to make a proposal at the article's talk that the template should not be used. After gaining consensus, possibly with an RfC, the template could be removed from articles which would make deletion possible. Johnuniq (talk) 01:18, 9 July 2020 (UTC)

should I speedy delete this template?

Hey I don't know where to talk about this but I have an edit conflict regarding a navbox. Template: Great Lakes Megalopolis. Apparently at least two editors want it gone because I placed it on Missouri cities etc. I am basing it on a source and I don't really want it gone but it seems useless for now. A major discussion on it will be Talk:Detroit. But I do seek more admins and highly knowledgeable editors on it. I should note there is two navboxes like it. One of them is not my creation so I can't speedy delete that one. Jhenderson ⁷⁷⁷ 23:21, 31 July 2020 (UTC)

I'm not going to tell you one way or the other, but if you created the page and there have been no significant edits by other users then you are more than welcome to G7 the template as a user request. Primefac (talk) 23:59, 31 July 2020 (UTC)

Ok it's on TFD right now. So at least the edit conflicters are doing it right this time now besides removing it on the article's placement. :) Jhenderson ⁷⁷⁷ 00:05, 1 August 2020 (UTC)

Holding cell sections

Originally mentioned at Wikipedia talk:XFDcloser/Archive 4#TfD categories

I've long been thinking that separating mergers into template types (Infoboxes, navigational templates, link templates, meta, others) would be a better way to organize the holding cells than the current by topic system. I can update XFDcloser (and sync with an ER). What do you all think? --Trialpears (talk) 18:42, 1 August 2020 (UTC)

wrt the original idea I posted, I was more getting at the odd temporary category rather than dozens of permanent ones, but admittedly that idea may also suffer from the same issues. If we keep the current structure, perhaps it's worth adding a "science" category at least. 3 of our main page portals are science-related, and "science" is broad enough to chuck stuff like medicine into as well. I can't remember the link for the graph of mainspace articles on Wikipedia by topic, but I think we had a fair number of science articles on it. Course, this is moot if we change to a type split. For the suggestion here, I think I'm a fan; categorising by template type is much more useful to people implementing TfDs than categorising by topic imo. ProcrastinatingReader (talk) 20:47, 1 August 2020 (UTC)

I do suppose if we were to add one more category, it would be "science". Simple change all around (one extra section, one line of new code). Primefac (talk) 20:56, 1 August 2020 (UTC)

So basically easy and hard merges? :) --Izno (talk) 21:54, 1 August 2020 (UTC)

Hah! Primefac (talk) 23:19, 1 August 2020 (UTC)

I can't tell if that's sarcasm because you've implemented supposedly easy merges that made you want to murder... whatever your choice of murder target is, or if it's a bald laugh because my joke was so spot-on. ;) --Izno (talk) 02:01, 5 August 2020 (UTC)

I like this idea. My sense is that implementers look for templates that are within their ability to merge before considering whether it is a subject matter they like. So, actually, Izno's joke might be spot on. --Bsherr (talk) 01:32, 5 August 2020 (UTC)

Looks like a rough consensus to categorize per template type. I've implemented it at User:Trialpears/sandbox/XFDcloser.js and tested it here where it placed my test in the proper holding cell section. Pinging Evad37 for syncing of the gadget. I'll take care of fixing the holding cell as soon as XfDcloser is updated. --Trialpears (talk) 17:33, 7 August 2020 (UTC)

@Trialpears: Gadget updated, thanks for taking care of the coding - Evad37 [talk] 01:28, 8 August 2020 (UTC)

Closer and Implementor

The instructions currently says nothing on the rather important question: If you decide to close a discussion, do you have to implement it?

I'm guessing the expectation is yes, in other words, if you're not prepared to implement the delete/merge/whatever, don't close it. But the instructions doesn't say either way!

Is this just an unspoken rule/assumption that "everybody" abides by, or is it really that you can close an xfD without implementing it - not even taking the steps to put it in a holding cell? (I tried looking through the archives, and it seems that back when non-admin closures were discussed, one argument to allow it was that non-admins could still implement outcomes, implying that no, you shouldn't close without implementing)

Either way, I feel the answer needs to be clearly explained on the page. Otherwise we can't tell people they forgot to implement after closing. CapnZapp (talk) 09:43, 4 August 2020 (UTC)

Just putting it in the holding cell is very common and an accepted practice. I think we should encourage people to implement it, especially if it's easy to do, but it shouldn't be required. If you had to implement it as well it could take ages before some discussions get closed and it's quite common that the nominator wish to implement the close. --Trialpears (talk) 10:02, 4 August 2020 (UTC)

So what you're saying is that the instructions should stipulate two stages of a three-stage rocket? Okay, I'll phrase that. (The reason I'm following these talk posts with bold action is that in my experience, people can't be bothered to discuss unless prompted by actual change the disagree with). CapnZapp (talk) 13:04, 4 August 2020 (UTC)

While I re-type my edit-conflicted message, don't just go ahead edit that page again - you've been reverted, so now it's time to stop being bold and discuss the issue. Primefac (talk) 13:06, 4 August 2020 (UTC)

(edit conflict) Because TFD has a non-admin closure exception (i.e. it's perfectly acceptable for non-admins to close the discussions, even as "delete") there is no expectation that the implementation has to be performed by the closer. I think just about every "regular" closer frequently lists things at the holding cell, either because they do not have the time, energy, inclination, or ability to perform the task that is required of the close. Hell, even the admins do it. Unlike other XFDs where the outcome is essentially "keep/do nothing" or "delete", template closures can result in rather labour-intensive follow-up, which isn't always possible at the time of closing. Primefac (talk) 13:07, 4 August 2020 (UTC)

Just to note I didn't see this until just now. Cheers CapnZapp (talk) 13:15, 4 August 2020 (UTC)

Just to add, sometimes people who implement TfDs wouldn't have closed those particular TfDs, so this requirement has that issue. Most the TfDs I've implemented I wouldn't have closed personally, either due to being a participant or lack of relevant experience. The roles of closing vs implementing TfDs certainly aren't the same. ProcrastinatingReader (talk) 13:19, 4 August 2020 (UTC)

No objections. I just want the instructions to reflect these insights. CapnZapp (talk) 16:20, 4 August 2020 (UTC)

In lieu of any discussion, do you have a proposal Primefac? (I assume you didn't revert because you actually prefer the status quo.) At the current rate, we're getting nowhere. CapnZapp (talk) 18:20, 8 August 2020 (UTC)

Do we need to be going somewhere? I see no reason why this proposed guideline is a good idea, as, for instance, I regularly implement my own TfDs. The job of a closer is to determine if consensus for a proposed course of action exists, which is separate from the technical skill required to implement that action. I expect the likely result of this would be that TfDs that propose difficult-to-do results never get closed, which is clearly not an improvement. * Pppery * _{it has begun...} 20:23, 8 August 2020 (UTC)

I concur. These are closing instructions, not implementation instructions. Primefac (talk) 23:31, 8 August 2020 (UTC)

Huh? Are you discussing some other page than this: Wikipedia:Templates for discussion/Closing instructions?

I see I didn't actually link to the page I'm talking about. Maybe there's closing instructions elsewhere. Anyway, on the page linked there's four sections. First "Close", then "Implement the Close". If they're not all part of "Closing Instructions" maybe that's the disconnect here? CapnZapp (talk) 19:55, 9 August 2020 (UTC)

Let's be painfully clear: I go from Wikipedia:Templates for discussion#Closing discussion to Wikipedia:Templates for discussion/Closing instructions and I find zero guidance on who performs which steps, if all steps are required or if I can pick just some. Hence my initial question: If you decide to close a discussion, do you have to implement it? Now you're telling me maybe not. That in itself is fine. But it shows the instructions aren't clear or complete enough. I have no intention of actually changing procedure here. Just to have our instructions actually straighten out the very first question mark I had when I got here. Thanks CapnZapp (talk) 20:00, 9 August 2020 (UTC)

Based on your latest explanation, I believe we're talking about two different things. We (or at least I) are talking about "closing the discussion", while you are talking about "implementing" the result of that discussion. This section, which is the only section that would involve any sort of "implementation", says that if the discussion is closed as merge/review/etc it should be listed at TFD/H. This is as much information as needs stating, because anything after that (i.e. the "implementation of the result") is handled by a different process. A similar example would be using {{Afd-merge to}} to indicate that an AFD has resulted in "merge"; the closer is not required to actually perform the merge themselves, just close the discussion. Primefac (talk) 20:09, 9 August 2020 (UTC)

I'm looking at Wikipedia:Templates for discussion#Closing discussion. It says Administrators should read the closing instructions before closing a nomination. Again at Wikipedia:Templates for discussion#Completed discussions, specifically the "Closing discussions" step, it says The closing procedures are outlined at Wikipedia:Templates for discussion/Closing instructions. If only PART of that page is meant to be followed during this step, and that some parts aren't actually part of the closing stage, that is not at all clear. Why is even the implementation instructions on that page? The page is called "Closing instructions", so it's natural to assume it contains the, wait for it, closing instructions...! I call for the instructions to make the answer to If you decide to close a discussion, do you have to implement it? simple and clear. What steps are actually part of "closing"? How, when and by whom does the process move from the closing stage to the implementing stage? I am telling you that unless you're an experienced TfD closer, for which all of this might be crystal clear, it is actually incomplete and confusing. Cheers CapnZapp (talk) 10:41, 11 August 2020 (UTC)

To be fair, I don't think this is a common misconception. The closing instructions already say to list it at the holding cell. Someone who doesn't know that they don't need to implement it themselves probably doesn't have enough experience in TfD to be closing discussions anyway. I personally don't see the issue here. ProcrastinatingReader (talk) 12:41, 11 August 2020 (UTC)

Well, we don't write your guidelines only for the people that already know what they say. Either you understand my concern, or I'll help explain - if you ask. CapnZapp (talk) 19:54, 11 August 2020 (UTC)

I have removed any instance of the word "implement" on the closing instructions in an effort to hopefully clear up this misconception about what that word actually means. CapnZapp, is it any clearer now? Primefac (talk) 12:52, 11 August 2020 (UTC)

Thanks, but you still don't seem to get my point. I see a list of steps to be taken. There are zero indication you shouldn't do all of them. Now, you guys says only some of the steps need to be taken at the point of closing. Okay fine, but then please make the page explain the details: is it okay to do a close without doing the "post-close" actions? If so, under what conditions? Look at the edits I made (now reverted) for examples of language that actually attempts to fix the issue, which is that a reader needs to be able to understand the closing procedure just by reading the instructions; with no details "that you just know". CapnZapp (talk) 19:54, 11 August 2020 (UTC)

There are zero indication you shouldn't do all of them. Right, because you're supposed to do all of them. I've further condensed the instructions to make that explicit. Primefac (talk) 20:15, 11 August 2020 (UTC)

Thank you. Now we're getting to the issue at hand. @Trialpears: How does this jive with your initial reply: Just putting it in the holding cell is very common and an accepted practice. I think we should encourage people to implement it, especially if it's easy to do, but it shouldn't be required. If you had to implement it as well it could take ages before some discussions get closed and it's quite common that the nominator wish to implement the close. CapnZapp (talk) 11:14, 13 August 2020 (UTC)

Looks to be consistent with current norms, so no complaints from me! --Trialpears (talk) 08:49, 14 August 2020 (UTC)

Help with removing a template

Hi all, hope that you're well. I was hoping there might be an automated way to remove {{Inflammation}} from these articles:

markup

| group4 = Specific<br/>locations | list4 = {{Navbox|child | group1style = background:LemonChiffon; | group1 = [[nervous system|Nervous]] | list1 = * ''CNS'' ** [[Encephalitis]] ** [[Myelitis]] * [[Meningitis]] ** [[Arachnoiditis]] * ''PNS'' ** [[Peripheral neuropathy|Neuritis]] * ''eye'' ** [[Dacryoadenitis]] ** [[Scleritis]] ** [[Episcleritis]] ** [[Keratitis]] ** [[Retinitis]] ** [[Chorioretinitis]] ** [[Blepharitis]] ** [[Conjunctivitis]] ** [[Uveitis]] * ''ear'' ** [[Otitis externa]] ** [[Otitis media]] ** [[Labyrinthitis]] ** [[Mastoiditis]] | group2style = background:MistyRose; | group2 = [[cardiovascular system|Cardiovascular]] | list2 = * [[Carditis]] ** [[Endocarditis]] ** [[Myocarditis]] ** [[Pericarditis]] * [[Vasculitis]] ** [[Arteritis]] ** [[Phlebitis]] ** [[Capillaritis]] | group3style = background:MistyRose; | group3 = [[respiratory system|Respiratory]] | list3 = * ''upper'' ** [[Sinusitis]] ** [[Rhinitis]] ** [[Pharyngitis]] ** [[Laryngitis]] * ''lower'' ** [[Tracheitis]] ** [[Bronchitis]] ** [[Bronchiolitis]] ** [[Pneumonitis]] ** [[Pleurisy|Pleuritis]] * [[Mediastinitis]] | group4style = background:#fd6; | group4 = [[Digestion|Digestive]] | list4 = {{Navbox|child | groupstyle = background:#fd6; | group1 = {{nobold|''mouth''}} | list1 = * [[Stomatitis]] * [[Gingivitis]] * [[Gingivostomatitis]] * [[Glossitis]] * [[Tonsillitis]] * [[Sialadenitis]]/[[Parotitis]] * [[Cheilitis]] * [[Pulpitis]] * [[Gnathitis]] | group2 = {{nobold|''tract''}} | list2 = * [[Esophagitis]] * [[Gastritis]] * [[Gastroenteritis]] * [[Enteritis]] * [[Colitis]] * [[Enterocolitis]] * [[Duodenitis]] * [[Ileitis]] * [[Caecitis]] * [[Appendicitis]] * [[Proctitis]] | group3 = {{nobold|''accessory''}} | list3 = * [[Hepatitis]] * [[Ascending cholangitis]] * [[Cholecystitis]] * [[Pancreatitis]] * [[Peritonitis]] }} | group5style = background:Linen; | group5 = [[integumentary system|Integumentary]] | list5 = * [[Dermatitis]] ** [[Folliculitis]] * [[Cellulitis]] * [[Hidradenitis]] | group6style = background:WhiteSmoke; | group6 = [[Human musculoskeletal system|Musculoskeletal]] | list6 = * [[Arthritis]] * [[Dermatomyositis]] * ''soft tissue'' ** [[Myositis]] ** [[Synovitis]]/[[Tenosynovitis]] ** [[Bursitis]] ** [[Enthesitis]] ** [[Fasciitis]] ** [[Capsulitis]] ** [[Epicondylitis]] ** [[Tendinitis]] ** [[Panniculitis]] * [[Osteochondritis]]: [[Osteitis]]/[[Osteomyelitis]] ** [[Spondylitis]] ** [[Periostitis]] * [[Chondritis]] | group7style = background:#BBEEBB; | group7 = [[urinary system|Urinary]] | list7 = * [[Nephritis]] ** [[Glomerulonephritis]] ** [[Pyelonephritis]] * [[Ureteritis]] * [[Cystitis]] * [[Urethritis]] | group8style = background:#BBEEBB; | group8 = [[reproductive system|Reproductive]] | list8 = {{Navbox|child | groupstyle = background:#BBEEBB; | group1 = {{nobold|''female''}} | list1 = * [[Oophoritis]] * [[Salpingitis]] * [[Endometritis]] * [[Parametritis]] * [[Cervicitis]] * [[Vaginitis]] * [[Vulvitis]] * [[Mastitis]] | group2 = {{nobold|''male''}} | list2 = * [[Orchitis]] * [[Epididymitis]] * [[Prostatitis]] * [[Seminal vesiculitis]] * [[Balanitis]] * [[Posthitis]] * [[Balanoposthitis]] | group3 = {{nobold|''pregnancy/newborn''}} | list3 = * [[Chorioamnionitis]] * [[Funisitis]] * [[Omphalitis]] }} | group9 = [[endocrine system|Endocrine]] | list9 = * [[Insulitis]] * [[Hypophysitis]] * [[Thyroiditis]] * [[Parathyroiditis]] * [[Adrenalitis]] | group10style = background-color: LightGreen | group10 = [[Lymphatic system|Lymphatic]] | list10 = * [[Lymphangitis]] * [[Lymphadenopathy|Lymphadenitis]]

Following a closure by Bsherr here Special:Diff/prev/973741037. Fingers crossed, --Tom (LT) (talk) 00:07, 19 August 2020 (UTC)

Yup. So the goal is to remove the template from the pages linked in the bottom half of the navbox, which you are removing. So, we can take the template and throw it into a sandbox, then delete the top half of the navbox, which we are keeping, so what's left is the part we are getting rid of. Then we can use AWB. We make a list using as our source "Links on page" from our sandbox page. Now we have a list of all the pages we want to rid of transclusions of the template. Set your find and replace to nullify the transclusions of the template, and run! --Bsherr (talk) 00:21, 19 August 2020 (UTC)

Thanks, very helpful! Will get to this on the weekend, hopefully. --Tom (LT) (talk) 00:23, 19 August 2020 (UTC)

 Done. Primefac (talk) 00:26, 19 August 2020 (UTC)

That Primefac is fast! --Bsherr (talk) 03:23, 19 August 2020 (UTC)

Wow, that was very speedy! Thanks Primefac! --Tom (LT) (talk) 06:49, 19 August 2020 (UTC)

No problem. Of course, it helps that a) I was around, and b) I have a bot that can deal with the hundred-odd pages that needed it. Primefac (talk) 00:37, 20 August 2020 (UTC)

"rmv implied statements"

Special:Diff/973977999

That's not good enough as an undo reason, User:Primefac. What do you mean? Address each change individually. Thanks CapnZapp (talk) 11:20, 20 August 2020 (UTC)

If you insist... italics are what I removed/reverted:

• Determine whether or not a "rough consensus" to delete (or not) has been reached. If a consensus to delete has not been reached then it has not been reached; i.e. if the answer "is there a rough consensus to delete?" is "no" then the "(or not)" has been met without it needed to be stated explicitly.
• See Deletion guidelines for administrators for more, in particular guidelines on what constitutes "rough consensus". I suppose this could be reworded to "See also Deletion..." but the name of the page gives a pretty good indicator of what will be there.
• If after seven days there is no consensus or little participation an editor may, at their discretion, choose to relist the discussion, thereby closing the old one, and starting a new one. If you decide to relist: That's just wordy and unnecessary.

All of what I've removed is "implied" by the statements that precede or succeed them, which means I can use one edit summary for all of the removed statements. We're trying to go with a philosophy of "less is more" with guidelines. Don't use seven words when four will do. I get that you're wanting to improve the guide, and I appreciate that, but "more words" doesn't always equal "better". Primefac (talk) 15:09, 20 August 2020 (UTC)

You did not mention my addition of an anchor, so your undo again breaks the in page link. In your haste to undo my work with minimal effort you probably didn't even see it. The "(or not)" is copied directly from Deletion guidelines for administrators. It refers to the result, that can be delete, but can also be something else. It does not mean the consensus has not been reached. (Feel free to improve, but undoing is not constructive progress!). If you suppose something, please don't blanket undo - it comes off as incredibly dismissive. I wanted to cue the reader in to why he or she is sent to deletion instructions even when attempting a keep or merge etc. I disagree the changed phrasing is unnecessary, after all I made the edit. But in this context "wordy and unnecessary" is not "implied statements", so again, consider stopping wholesale undo's with minimal edit comments. My rationale was to make it clearer that any editor can relist a discussion, not just some special kind of "closing editor". Relisting is not listed under Closing Instructions, so the distinction feels useful. You're not closing the discussion, you're relisting it. That relisting means following some of the Closing steps doesn't change this. Again, feel free to suggest improvements. But if your approach to less is more is terse reversion, I'd rather ask you to leave the page alone and wait for more verbose editors to offer suggestions.... Regards CapnZapp (talk) 19:08, 20 August 2020 (UTC)

It would be wise for future proposed changes to have consensus before implementation to avoid this sort of situation. Primefac (talk) 19:38, 20 August 2020 (UTC)

I made bold edits, you reverted me. But you did it with the least effort possible, missing half the reasons why I made changes. I also note that when you were called out on this unfriendly behavior, you spent maybe 90% of your total effort so far, not on the article, but justifying your shitty behavior here on the talk page! Again you dismiss me with phrases like "We're trying to go with a philosophy of "less is more" with guidelines." No, Primefac, you might be trying to do that. For me, that phrase basically only means "I didn't like your contributions so I shot them down without having to explain myself". Do you realize "reverted because the number of words increased" is a really unhelpful explanation on how to do better?

Then you reverted me again, and now you aren't even bothering to engage at all. No, I don't need your permission to make changes. Explain to me how your engagement is constructive and not gatekeepery. Now please finally realize that with reversion comes responsibility to actually constructively explain what you like and what you don't like about the reverted addition (if you don't simply improve them further on the page). If you can't do that, maybe it's time to leave the additions in for a week or so, to give other editors a shot at engaging (in a much more constructive way than you can be bothered with). Best regards, CapnZapp (talk) 08:06, 21 August 2020 (UTC)

I'm not really sure what you want here; I think the page is fine so I don't need to keep editing the article. That means that of course I'm going to [justify my] shitty behavior here on the talk page.

So let's discuss it with others; you've made your point, I've made mine, and neither one of us is finding the other's argument convincing. My last post was to imply that rather than "I'm going to change it again and then discuss" we should discuss changing the language first. I'm not gatekeeping (hell, you've made some very good points that have resulted in changes like this), just doing what I feel makes the most sense. Primefac (talk) 13:49, 21 August 2020 (UTC)

"I think it was fine" is a poor argument - why is it fine? It doesn't leave me anything to work with. You clearly know I find the previous version lacking. If you want to argue why my concerns are adequately addressed by the previous version, you are free to do so. But so far, you have only provided arguments once, you did not do so voluntarily or friendly, and you missed half my improvements. So since you aren't sure what I want, here's what I want:

* Why did you revert me clarifying "(or not)" now that you know the real reason?

* Consensus is linked, but arguably "rough consensus" is the important term here. Explaining to the reader what he should look for in the linked guidelines seems relevant. Why do you not agree?

* Relisting isn't closing. Read the instructions and you'll see the difference (hint: Relisting is now its own section!) Why did you think "rmv implied statements" would convince me to stick with the previous version?

Let me just say having to drag it out of you like this is testing my patience. You should reconsider your approach to Wikipedia if you truly think it is okay to spend two seconds just reverting somebody else's hard work, and then feign ignorance, repeatedly forcing me to drag answers out of you! Either don't spend the energy Primefac - and stand aside without interfering, or engage on the issue by constructively working with me, not against me! CapnZapp (talk) 10:20, 22 August 2020 (UTC)

Also, and this is important, statements such as It would be wise for future proposed changes to have consensus before implementation to avoid this sort of situation and So let's discuss it with others are 'disingenuous. If nobody else has a problem with my improvements, they respond by... doing nothing. Silence is consensus. By first reverting, and then asking people to discuss, you engineer the situation where people with no strong objections appear to agree with you. That does not fly. You are the only one objecting, so you need to be the one spending time on talk arguing for your position. If you want to give the floor to others, first stop reverting my improvements, then let some time pass to see if anyone engages! CapnZapp (talk) 10:26, 22 August 2020 (UTC)

Thank you Pppery for fixing the anchor, but really your edit comment kinda misses the woods for all the trees. It's not as if the matter is resolved - we're at the stage where my changes have been reverted wholesale and I'm waiting for Primefac to explain what compromise phrasing he suggests to move us forward. CapnZapp (talk) 08:13, 21 August 2020 (UTC)

My edit summary does not miss anything. I said, correctly, that there's been too much drama over the entirely uncontroversial addition of an anchor. * Pppery * _{it has begun...} 14:20, 21 August 2020 (UTC)

I've reviewed all sixteen links and redirects to the page to confirm, and the section link on this page is the sole link to the anchor. Can we just change the section link to use the name of the section? That would be preferable for clarity, anyway. Are there other changes we need to discuss? --Bsherr (talk) 22:05, 21 August 2020 (UTC)

Nobody made any drama over the anchor addition, Pppery. The drama has never been about the anchor addition. CapnZapp (talk) 09:50, 22 August 2020 (UTC)

Bsherr: you are free to change the link, the section title or both. But update, don't remove, the anchor - its function is to safeguard the article from breaking when inevitably a future editor changes one but not the other. Cheers CapnZapp (talk) 09:50, 22 August 2020 (UTC)

Because the section link should always be the name of the section, it would be better to put in a code comment at the section heading identifying the existence of the section link below and directing it to be updated if the section heading is changed. May I do that instead of the anchor? --Bsherr (talk) 10:42, 24 August 2020 (UTC)

I think the point here is that it used to just be called "close". In theory, this means that any old links pointing to #Close wouldn't go to the correct section any more, hence the {{anchor}}. Primefac (talk) 14:15, 24 August 2020 (UTC)

Indeed. As I said above, I checked them all, and none of them actually do. --Bsherr (talk) 17:03, 24 August 2020 (UTC)

Makes sense, wouldn't figure there would be that many places even linking to WP:TFDCI other than folks using the shortcuts. Primefac (talk) 18:47, 24 August 2020 (UTC)

Template renames

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

I think template renames belong at WP:TfD. Naming conventions (the obsession of RM regulars) do not apply to templates. Templates are technical, and changes can have wider impact, and the expertise for this can be best found at WP:TfD. The instruction at the top of the page should be reversed. --SmokeyJoe (talk) 11:09, 6 September 2020 (UTC)

The instruction was added 4 February 2015 here by Squiver (talk · contribs), a SOCK of Sardanaphalus (talk · contribs). --SmokeyJoe (talk) 11:14, 6 September 2020 (UTC)

I don't see any discussion on this question in the archives. --SmokeyJoe (talk) 11:24, 6 September 2020 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Clarification on closing instructions

Two points on the closing guidelines I'd like to clear up, following discussion:

1. The case for attribution, following a recent TfD. I see in the archives a couple of discussions on attribution, but no clear consensus on how attribution should be done consistently for all TfD closures, particularly in subst+delete cases. I would note that generally we do not provide attribution in such cases at present, but that seems to be more an oversight than deliberate policy? I think turning into a redirect and tagging with {{Attribution history}} works for many cases, but where a template has multiple usages that were substituted, it's not really clear what the "target page" is when preserving attribution (in such cases, perhaps the edit summary of subst could point to the preserved redirect)?
2. Are non-admin TfD closures subject to refunding at WP:REFUND, or should they always go to WP:DRV?

ProcrastinatingReader (talk) 13:49, 7 September 2020 (UTC)

To answer the second question first, a TFD closure should almost never go to REFUND unless the discussion was closed as a soft delete. Despite using "G6" i.e. "uncontroversial" as the delete reason, the closer needs to be contacted and either the discussion re-opened/relisted or sent to DRV. Back in my pre-admin days, there were quite a few templates that I asked for to be undeleted so that the discussion could be relisted.

As to the first question, it's never really been discussed. I've probably performed all permutations, from saying nothing but "substing template" to moving the template to a subpage of the article's talk space, but until recently (one or two TFDs in the last month come to mind) no one has ever said anything about what I (or any other TFD-involved editor) was doing. Primefac (talk) 14:01, 7 September 2020 (UTC)

To respond to second para (first question), it looks that way generally too. I can't see much consistency in how anybody applies attribution in these cases. I suppose with templates it's trickier because, unlike articles where content goes A -> B, templates go A -> B,C,D,E,[...]. One initial thought I have is:

• In one-usage subst+delete cases: do what you did with TfD Instructions (redirect + my tag of {{Attribution history}}, or a template variant of this, for purpose of categorisation).
• In multiple usage subst+delete cases: blank and replace with {{Attribution history}} with no redirect (as no target would be obvious).
• In both cases, move template to a subpage of some prefix (eg Template:Preserved/TfD instructions) to stop the main template namespace getting polluted with blanked templates.
• Have the subst edit summary mention this archived page to serve as attribution (e.g. "Substitution of Template:TfD instructions following TfD. See for attribution: Template:Preserved/TfD instructions")

ProcrastinatingReader (talk) 14:11, 7 September 2020 (UTC)

I can't imagine editors here could have deliberately decided to violate Wikipedia's license. Probably this was not something they have been conditioned to pay attention to, and that's likely been made easier by the fact that many templates contain too little content to be easily recognised as subject to copyright. There's a small paragraph about "subst and delete" at Wikipedia:Templates for discussion#Discussion, and sure enough it mentions the issue, but I think it's better if all this is unpacked into a page of its own. I've had an initial stab at it with Wikipedia:Substitute and delete. It's got a brief intro and a little section on considerations when deciding whether to delete. You're welcome to expand and modify it: it could definitely do with some practical advice on implementing "subst and delete" closures, and probably some guidance on when this outcome is appropriate in the first place. Oh, and obviously, any process for preserving histories that is agreed to in this discussion can be added there. – Uanfala (talk) 19:25, 7 September 2020 (UTC)

Adding one specific point: if a redirect is preserved because of its history, then the common way of marking this is with {{R from merge}}. I'm not quite sure what niche is occupied by {{Attribution history}}, it appears to be used mainly on talk pages and as far as I can see it duplicates the more commonly used {{Copied}}. – Uanfala (talk) 20:00, 7 September 2020 (UTC)

Not saying there's a violation of Wikipedia's license, just that the closing instructions are unclear & there's no consistent practice on the matter. I personally haven't paid that much attention to it, either. Ideally (hopefully) this section can come up with a general practice. I think any considerations on this can just be added as a section into the closing instructions. Would like to hear what experienced editors who have implemented TfDs for years think is a good way to consistently address the issue, whilst not polluting the namespace or something. ProcrastinatingReader (talk) 22:33, 7 September 2020 (UTC)

Following up, what do we think would be a good practice to create on issue (1)? Or thoughts on my suggestion above, as a starter? ProcrastinatingReader (talk) 15:17, 27 September 2020 (UTC)

XFDcloser proposals

There's some proposals on the XFDcloser talk page regarding non-admin soft deletes and holding cell formatting; please comment at WT:XFDC § Soft deletion at TfD and WT:XFDC § TfD merge to holding cell - Evad37 [talk] 23:46, 5 October 2020 (UTC)

Twinkle feature request update

Hi all, having used Twinkle quite a lot for my own template editing and seeing Pigsonthewing's opera proposals recently (which I hope we can respectfully disagree on), it does occur to me it would be quite useful to have the option on Twinkle to be able to set a defined link for a discussion about a group of templates, rather than having Twinkle list the discussions piecemeal. I do recognise piecemeal discussion this is often done intentionally but at the moment there isn't an option that lets you group things.

I think as an optional feature this would be really useful for us here.

I've requested this proposal on Twinkle - please feel free to comment - here: Wikipedia_talk:Twinkle#Request_for_custom_template_deletion_name. --Tom (LT) (talk) 23:50, 8 October 2020 (UTC)

Small template question - links to / from template checker

Hi all, small question here - I remember someone mentioned there being a tool which outputs articles which there is a mismatch between transcluding the template and being linked on the template (ie. which articles are linked from but don't include the template, and which articles link to the template but don't include it). I am sure there was a tool that printed a list, but I just can't find where that discussion was, so I have lost the link to the tool. Does anyone have the link? --Tom (LT) (talk) 09:15, 15 October 2020 (UTC)

https://templatetransclusioncheck.toolforge.org/index.php?lang=en&name= It would probably be useful to put it somewhere (maybe TFDH?) but I'll have to think about that. Primefac (talk) 11:59, 15 October 2020 (UTC)

Thanks :)! --Tom (LT) (talk) 23:48, 15 October 2020 (UTC)

Non-admin close

Is the non-admin close at Wikipedia:Templates for discussion/Log/2020 October 22#Template:RFArcasenav a valid close? Is there a guideline or policy which states that a set of templates are untouchable? If so, I'd very much like to see that exception. --Gonnym (talk) 16:29, 22 October 2020 (UTC)

Okay, a lot to unpack in your statement, in the close made by Cthomas3, and in the nomination itself. I see the rationale behind AGK's statement and the close; this is an ArbCom-specific template, and whether it's used or not is mostly up to them to decide. I've been seeing a lot of these "cart before the horse" nominations lately, wherein someone tries to get rid of the underlying template without having discussed the substance of the template beforehand (examples being AFD hatting templates, blocking policies, and even rcat templates among others).

Were the clerks contacted about this template? Doesn't appear to be the case. Should they have been contacted? Probably. Do they likely have a reasonable authority to decide which templates they use, deprecate, and delete? Kinda.

To answer the initial question, I think because of this template and (for lack of a better term) the BEFORE/discussion with the clerks did not happen beforehand, it's a reasonable close. There isn't a guideline that says if a template (or set of templates) is verboten for deletion, but I should hope one would give serious thought before nominating a set of templates from one of the most bureaucratic groups on Wikipedia. Primefac (talk) 17:05, 22 October 2020 (UTC)

Greetings, Gonnym, and thank you for asking the question, and thank you Primefac for chiming in. No, I don't believe there are templates that are untouchable or off-limits for discussion. The reason I closed this discussion wasn't to quash it, it was to use this as a catalyst to make a decision among the clerks that has come up before a few times. We've periodically kicked around some ideas for changing how casenav fundamentally works, but there was never any urgency to it. However, since the subject of one of the templates has come up, it now makes a lot of sense to actually decide what we want to do before anyone takes on a great deal of effort to fix something that we plan to make wholesale changes to anyway. I hope that helps explain my actions. CThomas³ (talk) 17:32, 22 October 2020 (UTC)

Since I suspect you're looking for a particular policy reference, Gonnym, the policy authority stems from Wikipedia:Arbitration/Policy § Procedures and roles ("The clerks' functions include the administration of arbitration cases and management of all the Committee's pages and subpages[...]."). Arbitration pages aren't "untouchable", but the arbitration policy provides that their management is in the hands of the clerk team. Best, Kevin (aka L235 · t · c) 07:33, 23 October 2020 (UTC)

"entirely too wordy. grammar and sentence structure is fine"

"Too wordy" is sweeping and non-specific. That is not constructive, since it leaves little to build further improvements on. I would not have made the edit if I thought everything was already top notch. What is your suggestion? Please propose an alternative that acknowledges my goal without falling foul of yours, or in other words - cooperate. Just reverting is not cooperative.

"grammar and sentence structure is fine":

The sentence "Determine whether or not a rough consensus to delete has been reached" means editors are instructed to proceed only if consensus on delete has been reached. This is incorrect. Your reply reads as if you either blow off my concern or don't understand it, yet you take it upon yourself to revert the change!

This reply also totally ignores the difference between consensus and rough consensus which I attempt to highlight. Two concepts, defined differently, at different locations. Understand not everybody has mastered this page, as you might have. My suggestions actually help newcomers to understand the process described here.

Finally, your last edit was technically not a revert. And yet, somehow it completely erases my efforts... making only a non-substantial change in phrase. When you relist what about step one isn't starting a new discussion? What about step two isn't closing the old one? Please explain exactly what's "technically incorrect" here?

More in general, Primefac, please respect when editors make an effort by at least making a similar effort in your responses! So far you are the only editor opposing my changes, and so far you have been less than forthcoming. Step up your game or step out of the way! Thanks. CapnZapp (talk) 11:02, 11 October 2020 (UTC)

Finally, your last edit was technically not a revert. And yet, somehow it completely erases my efforts... making only a non-substantial change in phrase. When you relist what about step one isn't starting a new discussion? What about step two isn't closing the old one? Please explain exactly what's "technically incorrect" here? The discussion is not closed. The whole point of relisting is to keep the discussion going. It is, for technical purposes, just moved (to the new dated page, hence preventing a fork). Saying the current discussion is being closed and a new one is started is perhaps in purely technical terms a correct description, but it's not an accurate one, and so is confusing.

Regarding grammar on "or not" I feel the current wording seems more grammatically correct.

For info on the procedures I personally think the wiki-wide policies are more helpful, combined with just observing TfD for a while. The TfD closing instructions are mostly technical advice, much of it made moot day-to-day by XFDCloser. ProcrastinatingReader (talk) 16:24, 11 October 2020 (UTC)

Thank you for your reasoned reply, Procrastination. I'll continue the discussion below. CapnZapp (talk) 19:38, 13 October 2020 (UTC)

I'm not going to write a treatise for every edit summary I make; "too wordy" means exactly that - you trebled the number of words in that sentence without changing the meaning. I will admit I realized after I saved that I should have said "...structure in current text is fine", but I wasn't about to make a null edit to correct it. As PR says above, your interpretation of the consensus statement is incorrect.

Additionally, as I have said multiple times after the multiple times you have made unnecessary (but I will admit, good faith) changes to these instructions, if I don't propose an alternative about how to improve the wording it's because I do not feel that there is an alternative (i.e. the current wording is acceptable). Also, as per previous discussions, I am more than happy to discuss any proposed changes you may wish to make, argue over grammatical structures, etc, but when you immediately come here and imply that I'm some sort of grand overlord who refuses to listen to anybody and is making horrendous changes without the slightest consideration for the little man, it doesn't really make it easy to find a middle ground. Primefac (talk) 19:27, 11 October 2020 (UTC) also, for those curious, we're discussing recent changes to Wikipedia:Templates for discussion/Closing instructions, the talk page of which redirects here

You can't just revert with "it's fine as is". That completely fails to distinguish between "I understand the impetus for change but feel every aspect of this is already covered" (fine) and "I just don't like it" (off-putting). When you make a revert, you negate sometimes hours of work of another editor. Please respect the work of other editors enough to actually engage with their points! For instance you just revert me AGAIN with a dismissive "we don't need this word" edit summary over at Deletion process, as if a) you're part of a community, but I'm not and b) "we" know better than I do. It's incredibly condescending and you need to stop. And now you make me appear as if I have demanded that you "write a treatise for every edit summary". This is a gross mischaracterization! CapnZapp (talk) 19:35, 13 October 2020 (UTC)

The discussion is not closed. The whole point of relisting is to keep the discussion going. It is, for technical purposes, just moved (to the new dated page, hence preventing a fork). Saying the current discussion is being closed and a new one is started is perhaps in purely technical terms a correct description, but it's not an accurate one, and so is confusing. I wanted to explain that what a Relisting really is, is closing an older discussion and opening a new, identical, one with the current, fresher, date. I consider that an editor that understands this is better armed to make the relisting. PS. I noted that the process of relisting involves closing the discussion with result of "relisted". So which is it, is it technically just moved, or closed - you claim both above, and what's the difference between "for technical purposes" and "in purely technical terms"? CapnZapp (talk) 19:55, 13 October 2020 (UTC)

Regarding grammar on "or not" I feel the current wording seems more grammatically correct. The important distinction I'm trying to get at is when there's consensus irrespective of what result. Maybe I'm wrong but with respect, please try read the following with no preconceived notions. Let's boil down the sentence

Determine whether or not a rough consensus to delete has been reached.

to it's essence:

Determine whether or not X has happened

X here is "consensus to delete". Thus, the sentence covers "consensus to delete has been reached" and "consensus to delete has not been reached". It does not cover the case of "consensus to merge has been reached", for instance.

In my suggested phrasing Determine whether a rough consensus to delete (or not) has been reached. The "or not" is meant to mean "or other outcomes". It is taken directly from WP:Deletion guidelines for administrators which says Once the decision to delete (or not) has been made. I am open to other approaches to solving this, but so far the only other editor (Primefac) has not engaged constructively, merely shut me down with no attempt to actually enter in conversation or ask me what I'm trying to do. CapnZapp (talk) 19:55, 13 October 2020 (UTC)

As for for more, in particular guidelines on what constitutes "rough consensus". we've just introduced the concept of "rough consensus" without meaningfully defining that term (or how it differs from regular consensus). I note that this definition can be found within the page we link to (Deletion guidelines for administrators). In order to ensure the reader looks for and find this definition, I suggest we explain WHY we link to the page. I myself was stopped in my tracks when I read this sentence with the question "what is this rough consensus thing" and being able to see that I would find a definition by looking in the linked article would have been clearly helpful. CapnZapp (talk) 19:59, 13 October 2020 (UTC)

This concerns edits over the last few weeks at Wikipedia:Templates for discussion/Closing instructions. This discussion is extremely vague and unhelpful. Please make one concrete proposal with a brief explanation of why it would be desirable, then wait for opinions. Johnuniq (talk) 22:33, 13 October 2020 (UTC)

you negate sometimes hours of work of another editor. You have been reverted multiple times here and elsewhere. You should expect at this point that your changes will be controversial in some way and should accordingly propose first, edit second. That way your time will not be wasted.

Secondly, are you attempting to close discussions? If not, your concerns are largely hypothetical. Please show us where you are having trouble closing discussions, not just with reading the instructions. Succinctly describe the issue you are having. --Izno (talk) 00:37, 14 October 2020 (UTC)

Okay so let us discuss the proposed changes in different subsections for your overview and convenience. Let's start with what I'd like to call "Consensus to what?" and "Rough Consensus". CapnZapp (talk) 22:13, 18 October 2020 (UTC)

Consensus to what?

Page Wikipedia:Templates for discussion/Closing instructions, section Closing the discussion, 2nd point:

Primary suggestion. Change:

Determine whether or not a rough consensus to delete has been reached.

to

Determine whether a rough consensus to delete (or not) has been reached.

Rationale: The text asks you to choose between A) a rough consensus to delete has been reached and B) a rough consensus to delete has not been reached. It does not provide instructions for when, say, a a rough consensus to merge has been reached.

The proposed change uses the language from Deletion guidelines for administrators: Once the decision to delete (or not) has been made where "delete (or not)" is shorthand for "delete, keep, merge etc". If this parenthetical expression is deemed unclear here (if not there as well), please consider the secondary suggestion:

Secondary suggestion. Change:

Determine whether or not a rough consensus to delete has been reached.

to

Determine whether a rough consensus to delete (keep, merge, etc) has been reached.

Thank you. CapnZapp (talk) 22:13, 18 October 2020 (UTC)

Since there is no objections, I will have to assume silent consensus. CapnZapp (talk) 23:24, 27 October 2020 (UTC)

I would recommend instead removing "or not" entirely. If we want to keep it, the parenthetical isn't particularly idiomatic or necessary as a parenthetical, and its cue to the deletion guidelines that you're implying is too subtle.

I don't see a need for the second change. --Izno (talk) 01:16, 28 October 2020 (UTC)

That's actually a fair point; a similar real-world example is "checking to see if it's raining", wherein there is the implication is that "or not" is still one of the binary options. I would support removal of "or not". Primefac (talk) 10:19, 28 October 2020 (UTC)

Why not just "Determine whether consensus has been reached"? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:53, 28 October 2020 (UTC)

I considered that last night. I wasn't sure if I liked it. We're shooting for rough consensus according to the current guide... --Izno (talk) 17:39, 28 October 2020 (UTC)

I think Andy's point is to remove the "to delete" as well. In other words, the closer should say "is there a <rough> consensus?", regardless of whether that consensus is to delete or do something else. Primefac (talk) 22:06, 28 October 2020 (UTC)

Right, and I'm saying that I considered the same. --Izno (talk) 23:11, 28 October 2020 (UTC)

Rough Consensus

Page Wikipedia:Templates for discussion/Closing instructions, section Closing the discussion, 2nd point:

Suggestion: Change

See: Deletion guidelines for administrators.

to

See: Deletion guidelines for administrators for more, in particular guidelines on what constitutes "rough consensus".

Rationale: The preceding sentence contains the phrase "rough consensus" (note the link). Thus we introduce the term "rough consensus" but do not define it. The link to consensus only defines consensus, not rough consensus. So a reader is left hanging here (maybe asking themselves "what is rough consensus and how does it different from regular consensus?"). Only a bit later did I realize this definition is in Deletion guidelines for administrators, but we don't say that here. We only say "See Deletion guidelines for administrators" - but that sort of advice is often general. And so it would be useful to add specifically that the definition the reader might be seeking right here right now will be found at this location.

Thank you. CapnZapp (talk) 22:13, 18 October 2020 (UTC)

Since there is no objections, I will have to assume silent consensus. CapnZapp (talk) 23:25, 27 October 2020 (UTC)

I've made a change here that I think should satisfy. "Rough consensus" should probably be in WP:CON. --Izno (talk) 01:13, 28 October 2020 (UTC)

I can support Izno's change, since it's solving the problem with a better link. Primefac (talk) 10:17, 28 October 2020 (UTC)

Early close

Recently, I nominated {{Message box}} and {{Messagebox}} for merging; I want to close the discussion early because I edited {{Message box}} so it includes all the functionality of the other template. After redirecting the inferior template, is it okay for me to close the discussion early? JsfasdF252 (talk) 14:00, 11 November 2020 (UTC)

Whether you are an admin or otherwise, you should not self-close your own nominations (with minor exception). --Izno (talk) 14:26, 11 November 2020 (UTC)

Agreed; unless you are withdrawing a nomination (generally when there is no support and/or there is opposition) you should not be closing a discussion that you started. Primefac (talk) 18:30, 11 November 2020 (UTC)

Holding page question

Hello, I just attempted to merge {{Top25}} with {{Top 25 report}}, I think it went well, I have checked pages and it appears to have no issues. Should I have also removed their entries from the WP:TFD/H page aswell? Terasail^[✉] 22:44, 17 November 2020 (UTC)

• Converting it to a redirect doesn't really solve the issue of there being both templates on the same page. See Talk:Audrey Hepburn. I have no idea how many pages have both, but the end goal is to have only one version. --Gonnym (talk) 00:26, 18 November 2020 (UTC)

  Indeed, I've gone through with the bot, about half the {{Top25}} transclusions were duplicates. The following pages need to be checked manually as they have different values between the two templates:

  • Talk:Roger Ebert
  • Talk:Tom Brady
  • Talk:R. Kelly
  • Talk:Maria Sibylla Merian
  • Talk:Rami Malek
  • Talk:Facebook
  • Talk:Star Wars: The Rise of Skywalker
  • Talk:Mulan (2020 film)

  Thanks. Primefac (talk) 02:44, 20 November 2020 (UTC)

Proposal to modify CSD T3

There is an RFC proposal to deprecate WP:T3 deletions of templates ("duplicate or hardcoded instances"). Your opinions are appreciated at the discussion. Primefac (talk) 15:06, 26 November 2020 (UTC)

Sidebar batch nominations

The closing "keep" statement in a 2019 deletion discussion about a group of related sidebar templates included: "There is significant opposition to deleting these in a mass nomination... No prejudice against individual renominations."

This necessitated three sets (September 28, October 5, October 8), so far, of individual nominations (and even there there were objections made on the basis that several had been nominated simply at the same time). Every one of which either resulted in a "delete" result, or in the case of the latter set, has unanimous "Delete" comments at the time of writing.

The second of those was closed, with the comment "any future nominators of these templates are encouraged to consider bundling any closely related nominations, as far as is practicable".

So, if I nominate another set of these templates should I do them as individual nominations, or in a batch? If I do the latter can I be sure that further "significant opposition to deleting these in a mass nomination" will not carry any weight? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:08, 14 October 2020 (UTC)

• The problem with batch nominations from my experience, is that a lot of the "oppose" result in people not really looking into the list and just voting because "it's a lot". Another smaller group of opposers, might find a problem with one, but don't care to state that, and just blanket oppose the full list. It's tedious for everyone TfD one at a time, but if you really want to delete a set of related templates, that is sometimes the only way. --Gonnym (talk) 14:25, 14 October 2020 (UTC)

  If you've put through three sets of ungrouped-but-basically-batched nominations, and all three sets have been deleted in their entirety, and you were encouraged to submit a batch nom the next time, I'd say it's perfectly acceptable to batch-nominate. I would agree with Gonnym about the potential opposition; there will be a number of !votes that are purely made to be ornery and/or trying to nitpick. It might be tedious (and deary me, am I well aware of that right now), but those sorts of generalist "you shouldn't do this" opposition usually receives a much smaller weight when I close things. Primefac (talk) 19:11, 14 October 2020 (UTC)

[restored from archive] The TfD has been closed as "no consensus", with a recommendation "I suggest usage be addressed on a per-page basis". I despair. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:59, 29 November 2020 (UTC)

• Can't say I didn't tell you that would happen. --Gonnym (talk) 14:32, 29 November 2020 (UTC)

I think you extrapolated my comment too far. What I said was: Noting the fractured and forked nature of these discussions, any future nominators of these templates are encouraged to consider bundling any closely related nominations, as far as is practicable. When I wrote that, I was thinking of (for example) bundling together all templates you want deleted for a same "unused" rationale, and additional bundles for another closely related rationale, etc., and single nominations for what has no closely related rationale or is individually controversial. I was not thinking you'd nominate the single master template and everything that depends on it in one discussion, which even the 2019 discussion did not do. The recent close you're referring to similarly states: bundling where appropriate (eg when arguments are the same, such as 'unused'). ProcrastinatingReader (talk) 14:33, 29 November 2020 (UTC)

I doubt that bundling as you suggest would have given a different result if the bundle had over 10 templates. Andy, just nominate 5-10 a week, which would slowly work. --Gonnym (talk) 14:35, 29 November 2020 (UTC)

Then bundle together 10 templates? If they're all unused, or have a close rationale and aren't individually controversial, it's hard to validly make arguments such as There aren't any horizontal navigation bars for many of the composers that use this template, the other format remains permissible, there is no consensus to remove it from Handel opera articles. I cannot discredit valid arguments such as these, which come up when you nominate the master template rather than bundles of the children. Nominating 5-10 a week is fine, if you prefer. The per-page part of the trimmed quote is, to be clear, referring explicitly to the Handel case (Robert's comment). The full quote was: I suggest usage be addressed on a per-page basis in line with Robert.Allen's suggestion, or templates be nominated on per-composer basis, bundling where appropriate (eg when arguments are the same, such as 'unused'). ProcrastinatingReader (talk) 14:45, 29 November 2020 (UTC)

I could tell you which are unused if not some were reverted quoting the close as the reason. Example Rita (opera), compare and mind edit summary. Not ready to despair but not far away. These duplicated "clunky" things are good for nobody. --Gerda Arendt (talk) 17:39, 29 November 2020 (UTC)

Attitudes to deleting templates

Some long-term templates that actually had a purpose are later made redundant by a TfD, in such a manner that a redirect would not be suitable. In such cases we delete. But this sometimes seems like a bad idea, when the contents are not a duplicate of their target (eg a typical infobox merger) and may have future relevance.

Case in point, this TfD. A redirect to {{Talk header}} would be nonsensical, so I tagged {{Findnote}} for deletion, but on reflection those templates have certain ways of doing things which may be useful to a template editor in the future looking to refine this logic beyond its minimally necessary TfD implementation. Many people will not bother ask for a copy of a deleted page, though (I've only done so twice ever, I think).

Should we be doing something else with these templates to retain their history / content somewhere so someone strolling along the archives could find it? Similarly related this discussion I started on attribution. ProcrastinatingReader (talk) 07:50, 4 December 2020 (UTC)

A graveyard of good ideas done wrong the first time? Nah. If it really was a good idea, someone will reinvent it for their need. --Izno (talk) 12:36, 4 December 2020 (UTC)

That assumes that all TfD discussions actually achieve the correct outcome, which isn't necessarily always true. Some merges are unnecessary / problematic, and some keeps are knee-jerks that gets resolved later, etc. But I suppose your point is fair, in that a later iteration could be built from scratch and would probably be better than the original, designed for a need rather than recreating what was once deleted. ProcrastinatingReader (talk) 12:51, 4 December 2020 (UTC)

The deletion of old templates is very frustrating to wikiarchiologists who look at old versions of pages. —SmokeyJoe (talk) 12:39, 4 December 2020 (UTC)

Deletion is only really necessary for pages eligible for speedy deletion (we don't want to have copyvios and attack pages), or for articles (we don't want the project's credibility further damaged by the existence of articles on non-notable topics). Outside of that, I don't see any particular reasons to specifically opt for deletion, rather than some other form of archiving (and deletion is a form of archiving, just a very messy one). I had floated a related idea, though for different reasons, a few years ago: Wikipedia talk:Templates for discussion/Archive 24#Unused templates, archivability, and simpler alternatives to deletion. – Uanfala (talk) 13:24, 4 December 2020 (UTC)

Nah. Our template coding language isn't that hard, nor are any tricks one can do with it likely to only be found in one place. And if someone desperately wants one back to borrow some code from it, they could ask for a WP:REFUND to a user-space sandbox.  — SMcCandlish ☏ ¢ 😼  21:25, 4 December 2020 (UTC)

Group of users interested in changes to CSS

Watchers of this page may be interested in Wikipedia talk:Manual of Style/Accessibility § Group of users interested in changes to CSS. Izno (talk) 22:07, 20 December 2020 (UTC)

RfC on categorizing redirects to the same namespace

FYI

 – Pointer to relevant discussion elsewhere.

Please see: Template talk:R to project namespace#RfC: Should we categorize redirects to the same namespace?
 — SMcCandlish ☏ ¢ 😼  19:14, 24 December 2020 (UTC)

Discussion at Wikipedia:Village pump (proposals) § RfC: Should we have Support/Oppose/etc. survey convenience templates?

 You are invited to join the discussion at Wikipedia:Village pump (proposals) § RfC: Should we have Support/Oppose/etc. survey convenience templates?. * Pppery * _{it has begun...} 22:30, 1 January 2021 (UTC)

Redundant wording, and request for clarification

III: Notify users. overlaps heavily with the following III: Notify users.After nominating: Notify interested projects and editors, in that it includes not only procedures that are required but also those that might be "helpful". If it is indeed a policy requirement to notify the template creator, then the "helpful" stuff should be removed from the required procedure, and some clarification regarding notification of the creator (such as You are not required to notify the template's creator if they have not edited English Wikipedia in three/five/ten years or are indefinitely blocked or You are still required to notify the template's creator even if they are no longer active on English Wikipedia or are indefinitely blocked.

FWIW, for the template I nominated for deletion earlier today, the page creator was put under a self-block to enforce their retirement more than a decade ago, and notifying them of the discussion was arguably, if not a completely redundant/useless act, disruptive (they do not have email enabled, so I guess they would not necessarily receive an unwanted notification that their talk page had been edited, but still...).

Hijiri 88 (聖やや) 04:45, 6 April 2021 (UTC)

There is not any requirement (and never has been) to notify the page creator of a deletion discussion (for any XfD). I'll note that the instructions at WP:AFDHOWTO have similar steps, in that step 3 is also "notify creator" along with a later paragraph about other interested parties. I don't necessarily have any issue with changing the how-to guides, but if we're going to change one we should change them all. Primefac (talk) 12:28, 6 April 2021 (UTC)

I'm 90% certain that I've been called out in the past for failing to follow AFDHOWTO's "explicit requirement" to notify the page creator (or at least seen others being called out so), but that's not an issue in the present case. If that situation ever occurs again, I'll hopefully remember to point them to what you have written here. Thanks for clarifying! Hijiri 88 (聖やや) 15:56, 6 April 2021 (UTC)

Sorry, I should clarify: "explicit requirement" isn't me attributing a strawman argument to anyone, since that's my reading of it and I can definitely see others reading it the same way. I came here today looking for instructions on what I must do and what I should do to open a TFD discussion, and I saw a list of imperative instructions, I'm sure there's something written somewhere in here that would justify reading "following this three-step process" in which the the third step is "please notify the creator" as meaning that notifying the creator is optional, but I don't use TFD often, much less have a detailed knowledge of the process and how to interpret the wording of the instructions (and I have to imagine that the instructions are meant for people who don't already have a detailed knowledge of the process). Hijiri 88 (聖やや) 16:09, 6 April 2021 (UTC)

• This isn't a requirement, but a strong expectation. See, for example, the last section of Wikipedia:Articles for deletion#After nominating: Notify interested projects and editors, which contains advice that's consistent with the much briefer instructions in other deletion venues. If a nominator doesn't notify the creator, then barring extreme cases (e.g. being confused about the process, or acting in bad faith) this is an indication that the nominator has a good reason not to notify: the creator may have retired, they may be blocked, or they may have previously expressed a desire not to get notified of similar discussions. Also, a notification doesn't have to be a talk page message. For example, when I nominate less consequential pages (like redirects), I tend to send a notification using a ping (provided the editor is active), so as not to clutter their talk page. – Uanfala (talk) 16:41, 6 April 2021 (UTC)

Informal check

Found 3 content tables hiding in template space that I'm not totally certain should be templates. They're transcluded multiple times but even so I have some doubt that they should be. {{Worldwide broadband subscriptions}}, {{Broadband subscriptions}}, {{Internet users by region}}. Any opinions from the peanut gallery? Izno (talk) 18:56, 15 April 2021 (UTC)

As far as the code goes, they're fairly simple/short tables, so I don't see any issue with putting the code directly into articles. With LST it's easy enough to transclude from a central article, but I guess it depends on if one exists. Primefac (talk) 19:04, 15 April 2021 (UTC)

Preview warnings and hatnote TemplateStyles

Pages watchers may be interested in MediaWiki talk:Common.css § Preview warning and hatnotes moving to TemplateStyles. Izno (talk) 01:08, 23 April 2021 (UTC)

Reader-facing discussion notifications

I would like to suggest that having the notification, “Template X is being considered for merging” show to readers in every article where that template is used is distracting and should be removed. I doubt that any readers are interested in knowing this, and editors who are interested in such things can monitor the relevant noticeboards. 193.48.225.132 (talk) 16:55, 2 May 2021 (UTC).

This gets proposed a lot, but there is never any strong consensus to change the current behaviour. Of course, I'm not saying that we will never change how templates appear on pages (w.r.t. deletion) but it would likely require an RFC. Primefac (talk) 22:01, 2 May 2021 (UTC)

How about only showing it for logged in users? I feel like we really should try to get input from people who aren't TfD regulars on this, probably through a RfC. --Trialpears (talk) 22:13, 2 May 2021 (UTC)

Esp when a large infobox or metatemplate is proposed it can clutter a lot of articles. Hiding it from non-logged-in is probably a good idea imo, but best to ask at VPP. ProcrastinatingReader (talk) 19:02, 3 May 2021 (UTC)

Trialpears, I think we should avoid making logged in-logged out a proxy for editor vs. reader. We want readers to be creating accounts even if they never plan to edit, and if doing so causes a bunch of extra annoying notices, that's a perverse incentive. Using autoconfirmed as the proxy might be better. {{u|Sdkb}} ^talk 18:17, 15 May 2021 (UTC)

Ugh definitely, I don't even think it's possible to do what I said using group css. --Trialpears (talk) 18:25, 15 May 2021 (UTC)

Trialpears, to implement this, wouldn't we just add {{If IP}} or {{If autoconfirmed}} around {{TfD}}? {{u|Sdkb}} ^talk 18:44, 15 May 2021 (UTC)

Sdkb As usual you are correct. I thought the list of group css pages at MediaWiki talk:Common.css was comprehensive (which it is now). I will make an actual proposal at the pump now. Although I wouldn't just wrap it since that would hide the notice on the template page as well which wouldn't be desirable. --Trialpears (talk) 19:16, 15 May 2021 (UTC)

Trialpears, sounds good. I think the core consideration here is that we need to find a way to balance the fact that the IP is correct about the notices not doing anything for readers with the need to find some way to ensure that editors are notified about big TfDs. {{u|Sdkb}} ^talk 19:21, 15 May 2021 (UTC)

Discussion started at Wikipedia:Village pump (proposals)#Hide TfD notices for non-autoconfirmed users. --Trialpears (talk) 19:32, 15 May 2021 (UTC)

• One problem is that we can not assume that an IP is a reader and not an editor. We have IP editors (some of whom have been editing for years) who have never created a user account, and thus can not be auto-confirmed. They may want to see TfD notices. Also... seeing notices may turn a mere reader INTO an editor. Blueboar (talk) 19:52, 15 May 2021 (UTC)

Close request

Would anyone be interested in wrapping up the discussion I started at Wikipedia:Templates for discussion/Log/2021 May 13#Template:Auto archiving notice? It's going to continue drawing !votes as long as it's open because it has such a prominent notice, but I think after three weeks the consensus has become clear enough, and it'd be nice to get that notice off of the top of every major talk page. {{u|Sdkb}} ^talk 17:42, 3 June 2021 (UTC)

That was my plan for this evening. Primefac (talk) 17:46, 3 June 2021 (UTC)

Template:Indefinite article actioned

@Primefac: On the 8th, Template:Indefinite article, was put up and then 3 hours later, closed, with the rationale "This can just redirect to {{a or an}} without any negative consequences. I don't think that needs a TfD discussion as the usage etc will remain identical, it's just a straightforward improvement to Indefinite article." Is this problematic? Techie3 (talk) 23:15, 9 June 2021 (UTC)

GKFX could have just redirected the page without involving TfD at all, so I don't see a problem. * Pppery * _{it has begun...} 23:31, 9 June 2021 (UTC)

Technically it's a withdrawal followed by a BOLD action. If you wish to contest that last bit you're welcome to revert and take it to TFD yourself. Primefac (talk) 18:21, 11 June 2021 (UTC)

Possible Candidate for Deletion

I don't get involved with templates too often and know little about guidelines for keeping or deleting them, so I will just start a discussion here. I found this: Template:Los Payasos de la tele, which seems wasteful to me because it has more red links than blue links (note that "Gaby" is currently being discussed for deletion as well), so it seems pretty pointless as a navigational aid. However I don't know if that is a reason to delete a template, so discuss accordingly. If anyone thinks it could be deleted, I can start the TfD process, or someone else could and I will cast a vote. Thanks. ---DOOMSDAYER520 (TALK|CONTRIBS) 13:25, 18 June 2021 (UTC)

"Not enough bluelinks" is an often-seen reason at TFD, usually supported by WP:NENAN. The general precedent for such nominations is a minimum of 4-5 bluelinks. For a template like this, it's a reasonable-enough borderline case that it can't hurt (i.e. the discussion wouldn't be SNOW closed). Primefac (talk) 14:08, 18 June 2021 (UTC)

Post-expand include size reached

The TfD page has currently past the post-expand include size and is now broken, with the last day not showing and older discussion link not even not displaying. Not sure if there is anything that can be done, but posting here in case there is. Gonnym (talk) 12:11, 13 July 2021 (UTC)

I'm guessing {{Tfd links}} is a major culprit, perhaps it could be made lighter, or twinkle could be changed to use the module directly. Since this is unusual I don't think it's worth consider larger changes than that. --Trialpears (talk) 12:20, 13 July 2021 (UTC)

That would likely require XfD closer changes as well though. --Trialpears (talk) 12:22, 13 July 2021 (UTC)

Well, I was going to quickly help by subst'ing some of them - but that template is broken for subst.... — xaosflux ^Talk 14:53, 13 July 2021 (UTC)

There were some massive lists of nominations. I've moved the bulk of them to subpages, which has allowed all of the discussions to be transcluded. WP:TFDH still isn't being transcluded, but to be completely honest I always thought it was dumb that we transcluded that here so I'm not going to inconvenience too many more of the existing logs to allow for its transclusion.

And yes, I realize this is a short-term fix, but for the moment it allows for all of the logs to be shown. Primefac (talk) 17:01, 13 July 2021 (UTC)

The holding cell isn't displayed so often that I think it's fine to turn it into a link. --Trialpears (talk) 17:05, 13 July 2021 (UTC)

• This comment may or may not be of use, but there was a similar problem at WP:RFD a few years ago, which lead to a few tweaks here and there (for example, closed discussions are omitted from the transclusion and are instead replaced with a single line of text linking to the relevant section on the log page). – Uanfala (talk) 00:37, 18 July 2021 (UTC)

  TfD already omits closed discussions from transclusion (not even leaving a placeholder), and has since a previous episode of transclusion-size problems in 2019. * Pppery * _{it has begun...} 03:02, 18 July 2021 (UTC)

  Ah, sorry. I did notice one apparently transcluded closed discussion though: [1]. There must be something I'm missing here. – Uanfala (talk) 11:33, 18 July 2021 (UTC)

  Only closed discussions in the "Old discussions" section are omitted. There generally aren't very many closed discussions in the "current discussions" section, so I doubt that's a significant PEIS problem. * Pppery * _{it has begun...} 15:39, 18 July 2021 (UTC)

• It has continued with only the 4 most recent days being showed earlier today. To combat this I edited Module:Tfd links. Some of it were quite minor such as removing Example as a parameter default, changing how concatenation is done dropping support for categories (I think I'm the only one semi-regularly using catfd anyway). I also removed the delete link since I think all active admins use XfD closer and the transclusion link since it's just a click away from links. This reduced the size by over a third and solved the issues for now. If we return to smaller nomination quantities it would probably be good to make a partial revert. --Trialpears (talk) 17:40, 27 July 2021 (UTC)

  There are probably other ways to decrease it further especially with the date features. I would very much want to continue having TfD as a one page thing. --Trialpears (talk) 17:45, 27 July 2021 (UTC)

  @Trialpears: it looks like this edit to the module has broken {{Tfd links}}, which is showing a Lua error. This in turn has spread HTML5 incompatible misnested tag Lint error to over 50k pages. Please fix this. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 02:43, 28 July 2021 (UTC)

  ಮಲ್ನಾಡಾಚ್_ಕೊಂಕ್ಣೊ fixed. Broken {{Tfd links}} is a bit of an exaggeration, I would say caused script errors on 4 pages and some lint errors. --Trialpears (talk) 06:15, 28 July 2021 (UTC)

  I'm not a big fan of that change. In particular, I used the transclusions link a lot. ProcrastinatingReader (talk) 11:16, 28 July 2021 (UTC)

  I also use it but, one click isn't all that much. I've re-added it while making some other minor PEIS improvements. It still increased by over 20% but it's enough to keep everything on the page right now. --Trialpears (talk) 11:42, 28 July 2021 (UTC)

  Thanks for bringing back the transclusions links. That is the link I used the most and for large nominations it saves me quite a bit of time. Gonnym (talk) 17:44, 28 July 2021 (UTC)

  Still a problem... How about removal of the edit link? I can't recall when I last used personally. --Trialpears (talk) 17:35, 1 August 2021 (UTC)

  Maybe it's better to ask which of the extra links we do use? For me I only really use transclusions, history and subpages. ProcrastinatingReader (talk) 19:11, 1 August 2021 (UTC)

  I'd add talk to that list, there are often some relevant discussion or an old TfD template. That leaves links, which I use but feel is largely redundant to transclusions and logs which I guess happen but not often enough to deal with the PEIS. Perhaps it's time to seriously consider using the module directly. Updating XfDcloser to recognize it would be the first step in that. Ping to Evad37. --Trialpears (talk) 19:23, 1 August 2021 (UTC)

Section transclusions

I'm sure anyone following this page is familiar with the considerable productivity of WikiCleanerMan in nominating templates for deletion when they have a few transclusions, but more than one, with the proposal to use section transclusion (or, in some instances, to substitute duplicate content on multiple articles). I will leave the merits of this proposal to a different discussion, but I have serious concerns with how I have seen section transclusion implemented as a result of these deletions.

Firstly, our guidance states that when section transclusion is used, Common sections like this should be marked with an explanatory header, and/or given a special layout, to inform the reader that this section of the page is in a different location, since transcluding shared article sections can easily confuse novice editors and readers alike if left unmarked. See Help:Transclusion#Transcluded section hatnote.

Secondly, section transclusion is succeptable to breakage when the heading name is changed at the transcluded article. And users edit section headings often enough for this to be a serious problem. Accordingly, we should be following the guidance at MOS:BROKENSECTIONLINKS to add comments at the transcluded article warning that the section is transcluded.

Thirdly, unless an entire section is being transcluded, it is almost always better to use Help:Labeled section transclusion than to rig up a section transclusion with "include only" tags. Section transclusion gives the false impression at the transcluded page that an entire section is being transcluded when it is not. It adds confusing "include only" tags to the transcluded article, often without explanation of their purpose. And it is more susceptible to breakage when a section heading is unwittingly renamed.

For the implementations I have seen (and I won't call out names but I hope they see this discussion), many of these things are not being done. So I think we should take the opportunity to discuss best practices and any questions, because it is awfully difficult to track down substitutions after they have been made and the templates deleted. --Bsherr (talk) 15:26, 4 August 2021 (UTC)

Tagging Number 57, Gonnym, and Frietjes (who has been doing the transclusions from the Tfd's) who can add some insight to this. --WikiCleanerMan (talk) 15:52, 4 August 2021 (UTC)

This isn't exactly section transclusion though, it's transclusion of a table, with the section heading simply used to locate it in the article (as in many cases the table is the only thing in the section). If using #section-h is an issue, it could be replaced with the simpler {{: and use of onlyinclude tags, which is done for transcluding sports league tables from the league season article to other locations they are used (for example, {{:2016–17 Serie A}} is used to transclude the league table from 2016–17 Serie A to other articles it's used on.

Frietjes has also suggested having a tracking category for articles containing broken section tranclusions, which would seem like a good way to pick up such errors. Number 57 16:45, 4 August 2021 (UTC)

@Number 57: Using parameterized section transclusion is no different than using #section-h. Both have to be rigged up with "include only" tags to get around the issue that you're not actually transcluding a section. That's why LST would be better. If you are using LST, you will greatly curtail the risk of broken transclusions, since it's not dependent on heading names. --Bsherr (talk) 20:30, 4 August 2021 (UTC)

I have no problem with the result being to use labeled section tags. The {{Transcluded section}} hatnote can be added above. Gonnym (talk) 16:47, 4 August 2021 (UTC)

Notice about re-inserting a mistakenly deleted nomination

I just noticed that @Anomalocaris mistakenly deleted this nomination of @WikiCleanerMan. I've re-inserted it to today's listing. Gonnym (talk) 15:18, 13 August 2021 (UTC)

Nice catch. Primefac (talk) 15:34, 13 August 2021 (UTC)

Terribly sorry, but, for the record, this was not my fault. WikiCleanerMan and I were editing simultaneously. WikiCleanerMan saved first, and I saved two minutes later, and there was no warning that I was stomping on another edit. Thank you to Gonnym for finding this and taking care of it. —Anomalocaris (talk) 18:10, 13 August 2021 (UTC)

Relisted a bunch

I relisted a bunch to help with the "expand size" preventing all the listings from appearing on the page. Please feel free to close any that I relisted if you feel as though consensus has been reached. Thanks! Plastikspork _―Œ^(talk) 23:21, 16 August 2021 (UTC)

To Orphan section

Re this. For the 5 or 6 years I've worked on these the to orphan section was populated by templates that needed orphaning. As soon as that task was completed they were moved to the ready for deletion section and then removed completely after the template had been deleted. Now there is one template that has been in the to orphan section for months and another that has a note to leave it untouched pending DRV. In other words there are items there that are not being orphaned so they are just cluttering up the section. I'm guessing that the message "XfDcloser but entries in the wrong section" means that new ones to be orphaned wont be put in the new sub-header I created so I understand the problem. I can see three options a) move the on hold ones to a new place b) change XFDclosers programming to put new entries in the new subsection c) leave things as they are. There might be other possibilities that I am unaware of. Whatever the rest of you decide is fine by me - apologies for being OCD about this. MarnetteD|Talk 23:21, 14 September 2021 (UTC)

Oops I didn't pay attention to the fact that this talk page is a redirect from the one for Wikipedia:Templates for discussion/Holding cell so I'm adding this link to help avoid extra searching. MarnetteD|Talk 23:24, 14 September 2021 (UTC)

I feel both those entries should just be moved to "To review" as they aren't straight orphaning in either case. Where XfDcloser puts entries is based on the section numbers. It would be trivial to change a constant to fix it if there's consensus, but if it's just changed we would get all the ready for deletion ones in "Ready to empty". --Trialpears (talk) 23:26, 14 September 2021 (UTC)

Moving those two items to "To review" sure seems like the simple solution to me. Other input is always welcome. MarnetteD|Talk 23:35, 14 September 2021 (UTC)

Residence parameter in the Template:Infobox sportsperson

Moved to Template talk:Infobox sportsperson

 – This has nothing to do with TfD. * Pppery * _{it has begun...} 04:30, 26 September 2021 (UTC)

Splitting

I have recently become aware that TfD has been the venue used to discuss template splitting proposals, a much better solution than following WP:PROSPLIT given the extremely low number of people that are typically attracted to template talk pages and the lack of a dedicated template split discussion banner. Would it be appropriate to add instructions for splitting proposals to the instructions here? Cavalryman (talk) 22:10, 18 October 2021 (UTC).

I think you are misinterpreting my comments here. I never said that TFD is the venue for discussing template splits, and the majority of the time "delete or split this template because it's too big" nominations are the result of either pushback or low-consensus turnout. It might be the next logical step following PROSPLIT, but I do not think split discussions should exclusively happen at TFD. Primefac (talk) 07:28, 19 October 2021 (UTC)

Apologies, my mistake, I’m all for reducing work loads not further burdening our regulars. One way of increasing talk page participation may be to amend Template:Split, or a new “template template” that renders like Template:Template for discussion but directs interested parties to the TP discussion. That being said, I am not sure how common template split proposals are, again this may be extra work for little benefit. Cavalryman (talk) 22:21, 19 October 2021 (UTC).

Updating infobox templates

I figured people who watch this page may be interested in helping another WMF wiki editor with tips for WP:VPT#Updating infobox templates. Izno (talk) 23:26, 30 October 2021 (UTC)

Jeez, they should have asked here first! Either way, replied. Primefac (talk) 07:58, 31 October 2021 (UTC)

VPT is more visible for an foreign-to-English editor, so I think it was probably reasonable to say something there. Izno (talk) 13:15, 31 October 2021 (UTC)

Indeed, though to be honest I thought we were at WT:WPT... Primefac (talk) 13:18, 31 October 2021 (UTC)

"Wikipedia:Review/Message boxes" listed at Redirects for discussion

A discussion is taking place to address the redirect Wikipedia:Review/Message boxes. The discussion will occur at Wikipedia:Redirects for discussion/Log/2021 November 25#Wikipedia:Review/Message boxes until a consensus is reached, and readers of this page are welcome to contribute to the discussion. Q28 hope you pay attention to TFD 00:06, 25 November 2021 (UTC)

Template:Phosphorus

Hello, Template folk,

I've been deleting some of these element templates that have gone through TFD after they've been readied for deletion. I always check to see if there are links and most of the templates haven't had links although a couple did have doc pages which I also deleted. Then there is Phosphorus. It was linked to Template:Engvar, Template:Engvar/doc and Template:Engvar/sandbox. I don't know the purpose of using the Phosphorus template on these pages but I thought maybe someone who did could check and see whether you wanted to substitute a different template for this deleted one.

Many thanks for your ongoing work to clean up the template world! Liz ^{Read! Talk!} 00:04, 5 December 2021 (UTC)

Liz, I linked to to Phosphorus, which appears to provide the necessary demonstration. Thanks for the note, and for your TFD work. – Jonesey95 (talk) 06:55, 5 December 2021 (UTC)

Making Category:Unnecessary taxonomy templates G6

At Wikipedia:Templates for discussion/Log/2021 October 17#All templates in Category:Unnecessary taxonomy templates @Izno, @Tom (LT) and @Peter coxhead (on Izno's talk page) supported having these templates G6. How do we move this forward? Gonnym (talk) 09:12, 15 November 2021 (UTC)

Gonnym, just to double-check, you're asking if we can delete the 0 pages in Category:Unnecessary taxonomy templates per the XFD? Primefac (talk) 09:14, 15 November 2021 (UTC)

Yes (per the past 6(?) discussions) Gonnym (talk) 09:17, 15 November 2021 (UTC)

 Done. I don't think there's any harm in having the category holding a dozen or so templates at any given time, but if it gets above about 20 feel free to ping me to clear it out again. Primefac (talk) 09:20, 15 November 2021 (UTC) update: HAH! I just noticed there's a line in the cat specifically stating to post here...

@Primefac 90 templates. Can you take care of this? Gonnym (talk) 00:41, 5 December 2021 (UTC)

 Done. Primefac (talk) 13:51, 5 December 2021 (UTC)