Wikipedia:Date formattings/script/MOSNUM dates/bugs

Untitled edit

August, 2007 – July, 2008. Is it possible to get it to remove the commas where there's no date? Tony (talk) 04:26, 11 August 2012 (UTC)[reply]

Haiti edit

<ref>[http://www.usatoday.com/news/world/2008-09-10-Haiti-floods_N.htm UN seeks almost $108 million for Haiti floods]. USA Today (9 October 2010)</ref>

note: seems to treat properly -- Ohconfucius ^{ping / poke} 08:47, 17 November 2012 (UTC)[reply]

Incomplete conversion of abbreviated date strings edit

at Beedi

Comment: Not a bug – script only converts 'clean' dates. -- Ohconfucius ^{ping / poke} 08:50, 17 November 2012 (UTC)[reply]

$amount edit

"$91,000" becomes ",1,000" [1]
some dollar amounts disappear 17 November 2012

Comma between date and an unrelated number edit

USS_Edwin_A._Howard_(DE-346)

Comma removal from an unrelated term and publication year edit

Billaea

Protection edit

protected string not restored

no longer a problem. -- Ohconfucius ^{ping / poke} 08:56, 17 November 2012 (UTC)[reply]

may edit

'may' not always month name

B-2 may cost

spurious comma edit

[2]

Done -- Ohconfucius ^{ping / poke} 03:15, 8 December 2012 (UTC)[reply]

cricket edit

capitalisation of "dec"

Month names in date ranges edit

[3] "January - 1 May 1944" becomes " – 1 January May 1944" — Preceding unsigned comment added by Ohconfucius (talk • contribs) 04:09, 8 December 2012 (UTC)[reply]

Question edit

Hi again! Just wondering why the script updates the date within {{use mdy dates}} and {{use dmy dates}}. I would think it would be more beneficial to indicate that the original decision for the article's date format, not the most recent time someone updated the article. Thanks! GoingBatty (talk) 01:52, 4 June 2013 (UTC)[reply]

These were not designed to be historic markers at the outset, but I guess it could change. Didn't think the original date is all that important since many are changed per WP:TIES – luckily there are next to no contested alignments.
Because of the Wiki contribution model, articles get changed, updated, added to. The thought process up to now is that the tags are changed each time the articles are swept. If a long time has elapsed since it was processed, there are greater chances of format drift needing to be corrected. Hasn't happened yet, but the plan is that, once an automated system gets under way, the 'older' articles can be cleaned up systematically in equally neat batches. -- Ohc ^¡digame!_{¿que pasa?} 02:09, 4 June 2013 (UTC)[reply]

That's an excellent point - thanks for the explanation! GoingBatty (talk) 02:23, 4 June 2013 (UTC)[reply]

Bug report edit

Hi again! On "And I Love Her", your ALL dates to dmy script doesn't change |date= 9/27/11 - could it be the space between the equal sign and the date? Thanks! GoingBatty (talk) 14:36, 6 July 2013 (UTC)[reply]

Also, on Riddick (film), your ALL dates to mdy script doesn't change |accessdate=8.9.12 - is this by design, since it could be 8 September or August 9? Thanks! GoingBatty (talk) 14:50, 6 July 2013 (UTC)[reply]

I seem to recall thinking there was too strong a possibility of false positives with slash dates when the year is stated as two-digit number. The rule as written only converts dates with 4-digit years. You need to click on the separate 'US slash dates' button to convert those. Same goes for the second case, which is worse because it's genuinely ambiguous. -- Ohc ^¡digame!_{¿que pasa?} 14:56, 6 July 2013 (UTC)[reply]

Bug report edit

On the Windows 8 article, the ALL dates to mdy script changes:

(2013-03-26). Retrieved on 2013-07-17.

to

(March 26, 2013). Retrieved on 2013-07-17.

Why doesn't it fix both dates? Thanks! GoingBatty (talk) 23:15, 17 July 2013 (UTC)[reply]

Done It has something to do with the protection mechanism. I've tweaked it now and it should now convert those instances too. -- Ohc ^¡digame!_{¿que pasa?} 02:28, 18 July 2013 (UTC)[reply]

Dates not changed edit

There appears to be a problem with the script when there are two dates that need to be converted in a reference. The script converts the first date only. You can get it to convert both by running the script a second time on the article. I am using all dates to DMY format option. You can see this on this edit that saved without realising one of the dates was not converted. Keith D (talk) 18:59, 12 August 2013 (UTC)[reply]

Done and tested. should work now. -- Ohc ^¡digame!_{¿que pasa?} 07:57, 13 August 2013 (UTC)[reply]

Not loading in toolbox edit

I no longer see the links in my Toolbox for your MOSNUM dates scripts in Firefox 22 and IE10, although I can still see your Fix sources links. I haven't changed User:GoingBatty/vector.js, and tried clearing my cache, upgrading to FF 23, and rebooting. Any ideas? Thanks! GoingBatty (talk) 02:05, 16 August 2013 (UTC)[reply]

I have the same problem and looked yesterday. I think the problem is this change. Keith D (talk) 18:24, 16 August 2013 (UTC)[reply]

May be worth giving Ohconfucius a ping. Keith D (talk) 20:42, 17 August 2013 (UTC)[reply]

Others have already contacted Ohconfucius here and here. User talk:Ohconfucius says he's on a short wikibreak. GoingBatty (talk) 21:12, 17 August 2013 (UTC)[reply]

I have looked at the change and looks like the brackets are unbalanced. I have inserted a bracket in the script and the entries now appear in my toolbox again. Hope this fixes the problem, if not will have to wait until Ohconfucius is back. Keith D (talk) 23:41, 17 August 2013 (UTC)[reply]

Good job! It's fixed. ;) Teammm ^talk
_email 01:54, 18 August 2013 (UTC)[reply]

Firefox Update edit

It seems that the recent Firefox browser update 23.0.1 has stopped me from being able to use the script. Just letting you know. Teammm ^talk
_email 13:37, 17 August 2013 (UTC)[reply]

It's not caused by the Firefox update, as I have the same issue with FF 22 and IE 10 - see section above. GoingBatty (talk) 14:31, 17 August 2013 (UTC)[reply]

I know, I saw it. Thank you. Teammm ^talk
_email

Bug report - "All dates to mdy" adding $1 edit

@Ohconfucius: - Could you please double check this edit? I believe it's now adding a $1 when running the "All dates to mdy" script (e.g. Try Adam Sandler or DC Universe Animated Original Movies. Thanks! GoingBatty (talk) 00:15, 9 September 2013 (UTC)[reply]

Done Er yes, sorry about that. -- Ohc ^¡digame!_{¿que pasa?} 02:56, 9 September 2013 (UTC)[reply]

Suggestion to expand All dates to mdy script edit

Hi Ohconfucius! You may want to expand your All dates to mdy script so it fixes creative formats such as "27th May, 2014" - see History of Firefox#Version 30. Thanks! GoingBatty (talk) 23:12, 25 September 2013 (UTC)[reply]

I've tweaked the script and that line of code works on a regex tester, but I cant fathom why it's not working when live. I'll let it ride for a few edits and will try again maybe tomorrow. -- Ohc ^¡digame!_{¿que pasa?} 03:20, 26 September 2013 (UTC)[reply]

All dates vs. body dates edit

Could you please clarify the difference between the "all dates" vs "body dates" scripts? The documentation states that the "all dates" script changes "dates in the body of the text as well as in the reference sections", so I thought that the "body dates" scripts did NOT change the dates in the reference sections. However, when I ran the "Body dates to mdy" script on United States federal government shutdown of 2013, it wanted to change the body dates and reference dates. Thanks! GoingBatty (talk) 13:15, 1 October 2013 (UTC)[reply]

Talkback edit

Hello, Date formattings. You have new messages at Wikipedia:Gadget/proposals#Please make the MOSNUM dates script into a gadget.
You can remove this notice at any time by removing the {{Talkback}} or {{Tb}} template.

If you reply, then please reply there instead of here. Thank you! —Unforgettableid (talk) 01:59, 28 November 2013 (UTC)[reply]

Suggestion to fix more CS1 errors edit

Would it be possible to expand your wonderful script to detect or fix more Category:CS1 errors: dates issues? I have some examples at User:GoingBatty/CS1 errors dates. Thanks! GoingBatty (talk) 04:29, 2 December 2013 (UTC)[reply]

As you know, I already have a MOSNUM script that mostly works on dates. I ran it on your examples and you can see what it does there. This work will have to be shared between the MOSNUM and SOURCES scripts. The problem is to determine the boundary between these scripts. I'll do some thinking to see where these rules can properly fit. Regards, -- Ohc ^¡digame! 05:35, 2 December 2013 (UTC)[reply]
- I've now incorporated most of the changes, split between the two scripts. Those that involve manipulating dates will be found in the MOSNUM script whilst those more general fixes or those involving only formatting are in the sources script. See how you get along with them being where they are. Regards, -- Ohc ^¡digame! 07:46, 2 December 2013 (UTC)[reply]
- Thinking out loud here, I think the removal of the {{Start date}} template might work outside of citation templates, but the harm done is minimal as there is possibility under Lua for metadata to be gathered from infoboxes. As to the removal of parentheses, I'm tempted to broaden it for all parameters as I don't really see where such can be useful. What do you think? -- Ohc ^¡digame! 14:41, 2 December 2013 (UTC)[reply]
  - Thanks so much for updating your scripts! I think there are people passionate about having {{Start date}} in infoboxes, so you might get some feedback if you start removing them. I can't think of a reason why any citation parameter would need to start and end with parentheses. Thanks! GoingBatty (talk) 01:11, 6 December 2013 (UTC)[reply]
    - At last count, there was one metadata-gatherer, his loyal supporter and his trusty steed ;-). Unfortunately, hundreds of infobox templates have instructions to place them inserted by the former. But the advance has been stopped dead in its tracks at least for the moment. I'm looking forward to them realising at last that the less cumbersome methods of gathering can be had through Lua without those ugly templates that people don't understand. -- Ohc ^¡digame! 01:46, 6 December 2013 (UTC)[reply]

Rotten Tomatoes score edit

Would you be interested in expanding your ALL dates to mdy script so that it would add |mdy=y to {{Rotten Tomatoes score}}? See 20 Feet from Stardom as an example where this would be useful. Thanks! GoingBatty (talk) 03:04, 21 December 2013 (UTC)[reply]

cite journal / contribution= edit

Happy New Year... just made a fix to my scripts due to a new one with {{cite journal}} this. You might need to test and adjust your script accordingly. Dl2000 (talk) 16:12, 1 January 2014 (UTC)[reply]

Thanks, I've now adjusted the relevant script. Season's greetings to you. -- Ohc ^¡digame! 15:09, 2 January 2014 (UTC)[reply]

Bug report - removes pp-move template edit

Hi Ohconfucius! When I run the All dates to dmy script on Upendra, the script wants to remove {{pp-move|expiry=2014-07-13 17:51:53|small=yes}}. Is this by intent, or is this a bug? Thanks! GoingBatty (talk) 18:32, 13 January 2014 (UTC)[reply]

I would not intentionally remove such a tag. Will look into the problem. Regards, -- Ohc ^¡digame! 03:05, 14 January 2014 (UTC)[reply]

I've tested both the production and test scripts, and neither removes the template. I also loaded your vector.js file, but the alleged removal of the template doesn't happen either. -- Ohc ^¡digame! 03:16, 14 January 2014 (UTC)[reply]

Hmmm - Maybe I was reviewing this edit, and then decided to edit the article, but instead clicked the "undo" link. If then I clicked on the All dates to dmy script, it would have appeared that your script was removing the template, whereas instead it would have been my error. Thank you for confirming your script is working as designed! GoingBatty (talk) 04:16, 14 January 2014 (UTC)[reply]

Phew!!! <wiping the sweat off my brow> Thanks for fessing up! -- Ohc ^¡digame! 04:59, 14 January 2014 (UTC)[reply]

Potential unwanted DEFAULTSORT refactoring edit

Might want to test the script regarding {{DEFAULTSORT: - for some reason, the DEFAULTSORT on Composed upon Westminster Bridge, September 3, 1802 has a tendency to be hit with a refactor, possibly due to embedded punctuations and the like. Dl2000 (talk) 15:33, 1 February 2014 (UTC)[reply]

Possible bug edit

I clicked on "Body dates to mdy" with this edit, and it caught only the one dmy date. I ~~did "ISO to mdy"~~ tried again in a second edit, and it caught all of the ISO dates. Not sure what that was about. – Muboshgu (talk) 15:12, 3 February 2014 (UTC)[reply]

No, my bad. "ISO to mdy" doesn't seem to work. – Muboshgu (talk) 15:47, 3 February 2014 (UTC)[reply]

Hi, from your two diffs, the script seems to be working according to design. The "Body dates to mdy" button ensures consistency by removing all instances of dmy dates anywhere in the article in favour of mdy. But because some editors prefer their reference dates in yyyy-mm-dd format, the "Body dates to mdy" button respects this preference by not flipping yyyy-mm-dd dates within references. Editors who deliberately want to convert all dates into mdy should click the two buttons as you did. The short cut for that is to click on the "all dates to mdy" button. I don't understand what you said about the "ISO to mdy" button not working, unless you made these changes manually. The "ISO to mdy" button will take all yyyy-mm-dd dates, mainly in the reference section, and convert them into mdy dates. You will find a more detailed description of the script actions at the documentation page. -- Ohc ^¡digame! 16:07, 3 February 2014 (UTC)[reply]

Template - Video game release edit

Hello, could you make the script work with the Template:Video game release template please. - X201 (talk) 10:40, 12 February 2014 (UTC)[reply]

Yes, will do. -- Ohc ^¡digame! 12:53, 12 February 2014 (UTC)[reply]

Thanks. - X201 (talk) 16:56, 12 February 2014 (UTC)[reply]

Not working edit

This tool does not seem to be working for some reason on this page. I'm trying to convert all dates to the dmy format but no matter how many times I try, I see no difference between the changes. I've tried clicking "ALL dates to dmy" and "Body dates to dmy" multiple times, but none of them has so far worked. Smtchahal (talk) 14:10, 21 February 2014 (UTC)[reply]

I loaded your vector file into mine to test. I have the sidebar buttons noted on the left side, and both of the two buttons you refer to in the script seem to work. So the problem at your end is not related to loading the script, nor to problems with the script itself. Another user had similar issues last week, and apparently solved it by going over to monobook skin. I don't understand why one should work but not the other. But by all means try if that works. -- Ohc ^¡digame! 15:47, 21 February 2014 (UTC)[reply]

It worked for me on Highway (2014 Hindi film) - are you having an issue just with that article or with every article? Good luck! GoingBatty (talk) 17:10, 21 February 2014 (UTC)[reply]

Good point, Batty. Smtchahal, you are suggesting that you have the buttons but they don't work for Highway. The script has not changed since 13 February. It seems that you installed the script on 20 February, and your contributions show no edit summary generated by the script, so I assume the script hasn't worked for you at all.

As I said, I loaded your vector.js, so I'm using effectively what you're using. I have the buttons, and it executes and seems to work correctly. When you click the button, do you get an edit summary and a diff? And if you don't get a diff, what do you see when you click on the 'Show changes' button? -- Ohc ^¡digame! 02:03, 22 February 2014 (UTC)[reply]

I do see the script buttons as shown in the screenshot in this script's documentation, and I do see an automatically generated edit summary ("date formats per [[WP:MOSNUM]] by [[WP:MOSNUMscript|script]]") when I click one of those, but I see "no difference" between the revisions. Clicking Show changes doesn't help either. Also, I tried the same thing with my sandbox without any success. Smtchahal (talk) 06:50, 22 February 2014 (UTC)[reply]

I'm not sure what did it, but I moved the script from my /vector.js to /monobook.js, then reverted it, using quotation marks instead of apostrophes, and it worked. Smtchahal (talk) 07:47, 22 February 2014 (UTC)[reply]

I'm pleased to hear you succeeded through perseverance. I really can't explain the phenomenon and would put it down to "gremlins". Hope you find the script useful. Regards, -- Ohc ^¡digame! 10:30, 22 February 2014 (UTC)[reply]

Use of ALL dates to mdy removed period after month abbreviation in book title within ref tags edit

On the page Senkaku Islands the use of "ALL dates to mdy" resulted in the removal of a period from the title of the book The Journal ... aboard the Argonaut from April 26, 1789 to Nov. 3, 1791,. This title is contained within <ref>...</ref> and is in italics. The problem is reproducible with the current version of the page. The script appears to already special case italicized text in ref tags such that the "Nov" is not expanded. The removal of the period just needs to be included within that special case.

I have not actually looked at the code to see what would be required to do so. When using something titled "ALL dates to mdy", I expect a human will need to check such changes and make any corrections. I probably would not have reported this as a "bug" if it did not appear there is already code written to prevent expansion of month names in this context.

Thank you for making this script available. It will be quite useful. --Makyen (talk) 03:09, 26 February 2014 (UTC)[reply]

@Makyen: That's why it's in a script and not a bot. Scripts require manual scrutiny by definition, whereas bots are meant to be infallible. I think this is one of those rare cases that depends on human vigilance. As far as writing rules for the script goes, this sort of change is unavoidable. Usually, book titles are protected by the script, as are all strigs within double quote marks. However, as the title in this instance is bounded by single quotes and not double quotes (correctly italicised and formatted), and the citation is a plain one existing outside of {{citation}} templates and its brethren (ie there's no |title= to define it), the date got changed. Although I know some people dislike citation templates (I'm one of them), I would suggest putting such special cases within a date in the title inside a {{cite book}} template. -- Ohc ^¡digame! 17:02, 23 March 2014 (UTC)[reply]

@Ohconfucius: I certainly expect there is a need for human vigilance when using this script. I am fine if there are no changes to the script as a result of this report. I still have not taken a look at the code. Thus, I am not sure what method(s) you are using to protect any section of the text, or to parse the wikitext.

However, this specific issue appears to be deterministic, and not all that rare. The additional determining factors would be: inside <ref>...</ref> and in italics. It is probable that inside <ref>...</ref> and bold should also be protected. Off hand, I can not think of a situation where either combination is used where one would want the date to be changed. I can think of a few where the date should not be changed. — Makyen (talk) 00:57, 24 March 2014 (UTC)[reply]

I would be pleased to have your feedback and specific changes in the rules and code. Regards, -- Ohc ^¡digame! 01:06, 24 March 2014 (UTC)[reply]

Please exclude singlechart template from script edit

Hi Ohconfucius! Could you please exclude the {{singlechart}} template from your script? Converting yyyy-mm-dd dates breaks reference 81 in Imagine (song). Thanks! GoingBatty (talk) 16:24, 23 March 2014 (UTC)[reply]

Protection enlarged for now, hopefully it will be effective. -- Ohc ^¡digame! 16:49, 23 March 2014 (UTC)[reply]

This is still causing an issue on Imagine (John Lennon song). GoingBatty (talk) 11:37, 23 October 2014 (UTC)[reply]

Feature request - fix dd mmm, dd yyyy format edit

Hi Ohconfucius! Would you be willing to update your date scripts to convert dates in "dd mmm, dd yyyy" format? (e.g. Carleton University has "27 February 27, 2012" and two others in this format) Thanks! GoingBatty (talk) 09:28, 25 March 2014 (UTC)[reply]

sure. I've been going through some of those cs1 errors to see what I can automate. This is certainly one of them. I'll just code it up to remove one set provided they are identical. -- Ohc ^¡digame! 09:58, 25 March 2014 (UTC)[reply]

Request to protect another proper name: Observance of 5th November Act edit

Hi Ohconfucius! Per User:Ohconfucius/script/MOSNUM dates#Known limitations, could you also please protect the text "Observance of 5th November Act"? (See Guy Fawkes Night for an example of an article that your ALL dates to dmy script currently changes.) Thanks! GoingBatty (talk) 02:23, 29 April 2014 (UTC)[reply]

Done Thanks. I've now protected the string in the script. However, I don't know how protection works in AWB, and I can't change your bot module. -- Ohc ^¡digame! 02:32, 29 April 2014 (UTC)[reply]

Thanks for the quick response! I was only asking you to change your script. I submitted a separate bug report for the AWB developers. GoingBatty (talk) 02:35, 29 April 2014 (UTC)[reply]

Bug report: Expand all dates doesn't do so edit

Hi Ohconfucius! When I run your Expand all dates script on Holy Terror (graphic novel), it does not change reference 13 from "Sep" to "September" as I expected. When I decided to RTFM at User:Ohconfucius/script/MOSNUM_dates#Overview, it says that Expand all dates will Expand month names elsewhere within the article while Expand ref dates will Expand month names within the references section. I don't see link called Expand ref dates (or links for ISO to dmy and ISO to mdy). Is the documentation lagging behind the functionality? Am I doing something wrong? Thanks! GoingBatty (talk) 22:14, 25 May 2014 (UTC)[reply]

Thanks for spotting that example of non-conversion. This is because the block quote was protected from script actions. I've now amended the order of execution. As to the 'Expand all dates', I don't recall. I may have run into false positives that made me disable it and I subsequently omitted to fix. I'll work on it. I decided to remove the independent 'ISO to dmy' and 'ISO to mdy' functions to reduce clutter. As there is the benefit of comprehensiveness without any perceptible time penalty, I was thinking one would logically run the full script. -- Ohc ^¡digame! 02:11, 26 May 2014 (UTC)[reply]

Thanks - it works just fine now. I took the liberty of commenting out the ISO to dmy and ISO to mdy text on User:Ohconfucius/script/MOSNUM_dates#Overview. GoingBatty (talk) 04:27, 26 May 2014 (UTC)[reply]

Could you please check it again? it doesn't seem to work on Johor Darul Takzim F.C. (specifically the "Dec" in the Johor Darul Takzim F.C.#Head Coach history section). Thanks! GoingBatty (talk) 13:40, 26 May 2014 (UTC)[reply]

Oh, it wasn't set up to do month–year ranges. Now working on it. Once the test regexes have proven stable, I will update the production script. -- Ohc ^¡digame! 02:54, 27 May 2014 (UTC)[reply]

Suggestion for Accessdate to YYYY-MM-DD edit

Hi Ohconfucius! When I run your Accessdate to YYYY-MM-DD script on Islam in Russia, it doesn't change the |accessdate=June 27 2014 value. Could you please consider tweaking your script so that it will make the change whether the comma is there or not? Thanks! GoingBatty (talk) 16:01, 30 June 2014 (UTC)[reply]

Done thanks for the great suggestion! -- Ohc ^¡digame! 04:47, 1 July 2014 (UTC)[reply]

Request to add support for Template:Death date and age edit

Hi Ohconfucius! Could you please expand your "All dates to dmy" script so that it would add |df=yes to {{death date and age}}? See Eva Beem for an example where this would be helpful. Thanks! GoingBatty (talk) 02:22, 23 October 2014 (UTC)[reply]

Done. Think I've patched it. Simple case of aligning it to my test script. Cheers! -- Ohc ^¡digame! 08:09, 23 October 2014 (UTC)[reply]

Confirmed - thanks! GoingBatty (talk) 11:33, 23 October 2014 (UTC)[reply]

Oops - while it worked great on Eva Beem, it now adds an extra |df=yes in {{Wayback}} templates on Imagine (John Lennon song). GoingBatty (talk) 11:38, 23 October 2014 (UTC)[reply]

@Ohconfucius: Could you please check the script again? It isn't adding |df=yes to {{Death date and age}} (or {{Birth date}}) on Charles Piguet. Thanks! GoingBatty (talk) 16:25, 25 April 2020 (UTC)[reply]

@Ohconfucius: Same problem with {{Birth date and age}} at Casper Janebrink. Thanks! GoingBatty (talk) 17:40, 25 April 2020 (UTC)[reply]

@Ohconfucius: Confirmed that it now works on Casper Janebrink. Thanks for the quick service! Hope you are doing well. GoingBatty (talk) 22:20, 25 April 2020 (UTC)[reply]

Bug report - Film date template edit

Hi Ohconfucius! When I run your ALL dates to dmy script on A Most Wanted Man (film), it wants to put an extra |df=yes parameter in the {{Film date}} template, even though it already contains |df=y at the end. Thanks for your continued work on these scripts! GoingBatty (talk) 14:56, 14 December 2014 (UTC)[reply]

Tip for using comments to prevent commas being deleted edit

Running the script on 2014 Sydney hostage crisis to check dates were in DMY format, the script proposed to delete the comma in the following:

During the raid on 16 December, 34-year-old hostage Tori Johnson...

Presumably, the script mistook "34" for the year (even though it was hyphenated) and sought to remove the comma where it would not belong in DMY format; however, the comma is needed to separate the age from the date where this might otherwise be confusing to parse the sentence. I assume this is too advanced for the script to distinguish. I found the solution was to insert a hidden comment:

During the raid on 16 December,  34-year-old hostage Tori Johnson...

With the comment in place, the script did not attempt to remove the comma. —sroc 💬 13:29, 18 December 2014 (UTC)[reply]

`|year=` vs. `|date=` citation usage edit

It seems users of your script are incorrectly replacing |year= with |date=. Please review Template:Citation Style documentation#date to readjust your script, and review the other Template:Citation Style documentation parameters to make sure they are all up-to-date. Thanks. ~ Tom.Reding (talk ⋅contribs ⋅dgaf) 14:07, 11 January 2015 (UTC)[reply]

Script breaking DOI values? edit

Seppi333 claims to be using this script to fix dashes and other items. In this edit, either the script or the human editor changed a hyphen within a DOI value into an en dash, which broke the DOI link and resulted in a red error message.

If this is a script bug, can you please fix it? Thanks. – Jonesey95 (talk) 18:43, 13 January 2015 (UTC)[reply]

@Jonesey95: Hmm, normally I check to see if scripts screw up anything when I use them. Must've missed that when I scrolled through. In any event, this isn't the right script in that message; User:GregU/dashes.js is the correct one, as I used 2 scripts in 1 edit. Seppi333 (Insert 2¢ | Maintained) 18:50, 13 January 2015 (UTC)[reply]

Sorry, OhC, wrong venue.

Seppi333, I believe (based on having seen this bug before) that User:GregU/dashes.js fails to ignore DOIs, even though there is a comment to that effect in the code. If you use that script, give the preview a quick scan for DOI values. Thanks. – Jonesey95 (talk) 18:59, 13 January 2015 (UTC)[reply]

Thanks, all. -- Ohc ^¡digame! 03:24, 14 January 2015 (UTC)[reply]

Incorrectly removes film link edit

Hi, in this edit the script incorrectly removes a link to the film article 22nd of May. Keith D (talk) 14:18, 15 January 2015 (UTC)[reply]

@Keith D:The string "22nd of May" is now protected. Sorry for having omitted to notify you. -- Ohc ^¡digame! 05:45, 14 May 2015 (UTC)[reply]

Page number incorporated into a date edit

https://en.wikipedia.org/w/index.php?title=Devils_Tower&diff=prev&oldid=662116609 mistakenly incorporated a page number into a date format (very last item in the edit.) SpinningSpark 10:18, 13 May 2015 (UTC)[reply]

Thanks. I'll have a think. Not quite sure how to handle those, except to preformat page numbers and ranges to terminate with semicolon. I usually change those commas manually to semicolons. -- Ohc ^¡digame! 10:24, 13 May 2015 (UTC)[reply]

Adding semicolons would be bad, unless that is already the established style on the page. Separating fields with commas is very common and a standard way of presenting references, including on many featured articles. SpinningSpark 10:40, 13 May 2015 (UTC)[reply]

I also sometimes change them to full stops. that's how citation templates display. Any ideas what we can tweak the script to do, User:GoingBatty? -- Ohc ^¡digame! 05:43, 14 May 2015 (UTC)[reply]

Which part of your script has this code? GoingBatty (talk) 05:12, 15 May 2015 (UTC)[reply]

Changing to full stops or semicolons? I do that manually. -- Ohc ^¡digame! 14:22, 15 May 2015 (UTC)[reply]

Hows about something like this to automatically replace commas after page numbers with full stops? -- Ohc ^¡digame! 07:07, 16 May 2015 (UTC)[reply]

Per WP:CITEVAR that is not something that should be done automatically. SpinningSpark 07:25, 16 May 2015 (UTC)[reply]

Original text	Modified text
`New York Times, p.25, 7 October 1941.`	`New York Times, p.October 25, 7, 1941.`

Why is [number1], [number2] [month] [number3] being changed to move the month before number1 anyway? Shouldn't the script recognise that the date starts with number2 and ignore everything before the preceding space? There is obviously never going to be such a date as "25, 7" in any month. —sroc 💬 07:51, 16 May 2015 (UTC)[reply]

@Sroc:Due to my general lack of any programming skills, I would appreciate it if someone could help me build in such a logical check into the script. -- Ohc ^¡digame! 06:54, 17 May 2015 (UTC)[reply]

@Ohconfucius: I'm no expert on this coding, but it looks like this is the relevant section:

    //convert date ranges (d,d,d-dmy to md,d,d-dy; d,d,d-dm to md,d,d-d; dm,d,d to md,d,d)
    ohc_regex(/(\D\W)@Day((?:, @day){0,5})(\/|\s?(?:[-–]|–)\s?|\s(?:and|&|to|or)\s+?)@Day\s@Month,? @YYYY(?=\W\D)/gi, "$1@LMonth @Day1$2$3@Day2, @YYYY");

It looks like the script interprets 25, 7 October 1941 as a date range (25–7 October 1941). Is that right? If so, why does it treat 25, 7 as a range? —sroc 💬 11:10, 17 May 2015 (UTC)[reply]

It doesn't interpret it as a date range; the comma is preserved and no dashes are inserted. That regex is meant to operate on the body of text, where often we have an event that takes place over several days that are not necessarily consecutive. -- Ohc ^¡digame! 11:45, 17 May 2015 (UTC)[reply]

You mean as in "25 and 7 October 1941"? —sroc 💬 12:14, 17 May 2015 (UTC)[reply]

Or "7 and 25 October 1941" or "6, 7, 25 October 1941". -- Ohc ^¡digame! 13:56, 17 May 2015 (UTC)[reply]

Does anybody ever write that, though? I could understand writing "7 and 25 October 1941" or "6, 7 and 25 October 1941"; but not "7, 25 October 1941" or "6, 7, 25 October 1941". Without "and", it doesn't look like anything anyone would write in English. If anyone ever did, it would be so unusual as to require a re-write needing manual intervention to deal with it effectively.

I don't think the script should pick up such strings with a series of comma-separated numbers without "and" or "&" (or similar) included. Can this perhaps be dealt with using separate rules: one that ignores comma-separated lists of numbers, another that deals exclusively with comma-separated lists of numbers with "and"/"&" before the second-last? This would distinguish "7 and 25 October 1941" from "p.7, 25 October 1941". —sroc 💬 15:53, 17 May 2015 (UTC)[reply]

Now that you've explained it, I tend to agree. I've now disabled those lines of the regex. Regards, -- Ohc ^¡digame! 02:32, 18 May 2015 (UTC)[reply]

—sroc 💬 07:53, 18 May 2015 (UTC)[reply]

Suggestion: Rotten Tomatoes score edit

@Ohconfucius: Could you please change your "ALL dates to mdy" script so that it will update {{Rotten Tomatoes score}} with |mdy=y? For an example where this would be helpful, see The Babysitters. Thanks! GoingBatty (talk) 17:35, 25 July 2015 (UTC)[reply]

@Ohconfucius: I see you've kindly added "Rotten tomatoes score" to your script, but it's not working on The Babysitters. Does your script need to be case sensitive to fix {{Rotten Tomatoes score}}? Thanks! GoingBatty (talk) 04:11, 18 January 2016 (UTC)[reply]

No. It's not case sensitive. I see no {{Rotten Tomatoes score}} template. -- Ohc ^¡digame! 08:27, 18 January 2016 (UTC)[reply]

@Ohconfucius: Ah, sorry - The Babysitters uses the redirect {{rots}}. GoingBatty (talk) 15:19, 18 January 2016 (UTC)[reply]

Suggestion to expand script to fix doi_brokendate field edit

Hi Ohconfucius! Could you please update your All dates to mdy/dmy scripts to also update the {{cite journal}} |doi_brokendate= field? (See Berry for an example of where this could be used.) Thanks! GoingBatty (talk) 13:59, 11 August 2015 (UTC)[reply]

Bug report edit

@Ohconfucius: When I run your "ALL dates to mdy script" on Paul Heyman, it wants to change "On the June 2 edition of..." to "On the edition of June 2 of..." Could you please let me know when this is fixed? Thanks! GoingBatty (talk) 13:36, 12 August 2015 (UTC)[reply]

@Ohconfucius: This appears to be fixed - thanks! GoingBatty (talk) 01:22, 8 November 2019 (UTC)[reply]

Suggestion for As of template edit

@Ohconfucius: Would you like to update your scripts so they change the {{as of}} |df= parameter? I've done it manually in this edit to the PlayStation 4 article. Thanks! GoingBatty (talk) 15:20, 31 December 2015 (UTC)[reply]

Suggestion for Allmusic template edit

@Ohconfucius: Would you like to update your scripts so they change the {{Allmusic}} |accessdate= parameter? See 30th Anniversary Tour: Live for an example. Thanks, and Happy New Year! GoingBatty (talk) 03:39, 3 January 2016 (UTC)[reply]

@Ohconfucius: Could you please reconsider this request? Thanks! GoingBatty (talk) 01:18, 8 November 2019 (UTC)[reply]

@GoingBatty: My scripts are not template specific nwhen searching for accessdate strings, so it ought to work. I can't for the moment see why it hasn't picked up that parameter. I'll keep looking, but do let me know if you can see an error in the script. -- Ohc ^¡digame! 15:24, 8 November 2019 (UTC)[reply]

Not changing "as of" intentional? edit

See here what I did manually after I realized the script missed the template. I guess "as of" could be in a quote. That is however independent of whether a template is used or not, but probably less likely that "as of"-template is used in one? If you have logic to exclude quotes, for non-templates, then I assume it could also work for templates.

Anyway thanks for the script, that has saved me a lot of time, while it could be improved. Just good to know then that there is an exception. Maybe they are or should be documented? — Preceding unsigned comment added by Comp.arch (talk • contribs) 14:31, 13 January 2016 (UTC)[reply]

@Comp.arch: I made the same suggestion in the #Suggestion for As of template section above. I hadn't thought about it possibly being used in quotes. GoingBatty (talk) 00:07, 14 January 2016 (UTC)[reply]

Bug report: Script does not fix access-date parameter edit

@Ohconfucius: Could you please tweak your script so it also fixes |access-date= in citations? (e.g. Tony Oursler) Thanks! GoingBatty (talk) 21:07, 16 January 2016 (UTC)[reply]

@Ohconfucius: Confirmed this works now - thanks! GoingBatty (talk) 04:00, 18 January 2016 (UTC)[reply]

Request to include airdate parameter edit

@Ohconfucius: Could you please expand your script to change dates in the {{cite episode}} |airdate= parameter? For an example, please see "Hotel California". Thanks! GoingBatty (talk) 13:36, 19 January 2016 (UTC)[reply]

@Ohconfucius: Could you please reconsider this request? Thanks! GoingBatty (talk) 01:16, 8 November 2019 (UTC)[reply]

@Ohconfucius: I see you added the |airdate= parameter in your script, but it's still not making the fix in this article. Where's the section that converts ISO to mdy? Thanks! 00:58, 9 November 2019 (UTC)[reply]

Duplicate edit summaries edit

I thought that this might sort of fix it; it did not. The edit summary from the script should only be appended if it is not already there. Examples:

when switching formatting to dmy then to mdy both before submitting the form
when adding ##-##-## dates after using the script but not submitting the form then using the script again to fix said dates

Results if use twice before submitting:

date formats per [[MOS:DATEFORMAT]] by [[WP:MOSNUMscript|script]], date formats per [[MOS:DATEFORMAT]] by [[WP:MOSNUMscript|script]]

—User 0 0 0 name 19:28, 12 May 2016 (UTC)[reply]

Changes reverted as WP:MOSDATE violation edit

See this diff. I'm sure there are other such instances; this page just happens to be on my watchlist. --Thnidu (talk) 16:41, 17 May 2016 (UTC)[reply]

Sorry, @Thnidu: I don't see the problem. The 20 other instances of access dates were in dmy. The script edit merely aligned 3 occurrences of yyyy-mm-dd dates among the access dates; they ought not to coexist. -- Ohc ^¡digame! 20:43, 25 July 2016 (UTC)[reply]

Archive date treated as publication date edit

Archive dates should be treated the same as access dates per MOS:DATEUNIFY: "Access and archive dates in an article's citations should all use the same format, ...", but the script treats them as publication dates and converts them to mdy/dmy when using the "Body+pub dates" links. nyuszika7h (talk) 10:42, 17 July 2016 (UTC)[reply]

Bug report: access 2 ISO does not fix access-date parameter edit

Hi Ohconfucius! Could you please update your "access 2 ISO" script so that it will also fix |access-date= parameters? (e.g. see Ferrero Rocher). Thanks! GoingBatty (talk) 19:17, 21 July 2016 (UTC)[reply]

Tweaked. I hope it works now. -- Ohc ^¡digame! 20:27, 25 July 2016 (UTC)[reply]

Bug report: Script changes trans-title parameter edit

Hi Ohconfucius! Could you please tweak the "All dates to dmy" script so it does not change the {{cite web}} |trans-title= parameter? (see 2016 Munich shooting) Thanks! GoingBatty (talk) 03:51, 25 July 2016 (UTC)[reply]

I see that there's one instance changed. I could protect it so it doesn't attack the contents of the trans-title parameter. I can see it's not desirable to go changing any dates in the |title=, only that example isn't undesirable. What am I missing? -- Ohc ^¡digame! 20:27, 25 July 2016 (UTC)[reply]

@Ohconfucius: I cannot replicate the issue. Thank you for any change you may have made! GoingBatty (talk) 01:13, 8 November 2019 (UTC)[reply]

Abbreviated month edit

Hi there, this is a brilliant tool! Just spotted a little bug, though. With this edit running ALL dates to dmy, the output showed "23 Jan 2009" and I manually changed it to "23 January 2009" before saving it. Schwede 66 09:59, 8 January 2017 (UTC)[reply]

Template:birth year and age edit

According to Jonesey95, the df=yes parameter isn't supported in this template. Schwede 66 06:26, 6 February 2017 (UTC)[reply]

Not according to me. According to the documentation and the template's code. – Jonesey95 (talk) 15:07, 6 February 2017 (UTC)[reply]

Yes, @Schwede66:someone pointed that out to me recently. It was adding the template parameter due to some careless coding. I have now amended the script. Regards, -- Ohc ^¡digame! 10:36, 7 February 2017 (UTC)[reply]

Script stopped working? edit

I've been using this script since 2013, rather successfully (thank you for that), but today when I tried to use it to edit List of Islamist terrorist attacks, the date-related links didn't appear in the toolbox on the left side of the screen. (The flag-related links from flagcruft.js did, though.) I thought it might have to do with the fact that most of that article consists of tables, so I tried editing Black Lives Matter, but I experienced the same problem. I disabled all my other scripts, to see if there might be a conflict. No luck. (My scripts are in User:Malik Shabazz/vector.js) Maybe a recent change to one of the gadgets? I'm afraid I can't—or rather won't—test each gadget I have enabled to test for conflicts. I'm running Firefox 51.0.1 on Windows 7, I disabled WikEd. Any suggestions would be appreciated. Thank you. — Malik Shabazz ^Talk/_Stalk 19:32, 19 February 2017 (UTC)[reply]

Date within archive-url reformatted edit

Thought you'd want to know that this script-assisted fix broke a reference in Buriganga River by converting the format of a date within an archive-url. I've fixed the article. --Worldbruce (talk) 22:12, 28 February 2017 (UTC)[reply]

Same problem with this recent edit to Amar Desh. The archive-url

https://web.archive.org/web/20130623070950/http://www.daily-sun.com/index.php?view=details&archiev=yes&arch_date=16-04-2013&type=Amar-Desh-goes-off-the-press&pub_no=469&cat_id=1&menu_id=1&news_type_id=1&index=12

was date-converted into the invalid url:

https://web.archive.org/web/20130623070950/http://www.daily-sun.com/index.php?view=details&archiev=yes&arch_date=16 April 2013&type=Amar-Desh-goes-off-the-press&pub_no=469&cat_id=1&menu_id=1&news_type_id=1&index=12

. A fix to the script would be appreciated, as Ohconfucius is making script-assisted fixes on a lot of pages. --Worldbruce (talk) 06:30, 14 March 2017 (UTC)[reply]

Heads up edit

I've just raised this for discussion. You may be interested. LeadSongDog come howl! 20:00, 18 August 2017 (UTC)[reply]

Changes to notices at top of articles edit

Hello there! First off, I'd like to give a huge thanks for creating this script. I use it on almost every article I come across when I'm doing the first edits. I have just found a bug however. When User:RMCD bot leaves a notice on an article, it will usually leave a link to the discussion, such as Talk:Burbank–Bob Hope Airport station#Requested move 15 May 2018. However, when changing to mdy and using anything but the BIGENDIAN option, this script changes the date, therefore breaking the link. Maybe this could be solved by detecting that it's surrounded by noinclude tags? Thanks! –Daybeers (talk) 07:44, 15 May 2018 (UTC)[reply]

Date format error edit

Script appears to incorrectly add date format, as seen in this edit. James (^talk/_contribs) 15:35, 18 June 2018 (UTC)[reply]

Changing from dates in the format dth, m, y edit

In this edit, I ran the script using "ALL dates to mdy" and dates like "17th, March, 2016" are changed to "17th, March 2016", only removing the second comma. The correct output should be "March 17, 2016". LightKeyDarkBlade (talk) 08:37, 5 July 2018 (UTC)[reply]

MOSNUM dates script removed date parameter from Template:clarify edit

Just want to report that the script did something I never saw it do before. I caught before saving so I don't have a diff but it happened on Today's featured article: Battle of Verrières Ridge. I used All dates to dmy.--- Coffeeandcrumbs 02:57, 19 July 2018 (UTC)[reply]

Nevermind, this was a false report. It was an edit conflict.--- Coffeeandcrumbs 02:59, 19 July 2018 (UTC)[reply]

removal of non-breaking spaces edit

Hi. I'm not sure if this is your script or part of AWB, or just the particular editor, but in this diff non-breaking spaces ( ) were removed from dates. This use of non-breaking spaces is to avoid awkward line-wraps separating the day from the month. Thanks for your attention. – Reidgreg (talk) 16:08, 17 August 2018 (UTC)[reply]

Does not handle templates correctly edit

At least two bugs are evident in this edit:

The "use mdy dates" template had its date stamp updated by the script. No-one, including the script, should modify cleanup template date stamps if those date stamps were correct. To modify them creates a misleading result.
That particular date stamp, since it refers to precisely the cleanup that the script is supposed to perform, should probably have been deleted by the script, if the script executed successfully across the rest of the page.

Zazpot (talk) 00:54, 12 September 2018 (UTC)[reply]

Uh. "Use mdy dates" is suppose to be updated whenever someone has verified/checked that all dates match the format, including by script. The script is correct to update the date there. You should read the documentation at Template:Use mdy dates. The template is not a "cleanup" template, it is a maintenance template that should remain in the article to inform others of the date format in use. -- ferret (talk) 01:14, 12 September 2018 (UTC)[reply]

Sorry, you're quite right. I was confusing it for a cleanup template. Thanks for correcting me. Zazpot (talk) 01:29, 12 September 2018 (UTC)[reply]

Invalid parameter being added edit

Hi, this script appears to have been incorrectly adding |df= to {{start-date}} and {{end-date}} (e.g. this recent edit by The Rambling Man). The parameter doesn't exist in those templates. Jc86035 (talk) 11:03, 1 November 2018 (UTC)[reply]

df removal edit

Hi, the script now removes |df= when it is set to something, could this be extended to remove the unset blank entries as well to clean things up. Regards. Keith D (talk) 12:00, 14 November 2018 (UTC)[reply]

Changes within titles edit

The Rambling Man just ran this script on Lilias Armstrong where it changed |articlename=London, May 19 to |articlename=London, 19 May within Template:Cite newspaper The Times. This should not have beeen done. Umimmak (talk) 20:22, 8 December 2018 (UTC)[reply]

Bug edit

For some reason, when I go to edit a page, the links don't show up unless I refresh. I tested it a bit, and it seems like they only check to show up once, when a page loads, but not later if you enter edit mode. I suggest checking when the access key to edit is pressed, and/or when you click "edit," in addition. --DannyS712 (talk) 06:24, 15 January 2019 (UTC)[reply]

Running the script fixes the output, but not the actual wikicode edit

Hi,

I ran the script here: [4] and everything looks fine in the output, but if you look at the current revision, [5] by searching the wikicode for "2018-", for example, the dates are still numbers instead of the actual month and date. Thanks! David O. Johnson (talk) 22:00, 9 July 2019 (UTC)[reply]

@David O. Johnson: The script doesn't need to update the citation dates because the citation template now obeys the "Use mdy dates" template at the top. So while the template contains 2018-mm-dd, it will display MMM dd, 2018. -- ferret (talk) 22:45, 9 July 2019 (UTC)[reply]

Thanks for the quick reply. David O. Johnson (talk) 22:52, 9 July 2019 (UTC)[reply]

Thanks to you both. -- Ohc ^¡digame! 10:28, 10 July 2019 (UTC)[reply]

Using the script produces strange characters edit

Hi, I recently used the script to fix date formatting and I got these weird characters. You can see them at the bottom of the page here: [6]. Here's the previous revision so you can see what the differences are: [7].

Here is what the characters look like:

⍌190⍍

⍌191⍍

Thanks for any assistance! David O. Johnson (talk) 05:15, 4 August 2019 (UTC)[reply]

@David O. Johnson:, what you are seeing is simply the result of a stalling of the script, where the protected strings haven't been restored by the time you see the changes displayed on screen. It happens occasionally. In such a case, you should abandon the edit by refreshing the edit window, and then click on the script button again. Hope that helps. Regards, -- Ohc ^¡digame! 09:28, 4 August 2019 (UTC)[reply]

Thanks for the quick reply! David O. Johnson (talk) 20:54, 4 August 2019 (UTC)[reply]

Non-breaking spaces edit

This script currently strips non-breaking spaces in dates, such as July 4 or July{{nbsp}}4 (displays as July 4). MOS:NBSP recommends them where breaking across a line would be awkward, which is especially the case when separating numbers from the rest of the date. Removing them is thus not MOS-conforming. Because the need depends on context, it is probably best for the script to leave them untouched; treat the various ways of inserting non-breaking spaces just like a regular space. Kim Post (talk) 19:27, 13 August 2019 (UTC)[reply]

Replacing file names which contain dates edit

A recent edit to War of 1812, said to be done using this script, broke four images on the page. Each image had a file name containing a date, which is presumably why the script interacted with them. --Noren (talk) 00:42, 16 August 2019 (UTC)[reply]

1996 United States Senate elections edit

Can't get script to work for 1996 United States Senate elections. The attempted change is here. Some of the dates are in refs using {{cite …}} so maybe that's the problem? —GoldRingChip 12:43, 3 September 2019 (UTC)[reply]

Please refer to the thread above. -- Ohc ^¡digame! 17:35, 3 September 2019 (UTC)[reply]

Indeed. Thanks. —GoldRingChip 18:00, 3 September 2019 (UTC)[reply]

`|year=` vs. `|date=` citation usage (over 4.5 years later) edit

@Ohconfucius: over 4.5 years ago, far above @ #year vs. date citation usage, I brought this up, but apparently nothing has changed. The script still favors |year= over |date=, see the top of this diff. Template:Cite journal/doc#Date makes very clear when |year= is to be used. This has been the case for at least as many years. Please update. ~ Tom.Reding (talk ⋅dgaf) 01:41, 13 September 2019 (UTC)[reply]

@Tom.Reding:Thanks for the comment. I have reviewed the code but cannot find the regex responsible for the change. It seems that the change you pointed to may have been the result of the action of the user who replaced the template. I could not find any systematic changes (to any other yyyy-mm-dd string) that mey indicate that it was the result of script action. If you have any other examples that demonstrate more obviously that it is a script error, please let me know. Regards, -- Ohc ^¡digame! 08:21, 13 September 2019 (UTC)[reply]

Script changes superscripts to @ edit

@Ohconfucius: When I try to run your "DATES to dmy" script on Toon Tunz, it wants to change superscripts like "5^th" to "5@th". Could you please let me know when this is fixed? Thanks! GoingBatty (talk) 01:09, 8 November 2019 (UTC)[reply]

Thanks, it should be fixed now. -- Ohc ^¡digame! 15:25, 8 November 2019 (UTC)[reply]

@Ohconfucius: I think you made the edit to the test script, but it wasn't included in your edit to the production script. Could you please double check? Thanks! GoingBatty (talk) 00:31, 9 November 2019 (UTC)[reply]

You're right. Thanks for keeping me on my toes! -- Ohc ^¡digame! 09:27, 9 November 2019 (UTC)[reply]

Ignore formatting within quote templates edit

Per this edit, it would be best if the script ignores any content within any quotation templates. MIDI (talk) 14:01, 4 December 2019 (UTC)[reply]

Removal of nbsp from dates edit

Regarding this edit, I am advised by User:GiantSnowman (in effect) that the user of a script bears no responsibility for the results, so any complaints should be referred to the script's author. I would strongly disagree since (1) scripts are not vetted by the community and (2) the use of any script is entirely a matter of choice.

But I'll disregard that and ask the same question I asked them: How is it better to allow a line break between month and day? ―Mandruss ☎ 12:38, 19 December 2019 (UTC)[reply]

Where did I say I am not responsible for the edit?! What a ridiculous thing to suggest. What I said (in effect) was that I don't have the foggiest as to why the script has been designed in that way. Giant Snowman 12:40, 19 December 2019 (UTC)[reply]

The point is that (in my view) you should have either defended the removal of the nbsp's or self-reverted that part of the edit. That's what responsibility for the edit means. ―Mandruss ☎ 12:46, 19 December 2019 (UTC)[reply]

No it does not. Was the nbsp aspect negative/detrimental? No, hence why I left it unchanged. Giant Snowman 14:56, 19 December 2019 (UTC)[reply]

Yes, removal of the nbsp's was detrimental because it reversed the efforts of some other editor who went out of their way to prevent line breaks between those months and those days. Preventing those line breaks is objectively a benefit and it's exactly the kind of thing nbsp exists for in the first place. Unless there is a reason to remove those nbsp's that that outweighs that benefit, it's detrimental by definition. You could not give that reason, and in fact you stated above that you have no idea why the script does that. ―Mandruss ☎ 18:38, 19 December 2019 (UTC)[reply]

Interesting discussion. The use of the nbsp is but a "style thing". Having them within dates does not serve any meaningful purposes as writing of dates within articles is widespread, and how they display depends on too many parameters, such as type of device, browser used, size of typeface. I am however aware that some wditors are fond of using these, and so these days I never use the script (or advocate its use) in such articles where dates are uniformly spaced using same, because such use usually means that some editor(s) has taken extreme care over how the dates are formatted, and there is invariably no benefit in running the script. However, I would run the script if the nbsp are inconsistently or spasmodically used on any given article: there is everthing desirable in removing them to make date formats (within edit mode as well as in display mode) uniform per WP:MOSNUM. -- Ohc ^¡digame! 21:17, 19 December 2019 (UTC)[reply]

@Ohconfucius: Thanks for the prompt response.

First, what you would do or advocate is of little relevance to what other editors do with your script. Few of them know, and few of those care what you would do or advocate. In any case, please point me to the specific part of MOSNUM that says an article should either uniformly allow or uniformly disallow line breaks within dates. To my mind, that is lowest-common-denominator reasoning, and consistency should never be our first priority – i.e. inconsistently better is preferable to consistently not-better regardless of the issue (Wikipedia is a work in progress). No reader is going to be alarmed or even notice when an article line-breaks dates only part of the time, so there is absolutely no real-world rationale for that approach. This is typography, not style, and as far as I know nbsp, being a long-supported element of HTML, works as intended regardless of type of device, browser used, or size of typeface. ―Mandruss ☎ 22:35, 19 December 2019 (UTC)[reply]

@Ohconfucius: You've been editing a lot since my ping above. If you are through discussing this with me (ie "I've responded, accept what I said or not as you will"), I'd appreciate you saying that rather than leaving me to guess. I could then decide whether it's worth my time to take this to the community for comment. ―Mandruss ☎ 13:05, 23 December 2019 (UTC)[reply]

@Mandruss: By definition, a manual of style serves to mandate a certain uniformity. Dates are pervasive in articles, occur in different places in an article, using different browsers and different devices, making consistency of placement of non-breaking spaces an important factor for them to be useful – there's little point in "nbspacing" some dates and not others. Notwithstanding, MOSNUM makes no pronunciation of their use within date strings, nor does WP:NBSP. I'd add that inserting the nbsp within date strings decreases accessibility for other editors in general and newbie editors in particular, who may be discomfited by the html or template clutter. By all means seek to widen the discussion. -- Ohc ^¡digame! 19:42, 25 December 2019 (UTC)[reply]

Strongly disagree on multiple fundamental points, so I guess there's no point in continuing here. ―Mandruss ☎ 20:10, 25 December 2019 (UTC)[reply]

Mandruss wrote, "removal of the nbsp's was detrimental because it reversed the efforts of some other editor who went out of their way to prevent line breaks between those months and those days. Preventing those line breaks is objectively a benefit". This is a flimsy argument; editors go out of their way for all kinds of strange edits, with marginal rationales. If preventing those line breaks is "objectively a benefit", we should cite a discussion that backs that up, and hopefully a discussion of what's the best way to get that benefit. The use of html magic is abhorrent to some, merely confusing to others; in this case, a date template would seem to be a better way to go if preventing that line break is enough of a benefit to warrant editor action. 12.39.147.66 (talk) 21:38, 24 December 2019 (UTC)[reply]

Hi, I don't respond to comments from one-edit IPs. Do you have an account? ―Mandruss ☎ 01:10, 25 December 2019 (UTC)[reply]

@Mandruss: Seems like a silly rule. If a comment is pertinent, what's the problem? I'd advise you to concentrate on the substance of the comment, not the form. -- Ohc ^¡digame! 19:44, 25 December 2019 (UTC)[reply]

If it seems like a silly rule to you, don't use it. ―Mandruss ☎ 20:10, 25 December 2019 (UTC)[reply]

I don't think our paths have ever crossed before. I should thank my lucky stars -- Ohc ^¡digame! 23:06, 25 December 2019 (UTC)[reply]

Until something better is developed (like option-space for Mac, and whatever for Windows), the ungainly clutter in edit-mode needs to be balanced against the rare occasions in which a date wraps onto the next line (and the very minor disruption for readers when that happens). New editors must be particularly turned off by that clutter. Tony (talk) 00:34, 26 December 2019 (UTC)[reply]
By that argument, we should also get rid of the refs which clutter up the text in the edit window. – Reidgreg (talk) 13:22, 13 January 2020 (UTC)[reply]
This issue has been pestering me since August 2018 (above) and has been a known bug/flaw in the script for going on four years (User talk:Ohconfucius/script/MOSNUM dates § script is adding regular spaces after nbsp template). I know that this is a valuable and useful script, but I've seen it abused which wastes a lot of time in discussions and sorting through full or partial reverts. True, most articles don't use non-breaking spaces in dates, but I tend to apply these to mature articles as they reach GAN and FAC. This is a painstaking manual process, which the script undoes on an industrial scale. MOS:NBSP is a guideline with community consensus, this script removes these article improvements and should own up to that fact. I feel that User:Ohconfucius/script/MOSNUM dates should prominently note this in the sections Known limitations and Disclaimers. I feel that's the least that should be done, to try to make script users aware of the issue and their responsibilities. – Reidgreg (talk) 13:22, 13 January 2020 (UTC)[reply]
- I've now tweaked the script for the non-breaking spaces. Let me know if there are problems. -- Ohc ^¡digame! 20:44, 24 February 2020 (UTC)[reply]

Script not running edit

The script was running yesterday but today, the links do not appear in the sidebar. Not an issue with extensions (haven't installed or enabled anything) or browser (use Chrome, but have also checked Firefox). Is this problem unique to me or are others also having this problem? Schwede 66 19:09, 24 February 2020 (UTC)[reply]

Same problem on my end.--Sunshineisles2 (talk) 19:37, 24 February 2020 (UTC)[reply]

This is possibly related. There was a syntax error in this change, a missing single quotation mark in the last modified line. – Jonesey95 (talk) 19:51, 24 February 2020 (UTC)[reply]

Thanks. Found it and fixed it. -- Ohc ^¡digame! 20:03, 24 February 2020 (UTC)[reply]

Thanks, it's working now.--Sunshineisles2 (talk) 20:42, 24 February 2020 (UTC)[reply]

Tools items don't match documentation edit

Thanks for the script. I've installed it and it is adding the following to my Tools section on the LHS:

DATES to dmy
DATES to mdy
BIGENDIAN ref dates
Expand ref dates
Expand all dates

This is significantly different than what's documented at User:Ohconfucius/script/MOSNUM dates. Am I missing something? ~Kvng (talk) 16:18, 20 May 2020 (UTC)[reply]

It's a case of documentation failing t follow the evolution of the script. Will update in due course. -- Ohc ^¡digame! 08:46, 27 May 2020 (UTC)[reply]

Let me know if I can help in any way. ~Kvng (talk) 14:43, 30 May 2020 (UTC)[reply]

@Kvng:Thank you very much for the offer. In fact, it would be great if you could update the documentation for me.

-- Ohc ^¡digame! 13:12, 1 June 2020 (UTC)[reply]

Revised. Correct or let me know if there are any problems with my reverse engineering. ~Kvng (talk) 20:25, 1 June 2020 (UTC)[reply]

Many thanks! -- Ohc ^¡digame! 09:05, 2 June 2020 (UTC)[reply]

Script not working on DMY dates for the month of May? edit

I had to fix the dates in this revision of C/2019 Y4 (ATLAS) manually because the script apparently didn't recognize them. There isn't any weird formatting involved with these dates ("31 May") and the problem seems to be fixed when I change them to a different month. Ionmars10 (talk) 14:41, 26 May 2020 (UTC)[reply]

Thanks for letting me know. I've been looking at the issue with the script for the last hour or so, but the issue is curretly eluding me. I think I'll need to work through the entire script. -- Ohc ^¡digame! 19:23, 26 May 2020 (UTC)[reply]

@Ionmars10: Isolated the problem with a bit of perseverence. Faulty protection mechanism was the cause; now disabled. Test here -- Ohc ^¡digame! 08:25, 27 May 2020 (UTC)[reply]

Script does not activate edit

The script does not activate for me except when creating a redlinked page. That is the only time I see "DATES to dmy", "DATES to mdy", "BIGENDIAN ref dates" ... etc. in the LHS toolbar. I have disabled every single gadget (I had 16 active) but apparently none of them were the source of the conflict. Elizium23 (talk) 14:07, 3 June 2020 (UTC)[reply]

I found the culprit - it's the Beta Feature "New Wikitext Mode". Unfortunately the script does not work for the case I needed it for: dates in the format of "2019.05.20" are not recognized. Elizium23 (talk) 14:17, 3 June 2020 (UTC)[reply]

@Elizium23:In which articles is this type of string found? I don't think it's very common, but I can write a throwaway regex to fix the issue in an ad hoc manner. -- Ohc ^¡digame! 15:18, 3 June 2020 (UTC)[reply]

Ohconfucius, Roman Catholic Diocese of Makurdi for example. It is endemic in obscure Catholic Diocesan articles for succession lists of bishops, because they are copied direct from a certain website. Elizium23 (talk) 16:08, 3 June 2020 (UTC)[reply]

@Elizium23:I've just created this new script. See how you get along with it. -- Ohc ^¡digame! 16:42, 3 June 2020 (UTC)[reply]

Ohconfucius, thanks! Several trial runs working like a charm. This will really aid me when editing such articles. Is this mine to keep as a separate import, or are you thinking of folding it into the main script? Elizium23 (talk) 16:49, 3 June 2020 (UTC)[reply]

@Elizium23: Thanks for your feedback. The scriptis for you to use to your heart's content

. I'll be keeping this as a separate script for now, but may revisit this depending on the extent of the issue. I've edited such articles before, preferring to make the odd run of one-off regex because I suspect it's not widespread, but I could be wrong. I can see that there is a risk of false positives if this part if the script is let loose on all articles. -- Ohc ^¡digame! 19:18, 3 June 2020 (UTC)[reply]

Note to self: bug example (line 2) edit

January 5–6, 2012 Nigeria attacks, around 37 Christians are targeted and killed by Boko Haram militants.
April 16 - 2013 Baga massacre, 187 people are killed in Baga in Borno State. It is unclear whether the Nigerian military or Boko Haram is responsible for the massacre.
June 18, 2009: Al-Shabaab claimed the 2009 Beledweyne bombing, which killed 35 people including Somali security minister Omar Hashi Aden.

DMY in Start date template edit

The script seems to have lost the ability to add the df=y flag to the {{Start date}} template. It still works the other way around, happily removing df=y to convert to mdy format. Can you have a look at it please. Thanks. - X201 (talk) 07:45, 23 September 2020 (UTC)[reply]

Draft:Mark Morrissey edit

Hi Ohconfucius! When I run your US-slash dates script on Draft:Mark Morrissey, it changes 9/22/20 to September 22, 1920. Could you please consider changing the script so it would change the date to September 22, 2020 instead? Thanks! GoingBatty (talk) 03:23, 21 January 2021 (UTC)[reply]

MOS:ORDER edit

When running the script on a page that doesn't have a date variety template and has a short desc template, the script will add the date variety template above the short desc template, which is against MOS:ORDER. Bait30 ^{Talk 2 me pls?} 04:05, 24 January 2021 (UTC)[reply]

Removing Date template edit

The script is removing the Date template from dates like this {{Date|2020-09-28|DMY}}, leaving behind plain text 2020-09-28. See Series 2 of Ghosts for a real life example. - X201 (talk) 07:29, 13 April 2021 (UTC)[reply]

Removing the closing markup of hidden text in a ref template edit

Notified to me by @Modulus12: - this edit where it removed the closing markup (but not the opening!) of hidden text in a ref template, breaking the reference and the rest of the ref list. Giant Snowman 07:17, 16 April 2021 (UTC)[reply]

Installed it and it will not show up edit

I cleared my gadgets, deleted all other scripts, kept purging, and nothing. I'd love some help getting this up and running as I keep getting asked by GA reviewers to standardize date formatting and it is so tedious! :) Judgesurreal777 (talk) 18:14, 16 May 2021 (UTC)[reply]

@Judgesurreal777:There's a script conflict. I got it to load after disabling Wikipedia:AutoEd/complete.js. It might be the same issue as mentioned in the script documentation. -- Ohc ^¡digame! 19:52, 16 May 2021 (UTC)[reply]

@Ohconfucius: The strange thing is, it doesn't show up unless I'm in edit mode on my script page... They are all there then, but when I'm in an article there's nothing. Judgesurreal777 (talk) 20:03, 16 May 2021 (UTC)[reply]

It ain't misbehavin', then. It's en editing button, and you need to be in edit mode to see it. But it should appear in edit mode for all pages,not just your script page. -- Ohc ^¡digame! 20:06, 16 May 2021 (UTC)[reply]

And that's the thing @Ohconfucius:, it only appears on the scripting page in editing mode, it doesn't show up in editing mode anywhere else... Judgesurreal777 (talk) 20:19, 16 May 2021 (UTC)[reply]

So I click edit, refresh the page, and the tools appear, but I click them and they don't do anything, so I looked on this page and unclicked the new wikitext format beta option and now it works! Thank you so much for your guidance!! Judgesurreal777 (talk) 21:29, 16 May 2021 (UTC)[reply]

You're welcome! -- Ohc ^¡digame! 16:27, 17 May 2021 (UTC)[reply]

df=yes? edit

In Special:Diff/1023800933 I expected the script to add df=yes to {{Start date and age}}. I did it in a subsequent edit instead, but should the script have done so? -- ferret (talk) 12:30, 18 May 2021 (UTC)[reply]

Template order edit

Currently, User:Ohconfucius/script/MOSNUM dates adds a template like {{Use mdy dates|date=July 2021}} to the very beginning of a page, if no {{Use xxx dates}} template is already present. Unfortunately, MOS:ORDER tells us to put {{Short description}} first, then hatnotes, then FA/GA, and maintenance templates. A lot of users don't know any better, and leave the template where the script adds it (first). Is is possible to make a change to the script to respect the order of templates already on the page? (Keep in mind: there's no guarantee the extant templates are in the right order themselves.) I don't know what's impossible/doable-but-hard/easy-as-pie, but I thought I'd suggest this little improvement. IAC, thanks for the great tool; I use it quite a lot. — JohnFromPinckney (talk / edits) 00:20, 4 July 2021 (UTC)[reply]

Thanks for the very useful script, which I mainly use for unlinking overlinked dates ([[1]] [[January]] [[1970]] etc.). I came here to make a similar request about SD (and see #MOS:ORDER above). I hope it's as simple as amending line 791 to replace ^({{short description|.*?}})? by $1{{Use ..., modulo a few \ and \s*. Certes (talk) 13:34, 24 August 2021 (UTC)[reply]

User:Ohconfucius, is there any chance of you getting around to addressing this? I've seen no reply either here or up at this section from January. Or have you already decided not to implement such an improvement? Thanks,— JohnFromPinckney (talk / edits) 00:57, 9 October 2021 (UTC)[reply]

I put in the necessary lines of regex for that some time ago, but I haven't had the time to test it to any degree, nor have I had any comments about it one way or another. So it isn't working? -- Ohc ^{revolution of our times} 07:43, 9 October 2021 (UTC)[reply]

Thanks, but no, it's not. I asked here again because I noticed in the last day or two that it was still placing the Use...dates template first, and I just did a quick test a few minutes ago, with the same result. — JohnFromPinckney (talk / edits) 22:25, 10 October 2021 (UTC)[reply]

I just tripped over this again, as I used the script four hours ago, then remembered I had forgotten to reorder the templates. User:Ohconfucius, can you find time for this? — JohnFromPinckney (talk / edits) 03:48, 15 December 2021 (UTC)[reply]

This script is saving me hours of work and I sure appreciate it. I'm still getting the result described above though. I'd love to see it follow MOS:ORDER among the templates at the top of the page, especially adding the {{Use mdy dates}} or {{Use dmy dates}} template below {{Short description}}. Thanks for the work. If there's anything I can do to help, please let me know. SchreiberBike | ⌨ 02:22, 15 January 2022 (UTC)[reply]

Adding df parameter to Cite tweet edit

Hi Ohconfucius! I noticed that {{Cite tweet}} will display a date even if a |date= parameter is not populated. Unfortunately, your wonderful scripts don't currently align the date format with the rest of the article. Could you please consider updating your scripts to add a |df= parameter if there isn't a |date= parameter? (e.g. this edit) Thanks! GoingBatty (talk) 15:46, 23 September 2021 (UTC)[reply]

Stop script from changing ref titles edit

Would it be possible to have the script ignore dates in the titles of references?

example: https://en.wikipedia.org/w/index.php?title=Nikos_Dendias&diff=1046097192&oldid=1046093992

the bot changed "title=el:Κυβέρνησις ΚΩΝΣΤΑΝΤΙΝΟΥ Α. ΚΑΡΑΜΑΝΛΗ - Από 19.9.2007 έως 7.10.2009" to "title=el:Κυβέρνησις ΚΩΝΣΤΑΝΤΙΝΟΥ Α. ΚΑΡΑΜΑΝΛΗ - Από 19 September 2007 έως 7 October 2009", which i had to manually revert

thanks

FMSky (talk) 23:25, 24 September 2021 (UTC)[reply]

Bug report with ⍌????⍍ edit

There is something wrong with this edit. "September 11 attacks" was changed to "⍌1301⍍", "File:Taliban Humvee in Kabul, August 2021 (cropped).png" to "⍌1300⍍", "February 1998 Afghanistan earthquake" to "⍌1302⍍", "2021 Afghan protests#September" to "⍌1299⍍". --Lagelander (talk) 12:58, 6 October 2021 (UTC)[reply]

@Lagelander: When I run the "DATES to dmy" script on the Afghanistan article, I cannot replicate this issue. Can you? GoingBatty (talk) 13:44, 6 October 2021 (UTC)[reply]

This issue is mentioned in the script documentation. It is an intermittent fault caused by the script stalling, so it usually isn't possible to replicate it. It may be due to server lag. Just quit the edit window, and try the operation again. -- Ohc ^{revolution of our times} 14:06, 6 October 2021 (UTC)[reply]

Aha - I see it at User:Ohconfucius/script/MOSNUM_dates#Known limitations. Thanks! GoingBatty (talk) 15:43, 6 October 2021 (UTC)[reply]

I searched the October 1 database dump for ⍌ and fixed all 19 articles that incorrectly had this character. GoingBatty (talk) 18:06, 6 October 2021 (UTC)[reply]

You're a star! Many thanks! -- Ohc ^{revolution of our times} 13:53, 7 October 2021 (UTC)[reply]

Template removal: Age in years, months, weeks and days edit

When I edit pages that contain the Template:Age in years, months, weeks and days, it removes the following string: "– present ({{Age in years, months, weeks and days" Example would be Siege of Chernihiv. It seems that it's the "– present" that's causing this; see this diff. Schwede 66 04:34, 4 March 2022 (UTC) Here's another diff; the word "present" is not required to cause this error. Schwede 66 05:18, 4 March 2022 (UTC)[reply]

India Today URL gets mangled edit

Hey, ran the date script and it converted the URL https://www.indiatoday.in/india/story/malala-yousafzai-karnataka-hijab-row-muslim-women-1910558-2022-02-09 into https://www.indiatoday.in/india/story/malala-yousafzai-karnataka-hijab-row-muslim-women-1910558-9 February 2022. Any way to catch this issue? Sammi Brie (she/her • t • c) 03:49, 4 April 2022 (UTC)[reply]

Hi User:Sammi Brie, the error seemingly plausible, I tried running my MOSNUM script on the article but could not repeat the error. I am a little puzzled as there was no apparent problem with the output after I had loaded your common.js script, and there was no undue transformation. I did however notice that a prior edit to the article, by User:Pranesh Ravikumar supposedly by script, also showed the error, although I could not see how said user loaded the script. Let me know if there are other particular circumstances of if it occurs again elsewhere. Regards -- Ohc ^{revolution of our times} 09:10, 4 April 2022 (UTC)[reply]
That makes more sense... Explains why I didn't remember catching this, because it wasn't my problem. Glad I was able to bring it to your attention at least. Sammi Brie (she/her • t • c) 17:18, 4 April 2022 (UTC)[reply]

Generated edit summary edit

The reference to MOS:DATEFORMAT in the generated edit summary is confusing. It would be more helpful to refer to the more specific MOS:DATEUNIFY. --Shmuel (Seymour J.) Metz Username:Chatul (talk) 13:14, 13 April 2022 (UTC)[reply]

Breaks URLs edit

Special:Diff/1069526504/1070385922.

Example:

https://archive.today/20130202031439/http://gfa.radioandrecords.com/PublishGFA/GFAChristianNextPage.asp?sDate=7/11/2010&Format=21

-->

https://archive.today/20130202031439/http://gfa.radioandrecords.com/PublishGFA/GFAChristianNextPage.asp?sDate=November 7, 2010&Format=21

-- GreenC 17:34, 14 May 2022 (UTC)[reply]

@GreenC:Thanks for the notification. Issue now fixed. -- Ohc ^{revolution of our times} 07:26, 15 May 2022 (UTC)[reply]

Big-endian dates standard, others not edit

Given that ISO 8601 and RFC 3339 are the only standard date formats and that "mdy" and "dmy" are non-standard leftovers, it's too bad there's not a way to make all the dates in an article big-endian and use the date template to display those in the text body in one of the antiquated formats while leaving all those in the tables and references in standard format. The "date" template will do this but, unfortunately, its use is discouraged outside of references. — Xenophore; talk 16:16, 28 May 2022 (UTC)[reply]

It's unfortunate. Anyone who's thought about it should prefer logical big-endian dates, especially if they've worked with computers. However our goal is to communicate with the general public who see 2022-05-28 and think the answer might be 1,989. Until people are more like computers and think in logical ways, we should stick with communicating with humans and use 28 May 2022 or the even worse May 28, 2022. SchreiberBike | ⌨ 16:44, 28 May 2022 (UTC)[reply]

Ha! I will never be satisfied until everyone knows 2011-12 means December 2011. 😁 — Xenophore; talk 18:03, 28 May 2022 (UTC)[reply]

Feature request: year ranges that use the term "present" edit

The script already converts a spaced endash to the unspaced version when it encounters a clean year range (i.e. no month shown) of the type "YYYY – ZZZZ". It could usefully do the same with ranges of this nature: "YYYY – present". Note that a date range that already contains a space should use a spaced endash, e.g. a construction like "MM YYYY – present" is correct. I manually fix "YYYY – present" constructions a lot; it would be fabulous if the script could do this automatically. Please note that MOS:DATETOPRES also allows for the abbreviated version pres. and the script should cover that as well. Schwede 66 23:32, 13 June 2022 (UTC)[reply]

Scripts not listed under Tools edit

@Ohconfucius - Hi there! For a few days, I haven't seen your great "All dates to MDY" and "All dates to DMY" scripts listed under my Tools when I edit an article. I still see your "Fix SOURCES" script. Is there an issue with the scripts, or is it on my side? Thanks! GoingBatty (talk) 21:12, 7 July 2022 (UTC)[reply]

While it's true that I've been migrating the tools that the script uses, it should now work as I have your vector script loaded and have run a couple of tests using it. I notice incidentally that you're using a custom version of the MOSNUM script, but that shouldn't cause a problem if you've mirrored it. The buttons now appear on the dashboard under a sub-header MOSNUM Dates (they are no longer simply under the large boldfaced header for Scripts). The menus and script buttons seem to jump around in a random way up and down the sidebar, and this can be confusing at times. I hope you can find them again! -- Ohc ^{revolution of our times} 07:57, 8 July 2022 (UTC)[reply]

@Ohconfucius: I've posted a screenshot of my left toolbar. I was looking for your scripts under the "Tools" section, which is where they used to be. I see they are now under Scripts > MOSNUM Dates. For many articles, there are several languages also displayed, which then requires me to scroll down to find the new MOSNUM Dates section. User:GoingBatty/vector.js has had your version of the script since 2014. There was a short time when I used User:GoingBatty/script/MOSNUM dates.js but haven't used it in a long time, and requested that it be deleted. Thanks for all your help and for these great scripts! GoingBatty (talk) 12:49, 8 July 2022 (UTC)[reply]

@GoingBatty: That;s it, the scripts are now grouped together under the heading of TemplateScript, which is the component/utility I migrated the MOSNUM script to. I've asked User:Pathoschild if there's a way of bumping them up into the Tools category. Let's wait to see what magic he can conjure up. -- Ohc ^{revolution of our times} 16:40, 8 July 2022 (UTC)[reply]

4AD unlinked by the script edit

On the page Dry Cleaning (band), when I ran the script, it unlinked the record label 4AD. Also, is there a way to not mark edits using the script as "minor" besides unclicking it manually? SchreiberBike | ⌨ 22:51, 21 September 2022 (UTC)[reply]

I have now disabled the unlinking of the term yyyyAD in the script. As the incidence of errors of the script actions is low, the edit summary will stay as it is so as not to confuse users, most of whom have now grown accustomed to seeing such edits marked as "minor". -- Ohc ^{revolution of our times} 09:41, 22 September 2022 (UTC)[reply]

Start date edit

Hey, can the DATES to dmy button add |df=y to Template:Start Date please? That not being added was causing mdy dates to be showing. Thanks, Indagate (talk) 16:33, 8 January 2023 (UTC)[reply]

Add yyyy.mm.dd to slash dates? edit

Hello,

I'm editing pages for Roman Catholic dioceses in Africa and am finding a lot that have date format yyyy.mm.dd (eg 1961.09.23). Would you be able to add that case to the slash-dates cases.

Example page: Roman Catholic Archdiocese of Bangui (Permalink to version with yyyy.mm.dd format if current page no longer has the issue)

Thanks, Referencer12 (talk) 05:27, 3 February 2023 (UTC)[reply]

Removes spaces used as indenting edit

Spaces used to indent the next line are removed even when the date format isn't changed, as seen in Robert Hanssen: Difference between revisions -- Pemilligan (talk) 16:25, 7 June 2023 (UTC)[reply]

EngvarB edit

MOVED

I suggested XAM2175 post a bug report, but should've clarified that it's in regard to my use of the EngvarB script, not the MOSNUM script. — voidxor 19:43, 19 June 2023 (UTC)[reply]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Why does this script change {{Use British English}} to {{EngvarB}}, as seen here? XAM2175 ^(T) 21:52, 18 June 2023 (UTC)[reply]

@Voidxor; drawing your attention to this. XAM2175 ^(T) 17:34, 19 June 2023 (UTC)[reply]

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Re-up Short Description ordering issue edit

As reported twice earlier on this page, when this script adds {{Use dmy dates}}, the line is added above an existing Short Description, violating MOS:ORDER. It's still happening. I fixed that instance. David Brooks (talk) 15:38, 28 June 2023 (UTC)[reply]

Yes, it appears that User:Ohconfucius lacks either the time or the inclination to correct this (two-and-a-half-year-old) bug. — JohnFromPinckney (talk / edits) 01:33, 29 June 2023 (UTC)[reply]

Or the technical skills

-- Ohc ^{revolution of our times} 21:33, 29 June 2023 (UTC)[reply]

Well, that's very different. We thought you just didn't like us.

— JohnFromPinckney (talk / edits) 21:53, 29 June 2023 (UTC)[reply]

And I certainly don't have the technical skills (rant about the nature of Javascript as a language, its pragmatic origins, and even its name, tactfully omitted - but then my opinion was solidified exactly 26 years ago). David Brooks (talk) 14:16, 1 July 2023 (UTC)[reply]

@JohnFromPinckney:

Nothing personal, i swear

Ohc ^{revolution of our times} 06:08, 22 July 2023 (UTC)[reply]

By the way, Ohconfucius, are you aware of this discussion? It's an amalgamation of complaints about this terrible script, other terrible scripts, terrible script users, and declarations about which date formats look "ugly" (spoiler: they pretty much all do, to somebody). — JohnFromPinckney (talk / edits) 08:42, 22 July 2023 (UTC)[reply]

Any way to run this script in Android edit

Hi, I tried to run this script in both Firefox and Chrome mobile. In both, script icons are avilable in the tool box, but nothing happens if I clicked on the buttons. Anyway to fix ? Anoop Bhatia (talk) 19:41, 12 October 2023 (UTC)[reply]

Unnecessary date changes edit

Why is the script making unnecessary edits to change date formats in citations (example)? This is an acceptable date format according to WP:MOSNUM and the default format for tools like toollabs:citer. If the reason is MOS:DATEUNIFY then that should be used in the edit summary instead, but it seems like a fluff edit to change citation dates that are perfectly fine and the internal format in the citation is not visible to readers. Daniel Quinlan (talk) 23:31, 24 October 2023 (UTC)[reply]

It is MOS:DATEUNIFY. While ISO YYYY-MM-DD dates are permitted in Wikipedia for certain purposes, they are not required for any of them [well, except as parameterized input in various date-calculating templates, but that's not a use this script would detect and alter in most cases], and don't serve a needed function in any of the citation templates. The "death to Ohconfucius's script" ranters hypothesize or, rather, utopianize, that as long as the page has a {{use mdy/dmy dates|cs1-dates=...}} set to something (other than ISO), then the ISO format is magically hidden from readers, and this gives them license to use YYYY-MM-DD with impunity, and turn aggressive on anyone who changes any of them to mdy or dmy. In actual reality, of course, this is bunk for multiple reasons (at least four, and probably others):

The number of pages that actually have one of those templates with that parameter and a sensible value set in it is very minimal; the parameter is so rare, you can edit every day for a month and never run into it. While the |cs1-dates= parameter has existed for years, virtually no one uses it. So, the vast majority of articles with YYYY-MM-DD access-dates and archive-dates and so on are presenting to the reader a geeky format that for many non-experts is confusing and ambiguous, and there is a consensus to avoid that format in most reader-facing circumstances.
Literally millions of citations are not formatted by CS1/CS2 templates that obey that parameter. Even if some bot job installed that parameter in every article (not likely possible, because it is tied to either {{use mdy dates}} or {{use dmy dates}}, and which to install is a human judgment), the problem of ISO dates in readers' faces would remain.
The YYYY-MM-DD format is Gregorian-only, so has to be avoided in various citations of older works.
Someone at the discussion linked to in a thread above vented about difficulties in translation when encountering dates not in YYYY-MM-DD format, but as others quickly pointed out there, that's entirely an issue on the end of the translation tool, since the vast majority of our citations are and always have been and always will be using mdy or dmy dates, so no dependency on YYYY-MM-DD format for translation is feasible. Code to handle all of our permitted date formats can simply be ripped for such translation tools from existing tools on en.wp and elsewhere; it's not much more complicated that copy-paste from one script into another, and change local-language month names.

So, yes, DATEUNIFY changes are in most cases justified. Even when that |cs1-dates= parameter is present, doing such a unification causes no harm of any kind, and is even compliant with the human-editor instructions in WP:COSMETICBOT as long as something substantive is done in the same edit (e.g. fix a typo). People who believe there is some policy or other rule against changing ISO dates in citations are simply wrong in virtually all cases (as noted below, it would only be a problem in the rare case that an off-site citation style has been imposed and maintained at a particular article and that style requires ISO dates). Our MOS:STYLEVAR principle is to not change one permissible style (of anything) to another without a good reason, but to avoid shooting ISO dates at the readers without necessity already consistitutes such a good reason. On the other hand, if an article has every citation in a CS1/CS2 citation template, then it is simpler to just add {{use mdy/dmy dates|cs1-dates=...}}, if the dmy or mdy MOS:DATEVAR of the article is clearly determinable (or is now being set). Even so, that does not equate to a prohibition against normalizing the date formats anyway, simply to make things easier on editors. A change does not actually have to be reader-facing to pass the COSMETICBOT test.

It's instructive to review the actual guidelines in detail. See first MOS:DATEFORMAT, which defines YYYY-MM-DD as a short format for use "Only in limited situations where brevity is helpful" (along with formats like "2 Sep 2001"), e.g. in columns in wide tables, and that it is one with "No equivalent for general use". I.e., it is not one we normally present to our readers. MOS:DATEUNIFY permits the use of the abbreviated formats, including YYYY-MM-DD, in citatations but certainly does not mandate them, nor even advise them; it's simply not outright forbidden. The notion that such a format must be "obeyed" and untouched, either as to the underlying code or the displayed result, is nonsense, or it would not be permissible for the |cs1-dates= to exist in the first place. Finally, the same section permits mixing date formats in the same citation when and only when implementing a particular citation style that requires this (e.g. "Jones, J. (20 September 2008) ... Retrieved 2009-02-05" is grudingly allowed, under that specific circumstance). But this is a holdover from the 2000s; only a vanishingly small fraction of our articles today are attempting to comply with off-site citation styles, and nearly all of our material is CS1 (our own citation style which has no such date-mismatch requirements), albeit with some mixing in of CS2 and manually-written citations that need (unless Julian-dated) to be converted to CS1 to impose a consistent citation style per WP:CITESTYLE. The guideline is quite clear that 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. That accounts for nearly all of our articles in the 2020s, and unless a particular article has been annoyingly written to conform exactly to Vancouver, AMA, MHRA, or some other external citation style, and that style requires ISO dates for certain things, then it is entirely permissible to normalize our dates to dmy or mdy. — SMcCandlish ☏ ¢ 😼 23:36, 24 January 2024 (UTC)[reply]

A guideline does not override policy. I believe changing citation date format when it doesn't affect the display of the article violates WP:COSMETICBOT. If other changes are being made to that specific citation, it's probably fine, but cluttering edit histories and watchlists with edits that are completely cosmetic and not visible (as in the example I cited above) is more of a negative than a positive. Daniel Quinlan (talk) 02:52, 25 January 2024 (UTC)[reply]

Well, I guess anyone can "believe" what they want, but the policy is clear on this stuff. The only human-related instruction in there is While this policy applies only to bots, human editors should also follow this guidance if making such changes in a bot-like manner. That's not only a recommendation not a requirement (explicit about that in two different ways), it's only applicable when "making such changes in a bot-like manner", which apply this script to a particular article is not; applying to hundreds in a rapid-fire manner would be. But what are "such changes"? Let's read closely: edits that are not worth the time spent reviewing them; hardly any editors are so dismissive about date formatting. Such changes should not usually be done on their own, but may be allowed in an edit that also includes a substantive change. (That's even for bots, mind you.) All scripts of this sort should have and usually do have an instruction to the effect that their use could be considered a COSMETICBOT issue if invoked soley for their own sake without doing something else more substantive in the same edit. changes that do not ... affect something visible to readers and consumers of Wikipedia ... are typically considered cosmetic. There are two key words in here: "consumers" and "typically". Many editors do not consider code changes that improve the material in some way for editors and the tools they use to be cosmetic, because editors are also consumers of Wikipedia. So are a wide variety of WP:REUSErs of our content, including those dependent on various forms of metadata emitted by our templates (including citation ones, with dates). If we improve the consistency of that data for them, then this is "visible to ... [those] consumers of Wikipedia". Another thing that qualifies as substantive is the "user-facing interfaces" of Wikipedia, such as ... on-wiki and external search engine results; it's likely that date changes will affect at least some forms of search, though this is a minor point. Another qualifier is administration of the encyclopedia, and consistent date formats are a part of this, since they enable editor-facing tools to do more automatically with more of the content. Not only does this not actually qualify as purely cosmetic, COSMETICBOT as applied to non-bots (humans) only applies to mass action not working on a particular article, and is a recommendation not a requirement. PS: Something almost everyone who likes to mis-cite COSMETICBOT against other human editors tends to forget: Keep in mind that reverting a cosmetic edit is also a cosmetic edit. If the changes made in a cosmetic edit would otherwise be acceptable as part of a substantive edit, there is no reason to revert them.

It's also worth looking at WP:MEATBOT, the other human-editor portion of the policy. Human editors are expected to pay attention to the edits they make, and ensure that they do not sacrifice quality in the pursuit of speed or quantity. ... errors an attentive human would not make. That's why it's important to review the output of scripts like this before saving. There can fairly often be errors. However, this entire section is about high-speed or large-scale edits ... processes which operate at higher speeds, with a higher volume of edits, or with less human involvement [which] are more likely to be treated as bots. Using a date cleanup script at an article you're working on, with the human involvement of paying attention before saving, doesn't quality. Piping it through AWB/JWB to change hundreds per hour in a robotic manner and with little in the way of review obviously would qualify. — SMcCandlish ☏ ¢ 😼 04:06, 25 January 2024 (UTC)[reply]

All that's needed here is changing the script to pass on making completely cosmetic edits. The issue is the net effect from the script suggesting these types of edits to users (plural). Daniel Quinlan (talk) 04:21, 25 January 2024 (UTC)[reply]

Future development suggestions edit

Given all the above, the ideal situation moving forward would be futher development of the User:Ohconfucius/script/MOSNUM dates script or a fork of it, to do something like the following:

If |cs1-dates= is encountered with a valid value, then analyze what it is.
- If the |cs1-dates= value is something presently permissible in reader-facing content by MOS:DATE (keep in mind that 1. a guideline can change at any time, and 2. some template editor creating an option neither means it is guideline-compliant now nor will be forever), then do not change the dates in CS1/CS2 citation templates, since they'll automatically be display-munged to match that |cs1-dates= instruction; but do normalize other dates (in running text, in manually formatted citations, in non-CS1/CS2 citation templates, etc.) to either the mdy or dmy format selected.
  - Have an override option to change all the CS1/CS2 dates to the prescribed mdy or dmy format anyway, for someone who is certain they have consensus to do it (e.g. because they're the only author, because there was a discussion that arrived at such a consensus, because FAC recommended normalizing them, or whatever).
- If the |cs1-dates= value is not something presently permissible in reader-facing content, then change it to |cs1-dates=l, and normalize all dates to either the mdy or dmy format selected.
If |cs1-dates= is missing or empty then add it, with a default |cs1-dates=l value, and normalize all dates to either the mdy or dmy format selected.
If |cs1-dates= is present but has a invalid value, then change it to |cs1-dates=l, and normalize all dates to either the mdy or dmy format selected.

But that would require a lot of new scripting. There's also the issue that various |cs1-dates= parameter values really only exist to mimic various off-site citation styles, yet these citation styles are not produced by CS1/CS2 templates at all. That is, various options that might be set in that parameter should not be, at least not with the intended use of formatting CS1/CS2 templates' dates, because they mix date formats, or use weird ones, or both, not to comply with a requirement of a particular citation style (none of which are the CS1/CS2 citation styles), but simply for some random editor's "I just like it" preferences. Maybe some other use for such options could be created, like handling by {{vcite journal}} and other Vancouver citation style templates, or whatever, but virtually no one uses that stuff any more, so this will never happen. PS Vanc doesn't actually use YYYY-MM-DD anyway, it uses a strange "2009 Jan 2" abbreviated format; yet another reason among half a dozen to not use that citation format). — SMcCandlish ☏ ¢ 😼 23:36, 24 January 2024 (UTC)[reply]

Wikipedia:Date formattings/script/MOSNUM dates/bugs

Untitled edit

Haiti edit

Incomplete conversion of abbreviated date strings edit

$amount edit

Comma between date and an unrelated number edit

Comma removal from an unrelated term and publication year edit

Protection edit

may edit

spurious comma edit

cricket edit

Month names in date ranges edit

Question edit

Bug report edit

Bug report edit

Dates not changed edit

Not loading in toolbox edit

Firefox Update edit

Bug report - "All dates to mdy" adding $1 edit

Suggestion to expand All dates to mdy script edit

All dates vs. body dates edit

Talkback edit

Suggestion to fix more CS1 errors edit

Rotten Tomatoes score edit

cite journal / contribution= edit

Bug report - removes pp-move template edit

Potential unwanted DEFAULTSORT refactoring edit

Possible bug edit

Template - Video game release edit

Not working edit

Use of ALL dates to mdy removed period after month abbreviation in book title within ref tags edit

Please exclude singlechart template from script edit

Feature request - fix dd mmm, dd yyyy format edit

Request to protect another proper name: Observance of 5th November Act edit

Bug report: Expand all dates doesn't do so edit

Suggestion for Accessdate to YYYY-MM-DD edit

Request to add support for Template:Death date and age edit

Bug report - Film date template edit

Tip for using comments to prevent commas being deleted edit

|year= vs. |date= citation usage edit

Script breaking DOI values? edit

Incorrectly removes film link edit

Page number incorporated into a date edit

Suggestion: Rotten Tomatoes score edit

Suggestion to expand script to fix doi_brokendate field edit

Bug report edit

Suggestion for As of template edit

Suggestion for Allmusic template edit

Not changing "as of" intentional? edit

Bug report: Script does not fix access-date parameter edit

Request to include airdate parameter edit

Duplicate edit summaries edit

Changes reverted as WP:MOSDATE violation edit

Archive date treated as publication date edit

Bug report: access 2 ISO does not fix access-date parameter edit

Bug report: Script changes trans-title parameter edit

Abbreviated month edit

Template:birth year and age edit

Script stopped working? edit

Date within archive-url reformatted edit

Heads up edit

Changes to notices at top of articles edit

Date format error edit

Changing from dates in the format dth, m, y edit

MOSNUM dates script removed date parameter from Template:clarify edit

removal of non-breaking spaces edit

Does not handle templates correctly edit

Invalid parameter being added edit

df removal edit

Changes within titles edit

Bug edit

Running the script fixes the output, but not the actual wikicode edit

Using the script produces strange characters edit

Non-breaking spaces edit

Replacing file names which contain dates edit

1996 United States Senate elections edit

|year= vs. |date= citation usage (over 4.5 years later) edit

Script changes superscripts to @ edit

Ignore formatting within quote templates edit

Removal of nbsp from dates edit

`|year=` vs. `|date=` citation usage edit

`|year=` vs. `|date=` citation usage (over 4.5 years later) edit