Template talk:Marriage/Archive 6

Archive 1

←

Archive 4

Archive 5

Archive 6

Archive 7

Archive 8

Repeat marriages

What's the best way to proceed when a subject is married to the same person on two separate occasions? For example Stan Laurel married five times and divorced his second wife twice. Should she be listed twice or would were want to do what's there now: two date ranges and "divorced twice"? Hairy Dude (talk) 22:00, 10 August 2017 (UTC)

• I think it should be listed twice. The list of marriages should remain chronological I think. —Мандичка^YO 😜 14:52, 14 August 2017 (UTC)
• Should be listed twice. Two marriages, but the same person. Other cases are Eminem, where he has only been married to one person but twice. In the case of Elon Musk the template has not been used. Emir of Wikipedia (talk) 15:04, 14 August 2017 (UTC)
  • I also support double and chronological listing. (Tangential evidence in support: Grover Cleveland is both the 22nd and the 24nd President of the United States.) —DocWatson42 (talk) 20:54, 11 January 2018 (UTC)

parameter "show="

It appears that |show=any text is working (that is, the entered text is shown), while not documented. I suggest it be one of two (doc & support, or remove). -DePiep (talk) 18:40, 13 January 2018 (UTC)

BTW, the parameter is unused by now. So could be removed from code harmlessly. I support that removal. -DePiep (talk) 22:31, 13 January 2018 (UTC)

The parameter was introduced in 2009 by the original creator of the template, J JMesserly (talk · contribs · logs), who hasn't edited since December 2016. If it hasn't found use since 2009, then we probably don't need it. You should go ahead and remove it - it's not difficult to restore in the unlikely event of somebody suddenly finding a use for it. --RexxS (talk) 01:03, 14 January 2018 (UTC)

Two-digit ending years

Any chance of modification to support the new community consensus at MOS:DATERANGE? It reads:

• Two-digit ending years (1881–82, but never 1881–882 or 1881–2) may be used in the case of two consecutive years; in infoboxes and tables where space is limited (using a single format consistently in any given table column); or in certain topic areas if there is a very good reason, such as matching the established convention of reliable sources."

If an infobox contains a mix of open-text date ranges and date ranges generated by this template, the only way to have consistent presentation is to ignore the guideline.

The details of the support could be TBD if there is enough interest and someone with the skills to make the changes. ―Mandruss ☎ 13:50, 28 March 2017 (UTC)

There is no contradiction with the MOS:DATERANGE guideline, because infoboxes are typical places where "space is limited". However, it may be useful to offer editors an option to force display of full years, so they can achieve consistency with other items in an infobox either by lengthening the marriage ranges or by shortening the other ranges. — JFG ^talk 14:29, 28 March 2017 (UTC)

I now see that the guideline comprises a list of three items delimited by semicolons (which differ from commas in the addition of one pixel which I always find it difficult to see). If I can be misled, so can others, so I'll think about the best way to clarify the guideline's grammar. But I maintain and agree with JFG that the template shouldn't impose one presentation. ―Mandruss ☎ 14:37, 28 March 2017 (UTC)

Y I (also) support the implementation of full-length end years. —DocWatson42 (talk) 08:35, 8 September 2017 (UTC)

• Y I support full year end years. Dates like "1881–2" is also an ISO code for "February 1881" and gets translated to that date in most spreadsheets. "1881–2" also prevents me from searching for an event that occurred in 1882 when I type in control-F "1882". I understand the shorthand for newspapers to save space, but we do not have that problem. Clarity and unambiguousness should take precedence over archaic space saving measures. --RAN (talk) 21:23, 27 October 2017 (UTC)

Edit request

I also agree with the implementation regarding the above stalled thread Two-digit ending years. If more discussion is warranted, please disable the request template. Not sure how to make the changes myself, hence the edit request. Pinging thread participants @Mandruss, JFG, DocWatson42, and Richard Arthur Norton (1958- ):. - FlightTime (open channel) 17:13, 11 January 2018 (UTC)

Y I still support four digit years. —DocWatson42 (talk) 20:45, 11 January 2018 (UTC)

Note: please check Template:Marriage/testcases to see if it matches the desired behaviour — Martin (MSGJ · talk) 14:07, 12 January 2018 (UTC)

@MSGJ: Yes, the Sandbox version is showing the purposed desired output as I understand it. - FlightTime (open channel) 15:27, 12 January 2018 (UTC)

Okay, deployed — Martin (MSGJ · talk) 20:26, 14 January 2018 (UTC)

Death 2

The previous RfC on this topic has caused more confusion than it has solved any issues. By not clarifying that the marriage ended upon the death of the subject of the article (although acknowledged in the article itself) causes issues as it implies the marriage has persisted after death. Additionally, if the spouse of the subject were to remarry, if people click around and skip over details it could suggest that the person in question is in two relationships at once which causes a whole stream of issues in itself. The original his death, her death thing was clearer than the layout being suggested by the discussion above. For articles where this is the case see Henry VIII where it clarifies and does not cause the confusion, a similar example is in Robert Mugabe's article.
So to summarise, the formatting used in the case of Henry VIII and Robert Mugabe is better than the discussed format above. Thoughts? Chieftain Tartarus (talk) 15:19, 20 February 2018 (UTC)

From the previous RfC I can see that option 1 has more support (which is the option I am proposing), therefore why are people enforcing option 2? I feel like the user who closed the discussion did not add up the votes for each option correctly. Chieftain Tartarus (talk) 15:21, 20 February 2018 (UTC)

• I don't understand why you're pointing us at Robert Mugabe as an example. What's wrong with saying his first wife is dead? It's obvious that a subject's marriage ends on their death. No-one is foolish enough to think it persists beyond the grave. The opening statement doesn't make logical sense and should be phrased neutrally. DrKay (talk) 20:53, 20 February 2018 (UTC)

@ChieftanTartarus: You need to respond to my point about Mugabe. The formatting on Mugabe is the same under both option 1 and option 2. It's one of the reasons the new RfC makes no sense. DrKay (talk) 10:43, 22 February 2018 (UTC)

• I don't understand this re-RfC, and I don't understand the previous RfC. At least, the RfC-closer tried to make sense. Time to redefine the topic.

1. When the article subject dies, the marriage ends.

2. When the article subject's spouse dies, the marriage ends.

This should be stated in the infobox (of the subject's article).

What is needed/missing: declaration of the End of subject's marriage, even if by death of subject (if by death of spouse: obvious), and even if date is unknown (but reason is).

I propose, add rule: "Allow adding add reason end of marriage", esp when by death (of subject or spouse).

This requires (I propose): when |end= is entered, show it (irrespective of parameter |3=<date>). Because: date can be unknown, but reason end of marriage must be shown. -DePiep (talk) 21:18, 20 February 2018 (UTC)

• @DrKay: The point is the current template and the previous RfC contests the use of 'his death', 'her death' and leaves some people with claims that they are still married despite being dead. Chieftain Tartarus (talk) 08:17, 21 February 2018 (UTC)

• No, that wasn't the point of the previous RfC. Everyone agreed that "his death" and "her death" was fine and no-one claims that they are still married despite being dead. DrKay (talk) 08:22, 21 February 2018 (UTC)

In that case, a user started a conflict with me due to the previous RfC not being clear enough on that resolution as I used the format you have just stated is acceptable. Chieftain Tartarus (talk) 09:10, 22 February 2018 (UTC)

• @DePiep: I agree with you on the proposed formatting, it will clear up many of the confusions with the template. Chieftain Tartarus (talk) 08:19, 21 February 2018 (UTC)

Invalid time

Why are 3-digit years (e.g. 940 AD) invalid? Timmyshin (talk) 12:10, 29 March 2018 (UTC)

This template uses {{Get year}}, and that template uses {{Four digit}}, which always returns four digits when the number is four or fewer digits. It has always been a poorly-designed template. DrKay (talk) 16:21, 29 March 2018 (UTC)

• What should be done? Timmyshin (talk) 07:33, 30 March 2018 (UTC)

For now, write 0940? →

Fred Smith

​

(m. 0940)​

. - DePiep (talk) 09:47, 30 March 2018 (UTC)

Or don't use this template: |spouses=Fred Smith (m. 940). - DePiep (talk) 10:49, 30 March 2018 (UTC)

Module:String2 now has a stripZeros() function, which reformats the first string of digits in its argument into a regular number. I've incorporated it into Template:Marriage/sandbox. You still need to write 4-digit dates to get around the error trapping in Template:Four digit, but at least the display will be correct.

• {{marriage/sandbox |Fred Smith |0940}} →

Fred Smith

​

(m. 0940)​

• {{marriage/sandbox |Claudius |0038}} →

Claudius

​

(m. 0038)​

• It should be a rare enough occurrence for folks to live with until I (or somebody else, hint) can find the energy to re-write the whole template. --RexxS (talk) 19:17, 30 March 2018 (UTC)

Looks good. Testcases? Promote & test for similar templates? - DePiep (talk) 19:51, 30 March 2018 (UTC)

RexxS: please take a look at /testcases#Uncommon_dates. (Check my testcases first wrt spelling etc ;-) ). AFAIK, magic word {{time:}} is used, so this is wm level & ISO dates -- which is unclear about pre-1582 at least. - DePiep (talk) 20:33, 1 April 2018 (UTC)

It all looks good to me, DePiep. I've added examples to the Uncommon dates section using 4-digit dates for (year=0, 7, 28, 945). There wasn't a year 0, of course, but that's nothing to worry about. You're quite right that ISO dates are only defined on the Gregorian calendar, but as this template only has a precision of one year, the differences between Julian and Gregorian (not more than a couple of weeks at most) are unlikely to be a concern. If we want to use it to say that Nero married Claudia Octavia in AD 53, the template ought to be able to cope with that without causing problems:

• {{marriage/sandbox |[[Claudia Octavia]] |0053}} →

Claudia Octavia

​

(m. 0053)​

Of course, it's a different scenario if anybody wants to use similar coding in templates that use dates that have precision of a day, as the calendar model then becomes important. --RexxS (talk) 01:13, 2 April 2018 (UTC)

Green

Why is the year's color is green? Hddty. (talk) 05:16, 15 August 2018 (UTC)

I've reverted that change. DrKay (talk) 07:50, 15 August 2018 (UTC)

Per {{abbr}} "Please note: Do not use or to mark up material other than abbreviations or acronyms. Using it to generate tooltips elsewhere is a misuse of the underlying HTML and causes accessibility problems." The recommended alternative is {{finedetail}} (which happens to use green) see "Typical use might be for dates, for example where the main fact can be the year only and the finer detail is the full day, month, and year."--Neve~selbert: 10:07, 15 August 2018 (UTC)

Green also causes accessibility problems. DrKay (talk) 10:14, 15 August 2018 (UTC)

@DrKay: Might this be acceptable? Text would now be highlighted rather than coloured green.--Neve~selbert: 11:00, 15 August 2018 (UTC)

It's much the same problem: the years will be formatted in a different text style to the rest of the template (name, brackets, abbreviation and dash). I don't see how a tooltip hovering over the abbreviation is any different from a tooltip hovering over the date. Nor do I see why fine detail should be highlighted. If you look at the 8 articles that use that template, it's by no means obvious why the text is highlighted and it looks poor to my eye. DrKay (talk) 11:25, 15 August 2018 (UTC)

Looking at this more deeply, should {{Finedetail}} also be deprecated? It creates the same floating text that is deprecated by Wikipedia:Manual of Style/Accessibility#Text, which seems to be why tooltip was deprecated/redirected: Wikipedia:Redirects for discussion/Log/2018 May 9#Template:Tooltip. According to the guideline, we shouldn't use that effect for anything other than abbreviations. DrKay (talk) 11:46, 15 August 2018 (UTC)

The HTML specification for the attribute appears to match its use at {{finedetail}}. The problem, of course, is the accessibility (on which the specification comments). <aside> or <small> might reasonably be implemented to make the same kind of distinction that {{finedetail}} purports to. We would probably want to set the CSS for those elements somewhat differently than their defaults, however. --Izno (talk) 12:47, 15 August 2018 (UTC)

The use of title in <abbr> is basically required per the HTML specification, and is intended to be the abbreviation's full meaning (i.e., <abbr title="married">m.</abbr> -> m.). This use is correct in this template. There are a few other must-uses listed at the title section in the HTML specification (<dfn> is the only other one we need to care about as wiki-editors--not relevant here).

Otherwise, the general guidance is to avoid using the attribute where you would need to rely on it to convey some extra meaning relative to the text inside the HTML tag in which it is used. On that point, the other use of {{abbr}} here looks like it is wrong--the year-only version is not an abbreviation according to the HTML specification. In its use to 'shorten the date', the title attribute attached to a <span> would similarly be wrong, per the general accessibility guidance (that is, relying on the title attribute to provide the full date). These uses should be removed. Either the full date should be provided in the text to the reader if you wish to communicate the full date, or the partial date should be provided in the text to the reader. --Izno (talk) 12:40, 15 August 2018 (UTC)

Text size

Using this template "as is" in an infobox produces text that is 83% of the page fontsize. This is clear breach of the bright-line accessibility requirement "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)." - MOS:FONTSIZE.

Given its extensive use in infoboxes, the default fontsize for this template should be 100%. --RexxS (talk) 17:29, 1 December 2016 (UTC)

@RexxS: – How did you get 83%? – wbm1058 (talk) 04:58, 15 December 2017 (UTC)

Probably by inspecting the html using Chrome's "Inspect" ability. It was 12 months ago!

However, infoboxes reduce the text size to 88% of page base font size and the template as it was at the time reduced the text size by default to 95% of that in line 13 (95% of 88% is about 83%).

None of of the options for font size that would reduce it by more than a couple of percent would be usable in an infobox. Given that this template is almost exclusively used in infoboxes, those options were also useless. --RexxS (talk) 11:17, 15 December 2017 (UTC)

Thanks. I see HERE the discussion which led to moving font-size:88% from Template:Infobox to MediaWiki:Common.css. I see that the current version of MediaWiki:Common.css still sets it to 88%:

/* Infobox template style */
.infobox {
	border: 1px solid #a2a9b1;
	border-spacing: 3px;
	background-color: #f8f9fa;
	color: black;
	/* @noflip */
	margin: 0.5em 0 0.5em 1em;
	padding: 0.2em;
	/* @noflip */
	float: right;
	/* @noflip */
	clear: right;
	font-size: 88%;
	line-height: 1.5em;
}

I added an example infobox to the Template:Marriage documentation. You can clearly see the fonts are smaller in the infobox. It seems to me that this template is intended to be used only inside infoboxes. Does anyone know of any uses that are not inside infoboxes? wbm1058 (talk) 23:38, 15 December 2017 (UTC)

I don't really know CSS and more advanced HTML that well. Playing with Chrome's "Inspect" I see that {{Infobox person}} generates

<table class="infobox biography vcard" style="width:22em">

but I can't figure out what that does exactly. I see that somehow it uses the Infobox template style (specs shown above). wbm1058 (talk) 01:22, 16 December 2017 (UTC)

@Wbm1058: The declaration class="infobox biography vcard" applies each of the styles defined for .infobox, .biography and .vcard in turn to the table that makes up the infobox. As it happens, there are no styles defined globally for the biography and vcard classes (although they are there for future use, or for users to change the styles to their personal needs). So the only change to font-style native to an infobox is the reduction to 88% of the page font size. That must apply to any infobox using our normal construction, so all text in an infobox is 88% of normal by default. That, of course, means that you effectively can't use any device that makes the font size any smaller in an infobox without breaching MOS:ACCESS. The 85% lower limit was agreed after some considerable debate, but it was recognised that a "bright-line" had to be drawn somewhere. If I can help further, please feel free to ask. Cheers --RexxS (talk) 01:49, 16 December 2017 (UTC)

Thanks RexxS. I see this explains font-size inheritance. So if we are already at 88% by virtue of being inside an infobox, and the MOS:FONTSIZE limit is 85%, then font-size: 97% is the lowest we can go for ()=small (0.88 × 0.97 = 0.85). Not sure if the 3% difference will be noticeable. wbm1058 (talk) 02:20, 16 December 2017 (UTC)

@Wbm1058: It won't. That's why we can't meaningfully reduce font size in an infobox. Editors will just have to find other ways of demarking the dates if they feel it necessary. --RexxS (talk) 03:48, 16 December 2017 (UTC)

Below are some examples, demonstrating the subtle differences. wbm1058 (talk) 11:45, 16 December 2017 (UTC)

Examples

Fred Smith (m. 2010) all at 100% Fred Smith (m. 2010) name at 100%, () at 97% Fred Smith (m. 2010) name at 100%, () at 85% Fred Smith (m. 2010) all at 88%[current default, as of 4 December 2016 (diff)] Fred Smith (m. 2010) name at 88%, () at 85% (97% of 88%) Fred Smith (m. 2010) name at 88%, () at 83.6% (95% of 88%) [former default] Fred Smith (m. 2010) name at 88%, ()=small[er] at 79% (90% of 88%) Fred Smith (m. 2010) name at 88%, ()=mini at 75% (85% of 88%) Fred Smith (m. 2010) name at 88%, ()=mini at 70% (80% of 88%)[until 4 December 2016 (diff)]

Template history

• When J JMesserly created this template in 2009, they clearly intended for it to be used in infoboxes, as just after creating it, that's where they implemented it. J JMesserly last edited a year ago, and hasn't been active since 2009.
• The small[er] parenthesis option was added by Sardanaphalus on 28 July 2014. Apparently they were unaware that this was non-compliant at 79% (90% of 88%). Sardanaphalus last edited over two years ago, when this ANI was filed.
• The parameter for mini/tiny was added by Trödel on 2 July 2015. Trödel has made 20 edits so far this year.
• The only discussion on this functionality I've found is at Template talk:Marriage/Archive 4 § Text size for dates, where concerns similar to those of RexxS were expressed.

Given this dubious background, I intend to remove support for parameter |()= from the template. There are some 700 uses of (small), out of 19,000+ transclusions of {{marriage}}, but it seems there are no uses of (mini/tiny). If I find any that aren't in infoboxes, then we'll deal with those then. – wbm1058 (talk) 13:32, 16 December 2017 (UTC)

Thank you, Wbm1058. I fully endorse your proposal for obvious reasons. If there are places in running prose that actually use this template, and different sizes are needed, they can always be finessed with a construction like this:

• {{smalldiv | {{marriage | {{big|[[John Doe|Jane Doe]]}} | 1 January 1895 | December 31, 1905}} }} →

Jane Doe

​

​

(m. 1895⁠–⁠1905)​

which doesn't require the template to provide the different font sizes. Hope that helps. --RexxS (talk) 14:11, 16 December 2017 (UTC)

 Done (diff) – wbm1058 (talk) 19:08, 21 December 2017 (UTC)

RexxS, wbm1058: The markup {{small | {{marriage | {{big|[[John Doe|Jane Doe]]}} | 1 January 1895 | December 31, 1905}} }} causes a miscellaneous Tidy replacement issues lint error: the div-span-flip, which happens whenever the code processes to <span><div>...</div></span>. As an alternative,

• <div style="font-size:smaller">{{marriage | {{big|[[John Doe|Jane Doe]]}} | 1 January 1895 | December 31, 1905 }}</div> →

Jane Doe

​

​

(m. 1895⁠–⁠1905)​

will work, but it will appear on a line on its own. So my advice is to use just plain {{marriage | [[John Doe|Jane Doe]] | 1 January 1895 | December 31, 1905}} and not worry about fine-tuning the font sizes. —Anomalocaris (talk) 01:11, 14 September 2018 (UTC)

< small > inside infoboxes

@RexxS: Taking a look at the monthly error report I'm seeing a bunch of bad parameter names. Looking at a random one in particular, children was specified on one page, Lynn Collins. The source code:

| spouse       = {{marriage|Steven Strait<small>|2007|2013|reason=div.}}</small><br>{{marriage|Matthew Boyle<small>|2014}}</small>
| children     = 1

Obviously this syntax has confused the Template Parameters tool. As of June 10, 2016, a rule has been added to MediaWiki:Common.css, so now <small> consistently renders at a 85% size. {{Small}} remains as a convenience wrapper. So the use in Lynn Collins appears to be a MOS:FONTSIZE violation at 75% (85% of 88%). I suppose the solution is to remove all the <small> tags that are embedded or partially embedded inside the {{marriage}} template. – wbm1058 (talk) 16:33, 28 December 2017 (UTC)

Indeed, Wbm1058. There's never any possible reason for making such a mess by trying to pass an opening tag in one parameter and the closing tag in another. Inside an infobox, there's no margin for altering font size at all, so the simplest course is to remove those tags. If the problem persists, I'll re-write the entire template in Lua and filter out any html from the parameters passed. Let me know if you feel that to be necessary. --RexxS (talk) 19:28, 28 December 2017 (UTC)

Parameter "()="

Parameter |()= has been removed from code: [1]. As of today, 13 Jan 2018, some 700 articles in mainspace have this (now idle) parameter. -DePiep (talk) 22:51, 13 January 2018 (UTC)

I've used AWB to clear these. There should be very few remaining in the monthly error report for March. – wbm1058 (talk) 11:54, 27 February 2018 (UTC)

I was looking at this earlier. What do you think about (possible) remarks saying this are "trivial edits"? - DePiep (talk) 14:58, 27 February 2018 (UTC)

I assume that you're referring to the WP:COSMETICBOT policy. I'm assuming that this qualifies as an exception under "administration of the encyclopedia", such as the maintenance of hidden categories used to track maintenance backlogs. I made those edits gradually, in batches of 100 at a time, and was prepared to stop if anyone objected. Nobody did. wbm1058 (talk) 15:50, 27 February 2018 (UTC)

Good change - I was unaware of the accessibility issues or standards. --Trödel 16:09, 11 October 2018 (UTC)

Invalid HTML

Resolved

Right now, this template outputs a <div> inside of a <span>, which is invalid HTML. I am not entirely sure of the best way to deal with this, since I'm not intimately familiar with itemscope and itemtype. --Izno (talk) 12:52, 15 August 2018 (UTC)

The span tags were removed. – Jonesey95 (talk) 08:24, 24 October 2018 (UTC)

Dates not given

If optional dates for a marriage not specified in the template, it appears that parentheses still show up in the rendered text (see use at Ilhan Omar, for example). I think that if no dates are offered no parentheses should appear. jps (talk) 14:31, 8 November 2018 (UTC)

OTOH, it's not clear why one would want to use this template if there are no dates to be provided. The template might be useful for providing confirmation that there was a marriage, but maybe not. jps (talk) 14:39, 8 November 2018 (UTC)