Wikipedia:Bots/Requests for approval/MOSNUM Bot Source: en.wikipedia.org/wiki/Wikipedia:Bots/Requests_for_approval/MOSNUM_Bot

The following discussion is an archived debate. Please do not modify it. To request review of this BRFA, please start a new section at WT:BRFA. The result of the discussion was Denied.

Operator: Ohconfucius (talk · contribs)

Time filed: 03:54, Wednesday February 2, 2011 (UTC)

Automatic or Manually assisted: Automatic, supervised, throttled at 5 edits per minute; I would be prepared to accept capping the total daily number of edits at, say, 1,000

Programming language(s): AWB

Source code available: Not yet established, but will be closely based on User:Ohconfucius/MOSNUM_dates.js – which has already been used on thousands of articles, specifically calling function Ohc_body_to_dmy() and function Ohc_body_to_mdy()

Function overview: It is aimed to make article dates compatible with the Manual of Style, by ensuring uniform presentation of dates within any given article.

Links to relevant discussions (where appropriate):

• There is long-standing, broad and general consensus on the consistent formatting of dates within the body of an article.

Edit period(s):

• Continuous

Estimated number of pages affected: upwards of 50,000+ (see this list from November 2009 as a point of reference)

Exclusion compliant (Y/N): Y

• will respect {{nobots}}
• will respect pre-existing date-maintenance templates (i.e. will not edit articles where {{use dmy dates}} or {{use mdy dates}} tags are already in place)

Already has a bot flag (Y/N):

Function details:

• delinks full dates (but not lone day-month strings or years), days (i.e. Wednesday), months (i.e. November), decades (i.e. 1940s), centuries,
• removes direct links to full dates, whether ISO8601, dd mmm yyyy or mmm dd, yyyy, including piped links of same to chronological articles in almost any imaginable form (i.e. strings such as '[[25 February]] [[1997]]', '[[February 25|25 February]] [[1997 in literature|1997]]', or '[[February 25|25]] [[February]] [[1997 in literature|1997]]'.
• converts dd mmm or mmm dd date fragments – including date ranges – to the same format throughout
• removes ordinal suffices and constructions such as 'the 5th of September', 'December the 25th' or 'October of 2003'
• adds commas where necessary (e.g. February 28 2001) – already a standard AWB fix – but will not amend any punctuation (i.e. will not insertion of a comma or changing same into or from full stops) after the year in the date string.
• removes redundant commas (e.g. July, 1997; 28 February, 2001) – already a standard AWB fix
• tags articles with {{use dmy dates}} or {{use mdy dates}} according to how the given article is processed
• articles will be aligned to dmy or mdy according to WP:TIES; article population to be acted upon will be based on carefully-chosen subcategories of national categories such as Category:United Kingdom, Category:Republic of Ireland, Category:Australia, Category:South Africa, Category:European Union, Category:Military of the United States for dmy, and Category:United States for mdy
• ISO8601-format dates will not be changed to dmy or mdy
• Each bot run will execute rules to align dates within articles to dmy, or mdy but not both. In other words, no autodetection of date format to be employed – these will be based on manually selected categories as indicated above, using suitably matched date format rules.

• Recused MBisanz ^talk 08:08, 2 February 2011 (UTC)[reply]
• Are there any checks for quotations or for idiomatic forms such as Seventh of March Speech (which is expressly approved by MOSNUM and will not be linked every time it is mentioned)?
• Are there any checks to ensure that this does not keep editing the same article when intentionally reverted - which was one of the standing problems which brought on the date delinking case?
• Is the application of WP:TIES restticted to the specified cats, or is there a presumption that every article not expressly about America is international - even if it is written in American? Septentrionalis PMAnderson 18:51, 10 February 2011 (UTC)[reply]

• Idiomatic date forms where the numbers are written out in words will not be acted upon; the rules will include a list of exceptions that will be expanded as and when false positives are discovered. For the avoidance of doubt, such exceptions do not include protecting non-idiomatic formulations such as 'September the 11th' or '5th of November'.
• Occurrences of dates within filenames, citation titles, quotations etc will be suitably protected from conversion – for example by insertion of non-breaking spaces or underscores.
• In this proposed run, the bot will not visit articles already tagged with {{dmy}} or {{mdy}}, and I do not expect any editor will be making a wholescale revert which removes also the tagging (as opposed to a partial revert) without leaving a message on my talk page about the false positive. To this end, I will try my best to include explanations of 'how to' on the Userpage; In addition, the bot will be stopped either by activation of a panic button on the bot's user page, or by posting any comment on its talk page.
• There are two different and independent rules here, national date formats, which is the province of MOSNUM, and English variants of English, a province of MOS. Just because an article – let's take for example an article is on a Brazilian subject – is written in American English does not necessarily mean date formats will be aligned to one or other date formats. This bot, so named, will not apply ENGVAR fixes – that will come with a suitably named bot. ;-) Articles on American people, places, organisations are likely to adopt mdy dates per WP:TIES, and will be aligned to mdy if they have a mix of date formats; US military articles will be aligned universally to dmy format. --Ohconfucius ^¡digame! 09:41, 11 February 2011 (UTC)[reply]

• "Each bot run will execute rules to convert all dates to dmy, or mdy, but not both". Could you clarify what you mean by "all dates" - if you really mean "all" then this task should be denied. Gimmetoo (talk) 11:53, 11 February 2011 (UTC)[reply]

• I don't exactly understand the question. What I meant is that the bot is not going to automatically "decide" on its own what format is to be chosen for any given category of article. I will personally load the code with dmy conversion and ensure the category carefully chosen to match; or I will load the code with mdy conversion and choose the category carefully to correspond to that. "All dates" is as defined above.--Ohconfucius ^¡digame! 16:31, 11 February 2011 (UTC)[reply]

Where is "all dates" defined? What specific classes or types of dates will be excluded from "all dates"? Gimmetoo (talk) 18:21, 11 February 2011 (UTC)[reply]

• I have amended the text above, and hope that this clarifies the scope. Ohconfucius ^¡digame! 15:02, 12 February 2011 (UTC)[reply]

OK, I'm primarily trying to figure out how the script recognizes quotes. Presumably any text within one of the standard quote templates could be excluded, but what about in-text quotes, which may be set off by " or ' or ` or a few other characters, and may not always be nested properly. Would a stray " at the start of an article make the script invert identification of quoted text? Gimmetoo (talk) 23:11, 12 February 2011 (UTC)[reply]

• Please refer to my responses below. --Ohconfucius ^¡digame! 03:08, 14 February 2011 (UTC)[reply]

• Will the bot avoid engaging in edit wars, in case someone reverts it? Will the bot avoid changing dates inside direct quotes, media filenames, wikilinks to articles (e.g. March 17, 2007 anti-war protest currently breaks if changed to 17 March 2007 anti-war protest), website titles (e.g. |title= in citation templates), and so on? Anomie⚔ 17:32, 11 February 2011 (UTC)[reply]

links which are piped will not be changed; please read responses already given above, as most of the questions appear to be duplicate and have been answered. Ohconfucius ^¡digame! 15:06, 12 February 2011 (UTC)[reply]

• Needs wider discussion. Is there any evidence that the community at large (as opposed to just MOS regulars) wants a bot to do this automatically? And, for that matter, whether the community at large trusts someone with your history in this area to be running the bot? Anomie⚔ 17:32, 11 February 2011 (UTC)[reply]

Thanks for that rather large dose of scepticism. I'm not asking for kid gloves, but some good faith would be nice. Ohconfucius ^¡digame! 15:04, 12 February 2011 (UTC)[reply]

Anomie, I notice that you haven't recused, but you certainly appear to have an axe to grind—whether personal or otherwise. I've seen this attitude going on and on and on at Lightmouse's BAG applications, and frankly, it's getting to be over the top. The assumption that an application is in bad faith unless proven otherwise is not helpful. We rely on BAG to make a measured assessment. BAG membership is not a platform for pushing personal agendas; if you have residual agendas, it would be better for you to recuse and allow other members to make an assessment. Tony (talk) 14:33, 13 February 2011 (UTC)[reply]

I agree 100 percent with Tony’s sentiments. Irregardless of the membership requirements to be part of BAG, membership does not confer an entitlement to behave as you have been lately towards Ohconfucius. Your above 17:32, 11 February 2011 post, where you question (suggest?) that the individual (Ohconfucius) can’t even be trusted to run a bot unnecessarily personalized the issue. It’s amazing that you couldn’t see that such a personal affront was unnecessarily provocative and inflammatory. That you would write that anyway clearly demonstrated that your objectivity here is severely compromised. I second the motion that you recuse yourself in this matter. Greg L (talk) 19:11, 13 February 2011 (UTC)[reply]

• I don't at all mind pertinent questions being asked in this application – on the contrary, I welcome them. If my answers to any of the foregoing questions were not clear, I would certainly not object to having supplementary questions asked to support my project. What irks me is that Anomie appears to have stomped into the discussion without at all having read the foregoing discussion, whilst at the same time wave around my previous 'conviction' implying that I did not deserve a second chance – despite, as it appears, the clear wishes of the assembled arbitrators. Maybe we started off on the wrong foot... I remain at your disposition to respond to any further queries. --Ohconfucius ^¡digame! 16:31, 13 February 2011 (UTC)[reply]

• Could you please indicate what "automatic" and "supervised" means? Do you constantly check the bots edits to verify that it is not making mistakes? How soon after the edits are checked? —  HELLKNOWZ  ▎TALK
  • I intend for the bot's edits to be checked daily after each bot run, or each day, whichever the more frequent. The bot runs will initially be small batches, starting with narrow categories to facilitate manual checking. I will go more slowly where I anticipate greater instances of dates within quotations, such as Category:Recipients of the Victoria Cross or Category:Recipients of United States military awards and decorations, where more checking will be necessary. --Ohconfucius ^¡digame! 03:08, 14 February 2011 (UTC)[reply]
    • Checking all changes -- in principle -- sounds great. I am weary that human factor may kick in. Even AWB can quickly become repetitive and mundane to the point where humans start to make errors. Every once in a while an issue is raised about someone editing bot-like. That said, you have probably chosen the best venue for your task. —  HELLKNOWZ  ▎TALK 11:04, 14 February 2011 (UTC)[reply]
      • It is true that the greater the number of edits, each edit is less likely to be checked properly. I would be amenable to capping the daily number of bot edits at 1000 – the approximate rate at which I could edit semi-automatically. --Ohconfucius ^¡digame! 16:03, 14 February 2011 (UTC)[reply]
• I do not understand why Anomie's wider discussion request was wrongly taken as personal or hostile. The operator has listed several changes that potentially affect a very broad range of articles. For all these changes, there is consensus. However, there is no (that I am aware of) consensus to do them all by bot. This is what this request is about -- to decide if a certain bot task can/should be run. There are still BOTREQ-relevant questions. —  HELLKNOWZ  ▎TALK
  • I have no objections to Anomie not recusing himself to ask me questions. I don't think I ever said or implied that Anomie had attacked me personally; if so, I sincerely apologise, for there was never any such intention on my part. Most of the questions Anomie asked questions that were already asked in greater detail by another editor. I attempted to answer them already. I would be pleased to answer supplementary questions. --Ohconfucius ^¡digame! 03:08, 14 February 2011 (UTC)[reply]
    • I did not direct this at you; this was a more general observation. There are many BRFAs and it a lot of work to read them all and think of all the possible issues. So I can sympathize with asking the same/similar questions. —  HELLKNOWZ  ▎TALK 11:04, 14 February 2011 (UTC)[reply]
      • Point taken. --Ohconfucius ^¡digame! 16:03, 14 February 2011 (UTC)[reply]
• How does the bot determine quoted text? This is usually the biggest underwater stone for bot requests, as without context, the bot may alter parts of the page that shouldn't be changed. —  HELLKNOWZ  ▎TALK
  • Directional quote marks and quotation templates will be recognised, and the bot will avoid dates within these. It will also avoid, as my script currently does, 'sensitive' date strings such as those within urls, images and title fields of citation templates. I have no solution for dates which are within the common unpaired/unpairable quote marks (', or "), which is why I proposed the bot's 'supervision'. --Ohconfucius ^¡digame! 03:08, 14 February 2011 (UTC)[reply]
    • Since you partially noted here and at Arbcom amendment that your script has been run for a long time with few false positives, I am tending to assume it produces few errors. —  HELLKNOWZ  ▎TALK 11:04, 14 February 2011 (UTC)[reply]
      • I do supplement my script editing with manual changes, so some tweaking to the rules may still be necessary before it goes live. --Ohconfucius ^¡digame! 16:03, 14 February 2011 (UTC)[reply]
• Similarly, how does the bot recognize when a date appears in context-important ways? Simple punctuation errors or poorly constructed sentences may lead to incorrect bot changes. For example, "If we ignore July, 2007 was a nice year.", for a valid comma after July as an introductory phrase. Or "In the 5th of May". —  HELLKNOWZ  ▎TALK
  • I could leave that sort of comma untouched; I only thought that it could be included because it is a standard AWB fix. I do not understand the reference to "In the 5th of May" – are you presenting this as a 'what happens if this is in quotes' scenario? From my personal experience of thousands of articles, I have not come across any such instances which ought not to be removed; constructions such as 'the February 5th edition of 60 minutes' are more common, where automation might remove the 'the'. When editing manually, I usually rewrite such instances, for example 'the edition of 60 minutes on February 5'. I would not make such corrections if these would cause problems. I would note that the removal of ordinals is a standard AWB fix too. --Ohconfucius ^¡digame! 03:08, 14 February 2011 (UTC)[reply]
    • Sorry, "In the 5th of May" was me typing something, then deleting less than intended; ignore that. Regarding AWB fixes, I do not think they are automatic? I think they are still applied with human reviewers in mind? Because AWB automatic mode would need a BRFA here. —  HELLKNOWZ  ▎TALK 11:04, 14 February 2011 (UTC)[reply]
      • MOS fixes are indeed optional. I do not know what proportion of AWB operators enable these fixes, but I am not aware of any controversy related to the correction. --Ohconfucius ^¡digame! 16:03, 14 February 2011 (UTC)[reply]
• Is the bot first-letter case sensitive, i.e., is "October" = "october"? Case insensitivity may fail to find additional fixes but will be susceptible to alternative meaning of words, e.g. "may" as in "can itself". —  HELLKNOWZ  ▎TALK
  • Yes, it is case sensitive. I was contemplating incorporating rules to capitalise month names, but it would potentially introduce more complexity than is necessary and also false positives. I believe that it is probably more important to avoid false positives than false negatives. --Ohconfucius ^¡digame! 03:08, 14 February 2011 (UTC)[reply]
    • OK. —  HELLKNOWZ  ▎TALK 11:04, 14 February 2011 (UTC)[reply]
• Do you have a public list of exceptions, e.g. "September 11" and such as mentioned above? —  HELLKNOWZ  ▎TALK
  • My list is small at present; I will make such a list public. Having said that, you will already have noted the treatment of idiomatic usages. I do not see why we should not use, in the context of an article on a British subject, date formats consistent with the prevailing article date format (such as 11 September attacks), provided wikilinks are not broken. --Ohconfucius ^¡digame! 03:08, 14 February 2011 (UTC)[reply]
    • Wouldn't any expression like that be nationally tied, even if used in other style article? Say, September 11 discussed the naming of the incident and said "Originally the incident was donated September 11 attacks, but UK officials have refereed to it as 11 September attacks." Is there some guideline that says dated titles need to be adjusted to current article's format? —  HELLKNOWZ  ▎TALK 11:04, 14 February 2011 (UTC)[reply]
      • If I understand your point correctly, that is why I feel most dates outside of titles and quotes could and should be aligned. To ensure no links are broken, piped links and redirects have a role to play. --Ohconfucius ^¡digame! 16:03, 14 February 2011 (UTC)[reply]
• To confirm -- does "tags articles with {{use dmy dates}} or {{use mdy dates}} according to how the given article is processed" corresponds to the currently chosen Category with national ties? —  HELLKNOWZ  ▎TALK
  • I hope I understand the question correctly: Articles will be processed according to criteria of WP:TIES. For example, British articles or articles on US military subjects will be aligned to dmy, and the article tagged {{use dmy dates}}, most other articles on US subjects will be aligned to mdy unless they are already tagged with {{use mdy dates}}. --Ohconfucius ^¡digame! 03:08, 14 February 2011 (UTC)[reply]
    • I was asking how "according to how the given article is processed" is to be interpreted? How is the article processed, based on specific categories selected by you? This is important in the sense that any bot's criticism and mistakes/bugs can be explained as exceptions in the category or human error in adding pages to the category, rather than error on your part. —  HELLKNOWZ  ▎TALK 11:04, 14 February 2011 (UTC)[reply]
      • Care in selecting categories is equally important to avoiding false positives. I do not expect I will be tagging or converting all sub-categories of 'United Kingdom', 'South Africa' or 'United States'. There will be few ambiguities with applying WP:TIES fixes to geographical articles for the above examples. I will not be treating 'Canada' at all. There may be some issues with people-based categories. --Ohconfucius ^¡digame! 16:03, 14 February 2011 (UTC)[reply]
• Personally, I think this is a valuable task to make the material consistent across the project. Nevertheless, I am sceptical that the bot can avoid making errors in ambiguous and context important text. BAG's job is to the best of their knowledge confirm that the bot won't be making mistakes or any will be swiftly fixed. That said, I have no issues this being a manual task. —  HELLKNOWZ  ▎TALK 20:38, 13 February 2011 (UTC)[reply]
  • Perhaps I am not yet fully aware of all the implications of running a bot for such a task, but having personally processed thousands of articles by script has given me the confidence to request fuller automation to deal with the very common problem of misaligned dates. The script has been fine tuned over a period of months, and the bot code will be based on that, taking into account feedback received here. While I know there will be false positives, I hope that manual review allow me to correct the errors, and fine tune the rules to further reduce any instances of false positives. I do not discount the possibility that the bot application will be refused, but I feel that the automation of this mundane task should be strongly beneficial to the project, and increase the time I spend creating content. --Ohconfucius ^¡digame! 03:08, 14 February 2011 (UTC)[reply]
    • Again, personally, I have no objections, besides various tweaks and minor issues. But, from BAG's standpoint, BAG usually gets the stick should something go wrong with an "approved" bot. Basically, there is an unwritten assumption that all bots are uncontroversial (like intwerwikis) or are very useful and have been approved with large consensus (ClueBot). That's why questions about consensus and wider discussion are requested for this task, which in past has stirred a lot of pots. Similarly, anyone wishing to pick on the bot will eventually ask if BAG considered Arbcom cases and involved editors/commenters. That's why the question is raised if anyone has any issues now (wider discussion and operator trust), so that it can be later said, that BAG did address all concerns before approval/denial. May be Anomie has stated this much more concise and to the point, but the issues -- as I see it -- are valid BAG question and have nothing personal to do with it. —  HELLKNOWZ  ▎TALK 11:04, 14 February 2011 (UTC)[reply]
      • Point taken. --Ohconfucius ^¡digame! 16:03, 14 February 2011 (UTC)[reply]
• Well done, HELLKNOWZ. Pure wiki-business without unnecessary personalization. Very well done. Greg L (talk) 01:23, 15 February 2011 (UTC)[reply]

• Community input has been invited at WP:VPR and WT:MOSNUM on the feasibility and desirability of this task [1] [2]. Please do feel free to reproduce the invitation at other relevant venues. –xeno^talk 16:25, 15 February 2011 (UTC)[reply]

• I apologize if this is answered somewhere above, but how will the bot determine whether or not a particular date link is "germane and topical to the subject, as discussed at Wikipedia:Linking#Chronological items" ? –xeno^talk 16:39, 15 February 2011 (UTC)[reply]

• I do not believe that will be an issue, as only full dates (adjacent linked date fragments) will be unlinked. I am thinking of those dates that will have been missed because of creative piping being used. I have not come across any instances where the month-day date and the year together are both germane. Ohconfucius ^¡digame! 03:58, 16 February 2011 (UTC)[reply]

• I'm not sure if I'm reading it incorrectly, but you also said it will delink decades, giving a specific example of "1940s". So it would remove the link in the lead sentence of Rhythm and blues? To me, the link seems germane to the topic. How will the bot handle for such links? –xeno^talk 19:52, 16 February 2011 (UTC)[reply]

• I would disagree that it is germane. A simple link to 1940s totally lacks specificity, and begs unlinking. The topic would be better linked to an article named 1940s in music, which will not be unlinked. --Ohconfucius ^¡digame! 02:21, 17 February 2011 (UTC)[reply]

• That part about retaining topic-specific date-targets sounds good. Except in the "Function details" description of this bot, I see:

removes direct links to full dates, whether ISO8601, dd mmm yyyy or mmm dd, yyyy, including piped links of same to chronological articles in almost any imaginable form (i.e. strings such as '[[25 February]] [[1997]]', '[[February 25|25 February]] [[1997 in literature|1997]]', or '[[February 25|25]] [[February]] [[1997 in literature|1997]]'.

That description appears to say it will remove links such as "1997 in literature", which sounds quite like the "1940s in music" you then said it would not remove. DMacks (talk) 04:18, 17 February 2011 (UTC)[reply]

• My response to the example Xeno gave was for a stand-alone link, not a disguised/piped one in the context of a "full date" incorporating elements of month, day and year. --Ohconfucius ^¡digame! 08:06, 17 February 2011 (UTC)[reply]
• I think the link to the 1940s is germane because it provides further reading about the decade in which rhythm and blues came to the forefront (not just the decade in music, but also what was going on in the world). In any case, this is only one example; and stuff like this requires human judgment - I think a bot doing this automatically would prove controversial, and should not be run by someone with such strongly held beliefs about date linking as that would give the appearance that the Bot Approvals Group endorses a strict point of view on this matter. –xeno^talk 13:36, 17 February 2011 (UTC)[reply]

• Xeno, concerning – at the start of Rhythm and blues – the link to 1940s, a target that has a "multiple issues" box and another complaining box at its top: I wonder what exactly in such a huge general article is remotely relevant to that topic. If one did want a decade-based link at the anchor article, I see a section within the target-linked article that could be pipe-linked, I suppose (1940s#Music) (which would look like this: 1940s), but better to attract clicks by explicitly linking – either a (see also ...) at the end of that sentence, which is a little clunky, or in the "See also" section after the main text, unpiped. But then, that section comprises just this short brush-off: "The most popular music style during the 1940s was swing which prevailed during World War II. In the later periods of the 1940s, less swing was prominent and crooners like Frank Sinatra, along with genres such as bebop and the earliest traces of rock and roll, were the prevalent genre." Hardly worth it, and better to incorporate into the anchor article in the first place. 1940s seems to be dominated by Hitler and the Nazis on a cursory scan. But from general knowledge, the most dramatic relationship between R&B and the Nazis was that bands in Germany and the occupied territories were forbidden to swing their bodies, to trill "excessively", to bend the pulse, etc, in the manner of "black" music: in other words, rank racism via the cramping of musical style; in some places this was enforced in a crazily bureaucratic way. But I can find not a jot about this – disappointing if the link is to be worthy of bothering our readers.

  1940s in music might be a better link, although rhythm and blues is nowhere to be found; so the reader is left to piece it all together. Better luck at Music_history_of_the_United_States_(1940s_and_50s), but that has a "no refs" notice at the top.

  My long-winded point is that WP:MOSLINK insists that links should be focused, where possible, for reader utility. If gnoming or copy-editing Rhythm and blues, I'd unlink 1940s immediately. My rationale: (1) readers soon become disinterested in following wikilinks when they find irrelevant targets; and (2) if I had endless time, I'd do the text a favour and search out a focused link, but frankly, that is beyond the call of duty. If the article editors can't be bothered, I'm not going to apply human effort, and there's the issue of deceptive piping bubbling underneath, anyway. So if a human won't do it, why should a supervised bot? Tony (talk) 14:24, 17 February 2011 (UTC)[reply]

• Above, Ohconfucius stated "Occurrences of dates within filenames, citation titles, quotations etc will be suitably protected from conversion". This illustrates the problem with the passive voice. Who will perform this protection? If the answer is whichever editor enters these kinds of dates, then I have a problem with the bot. Jc3s5h (talk) 18:40, 15 February 2011 (UTC)[reply]

• My script already performs that protection at present; the bot will use the same protection mechanism. Where this is not already the case, such protection will be written in to the bot rules. --Ohconfucius ^¡digame! 03:58, 16 February 2011 (UTC)[reply]

• How will the bot detect citation titles that occur in body text or citations that do not use templates? Jc3s5h (talk) 16:47, 16 February 2011 (UTC)[reply]

• I'm not saying citation titles that occur in body text do not exist, but I have not come across any. Is this a hypothetical question, or do you have some concrete examples in mind? As to citations within refs sections, I could exclude processing everything within references sections entirely. However, that would create a significant number of unaligned dates with little risk of false positives, IMHO. --Ohconfucius ^¡digame! 02:08, 18 February 2011 (UTC)[reply]

• I would expect citation titles to be used in body text whenever text compares various sources, if one of the sources does not have a person as an author, such as "Jones says blah but the 9/11 Commission Report contradicts this claim." I would expect articles about particular names to contain the date, for example, the article "Today in History: July 2" (that is the actual HTML title.) Jc3s5h (talk) 02:43, 18 February 2011 (UTC)[reply]

• Interesting example. I have not seen my script treat any such instances of dates when editing articles – it could be because the citation-title date and prevailing date format are the same. How occurrences within quotation templates are treated is already covered above in this discussion. If the above case (Today in History: July 2) exists in any article, I am sure it can be pre-empted by careful selection of the category treated. Having said that, assuming that such titles are already marked up in some way as required by the WP:MOS, the 'HideMore' function written into AWB (which protects changes to text within single or double quotes) can be activated. --Ohconfucius ^¡digame! 02:30, 19 February 2011 (UTC)[reply]

• A title like "Today in History: July 2" could be used in any kind of article as verification that some event described in the article occurred in on a particular date (presumably "Today in History: July 2" would give the year as well as the day and month). Thus careful selection of categories would not prevent problems. There is no particular markup required for the title. Many styles use italics for book and website titles, many use double quotes for articles, but APA uses nothing for article titles. Jc3s5h (talk) 13:55, 19 February 2011 (UTC)[reply]

• I am unfamiliar with APA, and believe that no particular style manual has primacy of force on WP. Some form of markup, whether italics or double quotes, is clearly expected for compliance with WP:MOSTITLE. --Ohconfucius ^¡digame! 16:41, 19 February 2011 (UTC)[reply]

• Wikipedia has an article about APA style. It is used in many social sciences, including education. As you say, no particular style manual has primacy of force on WP. Any recognized style manual may be used on Wikipedia, and to the extent such a style manual contradicts WP:MOSTITLE the style manual prevails. Your bot must accommodate every style with a reasonable level of acceptance. Considering the number of teachers in the USA who must use APA when submitting papers to teaching journals or student papers while studying teaching at university, APA clearly has a high enough level of acceptance that your bot must accommodate it. Also, I have seen remarks from users who were active in the development of the original citation templates that they were based on APA, although there do not seem to be any design documents for the citation templates, so I can't prove this. Jc3s5h (talk) 17:01, 19 February 2011 (UTC)[reply]

• Jc3s5h says, "Any recognized style manual may be used on Wikipedia". Not so at all. WP has its own style guide, for its own unique online product and readership. APA is reviled in many areas as a dictatorial and stupid tome. People in psychology bow before it but fully admit its craziness in some areas and its failure to update to modern times. And I have trouble respecting any "authoritative" publication that puts out a new version all too often (with insubstantial changes) so all of its lickspittle adherents have to buy another copy. So let me put to bed this notion that you can go around applying whatever style guide you please (Perhaps You're Introducing Title Case To Our Headings?). If you have problems with WP's MoS, please go there and argue your case. And when OC says, "no particular style manual has primacy of force on WP", I think he means "no particular external style manual", yes? Tony (talk) 01:09, 20 February 2011 (UTC)[reply]

• WP:MOS and WP:CITE are both guidelines. Since MOS is essentially silent on the topic of formatting citations, except to refer to CITE in the "See also" section, I believe the format of citations are controlled by CITE. The CITE guideline states "Several forms of parenthetical referencing are used in Wikipedia, including author-date referencing (APA style...." So anyone who wishes to run a bot that is incompatible with the APA style must first gain consensus to deprecate APA style at CITE. And since Tony brings up what he has trouble respecting, I have trouble respecting bots that won't let editors write anything that could trigger a false positive in a regular expression. Bots shouldn't mess with stuff they don't understand. Jc3s5h (talk) 02:55, 20 February 2011 (UTC)[reply]

• @ Tony, I did indeed mean no particular external style manual. WP has its own style guideline, which appears to clearly state that some sort of markup is expected. It seems to me that Jc3 – who I have not been interaction before – is attempting to impose APA through this discussion, when in fact it has no special standing at all. As to the 'Today in History: July 2' cited above, is such thing used in a real article? It still seems hypothetical to me and I would have difficulty seeing it being referred to without ambiguity in the absence of markups. Not having any markup is not a style, and it seems to be pure rubbish to suggest that people who mess with the lack of formatting have no right to do. The place for the whole wretched discussion is not here, but at the MOS. I like how you say "Bots shouldn't mess with stuff they don't understand." Indeed, people can often be stupider than bots. ;-) --Ohconfucius ^¡digame! 09:20, 20 February 2011 (UTC)[reply]

• Tony and Oconfucius on the one side, and I on the other side seem to have reached an impasse. I believe that MOS has no control over citations, and that CITE gives equal standing to all citation styles, including the Cite xxx tempates, the Citation template, APA, MLA, Chicago Manual of Style, and other published style guides within citations. I do agree that WP:MOS prevails over other published guides on topics that it addresses (that is, outside citations), such as not writing dates in the format 2/21/20 in running text. I believe the correct place to address this is a RfC at WT:CITE with a notice at WT:MOS and I will start an RfC now. Jc3s5h (talk) 14:13, 20 February 2011 (UTC)[reply]

• I must contest the statement "There is long-standing, broad and general consensus on the consistent formatting of dates within the body of an article." This section was changed within the last few days to say "dates in the article's body text and references should all have the same format." In the past there were two separate bullets, one for the body text and one for the references. In the past it had been impossible to gain consensus for requiring that the reference date format match the body date format. Jc3s5h (talk) 18:49, 15 February 2011 (UTC)[reply]

• In view of this edit by Headbomb it appears that the bot would not, in general, comply with MOS:DATEUNIFY. Jc3s5h (talk) 20:06, 15 February 2011 (UTC)[reply]

• I will make a stab at understanding what the above comment means: Notwithstanding the recent changes, I have always understood that the requirement is that date consistency within the two sections are treated separately. It is not intended for the bot to render the date formats within reference sections necessarily any more or less inconsistent than was before the bot's action, although it may change a dmy date into a mdy date (or the reverse) – for I have often seen 3 date formats being used in reference sections. It will not affect ISO-like dates except to unlink them. To ensure global compliance, it would perhaps be simpler for the bot to convert all date instances formats within reference sections into the prevailing format for the rest of the article to comply with the guideline in toto. However, I note that there does not seem to be consensus to align all dates to the prevailing format, especially where dates in the reference sections are already aligned (as ISO) – as is quite often the case. So, the bot will concentrate its efforts on dates within the body, but not exclusively. --Ohconfucius ^¡digame! 03:43, 16 February 2011 (UTC)[reply]

In a nutshell it means that

• Prose has to be consistent with itself. YYYY-MM-DD or abbreviated formats (such as 12 Sep 2009) are not acceptable, with some exceptions for tables, infoboxes, quotes, etc...
• References have to be consistent with each other. YYYY-MM-DD format or abbreviated formats (such as 12 Sep 2009) are acceptable.
  • References are allowed to have a different style of dates than the prose in certain cases. This mostly concerns YYYY-MM-DD format or abbreviated formats (such as 12 Sep 2009).
    • "12 September 2009" in prose but "September 12, 2009" (or vice-versa) in citations is still not acceptable
• Accessdates have to be consistent with each other. Accessdates have to be consistent with the reference format, OR in YYYY-MM-DD.

Headbomb {talk / contribs / physics / books} 04:37, 16 February 2011 (UTC)[reply]

• The above is more or less in line with my understanding, except that, as currently stated, one could theoretically argue for dmy dates within the body and mdy dates within the refs section in defiance of common sense. ;-) I will not introduce excessive complexity by having the bot expand abbreviated month names (i.e. Feb.), nor convert YYYY-MM-DD dates into dmy or mdy formats because I have not worked out how to detect dmy/mdy date formats mixed with YYYY-MM-DD within the refs section. The bot will equally not convert slash-dates, because they are often ambiguous. Nevertheless, I believe the bot actions would be a big step towards consistent formats. --Ohconfucius ^¡digame! 04:54, 16 February 2011 (UTC)[reply]

• Comment It's not clear to me that Ohconfucius is actually permitted, per the terms of this topic ban, which is still in force, to engage in this discussion. What is clear to me is that when the motion to amend his restrictions were under consideration, it was not my intent to enable a crypto-return to the date delinking area without explicitly addressing the topic. For that lack of clarity, both the BAG and Ohconfucius have my apologies. Jclemens (talk) 16:36, 17 February 2011 (UTC)[reply]

• As it seems this bot discussion got sucked down a wormhole of my own making, I will strike out the mention of delinking dates, decades and centuries from this request. --Ohconfucius ^¡digame! 01:55, 18 February 2011 (UTC)[reply]

We find on the Chicago Manual of Style (14th ed., p. 176) the following two examples of correct dates, one of which has been described in this discussion as American style and the other international style:

• "On 6 October 1924 Longo arrived in Bologna."
• "On October 6, 1924, Longo arrived in Bologna."

So how will the bot determine, when converting from international to American, whether to insert a comma after the year, since there might already be some punctuation after the year that will make the comma unnecessary (such as "!", ";" or ".").

Also, when converting from American style to international style, how will the bot know it is safe to remove the comma after the year, since the comma may be serving some other function in the sentence, such as separating alternatives: Shall we hold the meeting on July 3, 2011, shall we postpone it a week, or shall we cancel it? Jc3s5h (talk) 14:54, 20 February 2011 (UTC)[reply]

Small point of information: February 20, 2011 is not American style. It's used in the UK too, and in lots of other places. SlimVirgin ^{TALK|CONTRIBS} 16:29, 20 February 2011 (UTC)[reply]

Regarding the example in green: that doesn't sound like something that would appear in an encyclopaedia, so could you please provide an example of text from article space that demonstrates the problem?  GFHandel.   20:10, 20 February 2011 (UTC)[reply]

Here is an example from [[3]]: "It was a hybrid event for 3 dates: May 8, 1510, through May 29, 1546, and total eclipses from June 8, 1564 through March 30, 2033." If the dates were changed to dmy format the comma after 1510 should be removed and the one after 1546 should probably be retained. The present version of the article should be revised to place a comma after 1564. Jc3s5h (talk) 20:21, 20 February 2011 (UTC)[reply]

Why would the script be required to remove the comma after 1510? After the bot had run on the page, the result might be "8 May 1510, through 29 May 1546, and..." but that's okay as the comma problem is no better or worse in either version and is a localized editing issue independent to the date formatting question.

However the example in green tried to demonstrate a different problem: the close-proximity blurring of different dates with different date parts ("July 3" and "2011"). Can you supply an example from article space demonstrating that issue?

 GFHandel.   20:41, 20 February 2011 (UTC)[reply]

There is another example in Salem witch trials

There were four execution dates, with one person executed on June 10, 1692, five executed on July 19, 1692 (Sarah Good, Rebecca Nurse, Susannah Martin, Elizabeth Howe & Sarah Wildes), another five executed on August 19, 1692 (Martha Carrier, John Willard, George Burroughs, George Jacobs, Sr. and John Proctor), and eight on September 22, 1692 (Mary Eastey, Martha Corey, Ann Pudeator, Samuel Wardwell, Mary Parker, Alice Parker, Wilmot Redd and Margaret Scott). [citations omitted]]

If a bot were programmed to always remove a comma that occurs after a year when changing mdy to dmy the result would be "There were four execution dates, with one person executed on 10 June 1692 five executed on 19 July 1692..." but clearly 10 June 1692 should be followed by a comma. Jc3s5h (talk) 22:34, 20 February 2011 (UTC)[reply]

I can't see why the script would be required to remove a comma after a date. Is that really the intended behaviour of the script? Surely the only comma to be detected is the one between MD and Y, and whatever follows the date will be left alone?  GFHandel.   23:00, 20 February 2011 (UTC)[reply]

Please review the two examples of correct usage from the Chicago Manual of Style given at the beginning of this thread. In order to transform "On October 6, 1924, Longo arrived in Bologna" to the correct dmy format it is necessary to remove both commas. If you can look, you can find many examples of this usage in articles, where the two commas are present solely to set off the year in the mdy format.

An additional source for the practice of setting of a year in a mdy date with two commas, one on either side of the date, may be found in the Associated Press Style Book (2007) under the "Months" entry: "Feb. 14, 1987, was the target date." Jc3s5h (talk) 23:37, 20 February 2011 (UTC)[reply]

Okay, I see, but I'm wondering why we need to follow an external style manual? I don't fully respect their usage as the comma after the year has implications that are independent to the date format (e.g. meter). What is the problem with writing On October 6, 1924 Longo arrived in Bologna instead of On October 6, 1924, Longo arrived in Bologna (or vice-versa if that is how the article currently has it)? I believe our readers will cope with either case—which means that the script doesn't have to (necessarily) consider the situation. (That's not to say that I don't have confidence that the script can be made to detect the different forms of trailing punctuation.)  GFHandel.   23:58, 20 February 2011 (UTC)[reply]

Humans have every right to discuss language usage and defy printed style manuals if they can persuade other editors that they have good reasons. Bots are not humans and have no right to impose rules about comma usage just because the bot is incapable of making intelligent decisions because it does not understand what it is editing. My point is that correct conversion between dmy and mdy format requires human judgment and is not a suitable task for a bot.

Furthermore I believe I have completely debunked your claim "that's not to say that I don't have confidence that the script can be made to detect the different forms of trailing punctuation." If the script, while converting mdy to dmy, always drops a comma that follows a year, it will get the witches trial case wrong. If it always keeps the comma, it will get the Longo case wrong. The script cannot succeed in both cases. Jc3s5h (talk) 00:29, 21 February 2011 (UTC)[reply]

I'm not convinced that the same rules that humans would use (in this case) can't be programmed into the script (e.g. the trailing punctuation you mentioned). We should have to wait to see what the author of the script has to say on this issue.  GFHandel.   00:31, 21 February 2011 (UTC)[reply]

The rules humans use in this case are largely simple:

1. Determine the meaning of the sentence.
2. If the date is part of the same phrase as the word following, no comma after 21 February 2011.
3. If it is a separate phrase, and it defines its context, still no comma.
4. If it is a separate phrase and does not define, put a comma.

No program ever built has mastered step 1. I don't expect a bot to do so. Septentrionalis PMAnderson 19:09, 21 February 2011 (UTC)[reply]

That wasn't the point of the original post: ...since there might already be some punctuation after the year that will make the comma unnecessary (such as "!", ";" or ".")—which can be detected by a script. However we can all rest easily as the script is not required to address anything that follows the date. One thing the script can address is quantity—eventually churning through far more pages than can be addressed (for a single purpose of improving consistency) than can humans.  GFHandel.   20:31, 21 February 2011 (UTC)[reply]

You are starting from the foundation that there is an over-riding style that must be used. I don't believe the script will get anything "wrong" if it simply ignores what follows the date (but will be guided by the author of the script). I gave two (green) examples above that show that the world won't end based on the variance of a comma after the year. Our readers will cope, and localized editors can tidy anything they believe needs improvement. We must be careful not to argue from the minor to the whole, and must always remember that if an egg gets broken, we can still produce a beautiful omelette.  GFHandel.   00:57, 21 February 2011 (UTC)[reply]

Well, we have two three printed style guides to zero claiming that years in the mdy format should be set off with commas on both sides of the year. We also know that although Americans tend to favor mdy and English sources from outside North America tend to favor dmy, both formats are accepted throughout the world. So I would suggest conversion creates more problems than it solves. Finally there is the case of articles with mixed usage. These will have to be gone through manually in any case, since there is no assurance that commas are correct or consistent in such an article. (The additional printed style guide supporting commas on both sides of the year is the Publication Manual of the American Psychological Association (6th ed., p. 89). Jc3s5h (talk) 02:27, 21 February 2011 (UTC)[reply]

To put you out of misery, it doesn't. The rules do not add or remove commas at all in these circumstances (i.e. after the year), and I never said or even implied that commas after dates would be changed, added or removed. I also believe it's also nothing to do with MOSNUM, but everthing to do with red herring. --Ohconfucius ^¡digame! 02:29, 21 February 2011 (UTC)[reply]

What we have is one style guide: MOS:MOSNUM#Dates and that doesn't require the comma after the year in a MDY date (but feel free to introduce the suggestion for a trailing comma on the appropriate talk page). It is a mistake to debate this issue based on the examples from "two printed style guides" (there are many cases where WP does things differently to other major style guides). I haven't seen other evidence supporting the "creates more problems" suggestion (but would be happy to consider them). I don't know what will happen with the mixed usage case, but will suggest that a consistency edit may be an excellent prompt for localized editors to swap the dates the other way (but now consistently) should they disagree with the direction taken. Can we please keep this in perspective: we're talking about consistency here—not changes in meaning.  GFHandel.   02:39, 21 February 2011 (UTC)[reply]

• I've looked at the above, and now realise it may be slightly ambiguous. --Ohconfucius ^¡digame! 03:58, 21 February 2011 (UTC)[reply]

• The most recent version of CMOS is the 16th, not the 14th; and it's not god for any variety of English. The order of the month and day are not as simple as the US against everyone else. "On 6 October 1924 Longo arrived in Bologna"—many writers often insert a comma after the year in this context because it's a sentence-initial prepositional phrase. I would tend to do this myself. Many American authors would not insert a comma after 1924. It is best not to fuss with punctuation when harmonising date formats. Tony (talk) 05:45, 21 February 2011 (UTC)[reply]

• Human editors are able to read style guides and decide if their advice applies in any particular situation. Bots cannot. In the case discussed by Tony, a bot cannot recognize a sentence-initial prepositional phrase, and it would require elaborate programming to detect if an article consisted mostly of mdy dates with commas after the year, mostly mdy dates with no commas after the year, or something else. Thus only the most sophisticated bot would have a sub-rudimentary understanding of the style already in use in the article. And it just gets worse from there. Therefore it is best to not allow bots to try to harmonize mdy and dmy dates. The one task a bot might be able to perform (but which is not proposed for this bot) is conversion between the YYYY-MM-DD and the dmy formats. Jc3s5h (talk) 14:31, 21 February 2011 (UTC)[reply]

• You're really funny, Jc3... You wait until now to tell me that the only possible task a bot can do, in your esteemed opinion, is something I considered not to put forward for this bot because it would upset too many people but which, presumably, does not upset you if it was done. In that same esteemed opinion, the average reader would be able to parse something not in any sort of markup and know instinctively that it is a title. :-( --Ohconfucius ^¡digame! 14:48, 21 February 2011 (UTC)[reply]

I do not advocate automated changes between the dmy format and the YYYY-MM-DD format, and am pleased you did not propose to do so. But I think a bot, restricted to certain parts of the article, might be able to do so if anyone wanted such a task performed. Converting between dmy and mdy in running text is beyond the ability of bots. As for "in that same esteemed opinion, the average reader would be able to parse something not in any sort of markup and know instinctively that it is a title", yes, absolutely. One of the things that people can do and bots can't is parse language. Jc3s5h (talk) 15:32, 21 February 2011 (UTC)[reply]

Could everyone please accommodate some perspective in this debate? We're now being distracted by venturing down a theoretical human-versus-computer dead-end. Humans are good at parsing isolated examples, and computers are good at applying a tighter set of rules in great quantity—we get it. All bots are aimed at improving (usually through consistency edits) WP for all readers. We must decide if any resultant problems caused by this bot sufficiently detract from the consistency improvements it is designed to impart to a vast number of articles. I'm afraid that the point of the original post (the case where a DMY date—appearing just before punctuation—is to be altered to MDY and a comma is assumed to be added after Y because that is used in some external style guides) is not a sufficient reason. This one has run its course, so could we please consider other aspects of the script keeping in mind the greater consistency improvements it is designed to make for all of WP's readers?  GFHandel.   20:57, 21 February 2011 (UTC)[reply]

It appears the request will be denied, so for that reason, the debate has run its course. Bots are still incapable of converting between dmy and mdy formats. Jc3s5h (talk) 21:06, 21 February 2011 (UTC)[reply]

"Bots are still incapable of converting between dmy and mdy formats" is a black-and-white and unnecessarily dismissive comment. Script can convert between DMY and MDY formats (and vice-versa)—for the vast majority of cases. What has to be considered (with some healthy perspective) is whether the cases that cause problems are worth accepting based on the greater good the bot will accomplish for a vast number of articles. There are two additional aspects to remember: whether the script can be made to detect only the conversion cases with which it knows it will be successful, and whether the residual problems can be fixed easily by localized editors. I'm a bit of a heretic in this regard: thinking that the odd prod to localized editors is actually a good thing in that it causes them not only to give their articles a once-over, but also to see the types of fixes the script has made (in the hope that they will apply similar consistency edits to other articles they edit).  GFHandel.   21:35, 21 February 2011 (UTC)[reply]

• Not so. Unless they understand what they are doing, they must be programmed either to omit commas after the year or to insert them; either will introduce error into a substantial proportion of sentences which were grammatical before the bot meddled with them. There is a third category of texts where some punctuation marks do make it practically certain that commas are unnecessary; if the bot edits only those, it will avoid almost all error, and introduce inconsistency where it didn't exist before. Why is this an improvement? Septentrionalis PMAnderson 02:47, 22 February 2011 (UTC)[reply]

• Please explain to us why the script needs to concern itself with any characters following a date that it wishes to convert? Converting On 6 October 1924, Longo arrived in Bologna to On October 6, 1924, Longo arrived in Bologna, or (the non-comma case) On 6 October 1924 Longo arrived in Bologna to On October 6, 1924 Longo arrived in Bologna are well within it's abilities. Our readers will cope with both outcomes, and to suggest that this is an issue that should prevent the bot from running is getting close to ludicrous. The situation is not different in this example: ...on 6 October 1924. to ...on October 6, 1924. as the script simply ignores what follows the dates. If localized editors wish to address punctuation after the dates, they are well within their rights to do so, but it's obvious that the script has not made the situation worse. What is an improvement is that the dates in the article are now consistently represented (and that substantially outweighs what is being misrepresented here as a "problem".  GFHandel.   03:12, 22 February 2011 (UTC)[reply]

• In the morning of September 11, 2001, the Twin Towers fell converts to In the morning of 11 September 2001, the Twin Towers fell
• September 11, 2001, produced the following changes: converts to 11 September 2001 produced the following changes:
• One drops the comma, the other retains it; both are mandatory. To do either the other way is ungrammatical, and will interfere with the reader's comprehension. Both constructions are commonplace.
• The difference between them lies in the construction of the entire sentence. Septentrionalis PMAnderson 03:35, 22 February 2011 (UTC)[reply]

• I believe our readers will cope with the first conversion (In the morning of 11 September 2001, the Twin Towers fell), and localized editors can address punctuation in the course of time. The question has always been whether the overall benefit of the bot run outweighs this issue. I believe it does.  GFHandel.   03:48, 22 February 2011 (UTC)[reply]
  • Then you suport a bot which you admit will introduce error much of the time - if I understand your cryptic comment correctly, you support 11 September 2001, produced the following changes: with a comma between a simple subject and its verb. That would be deliberate harm to Wikipedia. Septentrionalis PMAnderson 03:54, 22 February 2011 (UTC)[reply]
    • In most instances, it is not incorrect to have a trailing comma with dmy dates, although it may not be necessary. However, removal of the comma after alignment may change the meaning of sentences in many cases, which is why my script rules never considered removing the commas. Leaving the trailing punctuation would be a minor nuisance to you, at worst, but only with dmy->mdy conversions; it's generally accepted and parsed correctly by the majority of English-speakers at best. --Ohconfucius ^¡digame! 04:13, 22 February 2011 (UTC)[reply]
      • Shorter Ohconfucius: My bot should be permitted to produce ungrammatical English because most readers will be able to figure out what Wikipedia should have said. (Doubtless this will make us look more professional.) Septentrionalis PMAnderson 04:26, 22 February 2011 (UTC)[reply]
    • You have a point, but remember that the outcome you describe results from the rare case when a date needs to be altered from MDY to DMY (due to inconsistency in the article) and the MDY date has been written with a trailing comma, and localized editors don't address it in a reasonable amount of time. That is what I mean't by perspective. I still believe that prodding the inconsistent article is better than leaving it.  GFHandel.   04:17, 22 February 2011 (UTC)[reply]
      • It is much simpler to handle the whole problem by localized editing. The sole point of preferring mdy or dmy in certain cats is the assumption that readers, writers, and editors of those articles overwhelmingly prefer one to the other. If so, we don't need a bot; we merely need to encourage them to follow their preferences on the few exceptions - and, since they can read, the wiki method will lead them to do so correctly. Septentrionalis PMAnderson 04:26, 22 February 2011 (UTC)[reply]
        • Nah, shake rattle and roll the cages. Leaving the exhaustive grunt work to localized editors will ensure things are missed. This way everything is addressed and quickly drawn to the attention of editors who can make the changes.  GFHandel.   04:45, 22 February 2011 (UTC)[reply]
          • The bot does not confine itself to internally inconsistent articles. At least with those articles you could claim they were wrong to begin with, so the bot didn't make them any worse. But the bot, unless carefully supervised, will introduced errors in articles that have consistent date formats. Wrong placement of commas is recognized as an error throughout the English-speaking world, while not using dmy on British-related articles is merely a Wikipedia preference that most of our readers are unaware of. So turning the bot loose on an internally consistent article will most likely make it worse. Jc3s5h (talk) 05:07, 22 February 2011 (UTC)[reply]
            • Well, that would be an issue. Could you please provide an example of an article that would suffer the problem you mention?  GFHandel.   05:17, 22 February 2011 (UTC)[reply]
              • History of Rugby, Warwickshire (search for "November 5, 1605,"). Jc3s5h (talk) 05:44, 22 February 2011 (UTC)[reply]
                • The script would add {{Use dmy dates|date=February 2011}} to the top of the page, and convert your example to "On the eve of the plot on 5 November 1605, the plotters stayed at an inn...". That's understandable by our readers, and localized editors can alter accordingly if required. Are there any other examples?  GFHandel.   08:42, 22 February 2011 (UTC)[reply]

An example of unnatural placement of a comma if mdy to dmy conversion were performed may be found in Polish prisoners of war in the Soviet Union (after 1939):

Thus the military agreement from August 14 and subsequent Sikorski-Mayski Agreement from August 17, 1941, resulted in Stalin agreeing to declare the Molotov-Ribbentrop Pact in relation to Poland null and void,

Also, the standard of performance of a bot that is supposed to improve style is that it improve style, or at least not introduce style errors where there was no error before. " That's understandable by our readers" is unacceptable as a standard of performance. Jc3s5h (talk) 14:26, 22 February 2011 (UTC)[reply]

• Actually, there is so much about that part-sentence that needs improving that it dwarfs the point you are trying to make.

Thus the military agreement from of August 14 and the subsequent Sikorski-Mayski Agreement from of August 17, 1941, resulted in Stalin agreeing Stalin's agreement to declare the Molotov-Ribbentrop Pact in relation to Poland null and void,

That's without even the required en dashes: "Sikorski–Mayski Agreement" and "Molotov–Ribbentrop Pact", although some editors might want to make a case against those. I find no particular advantage or disadvantage in retaining or removing the comma after 1941, but even if I did, the text requires higher-level treatment anyway. We could argue about whether there might be a comma after "Thus", too. This is a widespread pattern. Using a bot to harmonise date-formats seems like a good idea, since it is rare that they would encounter such an objection. I encourage editors to focus on the bigger job of fixing grammar and improving clarity; if that comma is the worst it gets in auto-assistance, it's not a problem to me. Tony (talk) 15:02, 22 February 2011 (UTC)[reply]

How about The terrorism of 5 November 1605, was among the worst... Is that a problem to you? Septentrionalis PMAnderson 16:47, 22 February 2011 (UTC)[reply]

This proposal has inspired me to begin a Request for Comment at WT:CITE#May a bot protect template citations but not plain citations?. Please note that even if the RfC determines that in general, plain citations should be given the same level of protection against bot alterations as citation templates, it might be decided the final design of this bot would make alterations to plain citations sufficiently rare that the bot could be approved. Jc3s5h (talk) 15:07, 20 February 2011 (UTC)[reply]

Could someone explain in words of one non-technical syllable what this is proposing to do? The reason I ask is I've been a bit concerned about some of your date edits, Ohconfucius, which have turned up on my watchlist, where you seem to be changing to dmy for no obvious reason. So I'd be a bit concerned about you botifying that. SlimVirgin ^{TALK|CONTRIBS} 16:27, 20 February 2011 (UTC)[reply]

(edit conflict) It seems to me that this BRFA is currently unlikely to be approved as an uncontroversial task with clear consensus, as required per BOTPOL. This is mainly due to human judgement required to resolve various possible false positives. And inadvertently Ohconfucius got involved in an area of his topic restriction. This all makes it very hard for BAG to even trial the bot whilst false positive issue remains open. This actually boils down to the task appearing/being "automatic". Even if the operator resolves any problems every day, this still leaves a window between the bot edit and the correction by the operator; a delay and edit which the participating editors apparently contest. The fact that this is a supervised task is almost never mentioned, even in the RfC, when discussing if the bot should perform the edits.

That said, the base proposed tasks are not actually contested -- correct punctuation/grammar should be enforced, non-germane dates should be unlinked, prose date format should be consistent, reference date format should be consistent, date format should tie with article subject. These are valid edits, just not automatically, because there is no consensus for that (what the BRFA is for). On the other hand, should this task be manual, it would become full editor's responsibility to verify the edits before committing them. Thus, any false positives become a human mistake. Of course, all the false positive issues would still stand; but for all BRFA purposes, should the editor prove they can fully verify their edits, such task can be approved.

So what I personally suggest is that the operator files a separate BRFA for manual implementation of each of the sub-tasks. Of course, this may not be the venue the operator wished to take. But from BAG's standpoint, that will be the easiest to deal with. —  HELLKNOWZ  ▎TALK 17:11, 20 February 2011 (UTC)[reply]

{{BAG assistance needed}} May I request a second/third BAG opinion on this issue, please. An RfC just got opened based on the BRFA by the operator who is topic banned. Should this BRFA be continued or should we endorse the operator to pursue separate BRFAs and/or specification as a manual task? —  HELLKNOWZ  ▎TALK 17:11, 20 February 2011 (UTC)[reply]

It seems to me that if the changes are effectively approved for manual use, then the only reason to withhold permission to run automatically is that we believe there will be errors that should be caught by a manual run. This is an easy hypothesis to test with a series of trials. Rich Farmbrough, 01:17, 22 February 2011 (UTC).[reply]

I would say we know the bot will make errors without manual assistance. As stated in the function details section, "adds commas where necessary (e.g. February 28 2001) – already a standard AWB fix – but will not amend any punctuation (i.e. will not insertion of a comma or changing same into or from full stops) after the year in the date string." We know there are four style guides that say that in mdy dates, the year should be set off by commas on both sides of the year. We must hope many editors are following these style guides. We know (and the Chicago Manual of Style concurs) that there are no commas used with the dmy dates. So when a properly formatted article that uses mdy dates is changed to dmy dates with no manual assistance, many of the dates will be followed by a comma that does not belong there. (Some of the dates will be correctly formatted because a comma is needed due to sentence structure, or because they are at the end of a sentence.) Considering Rich's skill with automation, I imagine he could search for instances of a month, one or two digits, a comma, four digits, and a comma, which fall outside a citation template. Most of these instances would result in errors if MOSNUM Bot were to process them. Jc3s5h (talk) 01:57, 22 February 2011 (UTC)[reply]

The objective of this bot is to align the date fragments. I have already clarified that we are not aiming for "perfect compliance" with the MOS. The punctuation after the date is not within the scope of the bot, and as such will be ignored. When I'm not aiming to make a certain change, and it isn't changed by the bot run, it isn't an "error". Plus rien à dire? --Ohconfucius ^¡digame! 02:04, 22 February 2011 (UTC)[reply]

If you truly believe you can turn an erroneous edit into an acceptable edit by defining the scope of your objectives such that the damage falls outside the scope of your objectives, you should not be running any bots. That rumble I feel must beIsaac Asimov rolling over in his grave. Jc3s5h (talk) 02:22, 22 February 2011 (UTC)[reply]

Jc3s5h: this is about commas in some dates, where commas are needed. You are making a mountain out of a mole hill and your allusions to Asimov drives home that your arguments are getting over-the-top and silly. We don’t need “three-law-safe” so read-hearted robots don’t hurt humans; nor a big illuminated E‑stop panic button mounted on your nightstand. This is a software tool to fix date fragments with some commas for God’s sake. Gi’me a break. Greg L (talk) 03:21, 22 February 2011 (UTC)[reply]

• I wasn't going to say anything here to dignify that unwarranted mauling. I had already said something to Jc3. --Ohconfucius ^¡digame! 03:31, 22 February 2011 (UTC)[reply]

P.S. I might add, Jc3s5h, that an edit you made, which Ohconfucius had to revert (his ∆ edit here) seemed either to be intended to bait or was intended to drive home a point about improper edits done that have to be manually fixed. You know full well the comma belong there. The rest of the community doesn’t have time for play-ground antics. Please behave yourself. Working in a collaborative writing environment is double-tough with you behaving this way. It would be nice, when I look at other editors’ contributions history, that I don’t discover that they have to devote even more time to Wikipedia undoing your mischief-making as they labor to do the heavy lifting to grow and improve the project. Greg L (talk) 03:39, 22 February 2011 (UTC)[reply]

Actually, no. For such a short parenthetical, the comma may be omitted. Both of them are wrong. Septentrionalis PMAnderson 03:49, 22 February 2011 (UTC)[reply]

Jc3s5h: you have said elsewhere, after one of your edits damaged the text, "When I was in grade school I was taught to put a comma where I would take a breath when reading aloud."—Interesting idea. Might be OK as a contingency to get little kids to think about one aspect of comma usage, but as a principle for adult writers, it is a gross oversimplification.

Concerning the bot application, methinks you may run the risk of appearing to be WP:POINTY. Please assure me this is not the case. Ohconfucius is not perfect (the same applies to me and to you), and has made mistakes as a bot and script runner. What Slim said above resonates with my own observations, and I'm sure that now it has been pointed out, OC will change this occasional practice. Overall, OC shows every sign of good faith and of learning from any mistakes he has made (how else does one acquire the right experience?). I think, Jc3, that you might consider giving him a little more slack, and come back with full force if he doesn't live up to BAG's high standards if granted bot permission. Tony (talk) 06:57, 22 February 2011 (UTC)[reply]

I agree, and let's encourage editors who bring great skill to the project and who are willing to work very hard to improve WP for all.  GFHandel.   07:24, 22 February 2011 (UTC)[reply]

Where is the evidence of "great skill"? Ohconfucius is unable even to assure us that this bot will not revert-war continually on the same article; he has declared that this bot will produce garbles, and that they don't matter. Septentrionalis PMAnderson 16:53, 22 February 2011 (UTC)[reply]

There is a quotes hiding feature within AWB's text hiding logic, which we use to avoid applying typo fixing to text in quotes. This hides quotes based on the use of double quote marks etc. I do not assert that it is perfect but I do believe it's doing quite well, and if used might considerably reduce the false positive rate for date changes on text within quote marks i.e. quotes or titles within hand-formatted citations. Rjwilmsi 15:52, 26 February 2011 (UTC)[reply]

O.K., there has not been further BAG input on the matter. Comments made above are relevant to the date formatting, but not to the BRFA. Again, no one is addressing the automatic vs. supervised issue. This is not the right place to discuss dates, especially if the operator has topic restrictions. BOTPOL: This is the place to come with a link to consensus, function details, and confidence of very few to no false positives (no additional work for humans).

In short: While the tasks may have consensus in principle, concerns are raised at the false positive rate in context sensitive content; and the operator cannot demonstrate consensus to perform these tasks by an automated bot. —  HELLKNOWZ  ▎TALK 09:33, 1 March 2011 (UTC)[reply]

The above discussion is preserved as an archive of the debate. Please do not modify it. To request review of this BRFA, please start a new section at WT:BRFA.