Template talk:Use dmy dates/Archive 2
This is an archive of past discussions about Template:Use dmy dates. 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 |
"date=": parameter meaning drifted
I noticed that a script (User:Ohconfucius/script/MOSNUM dates) is correcting date formats throughout articles and adding this template ({Use dmy dates}) with a "date=" parameter. (All okay.) But where this template was already present (with a "date=" parameter), that script changes the "date=" parameter! (See example.) I thought the script was malfunctioning. To my shock, I discovered that the script follows the current instructions for this template: Use the parameter
What the heck? All along, it seemed quite clear that for maintenance templates, "date=" gives the date that the template was added to the article. Reenforcing that view, if someone adds this template (and many others) without "date=", a bot will soon automatically add the missing "date=". But now this template's instructions come along and tell users to change "date=" whenever date formats are corrected, giving the parameter a totally different meaning (and effectively adding a specific technical requirement for even adding this template). Is there no fundamental guideline to tell the techno-mages who design templates that the "date=" field is static and records the date that the template was added; and, if they want a dynamic field that "tracks the last time an advisory style template was enforced", they must never call it "date=", and must call it anything else, such as "enforced-date=" or "checked-date="? (Or else redefine everywhere what "date=" means. (And keep going with the vagueries and vagaries of "access-date", etc.)) Instructing editors to change "date=" disagrees with replies to "Can you (i.e., we editors) update the date?" above → Wikipedia talk:Template messages#Can you update the date?. Wikipedia backstage is looking like "anything goes". Finally, who even cares about the last date that change(s) were made to enforce that every date complies with the specified date-format? - A876 (talk) 19:46, 23 December 2019 (UTC)
!date=
for the month and year that an editor or bot last checked the article for inconsistent date formatting and fixed any found.
Oops. This topic was discussed back in 2015. Editors proposed either adding a parameter ("last-checked=" or "last-updated=") for the bots, or restoring the field to mean only the date the template was added. Somehow that discussion stalled. One highlight there was this: "I see no reason to know the original date of tagging if a bot has since revisited the article. After all, that is the only reason we have the date parameter at all, to help understand which articles need to be revisited most urgently."
To which I must reply: {Use dmy dates} is first-of-all an instruction to human editors. The field "date=" preserves the date of addition, to inform human editors of the date that the template was added, so that they may casually see that date without having to search History to uncover it. There is no grounds for changing the value of "date=". "date=" should never have been redefined or repurposed. The distasteful repurposing was actually discontinued (and documented so) in 2011.
If "date=" were redefined to track the last date that a bot reviewed date-formats on the page, such reviews, when no change is made, would generate millions of useless edits, so that idea is basically unthinkable. (Besides, a sensible bot would track the dates of its own visits on the side (out-of-band), not on the page (in-band).)
If "date=" were redefined to track the last date that a bot reviewed date-formats on the page and made changes, that would reduce the value of the field to any bot, because every "flawless" page would keep its older date. This variation was followed until 2011, but with a modification. This template plus its "date=" parameter automatically place the page in a hidden monthly category, such as Category:Use dmy dates from August 2010. August 2010 is the earliest monthly category, so August 2010 is the earliest value attached to "date=". The August 2010 page was created on 2010-08-23. But why is August 2010 the oldest? See the previous month, Category:Use dmy dates from July 2010: It was deleted on 2011-12-06 because "it is a monthly clean-up category that has been emptied". Until 2011, someone actually emptied out the old monthly categories, such as July 2010! They could not have deleted the {Use dmy dates} from the pages – DMY is a permanent designation. So a final round of reviews must have updated the articles' "date=" parameter to December 2011 (or whenever they ran it), even if no dates were reformatted. That sounds profoundly stupid. Every DMY article that did not need any dates reformatted got edited anyway, every 12 months, merely to advance the "date=" parameter by 12 months. But that absurd process stopped eight years ago. These are no longer "monthly clean-up categories". No one "empties" these categories any more (except July 2010 and before). Some nonsense followed, for many of the monthly categories. For example, after [Category:Use dmy dates from July 2010] was deleted on 2011-12-06, some articles must have had "date=July 2010" put back in, thereby re-creating that deleted category. It happened on at least 6 articles, because [Category:Use dmy dates from July 2010] was deleted 6 more times: 2012-05-20, 2013-05-20, 2014-08-28, 2016-02-06, 2017-04-23, and 2018-11-29. The oldest deleted monthly category seems to be Category:Use dmy dates from January 2004 (first deleted 2017-06-06). Each deleted monthly category was deleted 1 to 6 times (possibly more). However, Category:Use dmy dates from January 2008 was present today: it was first deleted 2014-02-03; re-created 2019-12-21 (seen empty and tagged for deletion); and re-deleted 2019-12-23. (I found it because it was the first subcategory under Category:Use dmy dates.)
Using this parameter for cleanup might contradict instructions shown at Category:Use dmy dates from December 2019 (and all similar), because this template is not for cleanup! Each monthly category says Wikipedia articles (tagged in this month) that use dd mm yyyy date formats, whether by application of the first main contributor rule or by virtue of close national ties to the subject belong in this category. Use {Use dmy dates} to add an article to this category. See Wikipedia:MOSNUM.
(Since 2011-01-08!) (That instruction is vague - "not for cleanup" might just mean "don't delete this template after finding or making the article compliant with it.")
This system of tagging or categorisation is used as a status monitor of all articles that use dd mm yyyy date formats, and not as a clean up.
Because "date=" does not track the date of the last review unless changes are made AND "date=" is no longer bumped annually to reflect annual reviews with no changes, (and it does not know the number of edits since), the "date=" of {Use dmy dates} does not really "help [us] understand which articles need to be revisited most urgently"; at least not since 2011. The "date=" field is in a mixed state now; it is being updated for no good reason. "date=" has no value to any bot or script, because the bot or script has already selected the page (possibly from a monthly category containing it) and retrieved the entire contents of the page, and will analyze it regardless of the "date=" value. No human will ever change this field. No bot should ever change this field. It is time to stop updating a field that should never have been updated. - A876 (talk) 22:16, 23 December 2019 (UTC)
- This is indeed a maintenance template, and the date change at each update is part of the design of the page-maintenance procedure. You see, this template is an embedded template that is unlike {{NPOV}}, which will be removed once the underlying issue has been resolved, so it makes sense for that datestamp remains unchanged. Not this one. Why should you be shocked when something is working according to the documentation? There is no universal definition of any given parameter, so that each template will have their own definitions. It's a bit of a pain for me to navigate this too with my different scripts for reasons I won't go into here, but I make do with it as I can. Until the vast majority of articles (or, say, >90%) are tagged, there will be relatively small movement within the categories, but the idea is that they will be revisited at some point, when the timestamp will be updated. As to the emptied categories: I, or one or more other editors, may have started pruning the categories a while ago, probably because of the small number of articles in each, to reduce the number of categories. Articles get expanded, and new dates are added. Not all will be inserted in the correct format, and therefore have to be corrected at some point. There's currently no way of knowing whether there are any newly-added dates in the older tagged articles, but age since last update is probably the best indicator. Notwithstanding, another editor may get a bot started on the backlog, but I currently have no time to do this. -- Ohc ¡digame! 23:36, 25 December 2019 (UTC)
- As remarked above this is an ongoing process some of us have been working on for over a decade. It is currently a mostly manual effort, because there are so many potential exceptions to the nominated order - titles, quotes, place names (named after famous dates, usually streets named after revolutions), events (notably 4 July in some US contexts) and organizations - not to mention the infamous Long March 2 rocket. All the best: Rich Farmbrough (the apparently calm and reasonable) 08:38, 16 March 2020 (UTC).
- As remarked above this is an ongoing process some of us have been working on for over a decade. It is currently a mostly manual effort, because there are so many potential exceptions to the nominated order - titles, quotes, place names (named after famous dates, usually streets named after revolutions), events (notably 4 July in some US contexts) and organizations - not to mention the infamous Long March 2 rocket. All the best: Rich Farmbrough (the apparently calm and reasonable) 08:38, 16 March 2020 (UTC).
There is no universal definition of any given parameter, so [] each template will have [its] own definitions.
But lack of a "universal definition" does not oblige using the same word in different ways. Using "date=" two different ways is bad form, an anti-pattern. Agreed, {Use dmy dates} doesn't track its added-date, therefore&because it doesn't display any message when viewing. (It is a visible note to editors who edit in markup; most visible if it is placed at the top of the markup as-recommended.) This parameter should not have been named "date=", because it is not the preserved added-date (as it is in other templates). My suggestion reduces to this: Select a new parameter for this function (e.g. "not-verified-since=") that hints at its different function. Document that it is the preferred parameter, and that "date=" is a deprecated alias. (Optionally, the deprecated alias could be replaced by bots incidental to other edits.) Next, adjust the dater-bot (I assume a bot checks this template) to use the new parameter. The use of a dater-bot for this parameter has a serious weakness: When someone adds {Use dmy dates} without changing or even verifying any of the dates, how can you justify filling the field with added-date? I think I reduced this problem just now when I suggested naming the parameter "not-verified-since=", because that is what it really describes. If that is the understood meaning of the parameter, it is legitimate to initialize it with the added-date. After that, people (occasionally) or bots (maybe someday) can bump the date whenever they verify the date format throughout; after that, every subsequent edit potentially puts the article out of compliance. (With that comes a feeling that the parameter should include the "full" date, not just month and year.) Maybe that's too utopian, I don't know. That's the choice, rename the parameter to reflect its actual meaning ("not-verified-since=") and allow full date, or else just leave it as "date=". - A876 (talk) 11:10, 6 April 2020 (UTC)
Against consensus
Why does the use of this template cause access and archive dates in citation to change from "YYYY-MM-DD" to "D M Y"? MOS:DATEUNIFY clearly allows these dates to have "YYYY-MM-DD" formats regardless of the consistent formatting of all other dates. Until the template stops doing this, I am forced to revert its addition wherever I see it changing displayed access and archive date formats. Peter coxhead (talk) 08:59, 4 February 2020 (UTC)
- This template does nothing. Are you asking about what cs1|2 does when it finds
{{use dmy dates}}
? cs1|2 renders all dates in a cs1|2 template according to the{{use dmy dates}}
template. When unqualified, all dates are dmy. You can set|cs1-dates=
to have Module:Citation/CS1 format publication and archive/access dates in different formats. For example, to get publication dates in dmy format (6 November 2024) and archive/access dates in ymd format (2024-11-06) write:{{use dmy dates|cs1-dates=ly}}
- See Template:Use dmy dates § Auto-formatting citation template dates.
- —Trappist the monk (talk) 12:20, 4 February 2020 (UTC)
- This template (without
|cs1-dates=
) is being added to articles which have perfectly consistent dates, thereby forcing access and archive dates into a different style, contrary to clear consensus. The onus is not on me to alter the template, but on the editor who added it to respect existing citation styles, as they are required to do. (It would be better if cs1|2 didn't alter access and archive dates in this way, but that's another matter.) Peter coxhead (talk) 13:01, 4 February 2020 (UTC)- You are entirely correct. The editor placing this template is required to respect a clearly consistent, existing citation-date-style or to obtain consensus at the article's talk page to change citation-date-style to another style. That is the goal; whether or not that happens depends on those editors actually reading and understanding the template's documentation, depends on those editors actually evaluating the article's existing style – alas, they hardly ever do ...
- You might write an awb script that will add
{{use dmy dates|cs1-dates=ly}}
to the articles that you maintain as a preventative against drive-by editors who improperly add this template. - —Trappist the monk (talk) 14:11, 4 February 2020 (UTC)
- @Peter coxhead and Trappist the monk: There are two questions here that we mustn't conflate: 1/ placing of the template to indicate the correct date format for the date per WP:TIES – there's been consensus of long date. 2/ Autoformatting – this is merely a display option that's considerably more recent, made possible by our tagging of articles.
As none of the underlying date formats are necessarily changed, I don't think it violates WP:RETAIN. OTOH, removing
-- Ohc ¡digame! 14:35, 4 February 2020 (UTC){{use dmy dates}}
templates is certainly non-consensual, and is arguably WP:VANDALISM. Please don't blame editors placing the template on articles. I dislike this passing of the buck because editors placing the templates have little or nothing to do with the problem you describe. Having said that, Autoformatting ensures WP:CONSISTENCY (only on the surface, because it can hide a multitude of sins that lie underneath), but I really had no say in its implementation. It now seems to be done and dusted as an issue, but it can always be re-opened if you feel the need.- I agree that placing this template does not change the underlying dates. It does, however, change the rendered appearance of the page when the editor adding the template does not respect the pre-existing citation-date-style. Editor Peter coxhead's complaint suggests that prior to the addition of this template, citation-date-style consistently used dmy date format for publication dates and used ymd date format for access and archive dates. The editor who added this template apparently ignored that consistency so that now the access and archive dates are rendered in dmy format. Ignoring a consistent style when adding this template is just as much 'WP:VANDALISM' as removing this template is WP:VANDALISM.
Autoformatting ensures WP:CONSISTENCY (only on the surface, because it can hide a multitude of sins that lie underneath)...
What sins? Can you show me some place where these sins are hidden? Are there cases where these hidden sins are causing problems?- —Trappist the monk (talk) 15:29, 4 February 2020 (UTC)
- To avoid potential conflict, I already avoid running the script or place the template on articles maintained in the manner described, but other editors might indeed be unaware. The "sins" I referred to is the fact that parameters may contain dates of all formats, which are only visible in edit mode because they are interpreted in display mode according to the template placed. -- Ohc ¡digame! 15:42, 4 February 2020 (UTC)
...parameters may contain dates of all formats...
. That is no sin. As long as whatever format an editor used in a cs1|2 template has a valid format according to MOS:DATEFORMAT (qualified by Help:Citation Style 1 § Date compliance with Wikipedia's Manual of Style), the reader-facing citation dates will all render as directed by this template. If there are any dates in a cs1|2 template that do not comply with the format standards, cs1|2 will emit an error message and will not auto-format that template's dates. Dates in the cs1|2 template's wiki-text do not need to have the same format; dates in the article body, yes, dates in the cs1|2 templates, no. Unless you have removed it, code has been added to your script that preserves|cs1-dates=
when your script is run on an article that has this template with that parameter.- —Trappist the monk (talk) 16:30, 4 February 2020 (UTC)
- The problem is that editors will, quite reasonably, look at surrounding text to determine which style is in use. All the best: Rich Farmbrough (the apparently calm and reasonable) 08:41, 16 March 2020 (UTC).
- It's reasonable to look at the text to determine which style is use in the text. It's not reasonable, and clearly against existing policies and guidelines, to use the text to impose the same format on already consistent and conforming dates in citations. The effect is yet another (but this time under cover) attack on the use of yyyy-mm-dd dates in access and archive dates. This should stop. Peter coxhead (talk) 08:49, 16 March 2020 (UTC)
- I completely agree. This template should not be added to articles which consistently use numeric accessdates. —David Eppstein (talk) 16:23, 16 March 2020 (UTC)
- Or, if it is, than the
|cs1-dates=y
parameter must be given as well. And it is high time, that bots and scripts actually adhere to the|cs1-dates=y
parameter - unfortunately, the reality more than a year after the introduction of auto-date formating is that a lot of bots and scripts still ignore the parameter and rewrite dates in citations according to the {{Use dmy dates}}/{{Use mdy dates}} template names, which is against our guidelines. As User:Peter coxhead already pointed out, this causes articles, which previously used consistent YMD dates in citations, to be changed to DMY or MDY format over time, and after a while, some editors will even start to edit-war when other editors try to change the citation dates back to YMD format (I have seen that happening in many articles). Effectively, the auto-date formating this therefore indirectly (and probably unintended by the original developer) causing the eradiction of the YMD format from many articles, while, I think, it should be even more endorsed than it already is (for its many advantages). - As a counter-measure against this unintended damage to use of the YMD format, we could
- declare that the default format to be used by editors, scripts and bots for citations in articles using {{Use dmy dates}}/{{Use mdy dates}} without
|cs1-dates=
parameter is YMD (rather than DMY or MDY), and possibly even extend this to articles without {{Use dmy dates}}/{{Use mdy dates}} at all - disable auto-formatting in cs1/cs2 citation templates when they encounter {{Use dmy dates}}/{{Use mdy dates}} without
|cs1-dates=
parameter. Soon or later the parameter will be added (adhering to the existing format used in citations), and auto-formatting will resume. - block scripts and bots still not adhering to the
|cs1-dates=
parameter. More than a year after its introduction everyone should have had enough time to update their scripts and bots.
- declare that the default format to be used by editors, scripts and bots for citations in articles using {{Use dmy dates}}/{{Use mdy dates}} without
- --Matthiaspaul (talk) 18:22, 8 June 2020 (UTC)
- Or, if it is, than the
- I'm not making the case in respect of yyyy-mm-dd, though I failed to draw the distinction. I am happy with any article using yyyy-mm-dd for access dates, or even mixing yyyy-mm-dd and dmy/mdy for access dates (sacrilege!). Despite two editors claiming years ago that yyyy-mm-dd was a mysterious format that they could not understand, I see no significant problem with it for access dates. I agree with the substantive point: User:Peter coxhead made in his original post.
- My point was to some extent allied with Peter's, that an editor seeing dmy or mdy in source citations (or anywhere else auto-formatted), would assume that this was correct for the article as a whole, despite it being potentially the opposite. The auto-formatting has an appeal, I understand, but it's not a net positive IMHO. It's better to actually fix the format as applicable.
- All the best: Rich Farmbrough (the apparently calm and reasonable) 13:08, 24 March 2020 (UTC).
- I completely agree. This template should not be added to articles which consistently use numeric accessdates. —David Eppstein (talk) 16:23, 16 March 2020 (UTC)
- It's reasonable to look at the text to determine which style is use in the text. It's not reasonable, and clearly against existing policies and guidelines, to use the text to impose the same format on already consistent and conforming dates in citations. The effect is yet another (but this time under cover) attack on the use of yyyy-mm-dd dates in access and archive dates. This should stop. Peter coxhead (talk) 08:49, 16 March 2020 (UTC)
- The problem is that editors will, quite reasonably, look at surrounding text to determine which style is in use. All the best: Rich Farmbrough (the apparently calm and reasonable) 08:41, 16 March 2020 (UTC).
- To avoid potential conflict, I already avoid running the script or place the template on articles maintained in the manner described, but other editors might indeed be unaware. The "sins" I referred to is the fact that parameters may contain dates of all formats, which are only visible in edit mode because they are interpreted in display mode according to the template placed. -- Ohc ¡digame! 15:42, 4 February 2020 (UTC)
- @Peter coxhead and Trappist the monk: There are two questions here that we mustn't conflate: 1/ placing of the template to indicate the correct date format for the date per WP:TIES – there's been consensus of long date. 2/ Autoformatting – this is merely a display option that's considerably more recent, made possible by our tagging of articles.
- This template (without
Is there a template that causes date formats to display as dmy but stops scripts from changing it?
I would like my wikitext to be consistent and re-use citations between different articles. I use ISO dates in all my citation templates as they make the most sense to me. It is probably better for them to be displayed in the same way as the rest of the article, but if I add a {{use dmy dates}} or {{use mdy dates}} (I use either, depending on the topic) some people running scripts will change all of my citation wikicode. Do I have to stop using the templates or is there a different way of keeping my citation wikitext consistent? —Kusma (talk) 10:59, 24 June 2021 (UTC)
- It's not your citation. Once you put it in an article it belongs to the Wikipedia community. Jc3s5h (talk) 14:18, 24 June 2021 (UTC)
- Whilst of late, some editors seem to be insisting that date formats within citation templates should not to be changed once a dmy/mdy template is in place (simply because the Mediawiki software does all the work), there is no reason why they MUST NOT be changed by any editor running a script (or even manually, for that matter) except that such changes could be considered unwelcome because they are "inconsequential edits". Whilst I would agree that dates hidden in plain sight look tidier if they are all the same format, it is often necessary to make them uniform in edit mode because there are probably quite a few instances in Wikiverse where templates are not used for citation. Even if you insert yyyy-mm-dd dates (no, we don't use ISO dates here on WP), dates will display as directed by the template if there is a {{use dmy dates}} or {{use mdy dates}} template.
- Yes, we can and do use ISO dates in citations for access and archive dates, and editors adding the "use xxx dates" templates should respect existing citation formats where these formats are in the majority by adding
|cs1-dates=ly
. All too often they do not. Peter coxhead (talk) 10:11, 13 October 2021 (UTC)- I meant that yyyy-mm-dd dates are not entirely synonymous with ISO dates, and thus the former are not used here on WP -- Ohc revolution of our times 15:15, 14 October 2021 (UTC)
- Yes, we can and do use ISO dates in citations for access and archive dates, and editors adding the "use xxx dates" templates should respect existing citation formats where these formats are in the majority by adding
- Whilst of late, some editors seem to be insisting that date formats within citation templates should not to be changed once a dmy/mdy template is in place (simply because the Mediawiki software does all the work), there is no reason why they MUST NOT be changed by any editor running a script (or even manually, for that matter) except that such changes could be considered unwelcome because they are "inconsequential edits". Whilst I would agree that dates hidden in plain sight look tidier if they are all the same format, it is often necessary to make them uniform in edit mode because there are probably quite a few instances in Wikiverse where templates are not used for citation. Even if you insert yyyy-mm-dd dates (no, we don't use ISO dates here on WP), dates will display as directed by the template if there is a {{use dmy dates}} or {{use mdy dates}} template.