Template talk:Infobox person/Archive 30

RfC: Should resting place include cremation
Should the "resting place" parameter be used for "Cremation" such as used here? Please feel free to put new headers for alternatives such as renaming the parameter or adding a new one or the like if that seems appropriate. -- Ricky81682 (talk) 07:41, 10 February 2016 (UTC)

Yes

 * Yes; see below. SteveStrummer (talk) 10:16, 10 February 2016 (UTC)
 * Yes, but I could support other options: see below. BMK (talk) 20:59, 10 February 2016 (UTC)
 * Yes. It's a good way of saying "not applicable" in a way that anyone can understand — if you merely add "Not applicable" or "N/A" to the infobox without clarification, it will confuse readers (after all, a body had to end up somewhere), but as long as you know what cremation is, you'll understand why it's being mentioned.  PS Beyond My Ken's suggestion of "none: cremated" is also fine with me.  We shouldn't omit the fact of creation from the infobox merely because of the wording of the parameter, and demanding that we omit the information unless we know the place of ash scattering or the location of a crematorium would be absurd.  I'm just interested in ensuring that the fact of cremation be mentioned in the infobox, if that's all we know.  Nyttend (talk) 14:49, 15 February 2016 (UTC)
 * Yes. See below. J. D. Crutchfield  &#124; Talk 15:12, 19 February 2016 (UTC)
 * Yes. Let's be reasonable; most readers understand that "resting place" can mean more than just literally where the body is.  Calidum   ¤   02:42, 20 February 2016 (UTC)
 * Yes. The point of the parameter isn't merely to provide a "find-a--grave" feature or to facilitate Wiki-data-mining, but to summarize information about the subject's life and death for the reader. J. D. Crutchfield's examples, below, are very good examples of what the parameter should be used for. – Philosopher Let us reason together. 14:12, 3 March 2016 (UTC)

No

 * No. See below. -- Ricky81682 (talk) 07:45, 10 February 2016 (UTC)
 * No; explanation below. &#128406; ATinySliver / ATalkPage 08:03, 10 February 2016 (UTC)
 * No; cremation is manifestly not a "place", therefore this designation in the infobox is inaccurate. Just leave it blank if the ashes are not interred or entombed or enshrined anywhere. Or else change the label in the infobox to "Burial" (which it probably should be anyway, because "Resting place" is a confusing euphemism). Softlavender (talk) 10:43, 10 February 2016 (UTC)
 * No; per below comment SPACKlick (talk) 12:25, 10 February 2016 (UTC)
 * No, for reasons of consistency. This parameter has always displayed a place - both resting_place and burial_place are accepted and produce distinct labels, and in either case a set of coordinates may optionally be supplied. Re-users of the data in structures like infoboxes are much better served if the data is the same sort across articles. While "at sea" might be considered a useful exception to the expectation that a geographically defined place would be used, most of the others simply don't fit. If we allow "cremated", what other exceptions might be used as values for the parameter? "spontaneously combusted"? "vaporised"? "abducted by aliens"? "hung, drawn and quartered"? or even "drawn down to the pits of hell" in the case of Dr Faustus? --RexxS (talk) 13:21, 10 February 2016 (UTC)
 * No. - Sorry but "Resting place - Cremation" just sounds awful, But my main reason for opposing is as noted below being cremated isn't a place ... it's an action, The resting/burial place should be the actual place of burial ....., – Davey 2010 Talk 14:02, 10 February 2016 (UTC)
 * No as others have stated, cremation is an action and not a place Snuggums (talk / edits) 18:30, 10 February 2016 (UTC)
 * No Cremation is not a resting place. The fact is that the term is an odd euphemism since no one has died is doing any "resting." MarnetteD&#124;Talk 21:07, 10 February 2016 (UTC)
 * No unless you are cremated and buried somewhere.-- &#9790;Loriendrew&#9789;  &#9743;(ring-ring)  00:35, 11 February 2016 (UTC)
 * No if we are talking about the way it is used in the example at the top. That just doesn't make any sense since "cremation" is obviously not a place. Yes if it can be verified that their ashes are kept in a specifc location. Many large cemeteries have facilities for this. Beeblebrox (talk) 21:28, 16 February 2016 (UTC)
 * No, cremation is not a place. Kaldari (talk) 00:01, 18 February 2016 (UTC)
 * No, this parameter should list places only. Nikkimaria (talk) 02:03, 18 February 2016 (UTC)
 * No - Just places, for reasons that have already been well argued. &mdash;  Rhododendrites talk  \\ 13:09, 18 February 2016 (UTC)
 * No "Cremation" in this case is used to mean "not applicable". For cremations with no stated resting place, or burials with no stated resting place, we could consider a "not applicable" field. May cremations have a resting place, such as the many Indian people who are cremated in the Ganges, but to list a body management method in a field for a place is inappropriate. See Golders_Green_Crematorium for examples of people who were cremated and having a resting place in a famous crematorium.  Blue Rasberry   (talk)  16:56, 29 February 2016 (UTC)

Potential alternative #1
While maintaining the resting_place &#61; parameter, it could instead be rendered within infoboxes as, for example, "Burial/interment/cremation". &#128406; ATinySliver / ATalkPage 08:19, 10 February 2016 (UTC)
 * I support this suggestion. (See my comment below). BMK (talk) 20:41, 10 February 2016 (UTC)
 * Over my dead body. Not only is that sort of formulation stylistically inappropriate (along the lines of "and/or"), it is far too long to sensibly render as a label in any infobox. --RexxS (talk) 21:03, 10 February 2016 (UTC)
 * Not planning to be cremated, are you? The general suggestion does stand, with the actual wording to be determined if it's agreeable (other suggestions have included "Disposition of body"). &#128406; ATinySliver / ATalkPage  00:50, 11 February 2016 (UTC)


 * I'm not understanding what the parameter would look like in use. One of these?:


 * Burial/interment/cremation Cremated


 * Cremation Cremated


 * Neither of them make much sense to me. Softlavender (talk) 01:36, 11 February 2016 (UTC)
 * It would be your first example, presuming that wording. Also mentioned:
 * Disposition of body (or remains) Cremated
 * &#128406; ATinySliver / ATalkPage 02:56, 11 February 2016 (UTC)
 * Burial/interment/cremation is way too long (and unreadable) of a parameter for an infobox, and to me Disposition of body (or remains) sounds gruesome, grisly, and positively silly. (I'd also like to add that none of this information is important enough to mention in an infobox; the only possibly remotely relevant information for an infobox, in my mind, would be where their burial site or memorial is, if it is not in their home country or the country where they spent most of the adult years.) Softlavender (talk) 03:01, 11 February 2016 (UTC)

Discussion
Both Resting place and Burial place have a similar coordinates parameter which I assume is meant for the actual final place of rest. It would be weird to call the funeral home that did it (or wherever) their final "resting place" since the cremation isn't the actual resting place of the person (or their ashes) but it depends on where the ashes went. It could possibly be accurate if say the ashes were saved and put in a museum or something like that but generally I wouldn't support cremation being the final resting place in and of itself. This may sound like a maybe but I'm going with a flat no for now. -- Ricky81682 (talk) 07:45, 10 February 2016 (UTC)

The template instructions correctly read, "Place of burial, ash-scattering, etc." (Emphasis mine.) Cremation is an action, it is not a place. That said, I have  —while re-wording to restore the focus onto the place—those instances in which cremation is part of the explanation as to why a person's cremains are in those places. &#128406; ATinySliver / ATalkPage 08:03, 10 February 2016 (UTC)


 * * Valid answers that could be placed in the field "Resting place" include "At sea" and "Unknown", which give no more geographical certainty than "Cremated". What's problematic is that the field title itself is strangely worded, using a euphemism (uncharacteristic for the 'pedia) instead of unambiguous terminology like, say, "Disposition of remains". Like most matters concerning infoboxes, this issue calls for deliberation and consensus. SteveStrummer (talk) 10:11, 10 February 2016 (UTC)
 * "At sea" constitutes a place, if ambiguous; "unknown" is the same as "leave blank" per numerous template instructions. "Cremated" is not a place under any possible definition. As for the field title, I don't disagree with you; as for deliberation and consensus, I fully agree in terms of what should remain within articles, but not in terms of what should be removed. &#128406; ATinySliver / ATalkPage 10:26, 10 February 2016 (UTC)
 * I see no helpful reason to insist that the field show an actual "place". I also don't think the field title needs to be changed: despite the "problem" raised here, it's a commonly used expression and well understood. I think 99% of readers feel no pangs at all from the apparent lexical error, and are better served by simply having the desired information be present where they expect it to be. SteveStrummer (talk).

It may be worth tagging some locations as cremated such as if it's ashes in a museum rather than a body but no way should creamted be listed as a location. SPACKlick (talk) 12:24, 10 February 2016 (UTC)
 * Comment - Just add another parameter. We already have:""With instructions for burial place including to show where ashes were scattered, etc. We definitely should not take out the Cremation information from the articles. When people are searching for people, historical people, one of the things they want to know is where they are buried, or what happened after death. Stating they were cremated helps provide that information. So either add a body_disposal = parameter, or leave it as is, with the Cremation info. Dave Dial (talk) 17:57, 10 February 2016 (UTC)
 * Are people actively looking for that in the infobox? It seems like a complete out there thing to particularly care about to me. I'd get if you said we should include that in the text if it's reliably sourced but the infobox seems odd. I'm not even certain about the burial/resting place there but at least I can get that in the infobox. -- Ricky81682 (talk) 19:55, 10 February 2016 (UTC)
 * Well, yes. I know for a fact when researchers are researching the deceased for historical/genealogy purposes they first look to the infobox. I'm not saying that it stops there, but that is the first place they look for burial information, as well as children and spouses. It helps to have the basics listed there. Of course they continue to the article, but if a researcher is going through many historical figures that are deceased, having the info in the infobox helps quite a bit. Dave Dial (talk) 20:11, 10 February 2016 (UTC)


 * Comment I believe there are actually several parts to this "problem" (which is not actually much of a problem at all):
 * First -- and I know this has been discussed before, but it's worthwhile bringing it up again -- "Resting place" is a god-awful euphemism that is demeaning for us, as an encyclopedia, to use. No one is "resting", they're dead -- period.  "Burial place" or some other equivalent would be a vast improvement.  As a fact-based encyclopedia we should avoid euphemisms whenever and wherever possible.
 * Second, as Steve Strummer says above, the "lexical error" of having "cremation" appear in the "Resting place" parameter is really not much of an error at all. What "Resting place" means is actually something like "What happened to the body?".  Since the majority of deaths are dealt with by burial in a cemetery, the majority of times this parameter will show the name of a cemetery.  For those occasions where the body was cremated, having "Cremated" or "None: cremated" or "Cremated: ashes spread on Mount Olympus" provides the answer to the implied question.  It is only an over-strict and rather pedantic interpretation of the actual words appearing in the infobox that prompts the removal of pertinent information that is of interest to the reader.
 * However, having said that, I do know there are some people who are unable not to make overly strict and pedantic interpretations of words. If these folk, and those that agree with them, carry the day here, then I support the suggestion made above by ATinySliver that a second parameter might be necessary to deal with cremations. However, my first inclination is that the rendered wording of the current parameter could be altered in such a way as to allow the information to appear in one field instead of in two, as they are -- for the most part, but not always -- mutually exclusive. (The "not always" comes when ashes are interred in in a vault in a cemetery.)
 * Those are my thoughts. BMK (talk) 20:58, 10 February 2016 (UTC)


 * Where's the demand to add another parameter? Don't we have enough already? Isn't there a point where adding more and more parameters just makes the template so unwieldy that most of its parameters never get used because nobody knows about them? It seems many folks commenting here don't even know that burial_place can be used instead of the euphemism resting_place, as long as the body was buried, of course. You can't use both parameters, as one overrides the other. What "Resting place" actually means is precisely "Where is the body now?", not what happened to it. When the ashes are scattered in orbit around the Earth, there is no good answer to the real implied question. It's a pity that some people can't grasp the concept of data consistency across articles. This leads them to confuse pedantry - which is defined as "excessive concern with minor details and rules" - with the desire to ensure that information can be handled in a consistent manner. Anybody who has spent time programming will appreciate the value of making sure that when you're processing something that represents a place (possibly with geo-coordinates), you don't have to keep coding exceptions because somebody is inserting values that have no place associated with them. I can accept ignorance, but I'm not prepared to accept being labelled a pedant through it. --RexxS (talk) 21:27, 10 February 2016 (UTC)
 * You are exactly correct; another parameter won't even deal with the instant issue. It's how the existing parameter is rendered on the page to the reader that will determine whether "cremated/cremation" should be in the infobox. &#128406; ATinySliver / ATalkPage 21:41, 10 February 2016 (UTC)
 * You are exactly correct; another parameter won't even deal with the instant issue. It's how the existing parameter is rendered on the page to the reader that will determine whether "cremated/cremation" should be in the infobox. &#128406; ATinySliver / ATalkPage 21:41, 10 February 2016 (UTC)


 * Note - I put neutral pointers to this discussion on Centralized discussions, and on the talk page of WikiProject Templates. (Ricky81682 had already put one on the talk page of WikiProject Biography).  Also, a reminder that RfC's generally run for 30 days, so that a wide cross-section of the community can have their say. BMK (talk) 23:14, 11 February 2016 (UTC)


 * Re "resting place": as correctly noted above, this phrase is a poor euphemism and not particularly encyclopedic in and of itself. Both resting_place &#61; and burial_place &#61; should be rendered, say, Buried/interred at—or, even more simply, Burial site, allowing editors at each individual page to note interment or ash-scattering—and the instructions at the template page should read, say, Location of burial, ash-scattering, etc. If no location, leave blank. &#128406; ATinySliver / ATalkPage 23:20, 11 February 2016 (UTC)
 * As long as the presenting text implies physicality ("resting place" or "burial site") we end up with the same problem, in that some people can't deal with such a parameter having as entries something like "None: cremated" or "None: cremated, ashes spread from Mount Tamalpais". If the parameter said something on the order of "Disposition" -- not a good word choice, a better one can surely be found -- then that problem goes away entirely.  Entries can say "Buried in Fernwood Cemetery" or "Cremated". (Incidentally "cremains" is a dreadful word, it's industry jargon and thoroughly unencyclopedic and should be avoided.) If the parameter said "Burial or disposition" that would eliminated the need to say "Buried at..." for the 90% of entries which would be cemetery burials. I have no preference for 2 parameters, I'd rather it be done it one, but I'd also rather that pertinent information not be denied our readers because the parameter isn't expressed in the best way.  BMK (talk) 23:46, 12 February 2016 (UTC)


 * If a person was cremated, what is wrong with stating "Cremated at Foo Crematorium" in the infobox? Mjroots (talk) 22:34, 12 February 2016 (UTC)
 * If the cremains are still there, nothing—though I hope that will be moot as a result of this discussion. &#128406; ATinySliver / ATalkPage 22:38, 12 February 2016 (UTC)


 * Comment - wouldn't it be simpler to just rename the template to something that can accommodate any already existing cremation details? Something like; "Burial information"... or along those lines? - the WOLF  child  05:28, 13 February 2016 (UTC)


 * Comment: I vote "Yes." Bodies at rest tend to remain at rest.  "Resting" here does not imply "taking a nap":  it's not a euphemism, but a description of something that has ceased to be in motion.  In cases in which bodies have been cremated and the ashes scattered, or where they've been "buried" at sea, lost, disintegrated, etc., surely readers can make the tremendous mental leap to understand that the general term embraces such dispositions by analogy.  We need a short and inoffensive term, adequate to cover all reasonable alternatives, and "resting place" is as good as any.  If we want to be absolutely literal and eliminate all analogy or risk of sentiment, we'll have to use "Disposition of corpse", and, in most cases, "Consumed by worms and bacteria; excreted as soil."  A bit of decorum is not unencyclopedic.  J. D. Crutchfield  &#124; Talk 15:26, 19 February 2016 (UTC)
 * Leaps of decorum notwithstanding, you're addressing an alternative, not the main issue: whether, as long as _place renders place, we list a place. A suitable, agreeable alternative to place, "resting" or otherwise, would need to be crafted. &#128406; ATinySliver / ATalkPage 21:16, 19 February 2016 (UTC)
 * Forgive me if I misunderstood the problem. Perhaps it would be helpful to ask ourselves why the parameter exists in the first place?  Surely it's not merely to satisfy ghoulish curiosity as to the method used for the disposition of a notable person's corpse.  We care about a person's last resting place, I assume, because we'd like to know if there's a grave or monument we can visit, or some special location associated with the person's memory.  If there is no such place, then really all we need is to be told as much, in a conventional (and so unlikely to be disturbing), clear, and concise way.  The only exception I can think of would be where the disposition of the corpse is in itself notable.  (See examples below.)  In those cases, the value assigned to the parameter can state or imply that there is no physical place, without alarming the average reader.


 * Often, the ashes of cremated corpses are buried in cemeteries, placed in vaults or crypts, or otherwise put in identifiable locations. In such cases, the infobox need not even mention cremation (although it certainly could).  For example,


 * Resting place: Forest Lawn Cemetery
 * or
 * Resting place: Kremlin wall


 * In other cases, the ashes are scattered in some location that was meaningful to the deceased, and the infobox might read,


 * Resting place: Ashes scattered over Pacific Ocean


 * Other dispositions of the ashes or corpse can be described in whatever way best reflects the facts. For example,


 * Resting place: Ashes distributed to I.W.W. Branches throughout United States, except Utah
 * or
 * Resting place: Lost at sea
 * or
 * Resting place: Disintegrated by death ray
 * or
 * Resting place: Unknown
 * or even
 * Resting place: Cremated


 * These make it clear what happened to the person's corpse (as far as can be known), and, expressly or by implication, that there is no definite place where ghouls might dig it up, the reference to a "place" notwithstanding. (In the case of "Cremated", the implication might be simply that the deceased's loved ones took the ashes away, and that what they did with them is none of our business.)  This form is conventional, clear, and concise.  It's not confusing or misleading. To insist that a reference to a "place" in the form demands a physical location, with geographic co-ordinates that can be pinpointed on Google Maps, strikes me as unnecessarily pedantic.  Precision in forms is desirable, of course, and if anybody comes up with a more precise, decorous, clear, and concise alternative, then by all means we should consider it; but nothing I've seen proposed strikes me as better than "Resting place".  J. D. Crutchfield  &#124; Talk 23:23, 19 February 2016 (UTC)
 * I appreciate the clarity, thank you. I would only note that accuracy and pedantry are not necessarily mutually inclusive. &#128406; ATinySliver / ATalkPage  23:29, 19 February 2016 (UTC)
 * Agreed. ;0) J. D. Crutchfield  &#124; Talk 02:07, 20 February 2016 (UTC)
 * If we do ask the question "why the parameter exists in the first place?", then surely it is to locate a grave or similar place that has some relevance to the subject, whether or not we would wish to visit it - the point is that someone could. If there is no such place, then we don't need to use space in the infobox to tell people about that; the simple absence of an entry should suffice. The contents of an infobox are meant to provide a quick summary of key facts, not to answer every possible trivia question about the subject that might turn up in a pub quiz. By confining this parameter to locatable places, we are not engaging in "excessive concern with minor details and rules", but keeping the data "clean", so that it can be re-used in other applications without excessive effort. Now, there's no reason why we must make life easier for third-party re-users of our content, but given the choice, I think we should. The whole of this debate hinges on whether it is better to keep the information in a data field relatively consistent (and exclude values that don't fit, like actions instead of places), having the advantage that it can be easily re-used; or whether it is better to allow a free-for-all in the values allowed, having the advantage that editors can put absolutely anything they wish into the field, as it is clear from the discussion that those who want to include "cremation" as a burial/resting place would be happy to see a myriad of non-places there. Personally, my preference is the former. --RexxS (talk) 03:28, 20 February 2016 (UTC)
 * If we do ask the question "why the parameter exists in the first place?", then surely it is to locate a grave or similar place that has some relevance to the subject, whether or not we would wish to visit it - the point is that someone could. If there is no such place, then we don't need to use space in the infobox to tell people about that; the simple absence of an entry should suffice. The contents of an infobox are meant to provide a quick summary of key facts, not to answer every possible trivia question about the subject that might turn up in a pub quiz. By confining this parameter to locatable places, we are not engaging in "excessive concern with minor details and rules", but keeping the data "clean", so that it can be re-used in other applications without excessive effort. Now, there's no reason why we must make life easier for third-party re-users of our content, but given the choice, I think we should. The whole of this debate hinges on whether it is better to keep the information in a data field relatively consistent (and exclude values that don't fit, like actions instead of places), having the advantage that it can be easily re-used; or whether it is better to allow a free-for-all in the values allowed, having the advantage that editors can put absolutely anything they wish into the field, as it is clear from the discussion that those who want to include "cremation" as a burial/resting place would be happy to see a myriad of non-places there. Personally, my preference is the former. --RexxS (talk) 03:28, 20 February 2016 (UTC)
 * If we do ask the question "why the parameter exists in the first place?", then surely it is to locate a grave or similar place that has some relevance to the subject, whether or not we would wish to visit it - the point is that someone could. If there is no such place, then we don't need to use space in the infobox to tell people about that; the simple absence of an entry should suffice. The contents of an infobox are meant to provide a quick summary of key facts, not to answer every possible trivia question about the subject that might turn up in a pub quiz. By confining this parameter to locatable places, we are not engaging in "excessive concern with minor details and rules", but keeping the data "clean", so that it can be re-used in other applications without excessive effort. Now, there's no reason why we must make life easier for third-party re-users of our content, but given the choice, I think we should. The whole of this debate hinges on whether it is better to keep the information in a data field relatively consistent (and exclude values that don't fit, like actions instead of places), having the advantage that it can be easily re-used; or whether it is better to allow a free-for-all in the values allowed, having the advantage that editors can put absolutely anything they wish into the field, as it is clear from the discussion that those who want to include "cremation" as a burial/resting place would be happy to see a myriad of non-places there. Personally, my preference is the former. --RexxS (talk) 03:28, 20 February 2016 (UTC)

raises (I think for the first time in this discussion) another issue: re-usability of data. I've been working under the assumption that a Wikipedia infobox was intended solely as a convenient summary of essential facts for the benefit of Wikipedia's human readers, and that the reason for using templates and parameters in them was merely clarity and convenience for the reader. RexxS now quite reasonably suggests that we also consider the infobox's usefulness to computer programs, such as—I suppose—data aggregators, which might collect data from many, or all, of Wikipedia's infoboxes, and for which some sort of uniformity in the values assigned to parameters is highly desirable.

I have no fundamental objection to Wikipedia's being generally useful to computer programs. I would, however, object to the subordination of human interests to those of machines and applications—although I hasten to add that I don't know whether or not that would be the result of what RexxS is advocating.

Suppose we were to limit "resting place" to physical loci, with numerical map co-ordinates that could be passed to any application. What would then become of the examples I gave earlier, not all of which were whimsical? Joe Hill's ashes really were distributed to I.W.W. branches throughout the United States, except for Utah. (Some were seized by the Post Office because, you know . . . danger.) That's a notable fact, and seems to me to come under the rubric of "resting place", as discussed above; but you couldn't assign co-ordinates to Hill's ashes. The same goes for people lost at sea, and, more or less, for those whose ashes are scattered. Should these notable facts be omitted, simply because they don't make for tidy parameters? Human affairs are frequently untidy. I remain open to considering an alternative that serves all interests better than "resting place" (or "n place"), but so far I still vote Yes. J. D. Crutchfield &#124; Talk 18:08, 22 February 2016 (UTC)

I think if I understand here correctly, "cremated" is not an actual place, but the term's derivatives can be used as "cremated remains" or "ashes" scattered (somewhere), within the "resting place" field of the infobox. Most people refer to the term "final resting place" or some close variation thereof. Sam.gov (talk) 21:29, 24 February 2016 (UTC)

Post-RfC observation
Just to clarify (and since the closer recommended further discussion), I don't see a consensus above that if someone's ashes are stored at a columbarium, or were scattered at some specific place, that this would not be appropriate to use this parameter for; the only difference is whether the body is "intact" or not (and, given embalming, autopsies, etc., no bodies are "intact", at least in modern, Western burial). The problems with using "where someone was cremated" as "resting place" are a) it's the same thing as treating "where someone was embalmed before burial" in that way, which might even be a different country, and b) it serves no encyclopedic purpose (the reason we include "resting place" information at all is that some gravesites are of public, mostly spiritual/honorary interest; these reasons don't apply to body-processing facilities used on the way from the transition from freshly deceased to "final resting"). The problem with including simply "cremated" as "resting place" is that the content does not match the parameter (it's essentially the same debate about, and already concluded against, including "atheist" in the "religion" parameter. PS: I was going to raise a euphemisms concern about the name of this parameter, but perhaps that should be another discussion, and I don't feel as strongly about this as some other editors do.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  02:48, 16 March 2016 (UTC)
 * If there's a confirmed, sourced location for the cremains, even something as generic as, say, "Ashes scattered in the Pacific Ocean", that's wholly appropriate. &#128406; ATinySliver / ATalkPage 03:28, 16 March 2016 (UTC)
 * Late to this, but not to the wider debate: I've made the point many times before that "resting place" is not a euphemism. It uses the past tense of "to come to rest", in other words to stop moving. Consider: "The ship came to rest in a deep ridge on the ocean floor". "His marble came to rest two inches from its target". Andy Mabbett ( Pigsonthewing ); Talk to Andy; Andy's edits 12:27, 16 March 2016 (UTC)
 * Still a euphemism in my book. It's a metaphor for "buried" or 'remains scattered at". By your reasoning, the bed someone died in, or battlefield on which they were shot and died, is their "resting place", that being where they came to rest.  Coming to rest and being laid to rest are different things, and "being laid to rest" is a euphemism.  "Resting" is a euphemism, the exact same one used in "we had to put the dog to sleep". It's the same metaphor as "sleeps with the fishes", "the dirt nap", etc., etc.: a likening of death to a never-ending slumber (or not never-ending, depending on one's spiritual beliefs, if any). [To clarify earlier comment: I do feel strongly that this is euphemism; what I don't feel strongly about is some other editors' insistence that we must at all costs avoid all forms of euphemism, a view that gets pushed at WT:WTW quite frequently and in my view a bit excessively.]  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  15:34, 16 March 2016 (UTC)
 * I agree that any blanket no-euphemisms policy is silly—the more common its use, particularly globally, the more likely a euphemism would be considered acceptable encyclopedic language. That said, in this specific case, I find "resting place" to be like "passed away"—crafted specifically to mollify the sensitive and, therefore, not encyclopedic. &#128406; ATinySliver / ATalkPage 21:05, 16 March 2016 (UTC)
 * Is it worth mentioning that I made the effort to implement the burial_place parameter, which displays "Burial place" as label, as an optional alternative to resting_place for those editors who prefer not to use the latter? Obviously, it's only usable when a burial occurred. --RexxS (talk) 22:33, 16 March 2016 (UTC)
 * I would only repeat that the parameter is not relevant so much as how it's rendered. Also, the instructions for its proper use need added clarity. &#128406; ATinySliver / ATalkPage  22:40, 16 March 2016 (UTC)
 * Well, Somewhere renders as Burial place Somewhere, as an alternative to Somewhere, which renders as Resting place Somewhere . I'm not sure what else I can offer to meet your concerns. If you're offering to update the documentation to reflect the outcome of the RfC and to clarify the proper use of the parameters, I'm sure we'd all be grateful. --RexxS (talk) 23:30, 16 March 2016 (UTC)
 * You're exactly right, and that's exactly what needs to be addressed. Several of us have offered suggestions, and I think the result will be some variation thereof. &#128406; ATinySliver / ATalkPage 23:35, 16 March 2016 (UTC)
 * Your book is faulty. Get a new one. Andy Mabbett ( Pigsonthewing ); Talk to Andy; Andy's edits 12:29, 4 April 2016 (UTC)

So, how to fix it?
Based on the suggestions by myself and others, and the comments thereto, the most logical (and least disruptive) response is, I think, to leave intact the parameter and change how it is rendered within article space. Some updated ideas: The instructions at the template page would need to be addressed only if one of these suggestions—or a better one from another editor or the discussion resulting therefrom—is implemented. &#128406; ATinySliver / ATalkPage 23:57, 16 March 2016 (UTC)
 * Burial data—while still technically inaccurate, the use of "Cremated" would not be a complete fallacy;
 * Post-mortem data—makes virtually anything that follows accurate (though it's admittedly clunky);
 * Disposition of remains—also allows virtually anything on point, but at least one editor finds this "gruesome, grisly, and positively silly";
 * Burial/interment/cremation—as pointed out above, too damned long;
 * Burial site—addresses only the euphemism "resting place" and would, like doing nothing, require that "Cremation" be removed (again) from infoboxes.


 * There is nothing to fix. It's not broken. And "resting place" is not a euphemism. Andy Mabbett ( Pigsonthewing ); Talk to Andy; Andy's edits 12:31, 4 April 2016 (UTC)

Template-protected edit request on 3 April 2016
Per the RfC above, change Place of burial, ash-scattering, etc. to read Location of burial, ash-scattering, etc. If no location, leave blank. &#128406; ATinySliver / ATalkPage 00:17, 4 April 2016 (UTC)


 * Padlock-pink-open.svg Not done: According to the page's protection level you should be able to edit the page yourself. If you seem to be unable to, please reopen the request with further details. The documentation page is not protected. Izno (talk) 00:47, 4 April 2016 (UTC)
 * Well, fuck me. I keep forgetting about the separate doc pages ... &#128406; ATinySliver / ATalkPage  01:17, 4 April 2016 (UTC)
 * I'd really rather not. What part of the RfC do you feel came to this conclusion? Andy Mabbett ( Pigsonthewing ); Talk to Andy; Andy's edits 12:34, 4 April 2016 (UTC)
 * Q: Should the "resting place" parameter be used for "Cremation" such as used here?
 * A: It seems pretty clear, with decent arguments on both sides, that the nos have it.
 * That bit, I guess, as that's the conclusion of the RfC. Although I have no idea how that conclusion relates to the edit request. --RexxS (talk) 16:16, 4 April 2016 (UTC)
 * "Following the ..." might have been better language; but it was clear that, whatever the outcome, clarity was necessary, and the actual outcome supports the changes. &#128406; ATinySliver / ATalkPage 19:43, 4 April 2016 (UTC)
 * "Following the ..." might have been better language; but it was clear that, whatever the outcome, clarity was necessary, and the actual outcome supports the changes. &#128406; ATinySliver / ATalkPage 19:43, 4 April 2016 (UTC)

Use of "family" parameter to list relatives
The documentation recomments using the "relatives" parameter to list the members of the extended family (like brothers/sisters, uncles/aunts, etc.), however a lot of instances intuitively use the "family" parameter, which was intended for noble family or house or any notable family with its own article, like Kennedy family. Can "family" be added as an alternative keyword for "relatives" and the actuall keyword renamed to "house", "clan" or something similar to avoid the confusion? --92.242.59.6 (talk) 11:06, 8 April 2016 (UTC)
 * I'm not sure if you're confusing the label displayed with the name of the parameter, there's nothing called 'keyword'. If you're suggesting changing the name of the parameter from family to house or whatever, that could be done, However, it would then need a bot to check all 210,00+ pages that use this infobox and change the name of the parameter where used in those articles as well. I suspect that may be too big a job to justify your solution to an error that might be alleviated by better documentation. --RexxS (talk) 14:14, 8 April 2016 (UTC)
 * I'm afraid better documentation won't help at this point, because there are too many incorrect uses of 'family'. Most of these uses are for listing relativces, so I'd think it would be much easier to reassign this name as an alias for 'relatives', then correct a few instances where 'family' actually indicated a clan or a royal family, because most people typically don't have one. --92.242.59.6 (talk) 13:24, 21 April 2016 (UTC)

Ethnicity parameter
There is no mention of an ethnicity parameter in the template documentation, but it can still be used (e.g. Jessica Jung). Is there a consensus for when and how to use this parameter? Random86 (talk) 02:51, 24 April 2016 (UTC)
 * That parameter might not be around for much longer - there's been lively discussion about deprecating it, as it proves more troublesome than helpful.-- 3family6 ( Talk to me   &#124;  See what I have done  ) 03:28, 24 April 2016 (UTC)

Change Spouse(s) to Spouse
We have had a request here at the Teahouse that Infobox person list Spouse in the singular rather than Spouse(s), seeming to assume that people have multiple spouses even when there is only one. Template:Infobox royalty does this. As we can see at Henry VIII of England the list of his six spouses is labeled "Spouse". I am making a similar request for Partner(s) for the same reason. StarryGrandma (talk) 04:23, 25 April 2016 (UTC)
 * ❌ - Consensus or least several days passing with no one commenting on your proposal would be needed for such a change.
 * Personally, I would oppose the change because (s) means on optional plural. It is that way because former spouses are listed there by date. I suppose it would also be useful in the case of a polygamists, but it doesn't assert that. — Godsy (TALK CONT ) 04:56, 25 April 2016 (UTC)


 * I would oppose this. The request seems to be purely the result of a grammatical misunderstanding. "Spouse" alone assumes one spouse only. Spouse(s) does not imply multiple spouses, but only allows for the possibility of more than one, and the natural assumption of that is not at the same time, but a person who's been married more than once.--Fuhghettaboutit (talk) 12:29, 25 April 2016 (UTC)


 * I oppose as well any change to the template. Although this is requested for good faith reasons, this seems to me as veiled vanity. People do choose to remarry after having a spouse die, which does not in the least imply divorce or any negativity. Fylbecatulous</b> <b style="color:#DB7093">talk</b> 12:39, 25 April 2016 (UTC)


 * I would support the change to simply "Spouse". Compare infobox opera, librettist. In many cases, there is only one. When there are more, it's easily visible, see for example Carmen. There was a discussion on the template talk before dropping the "(s)" as unneeded. (I noticed this only now.) --Gerda Arendt (talk) 12:52, 25 April 2016 (UTC)
 * Note: prior discussion at Template talk:Infobox person/Archive 14 and Template talk:Infobox person/Archive 27--Fuhghettaboutit (talk) 21:12, 25 April 2016 (UTC)

"Influences"
Are currently used for scientists etc. but there seems to be no consistency as to whether a source calling people an "influence" is required, and this leads to "micro-essays" in infoboxes. See Richard Dawkins where the assortment proffered seems to be subjective opinion rather than simple objective fact. IMO. Should "not objective fact" fields be discouraged in infoboxes? Collect (talk) 18:55, 27 April 2016 (UTC)
 * Yes. --RexxS (talk) 20:09, 27 April 2016 (UTC)

Awards - distinctions?
Distinctions, decorations, honours, honors, accolades and awards seem to be the most common terms for this information in biographical articles. This discussion naturally also applies to titles in the contents other than the parameter of this infobox. All of them have pros and cons. On the ground of netruality, I would advocate "Distinctions". Why? Not everybody considers them decorations (term implying aesthetical value). Not all consider them honours (and yet get to avoid the discussion of preferences for "o" or "ou"). The term accolades, although connoting a broad sense today, inevidently has a specific historical etymology. Awards, lastly, complicate the matter by risking to limit the possible contents, considering that all distinctions aren't really awards as such. So, all in all, I would advocate "distinctions" as the most strict and neutral yet broadest term for the relevant information. Chicbyaccident (talk) 20:05, 7 May 2016 (UTC)

As for the "party" parameter,...
Is the parameter only to be used for political persons? Presumably not (because the template's note does not say so), or, otherwise, I never would have added information to Gabe Newell's article in the first place, so I need to find out about it. Gamingforfun 3 6 5 ( talk ) 21:49, 22 May 2016 (UTC)
 * This archive may be relevant for the discussion. Gamingforfun 3 6 5 ( talk ) 21:58, 22 May 2016 (UTC)
 * Ping me when you reply to this discussion. Gamingforfun 3 6 5 ( talk ) 22:08, 22 May 2016 (UTC)
 * I've weighed in on this somewhere before, ; darned if I can remember where, though. My thought is that it should be included only when there's a legitimate, demonstrable correlation between an article's subject and the readers' understanding of who that person is/was. For example, a party spokesperson is a definite yes, even if never elected. A highly documented outspoken celebrity such as Charlton Heston is a definite yes; I'd also call Alec Baldwin a yes. Other people will be somewhere in a large gray area. Absent such a correlation, though, inclusion serves only to dilute the parameter's purpose, IMO. &#128406; ATinySliver / ATalkPage 22:22, 22 May 2016 (UTC)

Help creating an infobox
How would folks feel if I moved this entire discussion to Template talk:Infobox horse person and left a link here? It's really not directly relevant to Infobox person at the moment. --RexxS (talk) 19:55, 28 May 2016 (UTC) Works for me. <span style="text-shadow:#F8F8FF 0.2em 0.2em 0.4em,#F4BBFF -0.2em -0.3em 0.6em,#BFFF00 0.8em 0.8em 0.6em; color:#A2006D;">Atsme 📞📧 21:14, 28 May 2016 (UTC)

Use of material not in the body of an article
Where a claim about a person is not made nor sourced within the body of any article, should such claims then be allowed in the infobox? shows my opinion thereon. Collect (talk) 14:48, 4 June 2016 (UTC)
 * How does removing sourced information improve the article? I can't understand why you didn't simply add the information and reference to the body of the article. If you want to ask the question "is net_worth a useful piece of information for the Barbra Streisand infobox?", then the appropriate place to ask is Talk:Barbra Streisand. --RexxS (talk) 16:48, 4 June 2016 (UTC)
 * Yes. When the appropriateness of an infobox item is debatable, its absence from the prose weights against including it in the infobox as anything important enough to list there usually merits discussion in the text as well. However, there's no firm guideline, and counterexamples abound. Take height, for instance: for athletes, it's clearly encyclopedic, yet repeating it in sentence form would be an exercise in verbosity. I suggest you open a thread at the article's talk page. Rebb  ing  19:23, 4 June 2016 (UTC)

Attention template editors!
Please see Category talk:Biographical templates usable as a module. Jujutsuan ( Please notify with &#123;&#123;re&#125;&#125; talk &#x7C; contribs) 13:35, 30 June 2016 (UTC)

Nationality vs Citizenship
How should someone's "nationality" or "citizenship" be described in the infobox if they are a permanent resident, but not a citizen, of that country? I am referring specifically to a dispute involving the late professional boxer Trevor Berbick. As an amateur he represented his birthplace Jamaica and that part is not in dispute. As a pro, however, he was based in Canada for most if not all of his pro career. He was a legal permanent resident (landed immigrant) for most of that time but never chose to apply for Canadian citizenship. He was generally known as a Canadian boxer for that time period--for example holding the Canadian heavyweight boxing championship. But according to reliable sources he never actually held Canadian citizenship, choosing instead to remain in Canada as a non-citizen permanent resident. Should his nationality be described as Canadian? Dash77 (talk) 17:38, 5 June 2016 (UTC)
 * Two points:
 * Any piece of information that's not straightforward is unsuitable to be included in an infobox. It's fine to discuss Berbick's citizenship and nationality in the body of the article when there is space and time to explore the nuances and provide the references that explain the information. But it really needs more than a single word to do that, so I'd recommend you leave it out of the infobox.
 * There was a recent RfC on the inclusion of 'ethnicity' in infoboxes, which also discussed the 'nationality and 'citizenship' parameters. The opinions expressed there are worth a read when you are uncertain about what is appropriate to use for those parameters.
 * Hope that helps. --RexxS (talk) 20:19, 5 June 2016 (UTC)
 * And, am I correct that parameters left blank simply do not appear, so there is no need to fill them, as they will not clutter the final product with blank fields?  Montanabw <sup style="color:orange;">(talk)  00:13, 6 June 2016 (UTC)
 * In a normal infobox, that's correct. (A Wikidata-enabled infobox may behave differently, but that's another story.) The only problem with putting something like nationality is that editors may take it as a request to supply a value for the field. If that's not what is intended, it's probably best to leave it out altogether. In my experience, short, concise infoboxes are more likely to survive a pogrom by the anti-infobox brigade. Andy may disagree with me on some or all of that, though. --RexxS (talk) 00:43, 6 June 2016 (UTC)
 * Yes, leaving in empty infobox parameters is very frequently interpreted as "this information is missing, please add it, even if you're not sure or don't have a source", and is the proximal cause of a great deal of the infobox-related strife. For this reason, I delete empty ones on sight, and do not add them when adding an infobox.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  09:41, 3 July 2016 (UTC)
 * But, leaving in empty infobox parameters is very frequently interpreted as "this information is missing, please search for a reliable source so that is can be added"? It may already be in the article. It does save skipping back constantly to the template description to check what's missing? I do agree, though, that blanks can prompt some newer editors to assume they know what "nationality" means and to add a best guess. I know that some editors think supporting references in the infobox are useful, while others think they are just clutter and that the contents of the infobox should always be supported, with the source(s), in the article itself. What does MoS say about that? Martinevans123 (talk) 10:51, 3 July 2016 (UTC)
 * Parameters set to blank in an infobox might have three different meanings that I'm aware of: (1) "Please fill in the value of this if you can find it"; (2) "This field is not to be used in this article - please leave it blank;" or possibly even (3) Fetch the value of this field from Wikidata (I don't know of any implementing that meaning yet). In other words, you just don't know what the editor intended. One solution is to upgrade to smarter infoboxes. The Module:WikidataIB contains calls to suppress named fields, which can be used to upgrade existing infoboxes. By supplying, for example, nationality, ethnicity in a given article the infobox would never display nationality or ethnicity in that article, and the intention would hopefully be made clear. I'm sure other solutions are possible, but we would be far better off implementing some solution, rather than leaving folks to guess. As for MoS, it says what we tell it to say - by that I mean it's meant to document accepted practice, not lay down rules. If practices differ fundamentally, then MoS should be silent on the issue. Personally, I think any statement that might be challenged should be referenced, including in the lead and infoboxes, but I'm not offended if others hold different opinions. --RexxS (talk) 12:33, 3 July 2016 (UTC)
 * Thanks for thinking outside the box, there. (Could you mention that "rules" bit again to Stanton? Thanks.) Martinevans123 (talk) 12:38, 3 July 2016 (UTC)
 * Parameters set to blank in an infobox might have three different meanings that I'm aware of: (1) "Please fill in the value of this if you can find it"; (2) "This field is not to be used in this article - please leave it blank;" or possibly even (3) Fetch the value of this field from Wikidata (I don't know of any implementing that meaning yet). In other words, you just don't know what the editor intended. One solution is to upgrade to smarter infoboxes. The Module:WikidataIB contains calls to suppress named fields, which can be used to upgrade existing infoboxes. By supplying, for example, nationality, ethnicity in a given article the infobox would never display nationality or ethnicity in that article, and the intention would hopefully be made clear. I'm sure other solutions are possible, but we would be far better off implementing some solution, rather than leaving folks to guess. As for MoS, it says what we tell it to say - by that I mean it's meant to document accepted practice, not lay down rules. If practices differ fundamentally, then MoS should be silent on the issue. Personally, I think any statement that might be challenged should be referenced, including in the lead and infoboxes, but I'm not offended if others hold different opinions. --RexxS (talk) 12:33, 3 July 2016 (UTC)
 * Thanks for thinking outside the box, there. (Could you mention that "rules" bit again to Stanton? Thanks.) Martinevans123 (talk) 12:38, 3 July 2016 (UTC)
 * Thanks for thinking outside the box, there. (Could you mention that "rules" bit again to Stanton? Thanks.) Martinevans123 (talk) 12:38, 3 July 2016 (UTC)

Please remove from TemplateData
should be removed as a parameter from the Infobox person TemplateData. is not recognized by the template itself and throws an error. The fact that  is listed alongside (and ahead of)   means that the correct parameter  cannot be input in the visual editor, and thus adding   necessitates a trip over to the source editor. — Preceding unsigned comment added by Plandu (talk • contribs) 01:12, 6 July 2016 (UTC)
 * ✅ -- John of Reading (talk) 06:26, 6 July 2016 (UTC)

Infobox image size
As per WP:IMGSIZE, we should implement changes which respect a user's preference to use the base image size of their choice. The default is "220px", but a user can set this to other values, such as "400px". Instead of a hard coded size for an infobox image, "upright=#.##" should be used, as is implemented in Template:Infobox aircraft occurrence, which transcludes Module:InfoboxImage. The way Infobox aircraft occurrence does this in practice (the precise syntax is in the template at that location) is to use an upright value if present (otherwise defaulting to 1/no modification), then fall back to use size/image_size if explicitly declared - but designated as a deprecated parameter which should be deleted or migrated to an 'upright' - and otherwise fall back to user preferences or site defaults if neither are present. See above template for suggested/workable implementation. Skybunny (talk) 05:37, 7 July 2016 (UTC) PAGE''' ]]) 14:29, 7 July 2016 (UTC)
 * Can you mock it up in the sandbox? --Ahecht ([[User_talk:Ahecht|<span style="color:#FFF;background:#00f;display:inline-block;padding:1px 1px 0;vertical-align:-0.3em;line-height:1;font-size:50%;text-align:center;">'''TALK
 * Argh, I see the problem. It was added almost a year ago, and nobody ever documented it. OKAY! I've just added the docs (go have a look!) I did notice that there's a signature_size (for the signature image) so that probably should have a companion parameter which is preferred (that is, something like signature_upright). Skybunny (talk) 17:55, 7 July 2016 (UTC)

Birth name parameter
Question, if the article title has a persons first and last name, for example Jon Smith, can the birth_name parameter inside the infobox include his middle name, example: Jon Alexander Smith? Or should it be left blanked? I have seen that it is a common practice to insert the middle name in this parameter. Now if he had no middle name, then of course to leave it blank. Tinton5 (talk) 21:50, 14 July 2016 (UTC)


 * The question is not whether it *can* include the middle name, but whether it is *worthwhile* to add the birth name parameter just to repeat the middle name, which is given again in the first line of the Lead. If the birth name were completely different from the article name, then the birth name would be of interest, but to add it to the infobox just to show the middle name again in the box is not helpful.  See WP:INFOBOX. -- Ssilvers (talk) 22:21, 14 July 2016 (UTC)
 * I'd like to get someone else's opinion if you don't mind, thank you. Tinton5 (talk) 19:00, 15 July 2016 (UTC)


 * Eh. I agree that, in most cases, birth_name shouldn't be used just to show a person's middle name because it's typically trivial and adding it needlessly clutters the infobox as it's stated in the lede. However, if you're already showing birthdate and birth place, it doesn't add much visual clutter to stick birth name in that block as well, so, in that case, I think it's appropriate. (See, for example, Flannery O'Connor.) Rebb  ing  19:14, 15 July 2016 (UTC)
 * I'd agree with ' general preference to keep infoboxes concise as far as possible. It is difficult, however, to judge whether something is worthwhile, because we really don't know for sure what visitors to an article are looking for. Another way of looking at the question is to try to get some estimate of what constitutes common practice on Wikipedia. If you examine a number of articles from Pages that link to "Template:Infobox person", you'll get some feel for how common it is to include the birth_date parameter where the subject has a middle name. Hope that helps. --RexxS (talk) 19:27, 15 July 2016 (UTC)
 * I agree with User:Ssilvers' reading of the overleaf guidance: birth_name should only be used if it's different from the subject's current name, and I mean really different. Mentioning the middle name of Jon Alexander Smith who is generally known as Jon Smith only clutters the infobox – which is meant to present concisely the most important biographical facts; same for Flannery O'Connor. I disagree with User:RexxS (who presumably mistyped when he mentioned birth_date) that inspecting current usage is a valid guide in this question. I've seen too many infoboxes where the subject's name is repeated identically. -- Michael Bednarek (talk) 06:56, 16 July 2016 (UTC)


 * Only if substantially different and if notable (we often exclude birth names per WP:BIRTHNAME). Use editorial discretion but err on the side of nit using it. For just a middle name, don't use. That can go in the lead sentence instead.  Eve rgr een Fir  (talk) 08:11, 16 July 2016 (UTC)

Infobox actor
Shouldn't there be a filmography option listing count of films the actor has acted in by industry? I mean like 400 Bollywood movies, 300 Hollywood movies etc. -- Pankaj Jain Capankajsmilyo (talk · contribs · [//tools.wmflabs.org/xtools-ec/?user=Capankajsmilyo&project=en.wikipedia.org count])  09:50, 20 July 2016 (UTC)

Documentation
In the documentation on the religion parameter there is a note that says "Religion should be supported with a citation from a reliable source". This notice should be removed because the manual of style says that reference tags shouldn't be in infoboxes (WP:INFOBOXREF); these references belong in the body text. Also requiring statements to have sources should be obvious.--Prisencolin (talk) 22:50, 21 July 2016 (UTC) PAGE''' ]]) 15:48, 22 July 2016 (UTC)
 * Given the sensitivity of the issue, the warning makes sense. However, it could be changed to "Religion should be supported in the article with a citation from a reliable source". --Ahecht ([[User_talk:Ahecht|<span style="color:#FFF;background:#00f;display:inline-block;padding:1px 1px 0;vertical-align:-0.3em;line-height:1;font-size:50%;text-align:center;">'''TALK
 * Agreed :: Kevinalewis  : <sup style="color:#C90">(Talk Page) /<sub style="color:#C90">(Desk)  16:01, 22 July 2016 (UTC)
 * Actually, the manual of style doesn't say "that reference tags shouldn't be in infoboxes". The text of WP:INFOBOXREF is:
 * References are not needed in infoboxes if the content is repeated (and cited) elsewhere or if the information is obvious. If the material requires a reference (see WP:MINREF for guidelines) and the information does not also appear in the body of the article, the reference should be included in the infobox. However, editors should first consider including the fact in the body of the article.
 * In the case of religion, the consensus is that references are required, so the documentation probably ought to read something like "Religion should be supported with a citation from a reliable source in the infobox, unless the citation is already in the article text". --RexxS (talk) 18:50, 22 July 2016 (UTC)
 * In the case of religion, the consensus is that references are required, so the documentation probably ought to read something like "Religion should be supported with a citation from a reliable source in the infobox, unless the citation is already in the article text". --RexxS (talk) 18:50, 22 July 2016 (UTC)

Parameters for actors
Should the agent parameter be used for actors? This is often used on Korean actor pages. Also, "notable works" is often used to list films and TV series, and "awards" is used to put the number of awards they have received. See Lee Min-ho (actor, born 1987) and Kim Ji-won (actress) for some examples. I don't see these parameters being used this way elsewhere on Wikipedia. Is there consensus on how to use these parameters for actors? Random86 (talk) 06:11, 17 July 2016 (UTC)


 * No. The only use for such an item is commercial, and as the information is not particularly encyclopedic or of general interest to readers, it should not really be used t all. Collect (talk) 12:05, 17 July 2016 (UTC)
 * That's what I was thinking for the "agent" parameter. Anyone else have an opinion on how these parameters should be used? Random86 (talk) 22:54, 31 July 2016 (UTC)

Use of Birth Date and age?
Would it be possible to get a maintenance category going for this template that indicates pages that use Infobox person but do NOT use birth date and age or death date and age? I would like to start cleaning those up but need a tracking category to make it happen. you four have all recently edited this template so I would love your thoughts on the subject! -- Zackmann08 (Talk to me/What I been doing) 20:21, 24 July 2016 (UTC)


 * there is always the chance that this infobox uses other similar infoboxes or cases where adding these infoboxes is not an option. -- Magioladitis (talk) 20:23, 24 July 2016 (UTC)


 * Can you explain? I don't follow... -- Zackmann08 (Talk to me/What I been doing) 20:24, 24 July 2016 (UTC)
 * , I am assuming you want this conditioned on using birth_date or death_date? if not, you can just use https://petscan.wmflabs.org/ Frietjes (talk) 20:25, 24 July 2016 (UTC)
 * Check Plato for instance. -- Magioladitis (talk) 20:26, 24 July 2016 (UTC)
 * Ok now I gotcha. That makes sense. I guess some crazy regex could be use to check if they are supplying a CE date?
 * that would be my thought yes. That is an interesting idea. I'll look into using pet scan. Thanks! -- Zackmann08 (Talk to me/What I been doing) 20:30, 24 July 2016 (UTC)
 * , for example, this scan. Frietjes (talk) 21:07, 24 July 2016 (UTC)

Gotcha! The scan has to be a bit more complicated then that because of the multiple different birth date templates... HERE is what I came up with. Something you might want to look at is this discussion. I found that there is both a birth date and age AND a birth-date and age. The only difference is that one can take the date as one parameter. So.... =. Seems like there has got to be some way to make both formats work for birth date and age.... -- Zackmann08 (Talk to me/What I been doing) 21:13, 24 July 2016 (UTC)
 * , Here's a couple of searchs that you could use as well, search 1 and search 2 that might be a good starting point articles worth updating. -- WOSlinker (talk) 21:18, 24 July 2016 (UTC)
 * Have you automated the process, or are you going to do it by hand? --Richard Arthur Norton (1958- ) (talk) 02:29, 11 August 2016 (UTC)

"Home town" parameter
I've never understood why this one is so low down. In my opinion it would better placed right up next to birth name, date and place. —  Cliftonian   (talk)  16:43, 31 July 2016 (UTC)
 * Why? It's rarely used (and from what I've seen, even more rarely used correctly) and isn't particularly important in most cases. Nikkimaria (talk) 17:58, 31 July 2016 (UTC)
 * Well, why have it at all then? —  Cliftonian   (talk)  18:09, 31 July 2016 (UTC)
 * Good point. Get a consensus here and we can remove it. --RexxS (talk) 18:15, 31 July 2016 (UTC)
 * I actually did use this for once on this new article: Katelynne Cox. The reason being, reliable sources seem to be in conflict as to whether she was born in Camas, Washington or Portland, Oregon. The bio on her website says "born and raised" in Camas, but at least one third-party source says Portland. Because of that, I have left the birth place parameter blank and simply given her current residence (Washington, D.C.) and what is clearly her hometown, Camas. If nothing else, this parameter is helpful if we are not exactly sure where the subject in question was actually born, but we do know where they were raised.-- 3family6 ( Talk to me   &#124;  See what I have done  ) 04:22, 1 August 2016 (UTC)
 * I actually did use this for once on this new article: Katelynne Cox. The reason being, reliable sources seem to be in conflict as to whether she was born in Camas, Washington or Portland, Oregon. The bio on her website says "born and raised" in Camas, but at least one third-party source says Portland. Because of that, I have left the birth place parameter blank and simply given her current residence (Washington, D.C.) and what is clearly her hometown, Camas. If nothing else, this parameter is helpful if we are not exactly sure where the subject in question was actually born, but we do know where they were raised.-- 3family6 ( Talk to me   &#124;  See what I have done  ) 04:22, 1 August 2016 (UTC)


 * Remove it The above post is a prime problem with the field. What does the term mean "Where a person was born?" - "Where they grew up?" - "Where they live currently?" This is one of those fields where the info is better discussed in prose in the body of the article. MarnetteD&#124;Talk 04:29, 1 August 2016 (UTC)
 * Well, 3family6's post is essentially the point I was trying to make. Doesn't it look odd having no birth town given and "Home town" all the way down at the bottom of the biographical section? An alternative case is if someone was born in one place but grew up somewhere completely different; the formatting in that case also looks more than a bit odd. If we do retain such a parameter it would be more logical to have it further up by the birth details. That said, I can't say I disagree with MarnetteD's post that this is probably something better done away with an dealt with in the prose. —  Cliftonian   (talk)  08:20, 1 August 2016 (UTC)
 * Even birth_place is difficult, do we mean the town of their parents legal residence when they were born, or the location of the hospital or taxicab where they popped out of their mother's uterus. --Richard Arthur Norton (1958- ) (talk) 19:22, 11 August 2016 (UTC)
 * My understanding is the latter, which is why birth statistics are often distorted by where the local maternity hospital is. —  Cliftonian   (talk)  13:42, 15 August 2016 (UTC)


 * Remove it we have the field "residence" for living people. --Richard Arthur Norton (1958- ) (talk) 03:40, 15 August 2016 (UTC)

Spouse param
Doc says "Use the format Name (married 1950–present) for a current spouse, and Name (married 1970–99) for former spouse(s)." But that's not how this field is usually used I don't think. I see a lot of "m. 1959" and also use of template:marriage, which produces the same thing. I have used the documented format only to have it changed by another editor. Is this still the recommended format, and if so why? Kendall-K1 (talk) 14:32, 22 August 2016 (UTC)

Education and Alma_Mater
Is there consensus to remove degrees-earned from the Education or Alma_Mater fields in the template? User:Therequiembellishere is actively removing them and leaving an edit summary "removing clutter", see this edit and this edit and this edit. Naming an institution without the accompanying degree does not serve the reader. I noticed it at Franklin D. Roosevelt when I looked to see where he went to law school. --Richard Arthur Norton (1958- ) (talk) 02:34, 11 August 2016 (UTC)


 * This is something Masageee33 has been continually blocked for doing. The general usage that I know of involves putting institutions in alma_mater and the degree and degree program in the education field, if they are specifically known. This has been the general standard since I've been here for nearly 10 years. Therequiembellishere (talk) 02:54, 11 August 2016 (UTC)


 * Ah, I see. So if we only know the institution we use the Alma_Mater field. When we know the degree and even the year, we use education. Is there a consensus on including the year? I see a mixture of use and non-use. You are saying the right thing, but the above edits show you are just removing the degrees instead of changing the field name to "education". --Richard Arthur Norton (1958- ) (talk) 18:55, 11 August 2016 (UTC)


 * In my experience, I don't usually see both fields used. Normally I see the institution with the degree in the education field or just the institution in the alma mater field. Graham (talk) 19:07, 11 August 2016 (UTC)
 * Yes, me too. Sorry if my wording suggested otherwise. I have never seen both used. --Richard Arthur Norton (1958- ) (talk) 19:30, 11 August 2016 (UTC)
 * I could use some help reversing the deletion of degrees. The editor has not been leaving edit summaries, the only way to tell is if the article is a biography and we see a negative edit count. --Richard Arthur Norton (1958- ) (talk) 19:30, 11 August 2016 (UTC)
 * I don't see where "deletion of degrees" has occurred. I do see where degrees have been inappropriately added to the wrong fields (such as the alma mater field), and then those problematic edits were reverted. Xenophrenic (talk) 18:13, 24 August 2016 (UTC)


 * User:Therequiembellishere is also changing law schools and medical schools to the parent university in multiple entries using piping. Is this proper? As a reader I find it confusing to click on a link and take me to a different entry. I can see doing the piping in the reverse, say, if we do not have an entry for a medical school, display the medical school and pipe to the parent institution. I expect to see a law school or medical school for those degrees, not the parent university: " | alma_mater =University of Virginia" — Preceding unsigned comment added by Richard Arthur Norton (1958- ) (talk • contribs)
 * I would say that that probably violates WP:EASTEREGG. Graham (talk) 20:11, 11 August 2016 (UTC)
 * Could you provide a link to where such a change was made, or where such an "Easter Egg" was created? The alma mater field should only contain the main institution name ("parent institution", I believe you called it), and not the names of satellite schools, branches, specialty divisions, etc.  The education field, however, can have the more specific school name within the main institution listed. Xenophrenic (talk) 18:13, 24 August 2016 (UTC)
 * Am I correct in assuming you intended to direct your question to Richard? Graham (talk) 05:00, 25 August 2016 (UTC)
 * You are correct, Graham, but I did borrow your "Easter Egg" phrase. Xenophrenic (talk) 06:54, 25 August 2016 (UTC)

The guidance from this Infobox page advises: The longstanding convention is to follow that guidance, resulting in the "Alma mater=" field (when used) containing only the name of the institution of higher learning, and the "Education=" field (when used) containing the degrees and fields of study, and optionally the institution and graduation year. When both fields are used correctly, the contents usually appears formatted as it does in the John Roberts article. So to answer the first question at the top of this section: Yes; there is consensus to remove degrees, dates, fields of study, weird font formatting and other "clutter" from the alma mater field, but not from the education where it is allowed. Xenophrenic (talk) 19:47, 12 August 2016 (UTC)
 * education: Education, e.g., degree, institution and graduation year, if relevant. If very little information is available or relevant, the |alma_mater= parameter may be more appropriate.
 * alma_mater: Alma mater. This parameter is a more concise alternative to |education=, and will often consist of the linked name of the last-attended higher education institution. It is usually not relevant to include either parameter for non-graduates, but article talk page consensus may conclude otherwise, as at Bill Gates.

Organisation parameter
I'm not very good with templates but I feel there is a need for an organisation parameter within the infobox, for use in British/Australian/Indian etc articles, in the same way such an option is available at Template:Infobox organisation. This was previously discussed here and consensus seemed to favour such an edit. Could anyone assist with this? AusLondonder (talk) 01:56, 22 August 2016 (UTC)
 * Do you mean you like to have a parameter called organisation that displayed a label "Organisation" in the infobox? I see that Template:Infobox organization (the en-gb spelling is a redirect) allows parent_organisation as an override for parent_organization and adjusts the label accordingly. Although it doesn't offer the option in Visual Editor. I've made the change in Template:Infobox person/sandbox:
 * Do you mean you like to have a parameter called organisation that displayed a label "Organisation" in the infobox? I see that Template:Infobox organization (the en-gb spelling is a redirect) allows parent_organisation as an override for parent_organization and adjusts the label accordingly. Although it doesn't offer the option in Visual Editor. I've made the change in Template:Infobox person/sandbox:

<pre style="margin-left:2em;">


 * It seems to work. If nobody objects, I can update Template:Infobox person for you. --RexxS (talk) 16:55, 22 August 2016 (UTC)
 * Seems reasonable. But how will this work, when the data is fetched from Wikidata - I expect we will need a language parameter. Andy Mabbett ( Pigsonthewing ); Talk to Andy; Andy's edits 11:23, 2 September 2016 (UTC)
 * As things stand, it would work with Wikidata only if the editor at the article specifically uses FETCH_WIKIDATA within the article. As you say, the alternative would be to equip the template with a language parameter and use it to determine the form of each label that has a difference in spelling between en-us and en-gb (or others). My preference would be for the latter, as a longer-term and more flexible solution, but it would require a major effort to convert existing articles, unless the current mechanism is also retained. --RexxS (talk) 13:21, 2 September 2016 (UTC)

As nobody has raised any objections in the last week or so, I've amended the template to include the alternate parameter. --RexxS (talk) 15:44, 2 September 2016 (UTC)

which biographical infobox to use
Is there a general guideline somewhere on how to decide which biographical infobox should be "first" and which ones should be lower in the article or modules? In particular, infobox person and infobox officeholder seem to have virtually the same function, with different layout. For example, how should editors decide whether a particular human was a tennis player, scientist, politician or "just a person" if they have done all three through their career? I have not found a guideline or essay to help decide. --Scott Davis Talk 02:10, 3 September 2016 (UTC)

Why can't we have standard infobox parameters for every biographical infobox?
Why can't the parameters that appear here appear in each of the 20 other biographical infoboxes? That way the field names are standardized. Some templates are missing spouse=, children=, parents=. --Richard Arthur Norton (1958- ) (talk) 00:06, 2 September 2016 (UTC)
 * Because of WP:LOCALCONSENSUS and WP:OWN issues. The work-around is to use this infobox, with one of the others as a module within it, or vice versa. If you have a specific example, I'd be happy to show you how. Andy Mabbett ( Pigsonthewing ); Talk to Andy; Andy's edits 11:21, 2 September 2016 (UTC)
 * Better yet, I'd like to see module embedding documented somewhere, either here or with a link from here. Last time I tried to do this I gave up in frustration after being unable to find any docs. Kendall-K1 (talk) 12:17, 2 September 2016 (UTC)
 * I wrote WikiProject Infoboxes/embed in December 2013. Andy Mabbett ( Pigsonthewing ); Talk to Andy; Andy's edits 12:51, 2 September 2016 (UTC)
 * I see that page is linked from just about everywhere except here. Can we put a link to it from the "module" line in the Parameters table? Kendall-K1 (talk) 14:06, 2 September 2016 (UTC)
 * I would need to see how to do that, I have never seen an example of it. --Richard Arthur Norton (1958- ) (talk) 14:52, 2 September 2016 (UTC)
 * Done and done. Is that OK? If not, remember that the documentation can be edited by anyone, so feel free to improve it. --RexxS (talk) 15:37, 2 September 2016 (UTC)
 * Thanks! Now if we just had a generic way to do this for all infoboxes that would really be something. Template:Infobox building, for example, uses "embedded" instead of "module". Kendall-K1 (talk) 15:47, 2 September 2016 (UTC)
 * Work - albeit painfully slow - to standardise infoboxes, and other templates, is ongoing. Andy Mabbett ( Pigsonthewing ); Talk to Andy; Andy's edits 18:01, 3 September 2016 (UTC)
 * Work - albeit painfully slow - to standardise infoboxes, and other templates, is ongoing. Andy Mabbett ( Pigsonthewing ); Talk to Andy; Andy's edits 18:01, 3 September 2016 (UTC)

Years active
For reasons I can't understand, this template is erroring over "years active". If I preview an article using the parameter (it was Willa Holland I was looking at), I get

and the page is categorised into Category:Articles using infobox person with unsupported parameters. The code looks right in the template, though, so I can't see why it's not showing up.

Could someone take a look? — OwenBlacker (Talk) 18:27, 4 September 2016 (UTC)


 * The problem was that the "у" in "уears_active" isn't a "y" but a Cyrillic Уу. It was introduced by some vandalism (diff), which was partially fixed (diff): it's easy to see how the editor didn't bother backspacing over the "у." Rebb  ing  20:00, 4 September 2016 (UTC)
 * Aha! Thank you! — OwenBlacker (Talk) 23:09, 4 September 2016 (UTC)

Parameter native_lang_name
Hi there, is there a reason why the template prefers that native_lang_name contain the two-digit ISO 639-1 code for a native language rather than just having us format native_name as:
 * |native_name = ഇന്നസെന്റ് വറീത് തെക്കേത്തല

native_lang_name doesn't seem to produce any on-screen information, so it's unclear why we're bothering to use it.
 * ഇന്നസെന്റ് വറീത് തെക്കേത്തല

Gives readers a crucial piece of information that
 * ഇന്നസെന്റ് വറീത് തെക്കേത്തല

is lacking. "What the hell are those squiggles? [checks page source] Oh, it's Malayalam!" Thoughts on this? Can we change this or is there a highly-technical reason why we can't? I see that the instructions say that we can format the native_name parameter with the lang template if there is more than one native name, but that seems completely arbitrary, considering that there is no on-screen benefit to native_name_lang. If there are two native languages, suddenly we need to know what they are? In India, there are dozens of native languages: Tamil, Telugu, Malayalam, Hindi, Gujarati, Punjabi, Kannada--so while we could easily infer that a native name in the infobox of someone from France is French, that's not so clear in other nations. (Assuming that was the rationale for the guideline.) Thanks! Cyphoidbomb (talk) 19:26, 14 September 2016 (UTC)
 * is not a name. The ISO code from native_lang_name is used in the emitted HTML. Andy Mabbett ( Pigsonthewing ); Talk to Andy; Andy's edits 21:13, 14 September 2016 (UTC)
 * Hi Pigsonthewing, I don't understand what you mean, specifically the part about the ISO code being used in the "emitted HTML". If you could please explain that to my non-technical brain, I'd appreciate it. I understand that "Malayalam:" is not a name, but 1) we are encouraged to format it that way if there is more than one native language per the template instructions. So it's not obvious to me why "Malayalam:" should be included if there are 2 names, but not 1. 2) If "Malayalam:" doesn't appear near the native script, it seems that we're ignoring an opportunity to explain to casual readers what the squiggly writing is. Yes, they can infer that it's a name, but in what language? Isn't that an important piece of information to be specific about? Cyphoidbomb (talk) 23:23, 14 September 2016 (UTC)
 * Replied at Village pump (technical). PrimeHunter (talk) 10:48, 25 September 2016 (UTC)
 * Please note that the template does not recognise any parameter named native_lang_name, so if you are using that, there will certainly be no difference in what you see. The correct name for the parameter is native_name_lang.
 * Now, assuming that ml is what you are actually using, there is no visible effect, this is true; but the web page that is displayed by your browser does differ in one invisible way when ml is present, compared to when it is absent. Web pages are not plain text, otherwise there would be no formatting, no semantics. The various sections, blocks, paragraphs and phrases are marked up using HTML, and the effects of this markup need not be visible to a human reader, but can be very important to a machine reader - such as your web browser. The page as a whole is given a language - we use the tag to specify that the page is in English and has a left-to-right direction. Within the page, anything that is not English (or not left-to-right) should be marked up appropriately. This language markup might be used by (for example) screen reader software in order to pronounce the words in a suitable manner.
 * In HTML terms, the infobox is a table, tables have one or more rows, and rows have one or more cells. When native_name is non-blank (let's say that it is ഇന്നസെന്റ് വറീത് തെക്കേത്തല, a row is added to the infobox containing two cells: the first is a "header cell" containing the text "Native name" (there's some invisible markup right away - the space between those two words is not a regular space, but a non-breaking space); and the second is a "data cell". If native_name_lang is blank or absent, the data cell will contain the HTML  which displays as ഇന്നസെന്റ് വറീത് തെക്കേത്തല ; whereas if ml is present, the data cell will contain the HTML   which displays as ഇന്നസെന്റ് വറീത് തെക്കേത്തല . The presence of the extra attribute   may make no apparent difference in this case, but in some languages it can be crucial. I have seen this happen with some Punjabi names, where the appearance of some letters differs according to whether the name is marked up with  or not. -- Red rose64 (talk) 11:09, 25 September 2016 (UTC)

Further to the above; if you have multiple values, you should not use markup like:



but you should use:



This renders as ഇന്നസെന്റ് വറീത് തെക്കേത്തല. Andy Mabbett ( Pigsonthewing ); Talk to Andy; Andy's edits 17:04, 25 September 2016 (UTC)

Default image
The template documentation mentions that this template tracks Wikidata:Property:P18, except there is no default image pulled through from Wikidata. Is that something we could / should add? Having just set  on Carly Chaikin, it is just that simple — it would only require changing   to   and it should Just Work™, right? Is this desirable? — OwenBlacker (Talk) 11:35, 24 September 2016 (UTC)
 * Sadly, it won't just work. Despite being set as a single-value property, exceptions are allowed (a list is at https://www.wikidata.org/wiki/Wikidata:Database_reports/Constraint_violations/P18#Single_value ). There are many people who have two images on Wikidata and by default that will result in a failure to show an image in the infobox. A current example would be  - if you paste   into the infobox at Ramón Barros Luco and preview it, you'll get an error because   returns  . One way to fix it is to make one of the mages on Wikidata a preferred rank (as is done at, for example), but that still means the fix would have to be manually applied in the Wikidata entries for an unknown number of articles. You can probably imagine the frustration of an editor who works on an article suddenly finding that somebody else (on another site) has added a second image and it's now broken the infobox on the Wikipedia article that they curate. --RexxS (talk) 14:36, 18 October 2016 (UTC)
 * Sadly, it won't just work. Despite being set as a single-value property, exceptions are allowed (a list is at https://www.wikidata.org/wiki/Wikidata:Database_reports/Constraint_violations/P18#Single_value ). There are many people who have two images on Wikidata and by default that will result in a failure to show an image in the infobox. A current example would be  - if you paste   into the infobox at Ramón Barros Luco and preview it, you'll get an error because   returns  . One way to fix it is to make one of the mages on Wikidata a preferred rank (as is done at, for example), but that still means the fix would have to be manually applied in the Wikidata entries for an unknown number of articles. You can probably imagine the frustration of an editor who works on an article suddenly finding that somebody else (on another site) has added a second image and it's now broken the infobox on the Wikipedia article that they curate. --RexxS (talk) 14:36, 18 October 2016 (UTC)

Teachers (or so)
What parameter should be used in order to insert the teachers and pupils an academic character have had? -- M h hossein   talk 12:00, 24 October 2016 (UTC)
 * I don't think there's a specific parameter for those, because it is not common for teachers and pupils of academics to be key facts in their life, per se, although some exceptions will exist. In Socrates, the parameters influences and influenced are used to mention influences like Anaxagoras and disciples like Plato. --RexxS (talk) 21:19, 24 October 2016 (UTC)
 * Those parameters are deprecated in this template - you could use infobox academic instead. Nikkimaria (talk) 00:22, 25 October 2016 (UTC)
 * Infobox scientist has doctoral_advisor, academic_advisors, notable_students, and doctoral_students. Kendall-K1 (talk) 00:28, 25 October 2016 (UTC)
 * Infobox scientist has doctoral_advisor, academic_advisors, notable_students, and doctoral_students. Kendall-K1 (talk) 00:28, 25 October 2016 (UTC)

Proposal: Remove weight & height from Infobox adult biographies
Would like to invite any interested editors to comment at Template_talk:Infobox_adult_biography. Thank you. K.e.coffman (talk) 23:20, 28 October 2016 (UTC)

Add field for 'Websites' (plural)
Does this look like a reasonable addition? <pre style="overflow: auto"> In some cases a subject has two noteworthy occupations and two corresponding official websites, each with its own set of biographical details and milestones. If the infobox lists only a single official website, many uninformed readers may be misled into thinking that the subject regards his other occupation as unimportant. --Dervorguilla (talk) 02:42, 18 October 2016 (UTC)
 * Websites =
 * Personally I'd rather see the existing parameter modified to support the addition of multiple entries when appropriate, rather than adding another parameter. DonIago (talk) 13:56, 18 October 2016 (UTC)
 * Could this be addressed by using modules for each distinct occupation? A module for infobox scientist and a module for infobox politician, each including the relevant website, for example? --Scott Davis Talk 11:09, 29 October 2016 (UTC)

Parents
To include parents in the infobox, they have to be "independently notable", why is that? As a reader I want to know the name of the parents, I do not care if they have their own article and are blue linked. Over 5,000 will have to be deleted from the template that are not blue linked, after that I stopped counting. Is this what we really want? --Richard Arthur Norton (1958- ) (talk) 15:12, 6 September 2016 (UTC)


 * I expect that it's an extension of "For privacy reasons, consider omitting the names of children of living persons, unless notable." It's probably reasonable not to draw attention to children, who have an expectation of privacy when not independently notable. The guidance for parents actually says "include only if they are independently notable or particularly relevant", so you could easily argue that a person's parents are relevant, especially as they are almost certainly named elsewhere in the article text. --RexxS (talk) 17:03, 6 September 2016 (UTC)
 * Why not just eliminate the requirement that parents be notable or relevant? It just leads to endless debates about what makes someone "particularly relevant". The whole point of standardized information categories in infoboxes is to have completeness, and not have to search the prose text for the information. --Richard Arthur Norton (1958- ) (talk) 05:01, 7 September 2016 (UTC)
 * Agree with -- Pankaj Jain Capankajsmilyo (talk · contribs · [//tools.wmflabs.org/xtools-ec/?user=Capankajsmilyo&project=en.wikipedia.org count])  06:04, 7 September 2016 (UTC)
 * It is completely incorrect that "The whole point of standardized information categories in infoboxes is to have completeness, and not have to search the prose text for the information." The point of infoboxes is to provide a quick overview of salient. notable information. Softlavender (talk) 06:06, 7 September 2016 (UTC)
 * The wiki has never been about "completeness". It has always been a summary of important knowledge. With that in mind, the infobox should show the most important and relevant points. Non-notable parents are not that. Binksternet (talk) 06:43, 7 September 2016 (UTC)
 * I agree with Binksternet: relations are not ordinarily the sort of key data points that belong in an infobox. Rebb  ing  11:34, 7 September 2016 (UTC)
 * And why are "parents" and "children" and "spouse" any more or less defining than "the day you were born" and the "city you were born in" or the school you attended? Can you really read the minds of our readers and know why they came to the article? Can you teach me how to do it, or are you born with the ability? --Richard Arthur Norton (1958- ) (talk) 15:38, 7 September 2016 (UTC)
 * The name of the subject's birth locality tells the reader a little about what a subject's background and nationality; age allows the reader to engage his generational preconceptions (the full birthdate is just a tag-along); knowing if someone attended Princeton or State provides valuable information about educational attainment (having attended at all), academic skill, and social status. The names of non-notable relatives provide... virtually nothing. If you know a subject's parents are named Sid and Nancy, what does that tell you? Except in cases where they provide clues about class, race, or nationality, the names themselves are arbitrary words and provide no more informative than the names of his next-door neighbors—and I see no reason to encourage our readers' bigotry. By your argument—that we cannot possibly know what a reader might find useful—we ought to include the entire text of the article in the infobox! Rebb  ing  16:48, 7 September 2016 (UTC)
 * What do I learn about someone born in New York City 30 years apart or 30 miles apart? Someone born on Staten Island is a different life from someone born on 5th Avenue on the Upper East Side. What does that add to their notability, what insight does it give me? --Richard Arthur Norton (1958- ) (talk) 04:56, 11 October 2016 (UTC)

Adding parents to an infobox seems fine, is part of a person's history and heritage, and has all the earmarks of encyclopedic knowledge (something, I sometimes fear, some editors here sometimes fear - present company excluded). Randy Kryn 16:54, 7 September 2016 (UTC)
 * What insight do I gain knowing that both Donald Trump and Elon Musk and "person X" attended Wharton? All it does is answer the question "where did Donald Trump and Elon Musk attend business school". Just as my question would be answered "who were the parents of person X". Why do we include non-notable spouses? We do not require them to be blue-linked, the same argument could be made that no one needs to know that, they can search the prose text. --Richard Arthur Norton (1958- ) (talk) 18:40, 7 September 2016 (UTC)
 * I support that if the parents are identified in the prose (with appropriate references), they can/should be included in the infobox as well. I challenge The name of the subject's birth locality tells the reader a little about what a subject's background and nationality with Ted Cruz born in Calgary, Alberta, Canada - information appropriate for the infobox, but does not identify his background or nationality, especially not in isolation from knowing also about his parents. --Scott Davis Talk 01:26, 8 September 2016 (UTC)


 * Should we eliminate birthdays and deathdays unless they are notable? Why don't we only list birthdays if that particular day has a blue link like Christmas Day or New Year's Eve? --Richard Arthur Norton (1958- ) (talk) 22:06, 10 September 2016 (UTC)
 * I'm not a fan of this analogy. A day isn't like a person; whether or not a person's birthday falls on a notable holiday makes little difference to that fact's importance. For instance, my birthday falls on a well-loved holiday, but I rarely open with that in conversation, and many of my acquaintances don't know about it. On the other hand, if I were married to, say, Ms. Taylor Swift, that would likely be a key fact about me. Rebb  ing  22:00, 10 September 2016 (UTC)

Support

 * ✅ We should have the name of parents in articles and in infoboxes, just as we do spouses. There is no requirement that spouses be blue-linked or be "particularly relevant". The exceptions are covered by WP:BLP. --Richard Arthur Norton (1958- ) (talk) 19:30, 10 September 2016 (UTC)
 * Support Details regarding parents -- notable or not -- are something that should be provided in infoboxes where available. Alansohn (talk) 17:43, 11 September 2016 (UTC)
 * Suppport that if the parents and/or spouse are cited in the prose, they may also be in the infobox. This infobox is used for both living and historic people, so references may not always be available anyway. Parentage is at least as relevant as birthplace in many cases. --Scott Davis Talk 00:44, 16 September 2016 (UTC)
 * Support, in an infobox the key "word" is "info". If a notable person has an infobox, and the subject's parents and spouses are known and are a part of that persons life, of course they should be included. Not everyone needs them listed, but that is the judgement of the page's editors, and if they decide to put that data into an infobox, there should be no barriers to the inclusion of that information. Randy Kryn 10:59, 16 September 2016 (UTC)
 * Support There's no harm in adding parents to infobox. It's better if they are added as they are an integral part of the person's identity as well as important for wikidata. -- Pankaj Jain Capankajsmilyo (talk · contribs · [//tools.wmflabs.org/xtools-ec/?user=Capankajsmilyo&project=en.wikipedia.org count])  03:46, 8 October 2016 (UTC)

Oppose

 * Oppose: The purpose of an infobox is to "summarize . . . key facts"; "[t]he less information it contains, the more effectively it serves that purpose . . . ." WP:INFOBOXPURPOSE. In most cases, the names of a subject's parents are mere trivia. They are distinguishable from a spouse's name in that whether a person is married, and to whom, are important talking points in Western culture. If anything, I am inclined to think that the spouse parameter should be limited to instances where the spouse is notable or particularly relevant, but I can imagine why it isn't. Rebb  ing  21:32, 10 September 2016 (UTC)
 * Oppose Per MOS:IBX, "The less information it contains, the more effectively it serves that purpose, allowing readers to identify key facts at a glance." Unless lineage is a "key fact" about the subject, it doesn't belong. SteveStrummer (talk) 02:32, 15 September 2016 (UTC)
 * Oppose per Rebbing, including that spouse should also be omitted unless notable and/or particularly relevant. Nikkimaria (talk) 02:57, 15 September 2016 (UTC)
 * Oppose -- no reason to include parents (and spouse) if otherwise not notable. The infobox is not the place for excessive intricate detail. K.e.coffman (talk) 00:53, 31 October 2016 (UTC)
 * Oppose. Listing non-notable and/or non-relevant parents only increases the irritating clutter in infoboxes, and violates individuals' privacy . Softlavender (talk) 02:32, 31 October 2016 (UTC)
 * Oppose – absolutely not, as per WP:BLPNAMES (and WP:NPF). --IJBall (contribs • talk) 03:38, 31 October 2016 (UTC)

General comments

 * I took the liberty of refactoring this proposal. Since it didn't have an accompanying introduction, it makes more sense as a subsection of the related discussion (also: duplicate section names), and, because there's only a simple decision to be made, I think asking for "support" or "oppose" votes is clearer and more conventional. Is this okay with you, ? Rebb  ing  21:13, 10 September 2016 (UTC)
 * Annnnd we're back to talking past each other in separate sections with interspersed, untrheaded replies. Rebb  ing  22:09, 10 September 2016 (UTC)
 * Because this really isn't the place for stray comments, just !votes, the general discussion was in the previous section with claims and counterclaims. --Richard Arthur Norton (1958- ) (talk) 23:18, 10 September 2016 (UTC)
 * I was referring to your unindented comment in the "oppose" section above, presumably, a reply to my vote. Rebb  ing  23:37, 10 September 2016 (UTC)
 * Comment "The less information it contains, the more effectively it serves [to summarize]", it will achieve perfection when it is empty. --Richard Arthur Norton (1958- ) (talk) 21:47, 10 September 2016 (UTC)
 * If you're going to make an argument to absurdity, at least consider both extremes. My position taken to the extreme would mean no infobox, yet many quality articles don't have infoboxes, so that's not an absurd result. Your position taken to its extreme would have every fact given in the article restated in the infobox, an obviously absurd outcome. Therefore, the argument to absurdity does not support your case. Rebb  ing  22:07, 10 September 2016 (UTC)
 * Just those fields agreed upon to be added to the infobox by consensus. It is as absurd as only adding birthdays and deathdays to the infobox if those dates are notable like Christmas Day or New Year's Eve. --Richard Arthur Norton (1958- ) (talk) 23:14, 10 September 2016 (UTC)
 * Good comparison. And the "less information" theory of infoboxes leaves me scratching my head as to why they are then named "infoboxes". A spouse is certainly a key point of information, and someone's parents may or may not be not be notable but are, in many cases, certainly notable in a summary of a subject's life. Randy Kryn 11:07, 16 September 2016 (UTC)

I propose dropping "resting place"
A. Dropping redundant, Weasel word-violating alternative. comp.arch (talk) 14:05, 31 October 2016 (UTC)

B. An alternative to proposal A. is looking for amended wording to my first change that got reverted; "may be used" seems strange; "should use" better. comp.arch (talk) 14:05, 31 October 2016 (UTC)


 * This is a perennial proposal; always rejected, It is not a "weasel word". It is the correct term, as in "come to rest; cease being mobile", not "rest in peace". Furthermore, contrary to your edits, which were correctly reverted, it has no religious connotation, and covers internments other than burials. Andy Mabbett ( Pigsonthewing ); Talk to Andy; Andy's edits 15:22, 31 October 2016 (UTC)
 * Andy is correct, it is the common term for such a location. It does not confer any sort of religious connotation. -DJSasso (talk) 16:36, 31 October 2016 (UTC)
 * If you really do mean "internment" I don't see what that has to do with burial. If you mean "interment" I have only ever heard that used to refer to burial; what other types of interment are there? Kendall-K1 (talk) 16:55, 31 October 2016 (UTC)
 * About "come to rest" I didn't think of that, meaning "cease being mobile", and it may not be true, seeing how e.g. the London underground has a non-"policy on the scattering of ashes. We deal with requests on a case by case basis.".., you wouldn't need a moving train, for atoms to move (just worms); or scattering ashes at sea. You can consider the proposal revoked, until I look into this more. [I do see eternal home, permanent address, boneyard, necropolis, place of interment and of course graveyard as possible synonyms. comp.arch (talk) 20:49, 31 October 2016 (UTC)
 * It's a matter of etymology, not physics. Andy Mabbett ( Pigsonthewing ); Talk to Andy; Andy's edits 16:44, 1 November 2016 (UTC)
 * "Interment of ashes" is a term-of-art for placing ashes, rather than scattering them - see e.g. http://www.scattering-ashes.co.uk/help-advice/interment-of-ashes/ - this would be associated with a cremation, of course, rather than a burial.
 * Question for : if we removed resting_place, that would leave only burial_place, so how would we deal with a subject whose ashes were scattered or interred, but not buried? --RexxS (talk) 17:26, 31 October 2016 (UTC)
 * Or like an acquaintance (I hesitate to call this person a friend) of mine who had their grandmother's ashes compressed down, converted into an industrial gem and set in a ring. They are now more mobile than they have been for the last 20 years... Only in death does duty end (talk) 17:30, 31 October 2016 (UTC)
 * Question for : if we removed resting_place, that would leave only burial_place, so how would we deal with a subject whose ashes were scattered or interred, but not buried? --RexxS (talk) 17:26, 31 October 2016 (UTC)
 * Or like an acquaintance (I hesitate to call this person a friend) of mine who had their grandmother's ashes compressed down, converted into an industrial gem and set in a ring. They are now more mobile than they have been for the last 20 years... Only in death does duty end (talk) 17:30, 31 October 2016 (UTC)


 * I propose a pull down menu with options such as "comfy chair" and "cozy warm bed". --Richard Arthur Norton (1958- ) (talk) 16:59, 31 October 2016 (UTC)

Consistency
Someone is making the argument that rules generated at this template do not apply to the other 35 biographical templates that use the same field, and they need to be negotiated at each of the 35 biographical templates separately (the number may be lower now, since we merge templates as best as we can). The argument is when to use "education=" vs. "alma_mater=" (the singular nourishing mother). The arguments are above on this page, but the changing of the field names has now spread to the officeholder template. Do we really have to relitigate this 35 times? --Richard Arthur Norton (1958- ) (talk) 02:46, 8 October 2016 (UTC)


 * I don't think so. MOS:INFOBOX § Consistency between infoboxes says that parameters should be consistent between infoboxes. Since infobox person is the most widely used biographical infobox, it seems to me that other biographical infoboxes should defer to it. "Well, we prefer it this way" isn't a good enough reason to disregard the guideline. Rebb  ing  03:07, 8 October 2016 (UTC)
 * It says that parameter names should be consistent, not their documentation. If we want to make the documentation from this template apply to all biographical templates, we should have a more central discussion (ie. not at this template).
 * The background here is that RAN is edit-warring across multiple pages that use other infoboxes to make alma_mater use inappropriate according to the documentation here (eg. by adding degrees or dates). The problem with that is first that those infoboxes don't use this documentation, second that he's trying to convert boxes to use education rather than alma_mater even when the discussion here hasn't concluded that that should happen, and third that when reverted he refuses to initiate discussion but rather just restores his edit. In other words, while documentation is part of the issue, it's not the only one. Nikkimaria (talk) 13:00, 8 October 2016 (UTC)
 * If you want to redefine |education= and |alma_mater= to definitions other than how they appear in infobox_person, then work to get consensus at the various other biographical templates. Until then they have the same definition that they have here. --Richard Arthur Norton (1958- ) (talk) 22:37, 1 November 2016 (UTC)
 * While the usage practices of this template provide a good rule of thumb for others modelled on it, discussions on this page are merely local consensus and cannot be binding elsewhere, if disputed. Andy Mabbett ( Pigsonthewing ); Talk to Andy; Andy's edits 11:23, 11 October 2016 (UTC)

alma_mater parameter
The description of this parameter is "the last-attended higher education institution" why a single institution? I think we should change it to "the higher education institution or institutions attended". What do you think? --RaphaelQS (talk) 19:29, 1 November 2016 (UTC)
 * Oppose alma_mater is Latin and is singular and means "nourishing mother", we already have an "education=" field for someone's full education from high school to graduate degrees. We should really just eliminate alma_mater, since the function is duplicated by the "education=" field. --Richard Arthur Norton (1958- ) (talk) 22:05, 1 November 2016 (UTC)
 * Many people are using the "education" parameter for the secondary school attended (for exemple this is the case with many articles about British subjects) and the "alma_mater" parameter for the colleges/universities attended later, other are using the "education" parameter for the list of diplomas and degrees. I don't see any reason to limit the "alma_mater" parameter to a single institution. Most (if not all) the articles about scientists are listing all the universities attended in the alma_mater parameter. --RaphaelQS (talk) 00:45, 2 November 2016 (UTC)
 * That is because those infoboxes were created before the education field was created, or the editors still cling to the old ways. I still use outdated ways of formatting data because that is all I know ... until someone points out a better or newer way. --Richard Arthur Norton (1958- ) (talk) 00:51, 2 November 2016 (UTC)
 * This is simply not the case. --RaphaelQS (talk) 00:55, 2 November 2016 (UTC)

Didn't we just discuss this in August? Kendall-K1 (talk) 02:23, 2 November 2016 (UTC)

Get rid of Alma_mater field
It is redundant with education and we really should not be using Latin, where we need a blue link in a template so people can figure out what it means. --Richard Arthur Norton (1958- ) (talk) 21:35, 11 August 2016 (UTC)

Remove

 * Remove Right now it is only used to remove degrees from anyone's infobox with the argument that "education" is the only place where degrees may be mentioned. Remove it. Collect (talk) 16:40, 12 August 2016 (UTC)
 * Remove it As with "hometown" field this is better handled in prose in the body of the article. MarnetteD&#124;Talk 18:15, 12 August 2016 (UTC)
 * Remove alma_matter English word education makes more sense in English Wikipedia. -- Pankaj Jain Capankajsmilyo (talk · contribs · [//tools.wmflabs.org/xtools-ec/?user=Capankajsmilyo&project=en.wikipedia.org count])  03:53, 20 August 2016 (UTC)
 * "Alma mater" and "Education" are both English words, and both make equal sense, and they do not mean the same thing. I find the assertion unpersuasive that "we really should not be using Latin, where we need a blue link in a template so people can figure out what it means".  Just as bonus, ego, bona fide, per se, ad hoc, impromptu, vice versa, etc. (yes, even et cetera!), are common English words with "blue links", so is "Alma mater". You do realize that most of English is derived from other languages, such as Latin, right?  Just remove the unnecessary blue link from "alma mater" if that is your concern, as the English term is rather self-explanatory.  If you wish to remove the alma mater field altogether, with what do you propose to replace it (remember: "education" serves a different function here)? Regards, Xenophrenic (talk) 18:13, 24 August 2016 (UTC)
 * A person has a J.D., Ph.D., and M.D. from three different schools, which one is their nourishing mother? — Preceding unsigned comment added by Richard Arthur Norton (1958- ) (talk • contribs) 23:41, 15 September 2016 (UTC)
 * I would say that's a case for the education field. Rebb  ing  02:34, 16 September 2016 (UTC)
 * All three degrees and all three schools go into the education field. The alma mater field, if it is also used in this highly unlikely hypothetical situation, would only have the name of the main institution described as the "alma mater" in the reliable sources already cited in the body of the article. Xenophrenic (talk) 04:45, 18 September 2016 (UTC)

Keep

 * Keep per Sarah: alma mater is appropriate when we only know the school; education when we have more details. The Latinate phrase is common English. Rebb  ing  02:34, 16 September 2016 (UTC)
 * Keep Neutral All information appearing in the Infobox should first appear in prose in the body of the article anyway; the factoids in the Infobox are supposed to be convenient "at-a-glance", clear and uncontroversial summaries. There are metadata collection applications that access parts of our Infobox data, but I'm not familiar enough with them to know which may use these specific fields. Xenophrenic (talk) 19:47, 12 August 2016 (UTC)
 * I am familiar, and I will adjust Wikidata accordingly. --Richard Arthur Norton (1958- ) (talk) 14:01, 15 August 2016 (UTC)


 * Keep. Sometimes the degree isn't known, or the person may have left without a degree. We should keep it with advice to use the "education" field when the degree details are known, and the "alma mater" field when not, but not to use both. SarahSV (talk) 18:16, 13 August 2016 (UTC)
 * SarahSV, could you elaborate on why one couldn't use education to cover both cases? It provides more room for details than alma mater which is designed only for institution name and nothing else. (I could see an argument for removing education as an anti-clutter measure, but I'm not sure I understand your point). Nikkimaria (talk) 20:01, 13 August 2016 (UTC)
 * , where we don't know what degrees were obtained, but we do know that the person attended a certain university, adding "education = Harvard University" seems odd. SarahSV (talk) 20:30, 13 August 2016 (UTC)
 * They were still educated at Harvard even if we do not know the degree earned and the year they graduated, or if they dropped out before graduation. If the field name needs a blue link to explain the Latin phrase then it is not a good field to have. It will also eliminate the problem stated above of people warring over what belongs in what field, like we are doing now. As I pointed out in the previous post we have one editor eliminating the years and the degrees from the alma_mater field instead of changing the field name to "education". I counted over 100 deletions. The current two fields confuses Wikidata which imports the data and supplies it to the other language Wikipedias. --Richard Arthur Norton (1958- ) (talk) 03:38, 15 August 2016 (UTC)


 * Remove education instead to provide for a concise and clear listing rather than a catch-all. Nikkimaria (talk) 11:36, 15 August 2016 (UTC)
 * Can you restate that, I can't understand "to provide for a concise and clear listing rather than a catch-all". --Richard Arthur Norton (1958- ) (talk) 02:39, 20 August 2016 (UTC)
 * Per the description above, alma mater is "a more concise alternative" to education; the former includes just institution, the latter is designed to encompass "clutter". Nikkimaria (talk) 03:51, 20 August 2016 (UTC)
 * Because the description calls it "concise", does not mean it is, "nourishing mother" is archaic, more than concise. Nor is "education" clutter, 99.99999% of Wikipedia is clutter because I have no interest in reading it. "Clutter" and "trivia" and "cruft" and the other synonyms you see in arguments, just mean "I have no interest in it". If you have no interest, ignore it, and let the people who have a genuine interest in the topic, find what they are looking for. Purposefully obscuring the information in prose somewhere in the body of the article does not serve the reader. Using outdated Latin terms, just to show we know Latin, is silly when we have a perfect English equivalent. --Richard Arthur Norton (1958- ) (talk) 04:01, 20 August 2016 (UTC)
 * Whatever information you personally think should be included, institution name alone is undeniably more concise than institution name+degree name+year+whatever else. I'd be fine with calling the parameter "education", but only if it adopts the description/data currently used for alma mater rather than what is currently used for education. And the anti-clutter argument that you dismiss is based on WP:INFOBOXPURPOSE - we don't include every datapoint that someone might possibly be interested in. Nikkimaria (talk) 12:10, 20 August 2016 (UTC)

Education template
How about an education template so that they are all formatted identically with the degree and year in small text? This would be similar to the "marriage" template that formats marriage and end of marriage dates identically across infoboxes. previously it was hard to discern if "Barbara Smith (1810-1840)" was the birth and death years or the marriage interval. --Richard Arthur Norton (1958- ) (talk) 05:06, 15 August 2016 (UTC)
 * We don't put small text in infoboxes - see Template talk:Marriage and MOS:FONTSIZE. --RexxS (talk) 09:19, 15 August 2016 (UTC)
 * Two people commenting does not make consensus for all of Wikipedia. MOS:FONTSIZE says "reduced font sizes should be used sparingly". and not to use it in infoboxes where a small font is already in use: Don't double small a font. --Richard Arthur Norton (1958- ) (talk) 12:56, 15 August 2016 (UTC)
 * What's your point? I was only showing you that marriage saw the problem of small text in infoboxes already. MOS:FONTSIZE says Avoid using smaller font sizes in elements that already use a smaller font size, such as infoboxes, navboxes and reference sections. In no case should the resulting font size drop below 85% of the page fontsize (or 11px). Your suggestion of "all formatted identically with the degree and year in small text" fails immediately because putting small text into infoboxes is contrary to MOS. --RexxS (talk) 16:13, 15 August 2016 (UTC)
 * We have guidelines not Biblical laws, they were written by us, and can be changed by us, through consensus. At one time all fair use images were being purged, and a few weeks later were being restored, all through consensus ... consensus can and always does change. The classical music group deleted all infoboxes from biographies despite all other biographies having them. --Richard Arthur Norton (1958- ) (talk) 17:52, 15 August 2016 (UTC)
 * Wrong, wrong, wrong, and wrong - see Beethoven. These particular guidelines at MOS are an accessibility issue - 85% of base page fontsize is a bright line - and aren't going to be changed to suit one editor's individual aesthetics. Putting small text into an infobox is never going to fly with the majority who believe it is important to accommodate readers with impaired vision. --RexxS (talk) 19:05, 15 August 2016 (UTC)
 * The one constant in Wikipedia is that the format will always be changing. First preserved Main Page of Wikipedia.jpeg --Richard Arthur Norton (1958- ) (talk) 23:15, 15 August 2016 (UTC)
 * The second constant in Wikipedia is that those editors who care about the readers will always outnumber those who don't. --RexxS (talk) 00:02, 16 August 2016 (UTC)
 * If you believe the manual of style should be changed, isn't that a discussion better suited to WT:MOSTEXT? Graham (talk) 02:59, 16 August 2016 (UTC)
 * The second constant in Wikipedia is that those editors who care about the readers will always outnumber those who don't. --RexxS (talk) 00:02, 16 August 2016 (UTC)
 * If you believe the manual of style should be changed, isn't that a discussion better suited to WT:MOSTEXT? Graham (talk) 02:59, 16 August 2016 (UTC)

How much information should it contain?
How much information should the field contain? --Richard Arthur Norton (1958- ) (talk) 13:32, 15 August 2016 (UTC)
 * A: "Harvard College (B.A.) Harvard Law School (J.D.) "
 * B: "Harvard College (B.A., 1968) Harvard Law School (J.D., 1970) "
 * C: "Harvard College (B.A., 1968, History) Harvard Law School (J.D., 1970) "


 * Unless the precise field of study is important to the person's notability, suggest use of school, year, degree (without Wikilink to degree name - just use "B.A., M.A., etc.)
 * Harvard College 1968 B.A.; Harvard Law School 1970 J.D.
 * Too major a change to grasp? Collect (talk) 13:43, 15 August 2016 (UTC)
 * You are right, the blue links for degrees create a sea of blue. --Richard Arthur Norton (1958- ) (talk) 23:17, 15 August 2016 (UTC)
 * What if abbr were used, as it is in marriage? Graham (talk) 03:02, 16 August 2016 (UTC)
 * How much info should the field contain? Which field?  alma mater or education?  The alma mater field should contain only the name of the main institution (usually the most recent location where the most advanced education was received).  The education field should contain degrees earned, along with the field of study for each degree (noting that someone earned a B.S., without saying what field of study, is uninformative for our readers), and optionally the institution name(s). Special formatting, font sizes, non-standard characters, and other clutter shouldn't appear in either field. Xenophrenic (talk) 18:13, 24 August 2016 (UTC)

College or parent university?
A small group of people are converting the college or school attended to the parent university. Should we be writing in Harvard Law School and Harvard Medical School or only the parent university, Harvard University. Does the reader expect a person with an M.D. to have attended a medical school and J.D. a law school? The same goes for an M.B.A. and the same for people getting degrees in politics from the Woodrow Wilson School of Public and International Affairs and the John F. Kennedy School of Government. Just telling me they attended Harvard or Princeton after their undergraduate degree is correct but misleading. --Richard Arthur Norton (1958- ) (talk) 13:31, 15 August 2016 (UTC)


 * Depends – In the cases that you have listed, I would definitely use the parent institution. Otherwise you could wind up with, for instance, "Faculty of Arts, University of X" being listed. I would list the college, however, for a collegiate university, e.g, University of London, University of Oxford, University of Cambridge.
 * I am curious as to why you believe it is "misleading" to say that an alumnus of the John F. Kennedy School of Government attended Harvard. Would you say the same if, rather than the John F. Kennedy School of Government, we were discussing Harvard Divinity School or the Harvard Graduate School of Arts and Sciences (which have Harvard in their name but are otherwise no different)? Graham (talk) 03:19, 16 August 2016 (UTC)
 * Just as if I asked someone where they lived, and they said Earth. While correct it conveys less information than the county, state, and city. Knowing that someone attended the University of California is not as informative as knowing they attended the "David Geffen School of Medicine at UCLA" or "UCLA School of Law". --Richard Arthur Norton (1958- ) (talk) 16:38, 26 August 2016 (UTC)
 * And yet, you have yet to explain where you draw the line with respect to specificity, because earlier you were concerned about being too specific. Graham (talk) 05:08, 26 August 2016 (UTC)


 * "Faculty of Arts, University of X" is a department, not a school. We also are not supposed to be using Easter Egg linking. I expect a physician to be attending a medical school, and I expect a lawyer to attend a law school. Knowing that someone is a human is less informative than knowing if they were male of female. --Richard Arthur Norton (1958- ) (talk) 04:22, 19 August 2016 (UTC)
 * I think there may have been a miscommunication, because I don't think I advocated easter egg linking (which, as an aside, is an issue I've been coming across more and more in the alma mater field recently). Graham (talk) 04:28, 19 August 2016 (UTC)
 * Also, how do you distinguish between a faculty and a school, if you're arguing that's the dividing line? The terms are used differently by different institutions. For instance, at the University of Warwick, a school is just a part of a faculty, and that kind of nomenclature isn't uncommon in a number of English-speaking countries. Graham (talk) 04:35, 19 August 2016 (UTC)
 * If it doesn't have an article, do not link to it, then use the parent article. I think that is a good compromise, what do you think? We shouldn't have red links. --Richard Arthur Norton (1958- ) (talk) 02:37, 20 August 2016 (UTC)
 * I don't see why we wouldn't link to the article about the university itself in the case of non-collegiate universities. Bear in mind, institutions like the John F. Kennedy School of Government don't normally have the authority to issue degrees; that resides with the university. Also, with your suggested "compromise", that would involve linking to articles about faculties (that have the word "faculty" in their name) in some cases. Graham (talk) 03:07, 20 August 2016 (UTC)


 * Depends on which field. alma mater should only display the main institution name, and not the satellite schools, departments, branches, specialty divisions, etc., of the main institution.  The education field, however, might display the more specific school branch(s) of the university along with the field of study and degrees earned, but would not indicate the alma mater. Xenophrenic (talk) 18:13, 24 August 2016 (UTC)
 * Very belated, but depends, which means not automatically changing any of these since it varies on a case-by-case basis. There are a lot of times where the specific sub-college is quite useful, and other times where the parent college is only a historical curiosity and not even formally affiliated anymore (e.g. many seminaries).  SnowFire (talk) 03:32, 28 October 2016 (UTC)

Capitalized or not?
As a bulleted list should they all be capitalized, or just the first one?

— Preceding unsigned comment added by Richard Arthur Norton (1958- ) (talk • contribs) 23:01, 3 November 2016 (UTC)


 * Only the first item in a horizontal list is capitalized. See WP:FLATLIST. Rebb  ing  01:46, 6 November 2016 (UTC)

Problem with duplication
A few minutes ago, I used module in an infobox with this infobox. Usually this causes no problem, but this time, the content was duplicated in the infobox. Any idea what has caused this and can it be fixed soon?-- Auric    talk  00:29, 22 November 2016 (UTC)
 * ✅: It was caused because the  parameter was specified twice (data35 and data53) in Template:Infobox Muslim leader. The duplication was introduced on 26 May 2016 with this edit. I've renamed the later parameter to  . --RexxS (talk) 04:32, 22 November 2016 (UTC)
 * ✅: It was caused because the  parameter was specified twice (data35 and data53) in Template:Infobox Muslim leader. The duplication was introduced on 26 May 2016 with this edit. I've renamed the later parameter to  . --RexxS (talk) 04:32, 22 November 2016 (UTC)

Nickname
Would it be possible to make this an alias for the other_names field? It is used in some other infoboxes. Ranze (talk) 16:07, 28 November 2016 (UTC)
 * At present, the field labelled "Other names" can be populated by other names, other_names, othername, and alias. Are you saying you want to be able to use nickname as well as those four? Or did you mean something else? --RexxS (talk) 18:15, 28 November 2016 (UTC)
 * At present, the field labelled "Other names" can be populated by other names, other_names, othername, and alias. Are you saying you want to be able to use nickname as well as those four? Or did you mean something else? --RexxS (talk) 18:15, 28 November 2016 (UTC)