Template talk:Talk header
This is the talk page for discussing improvements to the Talk header template. |
|
Archives: Index, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11Auto-archiving period: 60 days ![]() |
![]() | Template:Talk header is permanently protected from editing because it is a heavily used or highly visible template. Substantial changes should first be proposed and discussed here on this page. If the proposal is uncontroversial or has been discussed and is supported by consensus, editors may use {{edit template-protected}} to notify an administrator or template editor to make the requested edit. Usually, any contributor may edit the template's documentation to add usage notes or categories.
Any contributor may edit the template's sandbox. Functionality of the template can be checked using test cases. |
![]() | This page is only for discussions about the Wikipedia page Template:Talk header. To discuss an article, please use that article's talk page. To ask for help with using and editing Wikipedia, use our Teahouse. Alternatively, see our FAQ. | This page is not meant for general questions, nor discussions about specific articles.
![]() | This template was nominated for deletion. Please review the prior discussions if you are considering re-nomination:
|
![]() | This template was considered for merging with Template:Vital article on 17 May 2023. The result of the discussion was "Incorporate {{Vital article}}'s information into the {{WikiProject banner shell}} area". |
Proposal to drop archiving params
[edit]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
[edit]@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)
- 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)
- 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)
Proposal to drop archiving params – break
[edit]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)
- 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)
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)
- 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)
how and when to drop the bot notice params
[edit]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:
- make sure interested parties here are good to go with this; handle any concerns
- 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. - update the doc, removing the four from the main Parameters section but adding a temporary deprecated notice for some period (a year?)
- 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.
- Once the bot is complete (do Advanced search to make sure), remove the params from the unknown parameter invocation at the bottom.
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- Thanks, Aidan. The edit to revert would be rev. 1223139724 of 04:32, 10 May 2024, which removes the four archiving params
- 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)
- 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
- Mathglot,
- 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, 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)
- None I am aware of; I think we are good to go. Mathglot (talk) 04:20, 17 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)
- Mathglot, let me know when you want me to file a BRFA for this. — Qwerfjkltalk 14:50, 28 April 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- Mathglot, any update on this? Qwerfjkltalk 19:04, 18 August 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)
Is there a clear summary of the proposal / intended change?
[edit]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:
- 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.
- 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.
- 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
[edit]Convert Cluebot hours to days?
[edit]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)
- 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)
- 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)
- 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)
- 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)
minimum number of sections archived
[edit]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)
- 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
- 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
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)
- I think that was what CapnZapp meant by their example:
- So, if it uses both, how would you word that? Mathglot (talk) 20:33, 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)
- 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)
- Only saying something when
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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 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)
Testing progress
[edit]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)
- That fix is now done. Tollens (talk) 01:26, 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
[edit]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)
- @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)
- 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)
- 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)
- Awesome, thanks! –jacobolus (t) 06:59, 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)
- 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)
- 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)
Template-protected edit request on 24 June 2024
[edit]![]() | This edit request to Template:Talk header/styles.css has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
Define background-color using a CSS variable, for compatibility with night mode.
Diff:
− | .talkheader-help {
flex: 2 1 auto; border: 1px solid #c0c090; background-color: | + | .talkheader-help {
flex: 2 1 auto; border: 1px solid #c0c090; background-color: var(--background-color-base,#fff); color: inherit; } |
Andumé (talk) 03:02, 24 June 2024 (UTC)
Done Sohom (talk) 14:00, 24 June 2024 (UTC)
Template fails to grab annual archives
[edit]The standard way of naming annual archives is actually Talk:Foo/Archives/(date). The template is not looking for plural "archives" so it does not pick up the annual ones. Bensci54 (talk) 17:03, 25 July 2024 (UTC)
- This template calls {{Yearly archive list}}, with the root set to
{{FULLPAGENAME}}
. The documentation for {{Yearly archive list}} specifies that in your case,|prefix=/Archives/
should be set. I'm not sure if it's possible to automatically detect which version of the template call is needed, or maybe if it would be possible to just call them both. --rchard2scout (talk) 06:55, 26 July 2024 (UTC)