This is an archive of past discussions about Template:Talk header. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.
to simplify the expression by chaining the ifs rather than multiplying the results and by testing the disclaimer parameter first, since it is less likely to be called. Note that, while here it appears as one line, there are multiple lines of parser function syntax that I am requesting be changed (see in edit mode); I couldn't figure out how to get it to separate the lines. Thanks, --DannyS712 (talk) 00:17, 16 March 2019 (UTC)
MSGJ, I'm not exactly sure how/why, but I think your most recent edit may have added a blank line to the template, which can now be seen at the top of talk pages. ---Another Believer(Talk)17:30, 17 March 2019 (UTC)
This edit should fix it. This is why we prefer proposed changes to templates to be made in the /sandbox subpage first and demonstrated in the /testcases subpage. Code blobs in a talk page cannot provide such testing. --Redrose64 🌹 (talk) 21:51, 17 March 2019 (UTC)
@Redrose64: Speaking of not testing, and I'm really sorry, but it should have been namespace 3, not 1 ({{#ifeq:{{NAMESPACENUMBER}}|3|{{usertalkpage}}}}}}) I'm really sorry for not trying it in the sandbox first --DannyS712 (talk) 07:31, 19 March 2019 (UTC)
The template definition contains a <table> element with four rows. The first and last rows contain a single cell element <td> each, which declare spanning across four columns: colspan=4. However, the remaining two rows contain only three cells, or even just two (depending on the template's arpol parameter).
That causes the W3C HTML validator to issue a warning for the row number 2:
A table row was 2 columns wide, which is less than the column count established by the first row (4).
and an error for the whole table:
Table columns in range 3…4 established by element td have no cells beginning in them.
P.S. The validator also complains about a duplicated ID talkheader, but that results from an indirect code duplication (the template is displayed at the template's page directly, and then included by an included /doc subpage) and doesn't need fixing. --CiaPan (talk)
@CiaPan: Normally there are two columns. But under certain circumstances, one or two extra columns are added: if shortcuts are specified, or when |arpol=yes is set. --Redrose64 🌹 (talk) 11:55, 19 January 2020 (UTC)
@Redrose64: Yes, I suppose that's exactly what I described above. Any suggestions about improving it? I'd like to fix it myself, but I can't due to the template protection.... --CiaPan (talk) 15:42, 19 January 2020 (UTC)
@Redrose64: Oh, now I see I overlooked the case of four cells. But that's not a problem - the error isn't in just declaring a span of four columns, but rather in declaring four columns when there are actually just two or three. --CiaPan (talk) 17:06, 19 January 2020 (UTC)
@Redrose64: After two hours or so of googling and experimenting under F12 with style attributes for the whole cascade (td - table - tr - td) I found it's enough to set style="border-spacing:0" for the inner table. However, when I tried to save the change, an edit conflict popped out, and I gave up. Feel free to close this thread as unresolved, rejected or whatever you like. --CiaPan (talk) 22:36, 21 January 2020 (UTC)
Figured out why CiaPan's version added an extra space. When that version was expanded, the last four lines were
</tr></table></td></tr></table>
For some reason, MediaWiki interprets these empty lines as misplaced wiki markup and puts it outside the table. When the live template is expanded, the last four lines are
Using multiple tables is counterproductive. Rather, the number of colspan should be responsive to shortcuts and |arpol=. Nardog (talk) 21:51, 21 January 2020 (UTC)
Take a look at Template:Talk header/testcases. The shortcut box is not aligning the to right. Also, the right margin in the white cell is too small (the relative widths of the white and tan cells are also different than in the original, but I'm less concerned about that). --Bsherr (talk) 00:51, 22 January 2020 (UTC)
There seems to be an option, archives=yes that, when included, causes the list of archive files to be suppressed. Compare this talk page, with archives=yes (no "Archives: 1" above the search box) with this one, without archives=yes ("Archives: 1" properly displayed).
TJRC, hmm, so looking at the code, it's {{{noarchive|{{{noarchives|{{{archives|}}}}}}}}}. So there's a variable to suppress the list that does so when it's set to anything, and that variable can go by one of three names: "noarchive", "noarchives", and "archives". {{u|Sdkb}}talk20:51, 26 July 2020 (UTC)
Well, that's interesting. So it seems that "archives" is an alias for "noarchives", which seems counterintuitive. TJRC (talk) 20:54, 26 July 2020 (UTC)
MediaWiki markup (whether used in templates or elsewhere) does not have the concept of variables.
In a construct like |archives=no, archives is the parameter name, and no is the parameter value. It is not a variable because the page that sets its value cannot read that value back.
In a construct like {{{archives|}}}, archives is the parameter name, and {{{archives|}}} is entirely replaced by the parameter value. It is not a variable because the page that reads its value cannot alter that value.
Thanks, but the question is: should specifying the parameter as archives=yes suppress the list of archives? Is that a bug or a feature? TJRC (talk) 17:17, 27 July 2020 (UTC)
Given the search below, this is likely intentional. However, we don't document aliases in general. I don't see a large case to do so here. --Izno (talk) 18:06, 27 July 2020 (UTC)
I think that would be a good idea. I had a heck of a time figuring out that that archives=yes was the reason archives were not displayed. It's certainly counterintuitive that archives=yes means the same as the documented noarchive=yes, and I can't think of any justification for it. TJRC (talk) 19:14, 27 July 2020 (UTC)
What does parameter |display_title= do? – Possible bug
I don't understand what the parameter |display_title= does. I've tried it with different content/values but nothing happens. Are there any specific criteria to it? Nothing is specified in the documentation. I found the author, so a ping goes to @Mr. Stradivarius: --Mango från yttre rymden (talk) 19:18, 26 September 2020 (UTC)
It changes the article name specified in the"This is the talk page for discussing improvements to the _____ article" text. Compare:
There was a recent set of moderate copyedits to this template by EEng that were reverted by Sdkb in this diff. Setting aside any procedural disagreements about bold edits to heavily transcluded templates, I generally think EEng's wording changes were a wholesale improvement over the previous version - there are several mildly awkward bits of wording there that I'd never previously noticed. I'm interested to hear what the actual content objections are, and if there are tweaks that could be made to satisfy anyone involved. ~ mazcatalk13:15, 16 November 2020 (UTC)
Mazca, thanks for opening a separate discussion here in which we can focus on content. There are a bunch of distinct changes here that we should look at individually, so I'm going to open some mini-sections here. On taking a second look, I've warmed to some of them but remain opposed to others. {{u|Sdkb}}talk17:53, 16 November 2020 (UTC)
Yeah, this was one of the more unnecessarily verbose ones I was thinking of: this is broadly trimming word count without losing much. I get the point about the 'please', but as you imply below, this is a tight template. Signature use on Wikipedia basically is compulsory, and I would say we can do without it - though if it fits on the same line after we've lost the other two words, it's fair to include it. ~ mazcatalk21:17, 16 November 2020 (UTC)
As the deathless Strunk put it: A sentence should contain no unnecessary words, a paragraph no unnecessary sentences, for the same reason that a drawing should have no unnecessary lines and a machine no unnecessary parts. There's no please about it: sign your posts, period. EEng23:07, 16 November 2020 (UTC)
As someone who grew up in an atmosphere of too many "please, thank you, and sorry"s (a bad habit, tbh) I think we can gut the "please" and the date part (since the sign does that). But perhaps we can go a step further: "a tilde"? Just me who thinks that's obscure? Just say "Sign your posts with ~~~~"? ProcrastinatingReader (talk) 21:29, 16 November 2020 (UTC)
What P.R. suggests (i.e. to shorten "four tildes ~~~~" to just "~~~~"); had occurred to me, but I'm on the fence about it. On the one hand, the non-savvy don't know what a tilde is. On the other, calling them by name before you exhibit them at least alerts the non-savvy reader that he's about to see something new; without that, they may not understand that ~~~~ is a thing to be typed -- they may think it's an error or be completely puzzled as to what they're being shown. EEng23:07, 16 November 2020 (UTC) P.S. No surprise, but there's a nifty {{tildes}} macro that gives you, well, four tildes. Very handy for these discussions.
Another question: would it be preferable to use "~~~~" rather than "~~~~"? It is a piece of code, after all, and I think the code formatting is designed to make it easier to copy and paste. {{u|Sdkb}}talk22:46, 16 November 2020 (UTC)
The old text used < kbd> instead of < code>, so I followed that. Your suggested format uses < code>, which is better. EEng23:07, 16 November 2020 (UTC)
I don't think creating a new line here is a good idea, since it separates WP:QUESTIONS from the "new to Wikipedia?" context. We want most questions asked on the talk page itself, and only want to redirect people to WP:QUESTIONS when they have more general questions about being new to Wikipedia. {{u|Sdkb}}talk17:53, 16 November 2020 (UTC)
This is fair. I do get the point that if someone's come to this specific talk page to ask a specific question, that's not necessarily wrong. I hadn't noticed the break in the original edit, so I think I'd agree with leaving this bit broadly alone. ~ mazcatalk21:17, 16 November 2020 (UTC)
I think the newline is an improvement, but trim the "Ask questions, get answers" (seems implied, we presumably aren't saying it because we're gonna leave them hanging). ProcrastinatingReader (talk) 21:29, 16 November 2020 (UTC)
I do think it's helpful to offer the WP:QUESTIONS link (which is not my favorite page but does serve as the portal to more than just the Teahouse, such as the copyright questions page): instructions can be useful, but sometimes you're just stuck and need help from another human. If we're going to be updating this template, though, we should switch the introductory page link from the old WP:Contributing to Help:Introduction (I'm sure that'll get pushback from a particular editor, but the recent decision to add it to the left sidebar makes it clear it's the standard and there's no reason to repeat the debate again). {{u|Sdkb}}talk23:32, 16 November 2020 (UTC)
Yes definitely not help:intro any single page would be better. One of the worst things we have done as of late was mass link that intro. Rfc was populated by people not aware of basic reader behavior....second choice during the RfC was was the Wikipedia adventure that does not even work anymore... some decisions should be left to those that actually understand editor retention. look at the retention level..... absolutely pathetic and embarrassing for us ...2 pages linked from main page with 10,000 views...less then 10 percent of thoses 10,000 people click on a second page....less then 3 percent go on to a third page. We are working to redo our intro...should be done for the new year. Best lead these readers to a normal page that contains the info they are looking for over a 70 page tutorial that no one is reading thru. Whole thing has caused us to loss many new editors and more work for the rest of us.-Moxy🍁00:00, 17 November 2020 (UTC)
Sigh, right on cue. I'm not going to get into a debate on that here. You presented all of those arguments during the RfC and consensus still swung the other way. The matter is settled at this point, and at some point continued litigation becomes disruptive. {{u|Sdkb}}talk01:18, 17 November 2020 (UTC)
if you didn't bring it up all the time it would not be mentioned....cause and effect. It was very disruptive and detrimental to the project overall...as anyone can see by the stats. But at least it has caused us to start working on making new page for mobile consumption from scratch instead of implementing another failed adventure. Will let you know when the RfC for replacement will take place. One of thoses situations that will be fixed in time.--Moxy🍁01:28, 17 November 2020 (UTC)
Followup: In my original comment above I got a bit mixed up about what was being linked. Bottom line is I think only one "newbie/intro" link should be included. You guys ^^^^ battle out which one. EEng05:51, 17 November 2020 (UTC)
We don't give the exclamation mark treatment to some of the other bullets, which I'd say are equally important, so I oppose this. It also messes up the consistency of not having punctuation for these bullets. {{u|Sdkb}}talk17:53, 16 November 2020 (UTC)
Taken on its own, I rather like the exclamation point to emphasise this one, but I do take your point about the fact that all the right-column items don't have punctuation. This one I'd also be happy to leave alone. ~ mazcatalk21:17, 16 November 2020 (UTC)
Considering this further, I think it'd be better to put the "be polite" next to the "avoid personal attacks" than the "welcoming to newcomers", since being polite applies to everyone. I reflected that in the mockup below. {{u|Sdkb}}talk01:30, 23 November 2020 (UTC)
Avoid here is like please earlier in this discussion. There's no avoid about it: just don't! The exclamation point makes it brief and punchy, and the brevity – perhaps counterintuitively – makes it stand out. Which it should, because adopting the right stance toward other contributors is perhaps the most important aspect of a new editor's socialization to the project's norms. EEng08:04, 17 November 2020 (UTC)
The main issue here is that the proposed wording is too long. It looks alright when the article policies module is not present, but when it is (i.e. on article talk pages), it goes onto a second line and squishes the white box (adding an extra line) and module (making it go from four to six lines), which is very ugly. I do think there's something to noting that dispute resolution is optional, though. I'd suggest the wording Seek dispute resolution if needed to address that. {{u|Sdkb}}talk17:53, 16 November 2020 (UTC)
This is the one I was least happy with the status quo on, though I'm not sure I like the newer version either, particularly the use of 'stalemate' as a verb. Your alternate wording suggestion, I would say, is better than either. ~ mazcatalk21:17, 16 November 2020 (UTC)
Regarding "smush" factor, I was looking at this template as possibly converting to be more mobile friendly anyway, so that's maybe not a big deal. --Izno (talk) 21:26, 16 November 2020 (UTC)
the proposed wording is too long – Concision is my middle name, but it needs to say what it needs to say. It's absurd to tell readers to go somewhere "for disputes" and even after you fix that, as mentioned in my original edit summary we also don't want someone running to DRN the moment there's a dispute. DRN is for situations that are stuck ("if needed" doesn't express that – if needed by what criterion?). To shorten it, we could adjust:
Okay, so taking into account the above, I mocked up a sandbox with the changes that we broadly seem to agree on. View it at Special:PermanentLink/990141091#arpol=yes to see it with the article policies box enabled. Let me know if there are any major objections; we can certainly continue discussion and make further tweaks if desired, but since I was the one who applied the breaks here, I want to take responsibility for making sure we carry this to some sort of implementation before we forget about it and it gets archived. Cheers, {{u|Sdkb}}talk01:29, 23 November 2020 (UTC)
All looks OK except the addition on your help intro page. I object to sending our readers to a non standard page as outlined above. Also don't think learn to edit is the intent of the link as it is now. It's a welcome page telling people about our purpose the benefits of registration etc.--Moxy🍁01:57, 23 November 2020 (UTC)
All looks good to me. I have no strong feelings either way on the intro page disagreement, but overall this looks to be a good incremental improvement. ~ mazcatalk02:55, 23 November 2020 (UTC)
Implemented the sandbox changes. Regarding the intro link, Moxy is welcome to continue dissenting from the standardization around H:I, but the well-attended recent discussion on the question makes it clear their view does not align with the prevailing consensus. {{u|Sdkb}}talk08:20, 25 November 2020 (UTC)
You will need more input for that one change. Help:Introduction is only about editing..what we need is an intro about this place and a page that works for everyone --Moxy🍁12:53, 25 November 2020 (UTC)
As was pointed out by me and others at a few other talks is that WP:Contributing to Wikipedia#purpose is a vital part of learning about the place. it's disheartening that the stats and studies about accessibility on how people navigate web pages hasn't change your mind about orpahing our main page on this topic that leads to different styles of intros.--Moxy🍁01:01, 26 November 2020 (UTC)
Also, your revert introduced a grammatical error ("Welcome!; get help." is not proper punctuation or capitalization) that we should not let stand for too long. {{u|Sdkb}}talk17:11, 25 November 2020 (UTC)
I received a message on my talk page asking me to weigh in as I closed a prior related discussion assuming I understand the point of contention correctly, my interpretation of the procedure at this point is that Help:Introduction should be considered the status quo as far as revert-etiquette is concerned. The weakness of the consensus behind it means that it's fair game to continue to argue the points against using Help:Introduction (whereas immediately relitigating a firmer consensus on a talk page would be seen as tendentious), but in the absence of an alternative gaining any traction we should default to the status quo for the page itself. signed, Rosguilltalk22:59, 30 November 2020 (UTC)
User:Rosguill you just reverted to the new link that is disputed not the status quo link. Will chalk this up to inexperience ...all we can do is hope in the future Sdkb will think of what is best for the encyclopedia and listen to the recommendations of the Accessibility Project and Help project.--Moxy🍁01:05, 1 December 2020 (UTC)
I had intended to make a few suggestions but I think I'll wait until you two have killed each other off. EEng17:19, 25 November 2020 (UTC)
What do you have in mind. ....it's horible that we all have to spend more time on your simple edit.--Moxy🍁00:30, 26 November 2020 (UTC)
Seek dispute resolution if needed When is it needed? After someone says "I dislike this change"? I preferred the "when discussion stalemates" wording personally, or some variant of that. ProcrastinatingReader (talk) 20:20, 25 November 2020 (UTC)
ProcrastinatingReader, hmm, when I was previewing it in the sandbox, that wording was too long, but once I actually put it in the sandbox, it seems to just barely fit on my display. But it's still longer than the other items in its list, so it may be going onto multiple lines for others. Look at Template:Talk_header/testcases#arpol=yes and make your browser width just slightly narrower if needed to see the issue.
My other concern is that I'm not sure "when discussion stalemates" adequately summarizes when it's appropriate to seek dispute resolution. "Stalemates" or "stalls" to me implies a discussion dying out in a deadlocked state, which might be one circumstance to seek dispute resolution, but there are situations in which a discussion is still active in which starting an RfC can be fine. I think it's largely self-explanatory that "seek dispute resolution if needed" means "seek dispute resolution if needed to help you resolve a dispute", so I'm not sure we need to spend the words explicitly spelling it out. {{u|Sdkb}}talk20:57, 25 November 2020 (UTC)
It happens way too frequently that a naive user jumps to DRN (or ANI, or even Arbcom) at the first sign of not getting what they want. It does everyone a favor to help them understand that DRN is generally inappropriate so long as progress is being made in local discussion; that's only a first approximation, of course, but space is limited. Seek dispute resolution if needed is no guidance at all – its negation is Seek dispute resolution whether you need it or not, which is absurd, and when the negation of something is absurd that means the original statement is empty. I already mentioned that for brevity, we can change stalemates --> stalls. EEng00:59, 26 November 2020 (UTC)
Talk pages with only the talkheader template
Because there is a notice that says "Do not create a talk page that contains only this template", would a talk page be deleted if it only had this template? I have also changed the notice from "needed" to "a page requires it" since this makes sense to use this template for any talk page that needs it. Seventyfiveyears (talk)17:14, 5 January 2021 (UTC)
I cant find it but we had this discussion before. If i recall correctly...the idea of overwhelming the deletion process with 10s of thousands of pages considering Wikipedia does not need to "make more space" on its server was a waste of our voluntary resources.--Moxy🍁17:43, 5 January 2021 (UTC)
(edit conflict) Seventyfiveyears, I doubt anyone has bothered to set up a bot to speedily delete talk pages that contain only this template, but it seems from the documentation like that's what the consensus is, so if you'd like to put a request at WP:BOTREQ it'd probably get taken up. {{u|Sdkb}}talk17:45, 5 January 2021 (UTC)
@Sdkb: I did not mention a bot that can speedily delete talk pages with only the talkheader template. I just said that there was a notice that says to not create talk pages only with the talk header template. Would a talk page only with this template count as a test page? Seventyfiveyears (talk)18:53, 5 January 2021 (UTC)
Don't create a talk page just for this template, sure. That doesn't mean to delete them if that's all they have. This would be a gargantuan task with close to zero benefit. Oiyarbepsy (talk)
0.0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001 EEng07:22, 6 January 2021 (UTC)
Sources=no
Any objection if I add parameter |sources= as an opt-in? If |sources=no then you don't get the find sources bit at the bottom. Some (many) mature articles with plenty/hundreds of footnotes simply don't need this (even short articles on obscure topics with every possible reference ferreted out and included), and it's just another centimeter or two of vertical space we don't need. I notice a trend in templates all over the place, of trying to deal with too much use of vertical space, and this is an easy fix. Default would be current behavior, "include find sources", so backwards-compatible and no conversion needed. I'm pretty busy, so if this ends up being a snow-yes and you feel like doing it before I find a time slot for it, be my guest. Thanks, Mathglot (talk) 20:03, 26 January 2021 (UTC)
No objection from me, although, there’s an existing param name in the opposite direction (hide_sources) so existing usages should be converted. It should be noted that for the original TfD I migrated over thousands of pages with ProcBot not specifying a param value explicitly, since it was enabled by default, which in hindsight was probably a decision lacking hindsight that it may become disabled-by-default in the future. ProcrastinatingReader (talk) 20:14, 26 January 2021 (UTC)
Sdkb can you ping me when you're done with Template:Talk header/sandbox for the wording change? I will eventually get to this, but I'll probably forget again, without the ping. Or, if you feel like implementing it at the same time as the wording, please be my guest. Thanks. Mathglot (talk) 02:00, 12 March 2021 (UTC)
I've made an edit to the sandbox here, which changes the user talk wording at the top from e.g. This is Sdkb's talk page, where you can send messages and comments to Sdkb. to This is Sdkb's talk page, where you can send them messages and comments. "Them" is replaced with "him" or "her" as needed, using {{Gender}}. I think this new wording is a lot more natural, and the use of a pronoun might help reduce instances of misgendering. Does this look good to implement? {{u|Sdkb}}talk03:52, 11 March 2021 (UTC)
I see no recent edits to testcases; wouldn't that be the starting point? It's more reliable than code-reading. Mathglot (talk) 06:48, 11 March 2021 (UTC)
Mathglot, I previewed it on my talk page after I edited the sandbox and it showed up fine, but it can't really be tested in the testcases because it only appears through namespace detection. Are there any edge cases you're looking to stress test it with? {{u|Sdkb}}talk07:02, 11 March 2021 (UTC)
Oh, I see what you mean; that makes sense. I've seen a couple of templates that use param |demospace= for things like that, but I can't remember exactly where I saw it, or if that would work in this case or not. No, nothing special, just thought it would be easier on the Test cases page than trying to read the code, but if that doesn't work, then it doesn't. I certainly have no objection to the wording.
Oh, here's one idea for you, though: we have some example users to play with, I think they might be Example1, Example2, and Example3. That's a perfect number, because if you could figure out who maintains those, and ask them to change the gender on two of them, then you'd have all the test bed for this template that you would need (and they would be useful for other template testing, too). Mathglot (talk) 07:13, 11 March 2021 (UTC)
Implemented. I just checked a bunch of user talk transclusions and it looks like it's working fine. {{u|Sdkb}}talk02:13, 12 March 2021 (UTC)
Bulky template
It's a very heavy, long template, and the value of some parts seems dubious. For example: Sign your posts by typing four tildes (~~~~). which is also notified at the top of "edit source" and also in the box before you click "Save changes", and is now done automatically by replying tools. That Put new text under old text. Click here to start a new topic. is useful is also questionable. I think we should look to cut down the bulk of the template. ProcrastinatingReader (talk) 16:53, 23 May 2021 (UTC)
It'd indeed be nice to cut back on that stuff, but I'd suggest waiting until the Talk pages project features roll out. Once they're in widespread use, the instructions will have less value and it'll be easier to find consensus to remove them. {{u|Sdkb}}talk19:45, 23 May 2021 (UTC)
I see no reason why this modification should be specific to a particular skin, and I presume that most users would prefer to keep their customized display preferences even after switching skins. Daask (talk) 00:28, 7 June 2021 (UTC)
If you would prefer not to see this template on any talk page, you can hide it from your view. You'll need to have a named account to do this.
I propose that it should read instead:
If you would prefer not to see this template on any talk page, you can hide it from your view. Note that this will hide page archive links and the archive search box as well if they are configured to be shown through this template. You'll need to have a named account to do this.
@Daask, those changes both sound fine to me. But wait, why on earth is the documentation page protected? We almost never do that, and certainly not at template-protected level. Pinging @CambridgeBayWeather who protected it a few days ago. {{u|Sdkb}}talk01:12, 7 June 2021 (UTC)
@Timeshifter: I've long thought this would be an advantage here (as well as at all the sources-related maintenance templates). The {{find sources}} template supports double-quoted as well as unquoted search keywords, but the maintenance templates use double-quoted (exact search) only, which is problematic in many cases, especially in the case of articles with WP:NDESC titles which tend to be several words long, and the longer it is, the less likely a double-quoted string will produce the best results.
While we're at it: the param |hide_find_sources= has an awkward, negative name, but too late to change that now. But we could add param |find= alongside it taking search keywords for its value, and then structure it appropriately to allow quoted and unquoted keywords (or perhaps have a second 'find' param for unquoted keywords). A few templates, such as {{Unreferenced}} do that now, but only for double-quoted search.
So, I'd like to see the capability for unquoted search added as a possibility to this template, as well as to the maintenance templates dealing with sources. Maybe I'll mock up something in the sandbox for one of the latter, and we can get some feedback on it there. Mathglot (talk) 05:02, 23 June 2021 (UTC)
The merge discussion with Template:Auto archiving notice seems to be heading towards a merger, and an implementation of this template's sandbox version. The element in the sandbox saying "Auto archiving notice: XX days" will overlap with the list of archives if there is a certain number (depends on your resolution), which can be previewed at Talk:COVID-19 pandemic and Talk:Donald Trump, for example. This should be fixed to prevent overlapping before the sandbox goes live. — Goszei (talk) 09:05, 29 May 2021 (UTC)
If the solution ends up being a relative span instead of an absolute one (so it will just appear on the line at the end of the archive list), I suggest <span style="position:relative; top:2px; right:2px; float:right; font-size:90%;">. — Goszei (talk) 05:51, 30 May 2021 (UTC)
@Goszei: I made that change, which seems to fix up issues at Talk:Donald Trump for example. It could be better to move the notice to the top right rather than bottom right, but it's not a major change. Are we good to implement this merge? (ping Sdkb) ProcrastinatingReader (talk) 12:03, 22 June 2021 (UTC)
Thanks for the ping. The sandbox was only intended to be a prototype, but I think changes made since have gotten it pretty close. Once we've done enough testing to be satisfied everything works, feel free to start implementation. One thing we might want to implement first is the minimum threads functionality; I proposed a way to handle that here. {{u|Sdkb}}talk03:32, 23 June 2021 (UTC)
@Sdkb: I think it would be best to finalise this merge then add new features like min threads, since disagreement on those could just hold up the merge. I'm not sure what further testing there is to do, since I think only a couple of us have interest on this (ping Goszei too). ProcrastinatingReader (talk) 17:07, 4 July 2021 (UTC)
Sounds fine to me. I think the inability to display min threads was really just an oversight at {{auto archiving notice}}, but we can fix it either before the merge or after. {{u|Sdkb}}talk17:33, 4 July 2021 (UTC)
So here's a possible basic plan for the merge:
Implement sandbox version
For pages in Talk: namespace only, skipping any pages that have |dounreplied=no or any of the following parameters set: |target=, |index=, |page=
Thoughts @Sdkb and Primefac? After we could implement and test functionality for remaining parts (eg |index= can be implemented trivially, and others may not be well in use and can be manually converted) ProcrastinatingReader (talk) 15:25, 5 July 2021 (UTC)
Alright, the notice is now positioned and displayed properly, I do have some concerns about when the message is shown and how it handles defaults however. First of all it is displayed by default if an archive exists which is undesirable as not all pages are auto archived. "Auto-archiving" should probably be linked to Help:Archiving a talk page#Automated archiving; the bot user pages are not particularly informative and can easily be accessed from there. If the bot isn't specified I don't feel like we should assume it's lowercase sigmabot as that would probably be inaccurate in a lot of cases. Archive age should probably be mandatory for the notice to be displayed as guessing 7 days would be inaccurate in most cases. That would also solve the always displayed issue. |archive_days= sounds like an unintuitive and honestly unnecessary alias for |archive_units=. I've made these changes and would be comfortable with implementing. --Trialpears (talk) 16:53, 24 July 2021 (UTC)
Do we need to display the name of the bot at all? It seems largely like bloat to me. Most (perhaps all?) people don't care or know of the difference. ProcrastinatingReader (talk) 20:30, 24 July 2021 (UTC)
New sandbox param |search-domain= (alias: |domain=) displays different links when set to medical. In this case, it selects template {{find medical sources}} instead of the default. The new param is designed to take on multiple values, and setting |search-domain=video should invoke the video sources template. If the template is not used, then by default the search links displayed are from {{find sources}}. Test cases for |search-domain=medical all pass, and everything else looks good. However, {{find medical sources}} is brand new, so will wait a week or so while we shake it out before moving the sandbox live. Mathglot (talk) 03:56, 10 August 2021 (UTC)
@Mathglot, interesting idea! I imagine that most medical pages would forget to set the parameter, though. Instead of a parameter, could we use a page's WikiProject tags or something to determine which pages are for medical topics and decide whether to show {{Find medical sources}} or the normal one based on that? {{u|Sdkb}}talk04:25, 10 August 2021 (UTC)
@Sdkb:, the opt-in I think is good enough for the time being; the WP:MED folks are very motivated, and I think they'll add it when it matters. (I picture myself adding it, when a Wiki Edu class descends upon a bunch of articles; I'd add it to several dozen at the start of a class.) The other method I had thought about, is migrating it to a new WikiData attribute, like 'subject-domain' or something, which could have values like general, medical, video, and so on which we can interrogate by template here. A similar situation then obtains, namely, how do we get the attributes added to wikidata? But I think the WikiData folks might have some tricks up their sleeves, so we'll see.
In the meantime, I went ahead and added the video attribute value, and you can see the testcases for all of them in section #Param search-domain at Template:Talk header/testcases. If the testcases all look good and nothing else is broken, I don't think we have to wait out the week for {{find medical sources}} to stabilize, because nobody uses it yet, other than the /doc page, and the announcement at WT:MED. Mathglot (talk) 04:45, 10 August 2021 (UTC)
The WP:MED folks are definitely motivated, but it's another thing that adds to the work of setting up a talk page. My feeling is, if we're already doing the work of determining which pages are medicine-related by tagging them with {{WikiProject Medicine}}, why should we repeat the work by having to then set this parameter as well? It goes against the don't repeat yourself principle and increases complexity. {{u|Sdkb}}talk04:54, 10 August 2021 (UTC)
I didn't know about that tag. I'll see how we can integrate that into it. Maybe it should just be migrated to WikiData instead of tagged here; then it could be reused for whatever purpose, whether adding the WikiMedicine template, or the find sources, or warnings for student editors coming on board, or any number of things. But this is getting far afield for this page; we shoul probably move at least part of this discussion to WT:MED. Mathglot (talk) 04:59, 10 August 2021 (UTC)
(edit conflict) There wouldn't be increased effort accruing to page set-up, because it would be entirely optional, and it would default (as it does now) to "general" find sources. Those motivated enough to change it later, would get the added benefit. We do a lot of stuff like that already; somebody adds page-archiving, then somebody else adds page-archiving notice. Maybe not ideal, but we're not an engineering shop (at least, not on this side of the paid-WMF/volunteer-editor fence), and there's endless things I'd do differently if we were. Still, I get your point, so something definitely to think about. Mathglot (talk) 05:04, 10 August 2021 (UTC)
There's actually more to my dastardly plan: if this is well-accepted, then next step is to move {{find sources}} to {{find general sources}} (or similar), then recreate {{find sources}} as a wrapper that picks up the value of |domain= and then calls the right 'find sources' routine (with the default, of course, being the 'general' one). Which means that all the existing calls to it in {{more citations needed}} and everywhere else, all of a sudden become domain-param enabled, with no change at all to the code. (They would, however, have to have an update to their respective /doc pages.) Mathglot (talk) 04:53, 10 August 2021 (UTC) (edit conflict) updated by Mathglot (talk) 04:57, 10 August 2021 (UTC)
I do think it'd be very cool to have more specific find sources collections. One thing that's always irked me a tiny bit is that the NYT is the only newspaper included, which is U.S.-centric. It'd be amazing if we could pick up the geographical location of an article (where applicable) and include the newspaper(s) of record for that specific country.
amazing if we could pick up the geographical location
in some cases we can, and I bet WikiData to the rescue in many cases here, also. And I see your point about NYT, and it's of course a very valid point. As for {{Reliable sources for medical articles}}, I'm aware of it, and it was one of the first things I mentioned at the TP of the new template. Unless I forgot to? Praying-hands emoji, for no more ec's... Mathglot (talk) 05:07, 10 August 2021 (UTC)
Courtesy ping @Nikkimaria and @Stifle, who recently discussed the NYT thing. And Self-trout about the video games thing, I didn't catch that by "video" above you were referring to video games.
I think as we consider expanding the customization of find sources to bigger realms, that makes it all the more important to have automatic rather than manual detection of which topic an article falls under. It's one thing to try to tag the talk pages of every medical article (hard enough already), but quite another to tag every talk page on Wikipedia with a relevant domain. Luckily, we basically already do that with the project banners, which is why I think our best option is probably to rely on those and/or Wikidata as you suggest. {{u|Sdkb}}talk05:22, 10 August 2021 (UTC)
Little to usefull add besides that having the NYT is worse than having no newspaper at all, it's considerable systemic bias. Stifle (talk) 08:10, 10 August 2021 (UTC)
@Sdkb:I think the automatic detection would be better solution than a param, if you can get it to work. While working on your changes, can you please add some test cases (even if they have to be modified/deleted later, as things evolve) so that I can see where you're going with this? The previously working test cases for |domain= are now broken, which is fine if you have something better but I'd just like to be able to follow along. Mathglot (talk) 10:56, 11 August 2021 (UTC)
Yeah, sorry about breaking the testcases; I'm not quite sure how to do those when it requires the project banner. But it should already be working! Just go to any medical or video game article and preview the talk page with the sandbox version of talk header. It's not perfect (it won't recognize redirects to the project banners and the find text function it uses may be expensive), but hopefully it's workable enough it could be implemented. Lmk if you'd like more explanation of how it's working or anything. {{u|Sdkb}}talk16:14, 11 August 2021 (UTC)
I like the concept. The implementation could do with some more thought; Sdkb's idea of automatic detection (which we can do by detecting the WikiProject template, for example) seems a good idea. Detecting for the presence of certain WikiData identifies could also work. ProcrastinatingReader (talk) 14:00, 11 August 2021 (UTC)
@Sdkb: I see what you're trying to do. I did a quick test at Talk:Giardia (first example that occurred to me, because it came up somewhere else recently) and it failed. No big surprise there, it's not in WProj Medicine. But it *is* in WProj Microbiology. Given that there may be even other projects like that related to medicine, that would mean squeezing more and more parser conditionals into the "which-domain" code in the middle of the "find domain sources" invocation, so that it works for "Giardia" and everything else like that.
May I make a suggestion? Up above in the message of #05:01, 10 Aug, I suggested we move "find sources" to {{Find sources general}} (or, 'basic', or whatever) and create a wrapper in its place. If you hold off on the sandbox code and we do that move+wrapper thing first, then all the squirrely "which-domain" code would be isolated in the wrapper, and you'd have all the space you wanted to work it out, and the code in {{Talk header}} would need no change at all, it would just start working. Not only that, but the "find sources" transclusions in the maint. templates like {{more citations}} and all the other ones, would all start working with domains without having to duplicate the same squirrely code in each one, and then maintain them all in sync afterwards. A great programmer I know once told me about the Don't repeat yourself principle, and I think he might be onto something. Mathglot (talk) 21:34, 11 August 2021 (UTC)
Putting the code somewhere else besides talk header itself definitely sounds good to me. For moving the find sources template, I don't fully follow what precisely that will entail, and the module is pretty complex, but if you're able to find consensus to move forward, go ahead and just let me know where we'll want to have the code determining the find sources template to use. {{u|Sdkb}}talk21:52, 11 August 2021 (UTC)
Regarding the example you gave, Giardiasis would be the really medical-y article, but Giardia has enough medical connections that it should probably be tagged with WikiProject Medicine. I've gone ahead and done that. {{u|Sdkb}}talk21:58, 11 August 2021 (UTC)
link individual comments...... ... Re giardia/giardiasis: check. Re where to put, and all that, easy-peasy; bbiab > RL 🐾. Mathglot (talk) 00:54, 12 August 2021 (UTC)
@Sdkb:, okay the WikiProject detection code is now in the sandbox, and all test cases are working, and generating the correct "find sources" links depending what Project they belong to. See Template:Talk header/testcases#WikiProject detection. The only downside of this, is this will only work in the context of pages that have WikiProjects (ie., Talk pages), which is certainly a cool thing to have, but doesn't solve the problem of having the right "find sources" displayed in maintenance templates that use them on article pages. The WikiData angle might be the easiest way to solve that problem (which would also make the WikiProject detection code in the wrapper unnecessary, or perhaps an OR'd series of tests where any of them could trigger it). The other angle would be to add param |search-domain= to the wrapper and leave the WikiProject detection in there also; the maint. templates could invoke the parameter to cause the desired behavior. I think I like the WikiData solution best, what do you think? This may be an important enough decision that it should be presented to a larger group, and mentioned at projects Video games and Medicine. What's nice, though, is whichever way we go with this now, there's nothing at all that needs changing in Template:Talk header; everything is in the wrapper. Oh, by the way, I left the wrapper with comments to make it more intelligible to template editors; not sure if there's a convention that we get rid of comments before going live or not; I kind of like having it, because it makes it a lot easier to understand. Just my 2¢. Mathglot (talk) 05:01, 12 August 2021 (UTC)
It looks functional to me! I would definitely get some affirmative consensus before implementing, though, as Talk header is an extremely visible template (500k transclusions). The two parties I'd like to hear from are WP:MED and WP:WPVG, just to confirm they want this, and some technical editors (perhaps a {{Please see}} at VPT), to confirm that the way we've coded it is the best way to do it. (I have a feeling that {{Find page text}} may be an expensive call, so I worry about that more than your hidden comments, which look excellent.) {{u|Sdkb}}talk05:16, 12 August 2021 (UTC)
I opened this discussion, containing a draft of the proposal. Please have a look and comment or alter it as needed. Note that it's organized as a discussion and not as a formal Rfc, partly because I don't think we need an Rfc, and partly because it hasn't been discussed before by the wider community, and partly because there appears to be basic agreement between the two of us, so no real dispute that needs to be adjudicated. So I see it more as getting an opinion and imprimatur from the community, rather than the type of dispute resolution that Rfc is for. That said, if you prefer it as an Rfc, I don't really object, other than it would delay installation for 30 days, but that's not a big deal. Mathglot (talk) 21:01, 12 August 2021 (UTC)
Added {{find biographical sources}} to the pot. Also, added little "box wrappers" to make it easier for editors who might want to stuff an extra "find sources" flavor on the Talk page, so for example, {{medical sources box|giardiasis}} ⟶
Adding {{Find biographical sources}} seems alright, but we should just be wary that the more components that are bundled into this, the harder it'll be to get consensus. The template itself also seems to need some work: NYT needs italicizing, and we could probably do the same location customization thing with Loc/British library. {{u|Sdkb}}talk07:05, 14 August 2021 (UTC)
Reply tool
Would there be any point in replacing the Special:NewSection link with a reply tool link:
{{strong|[[Special:NewSection/{{TALKPAGENAMEE}}|Click here to start a new topic.]]}}
to
{{strong|[https://wiki.riteme.site/w/index.php?title={{FULLPAGENAMEE}}&dtenable=1 Click here to start a new topic.]}}
Once reply tool is rolled out, we will be able to remove the "please sign your posts" line, which will be awesome (the less space we have to spend on unnecessary technical instruction, the greater emphasis there is on policy stuff). I think we should wait until it goes out of beta, though, so that we only have to update stuff once. {{u|Sdkb}}talk16:49, 5 September 2021 (UTC)
Namespace
This seems to behave differently in non-talk namespaces, though it isn't mentioned in the documentation. Can this be added? (I would add this myself but I'm not sure exactly how it behaves differently. See Template:Setup auto archiving/testcases for an example; the archiving notice is gone. ― Qwerfjkltalk22:49, 15 August 2021 (UTC)
Thanks @Rchard2scout! I had a look at this, but quickly realized that I didn't know where to place it if there were no archives. I could do an "Archives: none yet" or something, but I'm unsure if that's a great solution. --Trialpears (talk) 16:53, 8 September 2021 (UTC)
If the archive notice parameters are set, doesn't that imply there're archive pages? My suggestion would be put this information in the doc and leave the coding as is. Just my opinion :P - FlightTime (open channel)17:01, 8 September 2021 (UTC)
Usually yes, but on newly created pages or pages with non-standard naming conventions that may not be the case. The main concern would be people setting up auto-archiving on new pages being unsure if it was working with no feedback. --Trialpears (talk) 17:06, 8 September 2021 (UTC)
OK, good point. This happened to me not too long ago, but was able to figure out the issue. It seems the hardest issue to spot is archive page names not being standard. - FlightTime (open channel)17:14, 8 September 2021 (UTC)
Indeed, I hope to be able to partly resolve that by adding support for automatic {{yearly archive list}} detection shortly, and if my ultimate archive plans are completed the template should be able to use the information supplied to the bot to guarantee it can find the auto generated archives. --Trialpears (talk) 17:37, 8 September 2021 (UTC)
Hm, what about not showing any of the "Archive: Index, 1, 2, 3..." stuff? Just have the <td>...</td> with only the <span>...</span> inside it. Would that work? --rchard2scout (talk) 07:20, 9 September 2021 (UTC)
Would work, but sounds like it wouldn't look great. I'm honestly quite inclined to just let it be and let it sort itself out when we get the my new archive bot, hopefully by like christmas. --Trialpears (talk) 22:46, 9 September 2021 (UTC)
This template is used in the documentation for the newish archival parameters. But there is no output, likely because the nowiki template demo hasn't been given any archived content for the template to detect and therefore show.
As you can see I have added a message explaining each of the two examples' output. If you can make the demo template output something sufficiently self-explanatory, feel free to remove. CapnZapp (talk) 08:40, 28 October 2021 (UTC)
Suppose I just want the archives search and nav part of this header. How do I get that? I know I can suppress "find sources" but how do I suppress "Put new text under old text" and article policies (arpol=no doesn't work)? GA-RT-22 (talk) 21:51, 30 October 2021 (UTC)
@GA-RT-22:, somewhat misleadingly perhaps, |arpol=no is not a valid param value and has no effect on the appearance of the template in any namespace. Only |arpol=yes has an effect, and that can be used outside of article talk space to *add* the article policies. Probably the documentation page should be clearer about this, and I'll probably make an update to it. As to your question about suppressing article policies, do you mean for all articles everywhere it appears? Or just for a particular Talk page? In the latter case, it would be possible to do that, but not recommended. If you want it for all pages that the header appears on, without affecting how it appears for other users, you can modify your common.jss by adding this line:
and it will do what you want. Note: in theory, the 'display:none' should be enough to remove it and allow the box to the left of it to expand to the full width of the template, but that isn't happening on my setup for some reason, so the second part about 'visibility' is there to make sure it gets blanked; in that case, the box on the left will just occupy half of the width of the template, and the box on the right will be empty. Hope this helps, Mathglot (talk) 21:44, 31 October 2021 (UTC)
I don't care how it appears to me. I'm just trying to follow the the template instructions, which say to add this template "only where it's needed". See the section "Consider updating..." on this talk page. Is there some other template that will give me just the archive box and nothing else? GA-RT-22 (talk) 21:52, 31 October 2021 (UTC)
I think we should consider reorganizing /doc page section #Appearance variations, maybe starting with just renaming it. My issue is, any template with a rich parameter set pretty much is all about appearance variations (other than invisible, behind-the-scenes changes, such as categorization) because that's what params are for, so "Appearance variations" doesn't really help much as a section header. I don't have a specific proposal, just wanted to brainstorm this. If we're going to stick with "appearance variations", then section "#Hiding the template" just above it should be part of it as well, because hiding is also about an appearance variation (but I'm not voting for doing that).
My first-blush idea would be to rename it "Parameter details", and go into more details about each Parameter and how to use it; or maybe just the complex ones where a brief one-liner in the Parameters section isn't enough. I'd remove the transcluded sample TP headers that are there now, which currently make the section vertically very long without imparting very much extra information or making it easier to understand, and move them down to a new "Examples" section. Mathglot (talk) 23:11, 31 October 2021 (UTC)
This section is now moot; I went ahead with a fairly major re-org of the doc to try to rationalize it and make the whole thing more comprehensible. I kept one aspect of the original with some misgivings that is unusual, namely, there is no complete list of parameters with descriptions all in one place in the #Parameters section. There is a complete param list, in fact two of them: one vertical, and one horizontal, but no complete plain-text enumeration of all the parameters along with a brief description of each, including whether they are optional, and what their defaults and valid values are. Previously, there was scattered information about (some of) the parameters scattered all over, and I've tried to group them by functionality, which is a bit better than the way it was before, imho; but there's still no complete, alphabetical enumeration (outside of the TemplateData, where I suspect few will go). Mathglot (talk) 11:28, 8 November 2021 (UTC)
Launch of new 'find-sources' functionality
The new 'find-sources' functionality with dynamic WikiProject autodetection and optional search-domain override is now live. For articles belonging to certain WikiProjects, you will notice a change to the {{find sources}} links in the Talk header to provide more targeted links. In the initial launch, this includes articles belonging to WP:WikiProject Medicine and WP:WikiProject Video games (others may be added in the future); articles not belonging to either one of these projects, continue to show the same 'find-sources' links as before.
There are some known issues, already discussed in the planning stages, which will be addressed in future releases, after the dust is allowed to settle on this one. Probably chief among these, concerns articles that belong to two (or more) projects, and how we want to deal with that. For example, Talk:Marie Curie belongs to a number of projects, including Medicine, but also Biography, Military history, and several others. In this first launch, because the new functionality detects "WikiProject Medicine" at that article, the Talk:Marie_Curie header now displays "find sources" links associated with the "medical" search domain, whereas perhaps the default links might be better (or maybe both sets should be displayed). Find-sources link sets for search domains "Biography" and "Military" already exist (see {{find biographical sources}} and {{find military sources}}), but are not incorporated into the Talk header in this release, but may be in a future one.
Looks good overall. I would suggest displaying both/all sets of links for articles belonging to multiple projects, as well as the default ones. It may at times result in some duplication, but that's harmless. – SD0001 (talk) 07:25, 10 November 2021 (UTC)
I am quite disappointed to see that the source of information that could mislead editors (particularly new editors we most need to reach), by failing to make any mention of WP:MEDRS in a widely used template that implies any of those sources can be used on medical articles, when most can’t, originated in a discussion that few editors are aware of. [1]. I hope this is rectified by correcting the template to add a link or mention of WP:MEDRS, as the generic “find medical sources”, absent of any context for understanding WP:MEDRS, will mislead the very editors we hope to reach via adding this info to talk page headers. Meanwhile, these additions have rendered this template unuseful and even misleading on medical article talk pages. SandyGeorgia (Talk) 02:59, 13 November 2021 (UTC)
Announcement: improved Wikipedia Library links launched
In a separate development undertaken by WMF involving some software changes, the "Wikipedia Library" link in the "find sources" section of this template has been upgraded. Previously, it was a static link to the WP Library portal, from which one would have to log in, navigate to the search page, type in a query, and submit it to get results.
This has been improved so that now when you click it, the Wikipedia Library link provides a search results page populated with the results of your query. Here's an example of how it might appear on the page Talk:War guilt question:
This will really improve the ability of editors to find reliable sources for articles they are working on; so a big shout-out to Samwalton9, Jsn.sherman and all the members of the WMF team who helped make this a reality. Mathglot (talk) 10:10, 11 November 2021 (UTC)
@FlightTime that would be possible from a technical perspective, but I think it would be potentially confusing. How would the notice look for starters? A better solution would be for the script to communicate when it has no source for the archive name. --Trialpears (talk) 00:43, 17 December 2021 (UTC)
I'd like to see us consolidating archiving systems rather than building out infrastructure to accommodate all of them. {{u|Sdkb}}talk01:24, 17 December 2021 (UTC)
Archive information doesn't show up
A bot has gone and merged the two templates, but {{talk page}} doesn't actually show any of the information given, effectively just removing the archiving information. Why isn't this displayed? NixinovaTC22:10, 20 December 2021 (UTC)
Hey @Nixinova. I'm the guilty one here with that being my bot. The template intentionally doesn't display a notice if it doesn't find any archives. The template doesn't quite yet find your archives as you use yearly archives instead of sequential, but it will soon since I've made a version of this template that does (You can replace the first line of your talk page with {{Talk header/sandbox|archive_age=180|archive_bot=lowercase sigmabot III}} if you want to see how it will look). I also plan on going through all pages with an auto archiving notice that isn't displayed shortly to make sure all cases are handled properly. --Trialpears (talk) 22:34, 20 December 2021 (UTC)
@Nixinova The talk header now properly supports yearly archives. Your talk page has an archive list and auto archiving notice incorporated in the talk header now. --Trialpears (talk) 21:09, 25 December 2021 (UTC)
Params |search_term3= and |search_term4= serve no purpose, and should be dropped. Currently, |search_term1= provides "exact search" (double-quoted search) capability, and |search_term2= provides unquoted (i.e. "normal") search. The other two search terms provide no additional functionality not already provided by search_term2. They appear to be a legacy left over from {{Find sources multi}}, which has positional search terms 1 – 5, and where only terms 1 and 2 ever made any sense, and 3 – 5 never served any purpose and should be dropped. Mathglot (talk) 01:28, 7 November 2021 (UTC)
Support: Yes. In favor of removing unused template parameters... and unused code in general. Is there any way to quantify the usage of specific parameters? - Wikmoz (talk) 05:34, 8 November 2021 (UTC)
Not sure; maybe an advanced search with ":insource" and a search query looking for "search_term3". I'll have to come back to this later and try it. If we can't figure it out, someone at WP:VPT will know. As a first step, if there's consensus to drop it, we should stop documenting the existence of those terms in the doc page, to discourage future use, although I can't imagine too many pages are using it, outside the doc page examples. Mathglot (talk) 11:33, 8 November 2021 (UTC)
First step might be to gray out and flag as deprecated... and remove from any active examples. Is there a parameter removal process that would prevent old implementations from throwing an error? Like maintaing a known-but-ignored list of deprecated parameters in the template code after deprecation? - Wikmoz (talk) 20:11, 8 November 2021 (UTC)
Qwerfjkl Nice work, thanks! Great news that it's not more widely used, and a good confirmation that removing search_term3 and -4 is the right way to go. I think we can start by dropping any mention of 3 & 4 from the documentation immediately. We can take our time about changing the code, there's clearly no hurry with that aspect of it. There will eventually be analogous changes to make with the "find sources" suite of templates, but they can start with the documentation, as well. Mathglot (talk) 09:27, 11 November 2021 (UTC)
Also dropped them from TemplateData. There was also a search_term5, which I overlooked, but removed that one now as well. Mathglot (talk) 01:41, 28 December 2021 (UTC)
Test case for 'archive notice'
@DannyS712:, do you recall what this edit of 11 Feb. 2019 to the testcases page with the summary +archive notice was about? It's currently still visible on the page (in a somewhat altered format for collapsed, side-by-side viewing) in section #Custom texts. I'm inclined to delete the two test cases involving nonexistent param |archive notice=. Or, should they be replaced with something else? (please mention me on reply; thanks!) Mathglot (talk) 21:40, 6 January 2022 (UTC)
If the {{not a forum}} message is on the talk, perhaps the "This is not a forum for general discussion of the article's subject." part of the talk page header should be removed. Guess this can be automatically checked using Lua. ProcrastinatingReader (talk) 16:12, 25 February 2022 (UTC)
If you think it's important enough, it can be done with regular template code. Whether it's worth it, is another question. Mathglot (talk) 22:29, 3 March 2022 (UTC)
Consider updating the "only where it's needed" instruction
There seems to be a reasonably strong consensus that the current wording of the template documentation is too restrictive regarding the guidance for its use, but there doesn't seem to be clear enough consensus for the outright deletion of the sentences that discourage its use. It's clear that there is definitely consensus against adding this template to every talk page, or allowing any bots or automated editing tools to plaster this template indiscriminately across the project. There seems to be general agreement that adding this template to an empty talk page (thereby turning it into a bluelink) is not inherently problematic, but also shouldn't necessarily be encouraged. So, that leaves us in a place where there is general agreement on principles, but no strict agreement on the exact modified wording of the instructions. I have attempted to modify the wording of the instructions in the spirit of the consensus found in this discussion, but please feel free to modify my updated wording if you believe it needs to be changed. If you do modify my wording, please strive to ensure that your updates don't contradict the consensus found within this discussion. —ScottyWong— 19:09, 10 March 2022 (UTC)
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.
Because this is linked to from CENT, here's a link to the template at issue in this discussion: {{Talk header}}.
This is one of the most useful talkpage templates, giving advice to new users on how to use the talkpage. It is one of the earliest talkpage templates (dating back to 2005), and as such met with some resistance in the early years - including being taken to AfD six times, so there was some restriction on its use. However, over the years it has developed, and has absorbed the task of linking to talkpage archives and to sources useful to building the article, so its function and usefulness has increased, and it is now used on over half a million talkpages. Yet the instruction to use only when needed, which has been on the documentation since 2006, has not been updated - despite the increase in acceptance, popularity, usefulness, and functionality. Given that it provides sourcing information and guidance to users on how to use a talkpage, and also provides a link to archives, my feeling is that it is useful on all article talkpages, especially on the talkpages of new articles where links to sources would be most useful. I feel at this stage all articles and their talkpages would benefit from having this talkpage header on the talkpage - I'm seeing positives in terms of helpful advice and functionality, and seeing little in the way of negatives, and so I feel that the wording "This template should be placed only where it's needed. Don't visit talk pages just to add this template, and don't place it on the talk pages of new articles. Talk pages that are frequently misused, that attract frequent or perpetual debate, articles often subject to controversy, and highly-visible or popular topics may be appropriate for this template." and "In accordance with talk page guidelines, this template should not be added to otherwise empty talk pages. That changes the "discussion" tab at the top of the page from a "redlink" into a "bluelink", which may mislead people into thinking there is discussion." should be removed from the documentation, allowing users to add the template to any talkpage, including new ones. The notion that a WikiProject template, which has a very limited use for the bulk of users, is allowed to be added to a blank talkpage, and so turn the discussion/talk tab to blue, but a template which gives guidance on how to use the talkpage (and so encourage new users to talk) and provides links to sources (and so enable all users to build the article) is not allowed to be added strikes me as an aberration which we need to fix. When visiting talkpages - and this is purely anecdotal, I haven't done any research - it has appeared to me that talkpages which don't have this template are those where new users either don't put forward their queries and suggestions, or do so with inappropriate formatting. SilkTork (talk) 14:00, 31 October 2021 (UTC)
"Only where it's needed" is what prompted me to ask how to get just the archive search banner and not the rest of it. Is it acceptable to add the talk header if that's all I want? GA-RT-22 (talk) 14:30, 31 October 2021 (UTC)
Good question. I would say yes, as the functionality you want/need is built into this template. Hard to see a reason why not. SilkTork (talk) 18:18, 31 October 2021 (UTC)
Support removal of text highlighted by SilkTork for the reasons given. I would add another reason to remove it: in addition to the helpful advice given, the header by default now includes the "{{find sources}}" functionality (added less than twelve months ago) which addresses the core issue of WP:Verifiability, certainly one of the main issues of new articles as they are being developed, and an ongoing issue for any article as it is expanded or modified. The Talk header is the best vehicle for presenting this useful sourcing information imho, and provides a standard location and presentation for it which makes it easier for a user to find and take advantage. The source links alone are a good enough reason to include the template on article Talk pages. Mathglot (talk) 17:30, 31 October 2021 (UTC)
Keep as is for now due to the principle that the more tags you have on a talk page, the more that people ignore them. That said, with some measures to reduce the tag overload, I think placing this on more talk pages could be a good thing. For example, if you could embed the Wikiproject and OldXfd templates within the talk header, collapsed by default, it would draw attention to the talk page guidelines, with the other information still there, but not distracting. I think there needs to be a broader discussion about talk page tags in general and making sure that we're drawing attention to important information while less important information is not prominent. Oiyarbepsy (talk) 17:37, 31 October 2021 (UTC)
Comment The main hesitation I'd have is with regard to obscure talk pages that never really get much discussion. I don't expect Talk:Amastra subsoror to ever become a buzzing hive of discussion, and experienced editors know that dropping a comment on such a talk page is basically casting it off into the void. Giving newcomers "This is the talk page for discussing improvements to [article]" is kinda misleading in that circumstance. If talk header could be modified to automatically identify and provide better advice in those instances (perhaps a link to Help:Introduction to talk pages/5), I'd be more comfortable with approving its use everywhere. But at that point, it should just be integrated into the software rather than a template that has to be manually added. {{u|Sdkb}}talk17:50, 31 October 2021 (UTC)
I would support having some kind of talkpage advice and links built into the software so the equivalent of this template, adapted as appropriate, appears automatically on every new article talkpage. SilkTork (talk) 18:16, 31 October 2021 (UTC)
User:Sdkb, considering that adapting Talk header would be easier than getting the software changed how would you identify an obscure talk page for TalkHeader to modify its presentation? Count links in, page views, and/or watchers? Or could we just create a separate Talk header template just for low use talkpages, with guidance to editors as to when to use the Low use Talkheader and when to use the regular Talkheader? SilkTork (talk) 09:33, 8 November 2021 (UTC)
Support - I agree with SilkTork's comments, plus this is a very useful template, in use for over 15 years and now on more than 613,000 pages. The reasons givens not to add it don't particularly make much sense ("this template should not be added to otherwise empty talk pages. That changes the "discussion" tab at the top of the page from a "redlink" into a "bluelink", which may mislead people into thinking there is discussion. - does that mean we can't place project banners on new talk pages either? How problematic is this "deception" anyway?) At the very least, it should be made clear that once it's been added, it shouldn't be removed just for the sake of removing it. - wolf19:06, 6 November 2021 (UTC)
There appears to be to be a movement toward support for removing the restrictions, though not quite support for encouraging universal usage. Would there be an objection to me simply removing "This template should be placed only where it's needed. Don't visit talk pages just to add this template, and don't place it on the talk pages of new articles. Talk pages that are frequently misused, that attract frequent or perpetual debate, articles often subject to controversy, and highly-visible or popular topics may be appropriate for this template." and "In accordance with talk page guidelines, this template should not be added to otherwise empty talk pages. That changes the "discussion" tab at the top of the page from a "redlink" into a "bluelink", which may mislead people into thinking there is discussion."? No encouragement for people to increase usage, just a removal on the restrictions on placing it on new pages or empty pages. Meanwhile discussion can continue on adapting the template for less visited pages. SilkTork (talk) 11:09, 9 November 2021 (UTC)
Perhaps such a move should be discussed more widely, since it will have an impact across the project, and those who frequent this talk page are probably not a representative sample. Kanguole11:25, 9 November 2021 (UTC)
Support per SilkTork. Awhile ago I suggested on the WP:RATER talk page to have rater automatically add this template, and I was surprised when people started quoting this documentation as an argument against it. It really doesn't seem like this template has a downside. The archive page numbers and archive search by themselves are immensely useful and are a good reason to allow inclusion on all pages, in my opinion. The "talk page rules" and "find sources" are a little more questionable, but are probably helpful for new users. –Novem Linguae (talk) 19:18, 9 November 2021 (UTC)
I think I agree with sdkb: how universal is the advice this template gives? I'd support the proposal as an improvement over the current situation, but there are differences in how small and large talk pages operate. On low-volume pages I use talk pages for general notes on editorial decisions, sources that could be useful in the future, and keeping track of what needs to be done; basically I use it as a public notebook. For high-volume pages though it's truly more of a discussion venue and the "notebook" style of talk page use is less productive. I think including the template in general would be a good idea as we increase the visibility of talk pages, but I also think we should work to improve our guidance to include how to use talk pages effectively. — Wug·a·po·des19:37, 9 November 2021 (UTC)
Removing the quoted instruction parts looks good to me, per the proposal. I have wondered about this in the past, but didn't bother enough to complain. ~ ToBeFree (talk) 19:57, 9 November 2021 (UTC)
Keep as is. This is another unfortunate example of discussions that have a broad effect on huge swaths of editors and articles being held on a page that few are aware of or watchlist (and it has taken me two days to find where the current problem in medical headers originated). This template has been since November 2020 linking to misleading information about sourcing of medical articles, with respect to WP:MEDRS. The new implementations made just this week are equally misleading, as they still don’t point editors to WP:MEDRS, and leave the distinct impression that anything found in the linked sources is acceptable sourcing for medical content, when the majority of what will be found in those links is not likely to represent good medical sourcing. We are misleading the very people we intend to orient on every medical article talk page. And, this was done based on discussions here, and at WT:MED, involving only three or four editors there. So, we have had since Nov 2020 misleading info on talkpages of all medical articles, and we have the same problem magnified with the latest addition. This template is now misleading on every medical article. This should be rectified, or a community-wide RFC about this misleading info wrt WP:MEDRS should be held. This template is unuseful now on medical articles, unless it includes information clarifying how and which of those sources can be used for medical content with a link to WP:MEDRS. Until that is done, the template should not be foisted upon every talk page. And neither should ordinary content editors be forced to learn complicated syntax to control the misleading output of this template. SandyGeorgia (Talk) 02:50, 13 November 2021 (UTC)
Hi Sandy! If I understand you correctly, your objection is with placing this on medical articles, yes? If this template is a problem on medical articles, then it is a problem on ALL medical articles, not just new ones. Would you remove your objection to this proposal, which is not related to your objection, and start a RFC on placing this template on medical articles. If you like, I'll help you with that. SilkTork (talk) 19:37, 13 November 2021 (UTC)
Hi, SilkTork! My apologies for butting heads here with some of the editors I most respect on Wikipedia, but this issue is far more important than the socking earlier this year that led me to stop editing. Coming back to active editing to find this is very offputting. I should not have to read through walls of technical text to a) find the related discussion myself, and b) ask that (what I believe should be) a very simple wording fix be implemented. It sounds like from the discussion over at WT:MED that there may now be some acknowledgement that the fix can be done, and I hope it will be done shortly, in which case I can strike all objection. For now, my objection is that the talk header template shouldn't be used anywhere, as it is hugely problematic. I hope an RFC won't be needed, and I hope I can strike any objection in short order. Information that can lead new and inexperienced editors to non-MEDRS-compliant editing should never have been contemplated anywhere, and I am quite astounded that it was. Perhaps I am missing the distinction between using this on new or existing; for now, I want to retain the ability to remove the Talk header anywhere it is used, as it is a trainwreck, and how do I know the same problems aren't being introduced outside of medicine content? Please feel free to pop over to my talk, or to email me, if I am completely missing the point, but I entered this page somewhat perturbed at having to spend several days finding the source of the problem, and encountering what felt like stonewalling earlier on. I hope/believe we are beyond that now. Best, SandyGeorgia (Talk) 19:47, 13 November 2021 (UTC)
I have struck my position above, and have no opinion now. After a slow start, we have now made great progress working together with template editors at WT:MED on correcting the info in the header affecting medical articles, so I am happier. We still have more work to do, but there is now a link to WP:MEDRS in the header, so this template is no longer something I don't want to see used anywhere, any time. I do have a separate question on how Wikipedia came to preference The New York Times over all other news sources, and will start a new section for that question. [2]SandyGeorgia (Talk) 21:08, 14 November 2021 (UTC)
Support conditional upon the fixes being discussed over at WT:MED reaching a satisfactory conclusion, which it looks like they will. Fretting about turning a red link into a blue one is just silly (and as noted, WikiProject banners already do that). Moreover, the wording in question is self-contradictory. On the one hand, we're told don't place it on the talk pages of new articles. On the other, talk pages for articles often subject to controversy are good places for it. What if the creator of a page is pretty damn sure that the topic will be subject to controversy? Should we forbid them from starting off the talk page in the best way? This advice is an artifact of arguments in a bygone era. XOR'easter (talk) 19:27, 14 November 2021 (UTC)
WikiProject banners convey information specific to the article (e.g. that the article is being tracked by a WikiProject). The talk header on an empty talk page conveys no such information. The editor starting the first discussion on such a page would be served just as well by an editnotice. DaßWölf19:59, 14 November 2021 (UTC)
Unbundle Any general instructions for using talk pages should be a standard part of the mediawiki interface. I attended a training session recently at which new users required instruction in using such pages and even the instructor forgot that you can't use the visual editor on them. So, there's a long way to go before these pages are usable by our general readership.
I don't like the {{talk page header}} because it's too long and bloated. The find statistics were recently forced into the template and the alternative templates were deleted. As a regular user of {{FSS}}, I've been trying the talk page template for my new articles but still don't like it because of all the other baggage. The project templates are largely useless as the relevant project is usually inactive or otherwise of no help. So, the general approach to these templates has yet to settle down and so we should not be trying to micromanage this. As and when the WMF get around to making the visual editor work on talk pages, we'll need to think again and so shouldn't get too invested in the current bodges and stopgaps. Andrew🐉(talk) 21:02, 14 November 2021 (UTC)
Oppose, if a talk page doesn't need this template, it is probably dead and we shouldn't encourage people to post there. (I would support using a general template for all the meta-information; why is article quality in Wikiproject templates and not in this one?) —Kusma (talk) 16:54, 20 November 2021 (UTC)
Keep as is until suitable replacement prose is approved. While I support the idea of "updating" the documentation instructions (by less stringent prose and clarification) I oppose any changes that simply remove existing instructions without regard to retaining the cautionary sentiments intended by their remit.--John Cline (talk) 18:01, 20 November 2021 (UTC)
I would support the well-reasoned removal of "only where it's needed", and I'm baffled by the opposes. "We shouldn't encourage people to post" on low-traffic talk pages? That's incomprehensible to me. But I wouldn't want this template to be widely added by means of automated tools such as AWB or bots because that's a needless strain on the server -- let's just say that it can be boldly added to any individual talk page by any editor who sees fit.—S MarshallT/C01:24, 21 November 2021 (UTC)
Support allowing discretionary use of the template in any situation per SilkTork's argument, provided this isn't used for en-masse additions of the template – as S Marshall points out, the current situation ain't broke. Encouraging appropriate use of talk pages, even quiet ones, by casual readers, would-be editors and new editors is a positive change in my view. I think the template's functionality & guidance will help lower the barrier to entry for these groups. Jr8825 • Talk18:27, 11 December 2021 (UTC)
Support Removing Boththe first, keeping the second - I think there is essentially zero downside to adding this to a talk page. that has discussion. But there is probably a small downside to adding this to talk pages that are empty. — Shibbolethink(♔♕)18:51, 21 December 2021 (UTC)
I Am Chaos and Shibbolethink. I'm curious as to the thinking behind the objection to put the template on a non-created or red talkpage. My thinking is that a new user who may have a question or suggestion in relation to an article would likely be put off by having to face a red page with no advice, and with perhaps the concern as to if they are allowed to create a talkpage in the first place, but they would be encouraged and helped by having a template which explains how to use the talk page. An empty talkpage seems to me to be one of the most useful places to put this template. SilkTork (talk) 11:45, 22 December 2021 (UTC)
My thinking is that a new user who may have a question or suggestion in relation to an article would likely be put off by having to face a red page with no adviceThat makes a lot of sense, and I hadn't considered it from that angle. — Shibbolethink(♔♕)12:41, 22 December 2021 (UTC)
That makes a lot of sense, didnt consider it that way, I had mostly considered the merits listed in the sentence itself Signed, I Am Chaos (talk) 17:46, 22 December 2021 (UTC)
Support Apart from the other arguments mentioned this will probably become a possible source of archiving settings. That makes it very useful to be able to put it on new pages you expect to have significant talk page discussion in the future. --Trialpears (talk) 20:14, 26 December 2021 (UTC)
Removed in this edit, per rough 12–5 tally plus several no opinion/unbundle/other. (Not an Rfc, and I'm involved, so this is not an Rfc-like evaluation that takes argument strength into account. If anyone objects, feel free to undo.) Thanks, Mathglot (talk) 05:04, 28 December 2021 (UTC)
Yeah. They'd need a bot, and it would never pass Bot Review. And if anyone used an existing bot to do it, it would likely be noticed... I agree with @Johnuniq, that would be concerning if it did happen en masse. But right now we have just removed a prohibition not created a mandate. — Shibbolethink(♔♕)21:54, 30 December 2021 (UTC)
Yeah, that would be the solution if we wanted to add it en masse, right? I personally support that, but I think probably many others would not. I think a drastic change like that would probably need much wider input, like an RFC at village pump or w/e. The proposal would need to be extremely brief and well reasoned as to why it would be beneficial to do this, and not disruptive. For example, this would double up the header on those 600k pages previously mentioned :( — Shibbolethink(♔♕)22:12, 30 December 2021 (UTC)
Oppose-ish Since this is still open, I'll voice my objection to removing the part about 'when needed'. I'm fine with "reducing" the "you shouldn't add it to a blank page ever" warning to "you can, but that doesn't mean you should" or something similar (where it's allowed but not encouraged), but this is not a template than needs to be mass-added to all pages. Which could simply be "Add the template when needed", which should reinforce that it's usually a good idea to add it to high-traffic, high-discussion, newbie-prone talk pages, and omit on other pages (like category talk pages, or project discussion pages like WT:CITEWATCH). Headbomb {t · c · p · b}19:49, 11 February 2022 (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.
Done — Martin (MSGJ · talk) 16:49, 17 March 2019 (UTC)
Done (and I agree the doc page shouldn't be protected) * Pppery * it has begun... 02:08, 7 June 2021 (UTC)
Not done as this is contentious and would require discussion. — xaosflux Talk 10:49, 29 June 2021 (UTC)
Fixed, and thank you very much for the good catch! P.I. Ellsworth ed. put'r there 01:18, 14 July 2021 (UTC)
Self-trout about the video games thing, I didn't catch that by "video" above you were referring to video games.
... Re giardia/giardiasis: check. Re where to put, and all that, easy-peasy; bbiab > RL 🐾. Mathglot (talk) 00:54, 12 August 2021 (UTC)
mention me on reply; thanks!) Mathglot (talk) 21:40, 6 January 2022 (UTC)
17:25, 20 November 2021 (UTC)
