Wikipedia talk:Manual of Style/Infoboxes

Grand Duchy of Finland

Hi, to meet MOS:INFOBOXPURPOSE, should we simply write "|birth_place=..., Finland, Russian Empire" instead of "|birth_place=..., Grand Duchy of Finland, Russian Empire" in infoboxes of people born in Finland between 1809 and 1917 (e.g. Carl Gustaf Emil Mannerheim and Jean Sibelius)? Thedarkknightli (talk) 03:36, 9 September 2025 (UTC)

What should be listed depends on the specifics of the case. Nikkimaria (talk) 04:12, 9 September 2025 (UTC)

Finland at the time was the Grand Duchy of Finland. This was not just a regional name; it was the official designation for the autonomous state.

The guideline you cited, MOS:INFOBOXPURPOSE, emphasizes summarizing "key facts" and the "|birth_place=..., Finland, Russian Empire" is too misleading. Finland was not a province or region of Russian Empire.

I've noticed your repeated attempts to pursue this idea and insisting on adding "Russian Empire" as the birthplace for Finnish people born in the 19th century everywhere, and I must respectfully disagree with this idea.

I see that you're trying to claim that Finland didn't have its own separate identity during that period, but this isn't accurate. It's important to recognize that the Grand Duchy of Finland had its own distinct legal and administrative systems. Although it was an autonomous state of the Russian Empire, it maintained its own constitution, currency, and military, and, importantly, its own citizenship. You're repeatedly claiming that people born in Finland at that time had Russian citizenship, that's simply not true.

Adding the Russian Empire as a birthplace would be misleading and would shadow the fact that the Grand Duchy of Finland had its own separate identity, which is a crucial part of Finnish history.

Also, I agree with @Nikkimaria's point that it may depend on the specifics of the case. Dresson354 (talk) 22:29, 16 September 2025 (UTC)

• Support the format "|birth_place=..., Grand Duchy of Finland, Russian Empire". There is no reason to omit Russian Empire here and using the long name for the Grand Duchy improves clarity and makes the target of the link clear (in the sense of WP:EASTEREGG).

The standard work discussing Finland's status within the Russian Empire is Jussila, Hentilä, Nevakivi (1999): From Grand Duchy to a Modern State: A Political History of Finland Since 1809. The concept of a "personal union" between Finland and the Russian state was an idea that was embraced by the Finnish elite starting from mid-19th century, and which caught wind in the late 19th century. It was never accepted by the Russian administration or the emperor. But even those promoting the idea of the personal union and a separate Finnish statehood did not dispute that Finland was a part of the Russian Empire, although they emphasized that it was not part of the Russian state. The inclusion of "Russian Empire" in the infobox is neutral with regard to that dispute, and does not take a side on whether Finland was a separate state of not. Jähmefyysikko (talk) 10:00, 17 September 2025 (UTC)

Hello again guys, I've just started an RfC on how to format Mannerheim's place of birth. Could you please share your thoughts at Talk:Carl Gustaf Emil Mannerheim#RfC on how to format place of birth in infobox? Thanks in advance, Thedarkknightli (talk) 17:16, 27 January 2026 (UTC)

"Grand Duchy of Finland, Russian Empire", would be correct. GoodDay (talk) 19:13, 27 January 2026 (UTC)

Hey guys, there's an ongoing RfC on how to format Jean Sibelius's place of birth at Talk:Jean Sibelius#RfC on place of birth format in infobox. Your participation is welcome. Thedarkknightli (talk) 17:14, 28 March 2026 (UTC)

Nowrap/nbsp in infoboxes for long parameter values?

Part of this discussion was on the use of the nowrap template in the infobox. Somewhat to my surprise, I failed to find any guidance on the use of the template in infoboxes aside from a somewhat vague recommendation at MOS:NBSP that a non-breaking space is "unnecessary" for "short" things in an infobox. This completely avoids the question of what happens if it's a long thing, like a name. I feel like this should be addressed, since (as MisterBee1966 pointed out) the use of a nbsp or nowrap could increase the width of the infobox to an unusable degree. Is there anything on this? Ships & Space_(Edits) 23:53, 23 March 2026 (UTC)

I am not aware of anything specific to nbsop in an infobox but MisterBee1966 is correct, in that we don't want to increase the default size of the infobox (see WP:IMGSIZELEAD). Cinderella157 (talk) 00:51, 24 March 2026 (UTC)

Criteria for adding an infobox

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

This resulted in Wikipedia talk:Manual of Style/Infoboxes#RFC on infobox criteria. -- Beland (talk) 05:37, 17 May 2026 (UTC)

---

This is about MOS:INFOBOXUSE, specifically the paragraph that says:

The use of infoboxes is neither required nor prohibited for any article. Whether to include an infobox, which infobox to include, and which parts of the infobox to use, is determined through discussion and consensus among the editors at each individual article.

Consider this to be one part of the "Community discussion recommended" by ArbCom about this subject and an attempt to address the problem they identified that It is not clear how infobox disputes are to be resolved (e.g. if 5 editors favor including an infobox in a given article and 5 disfavor it, there is no default rule and no policy guidance for determining how the consensus is to be determined, so the dispute continues indefinitely).

There have been prior RFCs such as Wikipedia:Village pump (policy)/Archive 143#Infobox RFC in 2018, but I don't think any covered this territory.

The question at hand is: What kinds of concrete, factual criteria might be considered by an editor who sometimes prefers an infobox and sometimes doesn't when deciding whether an infobox is appropriate for any given specific article?

Here are the ones I've considered so far (numbered for convenience in discussion):

1. Whether the page is a list or an article. (Infoboxes are uncommon on lists.)
2. Whether a suitable template exists. (We have an {{infobox royalty}}; we do not have an {{infobox algebra}}.)
3. Whether the subject of the article is a discrete thing (e.g., the Mona Lisa) or a broad or abstract concept (e.g., Fine art or Sports equipment).
4. Whether there are uncontroversial, basic facts that can be communicated clearly in a few words (e.g., an uncontested birth place).
5. Whether a higher proportion of readers with limited English proficiency are expected. (Infoboxes are easier for people who struggle to read text/paragraphs.)
6. Whether a higher number of readers with print disabilities are expected. (Ditto; this would affect, e.g., the article on Dyslexia.)

If you clicked Special:Random a few times (try it out!), do you think you could:

• apply a list like this to whichever article came up,
• produce an answer that satisfied you/subjectively felt like it was an appropriate result for the article, and
• usually get the same answer as other editors?

What else could we add to this list that you believe would be practical and helpful to editors? WhatamIdoing (talk) 16:28, 26 March 2026 (UTC)

I think you've identified a very persuasive set of baseline criteria. But I think any top-up test should be supplemented by a list of varieties of topic which are presumed to benefit from an infobox. For example, I think it's plausible that the community might agree that almost every biographical entry will have enough straight-forward, summary-level details to justify an infobox. An ironic statement, given the locus from which the great infobox wars arose, but I'd bet the broader community would endorse it. Articles on individual species or groups of organisms distinct enough to have a formal taxonomic rank below the level of family are probably another strong contender. Published works of most varieties, maybe? SnowRise ^{let's rap} 17:21, 26 March 2026 (UTC)

Can we make the fourth limb read "uncontroversial, pertinent, basic facts"? (For example, the height= parameter of {{infobox person}} is pertinent for a basketball player, less so for a chess player).—S Marshall T/C 18:02, 26 March 2026 (UTC)

Sure, anything you (all) want. WhatamIdoing (talk) 18:09, 26 March 2026 (UTC)

SnowRise, I think the most recent attempt to have a default was for biographies, and it failed. (AFAIK all attempts to establish a default have been to 'include'.) WhatamIdoing (talk) 18:17, 26 March 2026 (UTC)

The size of the article also comes into play. The lead is a summary of the article and the infobox is an adjunct to the lead to summarise key facts from the article. If the lead and/or article is small, any key facts from the article will be readily apparent and an infobox is likely redundant. Cinderella157 (talk) 00:06, 27 March 2026 (UTC)

@Cinderella157, thanks for mentioning this. I wonder, though, if that's really how we treat infoboxes these days? Look at a handful of random species articles: Many of our shortest articles have infoboxes, and most (sometimes all) of the content in the infoboxes is not present in the body of the article. WhatamIdoing (talk) 00:48, 27 March 2026 (UTC)

Why? I would think anything in an infobox should be in the article. Blueboar (talk) 00:57, 27 March 2026 (UTC)

Actually look at a handful of random species articles and tell me if you think the same thing. Then look at a handful of random chemicals, especially the "Identifiers" section in the infobox, and tell me how you would put that content into an article. WhatamIdoing (talk) 01:05, 27 March 2026 (UTC)

Chemicals are a specific exception to summarised from the article at MOS:INFOBOXPURPOSE because chemical properties are typically presented in tabular form. For a species, it is reasonable to detail key taxonomic levels in prose but not every level in the taxonomic hierarchy is necessarily key information - a bit like addressing an envelope with earth, the solar system, the Milky Way, the universe. Cinderella157 (talk) 01:42, 27 March 2026 (UTC)

Perhaps the species taxonomy should also be explicitly listed in MOS:INFOBOXEXCEPTIONS. Articles often don't mention even the family name in the prose, and they almost never mention anything higher than that. For many, many articles, the prose contains nothing more about the taxonomic tree than what the article title says.

About 15% of articles have taxoboxes. Those articles are disproportionately among the shortest (as measured in prose) in all of Wikipedia. I believe we decided when WP:NSPECIES was proposed that the median species article had a single-digit number of sentences (possibly 3, but I'd have to look). So "short articles don't get infoboxes" does not exactly seem to be true. WhatamIdoing (talk) 01:55, 27 March 2026 (UTC)

I didn't say, "short articles don't get infoboxes". What I said was: If the lead and/or article is small, any key facts from the article will be readily apparent and an infobox is likely redundant. The shorter the article, the less likely it is that an infobox is an improvement to the article that serves a useful purpose. Cinderella157 (talk) 03:06, 27 March 2026 (UTC)

• If the article (or its lead) is short, then "an infobox is likely redundant".
• If the infobox is redundant, it is "less likely" to be "an improvement to the article".
• Editors should not add things that don't improve the article.

Ergo: Shorter articles shouldn't (usually) get infoboxes. It seems to me that you said the same thing, only with more words. WhatamIdoing (talk) 03:26, 27 March 2026 (UTC)

(edit conflict) Well infoboxes are always definitionally redundant in their entirety, as a strictly technical matter, in the same way that leads are redundant because they too serve a summary function. I do get what you are saying: that with a stub article, having that info side-by-side can make the redundancy especially noticeable and the content lower utility, but I think there are a few reasons why default taxboxes still make sense: first, the same argument already mentioned with regard to chemical compounds is virtually as compelling for organisms: this is simply the most straightforward and consistent with the state of the academia way of presenting that information. And without question, every article on a species in any encyclopedia ought to have the fullest extent of the taxonomic designations existing in research. Phylogenetic too, to an extent. Of course, at a certain point we begin to get towards overlap with WikiSpecies and wikidata, but that's redundancy I can also live with, and clearly different applications and end-users anyway. In any event, as noted, very few of these articles are going to be unable to accommodate and benefit from some extra content. Indeed, a would hope that the presumption of a taxobox in particular would help encourage the gathering of that info, since the template itself lends to more categories of info being regarded as default features. That would be an unsurprising but nice knock-on effect. SnowRise ^{let's rap} 03:33, 27 March 2026 (UTC)

Adding an exception for taxonomy sounds reasonable and I think would be uncontroversial; I don't recall ever seeing a taxobox objected to.

I think short articles do get infoboxes, but I agree that in those cases (aside from chemical statistics, the taxonomic hierarchy, etc.) "any key facts from the article will be readily apparent and an infobox is likely redundant". I think they're prevalent because installing them is a pleasant low-cognitive-energy thing to do that creates an illusion of productivity and improvement. (I often do things that could be described in the same terms, like stub sorting.) Choess (talk) 02:13, 27 March 2026 (UTC)

Perhaps we have found two things here:

• Whether there is a specialized infobox, such as chembox or taxobox
• Whether the article is longer than a few sentences

(I think people like to add infoboxes because they amount to a sort of 'trade dress' for Wikipedia, so if you add one, it looks Right™. I do wish they'd start with Category:Wikipedia articles with an infobox request instead of articles where an infobox is disputed, though.) WhatamIdoing (talk) 02:43, 27 March 2026 (UTC)

How about, additionally, "Whether the article topic is also the subject of a STEM field for which uniform methods of documentation and classification exist (i.e. chemical compounds, documented species, or stellar bodies)."? SnowRise ^{let's rap} 03:40, 27 March 2026 (UTC)

Wikipedia:WikiProject Astronomical objects/Infoboxes appears to be the list? WhatamIdoing (talk) 17:13, 27 March 2026 (UTC)

Not just STEM. Other topic areas have structured data in standard formats (legal cases, for example).—S Marshall T/C 09:22, 27 March 2026 (UTC)

Are you thinking of {{Infobox SCOTUS case}} and the like? WhatamIdoing (talk) 17:14, 27 March 2026 (UTC)

Well, yes, that's an example. {{Infobox musical scale}} is another: the notes chords and modes should be listed in a structured way, because for many people looking up D minor in an encyclopaedia, it's because they're learning an instrument and that's the info they want. Put it in the same place in each article so they can see it at a glance. Surgical procedures are another example (although our current surgical procedure infoboxes are pretty americentric).—S Marshall T/C 23:36, 27 March 2026 (UTC)

From the policy-writing angle, I don't feel like we've found the right balance. We've identified a handful of infoboxes we want to encourage (e.g., chembox) but if we say something like "Widely used specialized template", then I expect the next thing we hear to be that {{infobox person}} is one of the the most widely used infobox templates and it's "specialized" because it's only for humans. WhatamIdoing (talk) 23:58, 27 March 2026 (UTC)

I think this is codifying the uncontroversial, which is fine but perhaps not progress. (I don't recall anyone ever removing a taxobox or a chembox from an article because it was "too short".) My recollection from the height of the infobox wars is that most of the conflict occurred in a pretty narrow band of the spectrum, typically biographies related to the humanities in liberal arts, where structured information could be presented about the subject in an infobox but did not do a very good job of expressing what was most important or essential about the subject.

Another way to express the conflict might be "Do we care more about quickly conveying the essence of the article's subject, or quickly looking up certain pieces of context that should exist for this type of article?" (phrasing inspired by that 2nd paragraph of WP:BALASP).

I might try to sum up the typical arguments on the point as follows. Anti: "Everything in the infobox is in the first 3 sentences of the lead, but the infobox contains only the trivial parts completely misses why this person's contributions were important." Pro: "Many people just want to look up a single popular fact about this person, and we should facilitate that, not try to nudge them into appreciating the person in their entirety." Choess (talk) 17:15, 28 March 2026 (UTC)

So true, but I don't think it will be practical.

Maybe it could form an introductory statement, rather than an individual criterion? It might sound something like "Editors choose to include or omit infoboxes for a variety of reasons. Taken together, these often amount to an editorial judgment about whether readers are more likely to be seeking a summary of the subject's essence (e.g., filmmaking), or wanting to look up a particular detail (e.g., the name of the film's director)".

I should put Wikipedia:Editorial judgment on my to-do list, or maybe one of you would start it (please do!). I think the idea that editors sometimes have to make a decision about what seems best for the article, using primarily common sense or their personal prior experience of editing Wikipedia, feels like a foreign concept to some of our more rigid, rule-bound editors. WhatamIdoing (talk) 17:59, 28 March 2026 (UTC)

Oh, I agree. I don't think we have consensus on which view is more correct, and even if we did, I don't think it would be stable. A decade or so ago, one of the arguments for infoboxes was their ability to produce structured data that could feed into Google summaries, etc. That's been eclipsed by the ability of LLMs to simply ingest huge quantities of prose. Should we lean away from infoboxes towards long-form prose that principally reaches the reader by training LLMs on it? Or should we lean towards them because no one has an attention span anymore? And what happens if in 2040, someone finds a good way to couple ontology to LLMs and structured data becomes important again?

I do very much like your formulation and I think it would be a good addition. Choess (talk) 22:39, 28 March 2026 (UTC)

I'm groping in the dark towards something slightly different from "widely used specialized template". I haven't found the right words for it. Snow Rise inspired me to think that some types of article are ones that benefit more from tables of key facts at the top right, but they're not just "STEM fields". They are subjects for which "uniform methods of documentation and classification exist" but that doesn't quite capture it. Articles about books are another example, where readers might just want author, publisher/editor, year, or ISBN, so having those key facts at the top right is important. People aren't the same. We can't predict so clearly what data readers might want about a person.—S Marshall T/C 08:55, 28 March 2026 (UTC)

If we say "tabulated statistics", then I think that will encourage people to think about certain sports. For chembox, we could say something like "containing identifiers or statistics that should not be repeated in the article", but I doubt that would help, and it would leave out infoboxes that you would like to include. WhatamIdoing (talk) 17:08, 28 March 2026 (UTC)

Yes. We want wording that discourages infoboxes about prices or supply chains, equivocates on infoboxes for statistics (sometimes OK sometimes not), and encourages... let me try this wording: infoboxes to summarize other key structured data where the article is part of a series.—S Marshall T/C 18:59, 28 March 2026 (UTC)

I think part of the puzzle is whether the information is difficult to express or to process in prose. Reading the contents of a taxobox or chembox as running text would be rather excruciating; the box has a higher density of useful information than the prose. The case is less compelling when infoboxes take compact prose and lower the information density by spreading it over many individual key-value pairs. WP:PROSELINE and WP:NOTSTATS sort of point at a similar general principle that we should try to present information using tools that are effective for conveying it. Choess (talk) 20:24, 28 March 2026 (UTC)

This is very insightful. WhatamIdoing (talk) 20:51, 28 March 2026 (UTC)

I don't think taxoboxes or chemboxes are actually infoboxes at all. They are not built on the code of {{Infobox}}, and they present information that isn't a summary of facts that appear elsewhere in the articles.

They could summarize facts that appear elsewhere, but that would basically mean reiniventing them. Taxonomic classification and chemical data could be presented in prose, but I think then we'd have people want to turn that prose into a standardized tabular format.

I don't know that it would be helpful to declare taxoboxes and chemboxes as "not infoboxes" for the purpose of discussing which articles should have infoboxes, but they are pretty different from other infoboxes, and there is zero controversy about including them in articles on relevant subjects. Plantdrew (talk) 16:46, 30 March 2026 (UTC)

@Plantdrew, the scientific infoboxes are indeed infoboxes, whether they use {{infobox}} or not. See Help:Infobox: An infobox is a fixed-format table usually added to the top right-hand corner of articles ... I appreciate that you are admirably trying characterize things to take them out of the controversy, but most of technical infoboxes are based on the infobox template or are named things like {{Infobox gene}}, so it won't help. It would be better to sort things out by topic area rather than by what modules they use. StarryGrandma (talk) 20:32, 30 March 2026 (UTC)

Taxoboxes are the original infobox. They came on the scene before anyone else thought of collecting key info together in a nice easy-to-find snapshot. --Redrose64 🌹 (talk) 18:37, 31 March 2026 (UTC)

I wouldn't describe Formic acid as being part of a series, but Chemistry has a sidebar at the top that declares it to be part of a series. WhatamIdoing (talk) 20:51, 28 March 2026 (UTC)

You're right, of course. "Part of a series" isn't good wording. Like you I find Choess's thoughts very helpful.—S Marshall T/C 21:46, 28 March 2026 (UTC)

I'm struggling with the wordsmithing too. Maybe [Infoboxes should be used...] "When the usual context for the article's subject is difficult to express in concise, readable prose (such as the many quantitative properties shown in chemboxes)". Improvements welcome. Choess (talk) 23:38, 28 March 2026 (UTC)

Of course formic acid is part of a series. Consider the blanket term carboxylic acid and the number of carbon atoms in the primary chain:

1. Formic acid
2. Acetic acid
3. Propionic acid
4. Butyric acid
5. Valeric acid

and so on, in theory ad infinitum, although you will reach a point where the substance is not only solid, but isn't very acidic either. --Redrose64 🌹 (talk) 23:48, 28 March 2026 (UTC)

Yes it is, but at the same time WAID is right to suggest that "part of a series" is poor wording because some people will invent their own definition of a series. Err... "The article is about something that has essential data or properties that are best out as a table or diagram"?—S Marshall T/C 07:26, 29 March 2026 (UTC)

That's better. Maybe not "diagram", though?

Whatever wording we come up with, I think that adding something like "such as {{chembox}} but not {{infobox person}}" will go a long way towards clarifying the intention. WhatamIdoing (talk) 18:31, 29 March 2026 (UTC)

Table or tree diagram?—S Marshall T/C 22:23, 29 March 2026 (UTC)

Do you have an example of a diagram in an infobox that you think is emblematic of the desired type? WhatamIdoing (talk) 00:07, 30 March 2026 (UTC)

I'm trying to capture the concept of... let's try, "a graphical representation of order, sequence, or hierarchy that helps the reader grasp the basics of the topic and is rendered in wikicode rather than a picture." So, Welsh language, with its indented bulleted list to show how it fits in a language taxonomy. Triceratops, with its graphical timeline. Hydrogen, with its inline periodic table. Tesseract, with its coxeter-dynkin diagram. Gulf War with its comparative tables showing the military strength of each belligerent. I could go on and on.

In fact, I think I will. Red deer with its graphical representation of conservation status. E major with its graphical representation of its key signature. Arabic script, with its table of glyphs. Pink, with its top bar that's pink to show you what pink is.

I'm stumped. I don't have wording that unifies these things. This could be a dead end in which case I apologize wholeheartedly.—S Marshall T/C 01:09, 30 March 2026 (UTC)

This is IMO a good discussion, even if we can't solve the problem today.

What about the route diagram in {{Infobox rail line}} (See, e.g., Red Line (BART) and click away from the map to the route diagram.) WhatamIdoing (talk) 02:47, 30 March 2026 (UTC)

Yes, that too! Um. Phrase it as a principle? "If a table of relevant data or a graphical representation of sequence, order, or hierarchy is likely to help at least some readers, and someone has written special wikicode to make that graphical representation render in an infobox, this often suggests it would be good to include an infobox in the article." Too long of course.—S Marshall T/C 08:20, 30 March 2026 (UTC)

• I would add 'Any article that has in image boxed in the lead, may be replaced with an Infobox, instead.' Images suggest concrete subjects. And the preference for one box over the other is really what, aesthetic? But an infobox can serve the boxed image function too, and if it has facts in it, tying it to the article fine, it provides different levels of summary per WP:summerize. And perhaps add a reminder, that not all fields need to be filled, and often they should not be. Alanscottwalker (talk) 13:08, 27 March 2026 (UTC)

  I don't think that would be popular. WhatamIdoing (talk) 17:12, 27 March 2026 (UTC)

IMHO, infoboxes shouldn't be included in bios, unless its politicians, religious leaders or sports figures. GoodDay (talk) 23:25, 28 March 2026 (UTC)

Do you think your view is popular? WhatamIdoing (talk) 00:24, 29 March 2026 (UTC)

@GoodDay, can you suggest (off the top of your head; I'm not asking for deep research) a category of BLPs for which infoboxes are relatively unpopular? If we were to write a sentence like "Infoboxes are popular for politicians and athletes, but not for ____ and ____", how would you fill in the blanks? WhatamIdoing (talk) 18:44, 3 April 2026 (UTC)

Is it mandatory that all bios have infoboxes? GoodDay (talk) 18:48, 3 April 2026 (UTC)

No. To avoid the impression that they are always a good idea, it would be helpful to be able to say when they're not usually wanted. I'm concerned that if we write something like "Biographies for people such as politicians and athletes usually get infoboxes", then some enthusiastic person will think "And religious leaders are just like politicians, and CEOs are just like athletes, and and and and" until it eventually becomes "Biographies usually get infoboxes". If we could put something like "usually yes for A and B, but often no for C and D", that could constrain the tendency towards creeping infoboxism. WhatamIdoing (talk) 18:55, 3 April 2026 (UTC)

• Points 5 and 6 should never be part of any guideline. They are not something that can be readily quantified and will only lead to extensive, fruitless and unsupported arguments. Who is to say which articles are likely to be visited by any ‘type’ of reader, let lone one with limited English or print disabilities. They are criteria that are unprovable (they are much like the argument of ‘what readers expect’) and will only be the locus of disagreements and strife. If there are to be hard criteria, they must be along the lines of SMART: specific, measurable, etc: something that cannot be disputed. I suggested something similar at a centralised discussion a while ago, but there we no takers. - SchroCat (talk) 22:50, 6 April 2026 (UTC)

  I don't think that we should have "hard criteria". I think we should have a list of things that editors actually do consider, and editors' judgment about whether dyslexic people are likely to read the article on Dyslexia, or that non-English speakers are likely to read articles on non-English-speaking people, is something that they do consider. Note also the absence of any "and if the answer is yes, then that means there should be an infobox". An editor is perfectly free to argue (e.g.,) that an infobox would be distracting to people with dyslexia and therefore should be omitted. WhatamIdoing (talk) 00:01, 7 April 2026 (UTC)

  Can you give me five examples of articles that would unarguably attract people from point 5 and five from point 6? - SchroCat (talk) 06:50, 7 April 2026 (UTC)

  Sure:

  We can realistically expect articles such as Muhammad, Gaza genocide, 2026 North Maluku earthquake, Angkor Wat, and COVID-19 pandemic in Japan to be disproportionately read by people with limited English proficiency. On the flip side, I would expect articles such as 2027 Jacksonville mayoral election to be read primarily by Americans and Mid Yorkshire Teaching NHS Trust primarily by British readers. Editors might disagree about whether that's a good reason to add an infobox, but they will not claim that readers interested in a Cambodian temple or an Arab religious figure will all be native English speakers.

  We can realistically expect articles such as Dyslexia, Diabetic retinopathy, Visual impairment, Learning disability, and Double vision to be disproportionately read by people who are having trouble reading. Again, editors might disagree about whether that's a good reason to add an infobox, but they are unlikely to claim that people living with these conditions will be uninterested in the articles on them. WhatamIdoing (talk) 18:06, 7 April 2026 (UTC)

  I can put in solid arguments against most on that list (and I did ask for “articles that would unarguably attract people”). This isn’t a measurable (or even sensible) criteria to have. If the criteria aren’t SMART then they will become the locus of disagreements, and it’s best these shouldn’t be included. - SchroCat (talk) 16:07, 8 April 2026 (UTC)

  If memory serves, about 30% of page views come from non-English-speaking countries. If an article attracted, say, 40% of page views from non-English-speaking countries, then that would be "disproportionate". Being higher than average doesn't necessarily mean a substantial majority. For example, Muhammad got 3.4 million page views during the last year. If that's "just" 40% people who don't read English easily, then that's more than 1.3 million readers who might find it easier to pick his birthplace out of the box than to read the second paragraph.

  We don't have SMART criteria right now. Yes, editors will sometimes disagree. But that's no different from what we have now. WhatamIdoing (talk) 18:32, 8 April 2026 (UTC)

  What’s the point of introducing criteria if it’s not going to resolve the problems (your opening statement makes it clear this is the aim). Why are a third of the suggested criteria too vague to be able to do that? It will only lead to general arguments on whether an article is more or less likely to have readers who don’t read English well - and all sorts of patronising and insulting arguments about are readers are bound to follow. Ditch the last two criteria and you’ll strengthen the whole thing. - SchroCat (talk) 05:04, 9 April 2026 (UTC)

  Any article of the English Wikipedia will also have foreign readers, because many inhabitants of the world have no Wikipedia in their native language, or if there is one perhaps missing an article about a specific subject. We can offer them a starting point. The other day I wrote an article about a composition, and was delighted to be offered this on the Finnish composer's website, easy to understand, easy to translate. --Gerda Arendt (talk) 09:52, 9 April 2026 (UTC)

  • What's the point in having criteria: We already have criteria, in the sense that these are things that editors actually do say in such discussions. I'm trying to document what editors already say, rather than make up new ones. The reason I'm trying to document them is that I see a lot of editors struggling to figure out how to move beyond "Infoboxes are generally good" towards "Considering this article in particular..." A list of questions might help people say "Oh, right, if we put an infobox in here, we are going to have a big fight over half the items in it, so let's just not".
  • I don't think that any of the listed items are vague. Do you mean something closer to "There's no tool I can click on, that says x% of page views are from non-English speaking countries, compared to y% average, so it's possible that one person will think this is a factor and another person will not"?

  WhatamIdoing (talk) 18:01, 9 April 2026 (UTC)

  Im obviously not going to persuade you on this, but you’re set on a path that will bring confusion and argument over points that are not the core reasons for including an IB. If there is no way of proving either of those two points, then they will just become the focus of conflict. You’re not listening to what I’m saying on this, so I’ll back out now and watch when these unmeasurable and dubious criteria become the focus of grief later on. - SchroCat (talk) 21:32, 9 April 2026 (UTC)

  What do you think the core reasons are for including/excluding an infobox? WhatamIdoing (talk) 23:03, 9 April 2026 (UTC)

  I agree with SchroCat that looking at how many foreign readers will come to a specific article is difficult. We could simply serve them by a concise infobox no matter how many how likely. --Gerda Arendt (talk) 06:55, 10 April 2026 (UTC)

  Anyone commenting here should know there has been an infobox war for over 15 years (Arbcom). Unverifiable criteria cannot do anything helpful. Team 1: "I like infoboxes and this article has a higher proportion of readers with limited English proficiency." Team 2: "I do not like infoboxes and anyone interested in this article obviously has reasonable English proficiency." Criteria which cannot be based on anything other than opinion are not helpful. Johnuniq (talk) 06:23, 10 April 2026 (UTC)

  I agree with not raising the question of proportion (see above), but I disagree with your opening. Most readers and editors in 2026 will never have met the so-called infobox wars, and I like that. In 2020, 2022 and 2023 I asked the candicates for arbitration if they still exist, and they basically said no. I stopped asking. When "battles" are so rare and so minor as Eric Satie back in March 2025, we better find a way forward without the load of that memory. --Gerda Arendt (talk) 06:55, 10 April 2026 (UTC)

  The battles are rare because of the Arbcom sanctions that I linked to. Any criteria need to at least have a hope of being discussed in a rational manner. An unverifiable quantity of readers not proficient in English (that's why we have simple:) is not helpful. Johnuniq (talk) 07:22, 10 April 2026 (UTC)

  There have been no sanctions that I remember, and I don't think fear of sanctions plays any role. For me, it's simply that I have better things to do. I offer one line of support in RfCs like Mozart and Satie, add infoboxes to the composers I encounter (Álvaro Cassuto, on the main page, and his teacher and his friend), and leave Britten alone. (There is a fresh question on that talk that I would have answered when I was younger.) --Gerda Arendt (talk) 08:52, 10 April 2026 (UTC)

  @Johnuniq, what do you think those two teams are saying right now? Is it just Team 1: "I like infoboxes" and Team 2: "I do not like infoboxes"?

  I think most ordinary editors are capable of making a guess about whether an article has a higher interest to a sub-group. If you're writing about Counterpoint, you can assume that the readers have more interest in and knowledge of music than the average reader, and that affects how you write the article. For example, even though we know that most people can't read music easily, we would expect that a higher proportion of the readers of that particular article can, so we would choose to include musical scores illustrating the various points. If we believed the opposite, we might not.

  While there might be editors who game such a thing (e.g., an editor who says that an obscure American politician will primarily be interesting to readers in Korea, or vice versa), I think that most editors would use some common sense.

  We could ask the community if they think they could do this. I think the question would sound something like this:

  • About 30% of the English Wikipedia's page views come from non-English-speaking countries. These page views are not randomly distributed (e.g., a Korean reader is more likely to read an article about Korea than an article about Scotland or Guyana or Botswana, and vice versa). Do you think you could often estimate, just from your general knowledge of a subject, whether an article might have a higher, lower, or about average proportion of readers with limited English proficiency?

  What do you think the response would be? I think editors would say that they can do this. WhatamIdoing (talk) 18:14, 10 April 2026 (UTC)

  Because of the history it is now impossible for the issue to be improved without significant damage. Some want their opponents to submit or be driven off. Others want a formula to remove argument. The problem is that developing featured articles is really difficult (really, really difficult). People who can and will do that are not necessarily ideal when it comes to putting up with uncomfortable situations. I think the community should acknowledge and welcome the fact that people are different. The practical solution is to halt the battles by keeping the two teams apart. The benefits from having a formula to require an infobox in contested articles is not worth the drawbacks. If it's not contested, there is no need to have a formula. Johnuniq (talk) 23:28, 10 April 2026 (UTC)

  I see your proposal for a sort of WP:IBXVAR, in which the preference of a designated editor is the tiebreaker. However, it's not responsive to my question.

  You indicated that you don't think editors can figure out whether an article is probably going to have more, less, or about the same proportion of English speakers as usual. My question for you: Do you think editors would say that they are capable of making such a determination, or do you think they would throw up their hands and say "Why, no, obviously nobody could even guess whether Mayoral elections in Smallville will be particularly interesting to people who live near Smallville vs in the rest of the world"? WhatamIdoing (talk) 23:41, 10 April 2026 (UTC)

  Our discussion is evidence of the problem. I'm talking about the underlying issue—a battle such that the mere mention of an opposing team member's name raises blood pressure. You seem to be wanting a debate about how many non-English speakers the English Wikipedia should make allowances for. That is not relevant. Suppose that article X has been developed by one of the teams, with no infobox. Then someone says that X is in fact of great interest to [insert suitable phrase here] and therefore the article must have an infobox. The result will either be yes or no. That will damage the community. If you want to get rid of one or both of the teams, please say so and work towards that. Otherwise, work on a way to keep them apart for a couple of years until natural attrition or mellowing or whatever makes the problem fade to history. No other outcome is possible because editors are human (at the moment). Johnuniq (talk) 03:12, 11 April 2026 (UTC)

  I'm interested in learning what factors should weigh in favor of or against including an infobox in a given article.

  Do you think that it's a bad idea to determine these factors at all? I can imagine that some editors could believe that the act of identifying some factors is a bad idea, because:

  • If a list of factors exists, then some editors might actually consider some or all of the factors rationally. And if that happens, then (these team members believe) that could result in more discussions will get the Wrong™ Answer in the end. Rather than get the Wrong™ Answer in a reasonably predictable and lower-drama way, it'd be best just not to have any list of factors for editors to weigh in the first place.
  • If there continues to be no list of factors, on the other hand, then we will continue to have the beautiful cacophony of editors saying whatever they want and claiming whatever they want about the invalidity of the other team's claims. The closers will still be struggling to figure out whether any of what the editors say is relevant, supported by the community, merely a team vote that's been decorated with a fig leaf's worth of a "logical" rationale, etc. It could (continue to) be more drama-prone and to produce somewhat inconsistent results, but the anti-infobox team would feel like they had a chance of the occasional surprise victory, and an organized list feels like it would logically close off such possibilities.

  This reminds me of a scene in Cheaper by the Dozen: The mother objects to corporal punishment of their children. If her husband spanks a child, she says "Not on the end of the spine!", and if he raps the top of their heads, she says "Not on the skull!" – but she never says her real objection, which would sound like "Please don't hit the children at all." So I ask directly: Are you mainly worried that making a list of factors at all could raise the prevalence of infoboxes (which is presently around 76% of all articles), or is your actual objection to this individual factor, but the other factors look okay to you? WhatamIdoing (talk) 04:30, 11 April 2026 (UTC)

Consider that different topic areas may need to use different criteria

Much of the discussion above is using technical infoboxes as examples though those areas don't lead to difficulties in choosing whether to have an infobox. We don't fight over when to use those infoboxes; we fight over what's included in them in them. Star doesn't have an infobox but Alpha Centauri has a very long one. What is appropriate for infoboxes in technical areas is often not appropriate elsewhere, and vice versa. These differing requirements are currently handled by giving technical infoboxes an implied exemption from the some of the existing criteria. Please leave these safely in their exemption. That section does not just cover the couple of examples listed there, but all those that provide a place for data tables.

Looking so deeply at these technical infoboxes is a distraction and seems to be derailing a discussion of WhatamIdoing's list of criteria. It would be worthwhile to get back to that - criteria aimed at people who like infoboxes to decide whether to add one. Consider it first for topic areas of general interest, then consider whether criteria are a bit different for specialized areas.

I especially like 3. Whether the subject of the article is a discrete thing. Every once in a while a new editor tries to do one for something like "physics concepts". But I don't think we should disallow creating new infoboxes (criteria 2). The discussion above mentioned series - things that can be linked as a possible criteria. StarryGrandma (talk) 06:31, 31 March 2026 (UTC)

I'd like to have a criteria that amounts to "We basically always have them on chemicals, species, individual stars, etc. but not people" because I think that captures something true about the choices the community makes. The discussion is long because we're struggling to find a way to describe these "technical" subjects. WhatamIdoing (talk) 17:16, 31 March 2026 (UTC)

Summing up

What do you all think of this? It would go after the first paragraph in MOS:INFOBOXUSE (the "The use of infoboxes is neither required nor prohibited for any article" bit).

Ultimately, editors must use their subjective editorial judgment to determine whether a given article would benefit from the inclusion of an infobox. This is often based on whether they believe the readers of that particular article are more likely to be seeking a summary of the subject's essence (e.g., filmmaking), or wanting to quickly look up a particular concrete detail (e.g., the name of the film's director), as well as whether adding an infobox would be feasible. In making that determination, editors consider various factors, such as (but not limited to) these:

• Is the page a stand-alone list or an article?
• Is the subject of the article a general concept (e.g., Fine art or Business) or a discrete instance (e.g., an individual painting or an individual company)?
• Are there uncontroversial, basic, relevant facts about the subject that can be communicated clearly, briefly, and accurately, or are the facts contested or in need of contextualization (e.g., sources disagree about a person's age, or a music album's genre is difficult to classify)?
• Is there a specialized infobox for this subject (e.g., {{chembox}}, {{starbox begin}}) that includes key technical facts, hierarchical information, or other standardized, field-specific structured data that is difficult or awkward to present in prose?
• Is this article disproportionately likely to be read by people with limited English proficiency or print disabilities (e.g., Dyslexia)?

While editors may find one factor compelling in a given case, no individual point always mandates the inclusion or exclusion of an infobox in any individual article.

WhatamIdoing (talk) 20:08, 3 April 2026 (UTC)

I think this covers when to use an infobox nicely. I have some comments on the wording. The second bullet point has reversed the order of criteria #3 above and now sounds like we want infoboxes for abstract concepts. "Or" can be ambiguous, it would be better to use "rather than". What about

• Is the subject of the article a discrete instance of something (e.g. an individual painting or an individual company) rather than a general concept (e.g., Fine art or Business)?

Similarly for the first bullet point. It is not clear whether the "or" means one topic or another for which one should use an infobox rather than "not use or use". StarryGrandma (talk) 02:43, 4 April 2026 (UTC)

Are you thinking that the answers should align? That is, that if the editor is looking at Mona Lisa, the answers should all be yes yes yes yes yes and if they're looking at List of algebraic geometry topics, the answers should all be no no no no no, rather than yes yes no no maybe? WhatamIdoing (talk) 02:47, 4 April 2026 (UTC)

My comment regarding size went on to discuss the particular issue of species and taxonomic hierarchy. Noting this exception, articles where the lead and/or the article are particularly small, they are unlikely to benefit from an additional level of summary. Cinderella157 (talk) 00:32, 5 April 2026 (UTC)

The species exception means about 15% of articles (and probably half of the shortest articles). Do you think there are other subject area exceptions? I suspect, for example, that athletes also get infoboxes by default. WhatamIdoing (talk) 04:22, 5 April 2026 (UTC)

I think we are in agreeance with the species exception and I am not aware of another that would be similar. What I am raising is an absence in the summary of size as a criterion. Cinderella157 (talk) 02:38, 6 April 2026 (UTC)

Do you think something like "How long is the article?"

I also wonder whether "editors consider various factors" should be "editors often consider various factors". Or maybe words like optionally and voluntarily could be sprinkled through the text. WhatamIdoing (talk) 00:15, 7 April 2026 (UTC)

Try: How lomg is the article? How long is the lead? Will the article benefit from an additional level of summary in the lead? To the question in the second part, I think that the language is reasonable and appropriate for the purpose. Cinderella157 (talk) 01:16, 7 April 2026 (UTC)

I'm not sure that "Will the article benefit from an additional level of summary" will produce a result that is different from "Do you like infoboxes in general?" WhatamIdoing (talk) 18:04, 9 April 2026 (UTC)

I think this is a good enough place to start that I would support addition of this verbiage as is, with the expectations of substantial augmentations as time goes on. I am particularly supportive of "Are there uncontroversial, basic, relevant facts about the subject that can be communicated clearly, briefly, and accurately, or are the facts contested or in need of contextualization (e.g., sources disagree about a person's age, or a music album's genre is difficult to classify)?" as I believe these are the circumstances which most concretely militate for avoiding an infobox, or omitting particular fields.

My observation of aggregate community consensus on the issue of infobox inclusion (both in terms of express opinions in previous discussions and implicit guidance through how contributors actually edit and !vote on individual articles) is that most editors favour an infobox for most substantive (non-list) articles, and I don't have strong objections to that generalized presumption in a majority of cases. However, that statistical concession made, infobox content must be strictly constrained where a field is unable to capture vital nuance on complicated or controversial aspects of a topic. That should be the first order presumption from which all other determinations follow. Probably the apparent general community presumption that some level of summary info can be presented in an infobox for most article subjects is reasonable, I suppose. But any rules of thumb that we put forward (whether as broad as a general presumption or as particularized as the ones we are considering adopting from the above thread) must not encourage presentation of any information in an infobox where said information would be substantially incomplete or misleading in that summary format. SnowRise ^{let's rap} 10:25, 6 April 2026 (UTC)

Yes, I think most editors are OK with infoboxes for most substantive (non-list) articles. The problems that occur are more what form that infobox takes, with MOS:INFOBOX routinely ignored, and bloated infoboxes common. So I concur we must not encourage presentation of any information in an infobox where said information would be substantially incomplete or misleading in that summary format and add that we should not be encouraging long infoboxes (which violate MOS:INFOBOX) or unnecessary decoration (violating MOS:INFOBOXFLAG and MOS:DECOR), etc. Bondegezou (talk) 10:38, 6 April 2026 (UTC)

I'm concerned that language around substantailly incomplete might be misunderstood as a requirement to fill in every possible blank in the infobox. WhatamIdoing (talk) 00:04, 7 April 2026 (UTC)

Well, to be clear, I was presenting that as the guiding principle, not the actual verbiage of any change to a guideline. I believe your existing wording adequately captures the sentiment. SnowRise ^{let's rap} 08:14, 7 April 2026 (UTC)

"Is this article disproportionately likely to be read by people with limited English proficiency or print disabilities (e.g., Dyslexia)?" This does not seem in keeping with most Wikipedia policy and guidance. We don't take this into account with other editing decisions usually, so why here? Bondegezou (talk) 10:34, 6 April 2026 (UTC)

At the simplest level, simply because we do.

Parts of the Wikipedia:Make technical articles understandable approach are known to be helpful for LEP readers. @Doc James spent literally years simplifying and sourcing the leads of medical articles for the sake of people who don't read English well (which includes a lot of native speakers). While someone might disagree with any particular edit, and other editors don't think it's important, I've never seen anyone say that it's actually wrong to consider the needs of the likely reader of a given article. In the case of Dyslexia specifically, I know that WPMED editors have considered what they can do to help readers with dyslexia. WhatamIdoing (talk) 00:09, 7 April 2026 (UTC)

As others have raised concerns about the last bit, I will say that it has been a bit of a concern for me too. Per INFOBOXPURPOSE, infoboxes are a simple summary of key facts. They should avoid prose or prose-like statements. They are a supplement to the lead and not a replacement. We aren't trying to write the article in the infobox. Making articles more accessible is about readability (avoiding complex sentences) and jargon (avoiding or at least explaining technical terms and/or terms that have a particular meaning in a particular context rather than a more general meaning). Wikipedia:Make technical articles understandable makes no mention of infoboxes. It is not clear to me how the last point in the summary (or the last two points in the OP) is relevant to whether we should have an infobox or not. While there are editors who do consider accessibility/literacy matters in writing articles, an awareness of this is probably a minority. Even in this minority, I would be surprised to see that having an infobox is a consideration with respect to accessibility/literacy (as opposed to how the contents of an infobox are presented). Cinderella157 (talk) 02:54, 7 April 2026 (UTC)

Here's the connection:

• I'm trying to make a list of things editors actually do consider.
• Sometimes at these discussions, editors say things like "Infoboxes are helpful for people who don't read very well, so we should have one in this article".
• Therefore, "editors consider various factors, such as" whether people read (easily, or in English).

It sounds like you think they shouldn't consider this, rather than thinking that they don't. WhatamIdoing (talk) 05:05, 7 April 2026 (UTC)

What I am saying is, is this really a consideration in choosing to have an infobox. It is one thing for an editor to opine: "Infoboxes are helpful for people who don't read very well, so we should have one in this article". It is another thing for this opinion to have any substance (do they? what is the evidence?) and in what circumstances. Cinderella157 (talk) 02:46, 8 April 2026 (UTC)

Here's is part of the evidence: Wikipedia editors whose first language is not English have directly told us, in discussions about whether articles should have infoboxes, that they find them helpful. I'm not going to link to any of these, because I don't want to embarrass any individuals, but if you take the time to search (e.g.,) the village pumps, you'll find some examples of this.

But we're talking about different things. You're saying "Well, they're just opining that. They don't have enough objective evidence that their mere personal opinion is correct."

I'm saying "This is something editors actually do consider. It doesn't make any difference if it's based on evidence. Certain editors routinely object to infoboxes for no reason other than their personal, subjective, non-evidence-based opinion that infoboxes are inappropriate, or inappropriate for certain subjects. This unfortunate ArbCom case is not happening because the named editor was presenting 'evidence' in infobox debates. Talk:Wolfgang Amadeus Mozart/Archive 16#Mozart Infobox RFC was not decided by anyone presenting 'evidence'. People made unsubstantiated, evidence-free assertions of their opinions, and the RFC was successfully decided on that basis ("successfully", because we no longer have arguments over whether to have an infobox; instead, we have arguments over what to include in the infobox). If editors were routinely flipping a coin to make these decisions, then 'Whether a coin toss comes up heads or tails' would belong in this list." WhatamIdoing (talk) 17:38, 8 April 2026 (UTC)

I know Doc James well and support his work. However, that's part of making all of Wikipedia accessible. That seems to me different to identifying an "article disproportionately likely to be read by people with limited English proficiency or print disabilities". We should try to make all articles more accessible (and most of the ways of doing that are not to do with infoboxes, as per Cinderellla157); and obviously individual editors choose to focus their work in different places. However, I don't think it should be a formal criterion for whether an article gets an infobox. Consider the logical corollary of your suggestion: I don't think anyone should be arguing that a particular article is probably being read mainly by those with good English, therefore it shouldn't have an infobox. Bondegezou (talk) 07:23, 7 April 2026 (UTC)

@Bondegezou, how could we change this text so that editors don't think it's a list of "formal criteria"?

My goal is something closer to MOS:REFERENCES, in which we provide a purely factual statement that says ==References== is the most common choice, and in which we carefully do not say editors "should" or "must" use ==References==.

I'm trying to document different points that editors actually mention when they're debating whether to have an infobox in a given article. I'm not trying to say "You should consider these, and if the answer is ____, then you should support including an infobox." WhatamIdoing (talk) 18:11, 7 April 2026 (UTC)

If you include a section here, along the lines you lay out above, people will tend to interpret it as formal criteria, as "should" rules. If you don't want to do that, I would suggest you don't add any text! Write a standalone essay or something. Bondegezou (talk) 07:50, 8 April 2026 (UTC)

Also, I've got no problem with someone "arguing that a particular article is probably being read mainly by those with good English, therefore it shouldn't have an infobox". I haven't personally seen such a comment, but it wouldn't concern me if this was a reason someone gave. It meets the ArbCom requirement of being specific to the article in question (as opposed to, e.g., "all articles should/shouldn't have an infobox" or "I like/dislike infoboxes"). I could imagine people using it as a tiebreaker if they're genuinely uncertain. WhatamIdoing (talk) 17:48, 8 April 2026 (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.

INFONAT-related dispute

Hi, there's an ongoing dispute over how to format |citizenship= in Audrey Hepburn's article. Could you guys please share your thoughts at Talk:Audrey Hepburn#MOS:INFONAT? Thanks in advance, Thedarkknightli (talk) 16:44, 28 March 2026 (UTC)

Dispute over Milla Jovovich's infobox

Hi, there's an ongoing dispute over how to format the infobox of Milla Jovovich's article. Could you guys please share your thoughts at Talk:Milla Jovovich#Infobox formatting? Thanks in advance, Thedarkknightli (talk) 08:11, 31 March 2026 (UTC)

Hello again, the discussion has been continuing at Talk:Milla Jovovich#Birth place and nationality. Thanks, Thedarkknightli (talk) 00:41, 2 May 2026 (UTC)

Default infobox spot

Is it just me or did all of the infoboxes move down the page a little: Tom Brady, Bob Atha, LeBron James. They used to be above the lead or at least even with the first sentence, now the infobox starts below the first sentence. Thoughts? Thanks, ~WikiOriginal-9~ (talk) 12:49, 2 April 2026 (UTC)

I've noticed for a while (months, years?) that the infobox's title seems to be slightly below the lead sentence. Though Tom Brady looks fine for me (perhaps because there's the maintenance tag in the lead?) —Bagumba (talk) 07:08, 3 April 2026 (UTC)

Really? I only noticed it in the past few days, lol. Are you using Vector legacy 2010 as your skin. That's what I use. ~WikiOriginal-9~ (talk) 12:45, 3 April 2026 (UTC)

Yes, 2010 too. But I also see it logged out. —Bagumba (talk) 06:12, 5 April 2026 (UTC)

Dispute over Melania Trump's infobox

Hi, there's an ongoing dispute over how to format |birth_place= in Melania Trump's article. Could you guys please share your thoughts at Talk:Melania Trump#Linking SR Solvenia in infobox? Thanks in advance, Thedarkknightli (talk) 08:42, 10 April 2026 (UTC)

Infobox use policy question

I came across mass changes to page infoboxes that I question, and would like to check here on policy.

~2026-36481-5 (talk · contribs) has been rapidly removing large numbers of "Infobox needed" and "Photograph needed" maintenance tags from talk pages. In some cases an infobox was present, so they are OK edits. In many cases there was no photo, so the edit seems to be dubious; no talk concensus per MOS:INFOBOXUSE. In some other cases the editor used the edit description "Short article" which I do not see as a justification. (In many others there was no edit description.)

I have tagged on their talk page twice, no explanation from them as yet. Are these removals some policy, or should I bounce this to WP:ANI; checking all these edits as some seem to be inappropriate is a lot of work for volunteers. Ldm1954 (talk) 11:26, 13 April 2026 (UTC)

@Ldm1954, there was probably no discussion about adding those in the first place, so it's just as fair to remove them. (I thought there was a bot that processed the "infobox needed" ones, but maybe not any longer.)

Cinderella157 was saying above that article length is a criterion that some editors have used in deciding whether to include an infobox. In that case, "Short article" might be a justification (according to some editors). WhatamIdoing (talk) 21:23, 13 April 2026 (UTC)

RFC on infobox criteria

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.

---

Since 2013, ArbCom has asked the community to create a list of factors that editors could weigh when deciding whether to include or exclude an infobox in a given article.

Shall we add this proposed list of factors to Wikipedia:Manual of Style/Infoboxes#Using infoboxes in articles (after the paragraph that begins The use of infoboxes is neither required nor prohibited for any article)? WhatamIdoing (talk) 21:55, 13 April 2026 (UTC)

Proposed addition:

Editors must use their subjective editorial judgment to determine whether a given article would benefit from the inclusion of an infobox. Broadly speaking, their choice is often based on whether they believe the readers of that particular article are more likely to be seeking a summary of the subject's essence (e.g., Filmmaking) or wanting to quickly look up a particular concrete detail (e.g., the name of the film's director), as well as whether adding an infobox would be feasible. In making that determination, editors often consider various factors, such as (but not limited to) these:

• Is the page a stand-alone list or an article?
• Is the subject of the article a general concept (e.g., Fine art or Business) or a discrete instance (e.g., an individual painting or an individual company)?
• Are there uncontroversial, basic, relevant facts about the subject that can be communicated clearly, briefly, and accurately, or are the facts contested or in need of contextualization (e.g., sources disagree about a person's age, or a music album's genre is difficult to classify)?
• Is there a specialized infobox for this subject (e.g., {{chembox}}, {{starbox begin}}) that includes key technical facts, hierarchical information, or other standardized, field-specific structured data that is difficult or awkward to present in prose?
• Is this article disproportionately likely to be read by people with limited English proficiency or print disabilities (e.g., Dyslexia)?
• How long is the article?

Using this list is optional. Use it only if you want to, and then use it with common sense and good editorial judgment. While editors may find one factor compelling in a given case, no individual point always mandates the inclusion or exclusion of an infobox in any individual article. All decisions about article content, including decisions about including and excluding infoboxes, are made by consensus.

Discussion

Quick FAQ:

If we adopt this, can we change it later?

Yes.

Will editors have to use this? Can closers ignore anyone who doesn't use this?

No and no.

Does this mean that if an article is a list that it can't have an infobox, or that if the subject is an individual company, then it has to have one?

No.

Some of these factors seem unimportant or irrelevant to me.

Some factors are more important than others. Use whatever you think is helpful and relevant for a given article, and ignore the rest.

Some of these are just subjective. Editors have different opinions!

Editors always have different opinions, and adopting this (or not) won't change that. Use your own judgment when formulating your own recommendation. When talking to other editors, remember that the goal is to decide whether to have an infobox. The goal is not to decide whether 300 words is "long enough" or "too short", or whether dyslexic people read articles about dyslexia. If you both agree that an infobox should be included or excluded, it doesn't matter if you disagree over the reasons why that should happen.

What if I go through this list, and all my answers lean towards one side, but I really think that the opposite answer is the best for the article?

Then use your editorial judgment and common sense to do what you believe is best for the article.

WhatamIdoing (talk) 17:57, 14 April 2026 (UTC)

• I was summoned by bot; I won't opine on the merits given that I'm an Arb, but I do have some procedural wonders. I obviously wasn't around in 2013, but am I to understand that in the intervening thirteen years, that no RfC about an infobox criteria PAG has ever been run? CaptainEek ^{Edits Ho Cap'n!}⚓ 05:09, 15 April 2026 (UTC)
  • CaptainEek, If there was any proposal made at that time, or in response to the ArbCom request in 2018, then it wasn't successful, and it didn't happen via RFC on this talk page. This search will show you all the RFCs in the archives for this talk page. WhatamIdoing (talk) 05:25, 15 April 2026 (UTC)

  Wikipedia talk:Manual of Style/Infoboxes/Archive 21. ~~ AirshipJungleman29 (talk) 17:12, 15 April 2026 (UTC)

  That 2024 RFC was an attempt to set a default in favor of infoboxes, rather than trying to identify factors that should be weighed. WhatamIdoing (talk) 17:35, 15 April 2026 (UTC)

  Not a distinction relevant to Eek’s question. ~~ AirshipJungleman29 (talk) 17:47, 15 April 2026 (UTC)

• How exactly is one supposed to "use" this list? It's a list, not a flowchart or checklist or anything like that. If e.g. the first line read "Is the page a stand-alone list, where infoboxes are less common, or an article?" then that would be better, but as it stands we have two sentences about using a list that can't be used. I'd delete the final paragraph as excessively duplicative. Also, adding an infobox is always feasible. ~~ AirshipJungleman29 (talk) 16:43, 15 April 2026 (UTC)

  @AirshipJungleman29, one is supposed to use it however one likes, including not using it at all if one doesn't like using it. It is true that the obvious answers are not given, but I think they're obvious enough that we don't need to give them to even moderately experienced editors.

  I don't think that adding an infobox is always feasible, because of two main problems:

  • We don't have suitable infobox templates for some general concepts. There's no good infobox template for Fine art, Business, or Mathematics.
  • Too little information may be known. For example, during the high-school notability awards, I asked an editor about whether a particular 19th-century California high school was notable. He insisted that if it ever issued a high school diploma, then the answer was a firm yes. Here's all the information you could put in an infobox for that high school: approximate (brief) dates of operation, and general location (think "northwest part of the county"). That's it. Even whether it had a name is unknown. An infobox isn't feasible in this instance because there's nothing to put in the box.

  WhatamIdoing (talk) 17:34, 15 April 2026 (UTC)

  That’s not a question of adding an infobox, that’s adding one with suitable information. As the distinction is central to most of the disputes, it seems good to get that right, however pedantic. ~~ AirshipJungleman29 (talk) 17:36, 15 April 2026 (UTC)

  Which is why factor #3 is "Are there uncontroversial, basic, relevant facts about the subject that can be communicated clearly, briefly, and accurately?" Editors don't generally add an infobox if the result would be empty. WhatamIdoing (talk) 17:38, 15 April 2026 (UTC)

  I don’t see how factor #3 is relevant to the feasibility of adding an infobox? ~~ AirshipJungleman29 (talk) 17:46, 15 April 2026 (UTC)

  "Adding an infobox" in this case means "adding an infobox that contains some content". Sure, you could put an empty infobox template in any article – just type {{infobox}} – but it'd be invisible. If you want to add an infobox that shows on the page, then you have to put some parameters and values into the infobox template. And doing that (i.e., without violating any policy) means that you have to have verifiable facts about the subject that are suitable for putting into the infobox. You cannot put in |name=Nobody knows if it had a name. Editors will not agree to put in |enrollment=Unknown or |website=None, because it was the 19th century just so you can fill in some parameters to make the box visible.

  This is why I suggest feasibility as a standard. It's not just "Could you technically do this, at a rules-lawyering standard?" but "Would this really be functional in ordinary, everyday practice?" WhatamIdoing (talk) 17:54, 15 April 2026 (UTC)

  I look forward to your amendment of the RfC statement in light of this comment. ~~ AirshipJungleman29 (talk) 18:34, 15 April 2026 (UTC)

  Here's is the entire text of the RFC statement:

  "Since 2013, ArbCom has asked the community to create a list of factors that editors could weigh when deciding whether to include or exclude an infobox in a given article.

  Shall we add this proposed list of factors to Wikipedia:Manual of Style/Infoboxes#Using infoboxes in articles (after the paragraph that begins The use of infoboxes is neither required nor prohibited for any article)?"

  Which parts of it do you think should be amended, and why? WhatamIdoing (talk) 18:37, 15 April 2026 (UTC)

  I think the controversial nature of some facts is better served by indicating this uncertainty in the infoboxes rather then leaving them blank. — Charles Stewart (talk) 13:13, 16 April 2026 (UTC)

I generally think the guidelines are good in that they support discussion. I’d like to see lack of consensus displayed more prominently. — Charles Stewart (talk) 13:05, 16 April 2026 (UTC)

@Chalst, can you explain what you mean about "lack of consensus"? Is this related to your comment about including a note in an infobox when a fact is uncertain (e.g., |birthdate=disputed)? WhatamIdoing (talk) 22:45, 16 April 2026 (UTC)

Yes, exactly. Showing uncertainty about the evidence, where it exists, benefits such summaries. — Charles Stewart (talk) 16:29, 20 April 2026 (UTC)

While the list looks good, the question format is too confusing. Say an editor looks at the question Is the page a stand-alone list or an article? and says 'It is an article.' How does that help them at all? It doesn't. It doesn't give any information as to which one (article or stand-alone list) deserves an infobox or not. I suggest rewording all of the questions, as well as the sentence Broadly speaking, their choice is often based on whether they believe the readers of that particular article are more likely to be seeking a summary of the subject's essence (e.g., Filmmaking) or wanting to quickly look up a particular concrete detail (e.g., the name of the film's director), as well as whether adding an infobox would be feasible to say 'If it is X, use an infobox; if Y, don't use an infobox.' Cherrytxrt 📧 22:07, 18 April 2026 (UTC)

Are there any that you find difficult to interpret? WhatamIdoing (talk) 23:18, 18 April 2026 (UTC)

I agree with this complaint, and rather than trying to argue about which answers are the hardest to guess, I'd recommend simply flipping the guideline to a statement format. There are additional "what is" vs. "what should be" complications, so I would say something like this:

---

• Stand-alone list articles tend not to have infoboxes. Content is already generally presented in HTML table or list format, and a small amount of prose does the summarizing (e.g. noting how many entities are on the list or defining its scope).
• Infoboxes tend to exist on articles where the information needed to populate at least a minimal infobox is available.

Standardized infoboxes (often supported by dedicated templates) are typically either desirable or not desirable for all instances of a class or subclass of entity. For example, a biography is generally expected to have an infobox; depending on the subject's occupation, it might use {{Infobox academic}} or {{Infobox sportsperson}}. Deciding whether or not a given class of entity should have infoboxes can happen in a number of ways:

• Bottom up: Editors experiment with adding infoboxes to a few articles to get a feel for what type of information can be displayed and in what format, and to probe consensus as to whether they are helpful. Over time a clear pattern may emerge where infoboxes are either standard practice or rejected for this class of entity. If there is persistent disagreement across articles covering different instances of the same class of entity, another method of consensus-building should be pursued.
• Top down from a topic-specific talk page: A WikiProject or Manual of Style page might host an informal discussion or RFC as to whether a class of entity should have infoboxes, or how they should be scoped and formatted. This might take place before any have been created (in which case a prototype might be presented) or might propose deleting infoboxes that already exist.
• As part of the Templates for discussion process: A template that defines a certain specialized type of infobox could be nominated for deletion. This might result in merging the template with a parent type for consistency or lower maintenance, or it might remove infoboxes from all articles covering entities of this type. Relevant WikiProjects should be notified when a discussion of this type is happening.

When deciding if infoboxes are needed and how they should be scoped and formatted, consider the typical purposes:

• Infoboxes are used to concisely communicate important facts; prose is used to explain complicated facts in need of context.
• Infoboxes bring immediate attention to high-level context, often in graphical form, e.g. a geographical map, position in a relevant timeline, or situation in a classification scheme.
• Infoboxes highlight identifying information, such as a picture of a person, a diagram of a molecule, the written form of letters in an alphabet, or alternate names of the subject.
• Infoboxes make it easy to quickly find common reference information that would be awkward to find in prose, such as the specific heat capacity of a substance, or the elevation of the population of a city. Sometimes important information is repeated in prose but put in the infobox for quick lookup - for example, the birthplace of a person.
• Some infoboxes expose data in a standardized (often machine-readable) format for Wikidata or other applications.

---

I did not include two points:

• I object to different treatment for certain articles based on whether they are likely to be read by people with specific disabilities. All articles should be accessible to as many people as feasible, period. I often use a text-to-speech system to listen to articles instead of reading them. I by no means limit myself to articles that might be of interest to people who are blind or have low vision. It is also unclear whether infoboxes are helpful or a hindrance to people with dyslexia or low English proficiency. Is it easier to understand information in cluttered grammatical sentences or out-of-context labels? I think the answer may be different for different people.
• It's unclear to me that the guidance on concepts is wise. Some concepts are clearly instances of a general class, with infoboxable attributes. For example, disciplines of science can note the parent field, when they arose, important historical people, foundational works, top applications, and main theories or ideas. Or maybe those are complicated concepts that should have prose context. Maybe business doesn't fall into a nice class of entities that are infoboxable, but I would feel comfortable letting people decide how to create useful classes for infobox purposes, rather than giving the same advice for all abstract ideas.

I would agree with dropping the "Using this list is optional" paragraph. It's confusing and I think the point that needs to be made about that is already made in a better way by {{MoS guideline}} at the top of the page. -- Beland (talk) 23:35, 20 April 2026 (UTC)

• This matter should start with some evidence. It's my impression that infoboxes are almost universal for some topics. For example, I was recently looking at Marian Cygan. This has {{infobox football biography}} and that's used on 217,000 pages with the similar {{infobox gridiron football biography}} being used on another 39,000 pages.

Digging deeper I find that there's a List of infoboxes with usage numbers but they seem to need refreshing (see Module:Transclusion count/data/I for more live stats). I also notice that the MOS page already says As of 2026, approximately 77% of Wikipedia articles (excluding redirects and disambiguation pages, and including lists) contain an infobox. Given this preponderance, we should make it fairly clear that infoboxes are normal rather than exceptional for most topics. The text proposed by the OP seems too verbose and wishy-washy in dancing around this.

Andrew🐉(talk) 11:18, 19 April 2026 (UTC)

Wikipedia talk:Manual of Style/Infoboxes/Archive 21#RfC: Change INFOBOXUSE to recommend the use of infoboxes attempted that two years ago, and failed. WhatamIdoing (talk) 17:01, 19 April 2026 (UTC)

That RfC was closed as no consensus. Be that as it may, what I'm pointing to is a fact which already appears in the guideline. We should present such facts about prevalence more clearly to the readers of this huge page. They can then draw the obvious conclusion that infoboxes are now the norm. Andrew🐉(talk) 17:30, 20 April 2026 (UTC)

Survey (2)

• Support adopting this. I hope that it will help editors organize their thoughts, and therefore that it will help closers of RFCs. IMO the first two explain most of our inclusion and exclusion choices. WhatamIdoing (talk) 22:40, 14 April 2026 (UTC)
• BADRFC RfC statement is neither neutral nor brief. See WP:RFCNEUTRAL. Polygnotus (talk) 04:05, 15 April 2026 (UTC)

  Poly, the RFC statement, as shown, e.g., at Wikipedia:Requests for comment/Wikipedia style and naming, is just two sentences long, with a total of 62 words. It definitely the requirements for WP:RFCBRIEF and WP:RFCNEUTRAL. WhatamIdoing (talk) 05:13, 15 April 2026 (UTC)

  Fixed. Polygnotus (talk) 05:16, 15 April 2026 (UTC)

  Thank you for fixing the section heading, though I believe that's technically unnecessary these days, as the software automatically appends a _2 or _3 to non-unique section headings.

  I wish you had something to say on the substance of the proposal. There's really no point in posting if you have nothing to say except that you don't want to read the proposed addition to this guideline because it's almost 300 words long. WhatamIdoing (talk) 05:29, 15 April 2026 (UTC)

  @WhatamIdoing that you don't want to read the proposed addition to this guideline because it's almost 300 words long. That is not the point I am making. And I love reading. The point I am making is that the inclusion of a Questions and discussion section that starts with a FAQ makes the RfC unfair and biased. Especially when the FAQ is so clearly intended to persuade those who would oppose to not do that.

  We'll have to update WP:RFCBRIEF and WP:RFCNEUTRAL so that people can no longer use this loophole. Polygnotus (talk) 05:35, 15 April 2026 (UTC)

  These are all questions that were asked and answered in the prior discussion. It is "correctly explaining" rather than "clearly intended to persuade". I'm saving people the bother of asking the predictable questions, and, incidentally, documenting the intentions for anyone who might be reading this years later, e.g., because they wonder whether the word "optional" was intended or just accidentally stuck in there. Also, perhaps you'd move this discussion thread up to the section for discussions, if you don't plan to post a survey response. Meta discussions on whether the RFC is properly presented are not normally counted as ==Survey== responses. WhatamIdoing (talk) 05:44, 15 April 2026 (UTC)

  No, and I also don't agree with moving comments left by others. This is not a vote, it is a discussion.

  It is "correctly explaining" rather than "clearly intended to persuade". Maybe, but isn't the difference moot? A non-neutral RfC is non-neutral, even if I am right and am only explaining to people that I am right and they should agree with me.

  BADRFC is a "proper" survey response by the consensus of the community, and RfC starters do not have the special power to be able to forbid people discussing a topic. If you disagree with me, explain why I am wrong. That way we can form a stronger consensus and it benefits me and others.

  I think it would have to be a very weak support. In an ideal world it may have been better to just insert the content, and then if reverted start a discussion and if that doesn't work and 3O doesn't work then start an RfC. I am not too sure if adding a list of possible factors in someones personal decision making is super helpful considering people have very strong opinions about infoboxes which, in some cases and in my opinion, are based more on feelings e.g. "this is how an encyclopedia should look" vs "this ugly infobox is defacing my article" rather than on the considerations listed. If I understand correctly Arbcom's recommendation was a well-publicized community discussion be held to address whether to adopt a policy or guideline addressing what factors should weigh in favor of or against including an infobox in a given article. and this doesn't do that. I think they are talking about something that can be used to actually resolve disputes. The proposal is all optional and non-committal, and doesn't mention relative weight or even how a consideration like How long is the article? should influence the decision. On the other hand I understand that forcing either side to accept that they lost even a millimeter of ground would lead to a bunch of unnecessary drama. So I hope this is a step in the right direction, however small. Polygnotus (talk) 06:03, 15 April 2026 (UTC)

  I've lost track of how many times I've explained this point specifically to you over the last couple of years, but here's another try: A non-neutral RfC is non-neutral is irrelevant. Unimportant. The wrong question. WP:RFCNEUTRAL only applies to the RFC "question" (aka "statement"). In this case, the parts of the RFC that are covered by RFCNEUTRAL are 62 words long and meet all the requirements.

  The whole RFC does not have to be neutral. In fact, if the whole RFC were neutral from start to finish, we'd never reach a decision. Once we get past the initial RFC question/statement, it's time all editors to stop being neutral and start advocating for what they each believe is best for Wikipedia.

  The person starting the RFC is not limited in their ability to participate as an equal editor in the RFC. Anybody can ask questions in the ==Questions and discussion== section; anybody can answer questions there, too. That includes me, too. WhatamIdoing (talk) 17:21, 15 April 2026 (UTC)

  I think that a lot of the infobox dispute is not just about infoboxes but also ownership of articles and the fact that infoboxes are damn ugly.

  Maybe the WMF has a designer who can make some mockups of infoboxes that look less bad? That could be collapsed and expanded at will, and remembered that setting per user and even for people who are logged out.

  It would be nice to be able to exclude certain areas from the dispute by saying: "every article about a species/chemical element/musical artist gets an infobox" and then there is no need to debate each individual article. If that is systematically done using something like the Dewey Decimal System to cover every article, starting with the categories that have caused most disputes in the past, that might actually fix this longterm.

  It would also be smart to just get rid of certain infobox fields which convey no useful information to the reader and only lead to pointless debates (e.g. musical genres). Polygnotus (talk) 06:48, 15 April 2026 (UTC)

  Ideology for political parties and figures is another good one to delete. Katzrockso (talk) 12:00, 15 April 2026 (UTC)

  Exactly. Barely anyone knows the difference between Progressivism and Liberal Centrism or Shoegaze and Dream Pop. And it causes a gigantic amount of overhead to deal with such nonsense that does not help the readers. Polygnotus (talk) 12:08, 15 April 2026 (UTC)

  The ideology field also often leads to bloated infoboxes that are the subject of ridicule or memeification (which is often why they become so bloated in the first place). Katzrockso (talk) 22:34, 16 April 2026 (UTC)

  These are questions to talk up on the talk pages of specific infobox templates. -- Beland (talk) 23:46, 20 April 2026 (UTC)

  What's the objection here? That the FAQ section doesn't have a section header that says "Discussion" above it? That WhatamIdoing wrote something lengthy? The first is nonsubstantive and the second is common in RfCs Katzrockso (talk) 11:58, 15 April 2026 (UTC)

  This objection does not make sense to me. Whoever is the first to speak in the discussion - where neutrality is neither required nor expected - will inevitably bias all later discussion, as will the second person to speak, etc. That is the nature of deliberative discourse; this is not meant to be a blind poll without reading the comments of anyone else before coming to an ill-informed position.

  The proposer is always the first to speak, and when they cast their !vote they are nearly always arguing in favor of the proposal. It would be silly to ask people to propose something and then refrain from giving reasons why. -- Beland (talk) 23:43, 20 April 2026 (UTC)

• Support this or any other attempt to work towards an infobox-related guideline, accepting that the guideline can be edited over time.
  Also, please will an uninvolved sysop consider offering some support and direction to Polygnotus over his conduct here and on WT:RFC.—S Marshall T/C 07:38, 15 April 2026 (UTC)
• Support adopting this, making people think. --Gerda Arendt (talk) 09:55, 15 April 2026 (UTC)
• Support without the final paragraph per below, weak oppose otherwise. ~~ AirshipJungleman29 (talk) 16:47, 15 April 2026 (UTC)
• Support on the basis that this provides some points to go over, but isn't restrictive. My only test for whether to add an infobox has generally been "can I find enough to put in one", but I have created a few bare infoboxes (with the thought that they will be expanded on) and this has made me reconsider the practice, even if I tend to feel like the article doesn't look quite right without one. ASUKITE 23:33, 16 April 2026 (UTC)
• Oppose WP:GUIDES states:

  "Guidelines are sets of best practices supported by consensus. Editors should attempt to follow guidelines, though they are best treated with common sense, and occasional exceptions may apply."

  By definition, an editor need not attempt to follow a guideline that is entirely optional. This should be published as an essay instead. voorts (talk/contributions) 04:04, 17 April 2026 (UTC)
• oppose as written. this is completely unclear. let's take the last point as an example: How long is the article? so should an infobox be included if the article is long or not? how long is "long"? ltbdl (activate) 08:49, 17 April 2026 (UTC)
• Oppose This comes across as an essay, and a not a very helpful one. It is not suitable for inclusion here. Bondegezou (talk) 13:03, 17 April 2026 (UTC)
• Support adopting this. In my view, this is an accurate summation of many of the most common factors that are considered when people debate whether a given article should have an infobox, and including it would amend a longstanding gap in our guidance. I don't think the non-prescriptive nature of the text is disqualifying; to my eye, it's analogous to the policy at WP:CRITERIA, which outlines the different article titling criteria but deliberately avoids giving direct instructions on how to weigh them against each other. ModernDayTrilobite (talk • contribs) 15:19, 17 April 2026 (UTC)

  The AT criteria aren't "optional". voorts (talk/contributions) 15:57, 17 April 2026 (UTC)

  Not in so many words, but in practice, kind of? These should be seen as goals, not as rules...It may be necessary to favor one or more of these goals over the others. This is done by consensus. And then it gives an example of preferring the page title United Kingdom over a more WP:PRECISE name. One way to describe that situation could be that compliance with PRECISE is "optional", meaning editors "opted" not to follow it. WhatamIdoing (talk) 16:45, 17 April 2026 (UTC)

  That's not how AT works in RM discussions. Arguments are generally grounded in one or more of the criteria. You can't just choose to ignore all of them and say "I prefer this title over ones that are complaint with the criteria." By contrast, this proposal would let editors do exactly that. voorts (talk/contributions) 17:00, 17 April 2026 (UTC)

  It sounds like we agree that any individual AT criteria could be considered optional. WhatamIdoing (talk) 17:17, 17 April 2026 (UTC)

  No, we don't. That's not what the word "optional" means. voorts (talk/contributions) 17:18, 17 April 2026 (UTC)

  Editors actually did opt not to follow PRECISE when titling United Kingdom. I'd say that makes it optional, under certain circumstances. Do you think that PRECISE should be described instead as mandatory?

  For these criteria, my hope is that they will be less evaluated on an optional/mandatory spectrum, and instead that words like "helpful" or "practical" or "popular" would someday be used to describe them. WhatamIdoing (talk) 17:26, 17 April 2026 (UTC)

  If that's the case, then publish this as an essay and hope it gets adopted one day. Putting a completely "optional" process in the MOS will just confuse the issue. If it's compeltely optional, I can choose to reflexively reject any argument based on these criteria, no matter how rational, and substitute my own in a discussion. That is not how guidelines should operate. voorts (talk/contributions) 17:30, 17 April 2026 (UTC)

  The word optional appears in more than a quarter of the MOS pages. That suggests that this is how guidelines operate. WhatamIdoing (talk) 17:49, 17 April 2026 (UTC)

  You should take a look at how that word is used in the guidelines. None of the use cases are "here's a set of criteria for determining article content. all of this is optional by the way." voorts (talk/contributions) 18:14, 17 April 2026 (UTC)

  Most of the MOS doesn't provide information about determining content in the first place (the MOS is mostly about how to present X, rather than whether to include X), but WP:MEDORDER does make suggestions for content, and those lists are optional suggestions. WhatamIdoing (talk) 18:25, 17 April 2026 (UTC)

  What sections can be included in an article is fundamentally different than a set of criteria designed to guide editors to consensus over a particular article element. voorts (talk/contributions) 18:28, 17 April 2026 (UTC)

  Since I don't seem to be able to find anything that matches your requirements, can you give me some examples of "a set of criteria designed to guide editors to consensus over a particular article element" in the MOS now? WhatamIdoing (talk) 18:32, 17 April 2026 (UTC)

  Nothing I can think of off the top of my head. voorts (talk/contributions) 18:42, 17 April 2026 (UTC)

  So if I can't find any, and you aren't aware of any, then there is nothing to compare this against. Whether it's optional or mandatory or somewhere in between, it would still be unique, and we can't really look to prior examples in the MOS, because AFAWCT there aren't any prior examples in the MOS. WhatamIdoing (talk) 18:46, 17 April 2026 (UTC)

  @Voorts, if this proposal instead said nothing about it being optional, would you support this instead? I'd kind of been hoping that this discussion might identify some substantive objections to individual factors, or some missing ones – more like "Nobody should consider whether it's a list article, because lists should have infoboxes at the same rate as other pages" (identifiable list pages are about 10–15% as likely to have an infobox as ordinary articles) or "There should be a criteria favoring FAs at the time of promotion". Instead, the opposition sounds like "I don't like advice being optional", and I don't know whether a proposal next month that says "This will be mandatory" would satisfy you, or if you don't want any factors to be agreed upon at all. WhatamIdoing (talk) 18:31, 17 April 2026 (UTC)

  This is my only objection for now. I'm neutral otherwise. voorts (talk/contributions) 18:38, 17 April 2026 (UTC)

  I think that if we try it out as an optional process for, say, a year (because infobox disputes don't come up every day of the week), then we'd have a stronger basis for making a firm recommendation. WhatamIdoing (talk) 18:58, 17 April 2026 (UTC)

  That's why I think this should be an essay. Let people try it for a year, and if it works, promote it to guideline. voorts (talk/contributions) 19:26, 17 April 2026 (UTC)

• Oppose, mostly per voorts. Mike Christie (talk - contribs - library) 15:36, 17 April 2026 (UTC)
• Support. this sounds quite sound, although i will admit there may be some room for improvement. User "Oreocooke" (speak of the sun and it shines) 18:14, 17 April 2026 (UTC)
• Oppose but would support with a few tweaks. I think that we should be explicit that these when the article meets one or more of the criteria, there is community consensus that the article might benefit from an inbox, or at the very least indicate that they are positive things. Just listing common discussion points without indicating if it makes it more or less likely to have an ibox isn't in keeping with the majority of guidelines. It can be taken as read that the MOS isn't mandatory if there are good reasons to do things differently. I would also prefer that the final version handles the article length and English proficiency issues differently. I agree that these should be considered, but unlike the other points I think that if they were the only ones that applied (i.e. that there wasnt suitable information to include), they should be ignored. Scribolt (talk) 16:08, 18 April 2026 (UTC)
• Oppose. A completely optional guideline is fundamentally impotent; this is why we have essays to cover editorial suggestions. As written, this is not a guideline, as it is explicitly not something editors should attempt to follow (from GUIDES). By definition, if a proposal does not align with the purposes of guidelines, we should not be elevating it to that status. While progressivism is built into our policies and guidelines (from PGCHANGE), this cannot be allowed to be a reason to be unduly lax over the original text of a proposal. That said, I commend the proposer for attempting to bring clarity to this complex and contentious topic: the optionality of this addition is my only major issue, and I would likely support this RfC if the wording was tightened. UpTheOctave! • 8^va? 20:19, 19 April 2026 (UTC)
• Oppose because this is not a guideline, it's an essay describing things the proposer thinks should be considered. I generally agree with the list of things to considered, but per UpTheOctave a list of things to consider is not a guideline. I would support a guideline along the lines Scribiolt suggests - a list of characteristics the more of which an article has the stronger the recommendation for an infobox is, and conversely a list of characteristics the more of which an article has stronger the recommendation against an infobox. Particularly articles about clearly defineable concrete topics with objective and/or undisputed facts should generally have infoboxes (e.g. bridges, individual humans who verifiably exist(ed)), articles about nebulous concepts or about which there are very few things clearly known (e.g. broad emotions, individuals who may or may not be mythical). Thryduulf (talk) 19:31, 20 April 2026 (UTC)
• Oppose per Thryduulf. While I appreciate the work went into this, I’d like to see us take another crack at including more directive guidance in the MOS for people, places and things. Dw31415 (talk) 00:26, 21 April 2026 (UTC)
• Oppose per Voorts. I like the suggestions given in this proposal, and I can't immediately think of any changes I'd like to make, aside from decapitalising Dyslexia. However, the MOS shouldn't be a place for advisory elements; it should be restricted to items that ought always to be obeyed, aside from exceptional circumstances. If something in the MOS shouldn't almost-always be obeyed, the MOS shouldn't have that element at all. Nyttend (talk) 08:47, 21 April 2026 (UTC)

• Support with one crucial change. The paragraph about this guideline being optional should be removed. All guidelines and policies are default optional on Wikipedia by virtue of WP:IAR, thus there is no need to specify that this one, in particular, is also optional.

I would also like to appeal to other editors in this RFC which oppose this change arguing that it could be better worded or that the format is not the correct one, and tell them that they should consider putting aside these problems as we really really need a sitewide consensus on, at least a rough idea, of when to use infoboxes.

The current article-by-article consensus status quo just results in some very opposed small communitys effectively preventing infoboxes in their articles of interest (see the situation where musicians generally have an infobox (as all biographies do...) but there is "consensus" that classical composers shouldn't have them. I know that I'm beating a dead horse here but nobody has yet explained to me in a convincing manner why the articles for Freddie Mercury and Gustav Mahler differ so much in terms of infobox requirements. For a more in depth argument of my point, see the talk page of the Mahler article. Yes I am 100% for infoboxes in case it wasn't clear yet.) Milo8505 _(talk) 23:10, 20 April 2026 (UTC)

• Oppose I see this text as the draft of a possible essay. Since it is explicit about most of it being optional, it is not sensible to add it to the MOS, although a link to it would be OK. The essay needs to evolve into some form of decision tree so that it could become a guideline — GhostInTheMachine ^{talk to me} 11:47, 21 April 2026 (UTC)
• Oppose, due to the final paragraph. A guideline that says it is optional is an essay, and will only contribute to WP:CREEP. BilledMammal (talk) 05:37, 22 April 2026 (UTC)
• Oppose. If this is supposed to be a thinking aid, it should be in an essay, not a guideline. I have not been involved in any infobox-inclusion controversies, but if these wars of pedantry are invulnerable to consensus as is they certainly won't be brought to a lasting peace by "hey, here's some vague suggestions". Wh1pla5h99 (talk) 14:02, 22 April 2026 (UTC)
• Oppose – Nothing much to add. Just well-intended concrete proposal that's not gonna work well, especially due to instruction creeping. Also, every article is subjective, so I bet the proposal would be largely ignored per WP:GUIDES. George Ho (talk) 05:11, 23 April 2026 (UTC)
• Comment Arbcom suggested "a well-publicized community discussion be held to address whether to adopt a policy or guideline...". (Emphasis added by me on "whether".) It did not request that such a list be created. William Avery (talk) 10:35, 24 April 2026 (UTC)

  "Editors must use their subjective editorial judgment to determine whether a given article would benefit from the inclusion of an infobox. Broadly speaking,"

  This is bad writing. "Editors must use their editorial judgment" is the kind of sentence that would get red-penned in freshmen English.

  Our policy pages are too verbose. When the second sentence begins, "Broadly speaking..." it has veered from giving clear guidance for editors into rumination. Manuals of style are concise. We should strive to write policy pages that are focused. Trumpetrep (talk) 00:27, 30 April 2026 (UTC)

  Is it bad writing or weak guidance from ArbCom? I think it’s the latter. Clear writing failed in the RfC two years ago. The originator is working to move this forward through a narrow sliver so I think we owe them more than a “bad writing” admonition. Dw31415 (talk) 01:32, 30 April 2026 (UTC)

  Our policy pages are too garrulous. If our guidance were clearer, we could reduce the frequent and passionate recurrence of the Infobox dispute. Anyone who takes on this particular snarl of red tape has my gratitude, as well as my 2¢. Trumpetrep (talk) 19:53, 30 April 2026 (UTC)

• Oppose as written Given the state of discussions around infoboxes some guidance would be useful, but this is ambiguous and confusing. The current wording says these things can optionally (which is an odd way of stating it, maybe "here are some points to consider" instead) be considered but not why they should be or what relevance they have. I'm guessing those more embedded in such discussions understand the relevance, but it would be helpful for others if it was made more explicit. What difference does it being a stand alone article instead of a list make, why does reading proficiency or disability make a difference and why isn't that already an ACCESSIBILITY issue, how does length matter, etc? Such a list is going to be especially confusing to new editors who have zero context for the issue. -- LCU ActivelyDisinterested «@» °∆t° 15:48, 4 May 2026 (UTC)
• Oppose per Voorts, Ltbdl, Bondegezou, UpTheOctave!, Thryduulf, Nyttend. Would mostly prefer to keep MOS as clear, normative guidance (per Nyttend). - Asdfjrjjj (talk) 23:27, 8 May 2026 (UTC)

  @WhatamIdoing, would you please share your thoughts on withdrawing this? I ask because I’m interested in us taking another crack at guidance to include infoboxes. Dw31415 (talk) 00:02, 9 May 2026 (UTC)

  I think that "guidance to include" is unfortunate phrasing, as it shows a bias towards inclusion.

  I don't think that this should be withdrawn per se. I think that the community has provided valuable feedback. For example, they don't want to be told "Consider this: How long is the article?" They instead prefer something that sounds like "Don't put infoboxes in very short articles. Do put infoboxes in medium-sized and longer articles". I don't mind if we WP:RFCEND this early, but I believe that a closing summary would prove helpful. WhatamIdoing (talk) 00:50, 9 May 2026 (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.

Preparing for a second RFC on factors to consider

As WhatamIdoing has written, the text proposed in the RFC above is apparently not accepted, and the community would, if anything, prefer something that says more clearly in which direction a given factor should weigh. I made an alternative proposal above, which I'm not sure is all that great. It's copied below. @Dw31415: You said you wanted to draft an alternative proposal as well? I'd be interested to read it and see how if it differs from the below...

• Stand-alone list articles tend not to have infoboxes. Content is already generally presented in HTML table or list format, and a small amount of prose does the summarizing (e.g. noting how many entities are on the list or defining its scope).
• Infoboxes tend to exist on articles where the information needed to populate at least a minimal infobox is available.

Standardized infoboxes (often supported by dedicated templates) are typically either desirable or not desirable for all instances of a class or subclass of entity. For example, a biography is generally expected to have an infobox; depending on the subject's occupation, it might use {{Infobox academic}} or {{Infobox sportsperson}}. Deciding whether or not a given class of entity should have infoboxes can happen in a number of ways:

• Bottom up: Editors experiment with adding infoboxes to a few articles to get a feel for what type of information can be displayed and in what format, and to probe consensus as to whether they are helpful. Over time a clear pattern may emerge where infoboxes are either standard practice or rejected for this class of entity. If there is persistent disagreement across articles covering different instances of the same class of entity, another method of consensus-building should be pursued.
• Top down from a topic-specific talk page: A WikiProject or Manual of Style page might host an informal discussion or RFC as to whether a class of entity should have infoboxes, or how they should be scoped and formatted. This might take place before any have been created (in which case a prototype might be presented) or might propose deleting infoboxes that already exist.
• As part of the Templates for discussion process: A template that defines a certain specialized type of infobox could be nominated for deletion. This might result in merging the template with a parent type for consistency or lower maintenance, or it might remove infoboxes from all articles covering entities of this type. Relevant WikiProjects should be notified when a discussion of this type is happening.

When deciding if infoboxes are needed and how they should be scoped and formatted, consider the typical purposes:

• Infoboxes are used to concisely communicate important facts; prose is used to explain complicated facts in need of context.
• Infoboxes bring immediate attention to high-level context, often in graphical form, e.g. a geographical map, position in a relevant timeline, or situation in a classification scheme.
• Infoboxes highlight identifying information, such as a picture of a person, a diagram of a molecule, the written form of letters in an alphabet, or alternate names of the subject.
• Infoboxes make it easy to quickly find common reference information that would be awkward to find in prose, such as the specific heat capacity of a substance, or the elevation of the population of a city. Sometimes important information is repeated in prose but put in the infobox for quick lookup - for example, the birthplace of a person.
• Some infoboxes expose data in a standardized (often machine-readable) format for Wikidata or other applications.

-- Beland (talk) 01:32, 9 May 2026 (UTC)

WikiProjects cannot set rules, and given the past WP:OWNERSHIP problems in this area, I do not think we should encourage anything like "might host an informal discussion". "Hosting an informal discussion" is exactly what resulted in the creation of the Wikipedia:Advice page guideline, the example in WP:LOCALCON, Wikipedia talk:WikiProject Composers/Infoboxes RfC, all the other Wikipedia talk:WikiProject Composers/Infobox debates, and probably (at least by my count) two of the three infobox-related ArbCom cases. I don't think that any "top down" exclusion rules have ever worked for us, and "top down" inclusion rules have primarily been successful only in certain specialized areas (e.g., {{taxobox}} and {{chembox}}). WhatamIdoing (talk) 02:32, 9 May 2026 (UTC)

The "When deciding" sentences aren't parallel, and they need to be (or else people will say 'yes' to both, and thus be stuck). For example, "Infoboxes are used to concisely communicate important facts; prose is used to explain complicated facts in need of context" should say something like "Infoboxes are used to concisely communicate important, simple, uncontroversial facts that need no further explanation; prose is used to explain complex facts in need of context." That said, I feel from the RFC above that editors are looking for something a bit more hard-line – more "Do, or do not" than "Infoboxes have this characteristic or advantage". WhatamIdoing (talk) 02:32, 9 May 2026 (UTC)

OK, here's an attempt at being more "hard-line":

• Complex facts that need context should be explained in prose, not an infobox. This makes some fields not appropriate for infoboxes. Sometimes a piece of information is usually simple, with rare exceptions for complex cases. In these cases, the infobox value for an exceptional article can link to the prose with a terse phrase. Example: putting "(disputed)" for birth_place and linking to a section explaining the dispute.
• If available, an infobox should include graphics that identify the subject (e.g. picture of a person, diagram of molecular structure, the written form of letters in an alphabet).
• If applicable, an infobox should include graphics that provide high-level context, such as a geographical map, position in a relevant timeline, or situation in a classification scheme.
• Common (within reason) and uncomplicated reference information should be added to infoboxes (e.g. the specific heat capacity of a substance, the elevation and population of a city). It is OK to repeat information in prose (e.g. the birthplace of a person) or not (e.g. list of alternate names for a chemical) depending on importance and flow.
• Information that is exposed in machine-readable format by templates (whether for Wikidata or web crawlers) is usually placed in the infobox. There are exceptions (e.g. if a secondary location is discussed in prose and {{coord}} is used inline).

-- Beland (talk) 03:11, 9 May 2026 (UTC)

I just noticed MOS:INFOBOXPURPOSE and this is feeling somewhat redundant. Perhaps this advice could be merged into that section, to the degree that it's different. -- Beland (talk) 06:46, 9 May 2026 (UTC)

I think you're right about it being more INFOBOXPURPOSE than INFOBOXUSE. WhatamIdoing (talk) 23:36, 9 May 2026 (UTC)

OK, how about this instead:

"Top down from a community talk page: A discussion might be held as to whether a class of entity should have infoboxes, or how they should be scoped and formatted. This might take place before any have been created (in which case a prototype might be presented) or might propose deleting infoboxes that already exist. This type of discussion might happen on a WikiProject talk page and become a non-binding advice page. Binding guidelines generally become part of the Manual of Style and in this case should be added to or linked from Wikipedia:Manual of Style/Infoboxes.

? -- Beland (talk) 02:53, 9 May 2026 (UTC)

Do you think this is describing current community practice? I don't. If it is, you should be able to give us several links to recent discussions. WhatamIdoing (talk) 03:06, 9 May 2026 (UTC)

I don't think I've participated in any discussions on infoboxes, so if you're asking about them specifically, I don't know. In general... many WikiProjects have content guidelines where folks have sat down and thought "what should be in every article about X and in what order"? I suppose these discussions usually don't happen in a vacuum; probably there were a few articles about X, possibly with conflicting patterns, which informed them. But that's more top-down than editors organically just copying what they saw on other articles. I suppose some top-down-ness is enforced by template structure and documentation, though it's possible to use a generic template like {{infobox}} which doesn't dictate the fields available for an article on a given topic.

I'm thinking about the discussions I've participated in, and they are mostly style questions that arise because different articles use different styles, and someone wants to impose some sort of conformity or get consensus for non-conformity. (As seen onWikipedia talk:Manual of Style and friends.) Those discussions happen bottom-up (95% of articles do it one way and we're just documenting an existing practice and fixing remaining errors) and top-down (the decision is made once, in a central place). Personally, I have gotten useful rules from WikiProject discussions regarding Chinese, Korean, and Japanese typographical issues, and items from Wikipedia:WikiProject Astronomy/Style advice § Units that got discussed and promoted to guidelines on MOS:UNITS. -- Beland (talk) 03:40, 9 May 2026 (UTC)

WikiProjects do not have "content guidelines". They have "essays", which often (but not always) contain useful information from people who have some experience in the subject area.

Infoboxes mostly don't happen the same way, as they tend to have organic growth (Can we fork infobox-scientist to make an infobox-astronomer template? Can we add another parameter to infobox-company?) instead of creation from first principles. WhatamIdoing (talk) 23:40, 9 May 2026 (UTC)

I'm not sure what this implies about what text you would want to see. -- Beland (talk) 01:34, 10 May 2026 (UTC)

It means that I don't think we should talk about top-down creation of templates (because it doesn't really happen any more) and that whatever we say about infoboxes, we should never say anything about WikiProjects having any sort of decision-making role. WhatamIdoing (talk) 21:04, 10 May 2026 (UTC)

My inclination is to do a repeat of the 2024 RfC but to narrow the criteria for default-infobox-inclusion to increase the chances for consensus. I don’t feel strongly about it though and would want several others supporting that concept before working out the details. I’m also happy to wait to seee if the second-take at criteria gains traction. Dw31415 (talk) 04:23, 9 May 2026 (UTC)

Aha, the pointer to the old RFC is very helpful in figuring out what's controversial and what isn't. How about cutting the philosophy about how consensus is built, and just jump into documenting known consensuses for various classes of entity. Combining that with a "hard line" version of attribute-based advice, here's a draft:

If an infobox exists, it should use the most-specific template under Category:Infobox templates.

The following articles should not get infoboxes:

• Stand-alone list articles
• Not enough is known about the subject and the infobox would be awkwardly short

Infoboxes are a good fit for some subjects and a bad fit for other subjects; for some subjects their usefulness is heterogenous. The below list summarizes whether there is a known explicit consensus (of any consensus level with link to discussion or TfD outcome) or implicit consensus (longstanding accepted practice) to use infoboxes by default for each subject type. "Optional" means there is an affirmative consensus to determine on an article-by-article basis, and "no consensus" means there is an unresolved dispute or unclear general practice.

• Biographies - depends on subtype
  • Composers - optional - Wikipedia:Manual of Style/Infoboxes § Biographical infoboxes
  • Sportspeople - yes - implicit
  • Political office holders - yes - implicit
  • Scientists - yes - implicit
  • Military people - yes - implicit
• Groups of people
  • Ethnic groups - yes - implicit
  • Sports teams and leagues - yes - implicit
  • Religions - yes - implicit
  • Companies - yes - implicit
  • Schools and universities - yes - implicit
  • Political parties - yes - implicit
• Geography
  • Geographical places (non-fictional, on any planet or moon) - yes - implicit
  • Natural features - yes - implicit
• Buildings and structures - yes - implicit
• Transport
  • Ships - yes - implicit
  • Stations - yes - implicit
  • Rail lines, services, networks - yes - implicit
  • Roads - yes - implicit
  • Automobiles - yes - implicit
  • Aircraft - yes - implicit
  • Spaceflight (specific voyage) - yes - implicit
• Events - depends on subtype
  • Sports competitions - yes - implicit
• STEM - depends on subtype
  • Astronomical object - yes - implicit
  • Chemical elements and compounds - yes - implicit
  • Numbers - yes - implicit
  • Mineral - yes - implicit
  • Earthquake - yes - implicit
  • Biology
    • Biological classifications - yes - implicit (see {{taxobox}})
    • Anatomical features - yes - implicit
    • Drugs - yes - implicit
    • Genes - yes - implicit
  • Computing
    • Unicode blocks - yes - implicit
    • Top-level domains - yes - implicit
• Arts and culture
  • Awards - yes - implicit
  • Books - yes - implicit
  • Films and television shows and episodes - yes - implicit
  • Journals and newspapers - yes - implicit
  • Musical albums and songs - yes - implicit
  • Musical artists - yes - implicit
  • Radio and television stations - yes - implicit
• Social science
  • Languages and writing systems - yes - implicit
  • Military conflicts, wars, and battles - ?
• Fields of study - no - implicit (e.g. math, philosophy)
• Abstract ideas - no - implicit (e.g. time)

An overriding article-specific consensus or application of criteria can be persistently documented near the top of the wikitext with a comment like <!-- Infobox added per (link to discussion) --> or <!-- No infobox due to lack of known facts -->. This carries no more weight than the level of consensus being documented.

This list is getting long, though it might be possible to make it shorter by getting consensus for broader classes. Maybe that's not feasible; another possibility is to say:

If an infobox template exists for an entity type and is used on at least 100 articles (see Wikipedia:List of infoboxes), there is an implicit consensus to apply the infobox to all entities of that type (subject to per-article exceptions). This can be overriden by an explicit, type-specific consensus to make infoboxes optional or prohibited by default (in which case the template should be deleted). Known exceptions and consensuses for prohibition are documented here:

• Biographies - depends on the specific type of person
  • Composers - optional - Wikipedia:Manual of Style/Infoboxes § Biographical infoboxes
• Fields of study - no - implicit (e.g. math, philosophy)
• Abstract ideas - no - implicit (e.g. time)

-- Beland (talk) 08:50, 9 May 2026 (UTC)

Wikipedia:Request a query/Archive 6#Prevalence of infoboxes in articles found that more than 10,000 stand-alone list articles had an infobox. (List detection is difficult programmatically, but that's the best guess we have so far.) You've listed them as a "shouldn't", when community practice is "uncommon but permitted". Do you think that's a good idea? WhatamIdoing (talk) 23:44, 9 May 2026 (UTC)

It's unclear if "uncommon" means "sometimes permitted" or "sometimes incorrectly added". Can you give some examples of standalone lists with infoboxes so we can spot-check and evaluate them? All I see are counts on the linked pages. -- Beland (talk) 04:11, 10 May 2026 (UTC)

"Uncommon" means "seen on a small proportion of articles". It says nothing about the correctness or incorrectness of what's there; it merely acknowledges that, in reality, it is there. WhatamIdoing (talk) 21:11, 10 May 2026 (UTC)

@Beland, here are some examples:

• List of Marvel Cinematic Universe films
• List of sultans of the Ottoman Empire
• Ballon d'Or
• Academy Award for Best Actor
• List of European Cup and UEFA Champions League finals

Try this search if you'd like to see other examples. A quick estimate suggests that a third of Wikipedia:Featured lists have an infobox. WhatamIdoing (talk) 21:17, 10 May 2026 (UTC)

Those examples are extremely helpful. Those infoboxes don't look like errors to me. Certainly we could choose to have a different style, and put sum-up stats in a prose and not an infobox, and leave obvious things to readers to find on their own. For example, they can plainly see which entities are first and last on the list, whereas it's more work to count the total number of entities and the number of each subtype. Infobox seems like a relatively tidy format, though, and often a skim of that obviates the need to read the prose intro. I'd also say a third is more than "uncommon", but we don't necessarily have to characterize the frequency (or we could just give a number).

After looking at featured lists with infoboxes, those without did seem a bit disorganized, or at least I don't see a pattern where lists of types W and X do have an infobox and those of types Y and Z do not. I could easily see infoboxes being added to most lists, with per-list consensus exceptions. So I'd drop the "Stand-alone list articles should not get infoboxes" directive.

Let me instead propose merging something like the following into MOS:INFOBOXPURPOSE:

Infoboxes on stand-alone list articles (including articles that are mostly composed of a list even if they don't have "List" in the title) generally work well when they:

• Appear on lists with enough introductory prose (required by MOS:SALLEAD) to allow them to appear to the right of the lead.
• Give statistics about the list that would otherwise require work on the reader's part (like total counts, counts of subtypes, or the most frequent winner).
• For a topic "List of X", give attributes of "X". This is useful when "X" redirects to "List of X" and X is something repeated over time, such as an award or political office.
• Give an overview of an attribute that all items on the list have, and how they have changed over time. For example, a movie franchise has director X for films 1-4 and director Y for films 5-8.
• Have a visual element that:
  • Shows representative examples from the list (such as individual officeholders).
  • Shows an identifying entity that applies to all items on the list (such as a logo, coat of arms, or physical manifestation of an award or championship trophy).
  • Gives graphical context as to how all the items on the list relate to each other (such as a geographical map, family tree, or timeline).

Beland (talk) 06:41, 11 May 2026 (UTC)

The idea behind "Appear on lists with enough introductory prose (required by MOS:SALLEAD) to allow them to appear to the right of the lead" (i.e., that infoboxes should not hang down into the first section because it's ugly or throws off the layout on "my" screen) is not one that I've seen much enthusiasm for in recent discussions. WhatamIdoing (talk) 19:20, 11 May 2026 (UTC)

Yeah, I'm not sure why I thought that would be a good idea. Infoboxes look fine even with a short intro. Maybe I was thinking of stubs? I hit "random article" and landed on Georgios Kapnopoulos after a few tries, and it seems fine to have useful information in the infobox there even if it's not in prose yet. -- Beland (talk) 17:45, 12 May 2026 (UTC)

It used to be a common enough argument. I haven't seen it (organically) for a while now, though. WhatamIdoing (talk) 18:05, 12 May 2026 (UTC)

Composers are where the majority of infobox disputes arise, so I don't think listing them as 'optional' would be helpful. As an uninvolved observer of the recent RFC, I think the most viable alternative is to keep the list of reasons for infobox usage/non-usage the same as originally proposed, add bullet points under those reasons which explain their connection to infobox usage/non-usage, and make the language more firm and less optional.

My personal preference would be for something like the 2024 RFC:

The use of infoboxes is recommended for articles on specific biological classifications, chemical elements and compounds, conflicts, people, settlements, and similar topics with basic and relevant facts. Nevertheless, an infobox can be excluded from such articles if there is a clear consensus that one would be inappropriate for the article.

Which would (hopefully) turn disputes from "should an infobox be added to an article", which is often about infoboxes in general instead of the particular article, into "is an infobox inappropriate for this particular article?" But I'm not sure if my proposal can escape the 'no consensus' that the 2024 RFC got. Shogeneral (talk) 05:38, 10 May 2026 (UTC)

Would your preference then be to overturn the Composers RFC, or to simply not mention it in the guidelines on this page? -- Beland (talk) 07:00, 10 May 2026 (UTC)

I wouldn't want composers to be mentioned in this portion of the MOS without at least guidance that prevents future disputes from being headcounts about infoboxes in general. Perhaps adding a line in the original proposal that states "does the subject of the article have a related stand-alone list (e.g. a writer's bibliography, an actor's filmography, or a composer's list of works)?", as those are most frequently linked in liberal arts infoboxes. Shogeneral (talk) 07:18, 10 May 2026 (UTC)

Is "the" Composers RFC the 2010 RFC at Wikipedia talk:WikiProject Composers/Infoboxes RfC#Closing remarks? Or a different one? What specific details about this would actually be overturned? Obviously, it's not "Wikipedia:WikiProject Composers has been rewritten" or "support for Template:Infobox classical composer to be created" WhatamIdoing (talk) 21:22, 10 May 2026 (UTC)

"Composers are where the majority of infobox disputes arise", true, and how many? One RfC in 2025 (Erik Satie), none in 2026. Hundreds of composers have an infobox without any discussion. Those discussed usually got one in the end, because it's what the community wants (see Beethoven 2015, Mozart 2023). Would I participate in a discussion such as Debussy knowing that the principal writer thinks it's clutter? --Gerda Arendt (talk) 07:14, 10 May 2026 (UTC)

I support this path for a next RfC and was going to propose it before Beland proposed this interesting idea. I’m curious to see which gets more support. Maybe let’s start a separate topic to flesh out. Dw31415 (talk) 13:53, 10 May 2026 (UTC)

I've started a separate topic Wikipedia_talk:Manual_of_Style/Infoboxes#Alternative_second_RFC_proposal Shogeneral (talk) 17:47, 10 May 2026 (UTC)

Alternative second RFC proposal

As stated in the above topic, my personal preference for a guideline on infoboxes is something like the 2024 RfC:

The use of infoboxes is recommended for articles on specific biological classifications, chemical elements and compounds, events, people, settlements, and similar topics with basic and relevant facts. Nevertheless, an infobox can be excluded from such articles if there is a clear consensus that one would be inappropriate for the article.

Which would (hopefully) turn disputes from "should an infobox be added to an article", which is often about infoboxes in general instead of the particular article, into "is an infobox inappropriate for this particular article?" However, I'm worried that this proposal won't escape the 'no consensus' that the 2024 RFC got. What are others' thoughts?Shogeneral (talk) 17:45, 10 May 2026 (UTC)

On the general approach, I don't think this helps RFC closers, who are under pressure to move beyond vote counting.

I'd suggest not requiring a "clear" consensus, as that sets a higher standard than necessary.

I think it would be easier to get a statement adopted that says "The use of infoboxes is popular in articles on...". That's what we did years ago at MOS:APPENDIX when editors were disagreeing over the correct section headings for refs. While I'm sure that change was not the sole cause, those discussions basically evaporated afterwards, and articles have largely standardized on the most popular option. WhatamIdoing (talk) 21:28, 10 May 2026 (UTC)

The idea is that RFC closers could analyze arguments based on if an infobox is inappropriate for a specific article instead of infoboxes in general. e.g. an "oppose, as few facts are definitively known about the subjects life" will be weighted more than "oppose, as infoboxes are clutter".

The "clear consensus" wording was inspired by a comment in the 2024 RFC which pointed out that no RFC in recent memory has had a consensus against an infobox, its just either consensus to add or no consensus. I'm fine with removing "clear" and changing "recommended" to "popular" though. Shogeneral (talk) 21:54, 10 May 2026 (UTC)

I think that the RFC closers would like something more like "An infobox is likely to be inappropriate if there are few facts definitively known about the subject", instead of "This article is about a person, so it should have an infobox". WhatamIdoing (talk) 00:02, 11 May 2026 (UTC)

To answer WhatamIdoing's question in the above thread, yes, Wikipedia talk:WikiProject Composers/Infoboxes RfC#Closing remarks from 2010 says that infoboxes are what I'd summarize as "optional" on composer bios. This was a change from "should not contain an infobox". Likewise, Wikipedia talk:WikiProject Classical music#RfC: amending project guidelines on infoboxes made infoboxes for classical music biographies what I'd summarize as "optional". This was a change from "often counterproductive". I would say that if infoboxes are uniformly "recommended" for biographies in general, this conflicts with them being officially "neither required nor prohibited" for classical music and composer biographies. "Recommended" is not the same as "required", but I read "neither required nor prohibited" as "entirely agnostic" as opposed to "recommended" which I read as "there should be a good article-specific reason not to have it".

If the proposal is instead changed to "popular" instead of "recommended", that feels less contradictory, but it also seems weird to document frequency of use but not document what binding decisions have been made for specific topics by RFCs, especially if that information would tend to lean in opposite directions. -- Beland (talk) 07:00, 11 May 2026 (UTC)

I tried to build some empathy for the position on Composers by visiting Claude Debussy (a personal favorite). Even though I went there to look at example, it still felt surprising that there was no infobox. I can’t see how any of the criteria discussed would result in Debussy not meeting the criteria so I expect the the infobox hold outs will still object to any criteria we come up with. Better to identify the page categories where infoboxes are not controversial and add those to the MOS. Maybe a later RfC defers people to the wikiproject they belong to. Dw31415 (talk) 11:27, 11 May 2026 (UTC)

I don't think the result of that RFC is best described as saying that infoboxes are "optional". I don't think that "optional" hits quite the same notes as "neither required nor prohibited". "Optional" sounds like there's an unstated default, but we can make an exception for you. "Neither required nor prohibited" sounds like prohibiting the extremes but leaving the middle wide open. WhatamIdoing (talk) 19:31, 11 May 2026 (UTC)

OK, I'm not sure what the implied unstated default would be; I don't perceive it that way. An optional thing can simply be present or not present. It could be present or not present in all articles. I also don't see how "neither required not prohibited" excludes extremes. A thing not required could be present on all articles, and a thing not prohibited could be omitted from all articles. But I was just looking for a more concise expression, and don't care if exact wording from RFC is used to avoid any unintended change in meaning. -- Beland (talk) 05:42, 12 May 2026 (UTC)

Agree with removing “clear” because we should just use “consensus”. Dw31415 (talk) 10:32, 11 May 2026 (UTC)

Instead of “recommended”, let’s try for “should” like other parts of the MOS: A title should be a recognizable name. I think closers are looking for clear guidance to evaluate against. I agree with removing people and events from a next RFC since those seem more controversial. A follow up RfC could address people or events specifically with criteria for inclusion (the idea in the topic above) Dw31415 (talk) 10:45, 11 May 2026 (UTC)

I think one way to get over the "no consensus" hump would be to drop from this list "people" and "events", because some people objected that those classes are too broad. Some subclasses, like sportspeople and sports tournaments, seem to have strong consensus for infoboxes, and others like composers and complicated historical events have some people objecting to putting infoboxes on them.

I think your desire for "guidance that prevents future disputes from being headcounts about infoboxes in general" directed at closers makes sense. Any topic that we don't cover in an explicit list can create an infobox quagmire without a good determination procedure. Having such a procedure I think reduces the risk of narrowing the infoboxes-recommended list in order to get consensus on it in an MOS RFC.

How about something explicit like:

For articles on other topics, when determining consensus to include or not include an infobox:

• Arguments accurately citing article-specific rationale should be weighted highly (e.g. not enough is known about the subject to have an infobox with more than two fields)
• Decisions about whether all entities of the same type should have an infobox should be weighed accordingly:
  • RFCs should be weighted highly.
  • Advice pages should be weighted moderately. If they are not being followed they should either be updated or reaffirmed with an RFC.
  • Accurate and substantive arguments about the type as a whole made in a discussion about an individual article should be weighted moderately.
  • Inconsistent conclusions as to whether articles about a certain type of entity should generally include or exclude infoboxes should be resolved by inviting editors with a diversity of viewpoints and uninvolved editors to a community-wide discussion.
  • Arguments about whether a given subtype differs from a parent type should be examined carefully on the merits, and weighted more heavily for very broad, heterogeneous types.
• Arguments based on an objection to a specific field or fields being too complicated or otherwise inappropriate for inclusion should be resolved by dropping those fields, if other arguments generally favor an infobox and this would not render them too short, and if field-specific counterarguments are unconvincing.
• Arguments about infoboxes in general (e.g. "infoboxes are clutter", "all articles should have infoboxes") should be discarded.

-- Beland (talk) 07:30, 11 May 2026 (UTC)

I think this would be good approach if we wanted to try both approaches at once (category vs criteria). I’m starting to think we should have one for categories first, and then follow up with category specific criteria for ones that fail. Dw31415 (talk) 10:50, 11 May 2026 (UTC)

Maybe:

Articles on specific ______ should have infoboxes. (select all that apply)

1. biological classifications,
2. chemical elements,
3. compounds,
4. events,
5. people,
6. settlements

Dw31415 (talk) 11:00, 11 May 2026 (UTC)

This seems like a reasonable approach, but given events and people are kind of heterogeneous, maybe it would be better to put subtypes in the RFC for those? Like one-time concerts vs. repeating sporting tournaments vs. military events vs. assassinations vs. social movements vs. holidays are all very different. -- Beland (talk) 18:48, 11 May 2026 (UTC)

'Events' can be dropped or changed to 'conflicts' to make it less broad. I'd prefer not to drop 'people', as those are the locus of almost all infobox disputes (and if 'recommended is changed to 'popular', it just becomes a fact: infoboxes are popular on people).

I think the middle section of arguments can be trimmed down to avoid WP:CREEP, perhaps to 'arguments based on relevant factors external to the article (e.g. an infobox template doesn't exist for this type of subject, similar articles don't have infoboxes) should be weighed moderately. Infobox templates can always be created in the future, and what an article does is not ultimately determined by other articles.'

Besides that, the list of arguments is largely in line with what I intended (though I wonder if any other part of the MOS deals with arguments in particular. Even the 'arguments to avoid' pages are essays instead of policy). Shogeneral (talk) 19:03, 11 May 2026 (UTC)

Didn't we have an RFC a couple of years ago (at the Village pump?) about more or less requiring infoboxes for biographies? WhatamIdoing (talk) 20:00, 11 May 2026 (UTC)

This? Wikipedia:Village_pump_(proposals)/Archive_202#RfC_on_establishing_a_biography_infobox_guideline

The opposes seem to be treating the proposal as making infoboxes mandatory, which my proposal doesn't. In any case, I think the best way forward is to RFC a modified version of your proposal first, and only if that fails, work on a proposal based around our discussed weight of arguments. If we can't get consensus on a binding list of factors to consider, then we should try to give guidelines for arguments. Shogeneral (talk) 20:35, 11 May 2026 (UTC)

How does adding “Infoboxes on _____ are popular” help drive consistency or help closers?

My hope with the next RfC is that we can care out some less controversial categories and establish a global consensus to include. If I understand correctly, it will put the burden of consensus on those wishing to exclude infoboxes from these categories. Dw31415 (talk) 21:34, 11 May 2026 (UTC)

Most editors want to do the "normal" thing. As as result, if you tell them "Look, everyone else is doing _____", then they usually want to do that themselves. WhatamIdoing (talk) 23:51, 11 May 2026 (UTC)

Some quotes from the oppose participants in that RFC:

• "I have often said that I agree with infoboxes in bios for politicians and sports figures"
• "I don't think I've ever seen an article on a member of the military, or a politician, or a sports person, where there has been any question - and quite right too: they are the biographies where an IB works brilliantly. The problem comes with some in the liberal arts or an occasional historical person where the benefits of a box are not clear cut."
• "For many biographies (especially pre-1800) a huge amount of information is uncertain or non-standard, which is difficult to reflect in an infobox, and there should be nothing that forces editors to display such information in boxes."

Excluding these cases would help move the outcome toward consensus.

Lots of opposing editors felt "recommend" was too strong - equivalent to "require" and this would weigh too heavily against article-specific arguments. So "are popular" might evoke less opposition, but so could having an explicit mention of per-article rationales.

-- Beland (talk) 02:17, 12 May 2026 (UTC)

By "conflicts", do you mean "military conflicts"? -- Beland (talk) 02:00, 12 May 2026 (UTC)

Yes, Template:Infobox military conflict is used for conflicts in general and can be linked with the others Shogeneral (talk) 02:26, 12 May 2026 (UTC)

Does "Advice pages should be weighted moderately. If they are not being followed they should either be updated or reaffirmed with an RFC" refer to Wikipedia:Advice pages, which are just essays written by WikiProjects, and which can't be "reaffirmed" on the grounds that they were never "affirmed" by the community in the first place? WhatamIdoing (talk) 20:02, 11 May 2026 (UTC)

How is the composer infobox “ban” enforced? Is it just via advertising RfC’s on the project page and that’s enough to ensure infoboxes rarely achieve consensus? Dw31415 (talk) 21:58, 11 May 2026 (UTC)

There isn't a 'ban' per se, it's just that a group of editors will always revert infoboxes on some pages, meaning that its difficult to get 'consensus' without an RFC (which usually establish a consensus to add them). Shogeneral (talk) 22:07, 11 May 2026 (UTC)

Back in the day (before the 2010 RFC), the revert would be accompanied by statements that there is a consensus at the WikiProject to (almost) never have infoboxes. On more popular articles, infobox opponents would even add <!-- hidden text messages --> in articles to warn editors not to add an infobox, because it was "against consensus". I've heard that some of those messages are still in a few articles.

Post-2010 drama, the message has gotten appropriately softer: We don't like it, but of course everyone must defer to the community's consensus. If you can prove that the community definitely does want this inappropriate excrescence in this pristine article, then we'll go along with it. WhatamIdoing (talk) 23:59, 11 May 2026 (UTC)

I removed the hidden messages from featured articles after the most recent RFC, but there are still hidden messages in non-featured composer articles. Shogeneral (talk) 00:20, 12 May 2026 (UTC)

... but some of them were reverted (Boulez, Bizet ...) --Gerda Arendt (talk) 21:54, 12 May 2026 (UTC)

The HTML comment in Georges Bizet points to a talk page discussion, and doesn't advise what to do either way. It seems fine to leave in place.

The HTML comment in Pierre Boulez was removed again. To prevent gratuitous reversions, it might be helpful to use an edit summary that points out Wikipedia:WikiProject Composers#Biographical infoboxes no longer requires talk page pre-approval. Trying to prohibit certain edits without a supporting guideline or policy is prohibited by WP:BADHIDDENTEXT. Beland (talk) 22:25, 12 May 2026 (UTC)

I have removed the remaining HTML comments incorrectly saying that the Composers or Classical music WikiProjects require talk page pre-approval. I found it hilarious that some of them were right before or even wedged inside infoboxes.

While doing this, I found some advice on an inactive WikiProject: Wikipedia:WikiProject Gilbert and Sullivan § Infoboxes in articles. -- Beland (talk) 17:39, 13 May 2026 (UTC)

I also found that Wikipedia:WikiProject Musicians/Infobox requires infoboxes for non-classical musicians. -- Beland (talk) 22:38, 13 May 2026 (UTC)

I wonder if Wikipedia:WikiProject Musicians/Infobox#Infobox required is meant to communicate "having an infobox is required" vs "if you need help adding an infobox, here's how to request it". WhatamIdoing (talk) 22:29, 14 May 2026 (UTC)

@Shogeneral, would you please post a fresh version of what you’re thinking? Thanks!! Dw31415 (talk) 02:46, 12 May 2026 (UTC)

My and Beland's proposal together, with my revised middle section:

Infoboxes are popular for articles on specific biological classifications, chemical elements and compounds, conflicts, people, settlements, and similar topics with basic and relevant facts. Nevertheless, an infobox can be excluded from such articles if there is a consensus that one would be inappropriate for the article. When determining consensus to include or not include an infobox:

• Arguments accurately citing article-specific rationale should be weighted highly (e.g. not enough is known about the subject to have an infobox with more than two fields)
• Arguments based on relevant factors external to the article (e.g. an infobox template doesn't exist for this type of subject, similar articles don't have infoboxes) should be weighed moderately. Infobox templates can always be created in the future, and what an article does is not ultimately determined by other articles.
• Arguments based on an objection to a specific field being too complicated or otherwise inappropriate for inclusion should not be counted against an infobox as a whole, unless the exclusion of the field would render an infobox too short.
• Arguments about infoboxes in general (e.g. "infoboxes are clutter", "all articles should have infoboxes") should be discarded.

Shogeneral (talk) 03:10, 12 May 2026 (UTC)

Thanks. I’ll step back and watch from the cheap seats. I appreciate your work on this. Dw31415 (talk) 03:47, 12 May 2026 (UTC)

I think that's okay. WhatamIdoing (talk) 04:54, 12 May 2026 (UTC)

I like how concise this is and most of the phrasing. I'm not sure "what an article does is not ultimately determined by other articles" aligns with the weighting. External factors *can* be determinative, e.g. if an infobox would be OK but for consistency with similar articles we omit it. If these arguments never had any effect, they'd be discarded rather than weighted moderately. -- Beland (talk) 05:00, 12 May 2026 (UTC)

Yes. I don't agree with your low opinion of advice pages, but am happy to write "affirm" instead of "reaffirm". -- Beland (talk) 02:20, 12 May 2026 (UTC)

Consolidated refresh

PART 1 - GRAPHICS

Append to MOS:INFOBOXPURPOSE:

An infobox ideally includes graphics that identify the subject (e.g. picture of a person, diagram of molecular structure, the written form of letters in an alphabet) and provide high-level context, such as a geographical map, position in a relevant timeline, or situation in a classification scheme.

PART 2 - STANDALONE LISTS

Append to MOS:INFOBOXPURPOSE:

Infoboxes on stand-alone list articles (including articles that are mostly composed of a list even if they don't have "List" in the title) generally work well when they:

• Give statistics about the list that would otherwise require work on the reader's part (like total counts, counts of subtypes, or the most frequent winner).
• For a topic "List of X", give attributes of "X". This is useful when "X" redirects to "List of X" and X is something repeated over time, such as an award or term in political office.
• Give an overview of an attribute that all items on the list have, or if how they have changed over time if it is possible to do so briefly. For example, a movie franchise has director X for films 1-4 and director Y for films 5-8.
• Have a visual element that shows:
  • Representative examples from the list (such as individual officeholders).
  • An identifying entity that applies to all items on the list (such as a logo, coat of arms, or physical manifestation of an award or championship trophy).
  • How all the items on the list relate to each other (such as a geographical map, family tree, or timeline).

PART 3 - POPULAR FOR

Append to MOS:INFOBOXUSE:

Infoboxes are popular for articles on individual entities like:

• Biological classifications (like species), chemical elements and compounds, and astronomical objects
• Medical conditions and anatomical features
• Natural features like mountains and rivers
• Settlements and buildings
• Schools, universities, companies, and other organizations
• Aircraft, airports, ships, roads, and railway stations
• Films, TV shows, video games, and software
• Books and newspapers
• Albums and songs
• Sportspeople, military people, and political officeholders
• Sports competitions
• Military conflicts

(See full stats at Wikipedia:List of infoboxes.) Nevertheless, an infobox can be excluded from such articles if there is a consensus that one would be inappropriate for the article.

PART 4 - DISCUSSION WEIGHTING

Append to MOS:INFOBOXUSE:

When determining consensus to include or not include an infobox:

• Arguments accurately citing article-specific rationale should be weighted highly (e.g. not enough is known about the subject or can be explained concisely to have an infobox with more than two fields, the upper right corner is better used for a large image).
• Arguments based on relevant factors external to the article (e.g. similar articles do or do not have infoboxes) should be weighed moderately.
• Arguments based on an objection to a specific field being too complicated or otherwise inappropriate for inclusion should count against use of that field but not against the infobox as a whole, unless the exclusion of the field would render the infobox too short.
• Arguments based on an objection to a specific template not fitting the key facts of an article should be considered weak if a new template can accommodate them.
• Arguments about infoboxes in general (e.g. all infoboxes are clutter, all articles should have infoboxes) should be discarded.

Which of these parts would you support continuing into an RFC? Should it be four separate RFCs or one four-parter or one two-parter, or what? I've expanded the "popular" listing to more comprehensively cover templates that are used on 100,000+ or 10,000+ articles, and tweaked the "weighting" language, so I'm also curious if there are any suggested changes to any of the text. -- Beland (talk) 22:00, 14 May 2026 (UTC)

I don't think that #1 requires an RFC. You might add something about the ideal state not always being possible, but other than maybe adding that, I think it's uncontroversial enough that you could just WP:PGBOLDly add it. WhatamIdoing (talk) 00:17, 16 May 2026 (UTC)

Added with the suggested tweak! -- Beland (talk) 06:18, 16 May 2026 (UTC)

Best practices for light/dark mode software screenshots

This question was previously asked at User talk:Qwerfjkl but reposted here

On the page Marginalia (search engine), I decided that the screenshot of the website that used at the time should be in light mode as that is a common default for most software users. I don't have the permissions to overwrite the file for that screenshot, so I uploaded a separate file and used Template:If dark.

Is this use of If dark recommended or not? I ask because I don't really know if that's a standard thing to do or not for software screenshots.

You can see the specifics of what I did at this revision. Should I use screenshot_alt in the infobox template or the alt attribute for each image link? I ask because I'm unsure if the alt is correctly being added to the images since I use a file link in the screenshot parameter as opposed to a filename, and I don't know if the infobox template can add the alt to the image when the image isn't provided as a filename.

And in general, have I done things properly in that revision? Did I make any mistakes? Newtbytes (talk) 17:50, 22 April 2026 (UTC)

Examining the page (right click and Inspect Accessibility Properties on Firefox), it looks like the alt text didn't get added anywhere in the template. Definitely not your fault, as I think the infobox templates just never planned for this situation, but it is certainly something that can be worked on as having light/dark screenshots to match the theme can be a good thing!

Courtesy link to Module:InfoboxImage which is where the image magic takes place. Chaotic Enby (talk · contribs) 13:37, 1 May 2026 (UTC)

Alright thanks! I'll have to look into the template code to see if I can figure out a change I can propose. Newtbytes (talk) 19:11, 1 May 2026 (UTC)

Alright it seems that passing anything other than a filename or an image link is technically unsupported according to the docs for InfoboxImage:

-- Inputs:
--    image - Can either be a bare filename (with or without the File:/Image: prefix) or a fully formatted image link

The source code for the module also suggests that only bare filenames would have the screenshot_alt inserted. I can't seem to get using bare filenames to work though so I'm kind of stuck. Either InfoboxImage needs a smarter implementation that finds file links and adds parameters to it, even when surrounded by <span>s or whatever other extra HTML (as created by the If dark template), or when multiple file links are found in the input image parameter; Or I need to figure out why using If dark with bare filenames doesn't work.

Actually, as I write this I realize that If dark is adding extra HTML around bare filenames as well, which explains why bare filenames do not work. For now I'll simply manually add the alt to both screenshots, but ideally InfoboxImage would need a smarter implementation that somehow doesn't break other invocations of InfoboxImage that have weird input to the image parameter. Newtbytes (talk) 19:50, 1 May 2026 (UTC)

Hi @Newtbytes, when the docs say fully formatted image link I believe that includes everything covered in Help:Extended image syntax. I was able to add the alt directly and saw it show up in my browser.

If I understand correctly, Template:If dark evaluates first and wraps both screenshots in a (see WP:TSTYLES). Then Module:InfoboxImage tries to process the screenshots. On line 100 the infobox sees that the screenshots have been wrapped in complex wiki markup, so it accepts your screenshots as-is, since they look like they have already been processed. Blepbob (talk) 11:58, 7 May 2026 (UTC)

Slight correction, I'm not sure which order is true. Maybe Module:InfoboxImage processes before Template:If dark. The end result would be the same but the infobox stops processing on line 98 instead of line 100. Blepbob (talk) 12:46, 7 May 2026 (UTC)

I tried some tests and it seems line 102 is the important line. Your Template:If dark is translated by the wiki into a placeholder called a strip marker. The infobox finds that and stops processing. Blepbob (talk) 14:17, 7 May 2026 (UTC)

Are modules allowed to modify the contents of a strip marker? Actually, if that was the case I imagine Module:InfoboxImage wouldn't be skipping processing in the case it comes across a strip marker. Newtbytes (talk) 17:02, 7 May 2026 (UTC)

Also, would it be allowed to look at the textual content of a strip marker and treat that as a filename (assuming it is a filename of course). If I'm imagining things correctly, that would make it possible to avoid using a image link and let Module:InfoboxImage add the alt. Newtbytes (talk) 17:05, 7 May 2026 (UTC)

I considered adding the alt directly to each image but didn't end up doing that. Semantically I at first feel that that's the best approach in this case. However, an alt describes in image in its context, so although it's neat that the alt can vary whether dark mode is enabled or not, in context if the screenshot is the dark mode version just because the user has dark mode set, it isn't important for that fact to be included in the alt if it isn't an important feature of the screenshot contents. I think ultimately they should be the same alt description, and since they are the same I feel that avoiding repeating that description twice would be ideal. For now I'll just remove the "(dark mode)"/"(light mode)" from the alt(s), but I still think it would be useful for Module:InfoboxImage to be able to add the alt. Though if it's not valid for a module to modify the contents of a strip marker then idk then. Newtbytes (talk) 16:59, 7 May 2026 (UTC)

Modifying the content inside strip markers is probably possible, but has drawbacks.

1) Lua modules are already difficult to understand for most editors (including me). Adding new behaviors makes them more confusing and increases risk that something breaks.

Suppose Wikimedia introduces a new skin with several color modes. Template:If dark has to update to wrap its output in more layers. Module:InfoboxImage would also have to update to unwrap all these new layers.

Then say someone creates Template:If light and Template:If dim, each similar but not identical to Template:If dark in structure. How should Module:InfoboxImage support every variant?

It's simpler not to interfere with nested templates. The inner template should handle the fine-tuning.

2) The behavior may not fit every infobox. A counterexample is an article where the lead image is a collage.

The example at Collage tips is an event spanning multiple locations. Each location requires a separate alt.

The infobox module handles all these cases, including both yours where alts can match and collages where they can't. If the behavior is tuned for your case, the infobox would be less useful for collages.

Your goal is worthwhile for accessibility, but IMO the solution is better handled by improving Template:If dark, not inside the infobox module. Blepbob (talk) 18:59, 7 May 2026 (UTC)

Also, I currently am setting screenshot using the If dark template like so:

{{If dark
  |[[File:Marginalia Search Engine - Search Results.png|260px|frameless]]
  |[[File:Marginalia Search Engine - Search Results (Light Mode).png|260px|frameless]]}}

Ideally it could simply be used without a File: link:

{{If dark
  |Marginalia Search Engine - Search Results.png
  |Marginalia Search Engine - Search Results (Light Mode).png}}

However this just results in the text being rendered literally. I'm unsure if this is a bug or I am not understanding some detail about how templates evaluate. Newtbytes (talk) 19:17, 1 May 2026 (UTC)

Rating boxes

I'm seeing a handful of editors deleting prose content in album pages covering reviews because they are covered in a "ratings box". The effect is that the review isn't discussed anywhere, which would seem to run counter to the "summary" style criteria of the WP:Manual of Style/Infoboxes guideline. I would expect any review in a ratings box to be mentioned in the prose portion of a critical review section in order to be MOS compliant. Am I correct or incorrect in thinking this? An example of this would be On the Flip Side (see the edit dispute in the history) where the review was completely removed from the prose portion of the page, and is mentioned nowhere on the page other than in the limited format of the ratings box. Another example is this edit on Spotlight on Rick. Granted these prose sentences were previously "redundant" to the box as the former content simply reiterated the star rating. It would have been better to elaborate on the critical commentary from the review. However, redundancy is not a valid reason to remove prose content as a box is supposed to be redundant because of MOS's "summary" style criteria.

Curtesy pinging Caro7200 and 026 Starcheerspeaksnewslostwars who were involved on that page with dissenting opinion from WP:ALBUM. I think this deserves a wider discussion from the community on what we expect ratings boxes to be and do as a community. I advocate that they should only contain reviews discussed in prose under "summary" style MOS criteria. The solution here is never to remove the prose, but improve it. The ratings box should not become a housing tool for critical reviews not discussed in the body of the article.4meter4 (talk) 15:03, 14 May 2026 (UTC)

The key question here is whether the prose review expands upon the rating listed in the “ratings box”?

If the prose simply states “the song got a 5 star review on greatmusic.com”, that is unnecessary verbiage (covered in the box)… on the other hand if it says “The song blends disco with Mongolian throat chanting to create a unique soundscape that gained it a 5 star rating.” That isn’t something already covered in the box and should be kept. Blueboar (talk) 15:28, 14 May 2026 (UTC)

@Blueboar: I disagree. If the review isn't mentioned in the prose, then the box is no longer summarizing and contains original content not found elsewhere. Boxes are not supposed to do that under any circumstances per the very first sentence of MOS policy on infoboxes. We should not have reviews in the box not discussed in the body. Period. They need to "summarize" content found elsewhere.4meter4 (talk) 15:31, 14 May 2026 (UTC)

I think this is misstating things a bit--the majority of album articles do not repeat the ratings information in the prose of critical reception sections. See Big Daddy--Sgt. Pepper's Lonely Hearts Club Band--as one example of this. Unlike the main album infobox, which may contain information found in different sections of a long article, the ratings box is only found in one section, unless the article is a stub. My recollection of the last time this was brought up at Wikipedia talk:WikiProject Albums is that editors objected to sentence after sentence of "AllMusic gave this album four stars...", "Rolling Stone gave this album three stars...", etc., when the ratings info was often within the same line of sight as the prose (granted, I rarely help students with accessibility devices and can't remember how boxes and templates are conveyed to visually impaired readers). And I'm not sure that "a handful of editors deleting prose content" is accurate when thousands and thousands of articles exist where ratings are found only in ratings boxes. It is more accurate to state that a minority of editors want the ratings information included in the prose. Cheers. Caro7200 (talk) 15:47, 14 May 2026 (UTC)

I don't think waving at a generic wikiproject talk page without linking to the specific discussion had on that talk page at some unknown point in the past is particularly useful. We can't see what anybody actually said, and what the consensus was. More pertinently, I don't think the album wikiproject gets to overrule style guidelines governing the entire encyclopedia as it relates to infoboxes. Infoboxes are not supposed to have original content. That's a fundamental policy guideline. They are only supposed to contain content found in the prose section of the article. Ratings boxes need to follow those same rules. I note that visually impaired users don't get infobox content in auditory readings of wikipedia pages which is one reason we require all content in infoboxes to be expressed in prose.4meter4 (talk) 15:53, 14 May 2026 (UTC)

Your recollection is correct to my experience. Sergecross73 msg me 16:45, 14 May 2026 (UTC)

The prose should have more details about what the ratings box summarizes. Or at least say something.----3family6 (Talk to me|See what I have done) 16:06, 14 May 2026 (UTC)

I agree. I think we all agree on that. Simply stating the rating is not the best content choice. However, that doesn't mean we should gut prose mentioning star ratings. A visually impaired person has no access to the ratings box. It isn't read for them, and they can't see it, so the effect of removing even generic boring ratings text is to completely remove all mention of the review for those users. That isn't right. The solution here is to improve prose, not gut prose.4meter4 (talk) 16:13, 14 May 2026 (UTC)

@4meter4 I agree. In some cases, there's not much more, or isn't any more at all, than the rating, but in the majority of cases there's more than just a rating. Certainly, prose content shouldn't be blanked.----3family6 (Talk to me|See what I have done) 23:39, 24 May 2026 (UTC)

To me, it's redundant to note in both the prose and the review box, that an album got a "9/10" rating. I relegate the numerical score to the review box, while just paraphrasing the sentiment of the review in the prose. "John Smith of Pitchfork Magazine praised the album for its incredible sound and lyrics".

To my recollection, I don't believe I ever get pushback on this approach. It's always feels like an uncontentious thing I'm cleaning up, like italicizing album titles or something. This approach mirrors WP:VG's approach as well, per MOS:VGREC. Sergecross73 msg me 16:26, 14 May 2026 (UTC)

• Comment. I don't want to come across as BLUDGEONING, so I want this to be my last comment for a while. I have some questions I'd like editors to consider. 1) What is our responsibility to visually impaired users who can't see ratings boxes and have no access in read aloud format to those boxes? Knowing that access is an issue, should we require ratings to be expressed in prose so that visually impaired users have access to that information? 2) Should we allow reviews not articulated in the prose portion of the article to be housed in the ratings box? The biggest issue I see at the moment is that editors are removing prose sections covering star ratings, and then not replacing it with something better from those same reviews. They are literally just removing any critical discussion in prose in the cases of articles where the only thing previously said in prose was a star rating. That leaves the ratings box as the only place those reviews are mentioned, and then visually impaired users have no critical commentary access when that happens. (ie they hear nothing about what critics said ratings or otherwise when they access articles through read aloud format) See the two examples given above where that happened. That is a big problem in my opinion. I don't think we should be encouraging editors to gut mentions of star ratings in prose sections. It would be one thing if they were replacing the content with something else from those same reviews (like a critical quote). But that isn't what is happening.4meter4 (talk) 16:43, 14 May 2026 (UTC)

RFC: Guidance on infobox use, take 2

Should guidance be added to MOS:INFOBOXUSE on what types of articles infoboxes are commonly used on, and how to determine consensus on whether to include one in any given article? 07:14, 18 May 2026 (UTC)

Please indicate if you would support Part A, Part B, both, or neither, or have suggestions for improvement.

PART A - POPULAR FOR

Append to MOS:INFOBOXUSE:

Infoboxes are popular for articles on individual entities like:

• Biological classifications (like species), chemical elements and compounds, and astronomical objects
• Medical conditions and anatomical features
• Natural features like mountains and rivers
• Settlements and buildings
• Schools, universities, companies, and other organizations
• Aircraft, airports, ships, roads, and railway stations
• Films, TV shows, video games, and software
• Books and newspapers
• Albums and songs
• Sportspeople, military people, and political officeholders
• Sports competitions
• Military conflicts

(See full stats at Wikipedia:List of infoboxes.) Nevertheless, an infobox can be excluded from such articles if there is a consensus that one would be inappropriate for the article.

PART B - DISCUSSION WEIGHTING

Append to MOS:INFOBOXUSE:

When determining consensus to include or not include an infobox:

• Arguments accurately citing article-specific rationale should be weighted highly (e.g. not enough is known about the subject or can be explained concisely to have an infobox with more than two fields, the upper right corner is better used for a large image).
• Arguments based on relevant factors external to the article (e.g. similar articles do or do not have infoboxes) should be weighed moderately.
• Arguments based on an objection to a specific field being too complicated or otherwise inappropriate for inclusion should count against use of that field but not against the infobox as a whole, unless the exclusion of the field would render the infobox too short.
• Arguments based on an objection to a specific template not fitting the key facts of an article should be considered weak if a new template can accommodate them.
• Arguments about infoboxes in general (e.g. all infoboxes are clutter, all articles should have infoboxes) should be discarded.

(Notified: Template:Centralized discussion, Wikipedia talk:WikiProject Infoboxes)

Infobox use 2 responses (Part A)

• Support A and B as nominator: ArbCom requested "a well-publicized community discussion be held to address whether to adopt a policy or guideline addressing what factors should weigh in favor of or against including an infobox in a given article", and it seems we still haven't quite answered that question. The previous RFC attempting to directly fulfill this request did not gain consensus. After a lot of discussion and working through proposed text, this second attempt provides two possible answers from different angles. More specific guidance about the types of facts infoboxes are good for is contained in MOS:INFOBOXPURPOSE, and the proposed addition aims not to be redundant with that. -- Beland (talk) 07:14, 18 May 2026 (UTC)
• Oppose part A as unnecessary instruction creep. DrKay (talk) 07:49, 18 May 2026 (UTC)
• Support A and B Reasonable description of the facts on the ground. Rolluik (talk) 08:29, 18 May 2026 (UTC)
• Support A and B with the understanding it can be amended to have the list of stuff infoboxes are popular for (especially the ones about people, which is currently very lacking, considering we use infoboxes on the vast majority of biographies of people that we have enough information to make a good infobox for, and that includes pretty much every BLP). ⹃Maltazarian ^{ᚾparley$\lor$investigateᛅ} 08:52, 18 May 2026 (UTC)
• Soft Oppose A I'm not sure about the necessity of including this list. Note The initial bullet in Point B only including anti-infobox examples would seem to bias the policy. JuxtaposedJacob (talk) | :) | he/him | 10:15, 18 May 2026 (UTC)

• Comment: I am not per se opposed to this language, but in my opinion, it is a much less helpful alternative to the text proposed and discussed at length in previous recent discussion and which is, despite the lack of a formal close, I think pretty broadly endorsed in the previous discussion. Saying that infoboxes are "popular" for X, Y, and Z categories of article is going to do effectively nothing to deter the most problematic behaviours we have historical seen from partisans in the 'infobox wars', nor provide guidance enough to be particularly helpful in breaking deadlocks once conflicts start.
  While the previous proposal was also not a panacea in that respect, I believe that the detailed guidance about which factors which be utilized when making the editorial determination on whether to use an infobox would be far superior to any particular list of categories where we might expect them. I'm particularly concerned about the new proposal with regard to the "Nevertheless, an infobox can be excluded from such articles if there is a consensus that one would be inappropriate for the article." verbiage, which, while entirely reasonable in abstract, is very certain to be heavily leveraged by anyone without any nuance in their outlook on infoboxes. The fact of the matter is that the main reason we need additional guidance in this area is because of the confirmation bias in interpretations of existing policy from entrenched editors highly motivated on this issue (pro- and anti-infobox). While I mostly agree that this new proposed text and believe it is well-reasoned and that it identifies appropriate examples, I don't believe the addition would go far towards solving the existing issues with the recurrent contests of will over infobox usage; indeed, with that particular wording, I think it might only exacerbate the issues.
  So, again, not expressly opposed to this proposal, but I think the rough consensus of the previous discussion for language discussing the actual analysis and weighting of particular factors militating for or against inclusion of an infobox is the far superior way to go. Of course, the two proposals are not altogether mutually-exclusive, but I'd rather harmonize and merge the language of both and proceed from there, than endorse this proposal and risk consigning the previous discussion to the archives without formal adoption. SnowRise ^{let's rap} 03:22, 19 May 2026 (UTC)
• Oppose A – The 'popular' wording will be taken as meaning that unless a special dispensation is obtained via talk page discussion, the presence of an infobox on these sorts of pages is the default. Think of the analogous concept of COMMONNAME. There is no benefit to adding this wording. I am strongly opposed to any change that will result in the creeping proliferation of mandatory infoboxes that do not serve the interests of the reader. Yours, &c. RGloucester — ☎ 20:46, 19 May 2026 (UTC)
• Soft support A per Beland, but could also agree w/ JuxtaposedJacob re necessity of listing popular use cases in MOS (could be a short footnote, maybe? have not been involved in pro vs anti-infobox wars so list in MOS main text might actually be needed after all, I dunno) - Asdfjrjjj (talk) 21:01, 19 May 2026 (UTC)

  I was attempting to groom a list to include only non-controversial entries, but I agree it can get quite long for the MOS. Would it be better to just link to Wikipedia:List of infoboxes and let editors decide what's "popular"? -- Beland (talk) 21:07, 19 May 2026 (UTC)

  Ohh sounds reasonable imo, would maybe get JuxtaposedJacob's support to boot? - Asdfjrjjj (talk) 21:29, 19 May 2026 (UTC)

  Sounds good to me! JuxtaposedJacob (talk) | :) | he/him | 18:44, 21 May 2026 (UTC)

• Oppose Much like Snow Rise (and for similar reasons). I don't disagree with the text per se, I think it has too many words for any benefit. On the otherhand, I think we were closer with the first RFC. There was general agreement with the points to be considered - except possibly on accessibility (see the RfC before discussion). The RfC failed because the proposal did not identify how those points should be considered and because it was not written as a guideline should be. Cinderella157 (talk) 00:09, 20 May 2026 (UTC)
• Oppose per WP:CREEP. A list of where infoboxes are common can go in an essay. BilledMammal (talk) 03:21, 21 May 2026 (UTC)

  If this were more strongly worded - "these types of articles should have infoboxes unless there is local consensus not to" - would that be worthwhile, or is that going too far in your view? Just trying to figure out if the middle ground is actually less popular than either end. -- Beland (talk) 03:56, 21 May 2026 (UTC)

  Yes; I'd prefer a clearer definition on what is meant by "local consensus not to", but if this provided guidance rather than just information it would be useful. BilledMammal (talk) 03:49, 22 May 2026 (UTC)

• Oppose A - This does not help editors resolve infobox discussions, as it's just a list with no real required actions behind it. InfernoHues (talk) 03:50, 22 May 2026 (UTC)
• Oppose as per RGloucester and BilledMammal. Bondegezou (talk) 08:07, 22 May 2026 (UTC)
• Support A - a reasonable description of consensus. I think including it in the MOS might help resolve infobox disputes, maybe it won't but it's harmless enough to give it a shot. Levivich (talk) 18:49, 24 May 2026 (UTC)
• Support A per Levivich --Gerda Arendt (talk) 20:10, 24 May 2026 (UTC)
• Oppose as per Snowrise. The guideline should define criteria that should be considered in discussion, not simply list broad categories of articles where they've historically been "popular". Scribolt (talk) 07:27, 26 May 2026 (UTC)
• Oppose per WP:CREEP. ~~ AirshipJungleman29 (talk) 12:14, 29 May 2026 (UTC)
• Oppose A It might be interpreted as loose, permissive and ineffective, in which case there's no point adding it. It might also be read as indicating that there is a proper infobox to use for anything that falls into a category listed and it's the one linked, both of which are so very wrong, and that the default is to use infoboxes unless otherwise agreed specifically; that disastrous reading would keep being employed, to the great detriment of our articles. NebY (talk) 17:07, 9 June 2026 (UTC)

Infobox use 2 responses (Part B)

• Support A and B as nominator: ArbCom requested "a well-publicized community discussion be held to address whether to adopt a policy or guideline addressing what factors should weigh in favor of or against including an infobox in a given article", and it seems we still haven't quite answered that question. The previous RFC attempting to directly fulfill this request did not gain consensus. After a lot of discussion and working through proposed text, this second attempt provides two possible answers from different angles. More specific guidance about the types of facts infoboxes are good for is contained in MOS:INFOBOXPURPOSE, and the proposed addition aims not to be redundant with that. -- Beland (talk) 07:14, 18 May 2026 (UTC)
• Support A and B Reasonable description of the facts on the ground. Rolluik (talk) 08:29, 18 May 2026 (UTC)
• Support A and B with the understanding it can be amended to have the list of stuff infoboxes are popular for (especially the ones about people, which is currently very lacking, considering we use infoboxes on the vast majority of biographies of people that we have enough information to make a good infobox for, and that includes pretty much every BLP). ⹃Maltazarian ^{ᚾparley$\lor$investigateᛅ} 08:52, 18 May 2026 (UTC)
• Soft Oppose A I'm not sure about the necessity of including this list. Note The initial bullet in Point B only including anti-infobox examples would seem to bias the policy. JuxtaposedJacob (talk) | :) | he/him | 10:15, 18 May 2026 (UTC)

  What did you have in mind as a good pro-infobox example to include there? -- Beland (talk) 19:32, 18 May 2026 (UTC)

  One that I've personally used in past infobox-related RFCs is "there is encyclopedic information about this subject that fits the infobox parameters but wouldn't fit naturally in the lead." This comes into play most visibly for subjects that have statistical or database-like information of encyclopedic interest (e.g. species, cities, sports biographies) but can also be relevant elsewhere. ModernDayTrilobite (talk • contribs) 13:45, 19 May 2026 (UTC)

• Comment: Again, as per my comment in response to the first half of the proposal, I do see some value in the guidance being proposed for inclusion here, but (meaning no offense to Beland's good faith efforts), I just don't find the language nearly as practical or well-specified as the guidance discussed in the recent previous thread, which I think very arguably already achieved consensus. If the concern was that consensus was too hard to read because of a lack of a solid up-or-down !vote, then I think the solution ought to have been to have had that RfC based on the language that already had significant support and benefited from tinkering by a large number of community members. The decision to instead jump immediately to an RfC regarding language proposed by one user that kinda-sorta overlaps with the objectives of the previous language, but uses wholly different tests, is, imo, an issue.
  In short, even though I'm certain I wouldn't have objected to either of these additions if they had been made before the previous discussion, they now look like a substantial downgrade to my eye, relative to what the community just got done hammering out, and which I think will serve better to provide clarity on these issues and better prevent the kinds of entrenched disputes we have classically seen regarding infoboxes. Again, nothing personal against Beland, but for me, this is clearly a case where the crowdsourced language reflects a much more nuanced and utilitarian result than the efforts of one editor. SnowRise ^{let's rap} 03:35, 19 May 2026 (UTC)

Woops, I'm an idiot: my eyes somehow glanced over the fact that there was an intermediary discussion between the one I am referencing above and this RfC, wherein Beland workshopped the current proposal with some of the participants of the previous thread of recent months. While I still support language closer to that discussed in the "Criteria for adding an infobox" thread, for the reasons discussed above, I want to acknowledge that I see now that the current proposal involved more collaboration than I first realized. SnowRise ^{let's rap} 03:39, 19 May 2026 (UTC)

• Oppose B – WP:CREEP. No good reason to deviate from the standard methods for evaluating consensus. Yours, &c. RGloucester — ☎ 20:48, 19 May 2026 (UTC)
• Support B per Beland, and do not think this reaches CREEP status as instructions imo seem helpful, not redundant, not trivial :) - Asdfjrjjj (talk) 21:10, 19 May 2026 (UTC)
• Oppose See my comment at part A. Cinderella157 (talk) 00:11, 20 May 2026 (UTC)
• Support B - This is pretty much just a summary of existing practice, and codifying it would help reduce pointless arguing. InfernoHues (talk) 03:48, 22 May 2026 (UTC)
• Support, if an example of an argument to support including an infobox is also included in Arguments accurately citing article-specific rationale should be weighted highly, to avoid bias issues. This provides useful guidance and reflects current practice. BilledMammal (talk) 03:51, 22 May 2026 (UTC)
• Oppose as per RGloucester. Bondegezou (talk) 08:08, 22 May 2026 (UTC)
• Support B - reasonable set of instructions for closers on how to weigh consensus in infobox discussions. I think this is more likely to help resolve infobox disputes than A. We've needed a written set of community guidelines for what are "good" and "bad" arguments in infobox RFCs for a long time. It's not instruction creep, it's badly needed instructions. Now closers will have some guidance to hang their hats on. We'll see if this particular guidance works in practice or needs tweaking, but it's a good first step to bringing order to the ad-hoc chaos we've seen in some past infobox RFCs. Levivich (talk) 18:52, 24 May 2026 (UTC)
• Support B, per the reasoning by Levivich, - I love the last item especially. It would be nice if edit summaries would follow. --Gerda Arendt (talk) 20:17, 24 May 2026 (UTC)
• Weak Oppose. Not against some kind of closure related guidance in principle, but I think until the infobox inclusion / exclusion factors need to be defined first so they can be reflected if needed. Scribolt (talk) 07:27, 26 May 2026 (UTC)
• Oppose B particularly the third bullet on "specific field", which doesn't allow for realism. A proposed infobox may have several fields that are unsuitable for that article. Eager editors, especially comparatively new ones or editors unfamiliar with the subject, will fill those fields, but will only have been able to find data that's unsuitable. That's a maintenance burden for editors watching the article, and they cannot be expected to keep performing the necessary reverts with cheerful, tactful and encouraging edit summaries, nor can the new editors be expected to even see those edit summaries; this bullet point encourages setting up conflict and militates against editor retention. More broadly, I'm quite unconvinced that we should give such formal instructions to closers in the MOS or elsewhere; whatever in this does have value would sit better in an essay. NebY (talk) 17:23, 9 June 2026 (UTC)

Discussion

Would recommend splitting the responses section into Part A and Part B, to help the closer. –Novem Linguae (talk) 11:27, 18 May 2026 (UTC)

I've WP:BOLDly gone ahead and implemented this split now, since I felt that doing it as early as possible (before there's a large volume of responses or any back-and-forth under individual !votes) would minimize any disruption to the flow of the RFC. For responses left prior to the split, I've fully duplicated them across both sections, with the exception of DrKay's response, since that one explicitly only covered Part A. Anyone can feel free to revert this split if they feel I've overstepped. ModernDayTrilobite (talk • contribs) 15:49, 18 May 2026 (UTC)

Citizenship parameter

Hello, I had question on the use of citizenship parameters especially on subjects born in colonies or overseas territories. Per MOS:INFONAT, this means for eg John Doe who was born in British India, we should avoid adding British subject (until 1947), Indian (from 1947)? Rejoy²⁰⁰³(talk) 14:08, 24 May 2026 (UTC)

Hi @Rejoy2003, my reading of this is the same as yours, specifically "A |citizenship= field can be used, with the following guidelines: Omit when this can be inferred from the birth country (almost all cases): This includes when citizenship changes due to sovereignty changes (e.g., when a colony attains independence) but is a group change that only depends on citizenship at birth." So without any context (i.e.: citizenship is important for understanding the context of the article, and it is described in the text already) there should be no need to further state as much in the infobox. Bobby Cohn 🍁 (talk) 17:58, 26 May 2026 (UTC)

@Bobby Cohn Yes, omit it is. And what about Mother Theresa? there's like a whole list of her nationality (not forgetting it is depreciated now). A similar list was also present in Mahatma Gandhi. I had a discussion on this with another experienced editor who said that us editors even adding such nationality is basically "textbook WP:OR". Rejoy²⁰⁰³(talk) 06:57, 27 May 2026 (UTC)

Mother Theresa's citizenship changed from being based in Skopje to being based in Kolkata, so it can't be inferred from her birthplace. Given the changes of jurisdiction of each place, the list of citizenship changes for her is long and seems to take up a disproportionate amount of space in the infobox compared to its importance. I would say this falls under the MOS:INFOBOX directive: "In complicated cases, omit from the infobox and explain in the article body." Given that the parameter is going to be removed from {{infobox saint}}, it seems this is going to happen regardless of complexity. -- Beland (talk) 16:50, 27 May 2026 (UTC)

Context being important, of course, because it looks like, to me, Mother Teresa is an existing article where citizenship is also referenced in the body of the article, and a reasonable editor could make an argument for its inclusion. I would say begin the process by first proposing changes or attempting to establish consensus on the talk page. But, as Beland mentions, if citizenship is about to be depreciated in {{infobox saint}}, it's likely a moot point. Bobby Cohn 🍁 (talk) 17:07, 27 May 2026 (UTC)

@Beland @Bobby Cohn It does makes sense. I had another question, lets take example of Goans, per Portuguese nationality law they were considered Portuguese citizens prior to 1961 (Annexation of Goa) they eventually lost their citizenship automatically after Indian citizenship was imposed upon them by default from that date.

If we are dealing with Goans born and died before 1961 during Portuguese India, what do we term them as? Portuguese or Indians? I vouched for Portuguese as per the nationality law. But I was told that it simply is WP:OR. Is that correct? So I am guessing if there is a source that mentions a person born in the United States we can't assume they are american? I mean after all anyone born in the US are citizens by default. Rejoy²⁰⁰³(talk) 09:31, 28 May 2026 (UTC)

If their citizenship follows what happened to everyone else's in the place they were born, there's no particular need to put anything about citizenship in the infobox, just place of birth. -- Beland (talk) 11:17, 28 May 2026 (UTC)

@Beland I am talking about before that change happened in 1961. Rejoy²⁰⁰³(talk) 12:46, 28 May 2026 (UTC)

Yes, if everyone born in similar circumstances (i.e.: born in the same place at the same time) had the same thing happen to their citizenship due to external circumstances, then there is likely no need to use the citizenship parameter. Bobby Cohn 🍁 (talk) 12:59, 28 May 2026 (UTC)

@Bobby Cohn this is less of the param in question but what nationality should we designate the subject as. I didn't get you, are you trying to imply people born and died in Portuguese India, British India or French India, should be designated as "Indians" regardless of their death before it became part of the sovereign country? Rejoy²⁰⁰³(talk) 13:53, 28 May 2026 (UTC)

I tried answering your question about the citizenship parameter in infoboxes in the section titled #Citizenship parameter on the talk page for the Manual of Style/Inofboxes. I don't recall commenting on nationality, nor specific people in Portuguese India, British India or French India, rather clarifying the prior answer that you followed up on; I'm sorry if I gave you a different impression.

As I said in an earlier statement, if you have concerns about a specific article, your best bet for making changes is to "begin the process by first proposing changes or attempting to establish consensus on the talk page". I don't think I'll be able to offer any more advice than that. Bobby Cohn 🍁 (talk) 14:03, 28 May 2026 (UTC)

This is not about a specific article but how to handle articles when it came about Goans from a certain period . Appreciate the help though! Rejoy²⁰⁰³(talk) 14:15, 28 May 2026 (UTC)

When you're asking what nationality the subject should be designated as, are you asking about the infobox or article prose? MOS:INFOBOX does not apply to the latter. -- Beland (talk) 14:19, 28 May 2026 (UTC)

@Beland sorry I know I am a little late to reply. If I do have questions about the latter where can I take this to? do you have anyone that could guide me on this. Rejoy²⁰⁰³(talk) 12:13, 2 June 2026 (UTC)

Guidance for prose is at MOS:NATIONALITY. -- Beland (talk) 17:14, 2 June 2026 (UTC)

MOS:INFONAT

MOS:INFONAT seems to contradict MOS:INFOBOXREF, in the sense that the latter states that if content (such as citizenship in a BLP) is repeated and cited elsewhere in the article (lead or body), no reference is required in the infobox; whereas according to the former, we should "include an inline citation and use a reliable source, especially for biographies of living people". Shouldn't MOS:INFONAT elaborate more, so it doesn't cause confusion, and is more in line with MOS:INFOBOXREF; if the citizenship is repeated and already cited in the body, it would seem redundant to include a reference in the infobox as well. I propose something like the following:

• [Unless already cited elsewhere in the article, i]nclude an inline citation and use a reliable source, especially for biographies of living people.

Are there any objections for this addition? Should it be phrased differently? – Demetrios1993 (talk) 14:48, 24 May 2026 (UTC)

Some devices do not display the infobox, so the infobox should summarize the information already provided in full in the article itself. See MOS:INFOBOXPURPOSE. I take this to mean that the article should have the information and the supporting reference, but the infobox just has a summary of the information with no need for a supporting reference — GhostInTheMachine ^{talk to me} 16:30, 24 May 2026 (UTC)

Oppose. Since it's BLP, it's better to include a citation in order to avoid possible future disruptions. The policy has been working till now quite good. ~2026-31115-98 (talk) 20:21, 24 May 2026 (UTC) Blocked sockpuppet of User:Guxhuli. – Demetrios1993 (talk) 13:04, 14 June 2026 (UTC)

I agree; having a redundant citation helps prevent editors from changing the citizenship to an incorrect value, and makes it easier to verify what is often a contentious or complicated claim. -- Beland (talk) 16:52, 27 May 2026 (UTC)

Though I can see why a clarification is called for; I would add ", regardless of whether it is cited elsewhere in the article". -- Beland (talk) 16:56, 27 May 2026 (UTC)

MOS:INFOBOXREF already makes reference to WP:MINREF, which covers the case of contentious material requiring an inline citation. We are not talking about that though. The question is whether every mention of a citizenship in BLP infoboxes should be accompanied with an inline citation? If the answer is yes, then why not include an inline citation for literally every other detail in the infobox, and disregard MOS:INFOBOXREF altogether when it comes to BLPs? I would rephrase the proposed change into the following:

• Unless already cited elsewhere in the article, include an inline citation to a reliable source; especially for contentious material in biographies of living people.

This doesn't create confusion, and is in line with other related guidelines. – Demetrios1993 (talk) 13:04, 14 June 2026 (UTC)

I would prefer to have a redundant citation, and I'm open to having redundant citations for everything covered by BLPs. It would make infoboxes a lot easier to fact-check on the articles that most need correct facts. -- Beland (talk) 17:10, 14 June 2026 (UTC)

Hi @Beland. The only reason this guideline bothers this user is the article Pyrros Dimas. If you look at their recent edit on the article, the Infobox was updated according to the guidelines specified here. Not only they removed the inline citation about Albania, but even the year when he acquired greek citizenship. Furthermore they replaced the countries with a demonym which is against the guideline. They even put greek first, despite the Person having Albanian as their first citizenship. Before that the nationality fueld was used, which also shouldn't be used. There is clearly a hidden agenda here. ~2026-35123-07 (talk) 19:40, 14 June 2026 (UTC)

Two Corrections:

If you look at their recent edit on the article, the Infobox was PREVIOUSLY updated according to the guidelines specified here.

Before that the nationality FIELD was used, which also shouldn't be used.

@Beland ~2026-35123-07 (talk) 19:46, 14 June 2026 (UTC)

This sounds like a personal attack and failure to assume good faith. Disallowing people who have a pre-existing opinion from participating in the discussion about the merits of a question also seems profoundly unproductive. -- Beland (talk) 19:46, 14 June 2026 (UTC)

Either that or just applying logic to a situation. The edits from the blocked user were done according to the existing policy. Is seems that the undoing was done just because they don't like the edits. ~2026-35123-07 (talk) 19:55, 14 June 2026 (UTC)

Above participant has been reported as a possible sockpuppet; see Wikipedia:Sockpuppet investigations/Guxhuli. -- Beland (talk) 20:34, 14 June 2026 (UTC)

This doesn't change the fact that I am correct in my arguments. ~2026-35123-07 (talk) 20:38, 14 June 2026 (UTC)

A personal attack is not an argument, and the history of edits on a single biography has no bearing on how the correctly identified conflict between these two guidelines should be resolved. -- Beland (talk) 22:03, 14 June 2026 (UTC)

My arguments were not only the personal attack, which I don't even consider one but just pure facts. I explained pretty well how the editor has a problem with a guideline that is literally applied withot any issue by every other BLP article on wikipedia. Even without the inline citation one can see that the editor is not respecting NPOV but rather a nationalist greeek view. ~2026-35123-07 (talk) 23:31, 14 June 2026 (UTC)

This is just more personal attacks. I'm not going to respond to further messages from this account, which I expect to be blocked shortly. -- Beland (talk) 23:41, 14 June 2026 (UTC)

So, explain me, why should greek come before Albanian in the infobox of the article? Where is the personal attack here? And why is it ok to be a demonym and not a country like your highness has himself written? ~2026-35123-07 (talk) 23:59, 14 June 2026 (UTC)

If we had redundant citations in the infobox, should they be citations that are also used in the article proper? I'm queasy about using different ones and the possibility of differing claims. NebY (talk) 19:53, 14 June 2026 (UTC)

Yes, they should be citations to the same sources, and indeed the same footnotes. -- Beland (talk) 20:35, 14 June 2026 (UTC)

Template talk:Infobox military conflict#RfC to deprecate collages in conflict infoboxes

Please see subject discussion. Cinderella157 (talk) 22:34, 28 May 2026 (UTC)

Proposal to add text to MOS:INFOBOXNAME

I would like to propose adding the following text to the section Consistency between infoboxes.

Whenever possible data parameters should line up with the label that is displaying them. For example if the label is |label1=Full name, the parameter supplied to |data1= should be {{{full_name}}} and not some value such as {{{other_name}}}.

The goal of adding this text is to avoid what essentially amounts to a variant of MOS:EASTEREGG where you have, for example, a value |predecessor= that when used has a label that is "Preceded by". I would expect that a label "Proceeded by" would have a parameter |proceeded_by= and that |predecessor= would produce a label of "Predecessor". Another common variant I've seen of this issue is |url= or |homepage= that produce the label "Website".

Is there any objection to adding this text? Zackmann (^{Talk to me}/_{What I been doing}) 04:20, 9 June 2026 (UTC)

So many infoboxes, so little time. --Redrose64 🌹 (talk) 13:15, 9 June 2026 (UTC)

@Redrose64: while I agree with the comment in spirit, not sure what you mean here? Do you have any opinion on whether this is a fair MOS addition? Zackmann (^{Talk to me}/_{What I been doing}) 16:16, 9 June 2026 (UTC)

I think you're suggesting that parameter names should match the labels shown to readers, and vice versa. Wouldn't that freeze aspects of infobox design? We might all agree that there's a far better label for a parameter but now be unable to change it, because your new rule would require us to change the parameter name and so we'd have to change tens, hundreds, or tens of thousands of instances in articles. Or maybe you're suggesting something else? NebY (talk) 16:33, 9 June 2026 (UTC)

@NebY: You are partially correct. My goal is that (as I say) whenver possible (as you say) parameter names should match the labels shown to readers, and vice versa. I do not thing that this would automatically apply retroactively and require us to redo every Infobox on wikipedia. However, if and when someone is creating a new Infobox, or overhauling an existing Infobox, there would now be something in the MOS saying "hey this is the best practice". There will always be exceptions. The most notable one that comes to mind is the fact that |birth_name=, |birth_date= & |birth_place= all appear under the label "Born". This is why I am proposing the text Whenever possible.... I am not married to the exact verbiage of my proposal so if you think there is a more eloquent way to write this I am 100% open to that! Zackmann (^{Talk to me}/_{What I been doing}) 16:38, 9 June 2026 (UTC)

Thanks for the clarification. I didn't imagine that you wanted it to apply retroactively but your rule would still militate against improving in-use infobox labels. "Whenever possible" has just that effect; it's always possible to leave the bad or suboptimal label in place and not improve the infobox design. NebY (talk) 16:55, 9 June 2026 (UTC)

Exactly. I am doing a side project of cleaning up lots of infoboxes such that parameters conform to MOS:INFOBOXNAME, eliminating CamelCase parameters or those |with spaces= and this new proposal is one of the many things I am also trying to do as part of that process. I guess I also want to make sure this is, in fact, something we all agree is good to do when possible/practical. Will it apply 100% across the board? No way. But if we can make it best practice.... Zackmann (^{Talk to me}/_{What I been doing}) 17:00, 9 June 2026 (UTC)

What do you think about "It is preferable that" instead of "Whenever possible...should"? How prescriptive should we be, and how proactive should editors be about changing from one parameter name to another, or defining parameter aliases? TheFeds 20:42, 11 June 2026 (UTC)

@TheFeds: Either verbiage works for me. I guess my point is that it doesn't always make sense for them to match. As with the example above, |birth_name= and |birth_date= both appear under the label "Born". But I am hoping to avoid cases where you have:

| label1 = Foundation
| data1  = {{{founded|}}} 
| label2 = Ceased operation
| data2  = {{{closed|}}}

These are basically variants on WP:EASTEREGGs. If I supply a value |closed=2020 I would expect it to show up as "Closed: 2020", not "Ceased operation: 2020". As for being proactive about changing from one parameter name to another, that is for each editor to decide whether they want to take it on. In the above example, the problem could easily be resolved by changing the labels to "Founded" and "Closed", however if label2 really does mean "Ceased operation" and not "Closed", then the parameter should be deprecated and replaced in the long run.

To be clear, I do not see this new bullet point in the MOS as a trigger to have to redo every single Infobox on EnWiki... But, if someone creates a new Infobox or adds a new parameter, this is IMHO a good best practice to follow. --Zackmann (^{Talk to me}/_{What I been doing}) 20:52, 11 June 2026 (UTC)

That's reasonable, and my feeling is that (as a suggestion rather than a rule) editors ought to consider other editors' mental models for the template, and provide graceful fallback options for old parameter name usage, as in {{{closed|{{{ceased_operation|}}}}}}. I know, that might mean supporting uglier alternatives for a long time, but until a discussion aimed at consensus occurs, it's probably for the best. TheFeds 21:59, 11 June 2026 (UTC)

So if you are going to do that, you need to, at the very least, do {{if empty|{{{closed|}}}|{{{ceased_operation|}}}}}. Failing to use {{if empty}} means that in the example you gave, if you supply values for both closed and ceased operation even if |closed=null, |ceased_operation=2020 will not display. Additionally, it is important to recognize that you have no introduced conflicting parameters that will cause issues if both parameters are supplied. Zackmann (^{Talk to me}/_{What I been doing}) 22:11, 11 June 2026 (UTC)

Discussion at Wikipedia:Village pump (miscellaneous) § RFC: Alma mater vs Education in Infoboxes

 You are invited to join the discussion at Wikipedia:Village pump (miscellaneous) § RFC: Alma mater vs Education in Infoboxes. —Myceteae‍🌈 (talk) 23:34, 13 June 2026 (UTC)

This RFC concerns the use of the |education= and |alma_mater infobox parameters. MOS:INFOEDU is the section of the MOS that addresses usage of these parameters. —Myceteae‍🌈 (talk) 23:36, 13 June 2026 (UTC)