Template talk:Talk header

Proposal to drop archiving params

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

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

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

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

This proposal is linked from WP:VPR with an expiration 3 weeks from now, to allow sufficient time for this to air. Mathglot (talk) 10:40, 3 March 2024 (UTC)

What about Template:Archives

@Mathglot: Would it be worthwhile to add this functionality to Template:Archives as well? Tollens (talk) 23:30, 29 February 2024 (UTC)

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

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

Support - yes, if you want to contribute by writing a script/bot to get the information straight from the source, letting us bypass a manual element that mostly introduces a source of errors, this is of course very welcome! CapnZapp (talk) 12:00, 1 March 2024 (UTC)

I have something in the sandbox there, but it's not working yet. I basically got lost in a twisty little maze of curlies, all alike, and trying to fight my way out. Not sure when or if I'll get back to it, but it should point the way if someone else wants to have a look. At least the new code is comprehensible due to indentation, but I'm probably missing a curly higher up someplace. No new script needed, by the way; it calls the same parsing template developed for the solution here. Currently, it's a subtemplate of Template:Talk header, but if we use it from two places, maybe it should be spun off into its own root page. Mathglot (talk) 21:54, 1 March 2024 (UTC)

I'm happy to give it a go – what exactly was the issue? It looks like a bad parameter was being used for the minimum number of threads to keep, but other than that I can't see anything wrong. Curlies all seem to match up far as I can tell. Tollens (talk) 22:31, 1 March 2024 (UTC)

Made a couple other tweaks. As an aside, do we want to move the information about the specific archival bot and minimum threads to a tooltip as was done with Template:Talk header? I know I've used Template:Archives with only the age parameter on my user talk for quite some time and would prefer to keep it appearing that way or similar rather than having the other information be forced to display. Tollens (talk) 23:20, 1 March 2024 (UTC)

Thanks; as long as it's just in the sandbox, you can do pretty much what you like. I'll have to go look again to remind myself what the problem was. But a discussion section should probably be started there, linking/summarizing this one, to explain what it is that is being discussed. That box has had a different presentation for a long time, and any move of info to a tooltip should probably get consensus there, imho. Or now that I think about it, as it concerns two templates (maybe more?) perhaps at a more centralized venue, like Help talk:Archiving a talk page. Mathglot (talk) 02:43, 2 March 2024 (UTC)

Noticed your changes—thanks for that—and added a couple more. Wanted to add some test cases, but if this holds up, and there are no objections from regulars at the Talk page there, I think this would be a beneficial change, and keep the two templates relatively in sync. The same test cases as found at Template:Talk header/testcases4#B. Testing with the subtemplate but tested in situ should work here as well. Mathglot (talk) 12:00, 2 March 2024 (UTC)

Proposal to drop archiving params – break

How about ClueBot III? Graham87 (talk) 04:54, 29 February 2024 (UTC)

Thanks, wasn't aware it used a different config; it can be added. Do you know of any others? Mathglot (talk) 04:57, 29 February 2024 (UTC)

Graham87, it supports Cluebot_III configs now; any other bots you know of that need to be supported? Mathglot (talk) 08:34, 29 February 2024 (UTC)

@Mathglot: Nope, that's it. Your ping didn't work by the way, probably because of the shuffling around of messages. While I'm thinking about it I support removal of the now-redundant parameters; it means I won't have to make occasional updates of archiving bot names like this (a previous bot run caught many of them, but not everything). Graham87 (talk) 09:21, 29 February 2024 (UTC)

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

I think there is value in displaying such data - but they'd need to be the actual archive data and thus be displayed from User:MiszaBot/config. So yeah, remove 'em from this template. Jo-Jo Eumerus (talk) 07:51, 29 February 2024 (UTC)

Yes, it is displaying actual archive data pulled from the config. Currently, either MiszaBot, or Cluebot, whichever one it finds on the page. Mathglot (talk) 08:51, 29 February 2024 (UTC)

For the (rare) talk pages that have more than one archive config on the page, see #Pages with two bot configs. Mathglot (talk) 20:37, 5 May 2024 (UTC)

(That's archived here.) Mathglot (talk) 18:56, 30 July 2024 (UTC)

how and when to drop the bot notice params

This was supposed to run three weeks according to the notice pointing here from WP:VPT, but for some reason, the section there got archived, even with a {{DNAU}} in place. But it was there for over two weeks, and no objection was registered. Here's what it would take, imho, to drop the four bot notice params from the {{Talk page header}} template:

1. make sure interested parties here are good to go with this; handle any concerns
2. remove params |archive_bot=, |archive_age=, |archive_units=, |minthreadsleft= and their aliases from the template code, except for the unknown parameter invocation at the bottom. The effect will be that Talk pages currently containing these params will begin displaying data directly from the config params (if any) and stop overriding the actual configured values with the values given in the params. Pages having no archiving will stop displaying false notices. The parameters will still exist, but have no effect.
3. update the doc, removing the four from the main Parameters section but adding a temporary deprecated notice for some period (a year?)
4. at some point (no hurry), request a bot to remove deprecated params from transclusions of {{Talk header}}; maybe WP:AWB can do this with an appropriate regex.
5. Once the bot is complete (do Advanced search to make sure), remove the params from the unknown parameter invocation at the bottom.
6. Remove the doc page deprecated params notice.

The first three should be done whenever we are ready, which I think is now; unless there is some objection. The last three are optional, but it makes sense to do them, and will declutter the template code and the doc. The section above on § minimum number of sections archived, and in general, anything regarding what wording to use in the notice is completely independent from dropping the bot params, and the two processes may continue independently without taking the other into consideration. Probably subsections 3 and 4 should be broken out into a new, top-level discussion section about new wording, because they aren't really related to the dynamic bot notice topic at all. (edit conflict) Mathglot (talk) 03:01, 20 March 2024 (UTC)

7 – Spot check some cases in Preview mode (see tests at Template:Talk header/testcases2) Mathglot (talk) 05:52, 11 October 2024 (UTC)

Two subsections moved to § New and modified bot notice wording proposals. Mathglot (talk) 04:21, 20 March 2024 (UTC)

FWIW, Wikipedia:Village_pump_(proposals)#Feedback_sought_for_proposal_to_drop_archival_bot_notice_params_from_Template:Talk_header is there when I looked just now. CapnZapp (talk) 13:59, 29 March 2024 (UTC)

Hi Capn, yes, I see it; not sure what you meant to say about the VPR thread.

As far as the steps above, it's been a month since the auto-generation of the bot notice was installed on 29 Feb., and I haven't seen any response, so that's a good sign that probably nobody even noticed, and at a minimum, we didn't break anything because that would've caused howls right away. I think we can move on to step 2, at least, when someone is available to do it. I'll be away starting in a few days and I don't want to start something now that might break and require attention just when I'll have no time for it. I'll have wifi occasionally for questions while away, but I wouldn't attempt template coding from my phone. Of course, there is nothing stopping anyone else from updating it who feels like doing so. Steps 4 & 5 can even be ignored forever; the downside is that there would be stale code in the template that does nothing, which is inelegant and makes it harder for other template editors to maintain it or add new functionality, so it's still a good idea to do those steps at some point, if possible. Mathglot (talk) 00:01, 30 March 2024 (UTC)

Mathglot, if it helps I'm happy to take care of 4. — Qwerfjkltalk 19:36, 16 April 2024 (UTC)

Qwerfjkl, yes that would help, thank you, with the caveat of revisiting dependencies in the numbered steps first. I believe the simple, 1–6 enumeration is too simplistic, and a linear sequence doesn't properly represent interdependencies among them. I believe 5 & 6 must follow 4, but 4 is independent of 2 & 3, and may be done before, after, or simultaneously with 2+3. In addition, 3 could be done before 2, to discourage having to run 4 twice. In fact, maybe the sequence should be: 3 (without the temp deprecated notice), followed by 2 and/or 4 in any order, followed by dependencies of 4. Do you agree? If so, I'll update the doc, and then we can move on the rest, with your assistance at your convenience. Mathglot (talk) 23:23, 16 April 2024 (UTC)

Mathglot, sure, that sounds good to me. — Qwerfjkltalk 05:48, 17 April 2024 (UTC)

Or maybe we should keep a small deprecated notice, as some users will remember the old params and wonder what happaned to them? Mathglot (talk) 23:25, 16 April 2024 (UTC)

• Step 3 done (remove four bot notice params from doc). Next up: remove from template (will require sandbox changes and testing first). Mathglot (talk) 07:58, 17 April 2024 (UTC)
  • Mathglot, let me know when you want me to file a BRFA for this. — Qwerfjkltalk 14:50, 28 April 2024 (UTC)

    Qwerfjkl, thanks for the reminder. Step 3 (remove from /doc) is partially done: those params have been grayed out and tagged as deprecated in the doc. I just created a new sandbox with the four params stripped out per step 2 (diff), and that is now ready for testing. The removal was quite straightforward, but because of WP:THOSEDAMNCURLIES and the high visibility of the template, I want to take this slow and easy, and maybe get more eyeballs on it before releasing a change of this magnitude. (I'm scattered all over, so feel free to remind again if this stagnates.) Thanks, Mathglot (talk) 21:46, 28 April 2024 (UTC)

    Test cases A–1 to A–5 and A2–1 to A2–10 completed successfully. These are all ExpandTempates tests. Mathglot (talk) 00:07, 29 April 2024 (UTC)

    So, I'm happy with the current state of testing, and it looks like this is ready to be moved to live. I will do so shortly, but in an abundance of caution due to the high visibility, I'm pinging @Primefac, Trialpears, and MSGJ: to see if there are any objections. In a nutshell, if released to live this change will implement step 2 above (and open the way to step 4, the bot run which Qwerfjkl kindly offered to take on). Not releasing it would mean that transclusions of {{Talk header}} that use these bot params on Talk pages would have possibly incorrect archival information displayed in the Talk header, depending on whether the param values happen to be in sync with the actual archive config or not. If I don't hear anything in a few days, I'll release it. Regardless of feedback, I take full responsibility for the forthcoming release, and any errors that result from it are mine alone. Thanks, Mathglot (talk) 20:20, 5 May 2024 (UTC)

     Done. This (step 2) is now moved to live. Let's wait a few days more to see if there are any problem reports, and if not, we can move ahead with the bot. Aidan9382, would you mind monitoring for any problem reports? If they come up in the next three to four days, I can handle it, but after that, I may have spotty wi-fi for a few weeks, so if reports come in later requiring a revert, would you mind doing the revert for me? Qwerfjkl, if all goes well, I'll leave the bot step in your hands, and on your own timetable. Thanks, Mathglot (talk) 04:49, 10 May 2024 (UTC)

    I'd be happy to look out for any reports, though what change(s) would I be reverting and what could be the potential issue? Aidan9382 _(talk) 06:19, 10 May 2024 (UTC)

    Thanks, Aidan. The edit to revert would be rev. 1223139724‎ of 04:32, 10 May 2024, which removes the four archiving params |archive_bot=, |archive_age=, |archive_units=, and |minthreadsleft= from the set of parameters in the template. It's hard to know what issue might turn up, but likely it would be related to the presence (or absence?) of one of those parameters that hasn't been foreseen in any of the test cases, so I can't know for sure. But if something does turn up, I imagine we'll likely hear about it here eventually. Mathglot (talk) 06:48, 10 May 2024 (UTC)

    Mathglot, it's been around a week. Any issues with moving forward with the bot work? — Qwerfjkltalk 19:17, 16 May 2024 (UTC)

    None I am aware of; I think we are good to go. Mathglot (talk) 04:20, 17 May 2024 (UTC)

    Mathglot, sorry for the delay on this. Am I correct that this is just a straight removal of those 4 parameters from all uses of {{Talk header}}, and there's nothing else to consider? — Qwerfjkltalk 16:08, 5 June 2024 (UTC)

    No worries, there's no particular urgency. And yes, you're correct, as the template no longer looks at them at all (except for the param validation section, in order to avoid throwing an error on legacy transclusions that still use them). That said, if there are a lot of uses of those params, perhaps it's wise to do a small initial run to see if anyone squawks. It seems unlikely, but I suppose it's not impossible that some other template is using {{Tmpv}} to gather the content of those params and do something with them. I'm probably worrying too much, and if you want to just go for it, I think we are pretty ready. Mathglot (talk) 18:53, 5 June 2024 (UTC)

    Mathglot, BRFA filed. — Qwerfjkltalk 20:52, 5 June 2024 (UTC)

    Nice, thanks. Monitoring the trials. Spot-checked about a dozen, and noticed it missed one param in this edit at Talk:Barack Obama, and two in this at Talk:Acupuncture. Seems to be param |units= in both cases, plus |bot= in the latter case. I'm wondering if a leading blank is implicated. Mathglot (talk) 03:24, 7 June 2024 (UTC)

┌───────────────────────────┘
Mathglot, I think the bot's taken care of as many of these as is possible to find with a simple search. If you make a tracking category I can run the bot on that. — Qwerfjkltalk 14:59, 18 July 2024 (UTC)

For what it's worth, I find these watchlist-flooding edits annoying at scale, and would rather have bots wait until they have meaningful changes to make before pushing through site-wide changes like this. (Cf. WP:COSMETICBOT.) –jacobolus (t) 23:18, 18 July 2024 (UTC)

jacobolus, bots provide a real service, making many small, repetitive, beneficial edits that would be very annoying and time-consuming for human editors to make. Each bot edit leaves a human editor with a bit more time to do something productive that requires some thought, and is more enjoyable and rewarding for the editor. Those are good reasons to support bot activity. That said, having bot edits flood your watchlist can be annoying, as well. Fortunately, you can easily fix that in a single procedure, by turning off bot edits in your watchlist, as described at Help:Watchlist#Options. That should permanently solve the problem for you, reduce the flooding (except when human editors do the same thing), and leave a lot more room on your Watchlist for actual, human edits that you'd prefer to see. The more these repetitive tasks can be offloaded from human to bot, the better your watchlist will be, and the more we can all concentrate on more productive tasks. Mathglot (talk) 01:09, 19 July 2024 (UTC)

Sure, but this particular bot action of removing a recently deprecated no-op parameter does not serve any urgent or very important purpose, and large-scale trivial bot editing also imposes an attention cost on many human editors site-wide. Again, please read WP:COSMETICBOT. "Just stop watching bots" is not good advice. Bots routinely screw things up.–jacobolus (t) 02:58, 19 July 2024 (UTC)

Not sure what you mean by "Bots routinely screw things up", but if you know of a specific problem with a particular bot, it would be helpful if you could raise a discussion at the talk page of the bot user, at least to report what your experience has been that was sub-par with that bot. If nobody tells them, they can't fix it. Mathglot (talk) 08:18, 19 July 2024 (UTC)

What I mean is, it's worth having human editors keep an eye on what bots are doing, because bot edits are not always improvements to the encyclopedia. It's certainly fine if some people want to ignore bot edits, but that't not really a good reason to flood watchlists of the others. Anyway, this particular example isn't too big a deal, but in general bot operators should read WP:COSMETICBOT and consider whether they can defer this type of edit and combine it with something substantive. –jacobolus (t) 13:03, 19 July 2024 (UTC)

Jacobolus, I could monitor RecentChanges and only edit pages right after a normal edit, but that adds a huge burden on me for an otherwise trivial task. — Qwerfjkltalk 16:10, 19 July 2024 (UTC)

In my experience, I find it much more worth keeping an eye on what humans are doing, because human edits are not always improvements to the encyclopedia. While I have reverted a handful of bot edits over time, the numbers are orders of magnitude lower than the number of human edits I have reverted for just cause. On an even smaller number of occasions I have discussed improvements with bot operators, and if you see a problem, you can, too. This is all somewhat o/t for this page, but could be useful at WT:BOTN if you see a general issue that you would like to raise there. Mathglot (talk) 16:39, 19 July 2024 (UTC)

Qwerfjkl, that sounds like a good idea; I'll look into it. Mathglot (talk) 00:45, 19 July 2024 (UTC)

Mathglot, any update on this? Qwerfjkltalk 19:04, 18 August 2024 (UTC)

Qwerfjkl (or Mathglot), if you feel like merging rev. 1241008417 of the sandbox into the template it will add pages with the deprecated parameters to Category:Pages using Talk header with deprecated parameters. Tollens (talk) 19:57, 18 August 2024 (UTC)

I'll do some tests on that one tomorrow (concentrating on page 4), but superficially (existing test cases) it seems fine. Mathglot (talk) 06:23, 20 August 2024 (UTC)

@Mathglot? Qwerfjkltalk 16:10, 22 September 2024 (UTC)

I have added these test cases for testing categorization of pages using deprecated archiving parameters, and will go through them tomorrow. A few spot checks while running through them all turned out as expected. Noticed one small thing at the Category page, which is that it didn't mention minthreadsleft but that is a minor, doc-level only issue, and in any case, that param never occurs singly so is extremely unlikely to be responsible for missing a category, even if not specifically coded for, because one of the other params will trigger the category. Mathglot (talk) 08:54, 23 September 2024 (UTC)

Oh, my bad, made a typo there on the category page. The actual template code does do minthreadsleft, not minthreadstoarchive, which was never a parameter in the first place. I've fixed it there and on the test cases page. I wouldn't expect that this change would possibly not work – it's just one call to a preexisting module that does this kind of check, copied from the example on its doc; I think this would be safe to merge. I see there's been a change made since I drafted that, so a revised version that can be directly copied over is rev. 1247345256. Tollens (talk) 22:34, 23 September 2024 (UTC)

Darn, I just completed testing for all the new tests targeting this using rev. 1247169007 (a copy of your rev. 1241008417‎) minutes before your recent round of changes (all cases pass in situ and via ExpandTemplates) and was about to switch over and start doing regression. But if this is a new version, I guess I will have to do them again. Maybe I will just spot-check, and if they seem all right, will move over to regression. Mathglot (talk) 22:42, 23 September 2024 (UTC)

I have been testing your recent version, and have gone through tests D-1 – D-10 (via Expandtempilates) and they all pass, and in situ tests E-1 – E-11 also pass. This is a good sign, and it only remains to go through regression tests now to make sure nothing is broken, and then it can be released. Mathglot (talk) 05:01, 24 September 2024 (UTC)

Okay, regression looks good. I've been testing with rev. 1247404890 which is equivalent to your 1247345256 (diff), and if there are no objections, I will release this to live. Mathglot (talk) 01:02, 25 September 2024 (UTC)

Released. The category should populate shortly. Mathglot (talk) 10:06, 27 September 2024 (UTC)

@Mathglot I think the category should have populated by now, so I'm running the task. I think cases like Special:Diff/1249965244 could be handled better i.e. displayed as 3 years (see #Archive timing information appearing in the talk header should be human readable). Qwerfjkltalk 19:34, 7 October 2024 (UTC)

The task is complete. I've manually removed all the remaining usages, despite User talk:Vestrian24Bio still showing in the category. Safe to remove the check for deprecated parameters? SWinxy (talk) 18:29, 8 October 2024 (UTC)

Thanks. Yes, it is safe, and we are now at step 5 of the list, but it is not urgent, and no one will see any ill effects from not doing it. It's just superfluous code now. It's up to the community to prioritize it, but personally, I would put it off until some other tasks are done first, for example, I would put the task mentioned by Qwerfjkl at a higher priority, and do that one next. (And there are other tasks pending.) Mathglot (talk) 01:06, 9 October 2024 (UTC)

I've just removed a few more pages from the category, so I think the tracking should remain in place for a while. It doesn't do any harm, and it wouldn't suprise me if there's still going to be old pages popping up in the category every now and then. IIRC, template-populated categories can be weird like that sometimes. --rchard2scout (talk) 13:58, 9 October 2024 (UTC)

I've populated the category with what I think are all the ones that didn't come up on their own. Tollens (talk) 04:43, 11 October 2024 (UTC)

It looks like the category is still being populated, currently at 155 pages. @Qwerfjkl, is it possible to re-run the bot task? --rchard2scout (talk) 08:39, 11 October 2024 (UTC)

@Rchard2scout, I think it'd be best to wait a week or two and then clear out the category. Qwerfjkltalk 08:49, 11 October 2024 (UTC)

That was me – I ran a script to null-edit all the pages that didn't go in on their own so I think that should be all of them. Probably still best to wait a week or two as Qwerfjkl suggests above just in case, but I don't expect there to be any more. Tollens (talk) 15:12, 11 October 2024 (UTC)

Is there a clear summary of the proposal / intended change?

I don't really understand what is being proposed here, what has been implemented so far, what will be implemented in the future, etc.

I would strongly recommend that this template:

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

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

All information aside from archive time on this one is only located in a tooltip (you can see an example on this page's header if you hover over "Auto-archiving period"), so in this case, unlike Template:Archives, I don't see the harm here because it's only visible when you're looking for it. I agree completely with your second point. Tollens (talk) 22:16, 11 April 2024 (UTC)

Got it. I didn't realize it was a tooltip. (The tooltip seems fine!) I was coming here after seeing the change to {{archives}}, where the bot name is now presented by default on every talk page using that template. –jacobolus (t) 22:22, 11 April 2024 (UTC)

@Tollens I'm not sure if this was different when you answered, but this is now no longer true. I have explicitly set "|archive_age=3 |archive_units=years" on the template and in the body of the banner (not the tooltip) it says "Auto-archiving period: 1095 days", which was automatically pulled from the bot config.

This is a serious bug in my opinion, a reader hostile regression made without consensus. It must be fixed or reverted. The date must either (a) be automatically converted to a human-accessible unit, or (b) the explicit template parameters must be respected. –jacobolus (t) 20:49, 22 May 2024 (UTC)

First off, this discussion / these discussions are extremely hard to follow, with progress made in many places at once, including this sub-discussion that's placed in the middle of something from April. I'll simply start a new header below to say my piece, and let everybody decide for themselves how relevant it is to what various work they're currently doing. CapnZapp (talk) 05:39, 23 May 2024 (UTC)

Agree with your 2nd point here, but that is another proposal that should start off a new, top- level section as a discussion or edit request. Imho, it’s not a good idea to keep piggy-backing on additional requests onto an earlier request, which isn’t completed yet, especially in the case of a template with such high usage and visibility. We need to let this one complete, without additional complications. That doesn’t mean you can’t start another section now as it can be discussed and implemented completely independently from the current request. Does that help? Mathglot (talk) 00:28, 12 April 2024 (UTC)

New and modified bot notice wording proposals

Subsections § Convert Cluebot hours to days? and § minimum number of sections archived refactored here, as they are independent of the previous section.

Convert Cluebot hours to days?

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

I'd suggest rounding anything over 23 hours. I can convert 36, 48, 72 hours, etc. in my head, but it takes some thought. Would rather see that in 1.5 days, 2 days, 3 days format. –Novem Linguae (talk) 10:02, 29 February 2024 (UTC)

Sure, this sounds fine. Even if it involves some loss of precision, I have a hard time conceiving of any situation where it would matter that a talk pages be archived at a large but precise number of hours. Sdkb ^talk 14:51, 29 February 2024 (UTC)

Especially as there's no way to know what kind of delay might be involved before the bot gets around to visiting the page. Mathglot (talk) 23:48, 29 February 2024 (UTC)

Delays should not be taken into account. If a page claims archiving will happen after 6 or 18 or 30 or 60 hours, we should probably say that even though the actual arching cadency is just once a day... Cheers CapnZapp (talk) 14:35, 1 March 2024 (UTC)

 Done. A description of this new functionality can be found at § Archive bot notice; please have a look and adjust as needed. Mathglot (talk) 07:02, 1 March 2024 (UTC)

I would not round any hour figure lower than 72. Starting to round already at >23 feels unnecessarily aggressive. CapnZapp (talk) 14:32, 1 March 2024 (UTC)

No worries; it's incredibly easy to change it to any figure that comes out of consensus here. Mathglot (talk) 21:22, 1 March 2024 (UTC)

For archiving bots that use hours as the default units, they are converted to days, rounded to the nearest half-day This I take to mean ANY number is rounded to a multiple of 12 (half a day). I would suggest a more conservative start. Do not round any hours-number lower than 72 for starters, then let consensus drive rounding of lower numbers. The other way round assumes we will revisit the subject later. I think now is the only time you will hear voices to avoid rounding smaller numbers, so please consider this to be the consensus you'll get. CapnZapp (talk) 09:11, 2 March 2024 (UTC)

Thanks for pointing that out; I neglected to mention the > 23 threshold, so I tweaked the doc, which should be accurate now; sorry for the confusion. As far as what the threshold should be, 72 sounds fine, so does 96, so does 24; it's easily changeable and I have no strong preference myself. Mathglot (talk) 10:00, 2 March 2024 (UTC)

If my voice is the only voice with an opinion: start with 72 and change it if somebody asks for it. Not the other way round, partly because doing it that way in effect willfully ignores suggestions you are getting now. Why can't suggestions now hold equal weight to those that you (probably won't) get later? Thanks CapnZapp (talk) 14:04, 29 March 2024 (UTC)

Any multiple of 24 hours should definitely be presented as X days; this is significantly more likely to be the intention than hours per se. Odd multiples of 12 hours should generally be presented as X.5 days, though maybe 12h or 36h can be left as exceptions. If someone has some weird value like 20 or 50 hours then maybe show it as hours. –jacobolus (t) 22:32, 11 April 2024 (UTC)

minimum number of sections archived

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

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

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

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

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

|minthreadstoarchive= is currently displayed in the tooltip (along with the specific bot that does the archiving). It's not ideal, but when we designed the merge, keeping the display very concise was a top concern (for good reason, given the tendency for talk page banner bloat), so that's what we went with. Thinking in terms of a talk page user, I can see why it might be useful to know the auto-archiving period, but it's harder to envision reasons why it would be helpful to know the minthreadstoarchive or the specific bot that does the archiving. Sdkb ^talk 20:30, 1 March 2024 (UTC)

Capn, it would be a fairly easy upgrade to add what you are suggesting, but as Sdkb points out, it's already there in the tooltip, and I think the trade-off design of lean-and-mean visible part, and the rest of it in a tooltip was a good decision. Other than tooltips are not easily visible from mobile, not sure if there are other accessibility issues with tooltips; it had occurred to me that along with this change one might add alt text for screen readers, but I didn't want to overload the proposal, at least initially, with too much stuff. But it's something to consider, moving forward. Mathglot (talk) 21:31, 1 March 2024 (UTC)

Cap'n, since you mentioned wondrous—I also think it's pretty cool—I wanted to spread the credit where it's due. While in theory this could have been implemented earlier through use of a set of complex regular expressions, that would've been difficult to develop, test, and maintain, and might've been fragile. What really made the archival config auto-detection feasible here was the upgrade to Module:Template parameter value developed by Aidan9382, which in turn enabled construction of {{HasTemplate}}. There is still some regex code in the archive bot parser here, but it's straightforward and not the tangled mess it would've been had we not had access to this upgrade. While the Module upgrade was in progress, I didn't even imagine it being used here (had something else in mind) but after it was done, a little light turned on and I realized it was now possible, and not even difficult, to add the config detection and parsing. So that led in a pretty direct line to the changes here. I think the Module upgrade will have beneficial knock-on effects elsewhere, so spread a little love in Aidan's direction. Sdkb will recognize one opportunity in the somewhat clunky WikiProject detection in {{find sources}} for domain selection, and I predict others will come to light. Mathglot (talk) 22:18, 1 March 2024 (UTC)

Okay at first User:Sdkb (and User:Mathglot), I thought you meant this functionality had been recently added. But looking at an example page Talk:Gravity (2013 film) I don't see it. The tooltip states "Discussions with timestamps are automatically archived by lowercase sigmabot III after 120 days of inactivity when more than 5 threads are present." There is no mention the bot will archive only when more than 1 thread is eligible; for this page, the param is set to |minthreadstoarchive=2 So a reader can be left completely bewildered and not understand why the bot "isn't working" when it isn't archiving the oldest section once a sixth discussion is started, when in fact, it IS working: to keep down the number of archival edits; it will only step in once a seventh discussion is started, if it can then archive two discussions in one sweep. It's just the information that is inadequate. This is the same as when the talk header template first was reworked - support for every param except |minthreadstoarchive=. Unless there's something strange going on and I don't see what you guys are seeing? (I'm using legacy Vector if that matters) Cheers CapnZapp (talk) 09:27, 2 March 2024 (UTC)

I see what you are saying, and all I can say is, the proposal that is the object of this discussion was, at least at first anyway, solely about replicating existing wording from whatever the template was doing before, and just making sure to get accurate values directly from the config and not from template parameters which often go out of sync. If the bot notice didn't say anything about minthreadstoarchive before, then it won't say anything about it after the change, either. I see your point about reader confusion, and for whatever reason, there hasn't been a decision to address that in the bot notice previously, so we aren't addressing it either, in order to stick to previous behavior as much as possible.

My suggestion would be simply to start a new top-level discussion proposing your change. Then, regardless whether the bot config-detection function is kept or not kept, your proposal about minthreadstoarchive would stand on its own and could succeed independently. Or, you could just try a bold change and see if it sticks. That's my take; I wonder what Sdkb will say about this. Mathglot (talk) 09:50, 2 March 2024 (UTC)

Given that this is a TE-protected template with 500k+ transclusions, I wouldn't recommend bold editing. I'd be interested to see a concrete proposal (i.e. a mockup of the design you'd like) for displaying |minthreadstoarchive=, but as I said above, I'll be skeptical of its value (and more so the more prominent the display). Sdkb ^talk 16:29, 2 March 2024 (UTC)

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

@CapnZapp, if you go to a page like Talk:Algeria and hover your cursor over the text that says "Auto-archiving period", do you see the tooltip that reads Discussions with timestamps are automatically archived by Lowercase sigmabot III after 90 days of inactivity when more than 4 threads are present? That's what we're referring to. Cheers, Sdkb ^talk 00:50, 4 March 2024 (UTC)

Interesting; regarding Gravity: when I hover over Talk:Gravity's bot notice, I see it mentioning 365 days of inactivity and 10 threads; is that not what you see? The config hasn't been edited since January 10, but it was 180/none before that. Did you mean a different page? Mathglot (talk) 04:47, 4 March 2024 (UTC)

I think CapnZapp is referring to a completely different thing than Mathglot and Sdkb here. There are two different parameters that relate to a number of threads – one (the one currently displayed) is for the number of threads which have to remain on the page after archiving (for example, if this parameter was 2 and there were 5 threads on the page, all of them old enough to archive, only 3 threads would be archived). The other one, which I think CapnZapp is referring to, is for the minimum number of threads that are allowed to be archived with a single edit by the bot (as another example, if that parameter was 2 and there was exactly one thread old enough to archive, the bot would not archive it at all, but once there were 2 or more eligible threads the bot would archive them all). Tollens (talk) 10:07, 4 March 2024 (UTC)

Thanks for that clarification. Yes, agreed; but if the previous incarnation did not address that, should we be doing so? On the + side, strike while the iron is hot; on the - side, just trying to reproduce the original bot notice, which presumably had consensus previously (even if silent), without any significant changes, but more accurately. To the extent that a proposal represents a change to previous behavior, is this thread the right place to deal with it? I can see both views, but I wonder, given the visibility of the template, if additional changes to a highly visible template would require additional consensus? I don't know the answer to that question. Mathglot (talk) 10:39, 4 March 2024 (UTC)

Sdkb I see it. I also see that the bot instructions for that particular revision has no |minthreadstoarchive= parameter set. CapnZapp (talk) 16:03, 4 March 2024 (UTC)

Tollens I am indeed referring to |minthreadstoarchive= and not merely |minthreadsleft= which Talk header have had support for a while now. I think I have been consistently using minthreadstoarchive in my request but feel free to point out if I have accidentally mentioned a different parameter. CapnZapp (talk) 16:07, 4 March 2024 (UTC)

I agree that you've been using the correct parameter name – just trying to clear up the apparent confusion. Tollens (talk) 17:37, 4 March 2024 (UTC)

So, if it uses both, how would you word that? Mathglot (talk) 20:33, 4 March 2024 (UTC)

I think that was what CapnZapp meant by their example: "Discussions with timestamps are automatically archived by lowercase sigmabot III after 120 days of inactivity when more than 5 threads are present if more than 1 thread is eligible for archiving." (emphasis mine). Tollens (talk) 21:02, 4 March 2024 (UTC)

Mathglot: seeing that there's even confusion about which parameter we're discussing let me first ask you -respectfully- to make absolutely certain you understand the request I am making (instead of the request you might think I am making). To be clear, I am not asking for any visual change of the talk header template (and related templates). Only a more informative tooltip. Your caution to me suggests you might still think I'm asking for a more intrusive change than I am actually asking for. I honestly don't feel I need to make mockups - the template's appearance will remain unchanged. I honestly don't see why we would need a whole new round of consensus - again, it's only the tooltip that in a minority of cases would convey a little bit more information. Using Gravity movie as my example, if a page's bot instructions contain |minthreadstoarchive=2 I would like the tooltip to say something along the lines of "...if more than 1 thread is eligible for archiving". As stated previously!

I cannot do more than make sure I am using the right parameter name. I cannot help if people read that as referring to other parameters? Again, if y'all have any advice on how I can be more clear please advise - I thought I was crystal clear but apparently not so? CapnZapp (talk) 16:22, 4 March 2024 (UTC)

I'd support just making this change. I don't think anyone will be upset by (or, for that matter, notice) a change that's only inside a tooltip. Tollens (talk) 17:39, 4 March 2024 (UTC)

Yes, they are very similarly named, and I think I got confused. Especially if it's just inside the Tooltip, I agree with Tollens that probably hardly anybody will even notice. Mathglot (talk) 20:31, 4 March 2024 (UTC)

Parsing is working in the subtemplate sandbox; next is further testing and moving the subtemplate sandbox to live, deciding what wording you want, then we have to add the wording to the Talk header sandbox, add new test cases for it, and then move the new TPH sandbox to live. After that, similar for Template:Archives: new wording (not a tooltip), then sandbox and test it, and release to live. Both templates use the same parser. The blocking dependency now is deciding on the wording for Template:Talk header, presumably in the tooltip. Mathglot (talk) 02:35, 20 March 2024 (UTC)

I'd support CapnZapp's suggested "if more than X thread(s) is/are eligible for archiving" appended to the end of the existing tooltip. Tollens (talk) 02:58, 20 March 2024 (UTC)

How about: "If X or more threads are eligible for archiving"; that will save having to add code for verb number agreement. Also, I think we should only generate it when X >= 2. When X=1, adding the phrase or not adding it describe identical constraints, so the X=1 case doesn't need to be shown, and it might even make it worse as viewers would probably have to pause and try to parse out what it means. Mathglot (talk) 05:38, 23 March 2024 (UTC)

Oh, right, of course – I forgot that archiving was when there were ≥ the number specified in the parameter, not >. Your wording looks good to me. Tollens (talk) 06:10, 23 March 2024 (UTC)

Only saying something when |minthreadstoarchive=2 (or more) was part of my original proposal, so, yeah. CapnZapp (talk) 17:31, 26 March 2024 (UTC)

I would strongly recommend suppressing min threads to archive, even inside a tooltip. It's not reader-relevant information, even for the most pedantically config-obsessed readers. The only reason this parameter exists is to reduce the amount of archive-bot watchlist noise, and people only need to care about this parameter if a miconfiguration is causing some problem, either (a) if the bot is doing an excessive amount of archive edits which are distracting people by spamming their watchlists or (b) if the bot isn't archiving old threads for too long because the threshhold is too high. In either case it only comes up when someone is having a problem with it. It's otherwise unnecessary to know or care about the setting of this parameter. –jacobolus (t) 07:15, 14 April 2024 (UTC)

The same is true (perhaps more so, even) of the specific bot doing the archiving. I don't see why we would not include all available information in a tooltip which will only be viewed by people wanting more information. It isn't as if it's cluttering up the page. Tollens (talk) 07:25, 14 April 2024 (UTC)

Leaving out the bot name also seems beneficial, but at least doesn't require coming up with the kinds of confusing phrases proposed above for min threads to archive. –jacobolus (t) 08:03, 14 April 2024 (UTC)

Then what do you intend to leave in the tooltip? I just don't see the harm in providing more information in a tooltip, even if I were to assume that nobody cares, which I don't necessarily think is true. Tollens (talk) 08:04, 14 April 2024 (UTC)

I don't really care about the tooltip (getting the dates human readable is more important), but it seems substantially unnecessary overall. Try to remain focused to the extent possible on making changes which concretely benefit readers and cutting out every bit of extraneous stuff on highly used templates which doesn't directly benefit readers, rather than on just adding as many things as possible just for the sake of having more things. In aggregate the latter ends up being actively harmful. –jacobolus (t) 08:20, 14 April 2024 (UTC)

It isn't clear to me what it is you want; on the one hand, you say you don't care about the tooltip, but then you say it's unnecessary and we should cut extraneous stuff, and that it's harmful. In this or any template, of course we want to benefit readers, and it's hard to see how a tooltip is harmful to anybody: certainly not to the 60% of our users who are mobile and never see it, or to the other 40% who must actively move their mouse over it in order to activate the pop-up text. Who's getting harmed here? Finally, the tooltip has a few years longevity without objection, so I don't think its going away without a clear consensus to remove which would likely require a specific proposal in a new section and an Rfc. Mathglot (talk) 15:27, 15 April 2024 (UTC)

My point is that anyone adding material to widely viewed templates should try to be careful about what they add to make sure that it has significant value, because every additional bit of extra material that might benefit a few people also imposes a cost (distraction, confusion, etc.) on a large number of others. The bias should be toward being conservative, including fewer features, using less space, etc.

Putting stuff in a tooltip is significantly better than putting it elsewhere, but even within the tooltip try to consider whether each piece of information is really necessary, because the more information you cram in there, the harder it is to make sense of any particular piece. Try to put yourself in the position of a talk page reader. Do you really care about the "min threads to archive" setting on talk pages you visit? How often? How much of a burden is it to just look at the source if you do? –jacobolus (t) 15:48, 15 April 2024 (UTC)

Generally I agree with your philosophy of parsimony, but I don't care that much what is or isn't in the tooltip, as long as what is there is accurate, and under the previous design, often it was not, which is how this all got started. That said, I do mouse over the tooltip and like seeing the age and units, which I know I can rely on now as accurate with the latest changes to the template. The other bits of tooltip info don't bother me personally, and I don't care if they stay or go, but that's not up to me. Mathglot (talk) 16:29, 15 April 2024 (UTC)

Testing progress

This is developed and now in test mode. I tweaked the wording slightly which seemed to flow better. Here's a summary of status and pages involved:

• Functionality – description of requested change (in this section, above)
• Archive bot config parser sandbox – now parses minarchthreads/minthreadstoarchive
• Template:Talk header/sandbox – points to parser sandbox, and has new tooltip code added for minarchthreads/minthreadstoarchive
• Testcases, tab 4 – pre-existing and new tests for archiving notice functionality
  • test cases for Talk pages having a Miszabot config – no testcases yet; t.b.a.
  • test cases for Talk pages having a Cluebot config – (twelve tests in place, passing).

More eyeballs and more tests are needed; this is needless to say a highly visible template and we need to test the new functionality, as well as regression to ensure nothing is broken before going live. I need to set this aside for a while, so any help appreciated. Add tests directly to the test page {{Talk header/testcases4}}, and please examine or run regression tests on the first three testcase pages as well; please note what works/doesn't below. Doc on page testcases4 is still thin; feel free to adjust as needed, and if there is anything inscrutable, please lmk. Mathglot (talk) 02:10, 29 March 2024 (UTC)

Just added the tests on tab 4 for talk pages with a Miszabot config, and they all seem to be passing with the version in the sandbox. Looking through tabs 1 and 3, everything appears fine (tab 2 is now completely redundant and could/should probably be deleted). The one thing I did notice that is not really as expected is that when the number of threads to keep on the page is 1, the grammar is wrong (see Talk:Conspiracy theory), and when it's 0, there shouldn't be a message at all but there is (see Talk:Cold fusion) – I should be able to fix both pretty easily. Tollens (talk) 01:14, 30 March 2024 (UTC)

That fix is now done. Tollens (talk) 01:26, 30 March 2024 (UTC)

Edit-conflicted with you, so my test is invalid as I don't know if it took place after your fix, but the first part of the message was this:

Oh, that's great; thanks for the testcases update, glad they worked. As far as minthreads and the two Talk pages, that could mean the legacy code was doing that, as the minthreads stuff is old code and was not changed for this upgrade (although the conditional logic around it was). Looking at legacy rev. 1193759647‎, there is no adjustment for sing/plural; not sure if it handled the number of threads correctly or not at that point. But I am not seeing what you do: in both test methods, I see these results for Cold fusion:

• CF live: Discussions with timestamps are automatically archived by lowercase sigmabot III after 180 days of inactivity when more than 0 threads are present.
• CF sbox: Discussions with timestamps are automatically archived by lowercase sigmabot III after 180 days of inactivity.

Post-ec again: that sandbox test of mine could've been run after your fix, so that is meaningless; but the live test showed that problem before; anyway, good that you've fixed that. I've maybe missed something from your message, as I feel I have two many balls in the air; did I? Mathglot (talk) 01:51, 30 March 2024 (UTC)

If that was the result you got, you definitely ran that test after it was fixed in the sandbox, it wouldn't have worked before this change. It was certainly the old version that was broken, I agree nothing that's been done related to this changed it. I don't think you've missed anything. Tollens (talk) 01:58, 30 March 2024 (UTC)

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

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

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

Archive timing information appearing in the talk header should be human readable

There was a complaint when I brought this up in response to some other conversation, so let me make a dedicated thread instead.

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

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

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

The machine-readable units also appear separately, in the tooltip when someone hovers "Auto-archiving period". I don't care one way or the other if these remain in the precise format specified in the bot config. –jacobolus (t) 20:48, 5 June 2024 (UTC)

Seems reasonable. The problem with allowing the value to be overridden is that in the overwhelming number of cases, the correct values were being overridden with old, stale, incorrect values, and no one gains from that. There isn't an obvious way to determine which overrides are not stale and therefore should be carried out. But reducing large values into other units where possible seems like a good idea. Mathglot (talk) 02:38, 9 June 2024 (UTC)

Do you have evidence for this "overwhelming number of cases" claim? Every page I can remember looking at in the past however many years had a value matching the bot config. (Much more common was to not include these parameters at all, whereupon they would not be mentioned in the visible box, which is frankly also fine.) Most of the editors who change bot configs will also change the template if they notice it, and if they don't someone else easily can. Even where they disagree, the difference is pretty benign. Bot configs are not something that ordinary readers should much be worrying about. –jacobolus (t) 03:04, 9 June 2024 (UTC)

I don't disagree; ordinary readers probably rarely look at it. And if the difference is benign, and editors don't even look at it, then why even have this discussion? If we wish to change it at all, it seems self-evident that having the correct information in the bot notice is better than having the wrong information. If nobody looks at it or nobody cares, then we haven't changed anyone's experience and it doesn't matter. And if one person cares and notices, then their experience will be a little bit better. At that point, it becomes a decision of whether it's worth the investment of time to do it at all.

But it seems like we are talking about something else now, and not your original proposal regarding friendlier units for time intervals, which seems like a good one. Also, please keep in mind that Wikipedia is a volunteer project. In presenting your proposals for improvement, it might be more collegial to use terms like more user-friendly and less user-friendly, and avoid terms like reader-hostile. Anything that is an improvement in some way over the previous version or improves the reader or editor experience is a good thing, and the "reader-hostile" version we have now was once an improvement when it was created over what we had before, even if it is not perfect, and I appreciate the volunteers who brought it to that point. That doesn't mean things cannot be improved even further (see WP:NODEADLINE) and I appreciate your interest and energy in pushing for greater clarity for users, a goal that I share with you; it's just sometimes a matter of paying attention to how that desire for improvement comes out when describing the kind of improvement you wish to see. Thanks, Mathglot (talk) 02:01, 10 June 2024 (UTC)

The version we have now is not an improvement, but a clear regression, in my opinion. That's my whole point here. It should either be reverted or otherwise fixed. –jacobolus (t) 02:46, 10 June 2024 (UTC)

Sorry, I am having a harder and harder time figuring out what your actual objection is towards. To summarize what I think has been changed so we are working off of the same information: there was information in this template before, almost entirely hidden inside a tooltip except for the time between archives, all of which could occasionally have been incorrect (I don't really know, or quite frankly care, how often). The only change made was that the template will now auto detect the correct information. No fundamental information formatting changes were made, but units are now in the machine-readable format used in the archival template rather than respecting the human-readable units that could have been passed before. If any of that is not your understanding, could you please clarify.

Now, I entirely agree that units should be human-readable. In my opinion it seems obvious that this should be remedied by having the template automatically use human-readable units. I don't even think that this would be particularly hard. Assuming that change is made I believe all the information in the template will be displayed as well or better than it was before work on this change started, around the end of February. If you agree with all of that, and that is your only objection, could you please clarify that?

If your objection goes beyond unit display, but are still related to the changes made specifically regarding automatically detecting the archive configuration, great, could you clarify what those are?

If your objection goes beyond the auto detection changes altogether, or perhaps beyond this template entirely, okay, but that isn't at all what we're working on here. All we are changing is automatically detecting the archive config. If you want to have a discussion about anything other than the changes being made right now, could you please make very clear that this is the case, or alternatively and even better, hold off entirely on those objections until we finish making these changes? I am not saying you can't or shouldn't make those suggestions, just asking that you don't make them in the middle of discussions of unrelated changes. If you don't even have any such opinions, my apologies for misunderstanding.

I am in the same boat as Mathglot when it comes to being somewhat frustrated at how your concerns have been articulated here. For example, unless you for some reason believe that the core idea of automatically detecting rather than manually providing the archive config is bad, your above comment which suggests reverting the work entirely before mentioning that it could be fixed seems unnecessarily dismissive. Tollens (talk) 04:09, 10 June 2024 (UTC)

The previous version allowed people to manually set human-readable units in the visible part of the template. All of the rest of the information involved is irrelevant and can easily be looked up in the plain source. It was fine that it was previously hidden.

The new version overrides the manually set human-readable units, and replaces them with non-human-readable units. There's a bunch of irrelevant data now shown in a tooltip. I have no problem with that, but in my opinion it is of exceedingly marginal use.

Changing the units to be less legible is distracting and confusing, and makes the template worse for readers than the previous version.

If the template is changed to use more human-relevant units in the initially visible box, that would fix the problem as far as I am concerned. –jacobolus (t) 04:38, 10 June 2024 (UTC)

Alright, great. All of that makes sense and I agree with all of it. Just for your information, the tooltip did also exist before this change. I can work on getting the dates in a human-readable format at some point in the next day or two. Tollens (talk) 05:02, 10 June 2024 (UTC)

Awesome, thanks! –jacobolus (t) 06:59, 10 June 2024 (UTC)

This functionality has been created with the new template {{human readable duration}} and its accompanying module. I have changed Template:Talk header/sandbox to use it, and it appears to work fine (for an example, try previewing Talk:Switzerland with the sandbox version). The thresholds I currently have set for moving to the next units are (all of these are the last possible value which can be displayed in their unit): 59.5 seconds, 59.5 minutes, 71.5 hours, 50 days, 18 months. 24 and 48 hours are exceptions, and display as 1 and 2 days respectively. Pinging jacobolus, CapnZapp, Novem Linguae, and Sdkb, all of whom have previously expressed opinions on what thresholds should be set. I've tried to strike a balance between all of those proposals and am certainly happy to change the thresholds if these ones aren't what we all want. I know seconds and minutes aren't relevant to this template but figured I might as well include them, feedback on those thresholds is welcome too. Tollens (talk) 23:36, 10 June 2024 (UTC)

If one of you could change Module:Human readable duration/testcases's content model to wikitext and redirect it to Template:Human readable duration/testcases that would also be appreciated. Tollens (talk) 00:07, 11 June 2024 (UTC)

This seems great. Thanks Tollens! –jacobolus (t) 01:48, 11 June 2024 (UTC)

@Mathglot: Since there appears to be no objection from anyone involved, would you mind merging the changes from the sandbox into the template? Tollens (talk) 05:45, 13 June 2024 (UTC)

No problem; will do. This is a worthy improvement which I support (and thanks very much for the great new module and template, which may have other applications). I'll get to it eventually, but it won't be right away, as there are still some outstanding issues regarding archiving wrt this template, and the {{Archives}} template, that preceded this proposal and are in progress, including one pending bot issue. Will get back to this, but if you haven't heard anything in a couple of weeks, please ping me. Meanwhile, no objections on my side if someone else wants to grab the baton. Mathglot (talk) 01:14, 14 June 2024 (UTC)

@Mathglot: Forgot about this until just now when I saw that this was automatically archived. It seems to me like there shouldn't be any issue merging rev. 1228383628 of the sandbox into the main template given that this is essentially a purely cosmetic change. Tollens (talk) 05:32, 14 August 2024 (UTC)

This should now actually be rev. 1241007410 after the tracking category is merged. Tollens (talk) 19:59, 18 August 2024 (UTC)

With all the recent changes this is now rev. 1249977338. Tollens (talk) 20:45, 7 October 2024 (UTC)

Previously mentioned bot is now running, or about to be. Mathglot (talk) 21:17, 7 October 2024 (UTC)

I've updated the test cases to include testing for this feature, those test cases are here and are all passing. Tollens (talk) 21:33, 7 October 2024 (UTC)

Previously mentioned bot is now running, or about to be. As far as the '3 years', we should implement your new module, but there have been so many changes lately we almost need a Gantt chart to unscramble it all. I think if we just stick to one at a time, there won't be any complex interdependencies, so when the bot completes and we don't notice anything untoward, we can do this one next. There are others stacked up and waiting in the wings. (edit conflict) Mathglot (talk) 21:50, 7 October 2024 (UTC)

Excited to see this go through. Thanks folks! –jacobolus (t) 03:46, 8 October 2024 (UTC)

Restored Tollens's sandbox rev 1249977338 to for testing, as new rev 1250490433 of 18:50, 10 October 2024. (This wipes intervening sandbox changes; sorry, folks, please discuss prioritization of your desired changes at § Recent sandbox edits or wherever practical.)

Not done, but template test cases looking good so far. User:jacobolus, you were one of the people promoting this change, could you have a look at Template:Human readable duration/testcases, and see if there are any situations you ran into in the wild that were not well handled by the template{{Talk header}} as far as readable time units, and that aren't covered by one of the test cases? Feel free to just add a set of test cases directly to the page and let us know here, or if you are not comfortable with that, just describe the conditions that weren't being handled well. Thanks, Mathglot (talk) 19:37, 10 October 2024 (UTC)

Personally I wouldn't bother reporting "seconds" or possibly even "minutes" for this use case (0 might be better to convert to something like "immediately"), but maybe it's fine and people should just avoid inserting such tiny time increments. Otherwise your test cases look fine to me. –jacobolus (t) 20:04, 10 October 2024 (UTC)

Thanks for having a look. (Credit where due: Tollens's test cases.) Mathglot (talk) 22:03, 10 October 2024 (UTC)

@Jacobolus: Don't worry about seconds and minutes – I only included them in that module so that the module can be used in more places than this template even if that is important in those places. It isn't possible to specify anything less than 1 hour with any archiving bot as far as I am aware so it should never display durations that small. "Immediately" is a good suggestion for 0, though (I didn't like what it did before but didn't think of that, thank you!), so I'll look at implementing that in the module at some point regardless of the fact that it isn't relevant here. Tollens (talk) 02:56, 11 October 2024 (UTC)

Template-protected edit request on 24 August 2024 autodetect wikiprojects

Old
− {{{wp|}}} + {{{wp|{{#invoke:string2|startswith|{{ROOTPAGENAME}}|WikiProject}}}}} Template:Talk header/sandbox

−

{{{wp|}}}

+

{{{wp|{{{{#ifeq:{{FULLPAGENAME}}|Wikipedia talk:{{ROOTPAGENAME}}|#invoke:string2|void}}|startswith|{{ROOTPAGENAME}}|WikiProject}}}}}

Autodetect WikiProjects to always show the correct message. A WikiProject I notified today failed to use |wp=1. This parameter might be commonly forgotten. Autodetection will forever fix the error while making the template easier to use. 142.113.140.146 (talk) 22:41, 24 August 2024 (UTC) 174.89.12.36 (talk) 22:47, 12 September 2024 (UTC)

This is a good idea, but I think the given implementation would have far too many false positives. Just because a talk page starts with "WikiProject" doesn't mean it's the main talk page for a WikiProject. How about narrowing this to non-subpages in the Wikipedia talk namespace? jlwoodwa (talk) 20:37, 8 September 2024 (UTC)

@Jlwoodwa: Fixed 174.89.12.36 (talk) 22:47, 12 September 2024 (UTC)

 Done Sohom (talk) 22:42, 14 September 2024 (UTC)

Put page views link in talk header template

Note. If you want a pageviews link in the tools menu see here. For a pageviews link below all article and talk page titles turn on Xtools at the bottom of the appearance section of these gadget preferences.

{{annual readership}} will be removed from all talk pages (via noinclude). The deletion discussion concerning Template:Annual readership (page views) was closed before this final addition to the discussion had a chance to get replies. See:

• Wikipedia:Templates for discussion/Log/2024 August 25#Put page views link in talk header template.
• Wikipedia:Templates for discussion/Log/2024 August 25#Template:Annual readership.
• Wikipedia:Templates for discussion/Log/2024 August 25#Extra link in the tools menu?

There was some support for putting page views in the tools menu, but probably not enough. So I think a page views link could be put in the talk header. Many people want a page views link on article talk pages, but don't want a separate banner for it cluttering up the talk pages.

If we can't get it in the tools menu now, then let's start by putting the link in the {{talk header}} template. Note that there is room on the left side for a page views link. This way the number of links to page views on talk pages goes from around 53,000 ({{annual readership}}) to 726,000 talk pages ({{talk header}} ).

{{talk header}} is on around 726,000 article talk pages out of 6,908,286 articles. {{NUMBEROF|ARTICLES|en|N}}. That is around 11% of articles.

--Timeshifter (talk) 09:11, 9 September 2024 (UTC)

Let's keep the discussion centralised on the village pump. Feel free to implement your proposal in the sandbox to show others. --rchard2scout (talk) 09:52, 9 September 2024 (UTC)

The VP discussion will soon disappear. Eventually, more people will come here, especially after the template is removed from more and more pages (via noinclude). Some people will notice that and come here.

People may have more ideas on places to put page view links. They can read the previous discussion at the links I posted.

Thanks for the link to the sandbox page. I copied the pageviews link from {{annual readership}}. It is the "Daily pageviews" link in the sandbox template below. I tested it on an article talk page via preview. It works.

--Timeshifter (talk) 19:10, 9 September 2024 (UTC)

"Daily pageviews" isn't exactly a "Intro and newcomer link" or "Policy", so I oppose there. Neutral about in the "Archives" section, or between there and search. 174.89.12.36 (talk) 21:52, 12 September 2024 (UTC)

As a big supporter of the {{annual readership}} template—for which I am coming up with a replacement—I am nevertheless opposed to adding page view information to Template:Talk header for several reasons. Primarily, because it is not the principal purpose of the Talk header template, which is already quite complex (and has some tricky, pending incomplete issues), and secondly because there are tens of thousands of pages that have the {{annual readership}} template that do NOT have the Talk header template, and adding the latter merely to get the number of page views is the wrong approach. There has always been opposition to having the Talk header template, some have wanted to do away with it entirely, and I fear that adding page view information to it would backfire, resulting in not including page view information here, and at the same time, increasing opposition to this template. Therefore, I oppose this proposal, and support other methods of including page view information. Mathglot (talk) 22:52, 12 September 2024 (UTC)

{{talk header}} is not going away. And page views are important and it is important to be in a talk page header. The header has multiple purposes. If people find out the number of page views it would probably lessen the amount of tension on talk pages, a big purpose of the template. People will fight less over pages with very small numbers of views. Pages with a good number of views will keep and draw in more quality editors. And those editors usually know how to edit with less confrontation and tension. They understand NPOV better and working together better. --Timeshifter (talk) 00:41, 13 September 2024 (UTC)

Oppose. If page views is to be made more prominent, they belong in a separate template. This template is about basic conduct rules and basic navigation: the 101 of a talk page. While page views are valuable information, they don't really thematically fit here, and would just get lost among the already large amount of info crammed into a small space. ― novov (t c) 05:40, 13 September 2024 (UTC)

I think you missed the main point of all the discussions. A working page views link was already in a separate template, and it was decided to remove it from all talk pages. People don't want a link by itself in a separate template. You wrote: "would just get lost among the already large amount of info crammed into a small space." That's ridiculous. It's 2 words: "Daily pageviews". Look at the sandbox template higher up.

You wrote: "This template is about basic conduct rules and basic navigation". It's also about helping new editors with this: "New to Wikipedia? Welcome! Learn to edit; get help." Many new editors are interested in whether their edits make a difference. As in page views. You have blocked all remaining easy paths discussed so far for the average editor and reader to find page views. Since you also oppose putting the link in the tools menu. --Timeshifter (talk) 22:07, 13 September 2024 (UTC)

New editors who want that information can (and do) get it in Special:Homepage. Not only that, it emphasizes the most popular pages you've edited and calculates it based on the date of your contribution. Turn it on in Special:Preferences#mw-prefsection-personal-homepage if you'd like to try it out. WhatamIdoing (talk) 04:28, 14 September 2024 (UTC)

Thanks for that link. I had never heard of it before. I set the preference just now and looked at Special:Homepage. It has little I am interested in. It lists pageviews since my last edit for some pages. That is not useful to me. It may be useful to others. I am interested in pageviews for the last 30 days for specific pages. Or other time periods I can set at the standard pageviews link. --Timeshifter (talk) 07:48, 14 September 2024 (UTC)

I commented in the discussion for that template. My point here is that although I'm opposed to both, I'd prefer the separate template if I had to choose the two. ― novov (t c) 06:14, 14 September 2024 (UTC)

As I've said at the Village pump, I think this is a bad idea. Page views should not be emphasized. The people who want that information can get it. Everyone else should not be encouraged to think that it's more important than other things that editors value. WhatamIdoing (talk) 04:29, 14 September 2024 (UTC)

Page views are helpful feedback for Wikipedians trying to figure out how to have the most impact cleaning up or improving important and highly viewed pages which are currently mediocre (of course, if people want to edit obscure articles that is also great). But the most useful is probably to look at many-article comparisons with https://pageviews.wmcloud.org/massviews/, e.g. looking up all of the C-class articles in some wikiproject and sorting by page views. A chart of page views over time can also be interesting to look up when there is some large spike of interest. But emphasizing the page views on the talk page or promoting links to immediately find out page views doesn't seem that important to me. It's not that hard to get this info for anyone who needs it. –jacobolus (t) 06:12, 14 September 2024 (UTC)

Some editors also like pages such as Wikipedia:WikiProject Color/Popular pages, which are updated regularly by a bot. WhatamIdoing (talk) 06:17, 14 September 2024 (UTC)

WhatamIdoing. You wrote: "The people who want that information can get it." Yes, but not easily. It is buried well. And people may not know that access to pageviews for any Wikipedia article even exists. --Timeshifter (talk) 09:30, 14 September 2024 (UTC)

I see you asking for your preferred workflow to be put in front of everyone.

I think most experienced editors either know how to get pageviews information, or they aren't interested. For example, Wikipedia:Teahouse has gotten two questions about pageviews this year. If there were great demand for this, I think that more people would be asking for it, don't you? WhatamIdoing (talk) 17:32, 14 September 2024 (UTC)

Once people use it, many people appreciate it. For example, it is important to the many people who liked {{annual readership}} while it had the graph of pageviews. As witnessed by the many people participating in the deletion discussions. --Timeshifter (talk) 19:40, 14 September 2024 (UTC)

And if the editors of a specific page believe that provides them with interesting information (e.g., to see that page views for Santa Claus go up every December and that Homework goes down every summer), then I've no objection to them adding that information. But I do object to indiscriminate addition of this information. WhatamIdoing (talk) 19:46, 14 September 2024 (UTC)

Currently, those editors have no approved way to add a pageviews link that all editors and readers can see. {{annual readership}} is gone. --Timeshifter (talk) 20:42, 14 September 2024 (UTC)

Anyone could put a link to https://pageviews.wmcloud.org/ in an ordinary comment on the page, or even in a box at the top:

WhatamIdoing (talk) 21:41, 14 September 2024 (UTC)

Many comments roll off the page into archives.

Adding new unapproved, unvetted boxes on talk pages is often unwelcome. {{annual readership}} was also a one-line box, and it was removed. Without the graph it was just a link, same as your box. Many people did not want to take up space at the top of talk pages just for a link. That is why I am trying to find other places to put the link. --Timeshifter (talk) 22:00, 14 September 2024 (UTC)

If people want a smaller box, then that, too, is unobtrusive.

The rule is that editors should WP:Be bold. I don't think I've ever seen a complaint about "new unapproved, unvetted boxes on talk pages". In my experience, if the content is welcome, then there are no complaints about the box. If the content is unwelcome, then even using an "old, approved, pre-vetted box" won't change people's minds. WhatamIdoing (talk) 22:52, 14 September 2024 (UTC)

I guess the key factor is vetting by the talk page editors.

It seems though that almost everything I see at the top of talk pages has also endured some scrutiny by editors outside that particular talk page.

If you tried to place your box or banner on more than one talk page, then some people would call for its deletion, saying that it is, in effect, a duplicate of {{annual readership}}. And that you were trying to get around its deletion. --Timeshifter (talk) 00:51, 15 September 2024 (UTC)

I personally do not want to see this in a widely used box at the top of talk pages. It doesn't seem worth the space. I would support adding it to the tools menu though. –jacobolus (t) 01:35, 15 September 2024 (UTC)

jacobolus. After discussion of various options on VPT, the tools menu is currently my preference too. That would require moving many of the tool links to submenus to make it possible to see the tool menu links without scrolling, as is currently the case. The page menu has submenus. It is short because of this. No scrolling necessary. But the page menu requires enabling a gadget preference. The tools menu is on nearly all pages, whether logged in or not. See discussion of the tools menu as an option:

Wikipedia:Village pump (proposals)#Page views link in the Tools menu.

--Timeshifter (talk) 03:16, 15 September 2024 (UTC)

saying Perfect, let's watchlist Template talk:Xreadership

outside I agree. I expect talkpage templates to be listed in WP:TALKORDER. Less-accepted content can go in {{faq}}.

I also think most experienced editors either know how to get pageviews information, or they aren't interested. As in the TfD, I claim no template will make new editors know ... pageviews ... exists. Compare User:GreenMeansGo/WP:Death by template. When's the last time people ever read the fine print or terms and conditions? 174.89.12.36 (talk) 01:50, 15 September 2024 (UTC)

(Adding my two cents while replying, perforce, to one of Timeshifter's recent addition) I oppose making the talk header more cluttered. People have enough to ignore already, without adding more info to distract them. I oppose making page views more prominent. I very much agree with User:WhatamIdoing's arguments over at the Village Pump, too numerous and eloquent to repeat or link here. I oppose you forking a productive conversation from the pump, but I know that's something you do often. It's confusing and downright infuriating, but here we are again. I support you ceasing that behavior. I oppose your bizarre insistence on outdenting your comments, making it nigh impossible to reply to any one of your contributions, and leaving everybody confused about who said what to whom, when, and what you're talking about now. I oppose your overuse of bold in seemingly random places; you are not usually aiding communication, but hindering it. I especially oppose your frequent standpoint of ignoring the input/views/concerns/data of others so you can maintain that what you like is what "most readers" want. It comes across as pure arrogance, and I support your cutting it out. — JohnFromPinckney (talk / edits) 22:18, 16 September 2024 (UTC)

Find sources templates appears to be incorrectly parsing article names at times

I noticed when looking at the talk page header for the Talk:AC/DC article, the find sources template was pointing me to search queries that just contained 'DC' as opposed to 'AC/DC'. It appears that when there's a slash, the parsing might only include the last token. I wanted to fix this myself but couldn't seem to find where exactly the article name was being extracted. Aurangzebra (talk) 04:21, 13 September 2024 (UTC)

This template could pass |title= or the default can be edit requested on Module talk:Find sources. The code currently chooses to use title.subpageText. 174.89.12.36 (talk) 07:40, 13 September 2024 (UTC)

Aurangzebra, thanks for bringing this up. This does not surprise me at all, and I'm sure the problem is not with find-sources; although where the problem is exactly remains to be seen after further analysis, and may require some technical help. But first, I wanted to give you some background about slashes in titles.

An important thing to know when starting out analyzing this is that slashes are handled completely differently in mainspace titles and Talk space titles. In main space, a slash is just a regular character; the title AC/DC is just a title, it does not mean the 'DC' subpage of page 'AC'. But the Talk page Talk:AC/DC is not the same, and is actually a subpage, namely of page Talk:AC. You can see this in the breadcrumbs at the top of the Talk page, which links to the completely unrelated Talk page Talk:AC, whereas the main page has no such breadcrumbs.

Another way to see this, is to use magic words like {{SUBPAGENAME}} and {{BASEPAGENAME}}, and compare how they react in each space:

• The basepagename of AC/DC is AC/DC and the subpagename is AC/DC.
• The basepagename of Talk:AC/DC is AC and the subpagename is DC.

So you can see how they are not being treated the same. The {{Talk header}} template at the top of the Talk page is passing the title of the subpage it is on, namely, the 'DC' subpage of 'AC' to find-sources, and this is exactly as it should be. Suppose we had a Wikiproject, where they had a Talk page called Talk:Vital articles/Unsourced/Dadaism, and you had a talk header on it; what would you want your find-sources to search for? 'Dadaism', right? Typically you want the subpagename; that is, the right-most pagename after the last slash. So, since Talk:AC/DC is the DC subpage, that's what Template:Talk header is passing it. So, find-sources is merely doing what it is told to do in this case, which is, "find sources about 'DC'".

You might argue that in this case, that template {{Talk header}} is doing the wrong thing, and maybe it should do something like, strip out embedded slash, and pass a blank or a hyphen instead. Perhaps, but I still don't think that is right, either, as Template:Talk header is merely passing the title of the page it sees, which is DC (when it's the Talk page).

The real problem here is that the Talk page has the wrong PAGENAME, which derives from a PAGENAME that is legal in mainspace, but means something different when carried over to the Talk page. I'm not 100% certain of the right solution, but I think it could involve the use of {{DISPLAYTITLE}}, if that works in this situation. (Note that WP:Page name#Technical restrictions and limitations talks about the slash issue and gives the example of Talk:GNU/Linux naming controversy, but claims that "...this doesn't particularly cause problems", but I disagree with that, and the issue you raised is precisely one of the problems it causes.) I think what I would try next, would be to change the title of the main article "AC/DC", possibly to "AC DC" or "AC-DC", and see if it allows {{displaytitle:AC/DC}} (it might not). ... darn, just tried that (with redirects AC DC and AC\DC), and it is not allowed per WP:DISPLAYTITLE.

Since that didn't work, I don't think there is anything more to be gained here, and you need bigger guns for this. I would raise your question again at WP:VPT, linking this discussion at the top of your question with {{Discussion moved from}} or {{Courtesy link}}, depending on how you'd like to approach it. Pplease {{ping}} me from there if you do.

If that doesn't yield a solution via PAGENAME, we could brute force a find-sources hack that gives you the search results you want to see, but basically amounts to a workaround, fixing a problem whose locus is elsewhere. Hope this helps, Mathglot (talk) 05:40, 14 September 2024 (UTC)

{{alink}} behaves correctly. It uses {{ARTICLEPAGENAME}}.

SUBPAGENAME and BASEPAGENAME can be expanded into {{#titleparts}}. In Lua, that would be using mw.title.new. 174.89.12.36 (talk) 07:50, 14 September 2024 (UTC)

Rearrange

Could we do something fancy with the CSS formatting, so that "Be welcoming to newcomers" is hidden from newcomers (IPs and non-autoconfirmed?), and "New to Wikipedia? Welcome! Learn to edit; get help" is hidden from experienced editors (autoconfirmed or extended confirmed?)? WhatamIdoing (talk) 23:14, 14 September 2024 (UTC)

I don't likedon't support this change, but you can use the CSS of {{If autoconfirmed}}. 174.89.12.36 (talk) 00:17, 15 September 2024 (UTC)

Why don't you like this idea? WhatamIdoing (talk) 00:51, 15 September 2024 (UTC)

I generally don't like text being hidden from me. But overall, I'm mostly neutral on this.

More concretely, both groups can be said to currently benefit from the text that the proposal wants to hide. "Be welcoming to newcomers" will tell newcomers what the ideal behiavor to expect is, and encourage them to ignore the outliers of a few potential instances of bad interactions. "Learn to edit" would be useful if an experienced editor wants to help someone on an article talk page by clicking on that link, finding a specific page, then replying with it.

Actions can be expected to be hidden, but hiding rules may cause confusion and frustration. "IP: I clicked the 'get help' link at the top of the page and it told me to do xyz" "Admin: What are you talking about?" "IP: It's right there at the top, below 'to start a new topic'" "Admin: Stop making up stuff" 174.89.12.36 (talk) 01:33, 15 September 2024 (UTC)

This template already changes what's displayed in different contexts, and I'd hope that admins would be familiar with the concept of displaying different things to IPs than to other editors.

I don't think that "Be welcoming to newcomers" helps people ignore unwelcoming responses. It might make them more upset (that bad editor, he is unwelcoming and a rule breaker!).

Also, I don't ever remember seeing an experienced editor recommend those two pages. Editors tend to provide more specific links, based on the context of the request for help (e.g., Help:Link if the new editor wants to know how to add a link, Wikipedia:Teahouse if they have lots of questions, etc.). WhatamIdoing (talk) 02:02, 15 September 2024 (UTC)

If anyone personally wants these sections to be hidden just for them, a while ago I added instructions to the template documentation recommending including
#talkheader tr:has(> td > .talkheader-body){display:none;}
to your user CSS, e.g. Special:Mypage/common.css. Then you'll only see the find sources and archives sections, but not the obtrusive list of disclaimers and getting started links. YMMV. –jacobolus (t) 02:12, 15 September 2024 (UTC)

I think I'll try that for myself, but I think that it's still worth trying to get (only) the information each group most needs to that group. WhatamIdoing (talk) 02:49, 15 September 2024 (UTC)

@Jacobolus, it complains: "Error: Expected RPAREN at line 11, col 20." The first > is in column 20. WhatamIdoing (talk) 02:56, 15 September 2024 (UTC)

Yeah, the parser there is wrong (outdated) – this CSS works great in modern browsers [i.e. anything from the past 10–15 years]. It's possible to get the same effect from a much more verbose and obfuscated version – or perhaps a CSS expert could get a similar one to not throw this complaint up – but if you actually save this CSS there it should work. –jacobolus (t) 03:34, 15 September 2024 (UTC)

It appears to work, which is good enough for me. I wonder if the error would go away under Parsoid (or perhaps stop working). WhatamIdoing (talk) 05:03, 15 September 2024 (UTC)

#talkheader tr:nth-child(2){display:none} passes mw:css-sanitizer. Parsoid won't help. It's a pain that :has isn't allowlisted.

#talkheader tr:nth-child(1)>td{border-bottom:none!important} to get rid of the borders both solutions left behind. 174.89.12.36 (talk) 08:03, 15 September 2024 (UTC)

Recent sandbox edits

Awesome Aasim, you are welcome to improve this template, and to use the sandbox to test changes, but your recent sandbox change was added without explanation either in the edit summary, or here at Talk. Given that this is a highly visible template, and that there are more than one pending functional change to the template in the works and which have been under discussion on this page, in some instances for months, it would help if you shared your plans on this page, and cooperated to figure out when your sandbox changes could be applied (or if they have consensus to be applied at all) in the context of other changes waiting their turn to be implemented. What exactly are your changes about, and what do you hope to achieve? Thanks. Mathglot (talk) 00:55, 10 October 2024 (UTC)