Cannabis Ruderalis

Content deleted Content added
→‎Uncontroversial topics that primarily use infoboxes: +* '''Academic journals, Magazines, Newspapers, Websites, Publishers'''
(4 intermediate revisions by the same user not shown)
Line 212: Line 212:
--><p>Your "experiment" isn't valid. "Why on earth is that?" has [[Fallacy of composition|an obvious answer]]: Infoboxes are for presentation of details about a particular notable instance, details not possessed by the general class. I.e., it would not be rational for {{tlx|Infobox person}} and {{tlx|Infobox cat breed}} to be at [[Person]] and [[Cat breed]], respectively, since neither page is about a particular person or cat breed. A more interesting and illuminating experience is to see what percentage of non-stub articles qualify for a particular topical infobox yet do not have one. It's small and shrinking. When you find a case that does't have one, you'll generally find the same usual suspects fighting against inclusion at that article or at the category/wikiproject level (despite ArbCom invalidating the latter approach). It's pretty rare to see an infobox discussion actually focus on whether the template adds sufficient value to that particular article, rather than how bad/great infoboxes are and related "we don't want them on {{em|our}} articles" stuff.</p><!--
--><p>Your "experiment" isn't valid. "Why on earth is that?" has [[Fallacy of composition|an obvious answer]]: Infoboxes are for presentation of details about a particular notable instance, details not possessed by the general class. I.e., it would not be rational for {{tlx|Infobox person}} and {{tlx|Infobox cat breed}} to be at [[Person]] and [[Cat breed]], respectively, since neither page is about a particular person or cat breed. A more interesting and illuminating experience is to see what percentage of non-stub articles qualify for a particular topical infobox yet do not have one. It's small and shrinking. When you find a case that does't have one, you'll generally find the same usual suspects fighting against inclusion at that article or at the category/wikiproject level (despite ArbCom invalidating the latter approach). It's pretty rare to see an infobox discussion actually focus on whether the template adds sufficient value to that particular article, rather than how bad/great infoboxes are and related "we don't want them on {{em|our}} articles" stuff.</p><!--
--><p>I have a strong suspicion that lack of infoboxes on well-developed articles is a lost cause in the long run, unless we do something here. More editors support their inclusion, as a general matter, than oppose them. One of the reasons I opened this big meta-thread is that there can be legit arguments against infoboxes at particular articles and types of articles (defined multiple ways), but they generally get drowned out by "all i-boxes are great/terrible" battelgrounding. If some kind of criteria aren't reached, the likely result is the battlegrounding continuing until we can't take it any more, then a simplistic vote-type RfC on whether to make infoboxes a default feature, and the outcome would be "yes" without much room for nuanced arguments. At some point the disruption will force the community's hand, unless the disruption is short-circuited by something like some inclusion criteria (whether detailed and topical, or just general-principles stuff).<br /><span style="white-space:nowrap;font-family:'Trebuchet MS'"> — [[User:SMcCandlish|'''SMcCandlish''']] [[User talk:SMcCandlish|☏]] [[Special:Contributions/SMcCandlish|¢]] 😼 </span> 00:18, 10 July 2018 (UTC)</p>
--><p>I have a strong suspicion that lack of infoboxes on well-developed articles is a lost cause in the long run, unless we do something here. More editors support their inclusion, as a general matter, than oppose them. One of the reasons I opened this big meta-thread is that there can be legit arguments against infoboxes at particular articles and types of articles (defined multiple ways), but they generally get drowned out by "all i-boxes are great/terrible" battelgrounding. If some kind of criteria aren't reached, the likely result is the battlegrounding continuing until we can't take it any more, then a simplistic vote-type RfC on whether to make infoboxes a default feature, and the outcome would be "yes" without much room for nuanced arguments. At some point the disruption will force the community's hand, unless the disruption is short-circuited by something like some inclusion criteria (whether detailed and topical, or just general-principles stuff).<br /><span style="white-space:nowrap;font-family:'Trebuchet MS'"> — [[User:SMcCandlish|'''SMcCandlish''']] [[User talk:SMcCandlish|☏]] [[Special:Contributions/SMcCandlish|¢]] 😼 </span> 00:18, 10 July 2018 (UTC)</p>
::::::My experiment was perfectly valid; the point was not that [[Cat breed]] doesn't have {{tlx|Infobox cat breed}}, but that doesn't have any infobox at all - in theory (and probably in RexxS's mind) it could have {{tlx|Infobox breeds of animals}} or something, but it doesn't, because it is unlikely the box would say anything useful. In the same way [[School]] might have a {{tlx|Type of institution}} infobox, but it doesn't, nor do either infoboxes seem to exist. As you leave the level of discrete things, and ascend to more a conceptual level, the utility of infoboxes falls away. But I am glad you recognise that the type of article is a key factor. As I said above, my clear perception (doing a lot of editing in some of the more contentious areas) is that the general level of rowing is greatly reduced, which is why I am dubious we should respond to Arbcom's call. But if we do, I think recognising that one size won't fit all is the way forward. [[User:Johnbod|Johnbod]] ([[User talk:Johnbod|talk]]) 00:43, 10 July 2018 (UTC)


=== Styling criteria the MOS could stipulate ===
=== Styling criteria the MOS could stipulate ===

Revision as of 00:48, 10 July 2018

Suggested width

According to the Consistency between infoboxes section: A width of 22 ems (22em in CSS) is suggested... How does one check to see if an infobox complies with this?--Gibson Flying V (talk) 04:09, 20 February 2018 (UTC)[reply]

User:Thumperward, User:Plastikspork and User:PC78, in light of your input at Wikipedia_talk:Manual_of_Style/Infoboxes/Archive_5#Recommended_width, perhaps you could help with an answer to this?--Gibson Flying V (talk) 20:28, 24 February 2018 (UTC)[reply]
Fixing the ping to User:Plastikspork and User:PC78 -- John of Reading (talk) 07:42, 25 February 2018 (UTC)[reply]
Gibson Flying V, if you use {{infobox}} then it the default, and is only different if you override it, or put big image in it, or something else. Another way to check is to look at the page source and search for the 'width' inline css statement. Thanks! Plastikspork ―Œ(talk) 03:22, 28 February 2018 (UTC)[reply]
Thanks, User:Plastikspork. But I'm not having any luck with that. The infobox I'm trying to check is {{Infobox rugby league biography}}.--Gibson Flying V (talk) 02:06, 22 March 2018 (UTC)[reply]
Gibson Flying V, if you look at the source code for that infobox, you will find bodystyle = width: 25em, so it is overriding the default. Thanks! Plastikspork ―Œ(talk) 02:53, 22 March 2018 (UTC)[reply]
Oh gosh. Silly me. It's like the first tab at the top. Don't know why I missed that. Thanks!--Gibson Flying V (talk) 03:02, 22 March 2018 (UTC)[reply]

Editing an Infobox

I am trying to learn how to make some edits to the Template:Infobox Province of China (PRC). I want to add the category "|HighestPoint =". Do you know anyone that edits infoboxes that can help me add this to the Province of China Infobox? I have never added a parameter to an infobox and don't want to simultaneously screw up the infoboxes of every province in China. Thanks for any help. Geographyinitiative (talk) 12:25, 7 April 2018 (UTC)[reply]

This is, I think, the wrong venue. This talk page is for the discussion of issues related to the infobox portion of the Manual of Style. The proper venue to gain consensus for your proposed change is at Template talk:Infobox Province of China (PRC), where, I see, you have already started a discussion. One discussion in one place.
Trappist the monk (talk) 13:38, 7 April 2018 (UTC)[reply]

An RfC on the use of Wikidata in infoboxes has just started. Please !vote and/or comment on the RfC page. --Moxy (talk) 18:00, 7 April 2018 (UTC)[reply]

ArbCom wants there to be an RfC and the drafting of infobox inclusion criteria

Twice (at WP:ARBINFOBOX and WP:ARBINFOBOX2 the WP:Arbitration Committee has stated that the community needs to hold an RfC on what to about infoboxes, because "use of infoboxes is neither required nor prohibited" isn't helping and just seems to cause circular, endless page-by-page and sometimes category-by-category fighting. I'm not sure what this RfC should say, but we've been directed to try to draft some kind of "when an infobox should/shouldn't be included" guideline. The community is actually pretty good at that sort of thing; we have all kinds rules about proper categorization, navbox templating, lead content, etc. Whatever is drafted should be proposed at the Village Pump, since it's a site-wide matter.

However, this need for a draft infobox inclusion guideline points out another long-standing problem: Infoboxes are mostly not a style matter, but a content one. We need to split this page into WP:Infoboxes (WP:INFOBOX) and WP:Manual of Style/Infoboxes (or perhaps just WP:Manual of Style/Layout#Infoboxes; MOS:INFOBOX either way), and separate the content material from the style material, the same as we have with other things. Needs to happen eventually, and I suspect the forthcoming inclusion criteria would be the central matter of a WP:INFOBOX content guideline, around which the other content-not-style material in the current page can be framed. PS: A literal page split might not be needed; WP:Stand-alone lists is a content, style, and naming conventions guideline, with different sections tagged with the right banner templates, and this seems to work fine, and is less bureaucratic than splitting the page. (It also matters for WP:AC/DS reasons; disruptive editing in style and naming discussions is subject to DS, while it is not with regard to content guidelines.)
 — SMcCandlish ¢ 😼  04:30, 8 July 2018 (UTC); revised: 23:35, 8 July 2018 (UTC)[reply]

  • I welcome clarification on infobox use. Recent debate over having two infoboxes in a very short article showed to me the ongoing issues with their use: see Talk:Green Party of England and Wales leadership election, 2018 and Green Party of England and Wales leadership election, 2016. Happy to input. Bondegezou (talk) 15:25, 8 July 2018 (UTC)[reply]
  • I'm puzzled by this: currently WP:ARCA does not contain the word "infobox", WP:ARBINFOBOX dates to 2013, and WP:ARBINFOBOX2 ran between January and March this year. I see no sign that "use of infoboxes is neither required nor prohibited" can or should be replaced. Actually I thought things have calmed down considerably, not least because some of the most vociferous "infoboxes everywhere" people are now more on Wikidata. I suggest you find something else to do over the summer. Johnbod (talk) 16:23, 8 July 2018 (UTC)[reply]
    Relax Johnbod; you needn't be puzzled at all (IMHO). The fact is: this discussion would have been served better if "don't template the regulars" had been the order of the day. You've certainly enough wiki-tenure to have seen the sign that it can, many times. Whether it should or not is a matter that we can decide, and if so, how to improve it as well. Your insight is sorely missed in answering the core questions raised by the OP. I hope you'll consider rededicating that part of yourself since you obviously have a great deal to potentially give.--John Cline (talk) 17:52, 8 July 2018 (UTC)[reply]
    No one said the wording should be replaced (though that might end up happening depending on what the eventual RfC/proposal results are); rather, that it causes circular dispute when there are no criteria for deciding whether a particular article should/shouldn't have an infobox). ARCA isn't archived in the straightforward way a lot of other process pages are (which is a major butt-pain when you're trying to find this stuff!), but rather under a case to which the request pertains. The recent ARCA in question has to be dug out of the page history, and can be found here, or where it has been archived under ARBINFOBOX (not ARBINFOBOX2, for some reason), here. I've added a link to it to my original post, above.  — SMcCandlish ¢ 😼  20:55, 8 July 2018 (UTC)[reply]
@SMcCandlish: The problem is that there really isn't an easy way to resolve anything with an RfC. While we could feasibly get a result saying all articles of X category should have an infobox, and all articles of Y category are exempt from this requirement, that really just puts us in the same position as now. The only area that I've seen controversy is generally with various biographical artist articles, so even if we could get agreement for all other types of articles having mandatory infoboxes, it isn't going to change the problematic ones. There is no chance of an RfC coming down with the decision that "articles of Z category should not have infoboxes", so really the only outcomes will be what we have now, or infoboxes being mandatory. Given this, it is natural for infobox opponents to consider any proposal for an RfC to be an attempt to force infoboxes down their throats. I am personally of the mind that having a very simple infobox doesn't cause any issues, helps to unify a cohesive look of Wikipedia, and also would result in less disruption if they were made mandatory for all articles (there would still be discussion about which parameters to include in infoboxes, but this is less disruptive than the repeated RfCs seen on some articles). While we might get a consensus for something like this, I doubt that it is going to happen. — Insertcleverphrasehere (or here) 21:14, 8 July 2018 (UTC)[reply]
You are right that only certain types of article raise disputes (though there are more than you mention). There are other types that almost always have them and others that almost always don't, both without friction. I don't see any reason why a result might not say all articles of X category should have an infobox, and all articles of Y category should not. But it would be tough getting there. Johnbod (talk) 21:51, 8 July 2018 (UTC)[reply]
(edit conflict) On this sort of thing, I quite agree with your opening statement. This needs to be a discussion about how we even get to criteria before there's any RfC on exact proposed criteria. I think the range of criteria would can consider, however, could obviate some of your concerns (which aren't just "your concerns", of course, but rather easily observable historical problems with the debate about infoboxes). In particular, approaching it from "my topic versus your topic" perspective has been the primary source of conflict, and has been the main thing that ArbCom has come down against (along with hammering on the civility problems that emerge from that kind of debate), while generally skirting the larger question because the community is sitting on its thumbs. I've long remained neutral on infoboxes (early on, I began being opposed, switched to being in favor, and for about a decade now have been listening to both sides, though I've !voted in favor of or against particular i-boxes at particular articles based on utility-to-reader analyses). In a sub-thread below, I'll suggest some initial criteria talking points when I'm done drafting them in a few minutes. Someone has to get the "meat" of the discussion cooking.  — SMcCandlish ¢ 😼  21:58, 8 July 2018 (UTC)[reply]
SMcCandlish, ARCAs that become motions end up as a link at the bottom of the main page of the corresponding case. See this section of the case and the link labeled motion. StarryGrandma (talk) 21:49, 8 July 2018 (UTC)[reply]
Yes, I know; I already linked this (just in a different format and also to the original diff at ARCA itself) in previous post.  — SMcCandlish ¢ 😼  21:58, 8 July 2018 (UTC)[reply]
Ok, now we've found it, can you quote the bit from it where "the WP:Arbitration Committee has stated that the community needs to hold an RfC on what to about infoboxes" as you say at the start of the section? I can't see one. WP:ARBINFOBOX2 has "The Arbitration Committee recommends that well-publicized community discussions 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 how those factors should be weighted" from this March. Johnbod (talk) 22:42, 8 July 2018 (UTC)[reply]
Please hold; the ARCA link is wrong. Let me dig up the right bit.  — SMcCandlish ¢ 😼  23:28, 8 July 2018 (UTC)[reply]
Never mind; it's just WP:ARBINFOBOX and WP:ARBINFOBOX2; the ARCA bit isn't relevant. I was thinking of another case (where WP:ARBAP and WP:ARBAP2 pre-date 2018, and new ARCA material this year had come up about the central issues still being ongoing). The more recent action about infoboxes at ArbCom is ARBINFOBOX2. Sorry about that. I'll revise the OP above to compensate. The material you quote from ARBINFOBOX2 is the meat of the matter, along with previous (less directive, more "hand-wringing") material in ARBINFOBOX: "Because there is no project-wide policy governing when infoboxes should be used, disagreements concerning their inclusion arise with some regularity ... too often the consensus-building process has broken down, in a fashion that has been extremely demoralizing to many editors. ... It is not clear how infobox disputes are to be resolved ... there is no default rule and no policy guidance for determining how the consensus is to be determined, so the dispute continues indefinitely".  — SMcCandlish ¢ 😼  23:35, 8 July 2018 (UTC)[reply]

Toward drafting criteria

We'll need to air out what kinds of criteria the community might want to contemplate before drafting any actual proposal. An initial list of ideas (and this is hardly exhaustive):

  1. Level of article development: Is there enough detail to create an infobox that wouldn't substantively just duplicate the article prose? This answer may be "no" for the average stub. This approach may not take into account the views of some editors that infoboxes are not appropriate at all for certain topics or certain kinds of topics.
  2. Article length: Related to but distinct from the above, especially for mobile users: Can an article be long enough that an infobox's bullet-point presentation is helpful, regardless of the number of templatable "factoids" that can be extracted from that content?
  3. Type of article and need for an abstract of details: In an article on a cell phone model, a city, a species, or an actor, readers are more likely to be looking for "vital statistics" than they are for someone notable only for one event, or a concept like rhoticity in English.
  4. Pan-category consistency: It may be jarring for readers to find infoboxes at most articles on biologists, but not for the one they're most interested in. A problem with this broad-consistency idea is that few articles are in just a single category (and fewer actually should be). This also relates to the ArbCom-rejected idea that wikiprojects get to decide whether infoboxes are used on a cross-topic basis (deemed to be against WP:CONLEVEL and WP:OWN policies); few articles are within the scope of a single wikiproject, either.
  5. Pan-category standard: In some cases – usually when the infobox provides a special feature like the taxonomy chart in {{Taxobox}} – all articles in a category (even a very large one like organisms) have an infobox, and this appears to be uncontroversial. Attempts to apply this model to other categories have often been highly controversial (e.g., the suggestion that articles on classical music composers all should/shouldn't have infoboxes). These sorts of disputes are the main ones (they're behind both of the ArbCom cases) and are most frequently about biographies. If we recognize that infobox inclusion/exclusion is standardized in certain cases in actual practice, how do we square this with ArbCom ruling against wikiprojects dictating inclusion/exclusion?
  6. Pan-topic consistency: A variant of the above approaches would be to consistently use/avoid infoboxes across an entire topical group of articles covered by a navigation box. This raises similar problems (many articles have more than one), plus the articles in a navbox may be of radically different kinds (bios, published works, concepts, locations, etc.).
  7. Hierarchical consistency: Another variant of this is the observation that hierarchical relationships tend more often to produce infoboxes (a politican under a government, a bishop under a church, a sportsperson under a team, a CEO under a company, a professor under a university) than in article about "independents" (film directors, artists, writers, etc.). This seems most commonly to affect bios. Is this a good idea? Is it just accident?
  8. The value added on a case-by-case basis: Are there cases where an infobox, even at a well-developed article of a sort that usually has one, isn't actually reader-helpful? Are there cases were even a tiny stub benefits from one (e.g. due to specific features of the box in question)? Previous debates suggest the answer to both questions is "yes". But how can this be encapsulated in inclusion criteria?
  9. Presence or absence of an infobox in the first post-stub revision: MOS:STYLEVAR defaults to this on any intractable style dispute, but only as a last resort. Is it very applicable here, given that the central concern is utility, and infoboxes are unlike, say, an argument about whether to use "next to" or "alongside" in a sentence? (The concept is sometimes misconceptualized as the preference of the first major contributor, which is a WP:OWN / WP:SUPERVOTE problem.) Other difficulties with this approach are that later changes to the article's scope and content could make an infobox much less or more attractive than it was early on; and infoboxes are primarily a content not style matter, and we do not apply such reasoning to content.
  10. The kind of information included (or, perhaps, what should be included) in an infobox: This is not very consistent. Some infoboxes generically summarize the article, while others have documentation limiting them to very specific data (e.g. only the first edition of a book, in {{Infobox novel}}). Should they be inconsistent in approach, or normalized, and what implications does this have for their inclusion at particular articles? The novel example is a case of limitation of scope of the template, while {{Taxobox}} is the addition of a feature not suited to prose (full phylogenetic tree), and these seem qualitatively different.
  11. Questionably valid reasons to include/exclude. Some arguments may be fallacious, such as "it's disrespectful to condense this person's life into an infobox", or "I want people to read the entire article so that they fully understand the topic."; on the other side of the coin, "this type of article always includes an infobox", and "infoboxes are always useful". Should we list a few common non-policy/guideline-based arguments?
  12. Collapsing, either whole boxes or sections of them; whether doing this serves the reader or the purpose of having an infobox, or is merely as a "compromise" between exclusion or inclusion of an infobox. However, it impacts accessibility.
  13. Number of items: Many editors feel that an infobox that consists simply of the article name and a few factoids adds little to the article. On the other hand, many editors feel that an infobox with 100+ items is a monstrosity that detracts from the readability of the article. Should we establish guidelines on how many fields an infobox should have?
  14. Location of infobox Should the infobox always be in the lead? What about situations where multiple infobox templates apply to an article? (eg: NFL player and US congressmen Jack Kemp)
  15. Inclusion of image(s) and/or map When should an image be included in an infobox? Should there be a limit on how many images are included? Should maps be counted as part of such a limit? (For example {{Infobox school}} frequently includes the school's logo and, an image of the school campus, and a map)
  16. Add probably several more ideas here. Feel free to just insert them directly into the list.

Meta questions:

  1. Should there be a general default? ArbCom has suggested that there should be (or at least that having one would reduce disputation). It's not clear if the community agrees with this, nor what that default would be if we did.
  2. Should we just make them a standard feature, absent a sold WP:IAR reason to exclude one? The majority of well-developed articles do in fact appear to have infoboxes. However, the above questions at least hint that they are not desirable in every single case and thus such a blanket rule might be WP:BUREAUCRACY.
  3. Should we just get rid of them? Not every experiment is a success, and various things that Wikipedia once deployed widely were eventually deemed to be bad ideas and removed (two obvious examples to old-timers are the use of spoiler alerts and wrappers in plot summaries, and the imposition of automated date formatting and linking).

The central question before us is this (assuming the community agrees with ArbCom that the current "use of infoboxes is neither required nor prohibited" is not working):
     How do we take the criteria we collectively decide matter for particular kinds of cases and compress them into a paragraph or bullet list of guideline wording, that will actually be better than the status quo of no criteria?
After some initial discussion, draft approaches to doing this for a future WP:VPPRO proposal should probably each be in its own section, if the discussion proceeds here to a drafting stage. Hopefully we can merge any conflicting approaches into a single cohesive proposal (perhaps with multiple options to choose from).

Posted originally by  — SMcCandlish ¢ 😼  22:11, 8 July 2018 (UTC) – with the explicit intent that people add to the lists as they see fit if this helps further the discussion. It could also be converted to a pro/con table, or whatever.[reply]

I added 2 points to the list from discussion below (hierarchical consistency, and kind-of-information concerns), and ArbCom's own main concern, the lack of a default. Collapsing has also been added. Some later additions include: questionably valid rationales, number of items, location of infobox, images/maps.  — SMcCandlish ¢ 😼  00:20, 10 July 2018 (UTC)[reply]
First of all, can we make a list of the current status quo in terms of where infoboxes are controversial, commonly used, or commonly not used (topics and types of articles/number of valid criteria etc)? From there we can build a picture of what we have currently, draft it as a guideline, and then decide if anything on that list needs changing. — Insertcleverphrasehere (or here) 22:24, 8 July 2018 (UTC)[reply]
I will add another consideration that I had thought of when the last batch of infobox wars came up , and that's how well the person falls into a "hierarchy" organization that an infobox readily serves. For example, a politican (as part of a government), a bishop (as part of a church), a professional athlete (as part of a team), a CEO (as part of a company), or a professor (as part of a university). Whereas where infoboxes tend not to be added are for those that do not readily fall into such hierarchies (film directors, artists, writers, etc.). The only bright line from this is that the infobox should be included when the person falls into a hierarchy; this should not mean that a person that doesn't fall into this case should not have an infobox, but it should not be demanded either. That doesn't solve all the problems, but this seems like the brightest line where we do include infoboxes without question. --Masem (t) 22:26, 8 July 2018 (UTC)[reply]
Wikipedia only has biographies? Johnbod (talk) 22:29, 8 July 2018 (UTC)[reply]
Perhaps what Masem may be getting at is that bios seem to be the ones where infoboxes are potentially controversial? I, too, would echo Insertcleverphrasehere's request for making a list of where infobox inclusion is controversial / used / not used. It would probably help in creating a guideline. Killiondude (talk) 22:41, 8 July 2018 (UTC)[reply]
Perhaps, but if he thinks that he is wrong. Musical and artistic works and movements produce at least as many disputes in my experience. Johnbod (talk) 22:45, 8 July 2018 (UTC)[reply]
The only infobox wars that I've seen get out of hand (to the point Arbcom intervention has come up before) have been on BLPs; I was not aware that non-BLPs had this though I don't doubt if any had happened there. --Masem (t) 23:51, 8 July 2018 (UTC)[reply]
People have spilt blood over infoboxes in classical music articles—WikiProject Classical music used to ban them entirely in their guidelines. Curly "JFC" Turkey 🍁 ¡gobble! 00:58, 9 July 2018 (UTC)[reply]
Anecdotally, infoboxes are seemingly not useful in some cases: I wrote Columbia-Southern Chemical Corporation then another editor added an infobox; I have never removed it (not worth a potential disagreement) but have always thought that it is not particularly appropriate or helpful. — Godsy (TALKCONT) 00:54, 9 July 2018 (UTC)[reply]
In that particular case I would agree and say that as it currently stands it is pretty useless. To me though it seems to be an example of an underutilised Infobox, which would be better suited by filling in more of the relevant fields rather than removing the IB. The main issue is with other types of articles where there really isn't much of import to say in an infobox (where I believe that there is a valid argument for no-infobox). I think that there is generally always enough information that could be filled into company infoboxes, even if it isn't always there right now (analogousto why we don't delete all short stub articles). — Insertcleverphrasehere (or here) 05:45, 9 July 2018 (UTC)[reply]
  • I don't know where this would fit in, but we should also discuss the kind of information to include in infoboxes. I stopped using them entirely for articles on novels when WikiProject novels insisted the information in novel infoboxes must be about the first edition (including first edition ISBN, cover image, and page count), rather than a general summary of the subject (which is the approach of virtually every other infobox on Wikipedia). Curly "JFC" Turkey 🍁 ¡gobble! 01:03, 9 July 2018 (UTC)[reply]
    Both that and your point above about classical music non-bios, plus the nature of the (mostly music-related) bio disputes that went to ArbCom, would seem to indicate that wikiprojects trying to make up "rules" (their page layout advice pages are essays, not guidelines) is a proximal cause of at least some types of this dispute. A point made below is that we might try to nail down what is already being done across what topics where something consistent is happening, then try to establish some specifics in WP:INFOBOX (an actual guideline) that covers these cases, in addition to some general principles. However, this seems like a lot of work, and it could also end up enshrining one particular view in a long-running dispute (e.g., composers again). Hopefully just figuring out general criteria will avoid that, perhaps if we also take note of "special use" infoboxes that do more than summarize the article (e.g. {{Taxobox}}, which was actually the original infobox). Some infoboxes are also straying into navbox territory (e.g., {{Infobox album}} has features for navigating between releases, including often with little album-cover pictures); this complicates things. And them doing nav things is not necessarily a good idea in the first place.  — SMcCandlish ¢ 😼  02:13, 9 July 2018 (UTC)[reply]
  • I find infoboxes useful. When I'm looking something up, I can quickly find some information I want: e.g. who directed this film, when was this person elected. And yet I hate infoboxes, or rather I hate the endless editing disputes they seem to produce. In my experience, those are more often not around whether to have an infobox or not, but about what should go in the infobox. I wonder whether it's not that we need more guidance on when to use infoboxes, but we need more guidance on what to do with infoboxes. My experience is of three sorts of generic problems:
    • Infobox bloat: despite existing guidance saying infoboxes should be short summaries of an article, we get increasingly large infoboxes. Examples would be Doctor Who, Salbutamol, Margaret Thatcher and French legislative election, 2017. Those are all quite well designed infoboxes full of information, but they're not short summaries. And not all the information seems that important. Compare the brief infobox for Led Zeppelin. These big infoboxes are not how infoboxes were initially conceived. Do we want large infoboxes or should that material be integrated back into the article? Is Wikipedia trying to write a set of articles, or a set of infoboxes? It sometimes feels like the latter.
    • Infobox importance: there is a certain fetishisation of infoboxes, as if they are the most important part of an article. People insist there must be an infobox as if that indicates a certain cachet, e.g. Talk:Green_Party_of_England_and_Wales_leadership_election,_2018#Inclusion_of_the_deputy_leadership_contest, which was about having a second infobox in a short article. There are endless disputes over what political parties to list in election infoboxes, e.g. Talk:United_Kingdom_general_election,_2017/Archive_5#Infobox_consensus_2017.
    • Infoboxes are bad at fuzzy situations: the nature of the infobox requires simple answers. Reality isn't always simple. Sometimes we're not certain about someone's date of birth. Or there's more than one way to define how many seats a party won. In article prose, the text can explain all that, but infoboxes generally display one thing. I often find myself to tell people to focus on explaining the uncertainty/fuzziness in the text, or to use a footnote in the infobox. But editors get very blinded by local rules for what must be shown how. For example, The Matrix lists the director of the film as The Wachowski Brothers, even though Wikipedia policy is to respect their self-identification as female: thus The Wachowski Brothers re-directs to The Wachowskis. But the local consensus is that the infobox must say the same as what the film credits say (even though this rule is not applied in other situations): see Talk:The_Matrix#Wachowskis. This is all much easier to handle in prose. Bondegezou (talk) 11:04, 9 July 2018 (UTC)[reply]
  • A rule of thumb I've often used is that the infobox should contain information that is essential for a concise summary of the subject—that is, the absence of these characteristics and facts would leave a significant gap in understanding or in traditional historical context (e.g. birth date / year of establishment / etc.). It's a subjective criterion, but one I have found useful in trying to frame the importance of including something in an infobox. isaacl (talk) 15:59, 9 July 2018 (UTC)[reply]

Alternate idea - do nothing

No one is perhaps a bigger proponent of infoboxes than me, but even I recognize that any attempt to lay out specific criteria for when an infobox must be included is foolhardy and limits the creative potential of the editors. We should be more open to new ideas and less hung-up on rigidly regulating aspects of presentation. A long time ago, we had no infoboxes, then someone tried one and it worked, so it was used in other articles, and usage grew... and now we've been asked by ArbCom to codify their usage. But who among us can say with certainty that infoboxes are the best way to present information in our articles? We should allow editors to continue to experiment with the format. Coming up with a rigid set of criteria under which we must require their use will stifle inventiveness. I say we, politely, decline this request from the ArbCom. -- Netoholic @ 02:40, 9 July 2018 (UTC)[reply]

  • Enthusiastic support. The less rigid our rules on presentation are, the more we have a chance to come up with creative improvements. Infoboxes are good ways to display information in some articles, but not in others (one classic case biographies of people notable in more than one field, or where parts of the infobox would need to contain disputed material with extensive annotations). Instead of forcing infoboxes on certain classes of articles (which then will require workarounds for the inherent weaknesses of infoboxes), we could just use what works in each case. —Kusma (t·c) 02:57, 9 July 2018 (UTC)[reply]
  • We're already doing nothing, and this has led to repeated ArbCom cases, otherwise productive editors being sanctioned (we may have lost a WP:FAC regular over this permanently) and ArbCom repeatedly asking the community to settle this. The fact that "forcing infoboxes on certain classes of articles" is problematic is part of the discussion, not a reason to not have the discussion.  — SMcCandlish ¢ 😼  03:06, 9 July 2018 (UTC)[reply]
    Those are behavioral concerns. We are allowed to say that the ArbCom may be wrong in asking for us to codify infoboxes, because we'll be sacrificing flexibility to maybe help with the bad behavior (but more likely, at best shift, the bad behavior or, at worst, even increase it). Infoboxes are already pervasive and we haven't needed to enforce their use to get them to be so. I for one want to see if any new ideas can come from freedom. -- Netoholic @ 03:23, 9 July 2018 (UTC)[reply]
    How would you codify such freedom? Doing nothing will not increase editorial freedom to do anything.--John Cline (talk) 04:33, 9 July 2018 (UTC)[reply]
    Right. The freedom Netoholic seeks is already the status quo, and is the cause of the perpetual conflict; it's a "Wild West" situation. The lack of criteria (or a default, or both) is the proximal cause of the round-and-round-and-round fighting over the matter. Maybe we need no default, and just criteria, I don't know. But we need something other than the unqualified, vague "maybe" of "is neither required nor prohibited".  — SMcCandlish ¢ 😼  05:07, 9 July 2018 (UTC)[reply]
  • No harm in a civil discussion and analysis. There is no proposal here yet, nothing to support or oppose, and you can't stop us from having a civil discussion and floating ideas. If you don't want to participate in the discussion, feel free to edit a different page. — Insertcleverphrasehere (or here) 05:48, 9 July 2018 (UTC)[reply]
  • Regardless, I integrated Netoholic and Kusma's "just do nothing"/"ArbCom is wrong" idea into the "The central question before us ..." line up top.  — SMcCandlish ¢ 😼  07:28, 9 July 2018 (UTC)[reply]
  • Support. We don't need more rules. Let it be decided by article. If the infobox is considered to add value to the article, let it stand. Natureium (talk) 14:31, 9 July 2018 (UTC)[reply]
  • Strongest possible support The status quo is fine. Headbomb {t · c · p · b} 00:31, 10 July 2018 (UTC)[reply]

Incomplete list of topics by controversy level

Below is start on a list of topic areas listed by category as 'uncontroversial', 'possibly controversial', and 'controversial'. Feel free to add more topics and examples. If you want to move a topic down to a more controversial category, please add links to articles where there have been disputes. Please help by filling in the list with more topics and examples. — Insertcleverphrasehere (or here) 06:13, 9 July 2018 (UTC)[reply]

Uncontroversial topics that primarily use infoboxes

  • Academic journals, Magazines, Newspapers, Websites, Publishers
  • Albums, singles, and bands: Albums, singles, and bands border on being navigation tools to help readers go from album to album, or song to singer, and might be considered generally essential.
  • Buildings including bridges - boy, do bridges have infoxes. Occasional disputes, as at Rialto Bridge.
  • Chemicals: Generally essential for high profile chemicals, and the chembox is generally used as a table of relevant attributes for the chemical in question.
  • Films, TV shows, and actors: Films, TV shows, and actors have nearly the same utility and needful purpose as the albums, singles and bands,
  • Human anatomical terms short boxes with standard codes and a picture: Interventricular septum
  • Taxonomy: Used for more than just info, could almost be considered "essential" as some of the information in Taxoboxes is generally not contained elsewhere in the article.
  • Countries, cities, provinces, et al.: generally full of stats.
  • Olympians and professional athletes:
  • Legislation, legislatures, and office holders (for all, individual examples; general articles have no box, eg Upper house, Statute of limitation)
  • Medical conditions and pharmaceutical drugs: Considerable discussion as to what should be included, beyond the standard medical codes
  • Politicians, some rows about including full details of offices held etc
  • Schools and colleges
  • Ships, planes, cars, motorbikes - anything manufactured multiply as a "model"
  • Software and video games
  • Sports teams
  • Musical compositions, especially Opera with the few exceptions where an article author is not in favour (French opera, operas by Handel), Choirs, Orchestras, individual performers in classical music (singers, players, conductors)

Uncontroversial topics that primarily omit infoboxes

Possibly controversial

  • Organizations: Infoboxes for companies, nonprofits, governments, and other organizations can generally be a convenient location for information that generally would not be naturally included in the prose, or might be awkward in the prose (i.e. parent company, website, logo, value, # of employees, etc), Example Apple Inc.. Some infoboxes that are nearly blank might be considered superfluous, and editors may disagree on whether the correct action in this case is filling in more information or removing the infobox.
  • Books: Some books have been controversial (examples?: ____, ____); historical works like On Virtue usually don't have infoboxes
  • Occupations some have boxes, like electrician, but these say nothing useful, and most don't (barber surgeon, groundworker). An example of infobox over-reach? Not aware of any actual rows, but this is a quiet area.
  • Scientists - the difficulty is what to usefully say, and whether some fields often used are accurate or sufficiently important
  • Authors

Controversial

  • Composers: Highly controversial whether composers should have infoboxes, the source of many spirited debates. (add examples here: ____, ____)
  • Film directors: Bios for some directors have become quite heated as well (i.e. Stanley Kubrick, ____, ____)
  • Works of visual art
  • Visual artists
  • Artistic movements
Allegedly controversial: composers

Perhaps let's have a look at examples:

All examples have in common that there are no traces of war ;) - The last controversity I was in was Pierre Boulez where I added a short infobox in 2016. Long discussion on the article talk and project composers. Why, I will never understand. Just to prevent people seeing basic facts at a glance that a good printed encyclopedia also provides at the beginning? --Gerda Arendt (talk) 07:18, 9 July 2018 (UTC)[reply]

Alma Mahler - none of these are mainly notable as composers - poor example. Mahler himself of course has no box. Johnbod (talk) 14:12, 9 July 2018 (UTC)[reply]
The lead describes Alma Mahler as a composer. All composers are also persons, most also musicians of some sort. What I want to illustrate is that it's a myth to think that there's a lot of controversy for classical composers, and all the people mentioned are good examples for that. Better no infobox and peace among editors, than the waste of time we sometimes had. I remember Bach (ibox) and Wagner (no ibox), but most composers peacefully have one, or not. There's even {{infobox classical composer}}, with 181 transclusions today, not counting those who come as infobox person or infobox musical artist. The 2010 suggestion of project composers to better not have an infobox for composers of classical music, mentioned in some hidden notices where someone would add an ibox, is not binding (which these hidden messages of course don't mention). --Gerda Arendt (talk) 14:42, 9 July 2018 (UTC)[reply]
"composer, author, editor and socialite", discreetly omitting "femme fatale" and given in reverse order of importance. It's still not a good example of anything. Johnbod (talk) 15:01, 9 July 2018 (UTC)[reply]

Alternative view: criteria are not practical

I've been a strong believer that adding an infobox to an article generally improves the article for multiple reasons. However, I have come to believe over many years of debate that numerous editors, whom I value, disagree with my view. They give less weight to certain advantages that infoboxes provide than I do, and more weight to other considerations. Consequently, I find there are are some realities that we must accept:

  1. The majority of articles on Wikipedia have infoboxes and there is a certain expectation on the part of readers and editors that an article should have one;
  2. It is possible for editors to disagree on the net value of an infobox without either side being objectively right or wrong;
  3. The disputes that have arisen, for example, in classical music composers or theatrical biographies are not because those topics are inherently less suitable to having an infobox, but because the editors most interested and hardest-working in those topics generally set a lower value on infoboxes;
  4. Many articles have editors who have invested a lot of time and care into them, and those editors attempt to steward those articles;
  5. Where those editors have chosen not to have an infobox, they consequently end up having to repeatedly justify that decision;

I have come to the view that the factors which need to be considered when deciding to have an infobox or not are: (1) numerous; (2) nuanced; and (3) often incapable of objective realisation. The human factor just has too great an effect. I started an essay some time ago at User:RexxS/Infobox factors which gives some further background, but is still incomplete, and may actually be incompletable.

I propose that we recognise that because of the complexity of the decision, it is not possible to produce a formula or algorithm to decide on whether an article, or group of articles should or shouldn't have an infobox. Instead we should promote goodwill and mutual understanding of each others' positions. We have a chance to make a paradigm shift in the way we reach decisions on this thorny topic. In the grand scheme of things, the presence or absence of an infobox ought not to be a big deal. --RexxS (talk) 18:48, 9 July 2018 (UTC)[reply]

I think this is wrong for various reasons - point 3 perhaps being the key. As the expanding section above demonstrates, there are types of articles where we normally have infoboxes, and types where we don't. There is absolutely no evidence that "there is a certain expectation on the part of readers" that all articles should have one, nor do I believe this is the case. The great majority of article types fall fairly neatly into one group or the other, but some types, for various reasons, get caught in the middle, and it is here that disputes are concentrated. The articles suited to infoboxes are about discrete things, whether people, places, taxa, events etc, where the important things to know about the subject are a) the same for other members of that class of thing, b) objective facts that are straightforward to verify, and c) clear and easy to state. The types of articles not suited to infoboxes are those where any of these three factors is not the case, which includes most articles on broader topics and concepts, but also some on things (like people of certain types). It is a particular feature of WP, considered as an encyclopaedia, that we are very strong on the former type, "thing" articles, of which we have vast numbers, but often very weak on articles on topics (many very obvious ones are completely missing) and concepts. Therefore most articles do indeed have infoboxes, but to conclude from this that all articles usefully can do so is an optical illusion. Mind you, busy editors who don't like researching and writing actual content (who increasingly seem to be the majority here) have typically filled up many sorts of non-infobox articles with other types of templates of the navbox or timeline sort. There are many good points made in your essay though. Johnbod (talk) 20:28, 9 July 2018 (UTC)[reply]
I agree with Johnbod that this alternative isn't workable, but for different reasons. It amounts to "Can't we all just get along?" with no substantive change to our approach. We already know for a fact that we can't just get along (or, rather, that certain otherwise productive editors can't). The usual response of "just topic-ban them from infoboxes" won't work, because there will always be more editors insistent that infoboxes should be on every article and others that infoboxes are trash, these extreme views are the source of most of the conflict, and they do not represent the views of the average editor (or reader).  — SMcCandlish ¢ 😼  20:54, 9 July 2018 (UTC)[reply]
I think the general view that all "infoboxes are trash" is vanishingly rare, and most supposedly "anti-infobox" editors have explicitly said in the past that they don't hold that at all - taxon boxes for example are surely entirely uncontroversial. I'm not even sure there are many editors (who have given the matter any thought) who really believe that all articles should have boxes. Disputes do in fact centre on a narrow range of types of article and if you want to actually achieve anything with this, it is best to concentrate on those and see if anything can be done bearing this in mind. Johnbod (talk) 23:47, 9 July 2018 (UTC)[reply]
@Johnbod: "As the expanding section above demonstrates, there are types of articles where we normally have infoboxes, and types where we don't." indeed - and that's not because the topics are somehow more or less suited to an infobox, but because the regular editors in those fields either like or dislike infoboxes, to put it bluntly.
Of course most bridges have infoboxes. One look at Wikipedia:WikiProject Bridges and Tunnels #To do, bullet point 4 ("Add {{Infobox bridge}} or {{Infobox tunnel}} to articles") will show you why.
Of course most classical composers don't have infoboxes. One look at Wikipedia:WikiProject Classical music/Guidelines #Biographical infoboxes ("current consensus among project participants holds that biographical infoboxes are often counterproductive on biographies of classical musicians ... and that they should not be used without first obtaining consensus on the article's talk page.") will show you why.
Can't you see what is obvious? It's the editors, not the topic that determines whether there is an infobox or not.
There is loads of evidence that casual editors (and by implication readers) expect an infobox; it's just that you don't want to admit it. Many's the time that I've looked at the latest outbreak of edit-warring on a composer's biography or that of an actor only to find that it was ignited by a new editor or a passing IP who expressed astonishment that the article had no infobox. If you tell me you haven't seen that, I just won't believe you.
Please understand that I'm not arguing here for an infobox where the regular editors don't want one. I certainly could produce the arguments, but I'm trying here to convince folks that they will never solve the problem by producing an ever-increasing list of instruction-creepy areas where we will have infoboxes and where we won't. You fundamentally misunderstand the nature of the problem and hence its solution.
YES, I am simply recommending "why can't we all get along", if you insist on putting it that way. I've seen good and productive editors like Andy, Gerda, and Cassianto sanctioned needlessly, and many other top-notch editors effectively retiring because of infobox disputes. Yet all it needs is some give-and-take on both sides to stop that from ever happening again.
Give up on trying to make categories of discrete things vs "most articles on broader topics and concepts". You've been banging that drum for years without being able to offer any help to those editing in the problematic areas. It's time to try something else, and you need to be looking at editor behaviour, not subject content. --RexxS (talk) 22:26, 9 July 2018 (UTC)[reply]
And why do these groups of editors have such different views? Can it possibly be because they know from experience that articles of a certain type do or do not benefit from boxes? What strange perversity in Wikipedia:WikiProject Classical music leads to articles on works and instruments almost always having boxes, but those by the same group of editors on composers and musical forms almost never having them (without any "guidelines" on either group). Most of the "usually without" set of types have no project instructions, and in fact rarely cause trouble. As an experiment take your favourite infobox "infobox:Foo" then see if the actual article "foo" has a box - typically it won't. Why on earth is that? Look at what's right in front of you! Johnbod (talk) 23:40, 9 July 2018 (UTC)[reply]
I agree with your general theme, but in fact quite a bit of special pleading does actually come out of WP:WPCLASSICAL, including strange, niggling insertions into style, naming, and other guidelines, and attempts to insert it into WP:AT policy itself. The general veracity of your observations doesn't preclude the possibility of unconstructive things coming from particular wikiprojects (more accurately: clusters of particular, like-minded editors at some wikiprojects – projects are not hive minds and sometimes have 100+ active participants). The centrality of classical composers and works in the worst of our "infobox wars" strongly suggests there is (or at least historically has been) such a problem. It's very similar to other issues that have arisen with wikiprojects that date back to the early days of Wikipedia and the wikiproject concept. Several of them have gotten locked into a kind of "we are a unique fiefdom, we own our articles, and we make up our own rules" mindset, which needs to be swept away like cobwebs.

Your "experiment" isn't valid. "Why on earth is that?" has an obvious answer: Infoboxes are for presentation of details about a particular notable instance, details not possessed by the general class. I.e., it would not be rational for {{Infobox person}} and {{Infobox cat breed}} to be at Person and Cat breed, respectively, since neither page is about a particular person or cat breed. A more interesting and illuminating experience is to see what percentage of non-stub articles qualify for a particular topical infobox yet do not have one. It's small and shrinking. When you find a case that does't have one, you'll generally find the same usual suspects fighting against inclusion at that article or at the category/wikiproject level (despite ArbCom invalidating the latter approach). It's pretty rare to see an infobox discussion actually focus on whether the template adds sufficient value to that particular article, rather than how bad/great infoboxes are and related "we don't want them on our articles" stuff.

I have a strong suspicion that lack of infoboxes on well-developed articles is a lost cause in the long run, unless we do something here. More editors support their inclusion, as a general matter, than oppose them. One of the reasons I opened this big meta-thread is that there can be legit arguments against infoboxes at particular articles and types of articles (defined multiple ways), but they generally get drowned out by "all i-boxes are great/terrible" battelgrounding. If some kind of criteria aren't reached, the likely result is the battlegrounding continuing until we can't take it any more, then a simplistic vote-type RfC on whether to make infoboxes a default feature, and the outcome would be "yes" without much room for nuanced arguments. At some point the disruption will force the community's hand, unless the disruption is short-circuited by something like some inclusion criteria (whether detailed and topical, or just general-principles stuff).
 — SMcCandlish ¢ 😼  00:18, 10 July 2018 (UTC)[reply]

My experiment was perfectly valid; the point was not that Cat breed doesn't have {{Infobox cat breed}}, but that doesn't have any infobox at all - in theory (and probably in RexxS's mind) it could have {{Infobox breeds of animals}} or something, but it doesn't, because it is unlikely the box would say anything useful. In the same way School might have a {{Type of institution}} infobox, but it doesn't, nor do either infoboxes seem to exist. As you leave the level of discrete things, and ascend to more a conceptual level, the utility of infoboxes falls away. But I am glad you recognise that the type of article is a key factor. As I said above, my clear perception (doing a lot of editing in some of the more contentious areas) is that the general level of rowing is greatly reduced, which is why I am dubious we should respond to Arbcom's call. But if we do, I think recognising that one size won't fit all is the way forward. Johnbod (talk) 00:43, 10 July 2018 (UTC)[reply]

Styling criteria the MOS could stipulate

Add MOS styling considerations that you want to discuss on the left margin of a new line to see if it's the stuff of good MOS guidance and/or add your comments from a bullet on the left margin of a new line under any of the stipulations where you wish to comment. Indent any comments you wish to make to any of the points made by another editor.

Unused parameters - Whether unused parameters should remain in an article's infobox or not could be delineated.

  • I believe unused parameters should not be left in an article's infobox. When desired for use, it's easy enough to manually import the parameter from the documentation subpage. The presence of blank parameters lends an impression that the information is needed as soon as possible.--John Cline (talk) 21:28, 9 July 2018 (UTC)[reply]
  • That's a practicality matter. Parameters that might be filled in at any time, because they could be applicable, should be left in, probably, while those that are not applicable, will not be applicable for the foreseeable future (e.g. |death= for a BLP), and any that are contentious (|religion= in the bio i-boxes that still support it, where it's reserved for religious leaders) should likely be removed. I just reverted someone the other day at a cat breed article removing parameters for links to breed standards at organizations that don't yet recognize the breed, because the recognition is very likely to come in the next few years, and the average editor will not know what parameters for which organizations are available at all if the blank ones are removed; they would have to go look up the codes in the template and are not likely to do so. By contrast, if we know someone doesn't/didn't have children or that their parents are unrecorded by history, no empty parameters should remain in the article for i-box factoids we can't fill in. I guess that could be compressed into a couple of bullet points as advice, but do people squabble about it enough that we should bother?  — SMcCandlish ¢ 😼  21:45, 9 July 2018 (UTC)[reply]
    I disagree a bit. A living person will die, and to have the coding of {{death date and age}} ready (and prepared by the birth date in it) might help at a time of stress. --Gerda Arendt (talk) 21:50, 9 July 2018 (UTC)[reply]

    I think we could fashion the guideline so as to treat a parameter like:

    |death date= <!-- {{Death date and age|YYYY|MM|DD|YYYY|MM|DD}} -->

    as not being empty by virtue of the HTML comment. This would give enough flexibility to allow an editor to retain certain unused parameters for good cause. And I agree that it should.--John Cline (talk) 22:38, 9 July 2018 (UTC)[reply]

Proportionality standards - Styling considerations can contain "infobox sprawl" and prevent it from undue domination of the article.

  • In my opinion, the infobox should not fall into the first section. I'd like to see a technical solution that automatically set overflow to vertical scrolling at the bottom of the TOC (if used).--John Cline (talk) 21:28, 9 July 2018 (UTC)[reply]
  • Whether it happens depends a lot on a reader's screen. --Gerda Arendt (talk) 21:35, 9 July 2018 (UTC)[reply]

Singular plural nouns - The MOS is a great place to depreciate the nonsense of rendering a man's wife as his Spouse(s), or his nicknames as his Nickname(s). It's way too easy to code the template so that one wife renders as his Spouse while two wives would render as his Spouses.

  • If we do nothing more than fix this one bit of malarkey, we will have done quite a bit. Many times over such molested grammar is featured on our pages; even on our featured pages.--John Cline (talk) 21:28, 9 July 2018 (UTC)[reply]
  • Support to drop the "(s)", keep simple. When there are two, a reader will understand ;) --Gerda Arendt (talk) 21:35, 9 July 2018 (UTC)[reply]
  • That's not an MoS matter, it's a template coding matter, probably only handleable by a conversion to WP:Lua (for ability to analyze the input for whether the data provided is a single value. Even this might not be practical because input may be comma-delimited, or wrapped in a template like {{unbulleted list}}. Another approach might be adding singular parameter, e.g. |spouse=, |spouses=.  — SMcCandlish ¢ 😼  21:45, 9 July 2018 (UTC)[reply]

Over-inclusion of details – a fairly common theme in infobox disputes is alleged triviality of included details, sometimes running to lengthy lists which are sometimes then pre-collapsed, which is an accessibility problem. We should address these matters directly, though in general terms about encyclopedic and contextual relevance – WP:NOT#INDISCRIMINATE, etc.

  • Support: Dealing with this would go a long way to resolving some (hardly all) of the complaints about infoboxes. A clear example of a problematic one is that at Sony Ten (and similar articles), crammed with local-station trivia, including both collapsed and uncollapsed lists. Collapse lists in particular should basically be banned per MOS:DONTHIDE. We permit it with navboxes because that feature itself is of low utility to mobile users and to users who need screenreaders or low-mobility pointing devices. That exception doesn't apply to infoboxes, which are heavily used by all categories of readers, right at the top of the page.  — SMcCandlish ¢ 😼  22:28, 9 July 2018 (UTC)[reply]


Leave a Reply