Wikipedia talk:Templates for discussion

Module:WikiProject banner/doc
This page is a soft redirect.

XFD backlog

V	Feb	Mar	Apr	May	Total
CfD	0	0	9	15	24
TfD	0	0	0	2	2
MfD	0	0	0	4	4
FfD	0	0	0	2	2
RfD	0	0	4	20	24
AfD	0	0	0	7	7

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.

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.

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)

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.

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)

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)