🇮🇷 Iran Proxy | https://www.wikipedia.org/wiki/Module_talk:Age
Jump to content

Module talk:Age

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

Unify error categories

[edit]

Currently we have 2 categories populated by age templates when there is an issue…

I was going to modify line 33 and retargeted this module to the first (Category:Pages using age template with invalid date) unless there is an important reason for this module to have its own error category… @Johnuniq: any objection? — Zackmann (Talk to me/What I been doing) 05:11, 26 September 2025 (UTC)[reply]

OK. I would like to say that simple is best and the convention of starting category names with "Pages using" is silly (that's literally what a category is), however, I can't stand alone against the tide of business speak so go for it. Johnuniq (talk) 05:47, 26 September 2025 (UTC)[reply]
Hey I feel ya. Hard to fight a rising tide sometimes… —Zackmann (Talk to me/What I been doing) 05:49, 26 September 2025 (UTC)[reply]

Abbreviated dates

[edit]

At a current TFD an error was raised about {{death date and age}}. The issue is that abbreviated months are replaced with the full name.

  • {{death date and age|3 Oct 2025|5 Dec 1990}} → October 3, 2025(2025-10-03) (aged 34) (should be: Oct. 3, 2025...)

Per MOS:DATE abbreviated date are allowed. Would be ideal if this template didn't force the longer form when the short form is provided.

I will also say that when you supply a df date like this, it would be great if it auto-detected that it should display in df format but that is another issue. Zackmann (Talk to me/What I been doing) 03:11, 9 October 2025 (UTC)[reply]

Merging complex stuff that has been used for years is very hard. The whole point of Module:Date and Module:Age was to provide reliable and consistent results. It seems that {{death date and age text}} accepts dates like "3 Octo 2025" and outputs the same. Is that really desirable? At any rate, there is no provision currently in {{death date and age}} to detect that an abbreviated month name was entered and therefore is wanted in the output. I don't think that "and therefore is wanted in the output" should be assumed. Just because someone entered (or pasted) "3 Oct 2025" doesn't mean that they want that as the output. The date is sometimes entered as |2025|10|3 or 2025-10-03 and those are definitely not wanted. The template is used 480,000 times and a lot of investigation and discussion notification would need to occur before changing such a fundamental way it works. A quick look at the doc for {{death date and age text}} suggests it has other features that {{death date and age}} does not have. Have they been raised at the TfD? Is it known whether they are used? Johnuniq (talk) 04:43, 9 October 2025 (UTC)[reply]
@Johnuniq: Merging complex stuff that has been used for years is very hard. Understatement... No but seriously, you make a very good point. I am making an assumption there. A few things I will say though.
  1. I don't think 3 Octo 2025 should output 3 Octo 2025. I have NEVER seen anyone abbreviate October Octo. I would say that should be considered an invalid date. But I think following the same date formats that Module:Date#L-570 spells out would make sense. I.E. October, Oct & Oct..
  2. Perhaps a better solution is to allow for an extra param following the |df=yes format. What if we did |abbr=yes I think that would be MUCH easier to implement and would require far less overhead. Additionally since it is adding a new parameter and only affecting outputs with that new parameter set, it shouldn't change any existing transclusions. I'll take a stab at implementing that in the sandbox.
  3. I do think that detecting the format (df vs mf) and respecting that if the date is entered in a string (I.E. 12 April 2010 vs April 12, 2010). I just cannot think of a situation where you would input a df string and be disappointed that you got a df string back (or an mf string and got an mf string). Plus if for some reason you did want to input a df string and have it output as an mf, you can always do |mf=yes which I think should still override the input format.
I'll take a stab at implementing #2 in the sandbox. What are your thoughts on #3? -- Zackmann (Talk to me/What I been doing) 05:36, 9 October 2025 (UTC)[reply]
@Johnuniq: ok so before I start I figured I better add some testcases... But I'm clearly doing something wrong...
  • {{death date and age|5 January 1990|6 July 1985}}→January 5, 1990(1990-01-05) (aged 4)
  • {{#invoke:age|death_date_and_age|5 January 1990|6 July 1985}}→Error: Need valid death date (first date): year, month, day
What am I missing... I'm sure it is something really obvious that will result in a facepalm... Zackmann (Talk to me/What I been doing) 05:55, 9 October 2025 (UTC)[reply]
Editing Template:Death date and age shows that it passes a parameter in the frame args to Module:Age. That is how the module determines what function is wanted. The user input parameters have to be in the parent frame args. That is, you can't invoke it, you have to use the template. Last I looked, the sandbox template invokes the sandbox module. My point about "Octo" is that only a deep investigation of the wikitext used in articles would reveal what is used. Before thinking about the modules, it might better to ask at a MOS talk page about what should occur. I saw a comment in the TfD asserting that "Oct" was sometimes desirable, but is that true? What examples show that? How many of them are there? Johnuniq (talk) 06:06, 9 October 2025 (UTC)[reply]
@Fourthords: you were the one who raised the issue at the TFD. can you shed some light on Johnuniq's comments above? Do you have any examples where the abbreviated form is preferred or is this more of a hypothetical (both are valid, just curious)?
@Johnuniq: I do think that is should be supported. MOS:DATE specifically says that abbreviated months at For use in tables, infoboxes, references, etc. Only certain citation styles use abbreviated date formats. By default, Wikipedia does not abbreviate dates. My read of that is that it is allowed, so if it is allowed, then I think {{Bda}} and {{Dda}} should support it in some fashion. Whether that is by parsing the input and detecting if an abbreviation is provided (obviously more complicated to implement) or by specifying that you want the abbreviated format (via something like |abbr=yes). Help me get where you are coming from. What is the downside you are seeing to allowing this? -- Zackmann (Talk to me/What I been doing) 06:54, 9 October 2025 (UTC)[reply]
When Module:Age first appeared, there were dozens of errors due to broken dates. I fixed many of them by writing things like "1 Feb 1980" knowing that "Feb" would be recognized and translated to the standard output, and that "February 1, 1980" would be used if required. At any rate, this talk page is the wrong place to discuss whether a fundamental way that a template works should be changed. Let's wait to see a list of at least half a dozen articles where abbreviated names are clearly desirable. If the examples show a need, then start a discussion about whether the change should occur. After that, discuss how (copy input format; new parameter; or something else). That should happen somewhere else, with a meaningful notification to the relevant MOS people. Johnuniq (talk) 07:18, 9 October 2025 (UTC)[reply]
Sounds good! Appreciate the advice and information. You obviously know more of the history here and have a better view of things so I appreciate your advice and perspective. - Zackmann (Talk to me/What I been doing) 07:23, 9 October 2025 (UTC)[reply]

Test cases

[edit]
Moved from User talk:Johnuniq § Module:Age testcases

So regardless of if any changes are made to Module:Age per the current discussion, I do think it would be beneficial to have some Module:UnitTests for the module. I found that with a tiny change to the module I can call the functions directly which will allow the unit tests to function. Can you review it and merge it if it looks good? Here is the comparison. I followed the format I have seen in many other Modules. Zackmann (Talk to me/What I been doing) 07:35, 9 October 2025 (UTC)[reply]

Now this is a discussion that should be on the module talk page! Please don't reply here but I'm slow and methodical and would need quite a bit of time to ponder the fact that the frame args are referred to in several different places. Johnuniq (talk) 08:43, 9 October 2025 (UTC)[reply]
@Johnuniq: Facepalm Facepalm . Moved the discussion. Let me know if you have any questions! --Zackmann (Talk to me/What I been doing) 09:16, 9 October 2025 (UTC)[reply]
I'm occupied elsewhere at the moment. Have you thought about my "ponder" point above? I haven't thought about whether that needs thought. Johnuniq (talk) 09:19, 9 October 2025 (UTC)[reply]
I will ponder whilst you figure out if pondering is needed... Obviously no rush on this. Get to it when you can. If/when it is merged, I will start making testcases. Zackmann (Talk to me/What I been doing) 09:21, 9 October 2025 (UTC)[reply]
@Zackmann08: See my edit at Module:Age/testcases. Why not call the templates? Johnuniq (talk) 08:15, 11 October 2025 (UTC)[reply]
Because...... Looking for witty retort... Error 404. Honestly because I didn't think of that or realize that was doable. I see no reason that shouldn't work just fine. I'll do that. Zackmann (Talk to me/What I been doing) 08:18, 11 October 2025 (UTC)[reply]

Updating df/mf syntax

[edit]

Per this tfd I have refactored the module's code for {{dda}} and {{bda}} so that they will respect the format of the input date. To be clear:

  • The change is that if you supply a date in df format, the result will ALSO be in df format (without you needing to specify |df=yes)
    • In other words, with my change: {{bda|2 May 1990}} → (1990-05-02) 2 May 1990 (age 35)
    • Prior to my change the date would be converted to mf by default: {{bda|2 May 1990}} → (1990-05-02) May 2, 1990 (age 35)
  • |mf= & |df= still work as before and will override the default behavior

The code diff can be see here.

Zackmann (Talk to me/What I been doing) 06:30, 5 December 2025 (UTC)[reply]

As in above sections, these templates are used in many places and it's hard to know what the effect of a change like this would be. I suppose that if no df or mf parameters are used, it's reasonable to assume that someone expected the output format to follow the input. I'll think about it over the next couple of days and will have a look at on old article dump download to see if any problems emerge. Please remind me if I haven't posted by next Tuesday. Johnuniq (talk) 06:56, 5 December 2025 (UTC)[reply]
@Johnuniq: to be clear, didn't mean to overrule you or anything. Kind forgot about the above discussion. I certainly want you to give this a good look over. A few thoughts:
  • Primary concern is that nothing truly break. I.E. Someone inputs 1 date and gets a completely different date or an error. That is priority number 1.
  • As you hinted at above, I cannot fathom a case where someone would supply a day-first date and then be disappointed that they got a day-first date back. (Note that |mf= & |df= still work as previous)
  • Assuming I haven't missed anything, the way I see it, the WORST case scenario is that someone is confused why all of a sudden the date that was displaying (for example) December 4, 2025 is now saying 4 December 2025...
    • In that case, I would assume the first they would do is look at the code and see "oh, the code is written df, so that is probably why it is displaying df...
  • Note that this change ONLY affects the {{dda}} & {{bda}} functions.
Think that is it for now. If you have questions, comments or concerns absolutely let me know! Cheers. Zackmann (Talk to me/What I been doing) 07:03, 5 December 2025 (UTC)[reply]
I'm not disagreeing. An unfortunately large slice of experience means that I have seen many cases where thorough investigation revealed issues that were not apparent at first. Johnuniq (talk) 07:13, 5 December 2025 (UTC)[reply]
Sounds great. appreciate your insight. Zackmann (Talk to me/What I been doing) 07:21, 5 December 2025 (UTC)[reply]

I have started looking at the changes. They are good but I haven't done my full check of results yet. Meanwhile, here are some differences to think about.

  • {{Birth date and age|2001|4|1}} → (2001-04-01) April 1, 2001 (age 24)
  • {{Birth date and age/sandbox|2001|4|1}} → (2001-04-01) 1 April 2001 (age 24)
  • {{Birth date and age|year=2001|month=4|day=1}} → (2001-04-01) April 1, 2001 (age 24)
  • {{Birth date and age/sandbox|year=2001|month=4|day=1}} → (2001-04-01) 1 April 2001 (age 24)
  • {{Death date and age|2005|4|12|2000|4|13}} → April 12, 2005(2005-04-12) (aged 4)
  • {{Death date and age/sandbox|2005|4|12|2000|4|13}} → 12 April 2005(2005-04-12) (aged 4)

More in a day or two. Johnuniq (talk) 06:03, 6 December 2025 (UTC)[reply]

So I literally JUST came across that a few minutes ago when reviewing the testcases. That was not an intended change. Without any investigation, my guess is that Module:Date defaults to 'df' when constructing a date in that format... Not certain and will investigate further. I will fix that as those should not be changing. - Zackmann (Talk to me/What I been doing) 06:19, 6 December 2025 (UTC)[reply]
It will just be some logic twist in Module:Age due to the input date format being ymd. I will look later. Johnuniq (talk) 06:21, 6 December 2025 (UTC)[reply]
If you get to it before me, awesome! But I'm happy to unpack it tomorrow. Too late on a Friday night my time to start down this rabbit hole. - Zackmann (Talk to me/What I been doing) 06:23, 6 December 2025 (UTC)[reply]
@Johnuniq: so I'm stuck. The issue seems to lie in the if loop starting at Line 660. When you construct a date with Date(...,y,m,d) then d.format will be 'dmy'. Since .format is read-only, there is no 'setter' to override that. Not sure what the best solution is... I guess we could change the formatting so that instead of constructing the date in 'ymd' it constructs it in 'mdy', but that seems like a sizable refactor. Maybe the easier solution is to refactor Module:Date to allow you to set the value for the format associate with a specific instance of a date? Off hand that seems like it would require less code changes and therefore be less risky overall? Open to your thoughts and suggestions. Zackmann (Talk to me/What I been doing) 19:14, 6 December 2025 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Module_talk:Age&oldid=1326039932"