Template talk:Talk header/Archive 11

Archive 5

←

Archive 9

Archive 10

Archive 11

Yearly archive list

I have made a version that also uses {{Yearly archive list}} in the sandbox. I plan to implement it, even though it will add a significant amount of expensive parser function calls in a couple days if there are no objections. Talk pages generally don't have issues with expensive parser functions and because of that I'm not especially worried. --Trialpears (talk) 23:20, 20 December 2021 (UTC)

Change has been synced, amount of expensive parser functions is now limited to 20 (during 2022 with it increasing one a year). Category:Pages with too many expensive parser function calls will be monitored by me to ensure no issues are caused because of this. --Trialpears (talk) 21:08, 25 December 2021 (UTC)

@Trialpears: I added the {{Expensive}} template to the doc. Mathglot (talk) 01:55, 28 December 2021 (UTC)

@Mathglot As a big fan of conciseness on widely read documentation pages, I'm uncertain if a big banner is necessary here. Since this template can't need more than 22 expensive calls even if used multiple times it can't be the main cause of a page hitting the limit. The only pages with this template hitting the limit are also user talk pages with years worth of mass messages that may use ifexist checks. It is also possible someone reading this banner becomes hesitant adding this banner since they don't understand the limit even though it really isn't a significant concern here. Documenting the expensive parser functions in the archive part seems sufficient to me. --Trialpears (talk) 12:38, 28 December 2021 (UTC)

@Trialpears:, I'm okay with that, I was just trying to follow the recommendations. Feel free to move it down to wherever you want. Either way, I don't think it will affect usage much; when contemplating using an unfamiliar template, or unfamiliar parameters, I look at the doc, not the Talk page and I assume others do the same, but maybe not? Mathglot (talk) 01:23, 29 December 2021 (UTC)

@Trialpears:, I've removed the banner, and added a subsection under #Testing issues based on the above. Could you review it, and adjust as needed? Thanks, Mathglot (talk) 07:51, 29 December 2021 (UTC)

@Trialpears:, can you look at the archive list at Talk:Gender role? There is an archive 8, and archive 2003 is a redirect. Mathglot (talk) 09:34, 20 February 2022 (UTC)

Sorry for the delay. I see two problems on that page, first that the last number and first year doesn't have spaces between them creating the mess that is 82003. This is easily dealt with by using {{comma separated values}}. The second issue is the one that you allude to with redirects meaning there are multiple links to the same archive. I think the best way to deal with this is to make a noredirect parameter at {{Yearly archive list}} using {{ifexist not redirect}} and then use that here. There is a risk that we in some cases go from 1 link to 0 if this is done, but based on my experience dealing with archives that should be very few cases and these links didn't exist before yearly archive list was added here anyway. Will give it a few days and then implement. --Trialpears (talk) 10:15, 2 March 2022 (UTC)

Thanks. While we're talking about the archive list, I noticed a very minor problem which is probably a css left-margin issue on the Archiving period. Example: if you look at Talk:Confederate States of America in a desktop browser, widen the window so that the list of archives and the archiving period all fit on one line, and then start to slowly narrow it, you can arrive at a point where the '0' of "archive 20" sits next to the 'A' of "Auto-archiving period' with about a {{hair space}} in between them. This is too little, and should probably be increased to an em, or at least half an em. Mathglot (talk) 22:26, 3 March 2022 (UTC)

Yup, I can see that happening. Adding margin-left: 1em helps, see this sandbox edit. --rchard2scout (talk) 08:34, 4 March 2022 (UTC)

Yes, that looks better (tested in ExpandTemplates, using a Context title to avoid inf. loop). You could probably whittle it down to 0.5, or 0.75em; see what looks best. Mathglot (talk) 08:49, 4 March 2022 (UTC)

Another way you could use to see how it looks is on that article talk page you mentioned, just change the template to /sandbox and watch the preview. I tried 0.5 and 0.75em using devtools, and I definitely think 0.5em is too small, it looks too much like a regular space. 0.75em could work, but I think 1em is fine. I like the visual separation between the list of archives and the notice. --rchard2scout (talk) 09:00, 4 March 2022 (UTC)

1em margins, comma separation between lists of different types and noredirects for yearly list implemented. --Trialpears (talk) 10:06, 24 March 2022 (UTC)

Archive basics indication

It would be nice to have, within the archive notice, an indicator of {{Archive basics}} being set on a talk page instead of an auto set. Archive basics is meant to be used on medium to low traffic talk pages and is manually triggered. It would be helpful to have that displayed without having to open the edit window to see. Suggestions, opinions (Example page Talk:David Lee Roth) - FlightTime (open channel) 21:03, 15 April 2022 (UTC)

Template-protected edit request on 3 June 2022

Please apply the changes I made to the sandbox [1] which adds the functionality to have zero-based archive indices. See also Template talk:Archives#Template-protected edit request on 14 May 2022. A test case is available at Template:Talk header/testcases#Plain. I will update the documentation once this request is fulfilled. 0xDeadbeef 06:57, 3 June 2022 (UTC)

I don't understand why anybody would want to start their archives at /Archive 0. To me, a zeroth archive is no archive at all, and the very first archive page should be /Archive 1. This senseless practice is akin to thinking the third millennium and 21st century began on January 1, 2000. There is nothing at zero; that's why it's called zero, because it's "nothing". P.I. Ellsworth , ed. ^put'r there 09:36, 3 June 2022 (UTC)

@Paine Ellsworth: The ability to specify start points was added nine years ago in 2013. It might be a niche feature, but I don't see any reason against this small addition that changes nothing for existing uses. 0xDeadbeef 10:37, 5 June 2022 (UTC)

Doesn't answer my question. If a user has an /Archive 0 and lists archives up to say [[/Archive 23|23]], then that user has 24 archives. It's misleading and confusing. No logical purpose that I can see. Zero is a starting point, yes; however, zero does not represent any actual unit, like say "1" or "2" or "73" represent units. Everything between 0 and 1 is part of the "first" – baby's first year: at 3 months we don't say baby is zero years old, do we. We say baby is in his/her first year, baby is 3 months old. Zero can be a starting point, and it can be a turning point, such as between -1 and +1, however zero has no value and should not be used as if it were a unit number with value. That defeats its purpose. If this edit gives users the ability to have an archive page titled /Archive 0, then in my opinion this edit should not be implemented. P.I. Ellsworth , ed. ^put'r there 10:58, 5 June 2022 (UTC)

I don't really see how these examples suggest that it is wrong for someone to have /Archive 0. There are examples of counting from zero (Zeroth law (disambiguation) Zero-based numbering#Other fields) so it is not particularly clear that starting from 1 is superior to starting from zero. 0xDeadbeef 11:11, 5 June 2022 (UTC)

Apologies, but like Paine Ellsworth, I don't think is a good idea. It makes it harder for others to communicate with you, which is what talk pages are for. I oppose changing this template to add complexity to it to facilitate such a niche/questionable use. {{u|Sdkb}} ^talk 15:43, 5 June 2022 (UTC)

Here's the thing. Even the verbage is confusing. You say "There are examples of counting from zero", yet when I start counting with the number one, it seems natural to me that by doing so I'm "counting from zero". A zeroth archive to me is no archive at all, and then when I started my very first archive I went from zero archive to one archive, and I naturally named it #1, my first archive. You say you are not clear how starting from one is superior to starting from zero. It's not superior, because when I make a #1 archive, it means that before that I had zero archives, so in effect I've started from zero, not from one. It appears to me that we, you and I, just have different definitions for "starting from". Your definition gives value to the symbol for zero, and my definition gives that symbol no value at all. You would have a zeroth archive filled with talk page discussions, and I would say that my zeroth archive was the one I had before I built my /Archive 1, and that was no archive at all. You seem to be applying a mathematical concept to some real life situations which are incompatible with the concept. That's not to say that there may or may not be application for a zeroth value in some abstract sense. This is probably the very reason why ancient Romans didn't even have a zero among their Roman numerals. It must have made them hurl just to think about these conflicts. Anyway, I'm truly sorry that we disagree, and please have a nice day and stay healthy! P.I. Ellsworth , ed. ^put'r there 20:50, 5 June 2022 (UTC)

Very Very Opposed - We should have a standard format for archiving which does not include "Archive 0" as this is really really confusing to the largest group of users of this site (who come from America where zero-based indexing is extremely uncommon). — Shibbolethink ^{(♔ ♕)} 15:57, 5 June 2022 (UTC)

Opposed for all the reasons already stated. Mathglot (talk) 20:16, 5 June 2022 (UTC)

Very, Very, Very Opposed - Not S.O.P. That would change the whole archive system for no good reason. Cheers, - FlightTime (open channel) 20:33, 5 June 2022 (UTC)

Whether archives should or should not be done this way is not necessarily relevant here. Are any existing archives that are numbered this way, and therefore the talk header template needs to be made to accommodate them? If there are, then it should. While I agree a numbering system starting a 0 for archive pages is not intuitive, I'm not aware of any guideline on the matter. This template already accommodates sequential alphabetic archive pages (Archive A, Archive B, etc.), and that's also not very intuitive. --Bsherr (talk) 23:39, 6 June 2022 (UTC)

Albeit including redirects, over 200, based on search result. --Bsherr (talk) 00:01, 7 June 2022 (UTC)

Thanks. Indeed this is not about whether archives should be this way or another way, or which way is more logical. I see it as a preference which does not affect one's ability for effectively communicating with other people. In the comments above, I see no reason for why naming an archive as /Archive 0 should be forbidden, which would be the only justification for why this edit should not be made. 0xDeadbeef 00:44, 7 June 2022 (UTC)

As is usual when policies and guidelines don't cover a subject, there is one other justification for why this edit should not be made. Since you're relatively new here, it is understandable that you might not know about it. To make up for those times when there is little or no coverage in policies and guidelines, Wikipedia recognizes consensus as a means to settle things, and looking above, it is obvious what the consensus is in regard to this issue.

Notice that some of those pages in the search are actually article talk pages! and the one's I've checked had no means on the talk page to make the 0th archive appear. I'll go through them with the solution, which is to use the {{Archives}} box with |start=0, and if {{Talk header}} is used, its parameters can be set to |noarchives=yes and |search=no. P.I. Ellsworth , ed. ^put'r there 01:55, 7 June 2022 (UTC)

@Paine Ellsworth: I can help with that, if you need, just give me a couple diff's to see exactly how you're doing it. Cheers, - FlightTime (open channel) 02:03, 7 June 2022 (UTC)

To editor FlightTime: thank you so much! 'Twas a small job and is completed. Most of them were User archives and I didn't mess with those. The rest were article talk archives and project page archives, and most of those were just redirects that needed rcat templates. Thanks again! P.I. Ellsworth , ed. ^put'r there 05:05, 7 June 2022 (UTC)

If the consensus suggests that no one should use /Archive 0, the real solution here is to delete those archives and merge them to their respective /Archive 1 pages. If {{Archives}} has |start=0 why shouldn't {{Talk header}}? It would be much more logical if |start is removed from {{Archives}}, if other editors are very against this. 0xDeadbeef 02:41, 7 June 2022 (UTC)

I too don't understand the distinction. Why should it be fine to use a separate archive box but not to adapt talk header to do it? What's the difference? --Bsherr (talk) 05:14, 7 June 2022 (UTC)

The consensus does not suggest that no one should use a 0th archive. The consensus in this discussion is against the suggested edit to this template. While dealing with the search results I found that many of them were redirects that resulted from page moves to another page, usually /Archive 1. Editors were misconfiguring the archive bot and had to rename the archive. There were less than 200 users with 0th archives. When that's compared with 121,958 active Wikipedia users, it's a very small percentage. So sorry but there isn't justification to grant this edit request. P.I. Ellsworth , ed. ^put'r there 05:20, 7 June 2022 (UTC)

Consensus results from a discussion, it doesn't precede one. So, again, what is the justification for using an archive box over adapting the talk header? If you explain it, perhaps I might even agree? --Bsherr (talk) 11:44, 7 June 2022 (UTC)

It it's helpful, I can set out a few points of discussion. There is no guideline against the use of a numbering system starting with Archive 0. I point out above the number of pages using it. Nothing would prevent someone from creating a spinoff of the talk header template to do it, but that would be less desirable than adding a parameter. One could also add to the documentation a statement discouraging the use of Archive 0 type numbering while still offering the compatibility. But I think it very undesirable and process-defeating to make an end-run around the work of making a guideline by instead policing a tool used to display archive pages. --Bsherr (talk) 11:55, 7 June 2022 (UTC)

Yes, consensus results from a discussion, and so far in this discussion the consensus is against the inclusion of 0th archive notation in this template. So what do you do? Editor Bsherr of longstanding experience, what do you do? You have at least two choices: you're a TE so you could go ahead and grant the request against the wishes of those editors above who say no, or... you could test the above consensus and see if a stronger consensus can be garnered that supports inclusion of 0th archive notation in this template.

Justification for using the {{Archives}} template box to make /Archive 0s appear is to account for those few editors who have made an /Archive 0 by mistake or by design. It is a minimal accomodation and is by no means an acceptance that /Archive 0s are acceptable discussion content archive page titles. It does not mean that /Archive 0 pages should be even moreso accomodated by including the ability to sense and show them in this template. In fact, I think all non-userpage /Archive 0s should be renamed to an appropriate page title, as many of them already have been renamed. User page archive 0s are like flat earther ideas; we can't do much about them, but we don't have to agree with them. P.I. Ellsworth , ed. ^put'r there 21:00, 7 June 2022 (UTC)

Agreed, Content page archives should not start with a 0, not much care for what's done in this respect, in ones own userspace. - FlightTime (open channel) 21:22, 7 June 2022 (UTC)

Why is it better to try to enforce that view through the design of a template rather than in an upfront and transparent way through a guideline? --Bsherr (talk) 22:52, 8 June 2022 (UTC)

Same question. I don't see why the line should be drawn at {{Talk header}}, and why people who intend to use inferior numbering schemes should be forced to use {{Archives}}. Besides, I can just create my own version of the template and transclude that to my user talk page. 0xDeadbeef 10:05, 9 June 2022 (UTC)

If someone creates a fork for personal use, it will be deleted. It might be time to review the opinions offered above and observe that there is no consensus to start archives from 0, and it's not going to happen. Johnuniq (talk) 10:37, 9 June 2022 (UTC)

Yes, I agree that a fork should not be created in the Template namespace, but how about creating it on a User talk subpage? The user can give that rendition the ability to sense a 0th archive and then transclude the subpage to their talk page. I think that would be okay, wouldn't it? P.I. Ellsworth , ed. ^put'r there 11:30, 9 June 2022 (UTC)

FYI, I started a discussion at Wikipedia:Village pump (technical)#Numbering system of archives 0xDeadbeef 11:51, 9 June 2022 (UTC)

The reason the line is drawn at this template is because this template is widely used on article talk pages and only minimally used on user talk pages. To give this template the facility of starting with /Archive 0 is paramount to saying it's okay to start article talk pages with a 0th archive. There is very little application for that. If a user wants to create a 0th archive on their talk page, then the Archives template would be a viable option. P.I. Ellsworth , ed. ^put'r there 11:22, 9 June 2022 (UTC)

Bug displaying archives and bot notice for subpages

Try using ExpandTemplates to test {{talk header|bot=lowercase sigmabot III|age=45|units=days}} using a value for ContextPage that points to a subpage that has archives. Example: compare results for ContextPage = Wikipedia talk:Manual of Style vs. Wikipedia talk:Manual of Style/Biography. (Adding |search=yes to the invocation will force addition of a working search box—try searching for "living"—but still demonstrates the bug.) Mathglot (talk) 23:41, 25 June 2022 (UTC)

It's got nothing to do with /Biography being a subpage, but with the fact that its archives aren't numbered according to this template's expectations. It expects either "/Archive 1" or "/Archive <year>" to exist, and /Biography has neither of those. Instead, it has "/<year> archive", "/Archive 3" to "/Archive 6", and some others. For the full list, see Special:PrefixIndex/Wikipedia talk:Manual of Style/Biography/. For cases like this, we could move all of those archives to their correct location, figuring out which one goes where chronologically. I have done that in the past for article talk pages with messy archives (as a result of moves, splits, misconfigured bots, etc.), but I don't think it's worth it in this case. The manually configured {{archive box}} (to which I've just added 2022) works fine here. rchard2scout (talk) 12:25, 27 June 2022 (UTC)

Thanks. I wonder if this is an outlier, or if there are a lot of other cases like this. If the latter, maybe it would be worth recognizing that style of archive name. Mathglot (talk) 05:31, 28 June 2022 (UTC)

Automatic post signing is here!

After years of waiting, as of tomorrow, automatic post signing will be live for both new sections and replies! I plan to remove the Sign your posts by typing four tildes (~~~~) note at that time, as it will no longer be necessary, and every element of the header we're able to remove helps place more relative emphasis on the important remaining elements. If anyone has any comments or concerns, please let me know, and cheers to all on this good news! {{u|Sdkb}} ^talk 14:51, 28 June 2022 (UTC)

Good news! Mathglot (talk) 01:15, 29 June 2022 (UTC)

Does the automatic signing works for all edits, or just new sections? Christian75 (talk) 08:56, 30 June 2022 (UTC)

Okey. It only works if you do it with the reply button... Christian75 (talk) 09:16, 30 June 2022 (UTC)

It works with either the reply button or the new section tool, and the UI guides newcomers to use those when they're starting out. {{u|Sdkb}} ^talk 15:09, 30 June 2022 (UTC)

Mobile

This template doesn't display on mobile or on mobile web page. Why? Thingofme (talk) 08:46, 2 July 2022 (UTC)

You have to click on "About this page" to get to it on mobile, as with all talk page banners. The intent is to reduce clutter on mobile, but it's a communication problem, and I think the community would prefer the WMF change the design to display it better. See also WP:THEYCANTHEARYOU. {{u|Sdkb}} ^talk 16:53, 6 July 2022 (UTC)

Evidence

Has there been any research or analysis into how new users interact with this template? Do they click through to these links or even interact with this part of the page, assuming that's the intent? I would suspect that this giant banner only contributes to template blindness and if that if its intent is to inform new user behavior, there are better ways to reach new editors (i.e., notices by account age or edit count, contextual suggestions in the new reply tool) than adding this to every talk page. czar 15:59, 6 July 2022 (UTC)

There's no research I'm aware of. I think this template includes a lot of information potentially useful for newcomers in a more compact format than the alternative (e.g. having individual banners for WP:NOTFORUM, civility, and every other issue that regularly comes up), but perhaps we could consider having portions display only to non-extended confirmed editors (via {{If extended confirmed}}) or the contextual suggestions you mention. But there's no way with current tech to know when a good time for a contextual suggestion of e.g. dispute resolution would be. {{u|Sdkb}} ^talk 16:51, 6 July 2022 (UTC)

Two points: let's not forget that "interaction" goes beyond merely clicking links, and also includes reading parts of the template to gain information without clicking anything. Secondly, the flip side of banner blindness, is having a familiar structure in a familiar place, so I know where to find things if I need them. Think of it, perhaps, like the dashboard in a car: I'm not constantly scanning the speedometer, water temperature, odometer, tachometer, gas gauge, and other sensors and indicators, but if I looked down and the car dashboard were suddenly replaced by a flat gray panel, that would be highly disconcerting, to say the least. The Talk page header performs a function similar to the car dashboard for me; I'm not constantly looking at it, maybe even only rather sporadically, but when I need it, it had better be there. Nothing else can really replace it. So the kind of evidence we would need to gather to assess its utility would have to go beyond what is visible from access logs. Mathglot (talk) 22:33, 6 July 2022 (UTC)

The only element of this template that approximates a car dashboard is that archive links appear in it. Car dashboards do not perpetually show the driver's manual. And more to the point, car dashboards are usability tested for utility. No, it doesn't have to be clicks. But we could link to the five pillars at the top of every page and it doesn't mean it will receive relevant traffic. Putting the driver's manual in the dashboard doesn't entail contextual relevance, which is why this is prominent enough and with enough assumptions about user behavior that it should be user tested. czar 22:48, 6 July 2022 (UTC)

Here is how we would measure this czar 23:02, 23 January 2023 (UTC)

Centering "Archives" when archive notice is used

I believed this was briefly discussed when the 'Auto-archiving period' notice was added to this template, but when such notice is used, it skews the "Archives: 1, 2, 3 (etc.)" to the left rather awkwardly. One can see what I mean on Talk:Cleopatra. I suggest it be altered to avoid this and keep the archives list centered, possibly with some '<div style="position:absolute;">' coding? Best – Aza24 (talk) 23:43, 21 July 2022 (UTC)

Mobile view workaround proposal in sandbox

@Primefac, Jonesey95, Sdkb, Trialpears, Izno, GKFX, Gonnym, and Paine Ellsworth: I have a proposal to improve the Template for mobile users by means of a workaround in order to make it visible on mobile view. However, since it is such a highly visible template, I thought it best to get your feedback first.

The problem is that {{tmbox}}es are currently hidden from mobile viewers, who cannot view Talk header templates (or any other tmbox) pending resolution of T257394. Afaict, there is no way around this with a tweaked or stylized tmbox (I tried everything; see failures in my common.css). So what I came up with, is to use an ambox instead, and dress it up in tmbox clothing. This first led to a general workaround—see Template:Tmboxw, which seems to do the trick. However, that template can't be used here, since {{Talk header}} mostly doesn't actually use a tmbox (except in one minor portion at the top). Instead, it uses a table with the class that causes the problem with actual tmboxes:

<table role="presentation" class="tmbox tmbox-notice talkheader plainlinks" id="talkheader" style="border-collapse: separate;"><tr>...

The solution here, is to ape the solution that worked in the {{Tmboxw}} workaround. That is now in the sandbox (rev. 1111079312; live-sandbox diff). Somewhat to my surprise, all the test cases look good (although only the ones with |demospace=1 are valid for this purpose). I still think there could be some issues around css display type (block, inline-block, etc.) but at first blush, everything looks good. (For a possible trouble area that might pop up, see Template talk:Tmboxw#Squished boxes.) Additional backstory at Template talk:Mbox.

Should we entertain this as a possible provisional modification to Template:Talk header until the ticket is fixed? Your thoughts appreciated. Mathglot (talk) 07:30, 19 September 2022 (UTC)

It doesn't seem to be a very mobile-friendly template; if I place {{talk header/sandbox}} on User talk:GKFX-2 and look at it on mobile (on my iPhone with the mobile skin) it is invisible on the default mobile talk page mode and has an awkward two-column layout in "Read as wiki page" mode. I'm not sure if it's possible to display content in the default mobile talk page mode but it should at least look good in the "Read as wiki page" mode before releasing to mobile viewers. User:GKFX^talk 13:10, 19 September 2022 (UTC)

@GKFX: If you mean, it looks narrower and longer than it does on a desktop, that's hardly surprising, right? My iPhone has a 2.5 in (6.4 cm) screen and even in portrait mode, it's all there. Imho, it's fair to compare it in two ways:

• to other tmboxes, such as the "alternative account" box at the top of your page, which doesn't show up at all of course; and:
• to other boxes that display using standard pages on mobile view, such as Template:Talk header#TemplateData, for example. If I look at that on an iPhone in portrait mode, I see only the first two columns (common header, "Parameter") and none of the last three columns. On the other hand, it is horizontally scrollable (swipe left), so appears to be in a fixed format (like PDF), so maybe the template could mimic that "fixed width/swipe" behavior. Mathglot (talk) 05:01, 20 September 2022 (UTC)

phab:T312309 and phab:T312312 which fixes the issue is a NearTerm, not LongTerm, fix. Let's not bifurcate the meta template space for talk pages when the issue should be sorted inside a year at most (and we've had this issue for a decade or more). Izno (talk) 16:45, 19 September 2022 (UTC)

I'm sympathetic to the "don't fragment" plea, but it just feels like we've heard this song before; as you point out, it's been a decade. I hope you're right, though, about the one-year prediction. In any case, I won't go forward if there isn't consensus for it. Mathglot (talk) 05:01, 20 September 2022 (UTC)

WAID on her WMF account left this comment a few days ago. It is going to be done sooner than that timeframe.

My pointing out that it's been a decade is that it's not critical. Barely any complaints at all. Nothing at the top of our talk pages really is, which they correctly assessed in 2012/earlierDate when they started building the mobile site. Izno (talk) 20:58, 21 September 2022 (UTC)

Not a message box

Would it be possible, in addition to the "not a forum" message, to include the text "It is not a message service for [Article title]." if the article is a BLP? This arises in the context of famous or wealthy people, and users who assume that "Talk:" means "Talk to." 67.180.143.89 (talk) 18:30, 17 October 2022 (UTC)

Hmm, interesting thought! I guess my main question is, how often does this misunderstanding happen? I've definitely seen it before, but there's a higher bar to clear to warrant a prominent disclaimer in this template.

There's also the question of how we'd word it. The current wording is This is not a forum for general discussion of the article's subject. Is changing to something like This is not a forum for general discussion of the article's subject, nor a messaging service for contacting the subject what you have in mind? Would that fit on one line in New Vector? {{u|Sdkb}} ^talk 18:37, 17 October 2022 (UTC)

I don't have statistics, but you can choose any world-famous person and look through the history of their talk page for reverted changes. (My choices were Bill Gates, Jeff Bezos, Elon Musk, Kim Kardashian.) Sometimes the reverted change has been expunged, which is necessary when someone posts sensitive personal information like bank account numbers. Often it's users whose first language is not English, so the wording should be simple and explicit to be effective. 67.180.143.89 (talk) 19:08, 17 October 2022 (UTC)

Agree that it's worth looking into. Mathglot (talk) 08:51, 29 November 2022 (UTC)

Template-protected edit request on 8 December 2022

Can you add a parameter where everything but links to the archives and search box are displayed suppressing all other text? Qwerty284651 (talk) 19:32, 8 December 2022 (UTC) Qwerty284651 (talk) 19:32, 8 December 2022 (UTC)

@Qwerty284651 Would that not make this template the same as {{Archives}} using |banner=yes? Terasail^[✉️] 20:03, 8 December 2022 (UTC)

@Qwerty284651 (edit conflict) I'm not really sure if you want only archives or everything but archives. If the former you can already use |noarchive=yes. If the latter I feel something like {{Archives}} would be more appropriate. --Trialpears (talk) 20:05, 8 December 2022 (UTC)

I requested this edit, because I wanted to retain the same bg color the one talk header has, not the archives template. I knew of the {{archives}} templates and its properties, but wanted the same bgcolor this template has, which the proposed template does not seem to have as a param. Qwerty284651 (talk) 21:02, 8 December 2022 (UTC)

@Qwerty284651 {{Archives}} has the same yellowish (#f8eaba) color as this template when it is placed on talk pages. Terasail^[✉️] 21:09, 8 December 2022 (UTC)

It does? Qwerty284651 (talk) 21:10, 8 December 2022 (UTC)

They should. See Special:PermaLink/1126342831 Terasail^[✉️] 21:12, 8 December 2022 (UTC)

You can also manually set the background color of Template:Archives, using the style parameter if this is the reason you didn't want to use that template. Terasail^[✉️] 21:11, 8 December 2022 (UTC)

Just checked. By God, you are alright. I guess we are done here. Tnx. Qwerty284651 (talk) 21:12, 8 December 2022 (UTC)

Use fewer columns on narrow screens

Please replace:

.talkheader-body {
	display: flex;
}

With:

.talkheader-body {
	display: flex;
	flex-wrap: wrap;
}

This will allow the current up-to-4-column layout of the template to be shown in fewer columns instead, depending on available screen width, when using new version of mobile talk pages (visit e.g. [2] and click "Learn more about this page" to see, either using your phone or resizing the browser window on desktop).

(This also affects desktop Vector 2022 with limited width mode enabled, which seems like a good change to me, its merits notwithstanding.)

While we're here, please also remove this fragment:

.talkheader-help > *,
.talkheader-policies > *,
.talkheader-shortcuts > * {
	flex: 1 1 auto;
}

It does not do anything. Matma Rex talk 10:43, 20 January 2023 (UTC)

 Done * Pppery * _{it has begun...} 05:27, 21 January 2023 (UTC)

"Article policies" spacing issue?

As seen in its use on Talk:Charles Robert Jenkins, why has the "Article policies" become its own lonely column? — Fourthords | =Λ= | 17:21, 21 January 2023 (UTC)

That would be a consequence on my change discussed above – rather than getting squished, the columns move to a new row. Do you think this needs to be changed? Matma Rex talk 19:19, 21 January 2023 (UTC)

I just wanted to raise attention about what looked like a glitch, is all. If that implementation is consensus, I've no opinion one way or another. — Fourthords | =Λ= | 22:37, 21 January 2023 (UTC)

Remove some styles to improve mobile version

Please remove the following fragment:

@media (min-width: 720px) {
	.talkheader {
		width: 80%;
	}
}

These styles are not necessary on desktop (tmbox already has styles to set it to 80% width), and cause this template to display at an unusually narrow width in the new version of mobile talk pages (visit e.g. [3] on your desktop and click "Learn more about this page" to see). Matma Rex talk 09:54, 20 January 2023 (UTC)

 Not done I did this in Special:Diff/1134876702, assuming you knew what you were talking about, and the result was that the template did actually display narrower on my screen (legacy vector on Desktop). Cc Izno, who seems to have previously tried the same thing. * Pppery * _{it has begun...} 05:31, 21 January 2023 (UTC)

Thank you for testing, that is my bad. I proposed these changes to several templates and I guess I didn't test this one well enough. It looks like the other ones have some nested elements forcing them to increase width, but this one doesn't.

Instead of removing, please replace it with the following:

@media (min-width: 720px) {
	.talkheader {
		min-width: 80%;
	}
}

Thanks and sorry about that. Matma Rex talk 06:37, 21 January 2023 (UTC)

Given the past mishap I don't trust myself to use my template editor rights to implement this, but another template editor is welcome to. * Pppery * _{it has begun...} 14:59, 21 January 2023 (UTC)

 Not done for now: Discussing at template talk:article history for a minute. Izno (talk) 22:23, 25 January 2023 (UTC)

Mobile view

I just noticed that this template carries the {{template display|nomobile}} warning box. However, it appears this template is visible in mobile view (from a desktop). For this example, I will use the Talk page for The Addams Family (1964 TV series). I had switched {{Archives}} (alias {{Archivebox}}) for {{Talk header}} accompanied by {{User:ClueBot III/ArchiveThis}} (I noticed the "nomobile" warning afterward).

1. Go to Talk:The Addams Family (1964 TV series).
2. Scroll down to the very bottom of the page.
3. In the small text at the bottom is a link for "Mobile view"; click on this.
4. On the mobile version, the talk page header doesn't initially display. However, after the list of sections is a bar that says "Read as wiki page". Clicking this will display the talk header with archives.

The point I wish to raise is that I didn't want to remove the "nomobile" warning box without first reporting what I have seen, in case there is more involved. — CJDOS, Sheridan, OR (talk) 10:54, 8 February 2023 (UTC)

There has been recent work here on the software side and the template can now be removed. Izno (talk) 20:54, 10 March 2023 (UTC)

Template-protected edit request on 25 March 2023

Instead of having two columns of policy/guideline related links, merge them into a single column. It improves visibility and makes it more mobile friendly. Now that talk page headers are visible on mobile we should consider this.

Extended content

Simplify the following two columns <div class="talkheader-policies"> * [[Wikipedia:Assume good faith|Assume good faith]] * [[Wikipedia:Civility|Be polite]] and [[Wikipedia:No personal attacks|avoid personal attacks]] * [[Wikipedia:Please do not bite the newcomers|Be welcoming to newcomers]] * Seek [[Wikipedia:Dispute resolution requests|dispute resolution]] if needed </div>{{#switch:yes|{{{arpol|}}}|{{#if: {{SUBJECTSPACE}} | no | yes}}= <div class="talkheader-policies"> <div>'''Article policies''' * [[Wikipedia:Neutral point of view|Neutral point of view]] * [[Wikipedia:No original research|No original research]] * [[Wikipedia:Verifiability|Verifiability]] </div> </div> into this single column <div class="talkheader-policies"> * [[Wikipedia:Assume good faith|Assume good faith]] * [[Wikipedia:Civility|Be polite]] and [[Wikipedia:No personal attacks|avoid personal attacks]] * [[Wikipedia:Please do not bite the newcomers|Be welcoming to newcomers]] * Seek [[Wikipedia:Dispute resolution requests|dispute resolution]] if needed * [[Wikipedia:Neutral point of view|Neutral point of view]] * [[Wikipedia:No original research|No original research]] * [[Wikipedia:Verifiability|Verifiability]] </div>{{#switch:yes|{{{arpol|}}}|{{#if: {{SUBJECTSPACE}} | no | yes}}=

~ 🦝 Shushugah (he/him • talk) 13:56, 25 March 2023 (UTC)

 Not done for now: please establish a consensus for this alteration before using the {{Edit template-protected}} template. Placed your code in the [sandbox], and results can also be seen on the [testcases] pages. Code might need a little cleanup. P.I. Ellsworth , ed. ^{put'er there} 11:29, 27 March 2023 (UTC)

Template-protected edit request on 17 May 2023

Update the TfD link to Wikipedia:Templates for discussion/Log/2023 May 17 Aaron Liu (talk) 17:49, 17 May 2023 (UTC)

 Done {{u|Sdkb}} ^talk 17:52, 17 May 2023 (UTC)

I've removed it. This discussion has had massive participation and I don't think we need further input from editors. It could have been closed after a week and should not have been relisted — Martin (MSGJ · talk) 15:31, 18 May 2023 (UTC)

I concur with all of that, MSGJ. {{u|Sdkb}} ^talk 17:16, 18 May 2023 (UTC)

Broken case

Talk:Nothing is producing an expression error, something about a comma somehow getting into an expression (originally posted at User talk:ClueBot III/ArchiveThis § Nothing is wrong). Aidan9382 _(talk) 17:11, 3 April 2024 (UTC)

Bad timing for me to look at this, as I'll be away for a couple of weeks; revert last change if you think it's needed. The locus of the problem is the rounding of the hours-to-days conversion for Cluebot age values > 24 in the parser subtemplate {{Talk header/archivebotparse}}. Here are some tests that show this:

content of the Cluebot config at Talk:Nothing
{{User:ClueBot III/ArchiveThis |archiveprefix=Talk:Nothing/Archive |format= %%i |age=15000 |maxarchsize=150000 |numberstart=2 |archivebox=yes |box-advert=yes }}

Test archive bot parser for Talk:Nothing page via ExpandTemplates

Set Context title to Talk:Nothing Set Input wikitext to the following: Test [[Template:Talk header/archivebotparse]]: * bot: {{Template:Talk header/archivebotparse|bot}} * age: {{Template:Talk header/archivebotparse|age}} * age (aliased): {{Th/abp|age}} * age rounded-a: {{Th/abp|age|round=y}} * age rounded-b: {{Th/abp|age|r=y}} * units: {{Template:Talk header/archivebotparse|units}} * minkeepthreads {{Template:Talk header/archivebotparse|minkeepthreads}} Expected results in Preview box: Test Template:Talk header/archivebotparse: bot: ClueBot III age: 15000 age (aliased): 15000 age rounded-a: 625 age rounded-b: 625 units: hours minkeepthreads Actual results Test Template:Talk header/archivebotparse: bot: ClueBot III age: 15000 age (aliased): 15000 age rounded-a: Expression error: Unrecognized punctuation character ",". age rounded-b: Expression error: Unrecognized punctuation character ",". units: hours minkeepthreads

The ExpandTemplates test fails rounding the quotient of 15000/24. It's interesting that it doesn't fail when invoking the parser without |round=y. So I suspect the problem is somewhere in here;

Parser code snippet to investigate

|age = {{#if: {{{round|{{{r|}}}}}} | {{#ifexpr: {{tmpv|{{{2|{{FULLPAGENAME}}}}}|User:ClueBot III/ArchiveThis|1|age}} > 24<!-- --> | {{#expr: {{round|2*{{#expr: {{tmpv|{{{2|{{FULLPAGENAME}}}}}|User:ClueBot III/ArchiveThis|1|age}} / 24}}|0}} / 2}} <!-- --> | {{tmpv|{{{2|{{FULLPAGENAME}}}}}|User:ClueBot III/ArchiveThis|1|age}} <!-- --> }} <!-- -->| {{tmpv|{{{2|{{FULLPAGENAME}}}}}|User:ClueBot III/ArchiveThis|1|age}} <!-- -->}}

Sorry about the timing; if this isn't enough to narrow it down sufficiently to lead to a solution, feel free to revert. Also, this points to additional test cases for the parser subtemplate that should be added to Template:Talk header/testcases4. I might be able to look at this one more time before I'm away to answer questions if something isn't clear. Mathglot (talk) 00:12, 4 April 2024 (UTC)

Found myself with some time this morning so I've tried to look into and fix the issue myself. Seems to be an issue with {{Round}} giving back comma-formatted numbers. I've fixed that in this change. Aidan9382 _(talk) 08:06, 4 April 2024 (UTC)

Tyvm. Mathglot (talk) 08:26, 4 April 2024 (UTC)

Pages with two bot configs

Convenience notice: A situation arose with a user who has two archive bot configs on his Talk page. The automatic bot notice generation feature of Template:Archives failed to work properly in this case, because it was only designed to look for one bot config per page. The bot parser subtemplate has been modified to handle this case and is in sandbox testing now; details here. When it is completed and released, Template:Talk header will automatically pick up this change, and begin working correctly for pages with multiple bot configs that use the same bot. For the very limited number of Talk pages that use two different archival bots, only the first one will be reported automatically and a further upgrade would be required if we want to handle both. Mathglot (talk) 02:17, 24 April 2024 (UTC)

purpose of the archiving bot information

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

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

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

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

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

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

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

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

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

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

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

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

@CapnZapp: Wait, what? I am almost 100% certain no information has been removed. In fact, I am pretty sure information has been added. What information do you think has been lost, and where was it displayed? Tollens (talk) 06:13, 23 May 2024 (UTC)

Hello. I am talking about calls to simplify/hide/remove the information given regarding archival bots. Since this information is now part of a very general template, I can certainly understand the viewpoint. I just want to post a heads-up that this reduction/removal of information details wasn't part of the deal when it was proposed to merge functionality into Talk header that previously was found in separate templates; templates whose specialized nature naturally meant nobody called for the information (the archive bot parameters) to be simplified/hidden/removed. Have a nice day CapnZapp (talk) 08:11, 23 May 2024 (UTC)

Ah, I see; you aren't saying that anything has already been removed, you are saying that nothing should be removed. I agree. Apologies for the misunderstanding. Tollens (talk) 08:16, 23 May 2024 (UTC)

Well, my point is that if there is consensus for only displaying simplified archive bot parameter data, then it's time to reconsider the decision to merge the various archive-specific templates into this. Or rather more to the point: the decision this template now supplants those and that therefore those templates could (and were) deleted as redundant. The deal was never "let's merge into Talk header and later get rid of the info entirely", to exaggerate a tiny bit. CapnZapp (talk) 10:26, 23 May 2024 (UTC)

Those templates should never have existed. Information presented at the top of ordinary talk page should be mercilessly culled to only the clearest and most essential. Shoving confusing and essentially useless information (such as how many threads the page will grow to before the bot archives it) in readers' faces is an attention tax on every page reader which is especially steep for new readers but also imposes a burden on long-time readers. –jacobolus (t) 20:34, 5 June 2024 (UTC)

I don't mind this template getting its archive bot info dumbed down, just as long as the templates that used to show the full information are un-deleted (and properly updated to reflect recent improvements). Cheers CapnZapp (talk) 10:30, 23 May 2024 (UTC)

I agree that if consensus leads to simplifying output of this template, the merged ones should be recreated. At this point, I don't see who stands to gain from such simplification (especially since most of it is hidden) but I don't feel strongly about it either way. I can imagine requests going in the other direction, making explicit what is currently hidden, mostly from mobile users who don't have access to hidden info, iirc. Mathglot (talk) 02:01, 3 June 2024 (UTC)

Give a big fat red error for search=yes

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

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

Those 7000 instances are crystal clear evidence that the current API is wrong and broken. The value search=yes should be allowed, and should do nothing. This is much more editor friendly, making the template simpler to remember and use. –jacobolus (t) 03:08, 9 June 2024 (UTC)

I must say I don't see it that way, pretty much the opposite. All those 7,000 instances are evidence of, is that users are attempting to use a param value that doesn't exist. You could say it is "allowed", if you want to, in the same way that non-existent param value |search=foobar is "allowed", because no error is produced currently when it is employed:

{{Talk header|search=foobar}}

but whatever the user thinks that |search=foobar does, is wrong—it doesn't do anything.

Wouldn't it be better to let the user know that whatever it is they wish to do by coding param |search=yes in the {{Talk header}}, in reality it won't do what they expect? Had we had this from the beginning, then we wouldn't have those 7,000 instances right now, and editors transcluding the template would be better served. At least, that's how I see it; evidently you see it differently.

As far as your second sentence is concerned, |search=yes is allowed, and does nothing; just like |search=maybe and |search=20 are allowed and do nothing. I consider both of those a failure of the template to properly validate the user input, and should be fixed by disallowing them. By allowing them, we lull the user into thinking they have added a proper value which will cause the template to do something, when it will not. Not specifying what parameters do in the doc make them harder for a user to code the transclusion, and failing to call out bad param input makes the template harder for the user to use because they won't understand why it isn't doing what they expected, like maybe search only the first 20 discussions in the archives, or whatever they think |search=20 should do. By returning an error, they will understand that "20" is invalid input for that param, and then they can look up the proper usage by reading the doc for that parameter. So, I would say that your proposal is less user-friendly, and makes the template harder to use. As I see it, better param documentation and better param validation saves the user time. I wonder what others might think. Mathglot (talk) 01:37, 10 June 2024 (UTC)

Have you ever been a computer programmer? The concept of "default arguments" is a basic tool found in most modern programming languages (and where it isn't natively supported, many API designers jump through hoops to get some variant working). Anyone who ever makes APIs immediately runs into it, and a few years trying to write programs is enough to make most programmers recognize the fundamental value of the idea.

If your API is being constantly used "wrong", that means the API sucks, full stop. All of the users trying to use this API in the basic obvious way are giving a clear and obvious signal of the way an ordinary Wikipedia editor expects it to work. If you decide, in the face of that evidence, that you should do exactly the opposite, then you are just gratuitously inflicting pain on those people. Please don't do that. Don't put your ego above other people's comfort, when just accommodating them instead is trivial – cf. pave the cowpaths.

Also, |search=yes does do exactly what people expect: it shows the search box. So what we should do is add this to the documentation, mentioning that it's optional and that leaving it blank is equivalent to "yes". Then the template can be changed so that including |search=yes is explicitly supported as a no-op, and doesn't cause any error messages, linter complaints, etc.

–jacobolus (t) 02:28, 10 June 2024 (UTC)

I would agree on this one. When someone types out search=yes, I don’t see how they could possibly mean anything other than "please show the search box". Since "no" is supported, "yes" should be too, regardless of whether or not it’s the default. How people manually inserting a parameter they believe will activate what is actually default behaviour means that the API is "wrong and broken", I don’t understand, but I don’t think we should be throwing an error when a user says that they want to do something the template is designed to do. If we really want to give an error when anything other than "yes" or "no", that would be fine with me. Tollens (talk) 03:11, 10 June 2024 (UTC)

By "wrong"/"broken", I don't mean that the current template behavior is wrong, but rather that rigidly insisting a "search=yes" parameter to be invalid would be a wrong/broken API. My argument is a bit more general than this specific case: any time you have an API and a very significant number of users are using it in a way that is reasonable and logically coherent but not supported, then it is the API that is the problem rather than the users. –jacobolus (t) 03:19, 10 June 2024 (UTC)

Sure, agreed. Tollens (talk) 03:24, 10 June 2024 (UTC)

Whether it's throwing an error for anything other than "yes" or "no" or any other behavior, I'm fine with it if there is consensus for it. And that includes views that the current API is broken, in which case, get consensus for that and propose something you think will carry the day, and if it does, move forward with it. More light, less heat. Regarding your last paragraph about what to do with the documentation, WP:BE BOLD. Mathglot (talk) 02:55, 11 June 2024 (UTC)

I hear your frustration, and wanted to address what you are saying about defaults and professional programming, I would start by underlining my comment above about Wikipedia being a volunteer project. I don't doubt that in a professional environment with a business unit determining engineering priorities, a manager coordinating design and development, programmers on payroll to create the new or changed functionality per spec, tech writers to describe it accurately for the customer base, and a QA department to check that it all meets standards of quality before going live, it likely all takes place as you describe. Even a non-profit (like Wikimedia) has that, but a volunteer project like Wikipedia has none of those things. Development here takes place haphazardly, with no business plan, coordination, prioritization, or design, by whoever is around, whenever someone feels like contributing something. Sometimes there is something like a plan (if "Whoever" feels like writing one), but with no one in authority to approve or veto it, other than the general feedback of whoever else is around, and no specific individual or group to check quality of the result. This leads not infrequently to inconsistencies or errors in the design, functioning, workability, or documentation of these templates (or modules, gadgets, scripts, and so forth) at Wikipedia.

Because of this haphazard workflow, there are endless problems and inconsistencies in templates, including yes/no problems of the sort you describe, even in this very template, such as with param |arpol=, which has the identical yes/no problem you identified, but in the other direction. So with respect to a wrong/broken API, the approach in a commercial company or in a non-profit would be to file a ticket in an issue tracking system (such as Phabricator, in the case of Wikimedia issues). But Wikipedia doesn't have that either; we just have this Talk page, and unpaid volunteers.

In a sense, this template issue (even all template issues taken collectively) is just a tiny fragment of a larger issue that is characteristic of a large, volunteer project. I can see that it must be frustrating for you, and there are echoes of frustration with the larger issue on your Talk page, such as your comment about how "Wikipedia is simultaneously an amazing testament to years of dedicated collaboration, and a constant stark reminder of how far short it falls of its potential". Precisely. This is no less true of templates and other engineered development aids, than it is of the bigger issue you were commenting on. That means there is plenty of work to do in both arenas, and only ourselves to do it. The buck stops nowhere; it just goes around in circles until someone grabs it or nobody does. If we don't do it, nobody will, but with collegial collaboration, we can improve the templates and improve the encyclopedia, even if neither ends up perfect or on time or consistently meets professional standards, although those are worthy goals to aspire to. Hope this helps, Mathglot (talk) 19:50, 14 June 2024 (UTC)

No this has nothing whatsoever to do with professional environments or QA departments vs. volunteer projects. This is a basic fundamental design flaw which you are proposing to make much worse at other editors' expense.

(I asked about programming experience only because every person who writes computer programs of any type is going to spend time both using and writing APIs, if only project-internal APIs for other parts of their own program. It is inevitable they will run into the concept of default arguments in the APIs they use, and if they do it for a while are likely to learn from firsthand experience that not having such a concept causes trouble.

Having an optional argument that cannot be explicitly set to the default (the way Wikipedia's templates are often set to do) is worse still, and is basically unheard of in programming environments, because it's a really bad idea which causes completely gratuitous frustration for API consumers.

Of course, many programming projects of all flavors (volunteer, professional, ...) have serious design flaws of many types. Where possible these should be fixed at the furthest upstream source possible. Where that isn't possible, they should be worked around to make users' lives pleasant.)

But the situation we are in here is very simple. What you are suggesting is going to cause confusion and frustration, for no practical benefit. So we should just not do it. The basic alternative is to do nothing, which would be fine; there will continue to be thousands of instances of "|search=yes", and we can just not worry about them. As a better alternative, we could explicitly allow the argument to be explicitly set to the default value. This would be nearly trivial and would instantly eliminate whatever other related problems you were worried about.

Note: I am not trying to be mean here, or personal. I don't think you are trying to cause problems, or anything like that. Everyone has problematic ideas sometimes (or often in my own case).

–jacobolus (t) 05:42, 15 June 2024 (UTC)

Withdrawn. Mathglot (talk) 07:39, 16 June 2024 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Template-protected edit request on 24 June 2024

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: white; }

+

.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

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)

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)

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)

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,979,782 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)

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)

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

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

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)

Remainder of discussion collapsed.

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)

Moved. Mathglot (talk) 02:19, 16 November 2024 (UTC)

Moved to Template talk:Find sources § Incorrect parsing when title contains a slash

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

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)

As of now, template {{Talk header}} invokes the {{human readable duration}} code added by Tollens, which has been in testing in the sandbox (test cases all passed; see here). We should probably keep this thread open for a week or two to monitor for bugs, questions, and comments. One possible issue to look into (non-urgently) at some point, is that previously, some code was added to support a minimal human readable duration capability to Template:Talk header/archivebotparse due to complaints during the deprecation of the bot params; I don't believe the parse subtemplate code will conflict with {{human readable duration}} code (nothing turned up in testing), but we should monitor the situation. The code in the parse subtemplate is probably unnecessary now that the new Talk header template is live. Keep in mind, though, that the parse routine may be used in template {{Archives}} as well, so the now-extraneous code can't just be stripped out until {{Archives}} also gets the human readable template as well. Mathglot (talk) 07:50, 17 November 2024 (UTC)