Template talk:Talk header

This parameter is still not discussed by the popup message explaining why/why not a page gets archived.

If | minthreadstoarchive = 2 for instance, then an editor needs to read the actual code (=editing the page) to understand why the archive bot isn't running. (It is because even though a section is clearly ripe for archiving, there is only one section to archive, and the parameter tells the bot to hold off archiving until it can archive 2 or more sections in a single go).

Either we agree the bot's behavior should be explained by what we tell talk page readers, or we agree this isn't necessary.

In the first case, the info that the bot won't act until more talk sections have expired needs to be added somehow. In the second, why not simply remove all info related to the bot's parameters? CapnZapp (talk) 14:27, 20 May 2025 (UTC)Reply

@CapnZapp, we could try adding it to the tooltip somehow. But I'm also not losing sleep at night over it just not being displayed, and I'd oppose any sort of display more prominent than inclusion in the tooltip. Sdkb ^talk 14:54, 20 May 2025 (UTC)Reply

@CapnZapp and Sdkb: I think it is a good idea if done within the tooltip. --Timeshifter (talk) 14:29, 17 June 2025 (UTC)Reply

Within the past few days, this template has started throwing up a redlinked Category:Pages using Talk header that I can't figure out how to fix.

This template is used on well over 750,000 pages, so it's clearly not a category we would actually need for tracking purposes — we have various more specialized categories, like Category:Pages using Talk header with unknown parameters, to track errors in its usage, but we would have no need whatsoever for a comprehensive category indiscriminately tracking all of its usages across the board. That's not what's actually happening, however: it isn't showing up across the board on all 750,000 usages of the template, it's showing up on isolated project pages that are invoking the template for discussion or testing purposes, such as Template:Talk header/testcases4 and Wikipedia:Templates for discussion/Log/2023 May 17.

But it also isn't being directly transcluded by the template itself — the template only adds the more specialized error-tracking categories, while including absolutely no code that would directly transclude an indiscriminate Category:Pages using Talk header, and it hasn't been edited since December 2024 to start adding any new categories that didn't already exist previously. So once again, it's clearly being smuggled in via a module.

When the report last updated on Thursday, it was only on the testcases page, which I resolved by wrapping the invocation that was causing it in {{suppress categories}} — but when I did my daily "have any of the last set of redlinks come back again" check today, it was back, this time on the TFD page. And while I could just wrap that one in the suppress wrapper too, the fact that it recurred more than once suggests that it might continue to recur if it isn't resolved at the source.

So could somebody figure out where it's coming from and make it go away? Thanks. Bearcat (talk) 14:16, 24 May 2025 (UTC)Reply

I can answer the where part of that - currently the category is being emitted only by the sandbox version of this template (see Special:Diff/1291362857). As to what the purpose of it is, not too sure. Aidan9382 _(talk) 14:27, 24 May 2025 (UTC)Reply

{{Archives}}. See:

• Template talk:Archives#A narrower banner would help declutter the top of talk page.

We need someone with template skills to copy the archive banner part of {{talk header}} over to {{archives}}. And {{talk header}} uses Lua. --Timeshifter (talk) 14:41, 17 June 2025 (UTC)Reply

The archive-banner part doesn't. Aaron Liu (talk) 14:11, 19 June 2025 (UTC)Reply

After Timeshifter suggested making {{archives}}'s banner style more similar to the archives box in this template, I've been exploring the idea of replacing the archives box in the talk header here with {{archives}}'s banner style with some parameters. What do you think?

{{Archives/sandbox|root=Talk:France|banner=yes|tooltip=yes|image=none}} →

Note some differences:

1. The horizontal rule (bar) above the search box would be removed. Though I never got why that was there anyway; the search box is very closely related to the list of archives.
2. When the archives have been set up yet the first archive page has not been created, the full template will still show:

{{Archives/sandbox|root=User talk:Aaron Liu/sandbox|banner=yes|tooltip=yes|image=none}} →

Though I don't see any reason to at this time, I could make changes to eliminate these differences if there's consensus to. Aaron Liu (talk) 01:53, 20 June 2025 (UTC)Reply

If there are no archives yet the whole section should be hidden. –jacobolus (t) 01:58, 20 June 2025 (UTC)Reply

Agreed, but the page links show, no matter what (if there're any). - FlightTime Phone (open channel) 02:05, 20 June 2025 (UTC)Reply

So, when there's no archives yet, you want to show this?

{{Archives/sandbox|root=User talk:Aaron Liu/sandbox|banner=yes|tooltip=yes|image=none|search=no}} →

Or do you mean hide the archive part entirely, only showing the policy reminders and stuff above the archives section of Talk Header?

@Timeshifter recommended instead only displaying the archival configuration:

Sections older than 2278 hours may be auto-archived by Lowercase sigmabot III if there are more than 2.

Aaron Liu (talk) 02:18, 20 June 2025 (UTC)Reply

I would like a variation of this:

{{Archives/sandbox|root=User talk:Aaron Liu/sandbox|banner=yes|tooltip=yes|image=none|search=no}} →

Except I would substitute: "ClueBot III will archive sections when more than 4 are present" for the first part. I don't know how to make the banner, so I just put it in a table. Needs the tooltip too.

--Timeshifter (talk) 03:48, 20 June 2025 (UTC)Reply

I don't see how that's superior to "just the configuration" (box with just "Sections older than..." and nothing else). Aaron Liu (talk) 11:36, 20 June 2025 (UTC)Reply

That one takes up 2 lines on my 1080p monitor even at the same banner width as {{talk header}}. --Timeshifter (talk) 13:24, 20 June 2025 (UTC)Reply

I've shortened the automatic summary so the ClueBot case for just the summary sentence is also just one line. Check out my sandbox: User:Aaron Liu/sandbox. Your suggestion also takes up two lines for sigmabot. Aaron Liu (talk) 16:30, 20 June 2025 (UTC)Reply

If there are no archives yet, nothing needs to show at all. In practice people only add a bot to archive talk pages when they are getting long-ish and the bot is supposed to run at the earliest opportunity. We don't need any special marker for the short and trivial time window in between when the bot setup is added and the first time it runs. Thinking about this is a waste of time and effort; find something better to do. –jacobolus (t) 14:19, 20 June 2025 (UTC)Reply

"Thinking about this is a waste of time and effort; find something better to do." Well then, stop thinking about it, and go elsewhere with your comments.

I, and many others, have added archiving bots to pages with few sections currently. On contentious articles for example. For example, to make sure the minimum thread settings aren't set to zero or one, as a means to stifle discussion. Also, 4 is the minimum for a table of contents to show up in Vector 2010.

It can be months to go from 4 threads to 5 threads. So letting people know there is an archiving bot already set up keeps people from wasting time looking in the wikitext. --Timeshifter (talk) 15:01, 20 June 2025 (UTC)Reply

I would love to: this part of the template works fine as it currently is, and there are plenty of better things to do. Unfortunately, by proposing changes to one of the most widely used templates on the site, you are forcing other folks to think about it.

"I, and many others, have added archiving bots to pages with few sections currently."

Well one easy solution is to just stop doing that. Alternately, you can keep doing it, and not worry that readers who care about the archive settings need to read the page source. If there are only 4 threads on the talk page, then any choice to think about archive settings is some editor's own business – if they want to spend their time looking at the page source they can do so, or they could just not worry about it and move on with their day. There's no significant need to archive talk pages until they become unmanageably long (say, at least 10+ topics) or full of extremely stale discussion. If there are no archives, then showing anything at all related to archives is distracting and confusing to unfamiliar readers, while providing negligible benefit to anyone else. I am opposed to showing it. –jacobolus (t) 20:29, 20 June 2025 (UTC)Reply

• I'll leave the discussion about what to display when there are no archives yet to others, although I think the general principle that we should only display information when it is relevant is a good one. I support removing the horizontal rule per Aaron Liu's reasoning and general graphical design best practice, and I likewise support overall consolidation of templates, so I hope this goes forward. Cheers, Sdkb ^talk 20:57, 20 June 2025 (UTC)Reply

It could be an optional parameter to show something when there are no archives yet. That lets the page editors decide. I like Aaron Liu's latest version:

I think Sigmabot or Cluebot can be used as the link label. The full name can be used as the link under the label. That will keep it all shorter, and on one line in most cases. --Timeshifter (talk) 00:52, 21 June 2025 (UTC)Reply

I still prefer the last version mentioned #c-Aaron_Liu-20250620021800-FlightTime_Phone-20250620020500. It's simple and doesn't extend code to handle template parameters to a somewhat unwieldy level. After a change it's also no more longer than what Timeshifter prefers. Aaron Liu (talk) 00:57, 21 June 2025 (UTC)Reply

As I realized elsewhere there is no need to right and left align the 2 halves of the banner showing just above when there are no archives. They can be joined. That might make the coding easier. --Timeshifter (talk) 01:18, 21 June 2025 (UTC)Reply

The splitting is not the problem. The problem is having two versions of the summary of the archive configuration. Which I don't think even has a benefit as what you like more fits on the exact same number of lines after I shortened the automatic summary. Aaron Liu (talk) 02:04, 21 June 2025 (UTC)Reply

OK. This is pretty short below. In a table since I don't know how to do a banner. Removed "automatically". Kept full bot names.

--Timeshifter (talk) 02:25, 21 June 2025 (UTC)Reply

Yeah that sounds good. (I still think "may" is better to prevent people asking when a message will be archived since ClueBot has inconsistent scheduling. It's also slightly shorter.) Aaron Liu (talk) 02:42, 21 June 2025 (UTC)Reply

How long can Cluebot take to archive a page once the necessary number of sections has been reached? Maybe a tooltip can be put on the word "will" saying "depending on bot scheduling". Another problem is if there is a minimum number of threads to archive at a time. That could go in a tooltip on the words "older than 30 days". Maybe "minimum of 2 sections older". That option should be removed from the bots in my opinion. It can be very confusing to editors. It is "minthreadstoarchive" in Sigmabot. "minarchthreads" in Cluebot. --Timeshifter (talk) 03:02, 21 June 2025 (UTC)Reply

ClueBot does things a bit irregularly. I think it's best to just say "may" plus, for example, the bot could be temporarily down. I also don't think much people need to have minarchthreads displayed in no small part because nobody has ever asked for it to be displayed. Aaron Liu (talk) 03:22, 21 June 2025 (UTC)Reply

There is no need to surface this information to readers (and if you are confused about it, you can put your worry away and ignore the distinction). The point of having a minimum number of threads to archive is to prioritize human discussion over distracting and not-at-all-urgent bot edits. This configuration option helps the bot better serve the needs of a variety of different types of talk pages with different levels of activity. If a bot takes an extra day, week, month, or 3 years to archive a particular discussion, it causes no harm. Whether a discussion page shows 4, 6, or 10 prior topics and whether some of them are 6 months, a year, or 3 years old is not really relevant to participating on that page. These features only become relevant if the page is becoming bogged down or people keep getting distracted replying to no-longer-relevant discussions.

The parts readers care about, with respect to archiving, are: (1) the discussion page should not get overwhelmingly big so that it's necessary to skim past many hundreds of kilobytes of talk history to get to active conversations; (2) the discussion page should not gratuitously keep around very old discussions about past versions of the page that are no longer relevant after significant intermediate editing – it's rarely if ever useful to have someone reply to 10+ year old topics, most of whose participants are long gone; and (3) the archives of old discussions should be easy to locate, and ideally searchable. Everything having to do with bots and their configuration is a distant last place, only of interest to a tiny group of readers. –jacobolus (t) 03:34, 21 June 2025 (UTC)Reply

There is also no good reason to publish the bot's name to ordinary readers, for whom it is irrelevant. Having the bot name in the "Auto-archiving period" mouse-over text when there are archives available is already more than sufficient.

Adding additional "optional parameter" seems like a bad idea. It's self-indulgent to throw additional distractions into regular readers' faces that is only relevant to a trivially tiny subset of editors who care about bot config settings but can't be bothered to read the page source.

–jacobolus (t) 03:12, 21 June 2025 (UTC)Reply

The entire thing is for people who care about archiving, not regular readers. I don't see any optional parameters added here. Aaron Liu (talk) 03:20, 21 June 2025 (UTC)Reply

Quite the contrary. This is an extremely widely used template. Every bit of it needs to be extremely important to justify showing up in the faces of readers. Editors working on this template must hold regular readers' interests firmly above their own or other "power users'" interests. The template API must also be kept as simple as possible, since it is very widely deployed and we shouldn't be forcing large numbers of editors to go consult the documentation unless it's necessary.

The fundamental purpose of this section of the template is to show an archive search box; when there are no archives that purpose is nullified and the section should be hidden. Additional doodads about bot configuration are essentially distractions from the primary purpose, and to the extent they are shown at all they must be made as unobtrusive as possible. It's okay to use otherwise unusable space next to the archive wikilink list to show a very brief summary with more information in a mouseover, because in that context readers will already see that there are archives and it's not too confusing what "Auto-archiving period: 1 year" (or whatever) means. But when there are no archives, and the metadata doodads are the only thing left, they aren't important enough to justify themselves. –jacobolus (t) 03:21, 21 June 2025 (UTC)Reply

You have a low opinion of readers' ability to understand something as simple as this: "Cluebot III will archive sections older than 30 days when more than 4 are present." --Timeshifter (talk) 03:30, 21 June 2025 (UTC)Reply

No, I just have high standards and care a lot about respecting the needs of ordinary readers instead of self indulgently making every part of the site as unwelcoming as possible. –jacobolus (t) 03:31, 21 June 2025 (UTC)Reply

I'm saying the entire thing we're discussing about showing just the config information when there's no archives yet is mainly for people who care about archiving. I found it weird that you singled the bot's name out.

It's also good to have some indication the template will show the archives listing. The archives box on pages without a talk page header is one of the ways to help verify that your bot config will work correctly, as the config summary won't show up if e.g. you set an invalid archival duration. And you don't know whether logged-out editors—our most prolific content contributors by word count—will be surprised when their discussions suddenly disappear after a day.

Also, the parameter to disable the search box exists for a reason. More than enough people find this area useful for purposes besides searching the archives. If you were correct that only the search box was what's important, you would not have anything besides the search box so as to simplify and "not confuse regular readers".

I don't see any reason this'll newly cause editors to consult the documentation. Again, this will not add any new parameters. The config summary is already in the tooltip and if anyone would be confused they already are. Aaron Liu (talk) 03:31, 21 June 2025 (UTC)Reply

Literally nobody's discussion is going to "disappear after a day" on a talk page that just now had archiving set up but hasn't yet had the bot run on it yet, unless the bot is outrageously misconfigured. cf. YAGNI. "not add any new parameters" – I was replying to "It could be an optional parameter to show something when there are no archives yet. That lets the page editors decide." –jacobolus (t) 03:37, 21 June 2025 (UTC)Reply

Sure, disappear after a week. The first time someone goes to a talk page they reads all applicable banners. A week later they wants to check on it, so during break time they mentally ignores the banners "they's read already" to discover that their discussion has mysteriously disappeared. This is curbed if not prevented by having an indication that automatic archiving is set up, and we use the rest of that "otherwise unusable" one-liner space to say a little bit of details. The population of editors who want to see whether archives are set up on a talk page is higher than you think.

And again, I don't see why you aren't arguing this for the list of archive subpages, the wikilink list.

I was replying to "It could be an optional parameter to show something when there are no archives yet. That lets the page editors decide.

That's a parallel discussion on improving {{archives}}, comments which Timeshifter decided to copy and paste here, not exactly sure why. Aaron Liu (talk) 03:42, 21 June 2025 (UTC)Reply

"disappear after a week" – your fantasy scenario is still entirely implausible, and this change isn't going to have a meaningful effect.

Either way, someone could leave a comment on a (brand new and never archived but somehow extremely high traffic) talk page, have the same aggressive archiving set up either just before they left or while they were gone, and then come back a week later to find their post has been archived. In either case they weren't going to have been looking at the talk header box before they commented to figure out what the bot config was, and in either case after they come back there will already be archives (that's the entire premise here). With or without this change the person is going to be identically confused (or not) and presented with identical information on their return. –jacobolus (t) 03:49, 21 June 2025 (UTC)Reply

your fantasy scenario is still entirely implausible

How? Archive durations are very commonly one-week, and there exists talk pages with so little activity that they haven't had archives yet. I didn't say it would need to be high traffic. My scenario is more common than yours, especially given that the editor doesn't guess that it was automatic archiving yet and thus is new and is more likely to read the talk header before their first comment. Aaron Liu (talk) 03:54, 21 June 2025 (UTC)Reply

The situation you are imagining requires all of these to happen, in this order:

1. A brand new but very high traffic page has extremely (over)aggressive archiving set up by some zealous editor
2. A novice reader navigates to the page before the bot has a chance to ever run on it, and makes careful note of the bot config mentioned at the top of the page
3. The reader leaves a comment, now expecting their comment to disappear because they did a close analysis of the bot config
4. The reader goes away for a week, during which time there are 5+ more separate discussion topics added and the bot then archives the topic where the reader's comment was left
5. The reader comes back to the page and their comment is gone, but, because our change to the template saved the day, avoids confusion.

This seems extremely implausible to me, to the point were I doubt, in the situation where this change goes through, it will ever happen even a single time. #1, #2, #3, and #4 are each independently rare, and their combination is vanishingly unlikely. –jacobolus (t) 04:34, 21 June 2025 (UTC)Reply

@Jacobolus: Page editors can put {{archives}} on a page that has an archive bot set up. And even before an archive has been created, the archive bot or banner shows up.

I am not wedded to the option to allow the same in {{talk header}}, but I believe many page editors would want that. I was just trying to give them that option. You apparently don't want to give them that option. Let's let other editors here weigh in. --Timeshifter (talk) 03:57, 21 June 2025 (UTC)Reply

I am indifferent about {{archives}}. It's used on fewer than a tenth as many pages as {{talk header}}, it's relatively out of the way in a narrow right-floating box, and I've never seen it used when there weren't already archives. Feel free to advocate hiding this one when there aren't yet any archives. –jacobolus (t) 05:22, 21 June 2025 (UTC)Reply

@Jacobolus

1. Again, "high-traffic" is your invention. (Or maybe you confused this with Timeshifter saying it's also helpful to stop people from wasting time adding an archive config when it's already added on new high-traffic pages, which is a different scenario with different effects.) In fact, I specified that this scenario is more likely on chill-traffic pages. I do not find seven days overaggressive.
2. I do not see the first part being uncommon on chill pages. And if you're assuming that readers won't read the banner, then nothing we decide about any parts of the talk header has any point.
3. You do not need to do a "close analysis" of the bot config. It says in plain text that inactive discussions will be automatically archived in a week.
4. Where's the 5+ topics from? How does that influence anything? Who said anything about that? Without that part, I do not see any reason why this would be rare.

I do not see how having a single, clear line of text is unwelcoming or confusing.

And you still have not answered why your argument does not apply to the wikilink list as well. Aaron Liu (talk) 15:47, 21 June 2025 (UTC)Reply

It would have to be a "high traffic" talk page in order to need very aggressive (weekly) archiving, and accumulate more than 4 new topics within a single week. And it needs to be a brand new page, because anything older with that much discussion would already have one or more archive pages. On a typical not-yet-archived (low-traffic) talk page, what would happen instead is that the person's post would stick around for at least many months if not years before being archived. "says in plain text" – a Wikipedia novice just leaving a rare discussion comment (or, frankly, anyone else) is unlikely to be very carefully perusing all of the banners on the page before leaving their comment, in case there might be aggressive archiving. Instead, they'll wait until the post is archived to wonder what happened, at which point this change will be moot.

I don't understand your question. This entire section (list or archive pages, bot config, search box) should be hidden if there are no archives. –jacobolus (t) 20:26, 21 June 2025 (UTC)Reply

The same scenario can happen under other durations at least up to a month. And even for high-traffic situations, it's not uncommon for new articles (thus with new talk pages) to be popular, and then you can very conceivably have this happen.

and accumulate more than 4 new topics within a single week

I don't get why you're mentioning that either. The same scenario occurs even if the reader's discussion is the only new one in the past week.

very carefully perusing

Again, this information will be immediately understood if one reads it at all. The part of the talk header before the archives display is designed to offer novices basic information. It is pointless to argue that it shouldn't be there because novices won't read it because the bulk of this entire template is made on the presumption that novices will read it.

You said The fundamental purpose of this section of the template is to show an archive search box [...] Additional doodads about bot configuration are essentially distractions from the primary purpose, and to the extent they are shown at all they must be made as unobtrusive as possible. This makes the archive list also an additional doodad. You then say that such additional doodads can only be justified as they do not take up additional space. The archive list takes up additional space when there are archives. There are way more ways people use this template than you assume. You have not clarified why taking up one extra line creates a distraction either. It has no possibility of confusing anyone, or at least no more than the archive list. Aaron Liu (talk) 22:14, 21 June 2025 (UTC)Reply

Anyways, I can drop the discussion on whether to change existing behavior for now. Would you agree with replacing the standalone Archives reimplementation with a transclusion if it still just hides when there are no archives? I've rigged what this should look like up in {{Talk header/sandbox}}, and you can see it in effect at TM:Talk header/testcases. Aaron Liu (talk) 19:21, 27 June 2025 (UTC)Reply

|minthreadstoarchive= is a parameter used to configure archiving bots (cf User:Lowercase sigmabot III/Archive HowTo), telling the bot to only engage when at least the specified number of discussion sections meet other criteria for archival. The reason you might want to set |minthreadstoarchive=2 or any other number > 1 is that for some talk pages, the cadence of new topic results in annoyingly frequent bot archive operations - each time a new topic is added, the bot might archive an old one. Of course, on most pages using frequency ("only archive every week") is more than adequate, and on other pages archive bot activity is a complete non-issue. But if a topic attracts attention, say, once every three months, and you set the archiving frequency also to three months, you still get a page history where every time a new topic is started, that is followed by a bot archiving action. |minthreadstoarchive= is meant as a solution to this issue. Set perhaps |minthreadstoarchive=3 to stop the bot from appearing to "obsessively clean out" the talk page.

But this is currently not explained to the user. |minthreadstoarchive= is currently ignored by the auto archive notice part of this template. To understand why the bot "isn't working", you need to edit the page and look at the actual bot config. The entire reason to have an auto archive notice section of this template is so the user can avoid this.

The ability to explain this to regular readers ("the reason the bot hasn't archived the page yet even though there is an eligible discussion section old enough and even though there are enough sections left afterward, is that the bot is told to not archive unless 3 or more sections can be archived in one go") did once function but is still not re-instituted after the major works done (where this archive automatically interprets the bot instructions, instead of the user having to duplicate the settings: once for the bot and once for the auto archive notice) on this and the {{Archives}} templates. When the auto archive notice functionality was merged into Talk header a promise was made to fully port all capabilities of the older code. There was never any consensus to drop this functionality. Please add it back. CapnZapp (talk) 09:41, 4 August 2025 (UTC)Reply

Let's have a specific concrete example. Talk:Kármán line's Talk header currently says Discussions with timestamps are automatically archived by Lowercase sigmabot III after 90 days of inactivity when more than 4 threads are present. in the tooltip if you hover over "Auto-archiving period". It should say something along the lines of Discussions with timestamps are automatically archived by Lowercase sigmabot III after 90 days of inactivity when more than 4 threads are present, but only when 2 or more discussions can be archived. (my emphasis). Cheers, CapnZapp (talk) 09:48, 4 August 2025 (UTC)Reply

I agree. I remember being totally confused by a talk page not archiving a section. Looking at the bot code did not help. Because minthreadstoarchive was not listed at all.

I found out later it existed and that it defaulted to 2 threads minimum. —Timeshifter (talk) 15:16, 4 August 2025 (UTC)Reply

At least for Lowercase sigmabot III, I heartily recommend everybody to set up the parameters as needed, and not rely on the code's defaults. I believe the defaults^[1] are seldom what you want. Cheers CapnZapp (talk) 17:14, 4 August 2025 (UTC)Reply

Thanks CapnZapp for perusing the source code.^[1] I fixed the default listed for minthreadstoarchive at User:Lowercase sigmabot III/Archive HowTo#Parameters explained. It now says 2. It mistakenly said 1 before. --Timeshifter (talk) 01:39, 5 August 2025 (UTC)Reply

Its not my thing to say, but I don't think a how to should be mistaken for technical documentation. In other words, those numbers were probably intended as suggested numbers, not the defaults of specific program code. Cheers CapnZapp (talk) 12:18, 5 August 2025 (UTC)Reply

CapnZapp. Column said "Default". I noticed you started a discussion there. I will reply further at User talk:Lowercase sigmabot III/Archive HowTo. --Timeshifter (talk) 16:13, 5 August 2025 (UTC)Reply

This is not something that ordinary readers need to care about at all. The more complicated you make the popup text the more likely it is to confuse someone. Anyone obsessively interested in bot config can easily look at the page source. –jacobolus (t) 16:35, 4 August 2025 (UTC)Reply

It appears you want to start a discussion where some, but not all, pertinent information regarding the archive bot's activity should be presented to the user, user:jacobolus. That the archive bot notice section of this template should help the user avoid having to look at the page source only some of the time? Meanwhile, I didn't start this discussion to change or question consensus. I started this discussion to remind the powers that be that the work to implement the various changes and improvements to this and the Archives templates isn't complete. Have a nice day, CapnZapp (talk) 17:02, 4 August 2025 (UTC)Reply

I want to urge people to consider the trade-off involved in every bit of additional information added to one of the most widely used user interfaces on Wikipedia, and aim for restraint and minimalism on such interfaces rather than trying to cram every possible thing in. Make sure a large audience really needs it before you add each extra thing that is likely to be distracting and unhelpful to the vast majority. –jacobolus (t) 19:22, 4 August 2025 (UTC)Reply

@Jacobolus: Tooltips are pretty minimal. And readers don't have to hover over them. Those who bother to do so are obviously interested. --Timeshifter (talk) 01:03, 5 August 2025 (UTC)Reply

Fair enough. I personally find the proposed description ("Discussions with timestamps are automatically archived by Lowercase sigmabot III after 90 days of inactivity when more than 4 threads are present, but only when 2 or more discussions can be archived.") to be pretty confusing, and I already know what it's supposed to mean. I can only imagine what a new reader is going to think. I think the "obviously interested" should just look at the source markup, but if other editors all agree that we should cram more stuff in the tooltip, I'm not especially bothered – I will continue to ignore these. –jacobolus (t) 01:30, 5 August 2025 (UTC)Reply

@Jacobolus: I gave an example higher up where I did look at the talk page source code for the archive bot settings, and it didn't help. Because minthreadstoarchive was not listed at all, and I had no clue at the time what I was looking for, or should look for. --Timeshifter (talk) 01:51, 5 August 2025 (UTC)Reply

It looks like the issue there was that the docs were wrong. Good job fixing it; that should, already, prevent future problems like the one you encountered. Always archiving at least 2 threads seems like a good default (frankly the docs should urge people not to configure this lower than 2). –jacobolus (t) 02:37, 5 August 2025 (UTC)Reply

@Jacobolus:. At the time of my confusion I knew little about the bot parameters. It was on a Village Pump. I asked on its talk page what was going on. I was not the only one confused. Finally, someone stepped in who knew something about these arcane settings. It shouldn't take a separate discussion for editors to figure this out. The expanded tooltip solves the problem. --Timeshifter (talk) 02:56, 5 August 2025 (UTC)Reply

You are right, it shouldn't have needed a separate discussion: the docs should have been be accurate, so that anyone who is very curious about the bot behavior (apparently you were among the first and only people ever in this category) can can go look at the docs and see what the default setting is. Luckily you fixed the docs, which solves this problem. –jacobolus (t) 03:01, 5 August 2025 (UTC)Reply

@Jacobolus: I am definitely not the first. And at the time I didn't have a clue where to look for more info. So fixing the doc does not fix the problem. And I was an experienced editor even then, but not in this area. Newer editors often know next to nothing about bots, and don't know that the bot code is right there in the talk page wikitext at the top. And even if they do, they haven't spent time learning the meaning of all the parameters. So the expanded tooltip is necessary to get a simpler explanation of the current settings. --Timeshifter (talk) 03:13, 5 August 2025 (UTC)Reply

just to note: my stake in this is chiefly to prevent functionality from being stealth deprecated without discussion. Had the merge into Talk Header been predicated on dropping support for this parameter, I would have opposed it. The fact the coders are silent is disappointing. Regards CapnZapp (talk) 12:23, 5 August 2025 (UTC)Reply

Support but with a simpler wording and not shown outside of the tooltip. That message is already a mess, and adding a final "but" clause makes it sound insane. A simple Discussions with timestamps are automatically archived in pairs by Lowercase... is good in this example. FaviFake (talk) 20:48, 4 August 2025 (UTC)Reply

Opposed for now – I tend to agree with jacobolus, here. I think there is a limit to what users can absorb, even in a tooltip expansion. Param |minthreadstoarchive= is one of the ones that is a bit arcane, and it is enough if it is described in the doc page. That said, I will watch this discussion (which I hope will attract more diversity of opinions), and stay open to changing my opinion about it. Mathglot (talk) 09:01, 5 August 2025 (UTC)Reply

Mathglot. It's a sentence. How hard can it be? It is not enough if it is described in the doc page, as I previously explained why. Here is more info: Wikipedia talk:Village pump (proposals)#Archive bot was missing some parts. --Timeshifter (talk) 16:13, 5 August 2025 (UTC)Reply

Please note that this is not a request for new functionality. This is a reminder to add back what got dropped between chairs at some point of the substantial work on the archive bot notice, including its integration into Talk Header. Regards CapnZapp (talk) 12:26, 5 August 2025 (UTC)Reply

CapnZapp. I agree. Consensus should have been reached to remove it. Currently, 3 people support returning it. 2 oppose. --Timeshifter (talk) 16:13, 5 August 2025 (UTC)Reply

@Timeshifter Please remember WP:VIE and WP:PEPPER. Respectfully, FaviFake (talk) 16:27, 5 August 2025 (UTC)Reply

FaviFake. Please see WP:3LA and WP:Don't cite essays or proposals as if they were policy. I have responded to comments with new points in each of my comments. You have made only one substantive comment (the one where you supported CapnZapp's proposal). So you are violating the essay you promoted: WP:Polling is not a substitute for discussion. You are not discussing. I never said my poll was a substitute for discussion. Nor have I discouraged discussion. It seems that you are doing that. --Timeshifter (talk) 22:28, 5 August 2025 (UTC)Reply

@Timeshifter You seem to have misinterpreted my comment. I'm not "violating" any essay, since they aren't policy. I pointed you to WP:VIE because you seemed to be incentivising closing this discussion based on votes rather than consensus.

Besides, kindly keep the ad hominems to yourself. FaviFake (talk) 14:51, 8 August 2025 (UTC)Reply

You are repeating yourself. Please see my previous replies. --Timeshifter (talk) 15:15, 8 August 2025 (UTC)Reply

It is not exactly a request for new functionality, because we have seen it before, but it was not originally part of the archiving template bot notice params, which were these four: |archive_bot=, |archive_age=, |archive_units=, and |minthreadsleft=. The first appearance of minthreadstoarchive in the bot notice occurred a year ago, and was kind of piggy-backed into an altogether different project which did not involve changing any wording in the bot notice at all, but was designed solely to automate the bot notice so it would produce exactly the wording that was there before, so readers would see no difference at all, and editors would no longer have to manually add separate bot notice params and sync them up with archive bot config params every time the config params were added or modified. During the somewhat complex implementation of the bot notice automation, various wording change proposals were made at the same time. I don't recall the minthreadstoarchive as ever having achieved consensus, and may have been in a sandbox version or even live for a while during automation development, but either there was consensus against, or it just fizzled, I don't really recall anymore.

Put another way: the minthreadstoarchive parameter historically was not present in the bot notice emitted by the Talk header template or the Archive box template before the automation project got underway last year. Since the automation upgrade was designed to automate the four params that were already there, it did not automate minthreadstoarchive because it wasn't one of the four in use, and there was nothing to automate. It seems to have been added for a while, as one of several wording change proposals that were going on around the same time, but I guess it didn't stick.

I just wanted to correct the historical record about minthreadstoarchive as not something that got "dropped": it couldn't be dropped, because it was never there originally; it made an appearance during the wording change proposals coterminous with the automation project, and failed to be retained for whatever reason. I'm agnostic as to whether it should or shouldn't be added now, and as this is a time when we are raising all sorts of proposals about wording of the bot notice, that is certainly an appropriate issue to address. However, it is not a return to longstanding practice, it is an add-on. Mathglot (talk) 00:23, 6 August 2025 (UTC)Reply

Okay, I found the previous discussion about this, here. Skip the pre-April 2024 part of that discussion, which was mostly a comedy of errors. Adding previous discussant Tollens. Mathglot (talk) 08:16, 6 August 2025 (UTC)Reply

In that discussion (Template talk:Talk header/Archive 12#minimum number of sections archived), User:Sdkb told me |minthreadstoarchive= is currently displayed in the tooltip (along with the specific bot that does the archiving). That's what I'm basing this on. I've always assumed the "got lost in the shuffle" was an honest mistake, a dropped ball without being intentional. Because why would we leave the notice incomplete? I will note that there was a time when the archive bot notice was not part of Talk header. I fear the intricacy of archive bots seems to have been underestimated. Now editors argue that Talk header is already complex and large enough so we should be content with a half-assed bot notice. Had the archive bot notice been allowed to live on, and progress, in stand-alone templates^[2] instead of being folded into the already super complex Talk header I'm positive we would have a satisfying mention/explanation of what a setting of |minthreadstoarchive= can lead to; since everybody would have considered providing a full explanation the obvious and natural thing to do. CapnZapp (talk) 13:06, 13 August 2025 (UTC)Reply

It wasn't a dropped ball, though. I think either it wasn't there at the time and Sdkb got momentarily confused given everything that was going on during an intense period of change, or it was there, briefly, during testing or something and that's the moment when Sdkb responded; I really can't recall the sequence of events. Anyway, it wasn't there before the automation project, and it wasn't there after it, so the project did what it was supposed to do. I don't know how much is riding on this dropped-ball idea, but I don't think it really matters if it was there before or not; if it is a good idea now and there is consensus for it, it should be added, and if there isn't, it shouldn't. Mathglot (talk) 18:35, 13 August 2025 (UTC)Reply

I think I may have been confusing |minthreadstoarchive= with |minthreadsleft=. The latter is in the tooltip as e.g. when more than 4 threads are present; I don't think the former (e.g. 4 at a time) has ever been present. I don't have any objection to adding it to the tooltip, although I wouldn't want to see it any more prominent than that due to banner blindness. |minthreadstoarchive= also just seems like a fairly niche parameter that viewers of a talk page are unlikely to really care about, so I also don't think we really have a crisis in not displaying it currently. Sdkb ^talk 20:05, 13 August 2025 (UTC) (please   mention me on reply)Reply

Leaving arcane configuration details out of view when they are of no interest whatsoever to effectively 100% of readers is not "half assed". –jacobolus (t) 18:48, 13 August 2025 (UTC)Reply

Anyway. To proceed in a constructive manner, how about this: We concede that Talk header isn't the place for the full archive bot notice, as a tooltip it's already overloaded, and have our documentation tell users to only use its archive bot notice subsection for the easy cases (a vast majority of page config is content with |minthreadstoarchive=1), and we implement a fuller message in {{Archives}}, the only(?) surviving stand-alone talk page archive template. If you set minthreadstoarchive (or the ClueBot II equivalent, |minarchthreads=) to any value greater than 1 (a fully valid use case, btw); use Archives and suppress the archive bot notice subsection of Talk header. (In fact, why don't we make this automatic - if Talk header senses the presence of Archives and/or that minthreadstoarchive >1, it automatically turns off its archive bot notice subsection?) At Archives the message is thankfully not just a tooltip, it's fully presented as several lines of text right in the template: it can easily handle one more line, if that is what it takes to finally solve the issue: i.e. by explaining to users that their config makes the bot only act when so many sections are ripe for archiving in a single go. The work to find out which pages set minthreadstoarchive to a number greater than 1 has already been done; we can then add {{Archives}} to those pages. Regards CapnZapp (talk) 13:06, 13 August 2025 (UTC)Reply

See: User talk:Timeshifter/Sandbox291.

A suggested box below for {{archives|banner=yes}} when there is no archive yet. So a search form would not yet be needed.

--Timeshifter (talk) 14:37, 13 August 2025 (UTC)Reply

What about this version? It's much shorter and says the same thing.

Or, if the |minarchthreads= parameter is set to more than 2:

FaviFake (talk) 14:52, 13 August 2025 (UTC)Reply

I removed the indentation on the boxes so that they are full width. minarchthreads can be set to 2, but 3 sections may be ready to archive by the time the bot makes its appearance. Thus my wording. --Timeshifter (talk) 15:17, 13 August 2025 (UTC)Reply

I'm not sure I understood your comment. FaviFake (talk) 15:34, 13 August 2025 (UTC)Reply

What Ts meant, I think, is that your "in pairs" or "4 at a time" language, nice as it is, is not true. It isn't "4 at a time", it's "at least 4". I suppose you could say, "4 or more at a time", bu tis that better than "at least 4"? Mathglot (talk) 18:44, 13 August 2025 (UTC)Reply

Oh, got it. Why can't we just use "at least 4 at a time" then?

Still, I think using a much clearer yet not exactly precise wording is better UX. FaviFake (talk) 21:24, 13 August 2025 (UTC)Reply

Why "topics" instead of "sections", I wonder? Aaron Liu (talk) 19:13, 13 August 2025 (UTC)Reply

Because that's what the software calls them, and it's shorter. And i like it better, honestly. FaviFake (talk) 21:26, 13 August 2025 (UTC)Reply

Also, techincally a subsection is still a section, so "topic" is more precise. It's a win-win! FaviFake (talk) 21:26, 13 August 2025 (UTC)Reply

Timeshifter's suggestion is clear, easily understandable, written like a natural sentence. Aaron's suggestions have the problem it is easy to overlook that "in pairs." despite this being the crucial information currently lacking. Numbers should be presented as clearly understood digits; people aren't trained on finding numerical information as words. I also think the effort to save space is contra-productive. Finally, we should use the term for sections/discussions/topics most easily understood and used by general users. What the software calls them should not matter at all; in fact using technical terms outside of technical documentation is a typical trap us programmer-like types often fall into. A big thank you both for your constructive approach! CapnZapp (talk) 09:48, 14 August 2025 (UTC)Reply

Timeshifter's suggestion is clear, easily understandable, written like a natural sentence

I concede it's easily understandable but to me it definitely doesn't flow like a normal sentence.

Aaron's suggestions

What's Aaron's suggestions?

easy to overlook that "in pairs." despite this being the crucial information currently lacking

Well, I'd argue that's the least important information, as the rest is much more relevant (such as how old a topic needs to be).

Numbers should be presented as clearly understood digits; people aren't trained on finding numerical information as words

Sure, you could just use "2 at a time". It's still much shorter.

we should use the term for sections/discussions/topics most easily understood and used by general users. What the software calls them should not matter at all; in fact using technical terms outside of technical documentation is a typical trap us programmer-like types often fall into

Yeah, that's one of the reason why I chose "topic". Out of the 3 you mentioned, I'd say "topic" is the least technical; but I guess this is subjective.

You too! FaviFake (talk) 10:06, 14 August 2025 (UTC)Reply

Haven't read the stuff below but I also have no idea what I have suggested. Aaron Liu (talk) 04:14, 16 August 2025 (UTC)Reply

Sounds like there are two proposals here: one is, "suppress the archive bot notice subsection of Talk header", and I wouldn't support that one, as I am one of the users that does mouse over and read it. The other one appears to be expanding the cleartext (not hidden) message at template Archives, and that should probably be moved there as your message today on that page has already pointed out. Mathglot (talk) 18:50, 13 August 2025 (UTC)Reply

My proposal was to turn off the notice only when the notice wouldn't completely and properly convey the config not in general. When minthreadstoarchive = 1 the bot behave as readers expect it to, and our current notice is therefore unproblematic to display, and I wasn't suggesting turning it off there. The direct problem is instead when minthreadstoarchive > 1; that's how the confusion reported by Redrose64, Timeshifter & Co arises. So how about this template saying nothing rather than saying something directly causing confusion? At least to me, that's perfectly logical. CapnZapp (talk) 10:12, 14 August 2025 (UTC)Reply

"(a vast majority of page config is content with |minthreadstoarchive=1)" – Is that true? Sounds like most pages have misconfigured bots then. "If you set minthreadstoarchive (or the ClueBot II equivalent, |minarchthreads=) to any value greater than 1 (a fully valid use case, btw); use Archives" – No, that's an absurd recommendation, to which I am very strongly opposed. "At Archives the message is thankfully not just a tooltip, it's fully presented as several lines of text right in the template" – yes, that version is distracting and unhelpful and should generally be removed from talk pages unless the article's main author stridently insists (in which case, whatever, it's not worth arguing about). –jacobolus (t) 18:52, 13 August 2025 (UTC)Reply

user:jacobolus: I have read your comments with rising concern. Honestly at this point I don't see that you are acknowledging the problem your fellow editors are reporting. You come across as not caring about the details just as long as you keep down the size and complexity of this template. Hopefully I'm wrong about that. When you think the bot config is "misconfigured" when it sets |minthreadstoarchive=1 that's frankly a strong indicator you don't know what you're talking about. (minthreadstoarchive=1 is very common and fully legit, and so is minthreadstoarchive=2. The benefit of minthreadstoarchive=1 is chiefly this is the only value for this parameter that makes the bot act as newcomers expect, and thus is valuable for not causing confusion. In fact so much so that another discussion made a strong push to make minthreadstoarchive=1 the default) You also do not appear to sympathize that the archive bot notice once was not part of Talk header and thus has been forced into a very constrictive context? Can you say for certain you understand how certain settings of the bot config can make users not understand why the bot doesn't archive their content, how that inconveniences your fellow editors, and how this in no small part is because the current templates (Talk header and Archives) fail to fully inform the users? Because if you don't want to acknowledge the actual problems others are having, I honestly don't think your comments should carry as much weight as comments from those who do. If you want to display good faith, please exhibit an understanding of the problems and positions held by your fellow editors, and, if you must, directly address the concerns you have with these, instead of talking around, ignoring or dismissing their concerns. Thank you very much, CapnZapp (talk) 09:33, 14 August 2025 (UTC)Reply

@CapnZapp Yes, I reject the "problem" you have. It is not a significant issue, and is only of concern to a trivial number of people. The trivial workaround is to look at the page source. You seem to neither understand nor care about the trade-off involved, and you are willing to impose a cost on a much larger number of people (basically everyone on the site) without any consideration. That ends up leading to bad design which is self indulgent and frankly rude. –jacobolus (t) 10:18, 14 August 2025 (UTC)Reply

Your diagnosis of editor complaints about the bot does not seem accurate. The chief problem I see when I look at reader complaints somewhere like User talk:Σ is over-aggressive bot configuration resulting in archiving that happens too fast and cuts short discussion, with users not understanding why their recent discussion was apparently deleted; this is a bot behavior problem, not a talk header presentation problem, and is best proximately treated by relaxing the bot configuration case by case, and best treated at bigger scale / in the longer term by presenting better (less aggressive) configuration defaults in the bot config documentation, and possibly by taking a better census of existing bot configurations and adjusting them to be less aggressive on most low-traffic talk pages. –jacobolus (t) 10:25, 14 August 2025 (UTC)Reply

(edit conflict) Can you at least understand that this, your comments just now, are perceived as much more constructive, since now there's at least something to talk about, where previously you came across as dismissive and or not understanding of the issue? Let me ping those with the issues @Redrose64 and Timeshifter:; they (and perhaps others they in turn can bring here) are better equipped to tell you their issues than I am. I fully agree the first step must be to agree there even is a problem. I just wish you began making clear you're not agreeing one exists. CapnZapp (talk) 10:39, 14 August 2025 (UTC)Reply

Could someone please explain what exactly the issue is? I've read a few messages and have been pinged a few times but can't figure out what you're debating about. FaviFake (talk) 10:53, 14 August 2025 (UTC)Reply

@FaviFake the question on this topic is about what content to include in the talk-header banner shown on a significant proportion of all article talk pages. Currently, whenever an automatic archiving bot is set up for the page, there is a line in the banner that says something like: "Auto-archiving period: 12 months", with a hover popup including further information, along the lines of: "Discussions with timestamps are automatically archived by Lowercase sigmabot III after 365 days of inactivity when more than 5 threads are present."

The question is whether this notice is sufficient, or whether the popup should also describe the setting of the minthreadstoarchive parameter, which would change the text to something along the lines of "Discussions with timestamps are automatically archived by Lowercase sigmabot III after 365 days of inactivity when at least 2 threads could be archived leaving behind no fewer than 5 threads."

In my opinion, this is an unnecessary and distracting additional detail which readers don't need to care about, which can't be explained concisely enough to bother putting here. Talk page readers for whom the details of the bot config matters (a trivially small proportion of all readers) can trivially click to see the page source and read the bot config directly there. I think people's main problem with archive bots is poor configuration, substantially caused by poor recommendations in the archive bot documentation and existing pages since most people setting up new archiving just copy/paste from an existing config. I speculate that nothing we change in the visible message about the bot config in the talk header banner will have any appreciable effect whatsoever on readers' issues with the archive bots. But I generally want to keep the talk banner as simple and concise as possible, because it is one of the most widely used templates on Wikipedia.

However, CapnZapp is deeply troubled by[edit: apparently considers it unacceptable] not having the full specification of the archive bot config in the message, and seems to believe that not including it is a betrayal of some past promise. (I don't really understand that part.) –jacobolus (t) 23:37, 14 August 2025 (UTC)Reply

Please avoid making this personal. It makes you come across as not in good faith. There is absolutely no constructive reason for you to try to paint a picture of me fighting for this on my lonesome. And you absolutely need to cut out language such as deeply troubled or I'll report you for incivility and harassment. This stops right here and now, user:jacobolus. CapnZapp (talk) 10:07, 15 August 2025 (UTC)Reply

I was trying to share my impression, not put words in your mouth. I'm happy to strike that. While you are considering incivility, personalization, and "harassment", consider that you recently claimed that I "come across as not caring" and "don't know what [I'm] talking about", and that you "honestly don't think [my] comments should carry as much weight". You might want to tone down your own sensationalism and personal remarks if you don't want to give people the wrong idea. –jacobolus (t) 15:37, 15 August 2025 (UTC)Reply

@FaviFake: To sum up. Something like the following open text would be substituted in place of the hover text. There would be no hover text. CapnZapp doesn't want the info buried there. I agree. See example below. {{Search box}} and archive list need to be filled in correctly. I just put placeholders in for now. Search box actually works though to search the archives of this page. Narrow browser window to see that the archive list will wrap. Pinging Mathglot and Aaron Liu too.

If it can't be in {{talk header}}, then it will be in {{archives}}. Talk page editors could agree to use it by itself, or like this:

{{Talk header|noarchive=yes|search=no}}
{{archives|banner=yes}}

This way there is no duplication in {{talk header}}.

So talk page editors can decide whether they want open explanatory text, or hidden partially explanatory text via a tooltip. Mobile users can't see tooltip info normally.

--Timeshifter (talk) 07:10, 15 August 2025 (UTC)Reply

Wait what? Since when was that the proposal? I thought your desire was only to modify the hover text.

Replacing the hover text with a directly displayed message is completely unacceptable here, unless you first shop this by the broader wikipedia community to get consensus. Remember: this template is shown on a huge proportion of all talk pages. –jacobolus (t) 15:49, 15 August 2025 (UTC)Reply

It's just a proposal. As I wrote above: "If it can't be in {{talk header}}, then it will be in {{archives}}." To avoid duplication please respond at the end of this section where there is more discussion. --Timeshifter (talk) 15:57, 15 August 2025 (UTC)Reply

I'm having trouble understanding this. I understand that there's a proposal to add the minthreadstoarchive thing to the automatic archives blurb, but what exactly would the separation of the TalkHeader archives notice from the Archives template look like? See also Template:Talk header/testcases for the above proposal to replace that section of the TalkHeader with a transclusion of Archives; they really aren't too different at all. Aaron Liu (talk) 21:28, 13 August 2025 (UTC)Reply

Hi, Aaron. I don't understand, "the separation of the TalkHeader archives notice from the Archives template"; can you elaborate?

To fully understand this section, you should probably know that there is a backstory. I almost hesitate to bring it up, as the discussions there have exhausted me with little to show for it, and I don't wish to resurrect it or be drawn in if it metastasizes. However, it's not fair to hide relevant prior comment, so there you go. I am happy to confirm process or provide factual data upon request (but see here first). Best, Mathglot (talk) 01:09, 14 August 2025 (UTC)Reply

Besides the minthreadstoarchive thing of course, Zapp proposes a compromise to concede that Talk header isn't the place for the full archive bot notice and to make the template depart from Archives is what I currently understand. I don't understand on which aspects exactly this will depart. Aaron Liu (talk) 02:22, 14 August 2025 (UTC)Reply

I will readily admit I am not making a technical suggestion fully informed by the particulars. My thinking goes thus: if Talk header's bot notice detects it is not giving out complete and accurate info, such as when minthreadstoarchive is set to a greater value than 1 (or is left to its default value, also 2), then that notice is contraproductive since it is incomplete. Why not then refuse to say anything, rather then saying something not good enough? Turning it off also makes it obvious something is afoot, and readers will read our template's documentation, which obviously need to explain the situation and recommend users to add Archives. Of course I now assume it *does* have the functionality to tell the full story (as in your and Timeshifter's proposals, just above the Arbitrary break above I just inserted). I have zero clue whether this is easy or hard to implement. That was my thought. CapnZapp (talk) 09:57, 14 August 2025 (UTC)Reply

Again without reading the below comments: Disabling the blurb when the archives template is configured a certain way would go against the reason for Jacob(please tell me I remembered the right name)'s reason to oppose in the first place: that while the other details are of interest to general readers, minthreadstoarchive is not, in his opinion. Doing what you say would remove details of interest to readers. Aaron Liu (talk) 04:18, 16 August 2025 (UTC)Reply

We don't need the full archive bot notice. We need my shorter notice copied from the banner below.

If you look at the tooltip under "Auto-archiving period" in the {{talk header}} at the top of the page you will see that the text there is longer than the more informative text (with minarchthreads info) below:

So the text in the banner could be the tooltip text when there are archives.

I think trying to incorporate {{archives}} into {{talk header}}, either partially or fully, is way too complicated, and unnecessary.

I just showed how to solve the lack of minarchthreads info in {{talk header}}. What happens at {{archives}} should be separate. --Timeshifter (talk) 04:37, 14 August 2025 (UTC)Reply

I think we should really try to get rid off {{archives}} sidebox variant as much as we can. It really is a relic of the vector 2010 skin times when the TOC was a smilar box-ish thing and not in the sidebar.

with Vector 2022 as the new norm, just having a page with {{talk header}} that auto-generates the archives banner style, reading auto-archiving settings and search, there just isn't a need very many times for the standalone template - so maybe just outright deprecation would be preferable?

Or having the option to have the {{archives}} produce a banner by default that has all the functionality that the {{talk header}} currently has, maybe we could even just transclude it into it then so that changes are automatic? (though the runtime cost of that extra transclusion might be a non-starter, given that tph is on so many pages.. Raladic (talk) 05:36, 14 August 2025 (UTC)Reply

I can certainly understand a desire to simplify and streamline. The problem is that there exists a definite need for something to tell users when |minthreadstoarchive= is set to a value greater than 1, since that is a definite source of confusion some users report having to deal with, including User:Redrose64. The issue regarding simplification is that if Talk header, this template, becomes the only way to express the archive bot notice (without reading page source), there is strong resistance to the effort of this template providing all the details you need, in order to understand why the bot isn't archiving your talk section (because it is configured to wait until more sections can be archived in one swoop). One issue is this template is already very complex; people hesitate to make it more complex. Another major issue is that the efforts to simplify have relegated the archive bot notice to only a tooltip, and it's way overlong already.

What is needed (for pages with non-trivial archive bot config) is the space to be able to inform the user in a natural friendly "breathing" manner exactly how the bot is configured. A non-hidden multi-line text really is the only feasible way to say this in a non-contorted manner; that's why I suggested lets leave Talk header alone and focus on the only(?) remaining stand-alone archive template (Archives). Trying to convey all needed info regarding a talk page's automatic archiving in a very short abbreviated manner is imo a fool's errand: the point is to give non-technical readers the insight they need - the only way is to use natural (verbose) language, and not try to cram it in.

In other words, you need to somehow reconcile the strong drive to simplify and save space with the definite need for the opposite. Personally, I'm just about to give up on ever convincing people Talk header's archive bot notice subsection can become truly functional, because giving it enough room to breathe is directly against the drive to compress. I am assuming people aren't opposed to providing enough and complete information overall, but so far I'm resisted with few constructive suggestions how else to proceed: If the Talk header people (you reading this) won't allow Talk header to provide this information in a non-constrictive manner, then you need to tell us where we should and can add it! (My suggestion at the mo is {{Archives}} mostly because I can't see where else) In other words, removing Archives (and other stand-alone archive-related templates) AND refusing to expand Talk header is, unfortunately, the functional equivalent to "I'm happy with the bot notice being incomplete and dysfunctional; I care little for how other editors have to deal with constant confusion".

tl;dr: the problem isn't with the complexity of archiving bots; the problem is we're not giving the room needed to explain the config to users in a natural friendly (verbose) manner. Users aren't reading documentation and they certainly aren't parsing page source. Clearly what's needed is for at least ONE template to exist that uses a multi-line non-hidden message to detail how a specific page's config is set up in plain English. The options are not hard to understand, unless you're trying to convey the message in a contorted manner, say a single-line tooltip so long it disappears before you have time to read and grok it properly. CapnZapp (talk) 09:16, 14 August 2025 (UTC)Reply

OK. It looks like whenever there is minthreadstoarchive (or minarchthreads) greater than 1 then the open-text explanatory info will have to come from {{archives}}. Here is one way:

{{Talk header|noarchive=yes|search=no}}
{{archives|banner=yes}}

This way there is no duplication in {{talk header}}.

Making these changes on talk pages can be done manually for now. Maybe someone could create a bot to do it. --Timeshifter (talk) 13:10, 14 August 2025 (UTC)Reply

Currently neither Talk header nor Archives allow for the information about minthreadstoarchive. (Try adding {{Archives}} to my example talk Talk:Kármán line. Neither the existing Talk header nor the Archives I insert give readers any hint their talk sections might not archive, because the bot is instructed to hold off until it can archive 2 or more sections in one go (which is the cause of the confusion editors are having). I don't know of any other template that offers this functionality either, or any other solution at all. That's why I started a discussion. CapnZapp (talk) 10:02, 15 August 2025 (UTC)Reply

@CapnZapp: OK. I knew it needed to be implemented in {{archives}}. This was just an idea of how to get it to work in the end. Here below is the current banner: {{archives|banner=yes}}

Here below is a possible future implementation I threw together. Needs someone with a lot more coding experience than me to finish it, and put it in {{archives}}.

Search form (from {{Search box}}) works in searching the archives for this page. Narrow browser window to see that the archive links can wrap to 2 lines. --Timeshifter (talk) 16:06, 15 August 2025 (UTC)Reply

Ok so apparently my request to clear things up made them even more complicated. So, here are my thoughts in a simple list; i don't care about who proposed what or if it was proposed at all in this discussion:

1. Would lists or shorter messages illustrate our points better compared to walls of texts? Yes.
2. Should the {{Talk header}} tooltip be removed and the text be displayed in plainext? Absolutely not. This is against all UX guidelines.
   • (added to this list on 22:02, 16 August 2025 (UTC)) Should an optional parameter to display the text outside of the tooltip be added? No, there are no cases where it is that important to have it displayed. I also oppose an option to hide the plaintext sentence behind a [show] button, because the behaviour would be inconsistent between talk pages.
3. Should the tooltip be removed? No, it's useful and not annoying.
4. Should the tooltip be shortened? Yes, it think it's currently too verbose.
   • How? My suggestion is Topics older than 6 months are auto-archived 4 at a time by ClueBot III if there are more than 9.. Every small deviation from the original is intentional.
5. Should |minthreadsarchived= be added to and displayed on the tooltip? Yes but it must be a very short addition. I am very willing to mislead the user slightly if it means a smaller text will be shown. The above, while incorrect, is the max length I'm willing to add, it can't be longer than "4 at a time". Adding an entire subclause at the end is extremely confusing and unnecessarily makes it even more complex.
6. Should the two talk templates be merged in some form? I don't care, as long as the conditions above are met.

Have I missed anything? FaviFake (talk) 21:08, 15 August 2025 (UTC)Reply

Thanks for your concise list of your views on a lot of points. It is an alternative approach to something I have been thinking about, which is just to get an inventory of all the different suggestions because there have been quite a few, and I am losing track. Anyway, I just wanted to mention that your bullet 4 suggestion won't work, because the "4 at a time" part is inaccurate; that isn't how it works. That is, it will not archive in multiples of 4, it might archive 7, or 9, or 10, and so on. You seem to know this, by your follow-up point, but are you really saying you prefer brevity in the message, even at the cost of inaccuracy? Because that is what it sounds like. Mathglot (talk) 21:58, 15 August 2025 (UTC)Reply

Thank you. I hope others do the same. Could you explain exactly in what cases there could be many sections archived if min=4? I might not have understood the situation correctly. Wouldn't it be somewhat rare? FaviFake (talk) 22:00, 15 August 2025 (UTC)Reply

Sure; the aging param |algo= determines discussion staleness (age of last comment in the section) and stale sections become eligible for archiving, unless blocked by one of the two throttling params |minthreadsleft=N, which blocks archiving if it would leave <N sections on the page, and |minthreadstoarchive=M, which blocks archiving if there are fewer than M stale sections. If 5 go stale before the bot shows up, 5 would get archived. Yes, it would probably be rare, imho. Mathglot (talk) 22:26, 15 August 2025 (UTC)Reply

That makes sense. I still think this is worth the compromise in language. FaviFake (talk) 22:29, 15 August 2025 (UTC)Reply

I don't think anyone will be confused if the message says "2 at a time" and the bot archives 5 topics. The alternative would be to just drop that phrase. –jacobolus (t) 22:10, 15 August 2025 (UTC)Reply

I couldn't support an intentionally misleading explanation on a Talk page, but I am not opposed to just dropping it, if that finesses the problem. (Both of those options should go into a neutral, "proposal inventory" to help us track all this.) Mathglot (talk) 22:21, 15 August 2025 (UTC)Reply

I support FaviFake proposal:

Topics older than 6 months are auto-archived 4 at a time by ClueBot III if there are more than 9..

I also support this {{archives}} alternative if talk page editors want a more verbose, and more visible, explanation:

Let the editors of a talk page decide. --Timeshifter (talk) 04:49, 16 August 2025 (UTC)Reply

Thanks, I mentioned the addition of an optinal parameter in my list. To help other editors, you and the other partecipants CapnZapp, Aaron Liu, and jacobolus might want to consider publishing a similar list. I still have close to no idea where you stand on the issue, and I (and I suspect other editors too) wish not to read the previous, long-winded discussions.--FaviFake (talk) 22:02, 16 August 2025 (UTC)Reply

In your previous mention of an optional param (point 2 @21:08 above) you said you were dead set against it. Not quite sure why you raised it again now—is that because you have changed your mind? I guess I just don't understand what you are saying. Mathglot (talk) 22:38, 16 August 2025 (UTC)Reply

I may have misunderstood the previous discussions! point 2 @21:08 talked about a removal of the tooltip with no option to add it back, while point 2 bullet was about an optional parameter that would leave the default tooltip unless activated. Please tell me if I've misunderstood Timishifter's previous comments regarding tooltip removals. I assumed their initial proposal would have changed the default display. FaviFake (talk) 22:55, 16 August 2025 (UTC)Reply

I'd like to, but I can't really help you with whether you have misunderstood something or not (but I sympathize!). Honestly, there have been so many proposals, and slight alteration of previous proposals, and dropping of one proposal for another, and offshoots of proposals, that it would take a cladogram to see how they all relate. One shouldn't have to comprehensively have read everything about a topic in various discussions, pages, and archives and have a photographic memory about the history of it all in order to understand and contribute. I think I am going to forego posting my opinion for a while. I think with time, things will shake out and become clearer, and then it may make more sense to. I am always willing to answer specific, fact-based questions about templates and so on like the one you had above, so feel free to ping me anytime. Mathglot (talk) 23:17, 16 August 2025 (UTC)Reply

Yeah I agree. I may do the same if the walls of text continue. Thanks! FaviFake (talk) 00:27, 17 August 2025 (UTC)Reply

@FaviFake I think your proposed text seems fine, or the current stable version is also fine.

I would advise people to avoid use of the {{archives}} template as a full-width banner, and I think the appearance of that template as a right-floating box has been somewhat harmed by recent changes, relative to my recollection. If I remember correctly the elements listed in the bot notice used to be each optional, so the display could be simplified to only show the most important ones, but now the only way to simplify the display is to throw in "nobot=yes". My advice to folks working on {{archives}} would be to imitate the style of the talk header banner, leaving only a human-readable date as an immediately visible feature and showing most archive config details such as the name of the bot in a tooltip instead.

I would recommend against adding bot-config-related optional parameters to the talk header template. –jacobolus (t) 22:49, 16 August 2025 (UTC)Reply

I want access to at least one way to provide a full explanation ("more verbose, and more visible") with no tooltips, no abbreviations, no minimal word count. Including support for all configurations of the bot; just like when the templates didn't read the bot config automatically, and you could use the four |archive_bot=, |archive_age=, |archive_units=, and |minthreadsleft= parameters to inform the reader. I genuinely think the point (getting readers to actually read the bot parameters to the point they understand when the bot might not act) is lost if the message isn't allowed to be full, complete and accurate. Since it appears there is no hope Talk header will be allowed to support something like User:Timeshifter's Archives mock-up above (posted at 04:49, 16 August 2025) I support it for Archives instead. Allowing a specialized template like Archives to display the message in full sounds logical and useful. Let's just hope everything works when Archives are used in the standard appearance (right-floating box, not full-width banner). As for Talk header, do with it what you will; as far as I can see every proposal for it is compromised. CapnZapp (talk) 00:34, 17 August 2025 (UTC)Reply

Fact check: when the templates didn't read the bot config automatically, and you could use the four parameters to specify the bot notice independently, they were displayed in the tooltip, same place they are now. The sandbox now has rev. 1193759647 of 13:45, 5 January 2024 (not sure how long it will remain there) and you can run it with the bot notice params to see what it used to do. For example:

The bot notice appeared in a pop-up tooltip back then, and it still does today except it works automatically now, without the need for the four params. Mathglot (talk) 02:04, 17 August 2025 (UTC)Reply

Concerning showing any info about |minthreadstoarchive= (User:Lowercase sigmabot III) or |minarchthreads= (User:ClueBot III) in {{talk header}}:

FaviFake's proposal for short tooltip text under "Auto-archiving period". Example:
Topics older than 6 months are auto-archived 4 at a time by ClueBot III if there are more than 9..

It is supported by me, CapnZapp, and jacobolus. Mathglot is still against it? Are you willing to compromise and allow it Mathglot? It may not be perfect, but it is better than before.

We could do a Request for Comment. I don't think any new ideas will come up, and would be a waste of time. I think we have exhausted all possibilities. I could be wrong.

According to the RFC page it comes down to consensus after sufficient discussion. Wikipedia:Consensus says "Consensus on Wikipedia does not require unanimity (which is ideal but rarely achievable), nor is it the result of a vote." In my experience it comes down to a vote fairly regularly, and then it is called consensus. Per the dictionary definition which also does not require unanimity according to 1b below:

Consensus defined:

• https://www.merriam-webster.com/dictionary/consensus

consensus
noun
con·​sen·​sus kən-ˈsen(t)-səs 
often attributive
1
a
: general agreement : unanimity
the consensus of their opinion, based on reports … from the border—
John Hersey
b
: the judgment arrived at by most of those concerned
the consensus was to go ahead
2
: group solidarity in sentiment and belief

I don't think we need an RFC, and should just go ahead with an edit request and do it. I think we already have both the Wikipedia and the dictionary definition of consensus.

After it is implemented I doubt many people will object to the small amount of additional info. --Timeshifter (talk) 10:39, 17 August 2025 (UTC)Reply

I disagree with your view of an RfC about this topic and especially disagree with your unusual view of Wikipedia consensus. The dictionary definition isn't necessarily the one used on wikipedia.

I believe an RfC is needed because consensus among 3 editors is not enough to change such a widespread template, especially after this trainwreck, ahem, this long discussion.

I oppose an edit request, and support an RfC. After all, we're talking about simple yes/no questions; that's the type of questions where RfCs shine. FaviFake (talk) 15:07, 17 August 2025 (UTC)Reply

If the RFC is simple yes/no questions, then I agree with doing it. If the RFC seeks another long discussion then I think we all probably oppose that.

How is my view of Wikipedia consensus unusual? I quoted WP:RFC. And the dictionary definition is exactly what you are seeking: general agreement "by most of those concerned". You want to do it via the results of yes/no questions. Wikipedia emphasizes discussion first. We certainly have done that.

If it was an article change we were doing we'd be done. The change would have been made via WP:BOLD, and one disagreeing editor out of 4 wouldn't be able to stop it. If they did try they would be stopped by WP:3R.

I have seen tiny changes on guidelines and policies made this way. I consider this change tiny. But since you disagree, then please start an RFC. --Timeshifter (talk) 16:27, 17 August 2025 (UTC)Reply

If it was an article change we were doing we'd be done.

Yeah, the only difference is this change affects virtually all important talk pages, while an article change only affects one article.

I have now proposed a question for the RfC, let me know if you have feedack. FaviFake (talk) 19:53, 17 August 2025 (UTC)Reply

I'm not convinced there is local consensus here, even among a handful of editors, and even if it were unanimous, that would not be sufficient to alter the behavior of a template with such wide visibility; you would certainly need a higher level of consensus than that.

As far as starting an Rfc, I am not opposed, but in order to be successful—and by that I mean any outcome which fairly represents general opinion—I think we should pay particular attention to the wording of the Rfc question itself, and spend some time to make sure the list of options (hopefully a very short list) at least covers the concerns mentioned in discussions on this page and elsewhere. That is, I think there should be another subsection below, "Wording of the Rfc", to discuss how to present the topic and word the question neutrally, so everyone here feels that their views are fairly represented, and on par with others. You can always just ignore that and go start one as anyone has the right to do, but my fear is that skipping that step and charging ahead with an Rfc would increase the risk of an unsuccessful outcome, and lead to a possibly contentious Rfc with long-winded discussions more or less repeating all the long-winded discussions here, to no end. I really don't want to see that happen.

A major problem with the creation of an Rfc, imho, is how to present the issue to a general audience so they can vote intelligently on it. The discussants thus far are all more or less experts or at least very interested in the highly technical topics of templating and bot archiving (not to mention hidden text and tooltip popups, which are not available to mobile app users, let's recall), and from what I have seen, there have been misunderstandings on some of the technical points even among us. Given that, what explanation is needed in an Rfc in order to bring volunteers up to speed so they can vote? Even if you lay out a neutrally worded question that everybody here is happy with, if willing participants are confused by the topic—remember how all this got started, based on confusion about how bot archiving worked—then an Rfc might collapse in confusion as well, or result in a sketchy outcome. I don't relish that prospect. If we do an Rfc, let's maximize its chance of success. (edit conflict) Mathglot (talk) 16:45, 17 August 2025 (UTC)Reply

Fully agree with everything you said. This is a huge change FaviFake (talk) 18:24, 17 August 2025 (UTC)Reply

"Supported by" seems like a mischaracterization of what I said, which was: "I think your proposed text seems fine, or the current stable version is also fine." That is, I am indifferent but don't have a problem with FaviFake's proposal to tweak the hover text. –jacobolus (t) 00:04, 18 August 2025 (UTC)Reply

"Supported by" seems like a mischaracterization of what I said too: As for Talk header, do with it what you will; as far as I can see every proposal for it is compromised. Do count me in as a supporter of proposals that satisfy a full explanation ("more verbose, and more visible") with no tooltips, no abbreviations, no minimal word count, also as previously stated. To be specific, User:Timeshifter, your proposal is for Talk header, where I have come to abandon all hope of this ever being pushed through. Archives is a much more hopeful candidate; perhaps there we can get the message (which already is in plainly visible text, not a tooltip) to avoid errors such as "4 at a time". Regards, CapnZapp (talk) 15:44, 19 August 2025 (UTC)Reply

RFC intro starts:

See the tooltip hover text for "Auto-archiving period" for the archiving section of {{talk header}} below:

Answer yes or no. A yes vote supports an archiving message in plain text below the search box as shown below; a no vote means keep it as is, with the archiving message in the tooltip (as in the example above).

{{Talk header}} would look like this below, except the 2 parts would be adjacent to each other separated by a thin line, as one table. There would be no white space between the parts.

End of RFC question; Argumentation and survey begins below this point.

The current tooltip hover text is not readable by mobile users. 75% of Wikipedia visits come from mobile.

Also. the tooltip text is below the 85% minimum font size recommended by the above-linked MOS page for accessibility reasons. "No text should be reduced below 85% of the page's default font size."

There would no longer be tiny tooltip text confusing readers, no more perfect mouse hovers needed to read it all the way through, and no need for a magnifying glass for some people. The plain text has a larger text size than the tooltip text, and is right out in the open. No need for additional clicks or hovers.

The open text is set to 85%. The wording was selected so as to fit on one line in a PC monitor set at a larger font size for people without perfect vision. In other words it would fit on one line for the vast majority of people using PC monitors. In previous discussions participants did not want the overall {{talk header}} to be taller than it currently is.

The exact wording is not important as long as it fits on one line, and it includes info on |minthreadstoarchive= (such as "3 or more at a time"). Previous discussions agreed on the need for that info in {{talk header}} in some form or other. The exact wording will be left up to the template coders.

As for cell phones: In the Firefox browser in the iPhone SE 2020 in landscape mode the tooltip archive box (17 mm) is taller than the plain text box (14 mm). In portrait mode: 24 mm (tooltip) vs 22 mm (plain text). So the plain text box takes up less space on mobile.

Timeshifter (talk) 17:46, 17 August 2025 (UTC). Updated since then.Reply

Initial thoughts:

• I think the Rfc should state what happens now; it doesn't do that currently.
• Your last sentence should be couched as: "C. Other tooltip (specify).".
• What about users who want to continue the current behavior? Do you want to add 'no change' as a third option?
• I think you should mention somewhere, possibly in a notes section at the bottom or something, that this Rfc does not apply to users using the mobile app as they do not see tooltips.
  • Some previously mentioned proposals (including one of yours, iirc) would make it visible to mobile users as well; do you want to add an option for that, or just keep it simple for now and (maybe) deal with mobile users later?
• I am not sure you can impose a closure methodology like ranked instant voting on a volunteer Rfc closer. If you do that, you might not find anybody willing to close it; also, closures are not vote tallies. That said, instant runoff is not needed when there are only two choices. If you go to three or more choices, then you could still ask users to order their choices.
• Do you want to add any background or explanation about pain points that led to confusion previously, or do you plan to just answer questions as you go if they come up?

Thanks, Mathglot (talk) 18:07, 17 August 2025 (UTC)Reply

Yeah I have the same worries. I also think we should definitely use the template itself instead of just text. This would be easier to understand compared to "The tooltip is under Auto-archiving period. See the talk page header at the top of this page and hover over [...] etc. I do not think the voting method should be mentioned. If the consensus is not clear, we shouldn't resort to these. Discussions are not a vote. -- FaviFake (talk)

This is feedback for the later round incorporated into the example above, and announced as a major update below @11:27, 19 August 2025. This latest round is a clear improvement. Further points are more minor than ones before that have been dealt with, but here are some points anyway:

• Re 'RFC intro starts:' Currently, a user has to read a two-line intro (four brief sentences) followed by a Talk header template, followed by "The reason for this RFC is..." before they find out what it is about. Your Question 1 is further down. I would somehow explain what the Rfc is about in sentence one if possible. Even better, state your Q1 in the first sentence, even if it won't make sense just yet to a naive user, and you already have the explanation portions available to explain it.
• Q1 text: Are readers going to understand "tooltip text" ? Probably just linking it to tooltip is enough.
• Re Question 2: "will only show on ... pages ... with minthreadstoarchive set or defaulting to 2 or more" : It defaults to 2, not to "2 or more". I know what you mean, you can set it to 2 or more, but people new to this might get confused; probably need to spell it out.
• The wording of option F ("No change. No open text") seems a bit dismissive (or at least, negative) and non-neutral. It can be described without a negative: Keep as is – text appears solely in WP:tooltip [ hover-text]., or, "Keep current", or similar.
• Q1 or Q2, but not both: If I understand correctly, your Q1 and Q2 are mutually exclusive; responders can only answer one of those questions, not both, right? You say in Q2:

  This question is a totally separate question, and can be implemented regardless of the results of question 1.

It is true that you could implement both, but is that really what you mean? What if they say, Q1=A and Q2=E, then what happens? Do you get both hidden text, and also plain text under the search field? I'm pretty sure you meant just one or the other?

• Data validity: inside the stats box, it already says, "Numbers accurate as of Aug 18, 2025, which is true. But it would also be accurate to add, "... for live data, click the links" or similar, just in case anybody has doubts or wants to see for themself. (I just added something like that at the other page, after you updated it here.) Mathglot (talk) 23:18, 19 August 2025 (UTC)Reply

  I find Timeshifter's RFC to be somewhat confusing. I would recommend instead splitting the possibilities for this RFC into two questions:

  1. Which of 3 basic display methods should the talk header template use for bot config:

     a) the current display of "Auto-archiving period: X time" as visible text with further config details in a sentence in a tooltip,

     b) Full detail directly visible as a sentence, without a tooltip, or

     c) Either (a) or (b) could be shown depending on an optional template parameter, defaulting to (a).

  2. What should be the phrasing of the full details (whether in a tooltip or directly visible):

     a) current text, with no change,

     b) a version that leaves out minthreadstoarchive but is more concise than the current version,

     c) FaviFake's proposed concise version that includes minthreadstoarchive [just pick one version of this, don't present two], or

     d) A longer fully explicit version.

  –jacobolus (t) 23:20, 19 August 2025 (UTC)Reply

  This is very nice, actually, I just hope it doesn't upset the apple cart too much. I also have another concern, which is that with all the considerable effort everybody has already invested, I worry that the majority of respondents may see this as Q1: How many archive nerds can dance on the head of a pin?, but there is nothing I can do about that. I hope I am wrong. I guess we will find out, soon enough.   Mathglot (talk) 23:43, 19 August 2025 (UTC)Reply

  At this point I think I'm gonna abandon this discussion, I don't think I can keep working on an RfC introduction for this long without even knowing if Timeshifter and I will ever agree on a solution. For an RfC introduction. I, too, find Timeshifter's RFC to be unnecessarily confusing and do not think it should be used (i'm not even sure the lead's neutral, which is requirement).

  You all are free to completely modify my proposal in any way, even drastically, and if you want I am willing to initiate the RfC, but I can't keep going in this back and forth in this discussion regarding its wording or scope. FaviFake (talk) 12:31, 20 August 2025 (UTC)Reply

  @FaviFake: You might not have seen the latest changes I made a few hours ago. It's your text that is being offered up as a choice, not my text. I just added 2 words: "or more". --Timeshifter (talk) 13:14, 20 August 2025 (UTC)Reply

  Sure, I wasn't commenting on the choices this time, as I didn't read them. I opened the thread an hour ago. I noticed a couple of them are missing, but honestly I don't care anymore. do whatever you have consensus to do, i'm tired of this talk page. FaviFake (talk) 13:16, 20 August 2025 (UTC)Reply

@Mathglot:. I made the choices even simpler, and incorporated some of your ideas. Thanks for all the feedback. I basically offered a choice of Favifake's suggested tooltip text with the addition of 2 words: "or more". I removed my longer tooltip text altogether.

Favifake's tooltip with the 2 words added is better and shorter. It is easier to read in a tooltip with tiny text. That is where shorter is better.

Favifake's tooltip with the 2 words added is also better in the open text box. It fits on one line. --Timeshifter (talk) 11:19, 20 August 2025 (UTC)Reply

I also find Favi's draft far clearer. Timesh's is hard to concentrate on reading. You could try formatting your suggestion like Favi's. Aaron Liu (talk) 15:43, 20 August 2025 (UTC)Reply

@Aaron Liu: I now have it down to a single yes-no question. Have a look. One question may be enough. --Timeshifter (talk) 16:20, 20 August 2025 (UTC)Reply

It's still very unclear. How is RfCing the blurb wording reflected? I just don't understand what exactly it's asking. Aaron Liu (talk) 18:09, 20 August 2025 (UTC)Reply

I clarified the question paragraph some more. Have a look. --Timeshifter (talk) 18:36, 20 August 2025 (UTC)Reply

I'm still confused, so I think we should just work on improving Favi's. Aaron Liu (talk) 18:48, 20 August 2025 (UTC)Reply

Aaron Liu. I did. I adopted FaviFake's wording, and just added 2 words: "or more". I threw out my wording because it was too long to fit on one line in an open text box. The only real question left is whether people want open text or not. Thus my single question. What are you confused about? --Timeshifter (talk) 19:06, 20 August 2025 (UTC)Reply

What's "all cases"? Does the RfC ask about changing the layout of the banner? And for the uninitiated, what even are these parameters? The details of what "3 or more at a time" represents is confusingly worded and scattered. Arguments are seemingly incorporated into and thus clog up the question statement of what exactly is changed and make it hard to find which is which, potentially causing skipping of important text. Also, I think the original archive blurb's text should be quoted, instead of simply transcluding the current template, for much easier comparison.

I don't see any reason not to use Favi's as a starting point instead. I agree there are problems with the choices he presents, but he gets the statement right. Aaron Liu (talk) 19:17, 20 August 2025 (UTC)Reply

I did.

No you didn't. FaviFake (talk) 20:10, 20 August 2025 (UTC)Reply

@FaviFake: So adding "or more" is not an improvement on your original proposed text? I wonder what Mathglot thinks. See text with "or more" added:

• "Topics older than 6 months are auto-archived 3 or more at a time by lowercase sigmabot III if there are more than 9."

@Aaron Liu: I incorporated your ideas in my latest suggested RFC. Have a look. --Timeshifter (talk) 20:35, 20 August 2025 (UTC)Reply

So adding "or more" is not an improvement on your original proposed text?

Of course it's not if it's added to yours. FaviFake (talk) 20:38, 20 August 2025 (UTC)Reply

@FaviFake: Look at my comment in the "Clearing things up" section at 04:49, 16 August 2025 (UTC). Back when I supported a longer text. Your text below is what I added "or more" too.Reply

Now I support fixing {{talk header}} for the 75% of readers who are mobile users. Via this box at the bottom of the talk header using your text so it fits on one line. Thanks for the idea:

--Timeshifter (talk) 21:03, 20 August 2025 (UTC)Reply

i have no idea what this has to do with anything, but I know you haven't given up on your own proposal so I'm not gonna do anything to mine unless you do. FaviFake (talk) 21:06, 20 August 2025 (UTC)Reply

Steady as she goes. (See this comment, currently, all the way at the bottom of the whole discussion.) Mathglot (talk) 21:15, 20 August 2025 (UTC)Reply

This is feedback for the version announced below ("Now I support fixing...", tagged @21:03, 20 August; diff) and visible currently above, in this revision of 17:47, 23 August. This version is a big change, with three major differences compared to the last version: a) just one question; b) wording alternatives are dropped; and c) no more tooltip (hover text) – the message appears in plain text instead. A single, plain text wording is proposed as a yes-no choice.

• The single, yes-no question is a simplification that makes the Rfc easier for respondents to deal with.
• The flip side of that, is that this version bundles a lot of stuff into one question with a single up-down vote, including the OP issue about adding the minthreadstoarchive param to the tooltip and how to word that, and the issue of having a plain text message instead of the tooltip. That's a lot, and which restricts the options for responders; the wording choices are gone, so there isn't an easy choice for someone who, say, wants to remove the tooltip, say, but doesn't like the given wording; or who likes your wording, but doesn't want minthreadstoarchive.
• The main focus seems to be the tooltip vs. plain text iisue. That's fine, and I have no problem with that per se, as a valid issue for an Rfc and a valid issue to poll users about, but it is like a completely different Rfc than the earlier version which was about wording options, and whether to include minthreadstoarchive or not. To me, this argues for this as a separate Rfc (already discussed below). If we go that route, then your version could be simplified even further, by not offering any particular wording, as that is the point of the other rfc candidate, and just ask, "Should the current tooltip hover text be replaced by a plain text explanation below the search box?" That would avoid the problem of bundling multiple issues into one yes-no question. The downside is that it is a completely different issue, and doesn't address the OP question about minthreadstoarchive, but still a valid Rfc question in its own right.
• Either there is a non-neutrality issue, or I don't understand where your Rfc intro ends, and your sample vote begins. In particular, subsection § Ts proposal explained more contains arguments that favor a yes vote; that is the text you would put in your support vote, it wasn't intended as part of the Rfc question, right?
• To some extent, the non-neutrality issue extends to the discussion about mobile users. It's fine to say (and you should say) in the intro somewhere that mobile app users cannot view the tooltip text. But where you get into, "75% of visits come from mobile. This open text is short. So it fits on one line in the box below", that sounds more like reasoning why you favor a support vote; that shouldn't be part of the intro, imho. I.e., in the intro, 'just the facts': i.e., mobile users cannot view tooltips.
• After the mockups, I would add a brief explanation for responders about what a yes or no vote means as the very last line in your intro; i.e., something like,

  A yes vote supports an archiving message in plain text below the search box as shown above; a no vote means keep it as is, with the archiving message in the tooltip.

In sum, I think this version attempts to bundle too much into a single, yes-no question; if it were simplified to address just the tooltip-vs-plaintext question, it would make a good Rfc imho, leaving the wording questions to be dealt with in a separate one. Mathglot (talk) 19:37, 23 August 2025 (UTC)Reply

Thanks Mathglot for the ideas and suggestions. I incorporated some of them. Please have a look, and give further feedback. --Timeshifter (talk) 20:49, 23 August 2025 (UTC)Reply

Yes, that (rev. 1307472728 (of 0:59, 23 August) is an improvement. My main issue now, is to be sure I understand what text is part of your Rfc question (which should be neutral) and where your vote argumentation begins (which can be as partisan as you want; that is where you get to argue your opinion as persuasively as you are able). It looks to me like the neutral Rfc question ends right above the section heading § Ts proposal explained more, is that right? So that everything above that, is your neutral question, and everything below that from that heading down, is your vote argumentation, so would not appear in the neutral question, is that right? To clarify, you could stick a token up in there, 'End of Rfc question; Survey begins below this point' or some such; I don't mean having those words in the actual Rfc, just here, so we can tell where you mean for the Rfc question to end. (The subsection ===Survey=== is sometimes used for that in actual Rfc's.) Thanks, Mathglot (talk) 09:53, 25 August 2025 (UTC)Reply

@Mathglot: I made more changes. Have a look, and give feedback. Thanks. --Timeshifter (talk) 17:01, 25 August 2025 (UTC)Reply

It looks completely clear now. Mathglot (talk) 18:57, 25 August 2025 (UTC)Reply

This is my RfC suggestion

Which of the following tooltips should be used on the small list of archives in the {{talk header}} template? Rank your choices from best to worst. The tooltip is found by hovering over the "Auto-archiving period" text; see the example below or in the header at the top of this page (more examples). The main improvements are:

• The days are converted into months and the sentence structure is changed.
• If provided, the minimum number of threads that can be archived at once is no longer hidden. (In the example below, it is 3.)

Should an optional parameter be created to display the tooltip text directly? It would only appear when activated manually. Mobile app users do not see the tooltip; with this option enabled, the text would be larger and more accessible than a tooltip. Responses: Yes/No

Rank your choices from best to worst and use Yes/No to vote for the optional parameter that displays the text directly.

What do you think? I tried to strike a middle-ground of all options with option 4). Now, they should all be equally different.

Once we figure everything out and we agree on the wording to use, I would be willing to start the RfC as suggested by Timeshifter. --FaviFake (talk) 19:31, 17 August 2025 (UTC) (Last updated: 10:31, 18 August 2025 (UTC))Reply

Much improved. My main worry is about people new to this tooltip, or even tooltips (or archiving) in general, whether they will understand what the choice is about, and where the '9' and the '4' came from, and so on. That said, maybe you have to draw a line in the sand somewhere, and hope for the best. If there are no wording candidates proposed that seem like a clear improvement, I would be okay with this one. Minor point: I would use A–B–C... instead of 1–2–3, as letters eliminate any slight confusion about whether a '2' is my number 1 choice, or the number 2 option. Also, would you want to give more examples than just this page at the top? You could add, "... or any of these Talk pages [with archives]" (or, 'more examples here') to that sentence. Not sure if that's helpful, or complicates it. But I could go for your version. (edit conflict) Mathglot (talk) 20:18, 17 August 2025 (UTC)Reply

(edit conflict) Yes! I changed it to use letters instead of numbers, thanks. I like your idea of adding the Search link, but your link currently includes some pages that don't have the tooltip enabled, and that would be even more confusing. Could you somehow filter these talk pages? I agree that we should probably explain a bit. I was thinking of using the {{cot}} template with a name like "I'm new to Wikipedia. What is this?" and then explain archiving and the tooltip option in very simple terms. Thoughts? --FaviFake (talk) 20:29, 17 August 2025 (UTC)Reply

Good catch! How 'bout this link for the more examples, with only the ones having the popup? (But check my work; you might find something else.)

I think a collapsible section with more info would be a great idea, and could definitely be helpful. I once considered an Rfc background/help section related to this very topic (the minthreadstoarchive parameter); view it here in the collapsed section. That proposal (which never got off the ground) was for a different purpose, so you won't be able to copy it, but you might be able to adapt some of the content, and the structure might give you some ideas. Finally, in the title bar of the {{cot}} template, instead of "I'm new to Wikipedia...", maybe, "Remind me about archiving, and tooltips, and all that stuff" because there are probably lots of well-seasoned editors who are by no means new, that still don't know much about the topic, and I wouldn't want to discourage them by saying it's a section for newbies. Please improve on my wording, but you see what I mean.

That said, the kind of info we are talking about could be very helpful beyond the life of this Rfc, which makes me think it could be a new Help page, or info page in project space. In order not to delay an Rfc too much with a shiny new Help page, it could just be a subpage for now like Template:Talk header/Archiving tooltip info (or, /Rfc_tooltip_background, or whatever) containing whatever help info you want to collapse. I think it's fine to create a collapsible help section right in the Rfc and have all the help content there, but even better might be a hybrid with a collapse section and either transclude the subpage right into it (thus without increasing byte count here), or a very brief intro followed by a link to the subpage (or even just a long link instead of the collapse section). When this is all over, the subpage could provide the germ for a future Help or project page. Mathglot (talk) 21:29, 17 August 2025 (UTC)Reply

Thanks for the link and for the proposal, they'll be useful. But I'm not really sure a new page is needed? We already have Help:Archiving a talk page and Help:Archiving (plain and simple), couldn't you just add the info to one of these? They also look like they could use a general cleanup and more straighfoward instructions.

I have to go now, but tomorrow I'll try to write it and send it over. Have a good day! FaviFake (talk) 22:13, 17 August 2025 (UTC)Reply

You're probably right about not needing a new page. If you want to have a go at improving it, I'm sure a lot of people would be helped by it. Mathglot (talk) 01:06, 18 August 2025 (UTC)Reply

I'd like to but I don't think I'd have time. I added your suggestions! The previous proposal was really useful. FaviFake (talk) 10:33, 18 August 2025 (UTC)Reply

@FaviFake I think it's worth adding a sentence or so of context that the point of the minthreadstoarchive parameter is to reduce the number of single-thread archiving edits from the bot, to reduce clutter in watchlists and talk page edit history. –jacobolus (t) 18:26, 18 August 2025 (UTC)Reply

The full parameter description mentions only the first of those three in its explanation of minthreadstoarchive:

The minimum number of threads to archive at one time, which is used to lower edit frequency.

The other two items in your list are indeed effects caused by altering the param, but so are reducing server load, cpu time, memory use, and probably other things I could come up with, but none of those are listed in the doc. Neither are watchlists and page history, although those are both effects as well. Why mention them, though, if the parameter description does not? I am not sure we should add our opinions of what that parameter is for to an Rfc about wording choice about what the parameter *does*; it just isn't necessary. If we need to say anything about what it is for (and I don't think we do), then we should stick to what the page doc says, and not introduce editor interpretations of it now. By all means sort it out later in another discussion (or god help us, another Rfc) but here and now is not the time or place. Mathglot (talk) 20:07, 18 August 2025 (UTC)Reply

If you make an RFC, it's useful to (briefly) add enough context so that readers can figure out why this is even here / why anyone would want that setting. That prevents confusion. –jacobolus (t) 20:43, 18 August 2025 (UTC)Reply

I have to agree with Jacobolus here, the point isn't to give a complete list of all the things that it does. The objective is just to give non-technical users a reason for when they ask "why the hell did they create this parameter?". Also, this RfC isn't about what it does, it's about how it's displayed. A bit of context is needed, but not that much. I'll make sure to word it as an example rather than a complete list of things. FaviFake (talk) 21:02, 18 August 2025 (UTC)Reply

These are also the first things that came to my mind, not gpu usage and stuff. FaviFake (talk) 21:03, 18 August 2025 (UTC)Reply

@FaviFake It's not a huge discrepancy, but counts of minthreadtoarchive settings listed in the collapsed box are not quite right, because examples where there was no space "minthreadstoarchive=1" (etc.) were not counted. The regular expressions in these searches need to be adjusted to not require a space after the equals sign. –jacobolus (t) 18:41, 18 August 2025 (UTC)Reply

Are you sure? I don't agree, but perhaps I am missing something. Please indicate specifically which count you think is off and should have a different regular expression. Mathglot (talk) 19:45, 18 August 2025 (UTC)Reply

Sorry, I meant should not require a space before the equals sign. The regular expression

minthreadstoarchive * = *2[^0-9] should be
minthreadstoarchive *= *2[^0-9], etc. –jacobolus (t) 20:45, 18 August 2025 (UTC)Reply

Yes, you are correct. I will fix those, but might not be right away. Anecdotally, they seem to be generous with blanks for alignment (and style consistency?) so as you said, the discrepancy is probably minor. Mathglot (talk) 20:53, 18 August 2025 (UTC)Reply

Thankd for catching that. The updates should be completed, now. That was a lot of numbers to check; please lmk if you find anything awry. Mathglot (talk) 00:08, 19 August 2025 (UTC)Reply

Oh well, I'll let you two figure it out. FaviFake (talk) 20:19, 18 August 2025 (UTC)Reply

That was good, thanks. To avoid creating two different proposals in parallel, I've also implemented your suggestions into my proposal and added the suggestions from Mathglot. Does it look good? I avoided language that was too technical and posed it as a direct question. I think we shouldn't mention the instant-runoff voting, mainly because few people are likely familiar with it, it's not very helpful, and if consensus isn't clear enough it's usually up to the closer's discreton to decide. And, as Mathglot said, "I am not sure you can impose a closure methodology like ranked instant voting on a volunteer Rfc closer. If you do that, you might not find anybody willing to close it". FaviFake (talk) 10:39, 18 August 2025 (UTC)Reply

FaviFake I think my current list of choices for question 1 is more clear than yours. Open text would be a permanent, not temporary change in question 1. I insist on giving people that choice. I am very curious to see how many people support that. I know CapnZapp supports it.

My question 2 is currently clearer too than your question 2.

I think your collapsed info "What is |minthreadstoarchive= and what does it do?" is very good and should be used in the RFC intro above or below the questions. I think it should start off collapsed. Currently, you have it starting off expanded.

Also, there needs to be an actual example of a talk header right in the RFC intro. I just added the talk header for this page to my suggested RFC intro. --Timeshifter (talk) 12:55, 18 August 2025 (UTC)Reply

I think my current list of choices for question 1 is more clear than yours.

Well, we disagree again. I find some of the text in your RfC confusing and I don't understand parts of it. Additionally, you have't resolved some of the concerns Mathglot and I had, specifically regarding ranking. Ranking all of them isn't required and a system for ranking is unnecessary and possibly out of scope for an RfC. The consensus is judged at the discretion of the closer, not the nominator, and isn't based on votes alone.

Open text would be a permanent, not temporary change in question 1. I insist on giving people that choice.

I do not understand what "open text", "permanent", or "that choice" mean, or what they have to do with question 1? No change would be temporary in either of our proposals and it seems we offer the same choice.

My question 2 is currently clearer too than your question 2.

Well, I don't unstand it. What is "this", who "assumes"? Also, it's not a question.

I think it should start off collapsed.

I will do that.

Also, there needs to be an actual example of a talk header.

I'm not sure how we could implement it. We'd have to place it on both designs, but it is unwieldy in my opinion. My proposal already links to many examples.

Look, you suggested I start an RfC and now we have two proposals. I don't like the idea of spending my time arguing about which is "better". Could you make clear suggestions about what exactly you would like me to change, and then we can start? FaviFake (talk) 13:21, 18 August 2025 (UTC)Reply

"you suggested I start an RfC." Well that was before I decided to just go ahead and get the RFC ball rolling by starting the last 2 major subsections:

#Moving on, and possible request for comment

#Possible request for comment questions

In your question 1 choices you don't have an option for a permanent open text version of the archive section of talk header.

Also you have 3 tooltip text options in question 1. Only 2 are needed: Your preferred version, and my preferred version. My preferred version has evolved. No one else has offered other versions to vote on.

Your optional open-text parameter does not have the text. I assume you want it to be the result of the tooltip choices.

I started a question 3 about which choice of text people prefer for the optional open-text via {{talk header}} parameter. --Timeshifter (talk) 16:00, 18 August 2025 (UTC)Reply

starting the last 2 major subsections:

You added 2 headers...

3 tooltip text options in question 1. Only 2 are needed

That is because I want to give people who wish to keep roughly the same sentence structure an option other than "keep the current one". If that option is not there, they'll have to oppose the change and that's bad for both of us. If your or my version is truly better, the people will vote that.

I started a question 3 about which choice of text people

Oh NOW i get it. You want to use a different text if the optional parameter is set? I think this is starting to get too complicated. I think most people are either:

• Not going to understand all the options and simply not respond, or
• vote the same text for both. Why would the text change if it is displayed?

I think this is too uninuitive for one single RfC. We could do one for the tooltip first, and then a second one for the displayed text. Otherwise it's going to be a mess.

Please reconsider doing all of this in one single RfC FaviFake (talk) 16:02, 18 August 2025 (UTC)Reply

In this RfC we would end up asking:

• Should we mention minthreadsarchive?
• Which of these option is best for a tootip?
• Should we add an option to remove it?
• Should we change the text if the tooltip is displayed?
• Which of these option is best for the version of the blurb that is displayed only when the tooltip is diabled?

etc. This seems too much, let's take it slow. FaviFake (talk) 16:05, 18 August 2025 (UTC)Reply

You don't have my current choice:

• Sections are auto-archived by lowercase sigmabot III after 6 months of inactivity if there are more than 9, but only if there are a minimum of 3 sections to archive.
• None of your 3 choices have the bots linked so people can get more info. Your 3rd option (the one that is not mine or yours) is ridiculous, and just confuses people.
• Your question 2 offers an optional open text, but not a permanent open text. I am sure CapnZapp would want that question put out there.
• My current set of questions is easily understandable. Especially with my intro which explains why people want the short and long version. I tried to make that explanation neutral.
• And I did more than just add those RFC headers on this talk page. Don't be insulting. I also made the first posts in those sections. --Timeshifter (talk) 16:56, 18 August 2025 (UTC)Reply

• Huh, you're right. I fixed that.
• Bots are now hyperlinked. Regarding the third option, it's there because I want to give people who wish to keep roughly the same sentence structure an option other than "keep the current one". If that option is not there, they'll have to oppose the change and that's bad for both of us. If our versions are truly better, the people will vote our versions and you don't have to worry about other option.
• It's not like I'll understand if you repeat the same exact words over and over again. I don't have a clue what a "permanent open text" is or what Capp wants.
• I liked your second bullet point, but your first bullet point is not neutral. You're specifically advocating against one of the options you're proposing. That defeats the purpose of an RfC. Let the people be the judge. I added your second bullet to mine. I'll repeat: I find some of the text in your RfC confusing and I don't understand parts of it. And I know exactly what we're talking about. Instead of telling me why your version is not unclear, could you tell me in what way my version is apparently unclear?
• Sure, i was half joking

are you happy now? please. FaviFake (talk) 20:39, 18 August 2025 (UTC)Reply

also could you please explain what CapnZapp wants using different words? The displayed tooltip option would already be permanent once set. FaviFake (talk) 20:40, 18 August 2025 (UTC)Reply

For consistency and shared maintenance with {{archives}}, I would recommend not having the new blurb diverge too much from {{Automatic archives blurb}}. Aaron Liu (talk) 18:17, 19 August 2025 (UTC)Reply

@Aaron Liu: How about this blurb (under the search form and archive list)?:

See question 2 here: #Timeshifter's suggested RFC intro. Compare to the {{Automatic archives blurb}} in {{archives|banner=yes}}:

See {{archives}}

--Timeshifter (talk) 18:54, 19 August 2025 (UTC)Reply

Yeah, I personally think that looks reasonable. Just in terms of the blurb. Aaron Liu (talk) 19:46, 19 August 2025 (UTC)Reply

@Aaron Liu Oh, I thought the goal was actually to change both the tak header and archive blurb together. I don't see benefits in the archiving explanation differing depending on which underlying template is used to display the same info. FaviFake (talk) 12:20, 20 August 2025 (UTC)Reply

Except the "This page has archives." part, as that is not needed on talk header. FaviFake (talk) 12:21, 20 August 2025 (UTC)Reply

Changing the blurb template and having the talk header's blurb also use {{automatic archives blurb}} would also be fine. Aaron Liu (talk) 15:39, 20 August 2025 (UTC)Reply

Aaron, trying to keep track of everything, I have added H4 section header over your recommendation below (@18:50, 20 August). It maintains some parallel structure in the ToC that keeps things more comprehensible to me; hope that is okay with you. Please feel free to move/reword/delete it, if you are not happy with it. Thanks, Mathglot (talk) 19:56, 20 August 2025 (UTC)Reply

Another thing I would recommend is splitting the response section into two: one for each question. These are going to be very different discussions and they should be in at least two different sections by topic. Aaron Liu (talk) 18:50, 20 August 2025 (UTC)Reply

Which of the following tooltips should be used on the small list of archives in the {{talk header}} template? ~~~~

For reference, here's what the archives section currently looks like. The tooltip with the wording is found by hovering over the "Auto-archiving period" text; see the example right below or in the header at the top of this page (more examples).

Below are the options. The main changes are:

• The sentence structure is changed.
• The archive durations (120 days) will be converted (4 months) with {{human readable duration}}, like what the template currently does in the upper-right corner.
• If provided, the minimum number of threads that can be archived at once is no longer absent. (In the options below, it is 3.)

B > D >> C >> A. The absence of |minthreadstoarchive= has caused confused users to complain at Talk pages and Help pages that "the bot is not archiving their discussions, and why not?" Oftentimes, the reason is that there is only one archivable discussion on their Talk page, and the missing |minthreadstoarchive= param is set to 2 or higher. Currently, the only way to check if the parameter is set is to open the source code, which is annoying to do routinely. It takes one or two extra clicks compared to simply reading it in the existing archive message.

Those who are not power users or have otherwise misread the archiving manual have to have |minthreadstoarchive= explained along with the remedy, namely changing |minthreadstoarchive= in their config. This is just a lot of unnecessary pain for everyone involved: those running into the "non-working" bots, and the editors always explaining the reason why. Displaying |minthreadstoarchive= to the user would fix that.

also B is the best D C super janky blah blah blah ~~~~

To add the factual "or more" thing, plus make the choices describe the same archiving scheme, I suggest this. There can be a separate discussion to change "Discussions" to "Sections" or "Topics"; having it vary between those in the choices just messes up the variables a bit since participants might go for a choice only for the "Sections" while hating the wording. On "3" vs "3 or more", participants can also just argue to remove the "or more" if needed.

Per Mathglot's suggestion I've turned this into a full RfC proposal. Previously I only gave the Q1 options table for Favi's consideration.

Emphasized Q2 words per Mathglot. Previously, Favi changed the Q3 tooltip text to reference Q1 instead of "above".

Implemented Mathglot's suggestions, with a touch of "separate". Also, removed the dates from the changelog to hopefully make talk page notifications more representative; redaction syntax doesn't usually update the timestamp anyways.

Dropped Q3—Timesh's formatting option per Mathglot. Adjusted wording to reflect only RfCing the wording. the example below→the options below per Mathglot.

Replaced "Discussions" in the template's context with "Topics". Dropped Q2. Per jacobolus. Also kind-of drastically shuffled around wording to compensate for Q1 being the only question. Signing since a re-read would be helpful. Aaron Liu (talk) 13:57, 25 August 2025 (UTC)Reply

I feel like this builds on both of the previous ones, both Timeshifter's and Favifake's. It is also a simplification, as it asks only one question (as Ts's last update did), which I think is great, while preserving some of the clear language (as Ff's latest), and reduces blurb wording variation (best handled at another time, imho). I could go with this wording as the essentials of the Rfc question. What I am not clear on is whether this is how you envision the entire Rfc statement before opening it up for comment, or whether you assume the inclusion of any of the explanation material in the other two proposals or anything else, or just leave it exactly as shown above, and then let 'em have at it. Mathglot (talk) 20:04, 20 August 2025 (UTC)Reply

Upon rereading it, I think you were just addressing one question, and still mean to have two of them, the other being whether it is in the tooltip, or in plaintext, is that right? Can you show (or link) how you envision the whole thing? Feel free to just alter/add without redaction conventions; there is only this response so far, and I won't get confised. Mathglot (talk) 20:11, 20 August 2025 (UTC)Reply

Thanks. I decided to put my notes into their own dedicated section to see the suggestion itself more clearly. Aaron Liu (talk) 22:06, 20 August 2025 (UTC)Reply

That looks amazing. The only thing I've just thought of is a gray color for the Q2 options text after the first word of each option, to emphasise that it's the only word that would change. (And I've updated the text of Q3 to reference Q1 specifically instead of "above").

I love it! It's perfect. FaviFake (talk) 22:23, 20 August 2025 (UTC)Reply

Thanks! I've added the emphasis. (It would replace twice for option C, though.) Aaron Liu (talk) 22:37, 20 August 2025 (UTC)Reply

Thanks! (Wdym?) FaviFake (talk) 23:08, 20 August 2025 (UTC)Reply

Option C) mentions "discussions" twice ("minimum of 9 discussions"), so it would get two occurrences of whatever ends up the result. Aaron Liu (talk) 23:40, 20 August 2025 (UTC)Reply

Very good! Some minor suggestions for clarity:

• Should and how should... ⟶ Should the {{Talk header}}'s archives section be updated in [its] wording and layout, and if so, how?
• Note that consensus from this RfC is likely to also affect {{archives}}. ... ⟶ likely to affect the {{archives}} template as well – (to alleviate possible confusion between the term '{{archives}}', and the archives they see in the example)
• Q1: Which of the following tooltips... ⟶ Which of the following [[tooltips]]...
• Q1: see the example below or in... ⟶ see the example [[#some anchor|'''below''']] or in
• Q1: * The days are converted into months and the sentence structure is changed. ⟶ The sentence structure is changed. – (there is nothing in this proposal that changes anything having to do with how days are converted into months)
• Q1: * If provided, ... is no longer hidden ⟶ * If provided, ... is no longer missing|absent – assuming I understood this correctly, this doesn't mean any of: in an Html comment, collapsed, or in hover text; if it does mean any of those, that is not clear)
• Q2: wording is good; wouldn't care if this question were dropped (one fewer question) but okay either way
• Q3: I'm ambivalent; pro (i.e., keep Q3 in the Rfc): shouldn't hide info from mobile users; con (drop Q3): three questions are somehow a lot scarier than two; mobile hiding is not our fault – they don't see navboxes either (and other stuff) so why do we have to complicate a template to fix a WMF issue? I lean con, but don't let that hold up release of a good version, I will go with the flow.
• In the collapsed explanation section:
  • It instructs the bot to not archive discussions... ⟶ It instructs the bot to skip [or, 'to avoid] archiving discussions...
  • |minthreadstoarchive='s value is not displayed to the user anywhere except in the source code. ⟶ Currently, |minthreadstoarchive='s value is not displayed to the user. – (we do not display source code to the user)
  • This proposal aims to display STUFF more prominently. ⟶ I This proposal aims to display STUFF. – (it isn't that it is more prominent, it's that it wasn't displayed at all, and now we are proposing to display it)

Nice touch with the changelog, btw; beats the hell out of redaction decoration in a case like this. Thanks for this great effort; I feel like we are right on the brink. Mathglot (talk) 00:04, 21 August 2025 (UTC)Reply

Thank you! I've implemented most of the changes.

• I've just replaced "below" with a reference to the RfC banner since that's where I moved the "here's what it currently looks like" to.
• The days are converted into months in the proposed tooltips; I've hopefully clarified this.
• If the Q3 formatting is something only one editor supports, go ahead and drop it. Otherwise I think it's better to have this all in the same RfC with split sections, since some might be annoyed at being FRS-notified multiple times for closely-related things.
• stops the bot from; "skip" feels weird and "avoid" sounds like it might do it.

And yes, the collapsed section is gonna be subst'd. It's only a transclusion here because its length would otherwise make editing the draft unwieldy. Aaron Liu (talk) 00:47, 21 August 2025 (UTC)Reply

I support this version as good for an Rfc – namely, § Aaron Liu's suggested RfC intro in rev. 1307010177 of 00:47, 21 August 2025. Mathglot (talk) 01:02, 21 August 2025 (UTC)Reply

P.S. Can you either subst, or copy the sandbox to a[n unchanging] subpage here before this gets archived? (If only we had a way to know how long that might be...  ) Mathglot (talk) 01:07, 21 August 2025 (UTC)Reply

I'll just hopefully remember to subst it when the RfC opens. More proposed changes to the collapsible might arise! Aaron Liu (talk) 01:11, 21 August 2025 (UTC)Reply

Oops, one more thing, sorry: I think maybe we should drop Q3 for now. It is not at all clear to me that a parameter is the right way to go, because that affects one talk page for everybody, or could affect everybody, mobile or not, depending how you define it. A new parameter is perfectly fine to include it as an option in an Rfc (maybe even this one) but it is far from the only solution, and I would oppose a question that did not present the other valid options to deal with that issue.

Various approaches are possible: a new parameter changes it for all visitors for that page, mobile or not; an {{if mobile}} test (and no param) changes it from tooltip to plain text for all mobile visitors to all talk pages, but leaves the tooltips alone for all desktop visitors to all talk pages; keep as is but add a css class option on the text with both tooltip and plain text versions with opposite display: css values could default to plain for mobile but tooltip for desktop would allow parameterless control via an override in common.css as an opt-in per user that would allow anyone (mobile or not) to flip it from tooltip to plaintext. None of this is insurmountable or even difficult, but it does offer several paths which would need to be discussed as far as the wording and everything, and if we were starting from zero I wouldn't see a problem with resolving it now, but I think folks here are at the breaking point, and if we discuss one more thing everybody will go nuts. Do you see a problem of putting this off until a second Rfc down the road, solely to deal with tooltip vs. plain text, and how mobile users fit into that? (edit conflict) Mathglot (talk) 01:29, 21 August 2025 (UTC)Reply

And (sigh) these two:

• The main changes are... ⟶ The main changes in the tooltip are...
• (In the example below, it is 3.) ⟶ [what example? do you mean, the text in the five options? if yes:] In the tooltip options D and E below, it is 3.

Mathglot (talk) 01:50, 21 August 2025 (UTC)Reply

I think having a public discussion about whether to use the name "discussions", "sections", or "topics" is a waste of time. Pick any one, or decide via a poll here. –jacobolus (t) 23:18, 20 August 2025 (UTC)Reply

I've removed Q3.

• Is that not clear already? The question only changes the tooltip, and the change would be confusing to me as implying changes beyond the tooltip exist.
• Changed to "In the options below". B and C have it too.

Aaron Liu (talk) 04:01, 21 August 2025 (UTC)Reply

Well, I disagree. I don't see how a less public discussion would be any better than including it in the RfC. It'll probably get near-unanimity, for what it's worth. Aaron Liu (talk) 23:40, 20 August 2025 (UTC)Reply

Because every additional question and complication you add confuses readers, fragments the discussion, and adds noise. It's not worth wasting people's time unless there's actually some kind of controversy. I'd go for "topics", but any of these three terms is completely fine and effectively interchangeable. –jacobolus (t) 00:00, 21 August 2025 (UTC)Reply

The discussion is already divided into three discussion sections. They don't mix like one big section. Aaron Liu (talk) 00:47, 21 August 2025 (UTC)Reply

Okay, but I've seen no evidence that this is at all controversial. Does anyone have a problem with any of these terms? If someone just calls it a "topic" (or "section" or whatever) is there a complaint? You shouldn't just ask the whole community a question for the sake of asking a question. If you personally strongly prefer the existing term "section" but a few others of us have been using the name "topic", I don't think there's any serious objection to leaving the name as "section" (or at least, I have no complaint with that). To me this doesn't seem worth bothering the community about; it seems like an irrelevant distraction from whatever other question the community was supposed to be answering. –jacobolus (t) 01:36, 21 August 2025 (UTC)Reply

I didn't weigh in on this before, because I really just want to get us over the finish line, so I almost hate to say it, but I agree with j here. I don't feel super strongly about it, but the main question is hard enough and anything we can do to simplify is a +, in my book. That said, I don't object if you feel it must be included. Mathglot (talk) 01:57, 21 August 2025 (UTC)Reply

I believe it's pretty needed because the status quo uses "Discussion" instead of any of the alternatives, while Q1's Option C) would benefit from an alternative selection like "Topics". I don't want the RfC to be clouded and distracted with discussion over "Discussions" while participants weigh in on the actual question like y'all, and while I agree it's unsure whether the community will find Q2 controversial, I don't want us to be unsure and risk things.

The alternative is to just change the live tooltip to "Topics" or "Sections" right here, right now. I'm fine with either, but not "Discussions". Aaron Liu (talk) 03:55, 21 August 2025 (UTC)Reply

Understood, and am okay with including it on that basis. Mathglot (talk) 04:00, 21 August 2025 (UTC)Reply

I support you if you want to change the live tooltip to "topics" or "sections" right now (pick either at your discretion). –jacobolus (t) 04:23, 21 August 2025 (UTC)Reply

Am also okay with change now to either one. Mathglot (talk) 04:32, 21 August 2025 (UTC)Reply

I'd object to using anything other than "topics" in the live tooltip. FaviFake (talk) 15:28, 21 August 2025 (UTC)Reply

Ok, I'm back.

I oppose removing Q2, to avoid people voting based solely on the first word. These are two very different changes, 2 questions are needed.

I support removing Q3 per the incredible explanation by Mathglot. We definitely need a second RfC for this, likely with many options such as the ones Mathglot described. This RFC looks ready to go. FaviFake (talk) 14:49, 21 August 2025 (UTC)Reply

Would be okay if we removed Q2 but changed the live tooltip to say "Topics" instead of "Discussions" and adjusted accordingly? Aaron Liu (talk) 15:39, 21 August 2025 (UTC)Reply

Yes, it would. I don't love the idea of 40 thousand talk pages being changed to satisfy my personal preferences, but i guess we could consider this a bold edit.

You are a really good mediator, Aaron. FaviFake (talk) 15:47, 21 August 2025 (UTC)Reply

Regarding the "What is that" green collapse bar content under Question 1, I have a few comments: The overall design looks good, but there is one segue or flow issue, and maybe some minor points to address.

• The introductory bullet just above it introduces the concept of "minimum number of threads that can be archived at once" and the top paragraph introdues existing paramater |minthreadstoarchive=, so that is consistent and a good segue; lets the reader understand that this section will be about minthreadstoarchive. This is good.
• But then the next paragraph, starting with the bolded term 'Background', switches to talking about |minthreadsleft=. That seems like a context-switch; why are we talking about a different param than the one we started with? Or, is this a sign that we are about to list all the params? This was a little confusing.
• The third paragraph ("the point of this parameter...") is back to talking about minthreadstoarchive again. Now it feels really confusing, like we are jumping back and forth.
• Skipping the nested collapse section, paragraph 4 starts out, "The problem: This is not displayed to the user anywhere except in the source code", but what is This referring to?
• What did you mean by, "All of the bot config params have values..." ? Did you mean, "...have default values..." ? Params in config sections do not actually have to have values, and they don't always have them; that's when the bot defaults come in.
• P5: "It also takes a lot more times..." ⟶ "It also takes a lot more time..." ?
• P6: "Implications: All bot-archived pages that have a minthreadstoarchive param will continue to work as before. The only difference will be the displayed text." But all bot-archived pages that do not have a minthreadstoarchive param will also continue to work as before, so what are we trying to say here?
• The data in the nested blue collapse bar should be updated per the new values at § Miszabot/config data. But it is brand new, and you might want to hold off just a bit until we are sure there aren't problems or further updates.

Thanks. Mathglot (talk) 00:45, 19 August 2025 (UTC)Reply

Fixed! in the future feel free to update it yourself if you want to, I don't mind as long as it helps start this RfC FaviFake (talk) 07:56, 19 August 2025 (UTC)Reply

"takes a lot more time" also seems like quite an exaggeration to me. How about "takes one or two extra clicks". –jacobolus (t) 08:00, 19 August 2025 (UTC)Reply

  Done FaviFake (talk) 08:47, 19 August 2025 (UTC)Reply

@FaviFake: Under 'main improvements', you have: ^{[decoration added]}

• The days are converted into months and the sentence structure is changed.
• If provided, the minimum number of threads that can be archived at once is no longer hidden. (In the example below, it is 3.)

Some thoughts:

1. Days to months is not a proposed change; it already does this. (I presume you are not proposing further changes to the way that works.) The sentence structure changing is indeed something new, and can be in the proposal.
2. I believe you meant absent or missing, and not hidden, is that right? I would avoid use of the word hidden, which is an overloaded term and can mean a) inside <!-- Html comments --> and thus visible only in the wikitext, or b) collapsed, or c) in hover text (tooltip), which is invisible (hidden) for mobile users. Incorporating those changes would give:
   • The sentence structure is changed.
   • If provided, the minimum number of threads that can be archived at once is added to the message. (In the example below, it is 3.)
3. But now what about the If provided part? Do you mean to exclude it from the message if it is not provided, and therefore defaults to 2? That would seem to defeat one of the main purposes of the whole proposal, which is to clear up the confusion about what the value is, and what it does. Don't you want the value in the message, provided or not? If so, then it becomes:
   • The minimum number of threads that can be archived at once is added to the message. (In the example below, it is 3.)
4. But in "the example below" (I assume you are talking about the Talk header example with Index, 7 archives, and 6 months param?) the tooltip does not include a value for minthreadstoarchive, so if you mean another example, you should link the word below to wherever it is, or use some kind of explicit description about which example it is.

I think you are close. Thanks. (P.S. With the outdent below, it wasn't clear where to place this, but this is a reply to Ff's 08:47, 19 Aug. post above, and was posted after Ts's 11:27 post below.) Mathglot (talk) 22:14, 19 August 2025 (UTC)Reply

I updated the stats in my collapsed box to match the Aug 18, 2025 update. Thanks Mathglot for updating the stats!

I also made a major update to my RFC intro: #Timeshifter's suggested RFC intro. There are now only 2 questions, and they are much simpler. --Timeshifter (talk) 11:27, 19 August 2025 (UTC)Reply

@Mathglot: I am now down to a single yes/no question. Have a look. --Timeshifter (talk) 17:14, 20 August 2025 (UTC)Reply

Houston, I think we are go for lift-off! (Referring to Aaron Liu's suggested RfC intro in rev. 1307033774 of 04:01, 21 August 2025.) Everyone good? Mathglot (talk) 04:13, 21 August 2025 (UTC)Reply

I think Aaron Liu's intro is clearer. So I removed that background info from my suggested RFC:

#Timeshifter's suggested RFC intro.

So if you add my single question about open text, then we are good to go. I think it would make CapnZapp happy too.

I think Aaron's question 2 about discussion, section, and topic is trivial, unnecessary, and a waste of valuable RFC time. I don't care what is used in the tooltip. It is not a space issue there. Let whoever is coding it decide. Let them change it back and forth as they see fit.

Question 1 is the important question that deals with minthreadstoarchive.

My question about an open-text box is a lot more important than the choice of discussion, section, or topic.

--Timeshifter (talk) 07:52, 21 August 2025 (UTC)Reply

Let whoever is coding it decide. Let them change it back and forth as they see fit.

That's not how WP works, we need consensus and currently there isn't one. RfC are used to build consensus.

My question about an open-text box is a lot more important.

Yes, that's actually why we decided to remove it. Please read this explanation for why a second RfC for this is needed. There's more than one off/on switch, and it's a different issue from the one we're tackling with this RfC. A second one is needed. FaviFake (talk) 14:53, 21 August 2025 (UTC)Reply

Also, consider stopping pinging CapnZapp so frequently. They're not involved anymore and if they want to be, they'll come back. FaviFake (talk) 14:55, 21 August 2025 (UTC)Reply

Yes, seems we're all good. There seems to be consensus among everyone but TS, which hasn't partecipated in the discussion for removing Q3.

I'm assuming Aaron is going to start it. We're finally done! FaviFake (talk) 14:57, 21 August 2025 (UTC)Reply

What consensus? jacobolus opposes the question about discussion, section, and topic.

Mathglot was talking about a plain text box that only shows up for mobile users, or other partial options.

My question asks whether it should totally replace "Auto-archiving period" and its tooltip. For all readers, desktop, mobile, etc..

It's simple, and if supported, we are done. No more tiny tooltip text confusing readers, no more perfect mouse hovers needed to read it all the way through. No need for a magnifying glass for some people. No need for all these added steps. Plain text is right out in the open. Problem solved. CapnZapp would approve. He's on my talk page, and hasn't told me to stop pinging him.

--Timeshifter (talk) 15:24, 21 August 2025 (UTC)Reply

What consensus? jacobolus opposes the question about discussion, section, and topic.

I stand corrected. FaviFake (talk) 15:29, 21 August 2025 (UTC)Reply

Timeshifter, I would like to respond to your points. But first, I think we are at a critical point, here. I think we are very close to consensus, but we are also at risk of losing everything accomplished so far. Let me see if I can recapitulate where we we are now, and how we got here. (Or, just skip down to the three points.)

To your three points about lack of consensus:

1. Jacobulus did initially oppose Aaron's Q2 initially, as you said, but in subsequent discussion is okay with just changing it to topics or sections right now, and so am I. If you are, too, then we have consensus on number 1.
2. Regarding the bit I raised about "a plain text box that only shows up for mobile users" and so on: this is not a new proposal intended for now (it would probably kill the Rfc if we tried to discuss it at this point). It was part of an argument (diff) about why Aaron's Q3 should not be included at this time, but rather in a subsequent Rfc, which Aaron graciously accepted (and so does Ff). If you want to see what Question 3 looked like before it was removed, you can go here. If you have no objection, then we have consensus on point 2.
3. In #3, you wish to replace the tooltip and put everything in plain text instead, iiuc. I think we can resolve this. If we add an Option F to Aaron's Question 1 that said the following, could you accept it?
   • Option F): Use the wording above [from option A – E] (indicate which) but put it in plain text so it is always visible, and not in a tooltip.

You can see what Option F) might look like in context, at this link. Please indicate if you would accept this wording. If you do, then I think we have consensus on all three points, and can launch. I think we are right on the verge, but I think everyone is pretty exhausted, and has given ground in order to get to an agreement. I hope you can agree on this last point, so we can launch an Rfc. I'd hate to see us lose the opportunity to do so now, after all this work it took to get here and we are so close. (P.S. This was really hard to put together; it could be there are some non-working diffs or links, and I apologize in advance if so. If you notice any, please lmk, and I will fix them.) Thanks. Mathglot (talk) 01:53, 22 August 2025 (UTC)Reply

I just wanted to say, I appreciate how commited you are to this. The collapsed summary might be useful for summarising this discussion for RfC partecipants. FaviFake (talk) 09:33, 22 August 2025 (UTC)Reply

No, Mathglot. Do not add the plain text option in your format to the RFC. It does not remotely do it justice. It needs to be well-explained in order to get approval. See my format:

#Timeshifter's suggested RFC intro

You guys go ahead and do your RFC.

I will do a separate RFC later about plain text completely replacing "Auto-archiving period" and its tooltip after this RFC is over. I think you should do my RFC first by itself in my format. Without your RFC questions being asked at all. Because if plain text was approved we wouldn't need your RFC at all. We'd be done. I think you should seriously consider this. Do you really believe the tooltip method is better? 75% of visits come from mobile. --Timeshifter (talk) 09:39, 22 August 2025 (UTC)Reply

A couple of quick points:

• I agree that shoving option F) in our RFC [...] "does not remotely do it justice. It needs to be well-explained in order to get approval". This needs a separate RfC
• The mobile interface is very small and many people might think we don't need more clutter. But this should be debated in an RfC, as you said.

FaviFake (talk) 09:44, 22 August 2025 (UTC)Reply

Out of curiosity I pulled out the ruler and measured how tall the tooltip archive box (17 mm) is versus the plain text box (14 mm) in my suggested RFC intro. In landscape mode in my iPhone SE 2020. In portrait mode: 24 mm (tooltip) vs 22 mm (plain text). --Timeshifter (talk) 10:19, 22 August 2025 (UTC)Reply

That will be a very strong argument in the next RfC. FaviFake (talk) 10:24, 22 August 2025 (UTC)Reply

I think we are finally ready! --FaviFake (talk) 10:28, 22 August 2025 (UTC)Reply

It seems we finally are. Though based largely on FaviFake's version and other input, Aaron, your version is the one that got consensus and I think you should get the honors for releasing it, if everyone is okay with that. Do we want to wait a couple days for the dust to settle, or should we just go for it? Mathglot (talk) 18:20, 22 August 2025 (UTC)Reply

Yeah, I say we just go for it. FaviFake (talk) 09:48, 23 August 2025 (UTC)Reply

Sorry for the delay, all. I'll start the RfC once the edit request below to implement "Topics" is implemented. Aaron Liu (talk) 13:49, 25 August 2025 (UTC)Reply

I've started the tooltip wording RfC below. Aaron Liu (talk) 00:57, 26 August 2025 (UTC)Reply

Hi. Is it possible to have this template ignore redirects when listing automatically detected archives? Thanks! InfiniteNexus (talk) 06:25, 20 August 2025 (UTC)Reply

Example, please. Mathglot (talk) 06:28, 20 August 2025 (UTC)Reply

Well, I just moved my user talk page archives from numbers to years because they were becoming unmanageable, but the template now lists both. I guess I could just speedy-delete the redirects left behind, but I was hoping to preserve their histories and avoid breaking incoming links. If this change is not possible, I'll just do that. InfiniteNexus (talk) 06:34, 20 August 2025 (UTC)Reply

I don't think the template should automatically ignore redirects, because there may be users who want the opposite: i.e., they might have had oddball archive names in the past which the template would not pick up and display, and added redirects to them so it would. So I don't think we should do that.

Theoretically, you could make a request for a new param, |followredirects= with yes/no values which would do that, but let's just see if there is an easier solution first that will handle your case, before changing the template.

I think there is a workaround that will work fine for you, namely, moving the redirects away from the standard archiving naming system. As a test of concept, I moved your existing "Archive 11" redirect; it can now be found at User talk:InfiniteNexus/redirects/Archive 11.

Now go refresh your Talk page; see what it does? Once it hits a "missing" archive number in sequence, like the now missing User talk:InfiniteNexus/Archive 11, it looks like the template figures that #10 is the last one, and stops listing them after that one, even though redirects User talk:InfiniteNexus/Archive 12User talk:InfiniteNexus/Archive 12 through User talk:InfiniteNexus/Archive 31User talk:InfiniteNexus/Archive 31 still exist. So it looks like if you just move Archive 1 to User talk:InfiniteNexus/redirects/Archive 1, you will be done. Important: you have to move it *without creating a redirect* or it will not work! If it were me, I would move all of them for the sake of consistency, so you don't have to look in two places for them later, when you forget exactly what happened, but that's up to you. Does this solution work for you? Mathglot (talk) 18:27, 20 August 2025 (UTC)Reply

Thanks, I'll do that. InfiniteNexus (talk) 06:01, 23 August 2025 (UTC)Reply

InfiniteNexus, you're welcome. Let me know if you need help moving without leaving a redirect, without which this scheme will not work. Mathglot (talk) 06:04, 23 August 2025 (UTC)Reply

I came up with a different solution using your missing-number trick: since the Archive 1 redirect has no meaningful history (having been left behind from a move), I just tagged it for speedy deletion. Thanks again for your help! InfiniteNexus (talk) 06:12, 23 August 2025 (UTC)Reply

Yes, that definitely will work as well. Happy editing! Mathglot (talk) 06:17, 23 August 2025 (UTC)Reply

This is very helpful and detailed, you could consider adding it to WP:ARCHIVING or this template's doc. Unless it's already there. FaviFake (talk) 10:24, 23 August 2025 (UTC)Reply

FaviFake, if you think it would be helpful to have some version of it on one of the pages, by all means, go for it!   Mathglot (talk) 05:24, 26 August 2025 (UTC)Reply

on line 41. Consensus for this starts from #c-Jacobolus-20250821042300-Aaron_Liu-20250821035500 until the next subheading. Aaron Liu (talk) 13:49, 25 August 2025 (UTC)Reply

I am fine with this, but should probably abstain from implementation as I am involved. Mathglot (talk) 18:59, 25 August 2025 (UTC)Reply

  Completed. P.I. Ellsworth , ed. – welcome! – 22:17, 25 August 2025 (UTC)Reply

Which of the following tooltips should be used on the small list of archives in the {{talk header}} template? Aaron Liu (talk) 00:57, 26 August 2025 (UTC)Reply

For reference, here's what the archives section currently looks like. The tooltip with the wording is found by hovering over the "Auto-archiving period" text; see the example right below or in the header at the top of this page (more examples).

Below are the options. The main changes are:

• The sentence structure is changed.
• The archive durations (120 days) will be converted (4 months) with {{human readable duration}}, like what the template currently does in the upper-right corner.
• If provided, the minimum number of threads that can be archived at once is no longer absent. (In the options below, it is 3.)

B > D >> C >> A. The absence of |minthreadstoarchive= has caused confused users to complain at Talk pages and Help pages that "the bot is not archiving their discussions, and why not?" Oftentimes, the reason is that there is only one archivable discussion on their Talk page, and the missing |minthreadstoarchive= param is set to 2 or higher. Currently, the only way to check if the parameter is set is to open the source code, which is annoying to do routinely. It takes one or two extra clicks compared to simply reading it in the existing archive message.

Those who are not power users or have otherwise misread the archiving manual have to have |minthreadstoarchive= explained along with the remedy, namely changing |minthreadstoarchive= in their config. This is just a lot of unnecessary pain for everyone involved: those running into the "non-working" bots, and the editors always explaining the reason why. Displaying |minthreadstoarchive= to the user would fix that.

Among the options that include this information, B is the best in my opinion. B-sides b-ing short, it just flows well. D introduces a (nitpicky?) ambiguity by not relating the archive age to the topics themselves, and two of its bolded numbers being right next to each other feels somewhat confusing and overwhelming; it's easy to read "if there are more than 9 and 3 / can be archived at once" at first instead of "if there are more than 9 / and 3 can be archived at once". I think C is even worse because of how awkward "auto-archived" looks, the lede burying inherited form the status quo it was based on, and how tacked-on the |minthreadstoarchive= part feels. Aaron Liu (talk) 00:57, 26 August 2025 (UTC)Reply

Notified: WT:TPG. Aaron Liu (talk) 04:12, 26 August 2025 (UTC)Reply

Notified: WT:ARCHIVE, User talk:Lowercase sigmabot III/Archive HowTo, User talk:ClueBot Commons. Mathglot (talk) 05:51, 26 August 2025 (UTC)Reply

I know the archive bot notice info was put in a tooltip to save space, but as Graham87 says, there are concerns. Another (possibly even bigger) issue is tooltips aren't shown to the majority of our readers using their mobiles! So I strongly prefer a solution where we editors have at least one option to add a template to talk pages that spell this stuff out as plain text (no tooltip, no attempts at saving space, a full unabbreviated complete and correct archive bot notice that provides the full picture as to when the archive bot takes action and - to the main point here - does not take action).

As for the actual survey, my first choice would be option C, with option B as my second choice. (B isn't perfect because it lacks the "at least" info nugget: more than 9 and at least 3 can be archived at once. If that were to be added, I would view option B as equal to option C. I oppose options A and B - they are either incomplete or incorrect or both. If it turns out we can't reach a consensus to provide full and complete information in {{Talk header}} my backup proposal is to drop its archive bot notice functionality and instead build out {{Archives}} to provide option C as full text accessible to every visitor. My thinking is that as a specialized template, the pressure to favor brief but incomplete (confusing, misleading) information would not be there. CapnZapp (talk) 10:17, 26 August 2025 (UTC)Reply

Doesn't B include "at least" with "3 or more"? What else about B is incomplete or incorrect? Aaron Liu (talk) 13:15, 26 August 2025 (UTC)Reply

Coming here soon... Mathglot (talk) 02:06, 26 August 2025 (UTC)Reply

Extra information shouldn't be in a tooltip, per this part of the accessibility guideline. I don't know that it's there with my screen reader, for instance. Graham87 (talk) 08:25, 26 August 2025 (UTC)Reply

A separate RfC to have a way to display the tooltip as plain text is in the works at Template talk:Talk header#Timeshifter's suggested RFC intro. This RfC is just about the wording of the tooltip we've already adopted in this template, including that of a future implementation that allows it to be accessible and likely that of the {{archives}} template. In conclusion, how this text is displayed is irrelevant to this RfC IMO and should be discussed elsewhere. Aaron Liu (talk) 13:13, 26 August 2025 (UTC)Reply

The problem with dropping archives info from this template is the people who already expect archives info in this template. noarchives is not a parameter often used. (And as a side note, I have work on having this header just transclude the actual Archives template at TM:Talk header/sandbox anyways.) Aaron Liu (talk) 13:17, 26 August 2025 (UTC)Reply