Wikipedia talk:Manual of Style/Dates and numbers

Date range redux

To keep Legobot from removing the RfC Technical 13 (talk) 18:03, 29 December 2013 (UTC)

An old issue resurfaced. An editor again reverted a date range in the format mandated by our MOS. I've re-reverted, per MOS.

MOS says:

"Year ranges... sports seasons spanning two calendar years should be uniformly written as 2005–06 season....
A closing ... year is normally written with two digits (1881–86) unless it is in a different century from that of the opening year, in which case the full closing year is given (1881–1986)." (emphasis added)

This editor insists on reverting. Deleting the MOS-approved style of six digits, in the above example. And inserting his own preferred non-MOS style of eight digits (2000-2001).

He doesn't deny that the MOS states what it states. He either argues that there "is not consensus" to enforce MOS. In other words -- it appears that he will not follow MOS or accept it as consensus unless there is another consensus discussion that MOS will be enforced ... a concept I am unfamiliar with, and find unconvincing. MOS reflects our consensus. Or he argues that a wikiproject has decided not to follow MOS for sports articles, and that a wikiproject has the power to trump the consensus reflected in MOS itself.

I've invited him to seek to change MOS, if he wishes to. But asked that he not edit in violation of MOS.

He just reverted to the non-MOS format again.

Thoughts?--Epeefleche (talk) 02:36, 25 November 2013 (UTC)

Correction - it is not accurate to say that I think a project trumps MOS. As I state below, I do not think MOS closes the door on interpretations and since we went through a very long discussion here in April (linked below) with no definite end mandating 6 digit use in these cases, I think that the consensus in the form of tens of thousands of edits by multiple projects should be respected unless and until this is clarified. I don't see it as an MOS violation at all and since this editor started the last conversation he should be well aware that it had no resolution. Rikster2 (talk) 03:25, 25 November 2013 (UTC)

Request to formally insert language that an 8-digit date range format be allowable for sport tenures. This was discussed ad nauseum to no firm resolution in April (see here). In that discussion, it was pointed out that this format is used in infoboxes (not text) by most of the major sports projects (10k+ articles) to display club progression/tenure and that the strict MOS view would show tenures that span over a century change (e.g. 1997-2003) differently than those that don't (1988-91). In that discussion I linked evidence that this exact usage (specifically for summary profiles of athletes showing club tenure) is used by all of the biggest English-speaking professional sports organizations in an official capacity (Here are examples from the NBA, the Premier League, the NHL, the NFL and Major League Baseball (Search any common name in the historical dbase and see what comes back). In my opinion, the use of this format is a valid style choice and should be allowed in these narrow circumstances. I would like to ask that this use be expressly added to the MOS. In my opinion, we discussed this last time and no mandate came (MOS itself says dates are normally shown in 6 digit format, meaning there are circumstances where they aren't). I say we put this to bed and add language that makes it clear. Rikster2 (talk) 03:01, 25 November 2013 (UTC)

It's quite clear from the above-quoted language that MOS dictates precisely the opposite of what you are requesting. The fact that some editors (including, perhaps, you?) have flouted our consensus-driven MOS and -- despite what MOS clearly requires -- input the opposite, doesn't lead to the conclusion that your against-MOS edits then dictate that MOS be reversed. Because you and some others have ignored it.

Furthermore, the MOS quoted above indicates -- specifically as to sports, which is what is at issue here -- the limited instance when the 6-digit format is not used ... which is when "it is in a different century from that of the opening year". Your changes don't fall within that category.

In addition, The issue is 2011-12 (670 thousand ghits) vs. 2011-2012 (197 thousand ghits). As you can see from the ghits, the approach excluding the extra digits (which impart zero info) is standard.

If you search NBA.com, the official basketball website for the NBA, you will see that 2011-12 is also the preferred approach (995 hits vs. 38 hits).

If you search NHL.com, the official hockey site for the NHL, you will see that it is the preferred approach (2,762 hits vs. 141 hits).

If you search NFL.com, the same (approaching 2-1). And more than 3-1 for the Euroleague basketball league.

And that is what our MOS calls for.--Epeefleche (talk) 03:45, 25 November 2013 (UTC)

Never said those specific edits were the turn of a century. I said that a strict mandate for 6 digit was asked for by you and never received. Therefore I don't think you have a leg to stand on to individually force such a strict mandate over the consensus formed over tens of thousands of articles. Rikster2 (talk) 04:05, 25 November 2013 (UTC)

ghits are irrelevant when I am linking to the exact same purpose used on Wikipedia today - summary tenure of athletes' club history - like infoboxes. I have linked player profiles and databases meant to show exactly this, not the site as a whole which has all sorts of date formats mixed in. At a minimum, t shows a valid style choice. And MOS does not dictate anything. It is a guideline. You sought strict enforcecment in these cases in April, and now you are trying to enforce your will in the absence of that happening then. Wikipedia is built on common sense and questioning. Let's have the discussion now and get this to the finish line (though more than just you and I will need to be a part of that of course). And of course I am "one of" the editors who uses this convention - though it is important to point out that I was not the originator of it (though I agree with it). It is used in at least association football, American football, basketball, baseball and cricket. That's a lot of editors to all reach the same conclusion. Rikster2 (talk) 04:01, 25 November 2013 (UTC)

I support Rikster2's proposal that the MOS be amended to allow for 8-digit date range formats for sport tenures. As Rikster2, explains, the relative number of g-hits between the two formats are irrelevant to this issue. Individual seasons (often carrying the 6-digit format) are naturally going to have more mentions that multi-season tenures. I was not the originator of this convention either, but have independently reached the same conclusion about it as Rikster2 has. Jweiss11 (talk) 06:48, 25 November 2013 (UTC)

• Support Rikster2's proposal per common sense and clarity. Sports seasons are often abbreviated using the six digit format - i.e. 2012–13 season. If a player joined a club in January 2012 (i.e. during the 2011–12 season) and left in December 2013 (i.e. during the 2013–14 season). The current format (2012–2013) makes it clear that this is not the same time period as the 2012–13 season. In addition, if we have six digit ranges for years in the same centuries instead of eight-digit ranges, then it just makes the left-hand column in infoboxes look stupid when a player's career spans a new century. We've been using this format for years without complaint and I see no good reason to change. Number 57 13:37, 25 November 2013 (UTC)

• MOSNUM contradicts itself. In the subsection "WP:MOSNUM#Other date ranges" it states "Dates that are given as ranges should follow the same patterns as given above for birth and death dates." In turn, the "Dates of birth and death" section states that in cases where only the years of birth and death are known, the full years should be given (8 digits for 2nd and 3rd millennium births/deaths). On the other hand the "Years" subsection within the "Longer periods" section indicate that for four-digit years the end of the range should be given with just two digits, except when spanning a century. I'd like feedback on whether others agree there is a contradiction, and if so, an RfC should be initiated to see what the community wants to do about it. Jc3s5h (talk) 14:20, 25 November 2013 (UTC)
  • Comment - Certainly looks like a direct contradiction. If it makes the most sense to roll this discussion in with some larger effort to clean this up I am all for it. Rikster2 (talk) 20:59, 25 November 2013 (UTC)
• Support Rikster2's proposal Proposal reflects year ranges in reliable sources in the US sports domain (if not other countries and/or subjects). WP:GUIDELINE states in the lead that WP "does not employ hard-and-fast rules", allowing common sense in cases such as this. Per WP:PROPOSAL, guidelines are meant to document existing practices, not to override them. 2- or 4-digit format can coexist in WP, as long as there is consistency within a given article, and the format is consistent with sources in the article's domain.—Bagumba (talk) 21:22, 25 November 2013 (UTC)
• Support Rikster2's proposal, although "we currently do it this way" is not my primary reason. In football, it is common for a player to stay at a club for between a few months and a few years. It is therefore quite common for a player to be with a club in a period which under the six digit notation would be denoted as 2012–13. Often this will correspond with the 2012–13 season, but his actual tenure at the club could equally be significantly different from the length of time that notation would ordinarily imply. It is therefore preferable to have one form of notation for year ranges, and another for seasons, in articles where both would commonly be used. —WFC— _{FL wishlist} 21:51, 25 November 2013 (UTC)
• Another comment Princeton Editorial Style Guide says that a year range should be hyphenated and generally end in two digits when the range is used as an adjective. The range in the infobox effectively represents a noun, a tenure, and not an adjective. When the year range is a noun, the Princeton MOS recommends four digits, e.g. "from 1989 to 2005". The usage being contested in this thread is regarding a sportsperson's tenure listed in an infobox, not prose. It seems reasonable to allow the option for a compact form in an infobox to drop "from/to" but retain the 4-digit recommendation.—Bagumba (talk) 22:09, 25 November 2013 (UTC)
• Comment preferring uniformity I would tend to agree with the 6 digit form and support Epeeflech. I see no reason to extend the dates as long as the meaning is understood. JOJ ^Hutton 22:40, 25 November 2013 (UTC)
• Comment I disagree that Dates of birth and death has anything to do with the conversation as we're talking about sports tenures which are directly and unambiguously addressed in WP:YEAR. In the Gal Mekel example it is painfully obvious what the Manual of Style states should be done. Furthermore I am not seeing any good reason to change the MOS. Support Epeefleche. Also, regarding the comment "MOS itself says dates are normally shown in 6 digit format, meaning there are circumstances where they aren't", the circumstances where they aren't are plainly stated: "unless it is in a different century from that of the opening year, in which case the full closing year is given (1881–1986). " I find this discussion to be bizarre. The existing policy is neither ambiguous nor broken. Rejectwater (talk) 00:39, 26 November 2013 (UTC)
  • Comment I disagree. "Normally" is not "always" so I read that differently, otherwise there was no need for this to be bantered about to no resolution 7 months ago. And User:Jc3s5h is exactly right in that there are actually two different standards in two different places, so I don't see where anyone can truly argue that this does not need to be clarified at this point. Rikster2 (talk) 00:54, 26 November 2013 (UTC)
    • Please see "sports seasons spanning two calendar years should be uniformly written as 2005–06 season." This is not ambiguous in any way and requires no clarification. "Normally" is not "always": I agree. The word "always" does not appear in the paragraph "A closing CE or AD year is normally written with two digits (1881–86) unless it is in a different century from that of the opening year, in which case the full closing year is given (1881–1986). For clarity, years with fewer than four digits may be written in full (355–372)." Likewise, this paragraph is neither ambiguous nor in need of any clarification. "Dates that are given as ranges should follow the same patterns as given above for birth and death dates." Fantastic. This refers to terms where the entire date is written, as in "Jack Adams was general manager of the Detroit Red Wings for almost 35 years (May 14, 1927 – April 26, 1962)", or when exact dates are not known, or not entirely known (ie, the scenarios covered in the birth and death date section). There are two specific clauses that handle year ranges that only show years (tenures of sports players, for example): "Year ranges, like all ranges, are normally separated by an en dash, not a hyphen or slash: 2005–06 (unspaced) generally denotes a two-year range; 2005/06 may be used to signify a period of 12 or fewer months, such as a corporate or governmental fiscal year, if that is the convention used in reliable sources; sports seasons spanning two calendar years should be uniformly written as 2005–06 season. A closing CE or AD year is normally written with two digits (1881–86) unless it is in a different century from that of the opening year, in which case the full closing year is given (1881–1986). For clarity, years with fewer than four digits may be written in full (355–372)." I fail to see where any clarification or modification is necessary. That "there was no need for this to be bantered about to no resolution 7 months ago", I also agree with completely. Rejectwater (talk) 02:10, 26 November 2013 (UTC)
      • If "A closing CE or AD year is normally written with two digits (1881–86) unless it is in a different century from that of the opening year, in which case the full closing year is given (1881–1986)" means that 6 digit is mandated, then why is the qualifier "usually" included at all? Without the qualifier it means "always," no? With it (to me) it means "usually it's 6 unless it spans a century (in which case it usually means 8)". Very open to interpretation, which is why it was discussed to no resolution in the Spring. And "sports seasons spanning two calendar years should be uniformly written as 2005–06 season" refer to a single athletic season that spans two calendar years (like basketball or hockey), not multiple seasons (ie - tenures, which is the specific 8 digit use being discussed here). Rikster2 (talk) 02:20, 26 November 2013 (UTC)
• I replied yesterday and evidently neglected to save. The gist is that tables of sports data by season should simply use "1898-99", "1899-00", "1900-01". "1899-00" is clear in context and there is precedent, eg for use of YYYY-MM-DD in tables rather than any date format with alphabetic month names. --P64 (talk) 01:47, 26 November 2013 (UTC)
  • Clarifying question Each example you cite is a single sports season. Is your opinion also that tenures of multiple years (e.g. 2001-2005 or 2001-05 if you prefer) must be expressed this way? I think the answer is yes, but I'd like to be clear as single season ranges aren't the focus of the discussion. Rikster2 (talk) 02:28, 26 November 2013 (UTC)
• Would any of the supporters care to explain why it is a good thing for the MoS to specifically encourage 2012–13 and 2012–13, in the specific case of articles which routinely use both? In football the form 2012–2013 would never be used to denote a season, hence that form's desirability as a way of denoting year ranges. —WFC— _{FL wishlist} 02:04, 26 November 2013 (UTC)

• Support for the Request to formally insert language that an 8-digit date range format be allowable for sport tenures. Speaking as a member of the ice hockey project, an 8-digit date range format for article titles is the most commonly used format [1][2][3], and also allows for consistency in appearance when the years span over to the current Millennium. Although most defunct ice hockey teams and leagues have now been needlessly moved from their original (19xx–19xx) to (19xx–xx) titles (see All American Hockey League (2008–11) as just one of many examples), it is much preferred to use (19xx–19xx) for all such article titles when required. Not only does the 8-digit date range comply with WP:COMMONNAME (as least when to comes to ice hockey teams and leagues ) but it is also useful for clarity and consistency between articles which still use the 8-digit format in the title (for example International Hockey League (1945–2001)). Within ice hockey articles the 2012–13 format is correctly used for single seasons, but it is correct to use 2003–2009 to indicate a span of several seasons. Dolovis (talk) 21:32, 26 November 2013 (UTC)
• Strong oppose—Dolovis, eight digits might be, in your view, "the most commonly used format", but so what? We have special requirements, such as infoboxes and tables, both of which are space-constrained. I think this is a case of WP:I'MNOTUSEDTOIT. 124.171.120.208 (talk) 10:11, 27 November 2013 (UTC)
  • Can someone claim responsibility for the above IP comment? I find it strange that an IP's first edit would be this one, citing WP essays. Assuming good faith, I expect someone wasn't logged in, as opposed to engaging in some sort of sock puppetry. Rikster2 (talk) 19:57, 28 November 2013 (UTC)
    • Comment - currently the "space constrained" infoboxes in the majority of sport projects are doing just fine with the 8 digit format. I don't think that reason holds as much water as usage in the real world for the same purpose it's being used here. Rikster2 (talk) 12:54, 27 November 2013 (UTC)

• Correction: Normally the "2005–06 season" would be a 2-year season. A one-year season spanning 2005 and 2006, like an academic or fiscal year, would be the 2005/06 season (or 2005/2006 season). But sports seems to be an exception: "2005–06" is a season of 12 months or less, while "2005–2006" would imply two seasons. The seasons should therefore be 6 digit, while longer spans, such as 2008–2010 in this case, should be 8.
  Also, you can't respell Hebrew with English, so I deleted that. We can have a separate English pronunciation if we want. — kwami (talk) 17:19, 27 November 2013 (UTC)
• Strong oppose Rikster2's proposal: The 6 digit format year span is short and sweet, and is a format adopted as consensus after much discussion. It's a format perfectly suited to the density of infoboxes. Yes, different sports in different cultures seem to treat seasons' spans differently. However, I don't see many instances where there would be cause for ambiguity in an infobox – my major concern. The sport, the article and the other dates supply the necessary context for what the years mean. Also there is the inclination of editors to plaster these infobox dates with links to season articles, so I very much doubt that a year span like "1991–08", sandwiched between lines that have "1989–91 and "2008–11" as seasons, could ever be misconstrued, even if there were no links whatsoever. -- Ohc ^¡digame! 01:49, 29 November 2013 (UTC)
  • Could you please find and link the consensus discussion you mention? It would be helpful to this discussion because there is also a Consensus in the form of tens of thousands of articles for the 8 year span and we need to navigate the two. I should also point out that your proposal of a consistent 6 digit year span, even in cases spanning a century also does not meet current MOS phrasing. One way or the other, this standard will need to be modified. Rikster2 (talk) 03:03, 29 November 2013 (UTC)
• Oppose Rikster2's proposal. Much ado about nothing, frankly. The six digit format works for 99.9% of cases in the sports world, and I see absolutely no value in changing to eight simply for the sake of the .01%. Particularly since it is often unnecessary when placed in context. i.e.: in Jarome Iginla#Regular season and playoffs, nobody with a modicum of common sense would fail to understand that 1999–00 means "1999–2000". Resolute 19:00, 29 November 2013 (UTC)

Even regarding a span of full years, rather than a season spanning two-calendar years, we may expect that almost all readers understand "1999–00" in many contexts. For example, I read in a print newspaper three days ago that Joe Torre, newly elected to the baseball Hall of Fame, managed the New York Yankees to World Series victories in "1996 and 1998–00". Boston Globe or New York Times, a venerable newspaper that does edit such things. --P64 (talk) 23:59, 13 December 2013 (UTC)

Strong oppose. But I'm not so enamoured with "1998–00" ... readers have to stop for a half second to think about it. It's abominable that some infoboxes and tables currently clutter things up with full nine-character year-ranges; and even in running prose, I believe seven-character forms are easier to read (my PhD was in the pscyhology of reading, although I can't point to research precisely on this example, I concede ... it's a hunch from everything I have read on eye movement in reading text). Tony (talk) 01:51, 14 December 2013 (UTC)

• I support Rikster2's proposal for the same reasons as User:Number 57. The 8-digit range also avoid confusion with seasons. --Jaellee (talk) 12:04, 14 December 2013 (UTC)
• Support Rikster2's proposal for sports, as per N57. In association football the format is almost always "xxxx–xxxx". GiantSnowman 13:50, 14 December 2013 (UTC)
• Comment There's no way the average reader can be expected to know that 2012–13 is meant to mean something different than 2012–2013. I'm not crazy about the 2012–13 format in some situations, and don't think it has achieved consensus, which is why it is weasel-worded in the MOS. I think the MOS should be clarified to say that either is OK, and that it is reasonable to try to achieve consistency among a related group of articles. I do think it's reasonable to edit to use the abbreviated format in tables, if only to make better use of precious screen width. These seem like reasonable causes for edits, as opposed to blind following of MOS prescription. —[AlanM1(talk)]— 01:56, 18 December 2013 (UTC)
• Comment. Acceptable numeric season formats: 2011/2012, 2011/12 (only where space is severely constrained), 2012. Acceptable numeric time span formats: 2011…2012, 2011–2012, 2011 – 2012, 2011-12 – 2012-01, 2011-12-30 – 2012-01-02. Acceptable numeric month date format: 2013-12 (i.e. December). Everything else is too ambiguous. — Christoph Päper 13:27, 28 December 2013 (UTC)
  • Oppose two digit year formats such as 2011/12 or 2011-12, and two digit month formats (with no day) such as 2013-12, as I'm concerned this will encourage editors to add ambiguous formats such as 2001-03. GoingBatty (talk) 18:19, 29 December 2013 (UTC)
• Neutral for now... Due to the response that this has gotten so far, I've tagged it as an RfC to get a wider variety of input. Feel free to drop notes on appropriate forums or I can do it in about 9-10 hours (need to run out for a day with the ex and my baby). I'll also add it to {{Centralized discussion}} if not done. Technical 13 (talk) 13:57, 28 December 2013 (UTC)
• Support Rikster2's proposal. It makes sense especially given the fact that some sports pages already use the 8-digit format, and it would help certainly make reading slightly smoother in some cases, such as dates across centuries and cases where the second year could be mistaken for the month (I personally find something like "2001-02" a little distracting since I sometimes read it as "February 2001", although that may just be me...). I also don't expect that the proposal would cause problems with infobox formatting as someone above suggests, simply because I would expect editors to use common sense when applying the changes (it's not like the idea is to mandate that every year range in sports pages must be 8-digit!) As an aside, association football actually seems to use a variety of formats: both "YYYY-YYYY", and "YYYY-YY", are used at various points by the English Premier League.-Well-rested^Talk 16:16, 2 January 2014 (UTC)
• Comment Dates of the form "2003-04" are confusing in the |date= parameter in citations, since they may be interpreted or intended as "2003-2004" or "April 2003". I suggest making it clear that the six-digit year range (e.g. "2003-04") should be used only in prose, but not in citation date parameters or other locations where its meaning may be ambiguous. – Jonesey95 (talk) 16:38, 2 January 2014 (UTC)

• I dispute the concept that MOSNUM has authority over citations. If such a change is to be introduced, it should go in WP:CITE. Also, it should go through a separate RFC rather than being tucked into a thread that is only tangentially related. Note that such a change would potentially break software used in creating citations, whether used to create help:Citation Style 1 templates or other citation styles such as Chicago Manual of Style or APA style. Jc3s5h (talk) 16:53, 2 January 2014 (UTC)

• Support Rikster2's proposal There is no need to be prescriptive here, particularly given the potential for different conventions in different countries or sports. And the point about ambiguity is a valid one too. Neljack (talk) 01:37, 3 January 2014 (UTC)

• Comment There are also YYYY-Y ranges - there appear to be some on Aran_Islands#Further_reading, for example. GoingBatty (talk) 15:49, 4 January 2014 (UTC)

• Support for Rikster2's request: "Request to formally insert language that an 8-digit date range format be allowable for sport tenures." I personally think full-digit writings of years should be always allowed and always preferable in order to avoid potential confusion with YYYY-MM or YYYY-DDD formats (which themselves should be not advised). Startswithj (talk) 22:12, 5 January 2014 (UTC)

• Comment: Epeefleche is correct; MOS is clear on this and is the guideline. If Rikster2 wishes to change MOS he should open up a new RFC and propose his change there. Until consensus occurs through that process, edits should not be made in violation of standing MOS. Holdek (talk) 22:56, 6 January 2014 (UTC)

Comment This discussion is currently an RFC (see top of discussion). It is absurd to suggest that I reopen it and we start all over again. Rikster2 (talk) 23:12, 6 January 2014 (UTC)

Also, I must point out that Epeefleche himself has edited the article starting this discussion using two different date standards, using two different parts of MOS - I think what is clear is that MOS is not clear. This needs to be solved one way or the other. Rikster2 (talk) 23:16, 6 January 2014 (UTC)

The RFC is for comments on alleged violations of MOS by you. However, folks' reaction to your proposal might be a helpful predictor as to whether or not a new RFC by you would be successful in achieving consensus. Holdek (talk) 01:45, 7 January 2014 (UTC)

Totally disagree this is why this was put up for RFC, but why not ask the admin who listed it? 20-something editors have weighed in on my proposal so starting over is, in a word, nuts. It's also red tape for the sake of red tape. Rikster2 (talk) 01:57, 7 January 2014 (UTC)

I just left a message for the admin who listed the RFC. Hopefully he/she will come and clarify. Rikster2 (talk) 02:00, 7 January 2014 (UTC)

Just so I'm clear on the reason for my comment: regardless of the lister's intention, the template is above Epeefleche's complaint and his ending of, "Thoughts?" so I presumed that's what I was supposed to be responding to. I'm not trying to give you a hard time or add red tape for the sake of red tape or otherwise act "absurd" or "nuts." Holdek (talk) 23:10, 7 January 2014 (UTC)

• For the record, I'm the user that tagged this as an RfC. I'm as far from an admin as one could possibly be and the community would laugh at an RfA from me if one was posted because quite frankly, I have very poor social skills and am bad with communicating. That said, the reason I tagged this as an RfC is because I see mostly longer standing editors commenting here that are mostly specifically interested in how the MOS is set up and I thought it would be wise in order to get a wider range of consensus to tag it as an RfC to get a wider range of editors thoughts on this proposal. I am personally interested in the outcome of this as I spent a bit of time trying to make Template:Marriage conform to what my understanding of this is, and if it changes, I'll likely have to update that template again as well. I'm still neutral at this time, as I do not see a whole lot of extra participation going on. Happy editing! Technical 13 (talk) 14:07, 8 January 2014 (UTC)

Abbreviated months in citations

Per the discussion I started at Module talk:Citation/CS1/Archive 8#Another date check question, I noticed that month abbreviations with a period generate a CS1 date error, but abbreviations without a period are ok. While WP:MOS#Months and seasons shows that "Feb." is appropriate, MOS:DATEFORMAT shows "Sep" with no period. Would it be reasonable for this topic to be consistent across these two MOS pages? Thanks! GoingBatty (talk) 04:51, 10 December 2013 (UTC)

Actually, WP:MOS#Months and seasons says: "Feb. in the United States or Feb in most other countries". MOS:DATEFORMAT gives examples of 8 Sep 2001 and Sep 8, 2001 but is not explicit about whether a period is acceptable (it does not say that versions with a period are incorrect) so they are not inconsistent. I would say that either format is acceptable, but be consistent within each article. —sroc 💬 06:11, 10 December 2013 (UTC) —edited 13:03, 14 December 2013 (UTC)

I have no horse in this race except to note that one of the more annoying things about Wikipedia guidelines is that guidelines are sometimes distributed across multiple pages as can be seen by comparing MOS:DATE#Chronological items to Wikipedia:MOS#Dates and time. Which of these is the "more correct" guideline? If neither, then perhaps they should be merged so that there is a single complete guideline. It would seem that MOS:DATE#Chronological items is the primary guideline given that MOS#Dates and time several times links to it and because MOS:DATE#Chronological items contains multiple shortcut anchors implying that editors ascribe more weight to the content of MOS:DATE#Chronological items than to MOS#Dates and time.

—Trappist the monk (talk) 13:23, 10 December 2013 (UTC)

May be it is time to reduce the number of variants and take this opportunity to remove the option to have a period following an abbreviated month. It is probably the least used from my experience. Keith D (talk) 13:50, 10 December 2013 (UTC)

I am all for harmonisation too. It's not always easy to spot inconsistencies like that, where the ref section might have all of "Sep. 31, 2013", "Sep 31, 2013" and "September 31, 2013". Some readers may be sensitive to the differences, but a script or bot will pick it up in a split second. When there are such mixed formats, a human will need to arbitrate between which one should prevail in each case. A nuisance. -- Ohc ^¡digame! 14:05, 10 December 2013 (UTC)

Regardless of month name abbreviation style, these dates will fail the CS1 date check because there are only 30 days in September.

—Trappist the monk (talk) 16:27, 10 December 2013 (UTC)

There is no consensus about where to settle this question. A discussion about whether it should be covered by this guideline or WP:CITE was inconclusive. A disadvantage of imposing date format requirements on citations is that there is a lot of citation management software out there, such as Zotero and EndNote; any requirements we might invent could be incompatible with citation management software.

There is consensus that ambiguous formats such as 12/10/13 are unacceptable because the uncertainty they introduce is worse than any software incompatibility that might exist (if there are any citation management software designers stupid enough to adopt such a rotten format). Jc3s5h (talk) 15:26, 10 December 2013 (UTC)

• Nobody's talking about ambiguous formats such as 12/10/13. Formats such as 2013-Sep-31 and 31-Sep-2013 were rightly deprecated, and it would be quite logical to do away with one or other of "Sep. 31, 2013", "Sep 31, 2013". The impact that such a move would have on third party citation management software will be non-existent because machines can parse "Sep. 31, 2013" and "Sep 31, 2013" just as well as "September 31, 2013". -- Ohc ^¡digame! 15:35, 10 December 2013 (UTC)

Given the only time we suggest using abbreviated months is for space-saving on tables and lists in prose, I don't believe we should be using abbreviated months in citation formats, since there's no space issues there. I'm also unaware of any citation format that uses that, and even if some do, then we have to worry about our own house style of using 3-letter abbreviations vs. whatever abbrevation format the source may use. It is just easier to stick to dmy, mdy, or ISO-like for citations. --MASEM (t) 15:53, 10 December 2013 (UTC)

Actually, the table at WP:DATEFORMAT lists references first among the places where abbreviated months are allowed.

—Trappist the monk (talk) 16:00, 10 December 2013 (UTC)

WP:CITEVAR indicates Wikipedia does not have a house citation style. Masem would have to get that changed before attempting to apply WP:MOSDATE to citations. Ohconfucius's comment may be true for developers of external citation management software, who could make their software compatible with ever-chainging Wikipedia guidelines if the feel like it, but is not true for end-users who are not in a position to change the software. Jc3s5h (talk) 16:13, 10 December 2013 (UTC)

I may be mistaken but I think that the original topic of this conversation is the discrepancy between WP:MOS#Months and seasons and MOS:DATEFORMAT and how that should be resolved so that Module:Citation/CS1 does the right thing when it checks date-holding parameters in Citation Style 1 templates.

—Trappist the monk (talk) 16:27, 10 December 2013 (UTC)

I believe that the general MOS is meant, when it comes to date related items, to be a summary of MOSNUM, and any change to MOS that makes it inconsistent with MOSNUM is invalid and should be reverted (I will take a look). But since Trappist's software only checks citation style 1 templates, the acceptable date style may be specified at Help:Citation Style 1. If Trappist can gain consensus to disallow periods after month abbreviations there, that is sufficient to include the restriction in the checking software. Jc3s5h (talk) 16:53, 10 December 2013 (UTC)

• Your revert is retrograde. Of course a style guide is meant to give guidance as to permitted styles, and it always needs tightening and updating. That prohibition was placed there is quite reasonable and not queried at the time. It's been stable for 15 months, and it seems that you only realised it wasn't in conformity with what you had in mind when this discussion opened. I'm sure Trappist didn't mean to open up another can of worms with his request for clarification, but the leeway allowed in the guideline leaves plenty of scope for all that to happen. Also, because the body of style guides is now so utterly complex and some editors seek to use different instructions on different pages to game the system, it does not seem reasonable for MOSNUM to defer to the MOS when the subject is how dates are formatted. I have reverted. -- Ohc ^¡digame! 01:28, 11 December 2013 (UTC)

I will not accept the deliberate introduction of contradictions between MOS and MOSNUM. Seek permission at MOS before decpricating periods after month abbreviations and carry out whatever is agreed upon at both guidelines! Jc3s5h (talk) 02:34, 11 December 2013 (UTC)

• There's no contradiction when one is more general and one is specific to the treatment of dates and numbers. It's quite normal for the former to be more permissive or silent on matters and the latter to be more specific. -- Ohc ^¡digame! 04:22, 11 December 2013 (UTC)

• I'm pleased to see you didn't create a deliberate contradiction, but there is a contradiction. Because the allowed characters are laid out so specifically in MOSNUM, there is a clear implication that periods are not allowed. The following example from MOS clearly states periods are allowed:

• Abbreviations for months, such as Feb. in the United States or Feb in most other countries, are used only where space is extremely limited.

Now, if it was MOSNUM that commented on the acceptability of periods, and MOS was silent on the matter, that would be an example of a more general guideline glossing over a detail in a more specific guideline. But this case is a clear-cut contradiction. Jc3s5h (talk) 10:47, 11 December 2013 (UTC)

Two guidelines are not contradictory merely because one contains additional information that is not included in the other. That said, I agree that it would be preferable for both guidelines to convey the same information about whether or not a period is permitted in month abbreviations, so either MOS:DATEFORMAT should be amended to reflect WP:MOS#Months and seasons or WP:MOS#Months and seasons should be amended to remove the option with a period. —sroc 💬 11:43, 11 December 2013 (UTC)

I think that using a stop is so often used and taught that it should be accepted here as well. Is anybody willing to try and push a unification of standards across these two guidelines? Debresser (talk) 01:19, 31 December 2013 (UTC)

I see Jc3s5h has dealt with the issue by amending MOS to say:

• Abbreviations for months, such as Feb, are used only where space is extremely limited; abbreviations should consist of the first three characters of the month, and are not followed by a full stop unless at the end of a sentence.

—sroc 💬 23:14, 13 January 2014 (UTC)

The change having been reverted, Jc3s5h has now started an RfC at Wikipedia talk:MOS#RFC: Month abbreviations. —sroc 💬 03:32, 14 January 2014 (UTC)

BP dates - guidance needs to say don't change BP to BC/BCE

The guidance says don't convert other dates to BP, but the problem I find far too often is people changing BP to BC/BCE, often simply doing literally that, sometimes adding 2000 years. Even that is wrong particularly with uncalibrated dates. Dougweller (talk) 12:53, 23 December 2013 (UTC)

Too right - must be added. Even calibrated dates are not all the same, and using two different RS may produce inconsistent results and implications. I've been bold and added two magic words: "Do not convert other notations to or from BP unless you are certain of what you are doing.." But a bit more on the dangers might well be added. Not that the people doing it will ever look here, but it may help those reverting them. The page suggests "Years ago" may be a better alternative altogether, which I agree; converting to this is I feel somewhat less of a problem. I think it would be reasonable to insist on raising the issue on talk first. Views? Johnbod (talk) 13:54, 23 December 2013 (UTC)

Agreed guidance must be really, really clear. I do have some sympathy for the misinformed changers as palaeontological/geological/archaeological dates are often a complete mess when they get through to the sorts of secondary and journalistic sources used for Wikipedia. The temptation to 'tidy' them all up must be very strong. Maybe there's an argument for the front end articles connected to Dating (disambiguation) to have clearer guidance too. I've been meaning to fix that since -61BP. PatHadley (talk) 11:14, 24 December 2013 (UTC)

As a relatively few readers will be aware of the difference between BP and BCE dating, could not the convert template be updated to correctly calculate and display both BP and BCE dates in articles? It would seem an educational and productive use of templates to display both to readers. • Astynax ^talk 21:06, 1 January 2014 (UTC)

The convert template automates conversions. The point of this discussion is that the conversion can't be automated. Jc3s5h (talk) 21:50, 1 January 2014 (UTC)

I understand converting BCE to BP would be a chore and a waste of energy, but BP to BCE or even "Years ago" should be doable to address the problem noted of editors attempting to convert. As a calculated date, a conversion can surely be automated, no? If not, then how is the general readership supposed to glean any useful information from dates given as BP? • Astynax ^talk 08:11, 2 January 2014 (UTC)

My (limited) understanding of BP is that it is typically in very rough figures such as 500, 1000, 5000, 1,000,000 - eg 1000 BP rather than 1002 BP. Any automatic conversion would have to round the BC/AD year and also indicate that massive rounding has taken place. The actual amount of rounding would depend on the size of the number. Eg '500 BP' would convert to 'circa 1500 AD' (not '1514 AD') and '1,000,000 BP' would convert to '1,000,000 BC' (2014 years being about 0.2% error).  Stepho  talk  09:16, 2 January 2014 (UTC)

I'd say it is only normally used in article-like contexts (rather than technical reports etc) for BC/BCE dates, and rounded to the nearest 100 at least, more often 1000, then 10K further back. Mind you, there are things like this important article saying things like "an age of 17,610cal.yrBP" (last figure first page). It may depend on context. The last bit of the first para of the article proper is worth reading as an example of the clutter you have to specify if you use radiocarbon data figures properly. Don't forget "500 BP" would be 1450 not 1514, as 1950 is the fixed "Present" - itself enough of a reason to need 2000 years of distance before you start using it. Johnbod (talk) 23:20, 2 January 2014 (UTC)

I'm working on Module:Convert (which implements {{convert}}) at the moment, but I don't think that is the right place for a BP function as only very rudimentary time conversions are available, and BP does not convert to other supported units. However, some other module like Module:Age would be good, and it would be straightforward to implement what Stepho describes—providing someone makes a table of examples showing what is wanted. Perhaps Template:bp (not Template:BP) would be used to invoke the module, but some planning of expected input and output would be needed. Johnuniq (talk) 22:53, 2 January 2014 (UTC)

Conventionally, BP is used to indicate a date obtained by radiocarbon dating. These dates may be uncalibrated, or calibrated in various ways; see Radiocarbon dating#Calibration. A glance at that article will demonstrate this is a complex subject, not suitable for a template. For a module, it would appear that a number of parameters would have to be provided, and the person invoking the module would have to know a great deal about radiocarbon dating in order to understand the parameters. Jc3s5h (talk) 23:24, 2 January 2014 (UTC)

Spacing of mixed numbers

After 3 users noted relevance, tagged as RfC. -Wikid77 18:03, 27 December 2013 (UTC)

The templates {{fraction}}, {{frac}} and {{sfrac}} output mixed numbers with a strange and intrusive space between the integer and the fraction: {{fraction|8|1|2}} -> 8+1⁄2. This is clearly at variance with normal usage; the Fellini film is 81⁄2 not 8+1⁄2, and so on. It seems appropriate to seek consensus here before requesting changes to those templates. I tentatively propose replacing the first two bullet-points of Wikipedia:Manual of Style/Dates and numbers#Fractions with this text:

• The templates {{fraction}} (e.g. 81⁄2), {{frac}} (e.g. 81⁄2) and {{sfrac}} (e.g. 81/2) are available for representing common fractions.
• Mixed numbers are unspaced:

• Correct: A History of the World in 101⁄2 Chapters is a novel by Julian Barnes.
• Incorrect: A History of the World in 10 1⁄2 Chapters is a novel by Julian Barnes.

• Unless there is sound reason to the contrary, fractional parts of metric units should be expressed as decimal fractions (5.25 mm), not vulgar fractions (51⁄4 mm). However Imperial, English, avoirdupois, and United States customary units may use either form – both (5.25 inches) and (51⁄4 inches) are acceptable, provided that there is consistency in the way that the fractions are represented.

This introduces threetwo changes with respect to the current wording: the matter of spacing; a mention of {{fraction}}; and the replacement of algebraic with numeric examples, since an expression such as Np/q would in algebra probably be read as a product and not as a mixed number. Justlettersandnumbers (talk) 12:51, 27 December 2013 (UTC)

There are technical and accessibility reasons why the space is required. Please see Wikipedia talk:Manual of Style/Dates and numbers/Archive 140#Non-breaking spaces in mixed numbers for example, as well as the talk pages of the templates, for further discussion. MOS should not diverge from the well-considered implementation of the templates without good reason. —sroc 💬 13:33, 27 December 2013 (UTC)

Also, this should be posted on the talk pages of the various affected templates if this requires further consideration. —sroc 💬 13:36, 27 December 2013 (UTC)

• Extra space should be hidden to meet real-world styles: It is possible to hide the internal space before the fraction part inside a span-tag. The visible extra space, where {{frac|8|1|2}} has shown "8 1⁄2" has also caused inconsistency when used as "8{{frac|1|2}}" to show "81⁄2" where the whole-number portion is placed before the "{frac...}" part. The trick is to position the hidden space off-screen inside a valid span tag, as follows:
       • 8<span style="position:absolute; top: -9999px"> </span>¹⁄₂, to show: 8 ¹⁄₂
       • 87<span style="position:absolute; top: -9999px"> </span>²³⁄₁₀₀, to show: 87 ²³⁄₁₀₀
  During the past year, many users have tested such hidden spaces, on various browsers, to confirm how copy/paste as plain text indeed does retain the hidden space as visible in the copied text, such as "8 1/2" or "87 23/100" rather than 8723/100. -Wikid77 (talk) 15:20, 27 December 2013 (UTC)
• sroc: MOS should not diverge from the well-considered implementation of the templates: I'd say the other way around. We can change MOS with good reasons, and the templates should follow. -DePiep (talk) 16:07, 27 December 2013 (UTC)

Thank you, sroc, for linking to the earlier discussion. It seems to be both inconclusive and ill-considered. If there are technical and accessibility problems with displaying mixed numbers correctly, then those problems need to be addressed, at whatever level is needed (and luckily there are plenty of people here who are very clever at that sort of stuff). Just opting for an incorrect display of such numbers is not really an acceptable solution. What are the obstacles apart from the copy-paste problem (many things in wp fail to copy correctly, including, most notably, wikilinks)?

I'm with DePiep on the priorities here: first reach consensus, then make changes to the MOS if necessary, then make changes to the various templates if required. It isn't just the fraction templates that are affected - this post arose from discussion about {{Convert}}. Justlettersandnumbers (talk) 17:12, 27 December 2013 (UTC)

I agree, in principle, that MOS should take priority over templates and then templates should fall in line. However, accessibility also needs to be considered and should not be ignored (MOS:ACCESS is also part of MOS, by the way, and should not conflict with MOS:FRAC). Much work and discussion has taken place around these particular templates in recognition of accessibility issues and this should not be disregarded simply because it looks wrong. I agree that mixed fractions without the space look better and probably conform with other style guides, but I urge caution before leaping with this. Wikipedia works in electronic media and faces unique challenges that other style guides don't need to be as concerned about. There's also little point in changing MOS in such a way that it forces editors and templates to make a choice between complying with MOS:FRAC or complying with MOS:ACCESS if they conflict. It may also be important to post a link to this discussion at Wikipedia talk:WikiProject Accessibility for comment. —sroc 💬 05:43, 28 December 2013 (UTC)

re sroc: Is removing the space from {{frac}} an access'ity issue? I thought an universal typography could apply. -DePiep (talk) 11:55, 28 December 2013 (UTC)

Reply to sroc: in full agreement on all points. Thank you for mentioning this discussion at Wikipedia talk:WikiProject Accessibility. The accessibility issue (if there is one, I don't know) should of course not be disregarded; nor should the typographic appearance. It's my hope that a solution can be found that accommodates both. Whether or not fractions copy-paste correctly seems on the other hand quite trivial. Justlettersandnumbers (talk) 12:48, 28 December 2013 (UTC)

You can call me an enemy of the absolute offset hack for accessibility. It works, but it's bound to break some stuff somewhere in the future. I'm also an enemy of hidden characters. I'm an enemy of having to correct for the broken implementations of operating systems in terms of glyphs and copy paste implementations. And an enemy of the fractional notation to begin with. In all honesty, in the big picture it truly doesn't matter here very much. All solutions are broken and the only thing saving us here is a template so that once the majority of all browsers, Operating Systems and screen readers have proper implementations to deal with this, we can go back and adapt the template. So everyone can nitpick on this all they want, which i'm sure is what we will do, but in the end it's pointless and we will fix this in 5 to 10 years. —TheDJ (talk • contribs) 18:29, 27 December 2013 (UTC)

re TheDJ: so simply removing the space from {{frac}} give broken outcomes? (It's just a &#x20; in superscript). If so, I better rest this case. -DePiep (talk) 11:55, 28 December 2013 (UTC)

You have a lot of enemies :) We have to deal with the here and now, which means there is no perfect solution. But the 'hack' currently in place seems to be the best working solution out there... for now. — Edokter (talk) — 12:14, 29 December 2013 (UTC)

• Okay, without me having to go through and spend an hour reading the wikicode for each, what is the difference between the three templates and why are there three different templates to achieve the same result? Would it be possible to combine all three into one all inclusive template that functions the same as any of the three existing templates and add a parameter/function that will allow an editor to define if there should or shouldn't be a space between the two? Could there "ever" be any reason that a space in the middle would be appropriate (perhaps a movie, song, band, etc title with the space for effect)? Would it be better to simply create a fourth template that does not have the spacing? Lot's of questions to answer here before I can say that I support or oppose this. Technical 13 (talk) 21:19, 27 December 2013 (UTC)

@Technical 13, those 3 templates show 3 different formats: {{fraction}} uses unicode fraction glyphs ("8+1⁄2)"), {{frac}} uses slash virgule "/" between sup/sub numbers ("8+1⁄2), but {{sfrac}} uses horizontal bar (8+1/2). Plus {{convert}} shows fractions. Most worldwide styles have no space inside mixed numbers, but I think a [hidden] space between whole-number & fraction parts helps screenreaders (or copy/paste) to separate the parts; hence style="position:absolute; top:-9999px" could be used as tested (for months) to allow a hidden space to reappear in copy/pasted text (on any browser), such as copy "87 ²³⁄₁₀₀" into a text window. I think the absolute span-tag would be the compromise solution for all concerns. -Wikid77 23:47, 27 December 2013 (UTC)

When are the WMF engineers going to give us a less ugly formatting option for fractions? I'm talking about the unseemly size. Tony (talk) 00:30, 28 December 2013 (UTC)

Compare with small-font fraction: {frac|8|1|2} = 8+1⁄2, small-font = 8¹⁄₂. Hence, a user could enclose fractions within small-tags: <small>{{frac|1|2}}</small> for the smaller size, where needed. -Wikid77 (talk) 01:13, 28 December 2013 (UTC)

Okay, I see the differences and still think that all of these templates could be merged with an added |separator= parameter which would be defined as unicode, slash, or dash (or something of that nature). I'm also wondering why the unicode option is frowned upon where unicode symbols exist, as any system/browser that wouldn't support them would have to be very outdated. Also wondering why we aren't just using a LaTeX fraction such as $1{\tfrac {1}{2}}$? Technical 13 (talk) 02:19, 28 December 2013 (UTC)

Unicode support in screen readers (at least with their default settings) ) ranges from patchy to non-existent, in my experience. Graham87 03:47, 28 December 2013 (UTC)

Wikid: hardly any difference on Mac Safari. Tony (talk) 12:02, 28 December 2013 (UTC)

• IIC, the proposal is simple: remove the pre-numerator space from fractions, like this. From technical talks here (TheDJ), I understand that that could give browser issues (which looks weird, maybe it has to do with the optional class=frac?). I do not understand how accessability would oppose this (as sroc says). -DePiep (talk) 12:18, 28 December 2013 (UTC)

There was a time when {{frac}} could do Unicode fractions where possible like {{fraction}} does now, but this “smartness” led to inconsistencies in articles, most notably tables, and hence was removed. The consensus basically was that {{fraction}} should not be used at all; certainly, it shouldn’t be advertised in the MoS.

Smart fonts can easily turn a coded string sequence 8 1/2 into looking the same as “8 ½” or “8½” or anything in between, but CSS and browsers aren’t quite there yet. The template(s) should be prepared to take advantage of that technology as soon as possible. Few entries in the common stylesheet would make this easier. Actually, when I initially made {{frac}} I thought fraction slash ‘⁄’ would make such automatisms easier, but it may well be the case that more fonts implement the Open Type features for the solidus ‘/’ exclusively.

It would be possible to combine {{frac}} and {{sfrac}} into one template, but this required quite bloated HTML code and, again, some additions to common.css. The misuse of <sup> and <sub> could be removed at least. Stacked fractions (OTF feature afrc, CSS value font-variant-numeric: stacked-fractions) could be the default inside {{math}} and <math>, diagonal fractions (frac, diagonal-fractions) elsewhere. Logged-in users could then also select their preferred vulgar fraction style by editing their user stylesheet, which could also be turned into a preference setting of course.

Semantically speaking, the space between integer and fraction means ‘plus’ and there is a character for it: U+2064 INVISIBLE PLUS. Font and browser support wasn’t good enough, though, the last time it was suggested in Template talk:Frac. There used to be a hidden ‘+’, though, but it wasn’t accessible to tools – like spreadsheets – that would eventually need it, because browsers didn’t copy it. Not putting anything there is not an option, like others already said. — Christoph Päper 12:38, 28 December 2013 (UTC)

Thanks to Crissov and Wikid77 for pointing out the problems with {{fraction}}, which, it turns out, produces a few "better-looking" fractions, but defaults to rather ugly ones, e.g. {{fraction|7|9}} -> 7⁄9. If it uses the unicode characters that are specifically "discouraged entirely" here, then should not it also be "discouraged entirely" (deprecated and/or merged)? Unless there is any reason not to (?), I will strike it from the tentative draft wording I have proposed above. Justlettersandnumbers (talk) 13:14, 28 December 2013 (UTC)

Still not seeing why not use <math>...</math> and LaTeX... It's clearer, more precise, and has no messy, inconsistent HTML to deal with. Technical 13 (talk) 13:57, 28 December 2013 (UTC)

For all the reasons listed in Wikipedia:«math» and probably more. — Christoph Päper 14:40, 28 December 2013 (UTC)

Which are all moot as they can be dealt with... So, I'm still unclear why we can't use unicode in a screen reader friendly way. The template should apply the unicode (or fraction in general) as <abbr class="fraction" title="one half">½</abbr> and abbr.fraction{ border-bottom: medium none; } could be added to MediaWiki:Common.css or we could just do it with in-line styling like <abbr style="border-bottom: medium none;" title="one half">½</abbr> which would produce "½". For those that there are no unicode characters, it would simply render as "⁹⁹/₁₀₀". For mixed numbers, it would render as "25¹⁷/₃₂". For mixed numbers with a unicode fraction option "5¼". I think these look and read just fine even with screen readers or if the unicode fails to load... Technical 13 (talk) 15:11, 29 December 2013 (UTC)

Which one is it, TeX or Unicode?

For what it’s worth, I’ve implemented your suggestion to use abbr and title in {{fraction}}, although I don’t know whether any aural browser or screen reader actually makes use of that: 1⁄2, 99⁄100, 25+17⁄32 or 25 17⁄32, 5+1⁄4. — Christoph Päper 13:24, 8 January 2014 (UTC)

Would the use of thin spaces like   (en-space, U+2002),   (thin space, U+2009), ‍ (zero width joiner, U+200D, maybe only for Middle Eastern browsers) or a number of Unicode space characters such as U+200A (hair space), U+2006 (Six-Per-Em Space) or U+200B (zero width space) be useful? Some other possible alternatives are listed at Space (punctuation)#Spaces in Unicode. I don't know if they are well supported by the majority of browsers or screen readers.  Stepho  talk  23:38, 28 December 2013 (UTC)

Opinion of unspaced mixed numbers

• Support proposal to hide/omit space inside mixed numbers, which is the common, predominant format in worldwide styles. -Wikid77 15:20, 27 December 2013 (UTC)
• Support as nom and per Wikid77 - this is how mixed numbers are written. Justlettersandnumbers (talk) 17:12, 27 December 2013 (UTC)
• Support. Let us not concern ourselves with copy/paste issues; that is unsolvable as each browser behaves differently. Screenreaders should work though, but without any hidden-span-hack (the hack currently in place at {{sfrac}} does show the space, which it should not, which is probably a Chrome bug). — Edokter (talk) — 12:35, 28 December 2013 (UTC)
  • A hidden space CANNOT be "&#32;" to remain hidden, but using &#160; would stay hidden and allow upcasing text which contains mixed numbers. Beware: {{uc: &nbsp;}} = &NBSP;.
    Example fix: {{smallfrac|8|1|2}} = Template:Smallfrac, or {{smallfrac|77|23|50}} = Template:Smallfrac to copy/paste as "77 23⁄50". -Wikid77 16:23, 28 December 2013 (UTC)

New {{smallfrac}} is deprecated until this issue has an outcome. A MOS fork? Demo's shouold be in a /sandbox. -DePiep (talk) 20:34, 28 December 2013 (UTC)

Both {{frac}} and {{sfrac}} now employ this method. I think it was ment as a test template. — Edokter (talk) — 20:41, 28 December 2013 (UTC)

Test, demo, /sandbox: prevent gaining weight in mainspace. This one is inviting to fork MOS. -DePiep (talk) 07:54, 29 December 2013 (UTC)

• Weak oppose. The space probably shouldn't appear in normal display, but must appear to screen readers, and should appear to copy-paste. The latter "should" seems more important than the former, if there is a conflict. — Arthur Rubin (talk) 16:35, 28 December 2013 (UTC)

  As an aside, I created a linear fraction display {{tfrac}}, which has now been deleted; however, if major changes are made in the way {{frac}} and {{sfrac}} are implemented, {{tfrac}} should be restored as a backup format. {{tfrac|a|m|n}} was basically "a&160;m/n". — Arthur Rubin (talk) 16:47, 28 December 2013 (UTC)

  • Both {{frac}} and {{sfrac}} now use the &#160; method of hiding the space form display but not screen readers. — Edokter (talk) — 19:56, 28 December 2013 (UTC)
• Support There shouldn't be any space displayed here. The template could used a hidden space/plus sign (like it used to do). Jimp 12:13, 13 January 2014 (UTC)

Symbols for 2^30 bytes and 2^40 bytes

It is clear from the present text that the symbol MB is used for 2²⁰ bytes because that is stated explicitly ("256 MB of RAM" is preferred to "256 MiB of RAM"). By extension it follows also that the symbol GB is used for 2³⁰ bytes (ie "4 GB of RAM" would be preferred to "4 GiB of RAM"), but what about 2³⁰ or 2⁴⁰ bytes? Only KB, MB and GB are defined by JEDEC, which makes it unclear whether TB (or PB) is preferred over TiB (or PiB) for 2³⁰ bytes (or 2⁴⁰ bytes). Dondervogel 2 (talk) 14:37, 1 January 2014 (UTC)

You changed the binary prefix section to state it follows the JEDEC standards then add a dubious complaint about JEDEC has not updated their documents to cover terabyte RAMs. They will get around to that in due time. -- SWTPC6800 (talk) 05:59, 2 January 2014 (UTC)

OK, so WP does not follow JEDEC, but prefers the ambiguous "TB" and "PB" to unambiguous prefixes. I have edited the text to make that clear. Dondervogel 2 (talk) 07:48, 2 January 2014 (UTC)

Removing a column from the "Common mathematical symbols" table

The "Common mathematical symbols" table has a column for "Name", which includes multiple names for some symbols, and it has a column for "Other use" which looks mostly useless, as it only includes a couple of entries and those entries look like small variations of what is in the "Name" column. I suggest either simply removing the "Other use" column or merging its contents with the "Name" column. —BarrelProof (talk) 15:06, 2 January 2014 (UTC)

The way I see it, plus and minus are mathematical operators whereas positive and negative generally represent poles and charges. Car batteries have a positive and negative pole, not a plus and minus pole. Therefore, I think that it is appropriate to list the other uses for the symbols as listed. Attempting to merge the column with the name column would be ugly imho. Technical 13 (talk) 15:22, 2 January 2014 (UTC)

I think that people looking for a way to indicate positive and negative charges are probably not going to become very confused by seeing a description of a "Plus sign" that is not accompanied by an explanation that the symbol is also used as a "Positive sign". And anyhow, that section is already hatnoted to indicate that it is just a summary of more detailed guidance provided elsewhere. —BarrelProof (talk) 16:34, 2 January 2014 (UTC)

That's not the point of the column. I think that if the table is too wide, it would be more intuitive to remove the last two columns, which add no value a couple of bullet points above couldn't add like Any sign used as a binary operator should be spaced. Technical 13 (talk) 16:49, 2 January 2014 (UTC)

I agree that it looks like a good idea to remove the last two columns and replace them with a bullet that says "A symbol used as a binary operator should generally be spaced, while a symbol used as a unary operator should not". I think the issue is not just the width of the table (which certainly sometimes matters – e.g., on a mobile device with a small display), but the idea that having fewer columns makes the table simpler and easier to grasp at a glance., Simplicity has value. —BarrelProof (talk) 16:57, 2 January 2014 (UTC)

Regarding how to word the guidance about spacing of operators, note that there are bullet point descriptions on that topic included at Wikipedia:Manual of Style#Common mathematical symbols. —BarrelProof (talk) 17:08, 2 January 2014 (UTC)

Section entitled "Common mathematical symbols"

Please note that a discussion has been initiated at Wikipedia talk:Manual of Style#Common mathematical symbols that includes discussion of a section of this guideline (specifically, the section entitled "Common mathematical symbols"). Participation in that discussion is hereby encouraged. —BarrelProof (talk) 16:27, 2 January 2014 (UTC)

"b." or "born"?

I'm pretty sure that it's MOS to use "(born 1952)" or "(died 1066)" rather than "(b. 1952)" and "(d. 1066)", in the body of an article as well as at first mention in the lead, but another editor disagrees - see Baron Grimthorpe. If I'm right, could someone point me to the appropriate wording somewhere in MOS to cite: I can't see it explicitly mentioned in either WP:MOSNUM or MOS:BIO. If I'm wrong, let me know and I'll back down gracefully! Thanks. PamD 16:39, 8 January 2014 (UTC)

Ah, I've now found Wikipedia:WikiProject Peerage and Baronetage, which mandates the use of such abbreviations. I'll back down. PamD 16:45, 8 January 2014 (UTC)

I'm not comfortable with Wikipedia:WikiProject Peerage and Baronetage trumping Wikipedia:Manual of Style/Abbreviations and Wikipedia:Manual of Style/Dates and numbers. If a WikiProject wants to do something in a way that disagrees with the Manual of Style, they should propose it and seek a consensus. I sometimes change "b."s to "born" and "d."s to "died". It seems to me that understandability should be paramount since there's no limit on space like there would be in a book. SchreiberBike talk 19:09, 8 January 2014 (UTC)

"born instead of "b." is also good for non-native English speakers. I know for sure that many Greeks confuse b with d. Search for the famous in Greece phrase "how bo you bo?" :) -- Magioladitis (talk) 08:13, 9 January 2014 (UTC)

Additional bad date format

Please could we add the date format "June the 9th" to the WP:BADDATEFORMAT table? It is sort of implied by both "the 9th of June" and "June 9th", but I think it would be helpful to include it explicitly, particularly as I have found quite a few instances of it that require correction. Thanks. --Jameboy (talk) 14:42, 11 January 2014 (UTC)

Is YYYY-MM an acceptable date format? Part 2

I've split this into "Part 2" because it was getting a bit long and I'd like to formalise it. The recent (29 Nov 2013) banning of the yyyy-mm format brings about a conflict between parts of MOS but also highlights that the conflict was waiting in the wings as an unknown consequence. The guidelines state:

1. WP:DATEFORMAT - various formats with spelt out months are allowed (no problem). yyyy-mm-dd (all numbers) is allowed in tables, references and similar places where conciseness is needed. No mention of year and month combos (ie no day of month) at all. It points to Wikipedia:Citing Sources § Citation style, which explicitly allows yyyy-mm-dd.
2. WP:BADDATEFORMAT - lists various bad formats and the recommended replacement. yyyy-mm was unobtrusively added to the list on 29 Nov 2013 as a single line in a table with no reasoning or rationale given.
3. MOS:DATEUNIFY - states that only a single format is to be used within an article (some reading between the lines allows the main text to use spelt out months and tables/references/etc to use yyyy-mm-dd.

Articles are free to use references in the yyyy-mm-dd format. This is explicitly allowed. The conflict comes when we get a reference that has only year and month (typical of magazine references). Since BADDATEFORMAT disallows yyyy-mm, we must replace it a spelt out format such as Dec 2013. But then this causes a conflict with DATEUNIFY, which forces us to replace each and every reference with a spelt out format. In effect, that single line disallowing yyyy-mm means that every article using yyyy-mm-dd in references has a very good probability of being forced to change to a spelt out format. That's a wide ranging effect for a single sentence fragment with no rationale given in the guideline. The rationale given on the talk page is that it can be confused with the date ranges like 2002-03 (ie from 2002 to 2003).

The talk page discussion was only among a small set of contributors over a short period of time, so the repercussions were not obvious and were not thrashed out. After nearly three weeks of thinking it through, I haven't found an acceptable solution from any angle but I intend to thrash out the repercussions now . Hopefully it will inspire somebody to suggest a good solution or possibly to find a least-bad solution or at least to make the repercussions obvious in the guideline itself.

I will state each solution I could think of and follow each with pros and cons. Please add your own pros or cons within each subsection.

New ideas can be added to the end of the list.  Stepho  talk  23:37, 11 January 2014 (UTC)

Disallow yyyy-mm-dd altogether

Removes the source of all the conflict. Not used in common English speech anyway. Will make tables wider (big problem). Will require many articles to be changed (by bot?). Might get considerable kick back from some editors. Has trouble with the recommendation to use {{sort|2008-11-01|1 Nov 2008}}. Will need a formal discussion at MOS, not a quick discussion here.  Stepho  talk  23:37, 11 January 2014 (UTC)

As an amateur astronomer and software dev, I write and speak in ISO 8601 (big-endian, YMD) formatting, and I see it and hear it spoken more often than other formats. It should not be disallowed altogether, and I for one would prefer it become our standard first choice in all non-prose contexts. Startswithj (talk) 03:32, 13 January 2014 (UTC)

Support It wouldn't make many tables wider as this is not really that common in tables and for those that it might make wider there is a simple remedy: abbreviate the month. Dmy and mdy dates with abbreviated months are only marginally longer (if any longer at all) than ymd dates. I'm not sure what trouble there might be with the recommendation to use {{sort|2008-11-01|1 Nov 2008}}. Yes, there are some who prefer ymd but for most of us English speakers it is unfamiliar. I see no reason to allow ymd for the benefit of the few at the expense of the many. Jimp 11:48, 13 January 2014 (UTC)

Support. With all respect for those who are familiar with, or even actually use, this format, there is a fundamental reason for not using it in Wikipedia: it is completely ambiguous to those who are not familiar with it (which, I submit, includes most people on the planet). There's no way of telling by inspection whether 2001-07-09 is 9 July 2001 or 7 September 2001. How can anyone know whether or not those who write their dates mdy invert that order to ydm when they want to put the year first (as would be perfectly logical)? Other number-only date formats are not used here for exactly this kind of reason; this one should join them. There's no need to specifically disallow it. All that's needed is to say that all-number date formats are not used here, and month names are written in letters. That would answer the original question here also. Justlettersandnumbers (talk) 00:52, 16 January 2014 (UTC)

Curious comment - it's the only format that is totally 'unambiguous (assuming the Gregorian calendar). There is no group that uses yyyy-dd-mm (with the day in the middle) that I know of. WP:BADDATEFORMAT explicitly comments on dd-mm-yyyy and mm-dd-yyyy as being ambiguous (and hence banned) but there is no such comment for yyyy-mm-dd.

Your use of "most people on the planet" is a bad generalisation becuase most people in northern Europe and Asia are completely comfortable with this format and actually comprise most people on the planet. Granted that this format is still unknown to many native English speakers, it is gaining more traction in technological fields - especially those where technical details have to be shared amongst practitioners from multiple nations.  Stepho  talk  05:58, 16 January 2014 (UTC)

yyyy-mm-dd is not the only format which is unambiguous: dmy & mdy are perfectly unambiguous as long as the month is written in letters. As for there being no group that uses yyyy-dd-mm, what about those who do so by mistake? Perhaps "most people on the planet" is a bad generalisation but those who do use ymd (your "most people in northern Europe and Asia") do so because it's part of their language and their language is not English. Most English speakers on the planet not familiar with it and this is the point. Jimp 08:49, 20 January 2014 (UTC)

Per Jimp. Few English-speakers can parse this format naturally, without a double take. So support. -- Ohc ^¡digame! 07:06, 16 January 2014 (UTC)

Support. Agree with Ohc and Justlettersandnumbers. But we went into all this at enormous and occasionally acrimonious length in an RfC a year or two ago, and unfortunately there was no consensus for this change. (I suspect this was mainly because so many active Wikipedians of the sort likely to take part in such an RfC are rather techie and geeky people for whom this format does not seem as weird and difficult as it does to most ordinary readers.) -- Alarics (talk) 09:37, 17 January 2014 (UTC)

Perhaps this is a good time to try again? The format is unambiguous only to those who already know that no-one uses yyyy-dd-mm. Does anyone know that? I know that I don't, and it seems that Stepho-wrs isn't too sure. It is understandable that it would have been more widely used in the early days of computing, before operating systems were able sort by date without such artificial devices. But that what was, what, twenty-five or thirty years ago? Our purpose here is to be clear, and to be unambiguously clear. A date format that requires specialist knowledge to be understood is hardly consistent with that aim. Justlettersandnumbers (talk) 10:30, 17 January 2014 (UTC)

Oppose. Just to get a feel for how often yyyy-mm-dd is used, I tried a couple of google searches for 2012-01..12 and just 2012 across en.wikipedia.org (both searches with a simplistic removal of disambiguation, sign post and picture of the day articles which nearly always use yyyy-mm-dd in their title):

• 3,000,000+ results from https://www.google.com.au/search?hl=en&as_q=%222012+-02%22+%7C+%222012-03%22+%7C+%222012-04%22+%7C+%222012-05%22+%7C+%222012-06%22+%7C+%222012-07%22+%7C+%222012-08%22+%7C+%222012-09%22+%7C+%222012-10%22+%7C+%222012-11%22+%7C+%222012-12%22&as_epq=&as_oq=&as_eq=%22sign+post%22+%22wikipedia+signpost%22+%22featured+picture%22+POTD&as_nlo=&as_nhi=&lr=&cr=&as_qdr=all&as_sitesearch=en.wikipedia.org&as_occt=any&safe=images&tbs=&as_filetype=&as_rights=
• 82,500,000 results from https://www.google.com.au/search?hl=en&as_q=2012&as_epq=en+wikipedia+org&as_oq=&as_eq=&as_nlo=&as_nhi=&lr=&cr=&as_qdr=all&as_sitesearch=&as_occt=any&safe=images&tbs=&as_filetype=&as_rights=

That gives about 4%. But the result for 2012-01..12 is missing pages that use yyyy-mm-dd reference dates but don't happen to include dates from 2012. And the result for just 2012 is also including many pages that don't have properly dated references. So I feel comfortable that the true number is at least 4% and probably greater than 10%.

I also tried it from a different angle. I pressed Wikipedia's Random page 51 times and tallied which type of dates were used in references. I was quite surprised by the result. I counted:

• 7 articles that used predominately yyyy-mm-dd,
• 11 that use the spelt out form,
• 3 that used both forms, with neither predominating
• 30 that didn't use either (no references, references without dates, disambiguation pages).

Now, 51 isn't statistically significant - especially when 30 have to be thrown away. But 10 articles that have yyyy-mm-dd reference dates (predominantly or mixed) out of 21 shows that there must be quite a few editors that like using them. You are all quite welcome to try your own tally from random pages - the more pages the better.  Stepho  talk  00:19, 18 January 2014 (UTC)

I'm not so sure about "quite a few editors that like using them". My impression is that a lot of instances of yyyy-mm-dd reference dates are put there by bots, such as Reflinks. -- Alarics (talk) 09:05, 18 January 2014 (UTC)

Well, count me in for those liking the yyyy-mm-dd format (on Wikipedia, only inside references). Got used to it long time ago, primarily because it's very easily sortable. — Dsimic (talk) 00:37, 19 January 2014 (UTC)

Results from a sample of WP articles will be skewed by the fact that until recently the cite templates required yyyy-mm-dd. This requirement was put in place for autoformatting purposes. By the time autoformatting was ditched, the notion that yyyy-mm-dd was fine, even the preferred standard, had become well entrenched. I'd suggest that a lot of these yyyy-mm-dd we find in references are relics from the bad old days of date linking and autoformatting and that most of those that were put in since we're formatted like this due to the impression that ymd was the done thing for refs. Jimp 08:49, 20 January 2014 (UTC)

Oppose. YYYY-MM-DD is the International Standard for date and time formats (http://www.cl.cam.ac.uk/~mgk25/iso-time.html) under ISO 8601. It would be ridiculous for Wikipedia to disallow usage of an international standard. I also dispute the statements by Jimp that:

"those who do use ymd (your "most people in northern Europe and Asia") do so because it's part of their language and their language is not English. Most English speakers on the planet not familiar with it and this is the point."

"I'd suggest that a lot of these yyyy-mm-dd we find in references are relics from the bad old days"

The YYYY-MM-DD format is not uncommon in the UK and is becoming more common. Much as you may question it, our language is English! This usage may not be common in North American English, but there are many English speakers who are familiar with this format. Secondly, I'd suggest that, far from being relics, many of the "yyyy-mm-dd we find in references" are because usage of the ISO format is becoming increasingly common, at least outside N.America. TrevorD (talk) 01:18, 21 January 2014 (UTC)

Disallow yyyy-mm-dd for references.

Removes the source of all the conflict for references. Might still have conflicts in tables but less likely. Not used in common English speech anyway. Will require many articles to be changed (by bot?). Might get considerable kick back from some editors.  Stepho  talk  23:37, 11 January 2014 (UTC)

Again, I would prefer ISO 8601 become WP's standard first choice in all non-prose contexts. Startswithj (talk) 03:32, 13 January 2014 (UTC)

The argument for allowing ymd in tables and/or lists is even weaker than that for allowing it in references. If we get rid of this unfamiliar format in references, there'd be no reason to keep it anywhere. Jimp 11:48, 13 January 2014 (UTC)

Per Jimp. Few English-speakers can parse this format naturally, without a double take. So support. -- Ohc ^¡digame! 07:06, 16 January 2014 (UTC)

Oppose. Quite popular among editors (see tally in 'Disallow yyyy-mm-dd altogether' section above) and likely to get a lot of kick back.  Stepho  talk  00:19, 18 January 2014 (UTC)

Oppose. YYYY-MM-DD is the International Standard for date and time formats (http://www.cl.cam.ac.uk/~mgk25/iso-time.html) under ISO 8601. It would be ridiculous for Wikipedia to disallow usage of an international standard. (See my additional comments under 'Disallow yyyy-mm-dd altogether' section above.)

I also agree with Startswithj's comment that "ISO 8601 [should] become WP's standard first choice in all non-prose contexts." We should be moving forwards - not backwards! TrevorD (talk) 01:18, 21 January 2014 (UTC)

Put conflict repercussions in guideline

State "yyyy-mm-dd is allowed but as soon as a single year and month combination is required then all references must be changed to one of the other allowed formats". Sounds like a rigid schoolmistress grudgingly telling you that yes, you can do that but put one foot out of step and she will come down on you like a ton of bricks. Seems strange to allow you to use this format for references but that the very probable case of a magazine reference will require you to change to one of the other formats (at considerable expense). Goes very much towards disallowing/discouraging yyyy-mm-dd altogether (did I hear a cheer?)  Stepho  talk  23:37, 11 January 2014 (UTC)

Again, I disagree. Startswithj (talk) 03:32, 13 January 2014 (UTC)

I can't see this working. Jimp 11:48, 13 January 2014 (UTC)

A workable algorithm is more trouble than this is worth. -- Ohc ^¡digame! 07:06, 16 January 2014 (UTC)

Again Oppose. YYYY-MM is permitted under ISO 8601. See http://www.cl.cam.ac.uk/~mgk25/iso-time.html:

"If only the month ... is of interest: 1995-02" TrevorD (talk) 01:18, 21 January 2014 (UTC)

Allow yyyy-mm in limited cases

Allow references to use yyyy-mm because references rarely have a date range for the publishing date. For references such as financial results, the date range is often (but not always) in the title and publication date is usually a full date at the end of the range (eg "Company XXX financial results 2012-2013", 2013-08-05), Similarly, some references may have a publishing date at the start of the range. Doesn't cover all cases.  Stepho  talk  23:37, 11 January 2014 (UTC)

I would agree that we might recommend against YYYY-MM due to potential confusion with YYYY-YY (range), but I would not disallow it. I would sooner agree with disallowing YYYY-YY for ranges. Startswithj (talk) 03:32, 13 January 2014 (UTC)

This could be confusing. Jimp 11:48, 13 January 2014 (UTC)

Not one used frequently in the outside world, so can be a problem to parse. Too easily confused with the year range at the best of times. -- Ohc ^¡digame! 07:06, 16 January 2014 (UTC)

I agree with Startswithj. I agree that it might be confusing and that we might recommend against using YYYY-MM, but we should not disallow using an International Standard. I also would sooner agree with disallowing YYYY-YY for ranges. TrevorD (talk) 01:18, 21 January 2014 (UTC)

Allow mixed date formats in limited cases

Allow most references to be yyyy-mm-dd but year+month combos can be in 'January 2014' style (possibly 'Jan 2014' or less favourably '2014-Jan'). Makes a mockery of MOS:DATEUNIFY but most articles ignore it anyway. User: BattyBot has been changing yyyy-mm to mmmm yyyy, translating a violation of WP:BADDATEFORMAT into a violation of MOS:DATEUNIFY.  Stepho  talk  23:37, 11 January 2014 (UTC)

I'd certainly appreciate if BattyBot would stop changing ISO 8601s to MMMM YYYY. Startswithj (talk) 03:32, 13 January 2014 (UTC)

@Startswithj: As stated below, I have temporarily commented out the BattyBot code that changes yyyy-mm format while this discussion is going on. If the MOS is changed, then the code will be changed accordingly. GoingBatty (talk) 04:00, 13 January 2014 (UTC)

Awesome, thank you. User: AnomieBOT might be another? startswithj (talk) 05:05, 13 January 2014 (UTC)

This would soon lead us to a messy situation. Jimp 11:48, 13 January 2014 (UTC)

Frankenstein solution. Quasimodo is next. ;-) -- Ohc ^¡digame! 07:06, 16 January 2014 (UTC)

Make all references use the {{cite}} family of templates and make them use year, month, day parameters.

Allows a future addition to the user preferences to display these params in the user's preferred style. Doesn't help for tables. Unlikely to succeed because we're still trying to convince people to use the cite family at all. Also, the cite family deprecated the separate fields and prefer a single date param.  Stepho  talk  23:37, 11 January 2014 (UTC)

Date autoformatting is dead and gone. For all the reasons it was killed off in the first place, it's not likely to be raised from the dead. The cite templates are not universally used. Also, does this actually fix the problem? Jimp 11:48, 13 January 2014 (UTC)

Per Jimp. Citation templates encourage editors to populate with too much unimportant information, often wrongly. -- Ohc ^¡digame! 07:06, 16 January 2014 (UTC)

Year ranges should use yyyy-yyyy

Disallow yyyy-yy. Since 2001-03 has two possible interpretations, disallowing yyyy-yy is technically as valid as disallowing the other interpretation of yyyy-mm. Likely to be very hard to enforce.  Stepho  talk  23:37, 11 January 2014 (UTC)

@Stepho-wrs: First of all, thank you for creating this very detailed post. I hope it will lead to a consensus and clarification on the appropriate MOS pages. I have temporarily commented out the BattyBot code that changes yyyy-mm format while this discussion is going on.

My primary concern is that the use of unambiguous year ranges (e.g. "2013-14") may encourage editors to use ambiguous dates (e.g. "2001-03"). While "yyyy-yyyy" may be hard to enforce, we can choose to set a good example for our fellow editors. GoingBatty (talk) 17:04, 12 January 2014 (UTC)

I could agree with banning YYYY-YY for ranges. I think it has less validity than YYYY-MM, and the potential confusion is easily abated through writing the full four-digit year. Startswithj (talk) 03:32, 13 January 2014 (UTC)

A fan on ymd would think yyyy–yy had less validity than yyyy-mm but I'd disagree. yyyy–yy is pretty normal in English (as opposed to yyyy-mm). I would not be in favour of disallowing a common form of expression to make room for an uncommon one. Jimp 11:48, 13 January 2014 (UTC)

yyyy–yy is OK so long as we are clear that only years can be shown in this way. The ndash ensures that any ambiguity is kept to a minimum. -- Ohc ^¡digame! 07:06, 16 January 2014 (UTC)

Unnecessary complication. But this is only needed if we don't clarify or ban the ambiguous format of the type '2001-04'. -- Ohc ^¡digame! 07:06, 16 January 2014 (UTC)

Again, I agree with Startswithj. YYYY-MM is a valid format because it is permitted under ISO 8601, and therefore should not be disallowed. TrevorD (talk) 01:18, 21 January 2014 (UTC)

Year ranges should use yyyy-'yy

The second year is truncated, so it should be marked as such. Same as writing "Jan '14" as shorthand for "January 2014". Removes all conflict with yyyy-mm. Probably a good idea, no matter how the yyyy-mm discussion ends.  Stepho  talk  23:37, 11 January 2014 (UTC)

While writing "Jan '14" is an established custom, writing "2013-'14" isn't; it would be a novel extension by the English Wikipedia. I think it would leave readers wondering if that notation has some special meaning they had never heard of. Jc3s5h (talk) 19:00, 12 January 2014 (UTC)

YYYY-'YY looks weird to my eyes, personally. Startswithj (talk) 03:32, 13 January 2014 (UTC)

As per the above, we can't just go making things up: they wouldn't be understood even if they were used in the first place (and to get them used would be an uphill battle in itself). Jimp 11:48, 13 January 2014 (UTC)

currently not allowed by the guideline, and this change would involve a single-quote mark that would be otherwise redundant. Retrograde step. -- Ohc ^¡digame! 07:06, 16 January 2014 (UTC)

References use year and issue fields instead of date

A magazine labelled as June–July 2013 was probably published in mid-to-late May 2013. It is technically the June–July issue from 2013. Gets around a technicality but when displayed it will still look like June–July 2013 or 2013, June–July (depending on vagrancies of the cite template), which still looks like a violation of MOS:DATEUNIFY to the reader. Doesn't help for tables.  Stepho  talk  23:37, 11 January 2014 (UTC)

Magazines and journals often have both an issue number and a date, the later sometimes being expressed as a range such as "June–July 2013". Readers should be provided with both the date and the issue number to give them the greatest chance of finding the right article and confirming the copy in their hand is the right one. The information can also help to confirm that a citation in another article that seems to be to the same source really is. Jc3s5h (talk) 00:01, 12 January 2014 (UTC)

Sorry, I should have been clearer. If the publishing date is known then of course it should be used. But if the publishing date is unknown and the journal has a spelt out month such as 'June' or 'June–July' on the front cover then this suggestion might be applicable (subject to further discussion).  Stepho  talk  21:56, 12 January 2014 (UTC)

First off, I believe if you're going to provide metadata in the form of parameters, it should be accurate. The only use of issue I've ever seen is a number that allows the various issues that constitute a volume to be put in order. Putting a date in an issue parameter is providing false metadata and shouldn't be done. In the rare case where a parameter is mandatory, but putting accurate data in the parameter would make the cite template misbehave, that citation should be formatted by hand rather than introducing false metadata just to make the template work.

Next, the publication date is whatever the publisher says it is. If the publisher prints May–June 1974 on the cover, that's the publication date. If the editor saved his receipt and it's dated April 1, 1974, that makes no difference, the publication date is still May–June 1974. This is because the publication date is not primarily for determining when the publication first became available; the primary purpose is so that a reader can compare the date in the citation to the date on the magazine in his hand and determine if he has the right issue or not. Jc3s5h (talk) 23:11, 12 January 2014 (UTC)

I could see allowing this, but I don't think it should be required. As a reader, I'm more interested in dates (exact dates if possible), rather than issue numbers. Startswithj (talk) 03:32, 13 January 2014 (UTC)

Whatever looks like a violation of MOS:DATEUNIFY to the reader is a violation of MOS:DATEUNIFY. Jimp 11:48, 13 January 2014 (UTC)

Although I tend to agree with Jimp, I see no practical problems with this format, but this should probably populate the |issue= field instead of |date=. -- Ohc ^¡digame! 07:06, 16 January 2014 (UTC)

Restrict yyyy-mm-dd to reference accessdate and archivedate

Emphasize that yyyy-mm-dd is only allowed in "accessdate" and "archivedate" fields in references, not in "date" (or publication date), per the citation style guidelines.

This eliminates the need for commenting on yyyy—mm–mm, yyyy-season, yyyy-yyyy, etc. — Arthur Rubin (talk) 00:08, 16 January 2014 (UTC)

Close but not quite. The line in question in the {{cite}} documentation is:

"Accessdate and archivedate in references should all have the same format – either the format used for publication dates, or YYYY-MM-DD. See: MOS:DATEUNIFY."

This says that yyyy-mm can be used for accessdate and archivedate even when date uses another format. {{Cite}} it makes no prohibition against any other date format used in other fields.

Also, as much as I love the cite family, they should be submissive to here and to MOS - MOS should not be submissive to the cite family.

However, restricting yyyy-mm-dd to these two fields means that the publication date must be fully spelt out, which does remove the conflict. But it looks strange and unprofessional to have two dates on the same reference line in different formats. And the conflict still remains for tables.  Stepho  talk  05:58, 16 January 2014 (UTC)

Does not resolve the apparent inconsistency if/when the publication date is in dmy or mdy format. Also, as it stands now, "|archivedate=2014-01-12" renders in the reference as "Archived from the original on 2014-01-12", which looks simply awful. -- Ohc ^¡digame! 07:06, 16 January 2014 (UTC)

Use the {{date|yyyy-mm-dd}} template

Why isn't the {{date|yyyy-mm-dd}} template used more widely on Wikipedia? As far as its documentation tells, it's supposed to format displayed dates however each Wikipedia account is configured. That way, we'd have no disputes and endless discussions about preferred formats; Wiki code would always (and uniformly) contain {{date|yyyy-mm-dd}} templates, and readers could enjoy the dates in whichever format they prefer. In my opinion, that would be the best solution. Thoughts? — Dsimic (talk) 18:33, 16 January 2014 (UTC)

According to its documentation, {{Date}} does NOT attempt to present dates in the format preferred by the reader; it parses the input date and outputs it in a format specified by a template parameter. Automatic formatting of dates was rejected in the RFC at Wikipedia:Manual of Style/Dates and numbers/Date Linking RFC Jc3s5h (talk) 18:53, 16 January 2014 (UTC)

Thank you for correcting my understaning of how {{Date}} template works, I've somehow misunderstood its documentation. Then, how about making {{Date}} to take user preferences for dates formatting, maybe? Regarding the mentioned RFC, as far as I can see it's about linking dates for the side-effect of their formatting, what obviously isn't a good thing, as concluded in that RFC. In other words, to me, linking dates is wrong, but their formatting is right. Thoughts? — Dsimic (talk) 19:21, 16 January 2014 (UTC)

The concept of automatic formatting of dates was rejected after several long RFCs. In addition, it is technically difficult. The former mechanism only worked for logged-in users, but the majority of readers are not logged in. There is no existing mechanism for a reader with no account to indicate a preference; the general feeling was that mechanisms that don't work for the vast majority of readers are not worth considering.

Also, it is very difficult to find a way to render the mdy format and the dmy format correctly from the same input. Consider these examples:

• The event occurred August 21, 1985, and was very successful.
• The event occurred August 21, 1985; it was very successful.
• The following rules went into effect 1 January 1970:

Obviously it would be quite tricky to determine when a comma should be added after the year for an mdy date. Jc3s5h (talk) 19:41, 16 January 2014 (UTC)

Maybe taking the browser locale, by looking into values of Accept-Language request headers for example, would be an acceptable solution for not logged-in readers? I've seen some commercial web-based enterprise software doing exactly that.

Sorry, but I'm a bit confused about adding commas after years in auto-formatted MDY dates, as years are at the end of strings produced that way? Couldn't any required trailing punctuation marks be added manually, just as links can be extended ([[cookie]]s, for example)? — Dsimic (talk) 19:57, 16 January 2014 (UTC)

Suppose an editor thinks in terms of the mdy format, so codes The wildly successful-#^magicdaterenderer|1985|August|21+#^, event was repeated the next year. Then a reader with her date preference set to the dmy format reads the article and sees "The wildly successful 21 August 1985, event was repeated the next year." The comma after the year is correct for the mdy format but not for the dmy format. Jc3s5h (talk) 20:08, 16 January 2014 (UTC)

Ah, yes. Makes sense now, thanks. Though, an MDY format with its commas is somewhat awkward in such cases, but that's a topic for a totally different debate. :) — Dsimic (talk) 20:42, 16 January 2014 (UTC)

Width first or height for screen sizes? And inches again..

This is maybe not strictly about numbers, I'm sorry, but if there is another place to discuss nr. 1. then let's point that out. I do not want to discuss this in here then.

Nr 1. For screens, they were traditionally always in landscape and the bigger number comes first eg. 1920x1080. For eg. smartphones, *should* they use eg. 1080x1920 pixels? I do not want to bother changing pages anymore if not or even if I'm mistaken and the longer side (in pixels) should be first. Usually pixel are square, but the longer side could theoretically be fewer pixels.. Should the MOS (somewhere) say something about this?

Note also that portait would (?) have implications for aspect ratio as it is defined there. No one says 9:16, always 16:9? comp.arch (talk) 15:47, 13 January 2014 (UTC)

Nr 2. Screen size has traditionally been given in inches, and while this has been discussed before is anyone willing to accept an exception to say explicitly that inches should be primary (cm could be secondary). The MOS might even say this implicitly because of accuracy arguments (if we treat sizes scientifically), as cm is more accurate than an inch and we run into WP:OR problems if we encourage in cm (mm).

Nr 3. Nr. 2 Also applies to pixels per inch (ppi). PPI is universally used (not ppcm). This has been maybe overlooked. Given screen (diagonal) size (and resolution), PPI can be calculated exactly (and is done in Wikipedia), I guess avoiding OR issues. Given PPI size could be calculated backwards from that..

Nr 4. PPI vs. ppi? I have a IEEE style guide saying ppi is correct spelling and another one from IEEE using PPI.. comp.arch (talk)

Computer screens have always been listed as horizontal x vertical - even for the rare portrait monitors. As you said, most desktop/laptop screens were landscape mode, so this means most screens had the large number first but that is just coincidence. A mobile phone (eg Samsung Galaxy S) would be shown as 480×800.

Basic maths doesn't count as original research - conversions between units is allowed. Neither inch nor cm is more accurate - just specify the appropriate number of decimal points or fractions. {{convert}} is useful here.

PPI is generally only used for printed output (ie where the paper size is fixed or a very limited selection). For screens, it is more common to use a combination of screen size and number of pixels.

It is becoming more common to use mm for mobile screen and cm for TV sizes - at least outside of the US. Computer screens seem stuck with inches :(  Stepho  talk  23:29, 12 January 2014 (UTC)

WP general prefers to use lowercase initials - eg mph.  Stepho  talk  23:29, 12 January 2014 (UTC)

The thing with "horizontal first" is that who is to say that the phone's natural position is "pointing up" and that is the narrow side. They can be turned and probably usually are for watching videos (or maybe to type on a keyboard). Do we want to demand and standardize on the lower number first for phones? I even remember ("portrait") monitor from way back for the Mac that could be turned and who is to say which way is the correct. comp.arch (talk) 12:29, 13 January 2014 (UTC)

Do we want to go with reliable WP:PRIMARY sources, see [[4]] and [[5]] or make WP consistent in this way? Not other manufactures could reverse for their products. And WP:SECONDARY sources might do their own thing.. comp.arch (talk) 17:03, 13 January 2014 (UTC)

Obviously, width and height are interchangeable based on the orientation of the display. My opinion on this has evolved with the rest of the industry over the last several years. I recall that, when I first noticed smartphones were being listed in portrait orientation it felt wrong. This was due to a long established habit, from computer displays, of primarily seeing/using the landscape orientation. But now, it feels wrong when seeing a smartphone mentioned with screen dimensions listed in landscape orientation, unless landscape orientation is specifically being discussed.

IMO, dimensions should be listed with the width (first number) being the horizontal direction in which the specific display is most commonly used, or intended to be used. In general, for smartphones this is in portrait orientation; for computer displays this is in landscape orientation. Using the commonly used orientation is, effectively, an evolution in the industry due to the introduction of smartphones. Prior to their introduction, there really was not that much which was most commonly viewed in portrait orientation. Thus, the prior convention of using landscape orientation. For smartphones portrait orientation is clearly the norm in the industry. Generalizing this to be that we use the most common/intended by manufacturer orientation as the one in which we show the dimensions is reasonable.

If the article is about screen resolutions in general, then the dimensions should be listed in landscape orientation (largest number first). Unless it becomes that a specific screen resolution is almost always/only viewed in portrait orientation. If an article is specifically about smartphone resolutions, then portrait. In other words, follow the way that is generally use for the item(s) being written about. Which is used may change over time as the use of lower resolutions becomes embedded in our culture as strongly associated with smartphones rather than computer monitors.

As to the specific example you mention of the Samsung Galaxy Note 10.1 2014 Edition: This item positioned as a tablet by the manufacturer. The article explicitly called it a tablet in the first sentence. Tablet screen resolutions continue to be presented in landscape orientation. The fact that it also has phone capability does not change this. Makyen (talk) 20:58, 13 January 2014 (UTC)

GPS, MOS and events

Please see related discussion at Wikipedia_talk:WikiProject_Geographical_coordinates#GPS.2C_MOS_and_events. Relevance here is that our GPS section should include at least a sentence guideline regarding events. --_{Piotr Konieczny aka Prokonsul Piotrus| reply here} 13:02, 13 January 2014 (UTC)

New MOS RFC: Month abbreviations

I have begun an RFC on month abbreviations at WT:MOS#RFC: Month abbreviations. I have asked whether this guideline and the Manual of Style should be required to agree on this point. Please discuss at the MOS talk page. Jc3s5h (talk) 23:33, 13 January 2014 (UTC)

"of each month"

No controversy about this:

The museum is open the first and third Monday of each month.

But what about

The rent is due on the 1st of theeach month; nonreceipt means eviction by the 27th.

Certainly we need some way of expressing this. Right now we've got {WP:BADDATEFORMAT):

Do not use ordinal suffixes nor articles (the 3rd of January, January 3rd, January 3d)

Does this provision force us to say:

The rent is due on the first day of each month; nonreceipt means eviction by the twenty-seventh day of the month.

This seems so awkward. Thoughs? EEng (talk) 01:53, 14 January 2014 (UTC)

• Two options I see: 1/leave these alone, 2/expand the phrase to include the month name. My approach up to now is 1/, but expansion is arguably preferable as it leaves less chance for ambiguity. -- Ohc ^¡digame! 02:27, 14 January 2014 (UTC)

Sorry, my example wasn't clear enough -- there is no particular month -- see fix (using "each month") above. So "expansion to include the month name" isn't an option.

Not sure what you mean by "leave these alone", but if you're saying

The rent is due on the 1st of each month; nonreceipt means eviction by the 27th.

is OK, I agree. Thus we arrive at the problem: as quoted above, MOS seems to forbid "ordinals". It would seem, then, we need a modification to MOS. It's that I'm looking to discuss.

EEng (talk) 02:52, 14 January 2014 (UTC)

• Like you said, leaving them alone implies tacitly accepting ordinals. Unfortunately, such formulations are potentially ambiguous, extremely common, and would demand a lot of manual effort to correct. I would favour more precise guidelines as to how to avoid using these. -- Ohc ^¡digame! 03:02, 14 January 2014 (UTC)

So you're saying we can't say, "A typical rental lease calls for payment of rent by the 3rd day of each month"? Really??? Manual effort is needed for this? I have no idea what you're saying, to be honest. EEng (talk) 04:10, 14 January 2014 (UTC)

• Sorry, that's not what I meant. Of course "2nd day" is an ordinal construction, but it's not an "ordinal date" within the meaning of WP:MOSNUM as I see it. -- Ohc ^¡digame! 04:33, 14 January 2014 (UTC)

The MoS advises against ordinals in dates, but these aren't really dates. They have no specific month or year; they just tell what day of the month things happen. Similar to "Monday is the 2nd day of the week". I'm comfortable with ordinals in this case, and I don't think the present MoS prohibits them. SchreiberBike talk 03:35, 14 January 2014 (UTC)

I assure that someone will eventually say that the prohibition on ordinals I quoted means you can't say "the 3rd of the month", even if we sane people don't think it actually implies such a prohibition. So I do think a clarification to MOS is in order. But first I want to hear from Ohc (above) clarifying what he was saying. EEng (talk) 04:10, 14 January 2014 (UTC)

Indeed, these are not dates. Does this really arise in practice to warrant an explicit exception at the risk of CREEP? —sroc 💬 04:29, 14 January 2014 (UTC)

What is the ambiguity here, Ohconfucius? —sroc 💬 04:29, 14 January 2014 (UTC)

Note that MOS:NUMERAL states:

As a general rule, in the body of an article, single-digit whole numbers from zero to nine are spelled out in words; numbers greater than nine, if they are expressed in one or two words, may be rendered in numerals or in words (16 or sixteen, 84 or eighty-four, 200 or two hundred); those requiring more than two words are given in numerals (3.75, 544, 21 million). This applies to both ordinal and cardinal numbers.

So, the first half of the sentence in isolation should be:

• The rent is due on the first day of each month
• not The rent is due on the 1st day of each month.

However, an exception states:

Comparable quantities should be all spelled out or all figures: we may write either 5 cats and 32 dogs or five cats and thirty-two dogs, not five cats and 32 dogs.

So, the whole sentence could be:

• The rent is due on the 1st day of each month; nonreceipt means eviction by the 27th day of the month or
• The rent is due on the first day of each month; nonreceipt means eviction by the twenty-seventh day of the month
• but not The rent is due on the 1st day of each month; nonreceipt means eviction by the twenty-seventh day of the month.

—sroc 💬 04:40, 14 January 2014 (UTC)

Comma after year in m-d-y format

I added this sentence: "A comma is also required after the year unless the year ends the sentence." According to another editor, this issue has been discussed before without consensus as to whether the comma is required. I haven't verified that.

MOS:COMMA has the requirement in it ("Dates in month–day–year format also require a comma after the day and after the year (except at the end of a sentence)."). They can't both be "right". I have a personal preference for the comma, but I recognize that my personal preference doesn't matter much. However, can't we at least make the two guidelines consistent?--Bbb23 (talk) 17:42, 14 January 2014 (UTC)

"Dates in month–day–year format also require a comma after the day and after the year (except at the end of a sentence)" isn't right because other punctuation after the year could eliminate the need for a comma. Examples:

• The event ended January 1, 1900 (except for a meeting of a small committee).
• The deadline is December 31, 1998; entries received later will be burned.

Jc3s5h (talk) 17:51, 14 January 2014 (UTC)

I agree with your two examples. Obviously, one would never insert a comma before an open paren or a semi-colon. Whether that needs to be stated is a matter of opinion, but it doesn't alter the run-of-the-mill example used at MOS:COMMA.--Bbb23 (talk) 18:14, 14 January 2014 (UTC)

It is, in fact, well settled that a comma is required after the year in MDY format (unless superceded by other punctuation, such as a period, closing parenthesis, etc.). Until recently [since 2011], MOS:BADDATEFORMAT said this:

Wikipedia does not use ordinal suffixes, articles, or leading zeros (except for the YYYY-MM-DD format). Wikipedia does not insert a comma between month and year, nor does it insert a full stop after the day (10 June 1921); however, when using the mdy format, a comma is required between day and year. When a date in mdy format appears in the middle of text, include a comma after the year (The weather on September 11, 2001, was clear and warm). Write out the full year string instead of using the apostrophe (') to abbreviate the first two digits of the year.

On 13 January 2014, this edit by User:EEng moved the text relating to the trailing comma and this next edit removed it entirely, without consensus and contrary to MOS:COMMA which clearly requires it, consistent with major style guides. This needs to be restored. —sroc 💬 22:19, 14 January 2014 (UTC)

Why editors cringe at the phrase MOS discussion

Over the last few weeks I've made 50+ edits to MOS/dates'n'numbers [6] -- rearranging, reorganizing, reducing repetition and redundancy, resolving apparent conflicts where I could (and tagging others for the attention of my fellow editors) -- improving (I hope) and making more palatable (I hope) the presentation in many ways.

I don't expect adulation and flowers for these efforts but I do expect that another editor, on noticing what is obviously (to anyone not afflicted with borderline hypervigilance) an honest mistake, will take stock of what I've been doing before giving vent to such absurdly strident huffing and puffing about "against consensus" and so on. What's wrong with you? Really! What in the world is wrong with you???

It's behavior like this that inspired one appalled editor to pen the following some time ago:

In the last 48 hr I've become aware of a simmering dispute over whether the text of MOS itself should be in American or British English. With any luck the participants will put that debate (let's call it Debate D1) on hold in order to begin Debate D2: consideration of the variety of English in which D1 should be conducted. Then, if there really is a God in Heaven, D1 and D2 will be the kernel around which will form an infinite regress of metadebates D3, D4, and so on -- a superdense accrection of pure abstraction eventually collapsing on itself to form a black hole of impenetrable disputation, wholly aloof from the mundane cares of practical application and from which no light, logic or reason can emerge.

That some editors will find themselves inexorably and irreversibly drawn into this abyss, mesmerized on their unending trip to nowhere by a kaleidoscope of linguistic scintillation reminiscent of the closing shots of 2001, is of course to be regretted. But they will know in their hearts that their sacrifice is for greater good of Wikipedia. That won't be true, of course, but it would be cruel to disabuse them of that comforting fiction as we bid them farewell and send them on their way.

EEng (talk) 00:32, 15 January 2014 (UTC) P.S. Spare me the lecture about civility. Calling for civility at Talk:MOS is like imploring proper use of the dessert fork in a crack house.

I'm not going to get into the civility issue (almost always a mine field), but I've never been to a crack house. Had I known they served desserts (the pastry kind) ... As for your latest edit, I like the additional examples but am not crazy about the wording, particularly the use of the word "anyway". I would suggest "In the MDY format a comma is required between day and year, as well as after the year (unless other punctuation follows the year)". BTW, I plan on having apple bread pudding tonight with a dessert fork.--Bbb23 (talk) 01:05, 15 January 2014 (UTC)

I like to remind people that in arid regions the desert fork is more appropriate. EEng (talk) 01:14, 15 January 2014 (UTC)

Without changing any single rule, most of the MoS could benefit from a rewrite. It's been written in little pieces by consensus over the years and it could be better in many ways. I've been kinda surprised that no one has jumped on you; you are making lots of big changes. It's hard to follow each one, so I'm assuming good faith and planning to wait until you stop, then I'll go over it to see if anything has changed. Let us know when you feel like you are done. SchreiberBike talk 02:39, 15 January 2014 (UTC)

It's not something I think of as a project -- just here and there I thought I could condense, deduplicate, etc. I do not intentionally change the meaning anywhere (except the rare case in which I call out clearly in the edit summary that I think I'm correcting a mistake etc.) and because I know many eyes are watching, I try to make every edit very transparent i.e. obviously changing version X into version X+1 with the same content, just different presentation. Thus, for example, you'll often see the edit summary "Reorder material (no content changes)" i.e. since when paragraphs are reordered it's difficult to see, in the diff, any changes within paragraphs, I leave such changes to subsequent edits for which the diffs will be easy to interpret. Naturally there are times I get ahead of myself, so some edits are more complex than they should be.

I'm therefore disappointed to hear you say they're individually hard to follow. Can you give me an example. In all seriousness, I'd like to know.

One thing I don't understand is your plan to wait until I'm "finished". I have made a few formatting innovations ("spaced" semicolon between examples, boldface for "subcase" descriptions such as Years written in full when crossing era boundary, etc.), and I expect to hear quickly whether people want to build on them, or don't like them. If you feel you want to check what I've done -- and please, I hope numerous others will do that -- please start at your earliest convenience. I will naturally be pissed off if (assuming my inspiration holds up sufficiently) I make another 50 edits in the same vein, just to have have you declare at the end, "Well, I don't like it." So speak up promptly, please (though I don't feel the inspiration coming on for a few more days at least).

EEng (talk) 03:44, 15 January 2014 (UTC)

You are right that the individual edits are each easy to follow, I just don't consider the MoS to be core to my interests in Wikipedia, and since there are a lot of individual edits, I decided not to check each one. Had I thought about rewriting a section of the MoS, I think I would have worked on it in a sandbox, then sought feedback before proposing the new text. Your approach is completely valid though and what I've looked at has looked good. SchreiberBike talk 06:22, 15 January 2014 (UTC)

@EEng: Firstly, let me say that my comments above were not meant to criticise you, but merely to draw attention to the situation, and by mentioning you by name, your attention could be drawn to the discussion via the notification feature.

Secondly, let me say, with all due respect, that I don't this your edit re-writing that section was an improvement, because:

• I don't think additional examples are necessary (and we've happily gotten on without them for years);
• I don't agree that any punctuation supersedes the need for the trailing comma. For example, I do think that one would be needed following a set of parentheses: September 11, 2001 (now commonly known as 9/11), was a day that.... That second comma is needed because "2001" is parenthetical to "September 11" and needs the matching comma, and the parenthetical remark does not replace this. Similarly, a superscript footnote symbol or asterisk would not avoid the need for the second comma, either. (Yes, other terminal punctuation, such as a question mark, would of course supersede the comma, so this should be listed in the exceptions.)

I hope you don't take these criticisms personally. And thanks for your other efforts in cleaning up the section generally — it's just that this always requires care to make sure the meaning isn't lost in the process. —sroc 💬 03:50, 15 January 2014 (UTC)

You should never talk about edits "against consensus" unless it's clear that was intentional. It's offensive. Why didn't you just make the change yourself, with edit summary, "Looks like this may have been deleted accidentally"?

It's only by some cruel twist of fate that this accidental deletion I made -- I somehow misread the comma-after-year provision as comma-after-day, and therefore deleted it because comma-after-day is stated elsewhere -- happened to intersect one of these endless MOS disputes. I should get the hell out of here, but some Satanic force is draws me closer. I know I will regret it, but can't stop myself. I'll comment below later. EEng (talk) 02:01, 16 January 2014 (UTC)

I'm sorry if what I said was offensive. I wasn't directing criticism or anger against you, just stating the facts. It was directed at the others who created a "do we or don't we?" debate in the interim period while the pertinent text went missing. Please don't take it personally! —sroc 💬 04:44, 17 January 2014 (UTC)

Apology accepted. Now if you will seriously reevaluate whether your role in the promulgation of prescription on points of extremely minor importance (#Why_every_goddam_thing_needn.27t_be_micromanaged_in_a_rule), is helping or hurting the project, than my annoyance will turn to genuine respect. EEng (talk) 05:12, 17 January 2014 (UTC) (That wasn't very well punctuated, BTW.)

EEng, I have been watching your edits with admiration. They are bold, iterative, and for the most part small positive improvements that appear to be leading toward a coherent and much-improved whole. I will paraphrase what another editor expressed above: it is not always clear where you are going from a particular diff, and the next edit is sometimes a reordering or tweaking of the same section, but the sections in general end up clearer. I would also appreciate a posting here when you feel like you are ready for fresh eyes to take a look at the section as a whole. Many of us are willing and could point out, in a friendly and constructive way, minor areas for improvement – I expect there will be a few, as is typical with a complex text like this one. You are brave for taking it on amidst a crowd of picky editors armed with forks of various flavors. Something something just deserts.... – Jonesey95 (talk) 06:10, 15 January 2014 (UTC)

I think greater exposure of Jonesey's edit summary for his post just above ("Use every man after his desert, and who should 'scape whipping?" - Hamlet, II, 2) is no more than, er, its just deserts -- and with the talk now shifting to whipped deserts, the desert fork is more appropriate than ever.

There are three innovations I made at WP:Manual_of_Style/Dates_and_numbers#Ranges about which I'd particularly like feedback:

[List moved to #Feedback requested on formatting innovations ]

Why the comma is needed after parentheses

In MDY dates, the year is in apposition to the date. Appositions are padded by commas, similar to the use of matching parentheses. For example:

• Billy Ray, the son of a preacher, was immortalized in a song made famous by Dusty Springfield.
• The weather on September 11, 2001, was clear and warm.

When an apposition is followed by a remark in parentheses, the second comma is still required and follows the parentheses.

• Billy Ray, the son of a preacher (who is unnamed), was immortalized in a song made famous by Dusty Springfield.
• The weather on September 11, 2001 (now commonly known as 9/11), was clear and warm.

That's why I believe this edit by EEng (removing the comma in one example and removing the explanatory text) is erroneous. I have removed the disputed example for now, but would like to reach a consensus on this. —sroc 💬 22:25, 15 January 2014 (UTC)

• That is how I understand the grammatical rules, and how I usually try to apply them in my writing. -- Ohc ^¡digame! 01:22, 16 January 2014 (UTC)
• Yes, the year is in apposition, hence it requires a comma afterwards, even if there is a parenthetical statement after the year. Example without a year that shows the same idea: Billy Ray, the son of a preacher (who died in a car crash shortly after Billy Ray's birth), was immortalized in a song made famous by Dusty Springfield. The year does not require a comma afterwards if the year is followed by a semicolon, colon period (or other sentence-ending punctuation), or dash. – Jonesey95 (talk) 02:11, 16 January 2014 (UTC)

Let's review your first example (though I trust you don't mind my modifying a bit):

Billy, the son of Joe (who died after Billy was born), was immortalized in a song.

Here the phrase the son of Joe (who died after Billy was born) modifies Billy, and ("zooming in", so to speak) that (who died after Billy was born) modifies Joe. So far so good. But if, as you say, that example parallels this one...

The weather on September 11, 2001 (now commonly known as 9/11), was clear and warm.

...then the result would be nonsense, because by your logic not only does 2001 (now commonly known as 9/11) modify September 11 (which I'll let pass for the moment), but also (now commonly known as 9/11) modifies 2001, which is absurd.

I dare you to point to respectable writing that uses such a construction. I'll have more to say later, but for now I leave you with that challenge. EEng (talk) 02:40, 16 January 2014 (UTC)

By that logic, omitting the second comma (The weather on September 11, 2001 (now commonly known as 9/11) was clear and warm.) would mean that 2001 (now commonly known as 9/11) was clear and warm was in apposition to September 11. This makes much less sense.

I accept that the examples are not in perfect harmony—an unfortunate by-product of the awkwardly un-endian MDY format—but that's how it goes.

I'll need to do some digging to find a style guide on point in this particular case, but you can see from the above comments that I am not a renegade in this understanding. —sroc 💬 02:48, 16 January 2014 (UTC)

Looking at it another way, would you draw a distinction if the parenthetical remark were about the year?

• The weather on September 11, 2001 (a particularly humid year), was clear and warm.

Or if its point of reference were more vague?

• The weather on September 11, 2001 (long after meteorological records were kept), was clear and warm.

Would you dispute the appropriateness of the second comma in those cases? —sroc 💬 02:55, 16 January 2014 (UTC)

Why the comma is not needed even after the year -- at least not all the time

I'll get to your last two examples at the end of this post. I look forward to a published example of the

The weather on September 11, 2001 (now commonly known as 9/11), was ...

kind. But moving on to the more global issue of comma-after-year in general ...

Let me first repeat that my removal here [7] was unintentional (I mistakenly thought it was duplicated elsewhere), and it's only by accident that I find that it intersects a discussion into which I now, contrary to my better judgment, allow myself to be drawn.

You treat punctuation marks like mathematical operators which organize words into nested structures of Russian-doll clauses and such, and they're nothing like that. This talk of 2001 being an appositive (or parenthetical, or whatever) stems from the urge to force everything onto this Procrustean bed. But if that were in fact appropriate, then instead of The attacks of 11 September 2011 were... we'd write The attacks of 11 September, 2011, were... which of course we don't.

The function of the comma in September 11, 2001 -- like that of many commas -- is not grammatical but practical: it separates the two sets of digits -- a function unneeded in 11 September 2011, which is why there is not -- I point out again -- any comma there. There's no need to read the tea leaves of nearby commas in order to assign 2001 a grammatical function such as "apposition", because 2001 -- in that particular position, with its introductory comma -- needn't be justified by such a formal function -- it's just a component of one of (several) conventional ways of writing dates. (And consider the format 2001-09-11 -- where's the apposition there?)

The belief in the "required second comma" after the year seems entirely based on this idea that the year is appositive, and therefore needs to be "bracketed" by a paired set of commas. No appositive = no bracketing = no required second comma.

But that doesn't mean a second comma won't be present for other reasons. Notwithstanding the somewhat conservative NYT (stylistically conservative, anyway -- no doubt their style book dates back to the 19th century, when commas grown by slave laborers on colonial comma plantations were cheap and plentiful) there's plenty of good writing in which the year is or isn't comma-followed according to the logical and rhythmic needs of the sentence (and sometimes desired emphasis) -- not rigid logic alone:

Born on September 11, 2001, he always felt a special spiritual burden.

Born September 11, 2001, he always felt a special burden.

Born September 11, 2001 at 9:11 AM, he always felt a special burden.

Born September 11, 2001 -- at 9:11 AM -- he always felt a special burden.

Born September 11, 2001 (at 9:11 AM!) he always felt a special burden.

September 11, 2001 was a day to remember.

Those born September 11, 2001 may feel a special burden.

His September 11, 2001 birthdate meant he felt a special burden.

His birthdate of September 11, 2001, combined with an absent father, gave him the feeling of a special burden.

Please tell me the truth -- would you really write this?

Born September 11, 2001, at 9:11 AM, he always felt a special burden.

As to your last two examples: I wouldn't write any of those things (no matter how punctuated):

Not:

• The weather on September 11, 2001 (a particularly humid year), was clear and warm. (Kind of sounds like September 11, 2001 was a year.)

Instead:

• The weather on September 11, 2001 -- that year having been a particularly humid one -- was ...
• The weather on September 11 of 2001 -- a particularly humid year -- was ...
• In 2001 -- a particularly humid year -- September 11 was ...

Not:

• The weather on September 11, 2001 (long after meteorological records were kept), was ... (Kind of... well... the following is better...)

Instead:

• On September 11, 2001 -- many decades after meteorological recordkeeping had begun -- was ...

EEng (talk) 08:26, 16 January 2014 (UTC)

Firstly, MOS:COMMA states: "Dates in month–day–year format also require a comma after the day and after the year (except at the end of a sentence)." This guideline has been discussed at length. Your proposal contradicts it. If you want to change the status quo, you will need to form consensus to change both MOS:COMMA and MOS:DATEFORMAT to reflect that and remain consistent.

Secondly, the status quo is supported by reliable sources/style guides:

• Chicago Manual of Style, FAQ:

Q. Is the following the correct way to punctuate the date?

Period between June 23, 2003 and March 19, 2004

A. It’s conventional to put a comma after the year. The commas are like parentheses here, so it doesn’t make sense to have only one.

• C. Edward Good, A Grammar Book for You and I-- Oops, Me!: All the Grammar You Need to Succeed in Life (2002), pp 374–375:

When you indicate month, day, and year, put a comma after the dat and after the year (unless some other punctuation mark, like a period or question mark, follows the year). Include these commas even if the month-day-year expression serves as an adjective:

On July 1, 1991, the committee dismissed the employee.

We already responded to your July 1, 1991, letter.

• Geraldine Woods, English Grammar Workbook For Dummies (2006), p 70:

For a date that includes (in order) the month, day, and year, place a comma after the day. If this kind of date is in a sentence that continues beyond the year, place a comma after the year. ("I plan to blow up the rutabaga patch on August 4, 2006, unless I find a more enticing vegetable.")

• Katherine Hogan, Barron's GED Writing Workbook (2009), p 330:

On December 7, 1941, the Japanese bombed Pearl Harbor. Don't forget to place a comma after the year.

• Stephen R. Covey, FranklinCovey Style Guide: For Business and Technical Communication (2012), p 257:

Use a comma after the year in a date and the state in an address when either appears in the middle of a sentence:

The time sheets for July 6, 2010, show no overtime.

• Gina Hogan, Building Better Grammar (2012), p 214:

If you write a sentence that includes the month, day and year at the beginning, you must include a comma after the year:

On May 12, 2001, I found out about my father's cancer.

• David E. Sumner, Holly G. Miller, Feature and Magazine Writing: Action, Angle, and Anecdotes (2013):

As explained earlier, do not put a comma after a year when no date is mentioned, but do use a comma when the date includes a specific month, date and year. You should also use a comma after the name of a state when it follows the name of a city. Example:

Dennis Ulrich left his job on May 13, 2011, after a dispute with his former employer to move to Anchorage, Alaska, to take a new job.

Thirdly, you can't have your cake and eat it, too, by arguing that The weather on September 11, 2001 (a particularly humid year), was clear and warm implies that "September 11, 2001 was a year" because this: (a) is patently ridiculous; and (b) undermines your argument that the parenthetical remark should only apply to the apposition (i.e., 2001).

Incidentally, can we lay of September 11, 2001? It was a busy day, but it's shouldering a lot of work around here. —sroc 💬 11:44, 16 January 2014 (UTC)

Style guides determine when punctuation should be used. Punctuation is not some flighty thing that you use when it feels right or the mood takes you (otherwise the MOS would be redundant). As such, the following examples you provided are flawed because they flout the accepted style:

• Born September 11, 2001 at 9:11 AM, he always felt a special burden.
• Born September 11, 2001 (at 9:11 AM!) he always felt a special burden.
• September 11, 2001 was a day to remember.
• Those born September 11, 2001 may feel a special burden.
• His September 11, 2001 birthdate meant he felt a special burden.

In response to your question:

Please tell me the truth -- would you really write this?
       Born September 11, 2001, at 9:11 AM, he always felt a special burden.

If I were constrained to use MDY format and it were necessary to include the time, yes, that is how I would format it—but I don't see how the time of birth is relevant to his "special burden", so I would probably recast the text to separate it from the birth information (assuming that the date and time of birth were relevant at all). —sroc 💬 11:55, 16 January 2014 (UTC)

Why every goddam thing needn't be micromanaged in a rule

I'm not (as you say) "arguing that [blah blah] should only apply to the apposition [blah blah blah]", because I'm not arguing that "the apposition" is or is not anything, because as I've said over and over I don't think 2001 is an apposition. I only talked about apposition long enough to apply reductio ad absurdum -- to show that the idea it's an apposition is logically inconsistent with a dozen other things. Once again (for example): if 2001 is an apposition (requiring to be bracketed by mighty commas) in this ...

September 11, 2001,

... then why don't we comma-bracket 2001 here ...

11 September 2001

for the same reason.? Answer, again: in both cases 2001 is not an apposition, just a part of the date. And in the first case (only) convention calls for a comma, I guess because without it the day-digits and year-digits run into each other visually.

Unless I missed it in there somewhere, you still haven't given an example of anything supporting

On December 25, 2001 (which was Christmas Day), we all went ...

which is what I asked for several posts ago. If you can't find even a few (or even one) style guide, or respected-writer exemplar, to illustrate this year-(parenthetical)-comma claim, then that's pretty much it.

However, even if you had found such, that would only mean this construction has at least some support somewhere, so that it's not a waste of time for discussion to continue (looking at other sources, at other examples, into our own secret-hearts-of-style, etc.).

That's why you've wasted your time posting all those examples on the comma-after-year rule i.e. the idea that there must be a comma after the year in e.g.

On December 7, 1941, the Japanese ...

-- wasted your time because we all know lots of guides recommend that and you see that usage all the time. The question then becomes: What other views are there? What other usage is there? And out of all that, what rule do we want to adopt? Or do we need a rule on this at all?

That last is, actually, the most important question. Not everything has to be rigidly prescribed and no, I don't buy into the "OhButIfWeDon'tThereWillBeEndlessArgumentOnEachArticle" reasoning just because that might, sometimes happen.

Coffee-fueled parody

All over Wikipedia there are years with comma following, and years with no comma following, and never have I seen two editors, both of whom are actually engaged on a particular article, in serious conflict over a particular instance of that question. The discussion might go, "Hmmm... I'd use a comma myself but if you prefer none... yeah, that looks OK too. Now about that source-reliability question we were discussing..." but that's about it. Where I've seen actual trouble is when other editors -- who have shown (and will subsequently show) no active interest in the article itself -- arrive out of nowhere in their radar-equipped year-with-no-comma-detector vans, then break down the door to weld court-ordered ankle-bracelet commas onto some harmless 2001 whose only crime was appearing in public with his trailing digit exposed -- something which (these prudish enforcers of Victorian punct-morality seem never to understand) was considered perfectly acceptable in most cultures throughout human history. Did you know, for example, that in the ancient Olympic games, years and days competed completely naked, without even a comma between them? I'm not advocating that unhygienic extreme but a bit of exposed backside shouldn't shock anyone in this enlightened age. But I digress, so back to our narrative underway... Having rendered yet another noble service in defense of the homeland (as they like to tell themselves) they jump back into their black SUVs and scurry up their rappelling ropes to their double-rotor helicopters and fly off to their next target, never knowing or caring whether that particular article has, or has not, been improved by their visitation. Certainly all the breaking of the crockery and smashing of the furniture can't have helped, but order has been restored and choas beaten back, which is what's important. During all this the neighbors cower in their homes with the lights out, glad that they are not the targets of these jackbooted comma-thugs -- at least not this time. "Look," they say to their children, "that's what happens if you don't obey the rules. You should love Big Brother for his heroic decication to relieving your of the burden of deciding anything for yourself." But privately they're thinking, "CAN'T YOU JUST LEAVE US ALONE FOR ONCE -- GRANT US JUST A SHRED OF PERSONAL AUTONOMY, A TINY REMINDER OF THE TIME WHEN THERE EXISTED A FEW ZONES OF DISCRETION IN WHICH MEN WERE FREE TO WORK OUT WITH THEIR FELLOW-EDITORS WHETHER OR NOT TO APPLY A COMMA, ACCORDING TO THE DICTATES OF THEIR OWN CONSCIENCES? CAN YOU REALLY NOT SLEEP AT NIGHT, KNOWING THAT SOMEWHERE OUT THERE, EDITORS ARE DECIDING FOR THEMSELVES THE PLACEMENT OF COMMAS? MUST YOU DICTATE FUCKING EVERYTHING?" As Hannah Arendt put is so well: "It is the inner coercion whose only content is the strict avoidance of contradictions that seems to confirm a man's identity outside relationships with others. It fits him into the iron band of terror even when he is alone, and totalitarian domination tries never to leave him alone except in extreme situation of solitary confinement. By destroying all space between men and pressing men against each other, even the productive potentialities of isolation are annihilated..." Or as John Stuart Mill -- himself a great lover of commas, so you can't dismiss him as a bleeding-heart, comma-omitting permissive corruptor of young punctuators -- said... Oh, never mind.

You say

Punctuation is not some flighty thing that you use when it feels right or the mood takes you (otherwise the MOS would be redundant). As such, the following examples you provided are flawed because they flout the accepted style.

Yes, if we can't prescribe and control every detail of usage and punctuation societal decay sets in and soon there is immorality, open homosexuality, interracial marriage, and baby murder.. Or perhaps I've misunderstood you?

The opposite of rigid prescription of everything isn't "flightiness" on everything; the opposite of rigid prescription on everything is measured guidance appropriate to the point being discussed:

• Rigid prescription where truly appropriate.
• Clear direction where experience shows people often go wrong
• Enumeration of alternatives where choices are available
• Universal advice to use common sense no matter what

That last point, BTW, is one of the first thing MOS says. I'm quite aware (because I accidentally removed it, remember?) that there's currently a MOS rule requiring comma-after-year. And I'm telling you that if it were removed, or changed to a short mention that opinions differ on this, it would go a long way toward repairing the disdain many editors have for those parts of MOS which ridiculously overreach and overprescribe, thus preserving respect for its important provisions on things that really matter. But I have no expectation that will happen and I'm not gonna push it.

You can have the last word now. Unless you come up with something published which supports

The weather on September 11, 2001 (now commonly known as 9/11), was ...

there'll be no need for me to respond. EEng (talk) 02:06, 17 January 2014 (UTC)

Micromanaging the placement of commas for everyone while pushing rampant biases is ignored on numerous subjects. It's what Vogons do - and always will! Til Eulenspiegel /talk/ 02:52, 17 January 2014 (UTC)

Boy, that escalated quickly. I admit that finding an example of this specific arrangement is difficult. The point remains, however:

• Other editors agree that the year is in apposition in MDY dates; in fact, I learned that explanation from other Wikipedians. Perhaps this was a mechanism that was adopted by grammarians to justify the comma in the awkward date format where the elements do not follow a logical, endian order, which would explain why DMY dates do not require this construction.
• Chicago Manual of Style, a prominent style guide, explains that the commas act as parentheses, which would require that they be paired (one before, one after).
• Not to have a comma after a remark in parentheses that immediately follows the year in MDY format would be an exception to the accepted style. You have not provided any style guides or reputable sources that support this exception.
• An accepted style ought to be followed consistently, not decided on a whim on a case-by-case basis as in the examples you gave earlier. The corollary is that if you stray from the accepted style, others may come in and clean it up.
• It is therefore inaccurate to say: "In the MDY format a comma is required between day and year, and (unless the date is followed by some other punctuation) after the year as well." This is because the "other punctuation" could be an opening parenthesis, in which case a comma would be required after the closing parenthesis (as if the parenthetical remark were not there at all). I grant you that this situation may be rare, and the consensus may be to leave it out of the MOS for this reason, and that's fine. If the result is mini edit wars over the insertion/deletion of that disputed comma, then perhaps it would be better to deal with it now once and for all; if the consensus is to leave the exception unstated, then I'll let sleeping dogs lie, though if I ever do come across such an example on Wikipedia, I might just revise it accordingly — and then you'll have your sought-after example. —sroc 💬 12:14, 17 January 2014 (UTC)

Just what did those nuns do to you? EEng (talk) 17:51, 17 January 2014 (UTC)

Feedback requested on formatting innovations

Bold, spaced semicolons, code examples

There are three innovations I made at WP:Manual_of_Style/Dates_and_numbers#Ranges about which I'd like feedback:

(1) Use of bold to make "use cases" visually easy to find e.g.

2005/06 may be used to signify a fiscal year or other special period

(2) "Spaced" semicolons between examples:

355–372 (not 355–72) ; 95–113 ; 95–113 AD

...because with the more conventional

example, example

...it seems (to me) too hard to tell whether we're looking at two examples, or just one (that happens to have a comma in the middle -- it doesn't help that the coloration of the little comma is impossible to see).

(3) "Code:" examples for use of nbsp, endash, etc.

EEng (talk) 02:01, 16 January 2014 (UTC)

• The second change is fine with me, makes things much more readable. For (2), it's good to use semicolons, but without spaces before them; that's going to cause all kinds of formatting issues, with long lines wrapped so a semicolon starts a line etc. Also, that's against how semicolon is generally used. Regarding the first change, applying bold style is fine with me, though in general that's against MOS:BOLD and italicization should be used instead; MOS must have been an exclusion from its own rules. :) — Dsimic (talk) 23:09, 17 January 2014 (UTC) — Dsimic (talk) 01:58, 18 January 2014 (UTC)

Just to be clear, by "second change" you mean (2), right?

Re the bold: bold's main use (beyond emphasis -- at a level not generally appropriate for articles) is to make key phrases etc. jump out visually in a list of instructions, a reference to be consulted in a hurry, etc. And since WP:NOTMANUAL blah blah blah, that doesn't make sense in articles either. But MOS is a manual, so I think that use of bold (to catch your eye with phrases like birthdates of living persons or Old Style dates or whatever) makes perfect sense. EEng (talk) 23:49, 17 January 2014 (UTC)

Exactly, second change is (2), and first change is (1).

I'm perfectly fine with using bold typeface in MOS, it makes things much more readable; I was just trying to make everything clear to the point any later review of this isn't finding it incomplete. — Dsimic (talk) 00:30, 18 January 2014 (UTC)

• In (2), I favour semicolons between examples, but not preceded by a space. Firstly, that's not consistent with proper style in English. Secondly, spaces will lead to wrapping problems where the semicolon will appear at the beginning of lines of text unless you use a non-breaking space, and even then some editors will use a plain space without recognising the difference. Thirdly, the issue (if there is one) seems to arise from the green/red formatting the {{xt}} and {{!xt}} templates use, in which case it may be preferable to adjust the formatting those templates (and associated templates) use. I've customised my stylesheet so the examples are surrounded by a dotted green or red border, so each example appears distinct to me anyway, and you could adopt a similar format for your custom stylesheet if you find the default formatting particularly irksome, rather than prescribing a change to how everyone writes examples across Wikipedia. —sroc 💬 01:27, 18 January 2014 (UTC)

On second thought, I agree with sroc, and I will be changing my comment above. — Dsimic (talk) 01:58, 18 January 2014 (UTC)

Sroc, I wasn't "prescribing a change to how everyone writes examples across Wikipedia". I was trying out a new idea for formatting examples on this page, to address a problem I saw. After people had a chance to comment, it might (a) completely disappear; (b) continue to be used on this page only; (c) slowly spread to other pages where it makes sense; (d) catch fire and suddenly be used everywhere as the greatest thing since sliced bread. It's OK if there's a little inconsistency among pages, a little experimentation, a little demonstration. That's how progress is made.

Suggesting that a problem (if there is one) should be fixed by a user changing his own stylesheet is ridiculous. If it's really a problem likely to annoy many users, we should fix it; and if not then there's nothing to be fixed.

It doesn't matter whether it's "proper style of English" -- programming manuals, style books, and similar works jumping back and forth between text and metatext use all kinds of techniques to keep those clearly separate that you won't find elsewhere. SPACE;SPACE was an experimental way of delimiting examples that (without requiring squinting determine the color of a tiny comma) could be immediately distinguished from the examples themselves. SPACE;SPACE obviously fulfills that requirement exactly because it has the very attribute you complain of -- it's not anything you see in normal English, so can't be confused for part of the examples themselves.

BTW, putting text in green and in red isn't any kind of "proper style of English" I've ever seen. Assuming you haven't either, why aren't you complaining about that too? Here as elsewhere you're so preoccupied with propriety, instead of practicality (not to mention reality), that you get tangled up in your own arguments. (And -- again BTW -- that sentence you just read is a place where, yes, the paren should be followed by a comma.)

SPACE;SPACE may be too radical and I have no special affection for it. I'm happy with just a semicolon (spaced the normal way -- EXAMPLE;SPACE) is enough, because semicolon is sufficiently unusual -- in the few cases where semicolon might be misunderstood to be part of the example, we can break the examples out to separate lines.

All in favor?' EEng (talk) 08:42, 18 January 2014 (UTC)

Sorry I misunderstood the scope of your proposal from your (vague) original post. Was that diatribe response really necessary? I agreed that semicolons were preferable to commas. On the spacing, I pointed out several flaws with your proposal. If others agree that the separation between examples is unclear, then something should be done, but not necessarily what you proposed. If not, then I gave you a DIY fix. I was merely trying to be helpful by raising points you may not have realised or thought of. No need for the blown gasket, Charlie. —sroc 💬 03:05, 19 January 2014 (UTC)

(Nice work on the latest innovations to the date formatting tables, by the way.) —sroc 💬 03:09, 19 January 2014 (UTC)

And thank you for your contributions as well -- I was running out of steam on the table (I hate that syntax with all the ||s and stuff) and just couldn't face breaking up the examples further. I think the result so far is a much, much improved presentation, and the surprising fact that no MOS swarms have appeared out of nowhere to eat out our livers means we must be doing something right.

Naturally I'll be going through to tinker. If you feel strongly about anything we've push-pulled on already raise it here.

Contrary to concerns you've posted elsewhere, except for my very first post (re your statement that I had edited "against consensus" -- that really pissed me off!) I'm not upset nor in any way personally offended. I do think we have different sensibilities on certain subjective questions (in some cases, the differences begin with the fact that I consider subjective many things you consider subjectiveobjective -- a bit of a paradox there) but such tension can be productive, so long as you bear in mind that I'm always right.

A pair o' docs

A pair o' docks

EEng (talk) 12:49, 19 January 2014 (UTC)

If you consider subjective many things I consider subjective, our differences may be more similar than you think. —sroc 💬 16:26, 19 January 2014 (UTC)

Well, I said it was a paradox, didn't I? (See images.) Anyway, objectivity is subjective (skip to 0m50s if you're in a hurry).

EEng (talk) P.S. I take it you see now [8] the sense in using a character sequence not found in standard English to separate examplesnot consistent with proper style in English.

P.S. What?! (1) I started off saying "I favour semicolons between examples"! (2) When did semicolons stop being "found in standard English"?

—sroc 💬 01:25, 21 January 2014 (UTC)

They didn't. What you said (and I sorry I misquoted you -- corrected above) is, "I favour semicolons between examples, but not preceded by a space. Firstly, that's not consistent with proper style in English."

Just to make sure... we're in violent agreement on this. I proposed "spaced semicolons" (Ex1 ; Ex2) but figured it would be too radical. You countersuggested normally-spaced semicolons (Ex1; Ex2), and I agreed, because semicolon is rare enough in examples that there won't be too many situations wherein confusion could arise (requiring the examples to be broken out to a bullet list etc.). With commas, in contrast, that happens a lot, as you noted in your edit I linked above. If I were dictator I'd dictate spaced ; but I'm not, so I'm happy with everyday ;.  :)

An important point: I'm not speaking to you again until I get some kind of amused response to the pair o' docs and the pair o' docks. That pair 'o docs, by the way, performed one of the first partial removals of the large intestine, thus inventing the semicolon. EEng (talk) 02:57, 21 January 2014 (UTC)

I must disagree: I'm opposed to violence. —sroc 💬 09:41, 21 January 2014 (UTC)

Oh, here's a better way I stumbled upon at MOS:ENDASH—a semicolon followed by three spaces (;   ):

• pp. 211–19;   64–75%;   the 1939–45 war
• 10:30 pm Tuesday – 1:25 am Wednesday;   Christmas Day – New Year's Eve;   Christmas 2001 – Easter 2002
• boyfriend–girlfriend problems;   the Paris–Montpellier route;   a New York–Los Angeles flight
• the Uganda–Tanzania War;   the Roman–Syrian War;   the east–west runway;   the Lincoln–Douglas debates;   a carbon–carbon bond

Let's do that! —sroc 💬 15:03, 21 January 2014 (UTC)

Agreed, spaced that way it looks great! — Dsimic (talk) 01:45, 22 January 2014 (UTC)

I think the even greater separation lent by the 3 spaces is yet another improvement but (especially with 3 spaces "available" now) want to bring back the idea of using one of the 3 to clearly separate the ; as seen here:

• pp. 211–19 ;  64–75% ;  the 1939–45 war

Actually, while my head says that SPACE ; SPACESPACE is more logical my eye says that ; SPACESPACESPACE looks better, so I'll go with whichever the rest of you prefer. I am, however, extremely disappointed at getting not even a giggle at the paradoxical images above, despite dropping hints, giving elbow nudges, and even delivering the extremely topical and clever quip seen in bold. In future I shall cast my pearls before more appreciative swine. EEng (talk) 04:44, 22 January 2014 (UTC)

Umh, I'm still against spaces before semicolons.

About the images, they did bring a smile on my face, and the "semicolon surgery" was funny too! :) You're almost always bringing smile on my face with your comments and overall writing style. :) — Dsimic (talk) 04:54, 22 January 2014 (UTC)

Wow. That was really nice of you to say.

Not everyone agrees, however. One editor said that my writing (and in particular my use of the phrase remarkably small) "reads like a teenage girl's diary." I was about to ask what teenage girls' diaries he'd seen until I realized... it was probably the diary of a high school or college girlfriend. The intense feelings of inadequacy this no doubt instilled in him well explain the dyspeptic hostility seen in his activities here.

Anyway, thanks again. You did see the "Coffee-fueled parody" here [9], didn't you? EEng (talk) 06:24, 22 January 2014 (UTC)

You're welcome. Well, it all depends on how people are busy, I'd say. When people are really busy and thus unable to catch up, they tend to detect any digression as completely pointless; usually, males then project that onto the stereotypical female banter-style orientation. On the other side, when people have some slack, a certain amount of fun is actually good; all work and no play makes Joe a dull boy. Of course, all play and no work is equally bad.

And of course, those "radar-equipped year-with-no-comma-detector vans" are hilarious. :) — Dsimic (talk) 06:44, 22 January 2014 (UTC)

There really was a Mill quote I was gonna bring in, but it was a stylistic letdown after Arendt, so I didn't. But for the record here it is, from On Liberty' (Chapter III: "Of Individuality, as One of the Elements of Well-Being"):

In some such insidious form there is at present a strong tendency to this narrow theory of life, and to the pinched and hidebound type of human character which it patronizes. Many persons, no doubt, sincerely think that human beings thus cramped and dwarfed, are as their Maker designed them to be; just as many have thought that trees are a much finer thing when clipped into pollards, or cut out into figures of animals, than as nature made them.

I wish I could write like that. IMHO the three greats of the English essay, ever, are Orwell, Mill, and the strangely forgetten John Wilkins. EEng (talk) 16:57, 22 January 2014 (UTC)

snd template

There's a {{sn}}{{snd}} template for "spaced ndash" i.e. nbsp + ndash + regular space. Any reason not to start using that in e.g. the code examples at WP:Manual_of_Style/Dates_and_numbers#Ranges? EEng (talk) 16:34, 17 January 2014 (UTC)

• For what it's worth, templates of this type can cause problems when they are included in |date= and similar parameters in cite templates. It's fine to use them in examples, but if clever editors view the wiki source, copy the example, and use it in a cite template, it might generate a red error message, and a bot or an editor will have to come along and fix it. And then someone will no doubt post somewhere saying "but the MOS uses them in date range examples, so they must be allowable." Because that happens.

So if they are included, a note (even a hidden comment, for source viewers) about not using them in cite templates might be in order. I sigh because it's all so picky, but clear communication up front may allow us to avoid some of those conversations. – Jonesey95 (talk) 19:03, 17 January 2014 (UTC)

I'll look into what you're saying in a minute, but don't want to waste any time before pointing out that got the template name mixed up in my OP -- now corrected there. EEng (talk)

OK, now that I've gotten over being an idiot in posting the wrong template name... I don't see what the problem is with cite templates. Please explain. EEng (talk) 23:13, 17 January 2014 (UTC)

I was going to provide an example citation, but all of the endashed date ranges that I can think of will give errors regardless of whether templates are used or not, because complex date ranges are currently marked as errors by the cite templates' Lua module code. They should be supported soon, but are not right now. Too much to explain here; see Module_talk:Citation/CS1#HTML_entity_for_n-dash for a taste, and Module_talk:Citation/CS1#Legitimate_date_range_examples_to_add_to_the_date_checking_part_of_the_CS1_module for an extended take on date ranges in CS1 citation templates. – Jonesey95 (talk) 23:24, 17 January 2014 (UTC)

Without getting into whether certain values are or are not valid in certain fields of certain templates, I still don't see, if nbsp+ndash+space is a legal value, why a template that expands to exactly that shouldn't also be legal. And if nbsp+endash+space isn't legal, then none of this matters anyway. EEng (talk) 00:13, 18 January 2014 (UTC)

<bump> Jonesey95, if you really think there's some problem with using snd in citation templates, please explain. Otherwise I don't see why MOS shouldn't start presenting it in code examples. EEng (talk) 03:24, 21 January 2014 (UTC)

Well... I can't explain it, at least not with examples, because the CS1 modules do not currently support validation of date parameters with date ranges that require spaced endashes, like "Fall 1996 – Winter 1997" or "May 27 – June 3, 2002". Since the current module code would mark these as invalid dates regardless of punctuation (because a feature request has not been implemented yet), using a regular spaced endash or {{snd}} will produce identical error messages. As you can see in the linked examples, it doesn't even handle regular endashes of various types consistently.

Go ahead and use {{snd}} in the examples. Since the module has not been programmed to check for these date ranges, it may be able to check for {{snd}} in its new code. – Jonesey95 (talk) 04:56, 21 January 2014 (UTC)

• I've always used that one as {{spaced ndash}}, btw. — Dsimic (talk) 23:02, 17 January 2014 (UTC)

The advantage of {{snd}} is, of course, brevity. It's kind of the tail wagging the dog for the little dash to take up more space in the code than the 4-digit years (or whatever) on either side. EEng (talk) 23:22, 17 January 2014 (UTC)

Makes sense; just got wiring of my brain changed, so {{snd}} is my new friend. :) — Dsimic (talk) 00:44, 19 January 2014 (UTC)

hanging indent, multiple columns for examples

Please don't use templates like {{hanging indent}} or {{columns-list}}. The first causes the text to be misaligned; it is not designed for this purpose, and the use of columns makes it look very disorganized. Using a fixed number of columns is very much discouraged, and it is simply not needed for lists with very few items. — Edokter (talk) — 12:23, 18 January 2014 (UTC)

(1) It does seem something goes wrong with alignment in one situation which you (quite properly) reverted here [10].

(2) There's a bewildering array of multicolumn templates and I just closed my eyes and picked one; certainly a fixed # of columns was dumb. I've removed all the multicolumns for now.

[Later: turns out I failed to remove tham all, actually. [11]] EEng (talk) 10:39, 20 January 2014 (UTC)

(3) However, I don't see the problem with hanging indent. I want to fool with it more myself before trying to explain the use case -- maybe I won't like it myself anyway.

EEng (talk) 13:54, 18 January 2014 (UTC)

Can you "fool with it" in the sandbox, please, not in MOS where everyone will see you building castles with lopsided turrets. —sroc 💬 07:06, 19 January 2014 (UTC)

That's what I meant by fool with it "myself" -- I'm not afraid to innovate modestly on the live page (and almost everything I've done has met with approval so far -- just minor corrections and suggestions) but the moment I get resistance on something new of course I stop moving in that direction, rethink and experiment privately, and either drop it or open a discussion. EEng (talk) 02:57, 21 January 2014 (UTC)

Bullets vs. hanging for example lists

It seems that lists of examples that were previously presented in bullet form are now simply indented without bullets. For example, this edit by User:EEng (I don't have it in for you; you've just been busy) changed this:

• Publication dates in article references should all have the same format. Although nearly any consistent style may be used, avoid all-numeric date formats other than YYYY-MM-DD.

For example, in the same article, write

• Jones, J. (20 Sep 2008)
• Smith, J. (Sep 2002)

but not

• Jones, J. (20 Sep 2008)
• Smith, J. (September 2002)

to this:

• Publication dates in article references should all use the same format. For example, in a single article write

Jones, J. (20 Sep 2008)

Smith, J. (Sep 2002)

but not

Jones, J. (20 Sep 2008)

Smith, J. (September 2002)

Similarly, this edit, introduced this:

• In spelling out numbers, "components" from 21 to 99 are hyphenated; larger ones are not:

fifty-six

five hundred

two thousand four hundred sixty-six

four hundred seven

I'm not sure this is a good thing. Adopting such formatting has a potential to cause confusion between where one example ends and the next begins if the examples are long enough approach the right-hand margin (depending on the device/screen size/window size you happen to be using), which would seem to contradict the point EEng made above about separating examples with semicolons for clarity. Should the bullets return? —sroc 💬 07:33, 19 January 2014 (UTC)

• Hm, it does look cleaner without the bullet points, but that's pretty much an example of form winning over function. I'd vote for returning bullet points back, as it makes clear where are the boundaries of examples. — Dsimic (talk) 01:28, 20 January 2014 (UTC)

Ah, but the hanging indent solves that, as you'll see in a moment. I hope no one objects to my merging this section with the section just prior, because they're actually the same subject. I'm also going to outdent the remainder of my post. Ready? Execute outdent! Executing outdent, sir!

OK, that's better.

Unfortunately the Jones/Smith example above is unique in that the Jones/Smith entries together constitute a single example -- they're not two separate examples. (Though that one example is used repeatedly -- once in green/good, then , modified, in red/bad). So let's leave that one for now. The "numbers writ out" example is more typical. Anyway, take a look at this. Try successively narrowing the window to see what happens to the examples.

Pretend these are MOS rules, each introduced by a bullet:

• A MOS rule saying lorem ipsum
• A second MOS rule, being a very very very very very very very very very very very very very very very long one wrapping to multiple lines
• Another MOS rule saying lorem ipsum lorem ipsum lorem ipsum lorem ipsum lorem ipsum

• A MOS rule blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah Current technique for examples Each is bulleted:

• good example, bad example or other information
• good example somewhat longer, bad example longer longer longer longer longer
• unusual example which exhibits a length so very very long that it almost (but not absolutely) certainly wraps to the next line, bad example
• good example, bad example

• Another MOS rule blah blah blah blah blah blah Alt 1 Using hanging indent instead:

good example, bad example or other information

good example somewhat longer, bad example longer longer longer longer longer

unusual example which exhibits a length so very very long that it almost (but not absolutely) certainly wraps to the next line, when it wraps, see what hanging indent does

good example, bad example

• Another MOS rule blah blah blah blah blah blah Alt 2A: bullet list using &bull;

  •  good example, bad example or other information

  •  good example somewhat longer, bad example longer longer longer longer longer

  •  unusual example which exhibits a length so very very long that it almost (but not absolutely) certainly wraps to the next line, when it wraps, see what hanging indent does

  •  good example, bad example

• Another MOS rule blah blah blah blah blah blah Alt 2B: Same as 2 w/ modified spacing

   • good example, bad example or other information

   • good example somewhat longer, bad example longer longer longer longer longer

   • unusual example which exhibits a length so very very long that it almost (but not absolutely) certainly wraps to the next line, when it wraps, see what hanging indent does

   • good example, bad example

• Another MOS rule blah blah blah blah blah blah Alt 2C: "bullet" is & gt;

  > good example, bad example or other information

  > good example somewhat longer, bad example longer longer longer longer longer

  > unusual example which exhibits a length so very very long that it almost (but not absolutely) certainly wraps to the next line, when it wraps, see what hanging indent does

  > good example, bad example

• Another MOS rule blah blah blah blah blah blah Alt 2D: "bullet" is & rarr;

 → good example, bad example or other information

 → good example somewhat longer, bad example longer longer longer longer longer

 → unusual example which exhibits a length so very very long that it almost (but not absolutely) certainly wraps to the next line, when it wraps, see what hanging indent does

 → good example, bad example

• Just another rule at the end

An advantage of bullets is that they catch the eye as it passes down the page: "point... next point... next...". They give the first-time reader overview ("OK, I see there are 4 short points for me to absorb, then one long one..."); the returning reader seeking a point vaguely remembered can use the bullets to skip quickly from point to point ("This one? No, next bullet... This one? No, next bullet...").

What I don't like about the current technique is that the bullets on the examples dilute the eye-catching function of the first-level bullets, and make the left margin much busier, especially since most examples fit on a single line anyway: you pretty much get bullet after bullet coming at you, like from a machine gun.

Instead I'm proposing (for discussion -- not married to it) to replace the bullets with hanging indentation, as seen in Alt 1. I think it's a good fit because most examples fit on one line anyway, so that visually each new line is a new example -- no bullet needed. For the occasional example that wraps to a second line, the hanging indent gets the second (and any subsequent) lines out of the way visually, but indenting them more.

One issue is that the {{hanging indent}} template is verbose. I suppose we could invent {{hi}} for short. Thoughts? EEng (talk) 01:55, 20 January 2014 (UTC)

• Got your point with the hanging indentation, and it does work as expected. Though, with all the respect, I still prefer bullet points, as they simply make things more readable, at least to me. Maybe those bullet points are welded into my perception after spending so much time looking into them, but that's my current point of view.

How about making second-level (and third etc.) bullet points different than the first-level ones? I do agree that having multiple-level bulleted lists is making overall layout overcrowded, especially with short lines on the second level. If we had second-level bullet points different and thus less visibile, maybe that would also be a good solution? — Dsimic (talk) 03:23, 20 January 2014 (UTC)

I agree, having all levels of bullets identical makes it more difficult to parse the page at a glance. Having different bullets at different levels could work, but it may be too much to expect the wiki software to do this automatically. Perhaps we can invent a bullet specifically for examples?

An alternative would be to indent the sub-ordinate bullets by more than one step to make the leap between super-ordinate list of points and sub-ordinate list of examples more obvious, but I'm sure this would have its share of problems (e.g., reduced compatibility with smaller screens). —sroc 💬 07:10, 20 January 2014 (UTC)

See Alts 2A (smaller bullet) and 2B to 2D (fanciful variations). As usual there's a bewildering array of mis-named ill-coded templates for symbols and formatting, so I just hacked it up for now. No doubt there's a cleaner way to do it -- if nothing else we can invent another mis-named, ill-coded template. For anyone considering rushing in where angels fear to tread, {{bullet}} doesn't give the same thing as & bull; and see partial list of bullet-like things here Template:•/doc#Dot_size_reference_list. EEng (talk) 09:32, 20 January 2014 (UTC)

Looks good. I would prefer simpler bullets (e.g., circles) rather than icons which might otherwise be used in examples (e.g., 30,00,0000 → 30,000,000). —sroc 💬 11:20, 20 January 2014 (UTC)

Everyone's excited about &bull;

To me, these below are perfect – looking great, consistent with the first-level bullets layout/spacing, and of course very readable:

• Another MOS rule blah blah blah blah blah blah Alt 2A: bullet list using &bull;

  •  good example, bad example or other information

  •  good example somewhat longer, bad example longer longer longer longer longer

  •  unusual example which exhibits a length so very very long that it almost (but not absolutely) certainly wraps to the next line, when it wraps, see what hanging indent does

  •  good example, bad example

With a neat template, maybe {{bullet2}}, {{smb}} (small bullet) or something similar, that would be awesome. — Dsimic (talk) 21:09, 20 January 2014 (UTC)

I agree -- looks great! I'll use it in a few places live, using the hackish approach from above, and hope to stimulate more reaction. In the meantime, take a look at Template:Unordered_list -- do any of those geekishly-explained parameters allow us to substitute the "bullet" character? One special problem, I can predict now, is that the template machinery has to take into account the width of the bullet, in order to pad the right spacing on each side to get the total margin indent right.

Other editors -- what do you think? EEng (talk) 03:21, 21 January 2014 (UTC)

Template:Unordered list uses CSS to specify a base-64 encoded PNG image in order to produce customized bullet points, so everything should be still properly aligned when that image is substituted with another image of the same size. So, I've created a suitable PNG image (containing a small bullet), and tried specifying it through list_style and item_style parameters, but with zero success – bullets are staying the same, while everything is Ok with the CSS (it works as expected when applied via Firebug, for example).

Either I'm doing something wrong, or the template doesn't allow changing the value of list-style-image CSS property. Here's an example; merge it into single line, got it broken into multiple lines so it doesn't break the layout of this talk page:

{{unordered list|one|two|three|list_style=list-style-image: url("data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAUAAAANAQMAAABb8jbLAAAABlBMVEUAAAAAAAClZ7nPAAAAA XRSTlMAQObYZgAAAAFiS0dEAIgFHUgAAAAJcEhZcwAACxMAAAsTAQCanBgAAAAHdElNRQfeARYCMSElQjWOAAAAD0lEQVQI12NgQ AEFYAgGAAvqAVGb+hUDAAAAAElFTkSuQmCC");}}

— Dsimic (talk) 03:03, 22 January 2014 (UTC)

Hopefully some helpful wizard will drop by to explain what's going on with that. Just to repeat, the character we're so excited about is &bull;, and note that the *-at-line-begin syntax doesn't give this "bullet" but something else. In the meantime, for simple cases where there's no chance of linewrap (certain tables, etc.) I've created {{bullj}} (for "bull just" or "just-a-bull", since some idiot's created {{bullet}} and even {{bull}} to mean nbsp + &bull; + space -- how dumb can you get?) EEng (talk) 04:05, 22 January 2014 (UTC)

When tried out with plain HTML, like this:

<ul style="list-style-image:url(data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAUAAAANAQMAAABb8jbLAAAABlBMVEUAAAAAAAClZ7nPAAAAA XRSTlMAQObYZgAAAAFiS0dEAIgFHUgAAAAJcEhZcwAACxMAAAsTAQCanBgAAAAHdElNRQfeARYCMSElQ jWOAAAAD0lEQVQI12NgQAEFYAgGAAvqAVGb+hUDAAAAAElFTkSuQmCC);">

<li>one</li>

<li>two</li>

<li>three</li>

</ul>

the rendered HTML contains

<ul style="/* insecure input */">

what almost for sure means that MediaWiki disallows such embedding of images inside CSS definitions. Such stuff could be used for exploiting some security issues in browsers, so it's understandable why that isn't allowed. — Dsimic (talk) 04:30, 22 January 2014 (UTC)

What we could get are square points, like this:

• First level, then second
  • one
  • two
  • three

D'oh! — Dsimic (talk) 04:37, 22 January 2014 (UTC)

Nah, that spoils it, because those squares aren't as visually retiring as & bull; If worse comes to worst, can't we just copy {{unordered list}} to some new name (and please, let's think about that name first) and suitably modify it? EEng (talk) 05:16, 22 January 2014 (UTC)

I agree, squares are not even remotely close to what &bull; provides. Discovering that required CSS adjustments aren't allowed was pretty much a sinking feeling... To my (quite shallow) knowledge of MediaWiki, no approach of copying or modifying existing templates would bring us there, as those protections are probably deep inside MediaWiki (based on CSS being filtered out on a plain <ul> HTML element). Anyway, just as I wrote, my knowledge of MediaWiki is not so good, so let's see what the other editors are going to say about this. — Dsimic (talk) 05:26, 22 January 2014 (UTC)

Revamped "Acceptable date fmts" table

I've (boldly -- yes indeed very boldly) revamped the "Acceptable fmts" table at [[12]]. I think it presents all the previous info more systematically, but I know change can be disconcerting. Comments invited.

However, unless it's really, really wrong, I'd appreciate its being left in place for at least a while so others can see and comment on it, so as many as possible can be involved. EEng (talk) 03:41, 21 January 2014 (UTC)

Here are the old and the new...

[Later: In addition to OLD and NEW, there's a new Alt1] EEng (talk) 07:47, 21 January 2014 (UTC)

OLD Acceptable date formats

Format	Example	Where used
D MMMM YYYY Day, space, full month, space, full year	8 September 2001	General use
MMMM D, YYYY Full month, space, day, comma, space, full year	September 8, 2001
D MMM YYYY Day, space, short month, space, full year	8 Sep 2001	Only in references, tables, lists or areas where conciseness is needed (see Wikipedia:Citing Sources § Citation style)
MMM D, YYYY Short month, space, day, comma, space, full year	Sep 8, 2001
YYYY-MM-DD Full year, hyphen, two-digit month, hyphen, two-digit day; use only with years 1583–9999	2001-09-08
D MMMM (Day, space, full month) MMMM D (Full month, space, day)	5 March March 5	Only where no ambiguity (He was born 1866 May 5 but died June 7 or January 1 is New Year's Day)

• When writing dates as MMMM D, YYYY, follow the year with a comma (unless the year is followed by other punctuation):

The weather on September 11, 2001, was clear and warm.

Everyone remembers where they were on July 21, 1969—when Neil Armstrong first set foot on the Moon.

Acceptable date formats (NEW, Alt0)

NEW (Alt0, as posted and reverted) Acceptable date formats For general use For use only where brevity required (references, tables, lists, etc.‍—‌see WP:Citing Sources#Citation style) Notes 22 April 2001 Code: 22{{nbsp}}April 2001 22 April  22 Apr 2001 Code: 22{{nbsp}}Apr 2001 22 Apr  Omit year only where there is no risk of ambiguity: Born 5 May 1866, he died on 7 June January 1 is New Year's Day When writing a date such as April 22, 2001, follow the year with a comma (unless followed by other punctuation): The weather on July 11, 1969, was clear and warm. Everyone remembers July 21, 1969—when man first set foot on the Moon. April 22, 2001 Code: April{{nbsp}}22, 2001 April 22  Apr 22, 2001 Code: Apr{{nbsp}}22, 2001 Apr 22  [yyyy-mm-dd format not for general use] 2001-09-22 Code: 2001-09-22 Use only with years 1583–9999

Acceptable date formats (NEW, Alt1)

Where used Example Markup General use 22 July 2001 22{{nbsp}}July 2001 July 22, 2001 July{{nbsp}}22, 2001 When using these formats, follow the year with a comma (unless followed by other punctuation): The weather on July 21, 1969, was clear and warm. Everyone remembers July 21, 1969‍—‌when man first set foot on the Moon. Only where brevity required (references, tables, lists, etc.‍—‌see WP:Citing Sources#Citation style) Jul 22, 2001 Jul{{nbsp}}22, 2001 22 Jul 2001 22{{nbsp}}Jul 2001 2001-07-22 2001-07-22 Use only with years 1583–9999 Only where no risk of ambiguity: Born 5 May 1866, he died on 7 June January 1 is New Year's Day 22 July July 22 Jul 22 22 Jul 22{{nbsp}}July July{{nbsp}}22 Jul{{nbsp}}22 22{{nbsp}}Jul

Well, that didn't take long

According to one observer [13], the new table "looks awful, is confusing, and has left out substance from the original." Let's start with the least subjective complaint. What "substance from the original" has been left out? EEng (talk) 04:26, 21 January 2014 (UTC)

I like the new format - people tend to absorb examples (with a small amount of notes) better than they absorb lavishly detailed formulae and explanations. Minor gripes: 'Code:' is probably confusing to most people. Possibly use 'Wiki mark-up:' or similar. Even better to drop the entire line (no need to worry about & nbsp ; to avoid splitting on line breaks).  Stepho  talk  05:34, 21 January 2014 (UTC)

Thanks. I'll wire your "expense reimbursement" to the usual numbered account, yes? I think the code is important though, for a coupla reasons

• Editors really should be learning to place {{nbsp}}s as appropriate. It's maybe 50% a pet peeve of mine, but 50% is that it looks awful when a day # is stranded at the end of a line.
• It replaces the awkward "year, space, full month, comma, space, day" that was there anyway.

I put the code directly beneath the sample date to help the reader relate the bits of code to the human format. Maybe that's not so good. Anyway, I'm working up another fmt that's more like the old one (and changes "Code" per your suggestion).

EEng (talk) 05:51, 21 January 2014 (UTC)

OK, see Alt1 above -- now my preferred (and proposed) version. Thoughts? EEng (talk) 07:47, 21 January 2014 (UTC) P.S. Still would like to hear what "substande from the original" is missing, as claimed.

Thank you for bringing the discussion to the talk page. Making radical (potentially controversial[*]) changes to project pages (particularly the much trafficked MOS) without discussion first is so prone to upset and edit-warring, especially if one repeatedly undoes reverts by others and leaves a breadcrumb trail of edit summaries to justify the changes instead of forming consensus first. [*By "controversial", I mean subject to dispute or differing opinions, not necessarily scandalous. 15:36, 21 January 2014 (UTC)]

Let me add that EEng has been putting a lot of effort into MOS these last few days and I think some of this is a marked improvement on the earlier state of affairs: for example, setting out the entire "Unacceptable formats" section in a table is clearer than the dot points and random-examples-table we had, and it was a bright spark to come up with that. Kudos.

I actually think the old "Acceptable date formats" table was fine — I refer here to the last consensus version without the last row D MMMM and MMMM D that EEng has inserted here. I'm not afraid of innovation, but I have the following issues with these revised versions:

1. It is less clear because it does not provide any explanation of the acceptable formats (e.g., D MMMM YYYY) and instead relies solely on examples. This compounds confusion when the guideline later refers to specific formats (e.g., "YYYY-MM-DD") without having established that notation earlier. The reader has to read between the lines, and this is unnecessary.

2. The coding is unnecessary: editors know how to enter the text. It's also garish.

3. In both the new "Old" version and revised "Alt1" version, it is unclear whether omitting the year is permitted only in prose or in references as well.

4. The example Born 5 May 1866, he died on 7 June is very much prone to ambiguity: it is not at all clear that "he" died in the same year as his birth, so it's a horrible example for "where there is no risk of ambiguity".

5. Tables should have a heading for each column: e.g., in the "Alt1" version, the last column might be headed "Notes".

6. Tables become ugly when cells are merged over different spans in different columns: for example, in the "Alt1" version, disregarding the header row, the first cell in the first column ("General use") spans rows 1 and 2 and the second cell (Only where brevity required") spans rows 3, 4 and 5, whereas the first cell in the third column spans rows 2 and 3, and therefore spans some but not all of two different "Where used" cases. This is rather counter-intuitive and no doubt difficult for some readers to follow which cells overlap which rows.

7. Shrinking the text to shoehorn long notes and examples into all-pervasive tables makes it more difficult to read and may present an accessibility issue.

—sroc 💬 10:17, 21 January 2014 (UTC)

8. The last row in "Alt1" implies that D MMM and MMM D formats may be used anywhere there is no ambiguity over the missing year; actually, these formats should not be allowed in prose (just as neither are D MMM YYYY nor MMM D, YYYY), but this is not clear from the structure of the table.

9. The formatting of the examples in that row ("22 July/July 22/Jul 22/22 Jul") is cracked because the line breaks are within the example templates rather than using a separate template on each line: with my custom CSS, they are formatted as a single example with line breaks (i.e., no borders at the start/end of each line).

—sroc 💬 15:36, 21 January 2014 (UTC)

Alt 1B

Thank you for your kind comments and (despite confusion re nuns) I look forward to continued collaboration. I hope you'll forgive my numbering your points above for ease of reference, and I've created a revised "Alt 1B" incorporating some of your comments.

1. With one exception the only format referred to later is "the all-numeric YYYY-MM-DD", and I've added e.g. "(e.g. 2001-04-22)" at each reference to clarify (a bit clunky, but that can be improved later). The exception is that in the no-no table the formats DD-MM-YYYY and MM-DD-YYYY are mentioned, and these are directly adjacent to examples of those formats which make it obvious what is meant. The other format "pictures" aren't used at all so the old table was teaching a headache-inducing taxonomy for no apparent purpose.

2. I think the code layouts are good for two reasons (neither of which, on its own, would convince me to use them):

• Contrary to what you say, editors don't know where to put the {{nbsp}}s, as is obvious from looking at almost any article
• The code layouts double as replacements for the very clunky "full month name, space, day, comma, space, blah, blah, huh??" specifications inflicted by the old tables

3. If you think this is important suggest clarifying text to be added.

4. We've gone over and over this. You keep fussing that this --

In 1877 a son was born January 13, but the child died February 8.

-- is ambiguous because (you say) the reader can't be sure that the "February" referred to is February of 1877. I'm sorry, but that's ridiculous, and reflects the strange rigidity of thinking that you display now and then. (I say that with only the greatest affection, of course.) It's just idiotic. No one in his right mind would read that and say, "Huh? Wait... did the baby die at age one month, or one year and a month, or two years and a month... maybe the baby grew up and became President of the US and then died at the age of 87 years, plus one month. What ambiguous writing!" You would have us write --

An appeal was filed September 3, 1972; arguments were heard on September 27, 1972; and the Court ruled October 4, 1972.

-- instead of --

An appeal was filed September 3, 1972, arguments were heard on September 27, and the Court ruled October 4.

In fact, let me quote from a recent US Supreme court opinion Planned Parenthood v. Abbot (November 19, 2013):

In July of this year, the State of Texas passed two amendments to its abortion laws, which were to go into effect on October 29.

Mr. Justice Breyer didn't write "to go into effect on October 29, 2013", because he knows that his readers, by application of their native shrewdness, will infer that "October" is the October following the July already specified.

Now please, since the Supreme Court has ruled in my favor, can we drop this?(I surmise that you live outside that court's jurisdiction, but I'm asking you to respect its moral, if not judicial, authority.) EEng (talk) 08:33, 22 January 2014 (UTC)

5. No, not every column of every table needs a heading. If the content of a column is patently obvious, and can only be described by some vacuous phrase, then a heading adds nothing and can (or should) be omitted.

6. I agree that the relationship of the cells and overlaps take some thinking to understand, but that reflects the complexity of the rules being represented, which induce a sort of Venn diagram of rules applying to cases. The alternative is to go back to a lot of bullet items describing verbally, instead of visually, which rules apply to which formats. (I've changed it a bit in the new version below.) Also, this can probably be improved by changing the weight of (or erasing) some of the cell borders.

7. I "smalled" the verbiage because I think it looks better. I could be wrong. As I recollect {{small}} keeps text within size guidelines.

8. This requires more of the complex precision you complained of in item 6. However, I've tried to address this in Alt 1B below -- probably can do better with some thought.

9. Fixed in Alt 1B.

EEng (talk) 08:33, 22 January 2014 (UTC)

Acceptable date formats (NEW, Alt1B)

Acceptable date formats (NEW, Alt1B)

Where used Example Markup General use 22 July 2001 22{{nbsp}}July 2001 July 22, 2001 July{{nbsp}}22, 2001 When using these formats, follow the year with a comma (unless followed by other punctuation): The weather on July 21, 1969, was clear and warm. Everyone remembers July 21, 1969‍—‌when man first set foot on the Moon. Only where brevity required (references, tables, lists, etc.‍—‌see WP:Citing Sources#Citation style) Jul 22, 2001 Jul{{nbsp}}22, 2001 22 Jul 2001 22{{nbsp}}Jul 2001 2001-07-22 2001-07-22 Use only with years 1583–9999 Shorten month only where brevity is required, per above. Omit year only where no risk of ambiguity: Oktoberfest 2013 began 21 September and ended 6 October January 1 is New Year's Day 22 July July 22 Jul 22 22 Jul 22{{nbsp}}July July{{nbsp}}22 Jul{{nbsp}}22 22{{nbsp}}Jul

Alt 1C/1D

Here's my go at showing how this table might be better adapted. I've also replaced the {{center}} template with align=center | as it's easier to follow than counting the nested braces.

Acceptable date formats (NEW, Alt1C)

Where used Example Markup Notes General use 22 July 2001 22{{nbsp}}July 2001 July 22, 2001 July{{nbsp}}22, 2001 When using these formats, follow the year with a comma (unless followed by other punctuation): The weather on July 21, 1969, was clear and warm. Everyone remembers July 21, 1969‍—‌when man first set foot on the Moon. Only where brevity required (references, tables, lists, etc.‍—‌see WP:Citing Sources#Citation style) Jul 22, 2001 Jul{{nbsp}}22, 2001 22 Jul 2001 22{{nbsp}}Jul 2001 2001-07-22 2001-07-22 Use only with years 1583–9999 General use 22 July July 22 Jul 22 22 Jul 22{{nbsp}}July July{{nbsp}}22 Jul{{nbsp}}22 22{{nbsp}}Jul Omit year only where no risk of ambiguity: Oktoberfest 2013 began 21 September and ended 6 October January 1 is New Year's Day Shorten month only where brevity is required, per above.

Where did this requirement to use {{nbsp}} in dates come from? —sroc 💬 11:06, 22 January 2014 (UTC)

Here 'tis without the markup column, the only purpose of which is to highlight the use of {{nbsp}} (which is not the only way to produce a non-breaking space, nor does this appear to be an established convention):

Acceptable date formats (NEW, Alt1D)

Where used Example Notes General use 22 April 2001 April 22, 2001 When using these formats, follow the year with a comma (unless followed by other punctuation): The weather on July 21, 1969, was clear and warm. Everyone remembers July 21, 1969‍—‌when man first set foot on the Moon. Only where brevity required (references, tables, lists, etc.‍—‌see WP:Citing Sources#Citation style) Apr 22, 2001 22 Apr 2001 2001-04-22 Use only with years 1583–9999 General use 22 April April 22 Omit year only where there is no risk of ambiguity: Oktoberfest 2013 began 21 September and ended 6 October January 1 is New Year's Day Only where brevity required (as above) Apr 22 22 Apr

—sroc 💬 11:20, 22 January 2014 (UTC)

A request

Thank you to everyone who has been working to improve the MOS documentation! I do have a request about the last example in MOS:BADDATEFORMAT, which shows born in 1995. While I agree this is perfectly fine within a full sentence, the standard format for the lead of our biographical articles would be Joe Schmo (born 1995) is a ....., and I would hate for people to accidentally misinterpret the example and start using Joe Schmo (born in 1995) is a ..... instead. Is there another example we could choose to illustrate that we should use "in the year" only where needed for clarity? Maybe sold in the year 1995 and sold in 1995 (or some other short word instead of "born")? Thanks! GoingBatty (talk) 21:51, 21 January 2014 (UTC)

You wish is my command. Done. EEng (talk) 08:33, 22 January 2014 (UTC) (I tried to work Joe Schmo in but it made the example too wide for the column.)

Unwitting rejection of printed style guides

In a recent edit, EEng removed this phrase: "Although nearly any consistent style may be used". This phrase acknowledged that dates within citations may follow the mandate of the citation style used in the article. For example, APA style would call for the date of today's newspaper, in a citation, to be written "2014, January 18". I have reworded so that there is no change in meaning to the guideline. Jc3s5h (talk) 01:15, 19 January 2014 (UTC)

In "dates within citations may follow the mandate of the citation style used in the article" (which -- correct me if I'm wrong -- is your phrase, not MOS') is it your intention that "used in the article" mean "used in the article being cited"? If so that's hard to swallow since the various articles cited in any one WP article will employ a variety of date formats, and if those are imported into WP's citations of those articles, the citations will contain all kinds of different date formats willy-nilly, making nonsense of the "consistent format" provision. I fancy myself less of a control freak than most of those hanging around here, but even I can't conceive that the Creator intended dates-within-citations to constitute a do-whatever-feels-groovy zone.

That leaves "used in the article" to mean "used in the WP article doing the citing", and therefore the "any consistent style" needs to be one of the formats listed as acceptable in the prior sections.

Is there something I'm missing? EEng (talk) 20:26, 19 January 2014 (UTC)

Naturally, by "used in the article" I mean the citation style adopted for a particular Wikipedia article, not the citation style (if any) used in the article being cited. This freedom comes from WP:Citing sources#Citation style. So the table of acceptable date formats does not apply if a different date format has been adopted for citations. This is the inevitable result since Wikipedia decided to write a style guide that only explains the style of the article body, not the citations. Jc3s5h (talk) 21:02, 19 January 2014 (UTC)

Are you sure about this? The "Acceptable date formats" table/section elaborately enumerates all the acceptable and unacceptable formats, and even identifies certain formats as usable only in references and certain other places -- no hint that pub dates in citations can use all kinds of other formats too. And the examples in the "consistency" section use only formats in the "Acceptable" table.

I don't care a whit about which date formats are allowed in citations, but I'm not looking forward to trying to cast these maze-like regulations into something editors can readily comprehend. So (not that I don't believe you, Jc) I'd like to hear this confirmed by other editors. EEng (talk) 23:08, 19 January 2014 (UTC)

But that's not true, is it? The table at MOS:DATEFORMAT specifically refers to formats acceptable for citations in references, and MOS:DATEUNIFY provides guidance and examples for date formats in publication, access and archive dates for references. I inherently understood that the MOS for dates applies to citations as it does to everything else. If this is not the case and citations are an exception (and I would not think that this would be desirable), then MOS:DATEFORMAT is not clear on this and there is an apparent inconsistency. —sroc 💬 22:40, 19 January 2014 (UTC)

Wikipedia editors have been unable to reach consensus about whether MOS applies at all to citations. Note, however, that the "Punction and footnotes" section of MOS lists WP:CITE as the main page for that topic. Also, the MOS simply doesn't provide information on how to style a citation, so some system must be found for each article. It would be rather inconvenient to say it's OK to use, for example, APA style but the dates have to be changed; that would break any program that might be used to help with the citations, such as Zotero. In this guideline, the acceptable dates formats could be understood to prohibit abbreviated and all-numeric dates in places where space is not limited (and references being a place where space has been considered limited). The bullet point about publication date modifies the table, allowing dates in citations that follow the citation style that has been adopted for the article. Jc3s5h (talk) 23:01, 19 January 2014 (UTC)

To reiterate, if WP:CITE were an exception to MOS:DATEFORMAT (agreed by consensus), then this should be explicitly stated. As it stands, there is inconsistency between them to the extent that WP:CITE purports to allow citations to include date formats which are unacceptable under MOS:DATEFORMAT. How can this be resolved one way or the other? —sroc 💬 23:40, 19 January 2014 (UTC)

A previous related discussion may be found at Wikipedia talk:Manual of Style/Dates and numbers/Archive 135#Proposal:_date_formats_in_reference_sections Jc3s5h (talk) 00:27, 20 January 2014 (UTC)

Edit history chaos

Goodness me: this tidal wave of more than 100 piecemeal edits over the past six days—about 30 today alone—is it all consensual? I'm going to have to return a number of times to try to make sense of it. Tony (talk) 11:24, 19 January 2014 (UTC)

As discussed above, "piecemeal" = it's easy to verify that each step of the process doesn't change the meaning, only the presentation. Shall we stop and wait for you to catch up?

As for whether all this is consensual: I've certainly been subject to no coercion, compulsion, or undue influence, and all these edits are my free acts and deeds. But I'm only speaking for myself. Sroc, has anyone threatened you or otherwise attempted to compel you to edit in any way against your will? EEng (talk) 12:08, 19 January 2014 (UTC)

He's lying! He's forcing me to edit! Call the police! I'm in an abandoned server farm at IP 32 point 122 point 6<mmmph!> EEng (talk) 12:08, 19 January 2014 (UTC) P.S. <grunt!><grrrrr!>OK, I'll be good. Don't make me watch any more Youtube cat videos, please! I'll be good!

Ha, ha. Pay no attention to the man behind the curtain. Just part of the show, folks. Almost seems real, doesn't it?

No, I'm serious! It's horrible here -- we only have dialup! How can you people stand by and let this happen? Save me!

I think Tony1 is nervous about the (many!) edits not having been discussed on the talk page first. My suggestion is to do a comparison between one version before the "tidal wave" and the present version. There have been some edits that have been reverted, re-reverted, reworded, moved, paraphrased, relocated into table, reformatted, shot with a giant camera, transmitted in a million pieces, and reassembled a little smaller than before. The substance should hopefully still be the same, just in a different format which is hopefully easier to follow that before. —sroc 💬 12:50, 19 January 2014 (UTC)

Nonsensical delimitation

Within the guideline is toleration/acceptance of numerical separation that would appear highly unusual if not nonsensical to the average English speaker. We have:

Sometimes, the variety of English used in an article may call for the use of a numbering system other than the Western thousands-based system. For example, the South Asian numbering system is conventionally used in South Asian English. In those situations, link the first spelled-out instance of each quantity (e.g. [[crore]], which yields crore). (If no instances are spelled out, provide a note after the first instance directing the reader to the article about the numbering system.) Also, provide a conversion to Western numbers for the first instance of each quantity, and provide conversions for subsequent instances if they do not overwhelm the content of the article. For example, write three crore (thirty million). Similarly, if you write 3,00,00,000, also write (30,000,000) or (30000000). (Note that the variety of English does not uniquely determine the method of numbering in an article. Other considerations, such as conventions used in mathematics, science and engineering, may also apply, and the choice and order of formats and conversions is a matter of editorial discretion and consensus.)

With the exception of the articles on crore, lakh, Indian Numbering System and Indian English, I cannot see why we would have 3,00,00,000 / 3 crore in the running text, and want/need to "translate" these into both (30,000,000) and (30000000). We don't "translate" 30000000 into 30,000,000 in scientific articles. To require having all these conversions for 3,00,00,000 contributes unnecessary clutter and violates WP:COMMONALITY. Such numbers ought to be made into (30,000,000) (or (30 million)) 30,000,000 (or 30 million) <redacted> by default with there being no permitted use of 3,00,00,000 or 30000000. -- Ohc ^¡digame! 12:38, 19 January 2014 (UTC)

We obviously don't translate 30000000 into 30,000,000 (or vice versa) because the spacing is identical, only the separator is different. I assume you mean "Such numbers ought to be made into either 30,000,000 or 30 million by default"; not that these should be given as "3,00,00,000 (30,000,000)" or "3,00,00,000 (30 million)" as the parentheses in your comment suggested? I agree that it would be confusing to encounter 3,00,00,000 on English Wikipedia, except in an article specifically discussing such number systems where attention is drawn to the otherwise-unexpected spacing. —sroc 💬 12:59, 19 January 2014 (UTC)

Sorry, that is indeed what I meant. I copied the templates and didn't remove the parentheses properly. I also meant that using "lakh" and "crore" are meaningless to the English audience, and would add to unnecessary glossing and/or linking. Cheers, -- Ohc ^¡digame! 13:02, 19 January 2014 (UTC)

This makes more sense now:

*Sometimes, the variety of English used in an article may call for the use of a numbering system other than the Western thousands-based system. For example, the South Asian numbering system is conventionally used in South Asian English. In those situations, link the first spelled-out instance of each quantity (e.g. [[crore]], which yields crore). (If no instances are spelled out, provide a note after the first instance directing the reader to the article about the numbering system.) Also, provide a conversion to Western numbers for the first instance of each quantity, and provide conversions for subsequent instances if they do not overwhelm the content of the article. For example, write three crore (thirty million). Group digits in Western thousands-based style (e.g., 30,000,000, not 3,00,00,000): see Delimiting (grouping of digits) below. (Note that the variety of English does not uniquely determine the method of numbering in an article. Other considerations, such as conventions used in mathematics, science and engineering, may also apply, and the choice and order of formats and conversions is a matter of editorial discretion and consensus.)

• Definitely an improvement over my hatchet-job, thanks. However, I still fail to see the validity or interest of tolerating use of a numbering system (crore, lakh) that is alien to a vast majority of our readers. So I reckon these should be specifically banished in the guideline. But perhaps that's for another day. Regards, -- Ohc ^¡digame! 14:41, 19 January 2014 (UTC)

Hmmm, it looks like a lot of uses of crore do not explain the term and in some cases use it as if it were a currency rather than a numbering unit. The articles at least could use some improvement to comply with MOS:NUMERAL either way. —sroc 💬 14:59, 19 January 2014 (UTC)

I've been trying to clean those up, but it's a struggle. -- Ohc ^¡digame! 15:10, 19 January 2014 (UTC)

Hmmm, there seem to be some misconceptions here. There's nothing non-Western about numbering systems that are not (entirely) thousands-based: the myriad, and modern Greek usage thereof, being one example; the defunct miriametro (10,000 m) is still taught to Italian schoolchildren. So I don't think it has anything to do with language variety. Also, I'm not sure with what justification we would instruct speakers of Subcontinental English not to use the numbering system to which they are accustomed. I note that we do not instruct speakers of Transatlantic English to wake up and use the metric system like everyone else in the world; on the contrary, we go (correctly, in my view) to great lengths to accommodate their eccentricity. I would suggest a much shorter text which specifies that names for higher powers of ten that are outside the common short scale usage (such as lakh and myriad) should be written in words, with a numerical equivalent in brackets; and that comma separators in numbers written in figures should always follow the short scale convention. Any use? Justlettersandnumbers (talk) 19:15, 19 January 2014 (UTC)

Oddity in MDY guideline

The revised text for MOS:DATEFORMAT says:

In the MMMM D, YYYY format the year is followed by a comma...

Ironically, this statement is self-contradictory, because it should read:

In the MMMM D, YYYY, format the year is followed by a comma...

Now, there is some conjecture over whether the comma should be enforced when MDY dates are used as adjectives (although neither the above wording nor MOS:COMMA makes any such exception), but there is a strong view that such uses should be avoided in any case (although a recent RFC to say so at MOS:COMMA was unsuccessful due to disagreement over the wording). To avoid this problem, I suggest either:

• Reverting to the "MDY" wording:

In the MDY format the year is followed by a comma...

• Recasting the sentence:

When using MMMM D, YYYY, the year is followed by a comma...

—sroc 💬 16:10, 19 January 2014 (UTC)

Actually, that should also apply to dates in the format MMM D, YYYY (Retrieved Feb 5, 2009, from...), so perhaps the "MDY" wording is preferable to cover both formats. —sroc 💬 22:47, 19 January 2014 (UTC)

Human height

At Talk:Ian_Baker-Finch an editor has cited WP:UNITS as a reason for prohibiting the use of centimetres to display human height. This doesn't seem right, as the WP:SOURCES that the heights of people are taken from frequently use centimetres, and accordingly consensus appears to exist at the Human height article for their use.--Gibson Flying V (talk) 23:48, 21 January 2014 (UTC)

SI units include base units (such as the metre) and derived units (such as the centimetre). Perhaps this was misunderstood. --Boson (talk) 00:01, 22 January 2014 (UTC)

Thank you. Would it be worthwhile to include a mention to that effect in the guideline to prevent any future misunderstandings?--Gibson Flying V (talk) 00:32, 22 January 2014 (UTC)

Well, I think centimeters are fine, but we should draw the line at centimetres. As a wise man once said:

I believe in making the world safe for our children, but not our children's children, because I don't think children should be having sex.

EEng (talk) 02:43, 22 January 2014 (UTC)

Boson is right: centimetre is an SI unit, though not a base unit. This perhaps has implications for the {{height}} template which is designed for infoboxes and only uses metres and feet/inches: see Template talk:Height#Centimetres. —sroc 💬 12:32, 22 January 2014 (UTC)

By the way, by the logic that cm is not an SI unit, one might also say that one was driving at 16.67 m/s (that's 60 km/h for those playing at home). —sroc 💬 12:37, 22 January 2014 (UTC)