Misplaced Pages

User talk:Ohconfucius/script/MOSNUM dates

Article snapshot taken from Wikipedia with creative commons attribution-sharealike license. Give it a read and then ask your questions in the chat. We can research this topic together.
< User talk:Ohconfucius | script

This is an old revision of this page, as edited by Ohconfucius (talk | contribs) at 20:05, 16 June 2024 (→Affecting references: fixed). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

Revision as of 20:05, 16 June 2024 by Ohconfucius (talk | contribs) (→Affecting references: fixed)(diff) ← Previous revision | Latest revision (diff) | Newer revision → (diff)

Apologies

I'm sorry for not having seen the posts to this, as I was not aware of its existence. -- Ohc ¿que pasa? 02:18, 6 July 2013 (UTC)

Is your script responsible?

This script is being run by User:Alpha Quadrant, and it has introduced serious errors into at least one page it was run on. I am wondering if this script should be suppressed until it is fixed.

Here is the edit to which I am referring: Scroll down to the bottom. In the Further Reading section, you will see three kinds of errors introduced by this script:

  1. There were seven distinct books before this edit. After your edit, two of the books (by authors Crawford and Schneider) were deleted, and replaced with duplicates of other entries. The revised list still had seven entries, but two of them (authors Andrew and Rusher) appeared twice.
  2. The capitalizion of the book titles was altered (incorrectly).
  3. The old list was an annotated bibliography -- it included the books and a brief description of each book. In this edit, the descriptions were completely deleted.

To be fair, the only reason I believe this script was at fault is because the editor who made this edit stated so in his/her edit description. If he/she was incorrect in so stating, my apologies! — Lawrence King 03:41, 4 December 2011 (UTC)

Ordinal suffixes

"...removes ordinal suffixes and constructions such as '5th of September'," does not seem to be working in this script? Do you know what the problem is? For example, Luke James (footballer) - when I run the script nothing happens. Should it change to 7 January 2012 rather than 7th of January 2012? Thank you JMHamo (talk) 00:19, 27 January 2012 (UTC)

Spacing bug

This script seems to replace every "accessdate = " with "accessdate =" which seems entirely unnecessary and can be unhelpful. It's also hard to identify in a diff. Please fix. • Jesse V. 03:56, 17 September 2012 (UTC)

WP:MOSNUMscript

I am receiving javascript errors when running this script today. Do you know if Misplaced Pages made a change?

Webpage error details

User Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.2; WOW64; Trident/4.0; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; .NET4.0C) Timestamp: Tue, 9 Oct 2012 13:07:37 UTC


Message: Unknown dependency: reftoolbar-base Line: 147 Char: 276 Code: 0 URI: http://bits.wikimedia.org/en.wikipedia.org/load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=monobook&version=20121001T132818Z


Message: 'editbox' is undefined Line: 42 Char: 4 Code: 0 URI: http://meta.wikimedia.org/search/?title=User:Pathoschild/Scripts/Regex_menu_framework.js&action=raw&ctype=text/javascript

Please let me know if it's on my end. Thanks! --Teancum (talk) 13:08, 9 October 2012 (UTC)

File name, ref names, and URLs bug

I'm getting an odd bug with the script this morning; it's replacing all ref names and image names with the symbols "⍌92⍍", and putting it in front of every URL as well. Any idea what I'm doing wrong? Thanks as always for your work on this. -- Khazar2 (talk) 13:18, 30 November 2012 (UTC)

copy the following command:

This section seems to be invisible on my browser - I had to edit to see the command. Parrot of Doom 13:01, 19 April 2013 (UTC)

Updating use template

When I look at an article, I like to know when the template was first applied, not the last time the formats were updated. So rather than changing the |date= parameter in the {{use mdy}} template every time this is run, could you change it so that there's a last_updated parameter if a template is already in place? It should be ignored. Walter Görlitz (talk) 02:30, 23 May 2013 (UTC)

HTTPS

Hi. Please change the "http://" link so that it uses "https://" when the script is called through https. Firefox blocks the https→http call as Mixed Active Content. Thanks. --AVRS (talk) 15:38, 5 July 2013 (UTC)

Script has disappeared

I've been using various of your scripts for some time now - thanks! - but as of today they have all disappeared from my toolbox. They appear still to be listed in vector.js and so this is a mystery to me. Any ideas? What have I done wrong this time? - Sitush (talk) 12:22, 16 August 2013 (UTC)

Sorry, MOSNUM is one of those scripts and I am using Firefox 22.0 on Ubuntu - no change to that setup for quite a while. - Sitush (talk) 12:23, 16 August 2013 (UTC)
Same here. Menu options missing on both Firefox 22.0 and 23.0 on Windows 7. - X201 (talk) 14:39, 16 August 2013 (UTC)
Same here - see Misplaced Pages:Date formattings/script/MOSNUM dates/bugs#Not loading in toolbox. GoingBatty (talk) 21:17, 16 August 2013 (UTC)
Thanks to User:Keith D for fixing this! GoingBatty (talk) 22:07, 18 August 2013 (UTC)

Publication dates vs. archive and access dates

Is there a mode that will convert all dates within the article body and all publication dates within references to dmy (or to mdy) while leaving ymd archive dates and ymd access dates within references untouched (or even allow converting archive and access dates to ymd while making the other previously mentioned changes)?

I would like to see this option made available. It seems the current script is often used to eliminate ymd dates from references, even where it is clear they were intended to be there. - 91.84.77.67 (talk) 21:39, 22 April 2014 (UTC)

Script bug

This edit, where lower-case letters were removed from years in |date=, should not be done by a script. These lower-case letters are valid and used by harv refs to disambiguate two works by the same author published in the same year. Can you please fix the script, if you have not done so already? – Jonesey95 (talk) 03:11, 8 May 2014 (UTC)

Commas after MDY dates

Hi, Ohconfucius! What a handy little script I've stumbled upon. I've just installed it and look forward to trying it out!

One thing I would like to know is whether the script inserts a comma after the year in MDY dates that are not followed by other punctuation, as required by MOS:DATEFORMAT and MOS:COMMA? For example:

  • Original text: The weather on 11 September 2001 was clear and warm.
  • Converted text: The weather on September 11, 2001 was clear and warm.
  • Converted text: The weather on September 11, 2001, was clear and warm.

Or, for that matter, does it remove commas when converting the other way?

  • Original text: The weather on September 11, 2001, was clear and warm.
  • Converted text: The weather on 11 September 2001, was clear and warm.
  • Converted text: The weather on 11 September 2001 was clear and warm.

Otherwise, what is the most efficient way to find such instances to add/remove commas manually as needed? Would this necessitate scrolling through all the wikicode to find the altered dates? Thanks! —sroc 💬 13:33, 11 July 2014 (UTC)

  • Original text: The weather on 11 September 2001 was clear and warm. becomes The weather on September 11, 2001 was clear and warm.
  • Original text: The weather on September 11, 2001, was clear and warm. becomes The weather on 11 September 2001, was clear and warm.
The rule is that it behaves neutrally towards the trailing comma after the year in both cases. In both instances, the trailing comma is wrong. You can check by running the script yourself on the page. However, in my experience, the neutrality renders correctly because the construction you chose above does not seem all that common. Anyhow, it has to be manual because I've never been able to find a surefire way of making the script correctly parse to determine whether the trailing comma can or should be added or taken away. -- Ohc  14:50, 11 July 2014 (UTC)
I suspected as much. That would take an extra-special kind of wizardry, almost enough to pass the Turing test. I seem to spend a lot of my time adding those pesky missing commas! Thanks anyway! —sroc 💬 00:55, 12 July 2014 (UTC)

Thanks, the script is good but could be improved

E.g. I changed:

In February 2012, HP announced

Starting August 8, 2014, but had to add the commas after the years. Unless I'm mistaken they sould be for sentences starting as "In <DATE>," and "On <DATE>," I think I've seen exceptions where DATE is only a year. Maybe for <MONTH YEAR> possible that I don't see but would exceptions at least happen with full dates? If you are concerned about false positives I'v seen them for other cases, but the details escape me at the moment.. I'm always "fixing" minor other stuff such as newlines after titles. Could that also be worked in? comp.arch (talk) 15:02, 3 October 2014 (UTC)

@Comp.arch:The comma after the year in the case of ProLiant wasn't there before the script edit. the script respects neutrality of the trailing comma (see section immediately above), as I have not been able to parse strings to reliably add or remove commas. For the constructions "In <DATE>," and "On <DATE>," the comma is not obligatory in that many editors feel the comma is redundant grammatically, and are offended/irritated by their insertion. So I think it best to leave these unchanged. As to the new lines after titles, could you perhaps give an example? -- Ohc  13:22, 4 October 2014 (UTC)
Yes, I only noticed the previous section afterwards.. It says as I thought and had seen in MOS:DATE that the comma is required "The weather on September 11, 2001, was clear and warm" and "In 2013, Ramadan". In case I'm wrong and "the comma is not obligatory in that many editors feel the comma is redundant grammatically, and are offended/irritated by their insertion" then maybe I should slow down with changing. The MOS says required but links to MOS:COMMA that may not support this however(?) If you want it seems to me however that there are no false positives. It seems to me the comma is always required after the year unless using DMY.
As for the newlines, just look at this talk page as the WikiMedia software adds a newline. You could find many examples in article space. There is nothing wrong in including the newlines. Two would be excessive however and zero before. See the the section I added for more details. comp.arch (talk) 11:49, 6 October 2014 (UTC)
Perhaps I can clarify for Comp.arch.
Both MOS:DATEFORMAT and MOS:COMMA are consistent (and syntactically correct) in stating that a comma is required after the year in month–day–year format dates (hence: The weather on September 11, 2001, was clear and warm). This is because the year is set off by commas in much the same way as you would use a pair of parentheses or a pair of dashes to set off a remark – you need one on either side – except at the end of a sentence. This is not the case in day–month–year format dates (hence: The weather on 11 September 2001 was clear and warm; not: The weather on 11 September 2001, was clear and warm). The difficulty for scripts and bots is that it is rather difficult to automate the insertion or removal of commas after dates when adjusting the date format as a comma might be required for other reasons (e.g., He arrived in New York on 11 September 2001, the morning of the attacks, not He arrived in New York on 11 September 2001 the morning of the attacks).
As Ohconfucius pointed out, there are differing views on whether a comma should follow introductory phrases such as "On , ..." and the like. The example In 2013, Ramadan began on 10 July and ended on 7 August was only intended to show that the year could be omitted from the dates at the end of the sentence, but In 2013 Ramadan began on 10 July and ended on 7 August would also (arguably) be acceptable. Since MOS does not prescribe a preference one way or the other (as far as I know), it is safer for this script to leave well alone. After all, scripts cannot defend themselves against humans who might take offence. —sroc 💬 16:28, 10 December 2014 (UTC)

Month not expanded

Notice the change from "In Jan 2010," to "In January 2010,". The script didn't do that part (it changed however "Jan."). I had to manually fix. Could there be any false positive with a sentence starting with "In Jan 2010," (at least when there is a comma?) etc. comp.arch (talk) 10:04, 9 October 2014 (UTC)

Script changes titles

In my last edit "80’s Brick Cell Phone"->"80s Brick Cell Phone". Note, I catched that and didn't let the change through. I assumed titles in refs are like quotes, sacred. I've also seen "regular dates" in them and I believe the script tried to change. Didn't check the "quote"-part of refs but assume there you would also like to improve the script.

Is the change an error or by design? That is, "quotes" can sometimes be changed and in some cases might (also be spelling errors not originally there..). comp.arch (talk) 11:29, 13 November 2014 (UTC)

Edit summaries

I note that the script uses the edit summary:

date formats per WP:MOSNUM by script

Could this be amended to refer to the more specific section of MOS:

date formats per MOS:DATEFORMAT by script

—sroc 💬 13:33, 10 December 2014 (UTC)

The edition of 4 January 2015 of

Thank-you for such a useful script! However, running "ALL dates to dmy" causes "the 4 January 2015 edition of The Times" to become "the edition of 4 January 2015 of The Times". That's a little awkward; it was better before (when I run it, I have to reset all these types of corrections). If you'd like to see it do this for yourself, try it on Tintin in the Land of the Soviets Thanks. Prhartcom (talk) 05:56, 6 January 2015 (UTC)

A bug or intentional?

In this edit "which aired 8/28/2009 on TruTV" would have been changed to .."Aug 28, 2009".. I changed to the only legal form (for non-table main text) "August 28, 2009" manually before submitting the proposed script change. comp.arch (talk) 16:00, 19 February 2015 (UTC)

Concern with this script

I have an concern with your script, and its interpretation of MOS:DATEFORMAT and MOS:DATEUNIFY. Let me quote the documentation that that accompanies {{Use dmy dates}}:

In general, the date format used for publication dates within references should match that used within the article body. However, it is common practice for archive and access dates to use the alternative ymd format. This usage is valid and is specifically mentioned at MOSDATE. In those cases, the archive and access date formats should not be altered when fixing dates. (emphasis mine)

IOW, while the ref date parameters in references should match the date style used in an article's text, the accessdate parameters do not have to. But your script does not have an option to leave 'ISO dates' as is in the 'accessdate' and 'archivedate' parameters. Is there any chance that an option to leave ISO dates in those parameters will be added to your script? --IJBall (talk) 20:57, 6 April 2015 (UTC)

  • Thank you for highlighting your concern. I would, however, draw your attention to the documentation, where you will find the correct script button that addresses your concern. FYI, this functionality is an early feature of the script. Regards, -- Ohc  05:12, 7 April 2015 (UTC)
Yes, I had glanced at that before I posted the original message. For the record, I am not currently using your script. The issue is that some editors seems to be using it in (for example) all dates to dmy mode, which changes accessdates to dmy format as well, even when an article has previously settled on ISO dates for ref accessdates. This is a concern because these editors's use of the script this way are then in violation of MOS:DATERET. I just thought you should be aware of the issue, because I've already had to do one reversion on that basis on an edit using your script. --IJBall (talk) 06:05, 7 April 2015 (UTC)
The script has a very low false positive rate, and if you do many date conversions, it would make sense for you to start using the script for improved productivity. Note that I just provide a polyvalent tool and the user is then responsible. I think the best and only thing I can do is to make that clear in the documentation. I'm open to suggestions. -- Ohc  13:15, 7 April 2015 (UTC)
I think it's very clear which button to use to leave accessdate alone, even without referring to the documentation. --Laser brain (talk) 16:13, 7 April 2015 (UTC)

Your assistance please...

Your documentation says your script "converts other often used (but not MOSNUM-compliant) date formats within the references section, such as dd-mm-yyyy or dd-mmm-yyyy to the chosen prevailing format used in the rest of the article." @Walter Görlitz: says he used your script to convert YYYY-MM-DD to his preferred format -- using your script.

I don't use automated editing tools myself. And, frankly, I find many automated editing tools are too aggressive. Frankly, I am disappointed by contributors who show bad judgment in their edits, and then claim "but that edit was recommended by my favourite automated editing -- so it must be okay!"

As I pointed out to WG "MOS:DATEFORMAT says "Special rules apply to citations; see Misplaced Pages:Citing_sources#Citation_style," and Misplaced Pages:Citing_sources#Citation_style says: "Although nearly any consistent style may be used, avoid all-numeric date formats other than YYYY-MM-DD". So, YYYY-MM-DD, within a citation, should be left alone.

I request, if WG is correct, and your script currently changes YYYY-MM-DD to a text month date, within citations, then this feature should be deprecated.

One of my biggest frustrations, when I return to update an article I last worked on months or years ago, is to find that the large number of edits to the article since my last visit, a large number of edits that light up the diff like a christmas tree, were largely or entirely changes to the article's metadata, and the article's intellectual content was largely or entirely unaltered.

When the initial diff between the last change I made, and the current version shows practically everything has been changed, I step through each diff, one at a time, and, when lots of discrete changes have been made, this can take half an hour or more.

Its maddening to make that effort, only to find the article's intellectual content remains unaltered.

I find overly aggressive automated tools play a big role in eroding the value of diffs.

Diffs rely on line-endings. Automated tools that rewrite references to put them in the tool-writer's favourite format strongly erode the values of diffs. If there are circumstances where your tool will make cosmetic changes to how references are formatted when viewed in the editor, I requiest you remove that feature.

Automated tools that take paragraphs that are composed of multiple logical lines, and rewrite them on a single logical line, are a terrible problem. They can make it look like the original paragraph was excised, and replaced by a brand new paragraph.

It is extremely important to preserve the original line endings. Corrections of spelling or punctuation, or the fixing of poorly formed or broken wikilinks, don't alter an article's content, but they are still valuable. When contributors, or automated tools, change the line endings in a paragraph any diffs that show the highly valuable spelling corrections, and other similar corrections are drowned out by the change in line endings that misleadingly shows the whole paragraph being cut and replaced by brand new text.

So, if your automated tool is one of those which will, under some circumstances, alter line endings, I request you remove this feature.

Thanks Geo Swan (talk) 12:35, 18 July 2015 (UTC)

Version number (1.1.1031) canged to date

Unless I hadn't been careful, see this edit. Otherwise the script is great. comp.arch (talk) 22:00, 2 September 2015 (UTC)

citation and/or cite news -> cite web_cite_web-2015-09-03T11:23:00.000Z">

I've noticed that several people using your script also change the {{citation}} and {{cite news}}to {{cite web}} this seems inappropriate when the source is an actual news website (like ESPN). Is this the programmed behavior? If so, I think that it shouldn't change these in all situations. --Trödel 11:23, 3 September 2015 (UTC)_cite_web"> _cite_web">

yyyy-mm to mmmm yyyy

Any chance this script might be updated to include the above setup? E.g., 2015-12 to December 2015. This would be especially useful when converting ref dates (without days) that {{cite web}} doesn't like. Or is there a reason to not do this? (Has this been discussed before?) czar 18:37, 23 December 2015 (UTC)

Updated user doc

Hi, Ohconfucius. I updated the user doc with a workaround for wikEd. I hope you like it. I was very happy to find a workaround that was short of disabling wikEd in user preferences or in my common.js file.

Is there any way to have MOSNUM dates count the number of datestyles in a page so we can more easily figure out which datestyle to enforce and update?

Also, is there a way to have MOSNUM dates do the wikEd text area toggle automatically on the fly? Cheers! {{u|Checkingfax}} {Talk} 21:17, 15 January 2016 (UTC)

script is adding regular spaces after nbsp template

Hi Ohconfucius. The script is adding unnecessary regular spaces after the {{nbsp}} (non-breaking space) template as seen in this Diff. You can see it more clearly by using WP:wikEdDiff. Ping me back. Cheers! {{u|Checkingfax}} {Talk} 06:19, 24 January 2016 (UTC)

UPDATE: My bad. Hi Ohconfucius and GoingBatty. The script is actually removing the entire {{nbsp}} template throughout pages it is run on as seen in the Diff provided above. Cheers! {{u|Checkingfax}} {Talk} 01:28, 20 February 2016 (UTC)

That's by design. I'm not an expert coder and the script is not very sophisticated and cannot distinguish between those dates that are correct and those that aren't. Any nbsp within date strings are removed so that the script can perform its work. I used to insert nbsp to"protect" the date format, and I later realised that it's a bad way to do that. It's too complicated for me to have any workaround solution that preserves the nbsp. Regards, -- Ohc  09:19, 20 February 2016 (UTC)

Script is removing < signs from article

Hi Ohconfucius. The script is removing < signs from articles, for example: Michelin Guide. I left them in and canceled the edit. Please advise. I would like to get back to using the script to fix dates. Thank you. Cheers! {{u|Checkingfax}} {Talk} 10:43, 2 February 2016 (UTC)

@Checkingfax: I just ran the "all dates to DMY" script on Michelin Guide in this edit and it looks like it worked fine. GoingBatty (talk) 02:28, 3 February 2016 (UTC)
Thanks GoingBatty. Next time I see something I will grab a screenshot and upload it the Commons. Cheers! {{u|Checkingfax}} {Talk} 02:48, 3 February 2016 (UTC)

Reload button

I have copied the MOSNUM date script and pasted to my common js page and saved. I have Google Chrome, and it says to click the Reload button, but I don't know where that is. Can you tell me where the reload button is? Corinne (talk) 03:52, 20 February 2016 (UTC)

Thank you! Corinne (talk) 14:53, 20 February 2016 (UTC)

Script creates duplicate arguments

Hi, in this edit, using the script, it added |df=yes to the {{wayback}} templates even though the template already had a |df=y entry. This caused a duplicate template argument problem. Can the script be modified to avoid doing this? Thanks. Keith D (talk) 12:29, 20 February 2016 (UTC)



Why remove links?

It removes year linking templates (such as {{scy}}, {{by}}), and links to 'year-in X' where piped from years (such as ])

Why remove article links? What's the justification? Suppose an article contains links to ], ], and ]*, all in different paragraphs or sections relating to those topics. Deleting the links will remove information from the article.

(* 1988 in literature, Category: 1988 disasters, and Category: 1988 in the environment)

--Thnidu (talk) 17:22, 16 May 2016 (UTC)

@Ohconfucius:In addition to this nonsensical policy of destroying content instead of converting dates, the script has a similar bug where it likes to obliterate wikilinks with nonsense. For example, it'll take Burlington mayoral election, 1981 and turn it into ⍌1321⍍. I can't even imagine what this is, but it happens constantly. Also the tool seems to have become very slow, taking multiple minutes to run on each page, and one minute on even small pages. All of this is what happens on "ALL dates to mdy" for example. Thank you very much for maintaining this vitally necessary tool. — Smuckola(talk) 14:57, 21 January 2019 (UTC)
@Ohconfucius:I was wondering if there's any special reason why this huge bug is being overlooked in favor of other things. Also we need it to ignore dates inside of title= and other fixed metadata. Thank you. — Smuckola(talk) 22:01, 22 June 2019 (UTC)
@Smuckola:I use the script extensively, and I can tell you that what you describe is extremely rare. The error should be caught by the script operator, who should not save the edit. The error is a result of incomplete execution of the script. The symbols such as ⍌1321⍍ are markers for strings that are protected before the script proper is executed. Therefore, if you see these in the preview, it means that the script has stalled – this could be due to slow internet speed or perhaps slow browser. You should reinitiate the edit window and click on the script sidebar button for the function required. If the problem persists, you should try editing using a different browser. -- Ohc  23:28, 26 June 2019 (UTC)
@Ohconfucius: Ok first, I'm sorry for being blunt because this tool is invaluable and irreplacable to my knowledge, and I would pay a bit of cash to have it fixed, perhaps by someone else and submitted as a patch since I assume you're busy. It's good to know that it could be my system because I do run a lot of wikipedia userscripts (though I don't think they're running and taking cpu concurrently with your script) and some of my hardware is a core2duo with Chrome, or an iPhone 6sPlus with Safari. I'd suggest maybe having a check on the final output to see if there are inadmissible characters like ⍌ and revert that one, although yes I do check all my content prior to submission. So how about the rest of the bugs we listed, which occur 100% of the time? There can not be any reason to alter any content that isn't a date, such as obliterating any content or templates, or anything inside of other metadata such as title=. That just ruins the script, and there are many articles I simply can't feasibly run it on. Thank you so much. — Smuckola(talk) 01:17, 27 June 2019 (UTC)
@Smuckola: No offence taken. In the course of the next week, I will work to modify the script for the points you raised. It will probably involve stripping it down and removing certain functions that are obsolete. Regards, -- Ohc  11:42, 28 June 2019 (UTC)
@Ohconfucius: Hey there buddy. I guess you got that done, because it suddenly appears in my left column with different text now, "DATES to mdy" and it doesn't work at all.  :) It runs for a while, and it adds the standard text to the edit summary, but it changes nothing. Even in articles that have lots of numeric dates like "2019-06-01", like Howard Phillips (consultant). I'm sorry i dont know how to troubleshoot it. Where's the changelog and everything; is it on github? Thank you. — Smuckola(talk) 12:08, 6 July 2019 (UTC)
@Smuckola: I suspect what you observed was in the edit diff window. It seems to be working more or less correctly despite a minor glitch which I have fixed. I modified the script hoping to shorten execution time as you requested. However, I'm not convinced that the script runs much faster than before because the protection and unprotect modules are the parts that I think takes the longest to execute. The function that converts yyyy-mm-dd dates when housed in citation templates to dmy/mdy designation has been disabled. I have been informed that this is now automatically formatted when displayed – The Wikimedia software has been configured to look for the {{use dmy dates}} and {{use mdy dates}} templates and display these dates accordingly – so the change in date format would be considered an "inconsequential edit". The best way to test this is to open an article that already has a {{use dmy dates}} template and execute the DATES to mdy function of the script, you will then see all the instances that have been corrected in you diff; the dates will render to dmy or mdy if you looked at the edit in preview mode. The script is like any other page on WP, and the changelog can be found here-- Ohc  13:08, 8 July 2019 (UTC)
@Ohconfucius: Hi there. All the bugs in this thread are still present. The script edits indiscriminately, including inside citation titles and ] filenames. As the original poster said, there can not possibly be a reason to obliterate wikilinks; it seems there must be some deliberate vendetta against the existence of things like these: ], ], or ]. Those are globally destroyed, which has absolutely nothing to do with date formatting. And as I said, I still get those internal markers like on this. I'm sorry I'm not a programmer and can't help, or I can't understand what's happening. Thank you! — Smuckola(talk) 21:13, 5 September 2021 (UTC)
I am also seeing removals of these links. But in my experience, it's not a problem. These articles are so unspecific that in most cases linking them in an article is not useful. Robby.is.on (talk) 08:13, 6 September 2021 (UTC)

Purging cache

How do I do purge the cache? CrashUnderride 06:25, 29 March 2017 (UTC)

@Keith D: do you think you could help me out? CrashUnderride 14:44, 29 March 2017 (UTC)
Take a look at Misplaced Pages:Purge it may be of help. Keith D (talk) 16:29, 29 March 2017 (UTC)
There is also Misplaced Pages:Bypass your cache which give details for browser specific cache bypassing. Keith D (talk) 16:33, 29 March 2017 (UTC)
@Keith D: thanks, I used WP:PURGE and the Gadget method. I appreciate it. Now hopefully this will work so that I can fix date formats more easily. CrashUnderride 05:42, 30 March 2017 (UTC)

Dates in singlechart/albumchart

Is there anyway you can code the script so it doesn't change the dates in the Template:Single chart and Template:Album chart? Sometimes it needs to be a certain format in the parameters and it messes with it when I run this. If not that's alright. thanks, --Jennica✿ / 12:36, 29 June 2017 (UTC)

BIGENDIAN option?...

I believe, before, this option was titled "access to ISO" – why is it now called "BIGENDIAN ref dates"? I think that'll be more confusing to users than the previous "access to ISO" option was. --IJBall (contribs • talk) 23:33, 22 August 2017 (UTC)

Wikisource

How does this script handle date ranges within citation scripts that link to pages on Wikisource where most projects choose to use dash and not ndash in date ranges?

Usually if a script is linking to a Wikisource page then the page name and munges on the necessary information to create a link. eg {{cite EB1911|wstitle=A}}:Chisholm, Hugh, ed. (1911). "A" . Encyclopædia Britannica (11th ed.). Cambridge University Press. (s:1911 Encyclopædia Britannica/A).

So that the script can handle pages from an encyclopaedia not yet fully ported to Wikisource, most scripts use title= if the page= is not ported and wstitle= if it is. However books that have been fully ported to Wikisource may have thier templates changes so they always link title to wikisource. Eg {{cite Nuttall}}

So while it is not usually any real concern what this script does to the content of title= (with the exception of {{cite Nuttall}} and the like) it is a problem if it changes the content the parameter wstitle= because it is likely to break the link to wikisource.

Changing links to wikisource in non-templated links where for example the link includes dashes in a date range would also break links, if a simple substitution was made.-- PBS (talk) 12:04, 10 October 2017 (UTC)

Firefox 57

I should probably let you know it is not working for me on Firefox 57 Seraphim System 01:06, 16 December 2017 (UTC)

Access and archive dates per WP:CITEVAR, WP:CITESTYLE and MOS:DATEUNIFY

Per WP:CITEVAR, WP:CITESTYLE and MOS:DATEUNIFY:

"Misplaced Pages does not mandate styles in many different areas; these include (but are not limited to) American vs. British spelling, date formats, and citation style. Where Misplaced Pages does not mandate a specific style, editors should not attempt to convert Misplaced Pages to their own preferred style, nor should they edit articles for the sole purpose of converting them to their preferred style, or removing examples of, or references to, styles which they dislike.

"Access and archive dates in an article's citations should all use the same format, which may be:

  • the format used for publication dates in the article;
  • the format expected in the citation style adopted in the article (e.g. 20 Sep 2008); or
  • yyyy-mm-dd "

Access and archive dates in an article's citations may use one of the three bulletted formats above. Editors should not attempt to convert access and archive dates in citations if they comply with, for example, the yyyy-mm-dd format. Jeff in CA (talk) 01:40, 24 December 2017 (UTC)

Bug with "Body dates to dmy"

So say I go to edit this page: https://en.wikipedia.org/search/?title=Presto_card&action=edit&oldid=852611695

And I click "Body dates to dmy"

I would expect just the dates in the body to change to dmy, while citation dates would be left alone.

Instead, dates in the body and the |date= parameter in citations are switched to dmy. (Reference dates such as |access-date= are left as is, as expected.)

Can this be fixed?

Also happens with the "Body dates to mdy" option—|date= in <ref> tags are also changed to mdy. —Joeyconnick (talk) 05:29, 30 July 2018 (UTC)

Automated scripts

This thread pertains to the addition of template:Use DMY dates when the “All dates to DMY” option of this script is used in an article Moved from User talk:Seppi333
Imported thread

I shouldn't need to remind you that you are responsible for every edit you make, including those made by script. Misplaced Pages:User scripts is clear: "... you will be held responsible for any actions it takes on your behalf." If a script is faulty, then the onus is on you to correct the problems it causes when you use it.

There are sometimes objections raised about an article being marked as {{use dmy dates}} or {{use mdy dates}}, and there is a world of difference between the strength of argument for retaining the existing style when the template is marked as four years old and that when the template is four days old. There is no benefit derived from resetting that date. I hope it's clear what you should be doing next, and if you use the script again in future. --RexxS (talk) 13:56, 13 August 2018 (UTC)

@RexxS: This script is used by many editors and I've been using it for years; you are the first person who has ever mentioned this being an issue. You didn't substantiate the consensus in your edit summary, so I have no clue what you're talking about. But, if you want to fix that problem which is going to continue regardless of whether or not I continue using that script, you need to discuss it at the link I provided in my edit summary (i.e., this one: User talk:Ohconfucius/script/MOSNUM_dates). In any event, I don't intend to stop using it. Seppi333 (Insert 2¢) 14:08, 13 August 2018 (UTC)
If you reply on my talk page about this again, I'm just going to move the entire thread to that script's talk page; my talk page is not the right venue to broach this issue. Seppi333 (Insert 2¢) 14:10, 13 August 2018 (UTC)
This thread is pertinent to your behaviour and belongs on your talk page. I've made clear my objection to you resetting the dates in templates {{use dmy dates}} and {{use mdy dates}}. If you persist in resetting them against my objection, then I'll take the matter to ANI for adjudication. --RexxS (talk) 14:17, 13 August 2018 (UTC)

I don’t know exactly what RexxS’ concern about the addition/replacement of the date template is, so I’ll let him speak for himself. The edit he objected to is .

On an unrelated note, this is a really useful script. Seppi333 (Insert 2¢) 15:20, 13 August 2018 (UTC)

I'm guessing he sees the date on that template as being indicative of when consensus was established for using that date format? Any maybe resetting it to the current day/month is creating a false impression that the date format wasn't already supposed to be that way? The script could easily check for the existence of that template and not touch it if it's already there. --Laser brain (talk) 16:15, 13 August 2018 (UTC)
Indeed, Laser_brain that is exactly my concern. Thank you for spelling it out more clearly than I was able to. I agree that the script is very useful, and I also see it as useful to add {{use dmy dates}} or {{use mdy dates}} where they don't exist. But where one is already present, the script should not be changing the original date that the template was added. In addition, Seppi333 ought to be taking responsibility for the edits he's making and fixing the problematical edits he has made, rather than using the excuse that "the script did it". --RexxS (talk) 16:29, 13 August 2018 (UTC)
@RexxS: It seems to read like you've misunderstood the reason for the date field in the DMY/MDY templates. It's not there to indicate when consensus was reached, it's a maintenance field for bots to use. It indicates the last time that the article was checked for inconsistent dates so that bots don't edit articles too frequently. Ohconfucius' script - and anyone using it - is using it in the correct manner; updating the date field in the template to the date of the last date format check. It seems a bit much to chastise @Seppi333: when the reason for the date field is not their misinterpretation. - X201 (talk) 07:30, 14 August 2018 (UTC)
@RexxS, Seppi333, and X201: the script is operating as designed when it updates the date parameter as described. There is wide consensus for this course of action. The script alters every article in this way whenever it is run. I would also refer you to the script documentation as well as the relevant documentation explaining the function of the Template:Use dmy dates. Regards, -- Ohc  20:05, 25 October 2018 (UTC)

Use dates template not inserted into articles

I'm currently experiencing a problem using the script with the new markup editor: the Use dates template is not updating or inserted into articles automatically (I have to do this manually for some reason). Is there a possible ETA on when this can be fixed? jd22292 (Jalen D. Folf) (talk • contribs) 15:12, 24 October 2018 (UTC)

  • I tried running my MOSNUM script as you were doing presumably, by directly importing your common script. I experienced nothing unusual, meaning all date conversions were performed correctly, and all date templates were correctly inserted or dates updated. Kindly let me know exactly how you were using it and on which article did you perform the script edits whose failure you reported, so I can attempt to recreate the circumstancecs under which the error occurred. Regards, -- Ohc  19:53, 25 October 2018 (UTC)

Dates that are used as adjectives

Rather than having to manually reinsert a "the" or even rephrasing a sentence, could it be considered to set up a permanent workaround that tells the script to ignore it? For example, we could set up {{the}} and get it to display as "the". Would that successfully stop the script from removing the article? Schwede66 06:11, 21 November 2018 (UTC)

  • The reason for the removal of "the" in front of the date stems from the prevalent but obsolete practice of ordinal dates such as "the 5th of April" or "April the 5th". I don't know how we can have a workaround for that because there is no real way of distinguishing the adjectival use from the ordinal. I tried writing in a re-ordering, but it only works for certain structures and cannot be made universal without significant false positives. Such a template as you suggest is an interesting idea, but it would reauire manual insertion. But as it seems to me that the ordinal form has all but disappeared from en.wp, I may disable the removal of the "the" strings that appear before date strings. -- Ohc  19:45, 22 November 2018 (UTC)
I use your script a lot and come across the ordinal form with some regularity. Schwede66 00:49, 23 November 2018 (UTC)

Interface-protected edit request on 14 April 2019

This edit request to User:Ohconfucius/script/MOSNUM dates.js has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

The cs1|2 module suite has a update pending. Part of that update is implementation of code that looks for {{use dmy dates}} and {{use mdy dates}} and sets the date format in rendered cs1|2 citations accordingly (discussion). Because MOS:DATEUNIFY allows date formats in citations to be different from the date format used in the body of an article, the cs1|2 update will support a non-functioning parameter (|cs1-dates=) in the {{use dmy dates}} and {{use mdy dates}} templates to fine-tune the rendering made by the cs1|2 module suite.

User:Ohconfucius/script/MOSNUM dates.js, in its present form, wholly rewrites existing {{use xxx dates}} templates when it is invoked. That mode of operation is fine as long as editors don't care about fine-tuning the citation date formats. But, when editors have specified citation date formats using |cs1-date= the script must not throw that specification away.

I am not a js programmer. I have hacked a copy of this script at User:Trappist the monk/script/MOSNUM_dates.js. There is a bunch of documentation about the changes made at this testpage.—Trappist the monk (talk) 16:15, 14 April 2019 (UTC)

Ah-ha, ok guess it is  Done :D — xaosflux 23:12, 16 April 2019 (UTC)
Slyly. Wasn't that the idea? -- Ohc  10:22, 17 April 2019 (UTC)

Date formatting in cite X templates no longer necessary

Hi there. I wanted to point out that it is no longer necessary to change the date formatting in the code for the "Cite" templates if there is a {{use dmy dates}} template at the top of the page. See this discussion at WT:CS1. The cite templates will automatically show all dates using the defined format indicated by the {{use dmy dates}}/{{use mdy dates}} template at the top of the page. Sure, it is still somewhat nice to update the formatting of the code to match what will be displayed, but it is completely redundant at this point and should not be the *only* action done in an edit because there is literally no difference in how the page displays. - Paul/C 13:20, 12 June 2019 (UTC)

  • Thanks for the heads up. Now it increases the chance that a greater number of my edits will be considered "trivial"... -- Ohc  08:09, 13 June 2019 (UTC)
    • Curious. I haven't noticed that. I was just editing the Megan Rapinoe article and manually adjusted the ISO 8601 dates in refs because the script failed to convert them to MDY. I just checked the state in history and it does show as MDY in the refs. However, the script didn't modify the dates in the table in the "international goals" section either. Walter Görlitz (talk) 04:35, 8 July 2019 (UTC)
  • Judging by this edit, this is still an issue, since the script changed ISO dates in refs to mdy ones, even though there was already a {{Use mdy dates}} tag present. Nick Number (talk) 14:37, 13 September 2019 (UTC)
    • In July I disabled two script modules that converted yyyy-mm-dd dates to dmy or mdy dates following a user complaint that the script frequently stalled. Then I reinstated the modules on 3 September because I realised the speed issue wasn't affected by the change. Furthermore, I gathered from the discussion that wasn't a good idea to leave inconsistent date formats clearly visible in edit mode the article. I trust that explains the reason for the changes/non-changes as appropriate. -- Ohc  16:16, 13 September 2019 (UTC)

No "body dates only" option?

Hi, what happened to the "body dates" option that's shown in the page image? The only options I see are "DATES to dmy" and "DATES to mdy". I know the citation dates don't really matter since these are automatically set based on the {{Use (format) dates}} templates, but it would still be nice to have a less cluttered "show changes" view. Ionmars10 (talk) 23:16, 12 December 2019 (UTC)

  • Ionmars10 The script did not act on yyyy-mm-dd dates within reference strings but changed all other formats when using those buttons. I've now modified the script to protect all references, so that no dates within reference sections will be changed when the "body only" script functions are engaged, even if they are wrong (ie mdy in dmy articles and vice versa). I don't see any merit in that but hey, ymmv. -- Ohc  17:09, 9 January 2020 (UTC)
    Ohconfucius, many thanks. My rationale for wanting to use body dates only was that because the {{Use mdy dates}} and {{Use dmy dates}} change the reference formats automatically, the script itself changing them within the wikitext would essentially produce a bunch of dummy changes which would clutter the diff view and maybe annoy people who would have to scroll through the potentially hundreds of dummies while reviewing changes to find the one or two changes that actually affect how the article looks. It should also make it easier for me to manually review the changes the script makes on my behalf. Ionmars10 (talk) 21:29, 9 January 2020 (UTC)
  • Ionmars10 While automatic formatting of dates based on the template has effectively made many date changes "inconsequential", but there are cases where it could be highly consequential. Firstly, people would otherwise be very confused with a potential mess of dates visible in edit mode but not in read mode. Secondly, there are many other corrections the script makes dates such as missing commas (eg Sept 27 2013), extra commas (eg 27 Sept, 2013) or misspelt month names or missing capitalisation (eg 2 mars 2013), which will now not happen when the "body dates" button is engaged now. In any event, the "all dates" button of the script check "minor edit" – this should already allow editors to ignore them if they see them appear on their watch list. -- Ohc  22:22, 9 January 2020 (UTC)
  • Ionmars10 You can easily see how many script edits I make every month. Reviewing script changes gets easier very quickly with experience. -- Ohc  22:39, 9 January 2020 (UTC)
    Ohconfucius, these are quite good points. I'll try using the "all dates" ones from now on, and if I wasted your time with all this then I'm really sorry (maybe the "body dates" option will end up being useful for something else?) Ionmars10 (talk) 23:57, 9 January 2020 (UTC)

Conflicts with the <math> tag_tag-2020-01-08T13:54:00.000Z">

In this edit the script replaced hyphens U+002d with a unicode minus sign U+2212 inside a <math> tag. This causes problems with the math rendering engine which does not recognise the unicode minus. --Salix alba (talk): 13:54, 8 January 2020 (UTC)_tag"> _tag">

new bug?

I think your recent changes have introduced a bug, because I can't get the "DATES to dmy" or "DATES to mdy" links to work... I click them and nothing happens. —Joeyconnick (talk) 18:47, 9 January 2020 (UTC)

A few bugs

Thanks for a great script! I have been using it for a week or two, and have found a few bugs:

  • It changes dates in wiki links. See this edit where it changes ] to ]. This broke the link.
  • It changes dates in external links also. Try run the script on the article July 12, 2007, Baghdad airstrike. It changes "archive-url=https://web.archive.org/web/20110216183431/http://en.wikisource.org/July_12,_2007_Baghdad_airstrike_transcript" to "archive-url=https://web.archive.org/web/20110216183431/http://en.wikisource.org/July 12,_2007_Baghdad_airstrike_transcript". It removes the _ which will break the link.
  • Sometimes it removes "the" where it should not. Try run it on the article 2020 Baghdad International Airport airstrike. It will change "two months before the 27 December incident" to "two months before 27 December incident".

Kreggon (talk) 17:05, 11 January 2020 (UTC)

Suggestion: change mf and df template parameters

Could the script be made to change instances of mf=yes and df=yes (standing for "month first" and "day first") in templates such as {{Birth date and age}}? Here's an example of this in which I had to change it manually to fit with the {{Use mdy dates}} template. Ionmars10 (talk) 17:03, 14 February 2020 (UTC)

Film date

The script already works on {{Film date}}, can you fix it so that it also works on the template redirect Filmdate please. Thanks. - X201 (talk) 09:06, 4 March 2020 (UTC)

Two issues in April

Hi there. :-) Thanks a lot for providing this script, I've made a lot of use of it in recent years.

Since a few days, I'm seeing two issues when using "DATES to dmy":

  • dates in links are changed when they shouldn't as it breaks the links – screenshot: https://jmp.sh/dSzqVfn Looks like the issue reported in January (see above).
  • "df=yes" is no longer added to the {{Birth date and age}} template. This also worked until very recently, I think.

Kind regards, Robby.is.on (talk) 19:27, 25 April 2020 (UTC)

Update: The second issue seems to be fixed but not the first. Robby.is.on (talk) 09:36, 29 April 2020 (UTC)

VisualEditor compatibility

Hi Ohconfucious, thanks for this great script!

I may just be being dense, but I can't find any way of making this work at the moment with VisualEditor, even in its source editing mode. Is it possible, or is VE not supported at the moment?

Cheers, Naypta ☺ | ✉ talk page | 21:13, 16 May 2020 (UTC)

Conversion of all-numeric dates

The script currently assumes that dates of the form ##/##/#### are to be interpreted as DMY if it's unclear (i.e. month and day are both <= 12). However this means that dates such as 06/02/2020 are interpreted as February 6 instead of June 2, even though it's clear to a human based on context that these were meant as MDY. See List of Superfund sites in New Jersey for an example of this. Could an option be added to the left menu to convert these dates with either a DMY or MDY interpretation? Ionmars10 (talk) 18:32, 2 June 2020 (UTC)

Yes indeed, it's a function that was hidden to simplify the menu options. I'll bring it back out. -- Ohc  05:33, 3 June 2020 (UTC)

Suggestion or request or problem

I'm using this script for a while. It's good and I like it. But it has a problem that it changes the month name in template {{Use dmy dates|date=Month Year}} to current month and year. It shouldn't do so. Can it be fixed? I've also a suggestion that it should also appear in the sidebar while reading even if you aren't editing a page like 'Refill' and 'Duplinks-Highlighter'. By clicking on it, it should go to editing mode and perform the action. Thank you. Tears. Empire AS 13:51, 17 August 2020 (UTC)

But it has a problem that it changes the month name in template {{Use dmy dates|date=Month Year}} to current month and year. It shouldn't do so. Why would that be? Kind regards, Robby.is.on (talk) 14:32, 17 August 2020 (UTC)
Robby.is.on, I give you an example that an article contains this template such as {{Use mdy dates|date=March 2012}} but it will change it into {{Use mdy dates|date=August 2020}}, an 8 years old template to new. Isn't it awkward? I think it is. Empire AS 14:53, 17 August 2020 (UTC)
Second sentence in §Usage at {{use dmy dates}}:
Use the parameter |date= for the month and year that an editor or bot last checked the article for inconsistent date formatting and fixed any found.
It is a somewhat awkward sentence, but the script is doing the correct thing when it modifies |date= in the {{use xxx dates}} templates.
I might suggest rewording the sentence to read:
|date= records the month and year that an editor or bot checked and repaired article date inconsistencies.
—Trappist the monk (talk) 15:04, 17 August 2020 (UTC)
Empire AS: It is confusing because every other maintenance template's |date= parameter shows the date when a condition was first tagged, and this one shows the date when the condition was last checked. The documentation explains it, but a different parameter name should have been chosen. – Jonesey95 (talk) 15:10, 17 August 2020 (UTC)
Trappist the monk, I meant to say that it changes old month and year to current month and year. Empire AS 15:15, 17 August 2020 (UTC)
Yes, it does. Because that is what the template documentation says the script should do.
—Trappist the monk (talk) 15:21, 17 August 2020 (UTC)
Trappist the monk, But what you think it should do so or not? Empire AS 01:17, 18 August 2020 (UTC)
I think that the script should comply with the template documentation. Were I the template and script author, I might have chosen to use a different name for the date-last-checked-and-repaired parameter or maybe not. The {{use xxx dates}} templates are not like most maintenance templates. For example, setting |date= when {{citation needed}} is added to an article: if, two years later, the article text still needs a citation, delete the text and delete the template. The {{use xxx dates}} templates don't get deleted. If there is some dispute about date formatting in an article, it will be resolved by inspection of the article history, not by the date in the {{use xxx dates}} template.
So now, it's your turn. You have declared: It shouldn't do so. You have not said why shouldn't do so..
—Trappist the monk (talk) 12:08, 18 August 2020 (UTC)
Trappist the monk, I think you still didn't understand what I said. I simply said that it changes years old dmy tag to new tag. Means it replaces the date of tag to the date of last checked. Well, if it doesn't change the tag, I think it'll be good. And what about my suggestion? I think you should also pay some heed on that. Thank you. Tears. Empire AS 12:27, 18 August 2020 (UTC)
You wrote: an article contains this template such as {{Use mdy dates=March 2012}} but it will change it into {{Use mdy dates|date=August 2020}}. I understand what you wrote. I don't know if it was intentional on your part but the {{Use mdy dates=March 2012}} that I quoted is malformed (no |date= parameter):
{{Use mdy dates=March 2012}} → {{Use mdy dates=March 2012}}
If the script is smart enough to recognize that the template call is malformed and rewrote it into a valid form, then it did the correct thing. If the script changed a correctly formed template:
{{Use mdy dates |date=March 2012}} → {{Use mdy dates|date=August 2020}}
then, for that change, the script complied with the template documentation, and so, did the correct thing.
Well, if it doesn't change the tag, I think it'll be good. Ok, but that doesn't say any more than your previous declaration: It shouldn't do so. Why shouldn't the script modify |date= in the template?
Except for a small part of the script (support for |cs1-dates=), I am not the author of the script. I do not use the script so I have no opinion with regard to your suggestion.
—Trappist the monk (talk) 13:08, 18 August 2020 (UTC)
Trappist the monk, But the script updates the dates in dmy tag even if there's nothing to be corrected in the articles main body. Can you give me a script than only fixes date formats in article body without changing tag dates. Thank you. Tears. Empire AS 03:26, 22 August 2020 (UTC)
Empire AS, I still don't understand why this is a problem. According to documentation, the date parameter refers to the month and year that the article was last checked for inconsistent date formatting. Just because the script didn't make any changes does not mean that a check hasn't been done. The point of this is to ensure that articles don't go too long without a date format audit - i.e., articles in the oldest monthly category will be the ones most likely to require an audit and so can be handled first. Ionmars10 (talk) 03:45, 22 August 2020 (UTC)
Okay, it looks like this comment was made due to a message on your talk page in which a user claimed that these types of edits were clogging up the page history. Ionmars10 (talk) 04:14, 22 August 2020 (UTC)
Ionmars10, I already had pointed out this problem. But, I came again when that user said that it clogs history by changing tag dates. Thank you. Tears. Empire AS 05:18, 22 August 2020 (UTC)
If running the script is part of a larger change I don't see a problem with "clogging up the page history". It would be a bit daft to make a change that only consists of updating the date in the template. Robby.is.on (talk) 08:54, 22 August 2020 (UTC)
Can you give me a script than only fixes date formats in article body without changing tag dates. Don't you think that would be a pointless exercise? Some other editor would run MOSNUM dates.js because your custom script didn't update |date= in {{use xxx dates}} when you checked the article.
—Trappist the monk (talk) 10:23, 22 August 2020 (UTC)
Trappist the monk, But by going through article edit history, they will be able to see that the article has been checked. However, I know that it will be a hard exercise. I don't know how to write scripts, otherwise I would have tried to create such a script. Tears. Empire AS 11:10, 22 August 2020 (UTC)
That isn't making any sense to me. Your issue, as I understand it, it that MOSNUM dates.js adjusts |date= in {{use xxx dates}} when it changes dates in the article and, also, adjusts |date= in {{use xxx dates}} when it does not change dates in the article. You want a script that checks but does not adjust |date= in {{use xxx dates}} when the script did not make changes in the article. Do I have that right?
But by going through article edit history, they will be able to see that the article has been checked. If your custom script does not adjust |date= in {{use xxx dates}} because it did not make any changes in the article, saving the article amounts to a WP:NULLEDIT. If there are no changes, nothing is saved, there is no history.
—Trappist the monk (talk) 11:37, 22 August 2020 (UTC)

Script not working

I've installed this script, but now it's not working. No options appear of 'Dates to dmy' or 'Dates to mdy'. What did happen? Please fix it. Thank you. Empire AS 02:34, 31 August 2020 (UTC)

It does work here. Robby.is.on (talk) 08:02, 31 August 2020 (UTC)
Robby.is.on, Not working. No options load. I disabled some other scripts but in vain. Thanx. Empire AS 09:43, 31 August 2020 (UTC)

Script options not loading on edits

Hello! I was wondering if the script was having any issues because when I go to edit, nothing loads as a option. Thank you. Red Director (talk) 23:11, 13 October 2020 (UTC)

I'm seeing this too, @Red Director:, and asked for help at Misplaced Pages:Village pump (technical) a few hours ago. Robby.is.on (talk) 23:21, 13 October 2020 (UTC)
@Robby.is.on:, thanks for the reply. Will monitor this and see if anything comes up. Red Director (talk) 02:45, 14 October 2020 (UTC)
It's not loading for me as well. ~~ CAPTAIN MEDUSA 14:24, 14 October 2020 (UTC)
@Red Director and Robby.is.on: this fixes the problem. ~~ CAPTAIN MEDUSA 17:59, 14 October 2020 (UTC)
@CAPTAIN MEDUSA: I attempted this, but could not find that exact verbiage. Do you have any suggestion on what I may be doing wrong?--Esprit15d • talk • contribs 17:19, 16 October 2020 (UTC)
@Esprit15d: unsure where you are looking but it appears in User:Ohconfucius/script/MOSNUM dates.js loaded in your commons.js file. Keith D (talk) 20:37, 16 October 2020 (UTC)
@Keith D: It is, but, pardon my ignorance, I thought the fix CAPTAIN MEDUSA suggested above was something editors could fix on their own, and I was having difficulty figuring out how. Perhaps we can't?--Esprit15d • talk • contribs 16:18, 17 October 2020 (UTC)
@Esprit15d: you can by copying User:Ohconfucius/script/MOSNUM dates.js to your own user space and making the change in that copy. You can then load that local file from your commons.js file. Keith D (talk) 17:11, 17 October 2020 (UTC)
Thank you, @CAPTAIN MEDUSA:. @Ohconfucius:, will your incorporate the fix? Kind regards, Robby.is.on (talk) 22:15, 14 October 2020 (UTC)
Thank you, @CAPTAIN MEDUSA:. Appreciate the information. Red Director (talk) 02:02, 15 October 2020 (UTC)
  • thanks for your messages. I have been very busy in RL since before September and have hardly been on WP, so I have not made any changes to the script. All I can say for the moment, if the problem is recent, is that I suspect it may be due to conflict with one or more other scripts. Known conflicts are known to have existed with AutoEd, which may be at fault, or it may be another that I'm not aware of. Best, -- Ohc  04:57, 15 October 2020 (UTC)
@Ohconfucius: I tried turning off all other scripts. Does not fix it. Might be caused by a gadget though. DemonDays64 (talk) 06:26, 16 October 2020 (UTC) (please ping on reply)
@Ohconfucius: Based on the context of CAPTAIN MEDUSA's fix above, I'm thinking that this is an issue with either MediaWiki or the Vector 2020 changes being slowly rolled out. It's still possible that it might be a gadget causing it, but from what I can tell that doesn't seem likely. Nathan2055 19:02, 17 October 2020 (UTC)
Pinging @CAPTAIN MEDUSA and DemonDays64: as well since that message was somewhat replying to them as well. Nathan2055 19:04, 17 October 2020 (UTC)
I have put through the fix kindly provided by User:CAPTAIN MEDUSA, but haven't yet had the time to try it out. I'll get around to it tomorrow. In the meantime, pinging @Lee Vilenski: to check out the fix. -- Ohc  19:30, 17 October 2020 (UTC)
Everything has flooded back onto my sidebar Ohconfucius, fantastic work. Best Wishes, Lee Vilenski 19:39, 17 October 2020 (UTC)
Great to know. Happy editing! -- Ohc  20:09, 17 October 2020 (UTC)

Interface-protected edit request on 19 October 2020

This edit request to User:Ohconfucius/script/MOSNUM dates.js has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

LOVE this script. Could one devise a way to have only a single option? I only use 'DATES to mdy', but this script adds 5 other options to my Tools, such as 'DATES to dmy' and 'BIGENDIAN ref dates.' I think I could copy this script into my own .js, and // slash-out the options I won't use (which seems to be what's already been done with nine options — such as 'ISO to mdy' — and just implement that .js for myself, but I think it might be better to come up with toggle-able options for all to use. —GoldRingChip 16:47, 19 October 2020 (UTC)

 Not done (deactivating immediate edit request as there is not an edit immediately ready to go). @GoldRingChip:, Ohconfucius is certainly welcome to make updates to their script if they would like to; or you can certainly fork it. — xaosflux 16:59, 19 October 2020 (UTC)

Vgrelease new should be removed

Hi @Ohconfucius:

Once upon a time, there was a version of {{Vgrelease new}} which supported date formatting and a "v" parameter for specifying date format. I had long since forgotten this even existed until the script inserted v=2 in this diff. This caused the template to flag the page for bad syntax (unknown parameter), as the current version doesn't have this anymore. Can you please remove any special processing for "Vgrelease", "Vgrelease new", "Video game release new", etc?

Thanks! -- ferret (talk) 00:26, 23 October 2020 (UTC)

Interface-protected edit request on 12 November 2020 - slash dates JS is broken

This edit request to User:Ohconfucius/script/MOSNUM dates.js has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

For me, the entire script breaks at line 30 because the ohc_US_slash_dates_driver and ohc_UK_slash_dates_driver functions are not defined in the script. I think that lines 30 and 31 are supposed to point to ohc_US_slash_dates_to_mdy() and ohc_UK_slash_dates_to_dmy(), respectively, so I request that the correct names be used. -BRAINULATOR9 (TALK) 21:32, 12 November 2020 (UTC)

 Not done (as to an immediate edit request) as @Ohconfucius: is recently active and can update their script as needed. — xaosflux 14:21, 13 November 2020 (UTC)
  • @Brainulator9: Your suggested change has been put through. -- Ohc  20:33, 13 November 2020 (UTC)
    • Thank you! I think I figured out what my real issue is: the script only works if the "Temporarily disable the visual editor while it is in beta" option in Special:Preferences is unchecked. Otherwise, it seems to fail to do what it's supposed to do while in the &action=edit screen. It also appears as if it can never run while in the &veaction=editsource screen, which for me would be the default save for certain circumstances. However, that seems like a much more fundamental issue that would take much longer to resolve. -BRAINULATOR9 (TALK) 01:15, 14 November 2020 (UTC)

dd-mm-yyyy required as a template parameter value

I noticed that the script changes the legitimate value of a parameter in the template {{Almanacco}} which uses |dmy= and expects dd-mm-yyyy. It's normally easily caught by eyeballing the diff, but it would obviously better if the script didn't do that. -- Michael Bednarek (talk) 07:18, 21 November 2020 (UTC)

That template should be rewritten to use the {{#time:}} parser function and to use date formats supported by MOS:DATES. The template splits the date into day, month, and year portions with {{str mid}} templates and then uses a {{#switch:}} to make the dmy date for rendering; ugh. The {{#time:}} parser function can extract the necessary date parts from {{{dmy}}} (represented here with today's date in various MOS compliant forms):
{{#time:d|21 November 2020}} → 21 and {{#time:j F Y|2020-11-21}} → 21 November 2020
{{#time:m|November 21, 2020}} → 11 and {{#time:j F Y|November 21, 2020}} → 21 November 2020
{{#time:Y|2020-11-21}} → 2020 and {{#time:j F Y|2020-11-21}} → 21 November 2020
and it's even backward compatible with the existing non-MOS date format:
{{#time:j F Y|21-11-2020}} → 21 November 2020
So, I would argue that fixes to the MOSNUM script are not required here. I'll fix the template.
—Trappist the monk (talk) 12:21, 21 November 2020 (UTC)

Magazine date ranges

Hi,

I performed this edit and it changed the magazine date from a date range to an actual date. Are date ranges for magazines still allowed?-- 5 albert square (talk) 16:30, 3 December 2020 (UTC)

If the script made that change, it should not do so. Those date ranges were valid per MOS and accepted by the citation template code. – Jonesey95 (talk) 16:40, 3 December 2020 (UTC)
Thanks Jonesey95. Ohconfucius tagging you as may be be an error with the script.-- 5 albert square (talk) 17:07, 3 December 2020 (UTC)

Numeral / short year confusion

The timeline of the COVID-19 pandemic in New Zealand has numerous sentences that start like this: "On DD MMMM, <2-digit numeral> new cases..." The script interprets the two-digit numerals as a year in YY format and thus goes ahead and removes the comma after MMMM. Is there some workaround available for this short of rephrasing dozens of sentences? For example, can the comma be modified so that the script does not touch it? Any ideas gratefully received. Schwede66 18:25, 3 February 2021 (UTC)

Not working

Hi, I've manually installed the script to my common.js file, but I don't see anything in the "Tools" section to the left (even while in edit mode). Is there anything I've done wrong? This is my file: User:Nehme1499/common.js. Nehme1499 15:39, 25 February 2021 (UTC)

Try bypassing your cache-- 5 albert square (talk) 18:42, 25 February 2021 (UTC)
@5 albert square: Nope, nothing. Is it possible one of my scripts is conflicting? Nehme1499 19:37, 25 February 2021 (UTC)
Possibly; you've got (compared to me) rather a few of them there. I don't know/use most of them, but my next step (were I you) would be to copy the contents of the file away somewhere, and start testing with only MOSNUM dates. If it works then, add a few of your other scripts back, test again, add some more, etc., to see what addition breaks MOSNUM dates.
If it doesn't work at all, even alone, then you know something else is wrong. (It's not the script itself, because it's there for me.) Maybe try using other skins? — JohnFromPinckney (talk) 20:00, 25 February 2021 (UTC)
Nothing at all. By skins what do you mean? The .css? It's empty so I don't know what I should do. Nehme1499 20:36, 25 February 2021 (UTC)
No, not the CSS. By "skin" I mean the interface layer, sort of, that defines in part how you see the content of Misplaced Pages. I'm using the "Modern" skin, which I recently learned is quite old (despite its misleading name). I changed to it about a year ago, however, when I realized that the and functionality of collapsible items weren't working for me, and the notifications indicators at the top would light up, but I'd never see any message. So I tried changing from the "Vector" skin, and those problems cleared right up.
After you do the excise-and-readd exercise with the common.js contents, you might try choosing different skins in your preferences and see if that makes a difference. I'm not saying it will, mind you; it's just an idea. — JohnFromPinckney (talk) 21:01, 25 February 2021 (UTC)
I installed your commons.js file and the script seems to be working. I don't think there's a conflict within your commons file as it integrates all elements in your commons file, and I'm not experiencing any problems. It's possible that there may be a conflict elsewhere, if you have installed other gadgets, maybe? -- Ohc  10:16, 26 February 2021 (UTC)
Yes I have a few gadgets from the preferences page enabled. Could it be one of them? Nehme1499 15:10, 26 February 2021 (UTC)
Start by disabling them all. If your scripts work again, reinstate them one by one until you find the one responsible for the conflict. -- Ohc  16:42, 26 February 2021 (UTC)

I've disabled them all, bypassed my cached, but nothing. It doesn't work both in the visual editor and in the edit source (but the other scripts show up, such as DYK check). Nehme1499 16:02, 28 February 2021 (UTC)

New "discovery"

Interesting find: when creating a userpage for a user who doesn't exist, I see "DATES to dmy, DATES to mdy, US-slash dates, UK-slash dates" under "Tools", "Regex editor" under "TemplateScript" and a big bolded "Scripts" at the end of the bar on the left. Might this be of any help? I'm still unable to use the script under normal circumstances. Nehme1499 19:20, 29 March 2021 (UTC)

This actually applies any time I create any page; it still doesn't work when I edit an already-created article though. Nehme1499 17:04, 5 April 2021 (UTC)

Stopped working

Hi,

This seems to have stopped working for me, and it seems to have happened at the time when you made this change, or maybe that's just a coincidence?
SSSB (talk) 14:53, 16 April 2021 (UTC)

Nothing appearing for me now either.-- 5 albert square (talk) 15:48, 16 April 2021 (UTC)

It's working again.
SSSB (talk) 10:54, 17 April 2021 (UTC)

Not loading

I would really appreciate some help getting this script to work, any idea why it won't? Nothing I do gets it to load on the side. @Ohconfucius: Judgesurreal777 (talk) 18:44, 16 May 2021 (UTC)

Not seeing it

The one and only place where the script actually works is when i'm in edit mode on my common.js. After I click publish, the script disappears. I bypassed (or at least I think I bypassed) my cache. Here's my common.js: https://en.wikipedia.org/User:Dr.Swag_Lord,_Ph.d/common.js Dr. Swag Lord (talk) 09:10, 13 June 2021 (UTC)

If I understand you correctly, there is nothing wrong. Indeed, unlike some other scripts, my script only appears when in edit mode. Granted, life would be more convenient if it stays in the sidebar all the time, and I will look at how to achieve this. Regards, -- Ohc  09:15, 14 June 2021 (UTC)
No, you misunderstand. The script only appears in edit mode when I'm on my common.js page. On any other page, when I go into edit mode, the script is not there. Dr. Swag Lord (talk) 21:38, 14 June 2021 (UTC)
Same for me (also when I view the source of other users' common.js pages). Nehme1499 21:40, 14 June 2021 (UTC)
Yep, exactly the same as me^ Dr. Swag Lord (talk) 00:28, 15 June 2021 (UTC)
I loaded both your common.js files successively and the dmy/mdy/slash buttons of the script are there, and they work. I'd just say that with the Dr.Swag Lord/common.js, there's an additional issue where the scrolling function seems to go AWOL. the MOSNUM script is there in both your cases.
Loading problems are usually due to a script conflict. The usual troubleshooting method is to remove all but one script and replace them one by one. As it happens in both your cases, and I managed to get MOSNUM script using your common.js, it could be a conflict with an installed gadget; another troubleshooting method could be to transfer to other skins (e.g. vector.js or mono book.js) -- Ohc  17:05, 15 June 2021 (UTC)

Dr.Swag Lord, Ph.d, Nehme1499, are you using the 2017 wikitext editor, a Beta option? I believe the existing documentation does not cover this. I have to manually disable the new wikitext editor and use the legacy one for the script to appear.  Kylo Ren III  (talk ☎️) 04:13, 13 July 2021 (UTC)

KyloRen3, Yes I am. You're absolutely right. I disabled the new wikitext editor and the script appeared in the source editor. Dr. Swag Lord (talk) 10:04, 13 July 2021 (UTC)
Ohconfucius, can you please add this behaviour on the documentation (and possibly find a fix for this in the future)? Thank you, and great work on the existing scripts.  Kylo Ren III  (talk ☎️) 10:48, 13 July 2021 (UTC)
@KyloRen3: Yep, same for me. Disabling the 2017 wikitext editor "solves" the problem. Nehme1499 13:37, 13 July 2021 (UTC)

Images

Please tighten the script so it leaves images alone, error here. GiantSnowman 21:06, 22 June 2021 (UTC)

So that it doesn't happen again (prior to script tightening), I have removed the date from the file name. Schwede66 21:39, 22 June 2021 (UTC)
Is this issue fixed? It still converts the date in the image filename in Caloocan from Caloocan City Hall, view from commercial complex (Grace Park, Caloocan; 03-21-2021).jpg to Caloocan City Hall, view from commercial complex (Grace Park, Caloocan; Mar 21, 2021).jpg. –Sanglahi86 (talk) 09:05, 26 July 2022 (UTC)
@Sanglahi86 - You have demonstrated that the issue has not been fixed. Thanks for reporting this! GoingBatty (talk) 17:11, 26 July 2022 (UTC)

Incorrectly unlinking years

I saw this edit by Muboshgu using this script, which Sabbatino partially reverted. It seems that unlinking years like ] and ] is incorrect, as its usage in those cases are consistent with conventions of WP:NBA articles. Can you alter this behavior? Thanks.—Bagumba (talk) 16:34, 28 September 2021 (UTC)

But, you have to realize there're some types of pages you should know not to use certain scripts on, such as a article which specific dates, that shouldn't be changed by scripts. - FlightTime (open channel) 17:01, 28 September 2021 (UTC)
Unfortunately, the use of Easter egg links like those are all too common. At the request of the baseball community, I've already softened the script so that it doesn't act on baseball templates, but if the script also ignores links piped to simple years, I fear it would open up a whole can of worms. -- Ohc  09:41, 29 September 2021 (UTC)
I could understand removing links to 2015 or pipes to 2015 in basketball, but 2015 NBA playoffs seems relevant and specific enough.—Bagumba (talk) 09:45, 29 September 2021 (UTC)
A project-specific practice should never overrule a more general guideline like MOS:EGG. There should be no exception in a widely used script like this for such a subset of articles. —Joeyconnick (talk) 06:48, 4 October 2021 (UTC)
No. Year links are generally abused per WP:YEARLINK, linking to a page too general to be relevant. In the NBA case, they're typically linked from an NBA-related page, say an NBA player, and in the cited case it was in a playoff section or next to a reference to a championship, where the links are relevant, not astonishing at all, and even expected.—Bagumba (talk) 14:55, 4 October 2021 (UTC)
I agree that these links should not be modified. There are many thousands of them in article space; it is a common practice that, when used in an appropriate context, is not surprising. This linking practice is used in many sports as well as in film, music, and other subject areas. – Jonesey95 (talk) 17:15, 4 October 2021 (UTC)
I’ve encountered this issue as well and it would be great to have a fix applied. Thank you for this otherwise superb tool. Schwede66 18:30, 5 October 2021 (UTC)

Ohconfucius, I'm resurrecting this thread to add my voice to those requesting a change to this script behavior. When you said above that you "fear it would open up a whole can of worms", do you mean that this would be a tough fix technically, or that you're holding the line out of stylistic opposition to such links? Like others above, big fan of the script and thank you so much! Firefangledfeathers (talk / contribs) 15:48, 18 May 2022 (UTC)

  • I can disable a few regexes, it's easy enough to do. But the overlinking is so endemic that tells me that projects aren't dealing with the problem. There are often literally a hundred such Easter eggs in each one of all too many pages, particularly sporting or athlete articles; I can see that they are used more sparingly other articles (such as film or actors'). These are more often than not what can only be termed "low value links" that dilute other valuable links and that few readers are ever likely to click through on, so complete purging is often called for IMHO. I guess I can leave projects to do what they will, and adjust the script to leave these alone, and I can only urge projects to really "think before you link". -- Ohc  16:31, 18 May 2022 (UTC)
    I'd support such an effort to give the projects a nudge. When I use the script, especially since it automatically marks the edit minor, I'm only looking to make uncontroversial changes. I see evident controversy with the link changes, regardless of where I fall in that debate. Firefangledfeathers (talk / contribs) 16:34, 18 May 2022 (UTC)
    • the reason for the popularity of the script is that it's so useful. Controversy and popularity aren't good bedfellows. All the best! -- Ohc  23:50, 18 May 2022 (UTC)

Edit summary clarification for MOSNUMscript

The current automatic edit summary is this:

date formats per MOS:DATEFORMAT by script

In order to avoid confusion as to what people are doing, I suggest changing it to something like this:

checked article for inconsistent dates per MOS:DATEFORMAT, updated date last checked (by script)

This would make it much more clear what's being done with the script. ···日本穣 · 投稿 · Talk to Nihonjoe · Join WP Japan! 16:53, 6 May 2022 (UTC)

I disagree with this suggestion. The script does more than just check for inconsistent dates - it changes date formats. GoingBatty (talk) 19:15, 6 May 2022 (UTC)
I've now modified it to read script-assisted date audit and style fixes per MOS:NUM. Hope it's a bit clearer, although it is no substitute for fellow editors not reading the script or template documentation. -- Ohc  19:52, 6 May 2022 (UTC)

Note to self:

script glitch at Duke_of_Fife, unwarranted removal of ordinals (without months) when there are two together. -- Ohc  06:58, 7 May 2022 (UTC)

Dates in pre-existing templates

I don't know why this script changes dates in templates like {{EngvarB}} and {{Use dmy dates}} (example diff), but if there is not a very good reason, please can it stop? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:29, 10 May 2022 (UTC)

(talk page watcher) @Pigsonthewing: User:Ohconfucius/script/MOSNUM dates updates the {{Use dmy dates}} maintenance template. User:Ohconfucius/EngvarB updates the {{EngvarB}} maintenance template. This is expected hehaviour. Per Template:Use dmy dates and Template:EngvarB, the date parameter refers to "The month and year that the template was placed or the article was last checked or cleaned (in full)". Kind regards, Robby.is.on (talk) 19:39, 10 May 2022 (UTC)
@Pigsonthewing:: the functionalities of the script are transparent and are fairly well documented. I would invite you therefore to kindly refer to the respective documentation. As to the functioning of the maintenance templates, they are slightly unconventional but are as well documented as the scripts. However, if there are any specific issues caused by the script, you are welcome to make your feedback here. -- Ohc  21:23, 10 May 2022 (UTC)

Stopped working 2

The script has stopped working for me. I can click the DATES to ... link but nothing happens. I'm using Chrome by default but tried in Firefox, with it showing the same behaviour. Given that nobody else has commented yet, but I've had the problem for a few hours by now, I'm wondering whether the hiccup is at my end? The one thing that has changed for me is that I've transitioned to a new iPhone. Any pointers? Schwede66 23:37, 9 June 2022 (UTC)

+1 I posted here earlier. Robby.is.on (talk) 23:41, 9 June 2022 (UTC)
+1=3. No changes that I'm aware of at this end. SchreiberBike | ⌨  00:23, 10 June 2022 (UTC)
+1. Been having problems with more than one script today, actually. I've had the same issue you've described as well as another script (User:Ohconfucius/script/Common Terms.js) not appearing at all. Sunshineisles2 (talk) 02:14, 10 June 2022 (UTC)
I tweaked the script yesterday, so that must be the source of the problem. I'll rewind a step. -- Ohc  07:25, 10 June 2022 (UTC)
Yes, please do. I really miss the script. :-) Robby.is.on (talk) 07:43, 11 June 2022 (UTC)
Any progress on restoring the script? Keith D (talk) 10:35, 11 June 2022 (UTC)
All issues above regarding (User:Ohconfucius/script/Common Terms.js) and (User:Ohconfucius/script/MOSNUM dates) are still an issue on my end. - FlightTime (open channel) 15:41, 11 June 2022 (UTC)
Unable to work out what went wrong, I reverted the changes to try again another way. -- Ohc  17:14, 11 June 2022 (UTC)
Looks like everything is working on my end right now. Sunshineisles2 (talk) 19:23, 11 June 2022 (UTC)
Working for me again too. Thank you. Nothing like absence to make the heart grow fonder. SchreiberBike | ⌨  03:44, 12 June 2022 (UTC)

Improper capitalizing of May

I've seen this script trying to turn strings like "TRAPPIST-1 may" into "TRAPPIST-1 May" at TRAPPIST-1. I figure it's interpreting the "1 may" as a capitalization error? Jo-Jo Eumerus (talk) 10:31, 12 June 2022 (UTC)

  •  Done I have modified the script protection mechanism and I have run the script on TRAPPIST-1, so we can be sure there are no false positives with the string you mentioned. The regex should work more generally, but please let me know if you notice other strings that are incorrectly capitalised. Regards, -- Ohc  22:32, 12 June 2022 (UTC)

Script down?

It doesn't seem to be working for me - I click and simply nothing happens... GiantSnowman 15:03, 18 June 2022 (UTC)

  • I notice that instead of importing the script, you copied the content into your common.js file. The script has evolved somewhat, with some simplification or integration of functionality. I would advise you to simply import the active production script. Remove all the code that you had copied over, and replace with the line

    importScript("User:Ohconfucius/script/MOSNUM dates.js"); -- Ohc  17:15, 18 June 2022 (UTC)

    that seems to have worked, thank you! GiantSnowman 07:50, 19 June 2022 (UTC)
My pleasure. -- Ohc  13:04, 19 June 2022 (UTC)
It appears to be down again? GiantSnowman 18:18, 26 June 2022 (UTC)
I mirrored a change which works with my test script but which unfortunately seems to have failed to transpose to the production script. I have restored the previous version. -- Ohc  20:01, 26 June 2022 (UTC)

Script failing to correct dates

Using "DATES to dmy" option fails to convert any dates to dmy format thought there are some |access-date= in this version of the article History of the Jews in Kingston upon Hull. I had to make the changes manually as all the script suggested was a change to the |date= entry in {{Use dmy dates}} template. Keith D (talk) 13:41, 19 June 2022 (UTC)

Yeah, I had noticed that, too, but didn’t want to be the bearer of bad news yet again. Schwede66 20:49, 19 June 2022 (UTC)
I'm seeing this, too. -- Pemilligan (talk) 21:07, 21 June 2022 (UTC)
Same here. Robby.is.on (talk) 21:30, 21 June 2022 (UTC)
We have Keith D's example article. Are there any others? Dawnseeker2000 21:39, 21 June 2022 (UTC)
Ravi Paranjape Robby.is.on (talk) 21:44, 21 June 2022 (UTC)
RAF Linton-on-Ouse Keith D (talk) 22:12, 21 June 2022 (UTC)
Srikant Datar does some but not others Keith D (talk) 22:20, 21 June 2022 (UTC)
After getting complaints from editors insisting on the validity of ymd dates, I decided to modify the script so that it no longer converts those ymd dates that are embedded within |accessdate=. In these cases, we can rely on the MW software to render into dmy or mdy dates when in display mode. -- Ohc  22:40, 21 June 2022 (UTC)
Is there any way you let users know about these changes so we don't mistake a deliberate change for a script failure? -- Pemilligan (talk) 23:41, 21 June 2022 (UTC)
I'm sorry that the change has caused uncertainty and anxiety. I have reverted the change for now whilst keeping it in my test script. I will update the script documentation for any such changes. Regards, -- Ohc  06:33, 22 June 2022 (UTC)
@Ohconfucius: If you have reverted the script then it is still not working how it was. Please make it do what it should and change all dates to the appropriate selected option, or have appropriate options to do such. Example Charles Hedley. Keith D (talk) 16:13, 22 June 2022 (UTC)
Just now the script wouldn't attach ="df=y" to the birth date template at Bruno Pereira. Robby.is.on (talk) 06:35, 22 June 2022 (UTC)
yes, was coming here to report the same issue - it does not affect the birth template in infoboxes. GiantSnowman 15:59, 22 June 2022 (UTC)
Hi folks: I'd made this edit to Russia where it converted the date= figures but not the access date ones as some of you know. The same is true for the mdy date format as well, as seen in this edit. Not sure if any of you had taken the mdy format into consideration. --Iggy (Swan) (Contribs) 17:23, 22 June 2022 (UTC)
Vladimir Putin as well re dmy. There are plenty of other pages as well. Iggy (Swan) (Contribs) 17:28, 22 June 2022 (UTC)

U-turn

Comma inserted in date range?

The script inserts a comma after the first date: 

Congress granted Duterte's requests to extend martial law in Mindanao from July 22, 2017, to December 31, 2017.

Shouldn't it be: 

Congress granted Duterte's requests to extend martial law in Mindanao from July 22, 2017 to December 31, 2017.

Sanglahi86 (talk) 13:04, 4 August 2022 (UTC)

MOS:DATECOMMA advises that the former is correct. -- Michael Bednarek (talk) 13:41, 4 August 2022 (UTC)

Soccer season articles

In this edit, the script tried to remove the wikilinks to ] and ] - I manually overwrote as the links are valid. Please can you tweak the script so this doesn't happen again? GiantSnowman 19:33, 27 August 2022 (UTC)

This is a very annoying problem. Can anything be done about it? Robby.is.on (talk) 09:28, 20 September 2022 (UTC)

Can it work with Vector (2022)?

I ask as I have installed it but cannot see it in tools - could you check? Thanks Chidgk1 (talk) 06:12, 28 August 2022 (UTC)

  • Sorry I neglected to update the screen grab for the script buttons. The script buttons are still on the sidebar, but further down. For the new positions, see the image here. -- Ohc  15:49, 30 August 2022 (UTC)

Running out of memory (RAM)

Lately I've been having issues with running this script on larger articles (for example Kenneth Branagh). When I run the script I can see in Task Manager the RAM usage going up ~2% a second until it reaches about 90% total utilisation at which point chrome culls all the open Misplaced Pages tabs with a "Not enough memory to open this page" error message. I've tried this on two different PC's now, both in different locations and networks. One has 8GB ram and the other has 16GB but both had this same result.

Smaller articles are also running much slower lately and have the same RAM issue but the script usually finishes those pages before the RAM maxes out and Chrome culls them. Mesidast (talk) 09:21, 20 September 2022 (UTC)

I cannot reproduce this issue with Safari 15.6.1. Running the script on Kenneth Branagh went very quickly for me just now. Robby.is.on (talk) 09:30, 20 September 2022 (UTC)
I tried changing Kenneth Branagh to mdy in Firefox and it took less than three seconds (of course I didn't save), so there must be another problem. SchreiberBike | ⌨  13:18, 20 September 2022 (UTC)
Tested it on Firefox and it takes 21 seconds for me but it is working. Tested it again on Chrome after but it still crashed so I'm guessing it's something more to do with Chrome than the script itself. Mesidast (talk) 15:09, 20 September 2022 (UTC)
21 seconds is a very long time, too, though. On this nine-year-old MacBook Pro the script takes about a second to change all dates to mdy at Kenneth Branagh. Robby.is.on (talk) 15:29, 20 September 2022 (UTC)
Can't explain why it's seizing up for some users, but the variability in user experience suggests to me that it's a platform-related issue. In the early days of the script, before it was such a comprehensive and foolproof tool, execution was rapid and I could have maybe 30 window tabs executing almost simultaneously (using Safari, because it was the lightest and fastest browser for running the script). Now each run may take up to five seconds, and in addition it stalls occasionally and artefacts appear (but that's always been the case). Occasionally, a pop-up message in Firefox asking if you want to continue shows, but which usually disappears after a few seconds as if problem resolved. For me just now, the Kenneth Branagh article was completed in under 2 seconds – I wasn't fast enough but I reckon the edit summary appeared almost instantaneously. But if ever a blockage was serious (this happens quite rarely), I restart the computer while zapping the parameter RAM, with variable results. On the mechanical side, I re-evaluate from time to time the script and simplify the regexes or remove some of the redundant features. -- Ohc  16:54, 20 September 2022 (UTC)

Script error

Adding |df=y to {{birth year and age}}. Since there is no day, there is no df parameter either with this template. MB 16:17, 1 October 2022 (UTC)

  • Looking at it now, I think the OP's suggestion in this thread was based on a false premise, because the template can and does contain full dates. I have therefore reinstated the adding |df=y= parameters to the template. -- Ohc  21:50, 6 October 2022 (UTC)
    No, {{birth year and age}} contains only the year, or optionally year and month. If you use |df=y, there is a template error. MB 22:00, 6 October 2022 (UTC)
    Neither {{birth year}}, {{birth year and age}}, {{death year}}, or {{death year and age}} have df=. Are you mixing these up with {{birth date}} ? MB 22:04, 6 October 2022 (UTC)
    I have reviewed the script code and I did indeed reverse the change I made regarding the {{birth date and age}} template. However I have not found any regex that acts on the {{birth year and age}} template. I therefore didn't do anything one way or another. I shall be grateful if you will show me any instance/diff where my script has added the parameter. -- Ohc  16:44, 7 October 2022 (UTC)
    Is this related to the errors that you've been notifying me about (User talk:Dawnseeker2000#Bad edit)? Dawnseeker2000 23:40, 7 October 2022 (UTC)
    This edit added {{Birth year and age|1981|df=yes}} and the edit summary says this script was involved, which is why a reported it here. This edit by Dawnseeker2000 added |df=y also to make {{death year and age|df=yes|1653|1585}}, but the edit summary says AWB. I find these because I monitor Category:Pages using birth year and age template with unknown parameters daily and fix them. MB 01:34, 8 October 2022 (UTC)
    Alright, thanks for spelling all that out. I'd sure like to take this opportunity to get my end of things straightened out so I don't keep adding to the category. When I see those come up while using AWB, I do undo them, and the ones that you've notified me about were ones that I missed. The script and the software that I use have the same origin with Ohconfucius; it is just implemented in different ways. The code that I use, for example, hasn't been maintained by him for almost a decade, while the stand alone version (this one) is maintained.So, I've done some cleanup in the old (unmaintained code) that I use, but I just need to find the code that changes these templates. I can take a look some time on my weekend (Monday and Tuesday). I may need some suggestions. I'm a amateur at this stuff. Dawnseeker2000 09:09, 8 October 2022 (UTC)
    Well, that was easy enough, but now that I've located the code I am not sure what to do next. The issue that I see is that it's very inclusive. Probably too inclusive. It will add "df=yes" to any of the templates listed in the "find" part of the code listed below, even if the text in the template is listed in plain text in DMY format.(\{\{(?:Birth|Death|launch|release|start|end|film date|Wayback)*\|)I also remembered a dedicated AWB settings file that I had been using that dealt with these templates, but it was way more restrictive and only changed the template if it was in the format of day|month|year (with pipes separating the digits). In other words, it would only add df=yes if it was missing from that arrangement and not if it was in plain text (11 October 2022) or something else (like just a start year and an end year (1896|1968).I had realized that it's possible that we could just start with removing access to the templates that are causing issues, but that would require a rewrite (and the part where the script is really inclusive). So at the moment, maybe we could try to remove the four templates that you'd listed above? Dawnseeker2000 05:40, 12 October 2022 (UTC)
    I have a plan. Instead of disabling or attempting to rework the script on my own, I think I'm just going to use Ohc's four lines of code from the current (MOSNUMDATES) group in my own module to resolve the issues that I'm currently having. The error rate with that one line is quite high; I think that I just got accustomed to undoing the changes all the time. I could potentially do a side-by-side test using a identically-sized group of articles in the dmy space to help validate the changes for the community and myself. I'm pretty sure there's going to be an improvement. I'll respond with the results when finished. Dawnseeker2000 03:06, 19 October 2022 (UTC)
I've done a side-by-side test with my current module and a module with the (newer) group of scripts that handles the date formatting templates from MOS:NUMDATES. I did not note successes; only failures. I ran 100 articles without saving any over the course of about an hour and the results were inconclusive. The error rate was off by just one, and that could easily be attributed to me making a mistake. I was hoping for something better, but there's a lot of ifs, ands, and buts here. Dawnseeker2000 21:58, 8 November 2022 (UTC)

Dates in wikitables – Professional boxing records

This is in regards to your recent edit of the professional boxing record of Davey Moore (boxer, born 1959). I noticed that you changed the dates in Moore's professional boxing record wiki table into the full spelling of each month and used MOS:NUM to justify it. Chronological dates are not mathematical numbers as figures or words and using this section of the manual to justify spelling out each month makes no sense whatsoever. The section of this manual that is supposed to be used when dealing with dates is MOS:CHRONO ITM. As you will see under dates, months, and years, and more specifically, formats, it states that the usage of abbreviated spelling for each month is to be used "only in limited situations where brevity is helpful". The footnote of this statement also specifies said limited situations as meaning, "for use in tables, infoboxes, references, etc...". There have been quite a few people going around trying to spell out the months for the dates of fights in the professional boxing record wiki tables while either not citing any Misplaced Pages manual or using Misplaced Pages:Manual of Style/Dates and numbers to falsely justify it and it's becoming tiresome to randomly find a record affected by this and have to go through and re-abbreviate the months and hoping that other records haven't been changed in the same way. It's a big time waster and it could easily be avoided if people would just read the section of the manual that has to do to with dates and styles, rather than mathematical numbers and statistics. CaPslOcksBroKEn (talk) 18:52, 3 October 2022 (UTC)

Pinging FMSky, who made this edit. GoingBatty (talk) 21:08, 3 October 2022 (UTC)
I agree that within tables, months abbreviated to three letters should be left alone. Should be easy enough for the code to allow for that. Schwede66 21:13, 3 October 2022 (UTC)
yes i was actually going to request that anyway. definitely think that abbreviated months should not be changed, otherwise the script is basically unusable in boxer articles --FMSky (talk) 05:37, 4 October 2022 (UTC)

Infobox error

Please see here - for some reason the birth date in the infobox was not amended? GiantSnowman 15:03, 4 October 2022 (UTC)

That feature was disabled according to this section above. From that discussion it is unclear to me why. Robby.is.on (talk) 15:25, 4 October 2022 (UTC)
That's {{birth year and age}}, The template on the OP's article was {{birth date and age}} - X201 (talk) 15:29, 4 October 2022 (UTC)
Right, but this diff would suggest that formatting of {{birth date and age}} was disabled. Robby.is.on (talk) 15:33, 4 October 2022 (UTC)
Still not working. GiantSnowman 20:44, 14 October 2022 (UTC)
The problem is due to the proliferation of templates. The one used on this article, {{Death date and given age}} is not referenced in my script. I'll take care of it. -- Ohc  19:44, 15 October 2022 (UTC)

The script removed an article wikilink which is piped to just a number representing a year

The following edit correctly made all dates consistent within the article but it also removed a wikilink as well. I don't think it should be the intention to remove links like that since they are correctly linked to the competitions they played in. Iggy (Swan) (Contribs) 14:05, 5 November 2022 (UTC)

Yes, it's annoying. It's the issue mentioned above, Soccer season articles, if I'm not mistaken. Robby.is.on (talk) 15:35, 5 November 2022 (UTC)
Hi yes Robby, I was not aware that has already been discussed but without a fix to the script at present. Obviously the intention is to keep the links indefinitely rather than to manually reinsert them either in a later edit or in the same edit as the script one where you put them back before saving as what GiantSnowman did. Iggy (Swan) (Contribs) 18:08, 5 November 2022 (UTC)
Yeah, when using the script I have been having to check for incorrectly removed links and restore them as needed. It means a lot of extra work. Robby.is.on (talk) 18:20, 5 November 2022 (UTC)
I have now disabled the function in the production script per your request without changing it in my test script. However to my mind, these easter egg links are becoming a greater and greater menace to WP:SEAOFBLUE and it will be up to gnomers like yourselves to exercise discretion in attenuating their excessive use. Regards, -- Ohc  09:31, 6 November 2022 (UTC)

Does not appear anymore

Script used to work flawlessly back in the day, but its buttons do not even show up in the sidebar location now. I have tried re-importing it a couple times, but to no avail. What is the reason for it? Here's a link to my common.js page: . Kind regards, MBlaze Lightning (talk) 07:24, 10 January 2023 (UTC)

If your screen is like mine, it's changed recently after a bunch of discussion that I've not followed. The old sidebar is hidden now and you need to click the hamburger button (size = 60) in the top left. I'm not using the script much these days, but I'd think a fix would be helpful. SchreiberBike | ⌨  15:09, 10 January 2023 (UTC)
The sidebar appears in my screen, and it lists all the typical items save for the foregoing buttons, and that's what had been perplexing me. I tried importing the script all over again, and while that did not immediately make any discernible change, the buttons seem to now show up at bottom of the sidebar in editing window. But yeah I kind of liked them better when they could be accessed easily without having to enter edit. MBlaze Lightning (talk) 21:33, 10 January 2023 (UTC)
I imported your common script, and the MOSNUM script buttons show as they should; when I click on them they work as they are supposed to. -- Ohc  20:38, 11 January 2023 (UTC)

does not work on kn.wikipedia

how do i activate on kn.wikipedia? my attempt at https://kn.m.wikipedia.org/search/?title=%E0%B2%B8%E0%B2%A6%E0%B2%B8%E0%B3%8D%E0%B2%AF:%E0%B0%B0%E0%B1%81%E0%B0%A6%E0%B1%8D%E0%B0%B0%E0%B1%81%E0%B0%A1%E0%B1%81/common.js&oldid=1159283 రుద్రుడు (talk) 11:02, 14 March 2023 (UTC)

First use, first line

The first time I use this script on a page, the template is added as the first line; on subsequent uses on the same page, the template is moved below the Short description (if it isn't already below it). Could it be added after the Short description the first time? -- Pemilligan (talk) 16:29, 14 March 2023 (UTC)

Oh, I see there's already a "Template order" bug report, which is where I should have been looking anyway. -- Pemilligan (talk) 16:35, 7 June 2023 (UTC)

Script is apparently replacing YYYY-MM-DD style dates in citation templates?

Can you please disable the change from "YYYY-MM-DD" format to "DD Month YYYY" in the context of template parameters? The machine-readable YYYY-MM-DD format is significantly better in this context, and the relevant template(s) already know how to present it in a different format to readers. –jacobolus (t) 17:33, 30 March 2023 (UTC)

Seconding this. It's a frustrating issue that negatively impacts the ability to translate citations to other languages. Wracking 16:14, 3 April 2023 (UTC)
Without you tell the script that it is supposed to set |archive-date= and |access-date= to a format different from the format for the publication date in |date=, the script will assume that all dates in a cs1|2 template should have the same format per MOS:DATEUNIFY. For articles that use either of {{use dmy dates}} or {{use mdy dates}}, the script uses the default formatting for all dates in the citation template. Non-default date formatting can be controlled by {{use xxx dates}} templates that use |cs1-dates=. See Template:Use mdy dates § Auto-formatting citation template dates.
—Trappist the monk (talk) 16:50, 3 April 2023 (UTC)
This script should never reformat YYYY-MM-DD dates in template parameters. Replacing these with any other format is a bug which must be fixed. Dates in template parameters must be treated separately from dates in body text. (Indeed, ideally the script would instead always replace any other date format in parameters of citation templates with YYYY-MM-DD format, which is for good reason a broadly adopted standard for machine-readable metadata.) MOS:DATEUNIFY and MOS:DATEVAR do not address this topic, but are only about date formats for the dates in the main body copy of articles and dates written in plain wiki-markup, not about template parameters (the MOS should perhaps be amended to avoid potential confusion). Edit: MOS:DATEUNIFY does explain that Citation Style 1 and 2 templates automatically render dates (|date=, |access-date=, |archive-date=, etc) in the style specified by the "Use" template, regardless of the format they are entered in. See Template:Use mdy dates#Auto-formatting citation template dates. – what this means is that reformatting the dates in template parameters away from YYYY-MM-DD does not accomplish any visible change to the output. –jacobolus (t) 17:38, 3 April 2023 (UTC)
I don't see it as a bug, and I'm glad to see the script unify all the citation date styles. If the case for all citation templates requiring YYYY-MM-DD is strong enough, it should probably be considered for project-wide implementation. Firefangledfeathers (talk / contribs) 17:35, 3 April 2023 (UTC)
(edit conflict)
I'm pretty sure that this, quoted from MOS:DATES#Consistency (which is MOS:DATEUNIFY) does address archive and access dates:
  • Access and archive dates in an article's citations should all use the same format, which may be:
    • the format used for publication dates in the article (see above);
    • the format expected in the citation style adopted in the article; or
    • yyyy-mm-dd
For example, access/archive dates within a single article might be in one, but only one, of these formats (among others):
Jones, J. (September 20, 2008) ... Retrieved February 5, 2009.
Jones, J. (20 Sep 2008) ... Retrieved 5 Feb 2009.
Jones, J. (20 September 2008) ... Retrieved 2009-02-05.
When a citation style does not expect differing date formats, it is permissible to normalize publication dates to the article body text date format, and/or access/archive dates to either, with date consistency being preferred.
which particularly mentions a preference for 'date consistency' which is the default when {{use xxx date}} does not specify how access and archive dates should be rendered.
I do not disagree that all dates in citations, especially in cs1|2 templates, should be written in an ISO 8601-like format but, that is a battle that has already been lost; the month year form YYYY-MM is explicitly disallowed by MOS:BADDATE; ISO 8601-like date-range format (YYYY-MM-DD/YYYY-MM-DD) is not accepted as a valid date format in MOS:DATEFORMAT; and, editors just don't like the YYYY-MM-DD format.
If you think that you can make a sufficiently persuasive argument to change the MOS, WT:MOSDATE would seem to be the place to conduct that discussion, not this user talk page.
—Trappist the monk (talk) 17:57, 3 April 2023 (UTC)
Access and archive dates in an article's citations should all use the same format – this is talking about the human-readable output on the page, e.g. the format used in citations written as plain wiki-markup. How to format template parameters is not explicitly addressed.
Edit: plain wiki-markup citations could write access/archive dates as e.g. {{date|YYYY-MM-DD|dmy}} or {{date|YYYY-MM-DD|mdy}} if the author wants to write numeric-format markup and emit some other date format. –jacobolus (t) 18:08, 3 April 2023 (UTC)
I started a discussion at Misplaced Pages talk:Manual of Style/Dates and numbers § MOS:DATEUNIFY and MOS:DATEVAR should be more explicit about template parameters –jacobolus (t) 18:20, 3 April 2023 (UTC)

Script affecting URL in refs

See this (which I self-reverted). GiantSnowman 12:27, 13 April 2023 (UTC)

Script editing publish, access, and archive dates for refs

Please remove this feature, as seen in edits like this. As mentioned in prior discussions, these dates are already rendered correctly for the reader and these edits make dates no longer machine-readable. Thanks. Wracking  03:59, 30 May 2023 (UTC)

@Wracking: Hi there! Could you please give an example of a machine that you would want to read the dates but is unable to read dates in DD MMM YYYY format? Thanks! GoingBatty (talk) 12:44, 30 May 2023 (UTC)
@GoingBatty: The machine-readability has been brought up by other users so I'm not sure if I'm using the correct language. In my personal experience, these edits significantly hinder translation efforts, as the translator (me!) has to manually translate every single DD MM YYYY date from English to the target language. While translated templates can usually pass over all parameters without issue, English-language dates simply do not work. I'm not sure whether that qualifies as "machine readability" but it is a real pain for me and makes translating refs much more difficult. Thanks! Wracking  12:51, 30 May 2023 (UTC)
@Wracking: Thank you for your response. Note that for a notification to be sent, the link to the user and your signature need to be done in the same edit. When I forget to ping a user and go back to ping them, I also remove my signature and resign my post with the tildes. Thanks! GoingBatty (talk) 15:12, 30 May 2023 (UTC)
@GoingBatty Thanks! I learn something new every day... Wracking  16:51, 30 May 2023 (UTC)
I use CCYY-MM-DD in my own work. To me it is objectively the best and if I were king, I'd make everyone use it. I'm not king, but I've encouraged others to use that format and found that many are incapable. Yes it is better, but requiring people to use it sets the project back severely. They look at it and can see that it's not a telephone number, but they are not sure what it is. They see it and are turned off from editing Misplaced Pages. Almost every date format is machine readable for a reasonably intelligent machine. At this point we should not bow to our computer overlords, but to human fallibility and stick with dd Month YYYY or Month dd, YYYY, which everyone (including machines) can read.  SchreiberBike | ⌨  13:04, 30 May 2023 (UTC)
@SchreiberBike I'm not even requesting to require others to use YYYY-MM-DD; I'm just requesting to not revert the YYYY-MM-DD formatting to English-language formatting. For example, when I recently translated Ice Spice to Spanish using Content Translation, I had to manually rewrite every single Month, dd YYYY publication, access, and archive date. It's tedious and really discouraging for translation work. Maybe there's a bot that could help me with this? ¯\_(ツ)_/¯ Wracking  13:51, 30 May 2023 (UTC)
@Wracking: I apologize. I was responding to you, but thinking about the issue in general. I can not translate at all and know little about it. A global search and replace for January → enero and all the other months should work, though like everything it needs to be done carefully. When I do that sort of thing I use WP:AWB which works well (WP:JWB is also available now, though I've not used it, and it requires no permission). I hope that helps. SchreiberBike | ⌨  16:23, 30 May 2023 (UTC)
@SchreiberBike, no worries. Find & replace works in some cases (DD Month YYYY) but not others (Month DD, YYYY) as Spanish never uses MDY construction and doing so would be grammatically incorrect; ie, "January 1, 2023" has to be turned into "1 (de) enero (de) 2023"; "enero 1, 2023" is incorrect. I'm not sure if there's a script for these cases where the month and day need to be swapped, so I've just done it manually. Wracking  16:49, 30 May 2023 (UTC)
@Wracking:, is it possible to copy-and-paste the English versions into your sandbox, run this tool to change to either YYYY-MM-DD or DD-MM-YYYY, and then translate? Firefangledfeathers (talk / contribs) 16:59, 30 May 2023 (UTC)
  • There was a recent related discussion at WT:MOS/Dates and Numbers/Archive 162#MOS:DATEUNIFY and MOS:DATEVAR shoudl be more explicit about template parameters. The most important issue to me is that the script recognize when the cs1-dates parameter is present, and that it refrain from altering the archive and access date parameters when it is. You can see from David Eppstein's comments there that the script is making inappropriate changes. Ideally, we would all be aware of the possibility that an established, but mixed, style is present (e.g. body dates and publication dates in MDY, archive and access dates in YYYY-MM-DD), and we'd then be cautious in our use of the script. I was unaware of this legitimate option until it was mentioned to me, so I'm looking out for it moving forward. At the least, the script could help in the cases where this mixed use is in the Use XXX dates tag. Firefangledfeathers (talk / contribs) 16:59, 30 May 2023 (UTC)

Discussion at WT:DATE

Heads up—I have posted at WT:DATE about the use of this script in ref dates. See here. Thanks. Wracking  19:48, 12 July 2023 (UTC)

Failure to catch YYYY.MM.DD

The script failed to catch and change "2014.11.14" in the article Candidula lernaea. Please look into it. 〜 Festucalex • talk 11:15, 20 July 2023 (UTC)

Script timeouts on long articles

When running this script on a long article, I get script timeouts that I have to click "Wait" through, and sometimes the load crashes. Is there a way to avoid this? Or can the script code be modified to not trigger the timeout? Stefen Towers among the rest! 19:19, 2 January 2024 (UTC)

I found the culprit. This is a problem with long articles and syntax highlighting is turned on in the editor. Stefen Towers among the rest! 19:10, 17 February 2024 (UTC)

Am I being stupid?

I've got the script installed but its not appearing on my tools? I've used it for ages, its suddenly disappeared?? >> Lil-unique1 (talk) — 21:48, 4 February 2024 (UTC)

@Lil-unique1: I see the script installed at User:Lil-unique1/common.js. When you go to an article and click "Edit source", you no longer see "DATES dmy", "DATES mdy", etc.? Do your other scripts work properly? Did you try bypassing your cache? GoingBatty (talk) 17:07, 5 February 2024 (UTC)

Edit war over updating the date on the maintenance template

I'm in the midst of an edit war at LG with an anonymous user over the script automatically updating the date parameter on the "Use xxx dates" template when performing a date fix. The IP is insisting not to change the date on the template when I see no guideline preventing such change. Are there any outside opinions on this? Jalen Folf (talk) 01:32, 17 February 2024 (UTC)

Support you 100%. All the use xxx dates templates recommend your action. For example Template:Use dmy dates says

The parameter | date= is intended to track the most recent month and year in which an editor or bot checked the article for inconsistent date formatting and, if any inconsistencies were found, fixed them to comply with this template's date formatting preference.

Firefangledfeathers (talk / contribs) 01:45, 17 February 2024 (UTC)
I will need assistance in combating this level of disruption, as I am really close to 3RR at this point. Jalen Folf (talk) 17:59, 17 February 2024 (UTC)
Watchlisted. Firefangledfeathers (talk / contribs) 18:11, 17 February 2024 (UTC)

Affecting references

See this... GiantSnowman 08:57, 24 February 2024 (UTC)

and this. GiantSnowman 08:00, 16 June 2024 (UTC)