Template talk:Marriage/Archive 8

Archive 5

Archive 6

Archive 7

Archive 8

Use of circa

The years fields for template appear to be incompatible with {{circa}}, which is an issue. Could we fix that? {{u|Sdkb}} ^talk 12:42, 6 December 2020 (UTC)

This has proven my statements from several months ago right. A template should not care about what parameters it is given. It should just take them in as input, format them if necessary, and produce output. This template has instead acquired a vision of how it should be used, and gone out of its way to force its uses to match that vision. That vision not only does not support {{circa}} or anything else other than bare years ({{marriage|John Doe|c. 2010}} produces

John Doe ​(m. 2024)​, silently replacing the "invalid" circa with the current year!), but appears to lack consensus. * Pppery * _{it has begun...} 17:46, 6 December 2020 (UTC)

@Sdkb: Supporting this. Is there any template editor around available to take a look at this issue? Lulusword (talk) 08:13, 29 May 2021 (UTC)

I've removed all code that tries to parse the year from the sandbox, leaving a template that just displays the year it is given, regardless of how it is formatted, and added some testcases using circa to Template:Marriage/testcases. * Pppery * _{it has begun...} 18:31, 29 May 2021 (UTC)

As shown at the test cases page, that has led to new problems, such as inappropriate spacing, full dates being given, text being placed in the date field, and invalid years no longer being highlighted. DrKay (talk) 19:13, 29 May 2021 (UTC)

I've fixed the display of full dates. I'm not seeing the problem with spacing, and for your other concerns it's better to erroneously accept invalid values than to erroneously reject (or worse, silently mangle in the case of the "manual circa" example) valid values, which the current code is doing. * Pppery * _{it has begun...} 19:50, 29 May 2021 (UTC)

The spacing issue has been fixed by removing the full dates, but there is still a problem for when text is given in the date field, for example if people are married twice but dates are not given. Compare:

Diana Spencer

​

(m. )​

and

Diana Spencer

​

(m. )​

. DrKay (talk) 21:40, 29 May 2021 (UTC)

That's a valid concern, but it's difficult to distinguish "names entered into the date field" from "dates in unusual but correct formats". The current code both erroneously accepts some things that should be rejected (nearly any name is accepted if only the first initial is given, such as {{marriage|1=Diana Spencer|2=C. Bowles}} ->

Diana Spencer ​(m. 2023)​

) and erroneously rejects or mangles some things that should be accepted (the subject of this thread). One idea I had for a better validity check would be "does the value contain 3 consecutive digits"; nearly any date will, and nearly any name won't.

The current logic in the sandbox is to first check if the value is a bare year, and if so print it unchanged (and check for a posthumous/future ending year), then check if it is a DMY or MDY date and if so display the year with the date as hover text (and check for posthumous/future dates or dates that match the date of death of the subject), and otherwise assume it's something like {{circa}} and print it unchanged. * Pppery * _{it has begun...} 22:58, 29 May 2021 (UTC)

I've looked at the testcases and it looks good but I have similar concern as DrKay above. Does the wrong usage such as

Tom Hanks

​

(m. )​

will be tracked by Category:Marriage template errors? Lulusword (talk) 04:04, 30 May 2021 (UTC)

@Sdkb: Try using |reason= as a workaround. For example, {{marriage|John Doe|reason={{c. |2010}}}} will render the {{circa}} template. ‑‑Neveselbert (talk · contribs · email) 20:35, 4 July 2021 (UTC)

I've long since forgotten which page I was asking about this in reference to, but using |reason= as a workaround seems like a bad idea for creating clean code. {{u|Sdkb}} ^talk 21:53, 4 July 2021 (UTC)

@Sdkb: can you elaborate? So long as the first two parameters remain undefined, it should display just as you would expect, i.e. "John Doe (m. c. 2010)". ‑‑Neveselbert (talk · contribs · email) 18:10, 5 July 2021 (UTC)

It would display correctly (for now), but it's much better to always use parameters for their intended purpose. Hacky things can have unintended consequences—for instance, if the ordering switches in the future it could break, or it might prevent Wikidata from scraping the data. {{u|Sdkb}} ^talk 18:17, 5 July 2021 (UTC)

Malfunction inside of infobox?

See Aaliyah for an illustration. As I write this, I'm getting an "Expression error: Unexpected < operator" in the article, but it works fine in the sandbox. —C.Fred (talk) 03:45, 6 September 2021 (UTC)

@C.Fred: Yep, seeing the same thing at Ronald Reagan. Maybe we should just revert the last edit for now? This could be breaking many infoboxes. –CWenger (^ • @) 03:53, 6 September 2021 (UTC)

@Wbm1058: Since you made the last edit to the template, could you please take a look at this issue? Thanks! GoingBatty (talk) 03:58, 6 September 2021 (UTC)

(edit conflict) This is happening at Melville Fuller as well, where the infobox is also much larger than it was before. Not sure where the issue is (this template hasn't been edited recently), but there's definitely a problem. Extraordinary Writ (talk) 04:00, 6 September 2021 (UTC)

I noticed this earlier at Louis Majorelle and went to bed hoping that someone else would solve it. Happy to wake up and see that ST47 seems to have fixed it. Great work, that's not the sort of patch I'd quickly implement like that! These were populating Category:ParserFunction errors and I observe that null edits are clearing that category now. Noting that there are no recent code changes in {{Wdib}} but that template extracts Wikidata, I conclude that the issue was caused by bad Wikidata – such issues will persist as long as we allow English Wikipedia to be infected by Wikidata. By the way my earlier change was simply a {{subst:wbr}} to prevent edits like this one from doing nasty things to every page using {{marriage}} (like putting big Nazi symbols on each page) – my edit didn't change the template functionality at all, it just localized that functionality to prevent infections from another template. – wbm1058 (talk) 12:04, 6 September 2021 (UTC)

Pppery pointed us to the culprit. See WP:Village pump (technical)#Date formatting and WikidataIB. I'm looking forward to the day I can say "_{it has begun...}". I'd be honored to have the opportunity to help make it begin. wbm1058 (talk) 12:19, 7 September 2021 (UTC)

Examples

I changed the formatting of the examples so that each is in a table row with source and output together. The previous version was difficult to read as the outputs were all presented in a two-column list that made it difficult to match each output to the corresponding source. — GhostInTheMachine ^{talk to me} 09:21, 27 December 2021 (UTC)

Dates format

Can the template be edited to allow characters other than numbers in the dates sections? Currently, the template gives the error message "invalid year" when a letter is placed in these parameters, meaning that any attempts to integrate this template in articles where the subject married in a BC year, where the letters are required to distinguish from AD years, such as with Julius Caesar, immediately fail. -- Politicsfan4 (talk) 23:49, 24 March 2022 (UTC)

@Politicsfan4: see Template:Marriage/testcases (search "Cossutia" for the particular testcase). It's not meant as a permanent solution but it should work in the meantime. ‑‑Neveselbert (talk · contribs · email) 18:18, 26 March 2022 (UTC)

Line breaks

Fourthords mentioned improper categorization in {{infobox person}} when line breaks are used in this template. I looked in Category:Pages using infobox person with multiple spouses and quickly found several instances of this. Frietjes, what to you think about adding a check (like that which populates Category:Pages using infobox cyclist with multiple entries in single field) to find these? MB 16:40, 3 April 2022 (UTC)

User:MB, I can think of a few ways to fix this, (1) adjust the logic in Module:Detect singular by Hike395 since that would erroneous classify it is plural if the entry has a line break, or (2) here by replacing the <br> or (3) here by tracking the spurious <br> as you suggested. I imagine (1) could be hard, but I haven't really looked into it. Frietjes (talk) 15:12, 4 April 2022 (UTC)

User:MB, looking at the code for this template, it looks like the <br> is typical, with lots of logic to adjust the line spacing in that case. Frietjes (talk) 15:23, 4 April 2022 (UTC)

I found over 5000, so might be easier to do (1) or (2)? or maybe (4) which would mark the "end of spouse name" br tags so they aren't parsed incorrectly by Module:Detect singular? Frietjes (talk) 17:33, 4 April 2022 (UTC)

both short/aligned
Spouse	Jennifer Leigh ​ (div. 1997)​ Jordyn Blum ​ (m. 2003)​

one long/unaligned
Spouse(s)	Jennifer Leigh Youngblood ​ ​ (m. 1994; div. 1997)​ Jordyn Blum ​ (m. 2003)​

one long/forced aligned
Spouse(s)	Jennifer Leigh Youngblood ​ ​ (m. 1994; div. 1997)​ Jordyn Blum ​ ​ (m. 2003)​

Frietjes, No one else has commented either here or at IB person. It looks like the only reason to use a line break would be to change the alignment (as in example 3). I am fine with the unaligned version, since I find it just as readable and it makes the infobox shorter. If I understand what you said, option (2) would accomplish that (and fix the categorization). But since at lot of breaks have been added, there would probably be some objection. You didn't say anything about the difficulty of (4), but I assume that would be the fallback choice. MB 21:33, 8 April 2022 (UTC)

@MB: I was on wikibreak. If you need me to add more logic to {{Detect singular}}, I can, but it sounds like you want to remove spurious line breaks instead? — hike395 (talk) 04:09, 14 April 2022 (UTC)

hike395, since this template is used on 60k articles, I think there should be more discussion before doing anything. When you said "remove spurious link breaks", if that corresponds to (2) above which is essentially for this template to ignore/remove
, then yes, that is my suggestion. But that means if someone wanted the layout in the third box, they couldn't have it and may get annoyed/upset that the template was "behaving" that way. Frietjes, you haven't commented recently. MB 00:03, 19 April 2022 (UTC)

@Hike395 and MB: I think this change would fix it. I can't think of any cases that would be broken by ignoring a <br /> or <br> right before a </div>. I have added a case to Template:Detect singular/testcases. this will only catch the trailing <br /> which seems to be the most common. a more aggressive version would ignore all all <br /> nested inside of <div>...</div> but I don't know if that would mess up working cases. Frietjes (talk) 13:55, 19 April 2022 (UTC)

@Frietjes and MB: I was going to propose something simpler: I can add |no_break= to Module:Detect singular, and if |no_break=1, then line breaks are not considered to be plural. Then {{Infobox person}} can call Module:Detect singular with |no_break=1. This has precedent: there are other templates that call Module:Detect singular with, e.g., |no_comma=1.

Should I go ahead and implement that? — hike395 (talk) 05:31, 20 April 2022 (UTC)

hike395, we still need to detect when a <br> is being used to delimit two spouses, like in the examples above which are all multiple spouses. I have added a couple more test cases. Frietjes (talk) 14:48, 20 April 2022 (UTC)

Start and end dates of additional spouses unknown - help needed

The infobox for Nasim Ali has Amanda as his wife, whom he married in 2003. However, the press release for him becoming Mayor of Camden names his wife as Lina Choudhury. How can I incorporate this into the infobox, when I don't know the date his previous marriage ended, and when this one began?--TrottieTrue (talk) 18:52, 24 June 2022 (UTC)

@TrottieTrue: This article [1] have him mentioned the mother of his child as his ex-wife, so my advice is to do something like this.

Nasim Ali
Spouses	Amanda ​ ​ (m. 2003, divorced)​ Lina Choudhury

Lulusword (talk) 23:13, 24 June 2022 (UTC)

OK, thanks, I have added it as you suggested. TrottieTrue (talk) 23:56, 25 June 2022 (UTC)

Why is Wikidata date of death relevant to date of marriage's end?

I asked at the Help Desk why the spouse field in Alice of France's infobox has suddenly started throwing up an error message, and the responses seem to indicate that it has something to do with a change that was made in her Wikidata entry, regarding her date of death (which has nothing to do with the date her marriage ended). Can someone alter how this template draws on Wikidata, so that such ridiculous problems will not occur? (Indeed, I see no reason why the template should make use of Wikidata at all.) Deor (talk) 00:09, 10 July 2022 (UTC)

 Fixed, there should've been an error contingency, which I've now corrected. ‑‑Neveselbert (talk · contribs · email) 00:43, 10 July 2022 (UTC)

Thank you. Deor (talk) 00:51, 10 July 2022 (UTC)

Change "no value" red text

Hi. In cases where someone calls the template like this:

Alexandra Duarte

​

()​

We're currently putting "no value" in red text next to spouse names. This seems bad, can we please change the language to "marriage date missing" or remove this text? --MZMcBride (talk) 01:02, 8 January 2023 (UTC)

Done. This still seems suboptimal though. Legoktm (talk) 01:11, 8 January 2023 (UTC)

I would flag it as an error for the editor to fix either by supplying date(s) or not using the template. Why not "Error: date(s) missing" or something similar? Perhaps provide a "(help)" link back to the template page. — Archer1234 (u·t·c) 01:23, 8 January 2023 (UTC)

Why is the date required in the first place? Shouldn't it be an optional parameter, with at best a hidden tracking category? Legoktm (talk) 22:02, 8 January 2023 (UTC)

Agreed but red text with {{If preview}} sounds reasonable to me. --Trialpears (talk) 07:36, 9 January 2023 (UTC)

Template-protected edit request on 29 March 2023

 Done — Martin (MSGJ · talk) 15:09, 31 March 2023 (UTC)

Requested edit:

I'd like to propose changing the span tags for red error text to the use of Template:Error-small.

Details/comments:

It seems cleaner to use fewer direct html tags and instead abstract the error message formatting out from the template itself. A relatively small change all in all, but I think it would be beneficial to outsource it to the standard WP:CLASS for "error" text formatting (the error-small template invokes Module:error which applies the CSS class).

The changes would match that which was added to the sandbox version on this revision, or see the diff of changes from previous sandbox version

Example

Switch to using this:

{{error-small|(invalid year)}} →

Compared to current implementation:

(<span style="color:red;">invalid year</span>) → (invalid year)

I'd love to hear what folks think. Thanks!

– Pedantical (talk) 23:49, 29 March 2023 (UTC)

There were lots of other changes in the sandbox too. Before editing a sandbox it is worth checking that is synchronised with the live template :) I have done that now, so please make your change(s) again — Martin (MSGJ · talk) 08:44, 31 March 2023 (UTC)

Done! Apologies on the other changes in there. I suppose that would have been helpful for a quick review and edit :)

– Pedantical (talk) 14:43, 31 March 2023 (UTC)

Wikidata pull for death date?

Hello,

I'm a bit confused. The documentation doesn't suggest it, but I'm seeing on some pages like Grover Cleveland that the death year is assumed as end of marriage year when the death of the subject of the article has wikidata for death date but no marriage end date. Is this by design? I thought the whole point of removing 'her death' and 'his death' was to remove confusion in whether a marriage ended the same year as their death or they remained married until the end. --Engineerchange (talk) 21:59, 14 February 2023 (UTC)

I've reverted to an earlier revision. DrKay (talk) 22:03, 14 February 2023 (UTC)

I'll add one extra concern with that kind of change. If we assume people remained married until their death (by default), we are adding context to every subject's page that is not properly cited/sourced. In many pages, we may know the date of marriage of a spouse, but not the death date of the spouse (and whether one died prior to the other). This change would provide incorrect information (by default) on a number of scenarios. --Engineerchange (talk) 22:31, 14 February 2023 (UTC)

Inclusion of < !-- Omission per Template:Marriage instructions --> on end-date

Is there any known history or context on the inclusion of the hidden comment:

<!-- Omission per Template:Marriage instructions -->

after clearing an existing end-date and end/reason from an instance of a marriage?

I found the use/practice of this on 150+ other pages by way of a linked search off of the Template:Marriage parameter description for End Date) and it feels appropriate to include that in an edit where seemingly valid information is being removed.

I haven't gone back to clarify all previous edits where I didn't specifically add the hidden comment, but I've been including it for now since it would be relatively easy to remove that in bulk from source if needed.

–Pedantical (talk) 14:10, 21 March 2023 (UTC)

See documentation. ‑‑Neveselbert (talk · contribs · email) 12:08, 22 March 2023 (UTC)

My question got a little buried in all of that above.

i.e.,

Should the hidden comment be added as a general practice when removing the <end date> and <end reason> from an otherwise innocuous-looking** instance of the template — particularly when someone adds or re-adds the end-date in good faith?

I'm not sure what the intention is within the docs description for <end date> where it links out as "do not provide a date".

** Specifically in the removal of the deprecated usage of 'his death' or 'her death' or the general removal of the end-date when due to the death of the article's subject.

Pedantical (talk) 18:27, 22 March 2023 (UTC)

I think the documentation stands on its own here. On that parameter, it explains how it is used:

"Reason for marriage's end. If the marriage ended because of the death of the article's subject, do not provide a reason; use of his death or her death for this purpose has been deprecated"

Commenting "look at the documentation to understand how to use this parameter" shouldn't _have_ to be the way that's done. And doing that across thousands of pages seems kind of silly. One would expect reasonable editors to look at the documentation themselves and the remainder to be notified they are using it wrong. I can see more trafficked pages that frequently have this modified may need this type of comment though, but definitely not the lion's share. At least that's my take on the matter. Cheers, --Engineerchange (talk) 19:27, 22 March 2023 (UTC)

Maiden names?

Is it customary in the first parameter to use someone's maiden name? If so, we should note that in the documentation. {{u|Sdkb}} ^talk 03:30, 23 March 2023 (UTC)

This is a great question!

Bias alert: I am from North America and am male—two biases that I don't want to get in the way of what is best here. Call me out on them if needed.

TL;DR

I don't think there should be a TL;DR on this. Not yet.

Thoughts

So there's a whole section for changed names at MOS:CHANGEDNAME. An excerpt of note is:

"A person named in an article of which they are not the subject should be referred to by the name they used at the time being described in the article."

Reading that, I'd say to state the spouse's name as they were known during the marriage so that we align with "at the time being described in the article."

But, I think it's worth a bit more discussion than just manual of style references.

Over 80% of enwiki biography subjects are about men (see: Wikipedia:WikiProject_Women_in_Red), so it wouldn't be farfetched to assume many spouse names on enwiki are likely women. And suddenly the question is much closer to "What is the proper naming convention for women when they are listed as the spouse of a man?" and that question sounds a lot different than a manual of style blurb.

I definitely don't mean to imply that my paraphrasing above is your question—just extending that question to what I wouldn't want to accidentally start discussing implicitly.

I *just* read a great blurb by @Jengod on their thoughts on usage of patriarchy names with the intention of preserving the linkages to historical data for women in Wikipedia articles. I think this is the part that stood out the most to me:

"The important thing is to make these women findable, by any names necessary"

I'd love to hear Jengod's thoughts on this topic!

It would seem reasonable to me that additional names (whether marriage-related or not) be noted in body of the article in that same spirit, and where the spouse has an article of their own, described there as well (in alignment with the other sections of MOS:CHANGEDNAME that talk about those scenarios).

What do you think, @Sdkb?

– Pedantical (talk) 15:18, 11 April 2023 (UTC)

Those are some wise thoughts, @Pedantical! Overall, I'm a proponent of documenting best practices, even when they're not entirely clear, so I'd prefer to say something in the documentation. Otherwise editors who arrive at it with the same question I had are going to be confused and likely make a snap judgement that may not be as informed as our consideration here. Cheers, {{u|Sdkb}} ^talk 16:21, 11 April 2023 (UTC)

My thoughts:

• "Maiden name" is a good guideline but also if you were writing about Aristotle Onassis, you wouldn't say he married Jacqueline Lee Bouvier, you'd say he married Jackie Kennedy or Jacqueline Bouvier Kennedy.
• There also a lot of honorifics that may come into play: so-and-so married a woman known as Widow Plentymoney, etc.

I'm not sure if we want to dictate this at all but my thought would be, like, tiers:

1. Use person's most common name (Frida Kahlo not Magdalena Carmen Frida Kahlo y Calderón, Rihanna not Robyn Rihanna Fenty)
2. Use person's preferred name *at time of marriage*
3. Use birth name (this covers maiden names which is a common term but interestedly gendered because of the inclusion of the archaic "maiden" which gets into sexual and cultural stuff etc)

A quick look at List of American heiresses suggests this gets complicated quickly!

jengod (talk) 16:43, 11 April 2023 (UTC)

Within this discourse, I would also offer up an addition that you should provide only the given name if the last name is not "certain". A lot of times, I see {{marriage|Jane Doe|1900}} on John Doe's page when Doe was likely not the common name (or maiden) prior to marriage. Actively discouraging that type of usage I think is necessary. And provides some clarity when someone marries a cousin or something. --Engineerchange (talk) 16:54, 11 April 2023 (UTC)

Absolutely, although I will note that between roughly 1800 and 1945 (?) a fair number of primary sources on borderline notable people will only refer to couples or wives as Mr and Mrs Industrial Magnate. I'm just saying in some cases the maiden name of the wife will be lost (or temporarily lost) to history and I'd rather have her recorded as Mrs. Jane Magnate than just Jane. That seems to detach her from not just her father's name/village but her supposed life partner as well, which is enough detachment to approach depersonalization and make me uncomfortable. Obviously, though, just in case it needs explicit statement: Editors should make earnest efforts to identify the full preferred name of spouses, which may be their birth names, first marriage names, professional names, etc. jengod (talk) 18:39, 11 April 2023 (UTC)

Template-protected edit request on 18 April 2023

I'm working on improving line break and spacing consistency, and I'm starting off by moving some of the repeated styles into a templatestyles source, styles.css, which has been staged under the main template. Using templatestyles for now (and a little bit more down the road) will be a huge help in getting the template code into a more human-readable state as well. Long term, the styles should be likely be removed altogether, but this is the start.

My current edits to switch the inline style CSS over to classes can be found in Template:marriage/sandbox2, and there is a corresponding testcases subpage for sandbox2 under Template:marriage/sandbox2/testcases.

This change would also raise the question about also adding edit-protection to the main /styles.css file if this change is implemented.

The changes should be set to copy/paste over from sandbox2; I've diffchecked them just a moment ago to make sure it's only these changes. Let me know if you have any questions. Happy to elaborate.

Thanks!

– Pedantical (talk) 18:38, 18 April 2023 (UTC)

Link to proposed diff. It appears that the first margin-bottom has changed from -3px to -2px. If so, is there a reason for that change? Do any of the testcases demonstrate this difference? This template has been carefully crafted over many years and has many quirks, as you can see from long discussions in this talk page and its archives. – Jonesey95 (talk) 22:37, 18 April 2023 (UTC)

Hey @Jonesey95! I had looked over the differences between -2px and -3px and couldn't find any existing test cases that appeared mal-rendered, and after looking at specific pages with varying numbers and manners of Marriage template transclusions.

I couldn't find any notable differences on the 2 vs 3 pixels, but if you see a specific example of where this is still totally applicable, I can adjust that style to keep that use case around.

– Pedantical (talk) 18:10, 19 April 2023 (UTC)

I don't know of a specific case; I just noticed that there was a change and did not know if it was intentional or would break anything. – Jonesey95 (talk) 18:49, 19 April 2023 (UTC)

Could you update Template:Marriage/styles.css with required changes and change sandbox to refer to that page? — Martin (MSGJ · talk) 09:16, 20 April 2023 (UTC)

Jonesey95 and/or Martin — I've updated the main styles.css and the sandbox2 version to account for that first margin being -3px instead of -2px (don't wanna cause any weird styling issues here, just set up the template to use TemplateStyles to start off).

I did track down when -3px is used: in repeat marriages where no name is specified, it makes the second marriage date set just a bit closer to the first date set.

Let me know if you have any additional concerns.

– Pedantical (talk) 20:57, 23 April 2023 (UTC)

 Done — Martin (MSGJ · talk) 21:09, 23 April 2023 (UTC)

Template-protected edit request on 26 April 2023

I would like to add in the Module:Parameter_validation to the template to leverage the “low-config” nature of the module to work in tandem with the existing category logic and error logic in Template:Marriage.

I’ve got the proposed change in Template:Marriage/sandbox2 but it is worth noting that this is just the stock configuration of the module to start off. Pedantical (talk) 01:44, 26 April 2023 (UTC)

 Completed. P.I. Ellsworth , ed. ^{put'er there} 04:10, 26 April 2023 (UTC)

To editor Pedantical: curious as to whether or not Module:Check for unknown parameters is replaced by Module:Parameter validation and can therefore be removed? either now or later? P.I. Ellsworth , ed. ^{put'er there} 20:57, 28 April 2023 (UTC)

@User:Paine Ellsworth I think it could be removed later, but I’d like to see it remain in place for a bit longer while some other changes are coming along to the template. But I definitely know what you mean—it felt a bit odd to leave both there, but I’d also rather see how both compare over a month or two of natural settling. Any objection to leaving it for a bit? Pedantical (talk) 19:21, 30 April 2023 (UTC)

Up to you – I'm okay with just about anything 'long as it sits high on a pillar. P.I. Ellsworth , ed. ^{put'er there} 14:24, 1 May 2023 (UTC)

Template-protected edit request on 10 June 2023

Hi there!

I'd like to add additional incantations to the deprecated-value checks for "his/her death". The usage report for the template shows these values in-use, and it would be nice to have the deprecation categories also show these oddly phrased values.

There are 2 instances of the following; both #switch statements should be updated for both of these edits:

1. Change his death to his d. | his death in both places

2. Change her death to she d. | her death in both places

This was tested out in the Sandbox #2 for reference: Template:Marriage/sandbox2

Best, Pedantical (talk) 02:54, 10 June 2023 (UTC)

 Done Izno (talk) 00:40, 17 June 2023 (UTC)

Template-protected edit request on 21 June 2023

Hello!

I would like to expand a few more deprecated-value checks for "his/her death" (e.g., saying "his death" when the article's subject is known to be male per Wikidata attributes). The usage report for the template shows these values in-use, and it would be nice to have the deprecation categories also show these oddly phrased values.

There are 2 instances of the following; both #switch statements should be updated for both of these edits:

1. Add he d. and he died into both switch statements' list of options

2. Add her d. and she died into both switch statements' list of options

I've made the changes in Template:Marriage/sandbox2 for reference.

Thanks! :) Pedantical (talk) 21:29, 21 June 2023 (UTC)

 Completed. P.I. Ellsworth , ed. ^{put'er there} 22:43, 21 June 2023 (UTC)

Template-protected edit request on 19 July 2023

The #invoke:Parameter Validation validation has been working nicely for some time to handle unknown parameters (amongst other checks). Having let that settle in for a while, I think it would be reasonable now to remove the redundant invoking of "Check for unknown parameters" from the main template.

This can be accomplished by removing/deleting the entirety of the following from the main template:

{{#invoke:Check for unknown parameters|check|unknown={{main other|[[Category:Marriage template errors|U{{PAGENAME}}]]}}|preview=Page using [[Template:Marriage]] with unknown parameter "_VALUE_"|ignoreblank=y| 1 | 2 | 3 | 4 | end | reason }}

Nothing else should be put in its place, just removal of the entire #invoke:Check for unknown parameters... function.

Thanks!

– Pedantical (talk) 04:26, 19 July 2023 (UTC)

 Completed. P.I. Ellsworth , ed. ^{put'er there} 08:40, 19 July 2023 (UTC)

Lua conversion

I think this template should be converted into Lua. What do you guys think? RMXY (talk) 01:50, 16 September 2023 (UTC)

I think that's a good idea. I would do it myself but I'm not that familiar with Lua. ‑‑Neveselbert (talk · contribs · email) 14:52, 16 September 2023 (UTC)

@RapMonstaXY, I would be up for rewriting this as a Lua module. I've been mulling it over for months now and haven't gotten around to trying it out.

I think it would make it so much easier to implement some of the more cumbersome tidbits.

Is this something you're interested in working on in some capacity as well? Pedantical (talk) 02:13, 22 October 2023 (UTC)

I'm gonna help too... Will you teach me? RMXY (talk • contribs) 05:32, 22 October 2023 (UTC)

Template-protected edit request on 22 October 2023

I've updated the tracking categories from 3 separate categories into a single category for cleaner tracking.

All tracking items would go in to 'Category:Marriage template errors' and the following 2 categories would then be no longer used:

- Category:Marriage template deprecations‎

- Category:Marriage template anomalies‎

If this change is approved and implemented, I'll go back to the primary tracking category and update the sort keys and the documentation (I've got a list of the updated sort keys on my end so that would be a pretty quick edit), and then I'll go set the unused categories in motion to be deleted smoothly.

I'll also go update the Template:Marriage docs page to clean up the categories listed there too.

I think this is a small but helpful change in continuing to clean up the template bit by bit. It also feels fitting since the three separate categories were once totally justified given their previous size, but they're pretty well maintained now, so clumping the anomalies and deprecations into a single place will just help with continued maintenance.

To implement: you should be able to just copy/paste the sandbox template over (except for the very first line with the Template Styles CSS reference to sandbox). The /sandbox page was otherwise identical.

Thanks! Pedantical (talk) 02:10, 22 October 2023 (UTC)

 Completed. P.I. Ellsworth , ed. ^{put'er there} 17:01, 22 October 2023 (UTC)