Template talk:Marriage/Archive 2
![]() | This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 1 | Archive 2 | Archive 3 | Archive 4 | Archive 5 |
Removing parameters
The recently-concluded TFD was filled with people objecting to the presence of many of this template's parameters: many delete voters saw them as reason to delete, and many keep voters (including me) saw them as extraneous and worthy of chopping. I placed this template at the Sandbox (revision) with all parameters filled out, and the template only displayed the following parameters:
- 1= (the name of the person getting married)
- 2= (the date of marriage)
- 3= (the date of the end of the marriage)
- reason= (the reason why the marriage ended)
Everything else is in the HTML, but it's only producing the microformatting that's apparently broken; see the block of text at the end of the final section of this version of WP:VPT. Removing the other parameters apparently won't affect the appearance of the articles in which these parameters are used, so can we remove them to cut down on template bloat and mangled microformats? I'd say yes, but I'm not going to do it without additional input. Nyttend (talk) 02:26, 15 April 2013 (UTC)
- I'll back this, I see no problem with cutting this down. Ducknish (talk) 02:35, 15 April 2013 (UTC)
- This looks like a great proposal, I completely support it. Grammarxxx (What'd I do this time?) 02:42, 15 April 2013 (UTC)
- I would like to see what pages use the parameters that are under consideration to cut. I'll put in some maintenance categorization within an hour and put a little table below. If nothing is using the parameter, cut it. If it is being used, then it should probably be displayed. Technical 13 (talk) 11:07, 15 April 2013 (UTC)
- A good idea. I'd also like to be able to code multiple marriages.--Auric talk 11:16, 15 April 2013 (UTC)
- There's a version in the sandbox with less parameters (output is on the testcases page). The only thing it's missing from the list above is the reason parameter since it seemed like too much info to cram into the infobox field. — Bility (talk) 15:49, 15 April 2013 (UTC)
- Just waiting for the categories below to populate, then I'm sure we'll have a better idea of what is(n't) needed. Technical 13 (talk) 17:06, 15 April 2013 (UTC)
- Okay, based on the list below, there are some arguments that can just be chopped as they are unused:
- spouse1
- street-address3
- province
- locality2
- locality3
- uncertain
- state
- department
- postcode
- Technical 13 (talk) 17:50, 23 April 2013 (UTC)
- Okay, based on the list below, there are some arguments that can just be chopped as they are unused:
- Okay, after some more work, the only parameters left used by articles are:
- 1
- 2
- 3
- reason
- show
- There are some you can see listed below that are being used, but not on articles... I'm untagging those to list articles only so we can see what else is using the template. Then all but the ones I've just listed can be chopped until they can properly be coded to be included. Technical 13 (talk) 13:13, 24 April 2013 (UTC)
Maintenance list
Okay, so I've added all of the categorization to the template and here is a list that will show which parameters are used and which aren't.
- Given the above, and the below, what need is there, to keep this template. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:29, 10 July 2013 (UTC)
- The above is a representation of nothing since the maintenance categories were stripped out of the template. Kind of makes your question moot in my opinion. You are most certainly welcome to take it to another TfD to get a new consensus now that the extraneous arguments have been removed per the last discussion. Technical 13 (talk) 12:43, 10 July 2013 (UTC)
Template Violates WP:YEAR
![](http://up.wiki.x.io/wikipedia/en/thumb/f/fb/Yes_check.svg/20px-Yes_check.svg.png)
I've noticed that this template violates the terms of WP:YEAR. The YEAR page clearly states: A closing CE or AD year is normally written with two digits (1881–86) unless it is in a different century from that of the opening year, in which case the full closing year is given (1881–1986). For clarity, years with fewer than four digits may be written in full (355–372). Is there anyway to change the template so it does not violate such? livelikemusic my talk page! 14:22, 25 October 2013 (UTC)
- I've spent an hour or so and this template now has the logic that this isn't an issue. Was throughly tested through /sandbox revisions and monitoring changes to /testcases. Happy editing. Technical 13 (talk) 00:56, 26 October 2013 (UTC)
Endash got un-spaced
Somehow, the endash between the years became un-spaced, in contradiction of MOS:ENDASH section 1: "The en dash in a range is always unspaced, except when at least one endpoint of the range includes at least one space." Based on #Spaced endash above, it was apparently correct at one point.
To fix it, the endash ("–") in the template code should be replaced with " – ", right? —[AlanM1(talk)]— 00:16, 3 October 2013 (UTC)
- Hi Alan. This edit is what changed it. Rrius seems to think that "year-only date ranges aren't spaced", so I've just pinged him (and am reverting) so that it can be discussed. Technical 13 (talk) 11:57, 3 October 2013 (UTC)
- I'm sorry, but you don't appear to have read the policy. It says, "The en dash in a range is always unspaced". It then goes on to explain that when a certain condition is met, spaces are put on either side of the dash. That condition is that either the beginning or end point of the range contain a space itself. Since a year does not have a space, it does not meet the condition. As such, there should be no spaces around the dash. I am reverting. -Rrius (talk) 19:44, 3 October 2013 (UTC)
- To be clear, what the policy is saying is that 1901–1930 is not spaced, but 1901 – February 1930 is spaced. This is because neither "1901" nor "1930" contains a space, but "February 1930" does. -Rrius (talk) 19:49, 3 October 2013 (UTC)
- @Rrius:Yes, and the template seems to now always insert at least
"(m. "
in front of the marriage year (at least), meaning there is always at least one space and the endash should therefore be spaced (e.g."(m. 1930 – d. 1946)"
). —[AlanM1(talk)]— 23:58, 3 October 2013 (UTC)- I believe
- @Rrius:Yes, and the template seems to now always insert at least
should not be spaced. seems like logic would complicated to make this work in all cases. a better option, in my opinion, would be to simply not use the template in the cases that it is not producing the correct spacing (or use the show= option). Frietjes (talk) 00:22, 4 October 2013 (UTC)
- Wrong. If it is m. 1962–1982, then the "m." applies to the whole date range; it is not a part of the first year. If you are using "m." and "d." together, there should be no dash (i.e., it should be m. 1962; d. 1982 or some such). -Rrius (talk) 02:07, 4 October 2013 (UTC)
- I've got an edit/idea sitting on my laptop until I get to school tomorrow where there is wifi to test that should resolve this issue. I don't see why full dates aren't being used but instead only years. Technical 13 (talk) 00:56, 4 October 2013 (UTC)
- @AlanM1, Frietjes, and Rrius: so I've played in the sandbox and I think I've finally got it working well to address all issues raised above. This includes full dates (in an abbr popup), using "; " if there is a reason specified, and no spaces for just years. I'm unclear from MOS: if the years actually should be unspaced with the full years available as popups though... I'm thinking that maybe there could be a new parameter that would allow full dates to be not in abbr popup, and include extra spaces around endash. Please see Template:Marriage/testcases and let me know if there is anything else that needs adding. Technical 13 (talk) 13:56, 4 October 2013 (UTC)
I am, of course, wrong. D'oh!.
- In (m. 1930–1946), I agree that the "m" does apply to the range, not just the first year, making the unspaced endash correct.
- In (m. 1930; d. 1946) the semicolon with trailing space is the correct punctuation, not the endash.
- I'll note that the MOS currently says that the closing year of a range of years in the same "century" should have just two digits (i.e. 1930–46), but that's on my list of things to question, since I don't think that should be mandatory; as often as I run into 1930–1946, it may not even represent the majority of usage in WP. ("century" quoted because it may not be technically correct either)
- Since the template is normally used in Infoboxes, I think years only is the correct format, given the limited space available.
—[AlanM1(talk)]— 17:13, 4 October 2013 (UTC)
- AlanM1, so you support the sandbox version as it is? There is little I can do about the 1930-42 thing at this time, but I'd be happy to research and work on making that happen. Technical 13 (talk) 17:31, 4 October 2013 (UTC)
- It sounds like we've reached a consensus. I would only add that I think the technical problems seem to me to justify ignoring the YYYY–YY thing, which is ignored pretty routinely anyway. Incidentally, MOS tends to apply with more force to prose than elsewhere, so there is still another reason not to get too bothered about ignoring the problem. -Rrius (talk) 21:05, 4 October 2013 (UTC)
- With regard to the 2-digit year, I agree with leaving it as is – the performance penalty to "fix" it is too great in template code, and should probably wait for a Lua version (and I want to try to get it out of the MOS anyway
).
- {{Marriage/testcases}}: The doc says that
|reason=
is supposed to be either "divorced" or "widowed", but the code also appears to support aliases: "d", "d.", "div", "div."; and "w", "w.", "wid", "wid."; respectively. "s", "s.", "sur", "sur.", and "survived" are also supported. If the value is none of those, it just passes through whatever is given, whereas previously, it ignored the parameter. This last bit may affect existing usage, though I suppose it would have technically relied on undocumented behavior. I can do the doc changes. Does "survived" mean that the subject of the article survived the person named in the template, or vice-versa? —[AlanM1(talk)]— 21:36, 4 October 2013 (UTC)
- With regard to the 2-digit year, I agree with leaving it as is – the performance penalty to "fix" it is too great in template code, and should probably wait for a Lua version (and I want to try to get it out of the MOS anyway
- It sounds like we've reached a consensus. I would only add that I think the technical problems seem to me to justify ignoring the YYYY–YY thing, which is ignored pretty routinely anyway. Incidentally, MOS tends to apply with more force to prose than elsewhere, so there is still another reason not to get too bothered about ignoring the problem. -Rrius (talk) 21:05, 4 October 2013 (UTC)
- AlanM1, so you support the sandbox version as it is? There is little I can do about the 1930-42 thing at this time, but I'd be happy to research and work on making that happen. Technical 13 (talk) 17:31, 4 October 2013 (UTC)
Sorry about my delay Alan. Survived means the person died and Widowed means the spouse died. I've also added the logic to deal with the MOS:YEAR issue that was raised again below. Let me know if there is anything else I can do. Happy editing. Technical 13 (talk) 00:58, 26 October 2013 (UTC)
Abbreviations
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.
Please change the abbreviation for divorce to "div." and not "d." "d." is universally understood to mean died. DrKiernan (talk) 22:17, 21 December 2013 (UTC)
Not done: please establish a consensus for this alteration before using the
{{edit protected}}
template. Also, [citation needed] that this is "universally" understood. Also, it's not "d.", it is d. (put your mouse over it). Technical 13 (talk) 22:33, 21 December 2013 (UTC)
- As far as death goes, this template uses s. or w.. Technical 13 (talk) 22:35, 21 December 2013 (UTC)
- Why would I run my mouse over it? Normally, people just read what's written. The abbreviations (apart from m.) are not clear because they are not in general use outside of this template. DrKiernan (talk) 22:50, 21 December 2013 (UTC)
- Even without running your mouse over it, we are talking about marriage here, the options for that ending are, "widowed", "survived", or "divorced". "Died" isn't in this list. So, please get some consensus to make this change. :) Technical 13 (talk) 01:53, 22 December 2013 (UTC)
- A marriage obviously ends when one of the partners dies. DrKiernan (talk) 09:51, 22 December 2013 (UTC)
- Okay, yes, when someone dies the marriage ends. I'll give you that. Problem is "died" is ambiguous because it doesn't tell you ho died. This is why we use survived or widowed when dealing with deaths in marriage. Survived means the topic of the page died and left a spouse behind and widowed means the spouse died. Technical 13 (talk) 12:41, 22 December 2013 (UTC)
- I don't think that is clear at all since I would expect the parenthetical comment to apply to the spouse not to the subject of the page. Hence, I read "survived" and "widowed" in the same sense: spouse survived subject of the page, and spouse was widowed. DrKiernan (talk) 13:38, 22 December 2013 (UTC)
My initial request was not to change widowed and survived to "d." but to change "d." to the obviously unambiguous "div.", I think now it is better to change this template so that instead of using abbreviations we've made up ourselves, we use abbreviations that are already common practice:
These abbreviations in brackets beside the spouse's name would indicate to me that they apply to the spouse, i.e. the spouse died or was widowed in that year. DrKiernan (talk) 13:55, 22 December 2013 (UTC)
- You're overlooking why it was chosen to use single letter abbreviations with the {{Abbr}} template in the first place. This template is most often used inside of an infobox with very limited line width an longer words or abbreviations don't fit on one line. Technical 13 (talk) 17:50, 22 December 2013 (UTC)
- Then put a space in like the formatting at Charles, Prince of Wales, or Camilla, Duchess of Cornwall. It's much clearer than the formatting created by this template. DrKiernan (talk) 17:56, 22 December 2013 (UTC)
- Support proposal to change to "d.", "div.", and "wid." These are unambiguous, and I agree with Dr. Kiernan that d. generally speaking does mean "died", and thus using it for divorce is confusing. TonyBallioni (talk) 17:47, 30 December 2013 (UTC)
- support proposal to change to "d.", "div.", and "w." to "wid." per TonyBallioni and Dr. Kiernan. Frietjes (talk) 17:47, 2 January 2014 (UTC)
- Support change to "div." or similar. I have long thought that this was unnecessarily ambiguous and confusing, but I assumed there was consensus for it. Reliable sources and consensus seem to clearly favor DrK's proposal. NinjaRobotPirate (talk) 01:03, 3 January 2014 (UTC)
- Oppose as I think it takes too many lines and is bulky in the infobox... Template:Marriage/testcases#Testing in an infobox shows what I mean, having the extra 4 characters forces some lines to take two lines instead of one as in the Billy Bob Thornton example. Technical 13 (talk) 01:42, 3 January 2014 (UTC)
- Support change to div. to avoid confusion. Plastikspork ―Œ(talk) 05:31, 3 January 2014 (UTC)
- Support change to div. Somedifferentstuff (talk) 16:53, 18 January 2014 (UTC)
Ambiguous Abbreviations
Please change remove all of the abbreviations for married, divorced, survived, and widowed from this template. "m" means "male" or any number of the 67 ambiguous terms listed on M (disambiguation), Mar is most universally known as March, "d" means daughter or any number of the 93 ambiguous terms listed on D (disambiguation), Div is most universally known as divide or division, "s" means "second", "w" means "win" or any number of other things as can be seen on W (disambiguation). Since there is so much ambiguity here, let's just do away with abbreviations all together. Thanks Technical 13 (talk) 22:47, 22 January 2014 (UTC)
- I don't think there's any confusion with "m.", "div." and "wid." when they are immediately next to a row label "spouse". I could find no transclusions using survived, so I think that parameter can just be cut as unused and ambiguous. The ambiguity as I see it is that it is not clear whether the parenthetical "survived" refers to the subject of the article surviving the spouse, or the spouse surviving the subject of the article. As I said above, I think it's clearer when the parenthetical abbreviations are (1) standard abbreviations that are widely used, and (2) refer to whether the spouse died (d.) or was widowed (wid.), i.e. whether the spouse died (d.) or whether the subject of the article died (wid.). DrKiernan (talk) 23:46, 22 January 2014 (UTC)
- Eh, personally, to me d/wid is still ambiguous, because the antecedent is ambiguous, but overall I'd come down on the interpretation you suggest, albeit feeling uncertain. SamBC(talk) 23:48, 22 January 2014 (UTC)
- If you claim there is no confusion with "m.", then you are wrongfully overlooking the gay male marriage and the fact that it "could" be used to indicate that. If you truly believe that "died" is an acceptable alternative for d. in a template that only accepts parameters of annulled, divorced, married, survived, or widowed; then there is no reason for you to argue that it is possible for someone else to interpret m as male, div as diversion, or even wid as something else... So, I saw let's do away with all of it. I'll make the appropriate changes in the sandbox if someone wishes to make the change live. Technical 13 (talk) 01:33, 23 January 2014 (UTC)
- Edit: Sandbox updated. Technical 13 (talk) 01:40, 23 January 2014 (UTC)
- The template does accept the parameter died:
- Edit: Sandbox updated. Technical 13 (talk) 01:40, 23 January 2014 (UTC)
. The only reason it doesn't show d. for died is because you keep using it for the divorced parameter despite clear consensus that that is inappropriate. I never argued that "it is possible for someone else to interpret m as male, div as diversion, or even wid as something else". That was you. I said the opposite: see my comment of 23:46, 22 January 2014 above. DrKiernan (talk) 07:22, 23 January 2014 (UTC)
- There is no consensus to add died to a template about marriage. You misread what I said, what I said (let's rearrange the words a little here) is that you are claiming it is impossible for someone else to interpret m as male, div as diversion, or even wid as something else yet are dead set that those same people will interpret d as died in a template that has no consensus for allowing died as a parameter because the correct term is either widowed or survived. Does that not reflect what you are saying? Technical 13 (talk) 15:15, 23 January 2014 (UTC)
- The reason I call this a straw man is that there's no reasonable evidence or even logical supposition that anyone would misinterpret it that way - why would 'male' be attached to a date, and what does 'diversion' have to do with marriages at all? Okay, on the first of those, it could be to do with a gender reassignment, but that's a pretty outlandish thing to suppose. Meanwhile, a marriage can end by both divorce and by death. If I'd been in the original discussion, I'd say that d shouldn't be used for anything, because it's ambiguous, but I agree with the closer above that the consensus expressed is to use 'd' for death. I think the conclusion is wrong in an objective sense, but the closer has given an accurate depiction of the consensus. SamBC(talk) 15:31, 23 January 2014 (UTC)
- There is no consensus to add died to a template about marriage. You misread what I said, what I said (let's rearrange the words a little here) is that you are claiming it is impossible for someone else to interpret m as male, div as diversion, or even wid as something else yet are dead set that those same people will interpret d as died in a template that has no consensus for allowing died as a parameter because the correct term is either widowed or survived. Does that not reflect what you are saying? Technical 13 (talk) 15:15, 23 January 2014 (UTC)
- Nice straw man, well done, I applaud you... SamBC(talk) 23:48, 22 January 2014 (UTC)