Manual of Style

This page falls within the scope of the Wikipedia:Manual of Style, a collaborative effort focused on enhancing clarity, consistency, and cohesiveness across the Manual of Style (MoS) guidelines by addressing inconsistencies, refining language, and integrating guidance effectively.Manual of StyleWikipedia:WikiProject Manual of StyleTemplate:WikiProject Manual of StyleManual of Style articles This page falls under the contentious topics procedure and is given additional attention, as it closely associated to the English Wikipedia Manual of Style, and the article titles policy. Both areas are subjects of debate. Contributors are urged to review the awareness criteria carefully and exercise caution when editing. For information on Wikipedia's approach to the establishment of new policies and guidelines, refer to WP:PROPOSAL. Additionally, guidance on how to contribute to the development and revision of Wikipedia policies of Wikipedia's policy and guideline documents is available, offering valuable insights and recommendations.

Archives

Archive 1 Archive 2 Archive 3 Archive 4 Archive 5 Archive 6 Archive 7 Archive 8 Archive 9 Archive 10 Archive 11 Archive 12 Archive 13 Archive 14 Archive 15 Archive 16 Archive 17 Archive 18

This page has archives. Sections older than 90 days may be automatically archived by Lowercase sigmabot III when more than 4 sections are present.

Hello,

you are invited to participate at this discussion. Regards.--Tomcat (7) 13:25, 11 October 2012 (UTC)[reply]

A bot archived a previous message http://en.wikipedia.org/w/index.php?title=Wikipedia_talk%3AManual_of_Style%2FInfoboxes&diff=517335322&oldid=517196901

As the addition has been in the MOS for a while with no objections I have removed the 'proposed' tag from the main page diff .Oranjblud (talk) 12:08, 20 October 2012 (UTC)[reply]

At MOS:INFOBOX#Consistency between infoboxes, bullet 8 says "Multi-word parameter names should be separated with spaces, thus: |first second=". I looked at the popular templates {{Infobox person}}, {{Infobox country}}, {{Infobox city}}, {{Infobox football team}} and each has two (or more) word parameters that are sep'd by underscores, not spaces. Should this point be changed or removed? —[AlanM1(talk)]— 05:05, 20 December 2012 (UTC)[reply]

I'd say so. I raised this point here in October 2011, in conjunction with discussion at Parameter naming standards for Infobox person. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:35, 29 December 2012 (UTC)[reply]

The text:

Using an infobox also makes the data within it available to third party re-users such as DBpedia in a granular, machine readable format, often using microformats.

has been removed, because:

it's not the infobox that facilitates this, it's the classes within the infobox

This is ridiculous; the text should be restored. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:31, 8 January 2013 (UTC)[reply]

so explain how an infobox generates metadata without any additional microformat classes, and explain how a navbox or table with microformat classes does not generate metadata. it seems as though the microformat classes are the distinguishing characteristic here, not the fact that it is an infobox. Frietjes (talk) 19:28, 14 February 2013 (UTC)[reply]

DBpedia doesn't rely on the classes (though it may use them) for the extraction of metadata from infoboxes. An infobox, including the classes that are part of it can generate metadata available to other re-users. That's why the wording says "often", not "always". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:59, 14 February 2013 (UTC)[reply]

so, DBpedia doesn't parse {{persondata}} or any other part of the article? again, it appears that the fact that it is an infobox isn't what makes it able to be parsed, it is the use of a common structured presentation of data. Frietjes (talk) 20:06, 14 February 2013 (UTC)[reply]

Where did I say anything about Persondata? Again: DBpedia parses infoboxes. It may or may not make use of microformat classes when it does so, but it does not rely solely on them. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:43, 14 February 2013 (UTC)[reply]

again, I do not believe the statement, "using an infobox also makes the data within it available to third party re-users such as DBpedia", is entirely true. it is not the fact that the data is in an infobox that makes it available to DBpedia. if you look at the DBpedia content you will see that it has plenty of data that does not come from the infobox. so the infobox is not the reason why the information is available. Frietjes (talk) 22:10, 14 February 2013 (UTC)[reply]

The statement does not say that the infobox is the only place from which DBpedia extracts data. The presence on DBpedia of some data that is not from an en.Wikipedia infobox does not mean that DBpedia does not use our infoboxes; it does. Note also "such as". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:42, 14 February 2013 (UTC)[reply]

the statement is misleading, and should be either reworded or removed as off-topic. Frietjes (talk) 00:06, 15 February 2013 (UTC)[reply]

The statement does not mislead. It is entirely factual and accurate. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 00:12, 15 February 2013 (UTC)[reply]

I have to say I agree with IllaZilla and Frietjes that this doesn't belong in the purpose section. Thanks! Plastikspork _―Œ^(talk) 23:37, 16 February 2013 (UTC)[reply]

Why, when it is one of the purposes of infoboxes? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 00:03, 17 February 2013 (UTC)[reply]

I disagree that it is one of the purposes. Clearly third-party databases can harvest information from articles without infoboxes, so this is not really the purpose of an infobox. Any undergraduate computer science student familiar with natural language processing could write a program to parse prose. Most of the information is in the article in multiple places. For example, for people, we have birth/death information in the infobox, in the prose, in the persondata, and in the categories. All of these sources can be parsed by a computer, so if we are worried about making our content machine readable, we shouldn't be overly concerned about infoboxes. There are very good reasons for infoboxes, but this is not the real purpose. The real purpose is to present information in a concise format for our readers. Thanks! Plastikspork _―Œ^(talk) 00:28, 17 February 2013 (UTC)[reply]

What third-party databases can do is immaterial; that they do use infoboxes is irrefutable; as is that many of our infoboxes do emit metadata via microformats. That infoboxes are useful to humans in the way that they present information is not disputed; that is one of their purposes, but it is not the only one. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:01, 19 February 2013 (UTC)[reply]

they use the entire article, not just the infobox. hence, this is not a purpose of the infobox. Frietjes (talk) 16:39, 19 February 2013 (UTC)[reply]

They may use other things also; but they specifically use our infoboxes. I'm not sure why this is unclear to you: our article says so, as does their documentation. Nor are they the only users of the metadata emitted by our infoboxes. You've again removed the section under discussion, while noting that it is being discussed. Why could you not wait until we have consensus? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:10, 19 February 2013 (UTC)[reply]

you appear to be the only one arguing for the addition of this statement. and no, most third party sites don't specifically use our infoboxes, they specifically use the entire article which includes the infobox, the categories, any other tables, and the prose. Frietjes (talk) 17:45, 19 February 2013 (UTC)[reply]

And there s only you and one other arguing against it. Wikipedia is not, as I'm sure you're aware, a democracy. Where did I say anything about "most third party sites"? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:55, 19 February 2013 (UTC)[reply]

of course you conveniently forgot Plastikspork, who commented in this thread, and IllaZilla who reverted your edits. Frietjes (talk) 21:47, 6 March 2013 (UTC)[reply]

A small number of editors insist on hiding infoboxes inside collapsed sections; or moving them to the foot of articles. Recent examples include:

• Peter Planyavsky
• Little Moreton Hall
• Renaissance Theatre Company
• Montacute House
• Cathedral of Blessed Mother Teresa in Pristina

Is this acceptable? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:15, 6 March 2013 (UTC)[reply]

I think this is a not a good idea. Jweiss11 (talk) 18:17, 6 March 2013 (UTC)[reply]

It can be a good idea, where there is objection to a conventional infobox, and is likely to become increasingly useful, as infoboxes are loaded up with less important data that is excessive at the top of the page. Johnbod (talk) 18:22, 6 March 2013 (UTC)[reply]

It sounds to me like you might have a misconception about Wikidata does or will do. --Izno (talk) 18:28, 6 March 2013 (UTC)[reply]

If there is an issue with too much data being loaded into infoboxes, then that's an issue to address for whomever (editors/project) that maintain the infobox to start trimming excessive data, or use means (as Izno notes with the video game template) to collapse less-critical data within the infobox but still have it there. --MASEM (t) 20:15, 6 March 2013 (UTC)[reply]

But that's inconsistent with the view expressed by Andy Mabbett that the purpose of infoxes is to emit metadata. Surely the more we have of that the better? George Ponderevo (talk) 23:05, 6 March 2013 (UTC)[reply]

the way to do this would be to add the option to add 'collapsible collapsed' to the class in {{infobox person}}, {{Infobox historic site}}, etc., not use some hack of div tags and html tables. Frietjes (talk) 18:22, 6 March 2013 (UTC)[reply]

That would be one approach, but another problem with infoboxes is that they constrain the size of a lead image, so the width of a collapsed/expanded infobox really ought to mirror the size of the lead image to make the alignment look decent. Not a massive problem I agree, but one that would need to be addressed. George Ponderevo (talk) 19:48, 6 March 2013 (UTC)[reply]

Where there is consensus to allow that option at the template page itself, yes. Such exists at Template:Infobox video game (though I don't agree with it). Otherwise, no. --Izno (talk) 18:26, 6 March 2013 (UTC)[reply]

• If there is no consensus either way for including an infobox, it seems like a reasonable compromise to me. If people want to see it they can click it; if javascript is turned off it expands by default anyway. Betty Logan (talk) 19:00, 6 March 2013 (UTC)[reply]
• I am completely against info boxes, except on pages requiring statistics (sports people who have done little else but get laid and kick/hit a ball) and mathematical, chemical and scientific type pages. On historical pages, especially buildings, info-boxes either over simplify or give false information. This is the best compromise that there's going to be and the only one that I will agree to.  Giano  19:20, 6 March 2013 (UTC)[reply]
• There have been arguments for years over whether infoboxes are appropriate for English country house articles, which is why this approach was introduced a few years ago into Montacute House and more recently into Little Moreton Hall, so this is an attempt to give the best of both worlds. Infoboxes are in general often too long anyway, and distort the article's layout, but anyone who wants to see it has only to make a single click. Also, it's not infrequently that case that for some articles, in particular short articles such as Pendine Museum of Speed, the infobox completely overwhelms the article if it's not collapsed. I really don't see the problem here, and I hope that other editors will pick up on this approach. Contrary to what Andy Mabbett claims, the infobox isn't hidden, it's simply collapsed. George Ponderevo (talk) 19:29, 6 March 2013 (UTC)[reply]

• The choice of whether to use an infobox or not is up to page editors, but if one is going to include data in collapsed infobox that otherwise would have gone in a top-of-page infobox, it is improper to hide that data as such. Either use the infobox and incorporate the data into that, or don't and put the data into the prose. --MASEM (t) 20:12, 6 March 2013 (UTC)[reply]

• On a properly written page (per MOS), the data is always already in the 'prose' - and should always be easily available in the lead section. This is why so many people don't see the need for an unsightly, misleading and distorting info-box just a few millimetres away.  Giano  21:21, 6 March 2013 (UTC)[reply]

Masem, a major function of an infobox is to provide metadata. That metadata is emitted whether the box is collapsed or uncollapsed, but not if the box does not exist (or at least not yet - possible improvements might resolve this). In cases where a normal infobox is undesirable or contested, this solution allows that metadata to be emitted while respecting the needs of the article. Nikkimaria (talk) 20:54, 6 March 2013 (UTC)[reply]

• I started the discussion at Talk:Montacute House#Infobox removal back in 2009 when an infobox which had existed in the article for over a year was removed. Just to reiterate a few of the points there... Discussion about the appearance being "messed up" by the infobox reflects a particular point of view. I am in favour of them and having watched many other users of wikipedia (mostly students) have noticed this is the first thing they look at - particularly when they are looking for a "quick fact". People use/read wikipedia in different ways, a 30 second, 3 minute and 30 minute version of information has been advocated as meeting the needs of different users (or the same user at different times) and therefore providing the information in different formats is helpful to them - why shouldn't we provide it? This may also relate to research on Generation X and Generation Y and the different ways in which they consume or use information. As there were strong objections to the infobox on Montacute House a compromise/consensus was reached to use the collapsed infobox, which existed without problem until last month, and I haven't seem any strong arguments against that consensus. My opinion is that we should include appropriate infoboxes where possible. If there are strong objections then the collapsed version provides the next best option. If this is best achieved by including 'collapsible collapsed' (or similar) in the syntax of the infobox rather than " some hack of div tags and html tables" then I don't see any problem with that (although the coding would be beyond me).— Rod ^talk 20:21, 6 March 2013 (UTC)[reply]

Agree with Rod; he and I have both heavily edited Montacute House (and keep a close eye on it) the collapsed info-box was a compromise that suited us both. Until I mentioned it last nonth as an example of a reasonable compromise which caused Andy Mabbett to go rabid, there were no problems with it for years.  Giano  21:26, 6 March 2013 (UTC)[reply]

• Very interesting solution for pages were an infobox is not really wanted. However accessibility is a concern - makes us have to click on "show" to see the info. As a person with a disability i see this a yet another obstacle that impedes me from seeing all. I have to (with great effort) try and get my mouse pointer on that very small "show" tab just to derive serviceable information from the infobox. That said its better then no info at all in this format.Moxy (talk) 20:24, 6 March 2013 (UTC)[reply]
  • I imagine there is probably a css or js solution to make collapsed infoboxes uncollapsed by default, but not make navboxes uncollapsed by default. and, at the same time, fix the print version. Frietjes (talk) 20:45, 6 March 2013 (UTC)[reply]
  • Articles on musical subjects already have "hidden data" in the form of boxes to click on to hear an audio clip. Do you equally see that as some kind of additional obstacle Moxy? And in the specific examples that triggered this discussion (Montacute House and Little Moreton Hall) what "serviceable information" do you find in the infobox that's not already available in the lead? George Ponderevo (talk) 21:34, 6 March 2013 (UTC)[reply]

Yes they are just as hard to access - the biggest obstacle I face on a daily biases is {{Navbox with collapsible groups}} sometimes I will have to click on 4 or 5 "shows" just to find one link. I have MS and my shaking is bad sometimes and makes it hard to stabilizes my mouse on the very very small "show" tabs. ... I also logout all the time when trying to press "my contributions" and "my watchlist" LOL.Moxy (talk) 01:13, 7 March 2013 (UTC)[reply]

• Ugly, just ugly. Not only how they all look – none look the same in a side-by-side comparison – but each of those {{hidden}} templates in the articles listed by Editor Andy Mabbett had to be individually crafted with CSS to get them to look as they do: ugly, just ugly. The purpose of a lot of Wikipedia's templates is to hide the details of implementation from the users and to present a uniform look-and-feel to the reader.

If we must to have collapsible info boxes, the collapse should be happening within the infobox. The lead image and its caption should be inside the infobox but not hidden when the infobox is collapsed.

And yeah, I'm in favor of non-collapsed infoboxes though I will admit that there are some that are a bit too cluttered. I am not in favor of wrapping infoboxes with {{hidden}} templates.

—Trappist the monk (talk) 20:53, 6 March 2013 (UTC)[reply]

• If we could just put this discussion to bed than we could very easily come up with a solution that doesn't require any manual tweaking, but until it is I for one am disinclined to put any effort into such a solution. George Ponderevo (talk) 21:29, 6 March 2013 (UTC)[reply]

Re Montacute House infobox - that's not a big infobox (nor cluttered either IMHO), this is a big infobox and on a Featured Article. If editors have problems with infobox style or layout that's a specific infobox problem not a generic problem with infoboxes. GraemeLeggett (talk) 21:04, 6 March 2013 (UTC)[reply]

That's another good example of where the infobox overwhelms the article, and at least a significant part of it ought to be collapsed by default. George Ponderevo (talk) 21:26, 6 March 2013 (UTC)[reply]

• I prefer an open infobox to one that is collapsed, per Moxy, but I prefer a collapsed one to none at all. --Gerda Arendt (talk) 21:17, 6 March 2013 (UTC)[reply]
• I am definitely against hidden boxes. They require javascript. They also have accessibility problems. They also make it unclear what should be printed. If there is too much stuff then the article is too big and should be split. Articles being too big is a real problem whatever some people with fast connections say. Dmcq (talk) 22:42, 6 March 2013 (UTC)[reply]

  If you've disabled javascript then you simply see the uncollapsed infobox, so what's the problem? And to repeat myself, the infoboxes aren't being hidden, they're simply being collapsed. George Ponderevo (talk) 22:59, 6 March 2013 (UTC)[reply]

• I am definitely against hidden infoboxes - they exist to provide a basic overview of pertinent details about the article subject for those editors who are looking for specific information - but I would love to see collapsible sections within some of the larger and more detailed infobox templates. VanIsaac_{WS Vex}^contribs 23:21, 6 March 2013 (UTC)[reply]

  They're not hidden, they're collapsed. What's the difference in your mind between collapsible sections in some of the ridiculously detailed infoboxes and coillapsing the infobox itself? In the specific examples that initiated this discussion, what information do you feel was "hidden" from you by collapsing the infoboxes? George Ponderevo (talk) 23:33, 6 March 2013 (UTC)[reply]

• (e/c * 2) Most of this problem has come about because (a) there is some kind of agreement (and I do not know whether it is any kind of official policy or not) that metadata should be "emitted" in some way; (b) we have an aggressive approach adopted to this by an enthusiast for metadata that has led to problems both in the past and currently, who, for reasons that are not explained, seems to act as if the only way metadata can be "emitted" is to place them in infoboxes (he is curiously silent when asked whether the *only* way metadata can be emitted is by placing them in infoboxes, though, in fact, the answer is "no"); (c) this then has the effect that the two are so firmly linked that if there is any kind of policy about metadata, then that policy drives an implicit policy about infoboxes. (d) This "enforcement of infoboxes by stealth" (for there is no other way to describe it, given the behaviour of some who aggressively plonk infobozes in articles where there is a history of extensive discussion leading to consensus, about their presence in those articles) causes drama, an antagonistic atmosphere, and other problems that, because of the way questions about metadata and infoboxes are answered, (or, in many cases, not answered), causes disruption. My attitude is that the editor responsible for this needs to back off a bit, and let people who have a more understanding and collaborative approach to editing wikipedia have a more prominent role. At the moment, infoboxes and metadata seem to be a "one man show", and that is therefore coloured by aggressive and uncollaborative behaviour on the part of the main editor involved. This editor has had a number of long-term bans from wikipedia, exactly for these reasons and is, arguably, still on "probation" for his problematic behaviour. You can see that I am not alone in this opinion, and ArbCom also agreed with these points in earlier incidents. You can follow the links and the pages that show, what action the community has taken against this editor in the past here. This discussion, initiated by that same editor, is just another incident involving the same issues, dragging in all kinds of editors who have views about infoboxes, solely because, at some point (though it is never made clear), there was a design decision to link metadata (that editor's particular little hobby-horse) with infoboxes. In fact, the whole drama should be defused by unlinking the two and not trying to enforce infoboxes on all articles "by stealth". Then the issue of "hidden infoboxes" (which really means "collapsed infoboxes") would be much defused. I speak as someone who is both in favour of metadata, and of infoboxes, but apparently who respects the views of other editors more than some in this debate.  DDStretch  (talk) 23:37, 6 March 2013 (UTC)[reply]

  Let me make it clear that I am in no way against infoboxes in general, but I am against their blanket application where they add very little if anything and impact an article's visual presentation, as in Montacute Hall, Little Moreton Hall, and the Pendle Museum of Speed. On the other hand I'm very much in favour of metadata, from which any number of potential infoboxes could be generated by whoever wanted to see them. What I'm very much against though is this dishonest argument that metadata is dependent on the presence of infoboxes, or that important information is somehow being hidden by collapsing an infobox. What we ought to be doing is to work on a standardised data dictionary, hopefully hosted by Wikidata, which could be used by the mythical visual editor and potentially infobox generators for those who wanted to see one, instead of all the hand-crafting of infoboxes that goes on now. And as I think I've said before, the metadata argument is essentially a dishonest one anyway, as there is no real sense in which the association of a label such as "governing body" with the value "National Trust" can be considered to be metadata. George Ponderevo (talk) 00:20, 7 March 2013 (UTC)[reply]