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 114,527 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)