Template talk:Initiated
Add topic| Template:Initiated is indefinitely semi-protected from editing as it is a heavily used or highly visible template. Substantial changes should first be proposed and discussed here on this page. If the proposal is uncontroversial or has been discussed and is supported by consensus, editors may use {{edit semi-protected}} to notify an autoconfirmed editor to make the requested edit. Usually, any contributor may edit the template's documentation to add usage notes or categories.
Any contributor may edit the template's sandbox. Functionality of the template can be checked using test cases. |
Typo
[edit]The template puts the text INITATED not INITIATED. Can someone who knows how fix the typo? SPACKlick (talk) 15:37, 11 December 2014 (UTC)
- SPACKlick, thank you for fixing that. Happy editing! — {{U|Technical 13}} (e • t • c) 17:09, 11 December 2014 (UTC)
Resolved tag for usage
[edit]- Is there a way of incorporating a done tag into this template so it can be turned off by adding Status:= Complete or whatever? SPACKlick (talk) 15:54, 22 December 2014 (UTC)
- SPACKlick, that already exists as a previously undocumented
|done=yesparameter. — {{U|Technical 13}} (e • t • c) 16:18, 22 December 2014 (UTC)
- SPACKlick, that already exists as a previously undocumented
Category
[edit]@Technical 13: The template is categorising ANRFC as admin backlog (which is fine) but also every page to which ANRFC is transcluded (including AN and few pages in userspace). Callanecc (talk • contribs • logs) 00:38, 5 January 2015 (UTC)
- Callanecc, it's going to take some serious template-foo magic to make that transclude only one level deep, but I believe I've seen it done before and will dig up where I saw that and see if I can't replicate it here. Might not be right away, I have to do a lot of digging for that. :) — {{U|Technical 13}} (e • t • c) 00:44, 5 January 2015 (UTC)
- No worries, thanks for looking. When/If you work it out can you let me know, something useful to note down. Callanecc (talk • contribs • logs) 00:46, 5 January 2015 (UTC)
Type parameters
[edit]It would be helpful to have the type parameter abbreviations defined on the page, or a link to type definitions. As an irregular user of this template I find myself intermittently searching and wasting time. The list currently reads: afd; block; cfd; drv; ffd; mfd; mrv; rfa; rfc; rfd; rm; rmv; tban; tfd; xfd. Klbrain (talk) 10:06, 20 July 2018 (UTC)
- For most of them, there is a direct equivalent in WP: space. For example, afd → WP:AFD; block → WP:BLOCK, cfd → WP:CFD. I've not chcked them all, bit busy today. --Redrose64 🌹 (talk) 15:02, 20 July 2018 (UTC)
- Thanks; the list using that approach is: afd; block; cfd; drv; ffd; mfd; mrv; rfa; rfc; rfd; rm; rmv; tban; tfd; xfd. So, that would provide links for most, but current misses rmv and tban. Perhaps these are WP:RMV (but that's an essay on removing content) and WP:TBAN (seems that only the upper case is redirected for these). xfd also seems ambiguous; does it mean a discussion of any other deletion not defined elsewhere? Klbrain (talk) 08:35, 22 July 2018 (UTC)
- I intended my examples to indicate that all of them should be uppercased. As regards
|type=rmv, this edit shows that the related process is requested moves, for which the normal shortcut is WP:RM; and this edit shows that|type=rmwas also made valid later on. Perhaps rmv was a typo for rm, and was deliberately retained to avoid breaking existing uses. --Redrose64 🌹 (talk) 19:06, 22 July 2018 (UTC)
- I intended my examples to indicate that all of them should be uppercased. As regards
- Thanks; the list using that approach is: afd; block; cfd; drv; ffd; mfd; mrv; rfa; rfc; rfd; rm; rmv; tban; tfd; xfd. So, that would provide links for most, but current misses rmv and tban. Perhaps these are WP:RMV (but that's an essay on removing content) and WP:TBAN (seems that only the upper case is redirected for these). xfd also seems ambiguous; does it mean a discussion of any other deletion not defined elsewhere? Klbrain (talk) 08:35, 22 July 2018 (UTC)
An embedded left-to-right mark causes the template to malfunction
[edit]A left-to-right mark may be embedded in the DATE ( parameter {{{1}}}) if the timestamp is copy-pasted into this parameter field. Reported at Wikipedia talk:Administrators' noticeboard/Requests for closure#Concerning the instructions for Template:Initiated. See the examples at Template:Initiated/testcases. – wbm1058 (talk) 17:23, 9 February 2021 (UTC)
Fixed wbm1058 (talk) 19:54, 9 February 2021 (UTC)
Split tag missing
[edit]Can a three letter split tag parameter be added to this template. PicturePerfect666 (talk) 20:59, 21 May 2024 (UTC)
- @PicturePerfect666: I don't understand what you mean by "three letter split tag". --Redrose64 🌹 (talk) 22:09, 21 May 2024 (UTC)
- You have these ´afd; block; cfd; drv; ffd; mfd; mrv; rfa; rfc(default); rfd; rm; rmv; tban; tfd; xfd’
- So maybe not three but a split parameter would be very useful. PicturePerfect666 (talk) 22:24, 21 May 2024 (UTC)
- So what you are actually asking for is a new permitted value for the
|type=parameter. Nothing to do with tags at all. --Redrose64 🌹 (talk) 17:09, 22 May 2024 (UTC)
- So what you are actually asking for is a new permitted value for the
Syntaxhighlighting error
[edit]@Paradoctor: The attribute name is incorrect: it should be “wikitext”, not “wikicode”. Since the <kbd>...</kbd> tag represents only the user’s keyboard input in the user interface, it is not the correct semantic tag in this case. Cedar101 (talk) 01:02, 2 June 2026 (UTC)
Purpose of date, relists
[edit]Just dropping by with this dispute over what the intent of the date is in the context of relists. For me, as a backlog patroller, it seems like we should probably clarify that the date is for urgency and actionability sorting rather than recordkeeping. Alternatively, we could add a relist= param so that, obviously, freshly relisted discussions are de-emphasized. Feel free to lemme know if I'm wrong / crazy in this idea. :P --slakr\ talk / 17:26, 3 June 2026 (UTC)
- Find my initial thoughts in regard to this issue in this response to editor Slakr on the WP:CR page. IMHO there is no good reason to alter the date that the discussion was "initiated". I'm neutral on the inclusion of a
|relist=(date)parameter, because I do annotate that important information manually whenever I see that it's needed. That only takes a few seconds. P.I. Ellsworth , ed. – welcome! – 18:07, 3 June 2026 (UTC) - It's for the date when the discussion was initiated, that is to say, when it first began. Subsequent actions do not alter that. This has been the case for as long as I've been watching Wikipedia:Closure requests, which is since at least February 2017. See for example this edit. It can be said that something that has been relisted several times is more in need of a closure than something that has not been relisted at all, so having the date change to red for these older discussions assists in drawing attention. --Redrose64 🌹 (talk) 05:52, 4 June 2026 (UTC)
- My thoughts mirror the other participants in this discussion thus far: The
initiated=parameter has a clear purpose, and we should not deviate away from that. However, I can definitely see the value of an optionalrelisted=(or whatever name) parameter as the creator of this discussion has mentioned and Paine has explained. Steel1943 (talk) 00:49, 5 June 2026 (UTC) - Fine with an additional relist parameter, though I'm not sure how this would meaningfully differ from a comment with the same information. In solidarity, Iseult Δx talk to me 17:35, 10 June 2026 (UTC)
- My main thinking was the color coding / urgency. If I'm dropping by my usual backlog haunts, I can usually tell the things that actually need attention either by the order on the page or some sort of bold/red text. In this instance, if, for example, an AfD was initiated 20 days ago but hasn't been relisted, then it needs to be bold-red, implying hey, someone needs to close this, because it's long-overdue for a close. If, on the other hand, that same 20-day-old AfD was relisted less than 7 days ago, it definitely does not need to be bold-red, because until 7 days pass, it should be implying this is low-priority; it was relisted x days ago, so there's literally nothing any closer needs to do right now. --slakr\ talk / 03:08, 11 June 2026 (UTC)
- Your coloring at first appears to be logical; however, relisting usually means that at the time of the relist, there was little or no consensus. If consensus does emerge in, say, two days, then the discussion can then be closed. Closers don't have to wait seven days or any period of time to close after a relist. We look to see if consensus has been garnered. So dropping the red just because a talk has been relisted won't work for most editors. Forgive me, but on this page I still say it's best to maintain the status quo on this issue. P.I. Ellsworth , ed. – welcome! – 11:03, 11 June 2026 (UTC)
- My main thinking was the color coding / urgency. If I'm dropping by my usual backlog haunts, I can usually tell the things that actually need attention either by the order on the page or some sort of bold/red text. In this instance, if, for example, an AfD was initiated 20 days ago but hasn't been relisted, then it needs to be bold-red, implying hey, someone needs to close this, because it's long-overdue for a close. If, on the other hand, that same 20-day-old AfD was relisted less than 7 days ago, it definitely does not need to be bold-red, because until 7 days pass, it should be implying this is low-priority; it was relisted x days ago, so there's literally nothing any closer needs to do right now. --slakr\ talk / 03:08, 11 June 2026 (UTC)
- Initiated means initiated and the date should not be changed. The overall age of the discussion (days since initiation) should continue to be the primary data point for organizing and prioritizing requests. I'm sympathetic to the desire for additional color coding or other means of quick and objective prioritization based on the date of last relist, but I share Paine's concerns that this will ultimately prove deceptive in many cases. In addition to the scenario where consensus coalesces shortly after a relist, other fairly common scenarios include editors relisting just to clear the backlog or because they don't personally have the time/bandwidth to assess consensus; neither scenario tells us whether consensus could be assessed. The total number of relists and contributions between relists are also relevant in some discussions. Adding another parameter also creates a maintenance burden and errors and omissions will be especially problematic if the parameter is used for quick prioritization. I am grateful to the editors who take the time to close these often long, complex discussions and I want to make the job easier but I worry that relying on the date of last relist in this way is an oversimplification. The nature of WP:CR is that everything listed there needs an experienced closer to take a look at the actual discussion and make a determination. Most requests are bare-bones, which is usually appropriate, but any special context, nuance, or update is best stated explicitly in the request or in reply. —Myceteae🌈 (talk) 20:50, 11 June 2026 (UTC)