Wikipedia talk:Manual of Style/Infoboxes

Infobox length

The guidance on the Help:Infobox page says that Infoboxes should be "concise" and not "lengthy," but that guidance is open to interpretation. Some infoboxes have quite a bit of content. For example, the infobox for Pittsburgh stretches on for 2.5 pages on a regular-size computer screen. I've seen a number of editors on various talk pages (including this one) grumble about certain infoboxes becoming bloated.

My question is: How long is too long? There are clear policies for when an article is too big, and for when the lead is too long. Can we come up with some clear guidance on the suggested maximum length of an infobox? (PS - I left a similar note on the Help:Infobox talk page, but received no comments, so I though I'd try here). Barryjjoyce (talk) 01:17, 17 April 2014 (UTC)

I'm not sure what the role of that help page is (wrt length) when the community-agreed MOS guidance is here. This page says the role is "to summarize key facts that appear in the article. The less information it contains, the more effectively it serves that purpose". I have tried quoting this guidance to editors from Wikiprojects but they just don't want to listen. These are subject-enthusiasts who love every minute factoid. The reader of onion is presented with out-of-date historical synonyms -- Latin terms nobody uses. The reader of London King's Cross railway station is shown raw data of annual entry and exit stats over five years. In no stretch of understanding could these be considered key facts or summaries of information that appears in the article. So I don't think the problem is that MOS is unclear. I think the problem is that wikiprojects think they know better than MOS and they know better than the general reader. So WP ends up with articles with lead sections that contain information a handful of people in the world care about. And WP ends up with articles where the images people like to see accompany their text all get pushed down to make way for dry statistics. -- Colin°^Talk 07:06, 17 April 2014 (UTC)

The problem here would seem to be that the MoS is (or rather its authors are-) trying to dictate article content, rather than the more proper function of describing community norms. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:31, 17 April 2014 (UTC)

Nah. The community knows long infoboxes full of tedious shit is bad. The problem is Wikiprojects amplify the opinions of specialists and subject-nerds way above what the audience want. It wouldn't be an issue if people could go to articles and sort out the problem without being bullied by the wikiprojects telling them how it must be done. -- Colin°^Talk 18:08, 17 April 2014 (UTC)

Um, Colin, you are not correct on this the bullying tends to come from people who say things like "tedious shit" One person's "tedious shit" is another's critical data that would bog down the article if placed in narrative or even someone elses lifesaving data. Montanabw^(talk) 07:20, 22 April 2014 (UTC)

Wikiprojects, or specifically their members, are part of the community. It wouldn't be an issue if people could go to articles and sort out the problem without being bullied by MoS enforcers telling them how it must be done. But do share your evidence of what the audience want. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:05, 17 April 2014 (UTC)

Someone here seems unaware of W:LOCALCONSENSUS policy. Hint: It's not Colin. Wikiprojects too often forget that they are only part of the community and do not get to dictate content or formatting at articles they claim within their scope.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  20:37, 19 April 2014 (UTC)

I'm confident that my editing history is ample evidence that I'm well aware of LOCALCONSENSUS, having had my fingers burned trying to prevent it overriding wider consensus on more than one occasion. That does not mean that project members should be denied their voice as individuals. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:31, 20 April 2014 (UTC)

I can vouch for Andy's credentials in that respect, being more often on the other side of the argument. Equally, the tiny handful of editors who bother to follow the filibustering discussions here and on other MOS pages should remember that they are only a very small part of the community (as many of them do) and that their views often do not express wider community sentiment. Johnbod (talk) 11:35, 20 April 2014 (UTC)

Like Montanabw^(talk) 07:20, 22 April 2014 (UTC)

How about the following suggestion. The language is drawn from WP:LEADLENGTH and from MOS:INFOBOX. Establishing a suggested maximum length may help prevent infoboxes from becoming cluttered with too many marginally useful details.

As a general guideline—but not absolute rule—the infobox should usually be no longer than one page. A lead that is too long does not serve the purpose of allowing readers to identify key facts at a glance. Barryjjoyce (talk) 01:13, 19 April 2014 (UTC)

Nice sentiment, but "longer than one page" or "longer than a screenful" or whatever, is entirely dependent on the device on which the the material is being viewed. On my monitor, I'm hard-pressed to find a single infobox I can't get into one screen, even the longest of them. We do need some kind of limit, somehow, but sometimes long ones are very helpful, e.g at Galaxy Note 3. It's quite difficult to find any of those details in the prose of the article. I actually heavily depended on the infoboxes in WP articles on various phone models when deciding what phone to buy. (While Wikipedia is not a shopping guide, the point is that one person's "geeky details" is another person's "crucial summary data", and we cannot predict or dictate people's uses of and for WP content).  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  20:37, 19 April 2014 (UTC)

I agree entirely with the sentiment behind the proposal, being in the "less is more" camp with regard to their effect. Too often we end up with things like Hollywood Squares, which is no help to man nor beast, as any "use" to be had is drowned out by the sheer weight of other matter. And that pales slightly when we look at Winston Churchill: it may be the case that listing his various cabinet posts may or may not be useful, but also including the details of the PM under which served, and who preceeded and succeeded him is meaningless fluff (especially when we see exactly the same information in tabular form lower down the page at Winston Churchill#Political offices. Angela Merkel is an interesting one: English wiki has it's usual overly-long mess of factoids, which is interesting to see against the much more minimalist German language page. The main problem I see here is where to set the limit? A "length" or number-of-screens limit will always run up against the very good argument of differing screen sizes (not least on tablet and mobile devices). The "no longer than the lead" argument has merit, but does tend to count against stubs (there are lots of film stubs where the lead is a single line and even the very, very briefest details in the IB will run longer than the article, let alone the lead. I'll be happy to support anything that brings in a sensible limit to IBs as much as possible, but I think it may be a struggle to come up with a good rule of thumb that can be used. - SchroCat (talk) 08:42, 20 April 2014 (UTC)

• There should be a limit, which needs to be expressed in lines. I'd favour a low one of about 20 lines, which is absolutely not to say that all infoboxes needs to be anything like that long. If it is really felt locally that vastly more information is needed, then there can be two boxes, one for the important stuff in the lead, and one for lower down (in a long article) with more detailed stuff. This approach should be used more often. Johnbod (talk) 11:35, 20 April 2014 (UTC)

I like Johnbod's suggestion that an infobox recommended maximum length be measured in number of lines. This is a better method than the "one page" or "no longer than the lead" ideas, for the reasons already stated. I would recommend a maximum of 30 lines (which would be closer to the original sentiment I was trying to describe of one page on a standard-size desktop monitor). A problem with a 20 line limit, especially on a biographical article, is that the photo would take up most of the space, leaving very little room for anything else. Barryjjoyce (talk) 13:33, 20 April 2014 (UTC)

If such a limit would be used, it is probably better to have it as N lines + 1 photo and not allow lines in lieu of a image. CRwikiCA talk 15:14, 20 April 2014 (UTC)

Yes, I didn't mean to include the image, so N lines + 1 photo (though if you have as many as 20 or 30 lines it will often be best to have the image above the box, keeping that fairly narrow). Big images & small infoboxes are usually my ideal in a lead. Johnbod (talk) 15:35, 20 April 2014 (UTC)

If we go with something like the 20 lines + 1 image approach, would there need to be further guidance on what constitutes 1 image? For example, at the Pittsburgh page I mentioned previously, there are five photos in one box; would this count as one image or five images? There are also two symbols side by side; would these count as two images, or just one since the two images side by side don't add any more length than one symbol? Same questions for the two side by side maps. Maybe we can answer these questions in a way that won't generate a number of arguments. But the advantages of an approach of 30-35 lines max (instead of a 20 lines + 1 image max) is that the simpler approach may generate fewer arguments, plus it allows the members of various wiki projects the flexibility as how much space to allocate to images vs lines of text in their info box templates. Barryjjoyce (talk) 00:30, 21 April 2014 (UTC)

That's one image = one image file (Montage Pittsburgh.jpg). I could accept 1 image file + 1 map for geographical articles, and also 1 flag for countries and states/provinces. That's enough, imo, though as I say I'm open to secondary boxes lower down. If you are proposing some sort of image-into-lines conversion, that will get very complicated given all the display options, won't it? Johnbod (talk) 02:32, 21 April 2014 (UTC)

Clearly, there are projects, like geographic locations, where multiple images may be needed. Montanabw^(talk) 07:20, 22 April 2014 (UTC)

Just to butt in - some projects do use infoboxes for what they consider key data and can run to more than 40 lines excluding images - eg this featured article (part of this featured topic). I think before you get into a prescribed - rather than advisory - limits, you will need to get some projects on board to encourage them to shift (lede) infobox data to secondary infoboxes or other sections of the article - eg as the aviation wikiproject does with its infoboxes of about lines and the specification section for the numbers elsewhere in the article eg Supermarine Spitfire infobox about 30 lines long, specifications about another 30 near the bottom of the article. GraemeLeggett (talk) 09:15, 21 April 2014 (UTC)

Also true for certain political figures, sports figures, and topics with immense amounts of technical data. Montanabw^(talk) 07:20, 22 April 2014 (UTC)

Coin infoboxes contain a minimum of two images, sometimes several more if the designs were changed significantly during the coin's run. I view it as just one of those things. It's obviously important to illustrate the coin. No opinion on any matter suggested here except obviously I'd rather not have the MOS cut out from under 30 FAs or so, not all mine.--Wehwalt (talk) 14:18, 21 April 2014 (UTC)

Wrt the role of Wikiprojects: they seem to be the cause of infobox bloat. It is these projects that generally design the templates and get request after request for new common minor facts. Andy states that wikiproject members are part of the community too and should be allowed "their voice as individuals". I agree, but if one looks at the articles I linked and sees the discussions, then we are not seeing individual sentiment but group ideology. I have been asked, in defiance of policy, to overturn the wikiproject consensus before they will budge. I have requested members to say how the information is a "key fact" or "summary of the article" and receive no reply -- because there is no answer to that which allows them to get away with dumping facts into the box. I mean -- out-of-date Latin terms for crying out loud? The problem is we have often only one standard table in an article: the infobox and it is being used for all tabular information provided someone on a wikiproject can persuade others that it is fairly common. As long as some subject-nerd finds the data interesting, it gets imposed on everyone. Yet this is prime real-estate for the screen and a solid vertical box causes issues with images on the page, which are often right-aligned. I disagree with using an arbitrary cut-off for info box length. The guidance on this page is fine and rational rather than arbitrary. The problem is simply that it is being ignored by a group that do not represent the general reader. I dislike the attitude expressed here about MOS bullies. I'm no MOS regular. I didn't go to those articles to bully the editors there into obeying the MOS. I edited those articles to try to do the sensible thing and trim crap from the lead, and was bullied into accepting utter stupidities by a bunch of nerds, frankly. Our policies and guidelines already express community feeling on this matter. It is time the wikiprojects were reminded they have no higher voice on WP than individual editors. -- Colin°^Talk 10:32, 21 April 2014 (UTC)

Colin, you would have a lot more credibility with me (and others as well) if you'd cease insulting people with expertise as "some subject nerd" or "a bunch of nerds" and describing useful content as "crap." A know-nothing approach is not helping shed light on the concern for a very few infoboxes that get bloated. Montanabw^(talk) 07:20, 22 April 2014 (UTC)

Colin I can feel your pain and commend you in raising issues I had not thought about- but I don't feel that suggestions that could lead to valuble information being axed is productive. Each of the issues you raise must be addressed but addressing the cause rather than the result is probably more profitable. I have written an infobox- by c&p another one- then adding fields. I have gone back to reduce the redundant fields and found that they were already being profitably used by another Wikipedian.

I write on a venerable laptop but when in meetings, and needing info for a speech I am about to make- I pull out an WP app on my mobile phone and scan for the fact. All I will see is the infobox. The longer the better. It is not a summary of the article- it is the article. Take this one further- politician and journalists rely on our work and they are accessing them through the phone. Increasingly we are responsible for bad policy and thus human suffering.

Andy, probably will correct me, but if I am mining/scaping data for a web page, using, for instance python/beautiful soup- I would just use the infobox- which I see as the machine readable section of the article

I know that many folk are prose bunnies but for quick comparisons structured data in split windows is the most efficient way of doing the job- and there are many technical facts (surface area of different floors) that should be left out of the prose but included in the infobox.

Some infoboxes appear too long because they are too narrow causing word-wrap. I assume someone made a decision to standardise the width after the box was written and in use.

If the problem is with WikiProjects badly writing infoboxes then it is better to flag the issue warning that WikiProjects should guard against bloat and devise a policy for guarding against it- put that as item in the new WikiProject Welcome message. A new wikiproject is happy to receive all the help it can get but is irritated by extra hurdles. I see no harm in a bloat warning being placed on each WikiProject talk page- asking them to review their info-box- but we don't make work for ourselves by giving the deletionitas another bogus excuse.

I repeat Andy's words "The problem here would seem to be that the MoS is (or rather its authors are-) trying to dictate article content, rather than the more proper function of describing community norms."-- Clem Rutter (talk) 13:32, 21 April 2014 (UTC)

I agree very much with Colin's description of the issues and I'm very sympathetic to the view that smaller infoboxes generally perform their intended purpose better than larger ones. What is difficult is that there are so many justifiable exceptions to even that simplified philosophy. This is compounded by two common problems:

1. the inability of our community to sensibly deal with "rules-of-thumb" or "rough consensus" - we only seem to be able to manage "bright-line rules" with enumerated exceptions down to the smallest detail; and
2. the tendency of the limit to become the norm - if we suggest that 30 lines is a sensible upper limit, then I guarantee that smaller infoboxes will grow like Flopsy until they reach the new 'norm'.

I know where I feel we should be: at a point where it is easy to reach a sensible consensus on issues like how long an infobox in a particular article ought to be. I have no magic formula for moving us from where we are now to there, but I have no doubt that this issue - like many others - will remain intractable until we figure out how to do just that. --RexxS (talk) 17:43, 21 April 2014 (UTC)

The other issue is that the debate will never be resolved or consensus reached so long as people such as Colin choose to vent their frustrations with language that attacks the hard-working people who actually create content. I for one see no use in insulting people as "nerds" who insert "crap." That does not lead to a collaborative environment where consensus can be reached. Montanabw^(talk) 07:20, 22 April 2014 (UTC)

No, the debate has been resolved and consensus expressed on this guideline page. The problem is those who don't wish to listen. And the reasons for this are many but largely consist of flaws in thinking processes and personality -- which nobody wants to hear about. Montanabw, the Latin synonyms in the onion article are "crap" and anyone who thinks they are a key fact about a hugely important food crop is a "nerd". The entry-exit figures for Kings Cross are raw data from which one (or our sources) might formulate a fact (such as comparing its importance as an interchange with other stations). These are not key facts and they do not belong in the infobox. I don't see anyone here (or on the talk pages of those articles) actually raising a coherent argument in support of that. I just see a lot of people enjoy arguing for argument sake and are unwilling to back down in the face of evidence. Montanabw, if the best argument you have is that we should allow infobox bloat because those who bloat it are "hard working" then you are scraping. If your best argument is that my language is offensive to you then you are scraping. I see no arguments expressed here that disagree with the consensus opinion on this MOS page nor that explain how those expanded infoboxes on those pages (a) comply with it or (b) could not be reduced and whatever information removed from them be better expressed elsewhere in the article or even in another article. -- Colin°^Talk 07:15, 23 April 2014 (UTC)

@Johnbod: In response to my statement regarding "the advantages of an approach of 30-35 lines max (instead of a 20 lines + 1 image max)", you replied that "If you are proposing some sort of image-into-lines conversion, that will get very complicated given all the display options, won't it?" Could you explain further what you meant? My thought was that on a desktop view, where the infobox is on the right and the text is on the left, it should be easy enough to count the number of lines of text that an infobox takes up. For example, on a normal-size desktop monitor, the image at the Oak infobox takes up approximately 13 lines of text (10 lines in the lead plus 3 lines in the table of contents). If it's more complicated than that, please explain how. Thanks. Barryjjoyce (talk) 01:35, 23 April 2014 (UTC)

There is no such thing as a "normal-size" desktop monitor. What is concise for one type of article, or individual article, may be exaggerated for another. I don't believe that more regulation would help. --Gerda Arendt (talk) 05:54, 23 April 2014 (UTC)

The max-lines approach is stupid. Please, if people won't comply with rational guidance on what to put in an infobox, why should they comply with an arbitrary rules on how big the box should be. -- Colin°^Talk 07:15, 23 April 2014 (UTC)

Edits to lead

@AlanM1: Let's use this talk page to discuss your proposed change. If all you are trying to do is cleanup the "and/or", I have no objection to that. But you are changing singular words to plurals, which may be interpreted as encouraging more images & maps in the infobox. That is at odds with the tenor of another discussion on this talk page re infobox length, in which a number of editors have expressed concern re length. As you have not established a consensus for your changes, I have reverted them. Let's leave the lead as it was, until we see if a new consensus forms. Barryjjoyce (talk) 01:09, 22 April 2014 (UTC)

@Barryjjoyce: "and/ or" is clearly wrong (the space doesn't belong). I was going to change it to "and/or" and found that was "discouraged" by the MOS as well. In thinking about the usage, then, I realized that there are commonly, intentionally (through multiple image parameters), multiple images in many types of infoboxes, and the phrase was wrong to begin with. Really, it should just refer to "images", as maps are images as well. There should be as many images as it takes to accomplish the particular task, as always. —[AlanM1(talk)]— 03:14, 22 April 2014 (UTC)

Thanks for the explanation. If you want to change "and/or" to "or" or to "and", I have no objection. As for your other proposed changes, let's hold off for now. There is an ongoing discussion re infobox length. Let's see how that plays out, and then revisit this issue then. Barryjjoyce (talk) 01:08, 23 April 2014 (UTC)

Infobox length - should there be a limit?

Following the discussion above regarding infobox length, it might be useful to get a sense as to whether the consensus is in favor of trying to establish a maximum suggested length for infoboxes or against any such recommended limit on length. If the consensus is against a suggested maximum length, that may be the end of the discussion. If the consensus is in favor of a recommended maximum length, we can start then discuss how to set the suggested maximum length, but for now, let's focus on whether there should be a suggested maximum length or not. Barryjjoyce (talk) 23:46, 26 April 2014 (UTC)

This is a badly-worded Hobson's choice. Obviously there probably needs to be an outside limit could become a point where absurdity reigns (two pages would clearly be excessive, but then again, maybe not). So for those who can't really fall into either camp, I'm adding a third option. Montanabw^(talk) 20:15, 27 April 2014 (UTC)

Support

• Support — Many infoboxes have grown quite long. See for example Pittsburgh and HMS Hood (51). Too much info in the infobox makes it hard for the reader to identify the key facts at a glance — which is the main purpose of having an infobox. Barryjjoyce (talk) 23:46, 26 April 2014 (UTC)
• Support — Not exactly a bright line rule, but a general principle as I have proposed above (limit of 30 lines, plus image & map where needed), with more detailed information either in show/hide bars or secondary boxes lower down. Many infoboxes have become ridiculously long. Johnbod (talk) 01:51, 28 April 2014 (UTC)

Oppose

• Oppose — The concept of a "bright line" rule is problematic, and for that reason only, I vote Oppose. Some infoboxes, due to the nature of the content discussed, need to be long, others should clearly be quite short. This issue needs to be decided on a case by case basis. A bright line rule, say one allowing an infobox similar to that at the FA Richard Nixon would lead to complete bloat for a more minor figure, such as Lawnchair Larry. Montanabw^(talk) 20:15, 27 April 2014 (UTC)
• Oppose — Not all articles are created equal. Better write in the instructions not to fill every possibly parameter but present the most relevant ones to a reader who seeks information at a glance. Using the sense that is not so common is preferable to a fixed arbitrary to-be-observed limit. --Gerda Arendt (talk) 20:22, 27 April 2014 (UTC)
• Oppose — The quality of the data and clear presentation are the key to providing informative infoboxes. With standardized layouts for the different topics, we get an easy quick look. The two examples (Pitts & Hood) are actually quite good. – S. Rich (talk) 22:00, 27 April 2014 (UTC)
• Oppose - The number of infobox parameters that are relevant and useful will vary widely between topic areas, and the size of the entries for a particular parameter will vary widely between articles, so it's meaningless to complain about length/form without regard to the subject/function. I agree with S. Rich, and also find the articles the proposer gives as having "long" infoboxes to be very good, useful, and navigable. One of those articles is a FA, and so is supposed to represent our highest editing standards, and the other uses a template that is used on hundreds of thousands of articles, and so is presumably supported by an overwhelming consensus of editors. So it also seems clear that the proposer's opinion on this is not reflective of the community's.

  If the proposer has trouble finding certain information in infoboxes (though I do not in the examples given), then he can help suggest ways to improve their internal organization and presentation so the most significant facts can be better highlighted or grouped. It is senseless to complain about length in the abstract (akin to complaining about "too many notes") rather than making specific proposals to remove particular fields in particular infoboxes. postdlf (talk) 01:17, 28 April 2014 (UTC)

• Oppose — Discussion of infoboxes from the pov of a 20-20 sighted human is problematic. Infoboxes have other uses as they are a machine readable entry point to the article- and are often the only data that is scraped.-- Clem Rutter (talk) 08:31, 20 May 2014 (UTC)
• Oppose - Impractical instruction creep. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:29, 14 June 2014 (UTC)
• Oppose – As above. However, I do agree that some Infoboxes are too long, like the 6 years of traffic at London King's Cross railway station, entire careers for sports figures like David Beckham, and political careers along with succession and seconds like Angela Merkel. This sort of data belongs in table form, maybe even alongside running prose about it, just not in the main Infobox. —[AlanM1(talk)]— 08:39, 21 June 2014 (UTC)

Neutral

• Neutral Comment — I'm on the fence here—I prefer short, to-the-point infoboxes, but I don't think there should be arbitrary limits. What I do have a big problem with is minimum lengths—for example, WikiProject Novels requires an image of the first edition cover of a book in the infobox, and forces these images on articles even when no content editor of the article finds it appropriate. I wasn't even allowed to remove an image I had added myself. I'd rather see a wording that leaves things up to the judgement of the article editors after weighing each parameter for the value it provides to the specific article—which could result in either very short or very long infoboxes on a case-by-case basis. Curly Turkey ⚞¡gobble!⚟ 06:14, 14 June 2014 (UTC)
• Neutral Comment —

Additional discussion

@Montanabw: I was wondering if you could explain further — in light of your statement above: "Obviously there probably needs to be an outside limit" — why you placed yourself in the "oppose" camp? Barryjjoyce (talk) 02:20, 28 April 2014 (UTC)

Because I see no way that a bright line rule can work. As I explained above, it's a case by case basis - If we said "foo # of lines" "foo number of parameters," or "foo number of pixels", we'd no doubt see unneeded cruft added (height and/or weight might matter to a basketball player, a jockey or a supermodel, but is irrelevant for an artist) to some articles, and very relevant info omitted from others (for example, Serena Williams has a rather large infobox, but most of the data appears relevant). Montanabw^(talk) 06:31, 28 April 2014 (UTC)

"infobox bishopstyles"

I'm stuck. I've done a little work on Robert Finn (bishop). More recently, a coat of arms with a Latin motto has been added to the infobox which is set up under the "infobox bishopstyles" heading visible here. I tried to add a line for motto for an English translation but "motto=" didn't register. I found my way here in my search for what "infobox bishopstyles" was so as to find if I could find a way to enter the translation. I found the "Religion Topics" dropdown in this article but nothing there. No "bishopstyles" in a search of the article or in the archives of this Talk page. A search of all Wikipedia and wiki: also yielded nothing on "bishopstyles". Can anyone direct me on my way, here? I did check at Coat of arms and seem to be on the right path (with the right term: motto), substantively; and feel an English translation is appropriate for the encyclopedia and the article.

I do anticipate one further problem once I find a way into the infobox so I'll house the whole edit here for the time being, too; in short, I'm relying on Google Translate for my translation. I seem to recall problems using a Google-based citation. I'm prepared to cross that bridge when I get to it but am open to comment on it here, too. Here's the line I want to add to the Finn infobox: "Seek ye first the kingdom of God" <ref>[https://translate.google.com/?hl=en&tab=wT#la/en/quaerite%20primum%20regnum%20dei Google Translate from "Quaerite primum regnum dei" (Latin)]</ref>

Any help appreciated. Thanks. Swliv (talk) 23:55, 4 October 2014 (UTC)

Swliv try using {{Infobox Christian leader}}. the styles templates are very limited by design. Frietjes (talk) 16:54, 5 October 2014 (UTC)

Good start, thanks Frietjes. But simple substitution of the "Infobox Christian leader" for the "bishopstyles" template certainly didn't work. Three specific parameters -- dipstyle=The Most Reverend; offstyle=Your Excellency; Monsignor; and relstyle=Bishop -- are excluded. The "leader" template would theoretically (per your linked page) include motto -- my goal -- though the motto also didn't come up in my first try with "leader".

I don't have time for much more now but also will want to think about providing a portal to the 'leader' page on this 'Manual' page; where currently only Latter Day Saints and another are touched under Religion.

If any further direction off this first cut, again appreciated. Cheers. Swliv (talk) 12:25, 6 October 2014 (UTC)

Swliv, I wasn't suggesting a complete replacement. see, for example, Carlos Filipe Ximenes Belo, Joseph Duffy (bishop), etc. Frietjes (talk) 13:33, 6 October 2014 (UTC)

Frietjes, I have found no way INTO 'bishopstyles' to add "motto="; and, a little awkwardly (in practice), motto in "leader" template comes up under "Personal details" whereas I understand (and see, under "bishopstyles") the coat of arms (and hence motto I'm assuming) come/would come under "Styles" (also more connected to the diocese than to the individual bishop? that's how I'm seeing it for now). I've shown the best way I can work it out here at my Wiki sandbox; awkward-looking. More thoughts? Thanks for your help to here. I'll go with the sandbox version with explanation -- "motto translation; a bit jury-rigged but no motto option under 'bishopstyles', no way INTO 'b'styles' that I've found Wikipedia talk:Manual of Style#"infobox bishopstyles"" -- if there's nothing else, see how it flies.

If you could tell me how to get into "bishopstyles" I'm sure I could work with, say, "Caption" or some other available header; or, as I've said, add "Motto".

Looking at Carlos Filipe Ximenes Belo, the coat of arms doesn't have any Latin in it; but the article uses both '-styles' boxes; I'd have the same problem if there was Latin I wanted to show the translation for; as my sandbox version does but with the awkward doubling of Personal details some of which may not be so-much-personal details. Duffy of course has no coat of arms at all. Thanks again. Swliv (talk) 16:33, 6 October 2014 (UTC)

Swliv, I don't see a reason why the motto shouldn't be in "Infobox Christian leader" instead. if you want to change where the motto appears in "Infobox Christian leader", then you should start a thread at template talk:Infobox Christian leader, since there are more editors who watch that page than this one. Frietjes (talk) 16:51, 6 October 2014 (UTC)

Frietjes, for better or worse (and I see now you specifically advised against it, above), I went to Template talk:Infobox bishop styles instead. And for your reference, incidentally, in case you hadn't already figured it out, I didn't know that I was looking for a template ("template:"); and I guess I didn't make that clear above exactly. Once you directed me to "template talk:Infobox Christian leader" and I worked there a while it dawned on me you'd given me the key to the other door as well. The joys. We'll see. Thanks again. Swliv (talk) 17:54, 6 October 2014 (UTC)

Remedy six of the infoboxes arbcom case

See Wikipedia:WikiProject Quality Article Improvement/Infobox for an initiative regarding this recommended remedy. --Francis Schonken (talk) 18:47, 9 November 2014 (UTC)