Template talk:Talk header

Proposal to drop archiving params
This is a proposal to drop the four archiving params (a.k.a. bot-notice params) bot, age, units and minthreadsleft. We can get the same information from the MiszaBot/config with more accuracy without these four params, and at the same time, generate a bot notice for all the pages that have a Talk page header but currently lack these params.

Up till now, the four archive-related params have been responsible for the bot notice seen optionally below the archive search box, and still are in override mode. However, they only control the notice, and do not affect whether or how archiving is actually carried out on the page, which is instead specified by template User:MiszaBot/config. In fact, the template bot-notice params and the MiszaBot config often get out of sync, leading to a misleading notice displayed in the Talk page header.

I've just released a new version of Template:Talk header which generates the bot notice below the search box automatically without parameters; any page having a MiszaBot/config and lacking the bot-notice params will now show the notice. However, if both a MiszaBot/config *and* bot notice-params are present, then the latter act as an override, and in many cases this means that the correct values determined by the new template are overridden by incorrect or out-of-sync user-supplied bot notice params. Pages that formerly had no bot notice, now have them if they have archiving configured; for example, see Talk:2017 or Talk:Traditional marriage. lots more examples here.

I don't currently see a reason to keep the four bot-notice params bot, age, units and minthreadsleft, and I think they should all be deleted; 1) because they are no longer needed, and 2) in order to stop generating misleading bot notices. We should just let the template calculate the notice. Perhaps there might be a reason to sometimes suppress the bot notice; in that case we should replace the four params with a new one: none. Another reason to keep the four params, might be if there are other archiving schemes currently in use that employ some configuration other than MiszaBot/config or Cluebot III's config ; in that case, either the template should be upgraded to recognize the other schemes, or we should just keep the params for those cases. Feedback sought and appreciated. Mathglot (talk) 04:17, 29 February 2024 (UTC) updated by Mathglot (talk) 08:54, 29 February 2024 (UTC)
 * This proposal is linked from WP:VPR with an expiration 3 weeks from now, to allow sufficient time for this to air. Mathglot (talk) 10:40, 3 March 2024 (UTC)

What about Template:Archives
Would it be worthwhile to add this functionality to Template:Archives as well? Tollens (talk) 23:30, 29 February 2024 (UTC)
 * Tollens, I had just noticed that template during the updates for this one, and had the same thought. That said, let's give this one a chance to air, and if there's no strong objections to it here, then I think your idea makes good sense as a follow-on change. P.S. no ping needed; I'm subscribed. Mathglot (talk) 23:47, 29 February 2024 (UTC)

Seems fine so long as it works as advertised for both bot archival templates. Automates a step that is otherwise easy to forget when archiving needs to be tweaked and no real downsides. I presume if there were a case where the params had been deliberately kept blank for some reason, the auto-population would have already drawn a complaint. 184.152.68.190 (talk) 03:36, 1 March 2024 (UTC)

Support - yes, if you want to contribute by writing a script/bot to get the information straight from the source, letting us bypass a manual element that mostly introduces a source of errors, this is of course very welcome! CapnZapp (talk) 12:00, 1 March 2024 (UTC)
 * I have something in the sandbox there, but it's not working yet. I basically got lost in a twisty little maze of curlies, all alike, and trying to fight my way out. Not sure when or if I'll get back to it, but it should point the way if someone else wants to have a look. At least the new code is comprehensible due to indentation, but I'm probably missing a curly higher up someplace. No new script needed, by the way; it calls the same parsing template developed for the solution here. Currently, it's a subtemplate of Template:Talk header, but if we use it from two places, maybe it should be spun off into its own root page. Mathglot (talk) 21:54, 1 March 2024 (UTC)
 * I'm happy to give it a go – what exactly was the issue? It looks like a bad parameter was being used for the minimum number of threads to keep, but other than that I can't see anything wrong. Curlies all seem to match up far as I can tell. Tollens (talk) 22:31, 1 March 2024 (UTC)
 * Made a couple other tweaks. As an aside, do we want to move the information about the specific archival bot and minimum threads to a tooltip as was done with Template:Talk header? I know I've used Template:Archives with only the age parameter on my user talk for quite some time and would prefer to keep it appearing that way or similar rather than having the other information be forced to display. Tollens (talk) 23:20, 1 March 2024 (UTC)
 * Thanks; as long as it's just in the sandbox, you can do pretty much what you like. I'll have to go look again to remind myself what the problem was. But a discussion section should probably be started there, linking/summarizing this one, to explain what it is that is being discussed. That box has had a different presentation for a long time, and any move of info to a tooltip should probably get consensus there, imho. Or now that I think about it, as it concerns two templates (maybe more?) perhaps at a more centralized venue, like Help talk:Archiving a talk page. Mathglot (talk) 02:43, 2 March 2024 (UTC)
 * Noticed your changes—thanks for that—and added a couple more. Wanted to add some test cases, but if this holds up, and there are no objections from regulars at the Talk page there, I think this would be a beneficial change, and keep the two templates relatively in sync. The same test cases as found at Template:Talk header/testcases4 but tested in situ should work here as well. Mathglot (talk) 12:00, 2 March 2024 (UTC)

Proposal to drop archiving params – break
How about ClueBot III? Graham87 (talk) 04:54, 29 February 2024 (UTC)
 * Thanks, wasn't aware it used a different config; it can be added. Do you know of any others? Mathglot (talk) 04:57, 29 February 2024 (UTC)
 * , it supports Cluebot_III configs now; any other bots you know of that need to be supported? Mathglot (talk) 08:34, 29 February 2024 (UTC)
 * Nope, that's it. Your ping didn't work by the way, probably because of the shuffling around of messages. While I'm thinking about it I support removal of the now-redundant parameters; it means I won't have to make occasional updates of archiving bot names like this (a previous bot run caught many of them, but not everything). Graham87 (talk) 09:21, 29 February 2024 (UTC)

This sounds like a solid improvement. It's too bad we didn't initially think of it when merging in auto archive notice back in 2021, as it may generate a few complaints about watchlist clutter, but I think it'll be worth it to remove the duplicative information, so I support.  Sdkb  talk 05:15, 29 February 2024 (UTC)

I think there is value in displaying such data - but they'd need to be the actual archive data and thus be displayed from User:MiszaBot/config. So yeah, remove 'em from this template. Jo-Jo Eumerus (talk) 07:51, 29 February 2024 (UTC)
 * Yes, it is displaying actual archive data pulled from the config. Currently, either MiszaBot, or Cluebot, whichever one it finds on the page. Mathglot (talk) 08:51, 29 February 2024 (UTC)
 * For the (rare) talk pages that have more than one archive config on the page, see . Mathglot (talk) 20:37, 5 May 2024 (UTC)

how and when to drop the bot notice params
This was supposed to run three weeks according to the notice pointing here from WP:VPT, but for some reason, the section there got archived, even with a DNAU in place. But it was there for over two weeks, and no objection was registered. Here's what it would take, imho, to drop the four bot notice params from the Talk page header template: The first three should be done whenever we are ready, which I think is now; unless there is some objection. The last three are optional, but it makes sense to do them, and will declutter the template code and the doc. The section above on, and in general, anything regarding what wording to use in the notice is completely independent from dropping the bot params, and the two processes may continue independently without taking the other into consideration. Probably subsections 3 and 4 should be broken out into a new, top-level discussion section about new wording, because they aren't really related to the dynamic bot notice topic at all. Mathglot (talk) 03:01, 20 March 2024 (UTC)
 * 1) make sure interested parties here are good to go with this; handle any concerns
 * 2) remove params archive_bot, archive_age, archive_units, minthreadsleft and their aliases from the template code, except for the unknown parameter invocation at the bottom. The effect will be that Talk pages currently containing these params will begin displaying data directly from the config params (if any) and stop overriding the actual configured values with the values  given in the params. Pages having no archiving will stop displaying false notices. The parameters will still exist, but have no effect.
 * 3) update the doc, removing the four from the main Parameters section but adding a temporary deprecated notice for some period (a year?)
 * 4) at some point (no hurry), request a bot to remove deprecated params from transclusions of Talk header; maybe WP:AWB can do this with an appropriate regex.
 * 5) Once the bot is complete (do Advanced search to make sure), remove the params from the unknown parameter invocation at the bottom.
 * 6) Remove the doc page deprecated params notice.
 * Two subsections moved to . Mathglot (talk) 04:21, 20 March 2024 (UTC)
 * FWIW, Village_pump_(proposals) is there when I looked just now. CapnZapp (talk) 13:59, 29 March 2024 (UTC)
 * Hi Capn, yes, I see it; not sure what you meant to say about the VPR thread.
 * As far as the steps above, it's been a month since the auto-generation of the bot notice was installed on 29 Feb., and I haven't seen any response, so that's a good sign that probably nobody even noticed, and at a minimum, we didn't break anything because that would've caused howls right away. I think we can move on to step 2, at least, when someone is available to do it. I'll be away starting in a few days and I don't want to start something now that might break and require attention just when I'll have no time for it. I'll have wifi occasionally for questions while away, but I wouldn't attempt template coding from my phone. Of course, there is nothing stopping anyone else from updating it who feels like doing so. Steps 4 & 5 can even be ignored forever; the downside is that there would be stale code in the template that does nothing, which is inelegant and makes it harder for other template editors to maintain it or add new functionality, so it's still a good idea to do those steps at some point, if possible. Mathglot (talk) 00:01, 30 March 2024 (UTC)
 * Mathglot, if it helps I'm happy to take care of 4. — Qwerfjkl  talk  19:36, 16 April 2024 (UTC)
 * Qwerfjkl, yes that would help, thank you, with the caveat of revisiting dependencies in the numbered steps first. I believe the simple, 1–6 enumeration is too simplistic, and a linear sequence doesn't properly represent interdependencies among them. I believe 5 & 6 must follow 4, but 4 is independent of 2 & 3, and may be done before, after, or simultaneously with 2+3. In addition, 3 could be done before 2, to discourage having to run 4 twice. In fact, maybe the sequence should be: 3 (without the temp deprecated notice), followed by 2 and/or 4 in any order, followed by dependencies of 4. Do you agree? If so, I'll update the doc, and then we can move on the rest, with your assistance at your convenience. Mathglot (talk) 23:23, 16 April 2024 (UTC)
 * Mathglot, sure, that sounds good to me. — Qwerfjkl  talk  05:48, 17 April 2024 (UTC)
 * Or maybe we should keep a small deprecated notice, as some users will remember the old params and wonder what happaned to them? Mathglot (talk) 23:25, 16 April 2024 (UTC)


 * Step 3 done (remove four bot notice params from doc). Next up: remove from template (will require sandbox changes and testing first). Mathglot (talk) 07:58, 17 April 2024 (UTC)
 * Mathglot, let me know when you want me to file a BRFA for this. — Qwerfjkl  talk  14:50, 28 April 2024 (UTC)
 * , thanks for the reminder. Step 3 (remove from /doc) is partially done: those params have been grayed out and tagged as deprecated in the doc. I just created a new sandbox with the four params stripped out per step 2 (diff), and that is now ready for testing. The removal was quite straightforward, but because of WP:THOSEDAMNCURLIES and the high visibility of the template, I want to take this slow and easy, and maybe get more eyeballs on it before releasing a change of this magnitude. (I'm scattered all over, so feel free to remind again if this stagnates.) Thanks, Mathglot (talk) 21:46, 28 April 2024 (UTC)
 * Test cases A–1 to A–5 and A2–1 to A2–10 completed successfully. These are all ExpandTempates tests. Mathglot (talk) 00:07, 29 April 2024 (UTC)
 * So, I'm happy with the current state of testing, and it looks like this is ready to be moved to live. I will do so shortly, but in an abundance of caution due to the high visibility, I'm pinging to see if there are any objections. In a nutshell, if released to live this change will implement step 2 above (and open the way to step 4, the bot run which  kindly offered to take on). Not releasing it would mean that transclusions of Talk header that use these bot params on Talk pages would have possibly incorrect archival information displayed in the Talk header, depending on whether the param values happen to be in sync with the actual archive config or not. If I don't hear anything in a few days, I'll release it. Regardless of feedback, I take full responsibility for the forthcoming release, and any errors that result from it are mine alone.  Thanks, Mathglot (talk) 20:20, 5 May 2024 (UTC)
 * ✅. This (step 2) is now moved to live. Let's wait a few days more to see if there are any problem reports, and if not, we can move ahead with the bot., would you mind monitoring for any problem reports? If they come up in the next three to four days, I can handle it, but after that, I may have spotty wi-fi for a few weeks, so if reports come in later requiring a revert, would you mind doing the revert for me? , if all goes well, I'll leave the bot step in your hands, and on your own timetable. Thanks, Mathglot (talk) 04:49, 10 May 2024 (UTC)
 * I'd be happy to look out for any reports, though what change(s) would I be reverting and what could be the potential issue? Aidan9382 (talk) 06:19, 10 May 2024 (UTC)
 * Thanks, Aidan. The edit to revert would be rev. 1223139724‎ of 04:32, 10 May 2024, which removes the four archiving params archive_bot, archive_age, archive_units, and minthreadsleft from the set of parameters in the template. It's hard to know what issue might turn up, but likely it would be related to the presence (or absence?) of one of those parameters that hasn't been foreseen in any of the test cases, so I can't know for sure. But if something does turn up, I imagine we'll likely hear about it here eventually. Mathglot (talk) 06:48, 10 May 2024 (UTC)
 * Mathglot, it's been around a week. Any issues with moving forward with the bot work? — Qwerfjkl  talk  19:17, 16 May 2024 (UTC)
 * None I am aware of; I think we are good to go. Mathglot (talk) 04:20, 17 May 2024 (UTC)
 * Mathglot, sorry for the delay on this. Am I correct that this is just a straight removal of those 4 parameters from all uses of Talk header, and there's nothing else to consider? — Qwerfjkl  talk  16:08, 5 June 2024 (UTC)
 * No worries, there's no particular urgency. And yes, you're correct, as the template no longer looks at them at all (except for the param validation section, in order to avoid throwing an error on legacy transclusions that still use them). That said, if there are a lot of uses of those params, perhaps it's wise to do a small initial run to see if anyone squawks. It seems unlikely, but I suppose it's not impossible that some other template is using Tmpv to gather the content of those params and do something with them. I'm probably worrying too much, and if you want to just go for it, I think we are pretty ready. Mathglot (talk) 18:53, 5 June 2024 (UTC)
 * Mathglot, . — Qwerfjkl  talk  20:52, 5 June 2024 (UTC)
 * Nice, thanks. Monitoring the trials. Spot-checked about a dozen, and noticed it missed one param in this edit at Talk:Barack Obama, and two in this at Talk:Acupuncture. Seems to be param units in both cases, plus bot in the latter case. I'm wondering if a leading blank is implicated. Mathglot (talk) 03:24, 7 June 2024 (UTC)
 * ┌───────────────────────────┘ Mathglot, I think the bot's taken care of as many of these as is possible to find with a simple search. If you make a tracking category I can run the bot on that. — Qwerfjkl  talk  14:59, 18 July 2024 (UTC)
 * For what it's worth, I find these watchlist-flooding edits annoying at scale, and would rather have bots wait until they have meaningful changes to make before pushing through site-wide changes like this. (Cf. WP:COSMETICBOT.) –jacobolus (t) 23:18, 18 July 2024 (UTC)
 * jacobolus, bots provide a real service, making many small, repetitive, beneficial edits that would be very annoying and time-consuming for human editors to make. Each bot edit leaves a human editor with a bit more time to do something productive that requires some thought, and is more enjoyable and rewarding for the editor. Those are good reasons to support bot activity. That said, having bot edits flood your watchlist can be annoying, as well. Fortunately, you can easily fix that in a single procedure, by turning off bot edits in your watchlist, as described at Help:Watchlist. That should permanently solve the problem for you, reduce the flooding (except when human editors do the same thing), and leave a lot more room on your Watchlist for actual, human edits that you'd prefer to see. The more these repetitive tasks can be offloaded from human to bot, the better your watchlist will be, and the more we can all concentrate on more productive tasks. Mathglot (talk) 01:09, 19 July 2024 (UTC)
 * Sure, but this particular bot action of removing a recently deprecated no-op parameter does not serve any urgent or very important purpose, and large-scale trivial bot editing also imposes an attention cost on many human editors site-wide. Again, please read WP:COSMETICBOT. "Just stop watching bots" is not good advice. Bots routinely screw things up.–jacobolus (t) 02:58, 19 July 2024 (UTC)
 * Not sure what you mean by "Bots routinely screw things up", but if you know of a specific problem with a particular bot, it would be helpful if you could raise a discussion at the talk page of the bot user, at least to report what your experience has been that was sub-par with that bot. If nobody tells them, they can't fix it. Mathglot (talk) 08:18, 19 July 2024 (UTC)
 * What I mean is, it's worth having human editors keep an eye on what bots are doing, because bot edits are not always improvements to the encyclopedia. It's certainly fine if some people want to ignore bot edits, but that't not really a good reason to flood watchlists of the others. Anyway, this particular example isn't too big a deal, but in general bot operators should read WP:COSMETICBOT and consider whether they can defer this type of edit and combine it with something substantive. –jacobolus (t) 13:03, 19 July 2024 (UTC)
 * Jacobolus, I could monitor RecentChanges and only edit pages right after a normal edit, but that adds a huge burden on me for an otherwise trivial task. — Qwerfjkl  talk  16:10, 19 July 2024 (UTC)
 * In my experience, I find it much more worth keeping an eye on what humans are doing, because human edits are not always improvements to the encyclopedia. While I have reverted a handful of bot edits over time, the numbers are orders of magnitude lower than the number of human edits I have reverted for just cause. On an even smaller number of occasions I have discussed improvements with bot operators, and if you see a problem, you can, too. This is all somewhat o/t for this page, but could be useful at WT:BOTN if you see a general issue that you would like to raise there. Mathglot (talk) 16:39, 19 July 2024 (UTC)
 * Qwerfjkl, that sounds like a good idea; I'll look into it. Mathglot (talk) 00:45, 19 July 2024 (UTC)

Is there a clear summary of the proposal / intended change?
I don't really understand what is being proposed here, what has been implemented so far, what will be implemented in the future, etc.

I would strongly recommend that this template:


 * 1) Should not show the name of the archive bot by default, or ideally not at all. That information is a distracting reader-irrelevant internal implementation detail. At the very most, mention of the bot's name should be opt-in.
 * 2) Should show archive time in units rounded so that the number is a small value. That is, we should show "3 months" instead of "90 days", "2 years" instead of "730 days", etc.
 * 3) Should skip describing the min threads to archive, min threads left, max archive size, etc. Nobody who is just reading the talk page does or should care about these

In general, any very widely used talk page template should strongly prioritize eliminating, hiding, and minimizing the space use and distraction of non-essential information. Adding gratuitous configuration metadata is a reader hostile regression. –jacobolus (t) 22:06, 11 April 2024 (UTC)


 * All information aside from archive time on this one is only located in a tooltip (you can see an example on this page's header if you hover over "Auto-archiving period"), so in this case, unlike Template:Archives, I don't see the harm here because it's only visible when you're looking for it. I agree completely with your second point. Tollens (talk) 22:16, 11 April 2024 (UTC)
 * Got it. I didn't realize it was a tooltip. (The tooltip seems fine!) I was coming here after seeing the change to, where the bot name is now presented by default on every talk page using that template. –jacobolus (t) 22:22, 11 April 2024 (UTC)
 * @Tollens I'm not sure if this was different when you answered, but this is now no longer true. I have explicitly set "" on the template and in the body of the banner (not the tooltip) it says "Auto-archiving period: 1095 days", which was automatically pulled from the bot config.
 * This is a serious bug in my opinion, a reader hostile regression made without consensus. It must be fixed or reverted. The date must either (a) be automatically converted to a human-accessible unit, or (b) the explicit template parameters must be respected. –jacobolus (t) 20:49, 22 May 2024 (UTC)
 * First off, this discussion / these discussions are extremely hard to follow, with progress made in many places at once, including this sub-discussion that's placed in the middle of something from April. I'll simply start a new header below to say my piece, and let everybody decide for themselves how relevant it is to what various work they're currently doing. CapnZapp (talk) 05:39, 23 May 2024 (UTC)
 * Agree with your 2nd point here, but that is another proposal that should start off a new, top- level section as a discussion or edit request. Imho, it’s not a good idea to keep piggy-backing on additional requests onto an earlier request, which isn’t completed yet, especially in the case of a template with such high usage and visibility. We need to let this one complete, without additional complications. That doesn’t mean you can’t start another section now as it can be discussed and implemented completely independently from the current request. Does that help? Mathglot (talk) 00:28, 12 April 2024 (UTC)

Convert Cluebot hours to days?
One thing that becomes evident with this change, is the somewhat less friendly units used by Cluebot; how long is 2880 hours, anyway? This is not a big deal, but as long as we are talking about these changes, it would be an easy fix to display the hourly total as days (approx. days, decimal days, rounded days; preference?) if it exceeds some threshold number of hours. I think after 96 hours, I pretty much lose it, not sure about anybody else. If you want to see some live examples, check out the bot notice at any of these Talk pages which all use Cluebot: Talk:The Exorcist, Talk:List of colors, Talk:Toronto, Talk:Switzerland, Talk:Macedonia. We could display days in the notice, and exact hours in the Tooltip, if desired. Mathglot (talk) 08:48, 29 February 2024 (UTC)


 * I'd suggest rounding anything over 23 hours. I can convert 36, 48, 72 hours, etc. in my head, but it takes some thought. Would rather see that in 1.5 days, 2 days, 3 days format. – Novem Linguae (talk) 10:02, 29 February 2024 (UTC)
 * Sure, this sounds fine. Even if it involves some loss of precision, I have a hard time conceiving of any situation where it would matter that a talk pages be archived at a large but precise number of hours.  Sdkb  talk 14:51, 29 February 2024 (UTC)
 * Especially as there's no way to know what kind of delay might be involved before the bot gets around to visiting the page. Mathglot (talk) 23:48, 29 February 2024 (UTC)
 * Delays should not be taken into account. If a page claims archiving will happen after 6 or 18 or 30 or 60 hours, we should probably say that even though the actual arching cadency is just once a day... Cheers CapnZapp (talk) 14:35, 1 March 2024 (UTC)
 * ✅. A description of this new functionality can be found at ; please have a look and adjust as needed. Mathglot (talk) 07:02, 1 March 2024 (UTC)
 * I would not round any hour figure lower than 72. Starting to round already at >23 feels unnecessarily aggressive. CapnZapp (talk) 14:32, 1 March 2024 (UTC)
 * No worries; it's incredibly easy to change it to any figure that comes out of consensus here. Mathglot (talk) 21:22, 1 March 2024 (UTC)
 * For archiving bots that use hours as the default units, they are converted to days, rounded to the nearest half-day This I take to mean ANY number is rounded to a multiple of 12 (half a day). I would suggest a more conservative start. Do not round any hours-number lower than 72 for starters, then let consensus drive rounding of lower numbers. The other way round assumes we will revisit the subject later. I think now is the only time you will hear voices to avoid rounding smaller numbers, so please consider this to be the consensus you'll get. CapnZapp (talk) 09:11, 2 March 2024 (UTC)
 * Thanks for pointing that out; I neglected to mention the > 23 threshold, so I tweaked the doc, which should be accurate now; sorry for the confusion. As far as what the threshold should be, 72 sounds fine, so does 96, so does 24; it's easily changeable and I have no strong preference myself. Mathglot (talk) 10:00, 2 March 2024 (UTC)
 * If my voice is the only voice with an opinion: start with 72 and change it if somebody asks for it. Not the other way round, partly because doing it that way in effect willfully ignores suggestions you are getting now. Why can't suggestions now hold equal weight to those that you (probably won't) get later? Thanks CapnZapp (talk) 14:04, 29 March 2024 (UTC)
 * Any multiple of 24 hours should definitely be presented as X days; this is significantly more likely to be the intention than hours per se. Odd multiples of 12 hours should generally be presented as X.5 days, though maybe 12h or 36h can be left as exceptions. If someone has some weird value like 20 or 50 hours then maybe show it as hours. –jacobolus (t) 22:32, 11 April 2024 (UTC)

minimum number of sections archived
Related to this, there is one nugget of information you can configure the archive bots with, but wasn't possible to convey through the templates:

If you tell the bots to not archive until, say, 2 sections are eligible, then its possible for users to not understand why the bot isn't archiving.

Say there are 5 talk sections. All are older than the number of days specified. But the settings say "keep at least four sections and only archive two or more sections at a time." This means no archiving is done for now, since you need a sixth new talk discussion in order to archive two of the stale discussions and still leave four on the page.

(PS. Configuring the bot to keep 4 sections is very useful since the table of content is per default only generated on pages with four sections. Configuring the bot to only archive two sections at a time is relatively useful to avoid cluttering the history page with lots of archival edits, which can come across as the bot being "too aggressive" in its cleaning)

Proposal: tweak this new wondrous automatic display of the actual bot settings to also tell the user if the bot will only archive two or more sections at a time. Specifically when 2 (or more). Cheers CapnZapp (talk) 12:09, 1 March 2024 (UTC)


 * minthreadstoarchive is currently displayed in the tooltip (along with the specific bot that does the archiving). It's not ideal, but when we designed the merge, keeping the display very concise was a top concern (for good reason, given the tendency for talk page banner bloat), so that's what we went with. Thinking in terms of a talk page user, I can see why it might be useful to know the auto-archiving period, but it's harder to envision reasons why it would be helpful to know the minthreadstoarchive or the specific bot that does the archiving.  Sdkb  talk 20:30, 1 March 2024 (UTC)
 * Capn, it would be a fairly easy upgrade to add what you are suggesting, but as Sdkb points out, it's already there in the tooltip, and I think the trade-off design of lean-and-mean visible part, and the rest of it in a tooltip was a good decision. Other than tooltips are not easily visible from mobile, not sure if there are other accessibility issues with tooltips; it had occurred to me that along with this change one might add alt text for screen readers, but I didn't want to overload the proposal, at least initially, with too much stuff. But it's something to consider, moving forward. Mathglot (talk) 21:31, 1 March 2024 (UTC)
 * Cap'n, since you mentioned wondrous—I also think it's pretty cool—I wanted to spread the credit where it's due. While in theory this could have been implemented earlier through use of a set of complex regular expressions, that would've been difficult to develop, test, and maintain, and might've been fragile. What really made the archival config auto-detection feasible here was the upgrade to Module:Template parameter value developed by, which in turn enabled construction of HasTemplate. There is still some regex code in the archive bot parser here, but it's straightforward and not the tangled mess it would've been had we not had access to this upgrade. While the Module upgrade was in progress, I didn't even imagine it being used here (had something else in mind) but after it was done, a little light turned on and I realized it was now possible, and not even difficult, to add the config detection and parsing. So that led in a pretty direct line to the changes here. I think the Module upgrade will have beneficial knock-on effects elsewhere, so spread a little love in Aidan's direction. Sdkb will recognize one opportunity in the somewhat clunky WikiProject detection in find sources for domain selection, and I predict others will come to light. Mathglot (talk) 22:18, 1 March 2024 (UTC)
 * Okay at first User:Sdkb (and User:Mathglot), I thought you meant this functionality had been recently added. But looking at an example page Talk:Gravity (2013 film) I don't see it. The tooltip states "Discussions with timestamps are automatically archived by lowercase sigmabot III after 120 days of inactivity when more than 5 threads are present." There is no mention the bot will archive only when more than 1 thread is eligible; for this page, the param is set to 2 So a reader can be left completely bewildered and not understand why the bot "isn't working" when it isn't archiving the oldest section once a sixth discussion is started, when in fact, it IS working: to keep down the number of archival edits; it will only step in once a seventh discussion is started, if it can then archive two discussions in one sweep. It's just the information that is inadequate. This is the same as when the talk header template first was reworked - support for every param except minthreadstoarchive. Unless there's something strange going on and I don't see what you guys are seeing? (I'm using legacy Vector if that matters) Cheers CapnZapp (talk) 09:27, 2 March 2024 (UTC)
 * I see what you are saying, and all I can say is, the proposal that is the object of this discussion was, at least at first anyway, solely about replicating existing wording from whatever the template was doing before, and just making sure to get accurate values directly from the config and not from template parameters which often go out of sync. If the bot notice didn't say anything about minthreadstoarchive before, then it won't say anything about it after the change, either. I see your point about reader confusion, and for whatever reason, there hasn't been a decision to address that in the bot notice previously, so we aren't addressing it either, in order to stick to previous behavior as much as possible.
 * My suggestion would be simply to start a new top-level discussion proposing your change. Then, regardless whether the bot config-detection function is kept or not kept, your proposal about minthreadstoarchive would stand on its own and could succeed independently. Or, you could just try a bold change and see if it sticks. That's my take; I wonder what Sdkb will say about this. Mathglot (talk) 09:50, 2 March 2024 (UTC)
 * Given that this is a TE-protected template with 500k+ transclusions, I wouldn't recommend bold editing. I'd be interested to see a concrete proposal (i.e. a mockup of the design you'd like) for displaying minthreadstoarchive, but as I said above, I'll be skeptical of its value (and more so the more prominent the display).  Sdkb  talk 16:29, 2 March 2024 (UTC)

You are claiming minthreadstoarchive is currently displayed in the tooltip. I don't see it. I am not asking for this parameter to appear in the template. Just the tooltip text. I don't see why this could be controversial or why I need to start a new discussion or create a mockup? (Unless you mean simple wording along the lines of, still using Gravity as my example; "Discussions with timestamps are automatically archived by lowercase sigmabot III after 120 days of inactivity when more than 5 threads are present if more than 1 thread is eligible for archiving.") I'm simply thinking that since you're already editing the relevant code and you are the editors with the relevant knowledge (if you can extract the other params you can extract this one), why not suggest fixing this once and for all... CapnZapp (talk) 16:26, 3 March 2024 (UTC)


 * @CapnZapp, if you go to a page like Talk:Algeria and hover your cursor over the text that says "Auto-archiving period", do you see the tooltip that reads Discussions with timestamps are automatically archived by Lowercase sigmabot III after 90 days of inactivity when more than 4 threads are present? That's what we're referring to. Cheers,  Sdkb  talk 00:50, 4 March 2024 (UTC)
 * Interesting; regarding Gravity: when I hover over Talk:Gravity's bot notice, I see it mentioning 365 days of inactivity and 10 threads; is that not what you see? The config hasn't been edited since January 10, but it was 180/none before that. Did you mean a different page? Mathglot (talk) 04:47, 4 March 2024 (UTC)
 * I think CapnZapp is referring to a completely different thing than Mathglot and Sdkb here. There are two different parameters that relate to a number of threads – one (the one currently displayed) is for the number of threads which have to remain on the page after archiving (for example, if this parameter was 2 and there were 5 threads on the page, all of them old enough to archive, only 3 threads would be archived). The other one, which I think CapnZapp is referring to, is for the minimum number of threads that are allowed to be archived with a single edit by the bot (as another example, if that parameter was 2 and there was exactly one thread old enough to archive, the bot would not archive it at all, but once there were 2 or more eligible threads the bot would archive them all). Tollens (talk) 10:07, 4 March 2024 (UTC)
 * Thanks for that clarification. Yes, agreed; but if the previous incarnation did not address that, should we be doing so? On the + side, strike while the iron is hot; on the - side, just trying to reproduce the original bot notice, which presumably had consensus previously (even if silent), without any significant changes, but more accurately. To the extent that a proposal represents a change to previous behavior, is this thread the right place to deal with it? I can see both views, but I wonder, given the visibility of the template, if additional changes to a highly visible template would require additional consensus? I don't know the answer to that question. Mathglot (talk) 10:39, 4 March 2024 (UTC)
 * Sdkb I see it. I also see that the bot instructions for that particular revision has no minthreadstoarchive parameter set. CapnZapp (talk) 16:03, 4 March 2024 (UTC)
 * Tollens I am indeed referring to minthreadstoarchive and not merely minthreadsleft which Talk header have had support for a while now. I think I have been consistently using minthreadstoarchive in my request but feel free to point out if I have accidentally mentioned a different parameter. CapnZapp (talk) 16:07, 4 March 2024 (UTC)
 * I agree that you've been using the correct parameter name – just trying to clear up the apparent confusion. Tollens (talk) 17:37, 4 March 2024 (UTC)
 * So, if it uses both, how would you word that? Mathglot (talk) 20:33, 4 March 2024 (UTC)
 * I think that was what CapnZapp meant by their example: "Discussions with timestamps are automatically archived by lowercase sigmabot III after 120 days of inactivity when more than 5 threads are present if more than 1 thread is eligible for archiving." (emphasis mine). Tollens (talk) 21:02, 4 March 2024 (UTC)
 * Mathglot: seeing that there's even confusion about which parameter we're discussing let me first ask you -respectfully- to make absolutely certain you understand the request I am making (instead of the request you might think I am making). To be clear, I am not asking for any visual change of the talk header template (and related templates). Only a more informative tooltip. Your caution to me suggests you might still think I'm asking for a more intrusive change than I am actually asking for. I honestly don't feel I need to make mockups - the template's appearance will remain unchanged. I honestly don't see why we would need a whole new round of consensus - again, it's only the tooltip that in a minority of cases would convey a little bit more information. Using Gravity movie as my example, if a page's bot instructions contain 2 I would like the tooltip to say something along the lines of "...if more than 1 thread is eligible for archiving". As stated previously!  I cannot do more than make sure I am using the right parameter name. I cannot help if people read that as referring to other parameters? Again, if y'all have any advice on how I can be more clear please advise - I thought I was crystal clear but apparently not so? CapnZapp (talk) 16:22, 4 March 2024 (UTC)
 * I'd support just making this change. I don't think anyone will be upset by (or, for that matter, notice) a change that's only inside a tooltip. Tollens (talk) 17:39, 4 March 2024 (UTC)
 * Yes, they are very similarly named, and I think I got confused. Especially if it's just inside the Tooltip, I agree with Tollens that probably hardly anybody will even notice. Mathglot (talk) 20:31, 4 March 2024 (UTC)
 * Parsing is working in the subtemplate sandbox; next is further testing and moving the subtemplate sandbox to live, deciding what wording you want, then we have to add the wording to the Talk header sandbox, add new test cases for it, and then move the new TPH sandbox to live. After that, similar for Template:Archives: new wording (not a tooltip), then sandbox and test it, and release to live. Both templates use the same parser. The blocking dependency now is deciding on the wording for Template:Talk header, presumably in the tooltip. Mathglot (talk) 02:35, 20 March 2024 (UTC)
 * I'd support CapnZapp's suggested "if more than X thread(s) is/are eligible for archiving" appended to the end of the existing tooltip. Tollens (talk) 02:58, 20 March 2024 (UTC)
 * How about: "If X or more threads are eligible for archiving"; that will save having to add code for verb number agreement. Also, I think we should only generate it when X >= 2. When X=1, adding the phrase or not adding it describe identical constraints, so the X=1 case doesn't need to be shown, and it might even make it worse as viewers would probably have to pause and try to parse out what it means. Mathglot (talk) 05:38, 23 March 2024 (UTC)
 * Oh, right, of course – I forgot that archiving was when there were &geq; the number specified in the parameter, not >. Your wording looks good to me. Tollens (talk) 06:10, 23 March 2024 (UTC)
 * Only saying something when 2 (or more) was part of my original proposal, so, yeah. CapnZapp (talk) 17:31, 26 March 2024 (UTC)
 * I would strongly recommend suppressing min threads to archive, even inside a tooltip. It's not reader-relevant information, even for the most pedantically config-obsessed readers. The only reason this parameter exists is to reduce the amount of archive-bot watchlist noise, and people only need to care about this parameter if a miconfiguration is causing some problem, either (a) if the bot is doing an excessive amount of archive edits which are distracting people by spamming their watchlists or (b) if the bot isn't archiving old threads for too long because the threshhold is too high. In either case it only comes up when someone is having a problem with it. It's otherwise unnecessary to know or care about the setting of this parameter. –jacobolus (t) 07:15, 14 April 2024 (UTC)
 * The same is true (perhaps more so, even) of the specific bot doing the archiving. I don't see why we would not include all available information in a tooltip which will only be viewed by people wanting more information. It isn't as if it's cluttering up the page. Tollens (talk) 07:25, 14 April 2024 (UTC)
 * Leaving out the bot name also seems beneficial, but at least doesn't require coming up with the kinds of confusing phrases proposed above for min threads to archive. –jacobolus (t) 08:03, 14 April 2024 (UTC)
 * Then what do you intend to leave in the tooltip? I just don't see the harm in providing more information in a tooltip, even if I were to assume that nobody cares, which I don't necessarily think is true. Tollens (talk) 08:04, 14 April 2024 (UTC)
 * I don't really care about the tooltip (getting the dates human readable is more important), but it seems substantially unnecessary overall. Try to remain focused to the extent possible on making changes which concretely benefit readers and cutting out every bit of extraneous stuff on highly used templates which doesn't directly benefit readers, rather than on just adding as many things as possible just for the sake of having more things. In aggregate the latter ends up being actively harmful. –jacobolus (t) 08:20, 14 April 2024 (UTC)
 * It isn't clear to me what it is you want; on the one hand, you say you don't care about the tooltip, but then you say it's unnecessary and we should cut extraneous stuff, and that it's harmful. In this or any template, of course we want to benefit readers, and it's hard to see how a tooltip is harmful to anybody: certainly not to the 60% of our users who are mobile and never see it, or to the other 40% who must actively move their mouse over it in order to activate the pop-up text. Who's getting harmed here? Finally, the tooltip has a few years longevity without objection, so I don't think its going away without a clear consensus to remove which would likely require a specific proposal in a new section and an Rfc. Mathglot (talk) 15:27, 15 April 2024 (UTC)
 * My point is that anyone adding material to widely viewed templates should try to be careful about what they add to make sure that it has significant value, because every additional bit of extra material that might benefit a few people also imposes a cost (distraction, confusion, etc.) on a large number of others. The bias should be toward being conservative, including fewer features, using less space, etc.
 * Putting stuff in a tooltip is significantly better than putting it elsewhere, but even within the tooltip try to consider whether each piece of information is really necessary, because the more information you cram in there, the harder it is to make sense of any particular piece. Try to put yourself in the position of a talk page reader. Do you really care about the "min threads to archive" setting on talk pages you visit? How often? How much of a burden is it to just look at the source if you do? –jacobolus (t) 15:48, 15 April 2024 (UTC)
 * Generally I agree with your philosophy of parsimony, but I don't care that much what is or isn't in the tooltip, as long as what is there is accurate, and under the previous design, often it was not, which is how this all got started. That said, I do mouse over the tooltip and like seeing the age and units, which I know I can rely on now as accurate with the latest changes to the template. The other bits of tooltip info don't bother me personally, and I don't care if they stay or go, but that's not up to me. Mathglot (talk) 16:29, 15 April 2024 (UTC)

Testing progress
This is developed and now in test mode. I tweaked the wording slightly which seemed to flow better. Here's a summary of status and pages involved: More eyeballs and more tests are needed; this is needless to say a highly visible template and we need to test the new functionality, as well as regression to ensure nothing is broken before going live. I need to set this aside for a while, so any help appreciated. Add tests directly to the test page Talk header/testcases4, and please examine or run regression tests on the first three testcase pages as well; please note what works/doesn't below. Doc on page testcases4 is still thin; feel free to adjust as needed, and if there is anything inscrutable, please lmk. Mathglot (talk) 02:10, 29 March 2024 (UTC)
 * Functionality – description of requested change (in this section, above)
 * Archive bot config parser sandbox – now parses minarchthreads/minthreadstoarchive
 * Template:Talk header/sandbox – points to parser sandbox, and has new tooltip code added for minarchthreads/minthreadstoarchive
 * Testcases, tab 4 – pre-existing and new tests for archiving notice functionality
 * test cases for Talk pages having a Miszabot config – no testcases yet; t.b.a.
 * test cases for Talk pages having a Cluebot config – (twelve tests in place, passing).


 * Just added the tests on tab 4 for talk pages with a Miszabot config, and they all seem to be passing with the version in the sandbox. Looking through tabs 1 and 3, everything appears fine (tab 2 is now completely redundant and could/should probably be deleted). The one thing I did notice that is not really as expected is that when the number of threads to keep on the page is 1, the grammar is wrong (see Talk:Conspiracy theory), and when it's 0, there shouldn't be a message at all but there is (see Talk:Cold fusion) – I should be able to fix both pretty easily. Tollens (talk) 01:14, 30 March 2024 (UTC)
 * That fix is now done. Tollens (talk) 01:26, 30 March 2024 (UTC)
 * Edit-conflicted with you, so my test is invalid as I don't know if it took place after your fix, but the first part of the message was this:
 * Oh, that's great; thanks for the testcases update, glad they worked. As far as minthreads and the two Talk pages, that could mean the legacy code was doing that, as the minthreads stuff is old code and was not changed for this upgrade (although the conditional logic around it was). Looking at legacy rev. 1193759647‎, there is no adjustment for sing/plural; not sure if it handled the number of threads correctly or not at that point. But I am not seeing what you do: in both test methods, I see these results for Cold fusion:
 * CF live:
 * CF sbox: Discussions with timestamps are automatically archived by lowercase sigmabot III after 180 days of inactivity.
 * Post-ec again: that sandbox test of mine could've been run after your fix, so that is meaningless; but the live test showed that problem before; anyway, good that you've fixed that. I've maybe missed something from your message, as I feel I have two many balls in the air; did I? Mathglot (talk) 01:51, 30 March 2024 (UTC)
 * If that was the result you got, you definitely ran that test after it was fixed in the sandbox, it wouldn't have worked before this change. It was certainly the old version that was broken, I agree nothing that's been done related to this changed it. I don't think you've missed anything. Tollens (talk) 01:58, 30 March 2024 (UTC)

Was just poking around your new test cases, and found a new one at Talk:Hurricane Florence with minthreadstoarchive=7. It doesn't test the new code path, because the config defines the archive names as using the date style, and Talk header doesn't display anything for that case. But, we still have access to all the config params and if we wanted, we *could* still display the bot notice in that case, maybe even in plain text not as a tooltip, as a way for Talk header to display *something* even if it can't show the links. For that matter, it wouldn't be that hard to reconstitute the actual archive names based on parsing the Archive param, but this is sounding more and more like a new proposal and off-topic with what we are testing here, so I think I'll drop this for now. I just wanted to get that out there, before I forgot about it, so we can take it up again if we want later after the dust has settled on current stuff. Mathglot (talk) 02:15, 30 March 2024 (UTC)

Just to chime in regarding the cutoff for rounding ClueBot: it appears the code is using 24 hours. Only User:Novem Linguae suggested this. I have suggested 72 hours instead. Nobody has objected, but also, your response so far has been "it's incredibly easy to change it to any figure that comes out of consensus here" which is nice, but also kind of ignores my message. How about doing that which is so incredibly easy, and setting the number to 72 before finalizing testing, and then waiting for consensus to change it? CapnZapp (talk) 21:27, 4 April 2024 (UTC)

Note: the test code in the sandbox for adding this functionality has been removed in order to attend to a more important issue (see below). The change will need to be re-added and retested in the sandbox. before moving ahead. Mathglot (talk) 06:15, 14 April 2024 (UTC)

purpose of the archiving bot information
First off, this information was once presented using separate templates that have now been removed with the justification their functionality is integrated into this template.

But when those templates were removed, there were zero talk of then regressing the information, losing valuable functionality.

So let's discuss: what is the purpose of presenting archive bot parameters to the end user, the non-technical person?

It is to give him or her enough information to understand when and where discussion topics will be archived. (And, of course, the basic fact that they will get archived automatically; with the implication "you don't need to archive this page manually, the bot will come round to doing the job for you eventually".)

In order to perform this job, the user needs to be able to understand subtle things, like the bot being instructed to keep at least four talk sections on the page, even though some of them are older than the cut off point (the 90 days or whatever). This is very useful because it keeps the TOC - the TOC is automatically hidden on pages with 3 or less sections, and archiving ALL sections can be confusing for the beginner, since it now isn't immediately apparent where you're supposed to add your own section if there aren't existing sections that show you how it's supposed to look.

Similarly, the user needs to be told things like "the archive bot only acts when there are two or more sections eligible for archiving", commonly done to keep down the archive bot activity (without it, you can end up with History pages where every other edit is made by the archive bot. If you find this zealous cleaning distracting and frankly completely unnecessary, you tell the bot to only archive when multiple sections are eligible)

Now I hear the call to minimize and remove these "technical" pieces of information that "no ordinary user" needs to know.

''But that wasn't the deal when the previous specialized templates were taken from us. ''

If you make this template display only "bot info light" then you absolutely should consider restoring the more specialized templates we've lost where editors can once more show the user the actual specifics, ideally with no calls for "users don't need to know this". The whole point is for users to understand why their talk pages are or are not getting archived, and having to click "edit" and look at the actual code would be a shitty solution.

Don't do a bait and switch here. Don't first integrate functionality in general templates, and then argue the information is too specific for said general template, ending up with a dumbed down information display and no way to convey detailed archiving parameter info!

Or rather, if you do, that's fine if you then agree that perhaps integrating the functionality into an overly-general template (and few templates are as multi-purpose, dare I say bloated, and general as this one!) wasn't the best call, and reinstate more specialized templates for more specialized usage. Thank you for reading.

CapnZapp (talk) 05:56, 23 May 2024 (UTC)


 * Wait, what? I am almost 100% certain no information has been removed. In fact, I am pretty sure information has been added. What information do you think has been lost, and where was it displayed? Tollens (talk) 06:13, 23 May 2024 (UTC)
 * Hello. I am talking about calls to simplify/hide/remove the information given regarding archival bots. Since this information is now part of a very general template, I can certainly understand the viewpoint. I just want to post a heads-up that this reduction/removal of information details wasn't part of the deal when it was proposed to merge functionality into Talk header that previously was found in separate templates; templates whose specialized nature naturally meant nobody called for the information (the archive bot parameters) to be simplified/hidden/removed. Have a nice day CapnZapp (talk) 08:11, 23 May 2024 (UTC)
 * Ah, I see; you aren't saying that anything has already been removed, you are saying that nothing should be removed. I agree. Apologies for the misunderstanding. Tollens (talk) 08:16, 23 May 2024 (UTC)
 * Well, my point is that if there is consensus for only displaying simplified archive bot parameter data, then it's time to reconsider the decision to merge the various archive-specific templates into this. Or rather more to the point: the decision this template now supplants those and that therefore those templates could (and were) deleted as redundant. The deal was never "let's merge into Talk header and later get rid of the info entirely", to exaggerate a tiny bit. CapnZapp (talk) 10:26, 23 May 2024 (UTC)
 * Those templates should never have existed. Information presented at the top of ordinary talk page should be mercilessly culled to only the clearest and most essential. Shoving confusing and essentially useless information (such as how many threads the page will grow to before the bot archives it) in readers' faces is an attention tax on every page reader which is especially steep for new readers but also imposes a burden on long-time readers. –jacobolus (t) 20:34, 5 June 2024 (UTC)
 * I don't mind this template getting its archive bot info dumbed down, just as long as the templates that used to show the full information are un-deleted (and properly updated to reflect recent improvements). Cheers CapnZapp (talk) 10:30, 23 May 2024 (UTC)
 * I agree that if consensus leads to simplifying output of this template, the merged ones should be recreated. At this point, I don't see who stands to gain from such simplification (especially since most of it is hidden) but I don't feel strongly about it either way. I can imagine requests going in the other direction, making explicit what is currently hidden, mostly from mobile users who don't have access to hidden info, iirc. Mathglot (talk) 02:01, 3 June 2024 (UTC)

Archive timing information appearing in the talk header should be human readable
There was a complaint when I brought this up in response to some other conversation, so let me make a dedicated thread instead.

This template has suffered a very serious regression in recent months. It used to be that the template could be configured to show e.g. "Auto-archiving period: 3 years" or "Auto-archiving period: 8 months" by explicitly setting the archive_age and archive_units parameters. Now those parameters are ignored, and the the bot instead only directly shows human-irrelevant units as directly specified in machine-readable format for bot configuration, for instance "1095 days" or "243 days".

This is a reader-hostile change which was made without consensus and as far as I can tell without even much editor input.

Either (a) the template should continue to allow manually overriding these reader-hostile date displays, or (b) the template should be coded to convert machine-readable units to human-readable units.

The machine-readable units also appear separately, in the tooltip when someone hovers "Auto-archiving period". I don't care one way or the other if these remain in the precise format specified in the bot config. –jacobolus (t) 20:48, 5 June 2024 (UTC)
 * Seems reasonable. The problem with allowing the value to be overridden is that in the overwhelming number of cases, the correct values were being overridden with old, stale, incorrect values, and no one gains from that. There isn't an obvious way to determine which overrides are not stale and therefore should be carried out. But reducing large values into other units where possible seems like a good idea. Mathglot (talk) 02:38, 9 June 2024 (UTC)
 * Do you have evidence for this "overwhelming number of cases" claim? Every page I can remember looking at in the past however many years had a value matching the bot config. (Much more common was to not include these parameters at all, whereupon they would not be mentioned in the visible box, which is frankly also fine.) Most of the editors who change bot configs will also change the template if they notice it, and if they don't someone else easily can. Even where they disagree, the difference is pretty benign. Bot configs are not something that ordinary readers should much be worrying about. –jacobolus (t) 03:04, 9 June 2024 (UTC)
 * I don't disagree; ordinary readers probably rarely look at it. And if the difference is benign, and editors don't even look at it, then why even have this discussion? If we wish to change it at all, it seems self-evident that having the correct information in the bot notice is better than having the wrong information. If nobody looks at it or nobody cares, then we haven't changed anyone's experience and it doesn't matter. And if one person cares and notices, then their experience will be a little bit better. At that point, it becomes a decision of whether it's worth the investment of time to do it at all.
 * But it seems like we are talking about something else now, and not your original proposal regarding friendlier units for time intervals, which seems like a good one. Also, please keep in mind that Wikipedia is a volunteer project. In presenting your proposals for improvement, it might be more collegial to use terms like more user-friendly and less user-friendly, and avoid terms like reader-hostile. Anything that is an improvement in some way over the previous version or improves the reader or editor experience is a good thing, and the "reader-hostile" version we have now was once an improvement when it was created over what we had before, even if it is not perfect, and I appreciate the volunteers who brought it to that point. That doesn't mean things cannot be improved even further (see WP:NODEADLINE) and I appreciate your interest and energy in pushing for greater clarity for users, a goal that I share with you; it's just sometimes a matter of paying attention to how that desire for improvement comes out when describing the kind of improvement you wish to see. Thanks, Mathglot (talk) 02:01, 10 June 2024 (UTC)
 * The version we have now is not an improvement, but a clear regression, in my opinion. That's my whole point here. It should either be reverted or otherwise fixed. –jacobolus (t) 02:46, 10 June 2024 (UTC)
 * Sorry, I am having a harder and harder time figuring out what your actual objection is towards. To summarize what I think has been changed so we are working off of the same information: there was information in this template before, almost entirely hidden inside a tooltip except for the time between archives, all of which could occasionally have been incorrect (I don't really know, or quite frankly care, how often). The only change made was that the template will now auto detect the correct information. No fundamental information formatting changes were made, but units are now in the machine-readable format used in the archival template rather than respecting the human-readable units that could have been passed before. If any of that is not your understanding, could you please clarify.
 * Now, I entirely agree that units should be human-readable. In my opinion it seems obvious that this should be remedied by having the template automatically use human-readable units. I don't even think that this would be particularly hard. Assuming that change is made I believe all the information in the template will be displayed as well or better than it was before work on this change started, around the end of February. If you agree with all of that, and that is your only objection, could you please clarify that?
 * If your objection goes beyond unit display, but are still related to the changes made specifically regarding automatically detecting the archive configuration, great, could you clarify what those are?
 * If your objection goes beyond the auto detection changes altogether, or perhaps beyond this template entirely, okay, but that isn't at all what we're working on here. All we are changing is automatically detecting the archive config. If you want to have a discussion about anything other than the changes being made right now, could you please make very clear that this is the case, or alternatively and even better, hold off entirely on those objections until we finish making these changes? I am not saying you can't or shouldn't make those suggestions, just asking that you don't make them in the middle of discussions of unrelated changes. If you don't even have any such opinions, my apologies for misunderstanding.
 * I am in the same boat as Mathglot when it comes to being somewhat frustrated at how your concerns have been articulated here. For example, unless you for some reason believe that the core idea of automatically detecting rather than manually providing the archive config is bad, your above comment which suggests reverting the work entirely before mentioning that it could be fixed seems unnecessarily dismissive. Tollens (talk) 04:09, 10 June 2024 (UTC)
 * The previous version allowed people to manually set human-readable units in the visible part of the template. All of the rest of the information involved is irrelevant and can easily be looked up in the plain source. It was fine that it was previously hidden.
 * The new version overrides the manually set human-readable units, and replaces them with non-human-readable units. There's a bunch of irrelevant data now shown in a tooltip. I have no problem with that, but in my opinion it is of exceedingly marginal use.
 * Changing the units to be less legible is distracting and confusing, and makes the template worse for readers than the previous version.
 * If the template is changed to use more human-relevant units in the initially visible box, that would fix the problem as far as I am concerned. –jacobolus (t) 04:38, 10 June 2024 (UTC)
 * Alright, great. All of that makes sense and I agree with all of it. Just for your information, the tooltip did also exist before this change. I can work on getting the dates in a human-readable format at some point in the next day or two. Tollens (talk) 05:02, 10 June 2024 (UTC)
 * Awesome, thanks! –jacobolus (t) 06:59, 10 June 2024 (UTC)
 * This functionality has been created with the new template human readable duration and its accompanying module. I have changed Template:Talk header/sandbox to use it, and it appears to work fine (for an example, try previewing Talk:Switzerland with the sandbox version). The thresholds I currently have set for moving to the next units are (all of these are the last possible value which can be displayed in their unit): 59.5 seconds, 59.5 minutes, 71.5 hours, 50 days, 18 months. 24 and 48 hours are exceptions, and display as 1 and 2 days respectively. Pinging jacobolus, CapnZapp, Novem Linguae, and Sdkb, all of whom have previously expressed opinions on what thresholds should be set. I've tried to strike a balance between all of those proposals and am certainly happy to change the thresholds if these ones aren't what we all want. I know seconds and minutes aren't relevant to this template but figured I might as well include them, feedback on those thresholds is welcome too. Tollens (talk) 23:36, 10 June 2024 (UTC)
 * If one of you could change Module:Human readable duration/testcases's content model to wikitext and redirect it to Template:Human readable duration/testcases that would also be appreciated. Tollens (talk) 00:07, 11 June 2024 (UTC)
 * This seems great. Thanks Tollens! –jacobolus (t) 01:48, 11 June 2024 (UTC)
 * Since there appears to be no objection from anyone involved, would you mind merging the changes from the sandbox into the template? Tollens (talk) 05:45, 13 June 2024 (UTC)
 * No problem; will do. This is a worthy improvement which I support (and thanks very much for the great new module and template, which may have other applications). I'll get to it eventually, but it won't be right away, as there are still some outstanding issues regarding archiving wrt this template, and the Archives template, that preceded this proposal and are in progress, including one pending bot issue. Will get back to this, but if you haven't heard anything in a couple of weeks, please ping me. Meanwhile, no objections on my side if someone else wants to grab the baton. Mathglot (talk) 01:14, 14 June 2024 (UTC)

Give a big fat red error for search=yes
Given that param yes is an invalid value and does nothing, and that there are nevertheless 7,000 instances of it anyway, we ought to include code in the param validation section to prohibit this value from being added by users, and return an error message if they do. Only no is meaningful;  is not. Mathglot (talk) 02:32, 9 June 2024 (UTC)


 * Those 7000 instances are crystal clear evidence that the current API is wrong and broken. The value search=yes should be allowed, and should do nothing. This is much more editor friendly, making the template simpler to remember and use. –jacobolus (t) 03:08, 9 June 2024 (UTC)
 * I must say I don't see it that way, pretty much the opposite. All those 7,000 instances are evidence of, is that users are attempting to use a param value that doesn't exist. You could say it is "allowed", if you want to, in the same way that non-existent param value foobar is "allowed", because no error is produced currently when it is employed:


 * but whatever the user thinks that foobar does, is wrong—it doesn't do anything.
 * Wouldn't it be better to let the user know that whatever it is they wish to do by coding param yes in the Talk header, in reality it won't do what they expect? Had we had this from the beginning, then we wouldn't have those 7,000 instances right now, and editors transcluding the template would be better served. At least, that's how I see it; evidently you see it differently.
 * As far as your second sentence is concerned, yes is allowed, and does nothing; just like maybe and 20 are allowed and do nothing. I consider both of those a failure of the template to properly validate the user input, and should be fixed by disallowing them. By allowing them, we lull the user into thinking they have added a proper value which will cause the template to do something, when it will not. Not specifying what parameters do in the doc make them harder for a user to code the transclusion, and failing to call out bad param input makes the template harder for the user to use because they won't understand why it isn't doing what they expected, like maybe search only the first 20 discussions in the archives, or whatever they think 20 should do. By returning an error, they will understand that "20" is invalid input for that param, and then they can look up the proper usage by reading the doc for that parameter. So, I would say that your proposal is less user-friendly, and makes the template harder to use. As I see it, better param documentation and better param validation saves the user time. I wonder what others might think. Mathglot (talk) 01:37, 10 June 2024 (UTC)
 * Have you ever been a computer programmer? The concept of "default arguments" is a basic tool found in most modern programming languages (and where it isn't natively supported, many API designers jump through hoops to get some variant working). Anyone who ever makes APIs immediately runs into it, and a few years trying to write programs is enough to make most programmers recognize the fundamental value of the idea.
 * If your API is being constantly used "wrong", that means the API sucks, full stop. All of the users trying to use this API in the basic obvious way are giving a clear and obvious signal of the way an ordinary Wikipedia editor expects it to work. If you decide, in the face of that evidence, that you should do exactly the opposite, then you are just gratuitously inflicting pain on those people. Please don't do that. Don't put your ego above other people's comfort, when just accommodating them instead is trivial – cf. pave the cowpaths.
 * Also,  does do exactly what people expect: it shows the search box. So what we should do is add this to the documentation, mentioning that it's optional and that leaving it blank is equivalent to "yes". Then the template can be changed so that including   is explicitly supported as a no-op, and doesn't cause any error messages, linter complaints, etc.
 * –jacobolus (t) 02:28, 10 June 2024 (UTC)
 * I would agree on this one. When someone types out, I don’t see how they could possibly mean anything other than "please show the search box". Since "no" is supported, "yes" should be too, regardless of whether or not it’s the default. How people manually inserting a parameter they believe will activate what is actually default behaviour means that the API is "wrong and broken", I don’t understand, but I don’t think we should be throwing an error when a user says that they want to do something the template is designed to do. If we really want to give an error when anything other than "yes" or "no", that would be fine with me. Tollens (talk) 03:11, 10 June 2024 (UTC)
 * By "wrong"/"broken", I don't mean that the current template behavior is wrong, but rather that rigidly insisting a "search=yes" parameter to be invalid would be a wrong/broken API. My argument is a bit more general than this specific case: any time you have an API and a very significant number of users are using it in a way that is reasonable and logically coherent but not supported, then it is the API that is the problem rather than the users. –jacobolus (t) 03:19, 10 June 2024 (UTC)
 * Sure, agreed. Tollens (talk) 03:24, 10 June 2024 (UTC)
 * Whether it's throwing an error for anything other than "yes" or "no" or any other behavior, I'm fine with it if there is consensus for it. And that includes views that the current API is broken, in which case, get consensus for that and propose something you think will carry the day, and if it does, move forward with it. More light, less heat. Regarding your last paragraph about what to do with the documentation, WP:BE BOLD.  Mathglot (talk) 02:55, 11 June 2024 (UTC)
 * I hear your frustration, and wanted to address what you are saying about defaults and professional programming, I would start by underlining my comment above about Wikipedia being a volunteer project. I don't doubt that in a professional environment with a business unit determining engineering priorities, a manager coordinating design and development, programmers on payroll to create the new or changed functionality per spec, tech writers to describe it accurately for the customer base, and a QA department to check that it all meets standards of quality before going live, it likely all takes place as you describe. Even a non-profit (like Wikimedia) has that, but a volunteer project like Wikipedia has none of those things. Development here takes place haphazardly, with no business plan, coordination, prioritization, or design, by whoever is around, whenever someone feels like contributing something. Sometimes there is something like a plan (if "Whoever" feels like writing one), but with no one in authority to approve or veto it, other than the general feedback of whoever else is around, and no specific individual or group to check quality of the result. This leads not infrequently to inconsistencies or errors in the design, functioning, workability, or documentation of these templates (or modules, gadgets, scripts, and so forth) at Wikipedia.
 * Because of this haphazard workflow, there are endless problems and inconsistencies in templates, including yes/no problems of the sort you describe, even in this very template, such as with param arpol, which has the identical yes/no problem you identified, but in the other direction. So with respect to a wrong/broken API, the approach in a commercial company or in a non-profit would be to file a ticket in an issue tracking system (such as Phabricator, in the case of Wikimedia issues). But Wikipedia doesn't have that either; we just have this Talk page, and unpaid volunteers.
 * In a sense, this template issue (even all template issues taken collectively) is just a tiny fragment of a larger issue that is characteristic of a large, volunteer project. I can see that it must be frustrating for you, and there are echoes of frustration with the larger issue on your Talk page, such as your comment about how "Wikipedia is simultaneously an amazing testament to years of dedicated collaboration, and a constant stark reminder of how far short it falls of its potential". Precisely. This is no less true of templates and other engineered development aids, than it is of the bigger issue you were commenting on. That means there is plenty of work to do in both arenas, and only ourselves to do it. The buck stops nowhere; it just goes around in circles until someone grabs it or nobody does. If we don't do it, nobody will, but with collegial collaboration, we can improve the templates and improve the encyclopedia, even if neither ends up perfect or on time or consistently meets professional standards, although those are worthy goals to aspire to. Hope this helps, Mathglot (talk) 19:50, 14 June 2024 (UTC)
 * No this has nothing whatsoever to do with professional environments or QA departments vs. volunteer projects. This is a basic fundamental design flaw which you are proposing to make much worse at other editors' expense.
 * (I asked about programming experience only because every person who writes computer programs of any type is going to spend time both using and writing APIs, if only project-internal APIs for other parts of their own program. It is inevitable they will run into the concept of default arguments in the APIs they use, and if they do it for a while are likely to learn from firsthand experience that not having such a concept causes trouble.
 * Having an optional argument that cannot be explicitly set to the default (the way Wikipedia's templates are often set to do) is worse still, and is basically unheard of in programming environments, because it's a really bad idea which causes completely gratuitous frustration for API consumers.
 * Of course, many programming projects of all flavors (volunteer, professional, ...) have serious design flaws of many types. Where possible these should be fixed at the furthest upstream source possible. Where that isn't possible, they should be worked around to make users' lives pleasant.)
 * But the situation we are in here is very simple. What you are suggesting is going to cause confusion and frustration, for no practical benefit. So we should just not do it. The basic alternative is to do nothing, which would be fine; there will continue to be thousands of instances of "|search=yes", and we can just not worry about them. As a better alternative, we could explicitly allow the argument to be explicitly set to the default value. This would be nearly trivial and would instantly eliminate whatever other related problems you were worried about.
 * Note: I am not trying to be mean here, or personal. I don't think you are trying to cause problems, or anything like that. Everyone has problematic ideas sometimes (or often in my own case).
 * –jacobolus (t) 05:42, 15 June 2024 (UTC)
 * Withdrawn. Mathglot (talk) 07:39, 16 June 2024 (UTC)

Template-protected edit request on 24 June 2024
Define background-color using a CSS variable, for compatibility with night mode.

Diff:

Andumé (talk) 03:02, 24 June 2024 (UTC)
 * ✅ Sohom ( talk ) 14:00, 24 June 2024 (UTC)