Template talk:Infobox person

For pending merger proposals (2009 to date) see Template talk:Infobox person/Mergers

RfC: Should resting place include cremation

It seems pretty clear, with decent arguments on both sides, that the nos have it. It also seems clear that there's more work to be done here and that an understanding can be reached by talking things over. Drmies (talk) 00:38, 16 March 2016 (UTC)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

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 | 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. 🖖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 ....., –Davey2010^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|Talk 21:07, 10 February 2016 (UTC)
• No unless you are cremated and buried somewhere.--☾Loriendrew☽ ☏(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. — 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#Notable_cremations 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 = parameter, it could instead be rendered within infoboxes as, for example, "Burial/interment/cremation". 🖖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"). 🖖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

🖖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 attempted to maintain—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. 🖖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. 🖖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:

  | death_place = | death_cause = | body_discovered = | resting_place = | resting_place_coordinates = | burial_place = | burial_coordinates = | monuments =

  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. 🖖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 = and burial_place = 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. 🖖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. 🖖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? - ^theWOLFchild 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 | 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. 🖖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 | 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. 🖖ATinySliver/^ATalkPage 23:29, 19 February 2016 (UTC)

Agreed. ;0) J. D. Crutchfield | Talk 02:07, 20 February 2016 (UTC)

@Jdcrutch: 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)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘@RexxS: 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 | 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)

---

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

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. 🖖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. 🖖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. 🖖ATinySliver/^ATalkPage 22:40, 16 March 2016 (UTC)

Well, |burial_place=Somewhere renders as Burial place Somewhere, as an alternative to |resting_place=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. 🖖ATinySliver/^ATalkPage 23:35, 16 March 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:

• 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.

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. 🖖ATinySliver/^ATalkPage 23:57, 16 March 2016 (UTC)

known_for leads to incoherent grammar

e.g. Janet Mock gets "Known for: Transgender activist". She is known as an activist, not for an activist. The activist isn't something she created or owns, but something she is. Equinox (talk) 14:50, 15 February 2016 (UTC)

What about supplying "being a" before "transgender"? Nyttend (talk) 14:52, 15 February 2016 (UTC)

That would work, but seems a bit wordy for an info-box possibly...? Equinox (talk) 14:54, 15 February 2016 (UTC)

Or even "Transgender activism"? or is that too obvious. --RexxS (talk) 19:52, 15 February 2016 (UTC)

Nice, this is clearly the correct solution for this particular case and others like it. General rule: for the "known_for" parameter, use the activity itself instead of a role defined by that activity. A2soup (talk) 21:28, 15 February 2016 (UTC)

Just write proper English: |known_for=Transgender activism. Nothing is wrong with the template, and it is not producing incoherent grammar; editors not thinking is producing incoherent grammar.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  20:21, 22 February 2016 (UTC)

Template-protected edit request on 18 February 2016

Move the output placement of |denomination= so that it appears as Religion: <religion> (<denomination>) rather than on a second line. Where |denomination= is filled but |religion= is not, the output should simply be Denomination: <denomination>. See Template_talk:Infobox#Denomination_placement. Nikkimaria (talk) 02:09, 18 February 2016 (UTC)

Infobox person
Native name	John Just-Religion
Religion	Pastafarian
Spouse(s)	Mrs Just-Religion

Infobox person
Native name	John Just-Denomination
Denomination	Gluten Free
Spouse(s)	Mrs Just-Denomination

Infobox person
Native name	John Both
Religion	Pastafarian (Gluten Free)
Spouse(s)	Mrs Both

Have a look at Template:Infobox person/sandbox to check whether it does what you want, Nikki.

I've tried three test cases here, but you may want to check in some real pages by changing to {{Infobox person/sandbox}} and previewing without saving, just to be sure.

If it works for you then there should be no problem in updating the main template (data51 and data52), given the support in the discussion. --RexxS (talk) 02:58, 18 February 2016 (UTC)

Thanks RexxS, that looks right. Nikkimaria (talk) 03:18, 18 February 2016 (UTC)

Done --RexxS (talk) 03:31, 18 February 2016 (UTC)

Template-protected edit request on 25 February 2016

Add parameters father and mother. Visibly it can be shown in parents / family, but while editing please allow to add father / mother. -- Pankaj Jain Capankajsmilyo (talk · contribs · count) 20:34, 25 February 2016 (UTC)

@Capankajsmilyo: Done. The parameters won't be used unless |parents= is blank or missing. --Ahecht (TALK
PAGE) 16:46, 4 March 2016 (UTC)

Thanks -- Pankaj Jain Capankajsmilyo (talk · contribs · count) 17:12, 4 March 2016 (UTC)

allow for architect infobox to use all parameters

I added an infobox to Thorvald Astrup, who was an architect. However, the architect infobox didn't allow for some parameters, for instance, style and family. The architect infobox is supposed to work with all infobox person parameters. Can it either be made available as a module, or else all infobox person parameters be made accessible through it?--3family6 (Talk to me | See what I have done) 21:26, 2 March 2016 (UTC)

It would be better to just merge the templates, once and for all. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:51, 3 March 2016 (UTC)

That would work, too. I don't care which option is taken.--3family6 (Talk to me | See what I have done) 23:49, 3 March 2016 (UTC)

Specificity problem with /Wikidata

This version of Ali Aaltonen uses {{Infobox person/Wikidata}} and displays dates of birth and death as 1 January 1884 and 1 January 1918. However, Wikidata (and the Russian Wikipedia entry to which it is sourced) give the dates as simply 1884 and 1918. The template appears to be deriving specific dates from this year-only source, and it should not do that when the exact dates are unknown. Nikkimaria (talk) 00:15, 10 March 2016 (UTC)

The problem existed because we want to specify date formats as dmy or mdy, and that forced the display of day, month, year, even when the stored value in Wikidata only has precision of year (Wikidata always stores complete timestamps - like "+1884-01-01T00:00:00Z" for Ali Aaltonen's date of birth). I've added a test to the module that explicitly changes the date format to y (just year) when the stored precision in Wikidata is 9 (which indicates precision is year). The older version you indicated now seems to correctly display just the years, but we may need to see if anybody reports any bugs before we can be sure we have a fix. Cheers --RexxS (talk) 07:54, 10 March 2016 (UTC)

@RexxS: Thanks, but I've found one. I did a bit more digging and learned that the Historical Dictionary of the Russian Civil Wars identifies Aaltonen's DOD as August 1918. I've added that to Wikidata (although for some reason it didn't allow me to add the source...), but the old article now shows DOD as "31 July 1918". Nikkimaria (talk) 12:47, 10 March 2016 (UTC)

@Nikkimaria:. Thanks anyway for bringing it up, the module needed the fix. I can see that the old article now manages to automatically display the full date of death and just the year of birth, so that's progress. To add the source on Wikidata, it needs to be a Wikidata item, so I've created d:Q23023741 for the book (and d:Q23023849 for the author). Let's see if they last. In the meantime, it allowed me to add a reference as "stated in: Historical Dictionary of the Russian Civil Wars". --RexxS (talk) 17:19, 10 March 2016 (UTC)

Typo

There is a typo in the documentation: "It is usually not relevant to included" should be "It is usually not relevant to include". --Omnipaedista (talk) 11:45, 13 March 2016 (UTC)

@Omnipaedista: Well spotted; I've fixed it. Actually the documentation is at Template:Infobox person/doc, and since this is not a protected page you could have made the edit yourself. -- John of Reading (talk) 12:27, 13 March 2016 (UTC)

I realized that too late. Thanks for taking care of it. --Omnipaedista (talk) 21:53, 13 March 2016 (UTC)

Requested clarification

Many editors use the parameters religion and denomination in way that suggests they do not know the distinction. Therefore in the explanation box I request that either (a) a definition be added or (b) an example(s) usage be given. Hawaan12 (talk) 08:00, 15 March 2016 (UTC)

That sounds sensible. What definitions and examples do you propose? You're autoconfirmed, so you can edit the documentation at Template:Infobox person/doc, you know. --RexxS (talk) 14:26, 15 March 2016 (UTC)

RfC notice: Ethnicity in infoboxes

FYI: Pointer to relevant discussion elsewhere.

Wikipedia:Village pump (policy)#RfC: Ethnicity in infoboxes for ongoing RfC to remove |ethnicity=. (Not sure why this page wasn't notified earlier.)  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  00:12, 24 March 2016 (UTC)

RfC notice: Religion in biographical infoboxes

FYI: Pointer to relevant discussion elsewhere.

Wikipedia:Village pump (policy)#RfC: Religion in biographical infoboxes for new RfC to remove |religion= from {{infobox person}} (except where consensus determines it is directly relevant to why the subject is notable).  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  01:26, 24 March 2016 (UTC)

Age and infants

I'm a bit annoyed that the infobox in the article on Baby Fae says that her age at death was "0". She was a month old, that's not "0". Are there parameters which can be added / adjusted to show her age in terms of months and/or days? DS (talk) 16:10, 27 March 2016 (UTC)

This is a question for Template talk:Death date and age, but in the meantime I've applied a temporary fix. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:48, 27 March 2016 (UTC)

@DragonflySixtyseven: You should be able to use {{death date}} in combination with {{age for infant}}, and add the date of death as the "cmp" parameters. Alternatively, you can use {{death date and given age}}. Nikkimaria (talk) 16:56, 27 March 2016 (UTC)

Unfortunately, I've been trying this for several minutes and I don't see what I've been doing wrong. (I haven't clicked 'save' yet, though.) Could one of you take over for me? Thanks. DS (talk) 18:36, 27 March 2016 (UTC)

What's wrong with the edit by Pigsonthewing? After all, it seems unnecessary to compute the age at death of a person in perpetuity through a template – it's not going to change. -- Michael Bednarek (talk) 18:48, 27 March 2016 (UTC)

Nemmind, figured it out. DS (talk) 22:27, 27 March 2016 (UTC)

Date templates sucha s those mentioned don't just calculate an age; they also emit the date in a machine-readable format. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:49, 28 March 2016 (UTC)