Wikipedia talk:Short description

Short descriptions should be useful

A week ago, I appended some points about utility to Wikipedia:Short description#Format, which I believe summarises a number of discussions above:

• be meaningful, so no shorter or longer than is needed by a reader unfamiliar with the topic to identify it as worthy of further exploration
  • In addition to search support, SDs are used as the default annotations for entries in WP:see also lists, where they provide an important function as a "Guide to information sources" related to the host article. (See § Annotated links below.)
  • For this purpose, the article title and its SD will be read together, so the SD is not required to be wholly meaningful in isolation.

but MichaelMaggs reverted saying that it does not have consensus. I acknowledge that it has not been proposed in precisely this form but certainly the view that fatuous SDs like "Concept in mathematics" are unacceptable. Can my version be improved? because surely there cannot be any continuing argument about the principle? 𝕁𝕄𝔽 (talk) 17:56, 29 April 2026 (UTC)

See new section Wikipedia:Short_description#Complex_or_technical_subjects which tries to address this in a more general and considered way than deprecating just the specific wording "Concept in mathematics". MichaelMaggs (talk) 18:09, 29 April 2026 (UTC)

No, the purpose of my addition is to encourage editors to make the SD useful to "a reader unfamiliar with the topic to identify it as worthy of further exploration". My intention is to encourage good SDs, not provide excuses for the SDSHORT pedants to render them useless to anyone except searchers who already know what they want.

It is not acceptable to sideline the most basic ideas in science, mathematics or technology as "complex or technical". Contrast this with your own practice: for example, you recently added this SD to Abuzar Brigade: Afghan Shia militia, 1980–1988. Why did you not consider that Military group would not be adequate? For someone searching, it would be enough. At Figure study, you wrote Preparatory artistic study of the human body when Art technique would do, it distinguishes it from numerical analysis. You don't practice what you preach – and rightly so, yours are excellent and meaningful SDs. It is the sermon that is at fault, not the practice. Is the problem that STEM topics are ipso facto "complex" by definition in your worldview but topics in Humanities, Arts and Social Sciences are not? 𝕁𝕄𝔽 (talk) 19:59, 29 April 2026 (UTC)

As a ex-physicist myself, I really don't recognise the framing here. The entire purpose of the new section is the opposite of "rendering them useless": I wrote the section to meet your concerns, and I'm sorry you feel so negative about it. It's intended to acknowledge that for some topics there really is no way to make the whole thing comprehensible to a non-specialist reader, and to explicitly approve wording such as "Theorem in x" or "Algebra of x" where x may be something quite technical. I've tried tweaking the wording again to ensure that's clear, and to remove any implication that "Concept/Aspect/Topic" etc are the only possibilities; they are the last resort. There should be no need in any event to go as broad as "Concept in mathematics" (which I agree is not good) since the words "Theorem", "Algebra" etc provide sufficient context. I initially included an example from philosophy, to make this more general, but took it out for fear of being too wordy. It could easily be put back, for less emphasis on maths/physics. Really, this applies to all topics needing substantial background knowledge, not simply STEM topics. MichaelMaggs (talk) 21:08, 29 April 2026 (UTC)

First, I can only apologise for making an embarrassingly invalid assumption about your motivation.

No, I don't feel negative about it but only that it addresses the symptoms but not the disease. Your addition (which I applaud) suggests how to write better SDs for complex topics but it does not (and should not, because the disease is by no means unique to these cases) say why the effort should be made. In my view, the disease is the tendency to create SDs that are so terse that they are useless for anything but search. The underlying problem is that there are still too many SDs written to disambiguate between search results for cognoscenti, not to facilitate serendipitous discovery of related concepts. The purpose of my proposal is to encourage SDs that facilitate the latter, even if it is at the (marginal) expense of the former. 𝕁𝕄𝔽 (talk) 11:05, 1 May 2026 (UTC)

Thanks. If you could give me a few days I'll have a further think (I may not have much time over the long weekend). I do have sympathy for your "worthy of further exploration" idea, especially since SDs have started to appear in new areas such as the Wikipedia mobile "Because you read" and "Top read" recommended reading lists. MichaelMaggs (talk) 16:44, 1 May 2026 (UTC)

There are clearly some strong views (below) about the merits of "worthy of further exploration". It would be useful to have other views. MichaelMaggs (talk) 09:09, 16 May 2026 (UTC)

Strong oppose. There are a number of misapprehensions about the purpose of SDs here. This proposal is entirely contrary to the core purpose of short descriptions. Having been christened with an unfortunate name, editors have been missing the point of why short descriptions were created in the first place, and very often try to describe what the article is about using them. But SDs have nothing at all to do with describing clarifying complex topics and should not be used for that. Per Article title policy:

The title indicates what the article is about and distinguishes it from other articles

The SD is not about repeating or extending the title; how could you possibly hope to explain a complex topic in forty characters? It has one purpose: to get a user searching for an article to the right place as fast and easily as possible from a short list of titles returned by a search where title alone might be confusing, but title + SD makes it clear. That's why the SD of Ecuador is Country in South America and nothing more, because if a user is searching for something and ended up with a short list of just titles, let's say, 'Equator', 'Equatorial Guinea', 'Ecuador', 'Ecuadorians', 'Equatoria' they might not know that 'Ecuador' is the South American country they had in mind and click it, but if the list was title + SD instead, like this:

• Equator, Imaginary line halfway between Earth's North and South poles
• Equatorial Guinea, Country in Central Africa
• Ecuador, Country in South America
• Ecuadorians, People of Ecuador
• Equatoria, Region in South Sudan

then they would know right away, and click the right one. And that is the only reason for the existence of the (poorly named) "short description".

Keep in mind that users *never* see the short description on the article page itself, so it is not going to help them understand what a complex topic (or any topic) is about. For that, we have MOS:LEADSENTENCE. Note also, that Colombia, Peru, Bolivia, Paraguay, all have the *identical* SD: Country in South America. That would not work if it were really a description of what the topic is about, but that is not its purpose. Mathglot (talk) 17:35, 1 May 2026 (UTC)

The three purposes of SDs, with long-standing consensus, are set out at WP:SDPURPOSE. Things aren't quite as black and white as you say. MichaelMaggs (talk) 18:21, 1 May 2026 (UTC)

Just one point to add to MM's succinct reply: your users *never* see the short description on the article page itself flies out n the face of reality unless you have decided that See Also sections are not part of article pages? (Or did you mean that the SD of an article is not reflected back? If so, then you have completely misunderstood my proposal because it concerns how the short description of a given article is displayed in the See Also lists of related articles.) 𝕁𝕄𝔽 (talk) 19:50, 1 May 2026 (UTC)

• Comment. JMF calls out specifically the short description "concept in mathematics" as "fatuous" and suggests by implication that it is not "useful". I sharply disagree. We mathematicians like to give things names that make sense to us, but that often could appear to outsiders as something completely different. A lay reader coming across a listing including "supercompact cardinal" needs first and foremost to understand that it's not a tiny red bird, but rather "some math thing". Really "some math thing" is all that 95% of them will ever want to know about it, and so "concept in mathematics" is actually very useful.
  Now, in that particular case, there's considerable space below 40 characters to play around with a more meaningful short description, if that's the way someone wants to spend their time. I don't really see much value in it but it's not my place to tell you what's a waste of effort. Just don't make it longer than 40 chars, and don't make the reader work to figure out that it's some math thing. --Trovatore (talk) 19:51, 21 May 2026 (UTC)

  First, as has been declared repeatedly, there is no 40 character limit. SDs should be concise, not be a definition, and be read in conjunction with the title. That's it.

  Second, taking the example you cite,

  1. (search): nobody is going to search for "supercompact cardinal" without already having some mathematical knowledge. There is no ambiguity. No credible confusion with birds or Princes of the Church. That fatuous SD adds no value to the people who credibly would search for it. Just give them the article and get out of the way.
  2. (annotated links): the article would only be included in a See Also list of related – wait, don't tell me... – concepts in mathematics. Need I go on?

  Annotated links are seen and actually read by far more readers than are search results. 𝕁𝕄𝔽 (talk) 08:35, 22 May 2026 (UTC)

  Annotated links are seen and actually read by far more readers than are search results. This seems highly unlikely to be true, given that anytime anyone using the default Wikipedia skin types anything into the search bar, they will see and read short descriptions whereas annotated links are in "see also" sections at the bottom of pages or navigation-type pages such as dabs. -- Patar knight - ^chat/_{contributions} 05:36, 23 May 2026 (UTC)

  Someone searching already knows what they are looking for. In contrast, 'See Also' lists tell them what they don't already know but may well be interested to find out. Which is why most articles have a 'See Also' section.

  Btw, dabs are generally hand annotated for specific clarification in that context, rather than use the SD option. 𝕁𝕄𝔽 (talk) 08:33, 23 May 2026 (UTC) revised --𝕁𝕄𝔽 (talk) 09:04, 23 May 2026 (UTC)

  Under the original raison d'etre of SD, you have it exactly backwards: SD's are *only* needed and helpful when viewing a short list of search results, and rarely if ever helpful in See-also listings, and 'annotated links' did not exist. But that was then, and this is now. Because of the misunderstanding of what SD was for, and some major changes to the guideline based on the misunderstanding, the meaning has morphed (perhaps metastasized would be a better term) into something very different, and now many editors—perhaps most—might agree with you today.

  'Short description' was a poor name to begin with, and then Annotated links were introduced afterward and just confused things further. The fact that a single editor unilaterally created the {{Annotated link}} template on 13 September 2018 and the new SD section about annotated links called '#Using short descriptions in Wikipedia' the same day without any discussion about it afaict, is perhaps understandable given the confusion about SD, but nevertheless represented a departure from its original purpose. That section name completely usurped the original purpose of SD, or perhaps that editor never understood it to begin with. By 5 Jan 2019, it gained a subsection heading, "Annotated links", still under section "Using short descriptions in Wikipedia", as if that were its main purpose.

  The crappy name short description was the first step in obfuscating the original purpose, which led to making annotated links possible, which ended up becoming the nail in the coffin of a comprehensible, single-purpose short description. Through long acceptance this has now has become part of the foundation of SD, sitting uncomfortably alongside the original purpose, leading to these endless flare-ups that cannot be resolved, because some editors prefer one incarnation of SDs, while others prefer another, and a guideline in conflict with itself.

  I can imagine an article some South American topic have a See-also section listing some nearby countries, where the section might look like this:

  • Peru
  • Bolivia
  • Paraguay
  • Chile

  Perhaps some helpful editor thinks it might be an improvement to use {{annotated link}}, so they add them, leading to this:

  • Peru – Country in South America
  • Bolivia – Country in South America
  • Paraguay – Country in South America
  • Chile – Country in South America

  Being aghast at how unhelpful that was, they might then change all the South American SD's from old-skool SD's into definitions. Someone who buys in to the See-also/annotated-links theory of SD will probably see the original SD's that are faithful to the original purpose of SD as somehow wrong because they make no sense in a See also section and change them to definitions, which were originally forbidden. Yet given the current [per]version of SD, that would be a defensible change.

  In fact, annotated links should never have been created, or at least, they should not have been based on short descriptions, if they are to be uniformly helpful in See-also sections (as opposed to helpful only when the SD-authoring editor adheres to the SD-as-useful-in-See-also theory). But it's all one gigantic muddle now and there is no good solution to it anymore. Maybe we should just give up and go with the muddle, rename Short description to Sesquipedalian Definition, and limit them to 256 characters. Then we can stop maintaining that it was ever intended to be a search disambiguation phrase. Mathglot (talk) 10:42, 23 May 2026 (UTC)

  No, the key concept you have missed is emergent behaviour. Yes of course the original concept was as a timesaver at the regular query entry point. That was true then and it is still true. The key development since then is

  1. the recognition that there are thousands of items in 'See also' lists that have only the cryptic (to the uninitiated) names of the article concerned. Some conscientious editors were annotating by hand but that was a tiny minority.
  2. the recognition that most SDs are good enough to provide an 'out of the box' annotation

  So the leap of imagination was to create {{annotated link}} to capitalise on #2 to make a huge dent on problem #1. By and large, this idea hit the ground running and it is good enough for most of the articles most of the time. In narrow contexts, hand annotation is still needed but the SD is usually good enough. Or it is until some wikilawyer comes along and renders it meaningless or useless because they are still straitjacketted into the 40 character limit fixation. 𝕁𝕄𝔽 (talk) 15:00, 23 May 2026 (UTC)

  Some responses:

  • Most SDs are not good enough; or at least, not when they were being written according to the original conception.
  • The use of annotated links helped hardly at all (see South American example above) until editors realized they could *make* annotated links provide useful information by abandoning their original purpose and the character-size limitations, and writing the SD *for* annotated links. I.e., they wagged the dog, doing things backwards, figuring that annotated links are the goal, and needed longer SDs that look like definitions, because that was what a link needed to explain it, so that's what they did; adjusting the project page to boot, to suit the goals of the template. Of course, the total number of annotated links is minuscule, compared to the number of SDs, so the purpose of SD and the project page description were altered to suit a minuscule number of cases.
  • The leap of imagination was good in theory, but the design was tragically flawed. Instead of basing the annotated link on the SD, it should have been based on the WP:FIRSTSENTENCE of the article, which *is, in fact, a definition*. That would have been the correct approach. (And it still could be done now, but it seems like the horses ay have already left the barn.

  Thanks, Mathglot (talk) 03:47, 27 May 2026 (UTC)

  Nobody ever suggested that SDs should not be concise. SD:Short still applies and it sets out the consequences of excessive verbiage. But excessive brevity can produce a meaningless SD. Such fatuous and facile SDs disadvantage search too. --𝕁𝕄𝔽 (talk) 15:31, 23 May 2026 (UTC)

  It is also relevant that the advent of {{anl}} has led to a significant reduction in the number of articles without SDs. It is a win for both applications. --𝕁𝕄𝔽 (talk)

  I don't know what gave you that impression; annotated links have almost zero effect on the number of articles without SDs. The total count of transclusions of annotated link is around 16,000 (so, fewer than 16k articles, as probably most transclusions are not singletons), whereas the number of short descriptions is about 6.8 million (which means 6.8 million articles, as no article has two). Mathglot (talk) 03:59, 27 May 2026 (UTC)

  Mathglot, many articles have two, e.g. with an automatic one from the infobox and a manual one that overrides it. — Qwerfjkltalk 12:01, 27 May 2026 (UTC)

  Ah, thanks for the correction, I was unaware of that. I'm not sure how to exclude only those from the tally, but in the worst case (assuming every Infobox has an SD, which we know is an exaggeration) that would alter the tally by half, I think, so 3.4 million, not 6.8 million (unless some have two infoboxes); so the 'drop in the ocean' comparison still holds. Mathglot (talk) 19:14, 30 May 2026 (UTC)

  Mathglot, well, Category:Articles with short description has 6.3 million. But yes, your points stands. — Qwerfjkltalk 13:14, 31 May 2026 (UTC)

  I didn't try to quantify it and maybe there is something out of the ordinary about the threads I have followed, but my experience of applying annotations to many 'see also' lists is that five to ten percent have not had an SD before I added it. But anecdote is not evidence, so I must accept your numbers. 𝕁𝕄𝔽 (talk) 08:55, 27 May 2026 (UTC)

  • No, they aren't going to search for "supercompact cardinal" but it could nevertheless come up when someone starts typing "cardina...". It didn't, in my experiment just now, but enough stuff came up that wouldn't have started with those letters that I don't see why it wouldn't. As for annotated links, I have not been convinced that they have much value. --Trovatore (talk) 16:21, 22 May 2026 (UTC)

    So by simple inference, you are equally not convinced that 'See also' lists have much value. 𝕁𝕄𝔽 (talk) 08:36, 23 May 2026 (UTC)

    That's...actually true, but I don't see how it follows. I'm against "automagicizing" Wikipedia in general (I think for example that "abstract Wikipedia" is a completely ludicrous idea that needs to be junked and expunged), which is why I'm not convinced by automated links. I also think that "see also" has little clear rationale, and that there's a risk of people using it tendentiously to make insinuations that don't have to be cited. But I don't really see the thread connecting these two points. --Trovatore (talk) 01:00, 27 May 2026 (UTC)

    We partly concur on this one. Robotic annotation of entries in 'see also' lists is not perfect and they should all have been annotated by hand when they were added. But the perfect is the enemy of the good and the SD is usually good enough.

    One of the many advantages of annotations is expose entries in a 'see also' list to critical examination. "Why is this here? How is it relevant?" As I have written already, most editors don't routinely see the SDs of other articles - why would they? Annotated 'see also' lists cast light in the murky shadows. 𝕁𝕄𝔽 (talk) 09:07, 27 May 2026 (UTC)

Political persuasion

There is a bit of a discussion on dewiki and wikidata about what is suitable for a short description. It might be useful to gauge opinion on enwiki too. Is this suitable or encouraged?

• Tino Chrupalla - right wing German politician

In my opinion "right wing" is subjective and/or controversial and we should better stick with facts, e.g.

• Tino Chrupalla - German politician
• Tino Chrupalla - German politician and member of AfD party

The current one is German politician (born 1975) which seems sufficient — Martin (MSGJ · talk) 09:04, 25 June 2026 (UTC)

I agree. "[nationality] politician (birth/death range)" should (nearly?) always be sufficient to distinguish the person from other people with similar names. I imagine that there are a few instances of two politicians with the same name, but additional disambiguation can be provided in those rare cases. – Jonesey95 (talk) 17:43, 25 June 2026 (UTC)

I prefer just "German politician (born 1975)" here. "Right wing" is too opinionated rather than factual and its meaning varies significantly from country to country, and "AfD" is too jargony for anyone not familiar with German politics. Usually in surname articles (where the principle of what to include is roughly the same as for short descriptions, except for the different placement of dates) I only see "[birth and death dates] [nationality] politician" or maybe sometimes the name of the highest office they held. —David Eppstein (talk) 07:27, 26 August 2026 (UTC)

David Eppstein, presumably if a reader is trying to look up that person, they would already be somewhat familiar with German politics? — Qwerfjkltalk 18:01, 26 August 2026 (UTC)

Short descriptions are more often for when a reader is not trying to look up that person, finds them in a list of other results for whatever search they're doing, and wants to distinguish the person they're really searching for from all those other people with similar names. And if they're actually looking for Tino Chrupalla, the German politician, and see the short description "German politician" in one of their search results, it's probably specific enough to tell them it's the article they're looking for.

In short: short descriptions are for search disambiguation, not a précis of the article, per WP:SDNOTDEF. —David Eppstein (talk) 18:42, 26 August 2026 (UTC)

National Elections for Singular Offices (ex. Presidential elections)

I would like to suggest a slight shift on the suggested description for National elections, to include for a description of elections of one person-the person elected. This would go along well with the suggested scheme from earlier in the examples section (ex. the 2018 Brazilian general election was the Election of Jair Bolsonaro). It would indicate clearly what the article is about, providing a bit of disambiguation as well, since many articles are separated by a single digit in the year (pretty easy to misremember or mistype) and people may be searching for the election of a particular leader (for example many people go to 1980 United States presidential election, looking for how Reagan was elected). It would help clear up which option to pick when searching for a particular election article. Someone searching "US Presidential Election 198" not remembering the exact year of the election they look for could then easily select the 1984 election reading the SD "Re-election of President Ronald Reagan" or 1988 seeing "Election of President George H.W. Bush". Do you guys think this is a good change?FiredudeT (talk) 01:28, 26 August 2026 (UTC)

I like this idea, yes. Helpful Cat🐈‍⬛ 10:40, 30 August 2026 (UTC)

I'm going to be bold and make the change now, hopefully no one opposes it. FiredudeT (talk) 20:09, 6 September 2026 (UTC)

Should noreplace become the default?

Message intended for Template talk:Short descriptionTemplate talk:Short description, which redirects here.

Once again, a transcluded page with a short description has caused much head scratching. Is it time to make noreplace the default for short descriptions?

When multiple short descriptions appear in an article, we almost always have a carefully hand-crafted SD on line 1 followed by generic efforts generated via transclusions (normally of templates, but sometimes of article leads). Line 1 usually has the best SD (and should be improved or removed if it doesn't). The only use case I can see for replacing by default is when article A includes firstly the lead from article B and secondly a template: in this case, article B's SD may be so specific as to be wrong, so the generic template SD is better. However, almost all templates which produce SDs use noreplace anyway, so the current default does not help.

I think the best (and only?) place to change the default is in {{Short description}}. This template currently passes its second parameter (which is noreplace or absent) through to the SHORTDESC: magic word. Instead, Template:Short description would add |2=noreplace to the magic word by default but would accept a new optional parameter |2=replace (for which I can think of no use case) to suppress that behaviour.

• {{Short description|Type of foo}} → {{SHORTDESC:Type of foo|noreplace}} (second output parameter is new)
• {{Short description|Type of foo|noreplace}} → {{SHORTDESC:Type of foo|noreplace}} (as before)
• {{Short description|Type of foo|replace}} → {{SHORTDESC:Type of foo}} (second input parameter is new)

I believe that the only change of behaviour would occur when one page has or transcludes more than one {{short description}} without noreplace. The first such SD is usually on line 1 and is the one we want. Other SD(s) are either accidentally buried further down the page or in some transcluded page, and are unlikely to be better than the line 1 SD. Of course, the vast majority of later SDs are in templates which already use noreplace and would continue to be correctly skipped, this change having no effect on them. Certes (talk) 15:37, 1 September 2026 (UTC)

After a brief bit of testing, I think this might be a good idea. I put two short descriptions with "noreplace" in my sandbox, and the first one was chosen, as expected. I suspect that this might have unexpected side effects, and that adding the "replace" option (if there is a real use case) will require MediaWiki developers to make changes to the code. Other editors here might be able to predict some side effects. Reading the background at T193857 as well as MOS:ORDER discussions from 2018 and 2019 might help explain why the current situation exists. – Jonesey95 (talk) 19:38, 1 September 2026 (UTC)

The code might be more elegant if this proposal were implemented in MediaWiki rather than {{Short description}}, but it wouldn't require MediaWiki developers. The template code change may be as simple as replacing {{{2|}}} by {{#ifeq:{{{2|}}}|replace||noreplace}} (not tested). Certes (talk) 22:48, 1 September 2026 (UTC)

The effect of SHORTDESC:, if I understand correctly, is:

if there is any SD without noreplace

use the last SD without noreplace

else if there is any SD with noreplace

use the first SD with noreplace

else

there is no SD

The current effect of {{Short description}} is the same, as it just passes parameter 2 through to SHORTDESC:. If the proposal were implemented, it would become:

if there is any SD with replace (a very unusual occurrence)

use the last SD with replace

else if there is any SD without replace

use the first SD without replace

else

there is no SD

That seems like an improvement, as it will result in the line 1 SD taking priority unless something explicitly replaces it. Certes (talk) 22:59, 1 September 2026 (UTC)

I think that there is a danger of overthinking this. The Wonky transclusion problem was a problem with the transclusion, not really a SD issue. The current SD magic word behaviour is derived from the standard behaviour of other magic words. Where a magic word is repeated, the last one wins. Articles should always have their own SD in the first line, or none at all. Any templates (infoboxes or other stuff) should then always set a SD with noreplace so that the article one wins. This is what we have now and generally it works. Having the first SD win might be the technically better solution, but the time to make changes to the way the magic word works or redefine the behaviour of the SD template was probably in 2017 before the magic word was implemented in early 2018. — GhostInTheMachine ^{talk to me} 14:33, 2 September 2026 (UTC)

But we didn't fix it then, and it could be fixed now. Something being suboptimal for years does not mean that it should never be improved. Also, the above proposal does not change the way that any magic words work. The last transclusion without noreplace still "wins". – Jonesey95 (talk) 14:56, 2 September 2026 (UTC)

I think it is more a case of "probably we should have defined it differently back in 2017". However, we didn't and we have have made it work since. I don't really see anything to fix at this point. The last use without noreplace currently does win, because there will only ever be one use without noreplace. — GhostInTheMachine ^{talk to me} 15:20, 2 September 2026 (UTC)

I'll phrase it in a different way: What is the downside of making this proposed change? Will anything break? What, specifically? – Jonesey95 (talk) 16:16, 2 September 2026 (UTC)

I am trying, honest, but I am still having difficulty seeing an actual proposal addressing an actual need. As Certes says ... a new optional parameter |2=replace (for which I can think of no use case). If there is no use case, why add a new parameter? I don't see we have something to fix. The Wonky transclusion problem was a problem with the transclusions and was easily fixed. Maybe a sandbox with the modified SD template could illustrate the point? — GhostInTheMachine ^{talk to me} 19:01, 2 September 2026 (UTC)

I mentioned the possibility of adding a |2=replace as a counter to any possible objections that we would be losing functionality here. The change which may have no use case is that precaution, not the entire proposal. I think it's still beneficial to have noreplace as a default rather than having to remember to add it to every template which provides a backup SD and to every other page with an SD which might get transcluded in whole or part. Certes (talk) 19:12, 2 September 2026 (UTC)

The use case for the new code proposed above is evident in the VPT thread that originated this proposal. Two lead sections were included in an article, and a short description from one of the leads was inadvertently saved as the short description for that article. That would not have happened under this new proposal. The new code would also prevent an infobox or other template's embedded short description template from replacing an article's local short description if an editor forgot to use noreplace in the template. I see only advantages, and I haven't seen a counterexample (but I am very much open to the idea that one exists). This change would specifically fix the problem that we created in 2017–2018 when we decided to place the SD at the top of the page and codified that guidance in MOS:ORDER. – Jonesey95 (talk) 20:07, 2 September 2026 (UTC)

Fair, but adding a replace parameter really is an unnecessary step. If we limit ourselves to altering the SD template to treat noreplace as the default, then we effectively have first-use-wins for the magic word. That seems to be a fairly cheap way of avoiding the (admittedly rare) template issues. That would also serve to fix (but also mask) issues with unnamed transclusions, but I think that they should be hunted down and fixed as a separate issue — GhostInTheMachine ^{talk to me} 20:14, 2 September 2026 (UTC)

Certes has provided proposed code above. What is your proposed code for doing what you suggest? – Jonesey95 (talk) 21:38, 2 September 2026 (UTC)

If I've understood correctly, treating noreplace as the "default" without introducing a |2=replace option simply means mandating noreplace everywhere. That's as simple as replacing {{{2|}}} by a hard-coded noreplace, so parameter 2 is always ignored and becomes deprecated. This loses functionality (the ability to replace an earlier SD), but perhaps that's functionality we never use and never will use. I'm just concerned that someone may find a use case for it, and its absence may come back to bite us later. Certes (talk) 10:23, 3 September 2026 (UTC)

I think that your concern is inherently honourable, but as neither of us can think of a valid use case for the replace parameter, I feel that we should kick that can down the road somewhat. Making any overall change will take a moment, (agreeing to, not the code itself) so if somebody does think of a valid use case we can debate that when it happens. — GhostInTheMachine ^{talk to me} 12:36, 3 September 2026 (UTC)

New day. Reboot. Summarise

Let us consider the possibility that the SD template is changed to ignore any noreplace parameter (this is a thought experiment so just ignore the parameter for now, we can deprecate it and expunge it later) and always pass noreplace to the magic word.

This will give us the first-use-wins behaviour that could (should?) have been coded in back in 2017. Coupled with the current policy of always putting any SD template at the start of an article, this seems to give us everything we need:

• Articles should only ever have one SD template and so, if it does have one, it is at the start, is the first-use, so wins and continues to provide the SD for the article.
• Articles without an explicit SD template, devolve the setting of their SD to the infobox or some other general template.
• Infoboxes should only ever set one SD and so it will be used as the default whenever an article fails (or choses) not to have a SD of its own.
• Should an Infobox call other templates that also set a SD, then the infobox wins if it sets the SD at the start. (This is current standard behaviour.)
• Articles using transclusion to import text from other articles will not suffer any issues from importing too much stuff such as the SD from the target.
• Since the magic word is always being fed noreplace, the MW API will always return the same SD as the article itself.
• If a SD has been set in the article itself, the SD gadget always displays the correct SD.

Possible failure modes:

• An article has two (or more) SD templates. This is evil already, but our modified SD template defaults to the correct behaviour. The first SD template wins and any others have no effect.
• An article has an explicit SD template placed after the infobox. The infobox SD wins, whereas currently the article SD wins. We already judge this situation to be evil, so it still being evil in the new world does not worry me much. We might be able to set a tracking category if the SD template is used after the first line (first few lines??) of the article. I expect that the handling of that would generate an "expensive" template call. Not very worrying as the infoboxes often already cache the page source...

Big wins:

• Code in infoboxes that wants to set a SD no longer needs to perform the expensive "is there already a SD template" test.

Is the above a fair summary of the effects? Have I missed anything? — GhostInTheMachine ^{talk to me} 12:27, 3 September 2026 (UTC)

I think that you have summarized it well. We haven't been able to think of a use case for suppressing "noreplace". Presumably, if one exists, it will crop up after we deploy this change, and we can use some variant of Certes's code to handle it. – Jonesey95 (talk) 12:46, 3 September 2026 (UTC)

Thanks. That's a useful summary which matches my understanding too, except that I don't quite understand the "big win". Do you mean that templates can stop using {{Has short description}} or similar, which expensively reads the article wikitext? If so, and the purpose of that check is to prioritise the article's explicit SD, then the proposed change won't help (or hinder) that process. If the article's explicit SD comes before the template call then we can already prioritise it by using noreplace in the template. If the article's SD comes after the template call, which is unusual and violates MOS:ORDER, then the expensive check is still needed... unless, of course, we suppress noreplace in the article! Could that be the elusive use case for |2=replace? Certes (talk) 13:55, 3 September 2026 (UTC)

Enthusiastic as I am about this proposal, I do feel obliged to report some bad news. I was disappointed to find that we have several thousand articles, even GAs like Angata, where the SD is hidden away at the end of the page. This proposed change potentially has a negative effect there, as their explicit SDs stop replacing template-generated ones. Certes (talk) 14:22, 3 September 2026 (UTC)

Grumble mutter... that is why infoboxen need the {{Has short description}} call. Since we already regard putting the SD at the end of the article as "evil", we should fix those evil articles first.

I tried cooking a search, but searches generally do not have an awareness of the location of a match. "Infobox then SD" as a regex found some 1400 matches. {{#invoke:Is infobox in lead|main}} searches for the SD before any "==". I tried that as a regex and it timed out with 251 results. What search did you use? — GhostInTheMachine ^{talk to me} 15:20, 3 September 2026 (UTC)

I used this search to check for infoboxes before SD: 447 articles beginning with A. Some like Assynt also have a SD on line 1 just for good measure, which will of course be sneakily replaced by the one hidden near the bottom, no doubt leading to more scratching of heads. Certes (talk) 15:34, 3 September 2026 (UTC)

Good catch. Someone (or some bot) using AWB could presumably clean those up to make them compliant with MOS:ORDER. If one of you has AWB access, does running genfixes on one of these pages move the SD to the top? A bot/AWB run would probably get us at least 90% of the way to being able to implement this change. Having worked on Wikipedia for a while, I remain 98% confident that there are other edge cases that we will find only by implementing this beneficial change. – Jonesey95 (talk) 15:57, 3 September 2026 (UTC)

(ec) I'm digressing again but 42 A articles have two or more explicit SDs. Some pages like Aitebaar have the second SD on line 2, just to make sure, but the bonus SD could appear anywhere. This looks like an AWB task, with perhaps a Check Wikipedia report to catch new miscreants. Certes (talk) 15:58, 3 September 2026 (UTC)

Hunting articles with 2 (or more!) SD templates is part of my standard monthly routine. Sadly, I am a little behind on that - I have just used a canned search to add 93 such articles to my TODO list. Adding your search should keep me busy a while longer, but I think we should aim to fix these articles. They are breaking MOS:ORDER, so we should not be basing our plans around coping with them. — GhostInTheMachine ^{talk to me} 16:02, 3 September 2026 (UTC)

Thanks for your sterling work. I've fixed a few too. I think all the multiple SDs are now gone, though of course more will appear. Certes (talk) 22:19, 5 September 2026 (UTC)

Some are sure to return. I have altered my scanner so that it checks every day — GhostInTheMachine ^{talk to me} 16:36, 6 September 2026 (UTC)

Genfixes didn't seem to do anything to Angata or Assynt but I'm an AWB novice and may have pressed the wrong buttons. (I edit regularly with JWB but it doesn't do genfixes.) It should be easy (though tedious) to seek and destroy these cases with AWB or JWB. I'm not sure I'd trust a bot: a SD in the wrong position may have other problems, and picking the better of two (or more?) SDs certainly needs a human. Certes (talk) 16:13, 3 September 2026 (UTC)

I've just fixed the articles beginning with Z as a test, so the rest should be feasible in AWB/JWB. Perhaps the multiple SDs should be done first as they need more care; there should be about a thousand.

Here's another useful search which finds SDs after the bold text marker found in almost all article leads (and the AfD template, which I've excluded). Certes (talk) 16:43, 3 September 2026 (UTC)

I use AWB for all sorts of things, but the SD problems are often a symptom of further issues, so I have been doing them all manually. Heavy metal music at a high volume seems to help. — GhostInTheMachine ^{talk to me} 16:30, 3 September 2026 (UTC)

Yes, I've found one editor copying the article title into the SD, revised their contributions and had a word. A daily report catches SDs which match the title exactly (amongst other errors), but not variations. Certes (talk) 22:23, 5 September 2026 (UTC)

Restarting again: we now have few or no articles with multiple SDs, but 10,000+ with SDs a significant distance from the top of the page. Making noreplace the default could affect those articles: a generic SD generated by an infobox would override an explicit SD hiding later in the article. This may or may not be a good thing. Is it time to deploy a bot or AWB to move the SDs to the top, or would that fall foul of WP:COSMETICBOT or be undesirable in other ways? Certes (talk) 16:16, 15 September 2026 (UTC)

Since the SD should be at the top, asking a bot to move it should be OK. If there are then issues with articles, then there were probably issues with them before. Perhaps the bot can log the SD before and after it edits. Most changes should be from the infobox default to the moved SD value. We could then check the log to deduce patterns and maybe spawn misc clean-ups. I cannot think of a circumstance for which the bot introduces a real problem. — GhostInTheMachine ^{talk to me} 17:32, 15 September 2026 (UTC)

Do we know whether there are many examples of articles whose SD is deliberately later as a workaround for this transclusion issue? A bot move would break all of those, if they exist. —David Eppstein (talk) 17:56, 15 September 2026 (UTC)

I cannot think of any examples, or any realistic logic for doing that — GhostInTheMachine ^{talk to me} 18:41, 15 September 2026 (UTC)

It's conceivable that Ann Artiste#Some Album might transclude the lead of Some Album, unwisely including its SD, and someone has moved or copied Ann Artiste's SD down below so she gets described as a singer rather than an album. Moving SDs to the top would undo that kludge, but making noreplace the default would fix the problem properly and make the workaround unnecessary. Certes (talk) 20:33, 16 September 2026 (UTC)